HarmonyOS到底是不是Android套皮？

痛定思痛。 2022-10-06 12:59 319阅读 0赞

来源：21ic电子网，头条@我的小号等
    本文作者观点不代表本网观点
    
    
    某人曾说「没有调查就没有发言权」
    
    
    
    最近鸿蒙系统关注度好高，支持与反对、看好和看衰、「自主的全场景分布式系统」和「Android套壳」各执一词，吵的不可开交。
    
    
    作为十八流码农，本着了解行业动态、体验HarmonyOS开发流程、找出HarmonyOS的特性与不足、看看是否有新的机会，也为了看看吵得不可开交的诸位谁说得对，特地在这个鸿蒙系统马上正式开放升级的时间点，开发体验了一番。
    
    
    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只做了两件事：
    
    
    定义Application为ShellApplication
    定义MainActivity为MainAbilityShellActivity
    
    
    emmmmm……这名字起得真直白
    
    
    按照Android开发的惯例，从build文件夹中找这两个类的相关文件。
    
    
    
    
    果然不费吹灰之力，接着分析源代码：
    
    
    先分析一下Application的定义文件ShellMyApplication：
    
    
    
    
    ShellMyApplication继承自HarmonyOS SDK的AceHarmonyApplication，不过啥事都没干，接着看AceHarmonyApplication：
    
    
    
    
    emmmmm……俄罗斯套娃吗？照样啥事也没干，那就接着找它的父类：
    
    
    HarmonyApplication：
    
    
    
    
    看这么大段的引用和变量定义，应该是正主没错了，不过HarmonyOS的HarmonyApplication竟然继承自Android的Application，这件事就得说道说道了HarmonyApplication整个文件很长，就不贴代码了，这个类主要做了如下几个工作：
    
    
    1、初始化HarmonyOS应用...
    2、输出HarmonyOS应用开始初始化的日志......
    3、加载HarmonyOS的Ability到Android的Application的HashMap中.........
    
    
    4、接收系统产生的各种事件然后转发给鸿蒙应用............5、初始化一个EventRunner，结合ohos包的代码来看，估计就是官方文档提到的「分布式软总线」，是HarmonyOS所谓的「分布式设计」的相关实现，这部分后面分析
    
    码农果然都是老实人，起名都这么实诚又恰如其分：
    
    
    ShellApplication的作用就是Android的Application提供一个Shell（壳），让HarmonyOS的Application寄生其中
    
    
    接着来看看MainAbilityShellActivity，依旧是套娃设计，直接看具体的实现：
    
    
    
    
    MainAbilityShellActivity依旧继承自Android的Activity，整个文件依旧很长，但是逻辑很简单，就一个作用：
    
    
    将Android的MainActivity的生命周期、Intent、触摸事件、按键时间、权限申请结果……通过AbilityShellActivityDelegate（代理）转发给HarmonyOS的Ability
    果然不负Shell之名。本来想打开Androi……HarmonyOS的应用布局调试界面，但是设置里找不到了，233333……
    
    
    不过根据我的第一个鸿蒙app，以及所见内容,得知
    
    
    
    
    这篇文章2020年末写的，到如今只过去五个月，估计具体实现没有改变。
    
    
    03 分布式软总线HarmonyOS最大的卖点是其宣称的「面向万物互联时代的全场景分布式操作系统」，也是其最大的特性。
    
    
    从官方文档来看，不管是开发层面所谓的「分布式设备虚拟化」、「分布式数据管理」、「分布式任务调度」，还是目前官方演示的「无缝流转」、「多屏协同」都是以「分布式软总线」为通讯基座，因此我们重点来找找它是怎么实现的。
    
    
    具体到开发文档中，没有发现关于「分布式软总线」的API，只找到三个与其「分布式技术」所描述的特性相似的三个功能：
    
    
    
    
    分别是：

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

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

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

![7af8c650ecc1abfd1efc05c39b39ed12.png][]

Java开发中，这种情况比较少见，只有一些重要的、底层的API中可能会出现，不过这个ohos.jar包源码全部隐藏还是第一次见！！！HarmonyOS到底有多怕发现它的小秘密。

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

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

> ohos.rpc.\*

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

![8e63130bde2c38419603a03022394106.png][]

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

![ceb397e8d49bcefc254f9bf0c25566e8.png][]

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

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

不过，阿华不愧是立志要模仿、超越阿果的公司，连起名都一样的鬼才：如此专业的名词都能起得如此通俗易懂！

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

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

而且作为HarmonyOS的核心特性和杀手锏，作为十八线码农、不入流从业人员，怎么能不会对其设计思想产生好奇？

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

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

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

于是，我们来翻一下OpenHarmony的仓库:

https://gitee.com/openharmony

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

https://gitee.com/openharmony/communication\_services\_softbus\_lite

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

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

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

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

![4d82743d07675ac2dbe376c3c35777b9.png][]

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

![06a953e2f546f13422302e89a6b61eea.png][]

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

![c513dfdf766a77a87f12633822b37032.png][]

### **05 其他** ###

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

https://gitee.com/openharmony/ace\_engine\_lite

这个应该就是JS开发的Ability界面如何编译以及在嵌入式设备上如何渲染的相关实现，这也应该是为什么HarmonyOS可以采用多种语言开发界面的原因所在：

![b52bbb67dfa1aaf11cb91e15c6cababb.png][]

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

## 01 华为到底在HarmonyOS上做了哪些工作 ##

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

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

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

它们三者之间的区别：

小程序：运行中各自App环境内部

Flutter：致力于移动端、桌面端、Web、嵌入式全覆盖

Ability：主要为华为生态中的手机以及嵌入式设备设计

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

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

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

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

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

![4a7d86afb165549582386a838d009ef2.png][]

从分析结果来看，HarmonyOS有些地方确实夸大宣传了，比如：

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

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

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