对于单独的小型应用能处理好各部分的功能，处理好各部分分层的业务逻辑已经实属不易。因为模块与模块之间的耦合不易拆除，随着业务的增长，当初严格的划分已经越来越不能满足要求，模块开始变得异常膨胀，代码逻辑也异常的冗余。一个好的架构应该能解决这些棘手的问题，一个好的架构的机制一旦被确定，就不应该轻易更改。
小应用的架构之选
对于一个好的架构应该分工明确，各部分各司其职，低耦合，减少各部分相互依赖，能很容易的抽离各部分内容。
总体架构：谈什么MVC或者MVVM架构都太肤浅，总之，要有分层的概念
各司其职
- controller：负责业务逻辑处理，但随着业务量增长，代码量越来越膨胀，内容越来越冗余;
- view：负责视图的构建，随着controller代码量的增长，会渐渐把代码转移到view，有些view也会处理一定的业务逻辑;
- model分为几种：model(有业务逻辑的处理，数据的加工)，object(不带有业务逻辑的数据处理)，info（信息处理)，item（简单的数据model）；
- service：协调各部分的功能；处理各部分的网络功能：网络请求以及请求的结果；
- DataCenter：接收service的数据，在数据中心进行加工，一般处理公共的数据，对于单独模块的处理，直接在service处理即可；
- Manager：管理类，管理各部分功能；
- 公共类：config；
- protocol：协议；
其实以上架构分工明确，各层级间配合好，是不错的iOS架构：
- 整个的数据流向，就是从Service获取服务端的数据开始，在DataCenter进行处理，然后拿到view层进行展示；
- 整个的业务逻辑，是Service用来处理多个controller之间的关系，controller用来处理各部分的业务逻辑，负责协调每个view，manager辅助处理；
- 代码实现了分层：业务逻辑层（service或controller）、网络层（service）、数据层（DataCenter）、UI层（view）、模型层（model）、公共服务层。
目前架构遇到的问题
- 变瘦的controller和变胖的view,应该把代码均匀的分散在各处
- 多用继承，但是把公共部分在父类处理，各部分子类多态，继承层次太深，业务逻辑比较复杂，代码不好修改
- 机制和策略分离，对于公共部分的业务，不要频繁修改，修改变化的业务
- 好的架构两部分：数据流和业务逻辑
大型应用的架构
大型应用的架构，采用组件化的方式，基础SDK组件和业务组件分开，稳定的模块采用库的方式，改动频繁的模块采用工程的方式，每个模块拆分成单独project,支持模块按需编译。模块之间的通信方式，可能采用scheme（URL）方式进行，这样减少了模块之间的耦合性。
原则：组件的划分会越来越细。
model
对于model的处理，会有单独处理model的类统一对model进行修改
本地资源的加载
可以采用脚本的方式预先按需加载
采集性能数据
采集日志，上传至服务器，日志消息存入HDFS，Hive用于查询
- 网络请求成功率
- 启动时间、流量
- App版本、奔溃率等
优化细节
- 启动优化：优化启动速度
- 列表优化：监控性能，预加载，视图的合成的叠加，视图的布局优化，CPU与GPU特性
- 网络服务优化
- 离线包增量更新
- 图片性能优化：大图的预缓存机制、降低图片大小、wifi和移动网络下展示不同图片规格
扩展性
具有整体架构的思想，对未来扩展留有余地。
深度链接
链接每个APP，不再使APP变成孤岛。