如何看待 9 月 10 日华为发布的鸿蒙 OS 2.0 系统，应用前景如何？ 第1页

首先要先明白，操作系统是什么？

操作系统是一组主管并控制计算机操作、运作和运行硬件、软件资源和提供公共服务来组织用户交互的相互关联的系统软件程序，同时也是计算机系统的内核与基石。——维基百科

然后，再阅读 @赵俊民 大大的一些文章：

以及去年鸿蒙刚发布时我写的回答（不要脸一下哈哈哈）：

然后你大致就能明白，什么“鸿蒙是Android换皮”、“鸿蒙不就是垃圾LiteOS改的嘛”、“鸿蒙还不如YunOS”，等等，完全黑不到点子上，因为鸿蒙OS之所以称为“分布式操作系统”，是因为它的愿景是成为一个可以整合、管理多个设备的硬件、软件资源的系统。有兴趣的人可以多看一些前几年的OS顶会论文（为啥不是最近呢？因为最近基本都是AI相关的/捂脸/捂脸/捂脸）。

举个例子，上面的我去年的回答里提到的论文，里面有个概念叫split kernel，方便理解中文我就直接翻译为分布式内核吧（对不起英语老师！）。在实现时，作者是基于Linux修改的，兼容POSIX接口。那么，它到底是split kernel，还是linux kernel？从底层看，它每一个资源组件都是跑着linux kernel，但作为一个整体的操作系统，它是split kernel。也就是多个linux kernel组成了split kernel。

更新：对于SplitKernel，知乎上也有挺多文章解读，对于体系结构、OS感兴趣的可以去查阅一下。国内大厂例如阿里云、腾讯云对于这类系统的研究还是非常强的。

同理，在我个人的理解里，鸿蒙整体也是类似的这种架构。所以，它包含了LiteOS、安卓系统、Linux以及华为所说的微内核。另外，这些东西，在官网的文档里说得很清楚了。

关于它所展现的愿景，大家从华为现在已经很成熟的多屏协同能体会到一些。

更新：M2的论文（MobiSys 2019）演示视频，鸿蒙不一定可以做到下面那样，但是我觉得有助于理解。

看了一晚上的文档和代码，我不想讲细节，而且我本来不打算回答这个问题的，但是，看完很多回答，总有一种很奇怪的感觉，那就是：完全没有黑在点子上。

不谈立场（这个我也没必要谈，先入为主的思维已经没有意义了）的话，对于鸿蒙的开源，只取决于你是结果导向还是过程导向的人。

而且，就算再怎么黑，舆论导向早已形成，鸿蒙现在也已经有了很多厂家在对接、完善，虽然前途依然模糊，但是对于乐观主义的我，已经够了。

对于现在的大家提到的问题，我大致说一下我的理解。

首先是最受争议的那个导入了Android SDK的问题：

首先，这个图片里的东西，是鸿蒙APP的SDK，不是OS代码，OS代码在gitee上的一百三十多个repo里，基本都是C语言写的；其次，鸿蒙需要兼容Android应用，那就会有一个应用间的交互，可以看到图中class叫AbilityShellProvider，继承Android的四大组件之一ContentProvider，这明显就是一个为了兼容Android而写的兼容层代码，没有任何问题。如果直接发这个图，还开始嘲讽，我觉得没有必要去理会这种人了，没有相关的知识积累就算了，独立思考的能力也没有。

然后是如下的图：

红框圈出来的地方，也出现了Android字样。但是，仔细看这个stack trace，你就会觉得不对。因为Android相关的调用只在中间，下面依然是libcore，而且图中调用链是Android->libcore，为了兼容Android，总要用libcore吧？所以这明显也是兼容层代码。

（libcore部分我的描述不准确，这个部分我也不修改了，我可以正视我的错误。但是“兼容层”的看法依旧不变，等我晚上回去补充完整。谢谢你们让我有动力来继续分析/微笑）

既要兼容Android，又要SDK里完全不出现Android的字样？

然后我大致都看了一下SDK的内容，里面引用了Android相关内容的包叫abilityshell_ide_java.jar，这个包的功能会在编译出来的.hap包中有所体现（以后细说）。

更新：对于引用了Android SDK的问题，我的分析结果和如下的回答基本一致，我就不细写了。我发现我被某些人带跑了，我不是来争论这个问题的。

算了，还是补充一下吧。

编译出来的.hap包中包含一个classes.dex和一个.apk文件，其中最外层的classes.dex不知道为啥不能直接反编译。

不过这个是小问题，说到底.dex文件只是一种应用格式。实际反编译出来的结果中，就是我们在项目中写的代码，而且没有任何Android相关的符号：

