鸿蒙NPU实战：30行代码实现本地OCR图片文字识别

提示：本文介绍鸿蒙端侧调用 NPU 芯片完成 OCR 图片文字提取的完整实战过程，基于 ML Kit 文本识别能力，用极简代码实现本地推理，不涉及云服务，也为后续 AI 应用开发提供一个可复用的调用范式。

鸿蒙实战：调用华为手机 NPU 芯片，30 行代码实现本地“图片文字提取” (OCR)

作为一个做过几年鸿蒙应用开发的人，我一直觉得端侧 AI 才是鸿蒙生态最有意思的地方。毕竟手机上随时带着摄像头，拍个菜单、拍个路牌、拍个PPT，能直接识别出文字并复制编辑，这需求太刚需了。更关键的是，华为手机本身自带 NPU（神经网络处理单元），如果让它跑本地推理，识别过程不需要请求服务器，优点非常明显：快、免流量、数据不出设备，还稳定。

这篇东西我不打算堆理论，直接记录一次实战——用 HarmonyOS 的 ML Kit 文本识别能力，配合手机自带的能力调度，最终用 30 行代码左右实现了本地 OCR“图片文字提取”。整个流程跑下来，我对鸿蒙端侧 AI 的调用方式有了更落地的理解，也想把工程搭建、代码编写、参数配置、问题排查这些细节都梳理出来，给打算在鸿蒙上做端侧智能的开发者当个参考。

这项目适合谁？适合那些对鸿蒙应用开发有一定基础、想在应用里快速集成 OCR 功能、同时又不满足于只会调云接口的人。你要懂点 ArkTS 语法，会建工程，知道 UI 和事件的基本写法，剩下的就跟着这篇文章一步步来。

1. 项目整体思路与设计拆解

1.1 为什么坚持做端侧 OCR，而不是云端识别

如果只是想在应用里加一个识别文字的功能，最省事的办法是调云厂商的 OCR 接口。上传图片、等待返回、解析 JSON，整个链路网上现成的 SDK 一大堆，开发效率确实高。但我最终还是选择了端侧，就是这个项目触动了几个现实问题：

第一个，隐私问题。我做的是一个偏个人工具的 Demo，拍下来的图片往往包含聊天记录、票据信息或者笔记内容，这些东西如果传到云端，哪怕服务商承诺不存储，心里也不踏实。数据不出设备这件事，在端侧推理上天然成立，一张图从拍照到识别完毕，自始至终都在手机本地，这是很大的信任优势。

第二个，网络依赖。云接口对网络环境要求高，地铁、地下车库、电梯里经常没信号，一拍就转圈圈、转完还超时，那体验相当糟糕。但 NPU 推理完全没有网络参与，本地算完本地出结果，延迟稳定在毫秒级，这是端侧方案最让人放心的地方。

第三个，长期成本。现在很多 OCR 云接口都在调整计费策略，对调用频次和企业认证有各种要求，个人开发者维护一套云账号和鉴权体系挺折腾的。而端侧识别是硬件本身的能力，属于“一次性投入，无限次使用”，没有按量计费的后顾之忧。

当然端侧识别也不是没有缺点，比如对超大分辨率图片处理比较吃力、生僻字和特殊字体的覆盖率不如云端大模型，但它在主流场景下表现已经非常可靠。所以我的判断是：如果做的是工具类、隐私敏感类、离线优先类应用，端侧 OCR 是性价比极高的选择。

1.2 NPU 在整套方案里扮演的角色

说到“调用 NPU”，有人可能觉得是要直接操纵类似 GPU 的计算核心，跟写汇编一样去控制底层硬件。华为手机的 NPU 开发完全不是这个路子——它更像你开车，不需要懂发动机的每个缸怎么点火，只需要踩油门、打方向盘，剩下的交给整车系统来协调。

在这套方案里，NPU 的调度过程对开发者是“黑盒”状态。ML Kit 文本识别 SDK 在底层会通过华为 AI 框架把算子任务分发到 NPU 硬件上执行。开发者做的事情只是：把图片数据交给识别器，识别器调用底层推理引擎，推理引擎再决定所需的神经网络模型如何分配到 CPU、GPU 和 NPU 上。这本身是操作系统级的资源调度，应用层根本不需要去自己管理。

