1. 寶貝實(shí)驗(yàn)室簡(jiǎn)介

寶貝實(shí)驗(yàn)室是騰訊開放平臺(tái)為移動(dòng)開發(fā)者量身定制集合真機(jī)測(cè)試、評(píng)測(cè)任務(wù)發(fā)布系統(tǒng)、一鍵發(fā)布到應(yīng)用市場(chǎng)的綜合產(chǎn)品，現(xiàn)免費(fèi)開放給開發(fā)者使用。目前僅開放一期能力“寶貝實(shí)驗(yàn)室”，后續(xù)將會(huì)陸續(xù)放出二期和三期能力。
開發(fā)者可在上傳移動(dòng)APP的APK包后，在移動(dòng)APP的管理后臺(tái)通過(guò) “寶貝實(shí)驗(yàn)室” 的入口進(jìn)入（如下圖），再根據(jù)實(shí)際需求進(jìn)行使用。

2. 寶貝實(shí)驗(yàn)室之真機(jī)測(cè)試能力說(shuō)明

真機(jī)測(cè)試是提供給開發(fā)者進(jìn)行APK穩(wěn)定性檢測(cè)的基礎(chǔ)能力，來(lái)查看該APK在市場(chǎng)熱門機(jī)型的安裝成功率，確保開發(fā)者在發(fā)布前盡可能適配更多的機(jī)型，減少因安裝啟動(dòng)失敗而損失的用戶。在上傳APK包后即可開始真機(jī)測(cè)試。
測(cè)試時(shí)間說(shuō)明：正常情況下會(huì)在開始測(cè)試后15分鐘內(nèi)完成，如同時(shí)測(cè)試任務(wù)過(guò)多會(huì)有一段等待的時(shí)間，測(cè)試完成后您可以通過(guò)點(diǎn)擊查看測(cè)試報(bào)告，來(lái)查看測(cè)試的具體情況。

2.1 入口1（開放平臺(tái)管理端）

（1）請(qǐng)開發(fā)者在提交APK包后，再返回寶貝實(shí)驗(yàn)室頁(yè)面，即可開始真機(jī)測(cè)試；
（2）正常情況下15分鐘內(nèi)即可完成真機(jī)的穩(wěn)定性測(cè)試，在測(cè)試結(jié)束后會(huì)在OPEN官網(wǎng)頂部的消息內(nèi)進(jìn)行提示。
如圖所示：

2.2 入口2

騰訊移動(dòng)游戲開放平臺(tái)管理端 → 應(yīng)用管理中心 → 選擇需要測(cè)試的游戲 → 自服務(wù) → 微測(cè)試

2.3 能力說(shuō)明

一 ：上傳/更新移動(dòng)應(yīng)用的APK包之后，即可直接開始測(cè)試（無(wú)需提交源碼、選擇分辨率和選擇安卓版本），操作直觀上手簡(jiǎn)單。

二 ：測(cè)試結(jié)束之后，可下載測(cè)試結(jié)果到本地電腦查看，方便針對(duì)不同應(yīng)用版本的問題整理和回溯。

2.4 真機(jī)測(cè)試五大特點(diǎn)

2.5 常見問題

（1）真機(jī)測(cè)試是免費(fèi)的服務(wù)嗎？
是的，寶貝實(shí)驗(yàn)室中的功能均是免費(fèi)開放給移動(dòng)開發(fā)商進(jìn)行使用的。
（2）真機(jī)測(cè)試一般需要多久？
您好，一般在15分鐘內(nèi)可測(cè)試完畢，請(qǐng)不用停留在當(dāng)前頁(yè)面，測(cè)試結(jié)束后會(huì)有OPEN官方消息進(jìn)行通知，可在結(jié)果后再進(jìn)入寶貝實(shí)驗(yàn)室進(jìn)行查看。
（3）真機(jī)測(cè)試中的機(jī)型是市場(chǎng)上的熱門機(jī)型嗎？
是的，真機(jī)測(cè)試是使用當(dāng)前市場(chǎng)上最熱門的機(jī)型，單次測(cè)試任務(wù)會(huì)使用隨機(jī)五臺(tái)真實(shí)機(jī)型為您的APK進(jìn)行測(cè)試。
（4）為什么我看到的同一個(gè)APK的包的兩次測(cè)試結(jié)果不一致？
因單次測(cè)試是隨機(jī)抽取的五臺(tái)市場(chǎng)上熱門的機(jī)型，多次結(jié)果會(huì)隨機(jī)到不同的機(jī)型進(jìn)行測(cè)試，所以會(huì)出現(xiàn)測(cè)試結(jié)果不一致的情況，您可以點(diǎn)擊下載測(cè)試報(bào)告內(nèi)有詳細(xì)的說(shuō)明和機(jī)型。
（5）為什么我有時(shí)候等待超過(guò)15分鐘？
您好，由于我們是真機(jī)測(cè)試，可能會(huì)出現(xiàn)測(cè)試的任務(wù)過(guò)多而導(dǎo)致排隊(duì)的情況，建議您不用在當(dāng)前頁(yè)面等待，可在收到信息通知后再查看結(jié)果，一般測(cè)試任務(wù)的時(shí)間會(huì)在15分鐘內(nèi)測(cè)試完畢。
（6）真機(jī)測(cè)試還會(huì)提供其他的測(cè)試嗎？如電池耗能、穩(wěn)定性等？
您好，我們預(yù)計(jì)在二期中會(huì)增加更多測(cè)試的能力，請(qǐng)留意我們的官方公告，盡請(qǐng)期待。

