安卓AI入门：机器学习核心术语与TensorFlow Lite端侧部署实践

当安卓开发者第一次接触 AI 和机器学习时，最先遇到的往往不是某个算法，而是一堆看起来有关联又说不清区别的术语：人工智能、机器学习、深度学习、神经网络、训练、推理、特征工程、损失函数、过拟合、量化……这些词在技术文章里频繁出现，第一次读的人很容易被绕晕。如果只是零散地查单词，今天记住明天忘；更严重的是，真正需要在 Android 项目里集成一个图像分类模型时，会发现连“模型文件到底放哪、怎么加载、输入输出是什么”都讲不清楚。

这篇内容想做的事情很具体：围绕安卓开发者视角，把 AI 和机器学习最常用的术语一次讲清，同时给出它们在项目里的实际位置。读完以后，你能看懂一条典型的 AI 落地链路：从业务问题出发，准备数据，选一个模型结构，训练并评估，最后把模型转成 TensorFlow Lite 或通过 ML Kit 接入 Android 工程。重要的是，后面遇到其他相关术语时，你可以把它放进这条链路的某个环节里，而不是孤立地去背名词。

1. 从 AI、机器学习到深度学习：先分清三个词的关系

在技术讨论中，这三个词经常混用，但它们的范围完全不同。人工智能是一个学科领域，机器学习是其中一条主要技术路径，深度学习又是机器学习里的一个分支。安卓开发者在看文档时，如果分不清这三个词，很容易把“AI 框架”和“机器学习框架”混为一谈。

1.1 人工智能是目标，不是一个具体算法

通俗地说，人工智能希望让计算机完成那些“看起来需要人类智能”的任务，比如听懂语音、看懂图片、理解文字、做出决策。它不是某一个固定算法，而是一个目标领域。安卓系统里的语音助手、相册自动分类、输入法智能联想，本质上都是在做 AI 相关的事，但底层用的技术可以完全不同。

从工程角度理解，AI 更像是“问题域”，而不是“工具链”。你在 Android 项目里用到的 ML Kit、TensorFlow Lite、PyTorch Mobile，都是解决 AI 问题的手段，而不是 AI 本身。这个区分很重要，否则你会把“集成某个框架”当成“做 AI”，忽略数据和业务逻辑。

1.2 机器学习是让计算机从数据中找规律的方法

机器学习与传统编程最大的区别，是不再手工写规则。传统方式是给计算机明确指令规则，比如“如果邮件包含某个词，就标记为垃圾邮件”。机器学习则是给计算机大量已标注的数据，让它自己发现特征与结果之间的关系。

这个“从数据中学规律”的过程叫训练。训练完成之后，程序里保存下来的参数和结构叫模型。模型不是一个普通配置文件，它是一个能接收输入、产生预测输出的程序化产物。对安卓开发者来说，最常见的状态是：别人已经训练好了模型，你在 App 里加载它并执行推理。

1.3 深度学习是机器学习中的一类分支

深度学习通过多层神经网络学习非常复杂的模式，尤其适合图像、语音、文本这类高维数据。之所以叫“深度”，是因为网络有很多层，前面的层提取低级特征，后面的层组合成高级语义。

移动端的人脸识别、手势识别、OCR、实时翻译，底层大多是基于深度学习模型。与经典机器学习相比，深度学习对特征工程的要求更低，但对数据量、算力、训练时间的要求更高。这也是为什么大多数安卓项目的做法是“服务端训练，端侧推理”。

1.4 安卓开发者需要记住的分层关系

可以用一句简单的话概括：AI 是一个大领域，机器学习是进入它的主路，深度学习是这条路上最常用的交通工具。安卓开发者日常接触的一般是已经训练好的深度学习模型，或者通过 ML Kit 直接调用现成的机器学习能力。

实际项目中，如果只是调用一个云服务，可以不关心训练细节；但要在端侧运行模型，就必须理解数据、模型、推理、评估这条主线。

2. 机器学习项目里的核心术语：特征、标签、样本和训练

机器学习项目看起来复杂，但核心对象只有几个：样本、特征、标签、数据集、模型、推理。把这几个词完全理解清楚，后面读论文和框架文档都会轻松很多。

