TaroWeexHippy 齐聚 IMWebConf 2018！

Posted 2021-04-29 腾讯NEXT学位

Write once, Run anywhere. 一次编写，到处运行。

这句程序员圈子里十分著名的话，也许你早已听过。事实上，这是 JAVA 语言的 slogan，诞生于 1991 年。语言与平台，天生有着鸿沟，想要逾越，是当时美好的愿景；但如何逾越，确实是一个难题。

虽然几代的程序员，前赴后继地为这个梦想而努力，但遗憾的是，到 2018 年的今天，世界上还没有一个完美的方案。反而，因为程序在不同虚拟机或系统上执行的差别，很难确保正确性和稳定性，甚至造成了一个坊间笑话：

Write Once, Debug Everywhere. 一次编写，到处调试。

庆幸的是，玩笑的背后，我们从不缺少砥砺前行的开创者。

最近这两年，在移动端各种跨平台的开发方案如雨后春笋般涌现，一方面是因为，随着移动互联网的普及和快速发展，移动终端设备的软硬件、操作系统、开发工具链和技术社区等日趋成熟完善；另一方面，近几年传统 PC 端的技术、资源也逐步迁移到移动端上来，大家都想造轮子，然后一统天下。 特别是今年，随着微信小程序的流行，让本来 Web、ios、android 的三足鼎立之势，又加入了新的玩家。如何统筹兼顾，收归开发成本，跨端技术势在必行。

所以，“跨端融合”——这是每一个追求新技术的开发者的向往，同时也是守旧者的噩梦。

即将于10月14日在深圳举办的 IMWeb Conf 2018 中， 《Native 跨端融合分会场》将带你领略“天下大势，分久必合”前的腥风血雨。

本次腾讯 IMWeb 团队，邀请到了业内各大公司的著名前端布道者，围绕“跨端融合”这一主题，为您带来全新的核心理念、设计思路专场剖析。

主题有：

• 多端统一开发框架：Taro 深度剖析 - 李伟涛（京东）

• Hippy - 过亿量级动态运营解决方案介绍与应用 - 赵宏罡（腾讯）

• Hippy - 终端架构设计与核心优化 - 盛波（腾讯）

• Weex 内核的原理和演进方向 - 张翰、申远（阿里）

亲临现场，你将收获：

• 与前端大咖面对面交流

• 了解跨端技术的发展史和最新动态

• 深入挖掘跨端技术的原理

• 了解方案之间的异同

• 认知哪种方案最适合自己业务

10月14日，我们与你们不见不散！

技术大牛会前问答

IMWeb Conf 2018 是诚意满满的一次前端嘉年华。

为了让大家提前感受到大会的氛围，我们准备了干货满满的分会场提前问答。

采访的对象，是分别来自阿里与腾讯的赵宏罡与张翰两位前端技术专家，我们来看下他们对“跨端融合”的一些看法吧。

问题1： 最近有少量国外企业在放弃 RN，重新回到 native 开发，让业界对RN的信心有所动摇，那在技术选型的时候，是否有必要继续在 RN上面投入？新项目是否依然应该选择RN？

赵宏罡：技术选型没有“银弹”。没有一种技术方案可以完美的解决所有业务场景的所有问题。在 Airbnb 这类开发资源充足，且对动态化需求并不是那么强烈的业务场景，RN 的优势并不突出。因为一些坑选择放弃 RN 可以理解。

但是对于追求更高开发效率，以及对动态化运营需求很大的业务场景。RN 依然是一个不错的选择。因为原生 Native 开发，H5 开发各自都有很大的痛点。而 RN 这类大前端框架，通过结合二者的优势真正的抹平了这些痛点。只是目前的大前端框架都还不够完善，本身又引入了一些新的坑。 但是在我们长期的实践中，发现其实很多坑都是有解决方案的。腾讯的 Hippy 框架就是站在巨人的肩膀上，不断优化，让大前端框架成为“不坑”的选择。 因为大前端方向本身很好的解决了 Naitve 和 H5 原生的问题，而它自身的问题也是可以解的，所以我们有理由相信它就是移动开发的未来。

问题2： facebook 最近在重写 RN，是否意味着当前 facebook 也意识到了 RN 的部分性能问题；未来如果 RN 新的版本出来，且明显高于一些类似的框架，在协议允许的情况下，如何可以快速切回RN？

