iOS App开发的那些事儿2：如何搭建合适的框架

《iOS App开发的那些事儿》系列文章从更宏观的角度出发，不只仅局限于具体某个功能、界面的实现，而是结合 网易云信iOS端研发负责人多年的经验，从如何优化现有代码的角度出发，深度分析如何创造出iOS App开发中比较合适的规范和框架。 

推荐阅读

iOS App开发的那些事儿1：如何创建合适的规范

一个合适的框架不是银弹，在我看来框架要解决的问题历来不是：有了框架以后，工程就能无比正确地进行下去。好的框架可以作到的事仅仅只是：下降通用问题的复杂度和减小发生错误的可能性。我的认为一个良好iOS App框架应该是有以下特色：

定义清晰的层次结构

• 横向上，各模块互相独立，仅经过有限的几个接口进行通信。最理想的状态是除核心模块外，其余模块都是可拔插。纵向上，各层次间依赖关系清晰，基本不出现逆向依赖的状况。
  
• 横向模块通常依赖于业务需求，常被定义成各类Service或Manager。一种好的作法是有个统一的Service管理器负责相应Serivce的加载，卸载，监听和分发App级别的通知给相应Service，如先后台切换，收到内存警告等。这样作一方面容易实现上面说的模块的可插拔化，另外一方面也保证了公用特性处理的一致性。在这方面微信就作得不错，基本全部的模块都是从MMService继承而来，由MMServiceCenter进行管理。固然从dump出来的头文件也能够发现一些管理上的紊乱，好比一些ViewController都是继承自MMService。
  
• 纵向的层次划分基本各个App不会有太大区别，通常能够分为三个层次：
  

展示层(Presentation layer)，负责管理UI和UIViewController。

逻辑层(Business/Service Layer)，负责逻辑数据的定义和转发，起到承上启下的做用。

数据访问层(Data Access Layer)，负责具体API构造，网络请求，数据持久化等。

各层根据业务逻辑的复杂性内部又会使用单层或者多层结构。以数据访问层为例，通常又能够细分为网络层，持久化层。而通常而言，展示层(UIView和UIViewController)都是直接使用逻辑层提供的Model进行展示，可是某些场景下每每须要不一样的Model有相同的界面展现(如咱们的App易信中，会话界面，收藏界面，问一问功能都须要进行图片的展示，但这三个模块下的Model定义并不一致)，这就须要增长额外的ViewModel层用于粘合展示层和逻辑Model。

遵照SOLID原则和慎用各类设计模式

这是个老生常谈的话题了，并非iOS开发独有，展开讲能够讲上几天几夜，不赘述。

定义本身的UI基类：UIView，UIViewController，UITableviewCell

这一点的好处不言而喻，全部的子View，Controller，Cell都可以很方便的继承基类的共有的行为，样式。但也会引进很大的管理风险：组内成员总会经不起诱惑往基类塞各类并不普适的特性，引发基类权责的无限膨胀。大基类不只增长组内成员对代码的理解难度，同时也增长出现问题时的排查难度。从这方面讲，微信的UIViewController基类设计就极端失败：MMUIViewController这个类光头文件就有上百行。

提供方便好用的工具类

一些好用的工具类每每会成为框架重要的有机组成部分，方便快捷地解决局部问题，同时又不引入过多的复杂度。NSTimer的retain cycle是个很容易掉去的坑，那么提供一个基于Block或者weak delegate的NSTimer的封装就是不错的选择。使用KVO容易发生add和remove的不配对调用，那么就引入THObserversAndBinders或者FB的KVOContorller。某些核心模块须要被多个模块依赖时，引入相似XMPP的GCDMulticastDelegate就可以方便地进行解耦。

好的范例

在前几年使用C++的那段暗无天日的日子里，我常想的一个问题是：如何在API层面去限制和规避一些错误。好比往线程池里面扔的task必须是堆上分配的对象，那么如何去强制传入的指针指向的是堆地址而不是栈地址呢？这种傻问题大部分状况下是无解的，有时候有解倒是个异常别扭的解。而如今我更相信破窗理论所提供的可能性：作好示范，接下来的一切都会水到渠成。

你们能够戳 iOS App开发的那些事儿1：如何创建合适的规范 回顾该系列第一篇文章，也欢迎你们积极发表本身的见解，与咱们共同讨论。