2.1 样本、特征、标签：训练数据的三要素

一条完整的数据记录，在机器学习里叫样本。比如一张图片、一条短信文本、一组传感器数据，都可以是样本。样本中用于判断的输入变量叫特征。图片的特征可能是像素值，文本的特征可能是词频或词向量，业务数据的特征可能是用户年龄、点击次数、设备型号。

监督学习中，还需要一个希望模型预测的结果，这个结果叫标签。例如判断一张图片是不是“猫”，标签就是“是猫”或“不是猫”。机器学习训练的本质，就是找到从特征到标签的映射关系。安卓开发者在处理端侧模型时，同样要清楚模型输入的是特征张量，输出的是预测结果，而不是直接理解“图片文件”。

2.2 训练集、验证集、测试集为什么不能混用

训练数据通常要划分成三个集合，它们作用完全不同：

• 训练集：用于让模型学习参数，是真正被“读进去”的数据。
• 验证集：用于训练过程中选择超参数、比较模型效果，参与调参决策。
• 测试集：模型训练全部结束后，只用来做最终评估，绝不能参与训练和调参。

如果验证集和测试集混用，会导致评估结果偏乐观。最常见的结果是模型在开发阶段表现很好，上线后遇到真实数据效果明显变差。安卓端集成模型时，也要问一句：模型的评估指标是在什么数据集上算出来的？是不是和你的真实场景分布一致？

2.3 模型：训练完成后保存的是什么

训练完成后，保存下来的模型通常包含两部分：网络结构信息和权重参数。网络结构定义数据如何流动，权重参数决定每个节点的重要程度。移动端常见做法是把它们封装成一个文件，比如 TensorFlow Lite 模型扩展名是.tflite。

这个文件往往还包含一部分输入输出信息，例如输入张量形状、数据类型、输出类别索引。安卓开发时可以读取模型元数据，也可以查看训练时的代码来确定输入预处理方式。模型不是魔法，它只是一个“特征到结果”的映射函数，只不过内部参数是数据驱动学出来的。

2.4 推理：把模型用到新数据上

推理是加载模型，把新样本的特征输入进去，得到输出结果的过程。训练需要大量数据和算力，通常放在服务端；推理则可以在端侧完成，因为它不需要反向传播，只需要一次前向计算。

对安卓应用来说，推理是最常见的 AI 集成方式。典型场景包括：摄像头拍到一帧画面，模型输出物体类别；用户输入一句话，模型输出意图标签；一段传感器数据显示用户正在步行，模型输出活动类型。开发者的任务，就是准备输入、调用模型、解析输出。

2.5 特征工程和特征提取

经典机器学习非常依赖特征工程，也就是人工选择、组合、转换对预测有帮助的输入变量。深度学习出现后，端到端学习成为趋势，网络自动从原始数据中提取特征。但在端侧部署中，预处理仍然是一种“轻量特征工程”，例如图像要缩放、归一化、转成 RGB 顺序的 ByteBuffer，文本要转成 token，视频帧要抽帧。

很多 Android 集成问题不是模型训练得不好，而是预处理和训练时不一致。训练时图片是除以 255 后送入网络，端侧推理却忘记了归一化，结果就是正确率骤降。

3. 三大学习范式：监督学习、无监督学习与强化学习

机器学习可以按不同的学习方式分类。在业务场景中，选择哪种学习范式，取决于你手里有什么数据，以及希望模型做什么。

3.1 监督学习：分类和回归

监督学习要求训练数据带标签，模型学习输入到输出的映射。最常见的两个任务类型是分类和回归。

分类是预测离散类别，比如判断一张图片是猫、狗还是鸟，判断一条评论是正面还是负面。回归是预测连续数值，比如根据用户信息和设备传感器，预测电池剩余时间、房价、温度等。安卓端的图像分类、文本分类、目标检测，大部分都属于监督学习。

分类模型输出通常是每个类别的概率，比如[0.9, 0.07, 0.03]表示“猫”类别的置信度是 0.9。开发者处理输出时，通常要找到argmax索引，并映射到对应的类别名称。