赵宏罡：其实RN的诞生并非考虑周全的系统架构下的产物。先诞生了 Android 版，之后才有了 iOS 版，而且也不是一个团队在统一维护。所以它的一些问题是可以预见的。仔细看过 RN 的代码也会发现，有些性能瓶颈，就是底层设计不合理带来的。从一直没有1.0版本的出现，也可以看出 Facebook 显然对 RN 的现状是不满意的。想要真正被大众接受，重构势在必行。

其实也很期待RN的重构版。他们重构声明里提到对前终端通信机制的重新设计还挺令人振奋。不过他们也说明了本次重构只是在底层“大刀阔斧”，对上层API是保持了兼容的。而腾讯的 Hippy 框架，也是在上层兼容了 RN 的API。这意味着，如果你用 Hippy 构建了应用，又想要切回 RN 的时候，业务层的工作量是非常小的，几乎0成本。

问题3 ：JSBridge是前端和 native 进行通讯的桥梁，多次频繁的调用，会导致整个渲染和通讯效率很低，所以对于渲染和动画，常见的优化方案是降低传输字节数，降低调用的频次；那除了这些常规的手段，还有那些深入的通用优化方案，可以进一步优化整个解决方案的性能？

赵宏罡：当前的经验还有2个：大部分 JSBridge 都是基于 JSON 来通信的。在设计协议时，应该尽量减少数据的层级。用平铺的方式是最好的。对于层级很深的情况，序列化和反序列化会更加耗时。

对于大前端框架自身而言，不一定非用 JSON。还可以设计更轻量的定制化通信协议。比如 Weex 有 wson，Hippy 有 hippy buffer。用描述式的协议设计让编解码更小更快。

还有更加面向未来的方式：

把尽量多的工作直接交由JS引擎来完成。比如 vdom 的 diff、排版，渲染计算等。在C层做更多的事情，JSBridge的负担自然就降下来了。这是也是腾讯的 Hippy 团队正在预研的方向。

问题4 ：很多大企业都推出了一套自己的解决方案，比如阿里的 weex，京东的 taro，腾讯有 hippy、plato，携程深度定制了 RN 等；业界有很多方案以供选择，选择困难症如何破？如果碰到不在持续维护和更新的技术方案，如何处理？

张翰：选择困难可能来自于对自身技术需求和对大厂开源框架能力没有精确的把握。解决好这两点应该就不会选择困难了。

第二个问题，如果从开源社区的角度看，任何一个开源项目的成功只依靠一家公司的力量是远远不够的，需要社区开发者和企业的共同参与才能带来持久生命力和繁荣。所以“不持续维护和更新”在我看来是个伪命题，个人更呼吁业界开发者和团队破除用户思维，真正参与到项目的建设中来，成为开源项目的贡献者，亲手赋予这个项目持久生命力，让自己的思路在开源项目里得到体现。

另外如果真的不想贡献开源又想要保证框架的稳定性和持续维护，那么也可以考虑购买大厂推出的移动研发商业服务产品（如阿里巴巴的 EMAS 产品线）。

问题5 ：大前端时代，无论是哪种框架；native都在和前端逐步融合。从最初的H5，到hybrid App，再到RN跨端融合，都是想让用户体验更好，所以很多组件都直接使用 native 组件进行渲染，但是又不缺失前端的灵活性；那从前端的角度来看，除了可以在构建打包，dom-diff，vdom处理外，还有哪些方面可以进一步挖掘前端的价值？

张翰：“向Native要性能”是我们持续在探索的一个重要方向，如用 binding 取代 bridge、TS 强类型等 JS 引擎层优化，vdom、dom-diff、布局能力 native 化，以及用直接绘制方式取代系统 UI 组件以增强特定场景性能表现等方案，均是可以挖掘的地方。

以上是前端专家们的部分精彩问答，如果你想了解更多问题，或者有疑问想进行面对面交流，一定不要错过参加 IMWeb Conf 2018 的机会！

参会信息

大会提供线下票和线上票两种票型。

线下票（现场）

购买现场票的观众将可以前往现场，获得与讲师近距离接触以及面对面提问的机会。

线上票（网络直播）

如果您无法到达现场，也可以购买线上票，通过网络直播观看所有演讲，会后也可以观看回放。

戳左下方阅读原文，点击即可购票！

其他信息

Conf 官网：https://2018.imweb.io/

会议时间：2018年10月14日（周日）

负责人微信：guofengmian

负责人邮箱：[e-mail]

 

戳下方阅读原文，点击即可购票！