阅读 1312

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本身作为多端统一框架,初衷是为了解决小程序开发中的各种痛点,快速开发小程序,之后能够根据一套代码适配到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…)

关注下面的标签,发现更多相似文章
评论