从HarmonyOS应用到底是不是Android套壳？

Posted 2021-06-23 Jason_Lee155

注：文章来自于各位大佬分析总结，单纯技术论证，不吹不黑任何企业公司个人。

随着鸿蒙系统2.0的发布，各界一片争议，支持与反对、看好和看衰、「自主的全场景分布式系统」和「android套壳」各执一词，吵的不可开交。

作为一个菜鸟码农，本着了解行业动态、体验HarmonyOS开发流程、找出HarmonyOS的特性与不足、看看是否有新的机会，也为了看看吵得不可开交的诸位谁说得对，特地在这个鸿蒙系统正式开放升级的时间点，开发体验了一番。

首先声明：

不吹不黑，harmonyOS这一套确实是为了互联生态，但是根基依然是安卓给的，自研是有，套壳也是真，huawei自己也说了基于AOSP，AOSP是Android Open Source Project的简称，网上那些说是不是安卓或者是不是谷歌的问题，其实没必要争论，AOSP是谷歌的一部分，AOSP包含着安卓，安卓也包含着AOSP，他们是交集关系，先有鸡还是先有蛋的问题，那么可以这么说，有谷歌接手安卓的时候就有了AOSP，AOSP是意图用来完善安卓操作系统，和网上说的linux开源的目的是一个道理。

从开发的角度讲，安卓有Linux内核层、抽象驱动层、框架层以及应用层，这个核心构架已经发展了数年，并且从安卓8开始还引入了HIDL概念，重新定义了驱动接口的框架。鸿蒙的实现亦是如此，只不过在功能方面是为了物联网而生，单纯的说他流畅不流畅，能不能跑安卓没有意义，他本身依然是安卓，拥有这以上说的几个层面，huawei引入了Litekernel（微内核）的概念，加入了LiteOS，从内核开始，为物联网打基础，毕竟安卓的这个框架面对的是应用密集型，而huawei把应用型的系统和物联网的系统作为并列的层面了，但是依托的仍然是安卓的框架，安卓的ART，就目前的鸿蒙的规模来说，他是从内核到驱动，驱动到框架，框架到应用API都可以看做是安卓的附属品，他的概念比国产大牌门的系统来说要更高级，在安卓原有的基础上做了附属的创新。所以套壳是真，自研也是真，概念是好，宣传方式让人很不爽。

HarmonyOS到底怎么实现的——扒皮HarmonyOS

了解一个软件怎么实现的，最好还是查看源代码。

但是承诺2020年开源的OpenHarmony项目到现在只开源到嵌入式设备，这条路自然走不通。

只好退而求其次，看看已经开放的SDK、IDE、开发示例、编译产物，管中窥豹一下HarmonyOS到底怎么实现的。

00 安装IDE-配置环境-编译运行

这部分很简单，下载DevEco Studio，然后照着文档一步步操作就好了

模板选择了唯二的JS模板：Phone > Refresh Feature Ability

然后一直下一步，申请下虚拟机，编译运行就成功了

01 分析编译产物

运行成功后，先大致分析一下编译产物，找一下程序入口，看看代码到底怎么运行的。

点开build文件夹，打开一看，喔噢！！！这目录结构和Android的太相似了，于是作者熟练的点开outputs文件夹找apk文件。

.hap？？？怎么和预想的不一样？不过侵淫Linux多年的经验告诉作者，后缀都是浮云，于是果断把.hap改成.apk，然后用Android Studio打开，果然：

对比官方给出的App逻辑视图：

我们发现：

1、没有找到描述每个HAP属性的pack.info

估计是因为工程只定义了一个Entry，没有定义Feature，于是只生成了Entry的安装包，但是按照官方文档给的说法：

Entry可以独立安装运行，在只定义一个Entry的情况下，编译出这种包也说得通

2、App逻辑视图中的config.json正常在

3、App逻辑视图中的abilities竟然编译成Android包的.dex执行文件，而用js定义的界面、视图、逻辑竟然归入assets中，这里面就有点猫腻了