3.2 无监督学习：聚类与降维

无监督学习不依赖标签，而是从数据自身结构中学习规律。典型任务有聚类和降维。

聚类把相似样本分到同一个组。例如相册中人物分组，人脸聚类功能可以把同一个人的照片自动归类。降维则是把高维数据压缩到低维，保留主要信息，常用于数据可视化、特征压缩、加速后续模型。

在移动端，无监督学习不像监督学习那样直接产生“分类结果”，但它常用于用户行为分析、推荐系统的召回阶段、异常检测等场景。例如根据用户的屏幕操作序列聚类，发现异常使用模式。

3.3 强化学习：通过奖励信号学策略

强化学习不是从静态数据集中学，而是让智能体在一个环境中反复尝试动作，根据奖励信号调整策略。它更像“试错学习”。

典型例子是游戏 AI：智能体看屏幕状态，选择动作，得分增加或减少，然后调整策略。机器人控制、自动驾驶路径规划也常用强化学习。对安卓普通应用开发来说，直接训练强化学习模型不多，但可以部署已经训练好的策略模型，比如在游戏加速、设备功耗调度中做决策。

3.4 生成式模型为什么最近特别热

近几年的生成式 AI 热潮，来自生成式模型的发展。生成式模型学习训练数据的分布，并从中生成新的内容，例如文本生成、图像生成、音乐生成。

与判别模型“判断类别”不同，生成模型更关注“如何创造相似内容”。移动端可以使用小型生成模型做文本补全、图像风格迁移、超分辨率，也可以接入云端大模型接口。理解生成式模型的关键词包括：Prompt、扩散模型、Transformer、Token 等。

3.5 在安卓项目里怎么选

判断依据很简单：如果数据有明确标签，任务目标是预测，用监督学习；如果数据没有标签，想找结构，用无监督学习；如果问题是序列决策，需要不断根据环境做动作，考虑强化学习；如果任务目标是“创造”而不是“判断”，看生成式模型。

4. 神经网络入门术语：神经元、权重、激活函数与损失函数

如果你要接触的是深度学习模型，神经网络相关术语就绕不开。不需要马上去推导公式，但要知道每个词解决什么问题。

4.1 神经元与权重：模型学习的本质是调整参数

神经网络的基本单元是神经元。每个神经元接收多个输入值，每个输入都乘上一个权重，再加上偏置，最后经过激活函数输出给下一层。可以想象成一台小型计算器：多个信号汇总后，决定“是否激活”。

训练过程最重要的动作，就是不断调整这些权重和偏置。模型里的权重数量可能从几万到上亿，训练算法会找到一组权重，使模型在训练数据上的预测结果接近真实标签。对安卓集成来说，权重已经固化在模型文件里，推理时不再更新。

4.2 激活函数：给网络加入非线性

如果没有激活函数，神经网络即使叠加很多层，整体仍然是线性变换，无法处理图像、文本中的复杂关系。激活函数的作用是给网络引入非线性能力。

常见激活函数包括：

• ReLU：输入大于 0 时直接输出，小于 0 时输出 0，计算快，是移动端模型最常见的激活函数。
• Sigmoid：把输出映射到 0 到 1 之间，适合二分类概率。
• Tanh：映射到 -1 到 1，常用于需要正负输出的场景。
• Softmax：把多分类得分转换成一组和为 1 的概率。

在移动端推理时，激活函数由框架实现，但你需要知道输出层用的是什么。比如二分类任务可能只需要一个 Sigmoid 输出，多分类任务则可能依赖 Softmax。

4.3 损失函数：告诉模型错得有多远

损失函数量化模型预测值和真实标签之间的差距。训练就是不断减少损失函数的值。

分类任务常用交叉熵损失，回归任务常用均方误差。理解这一点可以帮助你调试模型：如果训练损失一直不下降，可能是学习率太大或网络结构有问题；如果训练损失下降但验证损失上升，可能过拟合了。

安卓开发者不直接参与训练，但需要会看模型说明中的“训练损失”和“验证损失”曲线，用来判断模型是否值得信任。

