本节目标

• 理解 HarmonyOS 端侧 AI 的完整技术栈与分层架构，掌握 MindSpore Lite、CANN Kit、Neural Network Runtime、格物推理服务、HiAI Foundation 五大核心组件的定位与协作关系
• 掌握端侧 AI 方案的选型决策框架，能够根据业务场景在系统内置 AI 控件、MindSpore Lite 推理、端侧大模型部署三条路径之间做出合理选择
• 掌握 MindSpore Lite 的模型转换、部署与推理全流程，能够正确管理 Context 与 Model 的生命周期，配置推理后端与线程数
• 掌握系统内置 AI 控件的零代码集成能力，能够通过 Image 组件和 Text 组件的配置属性快速集成主体分割、文本提取、实体识别等能力
• 掌握 AI 辅助开发工具链（DevEco Code、DevEco CLI、CodeGenie）的安装与使用，能够通过自然语言完成代码生成与工程分析
• 理解 AI 驱动 UI 的设计理念与实现路径，能够为动态界面生成场景设计合理的架构方案
• 掌握端侧 AI 的性能优化与安全防护策略，能够构建高效、安全、合规的端侧智能应用

一、端侧 AI 技术栈全景

1.1 为什么选择端侧 AI

在 HarmonyOS 应用开发中，AI 能力的部署位置直接影响用户体验、隐私安全和运营成本。端侧 AI 相比云侧 AI 具有三方面核心优势：

隐私安全：数据不会联网，仅基于本地模型计算。图片处理类 AI 能力无需上传用户图片到云端，人脸识别、OCR 识别等敏感操作全程在本地完成，从根源上杜绝了数据泄露风险。鸿蒙的星盾安全架构将端侧数据隔离在设备安全区内，人脸、语音、健康、本地文档不会默认上传，从源头降低隐私泄露风险。

低延迟：在理想状态下可以达到毫秒级的响应。OCR 识别准确率已达到行业领先水平，端侧推理无需等待网络往返。端侧推理不用网络往返，交互更跟手；地铁、无信号环境 AI 功能依然生效。

成本低：对于小厂或个人开发者，本地大模型加持下可以零成本实现很多 AI 能力，无需为云端推理付费，也无需维护昂贵的 GPU 集群。

端侧 AI 的挑战：内存资源受限、算力受限、对功耗敏感。端侧硬件算力、内存、功耗有上限，不适合超复杂长文本、深度逻辑推理、大规模知识库。工程上通常分三块应对：推理框架选型（选择能编译到 HarmonyOS/ohos arm64 的 native 方案）、模型文件管理（放 rawfile 或首次启动复制到沙箱）、线程与体验管理（推理放 Worker/native 线程，做流式输出、取消、温控和低内存保护）。

端云协同策略：鸿蒙采用混合策略——轻量、实时、隐私敏感任务在端侧本地跑；超大模型、复杂创作、专业计算自动切换云端；中间场景则由端侧做意图理解，云端做深度生成，结果回传本地。

1.2 端侧 AI 分层架构

HarmonyOS 的 AI 开放层次由上层到底层分为五个层次，各层分工明确：

MindSpore Lite Kit（推理引擎层）
HarmonyOS 内置的轻量化 AI 引擎，提供统一的模型推理和训练接口。自动硬件调度：优先 NPU，算力不足自动降级 DSP/CPU，平衡性能、功耗、内存，适配从旗舰手机到智能手表的全品类鸿蒙设备。

MindSpore Lite 的设计哲学可以用一句话概括：轻量、高效、跨平台。它不是简单地把服务端框架“瘦身”移植，而是从端侧场景出发重新设计的推理引擎。其工作流分为三个关键阶段：模型转换阶段（将训练框架产出的模型转换为端侧专用的 .ms 格式，同时进行图优化和算子融合）、模型加载与编译阶段（在设备端加载 .ms 模型，根据硬件上下文编译生成可执行的计算图）、推理执行阶段（输入数据，执行推理，输出结果）。

CANN Kit（硬件加速层）
面向 Kirin 芯片平台，为各种 AI 模型和算法提供统一的接入和运行环境。通过离线模型转换将 Caffe、TensorFlow、ONNX、MindSpore 模型转换为 CANN Kit 平台支持的格式，并可按需进行 AIPP 图像预处理和量化操作。

格物推理服务（QoS 调度层）
API 20 引入的 QoS 感知推理加速和资源管理优化服务。通过动态按需加载推理模型资源、结合 QoS 等级进行调度优化，在保障用户体验不卡顿的前提下实现端侧高效推理。

Neural Network Runtime Kit（跨芯片运行时层）
面向 AI 领域的跨芯片推理计算运行时，作为中间桥梁连通上层 AI 推理框架和底层加速芯片。

HiAI Foundation Kit（底层计算支撑层）
统一接入和运行时环境，面向 Kirin 硬件平台，支持 Ascend C 自定义算子编程语言，确保面向 NPU 的开发优化可以一次开发、多端运行。