那是不是意味着跟 NPU 无关？也不是。关键在于：ML Kit 识别能力会主动优先生成 NPU 可执行的模型格式，并借助 NPU 加速卷积运算、归一化等密集计算。这意味着在同样耗电条件下，NPU 能让识别过程跑得更快、更稳。我们在方案的代码层面看不到 NPU，但硬件层面 NPU 确实在干活。这种“无感调用”其实是系统能力成熟的体现。

1.3 ML Kit 文本识别能力全景

HarmonyOS 的 ML Kit 是官方提供的端侧智能开发套件，里面涵盖了不少能力：文本识别、文档检测、表格识别、二维码/条码识别、图像分割、人脸检测、语言检测、文本翻译等等。这次我用到的就是其中的文本识别（Text Recognition）能力。

ML Kit 的文本识别接口设计思路偏向“开箱即用”——创建识别器、传入图片、接收结构化结果，三步走。接口提供两种识别模式：

一个是文本检测模式。它识别的是图片里的“文字块”和“文本行”，专注于把文字区域找出来并输出每一行的文本内容，适合自然场景、多语言混排、字体不规则的图片。

另一个是文档检测模式。它针对的是相对规整的文档版面，识别的粒度细到单词级别，输出包含单词级的坐标和置信度信息，适合扫描件、截图、印刷文档这类场景。

我实际测试下来，两种模式的应用场景差异还挺明显的。拍路牌和菜单用文本检测模式识别效率和精度都不错，因为背景复杂但文字密度不算高。而扫描的合同、拍摄的纸质文档用文档检测模式效果更好，因为识别结果能按段落顺序排列、单词切分准确。我这里选择的文本检测模式作为实现的起点，因为它的适用范围更广、理解门槛也低，你后面换成文档检测模式只需改一个枚举值。

2. 环境准备与工程骨架搭建

2.1 开发环境与设备要求

在动手写代码之前，先说清楚环境怎么搭。我用的开发环境是 DevEco Studio，这是鸿蒙应用开发的官方 IDE，基于 IntelliJ 平台，界面和操作逻辑对用过 Android Studio 的人来说几乎可以无缝上手。

版本方面需要留意：ML Kit 文本识别能力从 API 12 开始逐步完善，目前稳定支持需要 API 12 及以上。我在工程里的 compileSdkVersion 和 targetSdkVersion 都指定到 API 12 或更高，兼容范围设置成 5.0.0(12) 起。如果你用的是更旧版本的 SDK，编译时可能会碰到接口不存在或者枚举值不匹配的错误。

真机设备也建议选对：最好是搭载麒麟芯片的手机或者平板，这样才能真正触发 NPU 加速的调用路径。如果是 HarmonyOS 模拟器，也能跑通逻辑代码，但模拟器没有 NPU，你无法验证硬件加速的实际性能表现。语言方面因为 ML Kit 内置了多种语言的模型，默认对中英文识别效果就很好，不需要额外下载语言包。

有一个点是很多人容易忽略的——存储权限。从系统的“图库”选择图片进行识别时，如果用的是 picker 方式，应用可以获得临时访问权限，并不需要申请存储权限。但如果你的应用通过文件路径直接读取公共目录的图片，就需要申请 ohos.permission.READ_IMAGEVIDEO 权限。我建议优先用 picker 方式，既贴合隐私保护规范，也可以少申请一个运行时权限，省去不少麻烦。

2.2 快速创建一个鸿蒙工程骨架

这部分我直接说结论，DevEco Studio 里新建工程的步骤已经足够傻瓜化：选择 Empty Ability 模板，填入项目名称和包名，选择 compatible SDK 版本为 5.0.0(12) 或更高，等构建系统把基础工程生成完毕即可。

工程创建之后需要做两件事：第一件事是在 module.json5 里面确认权限声明，如果需要读取图库图片，加上对应权限条目；第二件事是在代码里处理和权限相关的动态申请，HarmonyOS 的运行时权限弹窗逻辑和 Android 类似，需要用户在设置里授权后才能调用敏感能力。

