第1章:Activity的生命周期和啟動模式

1.1Activity的生命周期全面解析

1.1.1典型情況下的生命周期

從Activity整個生命周期來說,onCreate和onDestroy是配對的,分別標(biāo)志著Activity的創(chuàng)建和銷毀,并且只可能有一次調(diào)用,從Activity是否可見來說,onStart與onStop是配對的,隨著用戶的操作或者屏幕的點亮和熄滅,這兩個方法可能被調(diào)用多次;從Activity是否在前臺來說,onResume與onPause是配對的,隨著屏幕的點亮和熄滅,這兩個方法可能被調(diào)用多次.

問題1:onStart和onResume,onPause和onStop從描述上來看差不多,對我們來說有什么本質(zhì)的不同那?

onStart和onStop是從Activity是否可見這個角度進(jìn)行回調(diào)的,而onResume和onPause是從Activity是否位于前臺這個角度進(jìn)行回調(diào)的,在實際的應(yīng)用中除了這兩個區(qū)別,沒有其他明顯的區(qū)別.

問題2:假設(shè)當(dāng)前Activity為A,如果這時用戶打開了一個新的Activity B,那么B的onResume和A的onPause哪個先執(zhí)行?

通過測試及源碼分析得出:A Activity onPause--->B Activity onCreat-->B Activity onStart -->B Activity onResume --->A Activity onStop
從另一個角度分析,onPause與onStop都不能執(zhí)行耗時操作,尤其是onPause,這也意味著盡量在onStop中做操作,從而使Activity盡快的顯示出來,并切換到前臺.

1.1.2異常情況下的生命周期分析

情況1:資源相關(guān)的系統(tǒng)配置發(fā)生改變,導(dǎo)致Activity被殺死并且重建

當(dāng)系統(tǒng)配置發(fā)生改變后,Activity會被銷毀,onPause,onStop,onDestroy都會被調(diào)用,由于Activity是在異常情況下終止的,系統(tǒng)會調(diào)用onSaveInstanceState來保存當(dāng)前Activity的狀態(tài).這個方法調(diào)用的時機(jī)是在onStop之前,它和onPause沒有既定的時序關(guān)系.當(dāng)Activity重建后,系統(tǒng)會調(diào)用onRestoreInstanceState,并且把Activity銷毀時onSaveInstanceState保存的Bundle對象作為參數(shù)同時傳遞給onRestoreInstanceState和onCreate方法,因此我們可以通過onRestoreInstanceState和onCreate方法來判斷Activity是否被重建了,如果被重建了,那么我們就可以取出之前的數(shù)據(jù)進(jìn)行數(shù)據(jù)恢復(fù),從時序上來說,onRestoreInstanceState的調(diào)用時機(jī)在onStart之后.

情況2:資源內(nèi)存不足導(dǎo)致低優(yōu)先級的Activity被殺死

Activity的優(yōu)先級順序從高到低:
(1)前臺Activity---正在和用戶交互的Activity,優(yōu)先級最高.
(2)可見非前臺Activity---比如Activity中彈出了一個對話框,導(dǎo)致Activity可見但是位于后臺無法和用戶進(jìn)行交互.
(3)后臺Activity----已經(jīng)被暫停的Activity,比如執(zhí)行了onStop,優(yōu)先級最低.
當(dāng)系統(tǒng)內(nèi)存不足時,會按上述優(yōu)先級去殺死目標(biāo)Activity所在的進(jìn)程,并在onSaveInstanceState和onRestoreInstanceState保存和恢復(fù)數(shù)據(jù).如果一個進(jìn)程中沒有四大組件在運(yùn)行,這個進(jìn)程將很快被系統(tǒng)殺死.因此一些后臺操作不適合脫離四大組件獨(dú)立運(yùn)行.
當(dāng)系統(tǒng)的某項某項配置發(fā)生改變時,可以通過設(shè)置Activity的configChanges,來防止Activity的重建.

1.2Activity的啟動模式

1.2.1Activity的LaunchMode

