android出棧

『壹』 android的四大組件有哪些

Android四大組件分別為activity、service、content provider、broadcast receiver。
一、android四大組件詳解
1、activity
（1）一個Activity通常就是一個單獨的屏幕（窗口）。
（2）Activity之間通過Intent進行通信。
（3）android應用中每一個Activity都必須要在AndroidManifest.xml配置文件中聲明，否則系統將不識別也不執行該Activity。
2、service
（1）service用於在後台完成用戶指定的操作。service分為兩種：
（a）started（啟動）：當應用程序組件（如activity）調用startService()方法啟動服務時，服務處於started狀態。
（b）bound（綁定）：當應用程序組件調用bindService()方法綁定到服務時，服務處於bound狀態。
(2)startService()與bindService()區別：
(a)started service（啟動服務）是由其他組件調用startService()方法啟動的，這導致服務的onStartCommand()方法被調用。當服務是started狀態時，其生命周期與啟動它的組件無關，並且可以在後台無限期運行，即使啟動服務的組件已經被銷毀。因此，服務需要在完成任務後調用stopSelf()方法停止，或者由其他組件調用stopService()方法停止。
(b)使用bindService()方法啟用服務，調用者與服務綁定在了一起，調用者一旦退出，服務也就終止，大有「不求同時生，必須同時死」的特點。
(3)開發人員需要在應用程序配置文件中聲明全部的service，使用<service></service>標簽。
(4)Service通常位於後台運行，它一般不需要與用戶交互，因此Service組件沒有圖形用戶界面。Service組件需要繼承Service基類。Service組件通常用於為其他組件提供後台服務或監控其他組件的運行狀態。
3、content provider
（1）android平台提供了Content Provider使一個應用程序的指定數據集提供給其他應用程序。其他應用可以通過ContentResolver類從該內容提供者中獲取或存入數據。
（2）只有需要在多個應用程序間共享數據是才需要內容提供者。例如，通訊錄數據被多個應用程序使用，且必須存儲在一個內容提供者中。它的好處是統一數據訪問方式。
（3）ContentProvider實現數據共享。ContentProvider用於保存和獲取數據，並使其對所有應用程序可見。這是不同應用程序間共享數據的唯一方式，因為android沒有提供所有應用共同訪問的公共存儲區。
（4）開發人員不會直接使用ContentProvider類的對象，大多數是通過ContentResolver對象實現對ContentProvider的操作。
（5）ContentProvider使用URI來唯一標識其數據集，這里的URI以content://作為前綴，表示該數據由ContentProvider來管理。
4、broadcast receiver
（1）你的應用可以使用它對外部事件進行過濾，只對感興趣的外部事件(如當電話呼入時，或者數據網路可用時)進行接收並做出響應。廣播接收器沒有用戶界面。然而，它們可以啟動一個activity或serice來響應它們收到的信息，或者用NotificationManager來通知用戶。通知可以用很多種方式來吸引用戶的注意力，例如閃動背燈、震動、播放聲音等。一般來說是在狀態欄上放一個持久的圖標，用戶可以打開它並獲取消息。
（2）廣播接收者的注冊有兩種方法，分別是程序動態注冊和AndroidManifest文件中進行靜態注冊。
（3）動態注冊廣播接收器特點是當用來注冊的Activity關掉後，廣播也就失效了。靜態注冊無需擔憂廣播接收器是否被關閉，只要設備是開啟狀態，廣播接收器也是打開著的。也就是說哪怕app本身未啟動，該app訂閱的廣播在觸發時也會對它起作用。
二、android四大組件總結：
（1）4大組件的注冊
4大基本組件都需要注冊才能使用，每個Activity、service、Content Provider都需要在AndroidManifest文件中進行配置。AndroidManifest文件中未進行聲明的activity、服務以及內容提供者將不為系統所見，從而也就不可用。而broadcast receiver廣播接收者的注冊分靜態注冊（在AndroidManifest文件中進行配置）和通過代碼動態創建並以調用Context.registerReceiver()的方式注冊至系統。需要注意的是在AndroidManifest文件中進行配置的廣播接收者會隨系統的啟動而一直處於活躍狀態，只要接收到感興趣的廣播就會觸發（即使程序未運行）。
（2）4大組件的激活
內容提供者的激活：當接收到ContentResolver發出的請求後，內容提供者被激活。而其它三種組件activity、服務和廣播接收器被一種叫做intent的非同步消息所激活。
（3）4大組件的關閉
內容提供者僅在響應ContentResolver提出請求的時候激活。而一個廣播接收器僅在響應廣播信息的時候激活。所以，沒有必要去顯式的關閉這些組件。Activity關閉：可以通過調用它的finish()方法來關閉一個activity。服務關閉：對於通過startService()方法啟動的服務要調用Context.stopService()方法關閉服務，使用bindService()方法啟動的服務要調用Contex.unbindService()方法關閉服務。
（4）android中的任務（activity棧）
（a）任務其實就是activity的棧，它由一個或多個Activity組成，共同完成一個完整的用戶體驗。棧底的是啟動整個任務的Activity，棧頂的是當前運行的用戶可以交互的Activity，當一個activity啟動另外一個的時候，新的activity就被壓入棧，並成為當前運行的activity。而前一個activity仍保持在棧之中。當用戶按下BACK鍵的時候，當前activity出棧，而前一個恢復為當前運行的activity。棧中保存的其實是對象，棧中的Activity永遠不會重排，只會壓入或彈出。
（b）任務中的所有activity是作為一個整體進行移動的。整個的任務（即activity棧）可以移到前台，或退至後台。
（c）Android系統是一個多任務(Multi-Task)的操作系統，可以在用手機聽音樂的同時，也執行其他多個程序。每多執行一個應用程序，就會多耗費一些系統內存，當同時執行的程序過多，或是關閉的程序沒有正確釋放掉內存，系統就會覺得越來越慢，甚至不穩定。為了解決這個問題，Android引入了一個新的機制，即生命周期(Life Cycle)。

