Android本地TensorFlow Lite图像分类Demo全链路实践

简介：这份资源是一个面向 Android 开发者和机器学习入门者的完整工程 demo，演示如何在手机端借助 TensorFlow Lite 加载训练好的模型完成图像分类推理。适合已具备基础 Android 开发能力、希望把深度学习模型真正部署到移动设备上的学习者，用于理解模型集成、输入预处理与推理结果展示的完整链路。压缩包共 110 个文件，约 3.76MB，以 64 个 xml 布局与资源配置、4 个 java 源码文件和若干 gradle 构建脚本为主体，另含 1 个 tflite 模型文件及 9 个 bin 编译缓存，配合 png 图片资源与 properties 配置，构成可直接导入 Android Studio 的工程结构。已有 6821 人学习下载，说明其在移动端推理入门场景中具有一定参考价值。读者可获得一套可运行的分类示例工程，据此观察界面与推理代码的组织方式，替换模型与标签后快速验证自有模型，并借鉴其依赖配置与资源管理思路，减少环境搭建与集成环节的试错成本。

1. 需求切入：为什么把TensorFlow Lite图像分类放到Android本地跑

把 TensorFlow Lite 图像分类放到 Android 手机上跑，真正要解决的不是“模型能不能加载”，而是答辩现场没有网络、相机画面一直在动、千元机算力有限时，分类结果仍然要能解释。这个 Demo 适合课程设计、毕设原型和移动端算法落地练手：输入一张相机画面，输出 Top-K 类别与置信度，所有计算在本地完成。它不追求训练一个多强的模型，而是把“模型转换—预处理—推理—后处理—验收”这条链路跑通。选 TensorFlow Lite 而不是云端接口，核心原因是离线可演示、延迟可测量、隐私数据不出设备；代价是模型大小、输入尺寸和算子支持都要提前确认。下面按方案结构拆开讲。

2. 总体设计：从模型文件到Android界面的四条链路

这套 Demo 看起来只是“打开相机、拍一张、显示类别”，拆开之后其实是四条链路并行：模型链路负责把训练产物变成.tflite文件，相机链路负责拿到可解码的画面，推理链路负责把画面变成分类分数，展示链路负责把分数翻译成人能读的标签和耗时。四条链路任何一条断开，Demo 都会表现成“相机黑屏”“一直加载”“结果永远是同一类”这类看起来像玄学的问题。方案设计阶段先把边界划清楚，后面调参才不会在一堆变量里打转。

我一般会把 Android 端分成五个模块：采集、预处理、推理、后处理、展示。采集只关心拿到ImageProxy或Bitmap，预处理只关心把画面变成模型输入张量，推理只关心调用Interpreter，后处理只关心 Top-K 和标签映射，展示只关心把结果丢回主线程。每个模块之间用明确的数据对象传递，不让相机回调直接碰模型，也不让 UI 线程做归一化。这样做的直接好处是：模型换输入尺寸时只改预处理参数，换标签文件时只改后处理，排查问题时能快速定位是哪一段出了偏差。

2.1 模块划分与数据流

先看模块职责表。这张表不是摆设，后面写代码时每个类的输入输出都按它对齐，能减少“相机回调里顺手做了 resize，预处理里又 resize 一次”的重复开销。

数据流可以这样描述：相机以固定间隔产出一帧，采集模块把ImageProxy转成Bitmap后关闭帧；预处理模块按模型训练时的规则缩放并归一化，写入直接缓冲区；推理模块调用Interpreter.run，拿到形状为[1, numClasses]的输出；后处理模块排序取前 3，映射到labels.txt中的类别名；展示模块把“类别 + 置信度 + 推理耗时”渲染到界面。整个链路里最容易被忽略的是“关闭帧”和“结果节流”，前者不处理会很快卡死相机，后者不处理会让 UI 线程被高频结果淹没。

这里有一个设计取舍：Demo 阶段不必上多模型并发，也不建议一上来就做视频流逐帧分类。更稳妥的做法是“按时间间隔取帧”，比如 300 毫秒推理一次，中间帧直接关闭。这样在千元机上也能看到连续结果，又不会因为每帧都跑模型导致发热和掉帧。等链路跑通之后，再考虑把间隔调小，或者用“上一帧结果返回后再取下一帧”的背压方式。

2.2 模型准备与TensorFlow Lite转换