4、编译的可执行文件中竟然包含一个.apk文件，这个不速之客可在App逻辑视图中完全没体现，值得怀疑

于是接下来，我们就先重点分析这个entry_signed_entry.apk，分析一下这个不速之客在App安装包里有什么作用。

02 分析entry_signed_entry.apk

继续用Android Studio打开这个文件：

是一个标准的Android App！于是熟练的点开Android应用描述文件：AndroidManifest.xml

通过描述文件可以发现，整个apk只做了两件事：

1. 定义Application为ShellApplication
2. 定义MainActivity为MainAbilityShellActivity

名字起得直白。

按照Android开发的惯例，从build文件夹中找这两个类的相关文件：

果然不费吹灰之力，接着分析源代码：

先分析一下Application的定义文件ShellMyApplication：

ShellMyApplication继承自HarmonyOS SDK的AceHarmonyApplication，不过啥事都没干，接着看AceHarmonyApplication：

俄罗斯套娃吗？照样啥事也没干，那就接着找它的父类：HarmonyApplication：

看这么大段的引用和变量定义，应该是正主没错了，不过HarmonyOS的HarmonyApplication竟然继承自Android的Application，这件事就得说道说道了HarmonyApplication整个文件很长，就不贴代码了，这个类主要做了如下几个工作：

1. 初始化HarmonyOS应用。。。
2. 输出HarmonyOS应用开始初始化的日志。。。
3. 加载HarmonyOS的Ability到Android的Application的HashMap中。。。

1. 接收系统产生的各种事件然后转发给鸿蒙应用...
2. 初始化一个EventRunner，结合ohos包的代码来看，估计就是官方文档提到的「分布式软总线」，是HarmonyOS所谓的「分布式设计」的相关实现，这部分后面分析

码农果然都是老实人，起名都这么实诚又恰如其分：

ShellApplication的作用就是Android的Application提供一个Shell（壳），让HarmonyOS的Application寄生其中

接着来看看MainAbilityShellActivity，依旧是套娃设计，直接看具体的实现：

MainAbilityShellActivity依旧继承自Android的Activity，整个文件依旧很长，但是逻辑很简单，就一个作用：

将Android的MainActivity的生命周期、Intent、触摸事件、按键时间、权限申请结果……通过AbilityShellActivityDelegate（代理）转发给HarmonyOS的Ability

果然不负Shell之名。本来想打开HarmonyOS的应用布局调试界面，但是设置里找不到了。

不过根据知乎作者的第一个鸿蒙app，以及所见内容,得知

这篇文章作者2020年末写的，到如今只过去三个月，估计具体实现没有改变。

03 分布式软总线

HarmonyOS最大的卖点是其宣称的「面向万物互联时代的全场景分布式操作系统」，也是其最大的特性。

从官方文档来看，不管是开发层面所谓的「分布式设备虚拟化」、「分布式数据管理」、「分布式任务调度」，还是目前官方演示的「无缝流转」、「多屏协同」都是以「分布式软总线」为通讯基座，因此我们重点来找找它是怎么实现的

具体到开发文档中，没有发现关于「分布式软总线」的API，只找到三个与其「分布式技术」所描述的特性相似的三个功能：

分别是：

• 分布式任务调度
• 分布式数据服务
• 分布式文件服务

有了这三组API，我们就可以通过「排列组合」实现其官网所宣称的所有关于「分布式」的特性，所以，我们直接到SDK中找这三组API怎么实现的就可以追根溯源找到「分布式软总线」具体怎么实现的了。

打开ohos.jar包后，遇到了第一个问题：所有代码都不给看！

Java开发中，这种情况比较少见，只有一些重要的、底层的API中可能会出现，不过这个ohos.jar包源码全部隐藏还是第一次见！HarmonyOS可见对分布式软总线技术的保密程度。

不过我们只是为了看一下HarmonyOS的设计思想，又不研究它具体实现，所有也用不着源代码，直接看类名、函数名、依赖关系，大胆猜测、小心验证一下就好了。