1.3 端侧 AI 方案选型决策框架

面对具体的业务需求，开发者应该如何选择端侧 AI 方案？以下决策框架可供参考：

第一层判断：系统是否已内置该能力？

• 如果是图像文字识别、主体分割、实体识别等常见场景，优先使用系统内置 AI 控件（Image.enableAnalyzer、Text.enableDataDetector），零代码集成，无需模型管理。
• 如果是智能问答、对话生成等场景，优先使用端侧问答模型（DataAugmentationKit）。

第二层判断：是否有可用的预训练模型？

• 如果有 ONNX/TFLite/Caffe 等格式的预训练模型，使用 MindSpore Lite 进行模型转换和推理，适合图像分类、目标检测、语义分割等场景。
• 如果需要自定义模型，使用 MindSpore 训练后转换为 .ms 格式，再通过 MindSpore Lite 部署。

第三层判断：是否需要大模型能力？

• 如果需要文本生成、代码生成、复杂推理等大模型能力，考虑端侧大模型部署。鸿蒙 7 支持端侧 30B 盘古模型，兼顾推理能力与手机功耗，可做多轮对话、文档摘要、意图理解、多模态解析。建议使用 1B 以下的量化模型（如 qwen0.5b、hunyuan0.6b），推理放 Worker/native 线程，做流式输出和低内存保护。

第四层判断：是否有极致性能要求？

• 如果是游戏渲染、相机预览等场景，考虑 XComponent + EGL/OpenGL ES + NPU 加速方案，通过 CANN Kit 直接调用 NPU 算力。

1.4 模型压缩技术

在端侧部署大模型时，模型压缩是核心技术。一个残酷的现实是：手机内存大概 8-12GB，但一个 ResNet-50 模型就要 25MB 参数，一个 MobileBERT 要 100MB，更别提那些动辄几 GB 的大语言模型了。推理时需要的激活值内存往往是参数的 2-3 倍。

量化：把 FP32 模型转化为低 bit 模型（如 INT8、INT4），以节约网络存储空间、降低传输时延以及提高运算执行效率。量化是最常用的压缩手段，通常能减少 75% 的模型体积，推理速度提升 2-4 倍。量化后模型体积可以压缩 3-4 倍。CANN Kit 的 LLM 一站式量化工具支持 4bit 低位量化（权重量化 → 激活量化 → 量化参数提取三段式流程），推荐 INT4 权重量化 + FP16 激活组合。

剪枝：移除模型中不重要的连接或神经元，减小模型规模。结构化剪枝可以直接减少计算量，非结构化剪枝需要专用硬件支持。剪枝可带来 2-10 倍压缩比和 1.5-3 倍推理加速。

知识蒸馏：用大模型（教师模型）指导小模型（学生模型）训练，让小模型获得接近大模型的性能。适合需要保留大模型能力但又要控制体积的场景。

NAS（神经网络架构搜索） ：自动搜索最优的模型结构，在给定约束下（如参数量、推理时延）找到性能最优的架构。

移动端部署建议：优先选择小参数量、量化后的模型。不要假设任意模型都能直接走 NPU，先用 CPU/可用后端跑通小模型，再评估端侧性能。

二、MindSpore Lite 端侧推理实战

2.1 推理链路的核心对象

MindSpore Lite 的推理链路包含以下核心对象：

Model（模型对象） ：MindSpore Lite 最核心的类，负责模型的加载、编译和推理。一个 Model 实例对应一个推理会话，支持多线程安全调用。

Context（上下文） ：定义推理的运行环境，包括设备类型（CPU/GPU/NPU）、线程数、算子偏好等。Context 的配置直接决定了推理性能。

Tensor（张量） ：数据容器，承载模型的输入和输出。支持多种数据类型（float32、float16、int8 等），并提供了零拷贝的数据传递机制。

Delegate（委托） ：硬件加速的适配层。通过 Delegate 机制，MindSpore Lite 可以将部分或全部算子卸载到 NPU/GPU 上执行，实现硬件加速。

核心原则：Context 和 Model 是长生命周期的，应该在应用启动时初始化、在应用退出时释放。不要在每次推理时重复创建和销毁，否则会导致不必要的性能开销。每次推理时重复创建 Model 会导致模型文件反复加载，耗时可能高达数百毫秒。

2.2 模型转换

MindSpore Lite 使用 .ms 格式模型进行推理。对于第三方框架模型，可以使用 MindSpore Lite 提供的模型转换工具 converter_lite 转换为 .ms 模型。支持 MindSpore / TensorFlow Lite / Caffe / ONNX 等模型格式。

ONNX 模型转换命令示例：

./converter_lite --fmk=ONNX --modelFile=model.onnx --outputFile=model \
  --saveType=MINDIR --inputShape="input:1,3,224,224"

