业界 iOS 组件化与工程化

2016.09.26，抖音版本 1.0.0 上线，随后不断迭代优化和丰富产品，截止目前，抖音日活跃用户突破 6 亿，短短 4 年间，抖音从零爆发性增长。 快速的业务发展也对技术支撑提出了更高的要求，为了保障敏捷的业务开发，提升跨团队的协同合作效率，提高本地研发和 CI/CD 效率，抖音 iOS App 工程架构在不同的阶段进行了不同的技术方案的改进，满足合理的架构演化，同时又不影响正常的业务迭代速度。 架构演进的本质是为了提高研发效率，提高代码稳定性和保证代码质量。架构要解决的问题是如何组织代码。 合理的架构设计可以解决大型项目跨团队协作分工和多业务线并行开发的效率问题。抖音工程代码从一开始就采用了组件化思路，依赖管理工具是定制版的 Cocoapods。 以下动画介绍了抖音工程架构经历的四个阶段的演进过程： 在大型项目快速发展的过程中，要保证敏捷开发迭代的最大障碍就是快速膨胀的代码体积导致的编译效率问题，依赖关系复杂化问题，以及业务线代码冲突问题。 移动端项目可以类比后端项目中采用的微服务架构，要解决多业务线并行开发、并行测试问题，采用流水线式迭代开发，提高发版、集成、交付、提审、发布效率，结合分治思想技术选型上可以采用组件化的方案。 大部分小型项目，组件化仅仅做到代码分仓，使用 Cocoapods 的来管理组件依赖，就像抖音项目最初的工程形态。 但是对于几百号人、几十个业务线规模的大型项目，需要设计一套合理的组件分层架构，理清组件间依赖关系，需要 CI/CD 工具链支撑组件发版与集成，需要本地研发工具支撑本地代码同步、工程配置、依赖管理和效率优化。 流水线（pipeline）技术是指在程序执行时多条指令重叠进行操作的一种准并行实现技术，该技术可以充分提高资源的利用率，同时缩短产品的研发周期。对于客户端项目，流水线技术能很大程度满足敏捷开发迭代的节奏。 抖音项目一开始是单体架构+Cocoapods，业务代码、工程配置、资源文件全部放在一个大业务仓库。由 Podfile 文件描述第三方仓库的依赖版本。 图5：拆分壳工程后的工程架构 Podfile 拆分出版本依赖管理文件 Podfile.seer，由依赖管理平台进行各个版本的容器化管理，业务仓跟随宿主集成发版，打平依赖，解决版本依赖决议耗时问题。 大业务仓中的代码和资源被拆分到各个业务线的仓库下，由 podspec 文件描述内外依赖。业务线仓库增加 ModuleInterface subspec，存放对外接口，采用依赖注入方式实现接口隔离，初步建立接口层。 业务仓库之间规定只能依赖其他业务仓库的 ModuleInterface subspec，通过 lint 进行编译检查。 部分基础能力代码被拆分成基础仓库，跟第三方仓库一样独立发版。本地研发工具支持单仓开发和多仓开发，不参与代码修改的仓库通过二进制的方式进行链接。同时 CI 流程上也支持通过二进制打测试包，提高打包效率。 为了满足一个工程同时支持多个项目、部分业务线功能复用、部分业务线中台化发展的需求，我们把所有业务线抽象成独立的 Pod，所有业务 Pod 必须通过宿主的壳工程进行集成发版。 壳工程包含了项目依赖的 Pod 信息描述，同时还包括工程的配置、部分系统级别的资源文件、工程主入口代码。基于多份宿主壳工程，一份代码可以打包出抖音、抖音极速版等项目。 同时，基于宿主壳工程，一些业务线可以通过自动化同步生成自己的子壳工程，实现业务线自己的 Example 工程，进行独立开发，比如有语音通话的 Example 工程，有工具的 Example 工程，有直播的 Example 工程等等。 接口层顾名思义，只提供依赖的抽象接口，所有接口都是 protocol 协议声明。 接口层限制了所有其他依赖，类、枚举、 外部协议都采用前向声明，podspec 上只允许声明对 DI（依赖注入）框架的依赖。接口层满足封装、隔离和组合的原则。 业务层面对外封装了实现代码； 编译层面隔离了组件间依赖传递，减少头文件 import 嵌套提高编译缓存的命中率，对于 swift 业务组件，还能达到减少编译传递的问题； 架构层面声明抽象协议支持接口组合； DI 容器框架同时支持 stateless DI 容器，也支持 stateful DI 容器。 采用 Cocoapods 本身自带的版本依赖决议进行版本分析会消耗大量的时间； Podfile.lock 过于繁琐，可读性很差，难以解决 Podfile.lock 的冲突； 隐式依赖被动/不符合预期地升级，难以确定性地声明所有依赖，防止隐式依赖被升级； 依赖版本在 Podfile/Podfile.lock ...