简介面向安卓开发者的拍照OCR文字识别工程实现点击拍照后调用相机、获取图片并显示在页面再通过机器学习套件离线识别图像中的中英文文字并将结果展示在界面上。工程合理处理了运行时权限、相机回调与识别流程MainActivity与AndroidManifest等关键文件逻辑清晰适合初中级移动端开发者学习相机API、权限机制和ML Kit离线文字识别。压缩包共808个文件包含Java源码、XML布局配置、Gradle脚本、JSON资源、jar与so依赖库、tflite模型以及可安装APK等整体约68.12MB目录完整便于直接导入运行。已有161人学习下载可据此快速搭建具备拍照识别功能的应用掌握离线OCR集成思路与实际排错方法。1. 拍照 机器学习 OCR为什么端侧识别比云端更值得先做一个安卓手机 APP打开相机对准一张名片或快递单点一下拍照屏幕上立刻出现里面提取出的文字——这套能力听起来像是给云端 OCR 接口套了一层壳但真做起来你会发现完全在端侧跑机器学习模型的方案在隐私、延迟和离线可用性上的优势是云端替代不了的。标题里的三个关键词安卓手机、拍照、机器学习 OCR锁定的是一条完整本地识别链路不是接一个在线 API 就完事。适合两类人一类是给公司做内部工具比如发票录入、设备铭牌、料单拍照归档另一类是想低成本把 OCR 文字识别能力揉进自己产品的独立开发者。我见过不少团队一上来就对接云端接口结果每个月账单和弱网体验都在拖后腿。这篇文章会从选型、工程搭建、踩坑到调优给你一条能直接动手的落地路径。2. 端侧 OCR 技术选型ML Kit、Tesseract 与自建模型怎么选选错方案的代价不是多写代码而是写到一半发现模型不支持中文、包体超限、离线识别速度完全不可用。端侧 OCR 并不只是一次 API 调用它背后是“图像输入 → 预处理 → 文本检测 → 文本识别 → 后处理”的完整链路。在做任何 Android 开发之前先把这条链路里哪个环节是你的瓶颈想清楚。2.1 先搞清楚你的文字是印刷体还是手写体OCR 的识别对象直接决定方案上限。印刷体文字比如屏幕截图、打印文档、标牌、票据字体规范、笔画清晰端侧机器学习模型能做到很高的字符准确率而手写体比如会议记录、快递单上手写签名要在连笔、涂改、倾斜里找边界通用模型的表现会明显下滑。还有人习惯先在电脑上用 Python 跑通 OCR再往安卓上搬。这个思路做调研没问题但注意电脑上的 OpenCV 预处理和 Python 版本的 Tesseract和安卓端可用的库不是一套东西很多参数要重新调。端侧模型是一个黑匣子你输入 Bitmap它输出结构化文本当版面复杂时你很难判断问题出在检测还是识别这个别扭要在选型阶段就接受。2.2 三条主流路线的能力边界ML Kit、Tesseract、自建 TFLite 模型第一条路线是 Google 的 ML Kit 文本识别。它把文本检测和识别封装成了高层的TextRecognizerAndroid 工程接入成本最低离线运行时模型按需下载应用包不需要内置模型文件。缺点是可控性差你只能调 API 附带的一点点参数模型本身是黑匣子。中文识别需要额外依赖和中文模型这一点很多人会漏掉。第二条路线是 Tesseract。这是一套开源 OCR 引擎在 Windows 上装过 Tesseract OCR 安装包的人对它一定不陌生要下训练数据、配置语言包、还分各种 psm 排版模式。Android 端常用 tess-two 这类封装把chi_sim.traineddata内置到 assets完全离线缺点是语言包会让 APK 增加不少体积而且引擎本身偏传统图像处理思路对光照和噪声敏感。第三条路线是自建 TFLite 模型比如用 PaddleOCR 或 CRNN 训练后转成.tflite再通过 TensorFlow Lite 加载。这条路线精度定制空间最大比如只识别某个固定模板票据上的金额、编号字段但开发量也最大数据标注、训练、量化、端侧解码全都要自己处理。2.3 选型决策表按离线、中文、包体、精度四个维度打分方案印刷体精度中文支持离线可用包体增量开发量ML Kit 文本识别高需要中文模型依赖首次需下载模型模型按需下载低Tesseract tess-two中高内置 chi_sim 语言包完全离线1040MB中自建 TFLite 模型可定制可针对性训练完全离线310MB高选型时我会先问自己一个问题如果识别结果出错我能不能拿数据回来重新训如果只是做工具的辅助功能选 ML Kit跑通全链路再说如果做中文扫描、笔记类产品离线是卖点选 Tesseract 或自己微调模型如果做垂直场景比如合同、票据字段提取不少团队直接 Java 对接云端 OCR几小时就能跑通收入、单位、时间字段的解析但这笔账要放到长期资费和弱网回传来算。端侧初期开发量大但边际成本低。3. 用 Android Studio 搭出可拍照可识别的 OCR 工程实现步骤与关键配置这里直接用 Android Studio 建一个空工程逐步把拍照和机器学习 OCR 串起来。搭建时最有必要先把依赖和权限列清楚因为很多 OCR 识别不出来的问题根源不在模型而在 Uri 没给权限、图片被压到模糊、旋转参数重复处理。3.1 工程初始化依赖、权限与 FileProvider 配置新建工程后先在settings.gradle.kts里确认仓库配置里有google()ML Kit 和 CameraX 都靠它拉取。然后在app/build.gradle.kts里加依赖// app/build.gradle.kts dependencies { implementation(androidx.camera:camera-camera2:1.3.4) implementation(androidx.camera:camera-lifecycle:1.3.4) implementation(androidx.camera:camera-view:1.3.4) implementation(com.google.mlkit:text-recognition:16.0.0) implementation(com.google.mlkit:text-recognition-chinese:16.0.0) }说明第一组依赖是 CameraX第二组是 ML Kit 文本识别。注意text-recognition默认支持拉丁文要做中文识别必须再引入text-recognition-chinese否则中文会输出拼音或乱码。版本号我写的是当时工程里解析到的稳定版本你接入时以官方最新稳定版为准。接着在AndroidManifest.xml里声明相机权限和 FileProvideruses-permission android:nameandroid.permission.CAMERA / application provider android:nameandroidx.core.content.FileProvider android:authorities${applicationId}.fileprovider android:exportedfalse android:grantUriPermissionstrue meta-data android:nameandroid.support.FILE_PROVIDER_PATHS android:resourcexml/file_paths / /provider /applicationres/xml/file_paths.xml里指定拍照临时文件的目录?xml version1.0 encodingutf-8? paths cache-path nameocr_cache pathocr/ / /paths这里把拍照输出写到cacheDir/ocr/下不需要申请存储权限。FileProvider 会把真实路径转成content://形式的 Uri避免在跨组件传文件时直接把私有目录路径暴露出去。常见第三方 App 日志里能看到content://.../external_path/...之类的标识其实就是各家 FileProvider 的映射规则不同踩过这个坑的都知道直接在代码里拼绝对路径是最容易翻车的做法。3.2 拍照模块CameraX 拍一张临时文件别直接传 Uri相机权限使用运行时请求Android 6 以上都需要。请求成功后把 CameraX 绑定到生命周期再配置 ImageCapture。// 请求相机权限 private val requestCamera registerForActivityResult(ActivityResultContracts.RequestPermission()) { granted - if (granted) bindCamera() else log(相机权限被拒绝) } private fun bindCamera() { val preview Preview.Builder().build() val imageCapture ImageCapture.Builder() .setCaptureMode(ImageCapture.CAPTURE_MODE_MINIMIZE_LATENCY) .build() val providerFuture ProcessCameraProvider.getInstance(this) providerFuture.addListener({ val provider providerFuture.get() provider.unbindAll() provider.bindToLifecycle( this, CameraSelector.DEFAULT_BACK_CAMERA, preview, imageCapture ) }, ContextCompat.getMainExecutor(this)) } private fun capture(imageCapture: ImageCapture) { val file File(cacheDir, ocr/${System.currentTimeMillis()}.jpg) file.parentFile?.mkdirs() val output ImageCapture.OutputFileOptions.Builder(file).build() imageCapture.takePicture( output, ContextCompat.getMainExecutor(this), object : ImageCapture.OnImageSavedCallback { override fun onImageSaved(outputFileResults: ImageCapture.OutputFileResults) { val uri FileProvider.getUriForFile( thisMainActivity, $packageName.fileprovider, file ) recognize(uri) } override fun onError(exception: ImageCaptureException) { log(拍照失败, exception) } } ) }CAPTURE_MODE_MINIMIZE_LATENCY会优先保证快门响应可能损失一部分画质。OCR 对画质敏感如果发现图片边缘模糊改成CAPTURE_MODE_MAXIMIZE_QUALITY再测。文件名用时间戳避免缓存目录里同一路径互相覆盖。拍照输出用 FileProvider 转 Uri是为了下一步把文件安全地交给识别模块。3.3 接入 ML Kit 文本识别最小可运行代码与参数说明拿到拍照产生的 Uri 后送入 ML Kit 识别private fun recognize(uri: Uri) { val image: InputImage try { InputImage.fromFilePath(this, uri) } catch (e: IOException) { log(图片读取失败, e) return } val recognizer TextRecognition.getClient( ChineseTextRecognizerOptions.Builder().build() ) recognizer.process(image) .addOnSuccessListener { result - val lines mutableListOfString() for (block in result.textBlocks) { for (line in block.lines) { lines.add(line.text) } } binding.resultText.text lines.joinToString(\n) } .addOnFailureListener { e - log(识别失败, e) } }说明InputImage.fromFilePath内部会读取 JPEG 的 EXIF 旋转信息自动转正所以你不需要再手动旋转 Bitmap。ChineseTextRecognizerOptions必须配合上一节的中文依赖一起用。返回结构中TextBlock是一块文本区域下面包含多个Line业务输出通常取Line.text按行拼接。process是异步的回调在主线程执行不要在回调里再做耗时操作。跑通后这就完成了“拍照 → 本地机器学习模型 → OCR 文字识别结果”的最小闭环。4. OCR 落地避坑识别不准、中文乱码与内存溢出的 5 个真实案例以下都是项目里反复出现的问题每一条我都按现象 → 原因 → 解决整理好省得你再绕一圈。4.1 现象 1拍照后识别结果永远是空文本现象拍照正常回调也不报错但result.textBlocks是空的或者打印出来只有空字符串。原因最常见的是 ML Kit 的中文模型没有准备好API 没抛异常直接返回空结果。另一种可能是拍照生成的 JPEG 文件本身没有被正确写入 FileProvider 指定的缓存目录Uri 虽然合法但读取到的 Bitmap 是空白。解决先检查是否只加了text-recognition而漏掉text-recognition-chinese。再看拍照后文件是否存在直接val f File(uri.path)去读大概率会遇见content://映射不上的问题正确做法是回到第 3.2 节用 FileProvider 生成的 Uri 传给InputImage.fromFilePath。调试时可以把拍照原图单独保存到 MediaStore 相册用系统相册打开确认图片确实是清晰的、内容完整的。4.2 现象 2中文识别率低数字和英文却基本准确现象中文内容识别出来后夹杂着拼音、错字但同一张图里的数字和英文没问题。原因默认的 ML Kit 文本识别模型对拉丁字符优化过中文属于另一套模型。没有用ChineseTextRecognizerOptions时引擎会尝试用拉丁模型去“猜”中文结果自然不可读。解决引入中文依赖并确认创建客户端时使用的是ChineseTextRecognizerOptions.Builder().build()。另外如果图片里有手写签名ML Kit 会把它当成一个文本行混进结果里最好先裁剪掉签名区域再识别这属于 ROI 思路后面第 5 章会展开。4.3 现象 3大图识别直接 OOM现象拍照时选用了高分辨率识别启动后 App 闪退Logcat 里出现OutOfMemoryError。原因相机默认输出 4000 × 3000 级别 JPEGBitmapFactory.decodeFile直接用 ARGB_8888 解码一张图内存占用超过 48MB4000 × 3000 × 4再叠加 ML Kit 内部图形拷贝直接撑爆堆内存。解决解码前先采样压缩限制最长边。以下是常用写法val bounds BitmapFactory.Options().apply { inJustDecodeBounds true } BitmapFactory.decodeFile(file.path, bounds) val maxSide 1920 var sample 1 while (bounds.outWidth / sample maxSide || bounds.outHeight / sample maxSide) { sample * 2 } val options BitmapFactory.Options().apply { inSampleSize sample } val bitmap BitmapFactory.decodeFile(file.path, options)说明inSampleSize必须是 2 的整数次幂系统会按 2 的幂次缩放。最长边设 1920 是精度和内存的平衡点往下低于 640 时ML Kit 对密集小字的识别准确率会明显下降往上超过 2560 收益有限且内存压力陡增。4.4 现象 4文字位置乱序竖排文本输出成横排现象识别出来的文本内容都在但行与行之间顺序是乱的竖排文字被拆成若干横排片段。原因ML Kit 的TextBlock返回顺序是检测顺序不是阅读顺序。相册图片或拍照方向特殊时坐标旋转可能导致行的相对位置错乱。特别是竖排文本模型有时把它识别成多个独立 block不做坐标排序的话输出完全没法看。解决拿到result后不要直接按textBlocks的原始输出顺序拼接。先按 Y 坐标分组同一列的 Line 按 top 值排序不同列按 left 值分列。做法是取每个Line.boundingBox的top和left先按 left 粗排再组内按 top 细排。如果你的 APP 只处理横排单栏文本这一步可以省但一旦要支持票据、截图、拍照翻拍这个排序几乎是必须的。4.5 现象 5Android Studio 同步工程时依赖拉不下来现象新建工程后 Gradle 同步一直报错错误信息里是某个com.google.mlkit或androidx.camera的依赖解析失败。原因google()仓库没有配置或者网络波动导致拉取 Maven 包超时。国内开发者环境里默认的仓库顺序往往不是最优的。解决在settings.gradle.kts的pluginManagement和dependencyResolutionManagement里都加上google()并把它放在mavenCentral()前面。网络不稳定时可以在根目录build.gradle.kts里配置国内镜像仓库这和普通 Android 依赖下载是同一套处理方式。别写死某个版本的依赖先让 Gradle 把版本解析出来后再锁定到libs.versions.toml里。5. 识别速度与精度调优预处理、Tesseract 语言包与 TFLite 模型替换ML Kit 跑通之后你会开始在意两个指标识别准不准识别快不快。这一章讲三件能立刻上手的事图像预处理、Tesseract 语言包与版面模式、自建模型的接入思路。5.1 预处理管线灰度、二值化与降噪的代码对 Tesseract 这类传统引擎预处理直接影响结果白底黑字、背景干净是它最喜欢的输入。对 ML Kit 而言它内部已经做了归一化你再做二值化不一定有正面帮助但可以试。一个简单的二值化扩展函数fun Bitmap.toBinarized(threshold: Int 127): Bitmap { val out Bitmap.createBitmap(width, height, Bitmap.Config.ARGB_8888) val pixels IntArray(width * height) getPixels(pixels, 0, width, 0, 0, width, height) for (i in pixels.indices) { val c pixels[i] val gray (0.299 * Color.red(c) 0.587 * Color.green(c) 0.114 * Color.blue(c)).toInt() pixels[i] if (gray threshold) Color.WHITE else Color.BLACK } out.setPixels(pixels, 0, width, 0, 0, width, height) return out }说明阈值 127 是经验起点背光偏暗的图降到 100 左右强光照射的图调到 160 左右。二值化对 Tesseract 的收益更明显对 ML Kit 不一定因为 ML Kit 的模型训练时就见过自然光照下的清晰彩色图。先拿三张典型图对比识别结果再决定要不要把二值化放进正式管线。5.2 Tesseract 语言包与 psm 模式中文识别率提升的另一条路如果你最终选择 Tesseract先放下在 Windows 上用 Tesseract OCR 安装包的习惯安卓端要用 tess-two 这类封装。核心代码import com.rmtheis.tesstwo.TessBaseAPI val tess TessBaseAPI() val dataPath File(getExternalFilesDir(null), tesseract) val trainedData File(dataPath, tessdata/chi_sim.traineddata) if (!trainedData.exists()) { // 把 chi_sim.traineddata 从 assets 复制到 dataPath/tessdata/ } val initialized tess.init(dataPath.absolutePath, chi_sim) if (!initialized) { log(Tesseract 初始化失败检查训练数据路径) return } tess.setImage(bitmap) tess.setPageSegMode(TessBaseAPI.PageSegMode.PSM_SINGLE_LINE) val text tess.utF8Text初始化失败最常见的原因是路径错了init的第一参数指向包含tessdata目录的父目录不是tessdata本身第二参数是语言代码chi_sim对应的训练数据文件名必须叫chi_sim.traineddata。setPageSegMode要在init之后调用PSM_SINGLE_LINE适合一行文字PSM_SINGLE_BLOCK适合一段PSM_AUTO适合自由排版整页。模式设错中文识别率会断崖式下降。Tesseract 的优点是离线、可控缺点是速度。手机上跑整页大概要一两秒甚至更久所以如果只需要识别某个固定模板票据上的金额和日期字段别拿整页去跑先按模板坐标把 ROI 裁出来再按单行模式识别速度和精度都能上来。5.3 把模型换成自己的 TFLite固定模板票据识别思路当 ML Kit 和 Tesseract 都满足不了你比如票据背景复杂、字体特殊就需要自建模型。固定模板票据的一般做法是先做模板对齐再按 ROI 裁切字段最后用一个小模型识别数字和限定字符集而不是对整页做通用 OCR。这个思路比提升模型通用性更容易落地。Android 端用 TensorFlow Lite 加载模型的骨架大致是这样val interpreter Interpreter( loadModelFile(context, custom_ocr.tflite), Interpreter.Options().setNumThreads(4) ) // 假设输入是固定尺寸 32 x 256 的灰度图 val input FloatArray(1 * 32 * 256 * 1) // 把 Bitmap 缩放、归一化到 0~1 后写入 input interpreter.run(input, output) // output 是 CTC 解码前的序列概率再接字符表解析说明setNumThreads(4)是常见的端侧并发配置但线程数不是越大越好要真机实测。自建模型的工作量不在 Android 端而在训练数据字符级标注、样本增强、量化后精度验证整体周期按周计算。我的建议是把自建模型放到第二阶段先把 ML Kit 全链路跑通、积累真实图片再拿这些图去评估自建模型的收益。6. 验证与上线用一整套测试样本给 OCR 结果上保险OCR 上线前最忌讳拿真机随手拍两张看效果没问题就发版。文字识别模型的迭代依赖样本你得有一套固定的回归样本集每次改动后跑同一批图片靠数据判断是变好还是变坏。我的测试样本集分三类白底常规文档放 20 张目标是字符错误率低于 2%票据卡片放 20 张目标是金额、编号这类关键字段准确率高于 90%低光照、倾斜、模糊的极端样本放 10 张不求全对但要记录失败类型知道当前版本输在哪里。这样当你调整二值化阈值、换语言包、改 psm 模式时一眼就能看出哪类场景被牺牲了。具体做法是在 App 里留一个测试入口遍历assets/ocr_samples/下的图片自动调用识别管线把每张图的识别文本写入 CSV。每次迭代后把 CSV diff 一遍任何从“对”变成“错”的样本都必须给出解释。上线的时候把入口从正式包拿掉但这个测试代码和样本集保留在工程里作为以后的回归基线。我吃过一次没做回归的亏某个版本换了图形预处理办公室样张全部通过上线后用户拍出来的票据有一半被二值化过滤器吞了字段就是因为样本集里没有覆盖浅色纸张。现在我的原则是OCR 模型参数改动必须过回归样本否则宁可不上。这个规矩看起来笨却能挡住大多数“单独看没问题、合起来翻车”的改动。希望帮到你。本文还有配套的精品资源点击获取