其中 --fmk 指定源框架，--modelFile 指定输入模型路径，--outputFile 指定输出路径，--saveType=MINDIR 保存为 MindIR 格式，--inputShape 指定输入形状。

2.3 完整推理实现

以下示例展示了一个端侧图像分类器的完整实现：

import { mindSporeLite } from '@kit.MindSporeLiteKit';
import { common } from '@kit.AbilityKit';

export class ImageClassifier {
  private model: mindSporeLite.Model | null = null;
  private context: mindSporeLite.Context | null = null;

  async loadModel(abilityContext: common.UIAbilityContext): Promise<void> {
    try {
      // 1. 配置 Context（推理后端优先使用 NPU）
      const contextConfig: mindSporeLite.Context = {
        deviceType: mindSporeLite.DeviceType.NPU,
        threadNum: 2,
        precisionMode: mindSporeLite.PrecisionMode.PRECISION_MODE_AUTO
      };
      // 2. 创建 Model 实例并加载模型文件
      this.model = await mindSporeLite.loadModelFromFile(
        abilityContext, contextConfig, 'model.ms');
    } catch (err) {
      console.error('模型加载失败:', err);
    }
  }

  async classify(imageBytes: ArrayBuffer): Promise<number> {
    if (!this.model) throw new Error('模型未加载');

    // 设置输入数据
    const inputs: mindSporeLite.MSTensor[] = this.model.getInputs();
    inputs[0].setData(imageBytes);

    // 执行推理
    const outputs: mindSporeLite.MSTensor[] = await this.model.predict(
      inputs, this.context);

    // 读取输出结果（分类得分最高的类别索引）
    const outputData = new Float32Array(outputs[0].getData());
    return outputData.indexOf(Math.max(...outputData));
  }

  release(): void {
    if (this.model) {
      this.model = null;
      this.context = null;
    }
  }
}

2.4 流式推理

流式推理适用于需要实时展示生成过程的场景，如端侧大模型的逐字输出。开启后推理结果分多次通过回调逐步返回，每次返回部分内容，仅最后一次携带非空的停止原因。

async function streamingPredict(model: mindSporeLite.Model,
  input: ArrayBuffer): Promise<void> {
  await model.predictAsync(input, (partialResult: string, isFinished: boolean) => {
    if (isFinished) {
      console.info('推理完成');
    } else {
      // 逐步展示部分结果
      updateUI(partialResult);
    }
  });
}

流式推理的优势：用户可以更快看到部分结果，感知延迟大幅降低；适合长文本生成场景，避免长时间等待；可以在生成过程中动态调整参数或中断生成。

2.5 推理引擎的计算图优化

推理引擎就像一个翻译官，它把训练框架产出的“原始计算图”翻译成硬件能高效执行的“优化计算图”。翻译得好不好，直接决定了推理性能的天花板。

MindSpore Lite 的推理引擎在以下方面做了大量优化：

算子融合：将多个连续的小算子融合为一个大的算子，减少内存访问和内核启动开销。例如，将卷积层、批归一化层和激活函数融合为一个算子。

常量折叠：在编译期计算常量表达式的结果，避免每次推理都重复计算。

死代码消除：移除对输出结果没有贡献的计算节点，减少不必要的计算。

内存规划：为输入输出张量预先分配内存并复用，避免每次推理都重新申请释放内存。

2.6 开发方式选择

MindSpore Lite 提供两种开发方式：

ArkTS API 方式：直接在 UI 代码中调用 MindSpore Lite ArkTS API 加载模型并进行推理，此方式可快速验证效果。适合原型验证和简单推理场景。

Native API 方式：将算法模型和调用 MindSpore Lite Native API 的代码封装成动态库，并通过 N-API 封装成 ArkTS 接口供 UI 调用。适合需要精细控制推理过程的场景，如自定义算子、多线程推理、内存复用等。

2.7 约束与限制

本 Kit 适用于 Phone、Tablet、PC/2in1、TV 和 Wearable 设备。在 Wearable 设备上，仅支持 CPU 推理。模拟器不支持 NPU 后端。

三、系统内置 AI 控件集成

3.1 主体分割与文本提取

HarmonyOS 在 Image 组件上内置了 AI 分析能力，通过 .enableAnalyzer(true) 即可开启。AI 识图功能通过聚合 OCR（光学字符识别）、主体分割、实体识别、多目标识别等 AI 能力，提供场景化的文本识别、主体分割、识图搜索功能。

visionImageAnalyzer 是 ArkTS 提供的 AI 识图组件，支持物体识别、OCR 文字识别、主体分析，和小艺识屏底层能力一致。

import { visionImageAnalyzer } from '@kit.VisionKit';

@Entry
@Component
struct ImageAIExample {
  private aiController: visionImageAnalyzer.VisionImageAnalyzerController
    = new visionImageAnalyzer.VisionImageAnalyzerController();

