从 Android 组件到全端组件：一个跨端低代码平台的演进

2022 年，我入职某互联网公司，参与一个跨端低代码平台的建设。最开始负责 Android 端组件，后来接管了所有形态的组件工作。

在进入正文之前，先简单介绍一下这个平台。

开发者通过拖拉拽搭建页面，再用 JavaScript 编写业务逻辑，最终生成 PC Web、H5 和 Android 应用。整个开发流程分为三个阶段：编辑态负责开发，预览态负责快速验证和调试，最后生成对应平台的产物。

组件贯穿了整个流程。开发者在编辑器里选择和配置组件，在预览页里检查组件，最终用户在应用里使用组件。我最初负责的 Android 组件，只是这条链路的最后一部分。后来才逐渐意识到，许多出现在产物里的问题，需要从更前面的环节解决。

一、从零到一

“平台—scheme—产物”的整体设计，带来了两个绕不开的问题：多端一致性与性能。

scheme 可以简单理解为平台生成的页面和逻辑描述。各端解析同一份 scheme，生成对应的界面和交互。

多端一致性的问题是：同一套描述，在不同端上的表现和交互可能不同。性能的问题是：为了实现相同功能，低代码应用需要额外解析和执行这套描述，这部分开销可能影响使用体验。

初期的运行时路线确定为 React + DSL，Android 端也围绕这条路线展开。这个选择有很现实的背景：

1. 公司希望平台聚焦于前端开发者，预期未来平台开发者中，前端开发者占比会达到 90%，因此逻辑语言选择了 JavaScript。
2. 当时公司内部约 80% 的开发者是前端开发者，技术骨干也以前端为主。
3. 平台确定以网站形态提供，而不是桌面应用。

因此，Android 的整体方案也需要向前端靠拢，包括组件。

当时，组件能力的定义基本以 CSS 和浏览器能力为参照。但 Android 与浏览器有各自的布局、渲染和事件机制，要在 Android 上对齐这些能力，并不容易。

多端不一致的问题，从这里就已经埋下了伏笔。

不过，当时更紧迫的问题很快暴露出来：Android 端的性能，完全没有达到可用水平。

二、开箱即用

性能问题主要来自两部分。

一部分是当时公司的设备难以承受 QuickJS 执行 React 和相关 JS 运行逻辑的开销；另一部分是 scheme 体积过大，Android 容器层解析较慢。

相比运行时问题，scheme 体积的问题更容易找到直接的解决办法：聚合组件，让一个组件包含更多元素和功能，减少页面需要描述和组织的内容。

当时，业务项目有两个明确目标：尽快实现需求，并保证性能过关。

于是，组件改版的方向也确定了：包含更多内容，开箱即用。

但公司当时没有设计师，组件也没有独立的设计稿。我们只能拿着业务项目的设计稿，按照这个方向设计组件，优先保证当前项目能够交付。

这种做法很快产生了代价：组件越来越贴合某个业务场景，也越来越难适应其他场景。

回头看，这次改版确实有问题，后来我们也确认了这些问题并做了调整。但评价当时的选择，不能跳过当时的条件。

性能“卡脖子”，业务又有时间压力，我们在组件层做了妥协。这个妥协帮助项目向前走了一步，却也让团队在后面的数年里，持续为它付出成本。

三、业务拷打

经过半年的努力，第一个业务项目上线，组件完成了第一次大考，表现只能说差强人意。

当时最明显的问题，是大量的多端不一致。团队的判断也很直接：需要尽快解决这些差异。

但多端不一致只是症状。需求如何定义、组件如何设计、不同端如何沟通，以及此前为了性能做出的妥协，才是问题背后需要继续追问的原因。

我们还没来得及充分思考，第二、第三个项目就来了。

两个项目的设计风格迥异，体量也更大。围绕第一个项目设计的组件，很难承接新的业务需求。每个组件都要继续补充能力，预览态和真机之间的差异，又让开发者在使用过程中遇到大量问题，需要技术支持。

需求开发和技术支持挤满了时间。团队已经很难停下来考虑架构，更难为长期问题留出完整的解决周期。

于是，我们不断打补丁，补属性、补逻辑、补场景，优先保证两个业务项目能够上线。

组件越来越复杂，问题也越来越难定位。

四、走马上任

随着项目增多，组件的问题始终没有得到彻底解决。最后，组内几乎所有人都在参与需求开发和技术支持，很少有时间优化代码或者重构。

在这样的状态持续了一段时间后，领导决定让我担任组件负责人。

从入职到这时，已经过去了整整两年。

这两年里，Android 架构一直在围绕性能做调整。

第一次优化，是在 Java 层实现 React 的那套“数据驱动”机制。这个方案表现欠佳，也带来了不少新的问题。

