《Android開發進階：從小工到專家》——個人讀書筆記
[TOC]
第一章：Android 的構成基石——四大組件
- 四大組件：Activity、Service、ContentProvider和Broadcast
- Activity： 負責UI元素的加載與頁面之間的跳轉
- Service： 負責與UI無關的工作，如在後臺執行耗時操作等
- ContentProvider： 負責數據的存儲與共享，使得數據可以在多個應用之間共享
- Broadcast： 在各個組件、應用之間進行通信，簡化了Android開發中的通信問題
1.1 Activity
-
Activity 的生命週期
1、onCreate() <font color="ED1A3D">（創建）</font>
自Activity的類時會默認生成該函數，在Activity第一次創建時被調用，主要完成Activity的初始化操作，比如：設置佈局、初始化視圖、綁定事件等。
2、onStart() <font color="ED1A3D">（可見）</font>
當前依舊爲不可見狀態。
3、onResume() <font color="ED1A3D">（獲取焦點）</font>
變爲可見狀態，執行完畢後Activity就會開始請求AMS渲染它所管理的視圖。此時的Activity一定位於返回棧的棧頂，並且處於運行狀態
4、onPause() <font color="ED1A3D">（失去焦點）</font>
即將從可見變爲不可見。通常會將一些消耗CPU的資源釋放掉，以及保存一些關鍵數據
5、onStop() <font color="ED1A3D">（不可見）</font>
完全不可見，區別於 onPause() 如：Dialog彈窗
6、onDestory() <font color="ED1A3D">（銷燬）</font>
銷燬前調用
7、onRestart() <font color="ED1A3D">（重新可見）</font>
Activity被重新啓動了
Activity的生命週期圖
1.1.1 Activity 的構成
1.1.2 Activity 的四種啓動模式
- Android 內部使用通過回退棧來管理 Activity 實例的。
- 棧是一種後進先出的集合
- Activity 一共有四中啓動模式：standard、singleTop、singleTask、singleInstance
- 1、standard——標準啓動模式
如果 ActivityA 的啓動模式爲 standard，並且已經有一個 ActivityA 被啓動，在該 ActivityA 中調用 startActivity 時會啓動一個新的 ActivityA 實例
2、singleTop
如果在棧頂就直接複用當前的 Activity，如果不在棧頂就重新創建一個新的 Activity 放到棧頂使用
3、singleTask
棧中只能有一個該 Activity 的實例，如果該 Activity 不在棧頂，則系統會銷燬該 Activity 上方所有的 Activity，讓該 Activity 位於棧頂
4、singleInstance
會在一個獨立的任務中開啓，並且此任務重有且只有這一個實例對象，也即是說該實例啓動的其他 Activity 會自動運行與另一個任務中。當再次重啓這個 Activity 實例時，會重用已經存在的任務和實例
1.1.3 FragmentActivity 與 Fragment
- 爲了更好的運用越來越大的手機屏幕空間，Android3.0 引入了 Fragment。如果想要兼容更低版本的 Android系統，則需要引入v4包。
1.2 Service 與 AIDL
- Service 是 Android 中實現程序後臺運行的解決方案，但它並不是運行在子線程中的，也不運行在一個獨立的進程中，他同樣運行在UI線程中，所以不能在 Service 中執行耗時操作
1.2.1 普通 Service
- Service 的生命週期：onCreate、onStartCommand、onDestory
- 服務啓動了之後會一直保持運行狀態，直到 stopService() 或 stopSelf() 函數被調用
- Service 也需要在 AndroidManifest.xml 文件中進行註冊
1.2.2 IntentService
- 適用於完成一些短期的耗時任務，因爲它會在任務執行完畢後，調用 stopself 自我銷燬
1.2.3 運行在前臺的 Service
- Service 運行在後臺，優先級較低，當系統內存不足時，會優先回收服務
- 要想 Service 一直保持運行狀態，不被系統回收，可將 Service 運行在前臺（例如通知欄中的消息顯示）
1.2.4 AIDL（Android 接口描述語言）
- Android 提供的一種進程間通信（IPC）機制
1.3 Broadcast（廣播）
- 一種廣泛的運用在應用程序之間進行信息傳輸的機制
- 廣播模式是一種典型的發佈——訂閱模式，即觀察者模式
- 最大的特點：發送方並不關心結束方是否接收到了數據以及接收方如何進行數據的處理，收發雙方完全解耦。
- Android 廣播三要素：發送廣播的 Broadcast、接收廣播的 BroadcastReceiver 以及 傳遞信息的 Intent
- 廣播的分類：普通廣播、有序廣播、本地廣播
1.3.1 普通廣播
- 完全異步，通過 sendBroadcast() 函數來發送，消息的傳遞效率比較高，但所有的 receivers(接收者) 的執行順序不確定
- 缺點：接收者不能將消息的處理結果傳遞給下一個接收者，並且無法終止廣播，直到沒有與之匹配的廣播接收器爲止
- 注意：廣播需要進行註冊，分爲兩種：靜態註冊（在 AndroidManifest.xml 文件中進行註冊）、動態註冊（在代碼中進行註冊）
- 如果是在 Activity 或者 Fragment 中進行動態測試，則需要在 onDestroy() 中實時的註銷該廣播
1.3.2 有序廣播
- 通過 Context.sendOrderedBroadcast() 來發送，所有的廣播接收器按照優先級一次進行信息的接收。廣播接收器的優先級通過 receiver 的 inter-filter 中的 android:priority 屬性來設置，數值越大優先級越高
1.3.3 本地廣播
- 在進程內進行信息的傳輸，安全性較高
1.3.4 sticky 廣播
- 通過 Context.sendStickyBroadcast() 來發送廣播。使用此方式發送的廣播會一直滯留，當有匹配此廣播的廣播接收器註冊後，該廣播接收器就會收到此條廣播。
- 注意：使用此廣播需要獲得 BROADCAST_STICKY 權限
1.4 ContentProivider（外共享數據）
- 在 Android 中的作用就是對外共享數據。好處就是統一了數據的訪問方式。實際上是對 SQliteOpenHelper 的進一步封裝，通過 Uri 映射來判斷需選擇操作數據庫中的哪個表，並且進行增、刪、改、查處理。
- Uri 代表要操作數據表的絕對路徑，其中包含兩個部分的信息，一是需要操作的 ContentProvider ，二是對 ContentProvider 中的哪個表進行操作
- Uri 包含四個部分：scheme + authority + path + id
- 進一步劃分：
- [scheme:][//authority][path][?query][#fragment]
其中有下面幾個規則：
path可以有多個，每個用/連接，比如
scheme://authority/path1/path2/path3?query#fragment
query參數可以帶有對應的值，也可以不帶，如果帶對應的值用=表示，如:
scheme://authority/path1/path2/path3?id = 1#fragment，這裏有一個參數id，它的值是1
query參數可以有多個，每個用&連接
scheme://authority/path1/path2/path3?id = 1&name = mingming&old#fragment
這裏有三個參數：
參數1：id，其值是:1
參數2：name，其值是:mingming
參數3：old，沒有對它賦值，所以它的值是null
在android中，除了scheme、authority是必須要有的，其它的幾個path、query、fragment，它們每一個可以選擇性的要或不要，但順序不能變，比如：
其中"path"可不要：scheme://authority?query#fragment
其中"path"和"query"可都不要：scheme://authority#fragment
其中"query"和"fragment"可都不要：scheme://authority/path
"path","query","fragment"都不要：scheme://authority
等等……
關於 Uri 的詳細結構劃分，可參考這篇博客https://blog.csdn.net/harvic880925/article/details/44679239 - ContentProvider 的 scheme 已由 Android 固定設置爲 content://
- Authority 是標誌 ContentProvider 的唯一標識符，
- Path 是需要操作的數據庫表
- id 是可選的關鍵字段