1. 背景：为什么需要服务化架构
在 OpenHarmony 4.0 上直接使用 RKNN 进行 AI 推理，很多开发者一开始会想到 Android 那套方案：把 librknnrt.so 和模型文件打包到应用里，在 Native 层直接调用 RKNN 的 API。但实际一跑就发现，这条路在 OpenHarmony 上根本走不通——程序一启动就报错，so 库加载失败。根本原因在于 OpenHarmony 系统的运行时环境与 RKNN 库依赖的运行时版本不匹配。RKNN 库是用特定的交叉编译工具链（比如 gcc-linaro-7.5.0）编译的，它依赖的运行时库版本和 OpenHarmony 系统自带的版本不一致，导致直接加载失败。
这时候就需要换个思路了：既然直接加载不行，那就采用服务化架构。简单来说，就是让一个专门的服务进程（rknn_server）来负责 RKNN 推理，这个服务进程用 RKNN 官方推荐的工具链编译，完美匹配 RKNN 的运行时依赖。然后我们的应用通过一个客户端（rknn_client）和服务进程通信，把推理任务交给它处理。这样既避开了环境冲突问题，又能充分利用 NPU 的算力。
这种架构还有一个好处：资源复用。多个应用可以共享同一个 rknn_server 进程，避免每个应用都单独加载模型和运行时库，节省内存和 CPU 资源。对于嵌入式设备来说，这点尤其重要。
2. 服务化架构设计与核心组件
2.1 整体架构设计
服务化架构的核心是进程间通信（IPC），这里我们设计了两大核心组件：
- rknn_server：一个常驻后台的服务进程，负责加载 RKNN 模型、执行推理任务。这个进程使用 RKNN 官方推荐的交叉编译工具链（如 gcc-linaro-7.5.0）编译，确保与 librknnrt.so 的兼容性。
- rknn_client：一个运行在应用进程中的代理库，封装了 RKNN 的 API，负责与应用逻辑交互，并通过 IPC 机制与 rknn_server 通信。
两者之间的通信分为两部分：
