HarmonyOS 2.0公测版本已经发布，当然内测版本是可以直接升级的，我也第一时间升级了公测版本。
先说使用体验再解析：流畅度没发生变化，原神、王者游戏耗电和流畅度没任何区别，运行内存占用反而变多了（没有变少）。
再说大致分析：通过解析鸿蒙OS2.0的目录结构，我们发现鸿蒙OS 2.0整体是AOSP 10的深度定制，使用了Android Q的相当一部分内容。
接下来是组件和应用的分析：
libart与Android 10 AOSP（r7）上的完全一样，相比EMUI11反而没有进行特殊的改动，具体原因不明。
framework当中，安卓的framework部分是没有变化的，我们重点关注鸿蒙的framework。鸿蒙的framework独立于安卓的framework（framework.jar）之外，集成在boot-zframework当中。而华为的boot-zframework的vdex文件是特殊编码，因为修改了加载机制，文件头和结构跟普通安卓不同，因此需要特殊的读取和转换方式转换为原始dex。
解包鸿蒙自主的框架，可以看见ohos的包下面有鸿蒙的Ability、Application等等类似安卓Activity和Application的组件，并且加载也不是通过安卓的framework进行加载的，而是使用了鸿蒙自己的框架（但是应该是安卓框架使用适配器模式代理各种事件）。
但是，这些框架与系统服务通信，分析以后发现依然依赖安卓的服务，包括窗口管理服务、显示服务以及服务所依赖的安卓硬件抽象层。
解包鸿蒙的hap应用，可以看见里面包含一个apk，经过逆向分析，里面包含的apk不包含任何实质意义的代码、资源，仅供别的安卓应用识别。例如别的安卓应用可以通过getPackageInfo来获取鸿蒙应用的信息，实际上获取的是壳（Shell）应用的信息，而不是真实的鸿蒙应用信息，因此鸿蒙应用并不是使用安卓应用框架的。
打开鸿蒙应用以后，发现鸿蒙应用加载jar或者dex有限制，不能将jar或者dex放到数据目录动态加载。为了解决这个限制，我们hook openDexNative函数，具体是在C层实现，同Android Q，不多介绍。鸿蒙应用开发的SDK屏蔽了安卓的各种组件，包括libcore、framework，libcore、art等等，华为框架的限制可以在C层解决。
这里下个结论：鸿蒙OS 2.0严格意义上来说是基于安卓10开发的一个操作系统，内置了安卓和鸿蒙的框架。
鸿蒙框架应用是上层应用，底层依赖鸿蒙框架、安卓的框架等等。而安卓应用则依赖包括安卓framework在内的所有安卓组件，内存dump里面可以看见有鸿蒙的框架，但是没有实质使用或者调用。
而HarmonyOS 2.0所说的替换安卓是指替换安卓的framework，不包括替换art、services、libcore等等组件，也就是说仅实现了安卓的framework（虽然现在还是适配器模式，依赖安卓的框架），没有实现别的轮子。
有个有趣的地方，安卓沙盒内可以通过特殊手段加载并启动鸿蒙应用，但是需要自己实现鸿蒙的所有接口和服务。对于Sample里面的应用来说，我实现了Ability、Application以及tryLoadHarmony方法就能加载应用，实现服务管理就能使用跨进程通信以及一些基础数据库服务功能，通过代理鸿蒙的窗口管理类、实现内部类似Button等组件的类，就可以启动并显示hap软件的内容。注意安卓应用模式下是无法获取鸿蒙应用的真实安装包路径的，只能获取壳包路径，可以使用免安装模式来加载。

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！