#简介 　　

　　2016.09.26，Tik Tok 1 . 0 . 0版上线，随后产品迭代优化丰富。截至目前，Tik Tok的日活跃用户已经超过6亿，而在短短4年时间里，Tik Tok经历了从零开始的爆发式增长。 　　

　　业务的快速发展也对技术支持提出了更高的要求。为保证业务敏捷发展，提高跨团队协作效率，提高本地研发效率；d和CI/CD，Tik Tok iOS应用 　　

　　工程架构在不同阶段通过不同的技术解决方案进行了改进，以满足合理的架构演进，而不影响正常的业务迭代速度。 　　

　　# Tik Tok工程建筑演变 　　

　　建筑进化的本质是改善研发；d效率，提高代码稳定性，保证代码质量。架构要解决的问题是如何组织代码。 　　

　　合理的架构设计可以解决大型项目中跨团队协作、多业务线并行开发的效率问题。从一开始，Tik Tok工程代码就采用了组件化的思想，并且定制了依赖管理工具。 　　

　　椰子. 　　

　　以下动画介绍了Tik Tok工程建筑发展的四个阶段： 　　

　　图1:Tik Tok项目工程架构的演变 　　

　　#组件化 　　

　　在大型项目快速开发过程中，保证敏捷开发迭代的最大障碍是代码量快速膨胀带来的编译效率、依赖复杂化和业务线的代码冲突。 　　

　　移动项目可以与后端项目采用的微服务架构相比较。解决多业务线并行开发和并行测试的问题，应采用流水线迭代开发，提高发布、集成、交付、评审和发布的效率，在模型选择上可采用基于组件的方案，结合分治思想和技术。 　　

　　对于大多数小规模项目来说，组件化只能实现代码分段，Cocoapods用于管理组件依赖关系，就像Tik Tok项目最初的工程形式一样。 　　

　　但是对于几百人、几十条业务线的大型项目，需要设计合理的组件分层架构，明确组件之间的依赖关系，这就需要CI/CD。 　　

　　工具链支持组件的发布和集成需要本地研发；支持本地代码同步、工程配置、依赖管理和效率优化的工具。 　　

　　#流水线迭代开发 　　

　　流水线技术是指在程序执行过程中，多条指令重叠运行的准并行实现技术。该技术可以充分提高资源利用率，缩短产品研发周期。对于客户端项目，管道技术可以很大程度上满足敏捷开发迭代的节奏。 　　

　　图2: Tik Tok流水线迭代发布 　　

　　# Tik Tok工程建筑演变 　　

　　#第一阶段：项目Tik Tok原创建筑 　　

　　图3:Tik Tok项目原始工程框架图 　　

　　在Tik Tok项目的开始，Cocoapods是一个单一的架构，业务代码、项目配置和资源文件都在一个大型的业务仓库中。Podfile文件描述了第三方仓库的依赖版本。 　　

　　图4:Tik Tok项目原工程货架目录结构 　　

　　#第二阶段：壳分离后的工程框架(主机壳分离后) 　　

　　图5:拆壳工程后的工程框架 　　

　　分离shell项目后，将项目配置、部分系统资源和项目主入口分离到主主机shell项目中。 　　

　　Podfile分离出依赖于版本的管理文件 　　

　　Podfile.seer，依赖管理平台管理各个版本的容器化，业务仓库与主机集成发布版本，调平依赖，解决版本依赖解析耗时问题。 　　

　　大型业务仓库中的代码和资源被拆分成不同业务线的仓库，内部和外部的依赖关系由podspec文件描述。向业务仓库添加模块接口。 　　

　　存储外部接口的Subspec，利用依赖注入实现接口隔离，初步建立接口层。 　　

　　根据业务仓库之间的规定，只能依赖其他业务仓库的ModuleInterface子类别 　　

图6：抖音项目拆分壳工程后目录结构

# 壳工程

图7：壳工程抽象

为了满足一个工程同时支持多个项目、部分业务线功能复用、部分业务线中台化发展的需求，我们把所有业务线抽象成独立的 Pod，所有业务 Pod

