鸿蒙 NEXT 端侧 AI 实战:用 MindSpore Lite 把图像分类跑在手机上

引言

在 HarmonyOS NEXT(API 12+)里,"AI 能力"不再只是云端大模型背后的一句调用。真正的产品体验,往往发生在设备本地--一张照片拍下后立刻识别、一段语音说完立刻转写、一次手势触发立刻预测。把推理放到端侧,意味着更低的延迟、更强的隐私保护,以及完全离线可用的能力。

本篇文章只聚焦一件事:如何用鸿蒙 NEXT 的 NDK 把 MindSpore Lite 端侧推理引擎集成进应用,完成"加载模型 → 输入预处理 → 推理执行 → 输出解析"的完整闭环,并给出一份能直接落地运行的代码。我们以一个最经典、也最能体现工程细节的场景为例:移动端图像分类(Image Classification)。你读完之后,完全可以把它替换成目标检测、姿态估计,甚至文本特征提取--骨架是同一套。

下面所有的代码都基于 Stage 模型、ArkTS + Native(C/C++)混合开发,适配 API 12 及以上的鸿蒙 NEXT 真机与模拟器。阅读本文,你不需要是 AI 算法专家,但最好已经用 DevEco Studio 跑通过至少一个 ArkTS 工程。

本文的讲解顺序是"先搭台、再唱戏":先用工程配置与 CMake 把推理引擎请进应用,再深入初始化、预处理、执行、解析四个推理阶段,最后落到 UI 与性能。你读完应当能独立把任意一个 .ms 分类模型嵌入自己的页面,而不只是抄通一份示例。代码里的注释刻意写得克制,把"为什么"留给正文,把"怎么做"留给代码。

小结:端侧 AI 的核心价值是"快、私、离线",而 MindSpore Lite 是鸿蒙官方主推的端侧推理引擎,本文用图像分类把它跑通。

---

一、为什么选端侧推理,以及 MindSpore Lite 的定位

先说结论:云边协同是趋势,但端侧推理是刚需。云端推理依赖网络、有隐私风险、且网络抖动会让体验分崩离析;端侧推理在设备本地完成前向计算,适合实时性高、数据敏感的场景。尤其在鸿蒙"全场景"定位下,手表、车机、折叠屏都可能要跑同一个模型,端侧一致性的价值被进一步放大。

鸿蒙 NEXT 提供了多条 AI 能力接入路径,理解它们的边界很重要:

• 系统级 AI 能力 :如系统图像识别、语音识别等 @ohos 接口,开箱即用但定制能力有限,你拿不到中间特征,也无法换模型。
• Neural Network Runtime(NNRT):统一的推理运行时抽象,屏蔽底层 CPU/GPU/NPU 差异,适合不想关心引擎细节的场景。
• MindSpore Lite:华为推出的轻量级端侧推理引擎,跨平台、高性能、可深度定制,是本文主角。

MindSpore Lite 的优势在于它提供的是完整的推理运行时 ,而非某个具体模型的封装。你可以把训练好的 MindIR / ONNX / TFLite 模型转换为 .ms 格式,在鸿蒙 NEXT 上用同一套 C++ API 加载执行,无论底层是 CPU、GPU 还是 NPU,对上层代码几乎透明。换句话说,它给你的是"引擎",不是"功能",因此能撑起任意自定义模型。

一句话:MindSpore Lite 给你的是引擎而不是功能,因此它能撑起任意自定义模型,这正是端侧智能的底座。

横向对比一下会更清楚:Google 的 TensorFlow Lite、社区的 ONNX Runtime Mobile 也都能在鸿蒙上跑,但 MindSpore Lite 与鸿蒙 NEXT 的工具链、NPU delegate 适配最紧密,官方文档与示例最完整。如果你后续要上昇腾 NPU 加速,MindSpore Lite 的 delegate 路径是最省心的选择。这也是本文选它作为切入点的现实原因。

---

二、工程结构:NDK 原生模块的接入方式

要想在 ArkTS 里调用 MindSpore Lite,正确姿势是通过 NDK 编写 Native 模块,再用 NAPI 暴露接口给 ArkTS。两个世界在同一进程内直接调用,没有跨进程 IPC 开销,推理延迟可以压到毫秒级。这种"ArkTS 管界面与系统能力、C++ 管算力"的分层,是鸿蒙 NEXT 上所有重计算场景的标准解法,不独 AI 如此。

