1. 为什么设备端AI突然成了移动开发的必选项三年前我做一款图像标注工具时第一反应是把图片传到服务端做识别。结果上线第一周就收到大量反馈地铁里没信号用不了、上传一张图要等三四秒、用户担心隐私不愿意传。这三个问题像三根钉子把我钉在了必须把模型搬到设备上这条路上。后来接触到 ML Kit 这类设备端 AI 工具包才发现很多能力其实早就可以在本地跑根本不需要绕一圈服务端。设备端 AI说白了就是把推理这件事从远端服务器挪到用户手里的手机上。ML Kit 是其中比较有代表性的一套工具它把常见的视觉、文本、语音等能力封装成相对易用的接口让移动开发者不用从零训练模型也能在 App 里做出拍照识物实时翻译文字识别这类功能。它适合谁适合那些想快速验证 AI 功能、又不想背服务器成本和隐私包袱的移动开发者也适合做原型、做工具类 App 的独立开发者。这一章我想聊的不是 API 文档的复述而是我在实际项目里踩过的坑、做过的取舍以及那些文档里不会写、但真正决定成败的细节。比如为什么有些能力必须用设备端、有些反而适合放服务端比如模型体积和启动延迟之间怎么权衡比如同一个功能在不同机型上表现差异巨大时该怎么排查。这些才是把 ML Kit 用好的关键。2. 设备端推理和服务端推理的边界到底在哪2.1 延迟、隐私、成本这三本账要分开算很多人一上来就问设备端是不是一定比服务端好这个问题本身就问错了。它俩不是替代关系而是各有适用区间。我一般用三本账来判断延迟账、隐私账、成本账。延迟账最好理解。一次服务端推理的耗时 网络往返 排队 推理 回传。网络往返在移动网络下动辄一两百毫秒起步弱网环境直接飙到秒级。而设备端推理没有网络这一段耗时基本就是模型加载加推理本身。对于实时类需求比如相机预览里做人脸检测、做文字框选服务端方案几乎不可能做到跟手设备端是唯一选择。隐私账是很多人忽略的。用户拍了一张身份证、一张病历、一段聊天截图你把这些原始数据传到自己的服务器就意味着你要承担存储、加密、合规的全部责任。而设备端推理的原始数据根本不出设备你只拿到一个结果责任边界清晰得多。这也是为什么金融、医疗类 App 越来越倾向把敏感识别放在本地。成本账则相反。设备端推理不花服务器钱但花的是用户的电量和算力。如果你的功能是低频的、批量的比如每天凌晨跑一次全量数据清洗那放服务端反而更划算因为服务器可以跑大模型、可以批处理、可以随时升级。设备端受限于手机算力模型不能太大升级还得等用户更新 App。2.2 一张表看清什么场景该选哪边我把常见场景整理成一张对照表实际选型时直接对号入座场景特征推荐方案核心理由相机实时预览处理设备端延迟要求毫秒级网络不可控处理敏感原始数据设备端数据不出设备合规压力小低频批量任务服务端可用大模型可批处理易升级需要频繁更新模型服务端设备端更新依赖 App 发版离线可用要求设备端无网络也能工作超大模型高精度服务端手机内存和算力扛不住这张表不是绝对的实际项目里经常是混合方案。比如一个文档扫描 App实时取景框用设备端做边缘检测和文字定位保证跟手用户确认后再把裁剪好的小图传到服务端做高精度 OCR 和结构化提取。这样既保证了交互流畅又拿到了高精度结果还把上传的数据量压到了最小。2.3 混合方案里最容易被忽视的数据流设计混合方案听起来很美但数据流设计不好会翻车。我见过一个团队取景框里设备端检测到的坐标和服务端返回的坐标用了两套不同的参考系结果裁剪出来的图总是偏。后来统一成以原始帧为基准、所有坐标都相对原始帧才解决。我的经验是设备端和服务端的中间产物一定要定义清楚。设备端输出什么坐标、置信度、类别服务端接收什么两边坐标系怎么对齐图像有没有被缩放或旋转这些都要在接口文档里写死。别小看这一步它决定了你后期排查问题是几分钟还是几天。3. ML Kit 的能力版图与选型逻辑3.1 视觉、文本、语音三大块各自擅长什么ML Kit 的能力大致可以分成三块视觉类、文本类、语音类。视觉类包括人脸检测、条码扫描、图像标注、对象检测与追踪、姿势检测、自拍分割等文本类包括文字识别、语言识别、智能回复、翻译语音类主要是语音识别。选型时我有个简单原则先看有没有现成能力再看精度够不够最后才考虑自定义模型。ML Kit 的现成能力都是 Google 预训练好的开箱即用适合快速验证。但它们的精度和适用场景是固定的比如图像标注能识别几百个通用类别但你要识别特定品牌的商品它就不行了这时候就得走自定义模型那条路。这里有个坑要提醒ML Kit 的部分能力是设备端的部分是云端的名字很像但行为完全不同。比如文字识别设备端版本支持拉丁字母等有限语种云端版本支持更多语种但需要联网。选型时一定要看清文档里标的是 on-device 还是 cloud别想当然。3.2 预置能力和自定义模型的分界线什么时候该用预置能力什么时候该上自定义模型我的判断标准是如果预置能力的类别覆盖了你的需求且精度可接受就用预置的否则才考虑自定义。自定义模型在 ML Kit 里通常通过 TensorFlow Lite 接入。你可以用自己标注的数据训练一个 TFLite 模型然后集成进来。这条路灵活但成本高要准备数据、要训练、要调优、要处理模型体积。我一般建议先用预置能力做个 Demo 给需求方看确认交互和体验没问题再决定要不要投入做自定义模型。很多时候预置能力够用只是大家一开始期望过高。3.3 模型体积和启动延迟的权衡这是设备端 AI 最现实的约束。一个模型动辄几十兆用户下载 App 时看到包体积就劝退了。ML Kit 的预置能力大多通过 Google Play 服务动态下发不占 App 包体积这是它的一大优势。但自定义模型就得打进包里或者做动态下载。启动延迟同样关键。模型第一次加载要读文件、初始化可能几百毫秒甚至更久。我的做法是在 App 启动或进入相关页面时预加载模型别等到用户点了按钮才加载。预加载的时机要选好别和主线程的渲染抢资源一般放在后台线程做。提示模型加载是 IO 密集型操作别在主线程做否则会掉帧甚至 ANR。4. 从零跑通一个设备端文字识别功能4.1 环境准备里最容易漏掉的几步跑通一个设备端文字识别环境准备阶段有几个点特别容易漏。第一是依赖版本ML Kit 的各个能力是分模块的你要用文字识别就得单独引入对应的依赖别指望一个总包全搞定。第二是相机权限和存储权限实时识别要相机权限识别本地图片要读存储权限两个都要在清单里声明并在运行时申请。第三是设备兼容性。有些能力依赖特定的硬件或系统版本比如某些视觉能力需要较新的系统。我一般会在代码里做能力检测不支持时降级到备用方案而不是直接崩溃。// 以文字识别为例先做能力可用性判断 val recognizer TextRecognition.getClient(TextRecognizerOptions.DEFAULT_OPTIONS) // 处理输入图像 val image InputImage.fromBitmap(bitmap, 0) recognizer.process(image) .addOnSuccessListener { visionText - // 拿到识别结果遍历文本块 for (block in visionText.textBlocks) { val text block.text val box block.boundingBox // 用 box 在预览上画框 } } .addOnFailureListener { e - // 失败要区分是模型没准备好还是图像有问题 }4.2 输入图像预处理决定了识别上限很多人以为识别效果差是模型不行其实八成是输入图像没处理好。设备端模型对输入尺寸、方向、对比度都很敏感。我总结了几条预处理经验图像方向要对。相机拍出来的图带 EXIF 旋转信息直接喂给模型可能识别出乱码。要先按 EXIF 把图转正。尺寸要合适。太大浪费算力太小丢细节。一般把长边缩到一千像素左右比较平衡。对比度要够。逆光、阴影下的文字识别率会明显下降必要时做一次灰度化和自适应二值化。裁剪要准。如果只关心某个区域先裁出来再识别能显著提升准确率。这几步做下来同一个模型的效果能差出一大截。我做过对比预处理前后识别准确率能差百分之二三十这比换模型划算多了。4.3 结果后处理把原始输出变成可用数据模型吐出来的是一堆文本块和坐标直接展示给用户往往很乱。后处理这一步决定了最终体验。常见的处理包括按坐标把文本块排序成阅读顺序、把相邻的块合并成行和段、用正则提取结构化字段比如从发票里提金额和日期、过滤掉置信度低的噪声。排序这块有个细节不同语言的阅读顺序不一样中文是从左到右从上到下但有些场景是竖排。我一般先按 Y 坐标分行行内再按 X 排序这样对大多数横排文本都适用。合并的时候要注意块之间的间距阈值太松会把两行并成一行太紧又会把一句话拆散这个阈值得根据实际分辨率调。5. 那些文档不会告诉你的实战坑5.1 不同机型表现差异巨大的排查思路同一个功能旗舰机上丝滑千元机上卡成幻灯片这是设备端 AI 最常见的抱怨。排查时我按这个顺序走先看是不是模型加载慢再看是不是推理本身慢最后看是不是渲染拖累。模型加载慢通常是 IO 问题可以看日志里加载耗时。推理慢多半是算力问题可以尝试降低输入分辨率或换更轻的模型。渲染拖累则常出现在实时预览场景检测和绘制如果在同一线程绘制会阻塞检测。我的做法是把检测放后台线程绘制放主线程中间用队列传递结果丢帧也不影响检测节奏。还有一个隐蔽的坑某些机型对特定算子支持不好会回退到 CPU 慢速路径。这种情况只能通过实测覆盖主流机型来发现没有捷径。5.2 内存和电量的隐形消耗设备端 AI 是内存和电量大户。一个持续运行的检测器内存占用可能几十兆电量消耗也很可观。我踩过的坑是页面退出了但检测器没释放导致内存一直涨。后来养成习惯在页面生命周期结束时显式关闭检测器、释放图像资源。电量方面实时检测别用最高帧率。相机预览三十帧但检测没必要每帧都跑隔一两帧跑一次肉眼几乎看不出差别电量却能省不少。这个降频策略是我在多个项目里验证过的性价比极高。5.3 模型更新与版本兼容的坑预置能力通过系统服务更新一般不用你操心。但自定义模型一旦发出去更新就是麻烦事。用户不更新 App你就没法更新模型。我的做法是给自定义模型做动态下载模型文件放远端App 启动时检查版本并按需下载。这样模型迭代不用等发版。但动态下载又带来新问题下载失败怎么办、下载中用户断网怎么办、新旧模型结果不一致怎么办。我的经验是保留一个内置的兜底模型下载失败就用兜底的模型版本要和结果解析逻辑绑定别出现新模型输出格式变了但解析代码没更新的情况。6. 把设备端 AI 做稳的几个工程习惯6.1 能力检测与优雅降级不是所有设备都支持所有能力。上线前一定要做能力检测不支持时给出合理的降级方案。比如不支持某个视觉能力时可以提示用户当前设备暂不支持此功能或者退回到手动操作。千万别让用户点了按钮直接崩溃那是最差的体验。6.2 用真实数据做回归测试模型效果不能只靠实验室数据。我一般会收集一批真实场景的样本包括各种光照、角度、机型做成回归测试集。每次改预处理或后处理逻辑都跑一遍看指标有没有退化。这个习惯帮我避免了好几次改了一个地方另一个场景崩了的事故。6.3 给推理留出预算做性能规划时别把推理时间算得太满。我一般给推理留出总交互预算的三分之一以内剩下的留给渲染、网络和其他逻辑。比如一个交互总预算三百毫秒推理最好控制在一百毫秒内这样才有余量应对波动。我在实际项目里最大的体会是设备端 AI 的成败往往不在模型本身而在这些工程细节。模型是别人训练好的但预处理、后处理、线程调度、内存管理、降级策略这些才是你能掌控、也最能拉开差距的地方。把这几块做扎实一个普通的预置能力也能做出很稳的体验反过来再好的模型配上糟糕的工程照样卡顿、崩溃、识别不准。最后分享一个小技巧如果你不确定某个能力在目标机型上到底行不行别猜写个最小 Demo 装到真机上跑一遍。设备端 AI 这东西真机实测永远比文档和模拟器靠谱。 
长河君 · 2026/10/21 18:02:45 · 阅读 1.2k 设备端AI实战：ML Kit移动端推理选型与工程优化指南
1. 为什么设备端AI突然成了移动开发的必选项三年前我做一款图像标注工具时第一反应是把图片传到服务端做识别。结果上线第一周就收到大量反馈地铁里没信号用不了、上传一张图要等三四秒、用户担心隐私不愿意传。这三个问题像三根钉子把我钉在了必须把模型搬到设备上这条路上。后来接触到 ML Kit 这类设备端 AI 工具包才发现很多能力其实早就可以在本地跑根本不需要绕一圈服务端。设备端 AI说白了就是把推理这件事从远端服务器挪到用户手里的手机上。ML Kit 是其中比较有代表性的一套工具它把常见的视觉、文本、语音等能力封装成相对易用的接口让移动开发者不用从零训练模型也能在 App 里做出拍照识物实时翻译文字识别这类功能。它适合谁适合那些想快速验证 AI 功能、又不想背服务器成本和隐私包袱的移动开发者也适合做原型、做工具类 App 的独立开发者。这一章我想聊的不是 API 文档的复述而是我在实际项目里踩过的坑、做过的取舍以及那些文档里不会写、但真正决定成败的细节。比如为什么有些能力必须用设备端、有些反而适合放服务端比如模型体积和启动延迟之间怎么权衡比如同一个功能在不同机型上表现差异巨大时该怎么排查。这些才是把 ML Kit 用好的关键。2. 设备端推理和服务端推理的边界到底在哪2.1 延迟、隐私、成本这三本账要分开算很多人一上来就问设备端是不是一定比服务端好这个问题本身就问错了。它俩不是替代关系而是各有适用区间。我一般用三本账来判断延迟账、隐私账、成本账。延迟账最好理解。一次服务端推理的耗时 网络往返 排队 推理 回传。网络往返在移动网络下动辄一两百毫秒起步弱网环境直接飙到秒级。而设备端推理没有网络这一段耗时基本就是模型加载加推理本身。对于实时类需求比如相机预览里做人脸检测、做文字框选服务端方案几乎不可能做到跟手设备端是唯一选择。隐私账是很多人忽略的。用户拍了一张身份证、一张病历、一段聊天截图你把这些原始数据传到自己的服务器就意味着你要承担存储、加密、合规的全部责任。而设备端推理的原始数据根本不出设备你只拿到一个结果责任边界清晰得多。这也是为什么金融、医疗类 App 越来越倾向把敏感识别放在本地。成本账则相反。设备端推理不花服务器钱但花的是用户的电量和算力。如果你的功能是低频的、批量的比如每天凌晨跑一次全量数据清洗那放服务端反而更划算因为服务器可以跑大模型、可以批处理、可以随时升级。设备端受限于手机算力模型不能太大升级还得等用户更新 App。2.2 一张表看清什么场景该选哪边我把常见场景整理成一张对照表实际选型时直接对号入座场景特征推荐方案核心理由相机实时预览处理设备端延迟要求毫秒级网络不可控处理敏感原始数据设备端数据不出设备合规压力小低频批量任务服务端可用大模型可批处理易升级需要频繁更新模型服务端设备端更新依赖 App 发版离线可用要求设备端无网络也能工作超大模型高精度服务端手机内存和算力扛不住这张表不是绝对的实际项目里经常是混合方案。比如一个文档扫描 App实时取景框用设备端做边缘检测和文字定位保证跟手用户确认后再把裁剪好的小图传到服务端做高精度 OCR 和结构化提取。这样既保证了交互流畅又拿到了高精度结果还把上传的数据量压到了最小。2.3 混合方案里最容易被忽视的数据流设计混合方案听起来很美但数据流设计不好会翻车。我见过一个团队取景框里设备端检测到的坐标和服务端返回的坐标用了两套不同的参考系结果裁剪出来的图总是偏。后来统一成以原始帧为基准、所有坐标都相对原始帧才解决。我的经验是设备端和服务端的中间产物一定要定义清楚。设备端输出什么坐标、置信度、类别服务端接收什么两边坐标系怎么对齐图像有没有被缩放或旋转这些都要在接口文档里写死。别小看这一步它决定了你后期排查问题是几分钟还是几天。3. ML Kit 的能力版图与选型逻辑3.1 视觉、文本、语音三大块各自擅长什么ML Kit 的能力大致可以分成三块视觉类、文本类、语音类。视觉类包括人脸检测、条码扫描、图像标注、对象检测与追踪、姿势检测、自拍分割等文本类包括文字识别、语言识别、智能回复、翻译语音类主要是语音识别。选型时我有个简单原则先看有没有现成能力再看精度够不够最后才考虑自定义模型。ML Kit 的现成能力都是 Google 预训练好的开箱即用适合快速验证。但它们的精度和适用场景是固定的比如图像标注能识别几百个通用类别但你要识别特定品牌的商品它就不行了这时候就得走自定义模型那条路。这里有个坑要提醒ML Kit 的部分能力是设备端的部分是云端的名字很像但行为完全不同。比如文字识别设备端版本支持拉丁字母等有限语种云端版本支持更多语种但需要联网。选型时一定要看清文档里标的是 on-device 还是 cloud别想当然。3.2 预置能力和自定义模型的分界线什么时候该用预置能力什么时候该上自定义模型我的判断标准是如果预置能力的类别覆盖了你的需求且精度可接受就用预置的否则才考虑自定义。自定义模型在 ML Kit 里通常通过 TensorFlow Lite 接入。你可以用自己标注的数据训练一个 TFLite 模型然后集成进来。这条路灵活但成本高要准备数据、要训练、要调优、要处理模型体积。我一般建议先用预置能力做个 Demo 给需求方看确认交互和体验没问题再决定要不要投入做自定义模型。很多时候预置能力够用只是大家一开始期望过高。3.3 模型体积和启动延迟的权衡这是设备端 AI 最现实的约束。一个模型动辄几十兆用户下载 App 时看到包体积就劝退了。ML Kit 的预置能力大多通过 Google Play 服务动态下发不占 App 包体积这是它的一大优势。但自定义模型就得打进包里或者做动态下载。启动延迟同样关键。模型第一次加载要读文件、初始化可能几百毫秒甚至更久。我的做法是在 App 启动或进入相关页面时预加载模型别等到用户点了按钮才加载。预加载的时机要选好别和主线程的渲染抢资源一般放在后台线程做。提示模型加载是 IO 密集型操作别在主线程做否则会掉帧甚至 ANR。4. 从零跑通一个设备端文字识别功能4.1 环境准备里最容易漏掉的几步跑通一个设备端文字识别环境准备阶段有几个点特别容易漏。第一是依赖版本ML Kit 的各个能力是分模块的你要用文字识别就得单独引入对应的依赖别指望一个总包全搞定。第二是相机权限和存储权限实时识别要相机权限识别本地图片要读存储权限两个都要在清单里声明并在运行时申请。第三是设备兼容性。有些能力依赖特定的硬件或系统版本比如某些视觉能力需要较新的系统。我一般会在代码里做能力检测不支持时降级到备用方案而不是直接崩溃。// 以文字识别为例先做能力可用性判断 val recognizer TextRecognition.getClient(TextRecognizerOptions.DEFAULT_OPTIONS) // 处理输入图像 val image InputImage.fromBitmap(bitmap, 0) recognizer.process(image) .addOnSuccessListener { visionText - // 拿到识别结果遍历文本块 for (block in visionText.textBlocks) { val text block.text val box block.boundingBox // 用 box 在预览上画框 } } .addOnFailureListener { e - // 失败要区分是模型没准备好还是图像有问题 }4.2 输入图像预处理决定了识别上限很多人以为识别效果差是模型不行其实八成是输入图像没处理好。设备端模型对输入尺寸、方向、对比度都很敏感。我总结了几条预处理经验图像方向要对。相机拍出来的图带 EXIF 旋转信息直接喂给模型可能识别出乱码。要先按 EXIF 把图转正。尺寸要合适。太大浪费算力太小丢细节。一般把长边缩到一千像素左右比较平衡。对比度要够。逆光、阴影下的文字识别率会明显下降必要时做一次灰度化和自适应二值化。裁剪要准。如果只关心某个区域先裁出来再识别能显著提升准确率。这几步做下来同一个模型的效果能差出一大截。我做过对比预处理前后识别准确率能差百分之二三十这比换模型划算多了。4.3 结果后处理把原始输出变成可用数据模型吐出来的是一堆文本块和坐标直接展示给用户往往很乱。后处理这一步决定了最终体验。常见的处理包括按坐标把文本块排序成阅读顺序、把相邻的块合并成行和段、用正则提取结构化字段比如从发票里提金额和日期、过滤掉置信度低的噪声。排序这块有个细节不同语言的阅读顺序不一样中文是从左到右从上到下但有些场景是竖排。我一般先按 Y 坐标分行行内再按 X 排序这样对大多数横排文本都适用。合并的时候要注意块之间的间距阈值太松会把两行并成一行太紧又会把一句话拆散这个阈值得根据实际分辨率调。5. 那些文档不会告诉你的实战坑5.1 不同机型表现差异巨大的排查思路同一个功能旗舰机上丝滑千元机上卡成幻灯片这是设备端 AI 最常见的抱怨。排查时我按这个顺序走先看是不是模型加载慢再看是不是推理本身慢最后看是不是渲染拖累。模型加载慢通常是 IO 问题可以看日志里加载耗时。推理慢多半是算力问题可以尝试降低输入分辨率或换更轻的模型。渲染拖累则常出现在实时预览场景检测和绘制如果在同一线程绘制会阻塞检测。我的做法是把检测放后台线程绘制放主线程中间用队列传递结果丢帧也不影响检测节奏。还有一个隐蔽的坑某些机型对特定算子支持不好会回退到 CPU 慢速路径。这种情况只能通过实测覆盖主流机型来发现没有捷径。5.2 内存和电量的隐形消耗设备端 AI 是内存和电量大户。一个持续运行的检测器内存占用可能几十兆电量消耗也很可观。我踩过的坑是页面退出了但检测器没释放导致内存一直涨。后来养成习惯在页面生命周期结束时显式关闭检测器、释放图像资源。电量方面实时检测别用最高帧率。相机预览三十帧但检测没必要每帧都跑隔一两帧跑一次肉眼几乎看不出差别电量却能省不少。这个降频策略是我在多个项目里验证过的性价比极高。5.3 模型更新与版本兼容的坑预置能力通过系统服务更新一般不用你操心。但自定义模型一旦发出去更新就是麻烦事。用户不更新 App你就没法更新模型。我的做法是给自定义模型做动态下载模型文件放远端App 启动时检查版本并按需下载。这样模型迭代不用等发版。但动态下载又带来新问题下载失败怎么办、下载中用户断网怎么办、新旧模型结果不一致怎么办。我的经验是保留一个内置的兜底模型下载失败就用兜底的模型版本要和结果解析逻辑绑定别出现新模型输出格式变了但解析代码没更新的情况。6. 把设备端 AI 做稳的几个工程习惯6.1 能力检测与优雅降级不是所有设备都支持所有能力。上线前一定要做能力检测不支持时给出合理的降级方案。比如不支持某个视觉能力时可以提示用户当前设备暂不支持此功能或者退回到手动操作。千万别让用户点了按钮直接崩溃那是最差的体验。6.2 用真实数据做回归测试模型效果不能只靠实验室数据。我一般会收集一批真实场景的样本包括各种光照、角度、机型做成回归测试集。每次改预处理或后处理逻辑都跑一遍看指标有没有退化。这个习惯帮我避免了好几次改了一个地方另一个场景崩了的事故。6.3 给推理留出预算做性能规划时别把推理时间算得太满。我一般给推理留出总交互预算的三分之一以内剩下的留给渲染、网络和其他逻辑。比如一个交互总预算三百毫秒推理最好控制在一百毫秒内这样才有余量应对波动。我在实际项目里最大的体会是设备端 AI 的成败往往不在模型本身而在这些工程细节。模型是别人训练好的但预处理、后处理、线程调度、内存管理、降级策略这些才是你能掌控、也最能拉开差距的地方。把这几块做扎实一个普通的预置能力也能做出很稳的体验反过来再好的模型配上糟糕的工程照样卡顿、崩溃、识别不准。最后分享一个小技巧如果你不确定某个能力在目标机型上到底行不行别猜写个最小 Demo 装到真机上跑一遍。设备端 AI 这东西真机实测永远比文档和模拟器靠谱。