接上篇：https://developer.aliyun.com/article/1225907?spm=a2c6h.13148508.setting.31.595d4f0eudDbz0
四、 终端容器KUN，助力闲鱼再出发
以上的未来研发模式的构想部分的内容在闲鱼已经有了较好的基础，一方面我们的Flutter技术在业务落地侧的占比远高于目前市面上同等体量的App，这样的业务规模和技术落地规模让我们有机会验证在较为复杂的C端场景下基于Flutter技术的容器化解决方案是否有机会走通，随着团队对Flutter技术的理解和沉淀不断提升，在大量体验场景下的富交互细节以及操作系统升级带来的兼容性挑战正在持续被解决和优化，另一方面闲鱼在推进落地一周一版的研发模式的过程中目前通过新的客户端研发平台完成了发版流程的全面数字化和部分场景的技术自动化落地。以研发流程为例，我们力求将核心的90%的协作通过线上审批流、钉钉机器人通知，自动化的版本邮件来完成，让整个过程可观测和回溯，同时在构建集成、回归验证和版本放量等能力上通过跟自动化能力结合加速交付效能的提升。
然而在目前的布局下，闲鱼客户端基于Flutter容器化的基础架构以及一周一版的发布模型，在未来依然有较大的困难需要突破：一方面客户端的人员规模增长速度和生态演进速度在应用层这一侧都显然不如前端，在未来的快速迭代能力侧难以进一步突破以应对不确定的未来，另一方面作为C端产品又要求体验必须对齐原生，基础链路侧的富交互体验会持续存在，这在前端角度又是极大的成本。从这两个角度来思考，我们的终端容器需要进一步升级迭代。它应该海纳百川容纳更大的研发生态，让前端&客户端的生态为我所用，在需要体验的时候进行更轻量级的能力扩展，如直接引入通过Flutter研发的客户端组件，在需要迭代时发挥前端的作用，如研发期的迭代速度，发布期在合规的要求下具备业务线上的快速迭代的能力。
因此从2021年下半年开始，我们的KUN项目应运而生，简单描述KUN的定义，KUN是基于W3C标准子集&Flutter打造的高扩展性、高性能跨端渲染引擎。KUN的目标是通过提供一套统一的容器覆盖端内全部的业务场景来解决端内多套容器带来研发效能低下、业务代码复用难、不同场景叠加带来的性能水位差的问题。为帮助大家理解我这里增加一张KUN与其他类似框架的架构对比图。
KUN具备以下关键特点：
• 高扩展性
针对富交互场景以及高性能场景，Kun提供低成本的扩展机制，将FlutterWidget映射为上层可使用的自定义组件，过程中提供较为方便的文档生成工具给上层开发使用。同样，在W3C标准中，KUN也通过微内核的设计方案将W3C的核心Tag注册入KUN的内核当中。
高扩展性的核心目标是通过复用闲鱼4年来在Flutter侧大量的上层交互控件解决线上产品的交互体验和性能问题。高扩展性也是KUN的最核心特点，后续围绕Flutter生态，后续闲鱼有机会孵化出类似FishDesign的组件库生态。
• 面向W3C标准
上层应用开发通过JS/TS开发，并提供面向W3C子集的标准，这也意味着您可以通过React/Rax等框架进行上层开发。这部分目前跟常见的跨端框架的原理基本一致，在整体设计上也参考了业内主流的跨端框架，在标准的支持上，我们目前更多关注闲鱼侧业务较长使用的能力，由于扩展能力是我们的第一选择，因此在未来更多KUN使用的场景，我们会倾向于使用闲鱼内部的高性能自定义组件，这也意味着我们的这部分能力较薄。
• 高性能&多端一致性
通过Flutter引擎以及Flutter相关组件生态为整个渲染引擎提供高性能交付产物。底层的整体渲染基于FlutterWidget，保证了多端的一致性和容器复用。这部分的特性完全来源于Flutter的基础能力，这里不再赘述。唯一需要关注的是，当整个应用复用Flutter容器时，在内存水位和加载性能侧以及组件开发成本上来看，显著好于混合了多个容器如Flutter+Weex+WebView的性能。这部分的优势完全来自于整个App架构的简洁。
为方便大家理解，这里也补充一张扩展组件的核心描述，可以看到更多时候我们会在产品链路上使用混合模式进行开发，保证关键细节的体验与原生一致，而在基础组件的描述上我们更倾向于直接使用W3C的标准。
KUN项目较好的打通了现有的前端生态和Flutter生态，并通过配套工具进一步减少开发的门槛，使得具备JS/TS/Dart开发能力的终端工程师有机会在闲鱼诞生，这类工程师可以在性能敏感型和动态性敏感型的不同场景下选择不同的技术实施方案做业务落地，使得终端岗位独立完成端侧需求这件事情得以成立。目前我们已在导购场景和我发布的等场景下完成了前期的技术落地。后续会针对复杂场景如闲鱼号等业务进行改造和落地，通过技术的革新为业务带来效能的变化，为用户带来更好的产品体验。未来的几个月，我们会针对目前产出的一些关键能力和部分技术细节做系列性的总结和分享，在完成大规模的业务验证和技术优化后，我们将面向社区进行开源。
五、 后记
写这篇文章的最后，写一点自己的碎碎念。
首先要表达一些对行业内同事和朋友的感谢，比如文中提到的MXFlutter，是较早进行Flutter侧动态化方案落地的开源项目，早在我自己做GMTC出品人时跟该项目负责人有所交流，在KUN的设计的前期调研中也有了解过MXFlutter的一些使用方式和落地情况。这里另外要感谢的是Kraken团队，KUN的整个项目落地过程中得到了Kraken团队较多的支持，在技术交流和讨论中也让KUN的定位和路径更明确，两个团队也做了大量的代码实现的讨论和交流，得益于Kraken的开放性，KUN在这个过程中站在巨人的肩膀上继续演进。
这里插播一个彩蛋，KUN的名字本身就是对Kraken项目的一个致敬，大家可以猜一猜原因。未来KUN也希望最终能青出于蓝而胜于蓝，并把代码回馈给社区，在前期的建设中我们会先以集团内部开源作为目标，并在未来面向社会开源，为行业技术生态建设提供一些力所能及的帮助。
另外想讲下我看到的行业差距和不足。在了解整个国外行业对我所定义的终端岗位的情况来看，硅谷的头部公司工程侧的人才结构已经发生了一些变化，工程侧的人才更多面向全栈和终端全栈的方向去走，原因是海外的工程基建能力更发达和完备，这也意味着海外的技术组织通过技术能力和组织岗位的重新整合，达到了更好的生产效率。
近几年国内也开始更加强调组织的持续演进和工程师素养的提升，比如提出了DevOps的概念，减少运维参与，在云原生的大环境下降低开发和运维门槛。提出了测试开发的概念，推进研发的自测和持续集成自动化能力的建设。提出卓越工程的概念，更加强调软件架构和研发基础设施的重要性。但这些变化始终是跟随硅谷的步伐。作为国内的头部的互联网企业的一员，我也希望国内的技术人能在不确定的大环境下练好内功，通过持续的自我革新来形成企业的技术壁垒，正视我们与国际互联网公司之间的技术和基建上的差异，先追平能力，再找到机会持续超越，真正能为技术创造新商业提供一些微小的帮助。
日拱一卒无有尽，功不唐捐终入海。未来星辰大海的道路上，闲鱼技术与你一起乘风破浪。
参考资料：
【1】2021年互联网行业挑战与机遇白皮书。
【2】北海，高性能Web渲染引擎，基于Flutter构建。
【3】MXFlutter是一套使用TypeScript/JavaScript来开发Flutter应用的框架。
