NXP i.MX平台Android AI应用开发：从NNAPI到专用Delegate的性能优化实战

1. 项目概述与核心价值

在嵌入式AI应用开发中，我们常常面临一个核心矛盾：模型越来越复杂，但设备的计算资源却非常有限。尤其是在像NXP i.MX 8M Plus或i.MX 95这类面向边缘计算的处理器上，虽然集成了专用的神经网络处理单元（NPU），但如何让Android应用真正“榨干”这些硬件的性能，却是一个不小的挑战。Android系统自带的NNAPI（Neural Networks API）本意是提供一个统一的硬件加速接口，但在实际使用中，你会发现它更像一个“和事佬”，为了兼容各种不同的硬件和推理引擎，有时不得不做出性能上的妥协，导致NPU的算力无法被完全利用。

这正是NXP提供专用Delegate（如VX Delegate和Neutron Delegate）的价值所在。它们绕过了NNAPI的通用抽象层，直接与i.MX平台上的NPU驱动对话，实现了算子与硬件能力的最优匹配。我过去在多个基于i.MX的智能摄像头和工业质检设备项目中，从依赖纯CPU推理到逐步接入NNAPI，再到最终采用专用Delegate，亲眼见证了推理延迟从几百毫秒下降到个位数毫秒的飞跃。这个过程不仅仅是替换一个库那么简单，它涉及到对Android ML栈的深入理解、模型格式的适配、以及构建流程的调整。

本文将基于NXP官方的《i.MX Machine Learning User Guide for Android》文档，结合我个人的实战经验，为你拆解从NNAPI到专用Delegate的完整迁移路径。我会重点讲解三个核心环节：如何运行预置的Demo应用来验证硬件加速效果；如何在你自己的Android应用中集成NXP的TFLite库和Delegate；以及如何从源码构建整个环境，以便进行深度定制和问题排查。无论你是刚开始接触i.MX平台AI开发的工程师，还是正在为性能瓶颈寻找突破方案的资深开发者，相信这些从实际项目中沉淀下来的细节和“坑点”都能给你带来直接的帮助。

2. 核心思路解析：为什么NNAPI不够，而需要专用Delegate？

在深入实操之前，我们必须先理清一个根本问题：既然Android已经有了NNAPI这个“标准答案”，为什么我们还要折腾厂商提供的专用Delegate？这背后的原因，直接决定了我们技术方案的选择和性能优化的上限。

2.1 NNAPI的设计哲学与性能折衷

NNAPI的诞生是为了解决Android生态中AI硬件碎片化的问题。它试图在应用层（如TensorFlow Lite、ONNX Runtime）和底层五花八门的硬件加速器（高通Hexagon、联发科APU、以及像NXP NPU这样的第三方IP）之间，建立一个统一的抽象层。开发者理论上只需要面向NNAPI编程，就能自动调用设备上可用的最强算力。

然而，这种“大一统”的设计带来了不可避免的折衷。NNAPI需要定义一套通用的算子（Operation）集合，这套集合必须是所有声称支持NNAPI的硬件厂商的交集。问题在于，各家NPU的指令集架构、内存布局、对量化方式的支持（比如是int8对称量化还是uint8非对称量化）都存在差异。NNAPI规范为了最大化兼容性，有时会省略一些硬件原生支持的高效算子，或者无法以最优方式映射某些计算图。

在我的项目经历中，一个典型的例子是卷积算子（Conv2D）与激活函数（如ReLU）的融合。许多NPU在硬件层面支持“Conv2D+ReLU”作为一个原子操作执行，这能显著减少数据搬运和启动开销。但早期某些版本的NNAPI驱动可能并未将此融合模式暴露给上层，导致TFLite通过NNAPI Delegate下发任务时，NPU只执行了卷积，ReLU却被回退到CPU计算，产生了不必要的同步和性能损耗。

2.2 专用Delegate的“直连”优势

与NNAPI的“翻译官”角色不同，像VX Delegate（用于i.MX 8M Plus的Vivante NPU）和Neutron Delegate（用于i.MX 95的Neutron NPU）这类专用Delegate，扮演的是“专属司机”的角色。它们由芯片原厂深度定制，与自家NPU的驱动栈（如TIM-VX、Neutron Driver）紧密耦合。