我这次的使用场景是从图库选图，所以用了 picker 方式，不需要申请存储权限。但为了兼容某些直接访问路径的场景，我还是在 module.json5 中声明了图片读取权限，并且在 MainAbility 的 onCreate 里通过权限检查来动态处理授权结果。如果你也是做工具类应用，我建议一步到位：把权限逻辑写清楚，方便后续扩展。

2.3 UI 布局与业务逻辑分层的考虑

虽然标题说的是 30 行代码实现 OCR，但那是指调用识别能力的核心逻辑，不是整个应用只有 30 行。一个完整体面的 OCR Demo 必然包含：选图入口、图片展示区、识别按钮、结果文本区，以及把这几块串起来的状态管理代码。

我搭建了一个简单的分层：页面层负责 UI 展示和用户交互，它维护选中的图片 URI、识别中的 loading 状态、识别结果文本；业务逻辑层封装了一个独立的 OcrService 类，负责从图片来源创建 PixelMap、调用 ML Kit 识别器、解析识别结果。这个分层的好处是：后续你要换识别模式、接入文档检测或者把识别能力扩展到支付页面、扫题页面，都可以快速复用同一个业务类，而不是把所有代码堆在 UI 里。

页面布局我用的是 Column + Button + Image + Scroll + Text 的组合。图片区域用 Image 组件加载选中的图片 URI，结果区域用 Scroll 包住 Text，方便长文本滚动浏览。整个 UI 代码在真实工程里大概 60 行左右，加上核心识别逻辑的 30 行，整体工程很精简，可读性也强。

3. 核心代码实现与逐段深度讲解

3.1 导入模块与初始化识别器

鸿蒙的 AI 能力统一收敛在 Core Vision Kit 里，文本识别属于其中的一个子模块。所以你第一件事是从 @kit.CoreVisionKit 导入 textRecognition，这是全套能力的入口。同时我们还需要用 image 模块来加载和处理图片，以及用到 common 来获取上下文。

下面是导入和初始化部分的代码，我把它作为核心代码的第一段：

import { textRecognition } from '@kit.CoreVisionKit'; import { image } from '@kit.ImageKit'; import { common } from '@kit.AbilityKit'; import { BusinessError } from '@kit.BasicServicesKit'; function createRecognizer(context: common.Context): textRecognition.TextRecognizer { let config: textRecognition.TextRecognitionConfig = { textRecognitionType: textRecognition.TextRecognitionType.TEXT_DETECTION, maxLineCount: 50 }; return textRecognition.createTextRecognizer(context, config); }

这段代码里有两个值得说的点。

第一是 TextRecognitionConfig 的 textRecognitionType，这个字段决定了识别模式。前面提到的 TEXT_DETECTION 模式，和另一个 DOCUMENT_DETECTION 模式，就是用这个枚举来切换的。我把识别模式设为 TEXT_DETECTION，因为它对光照不均、拍摄角度略有倾斜的自然图片处理更从容。

第二是 maxLineCount 参数，这是对识别结果行数的预期限制。它不是硬性的过滤条件，更像一个软性提示：假设一个画面里一般出现不超过 50 行文字，SDK 会在内部对模型输出进行调整。这里我取了个 50 的保守值，原因是我这个 Demo 会处理 PPT 截图、书本照片等文字密度较高的图，行数太少可能截断边缘的小字。如果你只识别菜单、路牌这种稀疏文字场景，可以调低到 10~20，没准识别速度和内存占用会有一点点改善。

注意：createTextRecognizer 是异步初始化模型。第一次调用时会触发模型加载，可能会等待几百毫秒到一两秒不等，之后复用同一个识别器就非常快。所以用全局单例持有识别器，不要在每次识别时重复创建，这是性能优化的关键经验。

3.2 从图片 URI 构建 PixelMap

