第25章兼容性测试与适配

课程目录第25章兼容性测试与适配

第二十五节：兼容性测试与适配——不同厂商的NNAPI实现差异与回退策略

各位同学，今天我们来聊聊一个非常现实的问题——兼容性。

说实话，NNAPI 的接口是统一的，但底层实现嘛……各家有各家的脾气。高通、联发科、华为、三星，这四家几乎覆盖了市面上 90% 的 Android 设备。我这些年踩过的坑，大部分都跟它们的实现差异有关。

你想想看，同样是 ANEURALNETWORKS_AVERAGE_POOL_2D，在高通上跑得飞快，换到联发科上可能就报错。为什么会这样？因为各家对 NNAPI 的支持程度、算子实现、内存管理策略都不一样。

所以这一节，我们就来系统地梳理一下这些差异，以及如何优雅地做回退。

一、各厂商 NNAPI 实现的核心差异

先给一张总览图，让你心里有个底。

二、高通（Qualcomm）—— 最接近标准，但有小脾气

高通的 Hexagon DSP 对 NNAPI 的支持是最早也最成熟的。我个人觉得，如果你用高通设备做开发，大部分时候都很省心。

但注意，它有个特点：对模型输入张量的维度顺序非常敏感。我记得有一次，一个客户在骁龙 888 上跑分类模型，死活报 ANEURALNETWORKS_BAD_DATA。查了半天，原来是输入 layout 是 NHWC，但模型里写的是 NCHW。高通在驱动层会做严格校验，不像某些厂商会帮你偷偷转换。

高通适配要点：

优先使用 ANEURALNETWORKS_PREFER_SUSTAINED_SPEED 性能模式
输入数据尽量用 AHardwareBuffer 分配，减少拷贝
量化模型建议使用对称量化（symmetric quantization）

三、联发科（MediaTek）—— 算子不全，需要小心

联发科的 APU（AI Processing Unit）架构比较特殊，它把一些算子卸载到 VPU 上执行。这就导致一个问题：部分 NNAPI 标准算子，联发科可能不支持。

我在项目中遇到过，一个简单的 ANEURALNETWORKS_LOGISTIC（Sigmoid）在联发科天玑 1200 上直接返回 ANEURALNETWORKS_OP_FAILED。后来查文档才发现，它要求 Sigmoid 的输入必须是 4D 张量，而我的输入是 2D。

联发科避坑指南：

调用 ANeuralNetworksModel_getSupportedOperationsForDevices 提前检测算子支持情况
对于不支持的算子，手动拆分成多个支持的小算子
内存对齐要求高，建议使用 16 字节对齐的缓冲区

四、华为（Huawei）—— HiAI 与 NNAPI 的博弈

华为的情况比较特殊。它有自己的 HiAI 框架，对 NNAPI 的支持……嗯，怎么说呢，有点「若即若离」。

在麒麟 990 及之后的芯片上，华为的 DaVinci 架构对 NNAPI 的兼容性其实不错。但问题在于，华为对某些算子的实现做了自定义扩展。比如 ANEURALNETWORKS_QUANTIZED_16BIT_LSTM，这个算子在华为设备上表现很好，但在其他厂商上可能根本不存在。

我曾经在华为 Mate 40 上调试一个语音模型，用 NNAPI 跑一直崩溃。后来发现，华为的驱动对 ANEURALNETWORKS_ANNOTATIONS 这个扩展接口有特殊处理，需要额外设置一些元数据。

华为适配建议：

如果目标设备是华为，优先考虑 HiAI 接口（性能更好）
使用 NNAPI 时，避免使用非标准扩展算子
注意华为设备上 ANEURALNETWORKS_PREFER_LOW_POWER 模式可能限制性能

五、三星（Samsung）—— 性能波动大，需要兜底

三星的 Exynos 芯片，NPU 是独立单元。理论上性能很强，但实际表现……波动比较大。