通过分析依赖关系，发现，大多数与分布式相关的包都依赖于：

ohos.rpc.*

以及官方文档中有关「分布式任务调度」所依赖的包：

以及官方文档「分布式软总线示意图」

我们有理由相信：所谓的「分布式软总线」实际上是一个私有的RPC协议。

结合RPC的特点和HarmonyOS的特性，HarmonyOS的「分布式软总线」采用RPC就就根本不奇怪。

04 「分布式软总线」具体设计

上面说的再斩钉截铁，最终也不过是猜想；

而且作为HarmonyOS的核心特性和杀手锏，作为此行业从业人员，怎么能不会对其设计思想产生好奇？

不过苦于没有源代码，以及估计绝大部分都是在系统层实现的，ohos.jar里也不过是相关调用，这条路肯定是行不通

这时候灵感一闪，既然HarmonyOS是「全场景分布式系统」，那么这套协议肯定不止在HarmonyOS手机系统上实现，在其他类型设备上肯定有相关实现。

这时候按揭开源的OpenHarmony再次回到作者的视线，既然OpenHarmony项目已经开源了嵌入式设备的相关实现，那么没准里面就有这套协议的相关源码。

于是，我们来翻一下OpenHarmony的仓库: https://gitee.com/openharmony；

皇天不负有心人，与「分布式软总线」相关：

https://gitee.com/openharmony/communication_services_softbus_lite

这个项目实现了软总线发现、组网、传输相关协议，熟悉编程的朋友应该能想得到，有了这个项目，「全场景分布式」所列举的所有特性都可以实现了。

代码部分又臭又长，而且估计很多人也不感兴趣，也不确定全平台的都是这样实现的，就不具体分析了，只说一下设计思想和大致工作流程，不同平台具体实现可能有所不同，不过设计思想应该不会差太多。

「分布式软总线」主要有以下几个工作模块：

1、设备发现：采用了CoAP协议作为设备发现协议，通过发送在一个局域网内发送广播来发现设备，具体实现与本文无关，就不展开了，感兴趣的可以自己去看，在这个包里：

2、数据传输：基于Session提供统一的数据传输功能，不过网络通信是人家的老本行了，估计挑不出什么毛病，就仔细分析了，代码在：

3、设备认证与管理：这部分主要是为了安全的，代码在：

05 其他

整个OpenHarmony项目，还有一些有趣的实现：

https://gitee.com/openharmony/ace_engine_lite

这个应该就是JS开发的Ability界面如何编译以及在嵌入式设备上如何渲染的相关实现，这也应该是为什么HarmonyOS可以采用多种语言开发界面的原因所在（总之，宣传各种跨平台或者多语言的，几乎都是有一层c++实现的engine，说到底c++才是一直以来的王者啊）：

各种小程序、Flutter相关框架都是这样设计的，全都是用来实现诸如「无缝流转」、「远程启动」、「迁移」等与Ability有关的功能。

huawei到底在HarmonyOS上做了哪些工作

从编译完成的产物以及开源的源代码来看，huawei为其所谓的「全场景分布式操作系统」主要做了两个方面的工作：

1、定义了以Ability为核心的应用开发框架，使其可以屏蔽不同操作系统的差异，使开发的代码可以在不同操作系统中运行；

在HarmonyOS之前，与之类似的技术且比较成功的有各家的小程序框架以及Flutter。

它们三者之间的区别：

• 小程序：运行中各自App环境内部
• Flutter：致力于移动端、桌面端、Web、嵌入式全覆盖
• Ability：主要为huawei生态中的手机以及嵌入式设备设计

虽然它们各自的所追求的目标不同，但它们设计思想都是类似的：自绘UI，屏蔽系统差异。

2、定义了一个以「分布式软总线」为名的自有RPC协议框架，以此RPC协议为基础封装了一系列常用的API，屏蔽了设备之间的繁琐、多种多样、差异很大的通讯方式，提供了稳定、统一、可靠的近场通讯协议。

