跨平台开发框架的大旗,究竟谁能扛起来?

作者:方秋枋

阅读数:7975 2019 年 3 月 25 日

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

从早期的 PhoneGap,到后来的 React Native,再到现在的 Flutter,众多跨平台开发框架的应用实践,与原生技术展开了一场博弈。用户该如何在众多选择中,做好技术选型及落地实践?使用跨平台开发框架,应该注意哪些问题?对其通病有何应对方案?

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

另外,方秋枋老师也将在 QCon 全球软件开发大会(广州站) 分享题为《基于 C++ 构建微信客户端跨平台开发框架》的话题,感兴趣的同学也可以关注下。

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 会是跨平台开发框架非常好的一个选择。

方秋枋老师会在 QCon 全球软件开发大会(广州站)上带来《基于 C++ 构建微信客户端跨平台开发框架》的话题分享,感兴趣的同学可以来到现场交流。大会更有来自 BAT、京东、滴滴、网易等一线技术专家,共话微服务、大前端、人工智能、高可用高性能架构、DevOps…13+ 热门技术,探讨多业务场景下的技术落地与发展趋势。

收藏

评论

微博

发表评论

注册/登录 InfoQ 发表评论