3. 寶貝實(shí)驗(yàn)室之BUGLY監(jiān)控能力說(shuō)明

3.1 BUGly- Crash監(jiān)控能力

BUGly提供給騰訊移動(dòng)開發(fā)者免費(fèi)使用，提供全面的Crash出錯(cuò)信息，幫助移動(dòng)互聯(lián)網(wǎng)開發(fā)者更及時(shí)地發(fā)現(xiàn)異常，更全面地了解異常，更高效地修復(fù)異常。
備注：使用本功能需要在移動(dòng)APP的apk包內(nèi)添加對(duì)應(yīng)的SDK，請(qǐng)按3.3的下載說(shuō)明進(jìn)行對(duì)應(yīng)的配置。

3.2 訪問入口

訪問入口有如下兩種：
（1）登錄open.qq.com后，進(jìn)入應(yīng)用管理界面如下圖，點(diǎn)擊“寶貝實(shí)驗(yàn)室”，即可見到“騰訊Bugly”；
（2）直接訪問騰訊Bugly官網(wǎng)“bugly.qq.com”，通過(guò)QQ號(hào)登錄進(jìn)入，產(chǎn)品詳情頁(yè)點(diǎn)擊這里查看。

3.3 下載SDK和騰訊Bugly入口

“IOS SDK”點(diǎn)擊這里進(jìn)行下載說(shuō)明頁(yè)面。

“Android SDK” 點(diǎn)擊這里進(jìn)行下載頁(yè)面。

3.4 如何使用騰訊Bugly的Crash監(jiān)控平臺(tái)

登錄進(jìn)入應(yīng)用列表頁(yè)→點(diǎn)擊應(yīng)用名→進(jìn)入該應(yīng)用的異常首頁(yè)，即可看到應(yīng)用的問題列表。

（1）點(diǎn)擊進(jìn)入高級(jí)搜索頁(yè)

（2）點(diǎn)擊進(jìn)入issue詳情查看crash的詳細(xì)信息

（3）點(diǎn)擊進(jìn)入crash實(shí)時(shí)統(tǒng)計(jì)圖

（4）點(diǎn)擊進(jìn)入crash趨勢(shì)統(tǒng)計(jì)圖

3.5 Bugly能力解析

（1）多平臺(tái)支持：支持Android、iOS、WindowsPhone等平臺(tái)應(yīng)用的異常監(jiān)控；

（2）成熟的質(zhì)量監(jiān)控能力：累積超過(guò)百款品牌應(yīng)用多年的實(shí)踐經(jīng)驗(yàn)，擁有業(yè)界最全面的異常解決方案；

（3）安全可靠的大數(shù)據(jù)處理分析能力：日均覆蓋億級(jí)以上用戶，上報(bào)千萬(wàn)級(jí)以上異常，處理百億級(jí)以上請(qǐng)求；

（4）全面的Crash出錯(cuò)信息：出錯(cuò)堆棧，版本，內(nèi)存，cpu和硬盤數(shù)據(jù)；

（5）Android Native異常上報(bào)：Android NDK開發(fā)C/C++的移動(dòng)開發(fā)團(tuán)隊(duì)也可以使用Crash監(jiān)控；