为什么不直接用 ArkTS 写推理?根本原因是 MindSpore Lite 以 C/C++ 交付,其算子内核大量使用 SIMD、内存对齐与底层并行原语,这些在 ArkTS 的托管运行时里既无法表达、也跑不出性能。因此 NDK 不是可选项,而是必经之路。你付出的代价,只是多维护一份 CMake 与 NAPI 胶水代码--而这正是本文要替你铺平的部分。

工程结构并不复杂。在 entry 模块的 src/main/cpp 下放置原生代码与 CMakeLists.txt,把 MindSpore Lite 的头文件放到 cpp/include、预编译的 libmindspore-lite.so 放到 cpp/libs/arm64-v8a。模型文件 mobilenetv2.ms 放进 resources/rawfile/model,ArkTS 侧代码照常放在 ets 目录。关键改动只有一处:build-profile.json5 里声明 externalNativeOptions,告诉编译系统去构建 cpp 目录。

{
  "apiType": "stageMode",
  "buildOption": {
    "externalNativeOptions": {
      "path": "./src/main/cpp/CMakeLists.txt",
      "cppFlags": "-std=c++17 -DLOG_DOMAIN=0xD001234",
      "abiFilters": ["arm64-v8a"]
    }
  }
}

注意 abiFilters 只保留了 arm64-v8a。当前真机与模拟器基本都是 64 位架构,砍掉 32 位能显著减小包体。这段配置的本质,是告诉 DevEco 的编译管线:本模块含 Native 代码,请用 OHOS 工具链去驱动 CMake,并把产物随 HAP 一起签名打包。一旦就位,你无需手写任何 ndk-build 命令。如果你的模型依赖 NPU delegate,这里还需要按设备 ABI 引入对应版本的 libmindspore-lite.so。这个配置一旦就位,DevEco Studio 会在打包时自动编译 cpp 目录并把产物 .so 一并打进 HAP。

小结:原生模块通过 NAPI 与 ArkTS 通信,工程上只需把 cpp 目录、CMake 脚本、.ms 模型就位即可。

---

三、CMake 编译脚本:把引擎链进来

CMakeLists.txt 负责三件事:引入 MindSpore Lite 的共享库头文件、声明预编译的 .so 为 IMPORTED 库、把我们自己的 mslite_infer.cpp 编译成可被 ArkTS import 的模块。

cmake_minimum_required(VERSION 3.5.0)
project(mslite_infer)

set(ROOT ${CMAKE_CURRENT_SOURCE_DIR})

include_directories(${ROOT}/include)

add_library(mindspore-lite SHARED IMPORTED)
set_target_properties(mindspore-lite PROPERTIES
    IMPORTED_LOCATION
    ${ROOT}/libs/${OHOS_ARCH}/libmindspore-lite.so)

add_library(mslite_infer SHARED mslite_infer.cpp)

target_link_libraries(mslite_infer PUBLIC
    libace_napi.z.so
    mindspore-lite
    hilog_ndk.z)

target_include_directories(mslite_infer PUBLIC ${ROOT})

OHOS_ARCH 是鸿蒙 NDK 在编译时注入的变量,会自动解析为 arm64-v8a 之类的值,因此 libs/${OHOS_ARCH} 能精准找到对应架构的 .so。libace_napi.z.so 是 NAPI 运行时,hilog_ndk.z 提供原生日志,两者都是系统库,无需额外下载。MindSpore Lite 的 .so 则需从官方发布包(mindspore-lite-*-harmonyos-aarch64.tar.gz)获取。

小结：CMake 的本质就是"找头文件 + 链库 + 编出 .so"，三步定乾坤。

顺带澄清一个常见误解：你是不是觉得"链接了 mindspore-lite 就得把整个引擎源码编进 App"？不是。libmindspore-lite.so 是预编译的二进制，CMake 只是告诉链接器"运行时去这个 .so 里找符号"，真正的体积发生在打包阶段。如果你的模型只用 CPU 推理，还可以用 MindSpore 提供的"精简版"运行时（只含 CPU 算子），进一步压包。把引擎当成一个被链接的库，而不是一份要参与编译的代码，这个心智模型能帮你少踩很多坑。

