写点什么

阿里资深技术专家谈跨平台开发的发展趋势和变化

  • 2020-04-14
  • 本文字数:3896 字

    阅读完需:约 13 分钟

阿里资深技术专家谈跨平台开发的发展趋势和变化

随着移动互联网的发展,Android 和 iOS 呈两分天下之势,跨平台开发也逐渐成为移动领域的热门话题之一。怎么看待其背后的发展逻辑?跨平台开发的难点是什么?未来的发展方向如何?近日,InfoQ 有幸约到阿里巴巴淘系技术部资深无线技术专家黄刚(花名:腾渊),请他介绍跨平台开发的发展趋势和变化。


腾渊认为:从早期比较流行的 Hybrid App,到后来的 React Native、Weex,再到现在比较火爆的小程序和 Flutter,可以看到跨平台的发展趋势是框架变得越来越重。如果当前的业务情况下前台呈现比较不稳定并且整个前台开发占比较高,那么应用跨平台框架的收益就比较高了。到底哪个方向更正确、哪个框架更好其实是没有标准答案的,更多需要开发者因时制宜地选择。如果说跨平台解决的是个节约研发成本的问题,On-Device AI 的应用是真正会产生业务增量的技术新赛道。


他还会在即将召开的QCon全球软件开发大会 2020(北京站)上担任「移动新生态趋势下的应用实践」专题的出品人,感兴趣的读者可以关注。以下为黄刚(腾渊)的观点精华。

如何选择适合自己的跨平台开发框架?

在移动互联网时代,当 Android 和 iOS 奠定了整个移动 OS 的地位后,跨平台研发就一直是一个大的研究方向或者说大的课题。这个话题其实很有意思,因为很多时候大家会有些默认的假设,比较容易忽视这个方向出现或者变热的前提条件。


从 PC 时代开始,就有一些像 Qt 之类的非常优秀的跨平台软件研发框架。但是我们回过头来看,那个时候面向个人用户的跨平台研发很难说是一个非常热的方向,其中最主要的原因就在于 PC 时代 Windows 的绝对统治地位。假设今天我们在移动互联网上只有一个 OS 占绝对统治地位,那可能今天也不太会有业界同仁在研究跨平台研发这个事情了,这是一个大的前提。


在移动时代,在 Android、iOS 作为移动 OS 双巨头的格局下,天然就会带来一个重复开发导致移动应用开发成本增大的问题。要开发一个应用,服务端、前端都可以是一套班子,客户端基本需要 Android 和 iOS 两套开发班子,所以不难理解跨平台研发这个话题的起点在于降低研发成本。在这个基本问题下,往下衍生的问题就是多平台的开发增加的额外成本到底是多少,在整个研发生命周期中的占比是多少,跨平台的开发框架能多大程度上解决这个问题?只有这个问题回答清楚了,我们才能明确适合自己的跨平台开发框架应该具备哪些特征,这个跨平台框架在一个 App 应用中的使用范围是多大。


从早期比较流行的 Hybrid App 到后来的 React Native、Weex,再到现在比较火爆的小程序和 Flutter,可以看到跨平台研发框架变得越来越重。是不是一定越重、越新的框架越好?答案是不一定。


从应用的 Life Cycle 来看,研发阶段只是其中一个阶段,是否具有长久的可维护性、可运维性也是需要重点考虑的问题。再到研发阶段本身,整个研发是从前端到后端 End-to-End 的,跨平台更多地是集中在大前端领域内的话题,如果在当下的业务形态里,前台展现是高度产品化、比较稳定或者对于性能以及交互的要求极度苛刻的,那么 Cross-Platform First 未必是一个理想的选择。


一方面是多平台开发工作在整个研发成本里的占比不高,ROI 未必高;另一方面是 Cross-Platform First 是以牺牲平台特性为代价来达到跨平台的一致性(本质上跨平台研发框架也基本无法做到多平台上表现得完全一致性)。在达到一致性表现的过程中,工程上的填坑成本可能更高。


反过来讲,如果当前的业务情况下,前台的呈现比较不稳定并且整个前台开发占比较高,那么应用跨平台框架的收益就比较高了,在阿里比较典型的例子就是 Weex 在大促会场上的应用。


我们都应该理解,从 Hybrid 的方案到 React Native、Weex 再到 Flutter,本质上都是在研发成本、灵活性、性能体验三者间找一个平衡点,只是大家切入的点不太一样,最终导致整个解决方案有了不同。假设说现在你要做一个新的 App,可能整个开发团队是多前端、少客户端的,那么我可能会比较建议大家多考虑 Hybrid 的模式;如果对性能要求比较高,就可以考虑用用 Weex 或者 React Native;反过来,如果是客户端同学比较多,那么考虑下 Flutter 未尝不可。


