大型 SDK 组件化拆分的一些思考

笔者所在部门都一个很大的SDK，被公司众多部门所使用，笔者到来之前，这个SDK采取的是原始的开发方式，随着时间的迁移，已经变得非常大，大概一千多个OC文件，C++的没数过，功能也很丰富，但是对于某些部门，对包大小有非常严格的限制，某些不需要的功能需要减包，对于一个高度耦合在一起的SDK来说，几乎只能通过预编译宏来减少文件的引用，这样做造成一个git仓库上维护着多个分支，每次合并都是噩梦般地存在，而且由于功能模块很多，对于每一个功能模块都需要有一个预编译宏，这样带来一个问题，如果宏的组合发生错误，那么这个极有可能带来严重BUG。因为笔者面试的时候，和面试官除了常规技术问题，谈得最多的是架构设计，所以当笔者进入公司之后，总监以及组长都希望我能够解决掉现在的问题，至少说能够部分解决，特别是大ZT计划发布之后，这件事被真正意义上的开始实施。笔者这篇文章是一篇随笔，是希望为遇到同样的事情的开发者提供一些思路，由于保密的原因，有很多东西没有办法说清楚，忘见谅，勿喷。

需求

笔者的任务在初期是比较简单和明确的，要求对于某些模块能够可选集成，使用cocoaPod的时候，是否集成某个模块，不能改动一句代码，有点像友盟的社会组件集成方式，但是比那个应该要复杂一些，后面会细说原因。

看到这里，有经验的朋友第一个想到的就是组件化，组件化已经不是什么稀罕事儿了，业内有非常成熟的URL注册方案，Mediator方案以及Protocol注册方案。但是这些成熟的方案其实都是针对App的，App的组件化其实是比较简单的，因为App有可视化的逻辑帮助我们对整个App进行纵向切割和横向切割，工具与业务之间的界限非常明确，业务与业务模块之间的界限也非常明显，特别是在复合设计模式的帮助下，代码的可复用性变得很大。笔者认为，横向切割解决的是组件的依赖方向问题，纵向切割是解决组件间的黑盒问题，横向切割完成之后，位于上层的组件可以依赖下层，而下层不能反向依赖，纵向切割完成之后位于同一横向的组件不能够直接通讯，这是差不多有经验的开发者都能够想明白的事情。

问题

但是笔者所遇到的问题是：

1. 一个巨型SDK，在某种意义上本身就属于工具，其界线划分变得模糊。笔者在以前的公司集成过融云的SDK，融云的SDK分为两部分，UI和通讯功能部分，界线非常明显。但是笔者这边麻烦的是，没有UI，而且笔者部门的SDK涉及的是图像处理领域以及人工智能领域，连像App那样抽出基础工具类都变得异常麻烦。这个麻烦点来自于，这个基础工具类可能从逻辑角度都说不通它算是基础工具，笔者也是为了避免一个问题：基础工具类很有可能会变成垃圾堆。

2. 它没有办法使用现在成熟的复合设计模式，例如MVC，MVVM等。复合设计模式带来的最大的好处是我们能够在某种规范下划分代码。如第一个条件所说，我们的SDK没有UI，M肯定是有的，但是C也变得很模糊，例如笔者举个例子，渲染链读者们认为应该属于什么？人工智能那堆C++代码，桥接代码就更不用说了。

3. 渲染链中一帧数据在A模块的输出会影响的B模块该以何种方式处理这一帧的数据，而B模块对本帧数据不同处理方式又需要告知A模块下一帧数据该如何处理，这就让整个渲染链的通讯方向变成了双向的。在传统开发模式下，正向通讯采用属性传值或者调用方法的方式通讯，逆向通讯采用通知，代理，Block。因为笔者需要实现可选集成，所以代理和Block不能使用，通知是不可能用的，否则这么多模块的通讯，会让通知根本没法维护。

