PS:借鉴得物的架构师的经验

前瞻

Yami由于前期急速的开发导致整体架构野蛮生长，但是当项目稳定之后就想着优化整体架构
有架构师的团队：会对工程有规划，当遇到演进阶段的“分叉口”时，会有一个比较清晰的目标，决定接下来该往哪走。
我将工程演进分为了三个阶段：工程化、组件化以及容器化。

架构方向

首先，需要明确这三个步骤分别是什么，以及分别想要解决的问题：
工程化：
定义：为项目搭建一系列的基本组件以及封装实现类
解决的问题：快速解决业务需求问题。
组件化：
定义：将项目打碎并拆分成若干个组件组成的项目，以面向组件的方式进行开发。
解决的问题：解决工程业务复杂的问题。
容器化：
定义：利用拆分的组件，在快速满足业务需求的同时，尽量少地提升项目复杂度，同时以面向构件的方式进行开发。
解决的问题：解决组件复用性的问题以及项目动态性的问题。
需要注意的是，此处定义的“容器化”，是需要站在组件化的基础上实现的，与 Flutter、React Native、Weex、WebView 容器的概念有所区分。集成了上述容器技术的的应用，是具备容器能力的，但这并不代表工程是容器化的。

工程健康

工程健康是需要贯穿整个演进阶段的。
工程健康主要包含：包体积治理、Crash 治理、启动流程治理等三项。对于部分资源充裕的项目，可能还会关注电量损耗、图片加载时长、API 请求时长等。

包体积大小治理

Yami在2021接入Unity 并导入大量的Svga动画导致在21年4月份包体积迅速提升了100M。
包体积大小主要由资源大小与代码大小组成，所以治理的方向就是想办法减少这两块内容所占的大小。

图片

• 资源压缩：

• 第一阶段：尝试使用 ImageOptim 进行无损压缩，但是发现毫无收益，原因是因为 Xcode 已经帮我们进行了无损压缩。

• 第二阶段：使用了 PNGShrink 有损压缩，对于部分特殊图片，还可以选择更高的有损压缩。（获得了 30M+ 的收益）。

图片

• 重复资源合并：由于组件化的存在，每个组件可能会存在自己使用到的图片，导致大量相似、甚至重复图片存在。

• 第一阶段：使用脚本扫描出重复资源，然后手工对资源进行合并。

• 第二阶段：实现了脚本合并。在编译结束时，针对资源计算 MD5，然后确认相同 MD5 资源的数量，若存在多个，则移除相同的冗余资源。同时为了让大家都使用相同的资源，我们对 imageNamed: 等方法进行封装 / Hook，将传入的资源名字处理成 MD5，然后再进行资源的搜索。这样可以解决多组件使用相同资源的问题。

图片

• 资源下发：
  由于Yami有一套礼物体系以及称谓体系，所以需要大量的Svga资源，为了避免App体积过大以及资源可以动态配置就使用了动态下发资源
• 第一阶段：统一下发所有礼物资源以及称谓资源。若未下载好，则使用图片资源进行业务逻辑的降级兜底。
• 第二阶段：资源增量下发，只下载新版本新增资源。（对于资源下发平台，此块获得了大概 3 - 4 倍的提升）

代码的治理可以分为以下几个方向：

• 三方库裁剪：

针对只需要三方库一小部分功能的场景，我们对三方库进行定制化缩减，如移除不需要的功能；针对为解决同类需求，引入多个相似第三方库的场景，限定只用某一个，如 YYWebImage、SDWebImage 等同功能组件仅保留一个，其他业务需要进行迁移。同时，为了确认当前工程中用到的第三方库。

• 无用代码移除：
  使用了AppCode 进行无用引用的删除
  使用脚本搜索定义但是没有使用的方法并进行移除
  可能大家觉得这些影响的很小，但是Yami是一个成年累计的项目 而且有很多同学接手过，导致代码风格各种各样，截止2022年1月5日，最大的一个文件以及达到惊人的12000+行

• 重复代码合并

找由于复制粘贴产生的重复代码，然后抽出中间组件，各组件对中间组件进行依赖实现。

工程代码治理

图片

• 长依赖链组件：部分项目中会存在组件依赖链过长的情况，如 A -> B -> C -> D（此处 "->" 代表依赖状态）。这样会导致使用 A 组件的时候，必须同时引入 B、C、D 组件。我们认为长依赖组件的出现是不合理的，是没有合理区分纵向依赖与横向依赖导致的。针对这部分内容的处理，需要调整依赖方式。

