題:
當您從最近的應用程序列表中滑動某個應用程序時，實際上會發生什麼？
eldarerathis
2012-02-28 02:47:55 UTC
view on stackexchange narkive permalink

Ice Cream Sandwich中的最新應用程序列表增加了將應用程序從列表中滑出的功能，從而將其永久關閉（據我所知這是一種香草功能，不是CM /自定義ROM）。文檔和平台重點似乎並未涵蓋此功能的幕後工作，但我很好奇該系統的實際功能。

進一步增加了我的好奇心，我決定做一個快速測試：我在CM9安裝上啟動了Music，然後退出了。然後，我檢查了最近的應用程序列表，發現它確實在那裡（並且基於縮略圖處於適當的狀態）。然後，我進入 Settings->Applications 並強行停止了該音樂應用程序，但該應用程序仍列在最近的列表中，使我認為它與後台徘徊的進程沒有聯繫。

現在我意識到音樂可能是一個糟糕的選擇，所以我也使用《今日美國》應用程序進行了測試。這表現出基本相同的行為，儘管最近的應用程序列表中的縮略圖沒有反映出這一點（我想是緩存的），但似乎它在強制停止後被迫“重新啟動”（這是有道理的）。

因此，當您從最近列表中滑出某個應用程序時，在操作系統級別上會發生什麼實際情況？是否只是將應用程序的數據從RAM中清除出來並進行垃圾回收，從而破壞了其保存狀態？

五 答案:
eldarerathis
2012-03-16 05:58:16 UTC
view on stackexchange narkive permalink

我似乎發現了神奇的搜索詞，這些詞引起了Google員工的一些解釋。具體來說，我在幾個不同的地方發現了Dianne Hackborn解釋的內容，當您從最近的列表中輕掃某些內容時會發生什麼。首先是對她的一個Google+帖子的評論：

[W]當您輕掃最近的任務時，它具體發生了什麼：（1）殺死任何人應用程序的後台或空進程（有關說明，請參見 http://developer.android.com/guide/topics/fundamentals/processes-and-threads.html#Lifecycle）和（2 ）使用新的 http://developer.android.com/reference/android/app/Service.html#onTaskRemoved(android.content.Intent） API來告知應用程序有關該任務的任何服務被刪除，因此它可以執行其認為適當的任何操作。

她還在博客評論中註釋：

實際上，在近期任務中刪除條目將殺死該進程存在的所有後台進程。它不會直接導致服務停止，但是有一個API可讓他們找出已刪除的任務，以決定是否要停止該任務。這樣一來，刪除說電子郵件應用程序的最新任務不會導致它停止檢查電子郵件。

如果您確實要完全停止應用程序，則可以長按最近的任務，轉到應用信息，然後立即停止。要停止，就是完全殺死了該應用程序-所有進程都被殺死，所有服務都已停止，所有通知已刪除，所有警報已刪除，等等。除非明確請求，否則該應用程序將不允許再次啟動。

因此，摘要似乎是，從列表中刷出一個應用程序將首先殺死該應用程序的所有後台進程，然後使用 onTaskRemoved 通知該應用程序該後台任務已刪除。到那時，似乎應該由應用程序來決定發生什麼事情，所以我想從技術上來說，不是一條嚴格的規則來確定應用程序在那之後發生了什麼。 >

那肯定是不明顯的行為，非常有趣！
“殺死該進程存在的任何後台進程。它不會直接導致服務停止”。這仍然是真的嗎？我昨天進行了測試。昨天，我在主要流程中輕掃了帶有後台服務的應用程序。 apps => running UI顯示0個進程和0個服務。後來，我用一個在單獨的應用程序特定進程中運行的進程將同一個應用程序刷掉了。 apps =>正在運行的UI表示我有0個進程和1個服務。那是在裝有Android 4.4.4的Moto X（2014）上進行的。
@StevenWexler:可能是在第一種情況下該服務自行終止，但在第二種情況下並未終止，或者在第二種情況下，主進程確定（出於某種原因）它不想停止該服務。很難確定。
從最近列表中刷出後，啟動的服務會再次自動啟動，再次調用onCreate。但是在某些應用程序中，onCreate在onTaskRemoved之前調用，在某些應用程序在onTaskRemoved之後調用。
Austin Mills
2012-02-28 06:21:18 UTC
view on stackexchange narkive permalink

