(資料圖片)

問題描述在SDK初始化時，會在init方法中開啟一個倒計時，在5s倒計時結(jié)束后使用子線程將本地保存的歷史日志信息上傳到后臺。因業(yè)務(wù)需要，在日志在發(fā)送上傳前，需要對日志數(shù)據(jù)做編碼和特殊字符替換，而日志文件里包含的日志數(shù)據(jù)量相比于一般方法中的局部變量要大很多，所以這樣集中對日志文件數(shù)據(jù)的編碼和替換就直接導(dǎo)致了CPU占用過高，造成了宿主APP短時間卡住的情況。所以導(dǎo)致了因為SDK體驗問題，日志啟動上傳功能只能被迫關(guān)閉，等待優(yōu)化。背景描述SDK在使用過程中會產(chǎn)生日志，在操作正常情況下，一個流程結(jié)束就會把當(dāng)前單次產(chǎn)生的日志上傳到后臺。而對于異常退出或其他異常時，日志就保留在了本地，等SDK第二次啟動時時再上傳。問題解決情況優(yōu)化前：SDK啟動時，上傳日志對CPU的占用量為100%,占用時間為0.5s左右, 優(yōu)化后：SDK啟動時，上傳日志對CPU的占用量為40%左右,占用時間為1.5s左右。CPU使用情況數(shù)據(jù)采集如下，CPU采集頻率為0.5s。優(yōu)化前CPU使用情況：

優(yōu)化后CPU使用情況：

日志上傳策略1.當(dāng)APP調(diào)用SDK的init方法初始時，在init方法中會開啟一個倒計時，在5s后使用子線程進(jìn)行發(fā)起上傳。2.上傳方法調(diào)用后，日志工具會遍歷本地日志目錄下的日志文件，并將日志文件創(chuàng)建成NSData。3.然后日志工具逐個讀取未上傳成功標(biāo)記的日志數(shù)據(jù)進(jìn)行data拼接。4.每當(dāng)一個Data日志拼接后會判斷當(dāng)前批次拼接的Data的大小是否大于100k, 如果大于則把數(shù)據(jù)放入請求參數(shù)，異步發(fā)送一個網(wǎng)絡(luò)請求，重新創(chuàng)建一個Data可變對象。5.循環(huán)執(zhí)行3-4操作，直到所有的本地日志都發(fā)送到后臺當(dāng)前日志上傳策略邏輯清晰，但是存在一個問題。雖然每個上傳請求都是使用子線程上傳不影響主線程，但是當(dāng)本地日志量大時，比如有10M日志，那么可能會同時發(fā)生100條請求，并在同一時間段內(nèi)集中對日志數(shù)據(jù)進(jìn)行編碼和特殊字符替換。這樣直接就把CPU資源搶光了，所以會造成APP卡頓。解決方法以時間換空間，用戶對日志上傳時無感知的，只要不影響APP的使用就好。按照這個原則上傳策略可以改為只使用一個線程，讓這100個上傳請求做串行上傳。如何讓子線程的網(wǎng)絡(luò)請求串行執(zhí)行呢？將上傳方法在成功回調(diào)中做遞歸調(diào)用。遞歸出口是判斷帶上傳的日志個數(shù)，如果個數(shù)大于0就繼續(xù)遞歸調(diào)用上傳，否則就什么也不做，結(jié)束上傳操作。另外，通過后臺配置上傳開關(guān)，在SDK調(diào)用時從后臺請求到上傳開關(guān)保存到本地，等上傳時讀取開關(guān)配置信息，判斷是否開啟上傳。這樣可用于緊急情況關(guān)閉日志上傳功能。