HarmonyOS到底是不是Android套皮？

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-HmReBjDo-1715313572165)]
百万年薪必刷口试题
[外链图片转存中…(img-mleaTYrI-1715313572168)]
最全Android进阶学习视频
《Android学习笔记总结+移动架构视频+大厂口试真题+项目实战源码》，点击传送门，即可获取！

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。