iOS 架构的简单理解

曾经在面试的时候碰到过一个问题：谈谈对iOS应用架构的理解，你是如何设计应用的框架的？对于这个问题以前都没做相应的总结，回答问题的时候聊聊几句话总结作为了自己的答案。虽然没影响当时的面试结果，但总觉得当时的回答直到现在都感觉不满意。时隔这么久，现在抽空对这个问题做下整理：

（本人目前是做iOS开发的，只针对iOS框架谈谈自己的看法）

很多人都会问，iOS APP还需要考虑架构的问题吗？答案是必须得要的。iOS应用架构看似简单，但实际上还是需要考虑很多问题的。APP最重要也是最基本的就是两个操作：网络请求、页面展示。这么来说我们开发的APP至少要把这两个层面考虑到，那还需要就是数据的持久化和动态界面展示等等。每个人对架构的设计都有自己的见解和风格，不管怎么风格怎么设计都得考虑到到的是全局性、代码审美、确定使用一种设计模式

 

设计框架首先要搞清楚需要解决的哪些问题，不是为了架构而架构，也不是为了体验新技术而改架构方案。一直以来构建iOS APP的标准模式是MVC，这也是苹果推荐开发者使用的一种开发模式；最近微软退出了一个新的设计模式MVVM，也是很受到大多数开发者喜爱的。选择哪种开发模式也是得根据情况来定的，新的东西虽好但不一定适用而且MVC确实还不不错的架构。其次，推演预测一下未来可能的走向，必要时添加新的模块，记录更多的基础数据以备未来之需。软件是有生命的，你做出来的架构决定了这个软件它这一生是坎坷还是幸福。最后，打点，跑单元测试，跑性能测试，根据数据去不断的优化对应的地方。
     然而什么样的架构才算是一个好架构呢？
代码整齐，分类明确。代码整齐是对每一个工程师的基本要求。因为你的代码是要给别人看的，你自己也要看。代码不整齐、可读性差在应用的不断迭代的时候连自己的看不都了，是非常影响开发效率也是容易在修改的时候导致更多的问题。另外，如果代码不整齐分类不明确，整个架构随着一次一次的拓展而越来越混乱。至于分类明确是不要让一个类或者一个模块做两种不同的事情。如果有类或某模块做了两种不同的事情，一方面不适合未来拓展，另一方面也会造成分类困难。
 
思路和方法要统一，尽量不要多元。做架构的时候，得先考虑清楚要处理这样类型的问题的方案是什么、初衷是什么。另外，一开始设立这个模块一定是有想法有原因的，记录下解决思路。一旦确定了方案就不要在其他地方引入另外一个新的方案。
 
没有横向依赖，万不得已不出现跨层访问。没有横向依赖是很重要的，这决定了你将来要对这个架构做修补所需要的成本有多大。要做到没有横向依赖，这是很考验架构师的模块分类能力和是否熟悉业务的。
 
对业务方该限制的地方有限制，该灵活的地方要给业务方创造灵活实现的条件。区分哪些情况需要限制灵活性，哪些情况需要创造灵活性。比如对于Core Data技术栈来说，ManagedObject理论上是可以出现在任何地方的，那就意味着任何地方都可以修改ManagedObject，这就导致ManagedObjectContext在同步修改的时候把各种不同来源的修改同步进去。这时候就需要限制灵活性，只对外公开一个修改接口，不暴露任何ManagedObject在外面。
 
易测试易拓展。要实现易测试易拓展，那就要提高模块化程度，尽可能减少依赖关系。另外，如果是高度模块化的架构，拓展起来将会是一件非常容易的事情。
 
保持一定量的超前性。准确把握技术走向，保持适度的技术上的超前性，能够使得你的架构更新变得相对轻松。另外，这里的超前性也不光是技术上的，还有产品上的。接口少，接口参数少。越少的接口越少的参数，就能越降低业务方的使用成本。当然，充要条件还是要满足的，如何在满足充要条件的情况下尽可能地减少接口和参数数量。
 
最后一点是高性能，性能提高了对用户的体验就能更高层次的提升了。

以上是通过学习别人的经验与自己的见解对iOS APP架构的总结，如有不同的见解或者说的不对之处还望指正，毕竟我不是一名架构师。