抖音 iOS 工程架构演进(1)

图2：抖音流水线式迭代发版

抖音工程架构演进

========

阶段一：抖音原始工程架构（Original architecture of project）

---

图3：抖音项目原始工程架构图

抖音项目一开始是单体架构+Cocoapods，业务代码、工程配置、资源文件全部放在一个大业务仓库。由 Podfile 文件描述第三方仓库的依赖版本。

图4：抖音项目原始工程架目录结构

阶段二：分离壳工程后的工程架构（After splitting of host shell pod）

---

图5：拆分壳工程后的工程架构

分离壳工程后，工程配置、部分系统资源、工程主入口被拆分到主宿主壳工程。

Podfile 拆分出版本依赖管理文件 Podfile.seer，由依赖管理平台进行各个版本的容器化管理，业务仓跟随宿主集成发版，打平依赖，解决版本依赖决议耗时问题。

大业务仓中的代码和资源被拆分到各个业务线的仓库下，由 podspec 文件描述内外依赖。业务线仓库增加 ModuleInterface subspec，存放对外接口，采用依赖注入方式实现接口隔离，初步建立接口层。

业务仓库之间规定只能依赖其他业务仓库的 ModuleInterface subspec，通过 lint 进行编译检查。

部分基础能力代码被拆分成基础仓库，跟第三方仓库一样独立发版。本地研发工具支持单仓开发和多仓开发，不参与代码修改的仓库通过二进制的方式进行链接。同时 CI 流程上也支持通过二进制打测试包，提高打包效率。

图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：子壳工程依赖关系

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

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则近万的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Android）

学习福利

【Android 详细知识点思维脑图（技能树）】

其实Android开发的知识点就那么多，面试问来问去还是那么点东西。所以面试没有其他的诀窍，只看你对这些知识点准备的充分程度。so，出去面试时先看看自己复习到了哪个阶段就好。

虽然 Android 没有前几年火热了，已经过去了会四大组件就能找到高薪职位的时代了。这只能说明 Android 中级以下的岗位饱和了，现在高级工程师还是比较缺少的，很多高级职位给的薪资真的特别高（钱多也不一定能找到合适的），所以努力让自己成为高级工程师才是最重要的。

这里附上上述的面试题相关的几十套字节跳动，京东，小米，腾讯、头条、阿里、美团等公司19年的面试题。把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节。

由于篇幅有限，这里以图片的形式给大家展示一小部分。

网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！

跳动，京东，小米，腾讯、头条、阿里、美团等公司19年的面试题。把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节。

由于篇幅有限，这里以图片的形式给大家展示一小部分。

[外链图片转存中…(img-Adt1zwLH-1713622188540)]

网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！