• 纵向依赖：直接依赖代码，通过 Pod Dependency 进行依赖。

• 横向依赖：通过组件调度的方式进行间接依赖，无需直接依赖代码。

• 长编译耗时组件：当新组件仅需使用大组件的小功能时，直接依赖了大组件，会导致新组件开发时，开发、编译成本变大。针对这部分内容，需要将大组件再次进行拆分成若干小组件进行处理。

• 无用、重复代码：此块内容已在包体积大小治理中阐明，不再赘述。

Crash 治理

图片

• 纯人工阶段：使用 Bugly Crash 管理系统，手工确认 Crash 后分给具体的业务线，同时人工跟进问题修复情况。

图片

• 半自动化阶段：使用脚本爬 Bugly 信息（包括 Crash Stack 信息），然后自动识别业务线并自动落表。

图片

• 全自动化阶段：由于 Bugly 是每小时统计一次 Crash 数据，所以有可能出现数据滞后的问题。为此我们重新搭建了 Crash 平台，去做自动化收集、解析、告警的事情，同时实现自动跟进修复情况。

启动流程治理

图片

• 启动流程分组：将代码按业务线分块并标注，用以确定每条业务线所占的时长，随后可根据该指标治理部分业务线大幅增长的不合理情况。
• 代码插桩 diff：编译时，进行代码插桩。然后将新旧包代码插桩数据对比，当新增代码调用时，能够及时发现调用链的变化，用于确保调用链必要且合理。
• 安全模式：假设某个组件没有正常完成工作（如 DB 迁移、A / B Test 数据获取），可以进入安全模式，通过 Hook RunLoop 并尝试重启，以避免应用崩溃。

工程化

图片

Yami工程化主要围绕三项开展，分别是：围绕组件化的基础设施、包分发平台以及持续交付。

围绕组件化的基础设施

需要注意的是，工程化的基础设施，需要随着组件化、容器化阶段不停调整。并不是意味进入组件化后，工程化就不用继续，而是进入组件化后，工作重点主要放在组件化，但仍需投入精力调整优化相关的基础设施。

结合Yami场景，主要围绕组件化实现了以下命令行工具，用以提供业务同学的开发效率：

图片

• 组件创建脚本、组件工具：解决创建、管理组件的问题。
• 组件发版工具：解决组件发版的问题。
• 二进制调试工具：解决二进制组件调试问题。
• 组件上游依赖查询工具：解决组件依赖查询问题。
• 编译成功节点切换工具：解决“出包难”的问题。
• 裙带源码组件切换工具：解决 ARC 不对齐的问题。

后文会结合具体场景说明工具作用。

组件管理（包含组件创建、发版等组件工具）

区别于其他公司，Yami没有使用在 Podfile 中定义版本号的方式。主要因为Yami工程中组件较多（组件数量超 1430+），平均每隔 4.8 分钟发版一次（日均发版 100+）。如果使用 Podfile，会意味着每当组件发版，Podfile 都需要修改版本号，继而会产生大量的 Podfile 文件冲突。同时，Yami也经常存在多组件联合发版的问题，这样依赖上游需要同时调整多个组件版本号，存在较大的沟通成本。

图片

基于上述考虑，Yami目前主要使用索引做组件管理，且固定以下命名规范（下列假设版本号为 X.Y.Z）：

• 开发环境：使用 dev 索引库，规定组件发布新版本时，仅变更版本号的第一位，就像 A，从 1.0.0 变为 2.0.0。
• 沙盒环境：使用 test 索引库，规定组件发布新版本时，仅变更版本号的第二位，就像 B，从 1.0.0 变为 1.1.0。
• 灰度环境：使用 gray 索引库，规定组件发布新版本时，仅变更版本号的第三位，就像 C，从 1.0.0变为 1.0.1。
• 现网环境：使用 release 索引库，规定组件不能发布新版本。

不同环境使用不同的 Git 仓库，且 Podfile 中固定了每个组件当前环境的仓库地址（所以切换环境时，需要调整 Podfile 中的 Source，并处理不同环境 git upstream 的合并）。仓库环境的拆分，避免了新版本开发影响到已有版本逻辑。

二进制（包含二进制调试工具、组件上游依赖查询工具、裙带源码组件切换工具）

图片

• 单工程独立编译制作：

