iOS 应用架构浅谈

当咱们讨论客户端应用架构的时候，咱们在讨论什么？

其实市面上大部分应用不外乎就是颠过来倒过去地作如下这些事情：

简单来讲就是调API，展现页面，而后跳转到别的地方再调API，再展现页面。

 App确实就是主要作这些事情，可是支撑这些事情的基础，就是作架构要考虑的事情。

• 调用网络API

• 页面展现

• 数据的本地持久化

• 动态部署方案

上面这四大点，稍微细说一下就是：

• 如何让业务开发工程师方便安全地调用网络API？而后尽量保证用户在各类网络环境下都能有良好的体验？

• 页面如何组织，才能尽量下降业务方代码的耦合度？尽量下降业务方开发界面的复杂度，提升他们的效率？

• 当数据有在本地存取的需求的时候，如何可以保证数据在本地的合理安排？如何尽量地减少性能消耗？

• iOS应用有审核周期，如何可以经过不发版本的方式展现新的内容给用户？如何修复紧急bug？

上面几点是针对App说的，下面还有一些是针对团队说的：

• 收集用户数据，给产品和运营提供参考

• 合理地组织各业务方开发的业务模块，以及相关基础模块

• daily build 自动打包，提供给产品体验，给测试观测性能

 因此当咱们讨论客户端应用架构的时候，咱们讨论的差很少就是这些问题。

架构设计的方法 

全部事情最难的时候都是开始作的时候，当你开始着手设计并实现某一层的架构乃至整个app的架构的时候，颇有可能会出现暂时的无从下手的状况。无论你采用什么方法，全局观、高度的代码审美能力、灵活使用各类设计模式必定都是贯穿其中的。 

第一步：搞清楚要解决哪些问题，并找到解决这些问题的充要条件

　　你必须得清楚你要作什么，业务方但愿要什么。而不是为了架构而架构，也不是为了体验新技术而改架构方案。之前是MVC，最近流行MVVM，若是过去的MVC是个好架构，没什么特别大的缺陷，就不要推倒而后搞成MVVM。

　　搞清楚对于业务方而言的真正充要条件很重要！这决定了你的架构是否足够易用。另外，传的参数越少，耦合度相对而言就越小，你替换模块或者升级模块所花的的代价就越小。

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

　　这个不用多说了吧。

第三步：搞清楚各问题之间的依赖关系，创建好模块交流规范并设计模块

 　　关键在于创建一套统一的交流规范。要注意的是，必定是创建一套统一的交流规范，不是两套，不是多套。你要坚持你的价值观，不要摇摆不定。要是搞出各类五花八门的规范出来，一方面有不切实际的炫技嫌疑，另外一方面也会带来后续维护的灾难。

第四步：推演预测一下将来可能的走向，必要时添加新的模块，记录更多的基础数据以备将来之需

　　不少称职的架构师都会在这时候考虑架构将来的走向，以及考虑作完这一轮架构以后，接下来要作的事情。一个好的架构虽然是功在当代利在千秋的工程，但绝对不是一个一劳永逸的工程。软件是有生命的，你作出来的架构决定了这个软件它这一辈子是坎坷仍是幸福。

第五步：先解决依赖关系中最基础的问题，实现基础模块，而后再用基础模块堆叠出整个架构

 　　这一步也是验证你以前的设计是否合理的一步，随着这一步的推动，你颇有可能会遇到须要对架构进行调整的状况。这个阶段必定要吹毛求疵高度负责地去开发，不要得过且过，发现架构有问题就及时调整。不然之后调整的成本就很是之大了。

第六步：打点，跑单元测试，跑性能测试，根据数据去优化对应的地方 

你得用这些数据去向你的leader邀功，你也得用这些数据去不断调整你的架构。

总而言之就是要遵循这些原则：自顶向下设计（1，2，3，4步），自底向上实现（5），先测量，后优化（6）。