而那个.apk文件是一个正常的安卓程序格式，查看反编译后的结果可以知道，这是根据项目代码自动生成的，并且里面其实不含任何逻辑代码。它可以安装，但是因为缺少系统支持依赖所以无法运行：

如上，会自动生成两个类，和项目里的Ability类相对应。项目里的MainAbility对应MainAbilityShellActivity，继承自AbilityShellActivity；项目里的MyApplication对应ShellMyApplication，继承自HarmonyApplication。

AbilityShellActivity和HarmonyApplication来自SDK里的abilityshell_ide_java.jar这个依赖，但是编译出来的整个.hap文件中这些符号都没有另外出现了，所以实际上这个.jar包只在开发时会用到，实际跑起来需要系统的支持。类似的还有叫ace_ide_java.jar，名字里带个ide估计也是这个原因？

然后我们细细研究一下abilityshell_ide_java.jar里的东西：

可以看到，安卓中的四大组件，这里有三个（Activity、ContentProvider和Service，气抖冷，我们BroadcastReceiver什么时候可以站起来！），并且还有一个Application的子类HarmonyApplication。

AbilityShellActivity、AbilityShellProvider、AbilityShellService的实现都很简单，就是有一个叫XXXDelegate（SDK里找不到实现）的成员变量delegate，然后所有的方法都会被委托给这个delegate，代码实现太过规整，我都怀疑是Lombok的@Delegate自动生成的。如下图：

看到这里已经可以说明，鸿蒙不是另一套基于Android的UI库或者直接Android改名，因为没必要实现这么绕。

然后重点是HarmonyApplication这个类，和另一个大佬的分析一样，一眼能看到的就是会有一个IPC相关的动态库加载：

然后其他部分的代码反编译后加起来不到300行，也很简单。总的一句话就是，会创建一个加载鸿蒙Application的<del>进程</del>线程（另外加载多个Ability？），然后这个安卓Application实例会和这个鸿蒙Application实例绑定在了一起（同生共死）。

更新：根据与 @dontpanic 的交流，修改了鸿蒙“进程”相关的描述，鸿蒙程序目前是依赖于安卓进程来触发的。

更新：基本可以确定鸿蒙有自己的图形栈服务，不是用的安卓的SurfaceFlinger，名字叫AGP，SDK包里也有相关的东西，不过这个全称是啥不清楚，A(?) Graphics P(Processor?)？例如在ClickedListener里直接抛出异常，可以通过stack trace发现event最终交由AGPEngineAdapter来进行处理，最后通过native调用dispatch到我们写的事件处理函数；而在delegate里的convertTouchEventThenDispatch方法，将安卓的event转为了鸿蒙的event；delegate里估计还会有对于图像绘制的一些转换：

所以现在可以猜测的是：

1. 目前鸿蒙应用都会有一个安卓的Launcher apk，这个apk用于从系统中启动整个程序；因为它更像一个代理，我们就叫它proxy进程吧；
2. proxy进程会创建、启动运行鸿蒙程序的harmony线程，加载、创建鸿蒙程序的对象，并且proxy进程通过委托delegate将鸿蒙应用整体表现得像是一个Android应用，以便于和原生Android程序进行交互；这就是“兼容层”的意思；
3. 图像绘制、事件处理等最终转交给AGP服务；类似地，其他的安卓的Service Manager估计鸿蒙也有对应的；
4. proxy本身没有其他的逻辑代码，它的作用就是做为鸿蒙和Android之间的桥梁；
5. ipc的动态库的用途还不清楚；
6. 这个实现方式有一些绕，而且很明显是一个过渡方案。

以下截图可以佐证，第一张是调试时的UI线程：

然后是鸿蒙应用的加载线程栈：

因为这次开源的东西并不包括手机上的鸿蒙，对于Android SDK的问题，我就分析到这里了，我已经把我想说的说清楚了。

如果要黑，不管立场怎样，请有自己的主见，不要为黑而黑。例如我就很欣赏下面的文章，我也学到了很多东西：

另外，我也可以提供正确的思路：

1. 我看过了的代码里，基本都是采用Apache License 2.0协议，作为国产之光为什么不像去年的方舟一样采用木兰协议？（这个要加个狗头）
2. 之前说的微内核到底是哪个呢？
3. 开源的东西太乱了，一百多个让人怎么看得完？文档比去年方舟有很大进步。但还是不够详细啊！
4. 越看越像QNX，相对于QNX有什么进步吗？

SDK还有一个有趣的地方：

这估计是方舟编译器的支持，@Permanent等注解用于RC标记吗？以及真的有一个用于热更新的ClassLoader！

有空我再写写其它东西，顺便分析鸿蒙中安全相关的内容。