當iOS應用程序確實進入後臺

我創建了幾個實驗恰好TCP和UDP什麼（多播）連接：當iOS應用程序確實進入後臺

設置1：我創建了一個TCP發送者的應用程序和TCP接收器應用程序。

在這個實驗中，我開始iOS設備和另一iOS設備上的TCP接收器上的TCP發送者。然後兩者都被驗證已經建立連接併發送和接收數據。然後，我將TCP Receiver應用程序置於後臺。 TCP Sender應用程序顯示連接丟失並崩潰（是的，我是這樣想的）。

設置2：我創建了一個UDP發件人的應用程序和一個UDP接收機應用。

同上，我開始iOS設備和另一iOS設備上的UDP接收機應用的UDP發件人應用程序。在訂閱了多播組的UDP Receiver應用程序等上，我驗證了UDP Receiver應用程序正在從UDP Sender應用程序發出的多播組接收數據。然後我將UDP Receiver應用放到後臺。 2分鐘後，我得到UDP Sender應用程序發送另一個數據。然後我完全退出UDP Sender應用程序並關閉該iOS設備。然後等待另外2分鐘或更長時間，然後從後臺調出UDP Receiver應用程序。 UDP Receiver應用程序確實收到了UDP Sender應用程序在終止之前發出的數據。

在Setup1文件，我的解釋是，因爲TCP是一個面向連接。

在設置2，我明白了UDP是無連接的。任何解釋爲什麼setup2它在我的經驗中工作的方式？（仍然會收到即使在後臺模式數據）

來源

2012-01-28 user523234

所有這一切，當你把一個應用程序進入後臺，然後讓它去懸掛的是，它停止得到由內核調度的情況。它不會立即打破任何連接或拆除任何插座（除非你把它強制）。

在你的UDP情況下，內核接收數據包，並把它變成一個內核緩衝區，等待着您的應用程序接收它。由於您的應用程序進程存在但是被有效地停止，數據將僅位於內核緩衝區中。如果數據太多，它會溢出內核緩衝區並丟棄。否則，您的應用程序可以在（如果）再次安排時接收它。

在TCP的情況下，幾乎是同樣的事情hapens。

但是（很大但是）：操作系統總是可以選擇根據內存壓力等情況拆除掛起應用程序的套接字。所以雖然它不一定會做到這一點，但它可以做到這一點。

我不知道到底爲什麼你看到迅速切斷TCP連接。這可能是因爲TCP連接需要比UDP套接字更多的狀態和更連續的處理，所以用於服務器TCP連接的內核啓發式比UDP套接字更具侵略性。

見Technical Note TN2277 Networking and Multitasking。

來源

2012-01-28 17:30:55 smparkes

順便說一句，我假設當你說「背景」你的意思是「暫停」，因爲你沒有提到試圖運行啓用背景應用程序（VOIP，音樂等），除非你做一些事情特殊情況下，背景是您的應用的暫時狀態，在進入後臺後會很快暫停。查看Apple iOS應用程序生命週期文檔。 – smparkes 2012-01-28 17:41:05

優秀的解釋！我的想法與你的解釋是一致的，（+1票）技術文章非常確認。是的，我的意思是暫停而不是背景。僅供參考：我的TCP發送器因爲不斷向接收器發送數據流而迅速崩潰。 – user523234 2012-01-28 23:03:01

這將使意義：如果您發送的數據的目的地不接收，並與主線程阻塞調用做到這一點，iOS版將看到您的應用程序不響應，並殺死它。 TCP連接可能仍然正常;它有流量控制來管理緩衝區，但是你不允許阻塞主線太久。 – smparkes 2012-01-29 00:23:41

我的觀點是，因爲操作系統的，這不應該發生，如果你試圖在Android操作系統，因爲內部監督辦公室對什麼可以在後臺工作的限制，什麼不能。

從你說的，我認爲它是因爲TCP需要更多的資源來發送信息。 TCP使用數據流，UDP使用數據塊。問題是TCP創建更大的數據包，而UDP使用8 kb的數據塊。

來源

2012-01-28 17:25:20

當iOS應用程序確實進入後臺

回答

相關問題