猫客页面内组件的动态化方案—Tangram新解

导语
一直以来，无线应用都在不断寻求动态化页面的解决方案，在阿里巴巴集团内，除了风风火火的 Weex 项目外，各个团队都有大大小小的解决方案。我们猫客一直持续基于 Tangram 方案来解决页面动态化的问题，然而在面对持续升级的业务需求时，原有的开发模式也慢慢变得无法胜任，本年度以来…

需求大涨，唐僧历险记

随着业务发展，曾经简单的需求在如今已经变得十分复杂，以每年常规的双 11 大促为例，每个会场动辄几十个技术同学参与开发，高峰期代码变更提交量 1000+ 笔，除了传统的样式变动外，近年来也涌现了业务动态组件、数据埋点、业务组件 AB 测试等新需求，仅靠人工操作来管理，很容易出现纰漏，开发同学经常疲于奔命，成了真正的 “唐僧”，每日除了应对技术上的难题，还要时刻注意各种 “妖精” 对代码的侵袭。

工程优化，修炼九九八十一难

为了解决上述问题，猫客团队今年做了许多的工作，包括 Tangram 工程化和编译工具链、业务动态组件化和工程化、工程质量保障和提效等方面。
工程化和编译工具链，是我们的起点，Tangram 一直以来支持多种渲染方式，包括在 Native 层使用 JS 执行，或者在 Web 容器里使用 JavaScript 执行，我们希望多种渲染方式能通过一致的 API 被调用，经过较长时间的探索，最终选型了 React，将 Tangram 组件统一封装为 React 组件，由此打通了 React Native 和 Web 的编译工具链。然后我们将日常开发的构建过程自动化，包括对组件代码的提取、压缩、混淆等处理，利用丰富的工具链资源，极大地提高了开发效率和组件的加载速度。

随着工程化进程的开展，我们对整个 Tangram 框架做了模块拆分，使其粒度更细，更方便扩展和维护。工程化完成后，Tangram 变成了一个插件平台，只需简单的配置，便可接入各种不同的渲染引擎，比如现在我们已经支持 React Native 和 WebView 两种渲染方式。与此同时，我们也对渲染引擎做了大量定制，使之性能更优，更符合工程化的要求。

业务动态组件化和工程化是本年度工作中最核心的内容，也是最繁琐的一步。首先是组件库建设，目前，为了帮助各团队更好地管理各自的组件，我们内部搭建了一个组件管理平台，供开发人员检索和引用现有的组件。同时，通过对组件的元数据管理，可以方便地做组件的动态化和可视化。

同时，为了减轻开发者的负担，我们在组件工程化中引入了自动化构建的理念，开发人员只需维护组件的源码，将编译、构建、发布等过程自动化，使业务同学无需关心繁琐的构建配置，也不必关注各种环境差异导致的问题，只需一键生成离线包，便可完成一个组件的构建和发布。

工程质量保障和提效是历久弥新的话题，随着业务和系统的不断扩张，工程质量的保障日益重要。今年以来，我们通过对单元测试用例的统一管理，完成了两套测试方案的建设，一套面向 Tangram 框架的单元测试，另一套面向基于 Tangram 开发的业务代码的单元测试，通过自建的自动化任务管理系统，可以轻松实现任务的调度和结果收集，无需任何手工操作。在基建方面，针对 Tangram 组件化改造后的产物，我们统一了产物的打包方式，并自研了一套产物发布平台，做到产物的统一发布、管理和查询。此外，在组件化改造后，我们还改造了页面设计器，实现了基于组件的拖拽，使页面开发更加灵活和高效。

拨开云雾见明月

经过一年的探索和努力，Tangram 在工程化、业务动态组件化、质量保障和提效等方面都取得了长足的进步，开发者的体验也从原来的复杂、繁琐，转变为了轻松、高效。这得益于我们对技术方向的正确选择，工程基础的扎实建设，以及整个团队的不懈努力。在未来，我们将继续深耕技术，优化组件的加载机制，提升开发者的开发效率，并积极探索端云协同的新技术和新模式，为团队的业务发展提供更加强有力的技术支持。

我们相信，Tangram 将成为猫客团队动态化技术栈中不可或缺的一部分，为猫客业务的快速发展保驾护航。