4.4 梯度下降和反向传播：模型如何更新参数

梯度下降是训练模型的基础优化算法。它计算损失函数对每个参数的梯度，然后向梯度的反方向更新参数，让损失逐步变小。学习率决定每次更新的步长。

反向传播是一种高效计算梯度的算法，从输出层开始，逐层往输入层回传误差信息。没有反向传播，训练深层网络会非常困难。这些训练过程都发生在服务端，移动端只运行训练好的网络结构做前向推理。

4.5 常见网络层：卷积、池化、全连接、归一化

搭建模型时，会看到很多“层”的名称。理解它们的作用，有助于理解模型为什么这样设计。

在安卓端，网络层不会直接看到，它已经被编译进.tflite文件中。但这个概念能帮你理解：为什么更换模型后 APK 体积、推理耗时、支持的算子要求都会变化。

5. 模型评估指标：准确率、精确率、召回率、F1 与 AUC

训练出来的模型好不好，不能只看感觉。评估指标是一套量化工具，用来回答“模型在目标场景里有没有用”。安卓开发者在选模型时，也必须看懂这些指标，否则很容易被单个“准确率”误导。

5.1 准确率：先看它，但不能只看它

准确率是正确预测样本数占总样本数的比例。它最直观，但问题在于类别不均衡时非常失真。比如训练数据里 99% 是正常消息，只有 1% 是垃圾消息。模型把所有消息都判断为“正常”，准确率是 99%，但实际它一个垃圾消息都没识别出来。

安卓场景里，很多真实数据都是不均衡的。比如异常点击检测、崩溃日志分类、恶意应用识别，都是正样本极少。此时准确率只能作为底线指标，不能作为唯一标准。

5.2 精确率与召回率：不同任务要有不同侧重

精确率和召回率是二分类问题中最核心的两个指标。

精确率表示“预测为正样本的样本里，真正为正样本的比例”。精确率高，意味着模型预测出来的正样本比较可信，误报少。召回率表示“真实正样本中，被模型正确找出来的比例”。召回率高，意味着漏报少。

这两个指标经常互相矛盾。提高精确率通常会降低召回率，反过来也一样。在业务中要做取舍：

• 人脸解锁：误解锁代价高，应该更追求精确率。
• 疾病筛查：漏检代价高，应该更追求召回率。
• 垃圾短信过滤：可以接受少量误删，但不能漏掉太多垃圾消息。

如果把模型预测比作安检，精确率关心“被拦下的人里有多少是真有问题的”，召回率关心“真正有问题的人里有多少被拦下了”。

5.3 F1 分数和混淆矩阵

混淆矩阵是一个 2x2 表格，用来观察预测结果和真实标签的组合：

TP 是真正例，FP 是假正例，FN 是假负例，TN 是真负例。精确率和召回率都从这个表格中计算出来。

F1 分数是精确率和召回率的调和平均，公式是2 * 精确率 * 召回率 / (精确率 + 召回率)。当你想同时兼顾精确率和召回率时，F1 是一个综合指标。它不会因为一个指标太高另一个太低而给出虚高值。

5.4 AUC：评价排序能力

AUC 是 ROC 曲线下的面积，用来衡量模型把正样本排在负样本前面的能力。AUC 为 0.5 时模型几乎是无意义的随机猜测，为 1 时说明排序完美。

AUC 对类别不均衡问题相对稳定，适合在正负样本极不均衡时评估模型。但它的缺点是关注的是排序能力，不直接反映某个阈值下的业务效果。实际使用中，可以先用 AUC 判断模型有没有用，再根据业务需要确定分类阈值。

5.5 在安卓资源受限环境下怎么判断模型好坏

安卓端选模型，不能只盯着准确率。还要看四个端侧指标：

• 模型体积：直接影响 APK 大小和下载成本。
• 推理耗时：是否能在用户可接受的帧率内完成。
• 内存占用：是否会造成 App 内存紧张。
• 功耗：长时间调用摄像头或传感器时，是否导致设备发热。

一个准确率很高但体积 500MB、一次推理耗时 5 秒的模型，不适合端侧使用。相反，准确率稍低但量化后只有 10MB、耗时 50ms 的模型，可能更适合移动端。

