企业官网建设流程全解析

简介：本资源为Android原生开发核心工具——Android NDK R26B官方Linux版完整安装包（android-ndk-r26b-linux.zip），面向Android中高级开发者、JNI实践者及性能敏感型应用（如游戏引擎、音视频处理、AI推理）的工程人员。它提供完整的交叉编译链、头文件、预编译库与调试工具，支持arm64-v8a等主流ABI，助力C++11+代码高效集成至Android应用，并通过JNI实现Java与原生层深度协同。压缩包共2000个文件，主体为1977个.h头文件（含NeuralNetworks.h、gl32.h、OpenMAXAL.h等关键接口定义）、11个Python构建/辅助脚本、10个Markdown格式文档说明及1份PDF官方参考，总大小638.31MB，结构规范、即解即用。目前已有451人学习下载，读者可直接获取R26B版本全部原生开发资产，涵盖NDK标准目录布局、多架构编译配置模板、崩溃日志分析工具（ndk-stack）及典型JNI桥接示例所需的底层支撑，是搭建稳定、高性能Android原生开发环境的权威基础组件。

1. Android NDK 是什么：它不是“安卓的C语言插件”，而是让 native 代码真正跑进 APK 的编译中枢

你写了一段高性能图像处理逻辑，用 C++ 实现了 OpenCV 的直方图均衡加速版，本地测试快了 3.2 倍；但一打包进 Android App，就报UnsatisfiedLinkError: dlopen failed: library "libnative.so" not found——不是代码错了，是 NDK 没配对、ABI 没对齐、so 没塞进对的位置。Android NDK（Native Development Kit）本质是一套跨平台交叉编译工具链 + 系统接口头文件 + 运行时支持库的集合体，它的核心任务只有一个：把你在 Linux/macOS/Windows 上写的 C/C++ 代码，精准翻译成能在 ARM64、ARMv7、x86_64 等 Android 设备 CPU 架构上原生执行的.so动态库，并确保它能通过 JNI 正确加载、调用、与 Java/Kotlin 层安全交互。它不负责写业务逻辑，但一旦出错，90% 的表现是“App 启动就闪退”“某功能点击无响应”“Logcat 里满屏dlopen failed”。适用人群非常明确：需要音视频编解码、物理仿真、密码学运算、AI 推理后端、或复用已有 C/C++ 库（如 FFmpeg、TensorFlow Lite C API、SQLite 加密扩展）的 Android 开发者。别被“NDK”三个字母吓住——r26b 这个版本（2023 年底发布）已大幅简化构建流程，Clang 默认启用、CMake 成为唯一推荐构建系统、独立工具链废弃，你不需要再手动拼接arm-linux-androideabi-gcc路径。接下来，我们就从零开始，在一台干净的 Ubuntu 22.04 机器上，用android-ndk-r26b-linux.zip完整走通“写代码 → 编译 so → 打包进 APK → Java 调用 → 真机验证”的全链路。所有命令可直接复制，所有路径可直接替换，所有坑我都替你踩过。

2. 下载、解压与环境变量配置：为什么ndk-build已被弃用，而cmake路径必须手动加进 PATH

NDK 不是装上就完事的软件，它是一组离线二进制工具集，必须显式声明其位置，否则 Gradle 根本不知道去哪里找clang++或sysroot。r26b 版本彻底移除了ndk-build脚本（那个经典的Application.mk+Android.mk双文件体系），官方文档明确标注为deprecated since r23。现在唯一受支持的构建方式是 CMake，而 CMake 本身需要知道 NDK 的根目录才能加载android.toolchain.cmake。这就引出两个刚性动作：解压后固定路径 + 环境变量注入。

2.1 下载与解压：选对路径，省掉后续 80% 的路径错误

不要解压到~/Downloads/或桌面，更不要用中文路径或空格路径。NDK 内部脚本对路径空格极其敏感，曾有开发者因解压到~/My NDK/导致CMake Error: Could not create named generator报错 3 小时。标准做法是创建专用目录并赋予用户读写权限：

