在Android端部署癌症检测模型，通常使用TensorFlow Lite或ONNX Runtime Mobile等推理框架。这类应用的核心流程是采集或导入医学影像，经过裁剪、缩放、归一化等预处理，送入轻量级神经网络，输出良性或恶性的概率分布。测试工作如果只关注最终准确率，很容易遗漏移动端特有的问题，比如不同设备上的图像解码差异、量化算子的精度损失以及长时间推理导致的热降频。本文会从测试范围、数据集构建、推理验证和性能排查四个角度展开。
一、移动端癌症检测的测试范围与难点
Android端癌症检测应用并不只是模型文件的简单搬运。测试需要覆盖模型推理、图像采集、结果展示和异常处理等多个层次。常见测试维度包括功能测试、模型精度测试、性能测试、兼容性测试和合规测试。功能测试验证应用能否加载模型、处理图片并展示结果；模型精度测试评估量化后的模型在独立测试集上是否仍满足医学辅助诊断的最低要求；性能测试关注推理延迟、内存占用和耗电；兼容性测试需要在不同Android版本、屏幕尺寸和芯片平台上验证稳定性；合规测试则涉及医疗数据隐私和法规要求。忽略任何一个维度都可能导致上线后出现严重问题。
移动端测试的难点主要来自三个方面。第一是设备碎片化，不同手机的CPU、GPU、NPU性能和驱动实现差异很大，同一个TFLite模型在高端设备上可能只需20毫秒，在中低端设备上可能超过500毫秒。第二是输入数据不一致，用户拍摄的皮肤镜图片受光照、角度、焦距和背景干扰，与训练数据分布存在明显偏移。第三是模型量化带来的精度损失，为了减小包体和加速推理，移动端通常使用FP16或INT8量化模型，但量化对医学影像中的细微纹理特征可能造成破坏。测试时必须针对这些差异设计专门用例，而不是照搬服务端的验证脚本。
此外，Android系统版本和厂商定制也会引入额外变量。例如部分设备的相机预览默认输出YUV格式，转换为Bitmap时可能改变颜色空间；某些ROM对后台进程的内存限制更严格，导致推理过程被系统终止。因此，测试环境需要尽可能覆盖真实用户设备，而不是只在模拟器上验证。
二、构建可重复的测试数据集与预处理校验
模型精度测试不能依赖训练集或验证集，必须准备独立的测试集。测试集应当由临床医生或病理专家标注，包含足够数量的阳性与阴性样本，并覆盖不同图像质量、肤色、病灶大小和设备来源。对于皮肤癌检测，测试集应包含黑色素瘤、基底细胞癌、鳞状细胞癌以及良性痣等类别；对于病理切片分类，还需要考虑不同染色批次和扫描倍率。数据集应按照固定比例划分并保存清单文件，避免每次运行时随机划分导致结果不可重复。建议同时保留一份云端FP32模型推理结果作为基准，用于对比移动端量化模型的输出差异。
预处理一致性是移动端测试中最容易被忽视的问题。训练时通常会将图像缩放到224×224或299×299，并按照ImageNet统计值进行归一化。但Android端读取位图后，Bitmap默认颜色格式可能是ARGB_8888，通道顺序为R、G、B，而训练时可能使用BGR；像素值范围可能是0到255，而模型期望0到1或-1到1。任何一个环节不一致，都会导致预测结果完全错误。测试阶段应编写预处理校验用例，将同一张图片分别通过Python参考实现和Android端实现进行预处理，比较输出张量的最大误差应小于1e-5。下面代码展示了Kotlin中标准的图像预处理过程：
private fun preprocessImage(bitmap: Bitmap, inputSize: Int): ByteBuffer {
val resized = Bitmap.createScaledBitmap(bitmap, inputSize, inputSize, true)
val buffer = ByteBuffer.allocateDirect(4 * inputSize * inputSize * 3)
buffer.order(ByteOrder.nativeOrder())
val pixels = IntArray(inputSize * inputSize)
resized.getPixels(pixels, 0, inputSize, 0, 0, inputSize, inputSize)
for (pixel in pixels) {
val r = (pixel shr 16 and 0xFF) / 255.0f
val g = (pixel shr 8 and 0xFF) / 255.0f
val b = (pixel and 0xFF) / 255.0f
buffer.putFloat(r)
buffer.putFloat(g)
buffer.putFloat(b)
}
return buffer
}
如果模型使用INT8量化，预处理还需要按照量化参数进行缩放和零点校正。测试时应从模型元数据中读取输入张量的量化信息，而不是硬编码。TensorFlow Lite的Interpreter提供getInputTensor(index).quantization()方法，可以获取scale和zeroPoint。很多团队只测试FP32模型，上线时却切换到INT8模型，导致精度测试与真实运行不一致。建议在测试报告中明确标注模型类型、量化方式和输入输出细节，并将预处理脚本纳入版本管理。测试用例还应验证模型输入张量的形状、数据类型和内存对齐方式是否与实现一致，避免因ByteBuffer顺序错误导致偶发崩溃。
为了提升可重复性，可以建立一个轻量级测试数据管理模块，使用JSON清单记录每张图片的路径、真实标签、患者脱敏ID和采集设备型号。每次运行测试时从清单加载，而不是遍历文件夹。这样既能保证顺序固定，也方便追踪错误样本。对于医学影像，还需要在测试前移除所有与患者身份相关的元数据，例如DICOM头信息中的姓名和病历号。
三、推理正确性与性能评估方法
推理正确性测试的核心是比对设备端输出与参考输出。可以使用少量标注样本，在Android测试中调用模型并输出每个类别的置信度，与Python端FP32模型的输出计算余弦相似度或最大绝对误差。如果相似度低于阈值，例如0.99，需要检查量化参数、算子和输入预处理。对于分类任务，还需要统计灵敏度、特异度、阳性预测值和阴性预测值，仅看总体准确率可能掩盖对恶性样本的漏检。医学场景中漏检恶性病变的代价远高于误报良性，因此测试标准应给灵敏度设置更高权重。下面的Kotlin代码演示了如何加载TFLite模型并获取推理结果：
val modelBuffer = FileUtil.loadMappedFile(context, "cancer_model.tflite")
val interpreter = Interpreter(modelBuffer, Interpreter.Options().apply {
setNumThreads(4)
setUseNNAPI(false)
})
val inputShape = interpreter.getInputTensor(0).shape()
val outputShape = interpreter.getOutputTensor(0).shape()
val inputBuffer = preprocessImage(bitmap, inputShape[1])
val outputArray = Array(1) { FloatArray(outputShape[1]) }
interpreter.run(inputBuffer, outputArray)
val scores = outputArray[0]
val predictedIndex = scores.indices.maxByOrNull { scores[it] } ?: -1
性能评估需要在多台代表性设备上执行。推理延迟应使用SystemClock.elapsedRealtimeNanos测量，多次运行取P50、P95和最大值，避免只看平均值。内存占用可通过Debug.getMemoryInfo获取PSS，或使用Android Studio Profiler记录Java堆、Native堆和图形内存。耗电测试可以使用Battery Historian分析，重点关注持续推理场景下的电流和温度。通常要求中端设备上单张图片推理延迟低于300毫秒，内存峰值不超过200MB，机身温度不超过45摄氏度，否则用户难以接受。性能测试还应该覆盖连续推理场景，因为部分设备在长时间运行后会发生热降频，导致延迟急剧上升。
兼容性测试可借助云真机平台或本地设备矩阵执行，覆盖Android 8到最新版本、ARM64和x86模拟器、不同屏幕密度以及有无硬件加速。重点记录GPU Delegate、NNAPI Delegate和CPU执行的差异。某些SoC上的NNAPI实现存在精度问题，需要自动回退到CPU。测试用例应验证模型在不同Delegate下的结果一致性，并检查是否出现崩溃、ANR或内存泄漏。自动化脚本可以通过adb命令安装APK、启动测试Activity并抓取日志，结合JUnit报告生成可视化结果。对于依赖摄像头采集的应用，还需要在不同光照条件下测试实时预览帧的推理稳定性。
另一个容易被忽略的指标是模型加载耗时。移动端应用通常希望在启动后尽快完成模型加载，但大模型从assets或外部存储读入并初始化Interpreter可能耗时数秒。测试时应记录冷启动到首次推理完成的时间，并考虑预加载、异步初始化和模型缓存等优化手段。若模型文件较大，可以通过从APK中分离或使用动态下载的方式减小安装包体积，但必须确保下载校验和断点续传逻辑的正确性。
四、常见问题排查与优化建议
移动端癌症检测测试中常见问题包括图像方向错误、颜色空间不匹配、模型文件不完整、标签映射错位和权限缺失。Android相机返回的图像可能带有EXIF旋转信息，直接送入模型会得到错误结果，测试时应使用ExifInterface读取旋转角度并校正。部分设备输出的YUV图像在转换为Bitmap时可能出现颜色偏移，需要统一使用RGB_565或ARGB_8888格式。模型文件如果放在assets目录，加载前应校验文件大小和MD5，防止打包不完整或下载损坏。权限方面，如果应用需要调用相机，必须在AndroidManifest.xml中正确声明<uses-permission android:name="android.permission.CAMERA"/>，否则在运行时会出现SecurityException。
推理速度优化可从模型结构、量化和Delegate三方面入手。优先使用MobileNet、EfficientNet-Lite等移动端友好架构，避免使用过于庞大的ResNet或DenseNet。FP16量化通常能提升20%到50%的速度，对精度影响较小；INT8量化需要提供代表性数据集进行校准，否则精度可能大幅下降。测试时应比较FP32、FP16和INT8模型在同一测试集上的灵敏度和推理延迟，选择平衡点。若使用GPU Delegate，需注意部分旧设备不支持OpenCL，应实现自动回退逻辑。以下代码展示了一个简单的性能测量函数：
private fun measureInferenceTime(
interpreter: Interpreter,
input: ByteBuffer,
output: Array<FloatArray>,
iterations: Int
): Long {
val start = SystemClock.elapsedRealtimeNanos()
repeat(iterations) {
interpreter.run(input, output)
}
val end = SystemClock.elapsedRealtimeNanos()
return (end - start) / iterations
}
医学应用还涉及数据隐私和法规要求。测试环境中的患者影像必须脱敏处理，不得包含姓名、病历号等标识。测试数据应存储在内网或加密存储中，禁止使用公共云盘传输。发布前需要完成安全测试，包括检查APK是否包含调试日志、敏感信息是否明文存储、网络请求是否使用TLS加密。部分国家和地区要求医疗软件通过当地监管机构的审查，测试报告可作为技术文档的一部分提交。建议团队建立测试基线，每次模型更新后自动运行回归测试，发现灵敏度下降超过2个百分点时触发告警。
最后，测试代码本身也需要维护。模型输入输出名称、标签文件路径和测试样本目录都应当配置化，避免硬编码在测试用例中。使用持续集成系统在每次提交后运行模型测试和性能测试，可以尽早发现回归问题。移动端癌症检测的测试不是一次性工作，而是需要随着模型迭代、系统升级和硬件更新不断演进的过程。
Android癌症检测模型测试移动端深度学习修改时间：2026-08-19 14:54:23