关于鸿蒙有很多问题：鸿蒙到底是不是安卓套壳？鸿蒙应用是小程序吗？开源鸿蒙就是一个物联网系统，和鸿蒙无关？只要搞清了鸿蒙的发展史，你的心里就会有答案。
一、OpenHarmony 就是一个物联网系统，跟 HarmonyOS 完全不是一个东西吗？
这个说法在 API8 之前有一定道理，从 API8 开始这个说法就不准确了。在一开始，OpenHarmony 只有 JS API，而 HarmonyOS 不仅有 JS API，也有 Java API，而且两边的 API 也不完全一致。这就让两边的生态不能共享，非常尴尬。
从 API8 （对应HarmonyOS 3.0 版本）开始，HarmonyOS 和 OpenHarmony 实现了 API 统一，HarmonyOS 4.2/HarmonyOS NEXT 的 SDK 就直接采用了对应版本的 OpenHarmony SDK。HarmonyOS 应用想在 OpenHarmony 上运行，只需要在配置文件中修改一个字段即可。两边的生态是统一的，这就是鸿蒙宣称的“统一生态”。
现在的情况是：HarmonyOS 4.2/HarmonyOS NEXT 是 OpenHarmony 的一个发行版。目前 HarmonyOS NEXT SDK 的目录是这样的：
kit
｜----base
｜----HMS
其中，base 里面放的就是 openharmony 的 kit，HMS 中放的是华为账号、华为支付、华为地图之类的华为 kit。至于两边的 OpenHarmony API 是否一致，我可以明确的说是一致的。
二、鸿蒙是安卓套壳吗？
看下面这张图，目前的情况是：鸿蒙 4.2 实现了安卓开源项目的所有接口，同时又实现了开源鸿蒙的所有接口，也就是：
HarmonyOS implements Android implements OpenHarmony
根据鸭型理论，如果我是一个安卓应用，发现 HarmonyOS 实现了安卓的所有接口，我认为它就是安卓。如果我是一个鸿蒙应用，HarmonyOS 实现了鸿蒙的所有接口，我认为它就是鸿蒙。
但是，如果按照余承东在今年 1.18 鸿蒙千帆启航仪式上的说法，“有生态、有技术底座，才是真正的操作系统。”目前的 HarmonyOS 4.2 主要依赖的还是安卓生态，HarmonyOS 4.2 上的 API9 也没有能力支撑大型应用的开发。按照这个定义，目前的 HarmonyOS 4.2 还是不够格的。
而且，目前 HarmonyOS 4.2 上的鸿蒙应用采用的容器方案，还是需要安卓的启动器进行启动，外面也包了一层安卓的 Activity，这样才能融入目前的系统。这么看下来，说是“安卓套壳”也不过分。
至于 OpenHarmony 和 HarmonyOS NEXT，这两个系统则不支持安卓应用，只能运行鸿蒙原生应用，显然不是安卓套壳。
三、鸿蒙是 JS 写的，是不是性能很差
JS 的执行效率确实不行，这是为什么呢？知乎上有一个问题：理论上所有编程语言都可以编译成LLVM IR，请问为什么他们之间还会存在性能差异呢？（https://www.zhihu.com/question/545005023/answer/2590184338）
因为不同语言提供/承诺的语言特性/功能不同，在编译到更底层的语言/代码时仍然需要保留这些特性和功能。一般来说，承诺的动态特性越多，在编译为静态代码时代价越大，能做的优化越少。
为了提升 JS 的运行效率，google 投入大量资源优化 v8 引擎。在 v8 引擎中，引擎对 JS 代码做了很多优化，可以对部分代码进行提前编译优化，不用等到运行的时候再来解释，可以提前猜测变量的类型进行缓存。但有时候会猜错，导致缓存失效，还是需要运行时确定类型，依旧面临性能瓶颈。所以即便用上了 v8 引擎，JS 执行效率相较其他静态语言，还是低了一些。
目前有很多软件开发都用 TS，相较于JS，TS 可以定义一些更严格的语法规则，给变量加上类型，方便多人协作开发大型项目。但 TS 必须编译为 JS 才能被浏览器识别，在这个过程中会丢失类型信息，所以效率并没有大的改变。
而 ArkTS 就不一样了。首先，ArkTS
会进行严格的强制类型检查，要求所有变量/常量/参数/返回值都必须要有类型，且不能为 Any，而且取消了 JS/TS 的部分动态特性，比如禁止在运行时改变对象的布局，禁止字面量等，具体的约束可以看迁移文档https://docs.openharmony.cn/pages/v4.1/zh-cn/application-dev/quick-start/typescript-to-arkts-migration-guide.md。ArkTS 代码会被方舟编译器编译为方舟字节码，而且会根据 profile 将热点函数优化为机器码。这个过程中，会利用上ArkTS 丰富的类型信息进行优化。由于取消了大量动态特性，并且在编译期就能确定类型，执行的效率类似于静态强类型语言，所以不用担心执行效率的问题。所以在上面的图中，ArkTS 应该处于“大中型 APP 开发”的区域。
四、鸿蒙应用是小程序吗？
基于 JS API 写的鸿蒙原生应用确实类似于小程序，这种做法鸿蒙还支持，但不推荐，也基本没有应用是用这套框架开发的。目前推荐的是基于 ArkTS 开发应用，用 ArkUI 声明式框架开发的鸿蒙原生应用不是小程序。
小程序性能较差的原因有两个：一个是存在 DOM 的解析，另一个则是 JS 执行效率较为低下。前面已经讲了语言执行效率的问题，这里讲讲鸿蒙的 ArkUI 框架。
ArkUI 分为前端和后端，前端提供了
ArkTS 的接口，这些接口的实际执行是在运行时里面，通过跨语言调用来调用到后端的 C++ 代码。比如在前端声明一个 Text 组件，但却是没有实际的 Text 对象，而直接变成了 UI 后端引擎的节点。前端的描述、宽高、动效、交互事件触发、状态管理、提交绘制等，都是在后端引擎中利用 C++ 实现的。鸿蒙的 ArkUI 不存在 DOM，不存在 DOM 的解析，自然也就不存在这个性能瓶颈了。
在调用 Build 函数后，前端的
ArkTS 描述通过跨语言调用变为了后端 C++ 的组件树。再基于组件树进行数据处理和 UI 更新。这里可以看出，ArkUI 的主要逻辑都是在后端执行的，C++ 直接编译成机器码，执行效率很高。
所以，ArkUI 和小程序的原理不一样，能够保证性能。
另一方面，鸿蒙也借鉴了小程序的优点。为什么小程序为什么会火起来，以至于成为很多互联网公司的主要入口？主要还是小程序免安装、可以一键登录、一键支付，还可以直接在微信生态中分享。可能用户装 APP 之前还要想一想，而碰到小程序就会直接点开，分发成本非常低。所以即便小程序性能不太行，但是依旧很火。
而在鸿蒙中，华为的生态替代了微信的生态：只要应用支持第三方登录，就支持华为登录，可以用华为账号一键登录注册。在选取头像时，也可以授权华为账户的头像和用户名给应用。在应用中可以直接调用华为支付。在填写地址时，可以授权获取华为账户中保存的地址，让用户使用起来更便捷。
鸿蒙的元服务也学习了小程序：鸿蒙的应用程序分为两种，一种是需要安装的应用，另一种就是免安装元服务。元服务也像小程序一样免安装、轻量级。但同时，元服务是基于 ArkUI 的框架开发的，只是和 app 有一个字段不同，而且体积有限制，其他都是一样的，所以性能比小程序好很多，可以调用系统的 API，功能比小程序更强大。
五、为什么现在的华为官方应用基本都是安卓应用？
现在的 HarmonyOS 还处于
API9，API9 还缺少了很多能力，比如相机、设置键盘避让等等，不足以支撑大型软件的开发。而华为的鸿蒙原生应用都是基于 API10 以上的版本开发的，目前已经来到了 API12，这些应用需要用到更高版本的 API，所以无法在目前的 HarmonyOS 4.2 上运行。另外，现在的 HarmonyOS 4.2 采用了容器方案，有一定性能损失，所以体验也不太好，这也是需要过渡到原生鸿蒙的原因。
六、HarmonyOS NEXT 什么时候发布？
根据余承东在春季发布会上的说法，今年 6.21 HDC2024 发布开发者预览版，今年第四季度发布商用版本。
七、鸿蒙以后还兼容安卓软件吗？
目前是不兼容的，之后是否兼容，可能华为也没有确定。需要看到时候的适配情况来决定。
关于鸿蒙还有什么疑问，可以在评论区里留言，之后会再写一篇 Q&A 来回答评论区的问题。