# 创建统一工具目录（推荐） mkdir -p ~/android-tools # 进入目录，下载（此处用 curl 模拟，实际请从官网获取合法链接） # 注意：r26b 是 2023 年 12 月发布的稳定版，大小约 1.2GB curl -L -o android-ndk-r26b-linux.zip https://dl.google.com/android/repository/android-ndk-r26b-linux.zip # 解压（关键：必须用 unzip，tar 不识别 zip 内部结构） unzip android-ndk-r26b-linux.zip -d ~/android-tools/ # 验证解压结果：应看到 ndk/26.2.11394342/ 子目录（r26b 的完整内部版本号） ls -l ~/android-tools/android-ndk-r26b/ # 输出应包含：build/ meta/ ndk-stack ndk-which prebuilt/ sources/ sysroot/ toolchains/

提示：~/android-tools/android-ndk-r26b/就是你的NDK_ROOT。这个路径将在后续所有配置中复用，务必记牢。不要试图用符号链接绕过，Gradle 在某些 AGP 版本下会拒绝解析软链。

2.2 环境变量设置：PATH 和 ANDROID_NDK_ROOT 必须共存，缺一不可

仅设置ANDROID_NDK_ROOT不够，CMake 和 Gradle 都需要ndk-which、ndk-stack这类辅助工具在$PATH中可执行。常见错误是只设ANDROID_NDK_ROOT，结果cmake -G "Android Gradle - Ninja"报ndk-which: command not found。正确做法是双变量注入：

# 编辑 shell 配置文件（zsh 用户改 ~/.zshrc，bash 用户改 ~/.bashrc） echo 'export ANDROID_NDK_ROOT=$HOME/android-tools/android-ndk-r26b' >> ~/.zshrc echo 'export PATH=$ANDROID_NDK_ROOT:$PATH' >> ~/.zshrc # 立即生效 source ~/.zshrc # 验证：两个命令都必须返回有效路径 echo $ANDROID_NDK_ROOT # 应输出：/home/yourname/android-tools/android-ndk-r26b ndk-which clang++ # 应输出：/home/yourname/android-tools/android-ndk-r26b/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++ # 验证 CMake 是否能定位 NDK（关键！） cmake --version # 必须 >= 3.22（r26b 要求），若低于则需升级 CMake

注意：如果你使用 Android Studio 内置的 CMake（位于Android/sdk/cmake/），请确保其版本 ≥ 3.22.1。Studio 2022.3.1 及以上默认携带合规版本；旧版需手动更新 SDK Manager 中的 “CMake” 组件。混淆点在于：NDK 提供toolchains/llvm/下的 Clang，而 CMake 是独立构建驱动器——二者协同工作，但职责分离。

2.3 为什么不用sdkmanager安装 NDK？——离线部署的确定性优势

sdkmanager "ndk;26.2.11394342"理论上可行，但实践中问题频发：内网环境无法联网、公司防火墙拦截dl.google.com、sdkmanager自身依赖 Java 11+ 且常与系统 JDK 冲突。而android-ndk-r26b-linux.zip是完整离线包，解压即用，SHA-256 校验值公开（官网可查），版本锁定精确到 patch level（26.2.11394342），避免了sdkmanager隐式升级导致的 ABI 兼容性断裂（例如某次自动升级到 r26c 后，APP_PLATFORM := android-21编译失败）。对于 CI/CD 流水线，我们强制要求所有构建节点挂载同一份解压后的 NDK 目录，而非调用sdkmanager，这是保障多环境构建一致性的底线。

3. 用 CMake 在本地跑通最小 native 模块：从hello.cpp到libhello.so的三步编译

NDK 的价值不在“能不能编”，而在“编出来的 so 能不能被 Android Runtime 正确加载”。因此，本地编译验证必须模拟真实 Android 构建的 ABI、API Level、STL 选择。r26b 默认使用c++_sharedSTL 和android-21最低 API，这与当前主流 AGP（Android Gradle Plugin）3.6+ 的默认策略完全一致，无需额外调整。

3.1 创建最小可验证项目结构：严格遵循 CMake 的 source tree 规范

NDK 不接受随意目录结构。CMakeLists.txt 必须位于 native 源码根目录，且add_library()的名字将决定最终 so 文件名（lib{NAME}.so）。以下结构是经过千次验证的黄金模板：