『貳』 Android的四種啟動模式！

在Android開發中，為了高效地管理Activity實例，系統提供了四種啟動模式，幫助開發者根據實際應用場景選擇最合適的模式，以降低內存使用和提升應用性能。下面將詳細探討這四種啟動模式及其應用場景。

一、Android的四種啟動模式

1. **標准模式（standard）**：這是默認的啟動模式，每啟動一個Activity都會創建一個新的實例並置於棧頂。如果是由當前Activity啟動的，則這個Activity會運行在啟動它的那個Activity所在的棧中。應用場景廣泛，一般不主動設置啟動模式。

2. **棧頂模式（singleTop）**：如果棧頂存在當前Activity的實例，系統會復用這個實例而不創建新的實例。適用於點擊通知跳轉到詳情頁或新聞詳情頁點擊推薦新聞條目等場景。

3. **棧內模式（singleTask）**：如果棧內存在當前Activity的實例，系統會將棧中的其他實例出棧並置當前實例於棧頂，如果棧內無實例則創建。適用於APP主頁跳轉後需要返回主頁或瀏覽器主頁等場景。

4. **單例模式（singleInstance）**：系統會為當前Activity新開一個任務棧，該棧內只存放當前實例。適用於需要保持應用開啟後僅有一個實例的場景，如語音通話功能。

如何設置啟動模式？在AndroidManifest.xml的activity節點中設置lauchmode屬性即可。使用棧頂或棧內模式時，需通過onNewIntent回調中的Intent參數接收傳遞的內容。

設置啟動模式不當可能導致應用啟動異常，此外，系統bug也可能引發啟動問題。為了確保應用質量，開發者應嚴謹測試，及時發現並解決潛在bug。藉助工具如友盟U-APM，可幫助從研發測試到線上問題復現，有效提升測試效率。

雲真機測試期間自動採集崩潰信息，提供詳盡的崩潰報告，有助於快速定位和解決問題。未使用過的開發者不妨嘗試一下，減輕工作壓力。

回到主題，接下來將重點介紹啟動模式的實際應用場景。

二、啟動模式的實際應用場景

標准模式是最常見的選擇，無特殊注意點。單例模式則用於需要保持應用中特定Activity實例的場景，一般不直接在應用中應用。下面詳細介紹單頂模式（singleTop）和棧內模式（singleTask）的應用場景：

1. **單頂模式（singleTop）**：適用於點擊通知跳轉到詳情頁或新聞詳情頁點擊推薦新聞條目等場景。在這種模式下，如果棧頂已有對應的Activity實例，系統會復用實例，避免重復創建。

