(資料圖片)

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

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

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