鸿蒙的 image 模块提供了从多种图片来源创建 PixelMap 的能力，PixelMap 本质上是一块像素内存区域，也是很多图像类 API 的标准输入格式。这里我们接收图库返回的图片 URI，通过 createImageSource 创建一个图片源，再调用 createPixelMap 得到一个可供识别器使用的像素图对象。

async function createPixelMapFromUri(uri: string): Promise<image.PixelMap> { let source: image.ImageSource = image.createImageSource(uri); let pixelMap: image.PixelMap = await source.createPixelMap(); return pixelMap; }

这里有个很容易踩的坑：createImageSource 支持文件路径，也支持 uri。文件路径和 uri 不是一个东西，如果你是拿到的 content:// 开头或者 file:// 开头的字符串，直接传进去有时候没问题，有时候会解析失败。我在项目里从 picker 拿到的 selectResult 里的 uri，直接传给 createImageSource 实测可以正常工作。

还有个内存相关的经验：PixelMap 是原始像素数据，一张 4000×3000 的照片解出来的 PixelMap 可能占用几十 MB 内存。所以识别完之后必须手动调用 pixelMap.release()，否则频繁选图识别很容易把内存撑爆。我一开始就没注意这个释放动作，连续识别几张图片后系统内存持续增长，后来在逐帧排查时才发现是 PixelMap 没有释放的问题。

3.3 调用识别器并解析结果

识别器创建好了，图片也到位了，现在调用识别接口，做结果解析。这段是整个流程的心脏：

async function recognizeTextFromPixelMap(recognizer: textRecognition.TextRecognizer, pixelMap: image.PixelMap): Promise<string> { let result: textRecognition.TextRecognitionResult = await recognizer.recognizeText({ pixelMap: pixelMap, isRefresh: false }); let lines: textRecognition.TextLine[] = result.lines; let sb: string[] = []; for (let line of lines) { let values: textRecognition.TextValue[] = line.values; if (values && values.length > 0) { sb.push(values[0].value); } sb.push('\n'); } return sb.join(''); }

我需要解释一下这里为什么遍历的是 lines，并且每行取 values[0]。认识它的结构是掌握这套 API 的关键。

其实 TextRecognitionResult 的结构有三层：最外层是 TextBlock（文本块）数组，一个块代表图片里一块独立的文字区域，通常是一段话或者一个段落；每个 TextBlock 包含若干 TextLine（文本行）；每一行又包含若干 TextValue（单词/字符组合值）。在实际输出中，如果直接 result.lines 拿到的其实是所有 TextLine 组成的扁平数组，同时每个 TextLine 内部还有一个 String 类型的 value 字段作为“整行文本”的快捷方式。

那为什么要用 values[0].value 而不是直接 line.value？我在探索输出结构时发现，在 TEXT_DETECTION 模式下，line.value 和 line.values[0].value 大部分时候结果等价。但 line.values[0].value 更贴近“识别出的最可信结果”，在有些复杂排版场景下 values 数组里可能包含候选词，取第一个是整体置信度最高的组合。为了稳妥，我最终选择了解析 values 数组并取第一个元素。如果你不关心这种细粒度差异，直接拼 line.value 也行，得到的最终文本不会有太大出入。

另一个关键参数是 isRefresh。如果设为 true，会忽略上一帧结果、强制重新推理一帧；设为 false 则表示不刷新，重复调用可能返回缓存。由于我们是处理单张图片而不是连续视频流，所以设 false 避免出现不必要的重推理。

3.4 把三段代码合并成完整调用链

有了以上三个函数，我们把它们串起来，配合 UI 按钮事件，就得到完整的识别链路：

async function onRecognizeClick(context: common.Context, uri: string): Promise<string> { let recognizer = createRecognizer(context); let pixelMap = await createPixelMapFromUri(uri); try { let recognizedText = await recognizeTextFromPixelMap(recognizer, pixelMap); return recognizedText; } catch (err) { let e = err as BusinessError; console.error(`OCR failed, code: ${e.code}, message: ${e.message}`); throw err; } finally { if (pixelMap) { pixelMap.release(); } recognizer.release(); } }

