IMWeb Conf2018 Native跨端融合总结

有幸全程参与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自己做为多端统一框架，初衷是为了解决小程序开发中的各类痛点，快速开发小程序，以后可以根据一套代码适配到h五、RN等各端。

小程序在开发中会遇到代码组织复杂、规范不统1、字符串模板弱、依赖管理混乱、不能使用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…)