---

四、推理引擎初始化:Context 与 Model 的构建

所有推理之前,必须先构建两样东西:Context(运行上下文) 和 Model(模型实例) 。Context 决定了模型跑在哪个硬件、开几个线程、是否启用 FP16;Model 则是构建好的计算图。这两个对象应当只构建一次,之后每次推理复用,避免重复反序列化模型带来的开销。

先看原生侧的初始化逻辑。我们从把模型文件整块读进内存开始:

#include <fstream>
#include <memory>
#include <string>
#include <vector>

#include "hilog/log.h"
#include "napi/native_api.h"
#include "include/api/context.h"
#include "include/api/model.h"
#include "include/api/status.h"
#include "include/api/types.h"
#include "include/api/ir/tensor.h"

#undef LOG_DOMAIN
#undef LOG_TAG
#define LOG_DOMAIN 0xD001234
#define LOG_TAG "MsLiteInfer"

static std::unique_ptr<mindspore::Model> g_model = nullptr;
static std::shared_ptr<mindspore::Context> g_context = nullptr;

static bool InitEngine(const std::string &modelPath) {
  g_context = std::make_shared<mindspore::Context>();
  g_context->SetThreadNum(4);
  g_context->SetThreadAffinity(1);
  auto &device_list = g_context->MutableDeviceInfo();
  auto cpu_info = std::make_shared<mindspore::CPUDeviceInfo>();
  cpu_info->SetEnableFP16(false);
  device_list.push_back(cpu_info);

  std::ifstream ifs(modelPath, std::ios::binary);
  if (!ifs.good()) return false;
  ifs.seekg(0, std::ios::end);
  size_t size = static_cast<size_t>(ifs.tellg());
  ifs.seekg(0, std::ios::beg);
  char *buf = new char[size];
  ifs.read(buf, static_cast<std::streamsize>(size));
  ifs.close();

  g_model = std::make_unique<mindspore::Model>();
  auto ret = g_model->Build(buf, size,
                            mindspore::ModelType::kMindIR, g_context);
  delete[] buf;
  return ret == mindspore::kSuccess;
}

几个关键点值得展开。SetThreadNum(4) 不是越大越好--手机 CPU 大核通常只有 2~4 个,线程数过高反而会因上下文切换而变慢,图像分类的甜点区一般在 2~4。SetThreadAffinity(1) 把线程绑到性能核,避免被调度到小核导致推理抖动,这在相机实时预览场景尤其重要。SetEnableFP16(false) 用 FP32 保精度;若模型量化过且追求极致速度,可开启 FP16 甚至 INT8。最后,ModelType::kMindIR 表示我们加载的是 MindSpore 导出格式,用 ONNX 转换来的模型应改为 kONNX。

关于设备选择还有一层可玩性:除了 CPUDeviceInfo,MindSpore Lite 还提供 GPUDeviceInfo 与 NPU delegate。GPU 在卷积类模型上常比 CPU 快数倍,但首次编译内核有开销;NPU 最快但算子覆盖有限,遇到不支持的算子会自动回退 CPU。对于本文的图像分类,CPU 已足够,且行为最可控--这也是示例默认选 CPU 的原因。等你要上更大模型,再按"先 GPU 后 NPU"的顺序尝试不迟。

Build 这一步会解析模型字节流、分配权重内存、生成执行计划。它相对耗时(几十到几百毫秒),所以放在初始化阶段、且只做一次,是正确的工程选择。值得一提的是,g_model 与 g_context 用全局智能指针持有,整个应用生命周期内常驻;若你的场景需要热切换模型(如用户切换语种模型),则应在切换时先释放旧 Model 再构建新实例,避免内存峰值叠加。

小结:Context 控制"怎么跑",Model 承载"跑什么",两者在 init 阶段一次性就绪并长期复用。

---

五、输入预处理:从 PixelMap 到归一化张量

端侧推理最容易翻车的环节,往往是预处理对不齐 。训练时怎么归一化,推理时就得原样复现,否则精度会断崖式下跌。以 MobileNetV2 为例,训练时输入是 [1, 3, 224, 224] 的 NCHW 张量,像素归一化到 [0,1],并按 mean=[0.485,0.456,0.406]、std=[0.229,0.224,0.225] 做标准化。下面看 ArkTS 侧如何把一张 PixelMap 变成这样的 Float32Array:

import { image } from '@kit.ImageKit';

async function preprocess(
  pixelMap: image.PixelMap,
  modelWidth = 224,
  modelHeight = 224
): Promise<Float32Array> {
  const info = await pixelMap.getImageInfo();
  await pixelMap.scale(modelWidth / info.size.width, modelHeight / info.size.height);

  const bufferSize = modelWidth * modelHeight * 4;
  const pixelBuffer = new ArrayBuffer(bufferSize);
  await pixelMap.readPixelsToBuffer(pixelBuffer);

  const u8 = new Uint8Array(pixelBuffer);
  const input = new Float32Array(modelWidth * modelHeight * 3);
  const mean = [0.485, 0.456, 0.406];
  const std = [0.229, 0.224, 0.225];

  for (let h = 0; h < modelHeight; h++) {
    for (let w = 0; w < modelWidth; w++) {
      const src = (h * modelWidth + w) * 4;     // BGRA 布局
      const r = u8[src + 2] / 255.0;
      const g = u8[src + 1] / 255.0;
      const b = u8[src + 0] / 255.0;
      const dst = h * modelWidth + w;
      input[dst] = (r - mean[0]) / std[0];
      input[dst + modelWidth * modelHeight] = (g - mean[1]) / std[1];
      input[dst + modelWidth * modelHeight * 2] = (b - mean[2]) / std[2];
    }
  }
  return input;
}

注意三个细节。第一,scale 是就地(in-place)操作,会直接修改原 PixelMap,若需保留原图记住先 clone()。第二,通道顺序:PixelMap 默认是 BGRA,但模型要 RGB,读取时务必交换下标,否则颜色错乱。第三,NCHW vs NHWC:MindSpore 默认 NCHW,所以三个通道要分开写入不同区间,而不是交错--这是新手最常见的坑。

预处理对齐了,推理才有意义。这一步错了,后面哪怕引擎跑得再快也是无效输出。

需要提醒的是,预处理不是图像分类的专利。文本模型要做的可能是分词 + 转 token id + 补 padding;音频模型要做的可能是重采样到 16kHz + 加窗 + 提取梅尔频谱。它们的共同点是:把任意原始输入,变成模型训练时见过的、固定形状、固定分布的张量。只要守住"形状、布局、数值分布"三要素,换模态只是换公式,骨架不变。

小结:预处理就是"复现训练 pipeline",通道顺序与归一化参数一个都不能错。

---

六、推理执行:NAPI 桥接与 Predict

原生侧对外暴露两个接口:initModel(path) 和 runInference(input)。后者接收 ArkTS 传来的 Float32Array,填入输入张量,调用 Predict,再把输出张量原样返回。Float32Array 通过 NAPI 的 TypedArray 机制零拷贝传递,效率很高。

static napi_value RunInference(napi_env env, napi_callback_info info) {
  size_t argc = 1;
  napi_value args[1] = {nullptr};
  napi_get_cb_info(env, info, &argc, args, nullptr, nullptr);

  napi_typedarray_type type;
  size_t length = 0;
  void *data = nullptr;
  napi_value arraybuffer;
  napi_get_typedarray_info(env, args[0], &type, &length,
                           &data, &arraybuffer, nullptr);
  float *input_data = static_cast<float *>(data);

  if (!g_model) {
    napi_throw_error(env, nullptr, "model not initialized");
    return nullptr;
  }
  auto inputs = g_model->GetInputs();
  if (inputs.empty()) {
    napi_throw_error(env, nullptr, "invalid model inputs");
    return nullptr;
  }
  auto &in_tensor = inputs[0];
  if (in_tensor.DataSize() != length * sizeof(float)) {
    napi_throw_error(env, nullptr, "input size mismatch");
    return nullptr;
  }
  memcpy(in_tensor.MutableData(), input_data, in_tensor.DataSize());

  std::vector<mindspore::MSTensor> outputs;
  auto ret = g_model->Predict(inputs, &outputs);
  if (ret != mindspore::kSuccess) {
    napi_throw_error(env, nullptr, "predict failed");
    return nullptr;
  }

  const auto &out_tensor = outputs.empty()
                               ? g_model->GetOutputs()[0]
                               : outputs[0];
  const size_t out_size = out_tensor.DataSize() / sizeof(float);
  float *out_ptr = static_cast<float *>(out_tensor.MutableData());

  napi_value result, out_buf;
  napi_create_arraybuffer(env, out_size * sizeof(float), nullptr, &out_buf);
  napi_create_typedarray(env, napi_float32_array, out_size, out_buf, 0, &result);
  void *result_data = nullptr;
  napi_get_typedarray_info(env, result, &type, &length,
                           &result_data, nullptr, nullptr);
  memcpy(result_data, out_ptr, out_size * sizeof(float));
  return result;
}