再具体到huawei手机上将要升级的HarmonyOS，估计是：

原有的Android系统 - GMS + HMS + 分布式软总线 + 以Ability为核心的应用开发框架 = HarmonyOS

具体到示意图，估计就是：

从分析结果来看，HarmonyOS各自心里也有谱了，一些个人感觉：

• 随时换掉AOSP，这里的「随时」，估计在近五年内不会实现，在此之前，去掉Android虚拟机，HarmonyOS能不能正常运行，作者是持怀疑的态度的
• 「全场景分布式操作系统」，根据「分布式软总线」相关代码，这里的「全场景」，估计是同一个局域网内的「全场景」、同一个局域网内的万物互联

当然，对于HarmonyOS的绝大多数宣传，按目前的设计思路，完全有可能实现或者已经实现了，比如：

• 由于Ability、分布式软总线等技术屏蔽了操作系统差异，一点点挖空、取代AOSP是完全有可能实现的（虽然作者认为这个时间会持续5-10年，到时候Android、HarmonyOS存不存在都不能确定）

HarmonyOS到底是不是Android套皮

回到我们最初的问题：「HarmonyOS到底是个全新的自主操作系统还是个套壳安卓？」

分析完代码后，作者发现自己也不能回答这个问题：

说它是吧，它也确实是从Android发展出来的

说它不是吧，它也确实和Android有了明显的差异和特色

不过这时候，大家会发现这个问题和一个提出了2000年的哲学悖论很像：忒修斯之船

特修斯之船（The Ship of Theseus）亦称为忒修斯悖论，是一种有关身份更替的悖论。假定某物体的构成要素被置换后，但它依旧是原来的物体吗？说是一艘可以在海上航行几百年的船，归功于不间断的维修和替换部件。只要一块木板腐烂了，它就会被替换掉，以此类推，直到所有的功能部件都不是最开始的那些了。问题是，最终产生的这艘船是否还是原来的那艘特修斯之船，还是一艘完全不同的船？如果不是原来的船，那么在什么时候它不再是原来的船了？

回到这个问题：

替换掉Android一行代码，那么它还是Android吗？

替换掉Android一个模块，那么它还是Android吗？

给Android添加一个模块，那么它还是Android吗？

......

这个问题哲学家辩了两千年，相信我们这一时半会儿也辩不出来，而且争辩这个问题也没有太多的意义

所有我们不如抛弃这个问题，换一个新的问题，也是我们更关心的问题：「HarmonyOS能实现huawei在其终端上定下的目标吗？」

HarmonyOS能实现huawei的目标吗？

这部分本来想讨论HarmonyOS的发展前景以及能不能取得成功。

但是想要看清这件事，需要扎实的理论知识、丰富的行业经验，还要对商业活动有一定的见解，有这个能力的人，早就是行业泰斗、技术大咖了。

所以找了几天资料依旧没什么思路，因此想悄悄咪咪的把这个坑给忽略了。

但没想到看得人这么多，这下都不知道怎么鸽了，就只能强行人云亦云一波。

通常来讲，影响一个商业操作系统成败的因素有很多，但大体上都是从三个大方向进行分析：系统优势、商业运作、生态建设；

那么我们也从这三个方面探讨一下HarmonyOS有没有可能成功：

00 系统优势

目前HarmonyOS有两个独有的特性：

1. 一个跨平台的javascript应用框架（后面我们称之为Ace Engine，理由在下面）
2. 分布式软总线

这个JavaScript应用框架是Ability的最重要的组成部分之一，写前文时没有仔细看这部分的代码和文档，写的不太清楚，现在将补充内容写到这里，就不修改上面的内容了，这些补充内容也能解答评论区的一些疑问，补充内容如下：

1). HarmonyOS虽然号称可以使用Java、JavaScript、C写UI界面且UI界面可以跨设备，但目前在实际开发中，不同设备支持的语言是不同的：

