接上篇：https://developer.aliyun.com/article/1225889?spm=a2c6h.13148508.setting.16.595d4f0eudDbz0
三、 为什么用KUN渲染？
1. 闲鱼号端侧主要问题
为对症下药，对闲鱼号端容器（Weex）侧进行了全面的诊断。问题集中在性能、渲染质量、扩展能力、终端体验一致性四个方面。
1) 性能：闲鱼号首屏（700ms）和交互性能不错，性能问题主要在内存上，Weex页面重度访问是闲鱼客户端OOM的主要场景之一。启动Weex容器会产生较大的增量内存，部分控件无回收机制也会导致内存增加，如waterfall组件：加载5页带来了3000个未释放内存节点、40M内存增量。
2) 渲染质量：在基础样式、布局、事件体系等方面和前端预期不一致，如：
• 不支持overflow：visible。
• 不支持z-index，层叠只能通过节点位置先后实现。
• 不支持display：inline，替代方案rich-text标签不支持line-height等基础样式控制。
3) 终端体验一致性：闲鱼号工程中充斥着大量形如if(isIOS){xxxx}else if(isAndroid){xxx}的代码，主要作用之一按端处理，以规避渲染差异。尽管如此，目前两端仍存在不小差异。
4) 扩展能力：前端标准和生态起源于PC，无线设备相对于PC存在不少特性，无线端原生能力相对于纯前端也更加丰富。受容器扩展能力（成本）限制，前端无法（标准）实现部分业务认为理所当然的体验：
• 无法在元素上屏前获取元素布局信息（宽、高、位置）。大多折叠场景需要。
• 高频动画性能不佳。绑定滚动的动画如曝光、导航透明度渐变等场景。
• 基础控件能力缺失。如：输入框无法自动聚焦、控制聚焦时距离键盘空间；增强控件定制困难，如在嵌套滚动容器上添加回到顶部。
为从根本解决上述问题，我们进行了新容器调研。
2. 渲染容器选型
在无线前端容器演进过程中，前端侧比较固定，框架（React、Rax等）驱动业务代码生成Virtual DOM以抽象视图结构，特定Driver/容器内置JS Module将Virtual DOM翻译为容器对应的渲染指令；容器侧主要历经Webview容器渲染->客户端渲染衍生->自绘渲染（衍生）三个阶段。其中：
1) Webview渲染容器。为解决Native页面双端研发成本、双端渲染不一致、无动态化、页面与客户端耦合的问题，Webview容器开始承载无线业务。
2) 客户端渲染衍生容器（React Native、Weex 1.0）。Webview解决问题的同时引入了新的问题，渲染性能和能力边界明显逊色，故在2.0时代诞生了客户端渲染衍生容器，对接起了前端、客户端生态，用前端生态写，用客户端能力渲染。
3) 自绘渲染衍生（基于Flutter/完全自绘）。客户端渲染一定程度了解决Webview渲染性能、能力边界的问题，但将前端标准/生态“翻译”为Android/IOS标准/生态的过程，存在明显的失真，实际渲染与预期不一致，Android与IOS不一致。由此，更彻底的方法是重写渲染能力以进行统一。
自绘渲染方案一方面性能优于Webview，一方面渲染一致性优于Weex，闲鱼号新容器往自绘（衍生）类选型便是自然的方向。在自绘容器中，基于Kraken，闲鱼技术团队自研了KUN容器，整体思路是对接前端和Flutter生态，用前端写，在Flutter渲染。对于上文提到闲鱼号端侧的4个问题，KUN对应的解决原理如下：
1) 性能（内存）
• 对于已接入Flutter的客户端，打开KUN页面的增量内存只有KUN引擎本身，没有Flutter负担，KUN引擎较为轻量，内存增量相对于Webview、客户端衍生方案较少。
• Flutter自身提供了良好的回收能力（sliver），在无限流（瀑布流）场景，内存占用不会随内容加载无限上涨。
2) 染质量。借助Flutter像素级渲染能力，上述overflow：visible、z-index、rich-text等问题均能解决。
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基础组件，便能有更好的终端一致性。
4) 扩展能力。经过一层KUN Element抽象，自定义Flutter组件也可视为基础组件同等公民开放给KUN前端。如此，通过低成本对接前端、Flutter生态等方式，KUN有了灵活强大的扩展能力，以嵌套滚动容器为例：
以上从理论层面推导了KUN能解决上述问题，我们便开始了闲鱼号升级到KUN容器的实践。现阶段已完成升级，经过了一轮技术灰度。回顾升级过程，也像新生事物一样充斥着标准对齐、性能等诸多细节问题，但最终都悉数解决，整体体验符合预期。
接下篇：https://developer.aliyun.com/article/1225885?groupCode=idlefish
