【2026 最新】R8 分析教學：Android 官方 Skills 怎麼驗收？六步完成 Release 前後對照

AI 幫你刪了幾條 Android 保留規則，App 也成功編譯了，你敢直接上線嗎？這篇 R8 分析教學，要帶你把「看起來合理的建議」接到真正的 Release 產物，確認變小之後，原本的功能仍然走得通。

寫給第一次接觸 Android 最佳化、願意跟著專案操作的讀者：先用白話理解 Skill、R8 與保留規則，再做一次只改一處的前後對照。進入指令部分前，需要已有 Android Studio、SDK，以及可成功建置的小型 App；還沒準備好，可以先讀懂驗收方法。

本文按 2026 年 10 月 18 日的官方文件與原始碼整理。AlphaLab 本次環境未配置 Android SDK，以下是操作與驗收方法，沒有執行 App 建置或量得縮減比例；官方報告截圖與使用者故障回報會在各自段落標明。

先說結論：R8 分析教學的把手是「建議 → 單一變更 → Release 驗收」

把 R8 想成搬家前的整理員：不用的物品丟掉，常用動線重新安排，標籤也可能換成更短的名字。keep rules（保留規則）就是貼在物品上的「這個要留、這個名字別改」紙條。紙條貼滿整間屋子，整理空間就變小；亂撕紙條，又可能把靠特殊方式使用的東西收走。

• 先保存同一專案的基準 APK、規則與測試結果，再請 Skill 提建議。
• 一輪只採納一項規則修改；升級工具鏈另開一輪，避免兩種效果混在一起。
• 報告分數、APK 位元組與功能正確性，各自留一份證據。
• 裝到指定 API 版本的裝置上測試；失敗就還原候選修改，維持原本的驗收條件。

先懂三個零件：Skill 給方法，R8 改程式，驗收看交付

Android skills 是給 AI 程式代理使用的指令與資源包。你可以把它當作專業工作手冊；代理讀手冊、查看專案，再調用建置工具。它與實際執行最佳化的 R8 編譯器是兩個零件。想補上手冊的載入方式，可先讀 Agent Skill 與 SKILL.md 入門。

R8 做 shrinking（移除未用程式碼）、optimization（調整程式結構）與 obfuscation（縮短名稱）。像反射這種「執行時才用字串找類別或欄位」的路徑，需要額外告訴整理員哪些物品會被使用。這也是 官方排錯指南把反射列為最佳化後崩潰的重要排查方向的原因。

在本文查核的 r8-analyzer 原始規格裡，工具會檢視建置設定與保留規則，並且明訂只研究、提出建議，不修改檔案。我們另外安排變更與驗收回合，讓每個差異都能追到一個原因；這與 程式代理測試驗收的原則相通。

①「先留原樣」：建立可還原的 Release 基準

最常見的起步問題是：還沒量原始版本，就讓代理開始改。先找一個已能正常建置、沒有未保存修改的範例專案。若從零開始，可在 Android Studio 用 Empty Activity 建立 App，先讓原版執行成功；正式業務專案則使用獨立分支或副本。

git status --short
git rev-parse HEAD
./gradlew --version
./gradlew :app:tasks --all

這四行分別看工作目錄差異、程式版本、Gradle／JVM 資訊與可用工作。AGP 是 Android Gradle Plugin，要另外從根目錄建置檔或 gradle/libs.versions.toml 記錄；R8 通常隨 AGP 提供，若設定過替換版本，也要查建置解析結果。Gradle 版本不等於 AGP 版本。版本如何改變操作路徑，可接著讀 依專案版本選擇 Skill 操作。

確認目標是已啟用 R8 的 Release variant（建置變體）。Kotlin DSL 常見設定是 isMinifyEnabled = true 與 isShrinkResources = true，實際接法依專案採用的 DSL；官方啟用指南也列出 AGP 9.3 的新設定形式。若原本尚未啟用最佳化，先將「啟用並修到功能通過」當作獨立準備階段，再開始刪規則實驗。

./gradlew :app:assembleRelease

本文以 module 名稱 app、沒有 product flavor 的 release 為例；你的工作名稱以剛才的 tasks 清單為準。保存實際輸出 APK、建置日誌、完整生效規則與 mapping.txt。映射檔像新舊名字對照簿，之後可還原混淆堆疊；下一輪建置可能覆寫它，先複製到專案外的驗收資料夾。

基準還要真的安裝、啟動與操作。Release APK 的簽署要先依專案配置完成，使用測試裝置與測試資料；不要把 Debug APK 的成功當作這一欄。保留裝置型號、API、App 版本、APK 的 SHA-256、檔案位元組數與各測例結果，之後才知道兩輪比的是什麼。

②「只請它分析」：安裝 r8-analyzer，再核對實際位置

