1. 宝贝实验室简介
宝贝实验室是腾讯开放平台为移动开发者量身定制集合真机测试、评测任务发布系统、一键发布到应用市场的综合产品，现免费开放给开发者使用。目前仅开放一期能力“宝贝实验室”，后续将会陆续放出二期和三期能力。
开发者可在上传移动APP的APK包后，在移动APP的管理后台通过 “宝贝实验室” 的入口进入（如下图），再根据实际需求进行使用。
2. 宝贝实验室之真机测试能力说明
真机测试是提供给开发者进行APK稳定性检测的基础能力，来查看该APK在市场热门机型的安装成功率，确保开发者在发布前尽可能适配更多的机型，减少因安装启动失败而损失的用户。在上传APK包后即可开始真机测试。
测试时间说明：正常情况下会在开始测试后15分钟内完成，如同时测试任务过多会有一段等待的时间，测试完成后您可以通过点击查看测试报告，来查看测试的具体情况。
2.1 入口1（开放平台管理端）
（1）请开发者在提交APK包后，再返回宝贝实验室页面，即可开始真机测试；
（2）正常情况下15分钟内即可完成真机的稳定性测试，在测试结束后会在OPEN官网顶部的消息内进行提示。
如图所示：
2.2 入口2
腾讯移动游戏开放平台管理端 → 应用管理中心 → 选择需要测试的游戏 → 自服务 → 微测试
2.3 能力说明
一 ：上传/更新移动应用的APK包之后，即可直接开始测试（无需提交源码、选择分辨率和选择安卓版本），操作直观上手简单。
二 ：测试结束之后，可下载测试结果到本地电脑查看，方便针对不同应用版本的问题整理和回溯。
2.4 真机测试五大特点
2.5 常见问题
（1）真机测试是免费的服务吗？
是的，宝贝实验室中的功能均是免费开放给移动开发商进行使用的。
（2）真机测试一般需要多久？
您好，一般在15分钟内可测试完毕，请不用停留在当前页面，测试结束后会有OPEN官方消息进行通知，可在结果后再进入宝贝实验室进行查看。
（3）真机测试中的机型是市场上的热门机型吗？
是的，真机测试是使用当前市场上最热门的机型，单次测试任务会使用随机五台真实机型为您的APK进行测试。
（4）为什么我看到的同一个APK的包的两次测试结果不一致？
因单次测试是随机抽取的五台市场上热门的机型，多次结果会随机到不同的机型进行测试，所以会出现测试结果不一致的情况，您可以点击下载测试报告内有详细的说明和机型。
（5）为什么我有时候等待超过15分钟？
您好，由于我们是真机测试，可能会出现测试的任务过多而导致排队的情况，建议您不用在当前页面等待，可在收到信息通知后再查看结果，一般测试任务的时间会在15分钟内测试完毕。
（6）真机测试还会提供其他的测试吗？如电池耗能、稳定性等？
您好，我们预计在二期中会增加更多测试的能力，请留意我们的官方公告，尽请期待。
3. 宝贝实验室之BUGLY监控能力说明
3.1 BUGly- Crash监控能力
BUGly提供给腾讯移动开发者免费使用，提供全面的Crash出错信息，帮助移动互联网开发者更及时地发现异常，更全面地了解异常，更高效地修复异常。
备注：使用本功能需要在移动APP的apk包内添加对应的SDK，请按3.3的下载说明进行对应的配置。
3.2 访问入口
访问入口有如下两种：
（1）登录open.qq.com后，进入应用管理界面如下图，点击“宝贝实验室”，即可见到“腾讯Bugly”；
（2）直接访问腾讯Bugly官网“bugly.qq.com”，通过QQ号登录进入，产品详情页点击这里查看。
3.3 下载SDK和腾讯Bugly入口
“IOS SDK”点击这里进行下载说明页面。
“Android SDK” 点击这里进行下载页面。
3.4 如何使用腾讯Bugly的Crash监控平台
登录进入应用列表页→点击应用名→进入该应用的异常首页，即可看到应用的问题列表。
（1）点击进入高级搜索页
（2）点击进入issue详情查看crash的详细信息
（3）点击进入crash实时统计图
（4）点击进入crash趋势统计图
3.5 Bugly能力解析
（1）多平台支持：支持Android、iOS、WindowsPhone等平台应用的异常监控；
（2）成熟的质量监控能力：累积超过百款品牌应用多年的实践经验，拥有业界最全面的异常解决方案；
（3）安全可靠的大数据处理分析能力：日均覆盖亿级以上用户，上报千万级以上异常，处理百亿级以上请求；
（4）全面的Crash出错信息：出错堆栈，版本，内存，cpu和硬盘数据；
（5）Android Native异常上报：Android NDK开发C/C++的移动开发团队也可以使用Crash监控；
（6）24小时实时监控Crash：能让开发者第一时间掌控版本质量；
（7）Crash趋势跟踪：强大的数据分析能力，让开发者对crash的变化趋势一目了然；
（8）Crash高级搜索：业界领先的多维度搜索查询服务助力开发者快速找到关键Crash信息。
3.6 常见问题（通用问题）
（1）Bugly上报哪些Crash？
Android应用Java代码导致的Crash、NDK C/C++开发导致的Crash，IOS应用apple c++代码导致的crash。
（2）如何获取AppId及AppKey？
Bugly上创建产品后，在产品管理->产品详情里可以看到产品的AppId及AppKey。
（3）Crash是立即上报吗？
发生Crash会立即上报，如果上报不成功将会在在第二次启动时上报。
（4）什么是Bugly的异常合并？
为了保护App自动拉起的重复Crash，导致用户的流量消耗过高，相同异常发生次数太多时，会进行合并，24小时内不再进行上报，但不会影响Crash次数的统计。
（5）Bugly支持几个平台Crash上报?
Android、iOS、wp。
（6）为什么异常没有上报？
请检查：
a. AppId是否设置正确；
b. 初始化SDK是否在Crash之前完成；
c. 网络是否可用；
d. Crash一直没上报？提供Bugly的logcat日志，找专人处理；
e. 前面有上报突然不上报了？如果一直是同一种Crash，可能触发了Bugly的异常合并，请换一种异常再次尝试！
（7）不配置还原符号表会影响异常上报吗？会有什么影响？
不会影响异常上报！没有符号表，堆栈无法还原成代码中的类或方法及源文件行号，会对异常合并存在一定影响。
（8）什么是Issue？Crash和Issue的关系？
用户的每次崩溃对应Bugly上的一条Crash，Bugly根据算法把相同原因导致的Crash汇总成一类问题Issue，提高用户处理异常的效率。
（9）每个版本都要配置符号表吗？
需要！一个Appid+版本，需要对应一份符号表（Java的Mapping文件及SO的Symbol文件，applec++的dsym文件），配置只对设置的版本有效，重复配置将会覆盖。
（10）什么是Bugly的异常合并
为了保护App自动拉起的重复Crash，导致用户的流量消耗过高，相同异常发生次数太多时，会进行合并，24小时内不再进行上报，但不会影响Crash次数的统计。
（11）为什么相同的用户一天上报了几百条Crash？
检查是否存在Crash后，进程会被自动再次拉起（系统的、代码逻辑的），导致一致Crash！例如Service、Recevier等都比较容易出现自动拉起的情况。
3.7 常见问题（Andorid问题）
（1）Java的Crash是什么？
Java运行时没有被Try Catched住的Throwable，抛到JVM导致JVM退出的过程就是Java的Crash。
（2）Native的Crash是什么？
C/C++运行时出错，系统产生了Linux错误信号，导致出错进程退出就是Native的Crash。
（3）Bugly上报哪些Native Crash？
信号类型为SIGILL、SIGFPE、SIGSEGV、SIGBUS、SIGABRT、SIGSTKFLT的Crash会被上报。
（4）什么是Java的还原符号文件？
产品在发布时一般会使用Progurad工具对代码进行混淆，提高安全性，在使用Progurad工具进行代码混淆时会可以生成一个mapping文件，称为Java的还原符号文件。
（5）为什么要上传Java还原符号文件？
产品发布的安装包，一般代码经过混淆，导致上报的异常堆栈中的类名和方法名是一种不可读的方式（例如a.b()），Bugly需要通过Java还原符号表还原回真实的可读的类名和方法名（例如：MyClass.myMehtod()）。
（6）什么是Native的还原符号文件？
通过Bugly的还原符号提取工具，从产品开发的带有debug信息的SO中提取出还原符号信息生成的文件，称为Native的还原符号文件。
（7）什么是Native的还原符号提取工具，都提取什么信息？
用于提取出带Debug信息的SO中的，debug_line 信息的工具，生成的符号表信息包含方法名、源文件名、源文件行号，用于把SO出错时的错误地址还原回可读的代码地址。
（8）为什么要上传Native的还原符号文件？
Bugly上报的SO出错时堆栈中的错误地址不可读，为了提高用户定位问题的效率，需要用户上传还原符号文件，Bugly可以把这些不可读的错误地址转成可读的代码方法及行号。
（9）Android单独使用SDK的Jar或SO是否可以？
SDK的Jar是必选的，SO是可选的，如果是C/C++的App建议把SO带上。
（10）kill -9、exit等会被当成Crash上报吗？
不会。
（11）try catch的异常会被当成Crash上报吗？
不会。
（12）如何获得Bugly的Logcat日志？
初始化SDK时参数isDebug设置为true，把Logcat中的crashReport tag的日志拷贝到文件即可。
（13）为什么有些Crash上用户名是unknown？应该如何设置用户名？
用户名需要App代码中setUserId()塞入，默认是unknown，如果Crash时未设置则上报的Crash中的用户名就是unknwon。
（14）App无响应异常（ANR）能否捕获？
不行。
（15）SO的符号表生成工具无法工作？
请检查：
a. SO是否带debug信息的So，如果是ndk编译，一般会在obj\目录下存放的是debug so，lib目录放的是用于发布的release的so；
b. 文件的路径是否正确，请尝试使用完整的文件路径；
c. 可以把控制台输出及输入文件提交给Bugly专人进行跟进。
（16）如何识别SO是否带有debug信息？
可以通过readelf -S SO路径的命令查看是否存在debuginfo及debugline的段。（windows用户可以安装cgwin或mingw）。
3.8 常见问题（IOS问题）
（1）Bugly(IOS)能捕获哪些异常？
Bugly通过注册NSUnCaughtExceptionHandler监听未被try catch的Objective C(简称OC)代码异常。
Bugly通过注册SIGABRT/SIGBUS/SIGFPE/SIGILL/SIGSEGV/SIGTRAP几个unix信号，监听C代码引发的系统异常信号。
（2）监听接口会与其他同类的工具冲突吗？
会，同样的接口注册会覆盖（除非其他注册者保留当前注册函数并发出通知），不建议再调用这个接口设置自己的handler。如果想要在异常的时候做某些处理，请使用Bugly提供的回调函数。
（3）能捕获卡死的crash吗
不能。 越狱扩展包会从系统的crashlog中查找并上报这类的crash。
（4）能捕获Lowmemory导致的crash吗
不能。
（5）本地调试无法使用。
在本地调试的时候，如果使用xcode启动应用，gdb/lldb会拦截到信号并停止应用运行，Bugly就无法获取信号并处理，所以不能使用xcode启动（NSException可以点击断点继续执行，可以使用xcode启动调试）。
（6）基于用户的crash统计。
Bugly上报是会上报用户id(userId)和一个设备id(deviceId)，但后台只会会基于设备id统计crash影响用户，deviceId是用自动生产的一个uuid并保存在本地以及剪贴板。
（7）Crash堆栈不可读。
Bugly上报的crash堆栈是应用部分只有地址信息的，需要配置符号表才能对上报的crash进行符号化，或者可以开启进程内还原。
（8）什么是符号表？
IOS的应用编译的时候生产的dSYM文件，一般在build目录下，名称为*.app.dSYM的一个目录。 Bugly会对这个符号表文件进行解析，取出无用的信息，得到一个较小的新符号表用于上传。
（9）进程内还原结果不对。
如果应用的设置里面STRIP选项是ALL Symbols，那么还原是会出现错误的，不能开启进程内还原。
（10）上报堆栈中系统模块会部分还原失败。
较新的系统版本在进程内调用符号转换函数（dladdr）的时候会得到一个的结果，并不能得到正确的系统函数。
Bugly在后台还会进行一次还原，如果Bugly后台有对应该系统的符号表，你会看到正确的结果。
（11）上报堆栈中某些系统版本分会还原失败
Bugly在符号表系统堆栈的时候，需要对应系统版本的库，有很多小版本ios的build需要从设备上导出，只有收集到该系统的符号表才能进行还原。
（12）加入bugly的lib库以后，出现std c++库链接错误。br>
这是因为在bugly的lib库中使用了std c++库，为了确保你的工程编译通过，我们提供两种解决方案：
请将你应用的c++库设置为libstdc++，同时工程里面至少要有一个.mm的混编文件；
deploymenttarget选择6.1或以下。
建议采用第一个方案。
|