4. 再说那三种业内比较成熟的组件化方案。

   • URL注册方案，我见过某大型App用过，这东西很简单，通过参数和需要参数的对象（大多数情况下是ViewController）组建一个URL，然后传给Router去解析URL并完成组件的创建和传值。这方案非常适合组件非常独立的情况，但是对于复杂情况来说，应该有同学也会赞同，复杂通讯情况下，这种方案会变得很无力，而且创建URL方式进行通讯，特别是逆向通讯，非常无力。
   • Mediator方案，我没用过，但是我看过网上很多关于这套方案的一些框架封装或者Demo。这种方案核心就是Mediator的分类，由分类调起服务，但是这样的话，我们来思考一个问题，如果一个Mediator的分类对一个组件负责，而这个组件本身功能比较独特，那么这个分类写出来对外暴露的接口也会有一定的独特性，而该Mediator的分类对模块的通讯也会变得具有独特性，会造成Mediator的分类对模块的强依赖关系，这不像在App组件化中，通过类名创建类那么简单。就算解决了这个问题，但是如果不集成某个功能模块，这个Mediator的分类是否应该被移除？如果移除，会造成方法找不到，编译不过，如果不移除，那么就会存在一大堆Mediator，对于连几K包增量都要计较的团队，显然是他们不能接受的，这就不符合我们在计划之出，对于功能模块可选集成的要求。
   • Protocol注册方案是笔者认为最接近能够实现笔者要求的方案，但是问题来了，谁来遵循这个Protocol（后面还会细说）？但是无论哪种组件化方案，似乎我们都需要一个中介者，无论是Router还是Mediator。

方法

但是箭在弦上，不得不发，笔者具体做法如下。

1. 清理整个SDK，这一点是常规操作。依据经验，一个经历了几年迭代的任何代码工程，肯定有废弃代码，废弃文件以及无效依赖，由于我们的SDK影响非常大，所以笔者不得不采取人肉方式进行清理，这样清理后也放心，先找废弃文件，废弃文件会有一个特征，它的依赖链会断，也就是你顺着依赖往上找，会发现在某个时候断掉了或者直接根本就没人依赖它。无效依赖是指某个文件可能import了另外一个文件，但是却没有使用到这个文件的任何东西。清理会分几波，因为随着清理的进行，越来越多废弃的东西会暴露出来，这样是为以后做准备。申明一点，这和App不同的是，App由于是可视化的，哪个界面没用了，一目了然，随之的ViewController，View，Model都会被废弃到。

2. 横向切割，先确定引用方向，我根据我们的数据的流向从下至上分为

   • AI的C++库，Base库（这一层做架构把控的一定要严格控制好里面的文件，否则一定会变成垃圾堆。我们的base层只存放基类和线程模型）
   • 中介者库，AI封装库，渲染扩展库（主要是openGLES和metal之间的通讯）
   • 算法库（老大经常说，我们的核心科技啊！！！），能力库（也可以理解为业务层类似的东西）
   • 能力组装库

   注意，这里的数据的流向成为了我横向切割的重要依据，而不再使用App根据业务，UI，基础功能，基础工具这样的类似划分。

3. 纵向切割，这个没有什么太多说的，根据业务或者功能划分逻辑来，刚才分好的横向层虽然在纵向有了粗略的切割，但是不够，例如人工智能AI模块，我们有五六种人工智能能力，而C++库加上AI模型，是很大的，一个人工智能能力加起来可能就是几百兆了，所以还要分。但是这里早就有大神提到过，纵向粒度划分一定要合适，划分得太粗，相当于没怎么划分，划分得太细，给自己找麻烦，同时要结合收益是否和代价相匹配，除非非常明显的划分界限，一般不要分开。举个简单例子，可能不太准确，图形识别和文字识别界线非常明确，应该划分掉，前景贴纸贴花和前景贴纸贴草，这个界线就不那么明确，所以就不要划分。

