百度App组件化之路

原创：GuoJin 百度APP技术团队-资深技术专家 文章来源：百度APP技术微信公众号

          组件化是一个老生常谈的涉及面很广的话题，即不是做好一件事而是做好一系列的事情才能达成；其中包含组件化框架在内的各架构层级、构建系统、依赖管理系统、以及配套的防劣化机制与规则规范。

          本文主要基于百度App背景、目标和组件化历程来讲述保障并行开发和组件复用的手段，尽量避免过多发散到构建系统、依赖管理系统,以及组件化框架这样的具体子方向。组件化的重要性取决于应用规模、团队规模、产品技术目标；所述内容虽然是从iOS平台出发，但方法论与实现路径适用于大部分平台。

背景与目标

百度App(大型App)复杂度来源

• 业务规模大：百度App技术方向及子方向70+，单端代码量180w+；
  
  目标：隔离各组件间影响避免故障蔓延，并控制整体App的复杂度；
• 团队规模大：有代码权限的数百人;
  
  目标：保障高效并行开发；
• 公司内部接入业务多：30+,非单纯基础库，与百度App关系复杂；
  
  目标：处理接入业务与百度App架构及架构中各组件关系，保障快速高效接入与基础能力复用。
• 迭代速度快：3周一个版本，2周开发1周测试；
  
  目标：避免高速迭代情况下组件化程度劣化。
• 技术形态多：H5、NA、Hybrid、Talos、Flutter并存；
  
  目标：保障基础能力复用，构建系统支撑。
  

另外启动速度、体积等准入流程的约束；以及目标的多样性也是大型App复杂度来源因素；由背景产生的目标是天生的技术需求，除此之外，百度App在不同阶段有不同的产品技术目标。

百度App不同阶段的不同目标

• 合作业务三方库复用;单个技术组件输出(最早的需求，2014年),对单个组件输出来讲，如何避免输出时,拔出萝卜带出"泥";
• 矩阵产品孵化（2017年~2019）；
• 小程序开源复用（2018年）：输出组件兼容不同宿主,保持部分依赖组件可替代性；
  目标多样性要求在开发时考虑到各个目标的诉求，在方案设计时尽量避免和这些目标冲突。

重要架构迭代

初始态-2013(钻木取火)：

这一时期，百度App浏览器角色较重，大家都在一个工程里开发，各业务和基础逻辑交错，没有边界，你中有我、我中有你