❓❓❓鸿蒙元服务到底是什么？和应用的区别？什么业务适合元服务？元服务的定位、限制与未来

背景

2024年10月22日，华为全场景新品发布会上正式发布了原生鸿蒙系统HarmonyOS NEXT(5.0)。

2024年11月26日，华为发布的Mate70系列新机，以用户可选的方式出厂搭载原生鸿蒙系统。

随着原生鸿蒙系统的不断推进，肯定有很多开发者将开发鸿蒙版本应用提上了日程。

但是在刚刚了解原生鸿蒙开发时，会遇到一个概念问题：元服务是什么？和应用有什么区别？什么功能适合做成元服务？

下面，我们一一探讨这些问题。

什么是元服务？

元服务的官方介绍见：元服务

元服务是HarmonyOS提供的一种面向未来的服务提供方式。
元服务和APP是HarmonyOS生态的“一体两面”，是生态伙伴面向用户的两种形态。

官方的解释太过书面化，我因为原本是做iOS开发的，所以下意识的想要在iOS系统里找对标，因此一直以为是“桌面卡片”“负一屏卡片”之类的Widget。
后面搞了两天发现概念乱了，元服务是元服务，卡片是卡片，两者没有必然关系。

我们不如通过一些特性来进行了解：

秒开直达、即用即走、嵌入运行

是不是有种看张小龙的“微信公开课”的感觉？
没错，元服务想要达到的效果就是类似小程序的那种免安装打开的效果。（不过官方对于元服务的定义还是应用，因此在进行备案之类的操作时，元服务还是按应用进行处理。）

不过相较于小程序，元服务还是有一些明显的差别，比如无法跨平台。

因此，元服务其实更加接近于国内安卓厂商联盟搞的快应用，两者都是操作系统级的小程序。

元服务和应用的区别？

对于原生鸿蒙而言，元服务和应用的区别有哪些？

产品运营层面：

• 免安装；
• 自动更新；
• 无固定入口；
• 负一屏等系统分发入口；

开发层面：

• 包大小限制：单包2M，总包10M；
• API限制：元服务只能使用部分系统API；

官方文档对于元服务和应用的区别写了很多，但核心的其实就这些。

元服务发展的劣势

元服务的基本概念已经明确了，下面我们来探讨一下元服务这个产品形态本身的定位和未来发展前景。

首先，微信小程序作为小程序产品形态的开创者，和目前发展的最好的应用场景，我们还是和微信小程序进行一下比对。

元服务相比微信小程序有哪些优势和劣势？

功能	元服务	微信小程序
性能	基于系统原生，性能更好	基于JS引擎，性能略低，但用户感知其实不明显
API能力	系统原生API，但不是全量	需要通过wxapi进行桥接，相对不自由，但发展了很多年，已经趋于完善
开发成本	和鸿蒙原生应用共用ArkTS代码，但API不兼容，可能需要处理；而跨平台框架也需要兼容元服务API	原生开发成本高；但Taro/Uniapp等跨平台框架已经适配完善。
推送	直接使用系统推送能力，更自由	受微信限制，比较难受
生态	只能使用系统本身生态	可以使用微信内部的生态，社交资源较为重要
跨平台	不能跨平台	跟随超级APP，跨平台能力强大
运营	目前只能通过AppLinking分享	小程序码、分享能力

总结一下：

性能方面：元服务占优，但可惜用户体感不明显；
API能力：元服务可以拿到很多小程序管控的敏感权限，但结果鸿蒙又阉割api，好不容易有点长处，自己把自己阉了……
其他的都是元服务的劣势，尤其是跨平台和生态方面，短板太明显。

跨平台劣势

没有了跨平台优势，开发者相当于需要专门给你开发一个版本，即便开发成本不高，也不会去做。
当然，我这里说的“不会去做”是指开发一个完整的业务功能闭环的应用，而不是将元服务作为营销跳板，直接将流量导入到同名APP那边。

初期因为负一屏入口等原因，开发元服务的厂商应该不少，但是还是要看是否会长期维护。

推广劣势

而小程序的另一个重要推广渠道————线下，这种劣势更明显。
我可以接受搞一个微信小程序版的点餐二维码，但怎么也不会搞一个只能给鸿蒙手机用的二维码吧？

推广的另一个渠道————分享，如果你都不能跨平台了，我分享出去，能够有效触达的用户更是少得可怜，分享欲望不会很强。

其实最佳的形态还是国产手机联盟搞的快应用，系统级，除了苹果都能用，数据互通啊，分享还容易打通。

API限制问题

API阉割的问题影响也很大，元服务相对小程序本来就已经有很多的劣势了，API阉割真的是雪上加霜！

如果API完全不做阉割，凭借权限的开放性、API的全面性，有些特殊场景的业务可能使用元服务体验反而会更好一些。

但这不能用那不能用，还没有小程序的生态优势，肯定更愿意开发维护小程序啊……

什么业务适合用元服务开发？

说了这么多，那么到底哪些业务使用元服务呢？

我们先说不太适合的：

重型业务

如果有复杂业务，一般都会有同样的应用，想要通过代码移植来做元服务；但重型业务相关的代码及依赖代码量很大，为元服务API集做迁移，工作量可能会很大。

如果有比较轻、比较独立的业务，代码可以单独拆分开的话，单独抽出来上线元服务可以考虑。

跨平台项目

Flutter、Taro、uniapp、WebApp等跨平台项目迁移到元服务，其跨平台代码体积一般都很大。
基本都会超过单包2M的限制，而跨平台代码基本无法拆包。

如果跨平台代码幸运的没有超过2M，但加上鸿蒙原生ArkTS代码超过了，可以尝试下将鸿蒙原生ArkTS代码拆包。（虽然工作量也不会小）

有大量第三方依赖的项目

单包2M看着不小，但实际上并不大。
随便写个页面或者类都有十几或几十KB的大小，如果逻辑复杂，你会发现写个十几个页面，体积就快要超了。

更为麻烦的是第三方依赖：

1. 首先是第三方组件；尤其是流行的第三方组件，越是评价高越是用的人多，为了保证通用性就会加很多通用代码，你可能只使用了其中一个API，但就不得不引入总共几十个类的组件；
2. 然后就是第三方组件主要面向应用开发，可能使用了元服务不兼容的API。更换或者修改都要额外的开发成本。

所以除非你是元服务每行代码都是重新写，否则你引用几个第三方库，或者有和应用共用的组件，冗余代码一多，体积很快就会上来。
代码就越多，体积也越大。

使用了不常见系统API的应用

如果你的应用不是最为常见的信息展示、表单提交等类似功能的应用，比如使用了各种多媒体能力、网络能力、硬件能力。
最好先去官方开发文档里搜一下，看看相关API是否允许元服务使用。

那么有哪些场景推荐使用元服务呢？

1. 想要使用负一屏入口等场景，这些不对应用类型开放；
2. 引流；即开即用的特性会减少用户的决策成本，显著降低拉新成本。
3. 独立的精简版应用；如果你的应用功能就是很少，完全可以不（首先）开发应用，直接使用元服务作为默认形态。

元服务的定位与未来

鸿蒙对于元服务的定位更多的在于“即开即用”上面，如果是站在用户的角度考虑，这肯定是非常好的。

但是对于开发者来说，开发成本、维护成本等又是不得不考虑的东西。

如果能够将元服务API集放开，赋予元服务更多更强大的能力，元服务未来的发展可能会更好。