（6）24小時(shí)實(shí)時(shí)監(jiān)控Crash：能讓開發(fā)者第一時(shí)間掌控版本質(zhì)量；

（7）Crash趨勢(shì)跟蹤：強(qiáng)大的數(shù)據(jù)分析能力，讓開發(fā)者對(duì)crash的變化趨勢(shì)一目了然；

（8）Crash高級(jí)搜索：業(yè)界領(lǐng)先的多維度搜索查詢服務(wù)助力開發(fā)者快速找到關(guān)鍵Crash信息。

3.6 常見問題（通用問題）

（1）Bugly上報(bào)哪些Crash？
Android應(yīng)用Java代碼導(dǎo)致的Crash、NDK C/C++開發(fā)導(dǎo)致的Crash，IOS應(yīng)用apple c++代碼導(dǎo)致的crash。
（2）如何獲取AppId及AppKey？
Bugly上創(chuàng)建產(chǎn)品后，在產(chǎn)品管理->產(chǎn)品詳情里可以看到產(chǎn)品的AppId及AppKey。
（3）Crash是立即上報(bào)嗎？
發(fā)生Crash會(huì)立即上報(bào)，如果上報(bào)不成功將會(huì)在在第二次啟動(dòng)時(shí)上報(bào)。
（4）什么是Bugly的異常合并？
為了保護(hù)App自動(dòng)拉起的重復(fù)Crash，導(dǎo)致用戶的流量消耗過(guò)高，相同異常發(fā)生次數(shù)太多時(shí)，會(huì)進(jìn)行合并，24小時(shí)內(nèi)不再進(jìn)行上報(bào)，但不會(huì)影響Crash次數(shù)的統(tǒng)計(jì)。
（5）Bugly支持幾個(gè)平臺(tái)Crash上報(bào)?
Android、iOS、wp。
（6）為什么異常沒有上報(bào)？
請(qǐng)檢查：
a. AppId是否設(shè)置正確；
b. 初始化SDK是否在Crash之前完成；
c. 網(wǎng)絡(luò)是否可用；
d. Crash一直沒上報(bào)？提供Bugly的logcat日志，找專人處理；
e. 前面有上報(bào)突然不上報(bào)了？如果一直是同一種Crash，可能觸發(fā)了Bugly的異常合并，請(qǐng)換一種異常再次嘗試！
（7）不配置還原符號(hào)表會(huì)影響異常上報(bào)嗎？會(huì)有什么影響？
不會(huì)影響異常上報(bào)！沒有符號(hào)表，堆棧無(wú)法還原成代碼中的類或方法及源文件行號(hào)，會(huì)對(duì)異常合并存在一定影響。
（8）什么是Issue？Crash和Issue的關(guān)系？
用戶的每次崩潰對(duì)應(yīng)Bugly上的一條Crash，Bugly根據(jù)算法把相同原因?qū)е碌腃rash匯總成一類問題Issue，提高用戶處理異常的效率。
（9）每個(gè)版本都要配置符號(hào)表嗎？
需要！一個(gè)Appid+版本，需要對(duì)應(yīng)一份符號(hào)表（Java的Mapping文件及SO的Symbol文件，applec++的dsym文件），配置只對(duì)設(shè)置的版本有效，重復(fù)配置將會(huì)覆蓋。
（10）什么是Bugly的異常合并
為了保護(hù)App自動(dòng)拉起的重復(fù)Crash，導(dǎo)致用戶的流量消耗過(guò)高，相同異常發(fā)生次數(shù)太多時(shí)，會(huì)進(jìn)行合并，24小時(shí)內(nèi)不再進(jìn)行上報(bào)，但不會(huì)影響Crash次數(shù)的統(tǒng)計(jì)。
（11）為什么相同的用戶一天上報(bào)了幾百條Crash？
檢查是否存在Crash后，進(jìn)程會(huì)被自動(dòng)再次拉起（系統(tǒng)的、代碼邏輯的），導(dǎo)致一致Crash！例如Service、Recevier等都比較容易出現(xiàn)自動(dòng)拉起的情況。

3.7 常見問題（Andorid問題）