这里是真正的“30 行代码”核心调用逻辑。加上导入和其他辅助代码，差不多 40~50 行，但核心的识别调用与结果解析正好维持在 30 行左右。我在 finally 中统一释放 PixelMap 和识别器，避免中途抛异常导致资源泄漏——try-finally 在这里不是可选，而是必须。

关于调用链有个整体认知值得强调：整个调用过程没有任何一步是直接写“NPU 计算”相关代码的。我们做的是把正确的数据以正确的格式交给 ML Kit，NPU 的算子调度、模型推理、内存交换全部由系统框架在背后完成。很多做嵌入式或者底层开发的朋友一开始会不理解这种“看不到硬件”的实现方式，但实际上这正是移动端 AI 开发的标准范式：应用层永远只关心业务，硬件加速的复杂度交给系统来隔离。

3.5 完整可运行的 Demo 代码框架

把上面的逻辑放到一个实际页面里，大致长这样：

@Entry @Component struct OcrDemoPage { @State selectedImageUri: string = ''; @State resultText: string = ''; build() { Column({ space: 12 }) { Button('从图库选择图片') .onClick(async () => { let picker = new photoAccessHelper.PhotoViewPicker(); let options = { MIMEType: photoAccessHelper.PhotoViewMIMETypes.IMAGE_TYPE }; let result = await picker.select(options); if (result && result.photoUris.length > 0) { this.selectedImageUri = result.photoUris[0]; } }) if (this.selectedImageUri.length > 0) { Image(this.selectedImageUri) .width('90%') .height(220) .objectFit(ImageFit.Contain) } Button('识别图片文字') .onClick(async () => { if (!this.selectedImageUri) return; let context = getContext(this) as common.UIAbilityContext; let text = await onRecognizeClick(context, this.selectedImageUri); this.resultText = text; }) Scroll() { Text(this.resultText) .width('100%') .padding(12) .copyOption(TextCopyOption.LocalDevice) } .layoutWeight(1) .backgroundColor('#f5f5f5') } .width('100%') .height('100%') .padding(16) } }

这一段 UI 代码它会创建一个非常直观的交互界面：先选图，点击识别按钮后下方区域显示识别出的文本。其中 copyOption 设置允许长按复制识别结果，这个小细节对于 OCR 工具类应用来说非常实用，用户的最终目的是拿到文字，能不能方便复制决定了这个工具好不好用。

4. 运行验证与结果体验实录

4.1 多场景图片实测记录

代码跑通以后，我分别拍了三组照片来验证实际效果。

第一组是自然场景，我对着商场里的楼层导览牌拍了一张。导览牌背景复杂，还带着反光，但识别器很快标出了“餐饮”“购物”“影院”“停车场”等关键词，位置基本准确，英文“Restaurant”“Cinema”也一并识别出来。整体效果让我比较满意，排布顺序大致按从左到右、从上到下，跟人眼阅读顺序一致。

第二组是印刷文档，我用手机拍了一页书。这页书排版规整，字体统一，识别出的文字跟原书对照，错字率很低。段落换行基本符合原始版式。由于书籍扫描场景文字密度较高，识别结果里偶尔把标点符号识别成空格，但不影响整体阅读。

第三组是票据照片，我拍了一张消费小票。小票这种热敏纸打印的字体常常带轻微模糊，识别结果里金额数字全部正确，但有个别中文商品名出现了同音字错误。比如小票上的“农夫山泉”被识别成“农夫山 泉”，中间多了个空格。这类问题在端侧 OCR 里难以完全避免，尤其是拍摄角度不正、字体过小的情况下。如果你想提高此类场景的准确率，建议切换到 DOCUMENT_DETECTION 模式并增加二值化预处理。

4.2 性能表现：NPU 参与带来什么变化

我通过 DevEco Studio 自带的 Profiler 工具对识别过程做了性能分析。加载同一张 3000×2000 像素的照片，在真机上从调用识别接口到拿到完整结果，耗时大约在 380ms 左右。这个速度对单张图片识别来说已经足够快捷。

