这是我参与「第五届青训营 」伴学笔记创作活动的第9天，纵观跨端技术的演进历程，从 Web 容器 ，到泛 Web 化容器，再到自渲染，技术方案一直都在快速变化，从一个方案迁移到另一个方案，其成本与二次开发相当。我们会有自己的方案去解决这个疑难问题。
- Web容器方案：
浏览器和 WebView 本来就都是 W3C 规范下的标准化 Web 容器，因此 Web 页面天生就能轻松投放到任意浏览器、WebView 之中。从开发成本、标准统一、生态繁荣上来说，Web 方案基本是不二之选；不过 Web 本身也存在一些问题，例如页面加载慢、内存消耗大、交互体验差。尽管在 Web 基础上又衍生出了 Hybrid、PWA、PHA 等一系列 Web 能力增强的方案，让性能和体验得到了非常不错的提升，但相对于 Native 性能和体验的劣势却仍然存在。
Web 的高效和动态性是 Native 开发难以企及的，Native 的性能和体验也是Web一直追求的，有没有一种两全齐美的方式让我们在两者之间找到一个平衡点？React Native 的出现给开发者带来了新的思路。 - 容器化 Native 方案：RN / Weex 为了弥补 Web 容器方案性能和体验上的不足，同时也能拥有 Web 的研发效率；类 RN 容器尽可能的取长补短，保留了 JS 引擎，以便最大程度的对接前端生态，提升开发效率；出于性能和体验上的考虑在渲染上则复用了 Native 的渲染管线，使用原生渲染保障了性能和体验；通过类似的容器方案即可实现跨端，主流的 RN、Weex 都是采用这种方案。 容器化 Native 方案看起来既能拥有 Native 的体验又能拥抱 Web 的繁荣生态非常完美，但它实际上还是存在问题：比如难以抹平的一致性、W3C标准支持不足、研发体验、周边生态缺失等。尽管如此容器化 Native 方案仍是成功的，它迅速拓展了前端的边界。
- 自渲染方案: Flutter Web 容器存在性能问题，Native 容器化存在一致性问题；那么是否可以绕开 Native 渲染管线自建渲染引擎，解决跨端一致性问题呢？答案是必然的，Flutter 基于 Skia 实现了一套自绘引擎；因此 Flutter 的特点是一致性高，性能好；但它也有着自身的缺点 由于设计上采用全新的思路，抛弃 JS 而使用 Dart 作为开发语言，所以不管对于 Native 研发还是前端研发都有一定的学习成本，不过站在开发者的角度来说学习成本并不是特别高，更大的问题是前端生态需要重建，工程相关的 CI、CD，生态相关的搭投、智能化都需要重新建设，成本巨大。 正是这样的原因，让不少前端开发者望而却步；那么自然而然的就有各种各样的探索；上层让 Flutter 更好的对接前端生态，底层使用 Flutter 自绘渲染保证多端的渲染一致性，这里我们就不再展开了。
- 适配小程序的一码多投跨 App方案： 小程序帮助头部 App 建立起封闭流量体系和容器管控的同时，也因其双线程模型及自建 DSL 引入带来了新的跨端问题。随着各大厂商纷纷实现自己的小程序容器、快应用，跨端容器的碎片化愈演愈烈。 其实现方案大致可分为两类：编译时与运行时。 编译时思路：在编译时将框架的业务代码转换为小程序原生 DSL；
