简介：这份高通SNPE安装包面向移动端与嵌入式AI推理部署开发者，提供snpe-1.5版本的完整工具链，可直接下载安装，用于在高通骁龙平台上完成神经网络模型的转换、量化、性能验证与集成调试，适合具备一定深度学习与C++/Python基础、需要快速搭建本地推理环境的中高级开发者。压缩包共1022个文件，约119.22MB，内容以HTML文档、Python脚本、JavaScript页面、PNG图示、共享库与C++头文件为主，并配有Java示例、C++源码、XML/JSON配置及多套GCC交叉编译Makefile，覆盖从模型处理到平台校验的常见环节。已有213人学习下载，说明其在SNPE环境获取与版本匹配方面具有一定参考价值。读者可获得可运行的库文件、示例脚本、模型转换与量化工具、性能与平台验证入口，以及面向不同ARM架构的构建配置，便于对照排查依赖、ABI与运行时问题，减少环境搭建和工具链适配的试错成本。
1. 先别急着解压：SNPE 1.5 装不起来，八成不是包坏了
SNPE 是高通骁龙平台上的神经网络推理引擎，把训练好的模型转成 .dlc 之后，能在手机、开发板、车机模组的 CPU、GPU、DSP 上跑起来。snpe-1.5.zip 这一代用的人一直不少，理由很现实：老项目、老固件、老 BSP 全停在这个版本上，往上升 DSP 侧反而跑不通。
但十个第一次装的人里，至少八个会遭遇失败。解压完、环境变量也设了，敲 snpe-net-run 直接报找不到 libSNPE.so；换台机器重来一遍，又变成 Python 里 protobuf 版本对不上，import 就报错。更隐蔽的是模型转换成功、部署到设备上却初始化失败——DSP runtime 版本不匹配，报错信息含糊得像个未知错误。
这套东西适合的是手里有骁龙设备、要把模型真正跑起来的人。如果只是想找个推理框架做做 demo，那装 SNPE 1.5 纯属给自己找麻烦。下面按我实际装过的顺序，把环境、解压、变量、转换、验证一段段拆开。
2. 环境对照：SNPE 1.5 该配什么系统、什么 Python
装老版本工具，最怕“先解压、后试错”。SNPE 1.5 的依赖关系基本围绕一个时间点打包，中间任何一件东西版本跨得太多，它就不认。我在三台机器上试过，Ubuntu 18.04 之后的部分库已经换上新的符号版本，跑起来会出现 glibc 相关的动态库报错，而这些问题不装一次根本遇不到。
2.1 操作系统与编译器：这一代的舒适区
SNPE 1.5 时代官方测试覆盖最好的是 Ubuntu 14.04 和 16.04，64 位、x86_64 架构。到了 18.04 一般也能跑，但需要多装几个兼容包；20.04 以后就属于碰运气，主要会卡在 libpython 和 glibc 版本上。我一般会找一台 16.04 的机器，或者用系统里承载版本一致的容器镜像，先把链路跑通，再考虑迁移。
| 组件 | 推荐版本 | 可接受范围 | 说明 |
|---|---|---|---|
| 操作系统 | Ubuntu 16.04 LTS x86_64 | 14.04 / 18.04 | 64 位必须，32 位没有对应的 lib |
| glibc | 2.23 | 2.19 及以上 | 低于 2.19 会报 GLIBC 符号缺失 |
| Python | 2.7 | 2.7.x | 这一代的 snpe python 模块没有做 py3 适配 |
| protobuf（Python） | 3.6.x | 3.4 ~ 3.6 | 高了会与 dlc 的 proto 定义冲突 |
| numpy | 1.14 ~ 1.16 | 1.10 以上 | 用于读取 input_list 里的 raw 文件 |
| JDK | 不需要 | — | 只做模型转换的话无需安装 |
| Android SDK Platform Tools | 任意近期版本 | — | 用到的只有 adb 和 fastboot |
编译器这块，SNPE 自带的 x86 动态库是用 clang 构建的，正常情况下系统只需要有 gcc 和 g++ 用来编译少量辅助工具，不需要装 CUDA 工具链。如果项目里还要自己写 C++ 对接 SNPE API，才需要额外准备 Android NDK，版本卡在 r14b 附近最稳，r18 之后 NDK 换成了 clang + libc++，链接老版本 SNPE 的 libgnustl_shared.so 会出现符号冲突。
2.2 Python 2.7 与 protobuf 的版本绑定
很多人的第一个错误印象是：SNPE 是纯 C++ 的，Python 只是可选的。并不准确。snpe python 目录下的 snpe_client.py、dlc 解析相关脚本都依赖 protobuf 的 Python 实现来反序列化 .dlc 文件，而 .dlc 本身就是一个 protobuf 序列化出来的容器格式。这意味着 protobuf 的 Python 版本对不上，模型转换工具虽然能跑，但只要走 Python 路径就会出问题。
常见做法是单独建一个 Python 2.7 的虚拟环境，把依赖锁死，不要往系统 Python 里直接装。我用 virtualenv 而不是 conda，理由是 conda 在 2.7 环境下自带的 openssl 版本经常和系统里的 libpython2.7 冲突，报错信息还特别难读。
# 安装 Python 2.7 的虚拟环境支持 sudo apt-get install -y python2.7 python2.7-dev python-pip python-virtualenv # 建一个专门给 snpe 用的虚拟环境，放在家目录下 virtualenv -p /usr/bin/python2.7 ~/snpe-py27 # 激活后锁版本安装，注意 --no-cache-dir 避免拿到缓存的更高版本 source ~/snpe-py27/bin/activate pip install --no-cache-dir protobuf==3.6.0 numpy==1.16.4这三条命令里，-p /usr/bin/python2.7必须写绝对路径，不少机器上 python 已经软链到 python3 了，不指定就会建出一个 Python 3 的环境，后面所有脚本都会失败。--no-cache-dir是个容易被忽略的细节，pip 缓存里如果存着 protobuf 4.x 的 wheel，即使你写了 ==3.6.0 也可能因为本地元数据混乱而装上不对的版本。
提示：装完之后用
python -c "import google.protobuf; print(google.protobuf.__version__)"确认输出是 3.6.x，不要只看 pip list。
2.3 Android SDK、NDK 与 adb 的取舍
只做模型转换和 x86 本地推理的话，Android SDK 完全可以不装，SNPE 不会主动去读 ANDROID_HOME。但只要涉及部署到设备，adb 就是必需品，Windows 宿主的话装 platform-tools 即可，Linux 下一般用sudo apt-get install android-tools-adb，不过系统源里的版本通常偏旧，我一般会直接解压一份官方 platform-tools 放到 /opt 下，把 adb 加进 PATH。
NDK 的分界线需要说清楚：模型转换（snpe-tensorflow-to-dlc、snpe-caffe-to-dlc）完全不需要 NDK；只有你要写自定义的 C++ 推理程序，或者要用 examples 里 android 目录下的示例工程编译出可执行文件，才需要 NDK。这一代的示例工程还是 Android.mk 体系，NDK r17 以后移除了 gnustl，必须改用 r14b 或 r16b 才能编译通过。
2.4 装之前先跑一遍系统自检
拿到包先别解压，先用四条命令确认机器的底子，省得后面在报错堆里找原因。
uname -m # 期望输出 x86_64 ldd --version | head -1 # 期望 glibc 2.19 及以上 python2 --version # 期望 Python 2.7.x adb version # 期望能打印出版本，没有说明 platform-tools 没装如果uname -m出来的是 aarch64，那说明你拿的是 ARM 服务器或开发板本身，SNPE 的 x86 工具链在上面跑不了，只能把转换工作放到 x86 机器上做，再把生成的 .dlc 拷到设备。这个顺序千万别搞反，我在一块 ARM 开发板上折腾过半小时，最后才反应过来 bin 目录里压根没有对应架构的工具。
3. 解压与环境变量：三条路径决定能不能跑起来
解压这一步本身没什么技术含量，真正决定成败的是落在哪个目录，以及 SNPE_ROOT、LD_LIBRARY_PATH、PYTHONPATH 这三条路径有没有指向正确的位置。这三条路径里，任意一条写错，表现出的错误信息都跟真实原因看起来没什么关系。
3.1 目录落位与结构确认
我习惯解压到 /opt 下，路径尽量短、不含空格和中文。原因很实际：SNPE 内部有不少脚本在做字符串拼接，路径里带空格会让某些参数被截断，报错信息又不会提示是路径的锅。
# 解压到 /opt，目录名以实际包内顶层目录为准 sudo unzip snpe-1.5.zip -d /opt/ # 把属主改回当前用户，避免后续 chmod、写文件需要 sudo sudo chown -R $(whoami):$(whoami) /opt/snpe-1.5.0 # 确认 bin 下的工具带可执行权限 ls -l /opt/snpe-1.5.0/bin/x86_64-linux-clang/ | head -20第一行的-d /opt/指定目标目录，unzip 会自动在里面创建包内的顶层目录。第二行chown -R很多人省略，结果后面改配置、写日志全要 sudo，很容易把文件属主改乱，再跑就报权限拒绝。第三行是必查项：有些渠道拿到的 zip 在打包时丢了权限位，解压出来所有工具都是 644，直接执行会报 Permission denied，用chmod +x /opt/snpe-1.5.0/bin/x86_64-linux-clang/*补上即可。
解压完成后重点看四个目录：
| 目录 | 内容 | 用途 |
|---|---|---|
| bin/x86_64-linux-clang | 转换、量化、运行工具 | 宿主机上做模型转换和 CPU 推理 |
| lib/x86_64-linux-clang | libSNPE.so 等动态库 | 宿主机可执行文件的运行时依赖 |
| python | snpe 相关 Python 模块 | .dlc 解析、辅助脚本 |
| android | aarch64 版库与工具 | 部署到设备时整目录推送 |
顺便说一句，models 目录下会带几个示例 .dlc（AlexNet 之类），这几个文件在验证环境时非常有用，先别删。
3.2 SNPE_ROOT 与 LD_LIBRARY_PATH
SNPE_ROOT 是一个约定变量，SNPE 的部分脚本会读它来定位资源，但更重要的是你自己写脚本时用它拼路径。LD_LIBRARY_PATH 才是真正的关键：snpe-net-run 等可执行文件在启动时动态链接 libSNPE.so，找不到就直接退出，报错是error while loading shared libraries: libSNPE.so: cannot open shared object file。
# 指向解压后的顶层目录，不要指到 bin 或 lib 里面去 export SNPE_ROOT=/opt/snpe-1.5.0 # 可执行工具目录加入 PATH，注意是 x86_64-linux-clang 这一层 export PATH=$SNPE_ROOT/bin/x86_64-linux-clang:$PATH # 动态库搜索路径，必须精确到 lib/x86_64-linux-clang export LD_LIBRARY_PATH=$SNPE_ROOT/lib/x86_64-linux-clang:$LD_LIBRARY_PATH # 把原有值保留在后面，避免覆盖掉系统里其他库路径四个变量各自的坑不太一样。SNPE_ROOT 指错层级（比如指到 lib 上），所有拼出来的子路径都会多一层或少一层，脚本会报文件不存在，但报的路径看着挺像对的，容易让人怀疑包是不是缺文件。PATH 里如果只写到$SNPE_ROOT/bin，那命令还是找不到，因为可执行文件在架构子目录下。LD_LIBRARY_PATH 最常见的错是写成$SNPE_ROOT/lib，少了架构层，libSNPE.so 就在里面一层，照样找不到。而所有变量末尾的:$原有值不能省，直接赋值会把系统库路径冲掉，后果是 ls、grep 这类基础命令都启动失败，只能开新终端恢复。
注意：不要把这四行写进 ~/.bashrc 的末尾就以为没事了。多个项目共用一台机器时，全局污染 LD_LIBRARY_PATH 会影响到别的程序，我一般用独立的 envsetup.sh。
3.3 PYTHONPATH 与 Python 侧依赖
PYTHONPATH 决定 python 能不能 import 到 snpe 目录下的模块。常见误区是只在虚拟环境里装了 protobuf，却忘了把 SNPE 自己的 python 目录挂进来，结果from snpe import ...报 ModuleNotFoundError，看起来像是包没解压完整。
# 把 SNPE 自带的 python 目录追加进去 export PYTHONPATH=$SNPE_ROOT/python:$PYTHONPATH # 验证能否正常导入，同时打印 protobuf 版本 python -c "import google.protobuf as p; print(p.__version__)"第一行的顺序有讲究，$SNPE_ROOT/python放在前面，保证优先命中 SNPE 自带的模块，而不是系统里可能存在的同名包。第二行的验证命令看着简单，但它是判断环境是否可用的分水岭：输出不是 3.6.x，后面所有涉及 .dlc 的 Python 操作都有风险。
3.4 用一个小脚本把环境固定下来
每次开新终端都要重设四个变量，迟早会漏一个。我一般写一个 envsetup.sh 放在项目根目录，用 source 加载。
#!/usr/bin/env bash # 用法: source envsetup.sh export SNPE_ROOT=/opt/snpe-1.5.0 export PATH=$SNPE_ROOT/bin/x86_64-linux-clang:$PATH export LD_LIBRARY_PATH=$SNPE_ROOT/lib/x86_64-linux-clang:$LD_LIBRARY_PATH export PYTHONPATH=$SNPE_ROOT/python:$PYTHONPATH # 切到 Python 2.7 虚拟环境，路径按实际情况改 source ~/snpe-py27/bin/activate echo "SNPE_ROOT=$SNPE_ROOT" echo "protobuf: $(python -c 'import google.protobuf as p; print(p.__version__)')"必须用source envsetup.sh而不是bash envsetup.sh，原因是后者会开子 shell，变量设置完随子 shell 退出就没了，等于白做。脚本末尾打印两行确认信息，是我踩过太多“以为加载了其实没加载”的坑之后加的习惯。echo 里的嵌套引号容易写错，外层双引号、内层单引号，顺序反了会报语法错。
4. 模型转换：从 pb 到 dlc 再到 x86 跑通
环境就绪之后，真正的工作是从训练框架导出的模型转成 .dlc，再在宿主机上用 CPU 跑一遍确认精度和形状没问题，最后才谈设备部署。这一步的顺序不能跳，直接在设备上试错，出问题你根本分不清是转换错了还是运行库的问题。
4.1 先用 snpe-dlc-info 认模型
手上如果已经有 .dlc（比如 models 目录下的示例），第一步永远是看它的输入输出定义。所有后续的参数都得跟这里对齐，输入层名写错一个字符就报找不到输入。
# 打印 dlc 的网络结构、输入输出层名与维度 snpe-dlc-info -i $SNPE_ROOT/models/alexnet.dlc # 只想快速看输入输出，可以配合 grep 过滤 snpe-dlc-info -i $SNPE_ROOT/models/alexnet.dlc | grep -A 3 -i "input\|output"-i后面跟 dlc 路径，工具会输出层名、类型、维度、量化信息（如果有）。重点记住三样东西：输入层名、输入维度、输出层名。输入维度里的 batch 维在 SNPE 里一般写 1 或 0，0 表示运行时动态，老版本对动态维支持有限，我建议转换阶段直接写死成 1。
4.2 TensorFlow pb 转 dlc 的完整写法
TensorFlow 侧要先冻结成 pb，再交给 snpe-tensorflow-to-dlc。这个工具对 pb 的要求比想象中严格：必须是把变量固化后的 frozen graph，带训练的 checkpoint 直接给它是不认的。
# 1. 冻结图（在训练环境里做），输出 frozen_graph.pb # 具体 freeze 脚本按项目来，这里只示意调用方式 # 2. 转换，-i 参数格式为「输入层名 维度」，维度里 batch 写 1 snpe-tensorflow-to-dlc \ --graph ./frozen_graph.pb \ -i input 1,224,224,3 \ --out_node prob \ --dlc ./model.dlc # 3. 立刻回读确认转换结果 snpe-dlc-info -i ./model.dlc | head -30--graph是输入 pb 路径；-i是最容易写错的一个参数，格式是“层名 + 空格 + 四维，维度里可以留一个维度为 0 标记动态，我一般全写死；--out_node指定输出节点名，多个输出就重复写多次--out_node；--dlc是输出路径。转换工具默认会做一些图优化，如果发现输出和原模型对不上，可以加参数关掉这些优化再比对。
转换完立刻用 snpe-dlc-info 回读，这是我看过太多“转换命令返回 0 但产物是坏的”之后养成的习惯。如果 dlc-info 都读不出来，后面所有步骤都不用试了。
4.3 Caffe 模型转换的输入维度坑
Caffe 的转换工具参数少一些，但坑集中在 deploy.prototxt 上。这个文件经常被人从训练配置里随手改出来，input_shape 和实际权重对不上，转换时会直接报维度不匹配。
snpe-caffe-to-dlc \ --caffe_txt ./deploy.prototxt \ --caffe_bin ./model.caffemodel \ --dlc ./model_caffe.dlc--caffe_txt是网络结构定义，--caffe_bin是权重文件，两者必须严格配套，随便拿一个 deploy 配另一份权重是最常见的错误来源。工具会读 prototxt 里的 input_dim 或 input_shape，如果部署文件里写的是旧的 input_dim 四段式，也要保证顺序是 N、C、H、W，跟 Caffe 的约定一致。
我一般会在转换前先把 prototxt 的输入层单独拎出来看一眼，确认通道数和后面的卷积层对得上，这比转换失败后再回头查省事得多。
4.4 snpe-net-run 在 x86 上先跑通
转换出来的 .dlc 在推给设备之前，先在宿主机上用 CPU runtime 跑一遍。这一步能排掉八成的问题，包括输入维度不符、raw 文件格式不对、输出节点选错。
输入的准备工作是：每一条样本准备一个目录，目录里放以“输入层名.raw”命名的二进制文件，内容是该输入张量去掉 batch 维之后的 float32 原始数据。
# 目录结构示例 # data/sample0/input.raw # data/sample1/input.raw # raw_list.txt 每行一个样本目录路径 cat > raw_list.txt <<'EOF' data/sample0 data/sample1 EOF # 用 CPU runtime 跑推理，输出默认落在 output/ 下 snpe-net-run --container ./model.dlc --input_list ./raw_list.txt--container指定 dlc；--input_list是样本清单，每行一个相对或绝对路径，不允许有表头、空行。结果默认写到output/Result_0/这类目录下，文件名就是输出层名，内容是 float32 二进制。想指定输出目录可以加--output_dir，想换 runtime 加--use_gpu之类，但 x86 本地一般只用 CPU，GPU runtime 在宿主机上未必可用。
第一次跑通的标准很简单：命令返回 0、output 目录下生成的文件大小等于“输出维度 × 4 字节”、把数值读出来与训练框架里同一条样本的输出做对比，误差在可接受范围内。对不上就回退去查输入 raw 的排布顺序，NHWC 和 NCHW 搞反是最常见的原因。
4.5 量化：体积与 DSP 兼容性
原始 dlc 是 float32 的，推到设备上体积大、DSP 上也跑不快。量化这一步用 snpe-dlc-quantize，需要一个校准集。
# quant_list.txt 格式与 raw_list.txt 相同，样本量一般 100 到 500 条 snpe-dlc-quantize \ --input_dlc ./model.dlc \ --input_list ./quant_list.txt \ --output_dlc ./model_quant.dlc # 量化后同样要回读验证 snpe-dlc-info -i ./model_quant.dlc | grep -i "quant"--input_dlc是浮点模型，--input_list是校准样本清单，--output_dlc是产物。校准集的分布要贴近真实场景，拿训练集的前几张图凑数，量化后精度掉得会很难看。量化完务必再跑一次 snpe-net-run，把输出和浮点版本对比，差异超过阈值就说明校准集不合适。
需要上 DSP 的话还有额外约束：量化方式、层类型支持情况都会影响能否成功初始化。有些层在 CPU 上没问题，DSP 上直接不支持，量化工具不报错，运行时才失败。所以流程上永远是先 CPU 跑通、再考虑 DSP。
5. 避坑与排查：五条实际踩过的记录
这一段按“现象 → 原因 → 解决”写，都是我在装这套东西时真实遇到过的。
5.1 环境变量与动态库相关
现象：执行 snpe-net-run 立刻退出，报error while loading shared libraries: libSNPE.so。
原因：LD_LIBRARY_PATH 没设，或者设成了$SNPE_ROOT/lib而漏掉架构子目录。SNPE 的 .so 全在lib/x86_64-linux-clang/这一层。
解决：echo $LD_LIBRARY_PATH确认路径完整，用ldd $(which snpe-net-run) | grep -i snpe看解析结果，如果显示 not found，说明路径确实不对。改完记得重新 source 一次脚本，直接 export 后原终端生效、新开终端又没了。
现象：所有基础命令（ls、grep）突然报错，终端像坏了一样。
原因：给 LD_LIBRARY_PATH 直接赋值而没保留原值，比如写成了export LD_LIBRARY_PATH=$SNPE_ROOT/lib/...，把系统库路径整个冲掉了。
解决：这个状态在当前终端里不好救，直接关掉开新终端，或者用绝对路径/bin/ls之类的命令临时操作。根因是脚本里少了:$LD_LIBRARY_PATH，改脚本加回去。
5.2 Python 与依赖相关
现象：import 与 snpe 相关的模块时报 protobuf 相关的描述符冲突，或者提示版本不兼容。
原因：系统 Python 里装着更高版本的 protobuf（4.x 那一套改了内部 API），与 SNPE 1.5 这一代使用的 3.6.x 不兼容。
解决：不要在系统 Python 里装 SNPE 的依赖，用 2.2 节里的 virtualenv 隔离，装完用python -c "import google.protobuf; print(google.protobuf.__version__)"确认是 3.6.x。如果系统里已经装乱了，pip uninstall protobuf之后再在虚拟环境里重装。
现象：pip 安装时提示找不到匹配的发行版，或者装上了但 import 报错。
原因：pip 已经指向 Python 3，装到了 py3 的 site-packages 里，而脚本用的是 python2。
解决：先which pip和which python看两者是否来自同一环境，虚拟环境激活后应该都指向~/snpe-py27/bin/下。不一致就显式用python -m pip install代替裸 pip。
5.3 模型转换与设备侧
现象：转换命令返回成功，但 snpe-net-run 报找不到输入层。
原因：-i后面写的输入层名与 pb 里实际的输入张量名不一致，或者维度顺序写反了。
解决：先用snpe-dlc-info -i model.dlc查看 dlc 里记录的输入层名，与转换时写的名字做比对。TensorFlow 的输入张量名经常带:0后缀或者input_1这种自动生成的命名，转换时写的是去掉后缀的名字。
现象：设备上初始化 DSP runtime 失败，报错信息只写了个版本不匹配或者初始化错误。
原因：SNPE 1.5 的 DSP 运行时与设备固件里的 adsp 版本需要对应，刷过非官方固件、或者设备 BSP 比 SNPE 新太多，都会出现这种失败。
解决：先在设备上用包里的snpe-platform-validator --runtime dsp看 DSP 是否被识别，再用 CPU runtime 跑同一份 dlc 确认模型本身没问题。CPU 能跑、DSP 不行，基本都是版本配套问题，这时候要么换对应 BSP 版本的 SNPE，要么就退回 CPU/GPU 跑。
6. 装完怎么验证：三条命令定生死
环境装完最忌讳的是“看着像好了”。我给自己的验收标准永远是三条命令，全过才算这套环境真的可用，缺一条都不算。
# 1. 工具链能否正常启动并打印帮助 snpe-net-run --help | head -5 # 2. 动态库解析是否全部命中 ldd $(which snpe-net-run) | grep -i "not found" # 3. 用自带示例模型跑一遍完整推理 cd /tmp && mkdir -p snpe_check && cd snpe_check snpe-net-run --container $SNPE_ROOT/models/alexnet.dlc \ --input_list $SNPE_ROOT/examples/.../raw_list.txt第一条命令验证的是 PATH 和可执行权限，能打出帮助说明二进制本身没坏。第二条验证的是 LD_LIBRARY_PATH，输出为空才是正常的，有任何一行 not found 都要回去查路径。第三条是端到端验证，用包里自带的示例模型和样例输入跑一遍，返回 0 且 output 目录下有产物，说明转换链路、运行时、输入格式全部打通。
这三条里最容易出现假阳性的是第一条：某些情况下--help能打出来，是因为帮助信息在动态库加载之前就输出了，看着正常，一跑推理还是报找不到库。所以我一般把第二条当作核心判据，ldd后面接$(which snpe-net-run)而不是硬编码路径，这样能确保检查的就是 PATH 里实际会执行的那一个。
设备侧再补一条，把 CPU runtime 跑通当作设备验收的基线：
adb shell "cd /data/local/tmp/snpe-runtime && \ export LD_LIBRARY_PATH=/data/local/tmp/snpe-runtime/lib && \ ./snpe-net-run --container ./model.dlc --input_list ./raw_list.txt"这一条里的关键是把 lib 目录在设备上重新 export 一次，adb shell 进去之后不会继承宿主机的环境变量，很多人宿主机跑通了，设备上直接报找不到库，就是这个原因。设备上的 lib 目录要整份推上去，不是只推 libSNPE.so 一个文件，里面还有 libgnustl_shared.so 之类的依赖。
从那以后我每次装这类老版本推理工具，都会先在 x86 上把示例模型跑通、确认三条命令全绿，再动设备，一步都不跳。这套 snpe-1.5.zip 的目录结构和上面写的完全一致，解压出来就能按第 2 章到第 4 章的顺序走一遍，环境变量和转换参数照着抄基本不会出岔子。真卡住了，先回头看看是不是某条路径少写了一层架构目录。希望帮到你。
本文还有配套的精品资源，点击获取
与for(；；)性能对比及编译器优化解析)