我测试过 Exynos 2200 上的 NNAPI 性能，同一个模型，第一次推理 15ms，第二次可能变成 50ms。为什么？因为三星的驱动在做动态频率调整时，策略比较激进。

另外，三星对 ANEURALNETWORKS_DEVICE_TYPE_CPU 的回退处理也有问题。有时候你指定了 NPU 设备，但驱动发现算子不支持，不会自动回退到 CPU，而是直接报错。

三星适配要点：

手动实现多设备回退逻辑，不要依赖驱动自动回退
对推理时间做多次测量取中位数，避免单次抖动影响判断
优先使用 ANEURALNETWORKS_PREFER_FAST_SINGLE_ANSWER 模式

六、回退策略——让你的模型在任何设备上都能跑

好了，差异说完了。现在的问题是：怎么保证你的 App 在所有设备上都能正常工作？

我的做法是分层回退，从硬件加速一路退到 CPU 兜底。下面是一个典型的回退流程：

// 伪代码：分层回退策略
int inferenceWithFallback(ANeuralNetworksModel* model, ANeuralNetworksExecution* execution) {
    // 第一层：尝试 NPU/DSP 加速
    ANeuralNetworksCompilation* compilation = nullptr;
    uint32_t numDevices = 0;
    ANeuralNetworks_getDeviceCount(&numDevices);
    
    for (int i = 0; i < numDevices; i++) {
        ANeuralNetworksDevice* device;
        ANeuralNetworks_getDevice(i, &device);
        
        const char* name;
        ANeuralNetworksDevice_getName(device, &name);
        
        // 跳过 CPU 设备，优先加速器
        int32_t type;
        ANeuralNetworksDevice_getType(device, &type);
        if (type == ANEURALNETWORKS_DEVICE_TYPE_CPU) continue;
        
        // 检查算子支持情况
        bool supported;
        ANeuralNetworksModel_getSupportedOperationsForDevices(
            model, &device, 1, &supported);
        
        if (supported) {
            // 尝试编译执行
            int result = ANeuralNetworksCompilation_createForDevices(
                model, &device, 1, &compilation);
            if (result == ANEURALNETWORKS_NO_ERROR) {
                // 执行推理...
                return ANEURALNETWORKS_NO_ERROR;
            }
        }
    }
    
    // 第二层：回退到 CPU 加速（NNAPI CPU 实现）
    ANeuralNetworksCompilation_create(model, &compilation);
    // 执行推理...
    
    // 第三层：如果 NNAPI CPU 也失败，使用 TFLite GPU Delegate 或 XNNPACK
    // 第四层：纯 CPU 推理（TFLite 默认）
    return ANEURALNETWORKS_OP_FAILED;
}

这个策略的核心思想是：先试最好的，不行就降级。我在实际项目中，这个策略让模型的兼容性从 70% 提升到了 98% 以上。

七、兼容性测试清单

最后，我整理了一份兼容性测试清单，你可以直接拿去用：

测试项	测试方法	预期结果
算子支持检测	调用 `getSupportedOperationsForDevices`	返回 true 的算子占比 > 90%
多设备枚举	遍历所有设备，打印名称和类型	至少有一个非 CPU 加速器
内存分配	使用 `AHardwareBuffer` 和 `SharedMemory` 两种方式	两种方式均能成功分配
量化模型推理	分别测试 FLOAT32 和 INT8 模型	INT8 推理速度至少快 2 倍
回退路径验证	手动禁用加速器，验证 CPU 回退	推理结果一致（允许微小误差）
长时间稳定性	连续推理 1000 次	无内存泄漏，无崩溃

嗯，这一节的内容就到这里。兼容性测试没有捷径，就是一台一台设备去试。但有了上面的策略和清单，至少你能少走很多弯路。

记住一句话：不要相信任何厂商的「完全兼容」承诺，自己测过才算数。

公众号:蓝海资料掘金营，微信deep3321