最早接到這個任務(wù)時我原本以為只是把桌面版的 VTK 用 CMake 交叉編譯到 Android 平臺照著官方文檔跑一遍就行。真正動手之后才發(fā)現(xiàn)Ubuntu 24.04 配合 VTK 9.3.1 這套組合坑點比我想象的多得多光是解決鏈接期報錯就花了我兩個晚上。這篇文章就是一次完整復(fù)盤從環(huán)境準(zhǔn)備、CMake 配置到鏈接階段連環(huán)炸、最終產(chǎn)物驗證把我實測踩過的每一個坑、當(dāng)時的判斷依據(jù)、以及最終怎么繞過去的全部記錄下來。先說清楚我做的到底是什么。VTKVisualization Toolkit是一個開源的三維可視化庫桌面端常用在醫(yī)學(xué)影像、科學(xué)計算可視化、點云渲染這些場景。我這里的目標(biāo)是編譯出能在 Android 上運行的 VTK 9.3.1 動態(tài)庫后續(xù)要接進(jìn) Android Studio 的 JNI 工程里。編譯環(huán)境是 Ubuntu 24.04 LTSNDK 版本 r25cCMake 3.29JDK 17。如果你也準(zhǔn)備干同樣的事可以參考我這套流程但我不保證完全適用你的環(huán)境組合畢竟 NDK 和 CMake 的版本搭配足夠讓人折騰一陣子。1. 為什么非要在 Linux 上給安卓交叉編譯 VTK先回答一個很多人會問的問題VTK 官方不是有現(xiàn)成的 Android 構(gòu)建腳本嗎為什么不直接用VTK 倉庫里確實有CMakeLists.txt和官方的 Android 工具鏈支持但官方提供的只是“構(gòu)建入口”不是“現(xiàn)成產(chǎn)物”。官方 CI 會出一些預(yù)編譯包但版本更新滯后且不一定包含你需要的模塊組合。比如我需要的是帶Rendering、Filters、IO這幾個核心模塊同時要能用 OpenGLES 渲染的版本預(yù)編譯包要么缺模塊要么渲染后端對不上最后還是得自己編。另外一個現(xiàn)實問題是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 相關(guān)的兼容性警告。我后面會細(xì)說怎么處理。再說個更實際的原因Windows 上裝 NDK 交叉編譯也不是不行但 VTK 的 Java/Android 包裝層、vtkJavaUtil、JNI 相關(guān)的符號生成在 Linux 環(huán)境下更順暢。而且后續(xù)如果你要跑測試用例、用ctest驗證編譯結(jié)果Linux 下的腳本兼容性明顯更好。所以我個人建議是不要試圖在 Windows 上繞直接用 Linux 做交叉編譯省下的時間足夠你多踩兩個別的坑。還有一個隱藏動機是——Android 端的 VTK 往往不只是渲染還需要做模型處理、坐標(biāo)變換、數(shù)據(jù) IO。這時候光用vtkAndroidRenderWindow不夠需要把整套 VTK 編進(jìn)去這就繞不開完整編譯。所以這個項目本質(zhì)上是“在 Linux 上制作一個給安卓用的 VTK SDK”你說它是交叉編譯其實更接近“定制化 SDK 構(gòu)建”。小結(jié)自己做編譯不是為了顯得專業(yè)而是為了拿到一個干凈、可裁剪、帶特定渲染后端和模塊集的產(chǎn)物。這決定了后面所有 CMake 參數(shù)怎么選。2. 環(huán)境準(zhǔn)備Ubuntu 24.04 上最容易翻車的三個環(huán)節(jié)2.1 CMake 版本Ubuntu 自帶的不一定夠用Ubuntu 24.04 的官方源里CMake 版本是 3.28.x。VTK 9.3.1 官方 CMakeLists 寫著最低 3.16理論上 3.28 夠用。但實際跑起來你會發(fā)現(xiàn)NDK r25c 里的android.toolchain.cmake在處理ANDROID_ABI和ANDROID_PLATFORM時有一些只在 CMake 3.21 才完善的行為比如對ANDROID_PLATFORM的字符串規(guī)范化。如果版本偏低可能會出現(xiàn)Invalid ANDROID_PLATFORM這類讓人摸不著頭腦的報錯。我一開始用自帶 CMake報了一個非常詭異的錯CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage這個錯表面看是編譯器沒找到但其實是 toolchain 文件解析出了問題。升級到 CMake 3.29從 Kitware 官方 apt 源裝之后同樣的配置一次通過。安裝方式不復(fù)雜無非是添加 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 的代號別復(fù)制成jammy否則會裝到舊版本。2.2 NDK 版本與 toolchain 文件路徑VTK 的 Android 編譯官方推薦 NDK r25 或 r26。我實測 r25c 匹配良好r26b 也能編但部分老模塊的-Werror會報警告升級成錯誤需要額外處理。建議直接用 r25c省心。下載之后解壓到一個沒有空格的路徑這點非常重要。比如我放到~/android-ndk-r25c而不是~/Program Files/Android/...?？崭駟栴}會在 CMake 生成階段引發(fā)各種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。這塊我在第三節(jié)詳細(xì)展開。2.3 JDK 版本與 Java 依賴如果你只是編 C 庫JDK 看似無關(guān)。但 VTK 的 Android 構(gòu)建里包含Wrapping/Java這一層它需要 JDK 和 Ant/Gradle 才能生成 Java 包裝類。我最初是純 C 需求沒裝 JDK結(jié)果 CMake 配置階段就中斷了Could NOT find Java。Ubuntu 24.04 默認(rèn)倉庫里有 OpenJDK 17安裝后記得設(shè)置JAVA_HOMEsudo apt install openjdk-17-jdk -y export JAVA_HOME/usr/lib/jvm/java-17-openjdk-amd64安裝完后CMake 能自動檢測到 Java但如果你不需要 Java 包裝層其實可以在配置時直接關(guān)閉。我是因為后續(xù)要自己寫 JNI 調(diào)用不需要 VTK 自動生成的 Java 層所以選擇了關(guān)閉-DVTK_WRAP_JAVAOFF。這一步能省掉非常多麻煩尤其是少碰 ant 和 javac 版本不匹配的破事。注意就算你不開 Java 包裝VTK 的 Android 構(gòu)建仍然會檢查 Java所以 JDK 還是要裝。這是 VTK 源碼里CMake/vtkAndroid.cmake對 Java 的隱式依賴?yán)@不過去。3. CMake 配置階段這些參數(shù)不調(diào)對后面全白干3.1 必須先了解 VTK 的模塊體系VTK 9.x 以 module 為組織單位默認(rèn)會編譯一大堆模塊包含vtkRenderingOpenGL2、vtkInteractionStyle、vtkIOMINC、vtkFiltersParallel等等。Android 平臺用不到桌面版的 OpenGL很多并行計算模塊也沒有意義。如果全編光編譯時間就夠睡兩覺還會因為模塊依賴關(guān)系在鏈接期瘋狂報 undefined reference。所以我推薦的思路是基于模塊分組做裁剪。VTK 提供了VTK_GROUP_ENABLE_*這類開關(guān)可以批量控制組內(nèi)的模塊是否啟用。常用的組有組名默認(rèn)狀態(tài)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 關(guān)鍵開關(guān)集合一套實測可用的 CMake 命令這里直接上我最終驗證通過的完整配置。源碼目錄我放在~/vtk-src版本標(biāo)簽是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很多參數(shù)一眼看不懂我解釋下幾個關(guān)鍵的含義VTK_ANDROID_SUPPORTON和VTK_ANDROID_BUILDON這是讓 VTK 走vtkAndroidRenderWindow、vtkAndroidRenderWindowInteractor這套 Android 特有的窗口和后端邏輯的開關(guān)。不開的話它會去找 X11 或者 Cocoa立刻掛掉。VTK_OPENGL_HAS_EGLONAndroid 上 OpenGL ES 需要 EGL 來管理上下文這個是核心。VTK_USE_XOFF關(guān)掉 X11 依賴不然鏈接時找不到libX11.so。VTK_REQUIRE_ANDROID_OPENGLES3ON這個我必須強調(diào)。VTK 默認(rèn)在 Android 上如果沒檢測到 GLES3會嘗試走 GLES2 的兼容路徑。但 GLES2 下很多 shader 寫法會出問題。我在集成測試階段發(fā)現(xiàn)GLES2 路徑渲染出來的模型經(jīng)常黑屏改成 GLES3 后端后一切正常。所以從編譯階段就鎖定 GLES3 最省事。BUILD_SHARED_LIBSON編成 .so。雖然后續(xù)也可以選擇靜態(tài)庫但 VTK 的模塊特別多全靜態(tài)編會導(dǎo)致一個巨大無比的 so加載慢且容易 OOM。動態(tài)庫方案更常見。3.3 關(guān)于 Android ABI 的選擇這個項目里我只編譯了arm64-v8a。按說應(yīng)該連armeabi-v7a一起編但 VTK 9.3.1 在 32 位 ARM 上的 CMake 配置經(jīng)常卡在flatbuffers的生成階段問題很多。如果你只是做現(xiàn)代 Android 設(shè)備適配建議只出 arm64。實在要兼容老設(shè)備建議單獨再開一個 build 目錄專門編 32 位不要混在同一個 CMake 目錄里切 ABI這會引發(fā)緩存污染。這里有個容易被忽略的點ANDROID_PLATFORMandroid-26表示最低支持 Android 8.0。如果你的應(yīng)用 minSdk 是 21可以降到android-21但GLES3 支持在 ndk 的 API level 21 之后就已經(jīng)有綁定了降到 21 不影響 GLES3。我之所以用 26是為了保證 Android Native 的AAssetManager接口穩(wěn)定避免兼容邏輯干擾問題。3.4 為什么 Qt 組必須關(guān)掉這個問題值得單獨說。VTK 的VTK_GROUP_ENABLE_Qt默認(rèn)是開啟的它會把vtkGUISupportQt、vtkGUISupportQtQuick等模塊納入編譯這些模塊需要桌面版 Qt5 或者 Qt 6 的QtWidgets頭文件。而 Qt 并沒有針對安卓的標(biāo)準(zhǔn) apt 包就算你通過android_arm64_v8a的 Qt 安裝包配好了VTK 的 Qt 模塊在 Android 上也沒有實際意義——因為最終渲染還是走 OpenGL ESQt 只負(fù)責(zé) UI 殼子。所以直接關(guān)掉是唯一合理選擇不然 CMake 檢測階段就會報Qt5 not found白白打斷配置。4. 鏈接期連環(huán)炸我的失敗日志與逐條定位4.1 第一個炸點OpenGL 庫找不到CMake 配置通過后開始 make前 30% 編譯都比較順利雖然慢到鏈接某個模塊時突然報undefined reference to glBindBuffer undefined reference to eglCreateContext當(dāng)時我第一反應(yīng)是難道 OpenGLES 相關(guān)的庫沒鏈接進(jìn)去后來排查發(fā)現(xiàn)是VTK_USE_XOFF和VTK_OPENGL_HAS_EGLON的組合雖然開了但 CMake 某些模塊在find_package(OpenGL)階段會把OPENGL_LIBRARIES指到一個空變量導(dǎo)致鏈接命令里沒有-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對應(yīng)ANDROID_PLATFORM。如果你選的是android-21這個路徑就要改成21。NDK 從 r25 開始sysroot 里的庫路徑帶有 API level 子目錄很容易被忽略。提示libGLESv3.so在 NDK 里是一個很小的庫它和libGLESv2.so是同一個符號鏈接體系A(chǔ)ndroid 系統(tǒng)里只存在libGLESv2.so。但鏈接期寫libGLESv3.so是 OK 的因為 NDK 提供了這個 stub。4.2 第二個炸點atomic 符號和 libc 版本沖突在鏈接vtkCommonCore時又出現(xiàn)了一批undefined reference to __atomic_load_16。這個坑很經(jīng)典。NDK 的arm64-v8a目標(biāo)默認(rèn)支持部分原子操作但 16 字節(jié)的 atomic 操作比如std::atomiclong double或std::atomic__int128需要顯式鏈接libatomic.a。VTK 的某些頭文件在容器或數(shù)學(xué)計算里用了 16 字節(jié) atomic而 CMake 沒有自動幫你加上這個庫。解決辦法是手動設(shè)置-DCMAKE_EXE_LINKER_FLAGS-latomic -DCMAKE_SHARED_LINKER_FLAGS-latomic這里要注意-latomic必須出現(xiàn)在鏈接命令里且順序不能亂。有些教程推薦直接在target_link_libraries里加但 VTK 這種大工程手動全局鏈接標(biāo)志是最快的解法。4.3 第三個炸點內(nèi)存不足導(dǎo)致的編譯中斷編譯進(jìn)行到 70% 左右的時候我的機器16GB 內(nèi)存開始頻繁報c: fatal error: Killed signal terminated program cc1plus這不是代碼問題是并行編譯時內(nèi)存爆了。VTK 的vtkRenderingOpenGL2里有些模板頭文件比如vtkOpenGLPolyDataMapper單文件編譯可能占用 2-3GB 內(nèi)存。我用的-j$(nproc)把整機資源全部拉滿結(jié)果系統(tǒng) OOM直接殺掉了編譯器。處理辦法是降低并行度先make -j4。另外可以用-DVTK_ENABLE_WRAPPINGOFF減少一處內(nèi)存占用雖然我們沒開 Java wrap但 VTK 內(nèi)部還有 C wrapping 的流程。還有個經(jīng)驗是在鏈接大 so 時單線程比多線程更穩(wěn)。我干脆把編譯并行度控制到-j4鏈接時用-j1前后耗時其實差不了太多但穩(wěn)定性提高了一個檔次。別迷信 nproc編譯個大型庫貪多嚼不爛的道理依然成立。4.4 第四個炸點flatbuffers 生成器的宿主平臺問題VTK 里有個vtkIOMINC或者vtkFiltersParallelDIY模塊依賴diylog和flatbuffers。在交叉編譯中flatbuffers 需要先在宿主機也就是你的 Ubuntu上編譯一個flatc工具再拿去生成頭文件。問題在于如果 CMake 沒有明確宿主平臺和 target 平臺的區(qū)別它可能嘗試用 clang 交叉編譯的flatc去跑然后一運行就Exec format error。排查時看到這個錯誤我第一反應(yīng)是 CMake 緩存有問題。后來發(fā)現(xiàn)是VTK_GROUP_ENABLE_StandAloneOFF之后部分模塊的依賴被錯誤關(guān)閉導(dǎo)致 flatbuffers 的BUILD_EXECUTABLE選項被跳過了。解決辦法是單獨強制打開 flatbuffers 的 host 工具編譯-DVTK_BUILD_FLATBUFFERS_EXECUTABLEON或者在配置階段就加一個-DFLATBUFFERS_BUILD_EXECUTABLEON這樣 CMake 會先編譯一個宿主版本的flatc再進(jìn)入生成階段。這個問題不動手遇到真是猜不到。4.5 第五個炸點絕對路徑與 ccache 引發(fā)的迷之錯誤有一陣子鏈接時反復(fù)報No such file or directory: /home/myuser/vtk-android-build/../../../usr/include/python3.12/Python.h看到這個路徑的第一反應(yīng)是頭文件搜索路徑寫錯了../../../多跳了幾級。排查之后發(fā)現(xiàn)這其實和編譯參數(shù)無關(guān)是 CMake 在安裝階段用了緩存的CMAKE_PREFIX_PATH而那個路徑里混入了宿主機的/usr/include/python3.12。VTK 的 Python 包裝雖然沒開但 CMake 的find_package(Python3)還是會被某些模塊隱式調(diào)用一旦找到宿主機 Python就會把頭文件目錄寫進(jìn)INCLUDE_DIRECTORIES最終在 Android 鏈接命令里出現(xiàn)一個包含/usr/include的路徑。解決方法是顯式禁用-DVTK_USE_PYTHONOFF -DVTK_WRAP_PYTHONOFF同時清掉 build 目錄重新配置。這里強調(diào)一下修改 CMake 選項后一定要刪掉 CMakeCache.txt 或直接刪 build 目錄因為很多find_package結(jié)果會緩存不是所有選項變更都會觸發(fā)重新檢測。4.6 構(gòu)建成功的標(biāo)志經(jīng)過以上五輪折騰最終看到[100%] Built target vtkRenderingOpenGL2并且在lib/目錄下出現(xiàn)了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. 產(chǎn)物驗證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正常情況應(yīng)該看到libGLESv2.so libEGL.so libandroid.so liblog.so libc_shared.so libm.so libdl.so libc.so如果你的列表里出現(xiàn)了libX11.so、libGL.so或者libpython3.12.so說明 CMake 配置階段混入了宿主機依賴這個 so 裝到 Android 上必然UnsatisfiedLinkError。這時候要回頭檢查VTK_USE_X、VTK_USE_PYTHON這些開關(guān)。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 系統(tǒng)解析到實際驅(qū)動。5.3 AAR / JNI 集成前的最后準(zhǔn)備VTK 編譯出來的是一堆獨立的 so不是現(xiàn)成的 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 上下文如果系統(tǒng)不支持運行時直接崩潰。這個不是編譯期問題但很關(guān)鍵。然后在 JNI 代碼里記得加一個初始化調(diào)用#include vtkAndroidRenderWindow.h #include vtkRenderWindow.h vtkSmartPointervtkRenderWindow window vtkSmartPointervtkAndroidRenderWindow::New();Android 上不能直接創(chuàng)建普通vtkRenderWindow必須用vtkAndroidRenderWindow或vtkAndroidRenderWindowInteractor子類它內(nèi)部處理了ANativeWindow與 OpenGLES 上下文的綁定。這也是為什么編譯時必須開VTK_ANDROID_SUPPORT。5.4 一個容易忽略的宏定義問題如果你是從桌面項目遷移過來的測試代碼可能在初始化之前會調(diào)用vtkRenderWindow::SetGlobalMaximumNumberOfMultiSamples(0);或者設(shè)置一些桌面 OpenGL 的擴展選項。Android 的 GLES3 與傳統(tǒng)桌面 OpenGL 的 API 集合差異很大很多 VTK 底層 check 在VTK_OPENGL_HAS_EGLON時并不會預(yù)編譯桌面路徑所以這些選項不會生效甚至可能因為調(diào)用了不存在的方法導(dǎo)致 crash。寫 JNI 代碼時建議直接#ifdef一個自己的宏比如VTK_ANDROID_BUILD這個宏在 VTK 源碼里其實是存在的把桌面專用邏輯隔離開。驗證簽名階段最好在真機上跑一個最小 demo創(chuàng)建vtkAndroidRenderWindow、設(shè)置RenderWindowInteractor、加載一個簡單的 sphere polydata 并渲染。如果渲染黑屏但沒崩潰基本可以鎖定是 GLES2/GLES3 上下文問題而不是庫的問題。6. 關(guān)于 Ubuntu 24.04 這套環(huán)境我還踩過的幾個周邊坑前面五個炸點都是 VTK 交叉編譯的核心問題。但 Ubuntu 24.04 本身還有一些周邊坑雖然不影響最終 so但會嚴(yán)重打斷你的節(jié)奏。6.1 apt 源與依賴安裝慢的問題Ubuntu 24.04 默認(rèn)的 apt 源在國內(nèi)訪問很慢編譯前要裝 zip、unzip、ninja-build、openjdk 等基礎(chǔ)工具如果一直卡在下載階段后續(xù)什么都干不了。解決方案有幾種最基本的先把 apt 源換成可用的鏡像然后執(zhí)行sudo apt update sudo apt install -y cmake ninja-build zip unzip openjdk-17-jdk這里裝ninja是可選的VTK 用 Unix Makefiles 也能編但 Ninja 的輸出更清晰出錯時定位更快。實測下來兩者編譯時間沒有明顯差異。6.2 ccache 配置不當(dāng)導(dǎo)致的問題如果你本機裝了 ccache 并設(shè)置了CCACHE_PREFIX或CCACHE_DIR全局環(huán)境變量交叉編譯時會導(dǎo)致一個很奇怪的現(xiàn)象編譯產(chǎn)物一樣但每次 configure 都會重新觸發(fā)全量編譯因為 ccache 對交叉編譯器的hash_dir處理比較敏感。解決方法是給該項目的編譯單獨設(shè)置export CCACHE_DIR$HOME/.ccache-vtk-android不要用默認(rèn)的~/.ccache。這樣不僅避免串臺還能保留桌面編譯的緩存。6.3 磁盤空間和 inode 用量VTK 9.3.1 源碼加 build 目錄體積很容易超過 15GB且全是小文件在 ext4 上會消耗大量 inode。如果你用的是一塊分區(qū)空間很小的虛擬機磁盤編譯到一半報No space left on device且 df -h 顯示還有空間那就是 inode 用光了。檢查命令df -i $HOME/vtk-android-build如果Use%接近 100%趕緊清理其它項目緩存或者挪到一個更大的分區(qū)。別問我為什么強調(diào)這一點我第一次是在 WSL 的虛擬磁盤上編譯的20GB 空間剩了 3GB結(jié)果 inode 用盡只能從頭再來。6.4 關(guān)于 WSL 的額外提醒我看到熱搜詞里有 Ubuntu 24.04 和 WSL 相關(guān)的條目順帶提一句。WSL2 環(huán)境下編譯 VTK Android 版理論上可行但需要注意WSL2 的跨文件系統(tǒng)性能非常差源碼和 build 目錄必須放在 WSL 的 ext4 文件系統(tǒng)內(nèi)即~/下不要放在/mnt/c/。否則 CMake 生成階段會因為文件 IO 極慢而顯得像死機一樣。如果你看到 configure 卡在Optimize for native binaries很久不動先檢查路徑位置再檢查 resctrl 之類的 CPU 限制問題。7. 我最終沉淀下來的幾件事這個項目做完之后有幾個判斷我認(rèn)為是長期有效的干脆一起寫出來。第一VTK 的 Android 編譯不存在“一個命令行搞定”的靈丹妙藥。網(wǎng)上流傳的官方文檔命令我試過好幾次要么模塊裁剪不夠、要么鏈接期失敗。主要是因為 VTK 版本、NDK 版本、CMake 版本三者的排列組合實在太多。解決問題的核心不是背命令行而是理解 module 依賴關(guān)系和 CMake 交叉編譯的原理這樣碰到任何版本的 VTK 都能從容應(yīng)對。第二編譯前先確定渲染后端。如果你的應(yīng)用目標(biāo)機型基本都是 2018 年之后的直接鎖 GLES3如果需要兼容老設(shè)備最好在工程里準(zhǔn)備兩套 so或者在運行期動態(tài)探測 GPU 能力。但 VTK 的源碼本身在 GLES2/GLES3 之間切換并不平滑跑起來再切換容易出狀態(tài)殘留。這件事必須在編譯前決定。第三盡量把 build 腳本沉淀下來。我后來寫了一個build_android.sh每次配置、構(gòu)建、安裝、驗證全部封裝成腳本哪怕三個月后再編譯一次也不會慌亂。過程腳本比文檔靠譜。最后再分享一個小技巧編譯完成后別急著刪 build 目錄。VTK 的install目錄和 build 目錄里的CMakeCache.txt是后續(xù)排查問題的重要線索。如果集成階段發(fā)現(xiàn)某個符號缺失回來看 build 目錄里的CMakeFiles/CMakeError.log和CMakeOutput.log比重新跑一遍編譯要快得多。這個習(xí)慣在我用 VTK 做渲染項目時救過我很多次。