这种“直连”模式带来了几个关键优势：

1. 算子对齐精准：Delegate清楚知道NPU支持的所有算子及其变体，能实现近乎一比一的图优化和映射，避免了NNAPI可能发生的算子回退（Fallback）。
2. 内存优化深入：可以直接利用NPU的特定内存架构，比如使用零拷贝机制，让输入/输出张量直接在NPU的本地内存或共享内存中处理，省去了在CPU和NPU之间来回拷贝数据的开销。
3. 量化支持原生：对于模型量化，专用Delegate能更好地匹配硬件的量化特性。例如，文档中提到i.MX 95的Neutron NPU只支持对称的int8量化，而MobileNet V1的量化模型可能是uint8。Neutron Delegate配套的neutron-converter工具就提供了--convert-inputs-uint8-to-int8这样的参数来完成格式转换，这个细节在通用的NNAPI流程里可能就需要更复杂的预处理。

注意：选择专用Delegate并不意味着完全抛弃NNAPI。一个稳健的策略是采用“专用Delegate优先，NNAPI/CPU兜底”的混合模式。在创建TFLite解释器（Interpreter）时，先尝试加载专用Delegate，如果某些算子不被支持，则通过设置setUseXNNPACK(true)让XNNPACK（一个高度优化的CPU后端）来接管这些算子，从而保证模型的可用性。

2.3 i.MX平台Delegate选型指南

面对i.MX不同型号的处理器，你需要准确选择对应的Delegate：

• i.MX 8M Plus：搭载Vivante NPU。你需要使用的是VX Delegate(libvx_delegate.so)。它的底层依赖于TIM-VX（Vivante的神经网络推理引擎）和Vulkan驱动。在Android系统中，它通常预装在/vendor/lib64/目录下。
• i.MX 95：搭载新一代的Neutron NPU。你需要使用的是Neutron Delegate(libneutron_delegate.so)。它依赖于libNeutronDriver.so。一个关键区别是：在i.MX 95上，GPU加速（通过TFLite的GPU Delegate）也是一个重要选项，它支持OpenCL和OpenGL两种后端，你可以通过--gpu_backend=cl或gl参数来指定。

理解这些底层差异，能帮助你在遇到问题时快速定位。例如，如果Delegate初始化失败，你首先应该检查的不是应用代码，而是目标设备的/vendor/lib64/目录下是否存在对应的.so文件，以及应用是否有权限加载它们（这涉及到SELinux策略，我们会在第6章详细讨论）。

3. 实战起点：运行预置的ML应用

理论讲得再多，不如实际跑一遍看看效果。NXP在预编译的Android镜像中提供了三个开箱即用的机器学习应用，这是验证硬件环境和熟悉工具链最快的方式。我们以最经典的图像分类任务为例。

3.1 环境准备与资源获取

在开始之前，你需要准备好以下“食材”：

1. 硬件：i.MX 8M Plus或i.MX 95评估板，并已刷入NXP提供的Android BSP镜像（文档基于Android 16.0.0_1.0.0）。
2. 主机工具：在开发电脑上安装好ADB（Android Debug Bridge）。这是与板子通信的“生命线”。通过它，我们可以推送文件、执行Shell命令、查看日志。
3. 模型与数据：下载测试用的模型和图片。
   • 模型：从TensorFlow官网下载MobileNet V1的浮点和量化版本。对于NPU推理，我们通常使用量化模型（.tflite）以获得更快的速度和更低的内存占用。
   • 标签文件：ImageNetLabels.txt，包含1000个ImageNet类别名称。
   • 测试图片：例如经典的grace_hopper.bmp（一位海军军官的黑白照片）。
4. i.MX 95专属工具：如果你使用的是i.MX 95平台，还需要eIQ Toolkit。因为Neutron NPU需要特定的模型格式（Neutron Graph），你需要使用工具包中的neutron-converter将标准的TFLite模型进行转换。

实操心得：建议在开发主机上建立一个清晰的工作目录，例如~/imx_ml_demo，把下载的模型、标签、脚本都放在这里。使用ADB时，也尽量使用绝对路径，避免因Shell环境不同导致的“文件找不到”错误。