# 创建项目根目录 mkdir -p ~/ndk-demo/app/src/main/cpp # 进入 cpp 目录，创建源文件 cd ~/ndk-demo/app/src/main/cpp # 1. 编写最简 JNI 函数（hello.cpp） cat > hello.cpp << 'EOF' #include <jni.h> #include <string> extern "C" { JNIEXPORT jstring JNICALL Java_com_example_ndkdemo_MainActivity_stringFromJNI(JNIEnv *env, jobject /* this */) { std::string hello = "Hello from C++"; return env->NewStringUTF(hello.c_str()); } } EOF # 2. 编写 CMakeLists.txt（注意：路径、名称、参数必须精确） cat > CMakeLists.txt << 'EOF' cmake_minimum_required(VERSION 3.22.1) # 设置项目名（仅用于 CMake 内部，不影响 so 名） project(ndk_demo) # 声明要构建的 native 库（生成 libhello.so） add_library(hello SHARED hello.cpp) # 指向 Android NDK 提供的头文件（r26b 自动推导，但显式声明更稳） find_package(log REQUIRED) target_link_libraries(hello log) EOF # 3. 创建空白 Android.mk（仅作占位，r26b 已忽略，但某些旧脚本会扫描） touch Android.mk

逻辑说明：add_library(hello SHARED ...)中的hello是库名，最终生成libhello.so；target_link_libraries(hello log)是必须的——所有 JNI 函数调用__android_log_print都依赖log库，漏掉则链接失败。find_package(log REQUIRED)是 CMake 的模块查找机制，r26b 的prebuilt/中已内置log-config.cmake，无需额外指定路径。

3.2 执行 CMake 命令行编译：ABI、API Level、Toolchain 三参数缺一不可

NDK 的交叉编译不是“运行 cmake”那么简单，必须显式告知目标架构、最低 Android 版本、以及使用 NDK 自带的 Clang 工具链。r26b 的toolchains/llvm/prebuilt/linux-x86_64/下已预置所有 ABI 的 Clang（如aarch64-linux-android31-clang++），CMake 通过-DANDROID_TOOLCHAIN=clang和-DANDROID_ABI自动选择。命令如下：

# 创建独立构建目录（严禁在源码目录内 cmake，会污染） mkdir -p ~/ndk-demo/app/src/main/cpp/build-arm64 # 进入构建目录 cd ~/ndk-demo/app/src/main/cpp/build-arm64 # 执行 CMake 配置（关键参数详解见下表） cmake \ -DCMAKE_TOOLCHAIN_FILE=$ANDROID_NDK_ROOT/build/cmake/android.toolchain.cmake \ -DANDROID_ABI=arm64-v8a \ -DANDROID_MIN_SDK=21 \ -DCMAKE_BUILD_TYPE=Release \ -GNinja \ .. # 执行编译（生成 libhello.so） ninja # 验证输出 ls -l ./libhello.so # 应输出：libhello.so -> /path/to/.../build-arm64/libhello.so（实际为 ELF 文件） file ./libhello.so # 应含：ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV)

血泪经验：-DANDROID_MIN_SDK=21是 r26b 的硬性要求。若设为16，CMake 配置阶段就会报错NDK at ... does not support API level 16。这是因为 r26b 移除了对旧 API 的 sysroot 支持，精简了体积。如果你必须支持 Android 4.1（API 16），请降级使用 r21e，但会失去 Clang 16、LTO 优化等新特性。

3.3 验证 so 是否可被 Android 加载：用readelf检查动态依赖

编译出的libhello.so必须满足两个条件才能被 Android Runtime 加载：1) 是正确的 ELF 格式（ARM64）；2) 不依赖主机系统库（如libc.so.6）。readelf是检验利器：

# 检查 ELF 架构和类型 readelf -h ./libhello.so | grep -E "(Class|Data|Machine)" # 应输出： # Class: ELF64 # Data: 2's complement, little endian # Machine: AArch64 # 检查动态链接依赖（关键！） readelf -d ./libhello.so | grep NEEDED # 正确输出应只含 Android 系统库： # 0x0000000000000001 (NEEDED) Shared library: [liblog.so] # 0x0000000000000001 (NEEDED) Shared library: [libc++.so] # 0x0000000000000001 (NEEDED) Shared library: [libc.so] # 错误输出示例（含 libc.so.6）： # 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] ← 这是 Linux 主机库，Android 没有！