  aboutToAppear(): void {
    this.aiController.on('textAnalysis', (text: string) => {
      console.info(`文字分析结果: ${JSON.stringify(text)}`);
    });
    this.aiController.on('selectedTextChange', (text: string) => {
      console.info(`选中文字: ${JSON.stringify(text)}`);
    });
    this.aiController.on('objectAnalysis', (result: Object) => {
      console.info(`物体识别结果: ${JSON.stringify(result)}`);
    });
  }

  build() {
    Stack() {
      Image('rabbit.jpg', {
        types: [
          ImageAnalyzerType.TEXT,     // 文字识别
          ImageAnalyzerType.SUBJECT   // 主体识别
        ],
        aiController: this.aiController
      })
        .enableAnalyzer(true)
        .objectFit(ImageFit.Contain)
    }
  }
}

权限声明：需要在 module.json5 中声明系统能力 SystemCapability.AI.VisionImageAnalyzer。

典型应用场景：文档扫描（识别图片中的文字，支持复制、翻译、搜索）、商品识别（识别图片中的主体，实现以图搜图）、截图分析（识别截图中的文字，快速提取关键信息）。

3.2 实体识别

在 Text 组件上开启实体识别能力，可自动识别文本中的电话号码、网址、地址、时间、邮箱等实体，并提供快捷操作。传统做法需要开发者手动识别这些内容并添加点击事件，而 HarmonyOS 提供了 enableDataDetector 属性，可以自动识别文本中的特殊内容并提供交互能力。

Text(this.textContent)
  .enableDataDetector(true)
  .dataDetectorConfig({
    types: [
      TextDataDetectorType.PHONE_NUMBER,  // 电话号码
      TextDataDetectorType.URL,           // 链接
      TextDataDetectorType.EMAIL,         // 邮箱
      TextDataDetectorType.ADDRESS,       // 地址
      TextDataDetectorType.DATE           // 日期
    ]
  })

检测到的实体将以可交互的高亮样式呈现，用户可以点击识别出的内容直接触发相应操作（如打开浏览器、拨打电话等）。

典型应用场景：聊天记录（自动识别消息中的电话、地址、链接，支持一键拨号、导航、打开链接）、邮件客户端（识别邮件正文中的联系方式）、新闻阅读（识别新闻中的地址、时间）。

3.3 端侧问答模型

官方提供了基于端侧问答模型的智能问答组件示例，模型部署于本地设备，无需依赖云端，支持实时交互与离线运行。使用 @kit.DataAugmentationKit 能力实现：通过 Init 接口拉起端侧大模型，通过 Chat 接口实现智慧问答。

该组件支持 PC/2in1 设备，需 HarmonyOS 6.0 Beta3 及以上版本。模型管理应用首次被拉起时，需同意在 HarmonyOS 上管理本地 AI 模型后下载 Qwen 模型，等待模型下载完成后即可进行端侧问答。

四、AI 辅助代码生成与开发提效

4.1 DevEco Code

DevEco Code 是一款专为 HarmonyOS 开发场景打造的开箱即用工具，覆盖代码编写、问题修复、编译构建、功能验证等开发各阶段。提供了 Build、Plan、Goal 三种预置配置，并集成 HarmonyOS 工程开发相关能力。针对 HarmonyOS 开发场景进行了专门适配，能够更好地理解 ArkTS、项目结构以及相关开发流程。

安装命令：npm install -g @deveco/deveco-code

三种预置配置：

• Build：专注于代码生成和构建，适合快速实现功能。
• Plan：专注于方案设计和架构规划，适合复杂功能的拆解。
• Goal：专注于目标达成和问题解决，适合调试和优化。

4.2 DevEco CLI

DevEco CLI 适合希望将 HarmonyOS 开发能力接入现有 AI Agent 的开发者和团队。基于 DevEco Studio 开发工具原子能力，通过命令行提供工程创建、语法检查、编译构建、打包和模拟器运行等能力。AI Agent 能自主发现和调用 DevEco CLI 命令行，即可快速完成项目初始化、检查、构建、运行等操作。

安装命令：npm install -g @deveco/deveco-cli

典型使用场景：在 CI/CD 流水线中集成 DevEco CLI，实现自动化构建和测试；将 DevEco CLI 接入现有的 AI Agent，扩展其 HarmonyOS 开发能力；在脚本中批量执行工程创建、编译、打包等操作。

4.3 DevEco Studio 内置 AI 辅助编程

DevEco Studio 内置 CodeGenie，具备自然语言代码生成能力。在对话框内输入代码需求描述，点击发送，将自动生成符合要求的代码段。CodeGenie 提供代码修改能力，在对话框内输入需求描述，生成符合要求的代码，提升代码质量与开发效率。

从 DevEco Studio 6.0.2 Release 版本开始，代码修改使用的是 HarmonyOS Act 智能体。在 Changed Files 中可查看被修改的文件，支持一键接受或拒绝所有修改，并支持在问答区编译验证功能。

