前段时间,InfoQ发布了移动与IoT趋势报告2022年版本。在这篇文章中，我归纳了这份报告的最主要的观点，并做出我个人的解读。

由于我个人对移动端开发比较熟悉，IoT则完全没接触过，所以这份文章我只关注这份报告中关于移动开发的点。我个人也不认为移动开发与IoT有必要放在一起说，因为它们的开发人员大多数情况下并没有重叠性。

关键点

通过这份报告，关于移动开发趋势，我整理了下值得关注的点，分别是：

1. Hybrid跨平台开发已经进入衰退期
2. 原生开发仍然是主流
3. 移动端CI/CD以及批量设备自动化测试成为流行的移动开发实践
4. 声明式UI成为不可阻挡的趋势
5. 原生跨平台移动技术发展迅速
6. 小程序开发方兴未艾
7. 移动开发平台化成为流行的开发文化
8. 移动App在桌面操作系统上运行成为一种趋势

详细解读

hybrid跨平台开发已经进入衰退期

报告观点

• Hybrid混合开发进入衰退期

解读

做移动开发的程序员，不可能不清楚Hybrid开发，Hybrid是把原生开发与Web开发整合起来的一种开发模式。App的基础能力，稳定不易变动的用原生开发来实现。而业务上易于变动的则使用H5开发来实现。Hybrid大多还会还支持H5调用原生的方法，实现两者的交互。由于H5在移动设备上性能的不断提升，这种方式越来越受到欢迎。

但随着小程序，原生跨平台技术的成熟与兴起，Hybrid这种开发模式愈发不流行起来。现在，除了一些平台级的App，比如钉钉，企业微信这样的以外。非平台级的App使用Hybrid在现在并非最优选择。

原生开发依然是主流选择

报告观点

• 原生移动开发占据绝大部分比例，进入晚期主流阶段

解读

AppBrain给出了一份数据，在Android中，TOP 500的App中，8成使用的是原生移动开发，而在所有Android App中，这个比重是75%。这表明，在移动开发中，原生开发依然是最主流的选择。

这是非常容易理解的一个现象，时下虽然很多跨平台移动开发技术，诸如Flutter或React Native等。但相比起来，原生开发有着非常重要的优势，表现在：

1. 原生移动程序员众多，而相比较起来，跨平台开发人员并不是非常容易寻找。这就决定了，虽然是两个平台分别开发一次，但总体上来说，原生开发成本更可控。在考虑人力成本时，要把招到合适的人以及人员离职后招到后续替换的人放在一起考虑，这样一考量，原生开发在成本上仍然非常可控。
2. 原生移动开发仍然是最成熟的技术，没有之一。无论跨平台技术如何发展，它们在技术的成熟度上，始终不可能比得上原生开发。
3. 原生移动开发生态最成熟。现在，我们评估一个技术时，不可能不把生态考量进去。相比其它一些解决方案，原生开发在生态上仍然是最成熟与可靠的。就拿React Native来说，我也研究了一下它的主流生态，发现质量普遍难以与原生生态相比。

综上所述，我认为，无论移动技术如何发展，原生开发仍然是其它技术无法取代的。只是未来可能份额会不断受到侵蚀。

移动CI/CD的两个工程实践变得普遍

报告观点

• 使用fastlane来实现移动端的CI/CD变得普遍
• 设备批量自动化测试变得普遍

解读

在技术上，我一直有一个观点，凡事能自动化让计算机处理的，就不要依赖人手工来做。

移动开发的这两个实践其实我认为都是我这个观点的证明。

我过往有几年搞过移动开发，对于移动开发来说，打包以及批量化设备测试这是两个非常大的痛点，非常困扰移动开发人员及团队。

第一个是打包，不同于后端或前端，移动端的打包严重依赖于移动开发人员，开发，测试或预生产，我们以前还有各个不同的客户，每个客户又有个性化的一些打包需求，这导致让运营或其它非移动人员来打包根本不现实。于是大多数情况下只能开发人员来，但这非常打扰开发人员。

第二个是设备的自动化测试。众所周知，移动设备机型众多，后端只需关注部署的服务系统就好了，前端只关注主流的几个浏览器，但移动端不同，不同的操作系统，不同的手机设备，还有国内众多定制的ROM，还有不同大小的设备。以此种种，相信几乎每个移动测试团队都会有一批手机设备，每次手工测试都会尽量覆盖更多的移动设备。

理所当然的，在技术上能解决这两个痛点的当然会变得普遍与流行。

fastlane是一个专业的打包框架，支持Android与iOS，用它能很方便的让你的打包自动化。过往我是通过自己写Jenkins + SHELL脚本来实现自动化打包的，下一次我则会选择fastlane，因为它更专业。

而设备批量化自动测试也变得流行起来，比如国内也有一些类似的服务，你把App上传上去，这些自动化服务会在批量的设备上进行测试并将结果或截图生成给你。

