作者：闲鱼技能——吉丰

1、KUN的 布景/动机

即便现已到了2022年， 在面向复杂多变的用户端开发范畴，咱们仍然绕不开一个问题 ？咱们选择什么技能更习惯咱们的事务场景，不管是通用还是独特。 这回到一个问题的原点，每一种技能都有它的局限性（短板）。

单一技能的缺点

• • Native技能的局限性
  • • 虽然Native技能在用户体会上有肯定的天然优势，但在工程化，部署功率，敏捷上又有天然的短板。
  • • （1）工程化功率低
    • • 工程复杂度高，由于天然的把一切的事务集成在一个工程里，依靠复杂性，工程复杂度高
    • • 编译功率低，切环境，编译打包，功率低。 这明显影响实践的开发功率。
  • • （2）部署功率低
    • • 由有必要依靠用户的安装更新，生效周期长，导致实践迭代功率慢。
• • Web技能的局限性
  • • 虽然Web技能是当今最盛行的GUI技能，但受限于浏览器架构/烘托模型， 使其在体会上有天然的下风。特别是在强调 “图片/动画/视频控制、长列表容器、多Tab容器”等场景显得力不从心。
  • • 涉及底层根底才能，有必要依靠Native技能的增强。

更广义而言，这是C/S架构和B/S架构技能对比的缩影，历史上从以C/S架构为开始，到以B/S架构的大盛行。 而PC互联网年代后，Native技能和Web技能在移动互联网上的继续相爱相杀。

烟囱式多种技能并存的挑战

技能上的乌托邦，抱负的状况， 咱们期望日常的事务软件开发重视于事务自身的复杂度（比方前台而言重视与，中心重视于事务模型复杂度/展示复杂度/交互复杂度），而不是更多的重视于技能东西自身的复杂性。 但实践的状况却相反， 咱们往往考虑技能东西的问题，比方 什么场景下合适运用什么技能？ 什么时候运用 native技能， 什么时候运用web技能， 什么时候运用非web的跨端技能， 什么时候运用某些特定范畴的技能，跟着事务场景越来越多，越来越复杂，咱们的技能东西的数量也在不断的上升 。 每多添加一种技能东西，背面需求额定的投入， 1）怎么学习熟练掌握一种技能东西。 2）假如不断优化提升技能东西，使之在质量和功率上不断提升。 3）技能东西之间的耦合联系 使得复杂度进一步上升， 为了处理这部分复杂度所需求的额定的本钱。 4）安排功率的降低， 简略构成更多的开发瓶颈。

技能的分裂，对中小规划的技能团队的影响愈加明显，由于技能的分裂，愈加简略产生由于技能自身导致的人力瓶颈。

有没有一种技能，在功率、体会、通用性取得最大化的平衡。 乃至打破传统按技能栈粒度进行区分的职能鸿沟， 统一到普遍意义上的终端开发工程师职能上。

KUN是什么

image.png

KUN 是一个让开发者运用 Javascript，HTML，CSS进行开发，运用Flutter进行增强的跨端开发结构。

它最早的雏形是来自Kraken， 正如 鲲 这个姓名所内涵的：北冥（Kraken）有鱼，其名为鲲（Kun）。 Kraken将Flutter技能引进并使用于Web技能栈，而在和Kraken团队的沟通中吸取了很多的优异常识。 但咱们并不期望去做一个只是根据Flutter烘托带裁剪的Web浏览器。相反，咱们企图去完美交融Web生态和Flutter生态。 咱们期望在面向中小规划的大前端/大终端的安排中，找到一种 真实合适的， 长时间性的， 通用型 处理计划。 来处理 包含咱们闲鱼技能团队在内的，大前端/大终端 所面对的 前端用户体会低、客户端效能低、团队技能分裂、技能协作本钱高等一系列问题。

KUN 项目组是一个技能栈高度互补的团队，包含flutter、前端、native 多技能栈的要害专家开发者， 在这个进程中，缺少任何一方都将大幅度的降低所能达到的上限。

就像KUN Logo 所隐喻的，它既像一条大鱼又像一个猫身，它是敌对和统一的结合体。

2、KUN 的独特价值

已然现已有了React Native， WEEX2.0， Kraken等跨渠道开发结构，咱们为什么还需求 KUN ？

