大厂自研跨端框架技术揭秘
内容提要
文章梳理跨端框架的四大技术方向：WebView增强、DSL Native增强、代码共享（KMM）与GPL Native增强，并重点剖析自绘方案。Kun借助QuickJS将JS译为Flutter Widget，但存在两次Layout与FFI瓶颈；WebF在Dart层实现CSS、C++层实现WebAPI，更贴合W3C标准；Weex 2.0采用全链路C++与自研Unicorn渲染引擎；Waft基于WebAssembly与Skia，面向AIoT。技术要点涵盖脚本引擎选型、渲染引擎、调试器与工程化，强调标准对齐、文档与开发体验。
延伸解读
CSS 实现路径决定框架性能与维护成本
文章对比了 Kun 与 WebF 处理 CSS 的两种思路。Kun 通过 Dart FFI 将样式从 JS 侧传给 Dart 侧，再用 Widget 层层拼接实现样式，导致一条渲染链路出现两次 Layout，且样式更新数据量大时触及 FFI 瓶颈。WebF 则在 Dart 层实现 CSS，样式更新依靠 RenderObject 的 Layout，无需走 FFI。作者认为把 RenderObject 做厚、由样式表驱动渲染，比做薄后层层组合更易维护，因此更看好 WebF 的方案。
脚本引擎选型需权衡 JIT 与包体积
文章指出 QuickJS 被多个框架选用，胜在体积极小、性能优秀，但存在没有 JIT、手动 GC、缺失行号记录与 Debugger、缺少 code cache 和 inline cache 等问题。若选择双引擎，Android 可用 V8，iOS 用 JSCore 无包增量，但 JSCore 无法开启 JIT。作者还质疑 Waft 的引擎对比图：fib 用例太简单、AOT 对比解释执行不公平、QuickJS 未用优化版本、未对比 V8 和 JSCore 等有 JIT 的引擎。
自绘框架的常见短板与应对思路
文章总结自绘框架常遇问题：开发体验差需提供 JS Runtime、Debugger 和 IDE 语言服务；CSS 能力不够需对齐标准，若在 Dart 侧实现 CSS 则要把 RenderObject 做厚；样式与 H5 不一致需堆测试用例并配合 WPT 验证；双端不一致可基于 Flutter 利用已有资源；生态不足需对齐 W3C 标准。作者提炼的经验是标准至上、提供丰富文档、少自研并合理利用已有资源、重视开发体验和低端机表现。
Q&A
跨端框架有哪几种主要技术方向？
文章总结了四种技术方向：1）基于WebView的增强，如Ionic、Cordova等Hybrid框架；2）基于DSL的Native增强，如DinamicX、MTFlexbox；3）代码共享，如KMM；4）基于GPL的Native增强，包括原生渲染组件（React Native等）、自绘引擎（Flutter）以及基于Flutter或系统图形库的自绘框架。
Kun框架是如何实现跨端渲染的？有什么性能问题？
Kun基于Flutter开发JS Runtime，使用QuickJS（或QKing）作为脚本引擎，将JS源码翻译成Flutter Widget，再交给Flutter Engine渲染。其CSS处理先通过Yoga做polyfill，再挪用Kraken的CSSLib，通过Dart FFI传递样式。问题在于：一条渲染链路存在两次Layout，带来额外性能开销；Dart FFI不足以支撑样式更新的信息传递，会触及瓶颈；内联样式开发体验不好。
WebF和Kun在CSS实现上有什么不同？为什么说WebF方案更好？
Kun在Dart侧通过Widget拼接实现样式，存在两次Layout和FFI瓶颈；WebF则在Dart层实现CSS，C++层实现WebAPI，更贴合W3C标准。WebF将RenderObject做厚，集成大量布局渲染能力，上层通过样式表驱动渲染，避免了Kun层层嵌套的复杂度，因此被认为是更好的方案。
Weex 2.0的架构有哪些核心组件？相比1.0解决了什么问题？
Weex 2.0核心组件包括：WeexAbility（容器和能力扩展）、WeexFramework（通用基础框架，实现DOM、CSSOM、WebAPI标准）、QKing（基于QuickJS的脚本引擎）、Unicorn（自绘渲染引擎，实现完整渲染管线）、WeexUIKit（原生UI渲染引擎）。它全链路使用C++开发，解决了1.0的跨语言通信问题、双端渲染差异问题、布局算法问题和脚本执行效率问题。
Waft框架的应用场景和主要限制是什么？
Waft是天猫精灵团队基于WebAssembly Runtime和Skia开发的自绘框架，主要面向AIoT场景。其限制包括：CSS仅支持部分子集，W3C标准（DOM Element、WebAPI）实现欠缺，包体积可能偏大，因此目前只能支持简单的IoT页面。
自绘跨端框架在脚本引擎选型上有哪些常见方案？QuickJS有什么优缺点？
脚本引擎选型包括：JS引擎（如双引擎V8+JSCore、Hermes、QuickJS、自研）、Dart VM、WARM。QuickJS的优点是体积极小、性能优秀；缺点包括没有JIT、手动GC难以管理、缺失行号记录、缺失Debugger、缺少code cache和inline cache、缺少内存泄露检测能力、Bytecode有优化空间。
自绘跨端框架常遇到哪些问题？有哪些解题思路？
常见问题与思路：开发体验差→提供JS Runtime、Debugger和IDE语言服务；文档不好→写好文档；CSS能力不够→对齐标准，Dart侧实现CSS时把RenderObject做厚；样式与H5不一致→堆测试用例并用WPT验证；双端不一致→利用Flutter组件；生态少→对齐W3C标准；JS性能差→自研JS引擎；不够标准→对齐W3C标准。
