防劣化机制、向前兼容今日头条前端架构设计解读

防劣化机制、向前兼容今日头条前端架构设计解读本站　　当然，这样的压力需要前后端的技术团队共同承担，而后端架构的解读比较多，我们这篇文章主要是想介绍今日头条在前端架构上的一些设计原则和解决过的问题

　　当然，这样的压力需要前后端的技术团队共同承担，而后端架构的解读比较多，我们这篇文章主要是想介绍今日头条在前端架构上的一些设计原则和解决过的问题。

　　万里鹏老师目前就职于今日头条 Android 平台架构部，负责 Android 端性能、稳定性优化，研发流程组建和标准化建设，研发效率优化，架构优化与演进。以下是对万老师的采访问答整理：

　　万里鹏：我们遵守的整体原则是，架构服务于业务，以提升业务开发效率和体验为目标，配合业务发展齐头并进。

　　稳定性和可维护性：架构服务于业务，架构和业务都是持续迭代的，所以稳定性和可维护性很重要，架构设计不能影响到整体业务稳定性和可维护性，相反应该提升业务的稳定性和可维护性；

　　与业务形态和组织架构契合：业界有多种多样的架构设计方案，在头条前端架构设计时：需要从实际业务形态和组织架构出发，选择与业务形态和组织架构契合、最合适当前业务的方案。使得架构演进能给让业务开发更内聚、协作更顺畅，最终带来业务开发效率和体验带来提升；

　　成本可控：架构设计不建议憋大招，而应该是一定时间跨度内可落地、可完成的。架构设计应该是可以拆分为多次小的架构演进，然后通过配合业务持续迭代，最终达成设计目标。

　　万里鹏：业界有一些做得比较好的产品，也是我们参考的对象，毕竟技术领域尽量要避免重复造轮子。像微信、支付宝、美团等超级 App 的架构演进我们也会去学习了解，吸取别人的经验。

　　关注点这里，会关注：模块 / 组件划分、分层的策略和维度；模块 / 组件间通信方案；架构演进中遇到的问题；架构演进过程中使用的工具；防劣化机制；架构演进和业务迭代的合作模式；后续架构演进的方向。

　　万里鹏：业务高速迭代和架构演进的冲突与合作，其实大家也都明白，业务肯定是持续迭代的，不可能停下来专门进行架构优化；同时架构也需要持续优化，否则架构无法跟上业务，会导致问题越来越多。所以业务高速迭代和架构演进的既有冲突也有合作。

　　我们的解决办法是，业务和架构同步进行，以合作的形态共同为业务服务。同时合理安排业务迭代和架构优化的时间分配，不至于厚此薄彼，使得业务和架构能够并驾齐飞。

　　其次是，在长期架构演进与短期架构优化的取舍和配合上，我想这也是技术团队普遍会遇到的问题。架构演进是一个长期的工作，而版本迭代是短期的，优化是需要落地到版本迭代中的，那么肯定会存在长期架构优化和短期架构优化的取舍和配合问题。

　　常规的解法是对长期的架构演进方案进行合理拆分，拆分为多个短期可实现的架构优化方案，落地到不同的版本中，确保架构演进是以架构优化的方式在持续进行的。另一方面短期架构优化需要以长期架构演进为目标和方向，从而不至于跑偏。

　　随后，在跨部门协作中，因为移动端是众多业务共同集成在同一个 App 中，所以会涉及很多业务方，也存在跨部门协作的问题，这是难以避免的。首先是要达成共识，架构优化是为业务服务的，是和业务共赢的，业务也是愿意配合进行架构优化的。所以需要提前沟通，一起协调。

　　接着是在架构演进过程中，发现在需要花费很多时间在问题分析和定位过程中，最好的解决办法就是进行相应的工具链建设，参考和借鉴了业界开源的一些工具，同时也有针对性的设计和实现了很多的工具。工具链建设可以加速问题分析和定位，带来效率上的提升。

　　最后是防劣化机制的建设，在业务迭代和架构优化过程中，遇到了很多不符合架构设计的代码，导致架构出现劣化。架构是有生命周期的，劣化是肯定会出现的。通过防劣化机制及时发现问题，并进行拦截和消费，有助于保持架构持续正向演进。

　　万里鹏：我个人认为是历史遗留问题的消费，架构是持续演进的，App 在第一次上线时就已经存在一个相应的架构设计，后续更多的是在原有架构上进行优化和演进，而不是直接丢弃原有代码直接重新设计一套新架构，所以肯定需要处理历史问题。

　　涉及版本众多：移动端一般迭代周期比较短，所以累计上线的版本数量极大，同时也会导致累积了大量的遗留问题，这些遗留问题会给架构演进带来很多困难；

　　需要向前兼容：移动端都是高速持续迭代的，而且老用户会占所有用户中的大多数，所以客户端迭代需要兼容之前的版本，不然容易版本升级后出现异常。而如何兼容历史设计，如何保障在向前兼容的情况下还能持续进行架构演进是需要慎重考虑的；