6. 训练中的常见问题：过拟合、欠拟合、正则化与数据增强

训练一个模型，最常见的两个问题就是过拟合和欠拟合。理解这两个问题，能帮你判断一个模型是否能泛化到真实数据，而不是在训练样本上“背答案”。

6.1 过拟合：模型记住了训练集，没学会规律

过拟合的表现是训练集上表现很好，验证集或测试集上表现明显变差。原因通常是模型参数过多、训练时间过长、数据量太少，模型把训练集中的噪声和个例也记了下来。

就像学生死记硬背了考试题答案，换一个表达方式就不会了。对安卓场景来说，过度依赖某个原始模型可能在 demo 视频里效果很好，一到用户真实环境，因为光线、角度、背景变化，效果断崖式下降。

过拟合可以通过训练曲线判断：训练损失持续下降，但验证损失先降后升。这时需要减少模型复杂度、增加数据量、加入正则化或提前停止训练。

6.2 欠拟合：模型连训练集都没学会

欠拟合和过拟合相反。模型在训练集上表现就不好，说明它没有充分学习训练数据中的规律。原因可能是模型结构太简单、特征不够、训练不充分，或者学习率设置有问题。

出现欠拟合时，可以先增加模型层数或参数，检查特征预处理是否正确，延长训练轮数，并确认损失函数选择是否合理。欠拟合比过拟合更容易排查，因为问题很直观：连“记忆”都没做到。

6.3 正则化：L1、L2 与 Dropout

正则化是抑制过拟合的常用手段，本质是通过限制模型复杂度，让模型更关注主要规律，而不是死记每个样本。

• L1 正则化：让权重向 0 靠近，最终产生稀疏权重，很多权重为 0，能减少模型大小。
• L2 正则化：让所有权重都保持小数值，避免某个特征被过度放大。
• Dropout：训练时随机丢弃部分神经元，迫使网络不依赖特定节点，提升泛化能力。

在移动端，L1 和剪枝还能带来模型体积减小的好处。Dropout 只在训练时生效，推理时模型不再进行随机丢弃。

6.4 数据增强：用有限样本模拟更多变化

数据增强是在不增加人工标注的情况下，通过对原始样本进行小幅变换，生成更多训练样本。常见方式包括图像旋转、裁剪、翻转、亮度调整、加噪声。

对移动端场景尤其重要。端侧拍摄的照片受环境光、角度、遮挡影响很大，通过数据增强可以让模型适应这些变化，减少过拟合。训练分类狗和猫的模型时，如果原始图片都是正着拍的，模型可能对“倒着的猫”无法识别，那么训练时做随机旋转和翻转就能改善。

6.5 学习率与训练策略

学习率控制模型参数每次更新的步长。学习率太大，损失会震荡，模型不收敛；学习率太小，收敛非常慢，训练成本高。常见的做法是先用 0.001 作为初始值，再根据训练曲线调整，配合学习率衰减策略。

训练过程中还要关注批量大小、训练轮数、优化器选择。这里的经验是：不要一开始就追大模型和大参数，先用小模型跑通数据管道，确认训练曲线能稳定下降，再逐步扩大规模。

7. 安卓端部署 AI 模型：从 TensorFlow Lite 到 ML Kit

前面讲的都是概念，这一部分进入工程落地。安卓端跑 AI 模型，主流做法有两种：使用 TensorFlow Lite 直接加载模型，或者使用 ML Kit 调用封装好的能力。理解整个链路，需要先分清训练和推理。

7.1 训练和推理为什么要分开

训练需要大量数据、高性能 GPU/TPU、较长时间的迭代，通常放在服务端完成。移动端只加载训练好的模型，执行一次前向推理，得到结果。推理过程不更新权重，不需要反向传播，计算量远小于训练，因此可以在移动 CPU、GPU、NPU 上运行。

对安卓开发者来说，拿到的不再是 Python 训练代码，而是一个模型文件，比如.tflite。你的任务是把模型文件放进 App，加载到内存，准备输入数据，执行推理，解析输出。

