Android Performance Optimization 效能優化

效能優化不是在專案結束前才進行的補救措施，而是一種貫穿開發週期的習慣。良好的效能意謂著快速的啟動時間、流暢的 UI 互動以及健康的記憶體使用率。

核心優化：R8 與編譯技術

R8 編譯器與混淆

R8 是 Google 的程式碼縮減器，它能移除未使用的程式碼與資源，並進行混淆以縮小 APK 體積。

buildTypes {
    release {
        isMinifyEnabled = true // 啟用 R8 程式碼縮減與混淆
        isShrinkResources = true // 移除未使用的資源檔案
        proguardFiles(
            getDefaultProguardFile("proguard-android-optimize.txt"),
            "proguard-rules.pro"
        )
    }
}

Baseline Profiles (基準設定檔)

JIT 編譯器在 App 啟動時需要即時編譯，這會導致冷啟動 (Cold Start) 較慢。Baseline Profiles 允許你將啟動時關鍵的路徑預先編譯 (AOT)，這能提升約 30%~40% 的啟動速度。

啟動優化 (App Startup)

App Startup 函式庫

許多 SDK 需要在 Application.onCreate() 初始化。當 SDK 數量變多時，啟動速度會顯著下降。使用 App Startup 函式庫可以透過一個單一的 ContentProvider 來管理所有初始化任務，並支援延遲加載。

SplashScreen API

從 Android 12 開始，系統強制執行啟動畫面。正確實作 installSplashScreen() 能提供更流暢的視覺過渡，並允許你精確控制啟動動畫的結束時機。

記憶體管理與洩漏偵測

記憶體洩漏 (Memory Leaks)

常見的洩漏來源包括：

在外部類別中持有 Activity 的靜態引用。
忘記在銷毀元件時取消監聽器或 RxJava/Coroutine 任務。

LeakCanary

在開發階段，務必整合 LeakCanary。它會自動監控記憶體，並在偵測到洩漏時提供完整的引用鏈 (Heap Trace) 幫助你找出問題產生的根源。

dependencies {
    // 僅在 debug 環境啟用
    debugImplementation("com.squareup.leakcanary:leakcanary-android:2.x")
}

Compose 效能優化

在 Compose 中，核心目標是「避免不必要的重組 (Recomposition)」。

延後狀態讀取 (Defer State Reads)：盡可能在較晚的階段讀取狀態。例如使用 Modifier.drawWithContent 或傳遞 Lambda 而非直接傳遞狀態值，這能讓重組範圍縮小。
使用 derivedStateOf：當一個狀態是由其他多個頻繁變動的狀態運算而來時，使用 derivedStateOf 可以減少不必要的重組次數。
穩定性與 @Stable：確保傳遞給 Composable 的資料模型是穩定的（不可變）。如果 Compose 無法自動判斷，可以使用 @Stable 或 @Immutable 標註，讓偵測器跳過不必要的比對。
強大的跳過模式 (Strong Skipping Mode)：在最新版本的 Compose 中，這是預設行為，能極大地優化不穩定參數導致的重組。

診斷工具：Android Profiler

當你感到 App 有卡頓 (Jank) 時，請依照以下順序檢查：

CPU Profiler：檢查主執行緒是否正在執行耗時任務（如磁碟 IO 或複雜運算）。
Memory Profiler：觀察記憶體使用趨勢，檢查是否有異常的抖動（頻繁的 GC）。
System Trace (Perfetto)：深入查看框架層級的事件，找出掉幀 (Dropped Frames) 的確切原因。

體積優化 (APK Size)

除了縮減器，你還可以：

WebP 格式：將所有圖片轉換為 WebP 格式，體積通常比 PNG 小 30% 以上。
資源分級 (ResConfigs)：透過 resConfigs "zh", "en" 移除未使用的多國語言資源。

效能優化是一場持久戰，建議建立 Baseline 並在每次重大更新後進行評測。