3.2 运行Label Image应用

LabelImage是一个基础的图像分类演示应用。我们将通过ADB命令来启动它，并通过logcat抓取日志查看结果。

步骤一：推送文件到设备

adb push mobilenet_v1_1.0_224_quant.tflite /data/local/tmp/ adb push grace_hopper.bmp /data/local/tmp/ adb push ImageNetLabels.txt /data/local/tmp/labels.txt

这里将文件推送到/data/local/tmp/目录是因为该目录通常具有可执行权限，方便测试。

步骤二：在CPU上运行基准测试首先，我们清除旧的日志，然后启动应用并传入模型、标签和图片路径：

adb shell logcat -c adb shell am start -S -n org.tensorflow.lite.label_image/.LabelImageActivity \ --es graph "/data/local/tmp/mobilenet_v1_1.0_224_quant.tflite" \ --es label "/data/local/tmp/labels.txt" \ --es image "/data/local/tmp/grace_hopper.bmp" adb shell logcat | grep "LabelImage"

这个操作会在CPU上运行推理。在日志中，你会看到推理时间（如average time: 15.6 ms）和Top-5的分类结果。记录下这个时间，作为后续对比的基线。

步骤三：在NPU上运行（以i.MX 8M Plus为例）关键来了，通过--es ext_delegate参数指定NPU委托库的路径：

adb shell logcat -c adb shell am start -S -n org.tensorflow.lite.label_image/.LabelImageActivity \ --es graph "/data/local/tmp/mobilenet_v1_1.0_224_quant.tflite" \ --es label "/data/local/tmp/labels.txt" \ --es image "/data/local/tmp/grace_hopper.bmp" \ --es ext_delegate "/vendor/lib64/libvx_delegate.so" adb shell logcat | grep "LabelImage"

对比观察：此时，日志中应该会显示EXTERNAL delegate created.以及类似VX delegate: X nodes delegated out of Y nodes的信息，表明有部分或全部算子被委托给了NPU。最直观的是average time，应该比CPU推理时有显著下降。

步骤四：i.MX 95的特殊处理对于i.MX 95，你需要先进行模型转换。因为Neutron NPU对量化格式有严格要求（对称int8），而下载的量化模型可能是非对称uint8。

# 在开发主机上使用eIQ Toolkit中的转换器 ./neutron-converter --target imx95 \ --input mobilenet_v1_1.0_224_quant.tflite \ --output mobilenet_v1_1.0_224_quant_neutron.tflite \ --convert-inputs-uint8-to-int8 \ --convert-outputs-uint8-to-int8

转换完成后，将新模型推送到设备，并使用Neutron Delegate运行：

adb push mobilenet_v1_1.0_224_quant_neutron.tflite /data/local/tmp/ adb shell am start -S -n org.tensorflow.lite.label_image/.LabelImageActivity \ --es graph "/data/local/tmp/mobilenet_v1_1.0_224_quant_neutron.tflite" \ --es label "/data/local/tmp/labels.txt" \ --es image "/data/local/tmp/grace_hopper.bmp" \ --es ext_delegate "/vendor/lib64/libneutron_delegate.so"

3.3 使用Benchmark Model进行量化评估

LabelImage给了我们一个直观感受，但要科学地对比不同后端（CPU、NPU、GPU）的性能差异，就需要用到benchmark_model工具。它可以统计平均推理延迟、初始化时间、内存占用等关键指标。

运行CPU基准测试：

adb shell am start -S -n org.tensorflow.lite.benchmark/.BenchmarkModelActivity \ --es args '"--graph=/data/local/tmp/mobilenet_v1_1.0_224_quant.tflite --num_threads=1"'

这里num_threads=1是因为Android应用进程默认被限制在单个核心上运行，多线程对性能提升帮助不大。这是一个非常重要的发现，意味着如果你想在Android App中获取最佳的多核CPU性能，可能需要通过JNI调用C++版本的benchmark工具，或者将计算密集部分放到Native层处理。

运行NPU基准测试： 对于i.MX 8M Plus，命令如下：

