系统架构全景：OpenHarmony的整体分层架构
讲OpenHarmony，我习惯先从它的分层架构说起。为什么？因为搞嵌入式的人都知道，没有清晰的分层，移植就是一场噩梦。你想想看，一个系统要跑在百元手机、智能手表、甚至冰箱面板上，内核、服务、框架、应用全搅在一起，那还怎么玩？
OpenHarmony把整个系统切成了四层：内核层、系统服务层、框架层、应用层。每一层各司其职，层与层之间通过标准接口通信。说白了，就是「上层只管调用，下层只管实现」。我在做移植时，最深的体会就是：只要层间接口不乱，换内核、换硬件都只是局部改动。
核心原则：层间解耦，接口标准化。这是OpenHarmony能跨设备的底气。
1. 内核层：系统的地基
内核层在最底下，负责管理CPU、内存、中断、任务调度这些硬核东西。OpenHarmony支持两种内核：LiteOS 和 Linux。LiteOS主打轻量、实时，适合内存只有几百KB的IoT设备；Linux则功能全、生态好，适合带MMU的复杂设备。
嗯，这里要注意：内核层上面有个内核抽象层（KAL）。它的作用就是屏蔽不同内核的差异。我刚开始移植时，以为要改很多内核相关的代码，后来发现KAL把接口都统一了——你只需要实现KAL规定的几个函数，上层根本不知道底下跑的是LiteOS还是Linux。
我的经验：移植时优先搞定KAL。只要KAL适配好了，系统服务层基本不用动。我曾经在一个RISC-V开发板上移植，KAL花了3天，后面一路畅通。
2. 系统服务层：承上启下的枢纽
系统服务层是OpenHarmony最复杂的一层。它包含了各种子系统：电源管理、传感器、网络、多媒体、安全、分布式软总线等等。每个子系统又拆成多个系统服务，通过IPC（进程间通信）对外暴露能力。
举个例子，你写一个App要读取温度传感器，流程是这样的：
- 应用层调用框架层的传感器API
- 框架层通过IPC向系统服务层的传感器服务发请求
- 传感器服务再通过HDF（硬件驱动框架）去操作真实的传感器硬件
你看，应用层根本不知道底层是I2C还是SPI，这就是分层的好处。
避坑指南：我曾经在调试分布式软总线时，发现设备之间老是连不上。查了两天，最后发现是系统服务层的权限配置漏了一项。所以，系统服务层的配置文件（比如.json或.xml）一定要逐行检查，少一个权限字段都可能翻车。
3. 框架层：开发者的主战场
框架层是给应用开发者用的。它提供了UI框架、Ability框架（类似Android的Activity）、多模输入、分布式数据管理等能力。说白了，框架层把系统服务层的复杂接口包装成简单易用的API。
我个人觉得，框架层最值得关注的是UI框架。OpenHarmony的UI框架支持声明式编程，类似Flutter。你写一个按钮，只需要描述它的状态和布局，框架自动处理渲染和事件分发。这对前端出身的开发者很友好。
另外，Ability框架也很关键。它定义了应用的启动、跳转、生命周期管理。我建议初学者先搞懂Page Ability（页面）和Service Ability（后台服务）的区别——前者有UI，后者没有。很多新手把后台任务写在Page Ability里，一退出页面任务就没了，这就是没理解框架的设计。
4. 应用层：最终交付物
应用层就是用户能看到的那些App。OpenHarmony的应用分为两类：系统应用（比如设置、桌面）和第三方应用。系统应用通常用C++开发，性能要求高；第三方应用用JS/TS开发，开发效率高。
这里有个细节：OpenHarmony的应用包格式是HAP（Harmony Ability Package）。一个HAP可以包含多个Ability，但只能有一个入口Ability。我在做移植测试时，经常遇到HAP安装失败的问题，后来发现是签名和权限没配好。嗯，应用层的签名校验很严格，开发阶段可以关掉，但发布前一定要打开。
一句话总结：内核层管硬件，系统服务层管能力，框架层管接口，应用层管体验。四层各司其职，缺一不可。
5. 层间通信：让一切运转起来
层与层之间怎么通信？OpenHarmony主要靠两种机制：
- IPC（进程间通信）：用于框架层和系统服务层之间。基于Binder驱动，支持跨进程调用。
- HDF（硬件驱动框架）：用于系统服务层和内核层之间。它把硬件操作抽象成标准接口，驱动开发者只需要实现几个回调函数。
我记得第一次看HDF的代码时，觉得它有点像Linux的设备树，但更轻量。HDF支持设备热插拔、电源管理、中断处理，而且可以跨内核使用。你在LiteOS上写的HDF驱动，换到Linux内核上，只需要重新编译，代码基本不用改。
| 层级 | 主要职责 | 典型组件 | 移植关注点 |
|---|---|---|---|
| 应用层 | 用户交互 | 系统应用、HAP包 | 签名、权限配置 |
| 框架层 | API封装、UI渲染 | UI框架、Ability框架 | JS引擎适配 |
| 系统服务层 | 能力提供、硬件管理 | HDF、分布式软总线 | 配置文件、权限声明 |
| 内核层 | 资源管理、硬件抽象 | LiteOS、Linux、KAL | 中断、内存映射、驱动 |
6. 移植视角：分层架构的实际意义
做移植的人，最关心的是「我要改哪些地方」。根据我的经验，分层架构下，移植工作主要集中在三层：
- 内核层：适配CPU架构（ARM、RISC-V、Xtensa等），实现KAL接口，编写板级驱动（UART、GPIO、I2C等）。
- 系统服务层：配置硬件资源（中断号、内存地址），调整HDF驱动参数。
- 框架层：基本不用动，除非你换了JS引擎或者改了UI渲染管线。
你看，框架层和应用层在移植时几乎不用改。这就是分层架构的威力——把变化隔离在底层。我做过一个项目，从ARM Cortex-M4移植到RISC-V，内核层改了大概2000行代码，系统服务层改了500行，框架层和应用层一行没动。项目周期从预估的3个月缩短到1个月。
一个小技巧：移植前先跑一遍OpenHarmony的「最小系统」——只包含内核层和必要的系统服务。如果最小系统能跑起来，说明底层没问题，再往上加功能。我每次都是这么干的，屡试不爽。
好了，关于OpenHarmony的四层架构，我就讲到这里。记住：分层不是目的，解耦才是。你理解了每一层的边界和职责，移植时就知道该从哪里下手。下次遇到一个新硬件，先问自己三个问题：内核层适配了吗？系统服务层配置好了吗？框架层需要改吗？答案清楚了，移植就成功了一半。