已有 Android CLI 與 Android skills 環境後，在範例專案根目錄執行下列指令。這次只指定一個 Skill，不安裝整套。

android skills add r8-analyzer --project=.
android skills list --project=.

CLI 的 --project 限定專案範圍；--agent 則可指定代理。按安裝輸出與你的代理設定找到真正的 r8-analyzer/SKILL.md，記下其路徑、內容雜湊與版本來源。別把網頁範例中的 .agents/skills 當成每台電腦的固定答案。

給代理一個明確任務：「請使用 r8-analyzer 分析這個 App 的 Release 保留規則，先回報 AGP、R8 與可驗證的規則影響。保留原始檔案，將候選修改與驗收測例分開列出；資料不足的數字標成未量測。」分析結束，再檢查 git diff，確認業務程式、測試與規則沒有被改動。

③「先看工具鏈」：R8 分析教學的三條報告路徑

為什麼別人一行指令有報告，你卻找不到工作？先按既有 AGP／R8 分流。下面採用 目前 Android 官方 Configuration Analyzer 文件的 HTML 報告路徑；Skill 的版本判斷可作線索，報告是否真的產生則逐項核對。

• AGP 9.3.0 以上：在有對應工作的專案執行 ./gradlew :app:analyzeReleaseR8Config，官方文件列出的 HTML 為 app/build/reports/r8/r8-config-analyzer-release.html。這個獨立分析工作會略過 APK／Bundle 產生，後續仍要建置 Release。
• AGP 9.2 或更早，且已有相容 R8 分析器：官方提供建置時輸出 HTML 的方式，核心參數是 -Dcom.android.tools.r8.dumpkeepradiushtmltodirectory=<output_directory>。先確認 R8 達到文件門檻 9.3.7-dev 或以上；若必須替換 R8，另開工具鏈驗收，不混進本輪規則對照。
• 現有工具鏈不滿足定量條件：先做規則與反射路徑的人工檢視，保存定性發現，將分數填「未產生」。你仍能建置前後 APK、測試行為；這輪的結論就只限於那些產物與測例。

較舊 AGP 的 HTML 路徑，在已確認 R8 相容後可這樣指定專案內輸出目錄：

mkdir -p "$PWD/tmp/r8-html"
./gradlew :app:assembleRelease \
  -Dcom.android.tools.r8.dumpkeepradiushtmltodirectory="$PWD/tmp/r8-html"

還有一個容易卡住的細節：截至本次查核，固定 commit 5bda39f 的 Skill 文字指向 protobuf 轉檔腳本，但該版本的目錄樹未隨附所指的 scripts/convert_pb_to_json.py 與 scripts/analyze.py；相關參考頁另內嵌轉換程式，且報告目錄寫法不完全一致。遇到這種差異，先核對 該版本完整檔案樹，使用上面的官方 HTML 流程，不讓代理憑空宣稱已完成轉換。這是特定版本的觀察，不是對所有後續版本的斷言。

讀報告時，三種 score 描述的是哪些類別、欄位與方法可接受相應最佳化。把它當作可整理範圍的線索；實際省下多少 APK 位元組，要回頭量產物。「可動的東西增加」與「這次搬走多少東西」要分兩欄。

④「一次撕一張紙條」：保存 A、只改一條，再保存 B

先挑一項你能說清用途的候選，例如報告指出兩條規則涵蓋相同類別。先查合併後的生效規則與依賴來源，再決定是否移除重複項。如果來自函式庫的 consumer rules，按該函式庫版本與官方說明處理；看到「重複」標籤，仍要確認保留下來的那條真的涵蓋原本需求。

建立一張變更卡：原規則、候選規則、反射／序列化用途、預期受影響類別、驗收步驟、還原方式。這輪固定 AGP、R8、依賴、簽署方式、variant 與測試資料，只改這張卡上的一項。保存 git diff -- proguard-rules.pro 時，換成你的實際規則檔位置；其他規則來源也一併檢查。

A 是原規則，B 是候選規則。兩者各建置 Release，把 APK、雜湊、映射與報告放進不同資料夾。macOS 可用 stat -f %z path/to/app.apk 讀檔案位元組、shasum -a 256 path/to/app.apk 留指紋；檔名換成剛才真實產物。

若要看是哪個部分改變，開啟 Android Studio 的 APK Analyzer，載入 APK 並比較另一個 APK。原始檔大小、估計下載大小與 Play 裝置分發大小，口徑不同；同一份紀錄固定一個口徑。本文不預填改善百分比，由你的 A 與 B 結果計算。

一個完整判讀例子是：B 的分析分數提高，APK 位元組減少，但下節任一測例失敗，這張變更卡仍是「不採用」。若功能通過、APK 幾乎不變，就記為規則整理，別硬說加速或瘦身成功。要主張啟動更快，另以相同裝置、條件與多輪量測的啟動測試回答。