• 在手机设备上，只能使用Java、JavaScript写界面（相关文档 ：Java UI框架、JS UI框架 两部分）
• 在嵌入式设备上，只能使用C、JavaScript写界面（相关文档 ：JS应用开发、系统基础子系统集>图形及UI子系统 两部分）
• 只有JavaScript写的界面可以跨设备使用

只有JS UI界面可以跨设备，就是这个JavaScript跨平台框架的功劳

2). 这个JavaScript应用框架的嵌入式部分代码已经开源了，就是上面提到的：

https://gitee.com/openharmony/ace_engine_lite

框架图如下：

其中：

• JS引擎（JS runtime）是三星开源的IoT JavaScript引擎：JerryScript
• 除JS引擎外，其他应该都是huawei自己写的
• JS应用框架只负责解析JS Bundle（我们用JS写的界面编译后的产物），渲染交给了有C写的原生框架
• 因此C原生框架不可能跨设备，只能在LiteOS中使用
• 手机端能不能使用这个C原生UI框架未知，但是开发文档上没有提及，应该是还没有开放或实现（是哪一个不太清楚，但是嵌入式设备与手机UI框架的实现难度不是一个数量级，LiteOS上的C语言UI框架应该满足不了手机上的复杂且苛刻的要求，所有不可能直接使用）

因为这个JS应用框架的LiteOS开源部分被命名为ace_engine_lite，所以我们暂时将这个应用框架称为Ace Engine

3). 这个JS应用框架的手机版本还没有开源，所以我们不知道具体实现，但是我们在上面的文章中提到过：

JS Bundle由JS Framework解析后将数据交给了Android，由Android的负责将其渲染在SurfaceView上

这就是作者为什么质疑目前HarmonyOS离不开AOSP的原因；也是作者为什么认定HarmonyOS可以掏空AOSP的原因。

4). 接着我们看一下Ability框架图：

其中：

• User Native Ability在LiteOS中指的就是C语言实现的Ability；在HarmonyOS中就是Java实现的Ability
• AbilityKit在LiteOS中应该是用C语言自己实现的，但在HarmonyOS中，是基于Android的Activity实现的
• 图中的蓝色部分在LiteOS中很明确，但在HarmonyOS中怎么实现目前没有相关代码，不得而知（作者猜测，根据上面代码分析，有部分在ShellApplication（应用内）实现，有部分为系统服务，也有部分在内核中实现）

5). HarmonyOS所宣称的双内核，其中一个是AOSP，那么另一个就应该是4）中这个以Ability为核心的应用框架；

且不论其是否符合操作系统的定义，仅由于3）的存在，现在这个阶段这个内核的独立性是存疑的；

当然，也因为3）的存在，按照这条设计思路走下去，那么HarmonyOS最终实现其画的架构图是可以确定的。

其实上面这些框框里面所说的东西的其中一部分都已经实现了，还有一部分由于时间原因没有实现，但技术已经被我国工程师所掌握，实现起来也是时间问题，除了的两部分：

• Linux Kernel（在内核层中）
• AOSP（大致对应图中的UI框架+用户程序框架+Ability框架）

别看这俩数量上很少，但是坑很深，目前国内搞不定的也就这两部分；

为什么替换不掉Linux Kernel？这个国内真的没人能搞得定这个（操作系统）；

为什么不替换掉AOSP？我们是为了兼容；那为什么Ability要交给AOSP去渲染呢？那是因为国内也没有人能搞得定这个（计算机图形学）；

以及为什么LiteOS中的JS Framework都自己实现，但唯独JS runtime还要用三星开源的JerryScript呢（手机版不知道用的啥）？因为这个国内也没有人搞得定（编译原理）；

操作系统、计算机图形学、编译原理，这仨货是计算机三大天坑，其中艰难险阻，非专业人员不能体会（讨论了半天「操作系统」又回到「操作系统」了，23333……）。

HarmonyOS主打IoT系统:

分布式软总线技术将物联网通讯技术（NFC、蓝牙、WIFI……）与协议（CoAP、RPC……）做了良好的封装，以及对数据格式（HarmonyOS IDL）以及服务（PA）做了良好的抽象，使局域网内的设备之间可以方便的通讯、交换数据、调用远程服务，设备之间仿佛融为一体。

