先说结论，鸿蒙系统不是安卓套娃，华为近几年是有在做实事的。为什么这么说呢？各位请往下看。
作为一个业余app开发者，曾经开发过几个安卓App(原生、uniapp、flutter都有)，也研究过React Native，今天刚得知华为的鸿蒙2.0beta的开发工具释出了，就尝试了一下。
鸿蒙的IDE（集成开发环境）DevEco Studio是基于IntellJ IDEA开发的，这是一款非常优秀的IDE了有着非常优秀的代码提示功能，而安卓的IDE --Android Studio也是基于IntellJ IDEA开发的，这俩IDE算是同源了，所以操作逻辑上对于安卓开发者非常熟悉。
不过这个IDE其实在电视版鸿蒙释出的时候就发布了，现在终于能用它来开发手机应用了。
开发应用可以使用Java、Javascript、C。对于安卓开发者来说，鸿蒙的项目结构和安卓十分类似。使用C编程也类似于安卓的NDK，但是提供了很多特色的API。而使用Javascript开发则和微信、支付宝、QQ小程序类似，如果开发过小程序，只需要短暂学习便能掌握鸿蒙应用的开发。但是鸿蒙有很多安卓没有的特色功能比如计算机视觉、二维码扫描都被直接封装成了系统内置的接口，可以减少第三方SDK的使用、加快开发速度。Java、Javascript的支持极大降低了开发者门槛，只要经过短暂的了解，小程序和安卓开发者就能直接上手鸿蒙开发、可以说是十分有诱惑力的。
但是对于Java的支持和安卓如此像，也不免让人怀疑是否是安卓的套壳。我也带着这个疑问继续研究下去。
我根据官方提供的文档和模板编译了一个使用Java开发的App，并成功运行了起来
不过比较有意思的是，不同于安卓开发，可能是因为相关工具还没做完。App并不是运行在本地虚拟机的，而是一个远程设备。很可能我写的App是真正的运行在一台支持鸿蒙的设备上或是远程虚拟机上。打开远程设备的关于手机：
设备名为P40，不过不清楚这是位于服务器的P40虚拟机还是一台和P40同硬件环境的真机。
查看IDE的输出，我可以看到App打包后被放在了项目目录的entry/build/outputs/hap/debug/entry-debug-unsigned.hap下，按照传统打包惯例，我将文件后缀名改为zip，成功打开，里面有几个文件
第一个文件夹叫assets，从名字上看是资源文件，里面的内容也确实如此
第二个是一个apk，我解压后尝试在普通的安卓手机上安装，发现能够成功安装，但是启动会立即闪退。这个东西到底是干什么的呢，使用jadx（一款用来主要反编译安卓App的软件）打开APK，发现这个apk里确实蛮空的
看代码应该是用来启动应用的入口，但是暂时还不能确定。不过经过对远程设备的研究发现，这款远程设备会在我的本地创建一个支持adb的设备，我试了一下，发现能够直接使用adb调试这个设备。既然能够支持adb，我有个大胆的想法：开发者可以通过adb根据应用的包名将app打包回apk，那么我将一个鸿蒙App打包会有什么结果呢？如果打包成功并在其他手机上安装，岂不是说鸿蒙App就是安卓App？于是我尝试打包App
adbshell pm path com.example.harmonyproject1adbpull xx/xxx.apk ./
第一条命令中com.example.harmonyproject1是我App的包名，在执行第一条命令后将会输出apk保存的目录， 接着使用第二条命令将打包的App拉取到我的电脑（xx/xxx.apk是第一条命令输出的目录）。打包成功输出了一个apk，但是看着这个apk我陷入了沉思，这东西太小了，明显不是一个App应该有的大小
不过这个大小和解压得到的entry_signed_entry.apk大小一样，这不会就是同一个东西吧？于是我对比了一下两者的hash值
可以看到MD5、SHA1、SHA256的哈希值完全一样 可以确定是一个东西了。也就是说这个apk，应该是类似于安卓系统中启动鸿蒙App的入口。不能说有这个APK就是安卓套壳了。
第三个是config.json，从名字上看是一个配置文件，打开后查看，发现记录了诸如包名、App图标之类的配置。
config.json
第四个是classes.dex，安卓开发者们肯定知道，dex文件是安卓的Java虚拟机--ART的字节码文件，每一个安卓应用的逻辑代码都会被打包为一个或多个dex文件，在App启动时被加载进虚拟机。我使用jadx打开这个dex
打开后可以看到熟悉的代码了，上面的是DEX文件反编译的内容，下面是App真正的源码
几乎一模一样 ，看样子真相大白了：
鸿蒙的HAP文件中的entry_signed_entry.apk，是安卓系统中的一个App，在目前的鸿蒙2.0中，安装一个鸿蒙应用会同时安装这个APK，我们在桌面上点击App图标，会经过安卓系统启动entry_signed_entry这个app，这个App启动后会通过某种方式让操作系统运行真正的App代码，也就是HAP文件中的DEX文件。
但是这时一个问题出现了，某种意义上说DEX文件是安卓的Java运行时--ART的专属格式。那么这个DEX，是运行在ART中的，还是鸿蒙又自己实现了一个ART呢？这一点还很难知道，不过我认为ART经过多年发展，华为很难去在短时间内做出一个超越ART性能的Java虚拟机，程序的逻辑本身大概率还是运行在ART中，不过和大部分安卓App的启动方式不同。但是即使这个DEX是运行在ART中，也不能说鸿蒙是安卓套壳，因为ART只是提供了一个运行时，并不实现系统调用比如UI渲染等、3D，我们可以在鸿蒙的文档看到鸿蒙在ohos包中提供了一些有关图像渲染的API，另外还有一些安卓没有的API，这也是鸿蒙的优点了。
通过分析，可以看到鸿蒙确实是做了很多东西的。但是很显然鸿蒙中还存在着很多对安卓本身的依赖而非为了兼容安卓必须做出保留的东西。鸿蒙才刚刚开始，离真正的成为一个独立的操作系统还有很远的路要走。
如果觉得《鸿蒙系统是不是安卓套娃？这篇文章告诉你答案》对你有帮助，请点赞、收藏，并留下你的观点哦！