adb shell am start -S -n org.tensorflow.lite.benchmark/.BenchmarkModelActivity \ --es args '"--graph=/data/local/tmp/mobilenet_v1_1.0_224_quant.tflite --external_delegate_path=/vendor/lib64/libvx_delegate.so"'

对于i.MX 95，记得使用转换后的模型：

adb shell am start -S -n org.tensorflow.lite.benchmark/.BenchmarkModelActivity \ --es args '"--graph=/data/local/tmp/mobilenet_v1_1.0_224_quant_neutron.tflite --external_delegate_path=/vendor/lib64/libneutron_delegate.so"'

运行GPU基准测试（仅i.MX 95）： i.MX 95的GPU支持通过TFLite GPU Delegate进行加速，并且可以选择OpenCL或OpenGL后端：

# 使用OpenCL后端 adb shell am start -S -n org.tensorflow.lite.benchmark/.BenchmarkModelActivity \ --es args '"--graph=/data/local/tmp/mobilenet_v1_1.0_224_quant.tflite --use_gpu=true --gpu_backend=cl"' # 使用OpenGL后端 adb shell am start -S -n org.tensorflow.lite.benchmark/.BenchmarkModelActivity \ --es args '"--graph=/data/local/tmp/mobilenet_v1_1.0_224_quant.tflite --use_gpu=true --gpu_backend=gl"'

在输出的日志中，重点关注Inference (avg):这一行后面的数值（单位是微秒）。对比CPU、NPU和GPU的数据，你就能清晰地看到硬件加速带来的收益。通常，NPU在能效比和确定性延迟上会优于GPU。

3.4 体验TFLite Camera Demo

这是一个带有图形界面的实时摄像头分类Demo。在设备上找到并打开“TFLite Camera Demo”应用，它会调用摄像头进行实时画面分类。你可以在应用界面中切换不同的推理后端（CPU、NNAPI、NPU等），直观地观察帧率和延迟的变化。如果发现应用界面方向不对，可以通过ADB命令adb shell settings put system user_rotation 0来调整为竖屏模式。

4. 集成NXP eIQ TFLite库到你的Android应用

跑通Demo只是第一步，我们的目标是将NPU加速能力集成到自己的应用中。NXP将必要的TFLite运行时和Delegate封装成了AAR（Android Archive）库，集成过程与添加普通第三方SDK类似。

4.1 认识eIQ TFLite库家族

在Android BSP包的vendor/nxp/neutron-software-stack/Android/TfLiteLib/目录下，你会找到5个关键的AAR文件，它们分工明确：

依赖关系：tensorflow-lite.aar内部已经依赖了tensorflow-lite-api.aar。因此，在你的项目中，通常只需要显式声明tensorflow-lite.aar和tensorflow-lite-external-delegate.aar即可。GPU库按需添加。

4.2 在代码中创建支持NPU的Interpreter

集成库之后，在Java代码中启用NPU加速的核心是正确配置Interpreter.Options。下面是一个典型的代码片段：