必须通过宿主的壳工程进行集成发版。

壳工程包含了项目依赖的 Pod

信息描述，同时还包括工程的配置、部分系统级别的资源文件、工程主入口代码。基于多份宿主壳工程，一份代码可以打包出抖音、抖音极速版等项目。

同时，基于宿主壳工程，一些业务线可以通过自动化同步生成自己的子壳工程，实现业务线自己的 Example 工程，进行独立开发，比如有语音通话的 Example

工程，有工具的 Example 工程，有直播的 Example 工程等等。

图8：子壳工程配置同步同步

# 接口层

接口层顾名思义，只提供依赖的抽象接口，所有接口都是 protocol 协议声明。

接口层限制了所有其他依赖，类、枚举、 外部协议都采用前向声明，podspec 上只允许声明对 DI（依赖注入）框架的依赖。接口层满足封装、隔离和组合的原则。

* 业务层面对外封装了实现代码；

* 编译层面隔离了组件间依赖传递，减少头文件 import 嵌套提高编译缓存的命中率，对于 swift 业务组件，还能达到减少编译传递的问题；

* 架构层面声明抽象协议支持接口组合；

* DI 容器框架同时支持 stateless DI 容器，也支持 stateful DI 容器。

# 依赖打平

* 采用 Cocoapods 本身自带的版本依赖决议进行版本分析会消耗大量的时间；

* Podfile.lock 过于繁琐，可读性很差，难以解决 Podfile.lock 的冲突；

* 隐式依赖被动/不符合预期地升级，难以确定性地声明所有依赖，防止隐式依赖被升级；

* 依赖版本在 Podfile/Podfile.lock 重复声明，增加了解决冲突的成本；

* Podfile.lock 参与依赖版本决议流程比较复杂，会出现不符合预期的情况。

图9：把版本管理和仓库源信息迁移到 Podfile.seer 文件

* hook 掉 Cocoapods 采用 podfile.lock 进行版本决议的逻辑，采用 Podfile.seer 文件直接描述所有组件的版本信息，打平依赖。

# 阶段三：单仓多组件工程架构（Multicomponents in single repo）

图10：拆分单仓多组件后的工程架构

采用单仓多组件后，每个业务线仓库支持添加 podspec

增加组件，实现更小粒度的二进制依赖。业务线仓库内划分业务实现层、业务接口层、服务层和基础层，都是通过集成方式发版。

新增的服务层主要存放公共的业务逻辑和通用服务，限制

UI，一是满足业务逻辑复用，二是满足子壳工程最小化二进制依赖。同时服务层的服务接口也达到隔离依赖传递的目的，在不同的宿主上，支持通过改变服务层实现替换后台能力或者底层能力。建立分层间的依赖准入规则，完善

lint 编译链接检查。

图11：单仓多组件目录结构

# 编译链接完备性校验

* 编译校验：分开编译各个 subspec，确保每个 subspec 的依赖是正确的(由于 subspec 没有编译隔离)

* 接口符号校验：校验当前接口组件(ModuleInterface)中符号是否完备的，以保证其他组件单独引用是否能正常使用。如 extern 声明的全局变量。

# 分层依赖准入规则：

* 高层依赖低层

* 实现依赖接口

* 接口层无依赖

* 前向声明优先

* 服务层去"UI"

以下动画展示了业务实现层和服务实现允许依赖的分层：

图12：组件依赖关系示意图动画

# 阶段四：Example 子壳工程架构（Subshell for bizcomponent in example project）

图13:子壳工程架构

每个业务仓从宿主同步工程配置构建子壳工程。增加 AWELaunchKit

为子壳工程提供运行时的基础能力。通过服务层提供业务间运行时共享的服务能力，满足代码复用和更小二进制依赖。

图14：子壳工程目录结构

# AWELaunchKit

AWELaunchKit 框架为宿主和其他子壳工程提供了基础服务的依赖和初始化配置。同时提供了一套启动加载的 BootTasks