4. 做到这里的时候，笔者其实还是没有一个非常完美的中介者方案，但是有一个保底方案。回到我刚才面临的问题中的第四点，“Protocol注册方案是笔者认为最接近能够实现笔者要求的方案，但是问题来了，谁来遵循这个Protocol（后面还会细说）”。这里有一个比较好的解决方案是对于一个组件来说，每个组件要有一个其统一封装类，这个统一封装类对整个模块负责，通过这个统一封装能调到这个模块的所有功能（当然有些功能不是直接调用，而是通过其他类转调一层），有这个统一封装类来遵循这个模块的特有协议。笔者在这个时候已经有了一个保底方案，就是把这个统一封装对外所有暴露的方法和属性写进这个Protocol中，然后把这个Protocol放入到Base层，模块间通讯通过类似于[idmanager XXXXX:XXX];这样的方式调用，这样就把强依赖变成了弱依赖，是可以实现可选集成的，但是随之而来的要求让这个方案彻底被否决。

这里是一个插曲，几个大部门老大联合发话（主要是针对我们部门，我们部门的SDK最大，影响最深），不仅要实现功能可选集成，还要实现可扩展，例如AI能力，我们现在有五六种，以后出现新的能力，能够通过某种规则非常简单增加一种AI能力，不能对现有代码进行改动。刚才哪种方案很明显不行了，因为我们需要在上层重新写调用Protocol的代码。

5. 不得不承认，我这里受到了阿里的BeeHive团队的启发并进行了深度改造，由于有新增能力不得对现有代码进行改动的要求，这就决定了，我的中介者不止有一个，是多个中介者。例如对AI能力有一个中介者，对所有AI能力负责，能力库有一个中介者，能力组装库也有一个中介者。这个中介者有一个作用，上层对下层调用的统一入口，数据传输给中介者，由中介者对该层的所有组件进行数据分发，组件数据处理结束之后，再由中介者统一收集，由上层自行拿去。第二个不同的地方是，BeeHive方法的核心是每个组件有一个Protocol，作为标识符性质的协议，我这里有了一个BaseProtocol规范该层所有组件，SpecialProtocol用以作为标识符性质的协议，为什么用协议，不用字符串，是为了扩展。在SDK启动之初，所有的组件向该层中介者进行注册，告知中介者，我们有这个能力（这里我们经过线程和算法的优化，不必担心性能问题）。于是调用逻辑变成了这样，当数据来临的时候，最上层的中介者拿到数据分发给所有组件（如果没有该组件，对nil对象发送消息，不会崩溃，这个大家都知道），所有组件根据自己需要的东西向下一层的中介者发送数据并等待结果，下一层的中介者再分发给本层的所有组件，到最底层处理结束后又由反方向返回数据，最终将在最上层中介者告诉App，由于有BaseProtocol的存在，所以每一层的中介者对于本层的所有组件都是弱依赖，又由于SpecialProtocol的存在，能够让中介者准确地分发给对应组件，这个BaseProtocol能够存在得益于我第二，三步横纵向切割的正确性，如果切割不对，这个BaseProtocol将无法存在。

补充说明

1. 关于数据传递这一块，我非常赞同Mediator作者关于数据传递需要去模型化传递的思想，如果一个自定义模型需要被传递（首先这里已经不存在URL关于非常规参数无法传递的问题），需要去模型化。还有其他几种情况，如果在开发过程中，如果一个数据被大量使用，是可以下沉到基础层之类的地方去，如果仅有少部分组件实用，我目前的想法是我宁可复制一个类出来。如果读者有更好的方案，欢迎讨论。同时需要注意一点的是，如果某种特殊情况需要实现例如A->B->C这样的传递，其中A和C需要使用到该数据，B只需要传递就行了的情况，那么只有A和C需要知道具体类型，B是可以使用多态的，这在某些情况下非常实用。

2. 关于同一层级组件如果需要进行通讯，在我的案例里面，通过中介者，拿到另一个组件相关数据（去模型化的）

3. 单一设计原理，不要出现类似于common这样的东西，这会成为耦合的重灾区

4. 浅继承，继承是面向对象语言的优势，但是也是劣势，会出现强耦合和超级类，cat大神在说Swift面向协议编程的时候说过这个问题

由于我们的SDK对公司内都不开源，所以我没有办法把事情讲得很清楚，更不可能贴代码，如果我们有开源的那一天，希望能和大家细细讨论，我最满意的是能力组装层的Center-Classify递归分发的设计。最后，没有最好的设计，只有最合适的设计。勿喷，谢谢