（1）Java的Crash是什么？
Java運(yùn)行時(shí)沒有被Try Catched住的Throwable，拋到JVM導(dǎo)致JVM退出的過(guò)程就是Java的Crash。
（2）Native的Crash是什么？
C/C++運(yùn)行時(shí)出錯(cuò)，系統(tǒng)產(chǎn)生了Linux錯(cuò)誤信號(hào)，導(dǎo)致出錯(cuò)進(jìn)程退出就是Native的Crash。
（3）Bugly上報(bào)哪些Native Crash？
信號(hào)類型為SIGILL、SIGFPE、SIGSEGV、SIGBUS、SIGABRT、SIGSTKFLT的Crash會(huì)被上報(bào)。
（4）什么是Java的還原符號(hào)文件？
產(chǎn)品在發(fā)布時(shí)一般會(huì)使用Progurad工具對(duì)代碼進(jìn)行混淆，提高安全性，在使用Progurad工具進(jìn)行代碼混淆時(shí)會(huì)可以生成一個(gè)mapping文件，稱為Java的還原符號(hào)文件。
（5）為什么要上傳Java還原符號(hào)文件？
產(chǎn)品發(fā)布的安裝包，一般代碼經(jīng)過(guò)混淆，導(dǎo)致上報(bào)的異常堆棧中的類名和方法名是一種不可讀的方式（例如a.b()），Bugly需要通過(guò)Java還原符號(hào)表還原回真實(shí)的可讀的類名和方法名（例如：MyClass.myMehtod()）。
（6）什么是Native的還原符號(hào)文件？
通過(guò)Bugly的還原符號(hào)提取工具，從產(chǎn)品開發(fā)的帶有debug信息的SO中提取出還原符號(hào)信息生成的文件，稱為Native的還原符號(hào)文件。
（7）什么是Native的還原符號(hào)提取工具，都提取什么信息？
用于提取出帶Debug信息的SO中的，debug_line 信息的工具，生成的符號(hào)表信息包含方法名、源文件名、源文件行號(hào)，用于把SO出錯(cuò)時(shí)的錯(cuò)誤地址還原回可讀的代碼地址。
（8）為什么要上傳Native的還原符號(hào)文件？
Bugly上報(bào)的SO出錯(cuò)時(shí)堆棧中的錯(cuò)誤地址不可讀，為了提高用戶定位問題的效率，需要用戶上傳還原符號(hào)文件，Bugly可以把這些不可讀的錯(cuò)誤地址轉(zhuǎn)成可讀的代碼方法及行號(hào)。
（9）Android單獨(dú)使用SDK的Jar或SO是否可以？
SDK的Jar是必選的，SO是可選的，如果是C/C++的App建議把SO帶上。
（10）kill -9、exit等會(huì)被當(dāng)成Crash上報(bào)嗎？
不會(huì)。
（11）try catch的異常會(huì)被當(dāng)成Crash上報(bào)嗎？
不會(huì)。
（12）如何獲得Bugly的Logcat日志？
初始化SDK時(shí)參數(shù)isDebug設(shè)置為true，把Logcat中的crashReport tag的日志拷貝到文件即可。
（13）為什么有些Crash上用戶名是unknown？應(yīng)該如何設(shè)置用戶名？
用戶名需要App代碼中setUserId()塞入，默認(rèn)是unknown，如果Crash時(shí)未設(shè)置則上報(bào)的Crash中的用戶名就是unknwon。
（14）App無(wú)響應(yīng)異常（ANR）能否捕獲？
不行。
（15）SO的符號(hào)表生成工具無(wú)法工作？
請(qǐng)檢查：
a. SO是否帶debug信息的So，如果是ndk編譯，一般會(huì)在obj\目錄下存放的是debug so，lib目錄放的是用于發(fā)布的release的so；
b. 文件的路徑是否正確，請(qǐng)嘗試使用完整的文件路徑；
c. 可以把控制臺(tái)輸出及輸入文件提交給Bugly專人進(jìn)行跟進(jìn)。
（16）如何識(shí)別SO是否帶有debug信息？
可以通過(guò)readelf -S SO路徑的命令查看是否存在debuginfo及debugline的段。（windows用戶可以安裝cgwin或mingw）。

3.8 常見問題（IOS問題）