管理框架，部分业务涉及启动相关的逻辑可以在业务仓对应的服务层中实现，并通过 BootTasks 管理框架注册到启动加载器里面。

同时框架还提供了一套宿主 UI 入口和自定义入口框架。为了方便测试和调试，也整合了整套测试调试框架。

图15：子壳工程依赖关系

# 组件化探索过程中遇到的一些问题：

# 二进制污染

组件之间的依赖除了显式的依赖，还存在很多隐式依赖，代码层面，除了普通的接口依赖，还有宏依赖、枚举依赖、全局变量依赖以及内联函数等的依赖。单仓 lint

进行编译链接完备性检查并不能解决依赖变动对其他二进制的影响。

因此需要借助源码层面的依赖分析，判断当前组件的变更对其他依赖当前组件的二进制是否有影响，在 CI 流程中及时发现并拦截。否则错误的二进制发版，会直接导致整个

CI 研发流程和本地研发都受到影响。

# 编译优化

编译优化最高效的方式就是提高缓存的利用率。对于本地研发和 CI 流程，都涉及分布式编译缓存同步。同时通过编译参数优化、依赖优化、hmap

优化也能不同程度的提高编译效率

# 主干分支稳定性问题

对于多业务线并行开发，几百号人的业务开发团队，如果主干分支一旦出现问题，那么解决问题的时间就需要乘上几百倍。因此，需要从编译层面和运行层面都要有足够的机制去保证一个稳定的主干分支，才能保证业务侧的长期稳定性。

# 业务层的依赖耦合问题

大型项目动则千万行的代码，代码间的依赖关系是复杂的网状关系。需要基于代码的语法树模型，从语义中去分析不合理的依赖，并输出治理的方案。

我们内部自研了源码依赖关系分析平台用于依赖关系分析监控和代码治理，长期监控组件间的依赖度。同时，需要建立依赖健康度模型，从长期演进的角度去监控防止代码的劣化。

图16：spider 组件依赖分析平台

# 总结

大型项目的组件化工作是一个系统性工程。涉及工程架构的改造、CI/CD

研发工具链的支撑、本地研发工具链的支撑，业务架构的设计优化，需要从各个方面综合考虑成本和收益。

没有最好的架构，只有更好的架构，在架构演进的过程中，我们需要充分考虑架构的改动对业务的影响以及能给业务带来的收益。好的架构一定是能帮助业务节省时间，保证质量的。与此同时，我们在架构改进的过程中，要保证不能影响业务的正常迭代，所以向前兼容且避免大面积冲突也是很重要的事情。

组件化里面处处都有惊喜，比如一个小小的 hmap 优化，可以很大程度的减少编译耗时，比如一个二进制的压缩和解压的优化，可以很大程度减少 pod

install 的整体耗时。

当然这里面也会有很多很棘手的问题，需要通过一些特殊的方案解决，比如针对分布式开发，由于阻塞式发版必然会导致一些不同分支存在冲突的代码发版后影响主干的稳定性。

由于文章篇幅有限，只能点到即止地介绍当前一些工作成果和思考，各个 Topic 还有一些新的方向在探索，如果你对 iOS

底层原理、架构设计、构建系统、自动化测试有深入了解，快来加入我们吧！

# 加入我们

我们是负责抖音客户端基础能力研发和新技术探索的团队。我们在工程/业务架构，研发工具，编译系统等方向深耕，支撑业务快速迭代的同时，保证超大规模团队的研发效能和工程质量。在性能/稳定性等方面不断探索，努力为全球数亿用户提供最极致的基础体验。

如果你对技术充满热情，欢迎加入抖音基础技术团队，让我们共建亿级全球化 App。目前我们在深圳、上海、北京、杭州、均有招聘需求，内推可以联系邮箱：

tech@bytedance.com ，邮件标题： 姓名-工作年限-抖音-基础技术-iOS/Android 。或直接点击 拓展链接

查看部门所需岗位！

* * *

欢迎关注「 字节跳动技术团队 」

投递简历请联系邮箱： tech@bytedance.com