• 优点：组件发版时完成二进制制作；可靠性高。

• 缺点：组件制作二进制时长取决于组件规模，大组件制作仍旧耗时；存在大量组件需要做二进制，单光算编译时长，需要 5 天制作；出现测试包体积变大。

• 全工程编译产物制作：利用编译缓存，从 Xcode 编译缓存 DerivedData 中取出组件。

• 优点：每 50min 完成 1400+ 二进制制作。

• 缺点：只能分批制作（1h / 次）；存在 ARC 不对齐的情况。

• ARC 不对齐：A 组件已经是二进制（在编译时加入 ARC），B 组件使用源码编译，此时再次编译（编译器会为 B 会添加 ARC，但不会对 A 组件进行处理，有可能导致 ARC 不对齐引发内存被提前释放，导致 EXC_BAD_ACCESS Crash）。为了解决该问题，在做二进制时，需要对新发版的组件做裙带组件源码切换：将其上游一级、下游一级的组件变成源码依赖而非二进制依赖。

• 基于 Oolong 的增量制作，Oolong 是Yami开发的脚本（即上文中提到的裙带组件源码切换工具），能够将一个组件的上一级和下一级依赖的组件变为源码参与编译：

• 优点：彻底解决 ARC 不对齐；每 20 min 可以完成 1400+ 二进制制作。

• 缺点：只能分批制作（20 min / 次）。

最终，Yami完成基于 Oolong 的增量制作。需要说明的是，Yami不追求所有工程都是二进制，原因是开发工作一般以小时计，20min 的二进制编译时长已经能相对满足需求。

持续交付（包含编译成功节点切换工具）

图片

• Xcode Server 定时打包：CI 机定时打包。

• 优点：能够避免编译错误长时间不被解决的问题。

• 缺点：不保证编译成功，且每轮编译时长较长，相隔 1h 才能获得编译结果；但 CI 机编译成功不代表开发端编译一定能成功，对新人不友善。

• 记录编译成功节点并提供脚本（“Boom”）用以切换：执行脚本后，将代码切换至当前分支最后一次编译成功节点。

• 优点：能够避免编译错误长时间不被解决的问题；能够最大限度保证开发端代码编译成功。

• 缺点：编译成功节点落后近 1h；由于开发的组件一定是源码，若使用二进制编译，会造成 ARC 不对齐引起的各种偶发问题。

图片

• 多机车轮打包：使用大量机器持续构建不同环境的包（如上图示）。

• 优点：能够及时发现编译错误，每轮 10 min；能够最大限度保证开发端代码编译成功。

• 缺点：需要较多机器资源。

图片

除此之外，我们还利用了“飞书卡片”功能，定期输出构建信息。

• 若出现构建失败，则自动提醒引发失败的工程师（一次构建可能包含多个不同的工程师，此时提醒该组工程师）进行处理。
• 若工程师开始排查，可点击“我来处理”，“飞书卡片”状态会发生变化，变为“修复中”状态。
• 若修复完成，会展示“飞书卡片”会展示“已修复”状态。

组件化

IPO 模型

图片

在开始组件化相关的内容前，我们首先要明确，组件化想要达到的效果是：化整为零，各自独立；确保每一部分是正确的，整体就是正确的。解决代码复用并不是组件化要解决的主要问题，组件化要解决的问题是将复杂的大工程拆分成很多简单的小工程，且小工程之间能够互相协作；工程使用了 Cocoapods 也不意味着已完成组件化。组件化的是指代码可以独立编译，可以独立测试。

图片

在讲组件化之前，需要强调一个概念：“IPO”模型。

“IPO”模型是指：输入、处理、输出三者中，只要其中两者正确，剩余一者必定正确。该模型的指导意义在于指导我们如何做组件化拆解和组件设计。

1. 我们在做组件化拆解时，需要定义清楚这个组件的 Input。
2. 我们在做组件化拆解时，需要确保组件的代码是正确的，也就是说 Process 是正确的。
3. 在确定 Input 已经定义清楚，且 Process 是正确的情况下，我们可以不必关心 Output，因为根据 “IPO”模型，只要 Input 和 Process 是正确的，Output 就一定是正确的。

“IPO”模型指导了我们做组件拆分的重点：将 Input 定义清楚，且确保 Process 代码正确。

