文章标题

App

App 主要做的事

• 1调用网络API
• 2页面展示
• 3本地数据存储
• 4动态部署方案

上面这四点分别针对的是

• 1 如何让业务开发工程师安全方便地调用网络接口API，然后保证用户在各种网络环境下都能有良好的体验
• 2页面如何组织，才能够尽可能降低业务方代码的藕合度，尽可能降低开发界面的复杂度
• 3当数据有本地存储的需求时，如何能够保证数据在本地的合理化安排？尽可能地减少性能的消耗。
• 4iOS应用有审核周期，如何能够通过不发版本的方式展示新的内容给用户？如何修复紧急bug？

针对团队

• 1 收集用户数据，给产品和运维提供参考
• 2 合理地组织个业务方开发的业务模块，及相关基础模块
• 3每日app的自动打包，提供给QA工程师的测试工具
• 4系统崩溃日志统计

这系列文章主要是回答以下这些问题：

• 1网络层设计方案？设计网络层时要考虑哪些问题？对网络层做优化的时候，可以从哪些地方入手？
• 2页面的展示、调用和组织都有哪些设计方案？我们做这些方案的时候都要考虑哪些问题？
• 3本地持久化层的设计方案都有哪些？优劣势都是什么？不同方案间要注意的问题分别都是什么？
• 4要实现动态部署，都有哪些方案？不同方案之间的优劣点，他们的侧重点？

软件设计的方法

第一步：搞清楚要解决哪些问题，并找到解决这些问题的充要条件
关于充要条件我也要说明一下，有的时候系统提供的函数是需要额外参数的，比如read函数。还有翻页的时候，当前页码也是充要条件。但对于业务方来说，这些充要条件还能够再缩减。
比如read，需要给出file descriptor，需要给出buf，需要给出size。但是对于业务方来说，充要条件就只要file descriptor就够了。再比如翻页，其实业务方并不需要记录当前页号，你给他暴露一个loadNextPage这样的方法就够了。
搞清楚对于业务方而言的真正充要条件很重要！这决定了你的架构是否足够易用。另外，传的参数越少，耦合度相对而言就越小，你替换模块或者升级模块所花的的代价就越小

第二步：问题分类，分模块

第三步：搞清楚各问题之间的依赖关系，建立好模块交流规范并设计模块
关键在于建立一套统一的交流规范。这一步很能够体现架构师在软件方面的价值观，虽然存在一定程度上的好坏优劣（比如胖Model和瘦Model），但既然都是架构师了，基本上是不会设计出明显很烂的方案的，除非这架构师还不够格。所以这里是架构师价值观输出的一个窗口，从这一点我们是能够看出架构师的素质的。
tips:
胖Model包含了部分弱业务逻辑。胖Model要达到的目的是，Controller从胖Model这里拿到数据之后，不用额外做操作或者只要做非常少的操作，就能够将数据直接应用在View上。举个例子：
Raw Data:
timestamp:1234567
FatModel:
@property (nonatomic, assign) CGFloat timestamp;
- (NSString *)ymdDateString; // 2015-04-20 15:16
- (NSString *)gapString; // 3分钟前、1小时前、一天前、2015-3-13 12:34
Controller:
self.dateLabel.text = [FatModel ymdDateString];
self.gapLabel.text = [FatModel gapString];

把timestamp转换成具体业务上所需要的字符串，这属于业务代码，算是弱业务。FatModel做了这些弱业务之后，Controller就能变得非常skinny，Controller只需要关注强业务代码就行了。众所周知，强业务变动的可能性要比弱业务大得多，弱业务相对稳定，所以弱业务塞进Model里面是没问题的。另一方面，弱业务重复出现的频率要大于强业务，对复用性的要求更高，如果这部分业务写在Controller，类似的代码会洒得到处都是，一旦弱业务有修改（弱业务修改频率低不代表就没有修改），这个事情就是一个灾难。如果塞到Model里面去，改一处很多地方就能跟着改，就能避免这场灾难。
然而其缺点就在于，胖Model相对比较难移植，虽然只是包含弱业务，但好歹也是业务，迁移的时候很容易拔出萝卜带出泥。另外一点，MVC的架构思想更加倾向于Model是一个Layer，而不是一个Object，不应该把一个Layer应该做的事情交给一个Object去做。最后一点，软件是会成长的，FatModel很有可能随着软件的成长越来越Fat，最终难以维护。

瘦Model只负责业务数据的表达，所有业务无论强弱一律扔到Controller。瘦Model要达到的目的是，尽一切可能去编写细粒度Model，然后配套各种helper类或方法来对弱业务做抽象，强业务依旧交给Controller。举个例子：

Raw Data:  {      "name":"casa",      "sex":"male",  }  SlimModel:      @property (nonatomic, strong) NSString *name;      @property (nonatomic, strong) NSString *sex;  Helper:      #define Male 1;      #define Female 0;      + (BOOL)sexWithString:(NSString *)sex;  Controller:      if ([Helper sexWithString:SlimModel.sex] == Male) {          ...      } 

