跨平台开发框架的大旗

近年来，移动端上各种跨平台开发方案百花齐放，一方面是因为随着移动互联网的迅猛发展，纯原生开发无法满足业务快速增长的需求；另一方面，跨平台可以增加代码复用，降低开发成本。在移动终端设备的软硬件、操作系统、开发工具链和技术社区等日趋成熟的今天，众多开发者对“造轮子”跃跃欲试。

从早期的 PhoneGap，到后来的 React Native，再到现在的 Flutter，

众多跨平台开发框架的应用实践，与原生技术展开了一场博弈。

用户该如何在众多选择中，做好技术选型及落地实践？使用跨平台开发框架，应该注意哪些问题？对其通病有何应对方案？

InfoQ 记者带着这些问题，采访到了腾讯微信客户端工程师方秋枋老师。另有结合微信团队目前采用的跨平台方案分析，希望能对大家有所启发！

InfoQ：从早期的 PhoneGap，到后来的 React Native，再到现在的 Flutter，移动端跨平台开发框架一直是圈子里的热点。能否谈谈你对于跨平台开发框架的认识？这些年技术在不断迭代和演讲，你怎么看待他们背后的发展逻辑？

方秋枋：“Write once, run anywhere” 一直以来就是开发者的梦想。在移动客户端领域，主流的跨平台开发框架大体经历了三个阶段。

第一阶段，主要通过 WebView 绘制界面，并通过 JavaScript Bridge 将系统的一部分能力暴露给 JS 调用。PhoneGap、Cordova 都可以归属于这一类。

第二阶段，大家发现用 WebView 承载界面有性能等各种问题。于是将绘制交回给原生，通过 JS 来调用原生控件，编写业务代码。Weex、RN 就是其中的佼佼者，这也是现在绝大部分跨平台框架的思路。

第三阶段，虽然使用原生控件承载 UI 解决不少渲染的问题。但是处理平台差异性仍然需要耗费极大精力，效果也不尽如人意。这个时候，Flutter 提出的解决方案，就是连绘制引擎也自研，尽可能减少不同平台之间的差异性, 同时保持和原生开发一样的高性能。因此目前业界对 Flutter 的关注度也是最高的。

对于这样的发展路线， 个人认为根本原因还是 Web 标准和能力在移动客户端得不到很好的扩展与支持。实际上，Web 平台才是真正意义上的跨平台, 我们在所有主流操作系统上都能通过浏览器来访问相同的网页。目前第二，第三阶段方兴未艾，而 PWA、WebAssembly 等进一步增强 Web 能力的技术和标准并未成熟。 因此，在可预见的未来，移动端跨平台开发还是主要以当前的形式为主。但是，随着 Web 标准和能力的增强，最终绝大多数应用，只需要使用 Web 栈技术即可构建。

InfoQ：据了解，用户在选择跨平台开发框架时，比较看重其是否具备热更新的能力。但在 2017 年 3 月，苹果下发了警告邮件，禁止 JSPatch 等 iOS App 热更新方案，你如何看待“热更新”这件事？

方秋枋：前段时间围绕热更新， InfoQ 主编徐川已经写了一篇非常好的文章《移动开发的罗曼蒂克消亡史》。因此在这里就不再赘述。

目前 iOS 平台的热更新更多地是用于修复 Bug，而不是直接拿来进行业务需求的开发和更新。实际上对业务体验是无害的，但是也违反了苹果的规则。因此，大家目前在 iOS 平台基本只敢偷偷摸摸地做，没有新的开源项目公布。而安卓就百花齐放，有非常多的热更新框架可以选择。然而，安卓平台侧拥有了非常强的热更新能力，用户体验有变得更佳么？目前看来，好像还是没有的，因为安卓平台权限控制等相关问题的存在，反而厂家会利用漏洞来骚扰用户，获取隐私。

从用户角度来说，怎么真正利用好热更新能力来服务用户，提升应用体验，才是开发者真正需要考虑的问题。但是这也需要取舍。更开放的平台策略更允许热更新能力的存在，同时也会带来其他的一些问题。

从开发者角度，我希望平台能够允许和放开热更新技术。但从一个普通用户的角度，我更喜欢当前苹果的策略。

InfoQ：有人说，国外 App 开发偏重于“原生”，而国内 App 讲究的是“迭代”。你认同这句话吗？为什么？

方秋枋：我不太认同这句话。其实国内国外的应用，都在不断地迭代更新。只不过当下情况，国外 App 开发更倾向于使用原生技术进行开发，而国内则对跨平台的热更新能力非常关注。

InfoQ：2018 年，Airbnb 放弃使用 React Native，回归使用原生技术，究其原因主要是：项目庞大后，维护困难；第三方库良莠不齐；兼容上需要耗费更多精力……这是否是跨平台框架存在的通病？有什么解决办法？

方秋枋：这的确是跨平台框架存在的通病。 跨平台意味着需要花费很多时间来解决平台差异性问题，同时要面临第三方库不够原生平台丰富健壮的现状。跨平台其实是牺牲部分功能和体验，换取开发速度和一致性的权衡，并不是业务开发的银弹。

目前并没有一个能完善解决这些问题的解决方案。 Flutter 可能相对来说在兼容上会做得好一点，通过自底向上自研框架来尽可能减少平台差异，但是可靠性仍需进一步检验，引入 Flutter 需要大家对自己公司业务有非常清晰的认知，并权衡好利弊。

对于初创公司和普通开发者，我个人的建议是可以利用小程序来进行跨平台开发，把这些繁琐的兼容问题抛给小程序开发框架的开发者处理，这样就可以把更多精力放在业务开发，也省却了维护两个平台发版的工序。

InfoQ： 目前，微信团队采用的是哪种跨平台开发框架？基于哪种核心语言？是出于什么考虑选择这种语言的？聊一聊该框架的实现原理？

方秋枋：目前微信团队并没有统一使用一套跨平台开发框架。我们也在积极探索各种可能性。

微信小程序，是前面提到的第一阶段和第二阶段的融合做法，利用 Webview 作为渲染容器，通过规定 Web 技术栈的子集（WXML、WXSS），让客户端获得更多的渲染性能优化空间，同时通过规范化组件的使用，逐步引入原生控件代替 Webview 渲染。

除此之外，我们还探索了基于 C++ 进行跨平台开发。实质上还是第二阶段的做法，只不过是使用 C++ 作为中间语言，去编写业务代码和调用原生控件。为什么要采用 C++ 呢？ 因为 C++ 安全性会更高一点，同时性能也会更佳。可以应用在一些对安全性要求比较高的场景。 如果大家对基于 C++ 构建跨平台框架和业务开发有兴趣。可以关注一下 QCon 全球软件开发大会（广州站）， 我会更详细地阐述如何基于 C++ 构建跨平台开发框架。

InfoQ：你认为跨平台开发的难点是什么？Flutter 是如何解决这些问题的？你如何看待 Flutter 的发展？

方秋枋：从框架开发者的角度，我认为跨平台开发的难点就在于处理平台差异性。从框架使用者的角度，难点在于如果框架出问题了，维护成本将会变得非常高。

Flutter 通过自底向上自研框架来尽可能减少平台差异，同时将 Dart 语言， 渲染引擎等组成部件都进行完整开源，任何人都可以调试源码，当然维护门槛也是很高的。我认为如果谷歌愿意继续大力投入 Flutter 的开发，Flutter 会是跨平台开发框架非常好的一个选择。