Ace Engine在不同设备之间存在，使得可以对用户界面（UI）进行抽象（抽象为FA），让一次开发多端部署得以实现。

分布式软总线+Ace Engine 也就是HarmonyOS的核心设计思想，这一点在王成录的采访中也有所提及。

那么这两项技术有「技术壁垒」吗？可以作为HarmonyOS的护城河吗？个人认为答案都是否定的

先从技术层面看看:

HarmonyOS的嵌入式操作系统部分就不说了，玩过物联网的都知道，现在市面上的竞品有很多，除了huawei的LiteOS外，还有TencentOS tiny、Alios Things、Xiaomi Vela、RTOS……

LiteOS与其他相比最大的特点就是功能封装的更加友好，也更加统一，但最大的缺点也源于此：它需要的硬件资源太多了，对于绝大多数物联网设备来说，硬件成本是不可承受的。

而如果裁剪掉这部分，那么和其他的Iot系统并没有太多区别。

再看看Ace Engine:

熟悉编程的朋友一定知道，Ace Engine与小程序以及Flutter的设计思想与架构完全一样，Flutter由于Dart虚拟机无法运行中资源有限的嵌入式设备中，无法做到，那小程序对比如何呢？

以目前拥有最大生态的微信小程序为例，自诞生之日起，就支持Android、IOS、HarmonyOS（由于兼容Android），而又由于WMPF（Wechat Mini-Program Framework，小程序硬件框架）的存在。

目前微信小程序也可以运行在Windows、Mac、嵌入式设备上，基本覆盖了Ace Engine的所有设备（HarmonyOS、嵌入式设备）以及Ace Engine不支持的设备（IOS、Mac、Windows）

至于CoAP+RPC（分布式软总线）呢？且不说开源方案本来就有很多，就是从零开始实现，目前国内能做到的公司数量数起来，只怕两只手两只脚都不够用

那么依靠这些，huawei能够为HarmonyOS培育出自己的物联网生态吗？作者个人的观点是悲观的。

鸿蒙主管在采访中说：

作者认为，物联网作为提出了二十多年的概念，以及孵化了十几年的产业，「分布式软总线」相关技术和协议在不同产品中或多或少都才用过，而物联网到现在这个时间点都没有爆发，通讯成本高、开发成本高的确是没有爆发的原因之一，但绝对不是根本原因。

而且退一步讲，即使这个模式跑通了又如何？这套技术并没有什么垄断性的技术壁垒，以各手机厂商与移动互联网厂商的能力，最多只能给HarmonyOS六个月到一年的先发红利。

到时候不说手机厂商，就以微信为例：

除了构建在应用内的RPC协议不如构建在系统内RPC协议性能指标好外：

• 在微信小程序中做物联网应用，可以支持更多的平台（HarmonyOS vs Android+IOS）
• 在微信小程序中做物联网应用，开发成本更低（小程序 vs App）
• 在微信小程序中做物联网应用，推广成本更低（微信小程序生态 vs huaweiApp生态）
• 在微信小程序中做物联网应用，获客成本更低（即开即用 vs 下载、安装App）
• ……

假如你是产品经理，在想法验证阶段，面对这么多需要考虑的指标，你会优先选择哪一个？到时候恐怕应用响应慢点、通讯速度慢点会成为最后考虑的东西。

而一旦想法验证通过，又有几个服务不会全平台支持，而主动与一个平台绑定？

这就是HarmonyOS想要成功所需要解决的第一个问题：

如果「分布式软总线」这条路是无价值的，那么作为HarmonyOS最大的卖点，HarmonyOS所做的种种努力都是白费的，HarmonyOS最终就会走向失败；

而如果「分布式软总线」这条路走得通，极其容易被别的厂商参考、借鉴，HarmonyOS却并不能以此建立足够宽广的「护城河」并以此培育出自己的生态。

01 商业运作