声明式UI成为不可阻挡的趋势

报告观点

• iOS的SwiftUI已经得到普遍应用，进入早期主流阶段
• Android的JetPack Compose已经早期采用阶段

解读

我曾在自己的系列文章中前端之变中也阐述过这个观点，前端现在无论是React或是Vue等主流框架都已经是声明式UI，而过往移动端仍然停留在命令式UI上，相比起来，声明式UI的优点太多了。

其实，前端技术也经历过从JQuery的命令式UI转向React的声明式UI这一过程，那完全可以预测到，都属于大前端的移动端，理所当然的会发展出声明式UI技术。

于是，Apple的Swift发展出来SwiftUI，而Google则基于Kotlin发展出了Jetpack Compose。这两个都是声明式UI的实现。

相比较起来，iOS普及SwiftUI上更快，已经进入早期主流阶段了，而Android的Jetpack Compose仍然在早期采用阶段。这是因为Jetpack Compose很长一段时间都处于beta阶段。

但不管如何，无论是SwiftUI或是Jetpack Compose，再延伸到React Native或是Flutter这些技术，声明式UI已经成为不可阻档的趋势。

原生跨平台移动开发发展迅速

报告观点

• 诸如React Native或Flutter这样的原生开发技术进入早期主流阶段

解读

很多人可能不太理解什么叫原生跨平台开发技术。与Hybird这种使用H5的跨平台移动开发相比起来，原生跨平台开发技术是指跨平台技术最终会使用原生或类原生等非H5技术实现。

比如Flutter是自己基于Skia引擎在Android与iOS上都实现了一套UI控件，它们当然是原生的，只不过不是iOS或Android自的原生，而是Flutter实现的原生而已。而React Native则是通过将JS翻译成原生来实现。这样的技术我们统称为原生跨平台技术。

很显然，原生跨平台技术的性能一定是优于H5的跨平台的，是可以与官方原生性能相比拼的。

原生跨平台技术的出现与流行就是为了想要同时解决跨平台与性能这两个痛点的。Hybrid只解决了跨平台，但在性能上则表现出无能为力。

所以，现在Hybrid跨平台被原生跨平台慢慢取代也是理解当然的了。于是大家会见到的趋势就是，React Native与Flutter越来越流行，听到的频率将会越来越高。

当然，这不代表Hybrid就没有优点，H5的广泛性与通用性依然决定在类似钉钉这样的平台级App需要发展出App二次开发能力时，使用Hybrid依然是最好的选择。

小程序开发方兴未艾

报告观点

• 小程序进入早期主流阶段

解读

我认为这个可能更多的是在国内表现的更为突出。特别是微信为主要代表的小程序变得越来越流行。

核心原因只有一个，成本低。

不管你是使用什么跨平台开发技术，还是原生移动开发技术，它们在成本上都远高于微信的小程序的开发与维护及运营成本。

考虑到现在用户越来越不愿意下载新的App，App获客成本越来越高的情况下，对于那些只是希望将自己的服务能延伸到移动设备上的业务来说，使用小程序无疑是最优选择。

移动开发平台化成为流行的开发文化

报告观点

• 越来越多的公司会有一个移动平台级团队，负责开发App能用基础能力。比如日志，授权，闪退收集等。

解读

我个人认为这个更有可能是在大公司出现的趋势，中小公司的移动团队可能表现不突出。

对于大公司，这是理所当然的，一个大公司可能有上百个App在开发，运营。对于这些App来说，当然有一些通用的需求，比如收集与记录闪退情况，日志，通用授权等，所以基于此，有一个平台级团队专门负责开发类似的基础能力当然是成本最优的选择了。

比如腾讯的Bugly，这是个闪退收集的服务，它是一个基础能力，腾讯内部本身很多App都在使用这个服务。

而中小公司由于移动App少，而且移动开发人员也少，我认为这个趋势并不明显。

移动App在桌面操作系统上运行成为一种趋势

报告观点

• 移动App在桌面操作系统上运行，变成了一种趋势。

解决

我认为，这个趋势肯定是有的，其实最开始，支持的应该是Linux操作系统，而后Windows与MacOS也都支持了这种行为。

Window 11支持运行Android程序，而MacOS则是支持自己的iOS程序，Linux也是支持的Android。

Linux最开始部分系统支持Android运行完全是因为本身Linux生态不足，期望用这种方式来某种程度上弥补这个不足。而后Windows与MacOS平台也跟进了这一行为。

但我对于在桌面操作系统上运行App，这种究竟能起到多大的作用，还是怀疑的。Linux本身使用人数就不多，就不说了，最主要的Windows本身软件就非常丰富，在桌面上用Andriod App一个没有太大必要，二个体验也很一般。而MacOS也是同理，至少我没有在MacOS遇上需要使用iOS App的场景。

所以，我个人认为，在桌面级操作系统上支持App可能是一种得到支持的能力，但这种使用未必会流行起来。