典型使用场景：

• 生成页面骨架代码（如“创建一个带有搜索框和列表的首页”）
• 生成数据模型和接口定义（如“定义待办事项的数据模型”）
• 生成测试用例（如“为 TodoViewModel 编写单元测试”）
• 解释和修复代码错误（如“这段代码为什么编译不通过”）

4.4 AI 驱动 UI 的设计理念

AI 驱动 UI 的核心思想是：UI 由任务驱动而非页面驱动。用户需求 → AI → 动态 UI。ArkUI 的声明式 UI 框架天然支持状态驱动、组件组合、动态更新，非常适合 AI 动态生成和调整界面的场景。

在服务卡片场景中，AI 驱动型动态布局引擎（AI Layout Engine）基于用户行为画像、设备上下文、使用频次及语义意图等多维特征，实时预测最优卡片尺寸、内容权重、交互焦点与呈现顺序。其底层依托分布式任务调度框架与轻量级 AI 推理引擎（集成 MindSpore Lite 微型模型），支持端侧毫秒级布局决策；在 UI 层则通过 Declarative UI 框架中的 @BuilderParam、@Observed/@ObjectLink、LazyForEach 等高阶响应式机制，实现卡片内容模块的按需加载。

AGenUI 是高德与阿里千问 C 端应用团队联合发布的首个覆盖 iOS、Android、HarmonyOS 三端的端云一体原生 A2UI 开源框架。它由 AI 负责描述“界面意图”，客户端负责“原生呈现”，只需一套通用界面协议就能无缝适配鸿蒙手机、平板、车机、智慧屏、穿戴等多种终端设备。鸿蒙版 AGenUI 相较 iOS、Android 端对应版本，渲染性能提升 20%，内存占用降低 18%，多设备界面呈现与交互体验高度统一。

AI 驱动 UI 的实现路径：

1. 意图理解：通过自然语言处理理解用户需求
2. 布局决策：根据意图和设备上下文决定 UI 结构
3. 组件生成：动态生成 ArkUI 组件树
4. 数据绑定：将数据与组件绑定，实现状态驱动
5. 交互反馈：根据用户反馈持续优化 UI

五、综合实战：端侧图像分类完整链路

以下示例综合运用 MindSpore Lite、Image 组件 AI 能力和状态管理，实现一个完整的端侧图像分类应用：

import { mindSporeLite } from '@kit.MindSporeLiteKit';
import { image } from '@kit.ImageKit';
import { common } from '@kit.AbilityKit';

@Entry
@ComponentV2
struct ImageClassifyPage {
  @Local result: string = '';
  @Local isProcessing: boolean = false;
  @Local confidence: number = 0;
  private classifier: ImageClassifier = new ImageClassifier();
  private context = this.getUIContext().getHostContext() as common.UIAbilityContext;

  async aboutToAppear(): Promise<void> {
    await this.classifier.loadModel(this.context);
  }

  aboutToDisappear(): void {
    this.classifier.release();
  }

  async classifyImage(pixelMap: image.PixelMap): Promise<void> {
    this.isProcessing = true;
    try {
      const imageBuffer = await this.pixelMapToBuffer(pixelMap);
      const classIndex = await this.classifier.classify(imageBuffer);
      this.result = this.getLabel(classIndex);
      this.confidence = 0.95;
    } catch (err) {
      console.error('推理失败:', err);
      this.result = '识别失败';
    } finally {
      this.isProcessing = false;
    }
  }

  private async pixelMapToBuffer(pixelMap: image.PixelMap): Promise<ArrayBuffer> {
    const info = await pixelMap.getImageInfo();
    const buffer = new ArrayBuffer(info.size.width * info.size.height * 4);
    await pixelMap.readPixelsToBuffer(buffer);
    return buffer;
  }

  private getLabel(index: number): string {
    const labels = ['猫', '狗', '鸟', '鱼', '兔子'];
    return labels[index] || '未知';
  }

  build() {
    Column({ space: 20 }) {
      Text('端侧图像分类').fontSize(24).fontWeight(FontWeight.Bold)

      if (this.isProcessing) {
        Column({ space: 12 }) {
          LoadingProgress().width(48).height(48)
          Text('识别中...').fontSize(14).fontColor('#999')
        }
      } else if (this.result) {
        Column({ space: 8 }) {
          Text(`识别结果：${this.result}`).fontSize(20)
          Text(`置信度：${(this.confidence * 100).toFixed(1)}%`)
            .fontSize(14).fontColor('#666')
        }
      }

      Button('选择图片并识别')
        .width('100%')
        .height(48)
        .backgroundColor('#007DFF')
        .onClick(async () => {
          // 打开图片选择器，获取 PixelMap 后调用 classifyImage
        })
    }
    .width('100%')
    .height('100%')
    .padding(20)
    .justifyContent(FlexAlign.Center)
  }
}

