三代终端容器 KUN 的首次大考架构演进

闲鱼号在闲鱼业务中一直承担着非常重要的角色，它既是卖家组织商品的货架，又是达人自我表达的载体，既是大 V 私域运营的阵地，又是小铺开店经营的门面。它是闲鱼各产品线的交汇点，号店浑然一体，一定要类比的话，它更像是抖音/小红书个人主页 淘宝店的综合体。

闲鱼号是个用户高频访问的场景，产品 Feature 快速迭代，体验上备受关注，当下面临的问题：

• • 古董级高度耦合的业务代码、多业务线并行的日常需求时常让前端成为交付瓶颈

• • 基于 Weex 1.0 渲染附带着大量的双端不一致问题和体验顽疾，也限制了交互创新

最近我们对闲鱼号做了架构升级，相信很快就会和大家见面，这里做个小结，概括下来这次升级直接带来的收益：

体验

中高端机上维持秒开，同时：

• • 新增微信朋友圈式的下拉封面交互，手势体感更加连贯，个人表达更加充分

• • 新增贴近原生体验的下拉刷新交互，提升 APP 体验一致性

• • 优化嵌套滚动的交互体验，纵划横划更加自然顺滑，逛起来更高效

(iPhone12/iOS16 录制，Gif 压缩掉帧严重，实际无明显卡顿感)

• 可维护性

可维护性的提升是「产品->设计->实现」综合优化的结果，具体：

• • 产品侧重新梳理所有 Features，抽象并制订同类功能的表达原则，确定各业务的表达方式、优先级

• • 设计侧综合考虑模块权重、所属角色、用户比例、扩展方式等因素确定设计框架

• • 技术侧通过组件化拆分 全局状态的方式解耦业务逻辑，提高需求并行效率

为什么要升级

闲鱼号项目已有超过5年历史，目前业务较难向前迭代，原因主要归结为端容器能力受限和架构腐化两方面。

端容器能力受限

闲鱼号目前是前端页面，容器使用 Weex 1.0（后文统称 Weex）。Weex 两年前就少有维护，其既有问题使得承载当下业务有以下问题：

1. 1. 难维护。闲鱼号存在较多的舆情顽疾，究其原因，Weex 不是标准前端容器，在布局、组件、动画、事件等方面与预期不一致。一部分绕道解决，一部分只能保持现状依托升级容器解决

2. 2. 难做好体验。业务定位使闲鱼号在体验上有较高要求，但“这个交互是 Native 实现的，Weex 做不了”不时会出现在业务迭代的技术评估中。

项目架构腐化

闲鱼号有较高的业务复杂度和较厚重的历史上下文。承载了人设、电商、内容、信任等领域的业务，同时存在多维度视图（主/客态、B/C态、内容/电商态），多年下来已发展到 5.x 版本，技术架构仍未进行过本质升级，相关问题已严重影响项目日常维护和迭代，主要体现在：

1. 1. ViewModel 过于复杂。ViewModel 是大管家，统一格式化、将数据派发到模块。在平铺了15 模块数据的场景，ViewModel 改动不时“牵一发而动全身”

1. 2. 缺乏统一的状态共享方案，数据流混乱。组件间通信存在 Vue 事件体系、自建事件体系、全局 controller 、自建状态共享体系多种方式

升级目标

对应上述问题，闲鱼号迎来了技术架构升级。升级核心目标是，未来1-2年技术架构不成为项目迭代、维护的吞吐瓶颈，支撑业务快速、平稳、创新的发展，能持续保持高标准体验。其中：

• • 容器能力：升级渲染容器，提升容器能力边界。明显减少存量体验顽疾，多场景协助业务、设计完成理想的交互、视觉体验

• • 项目架构：模块解耦，打造清晰的数据流。明显提升迭代效率，减少影响面回归成本和压力，降低不同模块协作冲突次数

其中针对项目架构部分非本文重点，主要通过模块化前端后数据协议、统一状态管理方案进行了解决。后文继续介绍容器能力部分的思考和实践

为什么用 KUN 渲染？

闲鱼号端侧主要问题

为对症下药，对闲鱼号端容器（Weex）侧进行了全面的诊断。问题集中在性能、渲染质量、扩展能力、终端体验一致性四个方面

1. 1. 性能：闲鱼号首屏（700ms）和交互性能不错，性能问题主要在内存上，Weex 页面重度访问是闲鱼客户端 OOM 的主要场景之一。启动 Weex 容器会产生较大的增量内存，部分控件无回收机制也会导致内存增加，如 waterfall 组件: 加载 5 页带来了 3000 个未释放内存节点、40M 内存增量

1. 2. 渲染质量：在基础样式、布局、事件体系等方面和前端预期不一致，如：

   1. • 不支持 overflow: visible

   2. • 不支持 z-index，层叠只能通过节点位置先后实现

   3. • 不支持 display: inline， 替代方案 rich-text 标签不支持 line-height 等基础样式控制

2. 3. 终端体验一致性：闲鱼号工程中充斥着大量形如 if(isIOS){xxxx} else if(isAndroid){xxx}的代码，主要作用之一按端处理，以规避渲染差异。尽管如此，目前两端仍存在不小差异。

3. 3. 扩展能力：前端标准和生态起源于 PC，无线设备相对于 PC 存在不少特性，无线端原生能力相对于纯前端也更加丰富。受容器扩展能力（成本）限制，前端无法（标准）实现部分业务认为理所当然的体验：

   1. • 无法在元素上屏前获取元素布局信息（宽、高、位置）。大多折叠场景需要

   2. • 高频动画性能不佳。绑定滚动的动画如 曝光、导航透明度渐变等场景

   3. • 基础控件能力缺失。如：输入框无法自动聚焦、控制聚焦时距离键盘空间；增强控件定制困难，如在嵌套滚动容器上添加回到顶部

