宝贝实验室

目录

1. 宝贝实验室简介

宝贝实验室是腾讯开放平台为移动开发者量身定制集合真机测试、评测任务发布系统、一键发布到应用市场的综合产品,现免费开放给开发者使用。目前仅开放一期能力“宝贝实验室”,后续将会陆续放出二期和三期能力。
开发者可在上传移动APP的APK包后,在移动APP的管理后台通过 “宝贝实验室” 的入口进入(如下图),再根据实际需求进行使用。
baobeishiyanshi-01.png

2. 宝贝实验室之真机测试能力说明

真机测试是提供给开发者进行APK稳定性检测的基础能力,来查看该APK在市场热门机型的安装成功率,确保开发者在发布前尽可能适配更多的机型,减少因安装启动失败而损失的用户。在上传APK包后即可开始真机测试。
测试时间说明:正常情况下会在开始测试后15分钟内完成,如同时测试任务过多会有一段等待的时间,测试完成后您可以通过点击查看测试报告,来查看测试的具体情况。

2.1 入口1(开放平台管理端)

(1)请开发者在提交APK包后,再返回宝贝实验室页面,即可开始真机测试;
(2)正常情况下15分钟内即可完成真机的稳定性测试,在测试结束后会在OPEN官网顶部的消息内进行提示。
如图所示:
baobeishiyanshi-02.png

2.2 入口2

腾讯移动游戏开放平台管理端 → 应用管理中心 → 选择需要测试的游戏 → 自服务 → 微测试

2.3 能力说明

一 :上传/更新移动应用的APK包之后,即可直接开始测试(无需提交源码、选择分辨率和选择安卓版本),操作直观上手简单。 baobeishiyanshi-05.png

二 :测试结束之后,可下载测试结果到本地电脑查看,方便针对不同应用版本的问题整理和回溯。 baobeishiyanshi-06.png

2.4 真机测试五大特点

baobeishiyanshi-07.png

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的下载说明进行对应的配置。
baobeishiyanshi-03.png

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监控平台

登录进入应用列表页→点击应用名→进入该应用的异常首页,即可看到应用的问题列表。
baobeishiyanshi-04.png

(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或以下。
建议采用第一个方案。

以上信息是否解决您的问题?

Copyright © 1998 - 2019 Tencent. All Rights Reserved.

腾讯公司 版权所有

有问必答 返回顶部