將應用程序從最近的應用程序列表中滑出是很麻煩的，是的，沒有充分的文檔記錄。這一直是在各種Android論壇上進行大量討論的主題...共識似乎最好地描述在這裡的一些評論中：行為類似於但不完全相同。一個應用程序-通常（對於未定義顯式後退按鈕處理的應用程序）與從應用程序中退出該應用程序回擊足夠多的時間相同

該鏈接提供了更多詳細信息，但總的來說，您可以將其視為退出應用程序。

特定於Music應用程序，我相信它會啟動服務，因此儘管可能會關閉任務本身（“音樂”應用程序/ UI），但該服務會繼續在後台運行，因此您的音樂不會突然停止，僅僅是因為任務由於內存管理原因而被清除。那可能會影響您所看到的。

謝謝，該鏈接有很多不錯的討論。您也可能是正確的：音樂，這可能是一個糟糕的考驗。我會嘗試另一個應用程序，只是為了踢球。
繼續進行下去，因為reddit討論幫助我找到了一些更好的搜索詞，並且我在[我的回答]中提到的Dianne Hackborn的一些帖子似乎也證實了這一點（https://plus.google.com/105051985738280261832 / posts / GfwRYCC42uX）。謝謝！
[從Android的多任務抽屜中刪除應用程序時會發生什麼]（http://lifehacker.com/what-happens-when-you-remove-an-app-from-androids-mult-1179868228）
完美，謝謝！對我來說，這篇文章對我有所幫助：http://www.reddit.com/r/Android/comments/mpevh/id_like_to_squash_this_growing_misconception/c32sbsa
當您從“最近”列表中滑動應用程序時，即使Rocket Player這樣的第三方音樂播放器也會停止播放音樂，即使該服務在後台運行，並且您需要打開該應用程序或再次在小部件中播放才能開始播放音樂。
onik
2012-03-10 15:13:30 UTC
view on stackexchange narkive permalink

com.android.internal.policy.impl.RecentApplicationsBackground和 com.android.internal.policy.impl.RecentApplicationsDialog中的源代碼中有一些信息。

如果我正確閱讀了這些內容，則可以使用特定的處理程序來選擇應用程序，但是除了 onDetachedFromWindow（）（調用 com.android.View .onDetachedFromWindow（）基本上可以隱藏元素並清除其數據。這將暗示一個事實，即在刷卡應用程序時沒有發生任何特殊情況，這與Austin Mills的回答相對應，因為由於列表未顯示活動的應用程序，因此 onPause（）和其他系統調用當“退出”應用程序時已經完成了。

Leandros
2012-03-16 00:47:37 UTC
view on stackexchange narkive permalink

我認為它的作用與後退按鈕相同。除了一個小變化。它將 finish（）應用中的所有活動/片段。

只需使用一些自建應用程序進行一些測試。您也可以測試。這是我的測試應用程序： https://bitbucket.org/Leandros99/lifecycletest（也提供下載。對於無法構建的用戶。）
在每個Activity生命週期方法中（ http： //developer.android.com/reference/android/app/Activity.html#ActivityLifecycle）將應用打印為日誌。您可以使用adb logcat進行查看（將Android SDK安裝到cdd / shell中的cd-platform-tools中，然後鍵入 adb logcat 。現在您將看到，每次執行“回擊”或“主頁”按鈕之類的操作時，應用程序會打印上述生命週期方法。）

您的問題：如果我從最近的應用程序抽屜中滑動某個應用程序，則會調用 onDestroy 方法。它的功能與後退按鈕幾乎相同。
希望我能有所幫助。如果有問題，只問。

user3067986
2013-12-05 05:22:26 UTC
view on stackexchange narkive permalink

它關閉應用程序，並將其數據存儲在RAM中。因此，為您提供更多的RAM空間，以便您可以運行其他應用程序。但是，由於關閉正在使用的應用程序，後台服務不會自動強制關閉。

儘管使用日常語言編寫，但這實際上是一個相當準確的答案-它捕獲了處理已被廢棄的事實，其他很多答案（將其與後退按鈕進行了錯誤地比較）也有所遺漏。但是，這裡缺少的是認識到Android無論如何都將在需要獲取內存時處理進程，因此，儘管它完成了一些內存清理，但如果需要時會自動發生。


ⓘ
該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到，我們感謝它分發的cc by-sa 3.0許可。
Loading...