Predict 是同步阻塞调用。这里有个工程取舍:我们刻意保持同步,把"是否异步"交给 ArkTS 侧决定--在 UI 线程直接调会卡顿,正确做法是用 taskpool 把 classify 抛到后台线程执行,结束后再 postTask 回 UI 刷新结果。返回值 Status 必须判等 kSuccess,否则后续读到的张量可能是脏数据。输入张量通过 MutableData() 拿到可写指针,直接 memcpy--这正是 NCHW 预处理与张量内存布局对齐的地方。输出张量同样通过 MutableData() 取出,再包成 Float32Array 回传。

多输出模型要注意:Predict 的 outputs 是一个张量向量,顺序与模型导出时的输出声明一致。若你的模型有多个头(如同时出分类与检测框),务必按 out_tensor.Name() 或固定下标分别取用,不要想当然取 outputs[0]。张量的实际形状用 Shape() 查询,长度是 DataSize()/sizeof(float)--当输入 batch 或动态维度变化时应以 Shape() 为准,而非硬编码 1000。

小结:Predict 一行顶千言,但前后务必做好"尺寸校验 + 返回值判断"两道保险。

---

七、模块注册与 ArkTS 封装

原生模块要通过 napi_module_register 注册成一个可被 import 的模块名。这段是固定套路,但少一行都编不过。nm_modname 字段决定了 ArkTS 里 import 的名字。

static napi_value InitModel(napi_env env, napi_callback_info info) {
  size_t argc = 1;
  napi_value args[1] = {nullptr};
  napi_get_cb_info(env, info, &argc, args, nullptr, nullptr);
  size_t str_len = 0;
  napi_get_value_string_utf8(env, args[0], nullptr, 0, &str_len);
  std::string model_path(str_len, '\0');
  napi_get_value_string_utf8(env, args[0], &model_path[0], str_len + 1, &str_len);
  bool ok = InitEngine(model_path);
  napi_value result;
  napi_get_boolean(env, ok, &result);
  return result;
}

static napi_value MsLiteInferInit(napi_env env, napi_value exports) {
  napi_property_descriptor desc[] = {
    {"initModel", nullptr, InitModel, nullptr, nullptr, nullptr, napi_default, nullptr},
    {"runInference", nullptr, RunInference, nullptr, nullptr, nullptr, napi_default, nullptr},
  };
  napi_define_properties(env, exports,
                         sizeof(desc) / sizeof(desc[0]), desc);
  return exports;
}

extern "C" __attribute__((constructor)) void RegisterMsLiteInfer(void) {
  napi_module module = {
    .nm_version = 1, .nm_flags = 0, .nm_filename = nullptr,
    .nm_register_func = MsLiteInferInit, .nm_modname = "msliteinfer",
    .nm_priv = nullptr, .reserved = {0},
  };
  napi_module_register(&module);
}

ArkTS 侧需要一份类型声明 index.d.ts 才能享受类型提示,否则 import 会报找不到声明:

export const initModel: (modelPath: string) => boolean;
export const runInference: (input: Float32Array) => Float32Array;

真正的调用封装放在 utils/infer.ets。这里有个关键动作:模型文件在 rawfile 里是以资源形式打包的,运行时需要先用 getRawFileContentSync 读出来、写到应用可写目录(如 filesDir),再把路径交给原生 initModel。

import msliteinfer from 'msliteinfer';
import { common } from '@kit.AbilityKit';
import { fileIo as fs } from '@kit.CoreFileKit';

let inited = false;