性能优化要点：模型加载放在 aboutToAppear 中异步执行，避免阻塞首帧渲染；推理过程使用 isProcessing 状态展示加载提示，避免用户误操作；推理完成后及时释放中间资源，避免内存泄漏；对于连续推理场景，复用同一个 Model 实例，避免重复加载。

六、性能优化与安全防护

6.1 推理性能优化

模型层面：使用量化模型（INT8/INT4）减小体积和加速推理。对于固定输入形状的场景，使用静态形状模型避免动态形状的开销。MindSpore Lite 团队分享的 CPU 混合精度推理方案，通过混合精度子图调度、IO 免拷贝等关键技术，将鸿蒙内置翻译模型的推理内存优化至 66MB，相比原始 100MB 以上显著降低。

线程层面：推理放 Worker/native 线程执行，避免阻塞 UI 主线程。根据设备 CPU 核心数合理设置 threadNum，通常 2-4 线程即可。

内存层面：复用输入输出 Tensor，避免每次推理重新分配。对于大模型，使用内存映射（mmap）加载模型文件，减少内存占用。

调度层面：使用格物推理服务的 QoS 感知调度，在系统资源紧张时自动降级，保障用户体验。

6.2 模型安全防护

模型加密：对模型文件进行加密处理，在存储和传输过程中保护模型的完整性和保密性。可以使用对称加密算法或非对称加密算法对模型文件进行加密，只有在需要使用模型时才进行解密。

模型签名：在模型发布和更新时，对模型进行签名，确保模型的来源可靠且未被篡改。HarmonyOS 的安全 SDK 提供了 ModelGuard API，可在模型加载前自动校验数字签名、验证哈希摘要、触发 TEE 内安全解密。

密钥管理：严禁明文密钥写入 resources/base/element/string.json，反对使用 SharedPreferences 存储密钥，必须通过 HUKS 创建“受设备绑定+用户认证+时效约束”的三重策略密钥。

6.3 隐私合规

数据最小化：仅采集业务所必需的数据，避免过度收集。

本地优先：优先在端侧完成推理，避免上传用户数据到云端。

用户可控：提供明确的隐私政策，让用户了解数据的使用方式，并提供关闭 AI 功能的选项。

审计追溯：记录 AI 系统决策和执行过程，支持事后审计与责任追溯。

七、多元化习题

习题 1（判断题）

题目：在 MindSpore Lite 推理中，Context 和 Model 对象应该在每次推理时重新创建，以确保推理结果的准确性。

答案：错误

解读：Context 和 Model 是长生命周期的，应该在应用启动时初始化、在应用退出时释放。不要在每次推理时重复创建和销毁，否则会导致不必要的性能开销。

习题 2（单选题）

题目：以下哪个组件是 HarmonyOS 内置的轻量化 AI 引擎，提供统一推理接口和多后端硬件加速能力？

A. CANN Kit
B. Neural Network Runtime Kit
C. MindSpore Lite Kit
D. HiAI Foundation Kit

答案：C

解读：MindSpore Lite Kit 是 HarmonyOS 内置的轻量化 AI 引擎，提供统一推理接口和多后端硬件加速能力。CANN Kit 面向 Kirin 芯片平台提供统一的接入和运行环境，Neural Network Runtime Kit 是跨芯片推理计算运行时，HiAI Foundation Kit 是统一接入和运行时环境。

习题 3（多选题）

题目：关于端侧 AI 方案的选型决策，以下说法正确的有（多选）：

A. 图像文字识别、主体分割等常见场景优先使用系统内置 AI 控件
B. 有 ONNX/TFLite 等格式的预训练模型时，使用 MindSpore Lite 进行模型转换和推理
C. 端侧大模型部署建议使用 1B 以下的量化模型
D. 所有 AI 场景都应该优先使用端侧大模型方案

答案：A、B、C

解读：图像文字识别、主体分割等常见场景优先使用系统内置 AI 控件，零代码集成，选项 A 正确。有预训练模型时使用 MindSpore Lite 进行模型转换和推理，选项 B 正确。端侧大模型部署建议使用 1B 以下的量化模型，选项 C 正确。并非所有 AI 场景都应该使用端侧大模型，应根据业务需求选择最合适的方案，选项 D 错误。

习题 4（代码填空题）

题目：请补全以下代码，使用 Image 组件开启文字识别和主体识别能力。

Image('photo.jpg', {
  types: [
    ImageAnalyzerType.______________,   // 文字识别
    ImageAnalyzerType.______________    // 主体识别
  ],
  aiController: this.aiController
})
  .______________(true)
  .objectFit(ImageFit.Contain)

答案：TEXT、SUBJECT、enableAnalyzer

解读：ImageAnalyzerType.TEXT 表示文字识别，ImageAnalyzerType.SUBJECT 表示主体识别。通过 .enableAnalyzer(true) 开启 AI 分析能力。

习题 5（代码改错题）

