以下观点仅代表个人立场，可能并不一定准确，仅供参考。
1、鸿蒙首先必需承认它是一个全新的操作系统，但它也是建立在无数前辈的基础之上的，所以将它与其它操作系统隔裂的任何做法，都是不正确的。
2、鸿蒙底层是不同的操作系统内核，然后在内核上层加了一个抽象层，将操作系统的内核功能抽象出来，从而使上层应用达到与操作系统内核无关的目的。这样，基于鸿蒙开发的应用，就可以在不同的操作系统核心上工作。这里从两个视角来看：
- 以内核视角，鸿蒙的内核抽象层（KAL）可以认为是一个鸿蒙虚拟机，所有的上层都是运行在这个 KAL 虚拟机上的。所以，说鸿蒙是 XX 套壳，也不是说完全说不过去，只不过是内核套壳。
- 以 KAL 视角，各个操作系统核心相当于鸿蒙的驱动，就如 Windows 的硬件抽象层一样。
3、由于鸿蒙实现了一个 KAL，那么理论上，内核可以是 Linux、LiteOS、FreeBSD（MacOS 基于 FreeBSD），甚至 NT 内核，所要做的，只是对 KAL 的适配。对于商业操作系统内核，比如 MacOS、Windows，官方纳入的可能性几乎为 0，只是想想罢了。当然了，可以曲线救国，比如在 Linux 内核上套一个 Wine 做为一个内核，模拟 NT 核心或者是用某个开源的实现（我记不住名字了）。
4、同样是因为这个 KAL，那么实际上就能相对轻松实现跨不同设备平台运行的问题。这里，我们关注一点，因为 KAL 的一致性，那么只要是同一指令集，不同平台的软件，我们理论上只需要编译一次，就可以在不同的设备上运行。
5、基于 KAL ，如果在 KAL 上层，提供一个二进制指令集的翻译，在程序安装时，由方舟多语言运行时子系统翻译成对应的原生指令集的可执行代码，最终高效执行的问题。当然也可以像龙芯一样，进行指令集实时翻译执行。这样就可以做到一次编译，不管架构的目的。我不知道这个目标是否在鸿蒙的规划中，不过是个人的畅想，希望鸿蒙的未来会纳入类似的规划，这才能体现鸿蒙真正野心的地方。有了它，应用层在多设备上运行，需要调整的也就是一个 UI 布局的问题，这个对于多设备开发来说，简直就是一个致命的诱惑。
6、至于系统服务和框架层，这个就不需要说了，它们起承上启下的作用，只是用来简化开发过程的工具。理论上来说，没有它们，也是一个完整的操作系统，但有了它们，才是真正可用的操作系统，各种服务就是为简化开发和代码重用服务的，系统服务层和框架层实现的功能越丰富，上层应用的体积和重复代码就越少，开发速度就越快。同样的，中间这两层优化的越好，应用的运行效率和体验就越好。对于这一层，唯一操心的就是留给华为的时间太短了，可能会存在赶工的现象，存在优化不到位或者没有注意到的 Bug，影响开发和用户体验。Android 的开源实现 ASOP 应访是工作在这一层的，所以说鸿蒙是 Android 套壳的说法，只是从 Android 应用的视角往下看，只看到了 ASOP 这一层造成的。从 Android 应用的层面来看，确实底下是一层开源的 Android 实现，至于更底下的 KAL 和 Linux 内核，那个对 Android 上层应用是看不到的。
7、鸿蒙的打包格式 HAP 目前采用了和 APK 类似的格式，实际上是一个压缩包。象现在许多格式都采用了这种方式，比如说微软的文档，这个实际上只是一个取舍的问题。设计一种自己的打包格式并不难，象这种压缩包，实际上内部的内容才是关键，外包装重要也不重要，内涵才是关键。
8、鸿蒙现在的推广语言实际上集中在服务和框架层，分布式软总线等等，确实不错，但恐怕真正的野心在于统一操作系统。KAL 实际上是把现在的操作系统内核，当成一个黑盒子，内核变成了一个可以替换的选配。
9、鸿蒙的元服务和元程序，提供的是一种元能力。这个又是对软件功能的一种抽象，是面向对象的一种思想的体现，软件即服务，统合后，理论上可以方便的跨语言调用。分布式总线等服务在这些里，又变成了基础的存在，从而实现功能和交互的分离。换个说法，就是你的程序实际运行在手机上，但它的交互却在电视或智能手表上，而电视或手表上，并不需要真正安装这个程序，它只是类似于 Linux 中 X-Server 和 X-Client 的关系。计算能力被剥离出来，这样可以做到各取所需，各献所能的目的。这种设计，很考验华为对分布式的各种能力的底层优化功底，易用和好用之间的差距还是很大的，努力吧，少年。
10、对于鸿蒙生态来说，2021 年是很关键的一年，手机版本的推出，成为真正面向几亿用户的大考。优化和体验到位，后面就会顺风顺水，各种打压也会烟消云散，所以还是那句话，加油！
11、对开发者来说，鸿蒙是一个处女地，如果你看好它，那就该及时介入。就象一个赌局，牌已经发完了，就看你自己筹码放在何处。
12、对于 Delphi 开发者来说，理论上来说，做鸿蒙上运行的程序，可以首先把它当成 Android 应用来开发，ASOP、HMS 这些都是可以同时在 Andorid 和鸿蒙上用的，所以在 Idera 官方支持鸿蒙之前，这是一个解决方案。另外，鸿蒙本身提供的接口，有基于 C/C++ 的版本，翻译成 Pascal 代码并不难，只是工作量有点大。再就是交叉编译的问题，Delphi 本身提供了 DCCARM 编译器，链接成可以执行的 ELF 这块不成问题，也就是说工具链这块实际上问题并不是很大，需要做的是将程序打包成 HAP 格式的问题，本质上，前面说了，和 APK 的封包格式两者都是 ZIP，只是目录结构有所变化，因此也不存在特别高的难度。就目前来说，这个是有实力的朋友可以考虑的问题。
13、中美之间的冲突，本质上是发展权的冲突，老大当惯了，绝不当老二的零和思维作祟，眼中一切有可能超过自己的都是敌人。所以指望中美冲突迅速合解的可能几乎为零，像朝鲜战争末期，打打谈谈才是主流。这个过程可能会持续很长时间，做为开发者，是不可避免的卷入到其中，想要两耳不闻窗外事，一心只要码代码是越来越难了。所有人都应该做最坏的打算，争取最好的结果。