React Native 企图去混合和衔接 JS 生态和 OEM的GUI生态（Android生态 & iOS 生态）。但最大的问题在于其不同 OEM 生态之间天然的差异，去抹平它们之间的差异，是一件极具挑战的方针。 而放弃操作体系 GUI生态，企图去从头构建一套 独立完好的GUI 体系去对接 JS 生态，是一件十分有志向的方针。 它或许意味着在对齐W3C规范上的更高的上限，但相同这个方向上，挑战重重。

KUN站在伟人的膀子上，做出独特的价值 – 敞开性

image.png

（1）KUN 从一开始就不企图去达到齐备的W3C的规范。

• • 承受达到W3C规范（包含 html标签标识，CSS款式规范，WebAPI规范）的必要的子集对咱们而言充分的。 咱们在一开始就对咱们的方针做取舍和准确的界说。

（2）KUN 根据Flutter GUI 体系和其生态，以极低的扩展本钱，向上层JS运转时供给很多丰厚的扩展标签/组件。

• • KUN 不企图去构建全新独立的GUI体系， 也不去企图抹平多个操作体系GUI之间的差异。 最大程度结合JS 技能/生态和Flutter 技能/生态，取长补短，优势互补。

KUN 的敞开性 是 KUN 最明显的特征。 经过愈加敞开和轻量化的容器规划和完结。 KUN 企图经过愈加敞开性的架构规划，去混合统筹 JS & Flutter。 敞开性， 技能上意味着

  - 有更广泛的通用性  - 更大的生态/社区的支撑  - 有更敏捷的响应性  - 有更长时间的成长性

结合闲鱼技能在flutter技能范畴的天然优势，去混合衔接 JS 生态 & Flutter 生态，经过愈加敞开 & 愈加轻量化的规划，在功率，体会， 通用性上去取的最佳平衡。

根据将Flutter生态融入到Web生态中，同时高度的开发性，有着愈加广泛的通用性，使得从技能和安排的各种为政，从烟囱式的多技能栈，有时机向分层的技能交融改变，走向技能统一，最终进一步到安排交融成为或许。不再按细粒度的技能栈区分职能岗位，而是统一为职能更大类的终端开发工程师或许开发工程师改变。

这尤其在中小规划的技能团队安排中，产生愈加明显的价值。

当然就这一交融方针的达到，需求考虑至少三个因素： 1、技能计划能不能行 2、安排内同学愿不愿意 3、外部环境趋势是否契合

3、KUN 的技能计划和面对的挑战

image.png

KUN项目第一言语是Dart言语，也包含少量的TS（担任WebAPI声明） & C++（担任跨言语通讯）代码，以及很少的Java & OC代码（担任和操作体系相关）。

怎么完结 Written in JavaScript、Html、CSS， Rendered with Flutter.

首要咱们需求设定一个咱们要完结的方针的鸿沟。没有鸿沟的方针是虚无的。咱们清晰，不需求完结一切的W3C规范，即便在未来也没有这一方面的企图。 所以咱们在 KUN 容器诞生进程中，除了全体参照阿里巴巴集团现有的跨渠道规范外，同时考虑适用性、可测性、易开发、易遵从等原则。

1. 适用。适用于闲鱼事务，满足闲鱼大前端绝大部分事务需求；适用于移动端，摒除非移动端视角，彻底适用于移动端开发的容器规范；2. 可测。规范界说包含完好的功能鸿沟，可根据规范测试用例保证单测。3. 易敞开。未来非闲鱼 App 可快速接入契合规范的容器；大前端同学可快速上手，存量事务可快速迁移。4. 易遵从。界说出清晰、合理的优先级，容器可按照优先级阶段性完结最契合大前端事务的 一、二、三环。

假如从零开始完结这项作业，那无疑是十分艰巨又漫长的。好在咱们能够站在伟人的膀子上。经过借用很多的优异的开源根底库/项目来帮助完美更快更好的完结这一方针。

• • 运用 开源QuickJS 处理JS 运转时问题。
• • 运用 开源YOGA 库， 处理运用CSS布局问题。
• • 运用 开源Kraken部分源码 和 CSSLib库 完结CSS款式的界说/解析/核算以及选择器才能。
• • 复用 Flutter已有的Widget和API，进行灵活的组合，处理CSS 烘托问题。
• • 运用 CDP 协议，去处理开发者体会问题。
• • 运用 Flutter golden test 处理测试用例的功率问题。

