Android Framework 與 Application 層的關係

在 Android 系統中，Application 層 (最上層) 與 Framework 層 (中間層) 扮演了 應用邏輯 與 系統資源管理 的雙重角色。

• Application 層：

1. 使用者直接操作的 App，例如「設定」、「相機」、「LINE」
2. 使用 Java/Kotlin 開發
3. 呼叫 Framework 提供的 API

• Framework 層：

1. 提供 API 與系統服務
2. 負責 Activity 管理、UI 視窗繪製、應用安裝與權限檢查、通知系統、輸入事件分發
3. 由 SystemServer 啟動並常駐執行

Application 層如何使用 Framework 層？

API 呼叫流程

應用程式並不會直接操作底層硬體，而是透過 Framework API 進行。
以 startActivity() 為例：

1. App 呼叫 API

val intent = Intent(this, SecondActivity::class.java)
startActivity(intent)

2. Framework 接管

• ActivityManagerService (AMS) 收到請求
• 應用權限、準備目標 Activity

3. Binder IPC 通訊

• App 與 AMS 不在同一個進程，需透過 Binder 驅動 進行跨進程溝通

4. 最終顯示

• AMS 通知 WindowManagerService (WMS) 建立視窗
• 透過 SurfaceFlinger 完成畫面合成

這個流程展現了：

• Application 呼叫 Framework API → Framework 轉交給 System Services → 透過 Binder IPC 與底層互動 → 結果回傳給 App

System Services 的角色

Framework 層的核心是 System Services，例如：

• AMS (ActivityManagerService)：管理 Activity、Service、任務棧
• WMS (WindowManagerService)：管理 UI 視窗、螢幕旋轉、多視窗模式
• PMS (PackageManagerService)：應用安裝、權限管理、簽章驗證
• NotificationManagerService：推播與通知
• InputManagerService：鍵盤、觸控事件分發
  這些服務會在 SystemServer 啟動階段初始化，並透過 Binder IPC 對外提供介面，讓 App 可以使用。

Binder IPC 作為橋樑

Framework 層與 Application 層的關鍵溝通機制是 Binder IPC。

• App 與 Framework 屬於不同的 process
• 透過 Binder Driver (在 Linux Kernel 中)，達到跨進程通訊
• Binder 負責：

1. 方法呼叫代理 (Proxy/Stub 模式)
2. 參數序列化/反序列化 (Parcel 機制)
3. 安全驗證 (UID/GID 驗證)

interview questions

• 為什麼 Android 要設計 每個 App 獨立進程，而不是讓所有 App 共用 Framework 的記憶體空間？
• 如果沒有 Binder IPC，Application 與 Framework 的溝通會遇到什麼問題？
• 從「責任分工」的角度，App 層與 Framework 層的邊界設計是否合理？