由于SlimModel跟业务完全无关，它的数据可以交给任何一个能处理它数据的Helper或其他的对象，来完成业务。在代码迁移的时候独立性很强，很少会出现拔出萝卜带出泥的情况。另外，由于SlimModel只是数据表达，对它进行维护基本上是0成本，软件膨胀得再厉害，SlimModel也不会大到哪儿去。
缺点就在于，Helper这种做法也不见得很好，这里有一篇文章批判了这个事情。另外，由于Model的操作会出现在各种地方，SlimModel在一定程度上违背了DRY（Don’t Repeat Yourself）的思路，Controller仍然不可避免在一定程度上出现代码膨胀。

MVVM
MVVM去年在业界讨论得非常多，无论国内还是国外都讨论得非常热烈，尤其是在ReactiveCocoa这个库成熟之后，ViewModel和View的信号机制在iOS下终于有了一个相对优雅的实现。MVVM本质上也是从MVC中派生出来的思想，MVVM着重想要解决的问题是尽可能地减少Controller的任务。不管MVVM也好，MVCS也好，他们的共识都是Controller会随着软件的成长，变很大很难维护很难测试。只不过两种架构思路的前提不同，MVCS是认为Controller做了一部分Model的事情，要把它拆出来变成Store，MVVM是认为Controller做了太多数据加工的事情，所以MVVM把数据加工的任务从Controller中解放了出来，使得Controller只需要专注于数据调配的工作，ViewModel则去负责数据加工并通过通知机制让View响应ViewModel的改变。
MVVM是基于胖Model的架构思路建立的，然后在胖Model中拆出两部分：Model和ViewModel。关于这个观点我要做一个额外解释：胖Model做的事情是先为Controller减负，然后由于Model变胖，再在此基础上拆出ViewModel，跟业界普遍认知的MVVM本质上是为Controller减负这个说法并不矛盾，因为胖Model做的事情也是为Controller减负。
另外，我前面说MVVM把数据加工的任务从Controller中解放出来，跟MVVM拆分的是胖Model也不矛盾。要做到解放Controller，首先你得有个胖Model，然后再把这个胖Model拆成Model和ViewModel。
那么MVVM究竟应该如何实现？
在iOS领域大部分MVVM架构都会使用ReactiveCocoa，但是使用ReactiveCocoa的iOS应用就是基于MVVM架构的吗？那当然不是，我觉得很多人都存在这个误区，我面试过的一些人提到了ReactiveCocoa也提到了MVVM，但他们对此的理解肤浅得让我忍俊不禁。
MVVM的关键是要有View Model！而不是ReactiveCocoa
安居客分三大业务：租房、二手房、新房。这三个业务对应移动开发团队有三个API开发团队，他们各自为政，这就造成了一个结果：三个API团队回馈给移动客户端的数据内容虽然一致，但是数据格式是不一致的，也就是相同value对应的key是不一致的。但展示地图的ViewController不可能写三个，所以肯定少不了要有一个API数据兼容的逻辑，这个逻辑我就放在reformer里面去做了，于是业务流程就变成了这样：

这么一来，原本复杂的MKAnnotation组装逻辑就从Controller里面拆分了出来，Controller可以直接拿着Reformer返回的数据进行展示。APIManager就属于Model，reformer就属于ViewModel。具体关于reformer的东西我会放在网络层架构来详细解释。Reformer此时扮演的ViewModel角色能够很好地给Controller减负，同时，维护成本也大大降低，经过reformer产出的永远都是MKAnnotation，Controller可以直接拿来使用。
Controller夹在View和ViewModel之间做的其中一个主要事情就是将View和ViewModel进行绑定。在逻辑上，Controller知道应当展示哪个View，Controller也知道应当使用哪个ViewModel，然而View和ViewModel它们之间是互相不知道的，所以Controller就负责控制他们的绑定关系，所以叫Controller/控制器就是这个原因。前面扯了那么多，其实归根结底就是一句话：在MVC的基础上，把C拆出一个ViewModel专门负责数据处理的事情，就是MVVM。然后，为了让View和ViewModel之间能够有比较松散的绑定关系，于是我们使用ReactiveCocoa，因为苹果本身并没有提供一个比较适合这种情况的绑定方法。iOS领域里KVO，Notification，block，delegate和target-action都可以用来做数据通信，从而来实现绑定，但都不如ReactiveCocoa提供的RACSignal来的优雅，如果不用ReactiveCocoa，绑定关系可能就做不到那么松散那么好，但并不影响它还是MVVM。

第四步：推演预测一下未来可能的走向，必要时添加新的模块，记录更多的基础数据以备未来之需
很多称职的架构师都会在这时候考虑架构未来的走向，以及考虑做完这一轮架构之后，接下来要做的事情。一个好的架构虽然是功在当代利在千秋的工程，但绝对不是一个一劳永逸的工程。软件是有生命的，你做出来的架构决定了这个软件它这一生是坎坷还是幸福。