第一章Activity的啟動與生命周期
正常情況下的啟動狀態
onCreate加載布局，初始化數據
onStart界面可視化，但尚在后臺，不可交互。
onRestart從不可見（onStop）到可見（onStart）需要經過onRestart
onResume從后臺到前臺，Activity變得可以交互。
onPause一般onPause后緊接著onStop，所以不推薦將耗時的操作放在這里。
×當新的Activity為透明時，原先Activity還是可視的，因而不會執行onStop
onStop從不可互動到不可視，如點擊home鍵回到桌面，這是Activity一般還沒有被銷毀，等待著onRestart->onStart->onResume重新恢復狀態
onDestroy銷毀Activity，并進行一些回收工作，如關閉數據庫等。
基于書上說的屏幕的點亮熄滅以及手指的觸摸，我個人試了一下
界面一切·從簡，就是默認emptyActivity的界面
每個方法寫都寫一個Log.d("ActivityLife","onXXXX");//XXXX視方法而定
Activity剛啟動時： onCreate->onStart->onResume
點擊返回鍵，關閉程序時：onPause->onStop->onDestroy
點擊home鍵：onPause->onStop
從后臺喚醒：onRestart->onStart->onResume
一直到這里，都和我們在前面的理論是一樣的。
鎖屏時，其實和掛到后臺是一樣的
當喚醒屏幕時，如果有密碼的話，喚醒之后是要輸入密碼，這個時候Activity的界面依舊不可見，因此不會調用以上的任何方法，只有解鎖后，Activity重新可見時，又會執行之前從后臺喚醒相同的步驟
從Activity1啟動Activity2，會先執行Activity1的onPause，然后創建Activity2（onCreate->onStart->onResume）再執行Activity1的onStop.
關于生命周期的重點在于onStart、onStop控制的是Activity是否可見（在后臺），onResume、onPause控制的是Activity是否在前臺可供操作。
異常情況下的生命周期
而onSaveInstanceState是系統自行銷毀Activity時對數據的保存。重新打開時調用onRestoreInstanceState恢復數據。即異常情況下銷毀Activity時，會調用這兩個方法恢復數據。而橫豎屏就屬于這種異常情況。
- 這里我們可以發現，onSaveInstanceState是在onStop前執行的，而onRestoreInstanceState是在onStart后執行的。
- 當Activity異常情況下的情況下需要重新創建時，系統會默認我們保存當前Activity的視圖結果，并在Activity重啟后為我們恢復這些數據，比如文本框用戶輸入的數據，ListView的滾動位置等
- 關于保存和恢復View的層次結構，系統的工作流程：首先Activity會調用onSaveInstanceState去保存數據，然后Activity會委托Window去保存數據，接著Window會委托它上面的頂級容器去保存數據，頂層容器一般是DecorView（ViewGroup)；最后頂層容器再去一一通知它的子元素保存數據，這樣整個數據的保存過程就完成了。
×這里還要注意一下，onSaveInstanceState還有一個兩個參數的方法，是不會在異常狀態中調用的。
資源不足導致的Activity被銷毀
Activity的優先級
- 正在和用戶交互的Activity優先級最高： onResume
- 可見但非前臺的Activity優先級次之：onPause
- 后臺Activity優先級最低：onStop
當系統內存不足時會殺死目標Activity的進程，再用onSaveInstanceState和onRestoreInstanceState進行恢復。
如果一個進程在后臺沒有四大組件在運行，很容易被系統回收，因此可以在后臺放入一個service提高優先級。
configChanges
當系統配置發生改變時，Activity會重新創建，如果在Activity指定configChanges屬性，Activity就會執行configChanges的屬性，而不用重新創建了。
如橫豎屏切換：
manifests中配置
android:configChanges = "orientation"
//多個屬性用|
@Override
public void onConfigurationChanged(Configuration newConfig) {
super.onConfigurationChanged(newConfig);
Log.d("ActivityLife","onConfigChanged:"+newConfig.orientation);
}
Activity創建后，從豎屏到橫屏再到豎屏的過程中
常用的是locale、orientation和keyboardHidden
×android4.0以上orientation要注意配置screensize，不然還是會調用onCreate
使用configChanges:orientation時，就不會使用oSaveInstanceState和onRestoreInstanceState來恢復數據了，因為都沒有銷毀。。。
Activity的啟動模式
Activity的LaunchMode
任務棧是一個“后進先出”的棧結構，每次finish()處于前臺的Activity就會出棧，直到棧為空為止，當棧中無任何Activity的時候，系統就會回收這個任務棧。
-
standard
默認的模式，每次啟動都會創建一個新的Activity到任務棧中。Activity A啟動Activity B會讓B進入A所在的任務棧中，就是這種特性導致，ApplicationContext沒有任務棧，context啟動standard的Activity時會發生錯誤。這時候需要在Intent中加入FLAG_ACTIVITY_NEW_TASK，這時實際上是以singleTask啟動的。
Actvity1啟動Activity1
銷毀上面的Activity1
-
singleTop
棧頂復用模式，若該Activity處于任務棧的棧頂，那么就不會重新創建該Activity。
（Activity1為singleTop）
Activity1啟動Acticity1時：
只調用onPause->onNewIntent->onResume
銷毀時：
只有單個Activity在棧中
Activity1啟動Activity2再啟動Activity1時：
捕獲.PNG
會重新創建Activity1
銷毀時：
銷毀最上面的Activity1
銷毀Activity2 -
singleTask
棧內復用模式。這種模式下，Activity在一個棧中存在，那么多次啟動該Activity都不會重新創建實例，和sinleTop一樣，系統會回調其onNewIntent。如果啟動的Activity沒有所需要的任務棧，就會先創建任務棧再創建Activity。singleTask默認具有clearTop的效果，具有該模式的Activity會讓其之上的Activity全部出棧。
Activity1處于棧頂時啟動Activity1
這里和singleTop是一樣的
Activity1啟動Activity2再啟動Activity1
注意這里，由于不會生成新的Activity1，所以調用onRestart->onStart->onResume，而Activity2會直接被銷毀。 - singleInstance
單實例模式。這是一種加強的singleTask模式，除了具備singleTask的特性之外，具有該模式的Activity只能單獨位于一個任務棧中；比如Activity A是singleInstance模式的，當A啟動后，系統會為它創建一個新的任務棧，后續的啟動均不會創建新的Activity，除非這個任務棧被系統銷毀了。
這里可以這么理解，singleInstance會創建一個新的任務棧，這個任務棧中只有自己一個實例，啟動其他Activity會重新創建一個任務棧，供其他的Activity使用。此時Activity的銷毀順序與創建順序無關，和任務棧內Activity的順序有關。當銷毀時處在singleInstance所在的任務棧，那么該任務棧會被銷毀，跳轉到另一個任務棧的棧頂，再根據這個任務棧Activity的次序進行銷毀。而當銷毀工作處于另一個任務棧時，會先選擇清空這個任務棧的所有實例，在跳轉到唯一的singleInstance所在任務棧的實例。
關于四個啟動模式的流程圖->http://www.lxweimin.com/p/7a11ff292423
LaunchMode的使用方法
在manifests中activity下
android:launchMode="singleInstance"
或者在intent中addFlag
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
這里第二種方法的優先級更高，而區別在于第一種方法不能使用FLAG_ACTIVITY_CLEAR_TOP，第二種不能設置singleInstance。
這里書中還提到了TaskAffinity和AllowTaskReparenting兩個屬性
TaskAffinity標識了Activity所需的任務棧的名字
AllowTaskReparenting="true"時，例子如下：
A啟動B的ActivityC，ActivityC剛好是這個屬性，此時C會在A的任務棧中。當按下home鍵再打開應用B時，會直接打開ActivityC，而不是默認的首頁面。此時ActivityC會從A的任務棧轉移到B的任務棧
adb shell dumpsys activity命令可以詳細的了解當前任務棧情況
Activity的Flags
- FLAG_ACTIVITY_NEW_TASK
即singleTask - FLAG_ACTIVITY_SINGLE_TOP
即singleTop - FLAG_ACTIVITY_CLEAR_TOP
有此標記的Activity在啟動時，在其上的所有Activity都將被銷毀，一般會和singleTask一同出現，當被啟動的Activity是standard模式時，該Activity及以上的Activity都會出棧，再重新創建新的Activity - FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS
有該標識的Activity將不會出現在歷史Activity列表中，xml中等同于：
android:exculdeFromRecents="true"```
#####IntentFliter的匹配規則
- 顯式調用
明確表示啟動對象的包名類名
- 隱式調用
需要Intent匹配IntentFliter所設置的過濾信息
- 一個Activity可以有多個IntentFliter，一個IntentFliter可以有多個action、category或是data。
- 其中Intent需要同時匹配一個IntentFliter中的三種（action、category和data）信息。
- 一個Activity中只要匹配一個IntentFliter就可以了。
- #####Action
action系統有預定義的，當然我們也能自己定義，其中intent中action必須與IntentFliter中一個action匹配。（沒有就默認不匹配）還有一點就是action區分大小寫
- #####Category
category系統有預定義的，當然我們也能自己定義。category與action不同的是：intent中沒有category是默認匹配成功的。如果intent定義了category，則要求intent中所有的category都是intentFliter的category中的一個。
- #####data
data的匹配模式與action類似，都需要至少一個匹配。
data的語法
<data android:scheme="string"
android:host="string"
android:port="string"
android:path="string"
android:pathPattern="string"
android:pathPrefix="string"
android:mimeType="string"/>
data由兩部分組成，URI和mimeType。URI指定類似于路徑的狀態，mimeType指定媒體數據
- URI的結構有mimeType前面的scheme、host、port、path、pathPattern、pathPrefix組成。
<scheme>://<host>:<port>/{<path>|<pathPrefix>|<pathPattern>}
對應：
content：//com.example.project:200/folder/subfolder/etc
http://www.baidu.com:80/search/info
- scheme:URI的模式，如http、file、content等，若沒有指定scheme，URI是無效的。
- Host:URIde主機名，URI中不能為空
- Port:URI的端口號，scheme和host都指定了才有意義。
- Path、pathPattern、pathPrefix:三個參數表述路徑信息。
Path指定完整路徑
pathPattern也指定完整路徑，但是可以使用通配符"",""表示0或多個字符。由于正則表達式的規范，真實字符串中""要用"\"表示，""要用"\\"表示
pathPrefix表示路徑的前綴信息
當沒有指定URI時，URI默認為content和file。
Intent添加data信息：
如果要指定完整data信息，需要setDataAndType
intent.setDataAndType(Uri.parse("file://abc"),"image/png");
使用setData和setType會彼此擦除對方的值
這里data比action特殊的還有一點，就是：
<intent-filter...>
<data android:scheme="file" android:host="www.baidu.com"/>
...
</intent-filter>
<intent-filter...>
<data android:scheme="file"/>
<data android:host="www.baidu.com"/>
...
</intent-filter>
上面的兩種方法是一樣的。
當我們隱式啟動一個Activity的時候，可以做一下判斷，看是否能匹配到我們的隱式Intent，如果不做判斷沒找到對應的Activity系統就會拋出android.content.ActivityNotFoundException異常。
采用PackageManager的resolveActivity方法或者Intent的resolveActivity方法，如果找不到匹配的Activity就會返回null，我們通過判斷返回值就可以規避上述錯誤了。
######接收隱式意圖的Activity必須有<category android:name="android.intent.category.DEFAULT"/>，這個category的作用在于上述兩個方法只要不返回null，就能啟動Activity。
######有一類action和category的共同作用是標明這是一個入口Activity，并且會出現在系統的應用列表中，少一個都沒有任何意義，也不會出現在系統的應用列表中。
<action android:name="android.intent.action.MAIN" />
//最先啟動的activity
<category android:name="android.intent.category.LAUNCHER" />
//桌面的圖標，顯示在程序列表中
####知識點總結的比較全，難聽點就是筆記太啰嗦了吧，感覺都有點重要，整章的內容都快要都寫進來了。
####這一章的內容不是特別多，但我還是寫的有些雜亂，或許寫多了，就好了吧