7.2 模型转换与量化：减少体积，提升速度

TensorFlow 训练保存的模型通常是 SavedModel 格式，Android 端不能直接运行，需要转换成 TensorFlow Lite 格式。转换过程可以使用 Python 完成。

pip install tensorflow

下面是一个简单的转换示例，从 SavedModel 目录转换为.tflite文件：

import tensorflow as tf # 将 SavedModel 目录下的训练模型转换成 TFLite 格式 converter = tf.lite.TFLiteConverter.from_saved_model("saved_model_dir") tflite_model = converter.convert() # 保存为 Android assets 目录需要的文件 with open("model.tflite", "wb") as f: f.write(tflite_model)

转换后还可以做量化，把浮点参数变成低精度表示。最常见的三种形式：

全整数量化往往需要一个代表性数据集来校准激活范围，否则精度下降会很明显。如果原模型包含某些特殊算子，转换时也要检查是否被当前 TensorFlow Lite 版本支持。

7.3 Android Studio 集成 TFLite 运行推理

在 Android 工程中，把.tflite文件放到assets目录，然后在build.gradle中添加依赖：

dependencies { implementation 'org.tensorflow:tensorflow-lite:2.14.0' }

如果模型包含 GPU 加速支持，可以额外加入 GPU delegate 依赖。下面用 Kotlin 写一个最小的推理代码，读取assets下的模型文件，对输入数据进行预测：

import android.content.Context import org.tensorflow.lite.Interpreter import java.nio.ByteBuffer import java.nio.ByteOrder class TfliteHelper(context: Context, modelPath: String) { private val interpreter: Interpreter init { val modelBuffer = loadModelFile(context, modelPath) interpreter = Interpreter(modelBuffer) } private fun loadModelFile(context: Context, modelPath: String): ByteBuffer { val assetFileDescriptor = context.assets.openFd(modelPath) val inputStream = context.assets.open(modelPath) val bytes = inputStream.readBytes() inputStream.close() return ByteBuffer.wrap(bytes).order(ByteOrder.nativeOrder()) } fun predict(input: ByteBuffer, outputShape: IntArray): FloatArray { val output = Array(1) { FloatArray(outputShape[0]) } interpreter.run(input, output) return output[0] } fun close() { interpreter.close() } }

这里要特别解释几个关键点：

• 输入ByteBuffer的形状和数据类型，必须和训练时一致。比如图像分类模型输入往往是[1, 224, 224, 3]的 float 张量，需要先把图片缩放成 224x224，按 RGB 顺序填充，再执行归一化。
• 输出Array(1) { FloatArray(...) }的维度取决于模型输出。通过interpreter.getInputTensor(0).shape()和getOutputTensor(0).shape()可以动态读取形状，避免写死。
• 不要在 UI 主线程直接执行推理。否则遇到大模型时，界面会明显掉帧甚至 ANR。

一个典型的图像预处理代码片段如下：

fun bitmapToByteBuffer(bitmap: Bitmap, inputSize: Int): ByteBuffer { val scaledBitmap = Bitmap.createScaledBitmap(bitmap, inputSize, inputSize, true) val byteBuffer = ByteBuffer.allocateDirect(4 * inputSize * inputSize * 3) byteBuffer.order(ByteOrder.nativeOrder()) val pixels = IntArray(inputSize * inputSize) scaledBitmap.getPixels(pixels, 0, inputSize, 0, 0, inputSize, inputSize) for (pixel in pixels) { val r = (pixel shr 16) and 0xFF val g = (pixel shr 8) and 0xFF val b = pixel and 0xFF byteBuffer.putFloat(r / 255.0f) byteBuffer.putFloat(g / 255.0f) byteBuffer.putFloat(b / 255.0f) } return byteBuffer }

预处理顺序错一个地方，模型的输出都会受影响。最稳妥的方法是去查看训练脚本或模型元数据，而不是凭感觉猜测。

7.4 用 ML Kit 快速接入现成能力

如果不想处理模型文件、输入输出张量，Google 的 ML Kit 提供了多条现成的能力，例如人脸检测、文本识别、条码扫描、图像分类、对象检测、翻译等。它底层也运行模型，但对外封装成了更简单的 API。