一款商业操作系统想要生存，最基本的条件有两个：

1. 足够多的用户
2. 可以平衡厂家、用户、开发者利益的政策

死于没有足够多用户的操作系统太多了，就不说了；死于第二个因素的操作系统最著名的就是Windows Phone，一意孤行、反复横跳，导致微软错失了整个移动互联网时代。

先看用户问题，目前可以确定的是，在HarmonyOS没有成功的趋势之前，搭载HarmonyOS的手机以及使用HarmonyOS的用户绝大多数huawei以及荣耀用户。

以两年换机周期为例，目前huawei手机存量大约为4亿台

在目前这个时间点，HarmonyOS生态抗衡GMS生态的可能性微乎其微，所以第一批升级HarmonyOS的绝大多数应该都是国内用户，那这部分手机存量在2.2亿左右

由于GMS被禁用，huawei的海外市场估计会继续迅速萎缩

而在2020年9月15日之后，被禁止生产5nm Kirin芯片之后，huawei终端产品缺货的状态持续存在，huawei国内的市场份额估计也会快速萎缩。

再根据Android手机过去系统升级比例的经验，目前HarmonyOS装机量应该达不到王成录老师所说的生存线。

这也是HarmonyOS想要成功需要解决的第二个问题，

在商业政策方面，huawei整体的态度是开放的（老板的态度）。

但到了执行层面，就变成了huawei优先（余总的态度）.

所有可以预见未来一段时间HarmonyOS会主要服务于huawei终端的1+8+N战略。

那么在HarmonyOS证明自己是大势所趋之前，其他手机厂商估计是和huawei是玩不到一起的.

那么huawei手机产能受限的情况下，如何为那关键的「1」也就是手机终端获取新的用户也是一个需要解决的问题。

在第三方应用方面，一方面表示每一位开发者都是huawei要汇聚的星星之火；

另一方面执行起来，却是只和大厂合作：

在2021年这个时间点，当下已经发布了的开源新系统，以及Android（12）不断更新的同时.

不说别的，仅仅对比一下两者的开发文档：

https://developer.android.google.cn/about/versions/12

https://developer.harmonyos.com/cn/documentation

就不难发现为什么很多开发者对HarmonyOS不太看好。

这也就是HarmonyOS面临的第四个问题：对开发者政策问题：

02 生态建设

操作系统的生态基本上都是以操作系统为单位，比如MacOS、Windows、iOS：

但是由于Android碎片化、海量用户、谷歌服务在国内被禁用、国内Android厂商强势崛起等等原因，分裂为国内、外两个生态：

在海外，GMS具有垄断地位，HMS+huawei硬件暂时不具备与之竞争的能力

很多人对比GMS、HMS时通常从技术的角度论证，认为HMS比GMS在某些技术指标上的领先，huawei在应用商店分成上的让利等等来证明HMS在海外可以取代GMS，作者认为这种看法是不符合实际情况的。

实际上GMS这个框架在技术上确实没有什么难度，但GMS不可取代的并非框架本身，而是GMS连接着的Youtube、Gmail、Gmap、Google Pay、Google Search以及海外Android应用所依托的账号系统。。

HMS与GMS的竞争也并非这两个框架本身的竞争，而是HMS与GMS所承载的独占服务的竞争，HMS想要干掉GMS，前提是先干掉这些总用户20亿+的Google系服务。

在这一方面，huawei加上国内一票互联网厂商一起上都不一定有胜利的把握，所有短期内HMS在海外取代GMS基本上是不可能事件。

另一方面，HMS取代GMS也并非不可能，抖音出海成功之后，越来越多的中国互联网服务被海外用户所接受，中国互联网服务取代美国互联网服务并非不可能。

但是到那时候HMS取代GMS依旧面临两个问题

1. huawei终端能否活到那个时候。这方面要看huawei芯片问题能否解决、HMS在缺少关键应用的时候是否有人依旧选择huawei
2. huawei如何说服中国互联网厂商抛弃GMS拥抱HMS。因为两个生态都支持的话HMS对GMS依旧没有话语权与竞争力