　　历史问题消费困难：一方面架构演进在很多场景上难以进行实验和逐步放量上线，而且一旦上线只能继续向前迭代、而不能回滚，所以在问题消费上需要小心谨慎。另一方面，移动端是众多业务共同集成在同一个 App 中，所以会涉及很多业务方，同时很多问题也是同时涉及多个业务方的，而不同业务方的时间安排可能还不一样，所以在历史问题消费上需要协同处理。

　　万里鹏：虽然像高并发、负载均衡和容灾等架构设计的核心点在移动端上不存在，但是移动端还是有它自身的重点：

　　组件化：移动端往往是多个团队合力完成同一个 App 的开发工作，为了实现多团队协作，会将 App 拆分为不同的模块，由不同的团队负责不同模块的开发维护工作。同时模块会被构建为中间产物，以组件的形式进行集成，从而加速整体工程的编译速度。使得整体架构方向都在以组件化为承载形式，同时不断缩小业务所需要关心的范围、不断扩大代码复用范围；

　　插件化：随着业务的持续迭代，App 中聚合的功能越来越多，包体积也越变越大，导致用户下载安装体验变差。所以业界也衍生了插件化方案，可以将安装包拆分为宿主和若干插件。用户在应用商店下载时只下载安装宿主部分，其他插件在用户使用到相关功能时再通过网络进行下载，从而解决包大小问题；

　　多 App 复用：业界很多产品在原有 App 的基础上都有衍生出极速版、特价版、或者专业版，通过不同的 App 来服务不同的用户群体。而这些不同的新衍生的 App 和原 App 在很多功能上都是重合的，如果分开开发维护的话，显然需要投入更多的人力资源。所以往往都会考虑实现多 App 复用，使得相同的部分只用进行一次开发，从而提升研发效率；

　　动态化：大多数业务中都会有一些业务层级较深、使用用户较少，或者一些周期较短、时效性很强的业务功能（比如节假日活动等）。这些业务功能如果使用原生的开发方式，需要重新发版，时间点和覆盖率可能无法保障，同时也会导致包 size 增大。所以往往会采用动态化的方式进行开发：比如 H5 网页、Hybrid、RN、小程序等，这样可以实现相应功能的快速迭代，而不需要重新发版

　　多端复用：前面提到了在 Android 或者 iOS 某一平台上的多 App 复用，也提到了动态化能力，往往动态化就是具备同一套代码在 Android 和 iOS 双端实现复用，这样可以极大的提升研发效率。当然除了动态化方案，一些原生方案也可以实现在 Android 和 iOS 双端复用，同时 Flutter 等自建渲染方案可以实现在更多端复用，这也是业界在重点关注的一个方向。

　　万里鹏：这正如上面一直提到的，不管是架构优化还是性能优化，都是长周期、持续推进的过程，所以我们也会围绕业务环境去做完善。

　　1. 多端复用：字节内部的信息流产品有今日头条和今日头条极速版两个产品，现在两个产品的代码复用率还可以做进一步的提升，这是后续架构优化的一个重要发力点。这样可以实现更高的开发效率，使得这两个产品可以更加快速的给用户提供更多优质服务。

　　2. 架构优化闭环：头条架构一直在持续优化和演进，解决了大量的业务和技术问题。但现阶段的业务和技术问题发现到架构优化还没有完全形成闭环，还有很多问题没有被挖掘出来，问题的解决程度也无法全面评估。后续会从架构度量指标、架构分析工具建设和防劣化机制 3 个方向着力实现架构优化闭环。

　　架构度量指标：有了架构度量指标后，就可以主动对现有业务和架构进行分析，快速去发现和定位问题，从而进行相应的优化。同时也可以对优化后的结果进行度量，判断问题是否得到了有效解决；

　　架构分析工具：头条在进行架构优化的过程中，往往需要进行大量的分析来发现问题、定位问题和解决问题，而相应的工具能够极大的提高效率。后续会针对性的建设更多的架构分析工具，更好的服务架构演进和业务发展；

　　防劣化机制：由于业务的高速迭代和新同学的加入等原因，头条日常开发过程中也遇到了很多不符合架构设计的代码，这些代导致架构出现劣化，缩短架构生命周期。后续会建立更多的防劣化机制，及时发现并拦截这些不合理代码，保障架构能持续正向演进。

　　公司内：字节内部有大量的 App，头条作为字节内部一款头部产品，已经为公司内部其他产品提供了大量的技术支持。后续，这一块将会继续加大投入，沉淀出更多更优的技术方案，更好的支撑公司内其他产品的发展；

　　业界：头条也对外输出了大量的技术方案，这一块将会继续加大投入，沉淀和输出更多更优的技术方案，为业界前端技术生态的发展做出贡献。

　　万里鹏：技术人还是应该多看看业务，不能只在技术的象牙塔里，同时还要多看看业界的动向，接触业界的专家和经验。

　　1. 全局视角和思维：以全局的视角和思维去发现和审视业务的需求和问题，从而设计出最适合业务的架构；

　　万里鹏，目前就职于今日头条 Android 平台架构部，负责 Android 端性能、稳定性优化，研发流程组建和标准化建设，研发效率优化，架构优化与演进。主要服务于今日头条、同时技术复用在抖音、西瓜视频、番茄小说、多闪等全公司级移动端产品，为提升业务开发效率、架构与开发模式演进、优化用户体验提供整套的技术服务支持。