虽然以上并不处理一切问题，但现已掩盖很多了，给咱们更大的空间去处理其他更重视的问题点。

关于 CSS款式 的制作：

怎么运用已有的Flutter组件和API的组合，来完结对CSS款式烘托和事情的支撑才能

• • 典型代码举例：

• •

  

  image.png

• • 补白：其间恣意的一小段函数，比方 添加Appear/Disappear事情

• •

  

  image.png

制作 CSS款式 的复杂度远小于去完结 CSS款式的布局的复杂度。 运用Flutter已有的Widget和API去使得咱们避免侵入到Flutter Render-Object层去做十分繁重的作业。同时咱们有必要供认，在恣意阶段，咱们对W3C的规范对齐是不完善的，所以需求咱们不断经过更小粒度的组合去逐步完善。而某种意义上，咱们发现Flutter技能和Web技能的很深根由的部分，这使得咱们完结这件作业变得简略。

关于布局：

• • CSS 款式布局
  • • 根据 yoga & FFI， 咱们能快速完结必要的根本子集。
• • Flutter 扩展标签布局
  • • 并不需求额定的规划和处理，走原生Flutter Layout。
• • 混合鸿沟和约束处理
  • • 在 规范html标签 和 Flutter 扩展标签 的彼此嵌套中（能够嵌套的十分深），咱们需求界说它们的布局鸿沟和上下级之间的巨细约束联系。

一种简化的脱离文档流和层叠款式完结

• • developer.mozilla.org/zh-CN/docs/…

image.png

补白：KUN的DOM-Tree/Layout-Tree/Render-Tree 本质上是三组不同的指针构成的三棵树，而其Element是同一份。当DOM-Tree首Driver驱动发生改变时，Layout-Tree和Render-Tree 会同时发生改变。

关于更新机制：

• • 更新首要包含两个动作：标脏、改写
• • 标脏：
  • • 根据以JS驱动的主动改变的标脏
  • • 根据以Flutter驱动的被迫改变的标脏
  • • 根据运转时Widget构建的主动依靠搜集的标脏
• • 根据标脏后的最小化改写机制
  • • 最小化必要的yoga layout的从头核算
  • • 很好地借用了Flutter已有的改写机制，只要真实参与布局/制作/事情有改变的Widget才会从头构建，触发最小化的改写。

怎么完结 ，简直零本钱的扩展

KUN 企图经过规划强壮的敞开体系， 将Flutter生态完好的供给给JS生态。

除了在架构分层上，明显的将微内核和敞开层做了明晰的鸿沟区分，在详细组件的开发性上做了很多详细的规划和取舍。

详细有几点： 1、在KUN的标签/组件体系里， 一个自界说标签和一个规范html标签是相等的。 它们都对应一个或一组flutter-widget， 它们都是扩展的组成部分。 2、自界说标签 和 规范html标签 之间的彼此嵌套、约束联系，也是敞开标签/组件体系的组成部分。 3、一个规范的html标签不是一个复合的巨型 flutter-widget。 它是由一系列可组合的flutter-widget构成。 原因是对W3C规范的完结，是一个进程，更细粒度的组合联系，有利于不断引进Flutter生态已有的部分，更高效的迭代演进。 4、引进一个自界说标签/组件，应该简直是0本钱的。 包含标签/组件的内部完结自身，以及去组合通用才能（比方style烘托，常用事情等），应该快速0本钱的完结。

而根据丰厚的Flutter组件生态， 和极低的扩展本钱，极好的弥补了Web技能的天然缺点。

四个过程扩展并运用一个组件

• • 创立组件
• • 注册标签
• • 生成文档
• • JS运用

以一个简略的图片组件为例： （1）新建flutter组件 能够创立一个flutter组件，或引进一个已有的flutter组件。

image.png

（2）经过统一扩展接口KunDefs，注册标签

image.png

补白 >> 是一种才能组合方式， 用于让自界说标签快速取得额定的才能，比方通用的style的款式烘托才能或点击事情才能。

image.png

image.png

（3）在组件上加上必要的注解，用于主动生成组件文档和组件的TS界说（d.ts） 主动化完结，文档的更新发布 & 组件TS界说 npm 发布。

image.png