2. **棧內模式（singleTask）**：適用於APP主頁跳轉後需要返回主頁或瀏覽器主頁等場景。在這種模式下，如果棧內已有對應Activity實例，系統會將實例置於棧頂，避免重復創建實例。

在使用單頂或棧內模式時，還需注意生命周期回調。當一個Activity設置了單頂或棧內模式後，跳轉此Activity出現復用原有Activity的情況時，onCreate方法將不會再次運行。因此，需確保頁面數據與跳轉傳遞的參數解耦，避免數據獲取問題。

以上內容希望能夠為Android開發者在選擇啟動模式和理解其應用場景時提供幫助。通過合理的啟動模式選擇，可以有效提升應用性能和用戶體驗。如有更多問題，歡迎繼續交流與討論。

『叄』 Android 深入探討sigleTask和singletop的區別

1.singleTask和singletop都是保真了Activity在棧中的唯一性

2.singleTask和singleTop實例存在時，都不會重新創建 new task

不同之處有如下幾點：

如果singleTask啟動的ActivityA位於棧底，在棧頂startActivity到這個ActivityA時會調動
onNewIntent->onStart->onResume。

但singleTask啟動的的ActivityA不存在時，會重新創建ActivityA,調用方式OnCreate->OnStart->OnResume

2.如果singletop啟動的ActivityB在棧底時，在棧頂startActivity到這個ActivityB時會重新調動
onCreate->onStart->onResume，但不會調用OnDestroy

並且singletop啟動的的ActivityB不存在時，會重新創建ActivityB,調用方式OnCreate->OnStart->OnResume

3.singleTask在棧底時，從棧頂startActivity到棧底ActivityA,那麼該棧startActivity的發起者的中間部分Activity會被銷毀。而singletop是逐級跳躍到棧頂

singleTask

追加一點singleInstance,雖然也是保證唯一性，但改模式的Activity是全局性的唯一性，生命周期和應用程序相同，不能及時回收，此外的話Activity在MVC充當Controller的角色，

這點顯然對singleIntance來說不適合，因此不建議使用。

4.singleTask不適合充當ChildActivity，但singletop適合

5.對作業棧，默認情況下，沒有任何影響，因為棧的taskid是相同的，可以獲取getTaskid()，默認情況下每個activity的taskid相同

但是，如果自定義了棧的標簽（這個標簽相同的singletask activity在同一個作業棧中），那麼taskid就會初選差別

android:taskAffinity="com.sample.lanchmode.tester.main"，那麼一旦另一個作業棧被銷毀，下次必然重建（相信我，這不是廢話）。

為了一句不是廢話，我需要來證明一下。

當我們的初始載入WelcomeActivity界面--->HomeActivity界面時，如果將HomeActivity的啟動模式設置為sigleTask+android:taskAffinity="自定義（一般是類名）",

①那麼WelcomeActivity銷毀後，在到達HomeActivity之後，HomeActivity回作為一個新的作業棧棧底而存在，所以由HomeActivity啟動的Activity的TaskId和HomeActivity相同。

②這個過程，WelcomeActivity和HomeActivity的TaskId是不相同的，問題出現了，當我們按下 Home鍵，然後在點擊桌面上的app圖標你會發現，WelcomeActivity再次出現了，

而且再次進入了HomeActivity，並且這個HomeActivity調用了OnNewIntent，卻沒掉用OnCreate，所以來說他一直存在這，但你需要再次過渡才能找到它。

（對於追求捕獲Home鍵讓app退出的讀者是一個喜訊，這樣可以做到每次Home之後都能再次進入登錄界面），在這個過程中沒有直接進入HomeActivity，而是WelcomeActivity（有人說不對么，不應該是這樣么，在這里不想解釋）。

注意，使用了不同作業棧的Activity,會在最近打開的app顯示一個應用會出現2個界面。

在這里，需要強調一下singleTask+android:taskAffinity不一定必須使用，請依據需求而定，網上有人推薦使用，但我卻想說，不要盲目，並不是所有的應用都適合。

1-->
singleTask+android:taskAffinity對於效率而言，優勢並不存在，比如設置進程的，但對於帶有登錄狀態的app需要慎用，否則造成信息泄露等問題，開發中只使用singleTask即可。

2-->
singleTask+android:taskAffinity適用於單用戶保密性的app（可做到Home之後下次必須登錄才能查看信息），建議在這方面試試。

轉載