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包后,遇到了第一个问题:所有代码都不给看!!!
Java开发中,这种情况比较少见,只有一些重要的、底层的API中可能会出现,不过这个ohos.jar包源码全部隐藏还是第一次见!!!HarmonyOS到底有多怕发现它的小秘密。
不过我们只是为了看一下HarmonyOS的设计思想,又不研究它具体实现,所有也用不着源代码,直接看类名、函数名、依赖关系,大胆猜测、小心验证一下就好了
通过分析依赖关系,发现,大多数与分布式相关的包都依赖于:
ohos.rpc.*
以及官方文档中有关「分布式任务调度」所依赖的包
以及官方文档「分布式软总线示意图」
我们有理由相信:所谓的「分布式软总线」实际上是一个私有的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协议作为设备发现协议,通过发送在一个局域网内发送广播来发现设备,具体实现与本文无关,就不展开了,感兴趣的可以自己去看,在这个包里:
2、数据传输:基于Session提供统一的数据传输功能,不过网络通信是华为的老本行了,估计挑不出什么毛病,就仔细分析了,代码在:
3、设备认证与管理:这部分主要是为了安全的,代码在:
05 其他
整个OpenHarmony项目,还有一些有趣的实现:
https://gitee.com/openharmony/ace_engine_lite
这个应该就是JS开发的Ability界面如何编译以及在嵌入式设备上如何渲染的相关实现,这也应该是为什么HarmonyOS可以采用多种语言开发界面的原因所在:
各种小程序、Flutter相关框架都是这样设计的,全都是用来实现诸如「无缝流转」、「远程启动」、「迁移」等与Ability有关的功能。
01 华为到底在HarmonyOS上做了哪些工作
从编译完成的产物以及开源的源代码来看,华为为其所谓的「全场景分布式操作系统」主要做了两个方面的工作:
1、定义了以Ability为核心的应用开发框架,使其可以屏蔽不同操作系统的差异,使开发的代码可以在不同操作系统中运行。
在HarmonyOS之前,与之类似的技术且比较成功的有各家的小程序框架以及Flutter。
它们三者之间的区别:
小程序:运行中各自App环境内部
Flutter:致力于移动端、桌面端、Web、嵌入式全覆盖
Ability:主要为华为生态中的手机以及嵌入式设备设计
虽然它们各自的所追求的目标不同,但它们设计思想都是类似的:自绘UI,屏蔽系统差异
2、定义了一个以「分布式软总线」为名的自有RPC协议框架,以此RPC协议为基础封装了一系列常用的API,屏蔽了设备之间的繁琐、多种多样、差异很大的通讯方式,提供了稳定、统一、可靠的近场通讯协议。
再具体到华为手机上将要升级的HarmonyOS,估计是:
原有的Android系统 - GMS + HMS + 分布式软总线 + 以Ability为核心的应用开发框架 = HarmonyOS
具体到示意图,估计就是:
从分析结果来看,HarmonyOS有些地方确实夸大宣传了,比如:
-
随时换掉AOSP,这里的「随时」,估计在近五年内不会实现,在此之前,去掉Android虚拟机,HarmonyOS能不能正常运行,我是持怀疑的态度的
-
「全场景分布式操作系统」,根据「分布式软总线」相关代码,这里的「全场景」,估计是同一个局域网内的「全场景」、同一个局域网内的万物互联
当然,对于HarmonyOS的绝大多数宣传,按目前的设计思路,完全有可能实现或者已经实现了,比如:
- 由于Ability、分布式软总线等技术屏蔽了操作系统差异,一点点挖空、取代AOSP是完全有可能实现的(虽然我认为这个时间会持续5-10年,到时候Android、HarmonyOS存不存在都不能确定)
02 HarmonyOS到底是不是Android套皮
回到我们最初的问题:「HarmonyOS到底是个全新的自主操作系统还是个套壳安卓?」
分析完代码后,我发现我也不能回答这个问题:
说它是吧,它也确实是从Android发展出来的
说它不是吧,它也确实和Android有了明显的差异和特色
不过这时候,我发现这个问题和一个提出了2000年的哲学悖论很像:忒修斯之船
特修斯之船(The Ship of Theseus)亦称为忒修斯悖论,是一种有关身份更替的悖论。假定某物体的构成要素被置换后,但它依旧是原来的物体吗?说是一艘可以在海上航行几百年的船,归功于不间断的维修和替换部件。只要一块木板腐烂了,它就会被替换掉,以此类推,直到所有的功能部件都不是最开始的那些了。问题是,最终产生的这艘船是否还是原来的那艘特修斯之船,还是一艘完全不同的船?如果不是原来的船,那么在什么时候它不再是原来的船了?
回到这个问题:
我替换掉Android一行代码,那么它还是Android吗?
我替换掉Android一个模块,那么它还是Android吗?
我给Android添加一个模块,那么它还是Android吗?
…
这个问题哲学家辩了两千年,相信我们这一时半会儿也辩不出来,而且争辩这个问题也没有太多的意义
所有我们不如抛弃这个问题,换一个新的问题,也是我们更关心的问题:「HarmonyOS能实现华为在华为终端上定下的目标吗?」
03 HarmonyOS能实现华为的目标吗?
这部分本来想讨论HarmonyOS的发展前景以及能不能取得成功。但是想要看清这件事,需要扎实的理论知识、丰富的行业经验,还要对商业活动有一定的见解,有这个能力的人,早就是行业泰斗、技术大咖了。
所以找了几天资料依旧没什么思路,因此想悄悄咪咪的把这个坑给鸽了。但没想到看得人这么多,这下都不知道怎么鸽了,就只能强行人云亦云一波。通常来讲,影响一个商业操作系统成败的因素有很多,但大体上都是从三个大方向进行分析:系统优势、商业运作、生态建设。那么我们也从这三个方面探讨一下HarmonyOS有没有可能成功。
00 系统优势
目前HarmonyOS有两个独有的特性:
1、一个跨平台的JavaScript应用框架(后面我们称之为Ace Engine,理由在下面)
2、分布式软总线
这个JavaScript应用框架是Ability的最重要的组成部分之一,写00-02时没有仔细看这部分的代码和文档,写的不太清楚,现在将补充内容写到这里,就不修改上面的内容了,这些补充内容也能解答评论区的一些疑问,补充内容如下:
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引擎外,其他应该都是华为自己写的
-
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的嵌入式操作系统部分就不说了,玩过物联网的都知道,现在市面上的竞品有很多,除了华为的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(分布式软总线)呢?且不说开源方案本来就有很多,就是从零开始实现,目前国内能做到的公司数量数起来,只怕两只手两只脚都不够用。
那么依靠这些,华为能够为HarmonyOS培育出自己的物联网生态吗?我个人的观点是悲观的。
Android进阶资料
以下的资料是近年来,我和一些朋友面试收集整理了很多大厂的面试真题和资料,还有来自如阿里、小米、爱奇艺等一线大厂的大牛整理的架构进阶资料。希望可以帮助到大家。
Android进阶核心笔记
百万年薪必刷面试题
最全Android进阶学习视频
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》,点击传送门,即可获取!
utter的设计思想与架构完全一样,Flutter由于Dart虚拟机无法运行中资源有限的嵌入式设备中,无法做到,那小程序对比如何呢?
以目前拥有最大生态的微信小程序为例,自诞生之日起,就支持Android、IOS、HarmonyOS(由于兼容Android),而又由于WMPF(Wechat Mini-Program Framework,小程序硬件框架)的存在。
目前微信小程序也可以运行在Windows、Mac、嵌入式设备上,基本覆盖了Ace Engine的所有设备(HarmonyOS、嵌入式设备)以及Ace Engine不支持的设备(IOS、Mac、Windows)。
至于CoAP+RPC(分布式软总线)呢?且不说开源方案本来就有很多,就是从零开始实现,目前国内能做到的公司数量数起来,只怕两只手两只脚都不够用。
那么依靠这些,华为能够为HarmonyOS培育出自己的物联网生态吗?我个人的观点是悲观的。
Android进阶资料
以下的资料是近年来,我和一些朋友面试收集整理了很多大厂的面试真题和资料,还有来自如阿里、小米、爱奇艺等一线大厂的大牛整理的架构进阶资料。希望可以帮助到大家。
Android进阶核心笔记
[外链图片转存中…(img-58cisfYd-1715834801196)]
百万年薪必刷面试题
[外链图片转存中…(img-GHhFmUD5-1715834801198)]
最全Android进阶学习视频
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》,点击传送门,即可获取!