做移动端开发这些年我有个很直观的感受AI能力正在从“高不可攀的云服务”变成“手机里的常驻小功能”。扫个码、拍个名片、翻译一段文字、对着摄像头实时识别健身动作用户早就默认这些都是即拿即用的东西。而这些功能背后的技术底座很大一部分就是设备端AI——不上传数据、不依赖网络、直接在手机本地完成推理。ML Kit就是Google官方为这件事准备的机器学习套件。它不要求你从零训练模型也不要求你精通深度学习原理Android和iOS都能接入把几十种常见的视觉、文本识别能力封装成了几个可以直接调的API。这篇文章我会按照自己实际项目的落地顺序来讲先聊清楚为什么端上AI是趋势、ML Kit在整个技术栈里的位置再给你一张完整的能力选型地图然后从零跑通“扫码中文文字识别”的最小Demo进阶到姿态估计和分割最后把性能优化、模型交付和线上排查这些“只有踩过坑才知道”的东西全部摊开。适合正在做App功能选型的技术负责人、想给产品加AI能力但没太多模型经验的客户端开发以及准备把部分云推理迁移到本地的团队。我尽量把每一步的为什么也讲清楚而不是只丢代码。1. 为什么设备端AI是趋势ML Kit卡在什么位置1.1 四个让端上AI“不得不做”的驱动力先说结论设备端AI不是某个公司拍脑袋推的方向而是被四个非常现实的问题推着走的。第一个是隐私。很多数据天生就不该出设备。比如身份证OCR、聊天内容的情感分析、健康类App里的身体数据用户对“上传到服务器”这件事越来越敏感监管合规的要求也越来越清晰。把这些能力放到本地做意味着原始数据根本不会离开手机产品在隐私说明里可以底气十足地写“本功能完全在设备端处理”。光这一条就足以让不少团队从云端方案切回本地。第二个是实时性。网络请求一次往返至少几十毫秒加上云端排队和推理时间动辄两三百毫秒而端上推理通常可以做到十几到几十毫秒。做摄像头连续帧分析的场景比如实时姿态纠正、手势识别、AR贴纸延迟稍微一高画面就会“拖影”用户立刻觉得卡。这种场景只有端上能扛。第三个是离线可用。停车场扫码、地铁闸机、海外旅行打开翻译网络都不是可靠前提。把模型放到本地用户可以完全在无网环境下完成核心操作。这个体验一旦用户习惯了就回不去了。第四个是成本。很多人容易忽略云端推理是按调用量计费的。视频流分析每秒24帧、每帧都调云端API一个月下来账单会很吓人。而端上推理用的是用户手机的算力边际成本几乎为零。对大用户量产品来说这可能是最现实的决定性因素。1.2 ML Kit的定位它是工具箱不是炼丹炉ML Kit很容易被误解成“又一个AI框架”所以先说清楚它的位置。它其实做了三层事情第一层预训练好的模型比如文字识别模型、条码模型、姿态模型第二层推理运行时也就是怎么在手机上高效地跑模型第三层任务化的API封装把“输入图片-预处理-推理-返回结构化结果”这一整套流程打包成几个方法调用。你不需要关心模型输入要多大、输出怎么解析直接拿结果就行。如果你了解底层生态可以这样理解它和周边工具的区别。TensorFlow Lite是真正的推理引擎好比给你一套基础厨具和原材料ML Kit是直接封装好的菜包拆开加热就能上桌而MediaPipe是更灵活的流水线框架相当于给你整套锅碗瓢盆和菜谱你可以自由组合和定制。ML Kit适合“我要快速做出一个能用的功能”MediaPipe适合“我有定制管线需求、愿意自己调”直接上TFLite则适合“我对自己训练模型有执念”。三者不是替代关系是可以配合使用的。在iOS端苹果也有对应的Core ML和Vision框架。思路是一样的系统级能力、本地推理、离线优先。跨平台团队最合理的做法是业务层抽象一套统一接口Android侧用ML KitiOS侧用系统框架上层只感知结果。2. ML Kit能力全景与选型地图2.1 视觉类API一张表看清你的需求落在哪个接口ML Kit的视觉能力是重头戏。我按实际使用频率给你过一遍并标注一些只有用起来才会发现的细节。API做什么典型场景备注Barcode Scanning识别一维码/二维码扫码登录、商品条码、电子票券支持QR、Code128、EAN等多种格式可指定格式减小开销Text RecognitionOCR文字识别名片扫描、票据识别、拍照搜题分拉丁、中文、日文、韩文等独立模型不能混用Face Detection人脸检测与特征分类美颜预处理、人脸计数、微笑/睁眼检测偏“检测”不是人脸识别比对Pose Detection人体姿态关键点健身计数、瑜伽比对、动作捕捉有快速与高精度两套模型支持单帧与流式Object Detection物体检测与跟踪货架商品识别、车辆识别返回目标框与类别也能只做框不做分类Selfie Segmentation人像抠图背景替换、抠像、虚化对半身自拍效果好速度快Subject Segmentation更细粒度主体分割商品抠图、多人分区比自拍分割适用范围更广模型更大Image Labeling通用图片分类图片自动标签、内容过滤只能给最可能的几个类别不是精确识别Digital Ink手写笔迹识别手写输入、电子签名需要配套的模型配置中文支持逐步完善我建议的选型逻辑是先想清楚“用户输入是什么、输出要什么”。扫码和OCR是最高频、最稳定的人脸和姿态适合需要实时反馈的交互场景分割适合做视觉美化图片标签适合做粗筛不能当精确分类用。因为ML Kit的模型是“一个API一个模型”体积和资源消耗各不相同别为了省事把所有能力都初始化一遍按功能按需加载。2.2 自然语言类API本地完成了你想象不到的活视觉之外文本方向也有一整套能力用起来比想象中更省心。翻译支持几十种语言关键是有离线语言包。用户下载对应语言包后飞行模式下也能翻译这在国际旅行、跨语言客服场景非常实用。智能回复Smart Reply则会在本地分析收到的会话内容给出简短候补回复。注意它不会把内容传出去这一点在聊天类App里价值极大。语言识别用来判断一段文本是什么语言适合做输入法、内容路由的预处理。实体抽取能本地识别出邮件地址、电话、地址这类结构信息做卡片式提取很方便。还有一个做文本分类的能力带个情绪倾向模型可以本地判断评论正负面。这些能力整体上比视觉利落因为文本输入体积小、推理快资源占用也低。哪怕是中低端机跑这些也基本无感。2.3 自定义模型把你自己训练的东西塞进ML KitML Kit默认能力覆盖了大众需求但总有些场景是预训练模型照顾不到的。比如你要识别特定品牌的logo、工业零件缺陷、某一类新闻稿风格。这时候可以用自定义模型你把训练好的TFLite模型带进来由ML Kit负责加载和调度你自己管理预处理和结果解析。自定义模型有两种交付方式。一种是打进App里安装即有、离线可用但更新模型只能发新版本另一种是放在云端模型托管服务启动时动态下发模型更新不用等审核和用户升级代价是要处理下载失败、版本兼容。我的经验是模型不大、几乎不变直接打进包模型会迭代、或者不同用户需要不同模型一定走动态下发。2.4 模型托管方式bundled还是unbundled提到模型交付ML Kit里有一个很重要的隐藏选项。默认情况下部分API依赖Google Play services动态下发模型体积小、更新快但前提是设备有配套服务另一种方式是选择bundled版本依赖模型直接随App安装没有外部依赖但APK体积会明显增大。这两种方式不是随便选的它直接决定你的用户在哪些设备上能打开功能、首次打开是秒级可用还是等下载。后面的性能优化章节我会专门展开对比这里先记住这个坑不提前规划上线后一定会被“机型兼容问题”和“首次等待超时问题”来回折磨。3. 从零接入扫码与中文文本识别的最小Demo3.1 环境与依赖配置先说环境。ML Kit要求模块的minSdk在21以上项目本身用AndroidXAndroid Studio版本别太老。以扫码和中文OCR为例在模块的build.gradle.kts里添加依赖dependencies { // 请以官方Release页面为准这里只是示意版本 implementation(com.google.mlkit:barcode-scanning:17.3.0) implementation(com.google.mlkit:text-recognition-chinese:16.0.1) }如果要使用动态下载模式依赖配置不变首次调用时会自动触发模型下载。需要在AndroidManifest里申请相机权限如果功能涉及保存图片还需要对应的存储权限。权限就按最小必要来只声明相机。3.2 创建扫码器并解析结果扫码是所有能力里我推荐先接入的因为它链路短、反馈强最适合练手。创建扫码器时可以限定条码类型减少不必要的算力浪费val options BarcodeScannerOptions.Builder() .setBarcodeFormats(Barcode.FORMAT_QR_CODE, Barcode.FORMAT_CODE_128) .build() val scanner BarcodeScanning.getClient(options)然后准备InputImage。最常用的方式是从Bitmap创建注意按需缩放别把原图直接扔进去val image InputImage.fromBitmap(scaledBitmap, 0) scanner.process(image) .addOnSuccessListener { barcodes - for (barcode in barcodes) { val value barcode.rawValue ?: continue when (barcode.valueType) { Barcode.TYPE_URL - // 打开链接 Barcode.TYPE_TEXT - // 展示文本 Barcode.TYPE_WIFI - // 配置格式为WIFI:...可引导连接 else - // 其它类型 } } } .addOnFailureListener { e - // 打点 提示用户重试 }有几个细节值得说。第一扫描分辨率不是越大越好大图会让预处理耗时明显上升建议把最长的边控制在1300像素左右。第二二维码在画面中占比很小的话识别率会下降可以在进入相机的页面上画一个取景框引导用户把码放到框内同时只对框内区域做裁剪识别效果比整帧扫描好得多。第三process是异步的回调默认在主线程不要在回调里做重活解析逻辑复杂就丢到后台线程。3.3 中文文本识别别用错识别器文本识别是我踩坑最多的一个点最大的坑就是“用错模型”。ML Kit把文字识别拆成了好几个独立模型拉丁文模型不认中文字符。很多人在老设备上跑通一个Demo后直接上生产结果中文识别率惨不忍睹问题往往出在这。正确做法是明确使用中文识别器val recognizer TextRecognition.getClient( ChineseTextRecognizerOptions.Builder().build() )识别结果的结构是一棵三层树Text下面有TextBlockTextBlock下面有LineLine是最小识别单元包含Element和boundingBox。实际开发里最常用的是遍历Line拿坐标和文本用来在图片上画框、做点击选中或者拼出整段文字recognizer.process(image) .addOnSuccessListener { result - result.textBlocks.forEach { block - block.lines.forEach { line - val text line.text val box line.boundingBox // 这里可以画框、记录坐标 } } }中文OCR对输入质量更敏感。最大边小于600像素的小图基本识别不了什么昏暗、偏斜、大字号艺术字都会明显降低准确率。预处理阶段加一个“按最长边缩放到1200像素左右灰度化”的步骤对识别率提升很直接。3.4 与CameraX集成从ImageProxy拿正确方向扫码和OCR真正稳定工作的场景是接相机实时分析。CameraX是Android官方推荐的相机库配合ImageAnalysis用起来很顺手。关键点在于怎么从ImageProxy构造InputImage并且把旋转角传对class MLKitAnalyzer( private val scanner: BarcodeScanner ) : ImageAnalysis.Analyzer { Volatile private var isProcessing false override fun analyze(imageProxy: ImageProxy) { if (isProcessing) { imageProxy.close() return } isProcessing true val mediaImage imageProxy.image val rotation imageProxy.imageInfo.rotationDegrees if (mediaImage ! null) { val inputImage InputImage.fromMediaImage(mediaImage, rotation) scanner.process(inputImage) .addOnSuccessListener { barcodes - // 更新UI、播放提示音 } .addOnCompleteListener { isProcessing false imageProxy.close() } } else { imageProxy.close() isProcessing false } } }这段代码里最容易被忽略的是rotation。相机拿到的原始帧是传感器方向如果不把rotationDegrees传给ML Kit识别结果要么反着、要么永远失败。还要注意analyze方法里不能一直塞帧process是异步的所以用isProcessing做闸门上一帧没处理完就丢帧保证管线不被堵死。4. 进阶场景姿态估计、分割与自定义模型4.1 姿态检测的配置组合姿态估计是健身、运动、互动游戏类App的核心能力。ML Kit提供两套模型基础姿态检测和高精度姿态检测。前者模型小、速度快适合流畅跟手后者关键点定位更准但体积和耗电都上去了。两者都分单帧模式与流式模式流式模式专为连续视频帧设计会保留时序信息让关键点更稳定。val options PoseDetectorOptions.Builder() .setDetectorMode(PoseDetectorOptions.STREAM_MODE) .build() val poseDetector PoseDetection.getClient(options)拿到结果后每个关键点都有坐标和置信度。我在实际项目里的经验是业务逻辑判断动作是否标准时必须加置信度阈值。比如“手肘抬起来”这个判定不能只看关键点坐标移动还要看该点的置信度是否超过0.5否则在遮挡、半身出画的情况下会疯了一样误触发。这套能力对摄像头角度要求很高。用户正面朝手机是最好识别的侧面识别率会快速下降。产品设计上要主动引导用户“请站在一米外、正对镜头”能在很大程度上缓解算法压力。4.2 性能策略别让AI线程饿死UI实时姿态分析的性能敏感度比扫码高一个量级。我一直强调三个策略降分辨率、降帧率、抽帧分析。降分辨率指的是ImageAnalysis的targetResolution别设满1280x720足够。降帧率是让分析器输出的帧率不要跟着预览跑24fps和12fps在姿态场景里体感差异不大但功耗差很多。抽帧是在业务层做闸门比如每隔两帧处理一帧。综合这几个手段发热问题能压下来一大半。再补充一个底层策略ML Kit的推理默认走CPU当设备支持时可以开启加速让模型尝试用GPU或NNAPI执行。开启方式是在选项里调用enableAcceleration。但注意加速不是一定成功的某些设备、某些算子会失败运行时会抛异常。标准做法是捕获异常后回退到CPU并把失败机型记录下来作为后续机型适配的依据。4.3 自拍分割与手写识别分割类API里自拍分割实现背景替换非常快。输入一个人像图输出是一张alpha图或者人像区域蒙版。用来做“头像背景虚化”“视频会议换背景”“照片抠图保存”都很顺手。实际体验中它对人像半身照效果最好全身照、多人照要改用适用范围更广的主体分割。手写识别适合做笔记类、签名类App。它要求把采集到的笔画轨迹按格式传给API而不是传一张图片。这点容易混淆。如果你要做的是“拍一张手写笔记照片转文字”应该走中文OCR如果你做的是“手写板输入”才用Digital Ink。两条路完全不同别选错。5. 性能优化与模型交付策略5.1 Bundled与Unbundled的取舍这是上线前必须拿定主意的一个选型。我做个直接对比。维度动态下载unbundled随包内置bundledAPK体积几乎无增加每个模型增加几MB到十几MB首次可用需下载网络好时数秒安装即可用离线完全可用模型下载后可用始终可用外部服务依赖依赖设备预置对应服务无依赖模型更新可独立下发新模型只能发版更新不适合场景服务缺失的设备对包体积极度敏感的小工具我的建议是看产品形态。工具型App、安装包必须小、用户装上就要能用走bundled大型App、有更新通道和网络预判能力走动态下载把体积成本摊到运行时。更重要的是别混用两种模式我见过一个项目既在build里写动态依赖又在代码里判断本地模型结果逻辑和体积都失控了。5.2 动态模型下载的条件与容错动态下载如果不好好做用户提示和重试会让首启体验非常拉胯。下载前要判断网络一般建议只在WiFi下自动下大模型流量环境下要先弹窗征得用户同意。ML Kit支持设置下载条件比如要求WiFi、要求设备非低电量我用过的示例如下val conditions CustomModelDownloadConditions.Builder() .requireWifi() .build()下载状态要能被业务感知比如下载中给用户一个进度提示下载失败给重试入口千万别让用户干等在一个转圈页面上。下载完的模型会缓存在系统内部应用卸载时一起清掉这个不用我们管但要注意清理不及时也可能占空间设置页最好能展示“模型清理”入口。5.3 内存、帧率与发热的第一现场性能问题不能靠看文档解决得靠实测。我碰到过最典型的问题是OOM模型加载、图片Bitmap、相机帧三块内存同时存在峰值马上爆。解法是控制每一步的尖峰。Bitmap做采样缩放不要全尺寸解码相机分析用ImageProxy的裁剪接口而不是先转Bitmap推理结果及时释放不要持有整张图的引用做集合缓存。发热问题在持续使用场景尤其明显。实测长时间开姿态识别背部温度会明显升高。微信那种扫码是“不常驻”的压力不大但健身App不同用户对着摄像头练半小时发热和降频会直接影响推理速度。线上一定要做“延时关闭”策略用户停止动作五秒后自动关掉分析器而不是让它一直空转。另一个潜在线索是电量。端上推理是连续耗电行为我建议把单帧耗时、连续运行时长、设备温度这几个指标作为关键埋点。埋点只上报数值和统计信息不要上报画面和原图这是隐私底线。6. 常见问题与排查实录6.1 症状对照速查表下面这些是我在多个项目里反复见到的组合按“症状-原因-解法”整理成速查表。症状常见原因处理办法模拟器上识别一直失败或模型不下载模拟器镜像缺少所需服务组件换用带完整服务的真机测试模拟器只做快速UI验证中文识别率极低、出现乱码错用拉丁文识别器改用中文独立识别器检查依赖是否对应从相册选图识别方向反转EXIF方向信息丢失或rotation没传对用InputImage带方向参数的构造方式或读取EXIF手动纠正冷启动后内存飙升、偶发OOM大图解码模型同时加载采样缩放Bitmap分时加载模型控制相机分辨率回调里更新UI卡顿、掉帧process回调在主线程做重活回调里只做轻量UI操作耗时逻辑丢线程池老设备上推理闪退强制开启加速但硬件不支持捕获加速异常回退CPU记录失败机型首次进页面等待太久动态下载模型没有前置触发在合适的时机预下载模型比如开屏后后台悄悄拉取6.2 三个真实项目里的排查经过第一个是某个工具类App接二维码支付。用户反馈“扫得很慢”一开始以为是算法问题后来定位到是相机预览分辨率设成了2K每帧都在做大图预处理。把分析分辨率降到720p并在取景框内裁剪后识别速度肉眼可见地提上去了。这类问题不看数据很难找到项目里埋了“从相机帧到返回结果的毫秒耗时”才定位到。第二个是中文OCR识别率不高。我们最初用的是拉丁模型以为“都能认字”被用户骂了几轮。换成ChineseRecognizer后又发现低亮度环境识别率下降于是加了拍照前亮度检测低于阈值时提示用户开灯。产品功能直接从一个“总是认错”变成了“偶尔要开灯”。第三个是姿态识别App在低端机上发热严重。我们把帧率从全速降到每三帧分析一次、模型切到快速版、并把画中画预览降为低分辨率发热问题基本解决了动作计数的偏差在可接受范围内。这印证了一个判断很多时候用户感知的“卡”不是推理慢而是整机发热降频导致所有东西都慢。端上AI的性能优化目标不是让推理最快而是让整个App体验最稳。6.3 排查工具与手段排查端上AI问题不能只靠肉眼看log。我的建议是准备一份“性能基线”清单单次推理耗时、模型加载耗时、峰值内存、连续运行半小时后的温度变化这四项在选型阶段就固定下来。每次更换机型、升级依赖、替换模型后都跑一遍基线做对比。看似笨办法实际上能拦住大部分线上问题。7. 上线前要盯住的几件事7.1 隐私与合规不能拖到最后设备端AI在隐私上优势明显但合规工作依然要做。隐私政策里应当写清楚哪些AI能力在设备端完成、不会上传原始内容哪些能力可能触发模型下载下载行为也会产生网络流量。如果功能涉及相机画面还需要在App内的权限弹窗里说明用途并给用户关闭AI功能的入口。别小看这些文案审核阶段被卡住比写代码痛苦得多。7.2 模型更新与功能灰度设备端模型更新是产品迭代里容易被忽略的环节。模型不是上线之后就一劳永逸的字体变化、扫码场景变化、新机型拍照风格不同都可能让旧模型效果下降。动态下载模型能为灰度更新提供条件先小范围下发新模型对比识别准确率再全量推。自定义模型场景更要建立版本号机制模型和业务代码版本要能对应上。7.3 机型适配矩阵端上AI最大的不确定性是用户手里的设备差异。GPU支持程度、系统版本、可用内存都不一样。建议在选型阶段就确定一个覆盖高中低端的真机测试矩阵至少包含一个老款低端机、一个中端主力机、一个最新旗舰。不要只在新机子上测因为低端机上CPU推理耗时和内存占用都可能翻好几倍。7.4 可观测性和降级方案最后一定做好可观测性和降级。埋点覆盖功能入口点击、模型加载耗时、首次推理耗时、识别成功率、失败原因。当AI功能异常时要有一个降级开关。扫码失败可以让用户手动输入码号OCR失败可以提示拍照反馈客服姿态识别失败可以退回视频教学。用户要的是“功能可用”而不是“技术完美”。最后分享一点个人体会。刚接触ML Kit的人很容易陷入一个误区反复对比它和更底层框架的能力差距或者在模型精度上过度焦虑。我现在的做法恰恰相反——先用ML Kit把最小闭环跑起来老实验证在真实手机上的发热、耗电、识别率如果某个环节真的成为瓶颈再针对性地用自定义模型或更底层方案替换。设备端AI项目里最大的成本从来不是模型精度而是工程化摄像头角度、光线变化、机型差异、低端机的性能预算这些才是真正的战场。把ML Kit这套流程跑顺了后续不管换什么技术底座你积累的排查思路和性能指标都是通用的。 ML Kit 设备端AI实践：从扫码、OCR到姿态估计的移动端落地指南
做移动端开发这些年我有个很直观的感受AI能力正在从“高不可攀的云服务”变成“手机里的常驻小功能”。扫个码、拍个名片、翻译一段文字、对着摄像头实时识别健身动作用户早就默认这些都是即拿即用的东西。而这些功能背后的技术底座很大一部分就是设备端AI——不上传数据、不依赖网络、直接在手机本地完成推理。ML Kit就是Google官方为这件事准备的机器学习套件。它不要求你从零训练模型也不要求你精通深度学习原理Android和iOS都能接入把几十种常见的视觉、文本识别能力封装成了几个可以直接调的API。这篇文章我会按照自己实际项目的落地顺序来讲先聊清楚为什么端上AI是趋势、ML Kit在整个技术栈里的位置再给你一张完整的能力选型地图然后从零跑通“扫码中文文字识别”的最小Demo进阶到姿态估计和分割最后把性能优化、模型交付和线上排查这些“只有踩过坑才知道”的东西全部摊开。适合正在做App功能选型的技术负责人、想给产品加AI能力但没太多模型经验的客户端开发以及准备把部分云推理迁移到本地的团队。我尽量把每一步的为什么也讲清楚而不是只丢代码。1. 为什么设备端AI是趋势ML Kit卡在什么位置1.1 四个让端上AI“不得不做”的驱动力先说结论设备端AI不是某个公司拍脑袋推的方向而是被四个非常现实的问题推着走的。第一个是隐私。很多数据天生就不该出设备。比如身份证OCR、聊天内容的情感分析、健康类App里的身体数据用户对“上传到服务器”这件事越来越敏感监管合规的要求也越来越清晰。把这些能力放到本地做意味着原始数据根本不会离开手机产品在隐私说明里可以底气十足地写“本功能完全在设备端处理”。光这一条就足以让不少团队从云端方案切回本地。第二个是实时性。网络请求一次往返至少几十毫秒加上云端排队和推理时间动辄两三百毫秒而端上推理通常可以做到十几到几十毫秒。做摄像头连续帧分析的场景比如实时姿态纠正、手势识别、AR贴纸延迟稍微一高画面就会“拖影”用户立刻觉得卡。这种场景只有端上能扛。第三个是离线可用。停车场扫码、地铁闸机、海外旅行打开翻译网络都不是可靠前提。把模型放到本地用户可以完全在无网环境下完成核心操作。这个体验一旦用户习惯了就回不去了。第四个是成本。很多人容易忽略云端推理是按调用量计费的。视频流分析每秒24帧、每帧都调云端API一个月下来账单会很吓人。而端上推理用的是用户手机的算力边际成本几乎为零。对大用户量产品来说这可能是最现实的决定性因素。1.2 ML Kit的定位它是工具箱不是炼丹炉ML Kit很容易被误解成“又一个AI框架”所以先说清楚它的位置。它其实做了三层事情第一层预训练好的模型比如文字识别模型、条码模型、姿态模型第二层推理运行时也就是怎么在手机上高效地跑模型第三层任务化的API封装把“输入图片-预处理-推理-返回结构化结果”这一整套流程打包成几个方法调用。你不需要关心模型输入要多大、输出怎么解析直接拿结果就行。如果你了解底层生态可以这样理解它和周边工具的区别。TensorFlow Lite是真正的推理引擎好比给你一套基础厨具和原材料ML Kit是直接封装好的菜包拆开加热就能上桌而MediaPipe是更灵活的流水线框架相当于给你整套锅碗瓢盆和菜谱你可以自由组合和定制。ML Kit适合“我要快速做出一个能用的功能”MediaPipe适合“我有定制管线需求、愿意自己调”直接上TFLite则适合“我对自己训练模型有执念”。三者不是替代关系是可以配合使用的。在iOS端苹果也有对应的Core ML和Vision框架。思路是一样的系统级能力、本地推理、离线优先。跨平台团队最合理的做法是业务层抽象一套统一接口Android侧用ML KitiOS侧用系统框架上层只感知结果。2. ML Kit能力全景与选型地图2.1 视觉类API一张表看清你的需求落在哪个接口ML Kit的视觉能力是重头戏。我按实际使用频率给你过一遍并标注一些只有用起来才会发现的细节。API做什么典型场景备注Barcode Scanning识别一维码/二维码扫码登录、商品条码、电子票券支持QR、Code128、EAN等多种格式可指定格式减小开销Text RecognitionOCR文字识别名片扫描、票据识别、拍照搜题分拉丁、中文、日文、韩文等独立模型不能混用Face Detection人脸检测与特征分类美颜预处理、人脸计数、微笑/睁眼检测偏“检测”不是人脸识别比对Pose Detection人体姿态关键点健身计数、瑜伽比对、动作捕捉有快速与高精度两套模型支持单帧与流式Object Detection物体检测与跟踪货架商品识别、车辆识别返回目标框与类别也能只做框不做分类Selfie Segmentation人像抠图背景替换、抠像、虚化对半身自拍效果好速度快Subject Segmentation更细粒度主体分割商品抠图、多人分区比自拍分割适用范围更广模型更大Image Labeling通用图片分类图片自动标签、内容过滤只能给最可能的几个类别不是精确识别Digital Ink手写笔迹识别手写输入、电子签名需要配套的模型配置中文支持逐步完善我建议的选型逻辑是先想清楚“用户输入是什么、输出要什么”。扫码和OCR是最高频、最稳定的人脸和姿态适合需要实时反馈的交互场景分割适合做视觉美化图片标签适合做粗筛不能当精确分类用。因为ML Kit的模型是“一个API一个模型”体积和资源消耗各不相同别为了省事把所有能力都初始化一遍按功能按需加载。2.2 自然语言类API本地完成了你想象不到的活视觉之外文本方向也有一整套能力用起来比想象中更省心。翻译支持几十种语言关键是有离线语言包。用户下载对应语言包后飞行模式下也能翻译这在国际旅行、跨语言客服场景非常实用。智能回复Smart Reply则会在本地分析收到的会话内容给出简短候补回复。注意它不会把内容传出去这一点在聊天类App里价值极大。语言识别用来判断一段文本是什么语言适合做输入法、内容路由的预处理。实体抽取能本地识别出邮件地址、电话、地址这类结构信息做卡片式提取很方便。还有一个做文本分类的能力带个情绪倾向模型可以本地判断评论正负面。这些能力整体上比视觉利落因为文本输入体积小、推理快资源占用也低。哪怕是中低端机跑这些也基本无感。2.3 自定义模型把你自己训练的东西塞进ML KitML Kit默认能力覆盖了大众需求但总有些场景是预训练模型照顾不到的。比如你要识别特定品牌的logo、工业零件缺陷、某一类新闻稿风格。这时候可以用自定义模型你把训练好的TFLite模型带进来由ML Kit负责加载和调度你自己管理预处理和结果解析。自定义模型有两种交付方式。一种是打进App里安装即有、离线可用但更新模型只能发新版本另一种是放在云端模型托管服务启动时动态下发模型更新不用等审核和用户升级代价是要处理下载失败、版本兼容。我的经验是模型不大、几乎不变直接打进包模型会迭代、或者不同用户需要不同模型一定走动态下发。2.4 模型托管方式bundled还是unbundled提到模型交付ML Kit里有一个很重要的隐藏选项。默认情况下部分API依赖Google Play services动态下发模型体积小、更新快但前提是设备有配套服务另一种方式是选择bundled版本依赖模型直接随App安装没有外部依赖但APK体积会明显增大。这两种方式不是随便选的它直接决定你的用户在哪些设备上能打开功能、首次打开是秒级可用还是等下载。后面的性能优化章节我会专门展开对比这里先记住这个坑不提前规划上线后一定会被“机型兼容问题”和“首次等待超时问题”来回折磨。3. 从零接入扫码与中文文本识别的最小Demo3.1 环境与依赖配置先说环境。ML Kit要求模块的minSdk在21以上项目本身用AndroidXAndroid Studio版本别太老。以扫码和中文OCR为例在模块的build.gradle.kts里添加依赖dependencies { // 请以官方Release页面为准这里只是示意版本 implementation(com.google.mlkit:barcode-scanning:17.3.0) implementation(com.google.mlkit:text-recognition-chinese:16.0.1) }如果要使用动态下载模式依赖配置不变首次调用时会自动触发模型下载。需要在AndroidManifest里申请相机权限如果功能涉及保存图片还需要对应的存储权限。权限就按最小必要来只声明相机。3.2 创建扫码器并解析结果扫码是所有能力里我推荐先接入的因为它链路短、反馈强最适合练手。创建扫码器时可以限定条码类型减少不必要的算力浪费val options BarcodeScannerOptions.Builder() .setBarcodeFormats(Barcode.FORMAT_QR_CODE, Barcode.FORMAT_CODE_128) .build() val scanner BarcodeScanning.getClient(options)然后准备InputImage。最常用的方式是从Bitmap创建注意按需缩放别把原图直接扔进去val image InputImage.fromBitmap(scaledBitmap, 0) scanner.process(image) .addOnSuccessListener { barcodes - for (barcode in barcodes) { val value barcode.rawValue ?: continue when (barcode.valueType) { Barcode.TYPE_URL - // 打开链接 Barcode.TYPE_TEXT - // 展示文本 Barcode.TYPE_WIFI - // 配置格式为WIFI:...可引导连接 else - // 其它类型 } } } .addOnFailureListener { e - // 打点 提示用户重试 }有几个细节值得说。第一扫描分辨率不是越大越好大图会让预处理耗时明显上升建议把最长的边控制在1300像素左右。第二二维码在画面中占比很小的话识别率会下降可以在进入相机的页面上画一个取景框引导用户把码放到框内同时只对框内区域做裁剪识别效果比整帧扫描好得多。第三process是异步的回调默认在主线程不要在回调里做重活解析逻辑复杂就丢到后台线程。3.3 中文文本识别别用错识别器文本识别是我踩坑最多的一个点最大的坑就是“用错模型”。ML Kit把文字识别拆成了好几个独立模型拉丁文模型不认中文字符。很多人在老设备上跑通一个Demo后直接上生产结果中文识别率惨不忍睹问题往往出在这。正确做法是明确使用中文识别器val recognizer TextRecognition.getClient( ChineseTextRecognizerOptions.Builder().build() )识别结果的结构是一棵三层树Text下面有TextBlockTextBlock下面有LineLine是最小识别单元包含Element和boundingBox。实际开发里最常用的是遍历Line拿坐标和文本用来在图片上画框、做点击选中或者拼出整段文字recognizer.process(image) .addOnSuccessListener { result - result.textBlocks.forEach { block - block.lines.forEach { line - val text line.text val box line.boundingBox // 这里可以画框、记录坐标 } } }中文OCR对输入质量更敏感。最大边小于600像素的小图基本识别不了什么昏暗、偏斜、大字号艺术字都会明显降低准确率。预处理阶段加一个“按最长边缩放到1200像素左右灰度化”的步骤对识别率提升很直接。3.4 与CameraX集成从ImageProxy拿正确方向扫码和OCR真正稳定工作的场景是接相机实时分析。CameraX是Android官方推荐的相机库配合ImageAnalysis用起来很顺手。关键点在于怎么从ImageProxy构造InputImage并且把旋转角传对class MLKitAnalyzer( private val scanner: BarcodeScanner ) : ImageAnalysis.Analyzer { Volatile private var isProcessing false override fun analyze(imageProxy: ImageProxy) { if (isProcessing) { imageProxy.close() return } isProcessing true val mediaImage imageProxy.image val rotation imageProxy.imageInfo.rotationDegrees if (mediaImage ! null) { val inputImage InputImage.fromMediaImage(mediaImage, rotation) scanner.process(inputImage) .addOnSuccessListener { barcodes - // 更新UI、播放提示音 } .addOnCompleteListener { isProcessing false imageProxy.close() } } else { imageProxy.close() isProcessing false } } }这段代码里最容易被忽略的是rotation。相机拿到的原始帧是传感器方向如果不把rotationDegrees传给ML Kit识别结果要么反着、要么永远失败。还要注意analyze方法里不能一直塞帧process是异步的所以用isProcessing做闸门上一帧没处理完就丢帧保证管线不被堵死。4. 进阶场景姿态估计、分割与自定义模型4.1 姿态检测的配置组合姿态估计是健身、运动、互动游戏类App的核心能力。ML Kit提供两套模型基础姿态检测和高精度姿态检测。前者模型小、速度快适合流畅跟手后者关键点定位更准但体积和耗电都上去了。两者都分单帧模式与流式模式流式模式专为连续视频帧设计会保留时序信息让关键点更稳定。val options PoseDetectorOptions.Builder() .setDetectorMode(PoseDetectorOptions.STREAM_MODE) .build() val poseDetector PoseDetection.getClient(options)拿到结果后每个关键点都有坐标和置信度。我在实际项目里的经验是业务逻辑判断动作是否标准时必须加置信度阈值。比如“手肘抬起来”这个判定不能只看关键点坐标移动还要看该点的置信度是否超过0.5否则在遮挡、半身出画的情况下会疯了一样误触发。这套能力对摄像头角度要求很高。用户正面朝手机是最好识别的侧面识别率会快速下降。产品设计上要主动引导用户“请站在一米外、正对镜头”能在很大程度上缓解算法压力。4.2 性能策略别让AI线程饿死UI实时姿态分析的性能敏感度比扫码高一个量级。我一直强调三个策略降分辨率、降帧率、抽帧分析。降分辨率指的是ImageAnalysis的targetResolution别设满1280x720足够。降帧率是让分析器输出的帧率不要跟着预览跑24fps和12fps在姿态场景里体感差异不大但功耗差很多。抽帧是在业务层做闸门比如每隔两帧处理一帧。综合这几个手段发热问题能压下来一大半。再补充一个底层策略ML Kit的推理默认走CPU当设备支持时可以开启加速让模型尝试用GPU或NNAPI执行。开启方式是在选项里调用enableAcceleration。但注意加速不是一定成功的某些设备、某些算子会失败运行时会抛异常。标准做法是捕获异常后回退到CPU并把失败机型记录下来作为后续机型适配的依据。4.3 自拍分割与手写识别分割类API里自拍分割实现背景替换非常快。输入一个人像图输出是一张alpha图或者人像区域蒙版。用来做“头像背景虚化”“视频会议换背景”“照片抠图保存”都很顺手。实际体验中它对人像半身照效果最好全身照、多人照要改用适用范围更广的主体分割。手写识别适合做笔记类、签名类App。它要求把采集到的笔画轨迹按格式传给API而不是传一张图片。这点容易混淆。如果你要做的是“拍一张手写笔记照片转文字”应该走中文OCR如果你做的是“手写板输入”才用Digital Ink。两条路完全不同别选错。5. 性能优化与模型交付策略5.1 Bundled与Unbundled的取舍这是上线前必须拿定主意的一个选型。我做个直接对比。维度动态下载unbundled随包内置bundledAPK体积几乎无增加每个模型增加几MB到十几MB首次可用需下载网络好时数秒安装即可用离线完全可用模型下载后可用始终可用外部服务依赖依赖设备预置对应服务无依赖模型更新可独立下发新模型只能发版更新不适合场景服务缺失的设备对包体积极度敏感的小工具我的建议是看产品形态。工具型App、安装包必须小、用户装上就要能用走bundled大型App、有更新通道和网络预判能力走动态下载把体积成本摊到运行时。更重要的是别混用两种模式我见过一个项目既在build里写动态依赖又在代码里判断本地模型结果逻辑和体积都失控了。5.2 动态模型下载的条件与容错动态下载如果不好好做用户提示和重试会让首启体验非常拉胯。下载前要判断网络一般建议只在WiFi下自动下大模型流量环境下要先弹窗征得用户同意。ML Kit支持设置下载条件比如要求WiFi、要求设备非低电量我用过的示例如下val conditions CustomModelDownloadConditions.Builder() .requireWifi() .build()下载状态要能被业务感知比如下载中给用户一个进度提示下载失败给重试入口千万别让用户干等在一个转圈页面上。下载完的模型会缓存在系统内部应用卸载时一起清掉这个不用我们管但要注意清理不及时也可能占空间设置页最好能展示“模型清理”入口。5.3 内存、帧率与发热的第一现场性能问题不能靠看文档解决得靠实测。我碰到过最典型的问题是OOM模型加载、图片Bitmap、相机帧三块内存同时存在峰值马上爆。解法是控制每一步的尖峰。Bitmap做采样缩放不要全尺寸解码相机分析用ImageProxy的裁剪接口而不是先转Bitmap推理结果及时释放不要持有整张图的引用做集合缓存。发热问题在持续使用场景尤其明显。实测长时间开姿态识别背部温度会明显升高。微信那种扫码是“不常驻”的压力不大但健身App不同用户对着摄像头练半小时发热和降频会直接影响推理速度。线上一定要做“延时关闭”策略用户停止动作五秒后自动关掉分析器而不是让它一直空转。另一个潜在线索是电量。端上推理是连续耗电行为我建议把单帧耗时、连续运行时长、设备温度这几个指标作为关键埋点。埋点只上报数值和统计信息不要上报画面和原图这是隐私底线。6. 常见问题与排查实录6.1 症状对照速查表下面这些是我在多个项目里反复见到的组合按“症状-原因-解法”整理成速查表。症状常见原因处理办法模拟器上识别一直失败或模型不下载模拟器镜像缺少所需服务组件换用带完整服务的真机测试模拟器只做快速UI验证中文识别率极低、出现乱码错用拉丁文识别器改用中文独立识别器检查依赖是否对应从相册选图识别方向反转EXIF方向信息丢失或rotation没传对用InputImage带方向参数的构造方式或读取EXIF手动纠正冷启动后内存飙升、偶发OOM大图解码模型同时加载采样缩放Bitmap分时加载模型控制相机分辨率回调里更新UI卡顿、掉帧process回调在主线程做重活回调里只做轻量UI操作耗时逻辑丢线程池老设备上推理闪退强制开启加速但硬件不支持捕获加速异常回退CPU记录失败机型首次进页面等待太久动态下载模型没有前置触发在合适的时机预下载模型比如开屏后后台悄悄拉取6.2 三个真实项目里的排查经过第一个是某个工具类App接二维码支付。用户反馈“扫得很慢”一开始以为是算法问题后来定位到是相机预览分辨率设成了2K每帧都在做大图预处理。把分析分辨率降到720p并在取景框内裁剪后识别速度肉眼可见地提上去了。这类问题不看数据很难找到项目里埋了“从相机帧到返回结果的毫秒耗时”才定位到。第二个是中文OCR识别率不高。我们最初用的是拉丁模型以为“都能认字”被用户骂了几轮。换成ChineseRecognizer后又发现低亮度环境识别率下降于是加了拍照前亮度检测低于阈值时提示用户开灯。产品功能直接从一个“总是认错”变成了“偶尔要开灯”。第三个是姿态识别App在低端机上发热严重。我们把帧率从全速降到每三帧分析一次、模型切到快速版、并把画中画预览降为低分辨率发热问题基本解决了动作计数的偏差在可接受范围内。这印证了一个判断很多时候用户感知的“卡”不是推理慢而是整机发热降频导致所有东西都慢。端上AI的性能优化目标不是让推理最快而是让整个App体验最稳。6.3 排查工具与手段排查端上AI问题不能只靠肉眼看log。我的建议是准备一份“性能基线”清单单次推理耗时、模型加载耗时、峰值内存、连续运行半小时后的温度变化这四项在选型阶段就固定下来。每次更换机型、升级依赖、替换模型后都跑一遍基线做对比。看似笨办法实际上能拦住大部分线上问题。7. 上线前要盯住的几件事7.1 隐私与合规不能拖到最后设备端AI在隐私上优势明显但合规工作依然要做。隐私政策里应当写清楚哪些AI能力在设备端完成、不会上传原始内容哪些能力可能触发模型下载下载行为也会产生网络流量。如果功能涉及相机画面还需要在App内的权限弹窗里说明用途并给用户关闭AI功能的入口。别小看这些文案审核阶段被卡住比写代码痛苦得多。7.2 模型更新与功能灰度设备端模型更新是产品迭代里容易被忽略的环节。模型不是上线之后就一劳永逸的字体变化、扫码场景变化、新机型拍照风格不同都可能让旧模型效果下降。动态下载模型能为灰度更新提供条件先小范围下发新模型对比识别准确率再全量推。自定义模型场景更要建立版本号机制模型和业务代码版本要能对应上。7.3 机型适配矩阵端上AI最大的不确定性是用户手里的设备差异。GPU支持程度、系统版本、可用内存都不一样。建议在选型阶段就确定一个覆盖高中低端的真机测试矩阵至少包含一个老款低端机、一个中端主力机、一个最新旗舰。不要只在新机子上测因为低端机上CPU推理耗时和内存占用都可能翻好几倍。7.4 可观测性和降级方案最后一定做好可观测性和降级。埋点覆盖功能入口点击、模型加载耗时、首次推理耗时、识别成功率、失败原因。当AI功能异常时要有一个降级开关。扫码失败可以让用户手动输入码号OCR失败可以提示拍照反馈客服姿态识别失败可以退回视频教学。用户要的是“功能可用”而不是“技术完美”。最后分享一点个人体会。刚接触ML Kit的人很容易陷入一个误区反复对比它和更底层框架的能力差距或者在模型精度上过度焦虑。我现在的做法恰恰相反——先用ML Kit把最小闭环跑起来老实验证在真实手机上的发热、耗电、识别率如果某个环节真的成为瓶颈再针对性地用自定义模型或更底层方案替换。设备端AI项目里最大的成本从来不是模型精度而是工程化摄像头角度、光线变化、机型差异、低端机的性能预算这些才是真正的战场。把ML Kit这套流程跑顺了后续不管换什么技术底座你积累的排查思路和性能指标都是通用的。