⑤「真的走一遍」：Parcelable、反射與序列化三張考卷

測試要設在整理員看不見的使用路徑。在 A 上先通過，再對相同測例跑 B。用外部 UI 操作或既有 Release 相容測試設定驗收實際最佳化的 App，記錄被安裝 APK 的雜湊；普通本機單元測試可補邏輯，裝置上的產物行為另列結果。

• Parcelable：它是 Android 把物件打包、跨元件傳遞的機制。選一個真實導航路徑，由畫面 A 傳兩筆含不同 ID 的物件到畫面 B；檢查兩筆資料、順序與返回操作。使用過的 API 與分支條件要記錄。
• 反射：挑 App 真正在用的類別名稱載入、無參數建構或欄位讀取路徑，經由使用者入口觸發；檢查目標物件與回傳值，並保留崩潰堆疊。測例不要額外用直接參照把原本靠反射的程式強行保留下來，改變受測條件。
• 序列化：用專案實際函式庫與設定，測試物件寫出、讀回，以及既有舊格式樣本。檢查欄位、預設值與 enum 等實際用法；只看「解析沒有丟例外」會漏掉資料悄悄變成預設值。

API 33 為什麼值得單列？2026 年 10 月 6 日的 原始問題回報 #223描述：移除 Parcelable 規則後，使用 @Parcelize 與帶類別參數的讀取 API，在 Android 13 的最佳化建置遇到 NPE；作者列出兩筆物件觸發 Creator 快取路徑的步驟。這是回報者的案例，AlphaLab 未重跑，也不把它擴張成每個 App 都會崩潰。

它有獨立的官方技術依據可查：Bundle 的 typed getParcelable 說明明列 Parcelable 與其 CREATOR 執行時型別的 enclosing-class 關係，違反時可能擲出例外。因此，若你的 App 涵蓋這條使用路徑，至少分開驗 API 33 與 API 34，並依 minSdk 和支援範圍補測其他版本。

也可以評估 AndroidX BundleCompat等相容入口；官方明列 SDK 34 以上與 SDK 33 以下的不同檢查行為，list 元素型別檢查也有邊界。替換 API 要另開一張變更卡與測試，這篇不提供一條套用到所有 Parcelable 的刪除或保留規則。

⑥「失敗能退回」：用同一套標準做採用決定

B 只要出現資料遺失、導航錯誤或新崩潰，就先還原這次候選規則，重新建置並跑同題確認 A 回到通過。留下失敗裝置、API、日誌、APK 與對應 mapping，再縮小是哪一項規則需求被破壞；不要改斷言、刪測例或放寬預期值來迎合 B。

通過的候選也先把範圍講清楚：哪個 commit、variant、依賴版本與哪些裝置測例通過。規則最佳化與工具鏈更新分開提交，保留可回退的差異。把這個迴圈接進自動化工作，可參考 建立 Agent Harness的執行、驗證與停止機制。

FAQ：R8 分析教學的八個直接答案

1. 完全不會寫 Android，也能跟著做嗎？

可以先學驗收觀念。實際建置部分需要可工作的 Android 專案與 SDK；先讓範例 App 的原版 Release 跑通，再進規則修改。

2. 安裝官方 Skill 就表示建議一定適合我的 App 嗎？

仍要逐項驗收。Skill 的分析邊界、依賴版本與專案動態使用路徑，要接到你的 Release 產物一起核對。

3. 一定要升到 AGP 9.3 才能開始嗎？

依現有工具鏈選路。官方另列舊 AGP 搭配相容 R8 的分析方式；也可以先做定性檢視與產物驗收，將尚未產生的分數留白。

4. 分析工作成功，等於 Release APK 已通過嗎？

要另外建置與驗收。官方的獨立分析工作會略過 APK／Bundle 產生，報告與可安裝交付物是兩份證據。

5. 分數提高，就代表 APK 按同比例變小嗎？

兩者量的是不同東西。分數看可最佳化範圍；APK 位元組、下載估算與啟動耗時要分別量。

6. 只用最新 Android 裝置測試夠嗎？

依你的支援範圍安排版本。本文 Parcelable 案例要把 API 33 與 API 34 分開驗，保留真正在走的 API 路徑。

7. 可以讓代理一次刪完所有看似多餘的 keep rules 嗎？

先拆成單項候選。每輪只更動一個可解釋因素，失敗時才容易定位，且能單獨還原。

8. B 的測例失敗，應該先改測試嗎？

先保存失敗並還原候選。只有原本需求確實改變，才另行修訂驗收；不能靠改考卷把規則回歸變成通過。

給新手的三個重點

• 把 Skill 報告當作待驗證的變更清單，先查版本、檔案與真實產物。
• 同一規則實驗固定工具鏈與測試，報告、容量、行為分開記。
• Release 產物與支援的 API 版本一起過關，才把候選帶回正式開發流程。