交友2.0总结

• 新架构尝试

  • 在交友中尝试使用新架构，原因在于原有的架构耦合度较高，希望能够优化层次结构，降低耦合度，提高项目可维护性。参考了MVVM以及寻欢现有的架构。

  • 一般APP的主要组成部分

    • 数据获取层：网络请求，缓存数据（mem,disk）
    • 业务逻辑层：数据转换、算法逻辑
    • 数据模型层：提供视图所需数据
    • 界面视图层：视图展示，布局，动画

  • 这个架构也是基于以上组成部分

    • 数据获取层：NetService,LocalStore
    • 业务逻辑层：Logic
    • 数据模型层：ViewItem (也可叫ViewModel,含义是一样的)
    • 界面视图层：Controller,View

  • Controller的角色

    为Controller瘦身也是这个架构的目标之一，Controller的角色：视图展示交互及数据传递。

    
    
    

    Controller的角色
    
    

    这个架构中Controller的职责就很简单了，主要负责View的管理。View所需要的数据都交给Logic去处理，Logic通过网络请求或者从缓存数据取数据，再将数据处理成ViewItem返回给Controller,Controller将ViewItem传给View更新UI。Controller里面就不需要执行网络请求，缓存数据，数据处理，达到瘦身的目的。Logic和Controller是一一对应的关系，那会不会造成Logic很臃肿呢？

  • Logic的角色

    
    
    

    Logic角色
    
    

    Logic在这里是一个中间件/粘合剂的角色，Logic从LocalStore或者NetService中获取数据Data，再将Data转成ViewItem,转换方法是ViewItem自己实现，再将生成的ViewItem传给上层的Controller

  • 其他角色

    NetService负责网络请求，LocalStore负责数据缓存，ViewItem包含View所需的展示数据，View和ViewItem是一一绑定的关系。

  • View尽量自定义

    一些大厂把所有基础UIView类都封装了一次，封装的好处在于可以全局修改和复用。如果需要多个View组合的尽量自定义封装成一个独立的类，好处有1.方便界面调试 2.便于复用。

  • 整体架构图

    
    
    

    架构图

  • 总结

    • 这个框架在初期可能会觉得很繁琐，比如某个功能可以都放在Controller处理为何要多出几个部分分别处理。但随着业务的增加项目会越来越庞大，项目层次越清晰会越容易维护，新人更容易上手，查找问题也更容易定位。

• SimpleMediator
  • 原来Controller之间的跳转都写在内部，耦合度高还要引用对应的头文件，不能动态修改，尝试加入跳转中间类来解决。目前实现很简单：每个Controller有一个对应的ControllerId

        + (void)pushControllerWithId:(ControllerId)controllerId params:(NSDictionary *)params

params带所需的参数，每添加一个类都去实现这个方法。

• PerformanceMonitor
  • 原来获取Controller被销毁内存释放不准确，原来的做法是在dealloc时延迟1秒取内存，有可能1秒内又进入新的界面或者原来内存还没有真正释放。现在做法是在pop后执行viewDidDisappear将self传给一个单例，单例weak持有self,单例起个很短间隔的定时器，如果self为nil，则认为内存释放了。