企业官网建设流程全解析

去年冬天我接了一个扫码相关的功能模块，最初方案用的云端识别接口，实测下来稳定性和体验都让人头疼——弱网环境下每次识别要转圈好一会儿，网络一抖整个流程就卡住。后来把识别逻辑切到 ML Kit 的设备端检测，第一轮联调就跑得很顺。那一刻我才认真意识到：设备端AI并不只是"离线备用方案"，它本身就有不可替代的价值。

这篇内容对应我之前整理的技术笔记里的第18章，主题就是 ML Kit 与设备端AI。ML Kit 是移动端机器学习套件，核心思路是把模型直接部署到手机本地，让图像识别、文字提取、目标检测这些能力在设备上直接完成。对于移动端开发者、做应用智能化改造的朋友，尤其是那些正在纠结"识别功能放云端还是放端侧"的团队，这一篇应该能帮你把思路理清楚。

1. 从云端到端侧：设备端AI解决的是体验问题

1.1 为什么越来越多的功能要放在手机本地执行

几年前移动端要做图像识别，几乎只有一条路：把图片传到服务器，等服务器推理完再把结果返回来。这种做法在技术验证阶段没什么问题，但一旦放到真实用户手里，问题就暴露得很直接。

第一个问题是延迟。即使服务器处理只要50毫秒，一次图片上传加结果返回，在网络良好的情况下也要200毫秒以上。用户在扫码、拍摄文档、识别商品图时，200毫秒的等待会被直接感知为"卡了一下"。弱网情况下这个数字会变成几秒，基本不可用。

第二个问题是隐私。很多场景下用户并不希望图片被上传到服务器。比如身份证识别、病历单识别、企业内部设备铭牌识别，这些内容本身就敏感。把数据放在设备本地处理，可以从架构层面彻底规避"数据出境""服务器侧数据泄露"这些隐患。

第三个问题是成本。云端推理按调用量计费，业务量一大，费用会一路走高。设备端推理不消耗云端计算资源，很多高频调用场景算下来的性价比要高得多。

设备端AI的典型逻辑是：把推理能力前置到端上，让手机自己完成检测、识别、理解这些事。它不代表彻底抛弃云端，而是让"该在哪里算"这件事回到理性——能本地算的本地算，只有本地搞不定的再交给云端。

1.2 设备端AI不等于"阉割版AI"，而是架构选型

很多开发者下意识认为，设备端AI是受限于手机算力的简化方案，效果一定比云端差。这个认知在五六年前还成立，但现在实际情况已经变化很多。

手机端SoC的NPU算力逐年提升，模型量化技术和推理框架也在不断优化。面向文本识别、条码扫描、人脸检测、图片分类这一类场景，部署在端侧的轻量模型已经能有非常接近云端大模型的识别质量，而它的零延迟、离线可用、不消耗流量这些特性，是云端方案无法替代的。

ML Kit在架构上的特点，是把这些端侧能力封装成了按需接入的模块。官方提供的现成API大致覆盖下面这些场景。

这些API的好处是：拿到接入文档就能跑通，不需要自己训练模型，也不需要对推理框架有很深的理解。适合绝大部分业务场景的"第一版智能化"需求。

2. ML Kit上手：依赖配置与一次完整调用链路

2.1 引入依赖时最容易踩的坑

ML Kit有一个让新手容易混淆的地方：它不是一个大而全的SDK，而是按功能拆分的多个库。你用到哪个功能，就单独引入哪个依赖，而不是一次性把整个框架拖进来。