async function ensureModel(ctx: common.UIAbilityContext): Promise<void> {
  if (inited) return;
  const name = 'mobilenetv2.ms';
  const buf = ctx.resourceManager.getRawFileContentSync(`model/${name}`);
  const filePath = `${ctx.filesDir}/${name}`;
  const file = fs.openSync(filePath, fs.OpenMode.CREATE | fs.OpenMode.WRITE_ONLY);
  fs.writeSync(file.fd, buf.buffer);
  fs.closeSync(file);
  inited = msliteinfer.initModel(filePath);
}export async function classify(
  ctx: common.UIAbilityContext,
  pixelMap: image.PixelMap
): Promise<Float32Array> {
  await ensureModel(ctx);
  const input = await preprocess(pixelMap);
  return msliteinfer.runInference(input);
}

注意写文件时要用 buf.buffer 而非 buf 本身--getRawFileContentSync 返回的是 Uint8Array 视图,buffer 才是底层 ArrayBuffer,用错会导致只写入偏移部分甚至空文件。封装好之后,业务代码调用 classify 时完全感知不到原生的存在。

小结:NAPI 注册 + d.ts 声明 + ArkTS 封装,三层打通后调用方完全无感知原生存在。

补充一个排错视角:nm_modname 与 ArkTS 的 import 名必须完全一致,且 .so 必须被打进 HAP 的 libs 目录(DevEco 默认会做)。若运行时报"module not found",优先检查三处:cppFlags 是否包含 -DLOG_DOMAIN、CMake 是否真把 mslite_infer 编进产物、以及模块名拼写。用 hdc shell find /data -name 'libmslite_infer.so' 可快速确认 .so 是否真的随包落到了设备上。

---

八、输出解析:Top-K 分类与 UI 串联

runInference 返回的是长度等于类别数的 Float32Array(如 ImageNet 的 1000 维)。我们要做的是取分数最高的 K 个,并映射回标签名。还需先确认模型末层是否已带 softmax--很多分类模型输出已是概率分布,但若是 Dense 裸输出则需自行 softmax,否则排序虽对、数值却非概率。这再次印证"复现训练 pipeline"的原则。

function topK(logits: Float32Array, k = 3): Array<{ index: number; score: number }> {
  const arr = Array.from(logits).map((score, index) => ({ index, score }));
  arr.sort((a, b) => b.score - a.score);
  return arr.slice(0, k);
}

@Entry
@Component
struct Index {
  @State result: string = '请选择一张图片';
  private ctx = getContext(this) as common.UIAbilityContext;

  async onPick() {
    const pixelMap = await this.loadPixelMap();   // 实际用 photoAccessHelper 取图
    const logits = await classify(this.ctx, pixelMap);
    const tops = topK(logits, 3);
    this.result = tops
      .map(t => `${labels[t.index]}: ${(t.score * 100).toFixed(2)}%`)
      .join('\n');
  }

  build() {
    Column({ space: 16 }) {
      Text('鸿蒙端侧图像分类').fontSize(24).fontWeight(FontWeight.Bold)
      Button('选择图片并识别').onClick(() => this.onPick())
      Text(this.result).fontSize(18)
    }
    .width('100%').height('100%').padding(24)
  }
}

labels 是 ImageNet 的 1000 条标签数组,通常由 resources/rawfile/label/imagenet_labels 加载。到这里,一条完整的链路就闭合了:选图 → PixelMap → 预处理张量 → 原生推理 → 输出解析 → UI 展示。

小结:输出解析就是"排序取 Top-K + 标签映射",别忘了先确认模型是否已经过 softmax。

工程落地时,标签文件最好与模型版本一起管理:模型换了,标签索引含义可能也变。若做国际化,标签应走 resourceManager.getString 按 locale 取,而非把中文写死在代码里。另外 Top-K 的 K 不必固定为 3,搜索类场景可给 5~10 个候选供用户纠偏,体验更稳。

---

九、性能优化与避坑清单

把模型跑起来只是第一步,要跑得"快而稳",有这些经验值得记下来:

1. 模型选型:优先 INT8 量化。 FP32 的 MobileNetV2 在端侧约 30~60ms,INT8 量化后往往能压到 15ms 以内,精度损失通常可接受。用 MindSpore 的 converter_lite 配合 configFile 做训练后量化(PTQ),把权重从 float 压成 int8 并保存缩放因子。