为从根本解决上述问题，我们进行了新容器调研。

渲染容器选型

在无线前端容器演进过程中，前端侧比较固定，框架（React、Rax等）驱动业务代码生成 Virtual DOM 以抽象视图结构， 特定 Driver/容器内置 JS Module 将 Virtual DOM 翻译为容器对应的渲染指令；容器侧主要历经 Webview 容器渲染 -> 客户端渲染衍生 -> 自绘渲染（衍生）三个阶段。其中：

1. 1. Webview 渲染容器。为解决 Native 页面 双端研发成本、双端渲染不一致、无动态化、页面与客户端耦合的问题，Webview 容器开始承载无线业务

2. 2. 客户端渲染衍生容器（React Native 、Weex 1.0）。 Webview 解决问题的同时引入了新的问题，渲染性能和能力边界明显逊色，故在 2.0 时代诞生了客户端渲染衍生容器，对接起了前端、客户端生态，用前端生态写，用客户端能力渲染。

3. 3. 自绘渲染衍生（基于 Flutter/完全自绘）。客户端渲染一定程度了解决 Webview 渲染性能、能力边界的问题，但将前端标准/生态 “翻译” 为 Android/IOS 标准/生态的过程，存在明显的失真，实际渲染与预期不一致，Android 与 IOS 不一致。由此，更彻底的方法是重写渲染能力以进行统一。

自绘渲染方案一方面性能优于 Webview，一方面渲染一致性优于 Weex，闲鱼号新容器往自绘（衍生）类选型便是自然的方向。 在自绘容器中，基于 Kraken，闲鱼技术团队自研了 KUN 容器，整体思路是对接前端和 Flutter 生态，用前端写，在Flutter 渲染。对于上文提到闲鱼号端侧的 4 个问题， KUN 对应的解决原理如下：

1. 1. 性能（内存）

   1. • 对于已接入 Flutter 的客户端，打开 KUN 页面的增量内存只有 KUN 引擎本身，没有 Flutter 负担，KUN 引擎较为轻量，内存增量相对于 Webview、客户端衍生方案较少

   2. • Flutter 自身提供了良好的回收能力（sliver），在无限流（瀑布流）场景，内存占用不会随内容加载无限上涨

2. 2. 渲染质量：借助 Flutter 像素级渲染能力，上述overflow: visible、z-index、rich-text等问题均能解决

3. 3. 终端体验一致性。前端对接的生态从两套变成了一套，以 React Native 和 KUN 中 Text 组件渲染为例：下图中，Text 业务组件在 React Native 下被转为了 JS 元素，在 UIManager.js 中转为 RN Element RCTVirtualText。接下来就是客户端部分，RCTVirtualText 在 C 层通过 Bridge 将指令传递给 Native UIManager，UIManager 根据所处不同的系统环境进行组件映射，IOS 映射到 UITextView，Android 映射到 TextView。相对之下 KUN 则是一套映射，呈现 Flutter 基础组件，便能有更好的终端一致性

1. 4. 扩展能力：经过一层 KUN Element 抽象，自定义 Flutter 组件也可视为基础组件同等公民开放给 KUN 前端。如此，通过低成本对接前端、Flutter 生态等方式，KUN 有了灵活强大的扩展能力，以嵌套滚动容器为例：

以上从理论层面推导了 KUN能解决上述问题，我们便开始了闲鱼号升级到 KUN 容器的实践。 现阶段已完成升级，经过了一轮技术灰度。回顾升级过程，也像新生事物一样充斥着标准对齐、性能等诸多细节问题，但最终都悉数解决，整体体验符合预期。

体验变化效果 

性能

1. 首屏性能上，KUN 与 Weex 1.0 勉强持平，中高端机器上维持秒开。内存水位上初步测试较 Weex、WebView 有所降低，待补充准确数据（上图为 KUN，下图为 Weex）

渲染质量

1. 基础样式、布局、事件体系等方面已基本对齐前端标准，overflow: visible、z-index、rich-text等均已正常渲染

2. 扩展能力

3. Kun 使得前端享有了闲鱼客户端 Flutter 生态。闲鱼号升级中，快速扩展了前端无法（标准）实现组件10余个，包括：

   1. • 流畅嵌套滚动

   2. • 富交互下拉封面

   3. • 滚动视频播控

   4. • 图片加载控制（裁剪、渐显等能力）

   5. • 带高斯模糊背景的弹幕

   6. 
   7. (Gif 压缩掉帧严重，实际无明显卡顿感）

4. • 借助 Flutter 能力取背景图主色的蒙层

1. • 借助 Flutter 在上屏之前能获取布局信息，标准化实现了纯前端难以模拟的行数过多动态折叠功能

终端体验一致性

1. 渲染引擎较少与 OS 渲染能力耦合，解决了双端组件、交互（bounce 效果）、布局等方面不一致问题。 除了文字排版和字体外，基本做到双端一致。研发过程中，渲染层面也几乎不出现 if(isAndroid){renderAndroid()} if(isIOS){renderIOS()}的代码。

后续思考

如果从闲鱼号端侧诉求的视角出发，我们可以这样看待 KUN 的演进：

KUN 在基础规范上会持续扩充，并且与 W3C 规范持续对齐；在扩展能力上通过 CSS 扩展、JSAPI 扩展、混合组件扩展等方式持续增强容器能力、拓展容器边界、提升用户体验。

闲鱼号架构在持续演进中。有了 KUN 的加持，我们对此充满信心。