一、Activity的生命週期

1. activity的四種狀態

• running activity可以活動 使用者可以點選 處於棧頂的位置
• pause 失去焦點 被acitvity視窗覆蓋 ，或者是透明activity處於棧頂位置 失去和使用者的互動 記憶體緊張會被回收
• stoped 被完全覆蓋 記憶體緊張會被回收
• killed 被系統回收掉

2. activity的生命週期

• 啟動 oncreate -->onStart-->onResume 
  • onStart--使用者可見 但是使用者不能進行互動
  • onResume--使用者可見 可以進行互動
• onpause --->onStop 點選home返回主介面 
  • onpause--處於停止狀態，使用者不可見，記憶體緊張會被回收
  • onStop ----完全覆蓋，記憶體緊張會被回收
• 再次回到原activity onreStart->onStart->onResume
• 退出onPause->onStop->onDestroy

3.android中程序優先順序

• 前臺
• 可見
• 服務 （service）
• 後臺 （不可見的狀態)
• 空

4.activity狀態儲存

為什麼平時並沒有實現onSaveInstanceState()和onRestoreInstanceState()方法，但是有些時候，Activity中的UI狀態依然得到了儲存，是為什麼？

 在Android中，Activity類的onSaveInstanceState()方法預設實現會呼叫佈局中每個View的onSaveInstanceState()方法去儲存其本身的狀態資訊，Android框架中幾乎每個控制元件都會實現這個方法。我們只需要為想要儲存其狀態的每個控制元件提供一個唯一的ID（在xml中設定 android:id屬性），如果控制元件沒有 ID，則系統無法儲存其狀態。
 
我們可以通過將View的android:saveEnabled屬性設定為false或通過呼叫View的setSaveEnabled()方法顯式阻止佈局內的檢視儲存其狀態，通常不需要設定這些屬性，但如果想以不同方式恢復Activity UI的狀態，可以這樣做。
 

二、android中的任務棧 和activity的啟動模式

1.standard

• 標準的跳轉方式，可以複用activity,為了避免重新建立消耗記憶體資源

2.singletop

• 棧頂複用模式，如果建立的activity在棧頂，就不會重新建立，複用棧頂

3.singletask

• 棧內複用模式，單例模式，當前棧中有此activity，就會放在棧頂，並且將它之上的activity進行移除，此時會回撥onNewIntent方法

3.singleinstance 
- 棧中有且僅有一個例項

三、scheme跳轉協議

Android中的Scheme是一種頁面內跳轉協議，通過自定義Scheme協議，可以跳轉到app中的任何頁面。

-- Uri.parse("qh://test:8080/goods?goodsId=8897&name=fuck")

• 伺服器可以定製化跳轉app頁面
• app可以通過Scheme跳轉到另一個app頁面
• 可以通過h5頁面跳轉app原生頁面