Activity的四種啟動模式:
(1)standard,即標(biāo)準(zhǔn)模式,也是默認(rèn)模式.當(dāng)用ApplicationContext去啟動standard模式會報錯,是因為非Activity的Context并沒有所謂的任務(wù)棧,只需要在啟動Activity的時候指定FLAG_ACTIVITY_NEW_TASK標(biāo)記位,這樣在啟動的時候會創(chuàng)建一個新的任務(wù)棧.這時候啟動的Activity實際上是以singleTask模式啟動的.
(2)singleTop:棧頂復(fù)用模式.如果Activity已經(jīng)位于任務(wù)棧的棧頂,那么Activity不會被重建,直接回調(diào)onNewIntent方法,如果新的Activity已經(jīng)存在,但不是位于棧頂,那么Activity仍然會被重建.
(3)singleTask:棧內(nèi)復(fù)用模式.當(dāng)一個具有singTask模式的Activity A請求啟動后,系統(tǒng)首先會尋找它所需要的任務(wù)棧,如果沒有該任務(wù)棧,系統(tǒng)首先會進(jìn)行創(chuàng)建一個任務(wù)棧,然后把Activity A放進(jìn)去.如果有任務(wù)棧,就去判斷Activity A的實例是否存在棧中,如果沒A的實例不存在,就創(chuàng)建A的實例壓入棧中,如果存在,系統(tǒng)就把A調(diào)到棧頂且默認(rèn)具有clearTop的效果并調(diào)用它的onNewIntent方法.
(4)singleInstance:單實例模式.這是一種加強(qiáng)版的singleTask模式,它具有singleTask模式的所有的特性之外,還有一個特性:具有這種模式的Activity只能單獨(dú)位于一個任務(wù)棧中

Activity所需要的任務(wù)棧

默認(rèn)情況下所有Activity所需要的任務(wù)棧的名字為應(yīng)用的包名.同樣,我們可以為通過TaskAffinity屬性來為每個Activity指定任務(wù)棧的名字.TaskAffinity屬性值是字符串,且中間必須含有包名分隔符"."TaskAffinity屬性主要和singleTask啟動模式或者allowTaskReparenting屬性配合使用,其他情況下沒有意義.另外,任務(wù)棧分為前臺任務(wù)棧和后臺任務(wù)棧,后臺任務(wù)棧的Activity處于暫停狀態(tài),用戶可以通過切換再次將后臺任務(wù)棧切換到前臺.

1.3IntentFilter的匹配規(guī)則

只有一個Intent同時匹配action類別,category類別,data類別才算完全匹配,只有完全匹配才能啟動目標(biāo)Activity,一個Activity中可以有多個intent-filter,一個Intent只要能匹配任意一組intent-filter即可成功啟動對應(yīng)的Activity.

1.action的匹配規(guī)則

action是一個字符串,區(qū)分大小寫,action的匹配要求Intent中的action存在且必須和過濾條件中的任意一個action相同.

2.category的匹配原則

category是一個字符串,它要求intent如果有category,則必須與過濾規(guī)則中的任意一個category相同,未設(shè)置category時,系統(tǒng)在調(diào)用startActivity或者startActivityForResult的會默認(rèn)為這個intent添加"android.intent.category.DEFAULT"這個category.

3.data的匹配原則

data的匹配規(guī)則和action的匹配規(guī)則比較相似,如果過濾則中定義了data,那么intent中也必須要定義可匹配的data.

第2章:IPC機(jī)制

2.1:Android IPC機(jī)制簡介

IPC:Inter-Process Communication的縮寫,即進(jìn)程間通信也可以稱之為跨進(jìn)程通信.

IPC機(jī)制的使用場景

情況1:比如有些模塊因為特殊的原因需要運(yùn)行在單獨(dú)的進(jìn)程中,或者為了加大一個應(yīng)用可使用的內(nèi)存所以通過多進(jìn)程來獲取多份內(nèi)存空間.
情況2:當(dāng)前應(yīng)用需要向其他應(yīng)用獲取數(shù)據(jù),由于是兩個應(yīng)用,所以必須采用跨進(jìn)程的方式來獲取所需數(shù)據(jù),通過系統(tǒng)提供的ContentProvider去查詢數(shù)據(jù)的時候,其實也是一種跨進(jìn)程通信.

