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”模型是指:输入、处理、输出三者中,只要其中两者正确,剩余一者必定正确。该模型的指导意义在于指导我们如何做组件化拆解和组件设计。
- 我们在做组件化拆解时,需要定义清楚这个组件的 Input。
- 我们在做组件化拆解时,需要确保组件的代码是正确的,也就是说 Process 是正确的。
- 在确定 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 人左右,此时应以流程为维度拆分组件,组件数量大约在十几个到数十个不等。如果还保留之前小规模阶段的粒度或者拆得太细,工作效率就都不太理想。
在这样的业务规模和团队下,每次迭代时的状态是这样的:
我们能够看到,在中等规模和团队的情况下,工程的组件化拆解就已经引入分层的概念了。工程分层没有绝对的标准,合理就行。绝大多数工程分层就是三层:业务实现层、胶水层、工具 SDK 层。
大规模业务和团队
在大规模业务和团队下,工程师规模可能近百甚至几百,业务线越来越大。产品经理的数量也变得很多,需求越来越细。可能一个流程就是一个产品经理在提需求,一个业务线中有好几个产品经理去提需求是十分常见的情况。
那么,此时对应到我们的工程中,组件的拆解粒度也要更细,可能就要细到一个页面就是一个组件,一个工具就是一个组件。这样才能达到理想的工程效率。在这样的工程规模和组件粒度下,注册类的组件化方案可能就无法做到很好的支持。一方面注册会很消耗时间,另一方面,每拆一个组件就要对应要注册一个内容,提高了组件拆分的成本。
我们在进行架构设计的时候,要充分的考虑未来团队及工程的成长速度及成长规模,需要为工程设计一个合理的组件化方案。如果随着团队规模扩张,小问题再次变成大问题,没有真正的实现化整为零,则该组件化方案的价值就不大了。
在大规模业务和团队下,每次迭代时的状态是这样的:
通过这样的迭代状态,我们能够看到:
- 由于产品需求很细,当我们做到组件的颗粒度也很细时,每次迭代需求中的修改范围就能够做到很小,修改范围小了,需要考虑的连带关系就少了,工作效率就能得到提高。
- 在这种规模的业务和团队情况下,我们会发现,整个工程的分层概念已经没有意义了。我们转而需要关注的是组件的依赖关系是否合理,需要做好纵向依赖和横向依赖的区分和管理;需要做到某一个条线或者某一个功能,都能够在自己的工程里进行独立编译、测试。
- 虽然分层概念在整个工程的范围中已经失去了意义,但分层概念其实已经下沉到了某个条线或者某个功能中。我们把某个条线或者某个功能理解为一个“组件群”,在这个组件群中,是可以落实分层的概念的。
好的架构没有 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 时 / 编译时突然停止。
原因: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 业界日久不衰的话题之一。如何在工程演进的过程中,逐渐落地工程化、组件化,并复盘了在落地过程中的遇到的困难以及后续的方案迭代。除此之外,能够帮助我们在落地组件化之后,更好的面向构件开发。