(无人直播卖货素材)抖音无人直播协议软件技术开发

媒介介绍

2016.09.26，抖音版本 1.0.0 上线，随后不竭迭代优化和丰硕产物，截行目前，抖音日活泼用户打破 6 亿，短短 4 年间，抖音从零发作性增长。

快速的营业开展也对手艺支持提出抖音无人曲播协议软件手艺开发了更高的要求，为了保障敏捷的营业开发，提拔跨团队的协同合做效率，进步当地研发和 CI/CD 效率，抖音 iOS App 工程架构在差别的阶段停止了差别的手艺计划的改良，满足合理的架构演化，同时又不影响一般的营业迭代速度。

抖音工程架构演进

架构演进的素质是为了进步研发效率，进步代码不变性和包管代码量量。架构要处理的问题是若何组织代码。

合理的架构设想能够处理大型项目跨团队协做分工和多营业线并行开发的效率问题。抖音工程代码从一起头就接纳了组件化思绪，依赖办理东西是定造版的 Cocoapods。

以下动画介绍了抖音工程架构履历的四个阶段的演进过程：

图1：抖音项目工程架构演进

组件化

在大型项目快速开展的过程中，要包管敏捷开发迭代的更大障碍就是快速膨胀的代码体积招致的编译效率问题，依赖关系复杂化问题，以及营业线代码抵触问题。

挪动端项目能够类比后端项目中接纳的微办事架构，要处理多营业线并行开发、并行测试问题，接纳流水线式迭代开发，进步发版、集成、交付、提审、发布效率，连系分治思惟手艺选型上能够接纳组件化的计划。

大部门小型项目，组件化仅仅做到代码分仓，利用 Cocoapods 的来办理组件依赖，就像抖音项目最后的工程形态。

但是关于几百号人、几十个营业线规模的大型项目，需要设想一套合理的组件分层架构，理清组件间依赖关系，需要 CI/CD 东西链支持组件发版与集成，需要当地研发东西支持当地代码同步、工程设置装备摆设、依赖办理和效率优化。

流水线式迭代开发

流水线（pipeline）手艺是指在法式施行时多条指令堆叠停止操做的一种准并行实现手艺，该手艺能够充实进步资本的操纵率，同时缩短产物的研发周期。关于客户端项目，流水线手艺能很大水平满足敏捷开发迭代的节拍。

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

组件化摸索过程中碰到的一些问题：二进造污染

组件之间的依赖除了显式的依赖，还存在良多隐式依赖，代码层面，除了通俗的接口依赖，还有宏依赖、列举依赖、全局变量依赖以及内联函数等的依赖。单仓 lint 停止编译链接完整性查抄其实不能处理依赖变更对其他二进造的影响。

因而需要借助源码层面的依赖阐发，判断当前组件的变动对其他依赖当前组件的二进造能否有影响，在 CI 流程中及时发现并拦截。不然错误的二进造发版，会间接招致整个 CI 研发流程和当地研发都遭到影响。

编译优化

编译优化更高效的体例就是进步缓存的操纵率。关于当地研发和 CI 流程，都涉及散布式编译缓存同步。同时通过编译参数优化、依赖优化、hmap 优化也能差别水平的进步编译效率

主干分收不变性问题

关于多营业线并行开发，几百号人的营业开发团队，若是主干分收一旦呈现问题，那么处理问题的时间就需要乘上几百倍。因而，需要从编译层面和运行层面都要有足够的机造去包管一个不变的主干分收，才气包管营业侧的持久不变性。

营业层的依赖耦合问题

大型项目动则万万行的代码，代码间的依赖关系是复杂的网状关系。需要基于代码的语法示范型，从语义中去阐发不合理的依赖，并输出治理的计划。

我们内部自研了源码依赖关系阐发平台用于依赖关系阐发监控和代码治理，持久监控组件间的依赖度。同时，需要成立依赖安康度模子，从持久演进的角度去监控避免代码的劣化。

图16：spider 组件依赖阐发平台

总结

大型项目标组件化工做是一个系统性工程。涉及工程架构的革新、CI/CD 研发东西链的支持、当地研发东西链的支持，营业架构的设想优化，需要从各个方面综合考虑成本和收益。

没有更好的架构，只要更好的架构，在架构演进的过程中，我们需要充实考虑架构的改动对营业的影响以及能给营业带来的收益。好的架构必然是能帮忙营业节省时间，包管量量的。与此同时，我们在架构改良的过程中，要包管不克不及影响营业的一般迭代，所以向前兼容且制止大面积抵触也是很重要的工作。

组件化里面处处都有欣喜，好比一个小小的 hmap 优化，能够很大水平的削减编译耗时，好比一个二进造的压缩息争压的优化，能够很大水平削减 pod install 的整体耗时。

当然那里面也会有良多很棘手的问题，需要通过一些特殊的计划处理，好比针对散布式开发，因为阻塞式发版一定会招致一些差别分收存在抵触的代码发版后影响主干的不变性。

因为文章篇幅有限，只能点到即行地介绍当前一些工做功效和思虑，各个 Topic 还有一些新的标的目的在摸索，若是抖音无人曲播协议软件手艺开发你对 iOS 底层原理、架构设想、构建系统、主动化测试有深切领会，快来参加我们吧！

参加我们

我们是负责抖音客户端根底才能研发和新手艺摸索的团队。我们在工程/营业架构，研发东西，编译系统等标的目的深耕，支持营业快速迭代的同时，包管超大规模团队的研发效能和工程量量。在性能/不变性等方面不竭摸索，勤奋为全球数亿用户供给最极致的根底体验。

若是抖音无人曲播协议软件手艺开发你对手艺充满热情，欢送参加抖音根底手艺团队，让我们共建亿级全球化 App。目前我们在深圳、上海、北京、杭州、均有雇用需求，内推能够联络邮箱：tech@bytedance.com，邮件题目：姓名-工做年限-抖音-根底手艺-iOS/Android。或间接点击拓展链接查看部分所需岗位！

欢送存眷「字节跳动手艺团队」

送达简历请联络邮箱：tech@bytedance.com