各位戰士，歡迎來到第二十四天的戰場。昨天，我們使用 R8 和資源壓縮，對 APK 內部的「贅肉」進行了清理，讓我們的 APK 變得更精簡。但是，傳統 APK 的模式本身就有一個根本性的問題——它是一個「通用包裹」。

想像一下，為了支援所有前線的士兵，我們的後勤部隊準備了一個巨大的通用補給箱。裡面不僅有適用於熱帶作戰的短袖（mdpi 圖片資源），也有適用於雪地作戰的棉衣（xxxhdpi 圖片資源）；不僅有給 A 型步槍的子彈（ARMv7 原生庫），也有給 B 型狙擊槍的子彈（x86_64 原生庫）。

結果就是，每一位士兵，無論他在哪個戰區、用什麼武器，都必須背著這個包含了所有他用不上裝備的巨大包裹。這就是傳統的「胖 APK (Fat APK)」困境。

今天的任務，就是學習如何使用現代化的發佈格式——Android App Bundle (AAB)——來徹底改變這種低效的投放模式，為每一位使用者實現「精準空投」。

革命性武器：Android App Bundle (AAB)

Android App Bundle (.aab) 是一種發佈格式，而不是一個可安裝的 APK。你將一個包含了應用程式所有程式碼和資源（針對所有設備配置）的 .aab 檔案上傳到 Google Play，然後神奇的事情就發生了。

這個過程被稱為 Google Play 的動態交付 (Dynamic Delivery)：

1. 你將一個 AAB 檔案上傳到 Play 管理中心。
2. 當一位使用者從 Play 商店下載你的應用時，Google Play 的伺服器會分析該使用者的設備規格（例如：CPU 架構是 arm64-v8a，螢幕密度是 xxhdpi，語言是 zh-TW）。
3. Play 會即時地從你的 AAB 中提取僅僅符合該設備需求的程式碼和資源，為這位使用者產生一個量身訂製的、最佳化的 APK。
4. 使用者最終下載到的，就是這個體積極小的 APK，裡面不含任何多餘的檔案。

透過 AAB，我們不再需要手動管理複雜的 APK Splits。我們只需要建構並上傳一個 AAB，Google Play 就會為我們處理剩下的一切。

如何建構 AAB？
在 Android Studio 中，這只是一次點擊的區別：
Build > Build Bundle(s) / APK(s) > Build Bundle(s)

或者使用 Gradle 指令：
./gradlew bundleRelease

進階戰術：動態功能模組 (Dynamic Feature Modules)

AAB 的威力不僅僅在於最佳化初始安裝。它還帶來了一項革命性的能力：按需交付功能。

動態功能模組 是你應用程式的一部分功能（包含程式碼和資源），但它不被包含在初始安裝的基礎 APK 中。使用者只有在主動要使用這個功能時，應用程式才會請求 Google Play 在背景下載並安裝它。

適用戰場：

• 不常用的重型功能：例如應用內的「影片編輯器」、「客服真人聊天」等，可能只有 5% 的使用者會用到。
• 大型資源：例如遊戲的高畫質資源包、AR 功能所需的大型 3D 模型。
• 教學或新手引導：只有新使用者需要，可以在他們完成引導後移除。

作戰流程（高層次）

1. 在 Android Studio 中建立一個新的「Dynamic Feature Module」。
2. 將該功能的所有程式碼、資源、Assets 放入這個模組中。
3. 在你的主應用模組中，添加 Play Core Library 依賴。
4. 當需要觸發下載時，呼叫 Play Core API：

// 獲取 SplitInstallManager 實例
val splitInstallManager = SplitInstallManagerFactory.create(context)

// 建立一個請求
val request = SplitInstallRequest.newBuilder()
    .addModule("my_dynamic_feature") // 你的模組名稱
    .build()

// 開始安裝
splitInstallManager.startInstall(request)
    .addOnSuccessListener { sessionId -> /* 監聽安裝進度 */ }
    .addOnFailureListener { exception -> /* 處理失敗 */ }

透過這種方式，應用的初始下載體積可以被極大地縮減，讓使用者以最快的速度開始使用核心功能。

驗收戰果

• Play 管理中心：在你上傳 AAB 後，Play 管理中心會提供一份詳細的報告，告訴你相較於傳統的通用 APK，你的應用為不同設備的使用者節省了多少下載體積。

• 本機測試：你可以使用 Google 開發的 bundletool 命令列工具，或者直接透過 Android Studio，來為特定設備產生 APK 並進行本機安裝測試，以驗證動態交付的行為。

今日總結

今天，我們學習了 APK 瘦身術的下半部分，從「優化內容」轉向了「革新交付方式」。

• 我們拋棄了傳統的「胖 APK」模式，擁抱了現代化的 Android App Bundle (AAB) 發佈格式。

• 我們理解了 Google Play 的動態交付是如何為每位使用者產生量身訂製的最佳化 APK，從而縮減了初始安裝大小。

• 我們學習了使用動態功能模組，將非核心功能設定為按需下載，實現了應用程式的模組化和極致的體積最佳化。

從單體式 monolithic 到模組化 modular，這不僅僅是技術的演進，更是開發思維的轉變。

我們的應用程式現在「身輕如燕」。但是，當它在背景執行任務時，是否會像一頭笨重的巨獸一樣消耗電量？明天，我們將來學習如何紀律嚴明地管理【後台任務】，請出我們的王牌部隊——WorkManager。

我們明天見！