玄学提示：如果readelf显示libc.so.6，说明 CMake 未正确使用 NDK 的 sysroot，大概率是-DCMAKE_TOOLCHAIN_FILE路径错误或环境变量ANDROID_NDK_ROOT未生效。此时ninja虽然成功，但 so 是废品。

4. 避坑：NDK r26b 的 5 个高频翻车点与血泪解决方案

NDK 配置是典型的“一步错，步步错”，错误信息往往晦涩难懂。以下是基于 r26b 在真实项目中高频出现的 5 类问题，每条按“现象 → 原因 → 解决”给出可立即执行的方案。

4.1 现象：CMake Error: Could not create named generator

原因：CMake 版本过低（< 3.22）或未安装 Ninja 构建工具。r26b 强制要求 CMake ≥ 3.22.1 且默认使用 Ninja 生成器（比 Make 更快、更可靠）。
解决：

# 升级 CMake 到 3.22.1+ wget https://github.com/Kitware/CMake/releases/download/v3.22.1/cmake-3.22.1-linux-x86_64.tar.gz tar -xzf cmake-3.22.1-linux-x86_64.tar.gz -C ~/android-tools/ export PATH=$HOME/android-tools/cmake-3.22.1-linux-x86_64/bin:$PATH # 安装 Ninja（Ubuntu/Debian） sudo apt install ninja-build # 验证 ninja --version # 应输出 1.10.0+

4.2 现象：undefined reference to '__android_log_print'

原因：CMakeLists.txt 中漏掉了find_package(log REQUIRED)或target_link_libraries(... log)。r26b 的log库不再自动链接，必须显式声明。
解决：
检查CMakeLists.txt，确保包含以下两行（顺序不能颠倒）：

find_package(log REQUIRED) # 查找 log 模块 target_link_libraries(hello log) # 将 log 链接到 hello 库

注意：target_link_libraries必须放在add_library之后，否则 CMake 不识别目标。

4.3 现象：dlopen failed: library "libhello.so" not found（APK 安装后）

原因：so 文件未正确打包进 APK 的lib/arm64-v8a/目录，或AndroidManifest.xml中未声明android:extractNativeLibs="true"（Android 9+ 默认为 true，但某些定制 ROM 会覆盖）。
解决：

1. 确认 Gradle 配置中sourceSets.main.jniLibs.srcDirs指向src/main/jniLibs，并将libhello.so复制进去：

mkdir -p ~/ndk-demo/app/src/main/jniLibs/arm64-v8a cp ~/ndk-demo/app/src/main/cpp/build-arm64/libhello.so ~/ndk-demo/app/src/main/jniLibs/arm64-v8a/

2. 在app/build.gradle的android { }块内添加：

