問題描述
在SDK初始化時，會在init方法中開啓一個倒計時，在5s倒計時結束後使用子線程將本地保存的歷史日誌信息上傳到後臺。
因業務需要，在日誌在發送上傳前，需要對日誌數據做編碼和特殊字符替換，而日誌文件裏包含的日誌數據量相比於一般方法中的局部變量要大很多，所以這樣集中對日誌文件數據的編碼和替換就直接導致了CPU佔用過高，造成了宿主APP短時間卡住的情況。所以導致了因爲SDK體驗問題，日誌啓動上傳功能只能被迫關閉，等待優化。
背景描述
SDK在使用過程中會產生日誌，在操作正常情況下，一個流程結束就會把當前單次產生的日誌上傳到後臺。而對於異常退出或其他異常時，日誌就保留在了本地，等SDK第二次啓動時時再上傳。
問題解決情況
優化前：SDK啓動時，上傳日誌對CPU的佔用量爲100%,佔用時間爲0.5s左右,
優化後：SDK啓動時，上傳日誌對CPU的佔用量爲40%左右,佔用時間爲1.5s左右。
CPU使用情況數據採集如下，CPU採集頻率爲0.5s。
優化前CPU使用情況：
優化後CPU使用情況：
日誌上傳策略
1.當APP調用SDK的init方法初始時，在init方法中會開啓一個倒計時，在5s後使用子線程進行發起上傳。
2.上傳方法調用後，日誌工具會遍歷本地日誌目錄下的日誌文件，並將日誌文件創建成NSData。
3.然後日誌工具逐個讀取未上傳成功標記的日誌數據進行data拼接。
4.每當一個Data日誌拼接後會判斷當前批次拼接的Data的大小是否大於100k, 如果大於則把數據放入請求參數，異步發送一個網絡請求，重新創建一個Data可變對象。
5.循環執行3-4操作，直到所有的本地日誌都發送到後臺
當前日誌上傳策略邏輯清晰，但是存在一個問題。
雖然每個上傳請求都是使用子線程上傳不影響主線程，但是當本地日誌量大時，比如有10M日誌，那麼可能會同時發生100條請求，並在同一時間段內集中對日誌數據進行編碼和特殊字符替換。這樣直接就把CPU資源搶光了，所以會造成APP卡頓。
解決方法
以時間換空間，用戶對日誌上傳時無感知的，只要不影響APP的使用就好。按照這個原則上傳策略可以改爲只使用一個線程，讓這100個上傳請求做串行上傳。
如何讓子線程的網絡請求串行執行呢？
將上傳方法在成功回調中做遞歸調用。遞歸出口是判斷帶上傳的日誌個數，如果個數大於0就繼續遞歸調用上傳，否則就什麼也不做，結束上傳操作。
另外，通過後臺配置上傳開關，在SDK調用時從後臺請求到上傳開關保存到本地，等上傳時讀取開關配置信息，判斷是否開啓上傳。這樣可用於緊急情況關閉日誌上傳功能。