第二次优化，运行时回到 JS 层，但没有重新套用 React，而是在这一层完成从“数据绑定”到“命令式操作”的转换。这个版本的性能提升显著，此前在 Java 层实现 React 机制带来的问题，也随之消除了。

后续优化继续聚焦于 Java 容器层，通过异步加载、JS 文件字节码、产物分析与懒加载等策略，进一步改善 Android 产物的性能。

性能终于有了余量，我们也重新获得了一些选择空间。

最早讨论过的原子组件方案，又被搬上了桌。

五、推倒重来

那段时间，组内重新复盘了多端一致性问题，归纳出三类主要原因。

第一，需求对接和执行流程不清晰。

组内成员更多是在接收需求，却缺少明确的需求对接人。接到需求后，也没有统一的 SOP 可以参照执行。信息主要靠口头沟通传递，很多环节依赖个人主动补齐，遗漏和理解偏差很难避免。

第二，组件缺少共同的实现依据。

一个组件对应一张静态设计稿，各端分别实现。设计稿能说明某种状态下“长什么样”，却很难完整表达属性变化、内容变化和交互变化之后应该如何表现。

在大量业务场景中，不同的实现方式就会逐渐暴露差异。

第三，平台本身存在差异。

字体尺寸、overflow 规则、事件分发、嵌套滚动等能力，在浏览器和 Android 上有不同的机制，不能只靠“照着实现”就自然一致。

第三类问题需要技术方案来处理，前两类问题则需要规范和流程。许多看起来发生在代码里的差异，其实在需求传递和组件定义时就已经产生了。

找到原因之后，调整方向也更清楚了：

• 制定组件规范，把每个属性的含义、行为和限制说明白。
• 设计低耦合、高内聚的原子组件，并验证组合后的业务覆盖能力。
• 对齐各端的能力边界，以多端能够共同支持的能力作为组件承诺，避免一端提供的功能，在另一端成为缺陷。

实现侧只维护原子组件，平台侧通过搭建，把它们组合成基础组件。平台生成的描述天然可以被多端复用，也就有机会减少各端重复开发的投入。

但性能问题再次出现了。

大量原子组件的组合，会让现有项目的 scheme 内容显著膨胀。这一次，即使 Android 产物的性能已经不是主要瓶颈，平台编辑态、预览态，以及相关接口的响应时间，仍然受到了冲击。

似乎一切都在重演。

组件越灵活，组合和维护就越复杂；想减少各端的人力投入，就需要平台承担更多工作；而这些工作，又可能增加运行和加载成本。

我们开始用一个“不可能三角”描述这种反复取舍：灵活性、人力成本、性能。

而这时，coding agent 来了。

六、未来已来

coding agent 让我们重新审视了一个原本很难承担的方案：在代码层完成原子组件的组合。

此前，我们希望通过平台搭建生产基础组件，是因为各端分别编写和维护组件的成本太高。如果这部分实现工作能够由 agent 辅助完成，那么基础组件就有了新的生产方式。

思路并不复杂：保留平台定义的原子组件，将“原子组件搭建基础组件”的过程下沉到 procode，也就是代码实现层，由 agent 根据组件规范完成组合。

这样，组合细节可以留在组件代码里，页面的 scheme 主要描述基础组件的使用和配置，不必展开全部内部结构，从而缓解 scheme 膨胀的问题。

这个方案让我们看到了新的可能，但现在还不能说“不可能三角”已经被彻底打破。

Agent 有机会降低组件实现和维护的人力成本，让灵活性与性能之间出现新的解法。能否稳定生成符合规范的多端实现，能否控制测试和维护成本，仍然需要实际项目来验证。

目前，我们正在尝试建设一套组件开发的 harness 工程，也就是围绕 agent 建立一套可执行、可检查的开发流程：

先通过 agent + skill 生产组件文档，再由各端根据组件文档和对应的 skill 生成实现，随后结合文档、实现和测试 skill 完成验证，最后进入发布。

这套流程的关键，在于每一步都有明确依据，也有可以检查的结果。组件文档是否完整，多端实现是否一致，测试是否覆盖真实业务场景，都需要逐步落实。

回顾这几年的工作，很多方案都和当时的条件有关。

聚合组件回应了早期的性能和交付压力，原子组件回应了后来越来越复杂的业务需求。如今，agent 又让一些过去在人力成本上难以承担的方案，值得重新尝试。

这是一个美好的预期，落地可能比想象中更难。

但没事，先把流程跑通，在真实业务里看清问题，再继续优化。

未来软件开发会走向何方，我也不知道。至少眼下，我们又有了一条值得走下去的路。