問題描述
在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呼叫時從後臺請求到上傳開關儲存到本地，等上傳時讀取開關配置資訊，判斷是否開啟上傳。這樣可用於緊急情況關閉日誌上傳功能。