Android端实时表情识别：YOLOv8人脸检测+NCNN推理实践

简介：面向Android开发者和AI算法工程师，这份资源提供可直接运行的Android表情识别Demo，用于在普通手机上完成实时面部表情与情绪检测，推理速度CPU(4线程)约30ms、GPU约25ms，适合移动端实时交互、情绪分析、课堂专注度评估等低延迟场景，也可作为轻量级人脸表情识别算法工程化落地的参考基线。压缩包体积仅24.53MB，共2个文件：一个APK安装包，可直接部署到Android设备体验识别效果；一个JSON配置文件，可用于查看或调整程序中的模型与识别参数。已有1815人学习下载，说明其在Android端表情识别应用中有一定关注度与实用价值。作者还配套了《面部表情识别》系列技术文章，涵盖数据集下载、Pytorch训练、C++实现等内容，开发者可结合这些文章，快速打通从数据准备、模型训练到移动端部署的完整链路，有效缩短AI功能从算法原型到App落地的工程时间。 别再被网上那些"三天学会AI人脸识别"的标题党忽悠了，真正想在Android上跑一个实时表情识别Demo，最实在的路线就那几条。我最近刚好把一套完整方案调通，从模型选型到Android端推理链路全部走了一遍，这里把整个过程和关键代码拆开揉碎讲清楚，看完你也能自己build一个。

这个Demo的核心技术栈是YOLOv8n-face做人脸检测，配合轻量级分类网络判断表情，在Android端用NCNN做推理引擎，走CameraX的实时预览管线，做到打开相机就能在画面上框出人脸并打出当前表情标签。整个过程不依赖云端API，纯端侧计算，数据不出手机，实测在骁龙778G上整体帧率能稳定在15fps以上，完全够Demo级别使用。

1. 整体设计思路：为什么是"人脸检测+表情分类"两段式

1.1 别想着一步到位，两段式架构最简单可靠

表情识别这件事，如果直接扔给一个模型去做"图像→表情"的映射，看起来省事，但实际上有几个麻烦：一是图像里可能没有人脸，模型会胡猜；二是多人场景下没法逐个标注位置；三是模型训练需要的数据量和标注成本成倍上升。所以在实际工程里，几乎都会拆成"人脸检测"和"表情分类"两个阶段来处理。

人脸检测只负责回答"图里有没有人脸，框在哪"，输出一组边界框坐标，这一步是成熟的，有大量预训练模型可以直接用。表情分类则把检测出来的人脸区域单独裁剪出来，缩放后送入一个轻量级图像分类器，输出"生气、厌恶、恐惧、开心、悲伤、惊讶、中性"这7类概率。两段分开，各自调优，出了问题也好定位——是没框住人脸，还是分类错了。

1.2 模型选型对比：YOLOv8n-face好在哪

市面上人脸检测方案不少，我实际试过的有这么几类：

方案	模型大小	端侧推理速度	优缺点
MediaPipe Face Detection	约1MB	快	轻量但边框有时不够紧，多人场景略弱
OpenCV Haar Cascade	极小	极快	正面效果好，侧脸/低头基本凉
YOLOv8n-face	约6MB	中速	精度高、稳定、支持多人，适配性强
百度/腾讯云API	无	取决于网络	要联网、有延迟，还有隐私问题

最终我选了YOLOv8n-face。它的权重是在WIDER Face这类大规模人脸数据集上训练过的，对姿态变化、遮挡、暗光环境都比传统方案稳。打包FP32模型大约6MB，量化后可以压到3MB左右，在端侧可接受。而且YOLOv8系列生态成熟，导出到ONNX、再转NCNN的链路很顺，不需要自己造轮子。

1.3 表情分类器：用MobileNetV3-Small就够了

表情分类不用上大模型，ResNet50那种放手机上是灾难。MobileNetV3-Small最低只需要96×96的输入分辨率，模型大小约4MB（FP32），单次推理在骁龙平台上大概8~12ms，用来做第二段推理非常合适。分类类别是FERPlus数据集的8类，最后一类作为"未知"兜底，实际使用体验很关键。

