有幸全程参与IMWeb Conf 2018的Native跨端融合议题，近几年来由于移动Web的高速发展，它的简单灵活性使得越来越多的跨端融合方案不断涌现，尤其是小程序等各种端平台的出现，使得跨端融合诉求进一步提高，在当下跨端融合绝对是非常值得探讨的一个话题。会场以三个主流框架层面的分享引入话题讨论，本文总结会议主要内容，加以自己的思考，希望能够抛砖引玉，引发思考。
跨端融合
“一次编写，到处运行”(Write once, run anywhere, WORA)，最早是Sun公司在跨平台方面的宣传口号，也代表着我们作为开发人员对于效率的极致追求。近几年随着移动互联网的快速发展，移动终端设备的软硬件、操作系统、开发工具链和技术社区等日趋成熟完善，在前端也涌现出各种跨平台的开发方案。
会场主题
Weex内核的原理和演进方向
第一场分享是由阿里巴巴技术专家张翰、申远带来的有关Weex的分享，在分享中，张翰介绍了Weex的基本情况、内部结构、分析比较，申远讲述了Weex in 2018及相关特性。
Weex目前已在“阿里系”应用以及社区内得到广泛应用，常规业务、双十一/大促、高性能场景都有着生产环境的实践。同时搭配了一系列的配套设施，如EMACS、weex-ui、达芬奇等。
Weex整体结构设计分为Vue、JS Framework、Weex Core和Render Engine四个部分，由JS FrameWork与Weex DOM API对接，并通过Bridge API与Weex Core通信，Weex Core对Native进行底层调用。
如我们所知，在移动端出现的各种方案中，越接近原生开发的性能越好，越接近Web的开发成本越低，weex前期是比较贴近于Web的开发体验，因此和Web的开发曲线十分类似，到后来贴近原生开发的体验，中间会经历一个拐点，张翰认为这个拐点在于前端和客户端的有效结合，需要客户端为前端赋能，当前端需要客户端时，客户端可以提供相应的基础设施，过度到原生开发的性能体验。
接着申远讲述了WeexCore的架构升级，以及渲染架构2.0的情况，主要针对Layout性能进行了相关优化，对Timer进行了升级，针对首屏渲染情况进行了特别优化，可以看到优化后在速度性能、内存占用方面的明显效果。
最后申远也提到，Weex Render是基于skia的，抛开客户端原生view的限制，可以换来性能上的提升，最重要的是，可以实现复杂的CSS效果，基于此，weex也扩展了140多种CSS样式能力。
Hippy 框架设计与优化
第二场分享由腾讯高级工程师赵宏罡、盛波带来的有关Hippy的分享，从前端和终端的角度介绍了Hippy的诞生，相比RN的逐条改进优化策略，使用场景以及将来的规划等等。
Hippy作为腾讯的一款跨端框架，融合了前端和终端实现的优点，具有体验好、开发效率高等优势。Hippy的初衷是为了解决RN所带来的一系列问题。
Hippy总体架构设计分为组件层、Render解析、前端核心、C++和终端层5个部分，组件层封装了许多实用的上层组件，Render解析层支持React和Vue的核心解析渲染逻辑，前端核心层定义了通信模块、日志、ui管理等等核心模块，通过Bridge与终端通信，终端通过定制的V8和JS Core进行解析渲染。另外，Hippy提供了完善的发布管理系统，直接对接终端的sdk包，具有增量发布等功能，有效解决RN包太大的问题。
Hippy在上层支持React、Vue的语法，在Render层解析jsx或Vue Template，统一对应到Hippy的DOM API，再通过Bridge与底层通信。这与浏览器本身的DOM API设计思路也非常的相似。
Hippy相比RN在诸多方面都有优化，手势方面，Hippy改善了终端向前端持续发送手势事件的行为，解决了前终端通道被大量占用的问题；通信方面，Hippy去除了RN LastFlush的缓存；动画方面，Hippy使用AnimateConfig使得动画一步到位，性能得到显著提高。
针对ListView，Hippy也做了UI复用，防止List数据过多时带来的内存损耗。同时，Hippy也针对启动速度、两端的API设计、稳定性做了不少的优化工作。
Hippy介绍到，它不仅仅是提供一个库，还提供一整套解决服务，包括打包管理系统、动态运营、隔离灰度、ABTest、差量发布、强制更新、安全校验、流控等等，帮助更好的管理发布。
Hippy已经被腾讯内部不少业务广泛使用，在QQ浏览器的首屏已经切换到Hippy，在这个UI繁多、DAU达到千万级别的业务中经受住考验。
最后，Hippy也给出在实际业务中优化的一些建议，如裁剪包大小、扫描图片大小、第三方库检测、懒加载、AsyncStorage、关键路径优化等等。
多端开发统一框架 Taro 深度剖析
第三场分享由京东的高级工程师李伟涛带来关于Taro的分享，介绍了Taro的历史背景、设计思想、持续优化、开源探索以及未来规划等。
Taro本身作为多端统一框架，初衷是为了解决小程序开发中的各种痛点，快速开发小程序，之后能够根据一套代码适配到h5、RN等各端。
小程序在开发中会遇到代码组织复杂、规范不统一、字符串模板弱、依赖管理混乱、不能使用ES Next、开发方式落后等问题（部分问题已经在小程序更新版本中得以改善），于是Taro决定将React现代技术栈编写的代码，并通过编译的方式生成到不同平台，做到”一处编写，多端运行“。
Taro的总体思想是借助Babel的编译能力，经过词法语法等分析流程之后，对代码进行优化并根据不同平台进行转换，最终得到目标代码。
在编译过程中，会遇到许多难题，各平台的组件和API差异都比较大，因此Taro通过统一的组件和API层，通过bootstrap适配到各个平台。
Taro对JSX持续做较为丰富完善的支持，对小程序组件化方案做重构，使用更加直观好用的组件化形式组织代码，对于小程序的setState性能也按照React的异步方式做了优化，对TypeScript、React Native的转换做了进一步支持，百度/支付宝小程序也在支持中。
Taro是今年6月7日正式对外开源的，开源以来获取很多好评，对于issue的解决率也比较高，pr数量也不错，对React社区和小程序社区的一些知名框架都做了支持，同时也有一套较为好看的UI。
在未来规划中，Taro即将支持百度/支付宝小程序、快应用，提供更加便捷的测试调试方法，支持从原生小程序生成Taro代码，支持可视化的界面生成，都是一些值得期待的特性。
小结
跨端开发在前端领域探索已久，从PhoneGap时代开始，我们就希望移动应用既能拥有原生开发的性能体验，又能拥有Web开发的灵活性和敏捷性。在小程序与更多端的出现后，“一次编写，到处运行”成为了开发人员内心最强烈的渴望，RN、Weex、Hippy在不断平衡开发和性能中发展，Flutter选择牺牲一些开发体验追求较高的性能，Taro/mpVue等方案在小程序多端方面做出自己的探索，每个框架都有自己的出发点，但本质上的追求是多端能够更加统一，增强代码的可维护性，增强开发体验，增强性能体验。
很高兴能够在会议中看到Weex团队与W3C的交流，希望能够在多端方面制定些标准，在实际开发中少一些选择，多一些统一。同时也希望小程序团队能够更加开放的接纳社区意见，能够提供更好的开发体验，原生支持主流框架，而非依赖于其他手段曲线救国，解决好跨端开发体验的问题，前端才能更专注于思考自身。
(知乎相关问题：www.zhihu.com/question/29…)