其实我们也可以看到,像 Google 同时在推 Flutter 和 Kotlin,这两个东西本质是不一样的,Flutter 更多地体现 Cross-Platform,Kotlin 更多地体现 Platform First,到底哪个方向更正确,哪个框架更好,其实是没有标准答案的,更多需要开发者因时制宜地进行选择。

阿里各跨平台开发框架的发展及应用

当下阿里用的比较多的应该是 Weex、DinamicX 和小程序这几个框架,在不同场景下解决不同的核心问题。任何框架都不能脱离当时发展的背景讨论,这几个框架是因为在不同阶段解决了当时手淘的一些核心问题,所以才能在各条业务线上广泛应用。


我们从 2015 年开始做 Weex,2016 年大规模应用。当时我们大促会场页面从研发效率以及发布的灵活性考虑,统一使用的是 H5,但在当时,性能和体验都有些问题。同样,当时手淘上众多的导购业务因为很难接受 H5 的性能与体验,强烈要求使用 Native 做页面开发,这样就又带来了另外一个问题,即 App 的包大小的问题。Weex 在这个背景下诞生,在尽量保留 H5 研发效率以及部署灵活性的前提下,尽量提升页面的性能体验。


不难想象,在这种情况下,我们整个开发框架必然是面向前端、全面兼容 H5 的研发模式。当然其中 Vue 和 Rax 这样的前端框架也是功不可没的。因为 Weex 的出现,大幅度提高了当时会场页面的性能,而且满足了大部分导购频道对于性能的要求。导购业务在性能基础体验能够满足的情况下,其实很多导购业务还是倾向于更灵活的研发与部署模式,所以当时很多的导购业务还从 Native 转回到了 Weex 进行开发,间接帮助了手淘 App 包大小的控制。


我们从 2017 年开始做 DinamicX,2018 年大规模应用。这个框架的诞生就要顺着刚才的历史接着往下讲。Weex 解决了原先使用 H5 的业务的性能诉求,但是我们发现 Weex 在一些产品化程度很高的业务域内,依然不能满足性能要求,比如说首页这类一级 Tab 页,所以这种业务基本都还是保留了 Native 的开发模式。


虽然 Native 的开发模式被保留了下来,但是不意味着这些业务对于开发的平台一致性、研发效率、部署效率没有要求。为了解决这些问题,DinamicX 使用了类似于 Android layout 的声明式布局。相较于 Weex,DinamicX 并没有引入脚本引擎的能力,通过牺牲部分灵活性,来达到性能的极致。通过这样的方式,能够做到在性能基本和 Native 开发持平的情况下,比较灵活地调整页面布局,再通过和我们内部的新奥创研发平台的结合,实现页面布局与业务逻辑的分离。通过这样的方式,DinamicX 这个框架基本解决了我们在基础产品业务域内的研发效率以及性能体验的平衡问题。


再来讲讲小程序框架,现在我们更多地是使用在了商家应用场景上,核心是为了解决我们在集团多个 App 之间业务快速部署以及外部商家开发的页面快速入驻手淘并且能够得到有效管控的问题。小程序最近比较热,这个点上我就不展开了。


至于 Flutter,我们内部使用比较深入的是闲鱼的同学。对于跨平台领域的解决方案,我不太秉持只有一个正确答案的想法,对于终极解决方案这个结论我还是比较存疑的,但有一个需要探索的重要方向是可以确定的:决定一个跨平台解决方案的成败有两个重要因素,一个是技术产品化程度,或者说是工程化水平;另外一个是整个开发者生态的构建。如果从这两个因素来看的话,可以明确都还有一段很长的路要走。手淘今年也成立了专门的团队在研究 Flutter 的应用,我们可以拭目以待。

5G 时代给移动领域带来的新机会

5G 也是大家非常关注的热点,我们内部的讨论也会比较多。毫无疑问,5G 将能带来一些爆点场景,但是这方面的预测是相当困难的。现在市面上关于 AR/VR 和多媒体应用的畅想理论上都没有什么问题,但是从商业的角度来讲,我们还不知道整个变化对于成本方面的影响,而成本的考量对于应用场景是极其重要的。


我举个简单的例子,很多 App 在视频自动播放下都有一个设置选项,叫做“Wi-Fi 下自动播放”,绝大多数 App 在使用移动流量播放流媒体之前一般都会给用户弹一个提醒,“当前在用移动流量播放,可能会产生资费”。大家想一想,这个背后的本质是不是就是关于成本的考量。这个限制其实对于整个应用的场景影响是非常大的,正如 4G 的流量费用大幅降低让移动互联网走到了亿万用户手中,5G 的使用成本将极大影响它的使用场景。但是我们依然可以做一个大胆的预测,当 5G 帮助大家极大突破了网络传输速率的束缚后,后面紧接而来的可能是对终端设备算力大幅提升的诉求,最后才创造出一个个崭新的应用场景,这是一个从网络到终端设备到应用场景整体升级的过程。


