Android 元件 概要


元件:

  1. 鬆弛耦合，一支應用程式可以呼叫另一支應用程式的元件。
  2. 沒有單一進入點: no main() function 
  3. 預先定義好的事件 (event) -> as 意圖 (intent) -> 特定強況被激活 (activate)
  4. App 中的元件被特定活動調用 (invoke)
以下為四種元件類型:

  • 活動 (activity)


  1. App中主要建構區
  2. 總是佔有整個可見區域，疊在另一個活動之上

  • 服務 (service)


  1. 類似背景行程 (background process)

  • 廣播接收者 (broadcast receiver)


  1. 類似\中斷處理器 (interrupt handler)

  • 內容提供者 (content provider)


  1.  基本上是資料庫 
  2. 所有內容提供者皆呈現相同 API 給 App
  3. 依賴 Android 所包含的 SQLite

意圖 (intent): 

  1. 不同元件互動的晚期繫結 (late-binding)
  2. 不必預先定義、不需要具體指定目標元件...sort of 

元件生命週期 (lifecycle):

中心原則: 用戶不需要管理任務切換 (task switching)，當低優先性之元件資源被釋放、回收後，用戶返回時仍在解除時的狀態。

定義描述檔 (manifest file):

  1. Sort of 「主要」進入點
  2. 讓系統知道App有何元件、執行App所需能力、最低層級必要的API、硬體需求

行程 & 執行緒:

  1. OOM (out of memory) Killer 介入時，決定哪個行程必須被 Kill，以騰出空間
  2. 若App之生命週期正確的實作，用戶不會感到任何有害的行為、甚至不應該察覺到存放App之元件的行程消失，並於稍後使用時「自動」被重新建立

遠端行程呼叫 (RPC):

  1. Android 自訂 RPC/IPC (遠端行程呼叫/行程間通訊) 機制 -> Binder (繫結器)
  2. 跨元件不是使用socket，而是Binder 機制 -> /dev/binder 存取
  3. App開發者並非直接使愈Binder機制，他們必須定義介面語言 (IDL, Interface Definition Language) 與介面互動 -> .aidl file -> 產生 stub (虛設常式) & marshaling/unmarshaling code

留言

張貼留言