intro

在 Android 系統中，應用程式 (Application) 的運行並不是單純由 App 自己控制，而是受到 Framework 層嚴格管理。這一切的核心角色，就是 ActivityManagerService (AMS)。
AMS 是 System Services 中最核心、最複雜的服務之一，主要職責是：

• 管理應用進程：決定 App 何時啟動與 destory。
• 管理 Activity 生命週期：確保 Activity 與使用者互動時的正確狀態。
• 管理 Task Stack：維持多任務環境下的 Activity 排序。
• 與其他 System Services 協作：例如與 PackageManagerService (PMS)、WindowManagerService (WMS)、Zygote 共同完成 App 啟動。
  因此，AMS 幾乎所有與 應用管理 相關的功能都要透過 AMS。

AMS 的整體架構與角色

AMS 是一個 System Service，運行在 system_server 進程 中。
其核心角色可以分成三個部分：

• Process Management
  • 負責 App 啟動與停止
  • 與 Zygote 通信，請求 fork 新的進程
• Activity 與任務管理 (Activity/Task Management)
  • 負責 Activity 的新增、銷毀、狀態轉換
  • 維護 任務棧 (Task Stack)，決定 Activity 的顯示順序
• 跨服務協作 (Collaboration)
  • 與 PMS 溝通，確認 App 是否已安裝、權限是否允許
  • 與 WMS 協作，決定 Activity 的視窗顯示與焦點切換
  • 與 InputManagerService 協作，處理輸入事件與焦點

AMS 架構示意圖：

   [ App 層 ]               [ Framework 層 ]
 ┌─────────────┐          ┌───────────────────────┐
 │ Activity A  │ ←──IPC──→│ ActivityManagerService│
 │ Activity B  │          │   (system_server)     │
 └─────────────┘          └──────┬─────┬──────────┘
                                 │     │
                ┌────────────────┘     └────────────────┐
           [ Zygote ]                       [ WMS / PMS ]
       (創建 App 進程)                (視窗管理 / 套件管理)

應用啟動流程與 AMS 的角色

1. 啟動觸發
   假設使用者在 Launcher 點擊一個 App icon，流程如下：

• Launcher (App 層) 呼叫 startActivity() → 透過 Binder 請求 AMS。
• AMS 接收到請求後，先交由 ActivityStarter 解析 Intent。
• AMS 檢查該應用是否有進程存在：
• 若已存在 → 直接在該進程內啟動 Activity。
• 若尚未存在 → 透過 Zygote fork 出一個新的進程。

2. 與 Zygote 的交互

• AMS 透過 ZygoteProcess 向 Zygote socket 發送指令，要求啟動新進程。
• Zygote fork 出新的 App 進程，並加載 Application 與 ActivityThread。
• App 啟動後，透過 Binder 回調 通知 AMS 自己已經 ready。

3. 與 WMS 的協作

• AMS 負責 Activity 的邏輯管理
• WMS 則負責視窗顯示
• 當新 Activity 準備好時，AMS 通知 WMS 建立 Window，並進行顯示與焦點切換。

App 啟動流程圖：

[Launcher] → startActivity()
↓
[AMS] → 檢查進程 → 無 → 啟動 Zygote
↓
[Zygote] → fork 新進程 (App)
↓
[App 進程] → ActivityThread → onCreate()
↓
[AMS] ← App 報告 ready
↓
[WMS] → 建立 Window，顯示 UI

Activity 生命周期管理與 AMS

Activity 的生命周期方法 (onCreate, onStart, onResume, onPause, onStop, onDestroy) 其實並不是 App 自行決定，而是由 AMS 驅動。

1. 狀態轉換由 AMS 控制

• App 呼叫 startActivity() 後，AMS 決定何時回調 onCreate()。
• 當使用者切換 App，AMS 控制舊 Activity 進入 onPause()，新 Activity 進入 onResume()。

2. 與 ActivityThread 的交互

• AMS 不會直接調用 Activity，而是透過 Binder IPC 與 ActivityThread 互動。
• AMS 透過 scheduleLaunchActivity()、schedulePauseActivity() 等指令，請求 ActivityThread 執行對應方法。
• 最終 ActivityThread 透過 Handler 機制 在主線程 (UI Thread) 上回調生命週期方法。

生命周期控制示意圖：

[AMS] → scheduleLaunchActivity()
↓
[App 進程] ActivityThread → Handler → performLaunchActivity()
↓
Activity.onCreate() → Activity.onResume()

Task Stack 管理

1. Task stack 的基本概念
   每個任務 (Task) 是一個 Activity stack，內含一組有序的 Activity。
   例如：
   打開瀏覽器 → MainActivity → SearchActivity → ResultActivity
   這些 Activity 就在同一個任務棧內。
2. Task stack 的核心職責

• 維護前後台：確保前台 Activity 可以與使用者交互，後台 Activity 暫停但不銷毀。
• 返回鍵行為：由 AMS 根據任務棧狀態，決定返回到前一個 Activity 或退出 App。
• 多任務切換：透過 Recent Apps (Recents) 切換不同任務。

3. TaskAffinity 與啟動模式
   AMS 在管理任務棧時，會依據：

• TaskAffinity：決定 Activity 屬於哪個 Task。
• LaunchMode：例如 standard, singleTop, singleTask, singleInstance，影響 Activity 是否新建或重用。

Task stack 示意圖：

 Task #1 (Browser)
 ┌────────────────┐
 │ ResultActivity │  ← Top
 │ SearchActivity │
 │ MainActivity   │
 └────────────────┘

 Task #2 (Chat)
 ┌────────────────┐
 │ ChatActivity   │  ← Top
 │ LoginActivity  │
 └────────────────┘

AMS 與其他系統組件的協作

AMS 不是孤立的，它與多個核心組件緊密協作：

• PackageManagerService (PMS)
  • AMS 啟動 App 前，向 PMS 查詢應用資訊、權限設定。
• WindowManagerService (WMS)
  • AMS 負責邏輯層，WMS 負責視覺呈現。
  • 兩者合作，完成 Activity 的顯示與焦點切換。
• InputManagerService (IMS)
  • AMS 控制哪個 Activity 在前台 → IMS 將事件派發給該 Activity。
• BatteryStatsService / UsageStatsService
  • AMS 通知這些服務，記錄 App 的使用與資源消耗情況。

Summary

ActivityManagerService (AMS) 是 Android Framework 的核心：

• Process 管理：控制 App 的啟動與銷毀
• 生命周期管理：驅動 Activity 的狀態轉換
• Task stack 管理：維護前後台行為、多任務切換
• 跨服務協作：與 Zygote、PMS、WMS 等緊密合作