NVIDIA 初创加速计划,免费加速您的创业启动 了解详情
写点什么

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

  • 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:512473

评论

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

阿里云手机正式公测,定义手机全新接入方式

阿里云弹性计算

阿里云 弹性云手机

圆桌对话:云时代下,企业运维面临的挑战与机遇

阿里云弹性计算

运维峰会 圆桌对话

失去了SDK,云计算将会怎样?

亚马逊云科技 (Amazon Web Services)

计算

透析阿里云视频云「低代码音视频工厂」之能量引擎——vPaaS视频原生应用开发平台

阿里云视频云

云计算 阿里云 音视频 低代买

物联网场景中灵活实施对设备的控制管理

亚马逊云科技 (Amazon Web Services)

首届LoongArch生态创新大会成功召开,筑巢引凤共建信息产业命运共同体

OpenAnolis小助手

开源 芯片 白皮书

Flink 实践教程-进阶(6):CEP 复杂事件处理

腾讯云大数据

流计算 Oceanus

转换匹配患者记录,看Amazon Lake Formation FindMatches显神通!

亚马逊云科技 (Amazon Web Services)

analytics

openGauss数据库源码解析系列文章——存储引擎源码解析(五)

openGauss

呼叫医生云! Amazon HealthLake 现已正式上线

亚马逊云科技 (Amazon Web Services)

AI ML

如何使团队的git log更优雅

阿呆

#GitLab

使用Amazon Redshift Simple Replay实用程序简化Amazon Redshift RA3迁移评估

亚马逊云科技 (Amazon Web Services)

mad

模块9作业

Asha

专注于最有价值的事情!——亚马逊云科技首席科学家工作心得分享

亚马逊云科技 (Amazon Web Services)

Date

腾讯云原生实时数仓建设实践

腾讯云大数据

flink window 流计算 Oceanus

腾讯云 AI 视觉产品基于流计算 Oceanus(Flink)的计费数据去重尝试

腾讯云大数据

AI flink window

百度APP浏览内核资源加载优化实践 -- ResourceScheduler 调优机制

百度开发者中心

百度app

低代码实现探索(十六)业务勾连复杂验证器

零道云-混合式低代码平台

恒源云(GPUSHARE)_语音识别与语义处理领域之低资源机器翻译综述

恒源云

机器翻译 语音识别

Linux之df命令

入门小站

Linux

只需5步!在轻量应用服务器部署Hexo博客

阿里云弹性计算

Hexo 轻量征文 用户投稿

数云运维总监陈延宗:基于阿里云计算巢,数云CRM一键云上交付

阿里云弹性计算

弹性计算 年度峰会 计算巢

边缘网络 eBPF 超能力:eBPF map 原理与性能解析

火山引擎边缘云

Mycat 作为代理服务端的小知识点

CRMEB

VuePress 博客优化之开启 Gzip 压缩

冴羽

nginx 前端 后端 博客 vuepress

Mysql索引

zdd

MySQL

代码审计思路之PHP代码审计

网络安全学海

网络安全 信息安全 渗透测试 安全漏洞 代码审计

工业生产中的“主动刹车”,是怎么实现的?

脑极体

2021年12月券商App行情刷新及交易体验评测报告

博睿数据

吐槽一下网站

你?

在线常用crontab表达式大全验证解析

入门小站

工具

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