在安卓上做三維可視化VTK 基本是繞不開的庫但它的交叉編譯從來都不是“拉源碼、敲 cmake、等結果”這么簡單。這次我在 Ubuntu 24.04 上折騰 VTK 9.3.1 的安卓版本前前后后花了三天踩了十幾個坑從 NDK 選版、CMake 裁剪、第三方依賴下載到內存 OOM、STL 符號找不到、OpenGL ES 渲染后端切換每一關都有點反直覺的地方。這篇文章就是完整的過程記錄把我踩過的坑、最終的可用配置命令、以及排查思路原原本本寫出來。如果你也正準備在 Linux 環(huán)境下給安卓交叉編譯 VTK或者編譯過程中已經遇到奇怪報錯這篇文章應該能幫你少走不少彎路。1. 項目概覽為什么要折騰 Ubuntu 24.04 VTK 9.3.11.1 需求背景安卓平臺三維可視化需要什么先說清楚這次項目的實際需求。我手頭要做的是一套醫(yī)學影像相關的三維展示模塊目標設備是一臺 arm64 架構的安卓平板需要在上面加載三維模型、做基本的旋轉縮放交互后續(xù)還要接一些 VTK 的 Filters 管線做數據處理。選型階段其實沒有太多懸念VTK 在醫(yī)學影像、科學可視化領域就是事實標準尤其 DICOM 讀取、等值面提取、三維體繪制這些能力直接用 VTK 遠比自己手搓劃算。但問題就出在“安卓”這兩個字上。VTK 本身是桌面端為主的項目官方對 Windows、Linux、macOS 的支持很成熟到了安卓側雖然官方倉庫里有VTK_ANDROID_SUPPORT這種宏但真要把它編出來還是要自己手工處理整套交叉編譯工具鏈。而且 VTK 的模塊體系非常龐大默認全量編譯光是模塊就幾百個如果一股腦全編到安卓上體積和編譯時間都會失控。1.2 版本與方案選型VTK 9.3.1 和 Ubuntu 24.04 的組合為什么選了 VTK 9.3.1當時 9.3.1 是 9.3 系列里比較穩(wěn)定的一個補丁版本修復了此前 9.3.0 的一些渲染后端問題同時它開始默認使用std::filesystem對 C17 的支持更干凈。比它更新的 9.4.x 當時還處于開發(fā)周期內我不太敢在關鍵項目里直接上開發(fā)版。Ubuntu 24.04 是當時新裝的系統(tǒng)正好也想借這個機會驗證一下新版 LTS 在交叉編譯場景下的表現(xiàn)。實測下來Ubuntu 24.04 默認源里的 CMake 是 3.28.x、Ninja 是 1.11.x這兩項都滿足 VTK 的構建要求不需要像以前那樣手工編譯工具鏈這一點比老版本系統(tǒng)省心很多。編譯方案上我一開始也猶豫過要不要直接用 Android Studio 的 Gradle 插件配合externalNativeBuild在構建應用時順帶編譯 VTK這個方案對于小庫還行但 VTK 太龐大了每次修改 CMake 配置都要經過 Gradle 這一層排查問題非常痛苦而且 Gradle 進程和 CMake 交叉編譯混在一起時緩存路徑、NDK 版本切換、編譯并發(fā)數都不好控制。最后我決定采用獨立交叉編譯的方式先用 NDK toolchain 在純命令行環(huán)境下把 VTK 編成靜態(tài)或動態(tài)庫然后再把產物以 prebuilt 的形式集成進安卓工程。這樣每一步都有明確的產物出問題了也知道該看哪里。2. 編譯前準備Ubuntu 24.04 交叉編譯環(huán)境搭建2.1 軟件清單JDK、SDK、NDK、CMake、Ninja 一個不能少交叉編譯 VTK 到安卓首先得把整套安卓 NDK 開發(fā)環(huán)境裝好。雖然純 C 編譯只需要 NDK 和 CMake但后續(xù)集成到安卓工程時不可避免要和 Gradle、SDK 打交道所以 JDK 和 Android SDK 最好一次性裝齊。我在 Ubuntu 24.04 上的安裝順序是這樣的JDK 17安卓 Gradle 插件新版本強制要求 JDK 17別再用 JDK 8 了。Android SDK包括platform-tools、build-tools、platforms。具體版本不是特別關鍵但build-tools建議用 34.x 或更高。Android NDK這里版本尤其重要我在下一節(jié)單獨說。CMake、NinjaUbuntu 24.04 的 apt 源里直接有版本滿足 VTK 要求直接apt install cmake ninja-build就行不需要從源碼折騰。還有一點容易忽略就是檢查系統(tǒng)中是否有桌面版的 OpenGL 開發(fā)庫。這個在交叉編譯時看似沒關系實際上 CMake 在解析 VTK 的RenderingOpenGL2模塊時如果檢測不到明確的 EGL/OpenGL ES 環(huán)境可能會嘗試去找宿主機的 OpenGL 頭文件結果就是“不干不凈”。保險的做法是把宿主機上不需要的開發(fā)庫先放著不管重點確保 NDK toolchain 的路徑在 CMake 配置時被正確指定。2.2 NDK 版本選擇r25c / r26b 的取舍NDK 版本是這次編譯過程里最大的一個暗坑我最初用的是當時最新版的 NDK r27結果在 VTK 編譯到大約三分之一時連續(xù)報出好幾處 C 標準庫相關的編譯錯誤。具體報錯內容是不同模塊里對某些std::符號的解析不一致這多半是 NDK 自帶 libc 實現(xiàn)和 VTK 9.3.1 的代碼存在兼容性偏差。VTK 9.3.1 發(fā)布那陣子NDK r25 和 r26 才是社區(qū)驗證比較充分的版本。最后我換成了 NDK r26b問題一下子消停了很多。后來我也在發(fā)行說明里確認了一下r27 對 C 運行時的改動確實比較多很多老一點的項目在切換到 r27 時都會遇到類似情況。如果你不想折騰我建議直接選 r26b這是目前兼容性最好、社區(qū)踩坑記錄也最少的一個版本。NDK r25c 也可以但 r26b 對 arm64-v8a 的編譯優(yōu)化更好一點構建產物在運行性能和體積上更有優(yōu)勢。安轉 NDK 的方式有兩種一是通過 Android Studio 的 SDK Manager 下載二是在命令行直接用sdkmanager或者手動解壓。我個人推薦手動解壓放到固定目錄比如$HOME/Android/Sdk/ndk/26.1.10909125這樣后續(xù)在 CMake 配置里寫ANDROID_NDK路徑時更直觀不受 Android Studio 項目的局部配置影響。2.3 目錄規(guī)劃與環(huán)境變量交叉編譯項目一定要養(yǎng)成“目錄清爽”的習慣。這次我建的目錄結構如下后面所有環(huán)節(jié)都圍繞它展開$HOME/vtk-android/ vtk-9.3.1/ # VTK 源碼目錄 build-arm64/ # arm64-v8a 的編譯目錄獨立于源碼方便刪掉重來 install-arm64/ # 編譯安裝產物目錄頭文件、lib、cmake 配置都放這里 third-party/ # 需要手動放置的第三方庫源碼包緩存不直接在源碼目錄里編譯而是用獨立的 build 目錄是 CMake 交叉編譯最基本的原則。這樣一旦配置出錯或者需要切換 ABI、切換 Release/Debug直接刪掉 build 目錄重來不會污染源碼。環(huán)境變量方面我維護了一個簡單的env_android.sh腳本放在$HOME/vtk-android/下export ANDROID_NDK$HOME/Android/Sdk/ndk/26.1.10909125 export ANDROID_SDK$HOME/Android/Sdk export ANDROID_PLATFORMandroid-26 export ANDROID_ABIarm64-v8a export PATH$ANDROID_NDK:$ANDROID_NDK/toolchains/llvm/prebuilt/linux-x86_64/bin:$PATH為什么要堅持把這些寫進環(huán)境變量而不是每次手動敲因為后續(xù) CMake 配置、安裝驗證、集成到 Android Studio 工程時會反復用到這些路徑寫死在一個腳本里可以避免路徑不一致導致的各種詭異問題。3. CMake 配置與策略詳解3.1 源碼準備與必須了解的關鍵參數VTK 源碼我直接從官方 Git 倉庫拉取切到v9.3.1標簽不要用 master。需要提醒的是VTK 源碼包里的ThirdParty目錄并不總是把所有依賴都替你準備好部分組件會因為版權或體積原因在 CMake 配置階段通過FetchContent去線上拉取。這就意味著如果網速不穩(wěn)定配置時可能卡在下載環(huán)節(jié)很久甚至直接失敗。正式配置 CMake 之前有幾個關鍵參數必須先理解清楚CMAKE_TOOLCHAIN_FILE交叉編譯的“靈魂”指定為 NDK 自帶的build/cmake/android.toolchain.cmake。ANDROID_ABI指定目標架構真機用arm64-v8a如果要在模擬器上調試可額外編一份x86_64。ANDROID_PLATFORM指定目標安卓系統(tǒng)的最低 API 級別。這里建議設成android-26或更高原因我后面在踩坑部分詳細講簡單說就是 VTK 9.3.1 用到了 C17 的std::filesystem系統(tǒng)底層的支持需要 API 24 以上。ANDROID_STLC 運行時庫推薦c_shared雖然產物里要多帶一個libc_shared.so但能避免多個動態(tài)庫之間符號沖突。BUILD_SHARED_LIBS構建動態(tài)庫。VTK 模塊太多全靜態(tài)編會非常慢而且不好裁剪。CMAKE_BUILD_TYPEReleaseDebug 版體積大、運行慢對移動端沒意義。3.2 完整 cmake 配置命令逐項注釋下面這條命令是我最終穩(wěn)定復現(xiàn)的完整配置一行行展開講清楚作用cmake -G Ninja \ -DCMAKE_BUILD_TYPERelease \ -DCMAKE_TOOLCHAIN_FILE$ANDROID_NDK/build/cmake/android.toolchain.cmake \ -DANDROID_NDK$ANDROID_NDK \ -DANDROID_ABIarm64-v8a \ -DANDROID_PLATFORMandroid-26 \ -DANDROID_STLc_shared \ -DBUILD_SHARED_LIBSON \ -DBUILD_TESTINGOFF \ -DVTK_BUILD_EXAMPLESOFF \ -DVTK_BUILD_TESTINGOFF \ -DVTK_WRAP_PYTHONOFF \ -DVTK_WRAP_JAVAOFF \ -DVTK_USE_QVTKOFF \ -DVTK_GROUP_ENABLE_ViewsDONT \ -DVTK_GROUP_ENABLE_WebDONT \ -DVTK_GROUP_ENABLE_QtDONT \ -DVTK_GROUP_ENABLE_StandAloneDONT \ -DCMAKE_INSTALL_PREFIX$HOME/vtk-android/install-arm64 \ -S $HOME/vtk-android/vtk-9.3.1 \ -B $HOME/vtk-android/build-arm64這里最值得解釋的是幾個VTK_GROUP_ENABLE_*選項。VTK 9 之后引入了一個“組件組”的機制用來批量控制一個主題下的所有模塊。比如Web組里包含了VTK::WebGL、VTK::WebPython這些和網頁可視化相關的模塊在安卓上完全沒有用處Qt組包含QVTK交互組件安卓端并不會用桌面 Qt 做界面必須關掉Views組是圍繞高層視圖框架的對安卓來說屬于無用負載。有讀者可能會問為什么不把所有組都設成DONT只留最核心的渲染和過濾理論上可以但 VTK 的模塊依賴關系錯綜復雜你想要的FiltersSources可能又會依賴CommonColor、CommonDataModel這些模塊。全部手動控制反而不現(xiàn)實。所以我的策略是只關閉確定無用的高開銷組其余留給 VTK 的自動依賴解析去判斷這樣能在“減小體積”和“避免依賴地獄”之間取一個平衡。3.3 組件取舍哪些 VTK 模塊適合安卓哪些必須關掉經過實際編譯和運行驗證我最后保留的有效模塊集中在幾個地方Common*基礎模塊必然保留數量不多但被所有其他模塊依賴。FiltersCore、FiltersSources、FiltersGeneral這類算法模塊對醫(yī)學數據處理很有用保留。IOCore、IOImage、IOMesh解決模型和圖像文件的讀寫保留。RenderingCore、RenderingOpenGL2是渲染主鏈路必須保留安卓下它會自動走 OpenGL ES 后端。InteractionStyle、InteractionWidgets提供基礎的相機操控和拾取對觸摸屏場景算基本配置保留。需要關掉的除了 Qt、Web、Views 之外還有RenderingVolumeOpenGL2、RenderingRayTracing這類重渲染模塊。如果項目里確實要做體繪制可以單獨開但體積膨脹和編譯時間增長都相當明顯我的建議是先用最簡方案跑通全流程后續(xù)再按需補模塊。另外VTK_WRAP_PYTHON和VTK_WRAP_JAVA這兩個選項非常容易踩坑。很多人看到默認 ON 就忽略了結果 CMake 配置階段去宿主機找 Python 和 Java 開發(fā)環(huán)境然后又因為架構不匹配報一堆奇怪錯誤。這次明確關掉同時VTK_USE_QVTKOFF也是為了避免 CMake 去查找 Qt5在純交叉編譯環(huán)境里這是必須的。4. 編譯執(zhí)行與產物檢查4.1 執(zhí)行編譯輸出信息怎么看配置完成后進入編譯階段我用的是 Ninja 構建系統(tǒng)所以編譯命令很簡單cd $HOME/vtk-android/build-arm64 ninja -j4這里必須強調一下并發(fā)數。如果你直接用默認的ninja相當于-j全核并發(fā)在大型 C 項目編譯時會瞬間把內存吃滿然后編譯器進程被系統(tǒng) OOM Killer 殺掉現(xiàn)象就是終端里冒出c: fatal error: Killed signal terminated program cc1plus。我在編譯到一半時被這個問題搞崩過兩次后來老老實實把并發(fā)數限制在 4 到 6單次編譯時間雖然拉長到 40 分鐘上下但整個過程穩(wěn)定不崩。編譯過程中可以留意兩類信息。一類是模塊編譯順序從輸出日志里能看出CommonCore → CommonDataModel → FiltersCore → Rendering這樣的依賴推進序列如果某個模塊編譯失敗順著當日志倒推基本就是它的上游依賴出了問題。另一類是警告信息比如結構體對齊、隱式類型轉換這類警告在安卓交叉編譯時很常見多數可以忽略但如果出現(xiàn)和EGL、GLES相關的警告一定要重視那通常是渲染后端姿勢不對的早期信號。4.2 install 與產物結構拿到一堆 .so 后該做什么編譯完成后執(zhí)行安裝ninja install這一步會把頭文件、動態(tài)庫、CMake package 配置文件統(tǒng)一拷貝到CMAKE_INSTALL_PREFIX指定的目錄。安裝完成后在install-arm64/下會看到比較干凈的產物結構install-arm64/ include/vtk-9.3/ lib/cmake/vtk-9.3/ lib/libvtkCommonCore-9.3.so lib/libvtkCommonDataModel-9.3.so lib/libvtkFiltersCore-9.3.so lib/libvtkRenderingCore-9.3.so lib/libvtkRenderingOpenGL2-9.3.so ...這一步的產物比我想象中多。一開始全量編譯時lib/下一個模塊文件能列一大屏光是.so就有上百個體積更是嚇人。后來按第三節(jié)的策略把無關組件關掉最終產物體積控制在了 100MB 出頭雖然對安卓應用包來說還是不低但已經處于可以接受的范圍。安裝完成后建議立刻做一個驗證確認生成的 .so 是 arm64 架構避免出現(xiàn)“編了半天結果是宿主機 x86 版本”的烏龍file $HOME/vtk-android/install-arm64/lib/libvtkCommonCore-9.3.so如果輸出里能看到ARM aarch64那說明交叉編譯這條路走通了。5. 踩坑實錄編譯過程中遇到的 7 個典型問題5.1 NDK 版本過高導致的編譯失敗這個坑我開頭已經劇透了但值得再展開講。用 NDK r27 編譯時報錯點分散在vtkCommonMath、vtkFiltersCore等多個模塊中錯誤信息看起來像是源碼里某個 C 標準庫函數沒有被正確識別。一開始我以為是 VTK 源碼的問題反復檢查了 Cocoa、系統(tǒng)庫路徑最后才懷疑到 NDK 版本上。換回 r26b 之后同樣的源碼、同樣的 CMake 配置一次通過。這給我的教訓是在交叉編譯老一點的開源項目時“用最新 NDK”并不等于“最好”反而可能引入非預期的編譯兼容性問題。如果你也是剛接觸某個版本的 VTK 編譯建議直接查詢一下該版本發(fā)布時社區(qū)推薦的 NDK 版本區(qū)間不要一味求新。5.2 內存不足導致的 OOM Kill前面提過的cc1plus ... Killed問題本質就是內存耗盡了。VTK 的核心模塊里有些源文件依賴模板展開非常重單個編譯單元吃掉 2-3 GB 內存很正常。如果同時開十幾個并發(fā)16 GB 內存的機器也會撐不住。我的解決辦法分成兩層第一層是把 Ninja 并發(fā)數限制在-j4第二層是給系統(tǒng)加一個 8 GB 的 swapfile給編譯過程留一點緩沖余地。加了 swap 之后即使偶發(fā)內存峰值也不會立刻觸發(fā) OOM編譯穩(wěn)定性提升非常明顯。5.3 CMake 配置階段卡在第三方依賴下載VTK 源碼里ThirdParty目錄雖然自帶了不少庫但個別依賴我當時碰到的是OpenVR相關的組件在配置階段會嘗試從 GitHub 下載源碼包。如果網絡環(huán)境不好配置過程會一直停留在Fetching ...狀態(tài)看起來像是卡死了實際上是在反復重試下載。處理方式有兩個方向一是在 CMake 配置時徹底關閉這些可選依賴既然安卓平臺用不到 VR 相關功能直接在配置命令里加上-DVTK_MODULE_ENABLE_VTK_RenderingOpenVROFF這類開關二是提前把對應依賴源碼包下載好放到third-party/緩存目錄再通過FETCHCONTENT_SOURCE_DIR_name指向本地路徑。我最后選擇了前者理由很簡單不用的功能就別給自己找麻煩。5.4 OpenGL 與 EGL 的桌面/移動端之爭這個問題藏得比較深。VTK 的RenderingOpenGL2模塊在桌面端默認走 OpenGL移動端應該走 OpenGL ES 和 EGL。當你用 NDK toolchain 交叉編譯時CMake 雖然能識別出 Android 平臺但有些依賴模塊仍然可能試圖尋找桌面 OpenGL 的開發(fā)庫。我當時遇到的一個具體報錯是找不到EGL/egl.h頭文件原因是 VTK 某個子模塊在 include 路徑上不夠干凈或者是我宿主機上裝的桌面 OpenGL 開發(fā)庫干擾了查找。解決辦法是確保編譯環(huán)境里沒有多余的OPENGL_INCLUDE_DIR等變量干擾同時重新檢查 NDK toolchain 里的 EGL 頭文件路徑是否被正確加進了 include 搜索列表。VTK 9.3.1 在本地沒有顯式指定這些路徑時一般能根據 NDK 自動找到$ANDROID_NDK/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/EGL/但如果你動過CMAKE_SYSROOT之類的變量就要特別注意了。5.5 std::filesystem 與低 API Level 的符號缺失這個坑和ANDROID_PLATFORM的選擇直接相關。VTK 9.3.1 里不少模塊已經換用 C17 的std::filesystem來處理文件路徑。而在 Android NDK 中std::filesystem的完整支持依賴于 libc 和系統(tǒng) API level如果ANDROID_PLATFORM設置得太低比如android-21或android-23編譯時可能通過了一部分但在鏈接階段報出undefined reference to std::filesystem::__...這類錯誤。我最初設置的是android-24偶爾還會蹦出這種鏈接錯誤后來統(tǒng)一改成android-26配合 r26b 的 NDK就再沒出現(xiàn)過。所以這里直接給出結論編譯 VTK 9.3.1 安卓版本時ANDROID_PLATFORM不要低于android-26。5.6 誤開 Qt / Java 組件引發(fā)的連環(huán)錯誤VTK 的 CMake 配置默認值比較“桌面友好”如果你不做任何組控制它會嘗試啟用 Qt 相關的 QVTK 組件、Java Wrapping 組件。在安卓交叉編譯環(huán)境里這些組件要么找不到對應的開發(fā)庫要么即使找到了也是宿主機的 x86 版本配置階段就會直接失敗。我第二次嘗試編譯時就是因為忘了關Qt組日志里反復出現(xiàn)Could NOT find Qt5的提示后來加上-DVTK_GROUP_ENABLE_QtDONT之后問題立刻消失。Java Wrapping 也是同理VTK_WRAP_JAVAOFF必須顯式設置否則 CMake 會去宿主機找 JNI 頭文件雖然不一定報錯但產出的庫根本不是安卓能用的屬于“安靜地犯錯”。5.7 產物體積失控與裁剪優(yōu)化第一次成功編譯之后我ninja install發(fā)現(xiàn)產物體積直接奔著 400MB 以上去了。這對桌面端不算什么但對安卓安裝包來說完全不可接受。體積削減主要依賴兩個動作一是嚴格關閉用不到的組件組這點在第三節(jié)已經做了二是把CMAKE_BUILD_TYPE設置為Release不要用DebugDebug 模式下生成的符號和未內聯(lián)的模板代碼會讓庫體積成倍上漲。做完這兩步之后產物從 400MB 降到 100MB 出頭鏈接進最終 APK 時還能再靠 ABI 篩選和資源壓縮壓掉一部分。對一個醫(yī)學影像展示場景來說這個體量基本可以接受。6. 集成 Android 工程與后續(xù)擴展建議6.1 將 .so 與頭文件接入 jniLibs拿到 install 目錄里的 .so 后接下來要解決的是“怎么讓安卓應用真正調用它”。最簡單的做法是走 NDK 的 jniLibs 機制把lib/下的所有 .so 文件按 ABI 目錄結構拷貝到安卓工程里cp -r $HOME/vtk-android/install-arm64/lib/*.so $PROJECT/app/src/main/jniLibs/arm64-v8a/同時在app/build.gradle里聲明 ABI 過濾避免 x86 模擬器或 32 位設備誤加載android { defaultConfig { ndk { abiFilters arm64-v8a } } }如果你在 C 層使用 JNI不要忘了把libc_shared.so也一起拷貝進去因為ANDROID_STLc_shared模式下所有動態(tài)庫都依賴這個共享 C 運行時。初期我漏掉了這個文件導致應用啟動時拋出UnsatisfiedLinkError排查了將近兩個小時才定位到。6.2 使用 CMake 直接引用外部 prebuilt 庫如果項目本身有大量 native 代碼更推薦的做法是在自己的CMakeLists.txt里直接引用 VTK 的 prebuilt 庫通過find_package(VTK)的方式完成加載。前提是編譯 VTK 時的 ABI 和工具鏈參數與 Android Studio 里 CMake 配置的參數保持一致。示例配置如下cmake_minimum_required(VERSION 3.22) project(vtk_android_demo) set(CMAKE_PREFIX_PATH $ENV{HOME}/vtk-android/install-arm64) find_package(VTK REQUIRED COMPONENTS CommonCore CommonDataModel FiltersCore FiltersSources IOImage RenderingCore RenderingOpenGL2 InteractionStyle ) add_library(native-lib SHARED native-lib.cpp) target_link_libraries(native-lib PRIVATE ${VTK_LIBRARIES})這里有個容易忽略的點find_package(VTK)找到的 CMake 配置里打包了不少編譯選項和 include 路徑但這些路徑是相對于當初 VTK 安裝目錄的絕對路徑。如果你把 install 目錄從一臺機器拷貝到另一臺機器或者挪了位置就必須重新執(zhí)行ninja install或者重新配置一次否則會報一堆路徑錯誤。6.3 后續(xù)擴展多架構編譯與體積進一步壓縮當前方案只編譯了arm64-v8a對絕大多數現(xiàn)代安卓設備夠用。但如果要考慮低端 32 位設備或模擬器調試場景可以在相同環(huán)境下再配置一個armeabi-v7a或x86_64的 build 目錄把 ABI 相關的變量換掉即可cmake -G Ninja \ -DCMAKE_TOOLCHAIN_FILE$ANDROID_NDK/build/cmake/android.toolchain.cmake \ -DANDROID_ABIx86_64 \ -DANDROID_PLATFORMandroid-26 \ -DANDROID_STLc_shared \ ...其余參數保持一致 -B $HOME/vtk-android/build-x86_64多架構各自獨立編譯的好處是每個編譯目錄的緩存互不干擾出現(xiàn)問題時可以單獨刪除某個架構的 build 目錄重新來不需要動其他架構的產物。如果對 APK 體積有極致要求還能在鏈接階段使用llvm-strip剔除動態(tài)庫里的無用符號實測下來可以再壓掉 10% 到 20% 的體積不過這已經是后話了。我個人在實際操作中的體會是VTK 安卓交叉編譯這件事真正難的不是 CMake 命令本身而是對 VTK 模塊體系和 NDK 工具鏈的理解。版本組合、組件裁剪、并發(fā)控制、API level 這些變量每一個都能在某一個階段突然跳出來給你上一課。如果你也是第一次折騰建議嚴格按照“先最小集跑到 install、再加模塊、再調體積”這個節(jié)奏推進大概率能比我少熬兩個夜。