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

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

三代终端容器 KUN 的首次大考【架构演进】_第1张图片

闲鱼号是个用户高频访问的场景,产品 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 改动不时“牵一发而动全身”

三代终端容器 KUN 的首次大考【架构演进】_第2张图片
  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 不一致。由此,更彻底的方法是重写渲染能力以进行统一。

三代终端容器 KUN 的首次大考【架构演进】_第3张图片

自绘渲染方案一方面性能优于 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 基础组件,便能有更好的终端一致性

三代终端容器 KUN 的首次大考【架构演进】_第4张图片
  1. 4. 扩展能力:经过一层 KUN Element 抽象,自定义 Flutter 组件也可视为基础组件同等公民开放给 KUN 前端。如此,通过低成本对接前端、Flutter 生态等方式,KUN 有了灵活强大的扩展能力,以嵌套滚动容器为例:

三代终端容器 KUN 的首次大考【架构演进】_第5张图片

以上从理论层面推导了 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. (Gif 压缩掉帧严重,实际无明显卡顿感)
  4. • 借助 Flutter 能力取背景图主色的蒙层

三代终端容器 KUN 的首次大考【架构演进】_第6张图片
  1. • 借助 Flutter 在上屏之前能获取布局信息,标准化实现了纯前端难以模拟的行数过多动态折叠功能

终端体验一致性

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

三代终端容器 KUN 的首次大考【架构演进】_第7张图片

后续思考

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

三代终端容器 KUN 的首次大考【架构演进】_第8张图片

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

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

16b408e6967f35c671aa6bfbb91f5849.png

你可能感兴趣的:(分布式,gwt,toa,html,产品经理)