ML Kit 的优点是开箱即用，降低开发成本。适合快速实现功能，比如扫描名片、识别银行卡、检测图片中的人脸。缺点是你不知道模型的细节，也没有办法做针对性的模型压缩和优化。如果业务目标非常特定，自定义模型仍然是更可控的方案。

7.5 硬件加速：GPU、NPU 和线程数

TFLite 在 Android 端可以使用 GPU 代理（Delegate）和 NNAPI 来调用 GPU 或 NPU 加速。GPU 适合图形学相关模型，NNAPI 则可以把任务分发到设备提供的硬件加速单元。

启动 GPU 代理的示例代码：

val options = Interpreter.Options() options.addDelegate(GpuDelegate()) interpreter = Interpreter(modelBuffer, options)

硬件加速不一定总能带来收益。部分模型算子兼容性不好，在低端设备上可能比 CPU 更慢，或者初始化时间太长。生产环境一定要在真实设备上做多机型验证，不能只看单台机器测试结果。

线程数方面，Interpreter.Options.setNumThreads()可以控制并发线程数。大多数情况下 2 到 4 个线程就可以获得较好性能，继续增加线程不一定更快，还可能增加功耗和发热。

8. 安卓 AI 开发中的常见坑和最佳实践

端侧 AI 集成并不是“把模型文件放进去就能跑”。根据实际项目经验，很多问题都出在概念不清、数据格式不对和性能监控缺失上。

8.1 常见错误与坑

8.2 排查链路

当端侧 AI 功能出现问题，推荐按下面的顺序排查：

1. 确认模型文件路径是否正确，能否被正常读取。
2. 确认模型输入张量的形状、数据类型、数据顺序是否和训练时一致。
3. 用小范围的固定输入测试模型，比如一张已知训练图片，看输出是否合理。
4. 检查输出解析逻辑，例如是否需要经过 softmax，类别索引和标签表是否对齐。
5. 统计推理耗时，确认瓶颈在模型本身，还是在图像缩放、内存拷贝等数据准备阶段。
6. 日志记录关键信息：输入尺寸、耗时、输出置信度。没有日志很难排查线上问题。

这条链路比“改代码重试”高效得多。先确认输入，再确认输出，最后才考虑是不是模型文件本身有问题。

8.3 可复用的最佳实践清单

• 将模型文件放入assets，并统一约定模型版本号，更新时避免旧缓存冲突。
• 使用Interpreter作为单例对象，不要在每次推理时重复加载。
• 推理放到后台线程，使用Executors.newFixedThreadPool(2)或 Kotlin 协程隔离。
• 读取模型输入输出签名，通过getInputTensor(0).shape()动态获取形状，避免硬编码。
• 对图片数据进行统一封装，确保所有调用方使用同一个预处理工具类。
• 记录推理耗时和置信度，便于灰度发布时观察模型真实效果。
• 增加降级机制：端侧模型不满足条件时，可以调用云端服务兜底。
• 所有模型文件都要经过版本管理和安全审查，避免引入包含恶意行为的模型。
• 发布前在旧机型、低内存机型上做性能测试，重点观察 RAM 和温度。

8.4 学习路径建议

如果此前完全不了解 AI 和机器学习，不建议直接去看复杂公式。可以先跑通一个完整的最小示例，例如训练一个图像分类模型，然后转换、部署到 Android 上，观察端到端链路。只有亲手见过“模型文件从哪儿来、到哪里去”，才能把零散术语串成体系。

在熟悉基础流程后，再学习数据预处理、模型量化、模型评估指标和性能优化。遇到新术语时，不要只背定义，而是回到这条链路中问三个问题：它出现在训练阶段还是推理阶段？它影响模型效果还是端侧性能？如果换一种模型，它会不会变化？

对安卓开发者来说，最有价值的能力不是从零训练一个大模型，而是能够理解模型、评估模型、正确部署模型，并在真实场景中持续验证表现。把这篇文章里的术语都放进自己的实践项目里，下次看到任何 AI 技术文档，你都会比之前从容很多。