2. 模型获取与转换链路：从PyTorch到Android中间踩过的坑

2.1 模型出处和预训练权重

YOLOv8n-face不是一个官方发布模型，社区有很多基于YOLOv8改的人脸检测权重。我用的版本是在ultralytics框架基础上，用WIDER Face微调过的，输入尺寸默认640×640，检测头输出类别数只有1类（face）。拿回来后第一步是验证效果：用Python脚本读取一张测试图，打印检测框坐标和置信度，确认权重本身没问题再进入转换环节。

表情分类模型我用的是torchvision里的mobilenet_v3_small预训练版本，然后在FERPlus上做了二次微调。FERPlus比FER2013好一点，它修正了FER2013的标签噪声，有8类（多了一个"contempt"）。我在代码里把它和中性类合并了，最终输出7类表情。

2.2 PyTorch导出ONNX的细节

导出这一步看似简单，但坑在动态轴和输出层解析上。用ultralytics的export接口可以直接导出：

yolo export model=yolov8n-face.pt format=onnx imgsz=320

这里我把输入尺寸改成320不是为了省那点显存，而是为了移动端推理速度。640输入在手机上的耗时是320的3～4倍，但检测效果在近距离场景下差别不大。导出时有两个关键参数必须手动确认：opset=12（NCNN对高版本opset支持不够全），以及动态轴dynamic=True（如果你希望支持不同分辨率输入的话）。如果不需要动态输入，固定尺寸导出更稳。

导出后用onnxsim做一次图优化，能消除一些冗余算子：

python -m onnxsim yolov8n-face.onnx yolov8n-face-sim.onnx

这一步能砍掉不少无用节点，后续转NCNN出错概率也小。

2.3 ONNX转NCNN：工具链和注意事项

NCNN官方提供了onnx2ncnn转换工具，但遇到不支持的op会直接跳过或报错。我这里遇到的典型问题是YOLOv8的head部分有大量grid计算和sigmoid拼接，转换后偶尔会丢Reshape节点。解决办法是转换时加--opt参数让模型做裁剪和融合：

./onnx2ncnn yolov8n-face-sim.onnx ncnn/yolov8n-face.param ncnn/yolov8n-face.bin

转换完记得写个简单的加载验证脚本，确认param和bin能正常初始化。表情分类模型的转换同理，MobileNetV3的算子NCNN全部支持，基本没有坑。

2.4 量化权衡：什么时候需要INT8

Demo阶段FP32完全够用，但如果你后续要带到低端机上跑，就得考虑INT8量化。量化NCNN模型需要准备校准集，用几百张人脸图片跑一遍forward统计激活值分布，然后生成int8模型。我的实测感受是：检测模型量化为INT8后精度损失在2%以内，但体积从6MB降到1.8MB，速度提升约40%，值得做。不过有一个前提——你的校准集要贴近真实使用场景，否则会出现"校准图上效果好、真机上翻车"的情况。

3. Android项目搭建：CameraX+NCNN推理管线完整实现

3.1 项目基础配置和依赖

我用Android Studio Kotlin新建空工程，minSdk 26，targetSdk 34，使用CameraX的1.3.x版本。NCNN的接入方式很简单，官方release页面有对应架构的.aar，直接在build.gradle里依赖即可：

implementation 'com.tencent.ncnn:ncnn:20240820'

要注意的是，NCNN的.aar默认包含多个ABI，如果你只想打ARM64包，可以在abiFilters里指定，能大幅缩小APK体积。

权限声明在AndroidManifest.xml里：

<uses-permission android:name="android.permission.CAMERA" /> <uses-feature android:name="android.hardware.camera" android:required="true" />

3.2 实时检测主流程：ImageAnalysis里的每一帧

核心管线在CameraX的ImageAnalysis.Analyzer回调里，每一帧做四件事：格式转换、人脸检测、表情分类、结果回调。这里最需要留意的是耗时预算——CameraX的analyzer跑在独立线程里，如果一帧处理超过帧间隔就会掉帧，所以不要在analyzer里做任何不必要的对象分配。