android { packagingOptions { pickFirst '**/libhello.so' // 防止重复打包 } }

4.4 现象：java.lang.UnsatisfiedLinkError: No implementation found for java.lang.String com.example.ndkdemo.MainActivity.stringFromJNI()

原因：Java 层System.loadLibrary("hello")的库名与 C++ 中Java_com_example_ndkdemo_MainActivity_stringFromJNI的包名/类名/方法名不匹配。JNI 函数名是严格约定的，任何大小写、下划线、包路径错误都会导致找不到实现。
解决：

• Java 调用处：System.loadLibrary("hello")→ 库名必须小写，且与add_library(hello ...)一致
• C++ 函数名：Java_com_example_ndkdemo_MainActivity_stringFromJNI→com_example_ndkdemo是包名com.example.ndkdemo的下划线转义，MainActivity是 Activity 类名，stringFromJNI是 Java 方法名，三者必须一字不差。
• 验证技巧：用nm -D libhello.so | grep stringFromJNI查看 so 中是否导出了该符号。

4.5 现象：CMake Error: The source directory ".../cpp" does not contain a CMakeLists.txt

原因：执行cmake命令时，当前工作目录不是CMakeLists.txt所在目录，或CMakeLists.txt文件编码为 UTF-8 with BOM（Windows 记事本常见），CMake 无法解析。
解决：

• 严格在CMakeLists.txt同级目录执行cmake ..
• 用file CMakeLists.txt检查编码，若显示with BOM，用dos2unix CMakeLists.txt或 VS Code 保存为 UTF-8（无 BOM）

5. Gradle 集成与 ABI 分包：如何让一个 APK 同时支持 ARM64、ARMv7 和 x86_64

本地编译libhello.so只是第一步。真实项目需支持多 ABI 设备（华为 Mate 60 是 ARM64，老款三星 Galaxy S5 是 ARMv7，部分 Intel 芯片平板是 x86_64），而将所有 ABI 的 so 打进一个 APK 会使包体积暴涨。r26b + AGP 8.0+ 提供了优雅的 ABI 分包方案：Gradle 自动生成多个 APK，每个只含对应 ABI 的 so，Google Play 自动分发给匹配设备。

5.1 修改 app/build.gradle：声明 ABI 过滤与分包开关

AGP 8.0+ 默认启用android.packagingOptions.jniLibs.useLegacyPackaging = false，这意味着它会智能扫描src/main/jniLibs/下的子目录（arm64-v8a/,armeabi-v7a/,x86_64/）并打包对应 so。你需要做的是声明支持哪些 ABI，并开启分包：

android { // ... 其他配置 defaultConfig { // 声明应用支持的 ABI（必须与你编译的 so 目录名一致） ndk { abiFilters 'arm64-v8a', 'armeabi-v7a', 'x86_64' } // 最低 SDK 保持与 CMake 一致 minSdk 21 } // 启用 APK 分包（关键！） packagingOptions { jniLibs { useLegacyPackaging = false // 启用新打包逻辑 } } // 生成多个 ABI APK（非 AAB） splits { abi { reset() // 清空默认设置 include 'arm64-v8a', 'armeabi-v7a', 'x86_64' universalApk false // 不生成通用 APK } } }

逻辑说明：splits.abi.include告诉 Gradle 为每个列出的 ABI 生成一个独立 APK；universalApk false防止生成臃肿的通用包；useLegacyPackaging = false是性能关键——它让 Gradle 直接读取jniLibs/下的 ABI 子目录，跳过旧版的ndk { abiFilters }扫描逻辑，构建速度提升 40%。

5.2 自动化编译多 ABI so：用 Bash 脚本批量调用 CMake

手动为每个 ABI 运行一次cmake && ninja效率太低。写一个脚本，传入 ABI 名称，自动完成构建、复制、校验：

#!/bin/bash # save as build_all_abi.sh in ~/ndk-demo/app/src/main/cpp/ ABIS=("arm64-v8a" "armeabi-v7a" "x86_64") NDK_ROOT=$ANDROID_NDK_ROOT for ABI in "${ABIS[@]}"; do echo "=== Building for $ABI ===" # 创建 ABI 专属构建目录 BUILD_DIR="build-$ABI" mkdir -p "$BUILD_DIR" # CMake 配置（自动适配 ABI） cmake \ -DCMAKE_TOOLCHAIN_FILE="$NDK_ROOT/build/cmake/android.toolchain.cmake" \ -DANDROID_ABI="$ABI" \ -DANDROID_MIN_SDK=21 \ -DCMAKE_BUILD_TYPE=Release \ -GNinja \ -S . \ -B "$BUILD_DIR" # 编译 ninja -C "$BUILD_DIR" # 复制 so 到 jniLibs（Gradle 会自动拾取） JNILIBS_DIR="../../../../src/main/jniLibs/$ABI" mkdir -p "$JNILIBS_DIR" cp "$BUILD_DIR/libhello.so" "$JNILIBS_DIR/" # 校验 ELF 架构 if [[ "$ABI" == "arm64-v8a" ]]; then ARCH_CHECK="AArch64" elif [[ "$ABI" == "armeabi-v7a" ]]; then ARCH_CHECK="ARM" else ARCH_CHECK="x86-64" fi if file "$JNILIBS_DIR/libhello.so" | grep -q "$ARCH_CHECK"; then echo "✓ $ABI build OK" else echo "✗ $ABI build FAILED: wrong architecture" exit 1 fi done echo "All ABIs built successfully!"

赋予执行权限并运行：

chmod +x build_all_abi.sh ./build_all_abi.sh

参数说明：脚本中-S .指定源码目录（CMakeLists.txt 所在处），-B "$BUILD_DIR"指定构建目录，这是 CMake 3.13+ 推荐的 out-of-source 构建方式，彻底隔离源码与构建产物。

5.3 验证分包结果：用aapt dump badging检查 APK 的 ABI 声明

Gradle 生成的 APK 必须在AndroidManifest.xml中声明native-code属性，否则 Google Play 无法识别其 ABI。用aapt（Android SDK 自带）验证：

# 构建 APK（在项目根目录） ./gradlew assembleRelease # 检查 arm64-v8a APK aapt dump badging app/build/outputs/apk/release/app-arm64-v8a-release.apk | grep "native-code" # 应输出：native-code: 'arm64-v8a' # 检查 armeabi-v7a APK aapt dump badging app/build/outputs/apk/release/app-armeabi-v7a-release.apk | grep "native-code" # 应输出：native-code: 'armeabi-v7a'

提示：aapt位于Android/sdk/build-tools/34.0.0/aapt（版本号随 SDK 更新），若提示 command not found，请将该路径加入PATH。

6. 真机调试与崩溃分析：用ndk-stack把SIGSEGV日志还原成 C++ 行号

编译通过、打包成功，不等于 native 代码不出错。C++ 的SIGSEGV（段错误）在 Logcat 中只显示十六进制地址，如#00 pc 0000000000001234 /data/app/~~xxx==/com.example.ndkdemo/lib/arm64/libhello.so，根本看不出哪一行代码崩了。r26b 自带的ndk-stack工具就是为此而生——它能把崩溃地址映射回源码行号，是 native 调试的后悔药。

6.1 获取崩溃日志：过滤DEBUG级别并保存

在真机上复现崩溃，用adb logcat抓取完整日志，务必包含DEBUG级别（SIGSEGV属于 DEBUG）：

# 清空日志缓冲区 adb logcat -c # 抓取崩溃日志（保存到文件，避免滚动丢失） adb logcat *:S DEBUG:V | grep -E "(ndkdemo|libhello|SIGSEGV)" > crash.log # 或更暴力的方式：抓全部日志，崩溃后手动截取 adb logcat > full.log # 崩溃后 Ctrl+C，然后用编辑器搜索 "SIGSEGV"

6.2 准备符号表文件：obj/local/arm64-v8a/libhello.so是关键

ndk-stack需要带调试符号的 so 文件（即编译时未 strip 的版本）。CMake 默认生成的build-arm64/libhello.so就是带符号的，但 Gradle 打包时会自动 strip。因此，你必须保留构建目录下的原始 so：

# 确保你有未 strip 的 so（即 build-arm64/libhello.so） ls -l ~/ndk-demo/app/src/main/cpp/build-arm64/libhello.so # 大小应在 500KB+（带符号），而非 100KB（strip 后） # 将其重命名为 obj/local/arm64-v8a/libhello.so（ndk-stack 期望路径） mkdir -p ~/ndk-demo/obj/local/arm64-v8a cp ~/ndk-demo/app/src/main/cpp/build-arm64/libhello.so ~/ndk-demo/obj/local/arm64-v8a/

6.3 运行 ndk-stack：一行命令还原崩溃现场

# 在 crash.log 所在目录执行 $ANDROID_NDK_ROOT/ndk-stack -sym ~/ndk-demo/obj -dump crash.log # 示例输出： # ********** Crash dump: ********** # Build fingerprint: 'HUAWEI/.../...:12/...' # #00 pc 0000000000001234 /data/app/~~xxx==/com.example.ndkdemo/lib/arm64/libhello.so (Java_com_example_ndkdemo_MainActivity_crashTest+20) # #00 0000000000001234 /home/user/ndk-demo/app/src/main/cpp/hello.cpp:15 # #01 0000000000001256 /home/user/ndk-demo/app/src/main/cpp/hello.cpp:18

关键点：-sym参数指向obj/目录（必须包含local/arm64-v8a/子目录），-dump指向日志文件。输出中hello.cpp:15就是崩溃的精确行号，比对着汇编看寄存器省 90% 时间。

我带过的某高校图像处理 Demo 项目，学生总在cv::Mat构造时 SIGSEGV，用ndk-stack一跑，发现是cv::Mat mat(1000, 1000, CV_8UC3)申请了 3MB 内存，而 Android 的 native heap 默认只有 16MB，超出就崩。解决方案是改用cv::Mat::create()按需分配，或在Application中调用android.os.Debug.setNativeHeapSize(32 * 1024 * 1024)。没有ndk-stack，这个问题得靠猜和打 log 耗三天。希望帮到你。

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