更有意思的是耗电表现。从 Profile 数据看，识别期间 CPU 占用率明显下降，关键计算路径上能观察到 NPU 相关的处理痕迹。因为 ML Kit 内部会把预处理后的图像张量交给 NPU 执行卷积与特征提取。在实际操作中，连续识别 20 张图片后，设备背部没有明显发热，这在纯 CPU 推理的场景下是难以想象的——之前我用纯 CPU 方案跑同样的任务，连续 10 张左右手机已经烫手了。

这里需要提醒一点：不能只看接口耗时来判断 NPU 是否生效。识别接口耗时包含图像预处理、张量布局转换、模型推理、结果后处理的全链路，其中前几步都在 CPU 上完成。NPU 加速的体现主要是模型推理阶段，你在应用层很难直接测到这个阶段的独立耗时，更多的判断依据是整体功耗和热表现，以及系统跟踪工具里 NPU 硬件的活动记录。

4.3 30 行代码之外还需要做什么

“30 行代码实现 OCR”这个说法对了一半。核心调用确实是 30 行，但真正产品化的 OCR 功能还需要若干配套能力。

一是异常处理。图片格式不支持、PixelMap 创建失败、识别器初始化失败，这些错误都要有明确提示。在我实测中，偶尔会出现一张损坏的图片文件，直接传给 createImageSource 会抛异常，必须用 try-catch 接住并反馈给用户。

二是状态管理。识别过程中需要显示 loading 状态，防止用户重复点击多次识别导致内存任务堆积。我在按钮回调里用一个布尔状态来管控：点击后置为识别中，按钮变为不可点击状态，识别完成后再恢复。

三是生成式响应式 UI。识别结果需要支持一键复制、导出分享、清空重识等功能，这些在真实工具里都是刚需。Demo 可以不做，但产品必须做，否则用户拿到文字还得手动选中复制，体验大打折扣。我在这个 Demo 里就加了 copyOption 和复制按钮，虽然多写了十几行代码，但整个应用的完成度立刻就不同了。

5. 常见问题与排查技巧实录

5.1 问题一：createTextRecognizer 返回 undefined

我最初运行时碰到过一个问题：createTextRecognizer 返回了 undefined，导致后续调用直接报空指针。排查后发现是设备上的基础服务没有初始化完成，在某些特定场景下系统还未就绪。

详细说一下排查思路：

• 确认设备的 HarmonyOS 版本是否真的达到了 API 12 级别，“开发者选项”里能查看 SDK 版本。
• 确认工程里是否引入了正确的 SDK 依赖，有一些历史工程用的是旧的 API 版本，创建 TextRecognizer 的代码会被混淆解析。
• 用 try-catch 包裹调用，打印具体错误码。如果错误码类似 201 或者 2401004，大概率是“调用的接口不是系统接口”或“能力未就绪”，对应调整调用时机。

解决方案是尽量在页面 onPageShow 阶段做识别器初始化，而不是在模块顶层静态创建。因为此时 Ability 已经完成启动，系统服务绑定更稳定。

5.2 问题二：识别结果为空字符串

这个问题我碰到过两次，一次是传入的图片 PixelMap 太模糊，另一次是传入的图片不是标准的 RGB 色彩空间。

排查路径是这样的：先检查 PixelMap 是否为空，确认图片解码成功；然后检查图片分辨率，如果图片太小（比如 100×100 的缩略图），模型确实可能识别不出任何文本；接着检查原图方向，某些图片带有 EXIF 旋转信息，直接解码后内容是横躺的，识别效果自然很差。

解决办法是添加一个预处理步骤：如果需要，可以将 PixelMap 转换为统一的 RGBA 格式，或者使用 image 模块的 rotate 接口按 EXIF 信息旋转矫正。我实际使用的图片是手机拍照直出的，系统会自动矫正方向，但如果你从网络下载图片或者接收他人发送的图片，EXIF 方向问题就会高发，接一个 exif 解析库是长期方案。

5.3 问题三：识别接口偶发报错“模型加载失败”

这是一个让我花了些功夫排查的问题。在应用安装后首次调用识别时，偶发出现“模型未加载”的错误，再点一次却又正常了。