题目：以下 MindSpore Lite 代码存在资源管理问题，请指出问题并修正。

async function predict(imageBytes: ArrayBuffer): Promise<number> {
  const context: mindSporeLite.Context = {
    deviceType: mindSporeLite.DeviceType.NPU,
    threadNum: 2
  };
  const model = await mindSporeLite.loadModelFromFile(context, 'model.ms');
  const inputs = model.getInputs();
  inputs[0].setData(imageBytes);
  const outputs = await model.predict(inputs, context);
  const result = new Float32Array(outputs[0].getData());
  return result.indexOf(Math.max(...result));
}

答案：代码在每次调用 predict 时都重新创建 Context 和 Model，违反了长生命周期对象的管理原则。修正方案是将 Context 和 Model 作为类的成员变量，在应用启动时初始化一次，在应用退出时释放：

export class Classifier {
  private model: mindSporeLite.Model | null = null;
  private context: mindSporeLite.Context | null = null;

  async init(): Promise<void> {
    this.context = {
      deviceType: mindSporeLite.DeviceType.NPU,
      threadNum: 2
    };
    this.model = await mindSporeLite.loadModelFromFile(
      this.context, 'model.ms');
  }

  async predict(imageBytes: ArrayBuffer): Promise<number> {
    if (!this.model || !this.context) throw new Error('模型未加载');
    const inputs = this.model.getInputs();
    inputs[0].setData(imageBytes);
    const outputs = await this.model.predict(inputs, this.context);
    const result = new Float32Array(outputs[0].getData());
    return result.indexOf(Math.max(...result));
  }

  release(): void {
    this.model = null;
    this.context = null;
  }
}

解读：Context 和 Model 是长生命周期的，应该在应用启动时初始化、在应用退出时释放。不要在每次推理时重复创建和销毁，否则会造成严重的性能问题。

习题 6（简答题）

题目：简述 HarmonyOS 端侧 AI 的分层架构，以及各层的职责。

答案：HarmonyOS 的 AI 开放层次由上到下分别为：MindSpore Lite Kit 是 HarmonyOS 内置的轻量化 AI 引擎，提供统一推理接口和多后端硬件加速能力，自动硬件调度优先 NPU，算力不足自动降级 DSP/CPU。Neural Network Runtime Kit 是面向 AI 领域的跨芯片推理计算运行时，作为中间桥梁连通上层 AI 推理框架和底层加速芯片。CANN Kit 面向 Kirin 芯片平台为各种 AI 模型和算法提供统一的接入和运行环境。格物推理服务是 API 20 引入的 QoS 感知推理加速和资源管理优化服务。HiAI Foundation Kit 是统一接入和运行时环境，面向 Kirin 硬件平台，支持 Ascend C 自定义算子编程语言。

解读：五层架构从开发者接口到底层硬件加速，形成了完整的端侧 AI 技术栈。开发者只需关注 MindSpore Lite 的接口，底层调度和优化由系统自动完成。

习题 7（简答题）

题目：简述端侧 AI 方案选型的决策框架，以及各层判断的核心依据。

答案：端侧 AI 方案选型决策框架分为四层判断。第一层判断：系统是否已内置该能力？如果是图像文字识别、主体分割、实体识别等常见场景，优先使用系统内置 AI 控件，零代码集成。第二层判断：是否有可用的预训练模型？如果有 ONNX/TFLite/Caffe 等格式的预训练模型，使用 MindSpore Lite 进行模型转换和推理。第三层判断：是否需要大模型能力？如果需要文本生成、代码生成、复杂推理等大模型能力，考虑端侧大模型部署，建议使用 1B 以下的量化模型。第四层判断：是否有极致性能要求？如果是游戏渲染、相机预览等场景，考虑 XComponent + EGL/OpenGL ES + NPU 加速方案。

解读：选型决策框架的核心逻辑是“从简到繁、从内置到自定义”。优先使用系统能力，其次使用预训练模型，最后才考虑自定义大模型部署。

习题 8（简答题）

题目：简述端侧大模型部署的策略，以及模型压缩的核心技术。

答案：端侧大模型部署策略包括：推理框架选型（选择能编译到 HarmonyOS/ohos arm64 的 native 方案）；模型文件管理（放 rawfile 或首次启动复制到沙箱，注意包体、内存和加载时间）；线程与体验管理（推理放 Worker/native 线程，做流式输出、取消、温控和低内存保护）。模型压缩的核心技术包括：量化（把 FP32 模型转化为低 bit 模型，减少 75% 体积，推理速度提升 2-4 倍）、剪枝（移除不重要的连接或神经元，2-10 倍压缩比）、知识蒸馏（用大模型指导小模型训练）、NAS（神经网络架构搜索）。对于移动端内置本地大模型，通常优先选择小参数量、量化后的模型。

解读：端侧大模型部署的核心挑战在于资源受限。通过合理的推理框架选型、模型压缩和线程管理，可以在有限资源下实现高效的端侧推理。