模型准备阶段要确认三件事：输入形状、输入归一化方式、输出含义。输入形状通常是[1, H, W, 3]，但 H 和 W 必须和 Android 端预处理保持一致；归一化可能是0~1、-1~1或 ImageNet 均值方差，训练脚本怎么写，Android 端就怎么抄；输出可能是 logits，也可能是 softmax 后的概率，后处理要对应。很多“模型在电脑上准、手机上乱”的问题，根源不是 TensorFlow Lite 转换坏了，而是这三件事在转换后被重新猜了一遍。

下面是一个转换脚本的骨架，重点看参数，不要照抄版本号。工程里把 TensorFlow 版本统一放在虚拟环境里管理，脚本只负责转换和校验。

import tensorflow as tf # 从 SavedModel 目录加载，避免在脚本里重新拼网络结构 converter = tf.lite.TFLiteConverter.from_saved_model("saved_model_dir") # 默认量化：减小模型体积，但要用代表数据集校准，不能直接拍脑袋开 converter.optimizations = [tf.lite.Optimize.DEFAULT] # 先只启用 TFLite 内置算子；遇到不支持的算子再加 SELECT_TF_OPS converter.target_spec.supported_ops = [ tf.lite.OpsSet.TFLITE_BUILTINS, tf.lite.OpsSet.SELECT_TF_OPS, ] # 输入输出类型要和 Android 端 ByteBuffer 的写入方式一致 converter.inference_input_type = tf.float32 converter.inference_output_type = tf.float32 tflite_model = converter.convert() with open("image_classifier.tflite", "wb") as f: f.write(tflite_model)

这段脚本的逻辑很直接：from_saved_model保证转换的是训练产出的完整计算图；Optimize.DEFAULT打开默认量化策略，适合移动端体积敏感的场景；TFLITE_BUILTINS是首选算子集，SELECT_TF_OPS是兜底，但会增加包体和初始化时间，能不用就不用；inference_input_type和inference_output_type设成float32，对应 Android 端用ByteBuffer.putFloat写输入、用FloatArray接输出。如果改成uint8输入，Android 端预处理就要同步改成 0~255 的字节写入，不能只改一半。

转换完成后不要只看文件生没生成，至少做一次桌面端校验：用同一张测试图，分别跑原始模型和.tflite模型，比较 Top-1 是否一致、置信度差距是否在可接受范围。这个步骤相当于给后面省后悔药，因为一旦 Android 端结果不对，你可以快速判断是转换阶段掉点，还是预处理阶段写错。

2.3 工程目录与依赖配置

Android 工程按“模型、标签、推理封装、界面”四块放，目录不需要花哨，但要让人一眼能找到关键文件。常见组织方式是：assets/放.tflite和labels.txt，ml/或inference/放ImageClassifier封装，ui/放相机预览和结果展示，utils/放 YUV 转换、文件读取、计时工具。模型文件不要放res/raw再绕一遍输入流，assets配合AssetManager更容易按名称切换模型。

依赖配置里最容易踩的坑是“版本写死在模块里，换机器就冲突”。更稳妥的做法是根目录统一管理版本变量，模块只引用变量。下面是一个 Gradle 配置示例，版本号用变量占位，具体值按工程锁定的依赖清单填。

// 模块级 build.gradle.kts android { // 相机和 TFLite 都不需要额外 NDK 配置，先保持最小构建 compileSdk = rootProject.extra["compileSdkVersion"] as Int } dependencies { // CameraX：采集与分析分开依赖，便于单独替换 implementation("androidx.camera:camera-core:${rootProject.extra["cameraXVersion"]}") implementation("androidx.camera:camera-camera2:${rootProject.extra["cameraXVersion"]}") implementation("androidx.camera:camera-lifecycle:${rootProject.extra["cameraXVersion"]}") implementation("androidx.camera:camera-view:${rootProject.extra["cameraXVersion"]}") // TensorFlow Lite：解释器与支持库分开，按需裁剪 implementation("org.tensorflow:tensorflow-lite:${rootProject.extra["tfliteVersion"]}") implementation("org.tensorflow:tensorflow-lite-support:${rootProject.extra["tfliteSupportVersion"]}") }

