一、背景
APP發(fā)布后，在用戶側(cè)出現(xiàn)的問題統(tǒng)稱為“線上問題”。如果“線上問題”出現(xiàn)了：
解決率低
存在時(shí)間長
的情況，那么對(duì)APP的口碑會(huì)有很大的負(fù)面影響。經(jīng)過我們對(duì)2016年上半年手機(jī)QQ瀏覽器用戶反饋分析，我們發(fā)現(xiàn)“線上問題”解決的主要困難來自于“對(duì)解決問題的關(guān)鍵信息獲取困難”，統(tǒng)計(jì)數(shù)據(jù)如下：
圖表——日志獲取率和時(shí)間
大家可以看到：日志的獲取率平均只有10%，平均一份日志獲取時(shí)間至少30小時(shí)。那么有沒有辦法能夠改善這種窘境呢？
二、解決方案
1、SDK架構(gòu)
既然方向明確了，我們就來制造這個(gè)輪子。通過我們多輪迭代后，我們得到了如下的穿山甲SDK系統(tǒng)架構(gòu)：
圖表——穿山甲SDK架構(gòu)
從架構(gòu)圖上，可以看出整個(gè)SDK分為兩條線：以“日志數(shù)據(jù)”作為輸入的“數(shù)據(jù)線”和以“Push Cmd/代碼Cmd”作為輸入的“控制線”。
這也是常用的系統(tǒng)設(shè)計(jì)思路，數(shù)據(jù)和控制分離的最佳實(shí)踐。
下面將分開介紹。
2、數(shù)據(jù)線
從2-2的穿山甲SDK架構(gòu)圖中，我們可以看到“數(shù)據(jù)線”分為如下幾個(gè)主要模塊：
1）數(shù)據(jù)API
2）緩存模塊
3）安全模塊
4）擴(kuò)展服務(wù)
（1）數(shù)據(jù)API
數(shù)據(jù)API就是打印日志的接口，和普通android打印日志基本一致。例子如下:
Logs.d(TAG, “key1=value1;key2=value2;…”);
在這里我們用了自己Logs類而不是android默認(rèn)的Log。日志的內(nèi)容，也是通過key=value的形式進(jìn)行連接。這是為了將來對(duì)日志的智能分析做的規(guī)范性要求。
（2）緩存模塊
緩存模塊主要對(duì)日志寫入SD卡前，做緩存管理提高性能。分為兩個(gè)部分：
1）L1緩存
在Android中所有Log.d打印的日志首先都會(huì)進(jìn)入L1緩存進(jìn)行排隊(duì)。等L1緩存達(dá)到臨界值，管理邏輯才會(huì)把L1緩存中所有內(nèi)容發(fā)送到L2緩存。
2）L2緩存
L2緩存是比較純粹的寫入緩沖區(qū)，負(fù)責(zé)寫入SD卡前最后緩存。
至于為什么會(huì)有L1和L2兩級(jí)緩存結(jié)構(gòu)，我們將在后續(xù)講解詳細(xì)描述。
（3）安全模塊
出于安全的考慮，日志內(nèi)容需要進(jìn)行壓縮加密存儲(chǔ)。這個(gè)地方就有一個(gè)問題：到底是先壓縮在加密，還是先加密在壓縮？ 其實(shí)這和我們采取加密算法也有關(guān)系。
大家都知道，普通Zip加密算法基于“滑動(dòng)窗口”。簡而言之，在“滑動(dòng)窗口”中出現(xiàn)的重復(fù)詞越多，壓縮比就越大。經(jīng)過我們實(shí)踐發(fā)現(xiàn)，很多加密算法加密后，重復(fù)的詞明顯比加密前要少。并且，越短的詞在加密后，字符串也越短。
1）DES加密
針對(duì)原始日志，進(jìn)行DES對(duì)稱加密。但是這樣做有個(gè)問題，加密和解密都是同一個(gè)秘鑰A。秘鑰A會(huì)記錄在客戶端SDK代碼中，雖然SDK代碼經(jīng)過混淆，但是也有被破解的風(fēng)險(xiǎn)。所以，我們加入了第二層的RSA加密。
2） RSA加密
大家都知道，RSA非對(duì)稱加密存在性能問題。為了規(guī)避性能損耗，我們只是用RSA來對(duì)DES的秘鑰A進(jìn)行加密，而不是對(duì)整個(gè)日志內(nèi)容假。我們將DES中的秘鑰A改為一個(gè)隨機(jī)字符串，用RSA的公鑰加密后，寫入日志文件第一行。當(dāng)日志傳到server后，讀取日志第一行，用RSA的私鑰解密后，得到DES的秘鑰A。在用秘鑰A對(duì)剩下的日志進(jìn)行解密，就能得到日志原文。
（4）擴(kuò)展服務(wù)
擴(kuò)展服務(wù)包括如下組件：
1）CPU監(jiān)控
采集CPU占用率，用來監(jiān)控APP中某個(gè)CPU超過閾值的場景。
2）FPS監(jiān)控
采集FPS占用率，用來監(jiān)控APP中某個(gè)FPS超過閾值的場景。
3）MEM監(jiān)控
采集MEM占用率，用來監(jiān)控APP中某個(gè)MEM超過閾值的場景。
4）基礎(chǔ)信息采集
基礎(chǔ)信息包括：機(jī)型、固件等軟硬件信息。
3、控制線
從2-2的穿山甲SDK架構(gòu)圖中，我們可以看到“控制線”分為如下幾個(gè)主要模塊：
1）Cmd API
2）Cmd模塊
3）基礎(chǔ)服務(wù)
4）SDK工具
（1）數(shù)據(jù)API
通過代碼調(diào)用Logs.upload就能立即上報(bào)日志。如果是通過Push通道，則需要符合SDK的協(xié)議字符串即可。
（2）Cmd模塊
所有對(duì)SDK的控制操作，都被包裝為CMD進(jìn)行。
1）協(xié)議解析
通過Push的API接口，是需要進(jìn)行協(xié)議解析的。例如：命令字符串c=3&date=20170424，就會(huì)被解析為：當(dāng)前命令是“上報(bào)日志”，日志范圍“2017年4月24日”的日志。
2）配置管理
對(duì)SDK固有設(shè)置進(jìn)行云端控制和更新。例如：是否打開錯(cuò)誤碼上報(bào)，是否上報(bào)用戶反饋日志等。
3）調(diào)度器
對(duì)所有命令進(jìn)行統(tǒng)Task框架調(diào)度管理。
（3）基礎(chǔ)服務(wù)
1）文件分片
我們的分片策略，是按照文件級(jí)別區(qū)分的。最早我們沒有按照日志級(jí)別區(qū)分，所有debug、info、warn、error都輸出在同一個(gè)日志文件。這樣造成一個(gè)后果，如果只是需要debug日志，不需要其他級(jí)別。那么在終端做日志二次提取，必然浪費(fèi)CPU和內(nèi)存。所以，直接按照日志級(jí)別分片為不同日志文件，將來可以直接只上報(bào)debug級(jí)別日志。
2）淘汰策略
日志根據(jù)容量進(jìn)行循環(huán)淘汰，這里需要預(yù)估在用戶側(cè)每日產(chǎn)生日志總體大小。
（4）SDK工具
1）ZipUtil
提供壓縮打包服務(wù)，除了日志文件，還能將其他文件附件也打包上傳。
2）UploadUtil
提供Http上傳能力。
3）Task回調(diào)
提供Task回調(diào)機(jī)制，能在任務(wù)成功、失敗等場景下實(shí)現(xiàn)不同的處理邏輯。
4、方案流程
圖表——穿山甲SDK解決問題思路
（1）分析埋點(diǎn)
問題發(fā)生前埋點(diǎn)：就是在沒有發(fā)生問題之前，對(duì)代碼中關(guān)鍵位置進(jìn)行埋點(diǎn)。例如：異常捕獲、DB信息、函數(shù)輸入輸出、Server信息、分之條件、File信息等。
問題發(fā)生或埋點(diǎn)：出現(xiàn)了用戶反饋后，在補(bǔ)充針對(duì)問題現(xiàn)象、相關(guān)邏輯、排除邏輯等代碼位置進(jìn)行埋點(diǎn)。
（2）數(shù)據(jù)收集
數(shù)據(jù)收集，利用“眾測”（公測和正式版不收集），收集用戶數(shù)據(jù)。這里收集標(biāo)準(zhǔn)有：錯(cuò)誤碼觸發(fā)和用戶主反饋。錯(cuò)誤碼觸發(fā)：當(dāng)一些已知問題發(fā)生時(shí)，收集程序日志進(jìn)行上報(bào)。用戶主動(dòng)反饋：用戶點(diǎn)擊反饋論壇進(jìn)行提交時(shí)，收集程序日志進(jìn)行上報(bào)。
（3）數(shù)據(jù)分析
在數(shù)據(jù)分析過程中，采用正則表達(dá)式提取，針對(duì)同一類型日志關(guān)鍵信息進(jìn)行提取。然后通過離群數(shù)據(jù)分析，找到“小眾”部分?jǐn)?shù)據(jù)，進(jìn)行人工分析。
（4）問題解決
通過日志分析出根本原因，開發(fā)進(jìn)行問題修改解決。
（5）線上驗(yàn)證
通過反饋平臺(tái)和日志上報(bào)，驗(yàn)證問題修復(fù)后，線上用戶驗(yàn)證是否已經(jīng)OK。
三、實(shí)踐效果
1、外部反饋數(shù)據(jù)
（1）反饋日志獲取時(shí)間縮短80%。
以往獲取一份用戶反饋日志，平均需要30小時(shí)。采用SDK后，平均日志獲取時(shí)間縮短為6小時(shí)不到。
（2）瀏覽器7類問題，比預(yù)期提前一個(gè)版本解決。
小說語音暫停、小說翻頁翻不了、小說下載失敗等問題比預(yù)期提前一個(gè)版本解決。
（3）廣告過濾類問題，每條處理時(shí)間縮短3天，縮短59%。
之前廣告過濾，聯(lián)系用戶效率特別低。通過穿山甲SDK把廣告URL直接上傳，大大節(jié)省了聯(lián)系用戶找到URL的時(shí)間。
2、內(nèi)部反饋處理
大家都知道，來自內(nèi)部的產(chǎn)品反饋，特別是老板的反饋，很難處理。究其原因：
老板記不清復(fù)現(xiàn)路徑
老板手機(jī)不能借給你
按照之前經(jīng)驗(yàn)，項(xiàng)目組只能按照“抓瞎”方式進(jìn)行問題解決。平均每個(gè)問題至少需要一周時(shí)間，還必須厚著臉皮去“騷擾”老板才行。
現(xiàn)在我們有個(gè)穿山甲SDK，只需要讓老板直接用。出了問題，一鍵上報(bào)日志即可，開發(fā)拿到日志后30分鐘就能解決問題。節(jié)約研發(fā)流程時(shí)間5天/問題，效益非常明顯。
3、H5游戲問題（1）背景
圖表——H5游戲打不開背景
有用戶反饋，部分H5游戲無法進(jìn)入，嚴(yán)重影響他們的游戲體驗(yàn)。也嚴(yán)重影響了H5游戲口碑。
（2）定位和解決
圖表 ——H5游戲打不開-定位問題
針對(duì)H5游戲打不開時(shí)，用戶網(wǎng)絡(luò)狀態(tài)進(jìn)行埋點(diǎn)。我們通過“眾測”發(fā)現(xiàn)：
1）排除網(wǎng)絡(luò)原因
94%用戶在H5游戲打不開的時(shí)候外部網(wǎng)絡(luò)是通暢的，初步排除網(wǎng)絡(luò)原因造成。
2）排除機(jī)型原因
對(duì)打不開的機(jī)型進(jìn)行歸類，通過本地?zé)o法復(fù)現(xiàn)，初步排除機(jī)型問題。
最后我們把目標(biāo)定位到CP服務(wù)質(zhì)量，也就是H5游戲服務(wù)器質(zhì)量上。最后發(fā)現(xiàn)，由于大部分CP為了節(jié)約成本，沒有把H5資源放在CDN服務(wù)器上，導(dǎo)致拉取失敗概率增加。通過和CP溝通后解決了這個(gè)問題。
四、總結(jié)
（1）需求階段
在需求評(píng)審階段，測試人員可以開發(fā)約定必要的事前埋點(diǎn)。為提前發(fā)現(xiàn)問題做好準(zhǔn)備。
（2）編碼階段
這個(gè)階段測試人員，可以和開發(fā)人員結(jié)對(duì)編程，添加主要事前埋點(diǎn)。為接下來解決集成測試中問題，奠定良好的基礎(chǔ)。
（3）眾測
產(chǎn)品發(fā)布“眾測”后，測試人員可以針對(duì)線上出現(xiàn)問題，添加解決問題事后埋點(diǎn)。精準(zhǔn)的解決特定問題。
根據(jù)我們經(jīng)驗(yàn)，良好的事前埋點(diǎn)，不僅能夠解決線上問題。對(duì)于研發(fā)流程中問題解決，也能起到巨大的作用。結(jié)合穿山甲SDK的日志上報(bào)能力，為傳統(tǒng)測試模式打開了一個(gè)新的方向與未來。