2. 线程与亲和性。 SetThreadNum 设 2~4,SetThreadAffinity(1) 绑大核。在相机实时场景,避免每次推理都重建 Context--Context 与 Model 的重用是性能基线。

3. 输入输出复用。 GetInputs() 返回的张量指针在多次 Predict 之间可复用,无需每次重新 memcpy 到新内存,但要保证写入顺序与张量布局一致。

4. 内存与 ABI。 libmindspore-lite.so 体积不小,建议只保留 arm64-v8a;若需 NPU 加速,务必使用对应设备 ABI 编译的版本,否则会回退 CPU 甚至加载失败。

5. 日志别打太狠。 OH_LOG_* 在高频推理循环里会拖慢性能,发布版本建议关掉逐帧日志,只保留初始化与错误级别的日志。

这五点，本质上是"量化 + 线程 + 复用 + 精简日志"四件套的叠加。优化没有银弹，唯一的方法是拿到真机、用真实输入、量真实延迟，再针对性调参。

最后给一句心态上的建议：端侧推理的工程量，往往不在"跑通"，而在"跑稳、跑快、跑小"。跑通一篇示例半天够；但要做成线上功能，你得面对模型版本管理、灰度回退、低端机降级（自动从 INT8 退回 FP32 或减小输入尺寸）、以及 OTA 更新模型而不发版。把这些当成架构的一部分，而不是事后补救，你的 AI 功能才真正"智能"得起来。

还有一个常被忽视的维度:输入吞吐。单张图片推理快,不代表批量或流式场景快--相机每秒 30 帧喂进来时,预处理与推理要流水化(双缓冲/环形队列),否则 GPU/CPU 会空等。当你的场景从"点一下识别一张"升级到"实时连续识别",瓶颈往往不在 Predict,而在预处理与数据搬运,那时 TaskPool 并行预处理 + Native 内零拷贝才是关键。

小结:性能是"量化 + 线程 + 复用 + 精简日志"四件套的叠加成果,必须在真机上实测。

---

十、如何验证与调试:别靠"猜"

端侧推理的 bug 往往很隐蔽:结果是乱的,但编译一切正常。建立一套可验证的调试路径,比反复改代码高效得多。

第一步,先验证引擎本身。用一份已知输入、已知输出 的小模型(或官方示例模型)跑通 initModel 与 runInference,确认链路通畅,再换自己的模型。很多"精度不对"其实是预处理错了,而不是引擎错了。

第二步,打开原生日志。OH_LOG_INFO 在初始化与错误分支都有打印,用 hdc hilog | grep MsLiteInfer 能实时看到 Build 是否成功、Predict 返回码是什么。返回码非 kSuccess 时,MindSpore Lite 的码值能在官方错误码表里查到具体含义。

第三步,单测预处理。把预处理后的 Float32Array 单独打出来,检查数值范围是否在 [0,1] 附近、均值是否接近 0、通道顺序是否正确。一个常见的低级错误是 RGB/BGR 写反,导致分类结果整体"偏移但有序"。

第四步,量真实延迟。在 RunInference 前后用 std::chrono 打点,统计 P50/P99 而非单次值--端侧抖动大,单次数字没有意义。只有拿到 P99,你才知道极端场景下会不会卡 UI。

小结:调试端侧推理靠"已知样本 + 日志 + 单测预处理 + 延迟打点",而不是凭感觉改参数。

---

总结

本文从工程结构、CMake 配置、引擎初始化、输入预处理、推理执行、NAPI 注册、输出解析到性能优化,完整走通了 HarmonyOS NEXT + MindSpore Lite 端侧图像分类 的落地路径。

回头看,端侧 AI 在鸿蒙 NEXT 上的开发范式非常清晰:原生 C++ 承载推理引擎,NAPI 桥接 ArkTS,预处理/后处理放在 ArkTS 侧用系统能力完成。这种分层既发挥了 Native 的高性能,又保留了 ArkTS 在 UI 与系统 API 上的开发效率。

当你把这套骨架跑通之后,替换模型、扩展成目标检测或多模态推理,都是顺理成章的事。端侧智能,正是鸿蒙 NEXT "一次开发、多端部署" 之外,最值得投入的能力底座。