配置说明：CameraX 的camera-core、camera-camera2、camera-lifecycle、camera-view是相机预览与分析的基础组合，少一个都可能在真机上出问题；TensorFlow Lite 的解释器依赖是必须的，support 库可以用也可以不用，用了会方便一些图像处理，但不要把预处理全交给它，否则参数不透明。版本变量统一放根工程，模块里不写死，换环境时只改一处。构建完成后先跑一个空 Activity，确认依赖能下载、能打包，再往里加模型，别等相机和推理都写完才发现依赖冲突。

3. Android端实现：相机采集、预处理与TFLite推理的三段式落地

实现阶段按“先能拿到图、再能跑通模型、最后能显示结果”的顺序推进，不要一上来就把相机、预处理、推理、UI 全写在一个 Activity 里。更稳的拆法是三段：采集段只负责产出一张可用的Bitmap，预处理段只负责把它变成模型输入，推理段只负责调用Interpreter并返回分数。三段之间通过明确的函数签名连接，任何一段出问题都能单独替换和测试。下面按这个顺序落地，代码用 Kotlin 写，关键参数在注释里标清楚。

3.1 相机采集与帧节流

相机采集用 CameraX 的ImageAnalysis，因为它比直接写 Camera2 少很多样板代码，又比PreviewView截图更可控。关键配置有三个：背压策略设为STRATEGY_KEEP_ONLY_LATEST，保证不会积压旧帧；输出格式设为RGBA_8888，省掉自己写 YUV 转 RGB 的代码；分析器里用时间戳做节流，避免每帧都跑模型。下面这段代码是分析器的骨架。

private val analysis = ImageAnalysis.Builder() // 只保留最新帧，防止推理慢时队列越积越长 .setBackpressureStrategy(ImageAnalysis.STRATEGY_KEEP_ONLY_LATEST) // 直接输出 RGBA，减少手写 YUV 转换的出错面 .setOutputImageFormat(ImageAnalysis.OUTPUT_IMAGE_FORMAT_RGBA_8888) .build() analysis.setAnalyzer(cameraExecutor) { imageProxy -> val now = System.currentTimeMillis() // 300ms 节流：Demo 阶段先保证界面有反馈，不追求逐帧 if (now - lastInferAt < 300L) { imageProxy.close() return@setAnalyzer } try { val bitmap = imageProxy.toBitmap() lastInferAt = now val result = classifier.classify(bitmap) runOnUiThread { renderResult(result) } } catch (e: Exception) { // 采集或推理失败时不要让分析器卡死，记录后继续下一帧 Log.e("ImageAnalysis", "classify failed", e) } finally { imageProxy.close() } }

这段代码的逻辑是：ImageAnalysis.Builder先定背压和输出格式，setAnalyzer里做节流判断，未到间隔直接关闭帧并返回；到了间隔就把ImageProxy转成Bitmap，调用分类器，结果切回主线程渲染；无论成功失败，finally里都关闭帧。参数说明：STRATEGY_KEEP_ONLY_LATEST适合实时预览场景，避免旧帧拖慢；OUTPUT_IMAGE_FORMAT_RGBA_8888让toBitmap()直接可用，但会增加一点内存拷贝；300L是节流间隔，千元机上可以先用 300~500 毫秒，旗舰机再往下调。注意imageProxy.close()必须执行，否则相机会很快停止出帧，这是最常见的翻车点之一。

3.2 图像预处理与归一化参数

预处理是整套链路里最容易被“凭感觉”改坏的一段。模型训练时怎么缩放、怎么裁剪、通道顺序是 RGB 还是 BGR、归一化是0~1还是-1~1，Android 端必须逐项对齐。下面这段预处理代码假设模型输入是[1, 224, 224, 3]、RGB 通道、归一化到0~1，用直接缓冲区写入浮点数。

