正常应该写个危机，但实在是想不出来有太多的机，也可能是别人都让提前说完了，我也就只说下风险吧。

先声明，现在的鸿蒙2.0手机Beta版本是没有真正的原生应用，至于正式版本2.0会不会有，我只能说按照业界的经验，是不太可能有的。虽然说Beta版本，有可能加入一些新功能，也可能删除一些已有的功能，但对于一个开发工具，在Beta都没有提供原生应用的开发功能，在Release版本却加上，我印象中还没有这个先例。哪怕是最烂的Visual Studio2000 Beta版本也没干过这事，那是首个支持.Net的开发工具，测试版奇烂无比。


兼容Android的风险

很多人都强调要兼容Android，否则前期没有生态，没有这些APP在上面的运行，哪里还会有人用华为手机，听起来很有道理，我来说说兼容Android带来的风险：

  1. 目前开发Android App主要还是使用Java语言（也有部分Kotlin，以及使用C或者C++等开发的），而目前看到的鸿蒙手机默认主要也是使用Java语言，那么完全有可能会被国外起诉的，最大可能性就是Oracle（参见Oracle起诉Google，要赔88亿美元，理由是使用了Java，但是并不兼容JVM，脱离了J2SE等标准，有兴趣的同学可以自己去翻法律判决，其实在这之前，微软的Visual J++已经输过类似的案子了），从法律上看，也就是说使用java开发以及兼容Android，基本上是没法在海外卖手机了（虽然现在卖不了，但只要这样使用Java和Android，可以说是给未来在海外的业务埋了一个必爆的雷）。很多人会说，Google没有起诉华为是鸿蒙自主研发等。我先不讨论Oracle/Google有没有权利起诉华为这些过于专业的东西（涉及Linux和AOSP的开源协议，还有Java一堆东西）。就说Google被Oracle起诉的细节。2003年Android启动，05年Google收购，07年开始测试，08年正式发布，09年正式出手机，而Oracle是在10年才开始起诉（09年收购的Sun，获得Java产权）。也就是说，国外公司不傻，也肯定是考虑到利益最大化后才会出手起诉，而不是一开始就打上门。退一万步说，就算Oracle和google不起诉华为，谁能保证Oracle万一被收购，就不会有公司来起诉华为呢（Google当时肯定没想到这么多，所以。。。现在看，还不如当时Google收了Sun，哪怕是借钱收购）。
  2. 如果持续兼容Android App，那么几乎可以肯定，没有几个公司愿意给鸿蒙开发专用版本，因为需要太多的成本（不要觉得开发个程序很容易，后面的维护，客服等一堆问题，相当于把现在的一个公司手机团队开发成本直接添加50%甚至更多，毕竟是新开发的，成本可能极高）。这种情况下，何谈建立生态。更不用说，很多Native App依赖Unity这些第三方库，它们不支持的话，小公司自己想移植APP也根本就无从谈起。
  3. 很多公司为了保持用户体验，都会将iOS和Android两个平台上应用的界面风格等统一（往往是向iOS上靠），根本不会考虑Android建议的Material Design设计风格。而如果鸿蒙自己的控件等定制性不足，很难向公司自己的应用风格看齐，那么公司大概率是够呛用鸿蒙自己的API来开发应用。
  4. 安卓里还有一类应用，就是基于NDK的应用，这类应用可能是因为性能要求，或者是安全要求，要保证应用的一部分内容能够不被反编译，通常使用机器码运行，比如某一段加密算法，厂商肯定不想用Java写，太容易反编译了。支付及金融类的APP普遍有这个需求，所以如果鸿蒙不支持NDK，估计大量厂商是不会考虑开发鸿蒙应用的。


所谓微内核的问题

先声明，我对微内核确实不是专家，只是一个能够了解基本原理，能勉强看懂代码，但并没有能力写内核代码的程序员。所以我说的东西，更多只是原理以及基本逻辑的内容，如果有误，可指出。

