當字符串太大時，主線程（？）中運行的NSLog會阻塞主線程？

Question

我需要一些遺留的數據發送到服務器我的應用程序啓動時，所以在

applicationDidFinishLaunching 

我叫其將一些核心數據實體JSON文本，並將其發送到服務器的方法。有時，應用程序崩潰的原因是：

XXXXXX未能及時推出

我首先想到的是，我做的事情，當應用程序被啓動，主線程，然後我意識到這可能阻斷不是問題，因爲我使用NSURLConnection來發送異步數據，並且不應該阻塞主線程，經過一些測試後，我發現當數據很大時，應用程序更容易崩潰，因爲連接是異步的，唯一可疑的代碼是當我從Core Data實體創建JSON文本時，我使用NSLog來打印它，並且我嘗試使用硬編碼的大json文件，它總是崩潰，如果我註釋掉NSLog lin e，它不會崩潰。

根據該方案，我想知道：

1. 我在想，是的NSLog在主線程上運行，無論在哪個線程它叫什麼名字？然後，我在蘋果的文檔中發現：從NSLogv

輸出序列化，在這個過程只有一個線程可以執行上述在同一時間說明的寫/記錄。所有嘗試在下一個線程寫入/記錄消息完成之前都可以開始嘗試。

這是否意味着即使它在非主線程中，但它記錄了一些長字符串，這導致主線程被阻塞？

1. NSLog的字符串大小是否有任何限制（理論上，實際上）？硬編碼的JSON文件是150KB。

非常感謝！

Answer 1

使用GCD隊列並異步轉儲日誌。

粗略地說，你需要創建一個串行隊列：

lqueue = dispatch_queue_create("com.example.logging", NULL) 

用它寫日誌：

dispatch_async(lqueue, ^{ /* write log here */ }) 

我沒有測試它，但不是NSLog你可能需要使用ASL（asl_*功能系列）。

甚至更​​好，只需使用一些解決方案，如https://github.com/robbiehanson/CocoaLumberjack已經做了所有這些東西和更多。

Answer 2

我認爲你的應用正在被iOS看門狗定時器殺死。如果您檢查錯誤日誌，您應該看到代碼0x8badf00d。基本上，看門狗定時器觀看應用程序的啓動和停止，如果它們花費太長時間，則會將它們關閉。它觀察的其中一種方法是 applicationDidFinishLaunching方法。沒有關於應用程序執行啓動的時間長度的文檔，但僅需幾秒鐘。

你需要做的是將你的代碼移動到另一個方法或後臺線程。 applicationDidFinishLaunching應儘快完成，你可以做到這一點。

在這裏做一個0x8badf00d搜索，你會發現很多關於它的討論和組織你的代碼的方法。