做安卓开发这几年一个特别明显的感受是AI与机器学习不再是算法团队或者后端同学专属的话题。现在的招聘 JD 里开始出现“了解端侧推理”“熟悉 TFLite 模型集成”“能接入大模型 API”之类的描述产品需求里也越来越频繁地出现“智能识别”“自动分类”“AI 生成”这些词。很多安卓开发者不是不愿意接触 AI而是被一堆术语拦在门外特征、标签、训练、推理、过拟合、量化、TensorFlow Lite、ONNX、ML Kit……每个词单独看都能查到解释连在一起就不知道跟自己的 APK 有什么关系。这篇文章不打算讲数学推导也不准备让你从零手搓神经网络。我要做的是把安卓开发者最容易碰到的 AI 与机器学习基础术语一次讲清并且按照“概念 — 部署 — 集成 — 排查”的顺序告诉你每个术语在真实项目里意味着什么。1. 先分清 AI、机器学习、深度学习再看安卓开发者关心哪一层1.1 三层概念目标、方法和分支AI人工智能是最上层的目标指的是让机器表现出类似人类的智能行为。机器学习是实现 AI 的一种主流方法核心思路是让程序从数据里自动学习规律而不是靠人工规则一条条写死。深度学习又是机器学习的一个分支它用多层神经网络处理复杂数据图像识别、语音识别、大语言模型基本都是深度学习的成果。三者的关系可以理解为人工智能是你要去的地方机器学习是交通工具深度学习是其中一条高速公路。安卓开发者要区分这三层不是因为考试要考而是因为落地难度完全不同。如果需求只是做一个简单的关键词分类机器学习里的朴素贝叶斯、逻辑回归就够用如果需求是实时识别图片里的物体基本就要上深度学习模型。很多项目失败不是模型不够好而是需求方把“AI 功能”想得太笼统开发者没有把问题拆到具体方法层。1.2 算法、模型、权重、架构术语先对齐团队协作时这四个词经常被混用但它们的含义差别很大算法解决问题的计算方法比如决策树、卷积神经网络CNN都算算法。模型算法在数据上训练之后得到的结果通常表现为一个文件。权重模型文件里最重要的数值训练过程就是在不断调整这些数值。架构模型的整体结构设计比如多少层、每层做什么操作。我举一个安卓开发者熟悉的类比算法像设计模式模型像写好的 APK 文件权重像 APK 里的资源文件架构像整个项目的模块结构。你集成一个模型时其实是在使用别人训练好的成果文件并不需要重新实现算法。这直接关系到后续沟通。当算法同学说“这个模型效果不好”他可能说的是权重需要重新训练当他说“这个架构不支持端侧推理”他指的是模型结构太大手机跑不动。两种问题的解决方式完全不同。1.3 训练和推理一半术语都在说这两个环节训练Training是模型从数据中学习规律的过程需要大量标注数据、算力和时间。推理Inference是模型训练完成之后对新输入做预测的过程安卓端集成模型时做的几乎全是推理。很多安卓开发者第一次接触模型误以为自己需要懂训练于是去啃优化器、损失函数、反向传播结果越看越迷茫。实际上如果没有自训练需求你只需要理解推理流程加载模型文件 → 把输入数据预处理成模型要求的格式 → 跑一次前向计算 → 解析输出结果。但这不代表训练术语完全不用了解。产品需求里经常出现“准确率”“召回率”“误识别率”这些指标来自训练和测试阶段。你至少要知道准确率不等于一切比如一个物品识别模型对 A 类物品识别很好对 B 类物品几乎识别不出来整体准确率可能还是很高因为 A 类样本占了大头。这时候如果你只盯着一个数字上线后就会出问题。2. 数据与效果术语特征、标签、数据集、过拟合2.1 样本、特征、标签训练过程怎么“喂”数据机器学习训练的基本单位是样本。一个样本就是一条数据比如一张图片、一段文本、一条用户行为记录。特征是样本里用来做判断的信号。比如判断一封邮件是不是垃圾邮件特征可以是“是否包含敏感词”“发送频率”“链接数量”。图像任务里特征可能是像素值、边缘信息、纹理信息。传统机器学习需要人工设计特征深度学习则可以自动从原始数据里提取特征这也是它有巨大优势的原因。标签是样本对应的正确答案。有标签的数据叫监督学习没有标签但按相似程度分组叫无监督学习只有部分标签的叫半监督学习。安卓开发者接触到的成熟模型绝大多数是基于监督学习训练出来的。比如人脸检测模型训练时输入的是人脸图片样本、人脸位置框标签文本分类模型输入的是句子样本、类别编号标签。在做模型选型时你要先确认一件事你要处理的数据是什么类型输出期望是什么。图片分类、目标检测、文本分类、文本生成、语音识别背后是完全不同的模型结构不能拿一个通用模型硬套。2.2 训练集、验证集、测试集为什么不能共用一份数据会被分成三份训练集用来训练模型让模型学习参数。验证集训练过程中用来调整超参数、选择模型版本防止模型只记住训练数据。测试集模型训练完成后用来模拟真实场景评估效果测试集绝不能在训练阶段使用。这个原则和安卓开发里的测试环境很像。你不会只在自己手机上测一遍就发版至少要分开发环境、测试环境、生产环境。数据划分也是同样的道理如果用同一份数据既训练又测试模型相当于“背下了答案”测试分数再高也不能说明真实效果。判断一个模型值不值得集成不要只看算法同学给的测试报告要关注测试集是什么来源、是否覆盖了你真实业务里的数据分布。如果测试集里全是白天拍摄的照片而你的应用用户大量在晚上使用效果一定会打折扣。2.3 过拟合、欠拟合、泛化模型精度判断的基本功过拟合Overfitting是模型把训练数据里的细节和噪声都记住了换一批新数据就表现很差。症状是训练集准确率极高测试集准确率明显下降。欠拟合Underfitting是模型太简单连训练数据都没有学好训练集和测试集的准确率都很低。泛化能力Generalization是模型在新数据上的表现能力。所有模型训练的目标不是“记住训练数据”而是“在没见过的新数据上做对”。安卓集成场景里过拟合问题经常表现为用官方 Demo 图片测试效果很好换成自己手机拍的图片或真实业务图片识别结果完全不对。这不一定是集成代码有 bug也可能是模型训练数据分布与你的输入差异太大。这时候不要急着改代码先做对比测试用模型自带的样例图片跑一遍再用真实输入跑一遍。如果样例正常、真实输入异常大概率是数据分布不匹配而不是推理代码的问题。3. 端侧部署术语从 PyTorch 文件到 APK 里的可用模型3.1 端侧推理与云端推理该怎么选端侧推理On-device Inference是指模型直接运行在手机上。云端推理Cloud Inference是指手机把数据上传到服务器由服务器运行模型并返回结果。两者不是替代关系而是不同约束下的选择。我在实际项目中一般这样判断场景推荐方式原因离线可用、低延迟、隐私敏感端侧推理不上传数据不依赖网络响应快超大模型、复杂任务云端推理手机内存装不下大模型或端侧算力不够网络稳定、对实时性要求不高云端推理开发和迭代成本低混合场景端云协同简单任务端侧做复杂任务上云端侧推理最大的吸引力是隐私和实时性。人脸解锁、手势识别、实时翻译这类功能如果每次都要上传服务器用户网络稍差就卡顿还容易引发隐私质疑。但端侧也有代价包体变大、内存占用上升、老机型性能不足、模型更新需要发版。理解这个对比后你就知道为什么业内现在特别强调端侧部署。不是所有场景都适合端侧但适合端侧的场景体验优势非常明显。3.2 TensorFlow Lite、ML Kit、ONNX Runtime 实际定位这三个是安卓开发者最容易遇到的端侧推理框架。TensorFlow Lite简称 TFLite是 Google 推出的端侧推理框架专门针对移动和嵌入式设备做了优化。它支持的模型格式是 .tflite。如果你手里的模型是 TensorFlow 训练的转成 TFLite 非常顺。ML Kit 是 Google 提供的移动端 SDK封装了常见的视觉、文本、条码识别能力。它的特点是不用关心底层模型怎么部署直接调用 API 即可非常适合快速验证功能。ONNX Runtime 是微软主导的跨平台推理引擎支持 ONNX 格式模型。ONNX 是一个开放模型交换格式很多框架都能导出所以如果你的模型来自 PyTorch、TensorFlow 或其他框架ONNX Runtime 是一个折中方案。选型建议很简单如果不是重度定制先用 ML Kit 验证效果如果模型需要深度定制优先考虑 TFLite如果团队模型训练强依赖 PyTorch可以用 ONNX Runtime 或者先把模型转换为 TFLite。3.3 模型格式与转换链路.pt、.onnx、.tflite模型文件后缀就是格式的标识。常见的有.pt / .pthPyTorch 的模型权重文件。.h5 / .pbTensorFlow 旧版本格式。.onnxONNX 开放交换格式。.tfliteTensorFlow Lite 格式端侧部署的常见选择。安卓开发者经常遇到的情况是算法同学给一个 PyTorch 的 .pt 文件而你需要集成到安卓。这时候不能直接把 .pt 文件放进 assets要找算法同学或者自己完成转换链路。一个典型的转换路径是PyTorch 模型 (.pt) ↓ 导出为 ONNX ONNX 模型 (.onnx) ↓ 转换为 TFLite TFLite 模型 (.tflite)这是常见的转换链路示例实际操作时还要确认算子兼容性。有些模型包含端侧推理框架不支持的算子转换会失败这时候要么换模型结构要么用可替代的自定义算子。我在实际项目里踩过几次坑之后建议团队约定模型交付物统一为 .tflite 文件附带输入输出格式说明、量化方式和测试数据。这样算法和开发之间就有一份明确的交付接口。3.4 量化、剪枝、知识蒸馏端侧模型压缩的三板斧手机资源有限原始模型往往太大、太慢需要压缩后才能上端侧。量化Quantization是把模型里的浮点数参数从比如 32 位降到 8 位或更低从而减少模型体积提高推理速度。常见做法是训练后量化Post-training Quantization实现简单但精度可能有轻微下降更稳的是量化感知训练Quantization-aware Training训练时就把量化误差纳入考虑精度损失更小。剪枝Pruning是去掉模型中不重要的连接或神经元让模型变小。知识蒸馏Knowledge Distillation是让一个大模型“教”一个小模型把小模型训练到接近大模型的效果。这三个词在安卓项目里的意义是你可能不会亲自做这些操作但你要能听懂算法同学在做什么。当模型体积还是 80MB撑爆了 APK 大小限制这时候讨论的不是“优化代码”而是“量化 剪枝”。如果你什么都听不懂只能干等结果。注意量化不是零成本。模型体积变小后识别精度可能会有轻微下降。上线前一定要用真实业务数据重新做一轮测试不能只看体积和速度。4. 性能与运行术语延迟、FLOPS、CPU/GPU/NPU、线程配置4.1 延迟和吞吐衡量端侧推理体验的核心指标延迟Latency是指从输入数据进入模型到拿到输出结果的时间通常以毫秒为单位。对安卓应用来说单次推理延迟直接决定用户体验。人脸解锁超过一两秒用户就会觉得卡顿。吞吐Throughput是指单位时间内能处理的数据量通常以每秒处理多少张图片或多少条文本衡量。如果应用需要连续处理视频帧比如实时滤镜、实时识别吞吐量比单次延迟更重要。大多数情况下你要先确认需求更看重延迟还是吞吐。拍照识物只需要低延迟视频流识别除了低延迟还要求高吞吐否则画面会掉帧。优化方向不一样不要混在一起谈。我在集成模型时会先用一个测试页面统计几十次推理耗时看平均值、最大值和最小值。只看平均值很容易漏问题如果某几帧突然跑了 200ms而平均值只有 80ms用户感受到的卡顿就是那几帧带来的。4.2 FLOPS、TOPS、模型大小纸面算力不等于真实速度FLOPS 是每秒浮点运算次数TOPS 是每秒万亿次操作。它们是衡量硬件算力的理论指标不是实际推理速度。判断模型在某一台手机上跑得快不快最准确的依据是实际运行时间。理论算力高不代表框架优化得好模型体积小也不一定推理就快。有些模型被压缩后体积变小但计算量没变多少推理耗时几乎不降。安卓开发者只要记住纸面指标用于选型和对比真实体验必须跑测试机。同一个模型在不同芯片、不同系统版本上的表现差异可能很大不要拿一台旗舰机的测试结果代表所有用户。4.3 CPU、GPU、NPU 与 Android 设备上的调度手机上的计算单元主要分三类CPU通用计算灵活但并行计算能力有限。GPU并行计算能力强适合图像和矩阵计算。NPU专门为神经网络计算设计的加速器能效比高。推理框架通常会尝试用 GPU 或 NPU 加速但不是所有模型、所有机型都支持。TFLite 里有 GPU 代理和 NNAPINNAPI 是 Android 系统提供的神经网络 API可以调用底层的 NPU 或 GPU。这条术语链在项目里的实际含义是你设置一个“使用 GPU 加速”的选项不代表每台手机都能成功。代码里要做回退逻辑硬件不支持时自动切回 CPU 推理。很多端侧应用闪退或黑屏就是没有做好这个回退。4.4 多线程、内存占用、耗电实战里最容易翻车的点端侧推理不是只占 CPU 时间还会影响内存和电池。模型加载进内存后占用的空间可能远大于文件本身的体积推理过程如果持续占用多核 CPU手机会发热耗电会明显加快。我在项目里一般按这个顺序排查模型加载时间是不是发生在启动阶段如果是会导致冷启动变慢。推理是同步执行还是异步执行如果放在主线程会卡 UI。要不要限制并发数多个任务同时在模型上推理可能相互争抢资源反而更慢。输入图片是否被缩放过大图直接送进模型内存和时间都会爆炸。注意不要一上来就开最大并发先用一条样例确认输入、输出和日志都正常再根据内存和耗时数据调整并发数。5. 安卓项目接入 AI 模型的落地顺序和排查清单5.1 需求拆解把“加一个 AI 功能”变成具体任务产品经理说“给应用加一个人脸识别”这个需求看起来很明确但落地时至少要拆成这些子问题是需要检测人脸位置还是需要识别具体是谁需要在视频流里实时检测还是只处理拍照后的静态图片需要离线运行还是可以联网识别结果要求多高的准确率用户误识别时应用该怎么处理每个问题都对应不同的模型和方案。检测人脸位置用目标检测模型识别是谁用 face embedding 加比对算法视频流实时处理需要轻量模型加高效调度离线运行决定不能依赖云端接口。拆完需求再谈技术选型否则很容易出现辛苦接了一个大模型结果需求其实一个小模型就能满足或者反过来需求方以为手机能搞定实际需要服务器资源支持。我刚开始接触 AI 项目时最大的错误就是拿到一个项目就直接搜“哪个模型最牛”而不是先问“这个问题被完整定义了吗”。后来我养成了一个习惯所有 AI 需求先写成一段白名单描述包括输入、输出、边界条件、失败表现再让算法和产品一起确认。5.2 最小 Demo 先跑通再谈优化不管最终方案多复杂我建议按三步走第一步用最小样例验证模型。下载官方 demo APK或者用一个最简单的测试页面加载模型输入一张样例图片确认输出能解析出来。第二步替换成真实输入。用用户最常上传的图片、文本或视频帧测试确认模型在真实数据分布上可用。第三步再考虑优化。模型转换、量化加速、多线程调度、缓存策略全部在功能正常之后再做。这个顺序可以避免一个非常常见的坑项目一开始就陷入性能优化改了三天后发现模型输出本身就不对之前的优化全部白费。先保证“结果能对”再追求“速度够快”。5.3 模型输出异常时的排查顺序如果应用里模型推理结果不对或者直接报错我建议按这个顺序排查先看输入前处理图片尺寸是否被缩放到模型要求的尺寸像素通道顺序是不是 RGB数据是否归一化到模型要求的范围再看输出后处理模型输出是概率分布还是坐标框需要做 argmax 还是阈值过滤查看日志TFLite 和 ONNX Runtime 会打印算子、输入输出形状、设备选择信息很多时候问题在日志里已经写清楚了。对比官方 demo同一个模型在官方 demo 上能跑通说明模型文件本身没问题问题出在你的集成代码。检查模型版本是不是模型文件被替换过输入尺寸和标签列表是否和模型配套很多“模型不准”的报错最后定位到的是前处理逻辑写错比如没有归一化、图片缩小后变形、输入类型填错。这一行代码往往要花两三天才能发现。5.4 给安卓开发者的术语速查表和小项目建议最后整理一份速查表方便你日常回看术语简单理解安卓项目中的关注点训练模型学习规律的过程一般由算法团队完成推理用模型对新数据做预测安卓端集成的主要环节特征样本中用于判断的信号前处理阶段要把数据转成模型需要的特征标签样本的正确答案后处理阶段要把预测值映射回标签过拟合模型记住训练集新数据表现差真实数据测试才能发现量化降低模型参数精度来压缩模型模型更小更快但精度可能下降TFLite端侧推理框架最常用的模型集成方式之一ML KitGoogle 免维护 SDK快速验证功能时可优先选ONNX开放模型交换格式不同框架模型转换的中间桥梁延迟单次推理耗时直接影响用户体验吞吐单位时间处理任务量视频流处理时很关键如果你想从零开始接触安卓 AI 开发不建议第一天就去读卷积神经网络的原理。更推荐的路径是先选一个极简任务比如在图片里识别手写数字用 ML Kit 或者现成的 TFLite 模型跑通集成流程然后逐步了解模型文件、输入输出、前后处理和性能分析最后再回到术语表你会发现大部分概念都能对应到实际操作上。等这一轮走下来你再看算法团队的讨论就不会再被“模型、训练、量化、推理”这些词劝退了。