在华为对鸿蒙的宣传里，提到了鸿蒙的微内核，也提到了交大陈海波老师的一些技术，比如XPC和SkyBridge，这两者都是用来提高微内核一直以来被人垢病的IPC性能问题。我翻了这两篇论文，分别是《SkyBridge: Fast and Secure Inter-Process Communication for Microkernels》《XPC Architectural Support for Secure and Efficient CrossProcess Call》。两篇文章完整看下来，发现这两个方案都有一个共同点：依赖于硬件。

  1. SkyBridge是在Intel的CPU上做的验证，不知道SkyBridge和SkyLake有没有关系。原文是： Second, SkyBridge leverages one Intel hardware feature for virtualization, named EPT (extended page table) switching (the VMFUNC instruction), to change the virtual address space at the user level.
    解释一下，也就是说这个解决方案只在Intel的CPU上验证过，有点奇怪，为什么不一开始就在ARM CPU上验证。（我个人猜想应该是ARM的虚拟化技术可能不满足该方案的某些前提条件，我对这块的技术所知甚少，只是猜想，也可能是arm的虚拟化技术不够成熟，毕竟起步要晚很多）
  2. XPC则是通过新的硬件原语来加速调用，称为跨进程调用，这个是需要对CPU做一些改造。论文是在Risc-V上设计原语并验证的。原文如下： In this paper, we propose a hardware-assisted OS primitive, XPC (Cross Process Call),for fast and secure synchronous IPC. XPC enables direct switch between IPC caller and callee without trapping into the kernel, and supports message passing across multiple processes through the invocation chain without copying.
    好吧，又不是arm，我估计是因为arm现在的CPU架构已经太复杂了，验证成本太高，所以在相对简单的RISV-V架构上实验，这个很合理，没什么可以指摘的。

至于这两种方案是否具有可行性，玩微内核的同学会有更准确的判断，我就不细分析了。
我来简单说说这两种方案的问题：

  1. 都没有在arm上做验证，从实验室验证到真正的应用，中间的难度有多大，做技术的人都知道，最终是否可以真正应用，是具有极高不确定性的。
  2. 两个方案都依赖于硬件特性（事实上过去的微内核优化也很多是这个思路），那么如果arm的CPU体系不支持该方案的硬件特性，那么也就没什么好说的。因为华为现在也没有办法自行设计并生产高端手机CPU了（我不确认麒麟9000有没有这个特性，但估计够呛）。
  3. 这两个方案都依赖于硬件特性，如果arm的CPU体系不支持该方案的硬件特性，那么就算某一天华为能自产CPU，恐怕别的厂商也没法跟进（可以考虑到海思和鸿蒙独立出来，不能又做裁判员，又当运动员）。
  4. SkyBridge方案太依赖Intel的CPU特性，未必可移植。
  5. XPC方案，怎么说呢，它还需要一个Root Kernel，同时还需要对大量的硬件做一堆的可适配性处理，了解黑莓的同学应该有更清楚的认知。这些工作量恐怕都不是短期的。更关键的是在XPC方案里，有Root Kernel和Micro Kernel，如果鸿蒙兼容安卓，估计在很长一段时间里还会有Linux的存在。好吧，三个内核协作，会是桃园结义还是三个和尚，我也不知道答案。

最后邀请一下 @某用户 @CC88 ，麻烦两位看看，你们所说的开源Harmony OS代码里有没有明确告诉大家微内核的IPC方案是什么？作为一个你们口中不懂底层系统 的Java程序员，只好请教你们了。
特别是 @某用户 你可是一直坚持说，已经开源的鸿蒙代码和现在正在进行Beta测试的鸿蒙手机OS2.0是一套代码。

我也真是醉了，文章发给华为论坛上，竟然得到如下两个回复：

一看就知道不是开发人员：谁家测试人员或者消费者提个问题或者建议，还得带上解决方案的。再说，就算我给了解决方案，比如模仿Google开发个Flutter，或者使用Kotlin语言，估计还是被喷。



我感觉这位的意思是：如果我技术水平不如华为的专家，管理水平不如华为的高管。我就不能提建议，因为你水平不到，不理解。
对于盗窃这种说法，太严重了，只好在这里声明一下，不是盗窃，是原创，而且是我一个人。