（1）Bugly(IOS)能捕獲哪些異常？
Bugly通過(guò)注冊(cè)NSUnCaughtExceptionHandler監(jiān)聽未被try catch的Objective C(簡(jiǎn)稱OC)代碼異常。
Bugly通過(guò)注冊(cè)SIGABRT/SIGBUS/SIGFPE/SIGILL/SIGSEGV/SIGTRAP幾個(gè)unix信號(hào)，監(jiān)聽C代碼引發(fā)的系統(tǒng)異常信號(hào)。
（2）監(jiān)聽接口會(huì)與其他同類的工具沖突嗎？
會(huì)，同樣的接口注冊(cè)會(huì)覆蓋（除非其他注冊(cè)者保留當(dāng)前注冊(cè)函數(shù)并發(fā)出通知），不建議再調(diào)用這個(gè)接口設(shè)置自己的handler。如果想要在異常的時(shí)候做某些處理，請(qǐng)使用Bugly提供的回調(diào)函數(shù)。
（3）能捕獲卡死的crash嗎
不能。 越獄擴(kuò)展包會(huì)從系統(tǒng)的crashlog中查找并上報(bào)這類的crash。
（4）能捕獲Lowmemory導(dǎo)致的crash嗎
不能。
（5）本地調(diào)試無(wú)法使用。
在本地調(diào)試的時(shí)候，如果使用xcode啟動(dòng)應(yīng)用，gdb/lldb會(huì)攔截到信號(hào)并停止應(yīng)用運(yùn)行，Bugly就無(wú)法獲取信號(hào)并處理，所以不能使用xcode啟動(dòng)（NSException可以點(diǎn)擊斷點(diǎn)繼續(xù)執(zhí)行，可以使用xcode啟動(dòng)調(diào)試）。
（6）基于用戶的crash統(tǒng)計(jì)。
Bugly上報(bào)是會(huì)上報(bào)用戶id(userId)和一個(gè)設(shè)備id(deviceId)，但后臺(tái)只會(huì)會(huì)基于設(shè)備id統(tǒng)計(jì)crash影響用戶，deviceId是用自動(dòng)生產(chǎn)的一個(gè)uuid并保存在本地以及剪貼板。
（7）Crash堆棧不可讀。
Bugly上報(bào)的crash堆棧是應(yīng)用部分只有地址信息的，需要配置符號(hào)表才能對(duì)上報(bào)的crash進(jìn)行符號(hào)化，或者可以開啟進(jìn)程內(nèi)還原。
（8）什么是符號(hào)表？
IOS的應(yīng)用編譯的時(shí)候生產(chǎn)的dSYM文件，一般在build目錄下，名稱為*.app.dSYM的一個(gè)目錄。 Bugly會(huì)對(duì)這個(gè)符號(hào)表文件進(jìn)行解析，取出無(wú)用的信息，得到一個(gè)較小的新符號(hào)表用于上傳。
（9）進(jìn)程內(nèi)還原結(jié)果不對(duì)。
如果應(yīng)用的設(shè)置里面STRIP選項(xiàng)是ALL Symbols，那么還原是會(huì)出現(xiàn)錯(cuò)誤的，不能開啟進(jìn)程內(nèi)還原。
（10）上報(bào)堆棧中系統(tǒng)模塊會(huì)部分還原失敗。
較新的系統(tǒng)版本在進(jìn)程內(nèi)調(diào)用符號(hào)轉(zhuǎn)換函數(shù)（dladdr）的時(shí)候會(huì)得到一個(gè)的結(jié)果，并不能得到正確的系統(tǒng)函數(shù)。
Bugly在后臺(tái)還會(huì)進(jìn)行一次還原，如果Bugly后臺(tái)有對(duì)應(yīng)該系統(tǒng)的符號(hào)表，你會(huì)看到正確的結(jié)果。
（11）上報(bào)堆棧中某些系統(tǒng)版本分會(huì)還原失敗
Bugly在符號(hào)表系統(tǒng)堆棧的時(shí)候，需要對(duì)應(yīng)系統(tǒng)版本的庫(kù)，有很多小版本ios的build需要從設(shè)備上導(dǎo)出，只有收集到該系統(tǒng)的符號(hào)表才能進(jìn)行還原。
（12）加入bugly的lib庫(kù)以后，出現(xiàn)std c++庫(kù)鏈接錯(cuò)誤。br> 這是因?yàn)樵赽ugly的lib庫(kù)中使用了std c++庫(kù)，為了確保你的工程編譯通過(guò)，我們提供兩種解決方案：
請(qǐng)將你應(yīng)用的c++庫(kù)設(shè)置為libstdc++，同時(shí)工程里面至少要有一個(gè).mm的混編文件；
deploymenttarget選擇6.1或以下。
建議采用第一個(gè)方案。