private fun preprocess(bitmap: Bitmap, size: Int): ByteBuffer { // 先缩放到模型输入尺寸；如果训练用的是中心裁剪，这里要改成先裁剪再缩放 val resized = Bitmap.createScaledBitmap(bitmap, size, size, true) // 4 字节 float * 高 * 宽 * 3 通道 val buffer = ByteBuffer.allocateDirect(4 * size * size * 3) buffer.order(ByteOrder.nativeOrder()) val pixels = IntArray(size * size) resized.getPixels(pixels, 0, size, 0, 0, size, size) for (pixel in pixels) { val r = (pixel shr 16 and 0xFF) / 255f val g = (pixel shr 8 and 0xFF) / 255f val b = (pixel and 0xFF) / 255f // 通道顺序必须是 RGB；如果训练用 BGR，这里要交换 r 和 b buffer.putFloat(r) buffer.putFloat(g) buffer.putFloat(b) } buffer.rewind() return buffer }

逻辑说明：createScaledBitmap做尺寸对齐，allocateDirect分配直接缓冲区，getPixels一次性取出像素，循环里按 RGB 顺序写入0~1浮点值，最后rewind让读取位置回到开头。参数说明：size必须等于模型输入张量的高和宽；4 * size * size * 3是浮点输入的内存占用；/ 255f是归一化因子，如果训练用的是(x - mean) / std，这里要换成对应计算，不能只改一半。提示：预处理参数必须和训练脚本一致，别在 Android 端“凭感觉”改归一化。

如果模型输入是uint8，这段代码要改成buffer.put((pixel shr 16 and 0xFF).toByte())之类的写法，并且ByteBuffer的容量按 1 字节算。预处理写完先别接相机，拿一张固定的测试图跑一次，把输入张量的前几个值打印出来，和桌面端脚本的预处理结果对比，能省掉后面大量“模型不准”的排查时间。

3.3 Interpreter调用与后处理

推理封装建议单独一个类，构造时加载模型和标签，对外只暴露classify(bitmap)。Interpreter的配置项不多，但线程数和 Delegate 的选择会直接影响体验；Demo 阶段先走 CPU 多线程，保证所有设备都有可用路径，再按设备能力决定要不要挂 GPU 或 NNAPI。下面是一个最小封装。

class ImageClassifier( context: Context, modelName: String = "image_classifier.tflite", labelName: String = "labels.txt", private val inputSize: Int = 224, threadCount: Int = 4 ) { private val labels: List<String> = loadLabels(context, labelName) private val interpreter: Interpreter init { val modelBuffer = loadModelFile(context, modelName) val options = Interpreter.Options().apply { // CPU 多线程是兜底路径，先保证能跑，再谈加速后端 setNumThreads(threadCount) } interpreter = Interpreter(modelBuffer, options) interpreter.allocateTensors() } fun classify(bitmap: Bitmap): List<Pair<String, Float>> { val input = preprocess(bitmap, inputSize) val output = Array(1) { FloatArray(labels.size) } interpreter.run(input, output) return postprocess(output[0], labels, topK = 3) } }

构造部分的逻辑是：从assets读模型到MappedByteBuffer，配置Interpreter.Options，设置线程数，创建解释器并分配张量。参数说明：inputSize必须和模型输入一致；threadCount在千元机上不要盲目拉到 8，4 线程通常够用，过高会增加调度开销；labels.size要和模型输出维度一致，不一致时先检查标签文件行数和模型输出形状。classify里先预处理，再准备输出数组，调用run，最后后处理取 Top-3。

后处理不要只写一个max()就完事。输出可能是 logits，需要 softmax；也可能是概率，直接排序即可；标签文件可能带空行或分隔符，读取时要过滤。下面这段后处理假设输出已经是概率，并且标签数量与输出维度一致。

private fun postprocess( scores: FloatArray, labels: List<String>, topK: Int ): List<Pair<String, Float>> { return scores.indices .sortedByDescending { scores[it] } .take(topK) .map { index -> // 标签越界时给一个可读占位，避免直接崩溃 val name = labels.getOrElse(index) { "class_$index" } name to scores[index] } }

逻辑说明：按分数降序排序，取前topK，再用索引映射标签。参数说明：topK在 Demo 里取 3 就够展示；如果输出是 logits，要先做 softmax 再排序，否则置信度不可读；labels.getOrElse是保护，不是正常路径，出现class_占位就说明标签文件和模型输出维度对不上。到这一步，采集、预处理、推理、后处理已经串起来了，接下来才是性能和体验的取舍。

4. 性能与体验优化：让图像分类Demo在千元机上跑顺的四个取舍

性能优化不要一上来就堆 Delegate，先看瓶颈在哪。图像分类 Demo 的耗时通常分布在四段：相机格式转换、Bitmap 缩放、输入张量写入、Interpreter.run。前两段是 Java/Kotlin 层的内存操作，后两段跟模型和线程配置有关。更有效的顺序是：先把输入尺寸降下来，再把帧率节流做好，最后才考虑 GPU 或 NNAPI 这类加速后端。顺序反了，容易出现“挂了 GPU 反而更慢”的尴尬，因为小模型在部分设备上拷贝开销比计算还大。

4.1 线程数与加速后端的选择

Interpreter.Options.setNumThreads是最容易调的参数，但也不是越大越好。CPU 推理时，线程数超过大核数量后，调度开销会抵消收益；不同设备的核数不一样，Demo 里给一个保守值，再在设置页留一个可调项，比写死更实用。加速后端方面，GPU Delegate 适合卷积占比较高的模型，NNAPI 适合系统版本较新、算子支持较全的设备，但两者都有兼容性差异。我一般会做“能力探测 + 失败回退”：先尝试创建加速后端，失败就退回 CPU 多线程，界面不报错，只记录日志。

fun createInterpreter(modelBuffer: MappedByteBuffer): Interpreter { val cpuOptions = Interpreter.Options().apply { // 保守线程数，避免低端机过度调度 setNumThreads(4) } return try { // 这里只示意流程：具体加速后端按设备能力判断后再挂载 val options = Interpreter.Options().apply { setNumThreads(4) } Interpreter(modelBuffer, options) } catch (e: Exception) { // 加速路径失败时回退 CPU，保证 Demo 还能演示 Log.w("TFLite", "accelerator unavailable, fallback to CPU", e) Interpreter(modelBuffer, cpuOptions) } }

这段代码的重点不是某个具体 API，而是回退结构：先准备 CPU 配置，再尝试带加速后端的配置，异常时回到 CPU。参数说明：setNumThreads(4)是起点，不是标准答案；加速后端不要在所有机型上默认开启，最好按设备白名单或运行时探测决定；回退时不要在 UI 上弹一堆错误，记录日志即可，否则答辩现场会被弹窗打断。需要提醒的是，部分设备上 GPU 首次初始化时间较长，如果只在启动时测一次耗时，容易误判。

4.2 输入尺寸与帧率的取舍

输入尺寸直接决定预处理和推理的计算量。224×224是常见起点，降到192×192或160×160能明显减少耗时，但精度会掉，尤其是细粒度分类。Demo 阶段可以准备两档：演示档用224，流畅档用160或192，在设置里切换。帧率方面，不要追求“每帧都推理”，而是按“结果可用”来定间隔。分类结果本来就不需要 60fps，300~500 毫秒一次足够让人看到变化。

这张表不是精确 benchmark，而是取舍方向：尺寸每降一档，耗时下降，但别指望精度不掉。更稳的做法是固定一个尺寸做验收，另一个尺寸只作为体验选项，不要在同一份验收数据里混用。帧率节流放在分析器里做，别在推理线程里sleep，否则相机会以为分析器卡住。还有一点，Bitmap.createScaledBitmap每次都会分配新对象，高频调用时可以考虑复用Bitmap或改用ImageProcessor，但 Demo 阶段先保证逻辑正确，再谈对象复用。

4.3 内存与生命周期管理

移动端图像分类常见的内存问题有三个：ImageProxy没关闭、Bitmap频繁创建导致 GC 抖动、Interpreter在页面销毁后还在跑。第一个问题在采集段用finally关闭就能解决；第二个问题可以通过降低推理频率、复用输出数组、避免在循环里创建大对象来缓解；第三个问题要把Interpreter的生命周期绑到页面或 ViewModel，在onDestroy里调用interpreter.close()，并把分析器解绑。相机资源也要在生命周期回调里释放，否则切后台再回来可能黑屏。

override fun onDestroy() { super.onDestroy() // 先停分析器，再关解释器，顺序反了可能还有帧进来 analysis.clearAnalyzer() cameraExecutor.shutdown() classifier.close() }

这段代码说明的是释放顺序：先清分析器，停止新帧进入；再关线程池；最后关解释器。参数说明：clearAnalyzer()要在相机解绑前后按实际生命周期调用；cameraExecutor不要用主线程池；classifier.close()内部调用interpreter.close()，并置空引用。Demo 里很容易忽略这一步，结果连续进出页面几次后内存上涨，排查起来像黑匣子。把释放顺序写进验收清单，比事后猜更省时间。

5. 常见问题与排查：图像分类Demo最容易翻车的五个点

带课设时最怕的不是模型不收敛，而是 Demo 在答辩前一晚翻车：相机有画面、按钮能点、结果却永远显示同一类。图像分类链路的变量太多，模型、预处理、相机格式、标签文件、线程配置任何一处偏了，表现都差不多。下面五个点是最常见的踩坑位置，每条按“现象—原因—解决”写，照着排查能少走很多弯路。

现象：不管拍什么，Top-1 永远是同一个类别，置信度还很高。原因通常是预处理和训练不一致，比如训练用0~1归一化，Android 端写了0~255；训练用 RGB，端上按 BGR 写；训练做中心裁剪，端上直接拉伸。解决方式是把预处理参数逐项列成表，和训练脚本对照：输入尺寸、通道顺序、归一化公式、裁剪方式、数据类型。最有效的验证是拿一张固定测试图，在桌面端和 Android 端各打印输入张量的前 10 个值，对不上就先修预处理，别急着换模型。

现象：预览正常，点开始分类后相机卡住或直接黑屏。原因多半是ImageProxy没有关闭，或者分析器里做了耗时操作导致背压堆积。解决方式是把imageProxy.close()放进finally，并检查是否在分析器里同步跑了推理；如果推理耗时超过帧间隔，就加节流或把推理放到单独线程，分析器只负责取帧和投递。还需要检查ImageAnalysis是否绑定到了正确的生命周期，页面切后台后有没有解绑。

现象：模拟器上结果正常，真机上特别慢，甚至 ANR。原因通常是输入尺寸太大、线程数设置过高、每帧都做Bitmap缩放，或者在后处理里做了大量字符串拼接。解决方式是先降输入尺寸或加大节流间隔，确认耗时下降再继续；把耗时拆成“预处理、推理、后处理”三段打点，看瓶颈在哪；线程数从 4 开始试，不要一上来就 8；UI 刷新只传 Top-3，不要在主线程做排序和标签查找。

现象：模型转换成功，但 Android 端加载时报算子不支持或输出形状不对。原因可能是转换时开了SELECT_TF_OPS但端上缺少对应支持，或者模型输入输出类型和代码里的ByteBuffer、FloatArray不匹配。解决方式是先用 TFLite 解释器在桌面端跑一遍转换后的模型，确认输入输出形状和类型；端上加载失败时看完整异常，不要只看最后一行；如果必须用SELECT_TF_OPS，要接受包体和初始化时间增加，并在验收里单独记录首次加载耗时。

现象：标签和结果对不上，比如明明是猫却显示狗。原因通常是labels.txt的行数、顺序或空行处理和模型输出不一致，也可能是后处理忘了做 softmax，把 logits 当概率排序。解决方式是打印模型输出维度、标签文件行数、前三个索引和对应标签；检查标签文件是否有多余空行、是否带序号前缀；如果输出是 logits，后处理先做 softmax 再排序。这个问题的血泪经验是：标签文件不要手改顺序，改完必须重新跑一遍固定测试图。

6. 验收与答辩：用一张指标表把图像分类Demo讲清楚

验收不要只说“能跑”，要把“能跑到什么程度”量化。我一般会准备一张小表，答辩时直接展示：功能项、测试方法、合格线。功能项覆盖模型加载、相机采集、Top-3 输出、离线运行；测试方法写清楚用固定测试图还是真机连续拍；合格线不要写“越快越好”，而是写具体阈值，比如首次加载不超过几秒、单帧推理在目标设备上不超过多少毫秒、连续运行十分钟不崩溃。这样老师或评审问“你这个 Demo 到什么程度”，你有数据可答，而不是只说“我试了没问题”。

答辩时还有一个技巧：主动讲清楚“哪些没做”。比如没有做训练、没有做多模型切换、没有做逐帧视频分类，这些不是缺陷，而是边界。评审更愿意听到“我把输入尺寸、线程数、Delegate 回退做成可配置，验收数据在这张表里”，而不是听“我的模型很准”。如果时间允许，现场演示一次固定测试图和一次真相机拍摄，固定图证明链路正确，真机证明可演示，两个场景分开讲，比混在一起更有说服力。

从那以后我每次交付图像分类 Demo，都强制先跑一遍预处理一致性检查，再谈线程数和 Delegate。希望帮到你。这套 Demo 的工程结构、模型转换脚本和验收表我整理成了一份可参考的下载资源，按页面说明获取即可。

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