在 CTMediator 方案体系下，OC Category / Swift Extension 的目的就是要保证 Input 是定义清楚的；剩余只需保证组件能够正确执行，即 Process 是正确的。那么 Output 就一定正确。如此一来，一个组件就是完整正确的。一个工程中只要每个组件都是完整正确的，那么这个工程就是完整正确的。

为什么不使用基于注册的组件化方案

图片

目前组件化方案主要分为两大类：

• 使用注册：又可分为 URL 注册 / Protocol 注册。
• 不使用注册：基于 Target-Action 及 Runtime：类 CTMediator 方案。

目前注册类方案存在管理注册时序、大量注册实例造成无用内存消耗、大量注册代码造成的时间损耗等问题，对于这些问题，我们可以使用各种“补丁逻辑”（例如直接将注册 URL 注入 mach_O 文件等）来解决。但若使用类 CTMediator 方案，则无需考虑类似问题，也就不需要去做“补丁逻辑”。

组件拆分粒度

业界针对组件拆分粒度有不同的认知，因此也就会存在不同的讨论。这些讨论如果脱离了当前的业务阶和团队发展阶段，是没有意义的。在不同的阶段下，组件拆分粒度是不一样的。

小规模业务和团队

小规模业务和团队（5人以内）：此时应以业务线为维度拆分组件，拆分出几个组件即可，大多数情况下是 3 - 5 个。如果此时不做组件化、或拆分过多组件，工作效率都会降低。

图片

在这样的业务规模和团队下，每次迭代时的迭代状态是这样的：

图片

图片

图片

黄色的圆圈表示参与迭代并修改的组件。我们能够看到这三次迭代中，大家只需要关心各自业务的组件，迭代无关的组件可以不必修改。在这种情况下，组件化为工程带来了降低迭代复杂度的优势。

中等规模业务和团队

中等规模业务和团队一般在 10 - 20 人左右，此时应以流程为维度拆分组件，组件数量大约在十几个到数十个不等。如果还保留之前小规模阶段的粒度或者拆得太细，工作效率就都不太理想。

image.gif

在这样的业务规模和团队下，每次迭代时的状态是这样的：

图片

图片

图片

我们能够看到，在中等规模和团队的情况下，工程的组件化拆解就已经引入分层的概念了。工程分层没有绝对的标准，合理就行。绝大多数工程分层就是三层：业务实现层、胶水层、工具 SDK 层。

大规模业务和团队

在大规模业务和团队下，工程师规模可能近百甚至几百，业务线越来越大。产品经理的数量也变得很多，需求越来越细。可能一个流程就是一个产品经理在提需求，一个业务线中有好几个产品经理去提需求是十分常见的情况。

那么，此时对应到我们的工程中，组件的拆解粒度也要更细，可能就要细到一个页面就是一个组件，一个工具就是一个组件。这样才能达到理想的工程效率。在这样的工程规模和组件粒度下，注册类的组件化方案可能就无法做到很好的支持。一方面注册会很消耗时间，另一方面，每拆一个组件就要对应要注册一个内容，提高了组件拆分的成本。

我们在进行架构设计的时候，要充分的考虑未来团队及工程的成长速度及成长规模，需要为工程设计一个合理的组件化方案。如果随着团队规模扩张，小问题再次变成大问题，没有真正的实现化整为零，则该组件化方案的价值就不大了。

图片

在大规模业务和团队下，每次迭代时的状态是这样的：

图片

图片

图片

通过这样的迭代状态，我们能够看到：

1. 由于产品需求很细，当我们做到组件的颗粒度也很细时，每次迭代需求中的修改范围就能够做到很小，修改范围小了，需要考虑的连带关系就少了，工作效率就能得到提高。
2. 在这种规模的业务和团队情况下，我们会发现，整个工程的分层概念已经没有意义了。我们转而需要关注的是组件的依赖关系是否合理，需要做好纵向依赖和横向依赖的区分和管理；需要做到某一个条线或者某一个功能，都能够在自己的工程里进行独立编译、测试。
3. 虽然分层概念在整个工程的范围中已经失去了意义，但分层概念其实已经下沉到了某个条线或者某个功能中。我们把某个条线或者某个功能理解为一个“组件群”，在这个组件群中，是可以落实分层的概念的。

好的架构没有 Common 没有 Core，也不应该有大组件的存在

为什么不允许存在公共模块

有 Common / Core 时，意味着有那么一部分代码，其职责是不明确的。不明确职责的代码会造成代码未来难以维护，因此不是一个好的架构。