（*）可选的一码多端 在W3C规范上KUN容器是Web容器的一个子集， 在自界说标签上KUN容器是Web容器的一个超集。 一码多端是前端 为了适配 KUN容器和Web容器之间的差异，（想象一下历史上为不同浏览器做的兼容处理），但要简略得多，首要担任了怎么将KUN容器上的增强标签能够降低到H5版本。可选。

（4）前端工程导入 d.ts 界说后，能够像React组件一样运用，带Lint检查和代码提示。

image.png

补白, 恣意内置才能以相同的api进行扩展

image.png

怎么完结 更好的面向更广泛的 Web开发者 和 Flutter开发者的体会

面向Web开发者

• • 运转时面向规范Web-API 规划和完结

image.png

在这一层的规范上，咱们高度学习了Kraken的理念，面向WebAPI规划而不是绑定详细一个前端结构。

对不同言语的责备做了清晰的界说和区分： （1）Typescript 用于对WebAPI的声明部分； （2）C++ 用于跨言语通讯的部分； （3）Dart 用于对接动态库的驱动的部分以及详细的KUN完结部分； 所以（1）（2）十分薄。

• • 工程链路复用前端工程化
• • DevTools 对齐 Chrome DevTools

根据 Chrome DevTools Protocol ， 对齐常用的日志检查/元素审查/盒模型检查/CSS调试/款式锚点/特点检查/控制台输入输出/Source源文件和定位/网络/存储/事情联动等

image.png

而根据FlutterForWeb技能，未来有时机将KUN开发调试环境集成进浏览器环境。

面向Flutter开发者

• • 原生的flutter开发环境

  • • 运转KUN只需求最简略的flutter开发环境就够了， 它的依靠十分少。

• • 极简的playground

  4、KUN的发展和规划

  KUN 目前支撑 超越100 个 Web-API（包含DOM-API & BOM-API）

  • • 超越 30 种 html 标签。
    • • 掩盖 文档节点/文档元信息节点/片段节点/内容组/语义内容组标签/语义文本标签/嵌入式内容/脚本等
  • • 超越 30 种自界说敞开组件/标签。掩盖内容/容器/动画/输入等
  • • 支撑超越100个特点界说的CSS款式，掩盖
    • • 掩盖布局/盒模型/字体、文本/颜色、布景/边框、圆角/变形、过渡/动画/效果处理（滤镜、遮罩等）/@规则支撑/层叠上下文 等特点。
    • • 掩盖包含肯定单位/相对单位等15种单位，和包含继承等在内的5种值特点.
    • • 掩盖至少3种根底选择器。
    • • 较好支撑 层叠上下文
  • • 支撑63个BOM-API，掩盖定时/跳转/URL/环境/Location/屏幕/存储/日志等
  • • 并为此建立了超越1100个test-cases的高效的主动化测试体系。
    • • 根据flutter golden test，5分钟内完结像素级截图对比。
    • • 微内核和扩展，行掩盖别离超越80%和70%。

KUN的事务发展介绍 根据极强的事务需求驱动，KUN 现已在闲鱼导购场景/根底链路场景， 灰度或现已全量。 以闲鱼典型的“我发布的”页面为例：

image.png

经过技能晋级从H5晋级到KUN， 降价交互组件体会晋级，明显大幅提升了事务的要点目标。

后续包含新版闲鱼号等中心根底链路和双11中心互动场景都将根据KUN落地。

KUN的规划

这个项目的从最初是一个带有一点验证性的项目， 但跟着项目逐步在事务中的落地使用， 它让咱们的抱负变得愈加触手可及。一种技能合适闲鱼前端&客户端，掩盖全事务域场景。

2022 Q4 Roadmap ，会要点重视一下几个方面： 1、支撑包含双11在内的更多的要点事务； 2、更多维的功能优化； 3、根据KUN的组件库建造； 4、开发者体会； 5、CI & Test & Document 的持续建造；

最终， 假如你会Web使用开发，你能够经过KUN创立一个原生功能的移动使用程序。 假如你会Flutter使用开发，你能够经过KUN创立一个动态化的移动使用程序。 假如你的团队同时会Web使用开发和Flutter使用开发，你能够经过KUN，运用Web技能开发，Flutter技能增强你的移动使用程序。 结合Web技能和Flutter技能各自的优势互补，以及它们背面杰出的生态和社区支撑，你有时机运用一种技能来来掩盖你的一切上层事务。 KUN是一个新物种，有时机去完结这一点。