在国内，由于Google服务在国内被禁，又由于GMS这个框架确实没有什么技术壁垒，又由于HMOV四家手机厂商除了华为独有芯片设计能力之外，在手机设计方面各家技术实力相差不大，所以各家都实现了一套类似GMS的框架

• https://developer.huawei.com/consumer/cn/
• https://dev.mi.com/console/
• https://open.oppomobile.com/
• https://dev.vivo.com.cn/home?cid=w-2-baidu-sem-kfpt-qt

HMOV一个不落，全都提供类似的移动服务，如果你点开看一下，发现他们提供的服务内容也相差不大；

所以在国内，HMS、MMS、OMS、VMS的市场份额就约等于它们手机的市场份额，所以腾讯系、阿里系接入HMS并不会给HMS提供什么额外竞争力，因为它们接入huawei家的HMS，自然也会同时接入小米家的MMS、OPPO家的OMS、Vivo家的VMS。

而且它们接入的基本上只有推送服务，像比较重要的账号体系、支付体系都会牢牢把握在自己手中，甚至即使是推送服务，它们为了保证自己的业务以及消息送达率，它们在接入官方推送服务后依旧在后台维护这自己独有的推送服务，那些应用互启动、推送服务后台耗电问题依旧没有解决。

所以腾讯系、阿里系接入HMS是肯定的，在HarmonyOS出来之前，它们很多应用就已经接入了，但要是说腾讯系、阿里系接入HMS可以提高HMS的竞争力，恐怕是很多人的一厢情愿。

最后再说说HarmonyOS的物联网生态：

很多人认为软件没有实物，没有什么规则限制，只要想得到，就能做得到。

这也是很多人的一厢情愿，计算机科学是一门科学，是逻辑的产物，也受相应规则的制约。

对HarmonyOS来说，它将物联网通讯协议进行封装使通讯更加便捷，提供跨平台JS runtime使得UI界面可以一次开发多端运行，确实使得相关开发更加便利；

但有利必有弊，通常来说，软件封装的层次越高，其通用性就越差。

HarmonyOS在针对某些物联网场景进行了针对性的优化，确实意味着在这些物联网场景可以进行更便捷的开发，但也意味如果你的物联网设备不适用这些场景，那么在HarmonyOS上进行开发，会产生比采用其他平台更高的成本。

比如：

1. 对于绝大多数物联网设备，没有这么奢侈的硬件去运行HarmonyOS的物联网系统，也并没有这么多交互需要界面去实现，那么采用LiteOS，就意味着对其没有什么帮助还徒增成本（其他物联网系统有更通用的解决方案，成本也更低）
2. HarmonyOS更加私有化的封装也意味着与其他的物联网系统打通更加的困难，huawei估计没有能力做的所有物联网设备都采用鸿蒙系统，那么HarmonyOS与为鸿蒙系统物联网设备的交互也更加困难
3. 作者认为物联网设备的互联互通与相互控制并不是解决目前物联网产业困境的关键。目前，物联网产品的解决方案大多都是将控制权交给手机App或者语音，但这些并没有多少方便我们的生活，有点食之无味、弃之可惜的味道

比如：

我的手机、音箱都可以控制我的烤箱，我的烤箱依旧烤不出好吃的面包、蛋挞

我的手机、音箱都可以控制我的炒菜锅，我的炒菜锅依旧炒出来的菜该糊的糊，该怎么难吃的还怎么难吃

我的手机、音箱都可以控制我的空调，但室内温度依旧不能自动调到让我感到舒适的温度

......

作者认为这些问题才是物联网产业目前遇到的问题的关键。

而这也是为什么作者不太看好HarmonyOS的物联网生态布局，它确实将原来的物联网设备开发成本降低了一个数量级，但是依旧没有解决上面的这些问题，毕竟，就算所有物联网设备都可以畅通无阻的通讯又有什么用呢？买它们又不是让它们来说悄悄话的。

......