另外每人对 Common / Core 的认知不同，很可能会使得 Common / Core 变成一个公共垃圾堆，出现 “既然放哪里都不合适，那我就放 Common / Core 吧” 的情况。该垃圾堆持续增长，成为一座垃圾山，导致 Common / Core 未来无法维护。

为什么不允许存在大组件

原因是大部分功能的开发，其实仅需要大组件的其中一个功能，但为了实现该功能，却需要引入一个大组件。这种情况不仅导致代码维护复杂，还会导致这个小组件编译时长不合理地增多。此时更合理的做法应该是将大组件打散成若干个小组件，其他组件需要啥，就只依赖它需要的那部分。我们认为一个大组件应该是由若干个小组件组成，而不是一个大组件由很多功能的代码拼成。

Argument List Too Long

Argument List Too Long 指的是 Xcode 代码编译基本完成后，在执行工程 Build Phases 中的 Run Script 时 / 编译时突然停止。

image.gif

原因：Cocoapods 为 Pod 生成编译参数后，会写入到环境变量。此时若使用 Pod 构造的组件达到一定量级，会导致写入环境变量过多，继而导致环境变量总长度超过操作系统限制（即 26w 个字符），最终导致命令停止。

图片

解决方案：环境变量中主要包含三个长度较长的内容，即 Header Search Path、Library Search Path 及 ModuleMap Path，所以关键是对这些信息进行合并。

• 合并 Header Search Path、Library Search Path 到一个文件夹：建立专用文件目录，将相关数据迁移至该专用目录，然后在 Xcode 中设定该目录。
• 合并 ModuleMap 到一个文件：需要注意的是，Xcode 要求我们提供 ModuleMap 文件路径（而非文件夹路径），所以这里关键在于如何合并 ModuleMap 文件。由于 ModuleMap 编译时才产生，所以Yami在编译 Pre Action 时，将其他 ModuleMap 内容合并至当前 DerivedData 路径下的 ModuleMap，同时设定 Xcode 读取的 ModuleMap 文件路径。

容器化

随着工程的成长和业务复杂度的提升，我们一路从工程化、组件化走来，最后走向容器化。在这个过程中，容器化在一定程度上引入了动态性，但动态性并不是工程的容器化阶段真正要解决的问题。

容器化真正解决的问题是改变工程的开发模式：容器化将工程师从业务、页面的开发，转而变成页面上某个小卡片小功能的开发，再由容器根据规则，将这些小卡片组装成为页面。

从组件化走向容器化是一个自然而然的过程，容器化并不是凭空出现的，容器化是基于上一个阶段组件化的组件积累，逐步整合出来的。这意味着很多我们在组件化阶段已积累的组件，是可以在容器化过程中直接使用的。

视图渲染

针对容器化处理，Yami会下发一个协议，然后容器会对该协议进行解析，随后递交至渲染器进行渲染，渲染过程中，其会通过 CTMediator 获取视图组件。该步骤中，容器实际上就是一个利用现有组件的手段，力求达到 “活字印刷” 的效果。

事件通信

除了视图组件外，还存在事件需要进行通信。组件往容器传递事件，如果此时容器没有处理事件，则事件通过 CTMediator 继续进行分发。需要注意的是，事件可以由其他组件处理，也可以由容器自身直接处理（但如埋点等事件，更适合放在容器进行处理）。

除此之外，我们认为以命令模式来描述一个事件更为合理。因为在该模式下，我们告诉了开发者实现事件所有的充要条件。由于命令模式与 CTMediator 的 Target-Action 设计是一样的体系，因此容器化使用 CTMediator 进行实现则显得十分自然。

最终Yami落地后的容器化可以支持上述功能，基本与 React 类似，但使用的是原生组件构造的容器，相比而言，省去了通信时耗，理论性能更优。

此处再次重申，使用 WebView、Flutter、React、Weex 等容器技术搭建的工程，是具备了容器能力的工程。但在我个人看来，这并不意味着这个工程进入了容器化阶段。容器化阶段毕竟还是要从组件化逐步成长而来，利用组件化已有的体系和组件，针对已有的页面进行容器化的升级。

总结

工程化、组件化一直是 iOS 业界日久不衰的话题之一。如何在工程演进的过程中，逐渐落地工程化、组件化，并复盘了在落地过程中的遇到的困难以及后续的方案迭代。除此之外，能够帮助我们在落地组件化之后，更好的面向构件开发。