Image analysis的resolution要设置成和模型输入接近的尺寸，我设置的是640×480，这样旋转校正后直接缩放成320×320损失很小。CameraX默认输出YUV_420_888格式，NCNN的ncnn::Mat支持从YUV直接转RGB，所以我避免把YUV先转Bitmap再转Mat——那一步会额外消耗大量CPU。

核心代码片段：

class EmotionAnalyzer( private val faceDetector: FaceDetector, private val emotionClassifier: EmotionClassifier ) : ImageAnalysis.Analyzer { override fun analyze(imageProxy: ImageProxy) { val bitmap = imageProxy.toBitmap() val faces = faceDetector.detect(bitmap) val emotions = faces.map { face -> val crop = cropFace(bitmap, face) emotionClassifier.classify(crop) } resultListener(faces, emotions) imageProxy.close() // 不close会卡死相机 } }

imageProxy.close()千万不能漏，否则CameraX会认为队列里的帧没释放，后面的帧就不会再回调，画面直接卡死。

3.3 NCNN推理封装：模型加载和提取器复用

NCNN推理有两点非常关键：一是内存复用，二是提取器复用。每次ncnn::Net的create_extractor看似轻量，但底层会创建线程池和内存管理对象，频繁创建开销很大。正确做法是把Extractor实例复用，每次推理前只设置输入和调用extract。

class FaceDetector(context: Context) { private val net = ncnn.Net().apply { opt.use_vulkan_compute = false loadParam("${context.filesDir}/yolov8n-face.param") loadModel("${context.filesDir}/yolov8n-face.bin") } private val extractor = net.createExtractor() fun detect(bitmap: Bitmap): List<FaceBox> { // 将Bitmap转为ncnn.Mat val input = matFromBitmap(bitmap) extractor.input("images", input) val output = ncnn.Mat() extractor.extract("output0", output) // 模型输出节点名称要与转换时一致 // 解析输出，应用NMS，返回人脸框 } }

Vulkan加速这里我默认关了。原因很现实：NCNN的Vulkan在部分国产ROM上存在驱动兼容问题，有时开着反而比CPU慢几倍。评测下来中端骁龙的CPU推理速度已经能接受，Vulkan留作后续优化开关。

3.4 人脸框后处理：NMS和坐标映射的坑

YOLO头输出的是大量候选框加置信度，必须做NMS（非极大值抑制）去重。NCNN版本里我手写了一个朴素NMS，只处理单类别，逻辑很简单：按置信度从高到低排序，依次取框，把与其IoU超过阈值（默认0.45）的框丢掉。

另一个大坑是坐标映射。analyzer拿到的Bitmap是旋转校正后的，但NCNN内部的Mat坐标系和图像宽高、预览View坐标系不是直接对应的，尤其前置摄像头会做镜像翻转。你需要手动计算缩放比例，把模型输出的人脸框映射回预览画布坐标。这一步最容易产生"检测没问题，框的位置却是歪的"这种诡异现象。

4. 数据处理和表情分类细节：决定识别效果的隐藏因素

4.1 人脸裁剪和增强策略

拿到人脸框后不能直接把原始像素丢给分类器。我的做法是：把人脸框往外扩展20%（防止下巴或额头被裁掉），缩放到96×96，同时保证灰度图输入——表情分类对颜色信息不敏感，转灰度还能把模型大小和推理耗时降一些。

缩放算法我选的是双线性插值。Nearest太快，但边框锯齿严重；双三次太慢。实测双线性在质量和速度上最均衡。另外要注意归一化参数要和训练时一致，MobileNetV3用的ImageNet统计量是mean=[0.485,0.456,0.406], std=[0.229,0.224,0.225]，填错的话分类结果会非常飘。

4.2 表情类别置信度平滑

单帧分类结果噪声很大，相邻两帧可能从"开心"跳到"悲伤"再跳回来，视觉体验非常差。我加了个简单的指数滑动平均（EMA），对每个类别的概率做平滑，只有连续3帧以上都稳定在某个类别才切换显示标签。代价是实时性略有延迟，但换来的是画面稳定，Demo展示效果好很多。

平滑公式很简单：

smoothedProb = alpha * currentProb + (1 - alpha) * previousSmoothedProb

alpha我取0.6，效果居中。如果觉得切换太慢就调大alpha，如果觉得太跳就调小。这种后处理逻辑虽然学术上不够"高大上"，但在产品里非常管用。

5. 常见问题与排查技巧实录

5.1 问题一：模型加载直接闪退

症状：App启动后还没进相机就崩了，logcat里能看到so库相关的错误。

排查思路：先确认ncnn的.aar是否已经被打包进APK，看Build > Analyze APK里的lib目录。其次确认模型文件路径有没有问题——NCNN的loadParam用的是相对路径，如果你把param文件放在assets目录，需要手动拷贝到filesDir下再加载，直接传assets路径是找不到的。

我后续统一写了个ModelLoader工具类，启动时先把assets里的模型拷到cacheDir，再从缓存加载，省心很多。

5.2 问题二：一直检测不到人脸

症状：画面正常预览，但界面上没有任何检测框。

排查思路：先打印模型输出维度，确认不是模型输入/输出shape问题。然后检查传入模型的Bitmap方向——CameraX输出的图像在旋转前是横向的，如果你不处理rotation直接喂给模型，人脸就横过来了，检测器当然找不到。我用了一个rotateBitmap来处理：

val matrix = Matrix() matrix.postRotate(imageProxy.imageInfo.rotationDegrees.toFloat()) val rotated = Bitmap.createBitmap(bitmap, 0, 0, bitmap.width, bitmap.height, matrix, true)

5.3 问题三：帧率只有个位数

症状：预览画面卡成PPT，滑都滑不动。

排查思路：先看耗时分布。我打了日志，发现YOLO推理只占40ms，但裁剪人脸和分类占了大头——因为我对每帧都创建了新Bitmap。实测可以复用Bitmap缓存，不要在analyze里频繁Bitmap.createBitmap。另外把ImageAnalysis的backpressure策略设为STRATEGY_KEEP_ONLY_LATEST，这样如果上一帧来不及处理，相机会自动丢弃中间帧，优先跑最新的帧，预览流畅度提升明显。

5.4 问题四：前置摄像头画面是镜像但检测框不对应

症状：人脸框和实际位置镜像相反。

解决方案：开启镜像后，检测框的x坐标也要做对应翻转。CameraX里前置摄像头默认做镜像显示，但analyzer拿到的图像不做镜像，所以UI绘制时要用水平翻转后的坐标。我在OverlayView里加了个flipX标志位来解决。

6. 最终体验和可扩展方向

这个Demo打包后APK大小约12MB，启动时间约1秒，模型加载耗时300ms左右，进入相机后第一帧不会立即显示检测框，大概等0.5秒模型进入状态，之后每帧的反应都很跟手，基本能做到"人脸出现在画面里，框和表情标签随即跟上"。

实际跑下来最强烈的体会是：模型本身不是瓶颈，工程细节才是。数据转换、坐标映射、生命周期管理、线程调优，这些环节任何一个出错都是灾难。如果你想把它做成正式产品，后面还有几条路可以走：换用更轻的人脸检测模型、给人脸框加tracking（帧间跟踪，避免每帧重复检测）、接入更多场景数据做微调、或者尝试用GPU delegate做进一步加速（前提是目标机型的驱动兼容性验证过）。

最后分享一个调参小技巧：给每个模型加一个--save-log参数，把每帧推理耗时打到sdcard上，全程让App跑5分钟，收集数据看P99延迟。别只看平均帧率，平均帧率会被乐观的帧数带偏，P99延迟才能真正反映卡顿情况。调优就盯着P99，所有优化方案做完后重测，对比数字变化，你就知道钱该花在哪了。

本文还有配套的精品资源，点击获取