分析原因：ML Kit 在首次创建识别器时会将模型文件从应用沙箱读取并加载到内存。如果此时应用刚好处于后台或者系统内存压力较大，模型加载可能被系统回收，导致首次调用失败。

针对性方案：

• 在应用启动后的页面空闲期，提前调用一次 createTextRecognizer 和一次识别接口做“预热”，把模型加载到内存。
• 如果识别器被系统回收，捕获特定错误码后重新创建识别器并重试一次。
• 对识别操作增加一个简单的重试机制，失败一次后自动重建识别器再识别，实测可以把首识成功率提高到接近 100%。

> 经验体会：这类问题在端侧 AI 开发里很常见。你写的调用逻辑是没问题的，但模型生命周期管理、预热时机、重试策略这些“看不见的工程细节”才是线上好用的关键。

5.4 常见问题排查速查表

我把开发期间遇到的其他常见问题整理成一张速查表，方便你直接对照排查。

5.5 几个能看懂的调优参数实战心得

关于可调参数，我可以分享几个经过实测的经验值。

第一个是 maxLineCount。默认值可能偏向平衡，但在我的 PPT 截图上常出现漏行问题，调到 50 后基本能覆盖绝大多数场景。注意这个值不是越大越好，过于大的行数预期可能导致模型在一些噪声区域产生误检，所以需要根据目标场景合理设置。

第二个是识别模式的切换。文本检测模式在自然场景表现优秀，但到了文档扫描、票据拍照这类文字密集场景，文档检测模式的段落排序能力就体现出来了，尤其是多栏排版的印刷物，文档检测模式能更好地维持阅读顺序。如果你要做扫描全能王式的应用，建议直接采用文档检测模式。

第三个是图片解码策略。大分辨率图片直接解码成 PixelMap 非常耗费内存和时间。我做了个实验：4000×3000 的图片直接解码和压缩到 2000×1500 后解码，后者内存占用下降约 60%，而识别精度几乎无变化。因为 OCR 模型本身有输入大小限制，过高的分辨率不仅不会带来精度提升，反而会拖慢预处理速度。用 image 模块的 createPixelMap 接口里指定的 decodeSize 参数，或者先等比缩图再识别，是控制资源浪费的有效方式。

6. 从 OCR 到更广泛的端侧智能扩展

跑通了 OCR，得到的不只是“一个能识别文字的 Demo”，而是一条可复制的端侧 AI 能力接入路径。同样的三步走模式——创建能力引擎、传入媒体数据、解析结构化结果——可以平移使用到 ML Kit 里的其他能力上。

比如文档检测能力：识别器的创建方式几乎一致，只是配置里某些枚举换成文档检测模式，输出变成了包含段落、Tab 位、单元格的复杂结构。如果你想让 OCR 能力从“提取文字”升级成“理解版面”，整个基础工程不需要重写。

再比如文本翻译能力：在 OCR 识别出文字后，可以把结果透明地接入翻译服务，实现“拍照翻译”。这在旅游、学习场景中价值极大，而且识别与翻译都在端侧完成的话，全程无网络也能工作。

更进一步，如果你想把自定义模型接入应用来做图像分类、目标检测，可以通过 Core ML Kit 的模型推理接口加载你转换好的模型文件。这时候需要关注的问题就从“怎么调用系统 API”变成了“怎么把模型转换到系统支持的格式、如何管理模型生命周期、如何平衡精度与功耗”。但好在之前积累的工程经验和调试方法都是通用的。

我这段时间做下来的体会是：鸿蒙端侧 AI 的能力边界比很多人想象中要宽，而门槛又比想象中要低。你不需要是算法工程师，也不需要懂算子实现细节，只需要把系统提供的“积木”搭出合理的结构，就能让硬件计算能力为产品所用。把第一块积木（OCR）搭好，后续的扩展就顺理成章了。

一个小技巧收尾：调用识别接口之前，先用 image 模块的 ImageSource 读取一下图片的原始尺寸，如果宽高有任意一边超过 3000 像素，先等比缩到 3000 以内再识别。这个操作对精度影响极小，却能明显压缩内存与推理时间，算是我多次对比测试后最值得分享的细节。