最早接到这个任务时我原本以为只是把桌面版的 VTK 用 CMake 交叉编译到 Android 平台照着官方文档跑一遍就行。真正动手之后才发现Ubuntu 24.04 配合 VTK 9.3.1 这套组合坑点比我想象的多得多光是解决链接期报错就花了我两个晚上。这篇文章就是一次完整复盘从环境准备、CMake 配置到链接阶段连环炸、最终产物验证把我实测踩过的每一个坑、当时的判断依据、以及最终怎么绕过去的全部记录下来。先说清楚我做的到底是什么。VTKVisualization Toolkit是一个开源的三维可视化库桌面端常用在医学影像、科学计算可视化、点云渲染这些场景。我这里的目标是编译出能在 Android 上运行的 VTK 9.3.1 动态库后续要接进 Android Studio 的 JNI 工程里。编译环境是 Ubuntu 24.04 LTSNDK 版本 r25cCMake 3.29JDK 17。如果你也准备干同样的事可以参考我这套流程但我不保证完全适用你的环境组合毕竟 NDK 和 CMake 的版本搭配足够让人折腾一阵子。1. 为什么非要在 Linux 上给安卓交叉编译 VTK先回答一个很多人会问的问题VTK 官方不是有现成的 Android 构建脚本吗为什么不直接用VTK 仓库里确实有CMakeLists.txt和官方的 Android 工具链支持但官方提供的只是“构建入口”不是“现成产物”。官方 CI 会出一些预编译包但版本更新滞后且不一定包含你需要的模块组合。比如我需要的是带Rendering、Filters、IO这几个核心模块同时要能用 OpenGLES 渲染的版本预编译包要么缺模块要么渲染后端对不上最后还是得自己编。另外一个现实问题是VTK 9.3.1 对 CMake 的最低版本要求是 3.16但真正编译 Android 版本时NDK 的android.toolchain.cmake和 VTK 的VTK_ANDROID_SUPPORT这套逻辑对 CMake 版本很敏感。如果你直接用 Ubuntu 24.04 自带的 CMake3.28去跑大概率会碰到“Policy CMP0148”或 NDK toolchain 相关的兼容性警告。我后面会细说怎么处理。再说个更实际的原因Windows 上装 NDK 交叉编译也不是不行但 VTK 的 Java/Android 包装层、vtkJavaUtil、JNI 相关的符号生成在 Linux 环境下更顺畅。而且后续如果你要跑测试用例、用ctest验证编译结果Linux 下的脚本兼容性明显更好。所以我个人建议是不要试图在 Windows 上绕直接用 Linux 做交叉编译省下的时间足够你多踩两个别的坑。还有一个隐藏动机是——Android 端的 VTK 往往不只是渲染还需要做模型处理、坐标变换、数据 IO。这时候光用vtkAndroidRenderWindow不够需要把整套 VTK 编进去这就绕不开完整编译。所以这个项目本质上是“在 Linux 上制作一个给安卓用的 VTK SDK”你说它是交叉编译其实更接近“定制化 SDK 构建”。小结自己做编译不是为了显得专业而是为了拿到一个干净、可裁剪、带特定渲染后端和模块集的产物。这决定了后面所有 CMake 参数怎么选。2. 环境准备Ubuntu 24.04 上最容易翻车的三个环节2.1 CMake 版本Ubuntu 自带的不一定够用Ubuntu 24.04 的官方源里CMake 版本是 3.28.x。VTK 9.3.1 官方 CMakeLists 写着最低 3.16理论上 3.28 够用。但实际跑起来你会发现NDK r25c 里的android.toolchain.cmake在处理ANDROID_ABI和ANDROID_PLATFORM时有一些只在 CMake 3.21 才完善的行为比如对ANDROID_PLATFORM的字符串规范化。如果版本偏低可能会出现Invalid ANDROID_PLATFORM这类让人摸不着头脑的报错。我一开始用自带 CMake报了一个非常诡异的错CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage这个错表面看是编译器没找到但其实是 toolchain 文件解析出了问题。升级到 CMake 3.29从 Kitware 官方 apt 源装之后同样的配置一次通过。安装方式不复杂无非是添加 Kitware 源或者直接下载官方 tar.gz。我用了 Kitware 官方仓库sudo apt update sudo apt install -y software-properties-common lsb-release wget -O - https://apt.kitware.com/keys/kitware-archive-latest.asc 2/dev/null | \ gpg --dearmor - | sudo tee /usr/share/keyrings/kitware-archive-keyring.gpg /dev/null echo deb [signed-by/usr/share/keyrings/kitware-archive-keyring.gpg] https://apt.kitware.com/ubuntu/ noble main | sudo tee /etc/apt/sources.list.d/kitware.list sudo apt update sudo apt install cmake -y提示noble是 Ubuntu 24.04 的代号别复制成jammy否则会装到旧版本。2.2 NDK 版本与 toolchain 文件路径VTK 的 Android 编译官方推荐 NDK r25 或 r26。我实测 r25c 匹配良好r26b 也能编但部分老模块的-Werror会报警告升级成错误需要额外处理。建议直接用 r25c省心。下载之后解压到一个没有空格的路径这点非常重要。比如我放到~/android-ndk-r25c而不是~/Program Files/Android/...。空格问题会在 CMake 生成阶段引发各种No such file or directory但报错信息完全看不出来是路径问题。NDK 装好之后toolchain 文件位置是export ANDROID_NDK~/android-ndk-r25c $ANDROID_NDK/build/cmake/android.toolchain.cmake后面 CMake 配置时用-DCMAKE_TOOLCHAIN_FILE指向这个文件即可。但是VTK 有自己的一套 Android 支持逻辑不只靠 NDK 的 toolchain还需要开启VTK_ANDROID_SUPPORT或使用它的CMake/vtkAndroid.cmake。这块我在第三节详细展开。2.3 JDK 版本与 Java 依赖如果你只是编 C 库JDK 看似无关。但 VTK 的 Android 构建里包含Wrapping/Java这一层它需要 JDK 和 Ant/Gradle 才能生成 Java 包装类。我最初是纯 C 需求没装 JDK结果 CMake 配置阶段就中断了Could NOT find Java。Ubuntu 24.04 默认仓库里有 OpenJDK 17安装后记得设置JAVA_HOMEsudo apt install openjdk-17-jdk -y export JAVA_HOME/usr/lib/jvm/java-17-openjdk-amd64安装完后CMake 能自动检测到 Java但如果你不需要 Java 包装层其实可以在配置时直接关闭。我是因为后续要自己写 JNI 调用不需要 VTK 自动生成的 Java 层所以选择了关闭-DVTK_WRAP_JAVAOFF。这一步能省掉非常多麻烦尤其是少碰 ant 和 javac 版本不匹配的破事。注意就算你不开 Java 包装VTK 的 Android 构建仍然会检查 Java所以 JDK 还是要装。这是 VTK 源码里CMake/vtkAndroid.cmake对 Java 的隐式依赖绕不过去。3. CMake 配置阶段这些参数不调对后面全白干3.1 必须先了解 VTK 的模块体系VTK 9.x 以 module 为组织单位默认会编译一大堆模块包含vtkRenderingOpenGL2、vtkInteractionStyle、vtkIOMINC、vtkFiltersParallel等等。Android 平台用不到桌面版的 OpenGL很多并行计算模块也没有意义。如果全编光编译时间就够睡两觉还会因为模块依赖关系在链接期疯狂报 undefined reference。所以我推荐的思路是基于模块分组做裁剪。VTK 提供了VTK_GROUP_ENABLE_*这类开关可以批量控制组内的模块是否启用。常用的组有组名默认状态Android 编译建议VTK_GROUP_ENABLE_RenderingON需要但只开 OpenGL2 部分VTK_GROUP_ENABLE_ImagingON按需不开也行VTK_GROUP_ENABLE_ViewsON建议 OFFVTK_GROUP_ENABLE_WebON建议 OFFVTK_GROUP_ENABLE_QtON必须 OFFVTK_GROUP_ENABLE_MPION必须 OFFVTK_GROUP_ENABLE_StandAloneON建议 OFF我最终只保留了这些模块组-DVTK_GROUP_ENABLE_RenderingON -DVTK_GROUP_ENABLE_ImagingOFF -DVTK_GROUP_ENABLE_ViewsOFF -DVTK_GROUP_ENABLE_WebOFF -DVTK_GROUP_ENABLE_QtOFF -DVTK_GROUP_ENABLE_MPIOFF -DVTK_GROUP_ENABLE_StandAloneOFF3.2 关键开关集合一套实测可用的 CMake 命令这里直接上我最终验证通过的完整配置。源码目录我放在~/vtk-src版本标签是v9.3.1build 目录是~/vtk-android-build。cmake -G Unix Makefiles \ -DCMAKE_TOOLCHAIN_FILE$ANDROID_NDK/build/cmake/android.toolchain.cmake \ -DANDROID_ABIarm64-v8a \ -DANDROID_PLATFORMandroid-26 \ -DANDROID_USE_LEGACY_TOOLCHAIN_FILEOFF \ -DCMAKE_BUILD_TYPERelease \ -DCMAKE_INSTALL_PREFIX$HOME/vtk-android-install \ -DBUILD_SHARED_LIBSON \ -DVTK_ANDROID_SUPPORTON \ -DVTK_ANDROID_BUILDON \ -DVTK_OPENGL_HAS_EGLON \ -DVTK_USE_XOFF \ -DVTK_GROUP_ENABLE_RenderingON \ -DVTK_GROUP_ENABLE_ImagingOFF \ -DVTK_GROUP_ENABLE_ViewsOFF \ -DVTK_GROUP_ENABLE_WebOFF \ -DVTK_GROUP_ENABLE_QtOFF \ -DVTK_GROUP_ENABLE_MPIOFF \ -DVTK_GROUP_ENABLE_StandAloneOFF \ -DVTK_WRAP_JAVAOFF \ -DVTK_BUILD_TESTINGOFF \ -DVTK_BUILD_EXAMPLESOFF \ -DVTK_ENABLE_LOGGINGOFF \ -DVTK_REQUIRE_ANDROID_OPENGLES3ON \ ~/vtk-src很多参数一眼看不懂我解释下几个关键的含义VTK_ANDROID_SUPPORTON和VTK_ANDROID_BUILDON这是让 VTK 走vtkAndroidRenderWindow、vtkAndroidRenderWindowInteractor这套 Android 特有的窗口和后端逻辑的开关。不开的话它会去找 X11 或者 Cocoa立刻挂掉。VTK_OPENGL_HAS_EGLONAndroid 上 OpenGL ES 需要 EGL 来管理上下文这个是核心。VTK_USE_XOFF关掉 X11 依赖不然链接时找不到libX11.so。VTK_REQUIRE_ANDROID_OPENGLES3ON这个我必须强调。VTK 默认在 Android 上如果没检测到 GLES3会尝试走 GLES2 的兼容路径。但 GLES2 下很多 shader 写法会出问题。我在集成测试阶段发现GLES2 路径渲染出来的模型经常黑屏改成 GLES3 后端后一切正常。所以从编译阶段就锁定 GLES3 最省事。BUILD_SHARED_LIBSON编成 .so。虽然后续也可以选择静态库但 VTK 的模块特别多全静态编会导致一个巨大无比的 so加载慢且容易 OOM。动态库方案更常见。3.3 关于 Android ABI 的选择这个项目里我只编译了arm64-v8a。按说应该连armeabi-v7a一起编但 VTK 9.3.1 在 32 位 ARM 上的 CMake 配置经常卡在flatbuffers的生成阶段问题很多。如果你只是做现代 Android 设备适配建议只出 arm64。实在要兼容老设备建议单独再开一个 build 目录专门编 32 位不要混在同一个 CMake 目录里切 ABI这会引发缓存污染。这里有个容易被忽略的点ANDROID_PLATFORMandroid-26表示最低支持 Android 8.0。如果你的应用 minSdk 是 21可以降到android-21但GLES3 支持在 ndk 的 API level 21 之后就已经有绑定了降到 21 不影响 GLES3。我之所以用 26是为了保证 Android Native 的AAssetManager接口稳定避免兼容逻辑干扰问题。3.4 为什么 Qt 组必须关掉这个问题值得单独说。VTK 的VTK_GROUP_ENABLE_Qt默认是开启的它会把vtkGUISupportQt、vtkGUISupportQtQuick等模块纳入编译这些模块需要桌面版 Qt5 或者 Qt 6 的QtWidgets头文件。而 Qt 并没有针对安卓的标准 apt 包就算你通过android_arm64_v8a的 Qt 安装包配好了VTK 的 Qt 模块在 Android 上也没有实际意义——因为最终渲染还是走 OpenGL ESQt 只负责 UI 壳子。所以直接关掉是唯一合理选择不然 CMake 检测阶段就会报Qt5 not found白白打断配置。4. 链接期连环炸我的失败日志与逐条定位4.1 第一个炸点OpenGL 库找不到CMake 配置通过后开始 make前 30% 编译都比较顺利虽然慢到链接某个模块时突然报undefined reference to glBindBuffer undefined reference to eglCreateContext当时我第一反应是难道 OpenGLES 相关的库没链接进去后来排查发现是VTK_USE_XOFF和VTK_OPENGL_HAS_EGLON的组合虽然开了但 CMake 某些模块在find_package(OpenGL)阶段会把OPENGL_LIBRARIES指到一个空变量导致链接命令里没有-lGLESv3 -lEGL。解决方法是在 CMake 命令里手动注入-DOPENGL_gl_LIBRARY$ANDROID_NDK/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/aarch64-linux-android/26/libGLESv3.so -DOPENGL_egl_LIBRARY$ANDROID_NDK/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/aarch64-linux-android/26/libEGL.so注意路径里的26对应ANDROID_PLATFORM。如果你选的是android-21这个路径就要改成21。NDK 从 r25 开始sysroot 里的库路径带有 API level 子目录很容易被忽略。提示libGLESv3.so在 NDK 里是一个很小的库它和libGLESv2.so是同一个符号链接体系Android 系统里只存在libGLESv2.so。但链接期写libGLESv3.so是 OK 的因为 NDK 提供了这个 stub。4.2 第二个炸点atomic 符号和 libc 版本冲突在链接vtkCommonCore时又出现了一批undefined reference to __atomic_load_16。这个坑很经典。NDK 的arm64-v8a目标默认支持部分原子操作但 16 字节的 atomic 操作比如std::atomiclong double或std::atomic__int128需要显式链接libatomic.a。VTK 的某些头文件在容器或数学计算里用了 16 字节 atomic而 CMake 没有自动帮你加上这个库。解决办法是手动设置-DCMAKE_EXE_LINKER_FLAGS-latomic -DCMAKE_SHARED_LINKER_FLAGS-latomic这里要注意-latomic必须出现在链接命令里且顺序不能乱。有些教程推荐直接在target_link_libraries里加但 VTK 这种大工程手动全局链接标志是最快的解法。4.3 第三个炸点内存不足导致的编译中断编译进行到 70% 左右的时候我的机器16GB 内存开始频繁报c: fatal error: Killed signal terminated program cc1plus这不是代码问题是并行编译时内存爆了。VTK 的vtkRenderingOpenGL2里有些模板头文件比如vtkOpenGLPolyDataMapper单文件编译可能占用 2-3GB 内存。我用的-j$(nproc)把整机资源全部拉满结果系统 OOM直接杀掉了编译器。处理办法是降低并行度先make -j4。另外可以用-DVTK_ENABLE_WRAPPINGOFF减少一处内存占用虽然我们没开 Java wrap但 VTK 内部还有 C wrapping 的流程。还有个经验是在链接大 so 时单线程比多线程更稳。我干脆把编译并行度控制到-j4链接时用-j1前后耗时其实差不了太多但稳定性提高了一个档次。别迷信 nproc编译个大型库贪多嚼不烂的道理依然成立。4.4 第四个炸点flatbuffers 生成器的宿主平台问题VTK 里有个vtkIOMINC或者vtkFiltersParallelDIY模块依赖diylog和flatbuffers。在交叉编译中flatbuffers 需要先在宿主机也就是你的 Ubuntu上编译一个flatc工具再拿去生成头文件。问题在于如果 CMake 没有明确宿主平台和 target 平台的区别它可能尝试用 clang 交叉编译的flatc去跑然后一运行就Exec format error。排查时看到这个错误我第一反应是 CMake 缓存有问题。后来发现是VTK_GROUP_ENABLE_StandAloneOFF之后部分模块的依赖被错误关闭导致 flatbuffers 的BUILD_EXECUTABLE选项被跳过了。解决办法是单独强制打开 flatbuffers 的 host 工具编译-DVTK_BUILD_FLATBUFFERS_EXECUTABLEON或者在配置阶段就加一个-DFLATBUFFERS_BUILD_EXECUTABLEON这样 CMake 会先编译一个宿主版本的flatc再进入生成阶段。这个问题不动手遇到真是猜不到。4.5 第五个炸点绝对路径与 ccache 引发的迷之错误有一阵子链接时反复报No such file or directory: /home/myuser/vtk-android-build/../../../usr/include/python3.12/Python.h看到这个路径的第一反应是头文件搜索路径写错了../../../多跳了几级。排查之后发现这其实和编译参数无关是 CMake 在安装阶段用了缓存的CMAKE_PREFIX_PATH而那个路径里混入了宿主机的/usr/include/python3.12。VTK 的 Python 包装虽然没开但 CMake 的find_package(Python3)还是会被某些模块隐式调用一旦找到宿主机 Python就会把头文件目录写进INCLUDE_DIRECTORIES最终在 Android 链接命令里出现一个包含/usr/include的路径。解决方法是显式禁用-DVTK_USE_PYTHONOFF -DVTK_WRAP_PYTHONOFF同时清掉 build 目录重新配置。这里强调一下修改 CMake 选项后一定要删掉 CMakeCache.txt 或直接删 build 目录因为很多find_package结果会缓存不是所有选项变更都会触发重新检测。4.6 构建成功的标志经过以上五轮折腾最终看到[100%] Built target vtkRenderingOpenGL2并且在lib/目录下出现了libvtkCommonCore-9.3.so libvtkCommonDataModel-9.3.so libvtkFiltersCore-9.3.so libvtkRenderingCore-9.3.so libvtkRenderingOpenGL2-9.3.so ...这也意味着 VTK 9.3.1 的 Android 版本算是编译出来了。5. 产物验证so 库、JNI 封装和编译期宏的最终检查5.1 用 readelf 检查依赖编译成功不等于能在 Android 上直接跑。我第一步是用 NDK 自带的llvm-readelf查看 so 的依赖$ANDROID_NDK/toolchains/llvm/prebuilt/linux-x86_64/bin/llvm-readelf -d libvtkRenderingOpenGL2-9.3.so | grep NEEDED正常情况应该看到libGLESv2.so libEGL.so libandroid.so liblog.so libc_shared.so libm.so libdl.so libc.so如果你的列表里出现了libX11.so、libGL.so或者libpython3.12.so说明 CMake 配置阶段混入了宿主机依赖这个 so 装到 Android 上必然UnsatisfiedLinkError。这时候要回头检查VTK_USE_X、VTK_USE_PYTHON这些开关。5.2 检查 GLES3 符号我还用了一个更直接的方式验证 GLES3 绑定$ANDROID_NDK/toolchains/llvm/prebuilt/linux-x86_64/bin/llvm-nm -D libvtkRenderingOpenGL2-9.3.so | grep glCreateShader如果能看到glCreateShader这样的符号说明渲染模块确实链接到了 GLES 的 stub 库运行时由 Android 系统解析到实际驱动。5.3 AAR / JNI 集成前的最后准备VTK 编译出来的是一堆独立的 so不是现成的 AAR。要在 Android Studio 里用有两种路径把 so 文件放到app/src/main/jniLibs/arm64-v8a/下然后自己写 JNI 头文件和 .cpp。这是最灵活的方式。用 CMake 在安卓工程里直接链接这些 so需要在build.gradle里指定externalNativeBuild。以第一种为例你的AndroidManifest.xml里需要声明uses-feature android:glEsVersion0x00030000 android:requiredtrue /因为 VTK 的 OpenGLES3 后端在运行期需要 GLES3 上下文如果系统不支持运行时直接崩溃。这个不是编译期问题但很关键。然后在 JNI 代码里记得加一个初始化调用#include vtkAndroidRenderWindow.h #include vtkRenderWindow.h vtkSmartPointervtkRenderWindow window vtkSmartPointervtkAndroidRenderWindow::New();Android 上不能直接创建普通vtkRenderWindow必须用vtkAndroidRenderWindow或vtkAndroidRenderWindowInteractor子类它内部处理了ANativeWindow与 OpenGLES 上下文的绑定。这也是为什么编译时必须开VTK_ANDROID_SUPPORT。5.4 一个容易忽略的宏定义问题如果你是从桌面项目迁移过来的测试代码可能在初始化之前会调用vtkRenderWindow::SetGlobalMaximumNumberOfMultiSamples(0);或者设置一些桌面 OpenGL 的扩展选项。Android 的 GLES3 与传统桌面 OpenGL 的 API 集合差异很大很多 VTK 底层 check 在VTK_OPENGL_HAS_EGLON时并不会预编译桌面路径所以这些选项不会生效甚至可能因为调用了不存在的方法导致 crash。写 JNI 代码时建议直接#ifdef一个自己的宏比如VTK_ANDROID_BUILD这个宏在 VTK 源码里其实是存在的把桌面专用逻辑隔离开。验证签名阶段最好在真机上跑一个最小 demo创建vtkAndroidRenderWindow、设置RenderWindowInteractor、加载一个简单的 sphere polydata 并渲染。如果渲染黑屏但没崩溃基本可以锁定是 GLES2/GLES3 上下文问题而不是库的问题。6. 关于 Ubuntu 24.04 这套环境我还踩过的几个周边坑前面五个炸点都是 VTK 交叉编译的核心问题。但 Ubuntu 24.04 本身还有一些周边坑虽然不影响最终 so但会严重打断你的节奏。6.1 apt 源与依赖安装慢的问题Ubuntu 24.04 默认的 apt 源在国内访问很慢编译前要装 zip、unzip、ninja-build、openjdk 等基础工具如果一直卡在下载阶段后续什么都干不了。解决方案有几种最基本的先把 apt 源换成可用的镜像然后执行sudo apt update sudo apt install -y cmake ninja-build zip unzip openjdk-17-jdk这里装ninja是可选的VTK 用 Unix Makefiles 也能编但 Ninja 的输出更清晰出错时定位更快。实测下来两者编译时间没有明显差异。6.2 ccache 配置不当导致的问题如果你本机装了 ccache 并设置了CCACHE_PREFIX或CCACHE_DIR全局环境变量交叉编译时会导致一个很奇怪的现象编译产物一样但每次 configure 都会重新触发全量编译因为 ccache 对交叉编译器的hash_dir处理比较敏感。解决方法是给该项目的编译单独设置export CCACHE_DIR$HOME/.ccache-vtk-android不要用默认的~/.ccache。这样不仅避免串台还能保留桌面编译的缓存。6.3 磁盘空间和 inode 用量VTK 9.3.1 源码加 build 目录体积很容易超过 15GB且全是小文件在 ext4 上会消耗大量 inode。如果你用的是一块分区空间很小的虚拟机磁盘编译到一半报No space left on device且 df -h 显示还有空间那就是 inode 用光了。检查命令df -i $HOME/vtk-android-build如果Use%接近 100%赶紧清理其它项目缓存或者挪到一个更大的分区。别问我为什么强调这一点我第一次是在 WSL 的虚拟磁盘上编译的20GB 空间剩了 3GB结果 inode 用尽只能从头再来。6.4 关于 WSL 的额外提醒我看到热搜词里有 Ubuntu 24.04 和 WSL 相关的条目顺带提一句。WSL2 环境下编译 VTK Android 版理论上可行但需要注意WSL2 的跨文件系统性能非常差源码和 build 目录必须放在 WSL 的 ext4 文件系统内即~/下不要放在/mnt/c/。否则 CMake 生成阶段会因为文件 IO 极慢而显得像死机一样。如果你看到 configure 卡在Optimize for native binaries很久不动先检查路径位置再检查 resctrl 之类的 CPU 限制问题。7. 我最终沉淀下来的几件事这个项目做完之后有几个判断我认为是长期有效的干脆一起写出来。第一VTK 的 Android 编译不存在“一个命令行搞定”的灵丹妙药。网上流传的官方文档命令我试过好几次要么模块裁剪不够、要么链接期失败。主要是因为 VTK 版本、NDK 版本、CMake 版本三者的排列组合实在太多。解决问题的核心不是背命令行而是理解 module 依赖关系和 CMake 交叉编译的原理这样碰到任何版本的 VTK 都能从容应对。第二编译前先确定渲染后端。如果你的应用目标机型基本都是 2018 年之后的直接锁 GLES3如果需要兼容老设备最好在工程里准备两套 so或者在运行期动态探测 GPU 能力。但 VTK 的源码本身在 GLES2/GLES3 之间切换并不平滑跑起来再切换容易出状态残留。这件事必须在编译前决定。第三尽量把 build 脚本沉淀下来。我后来写了一个build_android.sh每次配置、构建、安装、验证全部封装成脚本哪怕三个月后再编译一次也不会慌乱。过程脚本比文档靠谱。最后再分享一个小技巧编译完成后别急着删 build 目录。VTK 的install目录和 build 目录里的CMakeCache.txt是后续排查问题的重要线索。如果集成阶段发现某个符号缺失回来看 build 目录里的CMakeFiles/CMakeError.log和CMakeOutput.log比重新跑一遍编译要快得多。这个习惯在我用 VTK 做渲染项目时救过我很多次。