- 新架构尝试
在交友中尝试使用新架构，原因在于原有的架构耦合度较高，希望能够优化层次结构，降低耦合度，提高项目可维护性。参考了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，则认为内存释放了。
