写到第18章也是时候认真聊一聊设备端AI了。很多移动端开发走到一定阶段都会冒出同一个诉求想让应用“看懂”点东西——扫个码、拍下名片自动提取文字、检测相机画面里的人脸、甚至把路牌上的英文实时翻译成中文。这些能力以前要么自己去训练模型要么接云端接口。可云端接口的硬伤很明显必须联网、要把用户数据传上去、还得等网络往返。于是ML Kit这类设备端AI方案就成了一个相当务实的答案。这一章的定位是给已经写过一段时间应用的开发者准备的。它不要求你懂机器学习原理只需要有Android开发基础了解基本的相机调用和UI搭建。我会把ML Kit是什么、它和TensorFlow Lite、MediaPipe这些名词到底是什么关系、以及如何在真实项目里接入文字识别、扫码、人脸检测和翻译这几类最常见能力讲清楚。网上关于这个主题的文章很多但大量内容停留在旧版接口和已经被调整过的API上照着写会踩不少坑。这一章我顺手把这些坑一起填了。1. 先搞清楚设备端AI到底解决了什么问题1.1 从云端挪到端侧不是追潮流是被需求逼的先说一个最直观的例子相机应用要做人脸检测。如果每次从预览流里抽一帧把图片传到服务器等结果回来再画框这个延迟足以让App彻底没法用。那已经是传输链路和服务器推理各几百毫秒起步的现实问题了。更何况用户不一定有网地铁上、电梯里、海外漫游时所有依赖云端的能力一瞬间全部瘫痪。真正逼着开发团队转向设备端的是三个很实在的痛点。第一个是隐私。用户的脸、身份证照片、银行卡号这些数据往服务器一传不管合同怎么写用户心里的信任成本就上来了。第二个是延迟。设备端推理通常只需要几十毫秒到几百毫秒对实时交互场景来讲这是唯一可行的路线。第三个是成本。云端接口按调用量计费用户量一大每个月的账单很吓人而设备端推理只是消耗一点芯片算力和手机电量边际成本几乎为零。还有一个背景也得提一下这几年手机芯片里的NPU、DSP等专用算力单元进步非常快。早年间在低端机上跑一个小模型要一两秒现在中端芯片跑一个分类模型也就几十毫秒。硬件把路铺好了端侧AI才能在普通应用里真正落地而不是停留在论文演示阶段。设备端AI不是要取代云端而是把适合在本地做的任务留在本地这个边界现在越来越清楚了。1.2 ML Kit在整张端上AI地图里的位置ML Kit本质上是一套预封装的开箱即用设备端AI接口你可以把它理解成“面向移动端开发者的AI工具箱”。它覆盖两大类能力一类是通用视觉和文本能力比如文字识别、条码扫描、人脸检测、图像标注、翻译、语言识别、智能回复另一类是让你托管自己的TensorFlow Lite模型通过远程模型管理方案按需下发到用户设备。这里有个很容易混淆的点得理清楚。ML Kit底层跑的是TensorFlow Lite也就是Google的轻量级推理引擎但正常做业务开发时你完全不需要直接碰TFLite的推理代码那些细节都被封装好了。而MediaPipe则是一套更底层的端侧机器学习流水线框架早期ML Kit里一部分能力后来调整到了MediaPipe的Tasks API下维护。这件事特别坑人因为很多老教程会教你怎么用ML Kit做人脸网格、姿态估计、自拍分割和物体跟踪而如果你现在去官方文档找这几个接口会发现它们已经不在ML Kit的主包里了。后面我会专门用一个章节来提醒迁移方案。使用方式上还有个历史变化早期ML Kit分“内置版”和“动态版”两种接入方式动态版把模型放在系统框架服务里随能力更新。后来这套体系做了调整现在更常见的是在首次使用时按需下载模型。比如翻译能力的语言包就是第一次调用时下载到本地的下载完成之后离线也能跑。这种设计明显更适合控制安装包体积。一个文字识别模型几十MB如果强制打包进APK很多用户光看到下载体积就不想装了。2. 能力全景ML Kit带哪些开箱即用的AI功能2.1 识别类文字识别与条码扫描文字识别是ML Kit里最常用的能力之一也最能直观体现“设备端AI成熟度”。它的接口叫TextRecognition可以对静态图片和相机流里的文字做检测和结构化提取。输出结果是有层级结构的整张图里的文字块(TextBlock)、块里的每一行(Line)、行里的每个元素(Element)再往下还有符号级(Symbol)信息。做名片扫描、证件信息提取、车牌识别这类需求时这个结构能帮你直接把文本按行拼接成可用数据而不是拿到一坨字符串再自己硬切。需要注意一个细节文字识别模型是分语种的。默认的DEFAULT_OPTIONS模型主要覆盖拉丁语系识别中文时需要单独依赖一个中英文模型文件这个我在第3章的依赖配置里会具体演示。如果你用默认模型去识别中文识别率会低到怀疑人生。条码扫描的接口是BarcodeScanning它支持二维码和一维码包括QR Code、EAN-13、UPC-A、Code 128这些常见格式。和以前很多扫码库要求把条码对准屏幕正中央的取景框不同ML Kit是整帧画面检测条码出现在画面里任何一个位置都能扫到这也是很多扫码项目迁移过来的直接原因。在做选取格式时我强烈建议按需配置。比如只做二维码收银就只注册QR格式既能降低模型加载体积也能避免识别到商品码导致误判。2.2 理解类人脸检测、图像标注与物体相关能力人脸检测接口FaceDetection提供的不是“人脸在哪”这一个框而是一整套信息左右眼、鼻子、嘴等关键点坐标、头的姿态角、眼睛睁开与否、微笑概率等分类信息。这些数据做相机自动对焦、前置镜头自动抓拍、疲劳检测、简单美颜贴纸都很顺手。它本身绑定的模型很小运行帧率可观在低端机上做实时检测也能扛住。图像标注ImageLabeling则是给整张图片打标签比如“户外”“汽车”“美食”“动物”。适合做相册自动分类、UGC内容的辅助审核。物体检测与跟踪、姿态估计、自拍分割这几项现在主要迁移到了MediaPipe Tasks去维护。姿态估计常用于健身App的动作计数和姿势纠正自拍分割用于背景替换物体跟踪用于视频里持续锁定某个目标。如果你正好要做这些功能别再按老教程绕回ML Kit了直接去MediaPipe那边找对应Task会少踩很多坑。2.3 语言智能翻译、语言识别与智能回复翻译接口Translation支持几十种语言互译和传统云翻译SDK最大的区别是目标语言模型可以整体下载到手机里。用户在设置页触发一次下载之后无论在地铁还是飞机上翻译照常可用。它给开发者带来的额外价值是隐私边界清晰——用户输入的文本没有离开设备在面向企业客户、医疗场景时会成为重要的卖点。语言识别LanguageIdentification用于判断一段文本属于哪种语言常见的使用场景是输入法自动切换键盘、客服工单自动打标。智能回复Smart Reply则更适合聊天类应用它根据对话上下文自动生成几条候选回复点一下就发送整套逻辑都在本地跑。早期这个能力对系统框架服务有依赖现在也是按需下载模型的方式。做IM、邮件、客服工具时智能回复是个能明显拉升用户体验的功能投入产出比很高。2.4 一张表看明白能力选型能力入口API典型使用场景当前状态文字识别TextRecognition单据扫描、名片提取、车牌识别活跃维护条码扫描BarcodeScanning二维码支付、商品码扫描活跃维护人脸检测FaceDetection相机对焦、自动抓拍、疲劳检测活跃维护图像标注ImageLabeling相册分类、内容审核辅助活跃维护语言识别LanguageIdentification输入法自适应、工单分类活跃维护翻译Translation离线翻译、聊天辅助活跃维护智能回复Smart ReplyIM快捷回复、客服助手活跃维护自定义模型自带TFLite模型远程下发行业专属识别、私有模型推理活跃维护人脸网格已调整至MediaPipe TasksAR贴纸、面具效果已迁移姿态估计已调整至MediaPipe Tasks健身计数、动作纠正已迁移自拍分割已调整至MediaPipe Tasks背景替换、分身效果已迁移物体检测与跟踪已调整至MediaPipe Tasks视频目标框选跟踪已迁移3. 实战把实时文字识别装进Android应用3.1 环境准备与依赖引入集成ML Kit的第一步是加依赖。以Android为例在项目的build.gradle里加上dependencies { // 中英文文字识别 implementation(com.google.mlkit:text-recognition-chinese:16.0.1) // 条码扫描 implementation(com.google.mlkit:barcode-scanning:17.3.0) // 人脸检测 implementation(com.google.mlkit:face-detection:16.1.7) // 翻译 implementation(com.google.mlkit:translate:17.0.3) }这里有两个容易踩的坑。第一中英文识别不是默认功能必须显式依赖text-recognition-chinese这个独立构件依赖里没有它运行时报错或者识别效果奇差都属于正常现象。第二文字识别有两个模型选择一个是通用拉丁语系模型一个是中英文增强模型代码里也要对应设置语言类型光加依赖不设置等于白加。编译层面还要求启用Java 8或以上因为SDK内部用了java.util.function这类API。如果你的项目还在用旧版本Android Gradle插件建议先升级再集成否则会出现Invoke-customs are only supported starting with Android 8.0这类报错。3.2 第一行代码静态图片文字识别文字识别最基础的调用方式是这样val options TextRecognizerOptions.Builder() .setLanguageType(TextRecognizerOptions.LANGUAGE_CHINESE) .build() val recognizer TextRecognition.getClient(options) val image InputImage.fromBitmap(bitmap, 0) recognizer.process(image) .addOnSuccessListener { visionText - visionText.textBlocks.forEach { block - block.lines.forEach { line - line.elements.forEach { element - Log.d(OCR, element.text) } } } } .addOnFailureListener { e - Log.e(OCR, 识别失败, e) }理解这段代码关键是理解InputImage这个中间层。不管是Bitmap、相机帧还是图片URI都要先包装成InputImage再交给识别器。为什么要多这一层因为相机帧的方向、旋转角度这些信息在Bitmap里是体现不出来的而文字识别对方向极其敏感一张旋转了90度的图片识别率会断崖式下降。所以fromBitmap(bitmap, 0)里的第二个参数rotationDegrees千万别随手填0如果图片来自相机或相册要按EXIF信息取真实旋转角度。识别结果是分层的我的建议是先用visionText.text拿整段文本验证效果等确认识别没问题后再解析textBlocks层级做结构化处理。做名片类App时往往还需要结合文本块的boundingBox坐标判断字段在版面上的位置而不是只依赖文本内容本身。3.3 接入CameraX实现实时识别静态图片识别是基本功真正复杂的是把它接到相机的实时预览流上。这里我推荐配合CameraX的ImageAnalysis使用案例来做它的KEEP_ONLY_LATEST背压策略正好适合AI推理场景val analysisUseCase ImageAnalysis.Builder() .setTargetResolution(Size(1280, 720)) .setBackpressureStrategy(ImageAnalysis.STRATEGY_KEEP_ONLY_LATEST) .build() .also { analysis - analysis.setAnalyzer(executor) { imageProxy - val mediaImage imageProxy.image val rotationDegrees imageProxy.imageInfo.rotationDegrees val inputImage InputImage.fromMediaImage(mediaImage, rotationDegrees) recognizer.process(inputImage) .addOnSuccessListener { visionText - // 在这里把识别框和文本回传到UI线程 } .addOnCompleteListener { imageProxy.close() } } }这段代码里有一条“生死线”imageProxy.close()必须调用否则相机缓冲区一直被占用预览几秒后会直接卡死。另一个重点是分辨率设置。很多人直接把相机原始分辨率丢给识别器结果中端机型跑起来烫得能当暖手宝。识别任务没必要追求1080P以上精细度1280x720是一个性价比很高的档位既保证远距离小字能识别又留出了性能余量。实时场景还有个必须考虑的约束一次文字识别在中等机型上通常需要200到500毫秒。如果你的分析器每帧都做推理画面会越来越卡。我在项目里的做法是做一个简单的跳帧逻辑每三帧才抽一帧交给识别器同时记录最近一次识别开始时间间隔不足300毫秒就直接跳过。这样识别频率控制在约3帧每秒既满足实时交互的需求也不会让CPU持续满载。3.4 翻译能力的离线模型下载与状态管理翻译类的设备端模型通常体积较大ML Kit采取的是“首次使用时下载”策略。以英译中为例核心调用流程如下val translator Translation.getClient( TranslatorOptions.Builder() .setSourceLanguage(TranslateLanguage.ENGLISH) .setTargetLanguage(TranslateLanguage.CHINESE) .build() ) // 先确保模型就绪 translator.downloadModelIfNeeded() .addOnSuccessListener { translator.translate(hello world) .addOnSuccessListener { translatedText - binding.resultText.text translatedText } } .addOnProgressListener { progress - // 这里可以更新下载进度条 } .addOnFailureListener { e - // 处理网络失败或存储空间不足 }这里一定要处理好的问题是模型下载的异步状态。下载是个可能失败的网络任务你不能默认用户点开翻译页就一定能用。界面至少要提供下载中状态、失败重试按钮、以及下载完成后自动切回正常翻译UI。如果用户反复触发下载还要限制并发避免同一个语言包被多个线程同时下载导致冲突。模型下载完成后后续所有翻译都在本地跑。实测一个中等长度的句子翻译延迟在几十毫秒到一两百毫秒之间体感上跟云翻译没有明显差距。这也是设备端AI最打动人的点体验和云差不了多少但数据没出过设备网络一断照样能用。4. 查漏补缺我踩过的坑与性能优化实录4.1 常见问题排查速查表学习和排查问题时我习惯先总结一个速查表把现象、原因、解决办法放一起团队其他人遇到了也能直接对照找答案现象根本原因解决办法中文识别率极低甚至乱码用了默认拉丁语模型依赖换成text-recognition-chinese并设置LANGUAGE_CHINESE大图片识别时内存暴涨原图直送按宽边缩放到1280px以内再识别相机预览越来越卡每帧都推理且未释放缓冲使用KEEP_ONLY_LATEST策略并跳帧处理确保imageProxy.close()扫码距离很远就识别成功整帧检测的特性不是bug用结果里的boundingBox做中心区域过滤翻译模型下载失败网络不稳定或存储不足增加进度UI、失败重试、检查可用存储空间构建时报Java 8相关错误未启用Java 8编译在compileOptions里开启Java 8老教程里的类找不到了API迁移到了MediaPipe改用MediaPipe Tasks对应入口这几个坑里最让我印象深的是扫码“误识别”问题。有个项目做的是某种门票二维码核销测试时发现门票明明没有对准取景框远在画面边缘也能扫出来。刚开始我以为是bug查了文档才意识到ML Kit本来就是全画面检测设计的初衷就是为了避免“必须把码摆正”这种反人性的交互。正确做法不是限制检测范围而是在拿到识别结果后用boundingBox判断条码中心是否落在画面中央区域不满足条件就忽略。这个思路既保留了ML Kit的高识别率又满足“票必须放到框里才算”的业务设定。4.2 实时性能调优的三条具体经验第一控制输入分辨率。这条前面提过再强调一次识别场景真不需要2000万像素。1280x720的输入对识别效果影响很小但对速度影响巨大。我在一个中端测试机上对比过:1080P输入单帧推理接近600毫秒降到720P后只要350毫秒左右帧率提升接近一倍。第二合理设置检测器的运行模式。人脸检测接口支持FAST和ACCURATE两种模式实时预览场景用FAST对静态的高清自拍做精细分析时才用ACCURATE。性能模式和效果模式不是非要二选一可以做成一个用户可切换的设置项像部分相机应用的美颜强度调节那样。第三善用异步回调千万别在分析器里做同步等待。ML Kit的process()返回的是异步任务如果你在主线程或者分析线程里怼着等结果UI会直接卡成PPT。正确姿势是在回调里把结果抛回主线程更新UI分析线程只负责拿结果和释放资源。4.3 老项目迁移当API被调整之后怎么办重点提醒一下已经明显迁移的几项能力人脸网格、姿态估计、自拍分割、物体检测与跟踪官方路线已经调整到MediaPipe Tasks体系维护。这意味着老教程里类似com.google.mlkit:pose-detection的依赖坐标方式已经不再适用你得去MediaPipe的依赖坐标找对应Task API。迁移逻辑其实不算复杂之前你调用ML Kit的getClient()在MediaPipe这里变成用PoseLandmarker等Task类输入图从InputImage变成MPImage。整体思路一致主要改的是API外壳。如果你在维护一个用了这些老能力的老项目我建议做一次全量代码审查。优先替换搜索关键词PoseDetection、SelfieSegmentation、ObjectDetection、FaceMesh。这四个类如果还在代码里出现基本可以断言它们引用的SDK版本已经停更。5. 选型建议什么时候用ML Kit什么时候别用5.1 端侧还是云端一条务实判断标准很多刚接触端侧AI的同学容易走极端要么觉得端侧AI万能什么能力都想塞进APK要么觉得本地模型不靠谱能上云就上云。我的判断标准其实就三条数据是否敏感、任务是否需要实时、模型是否可控。数据敏感就选端侧。人脸、身份证、聊天记录这些留在设备上是底线。任务需要实时就选端侧。相机预览里的目标检测端侧推理的几十毫秒完全够用云端往返的几百毫秒不可接受。模型可控则看你的业务是否依赖服务器端更新模型。如果你有一个行业专属的识别模型且需要频繁调整那走自定义TFLite模型加远程下发机制比把业务逻辑绑死在通用能力API上更合适。反向来说什么场景不该硬上端侧模型体积极大、设备算力明显带不动、需要结合超大上下文做语义理解的任务比如大语言模型相关的能力现阶段老老实实走云端才是务实选择。还有一种是图片质量极差、背景极复杂的文档级OCR端侧模型的鲁棒性确实还赶不上专门优化的云端接口。做技术选型时不要被“端侧AI”这个词的光环绑架多问一句“数据能不能本地算完”答案会清晰很多。5.2 对新手最有用的一条建议集成ML Kit前先翻一遍官方示例代码再动手写自己的项目。很多同学喜欢直接Google搜博客文章可博客时效性往往跟不上SDK更新速度照着半年前的教程写出来的代码大概率跑不通。官方示例所在的仓库覆盖了所有能力的使用范例看懂一个案例剩下的基本都是同类写法的变体。还有一个容易被大家忽略的点ML Kit的接口虽然被包装得很像普通API但“可辨识的性能问题”跟“不可辨识的性能问题”存在本质区别。前者比如出图速度、识别精度后者比如隐藏的内存缓存、底层模型的加载销毁生命周期。我在一个长列表复用相册图片做图像标注时就曾经因为反复创建识别器导致内存泄漏排查了很久才发现getClient()拿到的实例应该复用而不是每张图片都新建一个。这个教训让我养成了一个习惯凡是getClient()这类工厂方法创建的实例一律提升为成员变量或单例这个规则在ML Kit的所有能力接口上都适用。真要说这套东西给我最大的感受就是“把AI当功能用而不是当研究课题”。我最早接手一个扫码项目时团队花了大半周去调一个开源扫码库的识别率和兼容性换成ML Kit的BarcodeScanning之后工作重心一下子就转移到了UI交互和业务逻辑上——后者才是真正决定产品体验的地方。设备端AI的意义也正在于此它把那些已经被充分解决的识别类问题变成了普通API让开发者能够腾出手来把精力花在用户真正能感知的部分。如果你手上也正有一个“想让应用更聪明一点”的需求我的建议是先用开箱即用的接口把完整链路跑通再根据业务反馈慢慢走向定制化这条路线最不容易走弯路。