写到第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 Reply | IM快捷回复、客服助手 | 活跃维护 |
| 自定义模型 | 自带TFLite模型+远程下发 | 行业专属识别、私有模型推理 | 活跃维护 |
| 人脸网格 | 已调整至MediaPipe Tasks | AR贴纸、面具效果 | 已迁移 |
| 姿态估计 | 已调整至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，让开发者能够腾出手来，把精力花在用户真正能感知的部分。如果你手上也正有一个“想让应用更聪明一点”的需求，我的建议是先用开箱即用的接口把完整链路跑通，再根据业务反馈慢慢走向定制化，这条路线最不容易走弯路。