dependencies { // 条码扫描 implementation("com.google.mlkit:barcode-scanning:17.2.0") // 文字识别 implementation("com.google.mlkit:text-recognition:16.0.0") // 人脸检测 implementation("com.google.mlkit:face-detection:16.1.6") }

按需引入意味着最终安装包体积是可控的。这一点很重要——每个功能模块都会附带对应模型文件和推理代码，如果一次性全部引入，APK体积会明显增长。实际项目里，一个扫码功能模块大约会带来几百KB到一两MB的体积增量，算是在可接受范围内。

接入过程中最容易忽略的是最低系统版本要求。ML Kit要求最低支持Android 7.0（API 24）及以上，如果你的应用还停留在Android 6.0时代，就要先做系统版本兼容处理，或者给这部分用户走云端方案兜底。

还有一点需要特别提醒：这些模块不需要额外做模型下载配置，模型会随应用打包到本地。早期使用体验比较好的时候，很多人会误以为自己接的是云端版本，其实大部分调用都是纯本地完成的，不需要网络权限。

2.2 以条码扫描为例拆解调用流程

ML Kit的使用逻辑高度统一：创建检测器 → 传入图片 → 异步获取结果。以条码扫描为例，完整链路大致是这样。

class ScanActivity : AppCompatActivity() { private lateinit var scanner: BarcodeScanner override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) // 1. 配置扫描格式，只关心二维码 val options = BarcodeScannerOptions.Builder() .setBarcodeFormats(Barcode.FORMAT_QR_CODE) .build() // 2. 创建检测器实例，尽量复用而不是反复创建 scanner = BarcodeScanning.getClient(options) } fun scanBitmap(bitmap: Bitmap) { // 3. 把Bitmap包装成InputImage // 第二个参数rotationDegrees表示图片旋转角度，0表示正常方向 val image = InputImage.fromBitmap(bitmap, 0) // 4. 异步处理 scanner.process(image) .addOnSuccessListener { barcodes -> // 5. 拿到结果列表 for (barcode in barcodes) { val content = barcode.rawValue val cornerPoints = barcode.cornerPoints } } .addOnFailureListener { e -> // 处理识别失败 } } override fun onDestroy() { super.onDestroy() // 6. 释放检测器资源 scanner.close() } }

这里有两个细节，实际项目里直接影响稳定性。

第一，检测器实例一定要复用。ML Kit的检测器在首次创建时会加载模型，这个过程开销不小。如果每帧都重新去拿一个实例，性能会非常难看。正确做法是像上面代码一样，在页面初始化时创建检测器，整个生命周期内复用，页面销毁时调用close。

第二，InputImage的rotationDegrees参数常常被忽略。CameraX等相机框架在部分设备上返回的图像是有方向旋转的，如果不传入正确的旋转角度，识别出来的框和坐标就会错位。这点在后文会展开细说。

2.3 调用背后的线程模型与生命周期

ML Kit的process方法本身是异步的，模型推理会在内部线程池执行，结果通过Listener回调返回。默认情况下，如果调用方在主线程执行process，回调会回到主线程；如果你有明确的并发控制需求，可以传入一个Handler来控制回调线程。

新手常犯的一个错误，是在回调里做重量级任务，比如直接把Bitmap转成Base64、写文件、做复杂的UI计算，这些应该全部挪出回调。还有一个隐藏问题：process方法如果被频繁调用，内部任务队列会积压。尤其在相机场景下，每一帧都可能触发一次检测，队列一旦堆积，延迟会越来越明显。后面第4部分会专门讲这个问题。

从生命周期角度看，凡是创建了检测器的地方，都要保证在合适的时机调用close。否则模型占用的内存会一直留在进程里，页面反复进出后内存占用会持续上涨。Android的Profiler里能明显看到Native内存只升不降，就需要回去排查是不是有检测器没释放。

3. 设备端AI与云端推理的取舍：先算清楚这笔账

3.1 单次推理的成本账：延迟、流量、配额

设备端AI和云端推理不是替代关系，而是取舍关系。选哪种方案，得先算清楚账。

这组对比能得出很清晰的结论：凡是高频、实时、隐私敏感的功能，设备端推理是优先选择；凡是需要大模型理解能力、数据量大、对旧设备兼容要求极高的场景，云端推理仍然有价值。

比如你做一个会议纪要App，需要把用户录制的语音转成文字。转写过程涉及声学模型和语言模型，端侧模型能做到的程度目前仍然有限，这时把音频传到云端做处理是合理的。但如果你只是做一个门禁出入扫码应用，每一次扫码都要走一次云端识别，成本和使用体验都是灾难。

3.2 设备端推理的隐性代价：内存、体积与耗电

设备端推理不是零成本。它把云端的计算成本转移到了手机上，真正付出的代价体现在三个地方。

第一个是安装包体积。一个识别模块增加几百KB到2MB很常见。如果一个应用同时接入条码扫描、文字识别、人脸检测、图像标注，模型文件叠加起来会让APK明显膨胀，对应用下载转化率是负面影响。所以接入时一定要克制，用不到的模块不要碰。

第二个是运行时内存。模型加载到内存后，会同时占用Java堆和Native堆。实测单个检测器加载后的额外内存占用一般在20MB-50MB，多模型同时挂载时内存水位会明显上升。在低端机型上，这可能导致系统频繁GC，甚至触发内存紧张回调。

第三个是耗电。持续做端侧推理会唤醒NPU和CPU高频工作。如果是相机实时预览流上每帧都做识别，半小时明显发烫是非常正常的。避免方式就是后面要讲的——限制检测频率，不做无意义的重复计算。

3.3 混合架构实例：本地初筛与云端兜底

实际工程里用得最多的是混合架构。我来分享一个文档扫描功能的落地例子。

这个功能的第一步是检测文档边界和方向。用ML Kit的文档扫描模块在本地完成边界检测，可以做到毫秒级响应，用户举起手机就能在取景框里看到实时边界框。第二步做文字提取，这里没有直接上云端，而是先用本地文字识别跑一遍，识别置信度超过阈值的直接返回结果；只有本地识别不确定的内容，才发到云端做二次精细识别。

这套方案的效果很直观：大约70%的调用完全走本地，零延迟、零成本返回结果；30%的调用走云端兜底，保证识别质量。用户能感知到的是"识别速度很快，偶尔慢一点但结果很准"。

这种"本地初筛 + 云端精修"的模式，在我看来是当前阶段移动端AI应用最务实的做法。理解了这个模型，你在选型时就不会非黑即白。

4. 真实项目中的性能问题与排查经验

4.1 预览流卡顿：把检测放在正确的时间片里

接入相机预览做实时识别，是ML Kit最常见的应用方式，也是最容易翻车的场景。最常见的错误做法是：在相机的ImageAnalysis回调里，每一帧都调用检测器的process方法。

结果就是前面提到的任务积压。相机流是30帧每秒，检测器单帧处理需要50毫秒，每秒新增30个任务、只能处理20个，队列越积越多，延迟越来越大，最终表现为画面卡顿、识别结果越来越慢。

我的实测方案是两层控制。

第一层，控制分析频率。CameraX默认的ImageAnalysis回调频率太高了，直接设置targetResolution降低分辨率，预览分析控制在每秒8-10帧足够满足绝大多数扫码识别业务。

ImageAnalysis.Builder() .setTargetResolution(Size(640, 480)) .setBackpressureStrategy(ImageAnalysis.STRATEGY_KEEP_ONLY_LATEST) .build()

第二层，在业务层做节流。比如记录上一次检测的时间戳，间隔至少100毫秒才提交下一次检测，手动限制处理密度。

private var lastAnalysisTime = 0L private fun shouldAnalyze(): Boolean { val now = System.currentTimeMillis() return if (now - lastAnalysisTime >= 100) { lastAnalysisTime = now true } else { false } }

还要注意setBackpressureStrategy的选择。STRATEGY_KEEP_ONLY_LATEST的意思是，如果处理不过来就丢掉中间帧，只保留最新帧，这个策略对实时识别最友好。如果你用了不限制背压的默认策略，出现帧堆积和延迟膨胀只是时间问题。

4.2 首次加载慢：模型初始化的隐性耗时

ML Kit的模型是延迟加载的，第一次调用检测器时，要做模型读取、解析、初始化，这个过程通常要几百毫秒到一秒多。实际体感是：页面第一次打开时，识别要等很久才出结果，之后再调用就快得多。

解决这个问题的思路是预热。在应用启动后、用户真正进入扫码页面之前，找一个空闲时机创建检测器实例，并用一张无关紧要的图片（比如一张纯色小图）调用一次process，把模型加载的耗时前置到用户无感知的阶段。

需要注意，预热调用会回调一个识别结果，业务上必须忽略这个结果，不要在预热流程里做任何UI逻辑。另外，如果应用支持多进程，要注意预热和真正使用要发生在同一个进程里，常见的问题就是Activity跑在主进程，预热的业务代码却写在了一个独立进程的后台服务里，预热起不到作用。

4.3 内存水位飙升：多检测器并发时的控制手法

一个应用同时接入多个检测器时，内存问题几乎必然出现。举例来说，你的首页有扫码入口，识别屏幕上有文字识别功能，头像上传有人脸检测功能，三个检测器如果都常驻内存，模型占用的Native内存会叠加到近百MB。

我踩过这个坑之后，定下了一条规则：按需创建，用完即关。检测器只在对应功能真正进入前台时创建，离开后立即close。同时，尽量复用同一个进程内的模型缓存机制——ML Kit本身对相同模型会做缓存复用，你不需要为同一个模型反复创建多个实例，但要注意不同功能的检测器确实属于不同模型，它们无法共享。

内存问题要用工具验证，别靠感觉。Android Studio自带的Profiler在Native内存视图下能清楚看到模型加载前后的水位变化。如果发现某次功能跳转后Native内存不回落，基本就是检测器没关。逐个页面排查close调用，配合LeakCanary这类内存检测工具，很快能定位。

4.4 检测质量不佳：图像旋转、光线与输入尺寸

识别效果不好，别急着怪模型。多数质量问题出在输入图像这一个环节。

第一是方向问题。前面提到过，InputImage.fromBitmap的第二个参数是旋转角度，大部分情况下传0是没问题的，因为Bitmap本身已经经过解码处理。但如果你直接从CameraX的ImageProxy拿YUV数据生成InputImage，就一定要传正确的rotationDegrees。否则检测出来的坐标框整体偏移90度或180度，看起来很诡异。

第二是光线问题。设备端模型对复杂光照的适应能力有限。极端暗光下扫码失败率显著提升，强逆光下文字识别准确率也会下降。工程上的补救措施是引导用户：识别页面在低光环境下自动开启手电筒图标提示，或者引入时间降噪——同一目标连续多帧检测成功再确认结果，比单帧结果更可靠。

第三是输入尺寸。有些开发者习惯把高清原图直接丢给检测器，觉得分辨率越高识别越准。实际效果恰恰相反。超大图不仅增加推理耗时，还会让检测器处理时间变长、失败率上升。我的经验是，文字识别控制在最长边1600px以内，条码检测控制在1280px以内，效果最好。高分辨率原图可以直接压缩后再送入检测器。

5. 从现成API到自定义模型：设备端AI的进阶方向

5.1 ML Kit支持自定义模型，但有边界

ML Kit除了现成API，还支持加载自定义的TensorFlow Lite模型。这意味着你可以在设备端运行属于自己的推理逻辑，而不仅限于官方提供的固定能力。

基本流程是：在服务端用训练框架训练模型，导出为TensorFlow Lite格式，再把模型文件放到App的assets目录，运行时通过方式加载。

// 以本地模型加载为例 val localModel = LocalModel.Builder() .setAssetFilePath("mymodel.tflite") .build() // 通过自定义模型加载器获得解释器 val interpreter = CustomModelLoader.getInstance().load(localModel)

加载之后，你就可以像使用普通TensorFlow Lite解释器一样，对输入数据进行预处理、推理、后处理。这个API的边界在于：ML Kit主要负责模型的加载和生命周期管理，具体输入输出的张量转换、业务后处理逻辑，都需要自己实现。

5.2 端侧模型的选择、转换与量化

把训练好的模型搬上手机，转化这一步有很多细节。模型转换有两个方向需要注意。

第一是格式转换。用训练框架训练出的模型要导出为.tflite格式。转换过程本身不难，但会遇到一些算子不支持的问题，需要在转换时指定兼容目标区域。如果模型里有一些自定义算子，会显著增加落地难度，一般要改写模型结构或者用替代算子。

第二是量化。量化是减小模型体积、提升推理速度的关键手段。FP16量化损失很小，能把模型体积缩到接近一半；INT8量化则更激进，可能需要少量校准数据来调整精度。对端侧推理来说，INT8是目前性价比相对高的选择，识别精度的回退通常在可接受范围内。

举个例子，我之前接触过一个设备仪表盘读数识别需求。通用OCR模型在印刷体上的表现很好，但面对玻璃反光、数字字体特殊、表盘背景复杂时，准确率不够。后来针对这个特定场景收集了一批数据，训练了一个轻量的专用读数识别模型，经过INT8量化后体积不到2MB。部署到端侧的效果是：识别质量反超了通用云端OCR，延迟也稳定在几十毫秒内。

5.3 什么情况下应该从ML Kit切换到自训模型

虽然自训模型听起来更自由，但从工程效率看，它也有沉重的代价——数据标注、训练迭代、精度评测、模型版本管理、线上质量监控，每一项都是长期投入。我的判断标准很朴素：现成API跑不出来的业务，才真有自训的必要。

具体来说，出现下面几类信号时，就该认真考虑自训了。

一是现成API的识别目标不满足。比如你想识别特定型号的设备故障码，通用文字识别能提取字符，但无法帮你分类和结构化，业务要求又不能接受再套一层云端逻辑，这时自训一个小分类模型更合理。

二是模型体积要求极苛刻。现成的通用文字识别模型体积偏大，如果你只需要识别三五个固定的关键词，一个几百KB的超轻量模型会远好过拖一个完整OCR模型。

三是离线隐私强约束业务。有些企业内部应用明确要求任何图片都不得离开设备。这类场景下，所有现成API如果必须联网完善能力，都会触碰合规红线，而自训模型可以保证完整流程本地化。

不太建议的情况是：现成API完全能满足需求，但团队为了"技术先进"非要自训。这种投入在大部分业务场景里都收不回成本，不如把精力放在产品体验和性能优化上。

我个人的落地习惯一直是这样：先用现成API验证核心链路，把端到端流程跑通；然后采集一批真实业务数据，专门分析失败样本；只有当现成方案明确卡在了质量或性能瓶颈上，再启动自训模型计划。设备端AI不是炫技的玩具，它就是移动端研发里的一种资源调度手段和体验优化策略。多做几个真实的业务模块，再回头看这一章的框架，你会发现，技术选型的核心从来不是"哪个更高端"，而是"哪个更划算"。