2.2:Android中多進(jìn)程模式

2.2.1:開啟多進(jìn)程模式

Android中使用多進(jìn)程只有一種方法:在Menifest中給四大組件指定android:process屬性.也就是說無法為一個線程或一個實體類指定其運(yùn)行時所在的線程.其實還有一個非常規(guī)的方法,就是通過JNI在native層fork一個新的進(jìn)程.進(jìn)程名以":"開頭的進(jìn)程屬于當(dāng)前應(yīng)用的私有進(jìn)程,其他應(yīng)用的組件不可以和它跑在一個進(jìn)程中,而進(jìn)程名不以":"開頭的進(jìn)程屬于全局進(jìn)程,其他應(yīng)用通過SharedUID的方式可以和它跑在同一個進(jìn)程中.

2.2.2:多進(jìn)程模式的運(yùn)行機(jī)制

多進(jìn)程帶來的影響:所有運(yùn)行在不同進(jìn)程的四大組件,只要他們之間需要通過內(nèi)存來共享數(shù)據(jù),都會共享失敗.
一般情況下,使用多進(jìn)程會造成如下幾個方面的問題:
(1)靜態(tài)成員和單例模式完全失效.
(2)線程同步機(jī)制完全失效.
(3)SharedPreferences的可靠性下降.
(4)Application會多次創(chuàng)建.

2.3:IPC基礎(chǔ)概念

2.3.2Parcelable接口

系統(tǒng)提供的實現(xiàn)序列化接口的類：Intent凉倚、Bundle兜喻、Bitmap、List蹦魔、Map，但前提是他們里面的每個元素都是可序列化的撞牢。
Parcelable與Serializable的區(qū)別：
Serializable是java中的序列化接口宙彪，使用簡單但開銷大，序列化和反序列化需要大量的I/O操作等限。適用于將對象序列化到存儲設(shè)備中或?qū)ο笮蛄谢笥糜诰W(wǎng)絡(luò)傳輸爸吮。
Parcelable是Android的序列化方式，更適合在Android平臺上使用望门，缺點是使用麻煩形娇，但效率高。主要用于內(nèi)存序列化筹误。

2.4:Android中的IPC方式

(1)使用Intent傳遞數(shù)據(jù)
(2)使用文件共享和SharedPreferences
(3)基于Binder的Messenger和AIDL
(4)使用Socket

2.4:Android中的IPC方式

第8章:理解Window和WindowManager

WindowManager是外界訪問Window的入口桐早，Window的具體實現(xiàn)位于WindowManagerService中，WindowManager與WindowManagerService的交互是一個IPC過程厨剪，Android中所有的視圖都是通過Window來呈現(xiàn)的哄酝，包括Activity，Dialog祷膳，Toast等炫七。
事件的傳遞順序：Window----->DecorView------>View

8.1:Android IPC機(jī)制簡介

WindowManager.LayoutParams.flags
FLAG_NOT_FOCUSABLE:表示W(wǎng)indow不需要獲取焦點，也不需要接收各種事件
FLAG_NOT_TOUCH_MODAL:表示將當(dāng)前Window區(qū)域以外的事件往下傳遞钾唬，Window區(qū)域以內(nèi)的事件自己處理万哪。
FLAG_SHOW_WHEN_LOCK:可以讓W(xué)indow顯示在鎖屏界面上。
WindowManager.LayoutParams.type:
應(yīng)用Window：對于一個Activity抡秆，層級范圍：1~99
子Window：不能單獨(dú)存在奕巍，需要附屬在特定的父Window之中，層級范圍：1000~1999儒士，如：Dialog
系統(tǒng)Window：需聲明權(quán)限的止，層級范圍：2000~2999，如Toast着撩、狀態(tài)欄