我个人最近比较关注 On-Device AI 的应用实践,如果说跨平台解决的是节约研发成本的问题,On-Device AI 的应用是真正会产生业务增量的技术新赛道。过去的一年中,在 On-Device AI 上手淘有了比较大规模的应用,一个典型的场景就是信息流这个商品、内容等的混合智能推荐场景。我们通过更低的资源消耗、更多的数据输入、更实时的感知,在整个信息流场景导购侧有了非常大幅度的提升。过去一年的实践只是一个开端,我们齐头并进的应用场景还包括 AR 美妆、消息 Push、直播等等,这块的想象空间是非常大的。


作者介绍:


黄刚(腾渊) 阿里巴巴淘系技术部资深无线技术专家,现淘系技术部基础链路负责人,负责首页、商品详情、交易、信息流等核心业务。2014 年加入阿里巴巴,2018 年双十一淘宝技术部技术队长,2019 年淘系技术部技术队长。


更多前端前沿技术及工程化落地实践请关注 QCon北京2020,大会邀请多位技术大咖分享伴随业务形态转变、团队规模扩大和技术快速升级沉淀下来的经验和实践。点击了解详情。


2020-04-14 08:513375

评论

发布
暂无评论
发现更多内容

11个基于HTML/CSS/JS的情人节表白可爱小游戏、小动画

海拥(haiyong.site)

大前端 情人节 表白 2月月更

java培训:MyBatis高级进阶学习分享

@零度

mybatis JAVA开发

去吗?去啊!喜欢就不要再犹豫

码哥字节

爱情 2月春节不断更 情人节 情书 2月月更

手写一个线程池,带你学习ThreadPoolExecutor线程池实现原理

华为云开发者联盟

Java 线程 线程池 ThreadPoolExecutor

jQuery常用方法归纳总结

编程江湖

[C语言]打开C的大门

謓泽

入门 C语言 编程、 2月月更

警惕!Python 中少为人知的 10 个安全陷阱!

Python猫

Python

建木持续集成平台v2.2.2发布

Jianmu

DevOps CI/CD 自动化运维

Java最简单可靠的线上不停机发布方案

游牧

手写简易版 React 来彻底搞懂 fiber 架构

CRMEB

HiveSQL高级进阶10大技巧

编程江湖

分布式事务管理DTM:“买买买”背后的小帮手

华为云开发者联盟

微服务 电商 分布式事务管理 DTM 云图说

Go学习笔记——常量

为自己带盐

Go 学习笔记 2月月更

大数据存储领导厂商创新科加入,携手龙蜥社区共建开源生态

OpenAnolis小助手

大数据 Linux 开源 云存储

取代 Mybatis Generator,这款代码生成神器配置更简单,开发效率更高!

沉默王二

前端培训:React调度算法迭代过程

@零度

前端开发 React

大数据培训:Flink调度器性能的提高

@零度

flink 大数据开发

霜皮剥落紫龙鳞,下里巴人再谈数据库SQL优化,索引(一级/二级/聚簇/非聚簇)原理

刘悦的技术博客

sql 优化 SQL优化 MySQL优化 :MySQL 数据库

Mac 鼠标手势软件 -- MacStroke

TroyLiu

效率工具 推荐 Mac 鼠标手势 Mac 软件

mycat 中间件安装与使用

编程江湖

Redis 在 vivo 推送平台的应用与优化实践

vivo互联网技术

服务器 消息推送 redis'

第十一节:Springboot整合log4j2日志

入门小站

spring-boot

在线YAML转HTML工具

入门小站

工具

书单 | 作为冬奥会的技术支持方,阿里云的技术都写在这些书里了!

博文视点Broadview

Spring Cloud Alibaba Nacos路由策略之保护阈值!

王磊

spring cloud alibaba

朋友圈系统架构设计

Geek_8d5fe5

架构实战营

OceanBase 雄踞墨天轮2021年度中国数据库魔力象限领导者

OceanBase 数据库

魔力象限 OceanBase 开源 领导者

【网络安全】什么是应急响应,应急响应中你到底该关注哪些指标?

H

网络安全 应急响应

用户登录功能:说简单也困难

华为云开发者联盟

安全 cpu 加密算法 TPS 用户登录

在低代码开发时代,还需要IT部门吗?

TOBESOFT特碧软件

低代码 数字化 TOBESOFT

运维工程师的工作内容有哪些?能详细列举一下吗?

行云管家

云计算 运维 系统运维 IT运维

阿里资深技术专家谈跨平台开发的发展趋势和变化_移动_黄刚(腾渊)_InfoQ精选文章