接上篇：https://developer.aliyun.com/article/1225901?spm=a2c6h.13148508.setting.33.595d4f0eudDbz0
三、 KUN的技术方案和面临的挑战
KUN项目第一语言是Dart语言，也包含少量的TS（负责WebAPI声明）&C++（负责跨语言通信）代码，以及极少的Java&OC代码（负责和操作系统相关）。
1. 如何实现Written in JavaScript、Html、CSS，Rendered with Flutter。
首先我们需要设定一个我们要完成的目标的边界。没有边界的目标是虚无的。我们明确，不需要实现所有的W3C标准，即使在未来也没有这一方面的企图。所以我们在KUN容器诞生过程中，除了整体参照阿里巴巴集团现有的跨平台标准外，同时考虑适用性、可测性、易开发、易遵循等原则。
• 适用。适用于闲鱼业务，满足闲鱼大前端绝大部分业务需求；适用于移动端，摒除非移动端视角，完全适用于移动端开发的容器标准。
• 可测。标准定义包含完整的功能边界，可依据标准测试用例保障单测。
• 易开放。未来非闲鱼App可快速接入符合标准的容器；大前端同学可快速上手，存量业务可快速迁移。
• 易遵循。定义出明确、合理的优先级，容器可按照优先级阶段性实现最符合大前端业务的 一、二、三环。
如果从零开始完成这项工作，那无疑是非常艰巨又漫长的。好在我们可以站在巨人的肩膀上。通过借用大量的优秀的开源基础库/项目来帮忙完美更快更好的完成这一目标。
• 使用开源QuickJS解决JS运行时问题。
• 使用开源YOGA库，解决使用CSS布局问题。
• 使用开源Kraken部分源码和CSSLib库完成CSS样式的定义/解析/计算以及选择器能力。
• 复用Flutter已有的Widget和API，进行灵活的组合，解决CSS渲染问题。
• 使用CDP协议，去解决开发者体验问题。
• 使用Flutter golden test解决测试用例的效率问题。
尽管以上并不解决所有问题，但已经覆盖很多了，给我们更大的空间去解决其他更关注的问题点。
1) 关于CSS样式的绘制
如何使用已有的Flutter组件和API的组合，来完成对CSS样式渲染和事件的支持能力。典型代码举例：
备注：其中任意的一小段函数，比如 增加Appear/Disappear事件。
绘制CSS样式的复杂度远小于去实现CSS样式的布局的复杂度。使用Flutter已有的Widget和API去使得我们避免侵入到Flutter Render-Object层去做非常繁重的工作。同时我们必须承认，在任意阶段，我们对W3C的标准对齐是不完善的，所以需要我们不断通过更小粒度的组合去逐步完善。而某种意义上，我们发现Flutter技术和Web技术的很深渊源的部分，这使得我们完成这件工作变得简单。
2) 关于布局
a) CSS样式布局
基于yoga&FFI，我们能快速实现必要的基本子集。
b) Flutter扩展标签布局
并不需要额外的设计和处理，走原生Flutter Layout。
c) 混合边界和约束处理
在标准html标签和Flutter扩展标签的互相嵌套中（可以嵌套的非常深），我们需要定义它们的布局边界和上下级之间的大小约束关系。
一种简化的脱离文档流和层叠样式实现。
备注：KUN的DOM-Tree/Layout-Tree/Render-Tree本质上是三组不同的指针形成的三棵树，而其Element是同一份。当DOM-Tree首Driver驱动发生变化时，Layout-Tree和Render-Tree会同时发生变化。
3) 关于更新机制
a) 更新主要包含两个动作：标脏、刷新
b) 标脏
• 基于以JS驱动的主动变更的标脏。
• 基于以Flutter驱动的被动变更的标脏。
• 基于运行时Widget构建的自动依赖收集的标脏。
c) 基于标脏后的最小化刷新机制
• 最小化必要的yoga layout的重新计算。
• 很好地借用了Flutter已有的刷新机制，只有真实参与布局/绘制/事件有变化的Widget才会重新构建，触发最小化的刷新。
2. 如何实现，几乎零成本的扩展。
KUN试图通过设计强大的开放系统，将Flutter生态完整的提供给JS生态。
除了在架构分层上，显著的将微内核和开放层做了明晰的边界划分，在具体组件的开发性上做了很多具体的设计和取舍。
具体有几点：
• 在KUN的标签/组件系统里，一个自定义标签和一个标准html标签是平等的。它们都对应一个或一组flutter-widget，它们都是扩展的组成部分。
• 自定义标签和标准html标签之间的相互嵌套、约束关系，也是开放标签/组件系统的组成部分。
• 一个标准的html标签不是一个复合的巨型flutter-widget。它是由一系列可组合的flutter-widget构成。原因是对W3C标准的实现，是一个过程，更细粒度的组合关系，有利于不断引入Flutter生态已有的部分，更高效的迭代演进。
• 引入一个自定义标签/组件，应该几乎是0成本的。包括标签/组件的内部实现本身，以及去组合通用能力（比如style渲染，常用事件等），应该快速0成本的实现。
而基于丰富的Flutter组件生态，和极低的扩展成本，极好的弥补了Web技术的天然缺陷。
1) 四个步骤扩展并使用一个组件
• 创建组件
• 注册标签
• 生成文档
• JS使用
以一个简单的图片组件为例：
a) 新建flutter组件 可以创建一个flutter组件，或引入一个已有的flutter组件。
b) 通过统一扩展接口KunDefs，注册标签。
备注>>是一种能力组合方式，用于让自定义标签快速获得额外的能力，比如通用的style的样式渲染能力或点击事件能力。
c) 在组件上加上必要的注解，用于自动生成组件文档和组件的TS定义（d.ts）自动化完成，文档的更新发布&组件TS定义npm发布。
（*）可选的一码多端在W3C标准上KUN容器是Web容器的一个子集，在自定义标签上KUN容器是Web容器的一个超集。一码多端是前端为了适配KUN容器和Web容器之间的差异，（想象一下历史上为不同浏览器做的兼容处理），但要简单得多，主要负责了如何将KUN容器上的增强标签能够降低到H5版本。可选。
d) 前端工程导入d.ts定义后，可以像React组件一样使用，带Lint检查和代码提示。
备注，任意内置能力以相同的api进行扩展。
3. 如何实现更好的面向更广泛的Web开发者和Flutter开发者的体验。
1) 面向Web开发者
运行时面向标准Web-API设计和实现。
在这一层的标准上，我们高度借鉴了Kraken的理念，面向WebAPI设计而不是绑定具体一个前端框架。
对不同语言的指责做了明确的定义和划分：
a) Typescript用于对WebAPI的声明部分。
b) C++用于跨语言通信的部分。
c) Dart用于对接动态库的驱动的部分以及具体的KUN实现部分。
所以（a）（b）非常薄。
• 工程链路复用前端工程化
• DevTools 对齐 Chrome DevTools
基于Chrome DevTools Protocol，对齐常用的日志查看/元素审查/盒模型查看/CSS调试/样式锚点/属性查看/控制台输入输出/Source源文件和定位/网络/存储/事件联动等。
而基于FlutterForWeb技术，未来有机会将KUN开发调试环境集成进浏览器环境。
2) 面向Flutter开发者
a) 原生的flutter开发环境
运行KUN只需要最简单的flutter开发环境就够了，它的依赖非常少。
b) 极简的playground
接下篇：https://developer.aliyun.com/article/1225894?groupCode=idlefish