习题 9（简答题）

题目：简述端侧 AI 的安全防护策略，包括模型加密、签名验证和密钥管理。

答案：端侧 AI 的安全防护策略包括三个层面。模型加密：对模型文件进行加密处理，在存储和传输过程中保护模型的完整性和保密性。模型签名：在模型发布和更新时对模型进行签名，确保模型的来源可靠且未被篡改，HarmonyOS 的安全 SDK 提供了 ModelGuard API，可在模型加载前自动校验数字签名、验证哈希摘要、触发 TEE 内安全解密。密钥管理：严禁明文密钥写入 resources/base/element/string.json，反对使用 SharedPreferences 存储密钥，必须通过 HUKS 创建“受设备绑定+用户认证+时效约束”的三重策略密钥。

解读：端侧 AI 的安全防护需要从模型文件、密钥管理、运行环境三个层面构建纵深防御。模型加密保护静态数据，签名验证确保来源可信，密钥管理防止密钥泄露，三者协同构建完整的安全体系。

习题 10（简答题）

题目：简述 AI 驱动 UI 的设计理念与实现路径，以及 ArkUI 在其中的优势。

答案：AI 驱动 UI 的核心思想是：UI 由任务驱动而非页面驱动。实现路径包括五个步骤：意图理解（通过自然语言处理理解用户需求）、布局决策（根据意图和设备上下文决定 UI 结构）、组件生成（动态生成 ArkUI 组件树）、数据绑定（将数据与组件绑定，实现状态驱动）、交互反馈（根据用户反馈持续优化 UI）。ArkUI 在其中的优势在于：声明式 UI 框架天然支持状态驱动、组件组合、动态更新，非常适合 AI 动态生成和调整界面的场景。在服务卡片场景中，AI 驱动型动态布局引擎基于用户行为画像、设备上下文、使用频次及语义意图等多维特征，实时预测最优卡片尺寸、内容权重、交互焦点与呈现顺序。

解读：AI 驱动 UI 代表了界面开发的未来方向。传统 UI 开发需要预先定义所有可能的界面状态，而 AI 驱动 UI 可以根据用户意图动态生成界面，实现真正的个性化体验。

八、本节知识点总结

端侧 AI 技术栈全景
由上层到下层分别为 MindSpore Lite Kit（推理引擎）、CANN Kit（硬件加速）、格物推理服务（QoS 调度）、Neural Network Runtime Kit（跨芯片运行时）、HiAI Foundation Kit（底层计算支撑）。五层架构从开发者接口到底层硬件加速，形成了完整的端侧 AI 技术栈。

端侧 AI 方案选型决策框架
四层判断：系统是否已内置该能力？是否有可用的预训练模型？是否需要大模型能力？是否有极致性能要求？优先使用系统能力，其次使用预训练模型，最后才考虑自定义大模型部署。

MindSpore Lite 推理链路
核心对象为 Context（应用全局，配置推理后端与线程数）和 Model（按需加载，管理输入输出）。两者均为长生命周期对象，应在应用启动时初始化、退出时释放。支持 ArkTS API 和 Native API 两种开发方式。推理引擎通过算子融合、常量折叠、死代码消除、内存规划等优化策略提升性能。

系统内置 AI 控件
Image 组件通过 .enableAnalyzer(true) 开启主体分割与文本提取能力。Text 组件通过 .enableDataDetector(true) 开启电话号码、网址、地址、时间、邮箱等实体识别。端侧问答模型通过 @kit.DataAugmentationKit 实现智慧问答。

AI 辅助开发工具
DevEco Code 提供开箱即用的 HarmonyOS AI 开发助手，覆盖代码生成、问题修复等全流程。DevEco CLI 将 HarmonyOS 开发能力接入现有 AI Agent。DevEco Studio 内置 CodeGenie 支持自然语言代码生成与一键应用。

AI 驱动 UI
核心思想是 UI 由任务驱动而非页面驱动。实现路径包括意图理解、布局决策、组件生成、数据绑定、交互反馈五个步骤。AGenUI 是首个覆盖三端的端云一体原生 A2UI 开源框架。

模型压缩技术
量化、剪枝、知识蒸馏、NAS 是四种核心压缩技术。量化可减少 75% 体积、推理速度提升 2-4 倍；剪枝可带来 2-10 倍压缩比。移动端建议使用 1B 以下的量化模型，先在 CPU 上跑通再评估 NPU 性能。

性能优化与安全防护
推理性能优化包括模型层面（量化）、线程层面（Worker/native 线程）、内存层面（Tensor 复用）、调度层面（QoS 感知）。安全防护包括模型加密、模型签名、密钥管理三个层面。

下节预告

第9课将进入 ArkUI 的分布式能力与多设备协同的学习，涵盖分布式软总线、跨设备数据同步、分布式任务调度以及一次开发多端部署的架构设计方法。