import org.tensorflow.lite.Interpreter; import org.tensorflow.lite.external.ExternalDelegate; public class NpuInferenceHelper { public Interpreter createNpuInterpreter(String modelPath, String delegateLibPath) { Interpreter.Options options = new Interpreter.Options(); // 设置推理线程数，对于NPU，通常1个线程即可，因为计算主要在NPU上完成 options.setNumThreads(1); // **关键技巧**：启用XNNPACK。当NPU不支持某些算子时，让XNNPACK（高性能CPU后端）接管，保证模型能运行。 options.setUseXNNPACK(true); // 创建并添加外部Delegate ExternalDelegate.Options extDelegateOptions = new ExternalDelegate.Options(delegateLibPath); // 可以设置其他选项，例如extDelegateOptions.set("option_key", "option_value"); ExternalDelegate npuDelegate = new ExternalDelegate(extDelegateOptions); options.addDelegate(npuDelegate); // 将Delegate添加到解释器选项 try { // 加载模型文件，这里可以是Asset中的文件或SD卡路径 File modelFile = new File(modelPath); MappedByteBuffer modelBuffer = new FileInputStream(modelFile).getChannel() .map(FileChannel.MapMode.READ_ONLY, 0, modelFile.length()); Interpreter interpreter = new Interpreter(modelBuffer, options); interpreter.allocateTensors(); // 分配张量内存 return interpreter; } catch (IOException e) { Log.e("NPU", "Failed to load model", e); return null; } } public float[] runInference(Interpreter interpreter, float[] inputData) { // 假设输出是一个浮点数组 float[][] outputData = new float[1][OUTPUT_SIZE]; interpreter.run(inputData, outputData); return outputData[0]; } }

代码解析与注意事项：

1. setUseXNNPACK(true)：这行代码是稳定性保障的关键。不是所有TFLite模型的所有算子都能被NPU支持。启用XNNPACK后，NPU不支持的算子会自动回退到这个高度优化的CPU后端执行，避免了整个模型运行失败。你会在日志中看到类似“X nodes delegated out of Y nodes”的信息，了解有多少算子被成功卸载到了NPU。
2. delegateLibPath：这个路径指向设备上Delegate的动态库。对于预装系统，通常是/vendor/lib64/libvx_delegate.so（i.MX 8M Plus）或/vendor/lib64/libneutron_delegate.so（i.MX 95）。务必确保你的应用有权限读取这个路径。
3. 线程数：对于NPU推理，计算主要在加速器上完成，CPU线程主要起调度作用，通常设置为1即可。设置过多反而可能增加调度开销。

4.3 通过Gradle集成AAR库

对于大多数使用Android Studio和Gradle构建的项目，集成步骤如下：

1. 拷贝库文件：将上述5个（或你需要的）AAR文件从BSP包拷贝到你项目的app/libs/目录下。
2. 修改build.gradle (Module: app)：

   android { // ... 其他配置 } repositories { flatDir { dirs 'libs' // 告诉Gradle在libs目录下查找本地AAR } } dependencies { implementation fileTree(dir: 'libs', include: ['*.jar']) // 引入NXP eIQ TFLite库 implementation(name: 'tensorflow-lite', ext: 'aar') implementation(name: 'tensorflow-lite-api', ext: 'aar') // 如果需要NPU加速，必须添加外部委托库 implementation(name: 'tensorflow-lite-external-delegate', ext: 'aar') // 按需添加GPU库 // implementation(name: 'tensorflow-lite-gpu', ext: 'aar') // implementation(name: 'tensorflow-lite-gpu-api', ext: 'aar') }

3. 同步项目：点击Android Studio的“Sync Now”，确保没有依赖错误。

4.4 通过Bazel集成AAR库

如果你的项目使用Bazel构建（例如，你直接基于TensorFlow的示例项目开发），则需要修改BUILD文件：

# 在BUILD文件中定义aar_import规则 aar_import( name = "tensorflow_lite_api", aar = "libs/tensorflow-lite-api.aar", ) aar_import( name = "tensorflow_lite", aar = "libs/tensorflow-lite.aar", deps = [":tensorflow_lite_api"], # 声明依赖关系 ) aar_import( name = "tensorflow_lite_external_delegate", aar = "libs/tensorflow-lite-external-delegate.aar", deps = [":tensorflow_lite_api"], ) # 在你的Android应用目标中引入这些依赖 android_binary( name = "my_npu_app", srcs = glob(["src/**/*.java"]), manifest = "AndroidManifest.xml", deps = [ ":tensorflow_lite", ":tensorflow_lite_external_delegate", # ... 其他依赖 ], )

完成以上步骤后，编译你的应用，就可以在代码中使用ExternalDelegate来调用NPU了。

5. 从源码构建：定制化与深度调试

直接使用预编译库虽然方便，但当你需要调试底层问题、修改TFLite源码、或者将应用预置到系统镜像中时，就需要从源码构建整个生态。这个过程稍显复杂，但能给你最大的控制权。

5.1 构建环境搭建详解

文档中给出了基于Ubuntu 22.04和特定版本工具的搭建步骤。这里我补充一些容易踩坑的细节：

1. Java版本：必须使用JDK 1.8.0。高版本JDK可能会导致Bazel或Android构建系统兼容性问题。使用java -version确认，并通过update-alternatives命令切换系统默认Java版本。
2. Bazel版本：严格使用Bazel 6.5.0。Bazel不同版本间的构建规则可能有变，版本不匹配是编译失败最常见的原因之一。安装后，建议在项目目录下创建一个.bazelversion文件，里面写上6.5.0，让Bazel自动使用正确版本。
3. Android SDK/NDK配置：这是最繁琐的一步。文档建议通过Android Studio GUI来下载，但对于无头服务器（Headless Server）环境，你可以使用sdkmanager命令行工具来安装：

   # 假设SDK根目录为 $ANDROID_SDK_ROOT $ANDROID_SDK_ROOT/cmdline-tools/latest/bin/sdkmanager --sdk_root=$ANDROID_SDK_ROOT \ "platforms;android-26" \ "build-tools;30.0.3" \ "ndk;26.2.11394342"

   务必确保ANDROID_NDK_HOME等环境变量指向正确的路径，并在TensorFlow源码的.bazelrc文件末尾正确追加（如文档所示）。
4. TensorFlow配置：运行./configure时，对于Android构建，当询问Python和库路径时，如果不需要其他功能（如GPU支持），可以直接回车使用默认值。但一定要确保在后续问题中正确设置了Android NDK和SDK的路径。

5.2 构建Label Image与Benchmark Model

构建APK（用于安装到设备）：

# 构建Label Image APK bazel build -c opt --config=android_arm64 tensorflow/lite/examples/label_image/android:label_image # 构建Benchmark Model APK bazel build -c opt --config=android_arm64 tensorflow/lite/tools/benchmark/android:benchmark_model

生成的APK位于bazel-bin对应的目录下，有签名版和未签名版。

构建C++二进制文件（用于ADB Shell命令行测试）：

# 构建Label Image C++二进制 bazel build -c opt --config=android_arm64 tensorflow/lite/examples/label_image:label_image # 构建Benchmark Model C++二进制 bazel build -c opt --config=android_arm64 tensorflow/lite/tools/benchmark:benchmark_model

为什么需要C++版本？如前所述，Android应用进程受限于单核调度。而C++二进制文件在ADB Shell中运行，可以自由使用所有CPU核心。对于benchmark_model，这是获取多核CPU真实性能的关键。使用方式如下：

adb push bazel-bin/tensorflow/lite/tools/benchmark/benchmark_model /data/local/tmp/ adb shell cd /data/local/tmp # 使用4个CPU线程进行基准测试 ./benchmark_model --graph=mobilenet_v1_1.0_224_quant.tflite --num_threads=4

5.3 构建TFLite Camera Demo

这个Demo使用Android Studio + Gradle构建，相对简单。

1. 将TfLiteLib目录下的AAR库拷贝到Demo项目的app/libs/目录。
2. 用Android Studio打开tensorflow/lite/java/demo目录。
3. 等待项目同步完成，点击Build -> Build Bundle(s) / APK(s) -> Build APK(s)。
4. 生成的APK在app/build/outputs/apk/debug/目录下。

5.4 将自定义应用集成到系统镜像

如果你开发的是一个系统级应用（如预装的相机应用），可能需要将其直接烧录到系统镜像中。步骤如下：

1. 准备Android BSP构建环境：按照NXP的Android用户指南(UG10156)搭建完整的编译环境，下载所有必要的工具链和源码。
2. 放置APK：将你编译好的APK（例如myapp.apk）拷贝到BSP源码的特定目录，例如vendor/nxp/neutron-software-stack/Android/TfLiteApks/。你可以参考预置应用的做法。
3. 修改设备配置文件：你需要找到对应设备的Makefile（如device/nxp/imx8m/evk_8mp/evk_8mp.mk），在其中添加一行，将你的APK包含到PRODUCT_PACKAGES变量中：

   PRODUCT_PACKAGES += \ myapp

4. 重新编译系统镜像：在BSP根目录执行source build/envsetup.sh、lunch选择你的设备，然后make -j$(nproc)。编译完成后，刷写新的系统镜像，你的应用就会出现在系统应用列表中。

6. 进阶议题：权限、SELinux与第三方应用部署

当你成功在自己的Android Studio项目中集成了NPU Delegate，编译出APK并安装到设备上时，可能会遇到一个令人困惑的问题：应用在创建ExternalDelegate时崩溃，日志显示无法加载libvx_delegate.so或libNeutronDriver.so。这很可能不是代码问题，而是SELinux（安全增强Linux）策略在作祟。

6.1 理解SELinux对第三方应用的限制

在Android系统中，/vendor分区下的库（如libvx_delegate.so）通常具有特定的SELinux标签（如vendor_file）。而用户安装的第三方应用（来自Play Store或adb install）运行在非特权域（如untrusted_app）。默认的SELinux策略可能不允许untrusted_app域进程直接dlopen打开vendor_file类型的共享库。

6.2 解决方案：添加库到公共库列表

Android提供了一个机制，允许将特定的vendor库暴露给所有应用。这通过/vendor/etc/public.libraries.txt文件实现。系统启动时会读取这个文件，将其中的库加载到全局命名空间，从而允许任何应用链接它们。

为i.MX 8M Plus添加NPU库的步骤：

1. 定位设备配置目录：进入Android BSP源码的device/nxp/imx8m/evk_8mp/目录。
2. 创建或编辑public.libraries.txt：如果文件不存在就创建它。添加一行：

   libtim-vx.so

   为什么是libtim-vx.so而不是libvx_delegate.so？因为VX Delegate本身依赖底层的TIM-VX库。只暴露Delegate库是不够的，必须同时暴露其直接依赖。
3. 修改设备MK文件：编辑同目录下的evk_8mp.mk文件，确保这个txt文件会被打包进vendor分区。通常需要添加类似下面的内容（具体位置需参考现有文件的模式）：

   # 将public.libraries.txt复制到vendor分区 PRODUCT_COPY_FILES += \ device/nxp/imx8m/evk_8mp/public.libraries.txt:$(TARGET_COPY_OUT_VENDOR)/etc/public.libraries.txt

为i.MX 95添加NPU和GPU库： 对于i.MX 95，步骤类似，但库名不同。在device/nxp/imx9/evk_95/public.libraries.txt中添加：

libNeutronDriver.so libOpenCL.so # 如果还需要GPU Delegate加速

同样，需要在evk_95.mk中确保文件被复制。

6.3 重新编译与验证

完成上述修改后，你需要重新编译整个Android系统镜像（至少是vendor分区），并刷写到设备上。重启后，你的第三方应用就应该能够成功加载NPU Delegate了。

排查技巧：如果问题依旧，可以通过ADB在设备上检查：

1. 文件是否存在：adb shell ls -lZ /vendor/lib64/libvx_delegate.so
2. 公共库列表是否生效：adb shell cat /vendor/etc/public.libraries.txt | grep -i tim
3. 查看SELinux拒绝日志：adb shell dmesg | grep avc或adb logcat | grep avc。这些日志会明确告诉你哪个进程试图访问什么资源被拒绝，是调整SELinux策略的最直接依据。

这个过程虽然有些麻烦，但它体现了Android系统在安全上的考量。对于产品化部署，与系统深度集成的应用更适合采用这种预置到镜像的方式。对于快速原型开发，你也可以考虑临时将SELinux设置为宽容模式（adb shell setenforce 0）来验证功能，但切勿在产品中关闭SELinux。

从通用但可能低效的NNAPI，转向与硬件深度绑定的专用Delegate，是在嵌入式Android设备上实现高性能AI推理的必由之路。通过本文的梳理，你应该已经掌握了在NXP i.MX平台上进行这一转换的完整路径：从用预置应用验证硬件加速效果，到将NXP的TFLite库集成到自己的项目中，再到从源码构建进行深度定制，最后解决了第三方应用部署时的SELinux权限问题。

我个人的体会是，嵌入式AI部署的挑战往往不在算法本身，而在于如何让软件栈与硬件特性完美契合。每一次性能提升，都可能需要你在系统层、框架层和应用层做出细致的调整。多关注logcat的输出，善用benchmark_model进行量化分析，并且不要畏惧去阅读和修改那些底层的构建脚本与配置文件，这些才是解决复杂部署问题的关键。