(資料圖片)

問題描述在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調用時從后臺請求到上傳開關保存到本地，等上傳時讀取開關配置信息，判斷是否開啟上傳。這樣可用于緊急情況關閉日志上傳功能。