概述
Acra是老牌的bug自动采集系统。接入sdk后,可以实现程序崩溃自动发送崩溃日志。
发送自定义的错误日志等功能。具体详细介绍可以参见acra官网地址。
整体来看,Acra就是通过sdk收集进程的崩溃日志,然后以http或mail(默认的两类Sender)的方式将数据发送出去。服务器则是一套基于json的restful的接口。
服务端方面不是本次分析重点,暂不进行分析。
本系列文章将基于Acra 4.9.0 RC2源码进行分析。
Backend
服务端方面我们需要先搭建一个server,才能更好的看到我们的崩溃信息,
更直观的看到acra给我们提供了哪些针对崩溃的采集内容。
官方提供了acralyzer以及一些针对acra的第三方开源实现。
关于世面上常用的server端的,该文章做了明确分析,针对不同backend的比较。
官方backend acralyzer的搭建非常简单,具体可以参见该文章的server配置部分。
项目搭建完成后可以使用通过如下的url对server端进行访问。
查看app崩溃的表结构
http://ip:port/_utils/
查看崩溃日志
http://ip:port/acralyzer/_design/acralyzer/index.html#/dashboard/
关于server端的介绍结束。不是重点。
Client
项目构建
最新版本项目基于Gradle构建,了解Acra历史的肯定知道该项目是存在了很久了.
Android世界中项目最早是基于ant构建,后来是maven,现在是Gradle。
在没有Gradle的编译环境之前,基本上大部分是基于maven构建。
查看最新版本的代码可以看到仍然包含了之前maven的配置文件。
并且使用Gradle编译编译中使用到的version name等配置参数也都是从pom.xml中读取的。
具体可以参看build.gradle中关于版本号的相关配置。
需要注意的是,从github clone下来的项目是无法直接使用Gradle进行编译的。
熟悉Gradle android 编译流程的人应该从build.gradle文件中可以找出错误的原因。
具体的编译文件需要修改的地方为,在build.gradle中开头位置添加编译android项目使用到的plugin。
如下所示:
//此部分添加到build.gradle开头
buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'com.android.tools.build:gradle:2.1.0'
}
}
allprojects {
repositories {
jcenter()
}
}
task clean(type: Delete) {
delete rootProject.buildDir
}
//此部分添加到build.gradle开头
添加之后,就可以执行gradle build
命令打出需要使用的aar包。
项目配置及使用
首先需要注意一点,Acra使用独立进程:acra
,进行采集数据的发送,保证当app崩溃时,采集仍然能发送出去。
由于使用独立的进程,所以会导致application被实例化多次,这样就需要注意app自身的某些业务逻辑,不要在application类中执行多次,从而导致app产生bug。
对Acra的相关配置一般在application中进行初始化。
初始化配置
在application中进行初始化配置。
- 使用注解初始化
import org.acra.*;
import org.acra.annotation.*;
@ReportsCrashes(
formUri = "http://www.backendofyourchoice.com/reportpath"
)
public class MyApplication extends Application {
@Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
// 调用init方法,对acra进行初始化.
ACRA.init(this);
}
}
- 动态初始化配置
import org.acra.ACRA;
import org.acra.configuration.*;
public class MyApplication extends Application {
@Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
//使用ConfigurationBuilder构建ACRAConfirueation
final ACRAConfiguration config = new ConfigurationBuilder(this)
.setFoo(foo)
.setBar(bar)
.build();
// 传参的方式初始化acra
ACRA.init(this, config);
}
}
一般使用acra我们的目的是采集崩溃,所以需要在manifest中申请网络权限,以保证crash的正常发送。
<uses-permission android:name="android.permission.INTERNET"/>
目标服务器配置
acra中发送crash数据是通过Sender实现的,Sender是通过ReportSenderFactory实例化出来的。
而ReportSenderFactory是可以在初始化时进行配置的。
acra默认提供了email及http 两种sender。
如果自定义Sender则需要两个步骤,
- 实现ReportSender接口,用来执行发送报告操作。
- 实现ReportSenderFactory接口,用来创建自定义sender。
public class YourOwnSender implements ReportSender {
@Override
public void send(Context context, CrashReportData report) throws ReportSenderException {
// 遍历 CrashReportData 并做发送操作
}
}
public class YourOwnSenderfactory implements ReportSenderFactory {
// 由于在SenderService中通过Class.newInstance()来实例化对象
// 所以需要保证实例化的类的构造函数有一个默认无参的构造函数
// 自定义的ReportSenderFactory必须包含一个不含参数的构造函数
public ReportSender create(Context context, ACRAConfiguration config) {
...
return new YourOwnSender(someConfigPerhaps);
}
}
针对Sender的配置有两种形式,一种为注解,一种为通过代码进行设置。
//注解的方式设置Sender
@ReportCrashes{
reportSenderFactoryClasses = {
your.funky.ReportSenderFactory.class,
other.funky.ReportSenderFactory.class
}
}
public class YourApplication extends Application {
...
}
//代码的方式设置Sender
@ReportCrashes{
...
}
public class YourApplication extends Application {
@Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
final Class<? extends ReportSenderFactory>[] myReportSenderFactoryClasses = ...
// 初始化一个ConfigurationBuilder,并设置ReportSenderFactoryClasses.
final ACRAConfiguration config = new ConfigurationBuilder(this)
.setReportSenderFactoryClasses(myReportSenderFactoryClasses)
.build();
ACRA.init(this, config);
}
}
Acra中默认提供两个Sender
- HttpSender
- 提供了Post及Put两种提交crash到服务器的方式。
- 提交的类型可以为JSON或Form表单两种方式。
建议使用Put方式进行提交。
Put可以理解成已经知道了某个资源的位置.代表直接更新或创建该资源。
POST为不知道某个资源的位置,由server端来决定对该资源进行何种方式的存储。
所以在此场景下使用Put操作更合适,因为每一条bug实际上就应该对应与数据库中的一条,
只是该条记录还没有上传到服务器。
关于post与put的差别,具体可以查看该文档when should use PUT and when should use POST
- EmailIntentSender
组拼crash Report 通过intent调用系统提供的发送email的app。
流程分析及重点类分析
初始化设置流程
Acra的初始化函数为init,所以使用入口函数ACRA.init()对acra进行初始化。
一般入口函数在application初始化时进行调用。
ACRA.init()
使用ReportsCrashes来初始化Acra。
ACRA提供多个init方法,经过内部调用,最终都会调用参数最多的init方法完成初始化相关逻辑。
下面对重要的init方法进行说明
class ACRA {
//使用Application的注解进行初始化
public static void init(Application app){
//获取application上的注解
final ReportsCrashes reportsCrashes =
app.getClass().getAnnotation(ReportsCrashes.class);
//ConfigurationBuilder中通过注解获取application上配置的注解信息
init(app, new ConfigurationBuilder(app).build());
}
//参数 checkReportsOnApplicationStart 表示
//是否立即执行ErrorReporter.checkReportsOnApplicationStart()方法
public static void init(Application app, ACRAConfiguration config, boolean checkReportsOnApplicationStart){
//根据process的名字判断执行当前方法执行时所在的进程是否是发送crash的进程
final boolean senderServiceProcess = isACRASenderServiceProcess(app);
//ACRA只支持2.3以上的系统版本,所以预先做判断
final boolean supportedAndroidVersion = Build.VERSION.SDK_INT >= Build.VERSION_CODES.FROYO;
//保存config
configProxy = config;
//获取ACRA保存配置的SharedPreferences
final SharedPreferences prefs = new SharedPreferencesFactory(mApplication, configProxy).create();
if (!prefs.getBoolean(PREF__LEGACY_ALREADY_CONVERTED_TO_4_8_0, false)) {
//处理之前的版本的日志文件
}
errorReporterSingleton = new ErrorReporter(mApplication, configProxy, prefs, enableAcra, supportedAndroidVersion, !senderServiceProcess);
//当在非Sender进程,并设置app启动时发送report的情况下进行检测。
//当在Sender进程中,不需要进行检测,因为Sender进程中的逻辑自己会进行判断处理
if (checkReportsOnApplicationStart && !senderServiceProcess) {
//执行发送的相关业务逻辑
final ApplicationStartupProcessor startupProcessor =
new ApplicationStartupProcessor(mApplication, config);
if (config.deleteOldUnsentReportsOnApplicationStart()) {
startupProcessor.deleteUnsentReportsFromOldAppVersion();
}
if (config.deleteUnapprovedReportsOnApplicationStart()) {
startupProcessor.deleteAllUnapprovedReportsBarOne();
}
if (enableAcra) {
startupProcessor.sendApprovedReports();
}
}
}
}
ConfigurationBuilder
主要用来封装构造ACRAConfiguration的相关属性。
提供了两种方式来设置相关属性的值。
- 构造函数通过注解的方式,获取Application中定义注解的值,进行设置。
- 通过set方法,设置每个不同的配置项。
获取属性值之后,通过调用build()方法,创建ACRAConfiguration对象。
//通过app的注解所配置的值对builder对象本身进行初始化
public ConfigurationBuilder(@NonNull Application app)
{
//.....
}
//构建ACRAConfiguration对象
public ACRAConfiguration build() {
return new ACRAConfiguration(this);
}
....
//对外提供的设置相关属性的方法
public ConfigurationBuilder setHttpHeaders(@NonNull Map<String, String> headers) {
this.httpHeaders.clear();
this.httpHeaders.putAll(headers);
return this;
}
可能有些同学不太清楚注解的相关知识,可以参考该文章注解知识的介绍。
ACRAConfiguration
用来保存ACRA涉及到的所有配置。
SharedPreferencesFactory
用来获取ACRA所使用的SharedPreferences的文件。
通过这层封装可以对sp进行一些自定义的设置,比如sp的名字。
public class SharedPreferencesFactory {
//获取默认sharedPreferences的流程为
//1.如果通过builder或ReportsCrashes配置所构建的类生成的config文件,
// 包含sp相关配置,则使用该配置项。
//2.如果不满足1的条件,则通过android api PreferenceManager返回默认的sp文件
public SharedPreferences create() {
if (context == null) {
//..
} else if (!"".equals(config.sharedPreferencesName())) {
return context.getSharedPreferences(
config.sharedPreferencesName(), config.sharedPreferencesMode()
);
} else {
return PreferenceManager.getDefaultSharedPreferences(context);
}
}
}
ErrorReporter
ACRA最核心的类,该类用来捕获crash相关的信息,以及发送crash信息。
Android平台如果想要捕获java层代码的crash需要设置application Thread的UncaughtExceptionHandler。
ACRA会将ErrorReporter设置为Application Thread的UncaughtExceptionHandler。
从而实现对异常的捕获。
这里有一点需要注意的,Thread中的defaultUncaughtHandler为一个对象,
所以多次设置该属性,则会使用最后一个作为异常捕获的类。
比如现在市面上比较火的umeng等相关包含崩溃采集功能sdk。
使用的时候,需要注意查看文档或反编译其源码,查看sdk是怎么实现该部分功能的。
否则容易造成先设置的异常捕获类,无法被执行。
public class ErrorReporter implements Thread.UncaughtExceptionHandler {
ErrorReporter(
@NonNull Application context, @NonNull ACRAConfiguration config,
@NonNull SharedPreferences prefs,boolean enabled,
boolean supportedAndroidVersion, boolean listenForUncaughtExceptions)
{
...
//通过ConfigurationCollector获取系统的相关环境信息
if (config.getReportFields().contains(ReportField.INITIAL_CONFIGURATION)) {
initialConfiguration = ConfigurationCollector.collectConfiguration(this.context);
} else {
initialConfiguration = null;
}
//获取系统时间,崩溃发生时上传
final Calendar appStartDate = new GregorianCalendar();
crashReportDataFactory = new CrashReportDataFactory(
this.context, config, prefs, appStartDate, initialConfiguration);
final Thread.UncaughtExceptionHandler defaultExceptionHandler;
//listenForUncaughtExceptions为Acra初始化流程中传过来的。
//如果当前运行的进程是Sender进程则不监听崩溃。
//如果当前运行的进程是app主进程则对崩溃进行监听
if (listenForUncaughtExceptions) {
defaultExceptionHandler = Thread.getDefaultUncaughtExceptionHandler();
Thread.setDefaultUncaughtExceptionHandler(this);
} else {
defaultExceptionHandler = null;
}
//记录最后的activity
final LastActivityManager lastActivityManager = new LastActivityManager(this.context);
//用来保存针对崩溃的一些用户自定义的信息
final ReportPrimer reportPrimer = getReportPrimer(config);
reportExecutor = new ReportExecutor(
context, config, crashReportDataFactory,
lastActivityManager, defaultExceptionHandler, reportPrimer);
reportExecutor.setEnabled(enabled);
}
//崩溃采集需要实现UncaughtExceptionHandler为接口。
@Override
public void uncaughtException(@Nullable Thread t, @NonNull Throwable e) {
//未开启crash采集时,使用之前默认的ExceptionHandler处理
if (!reportExecutor.isEnabled()) {
reportExecutor.handReportToDefaultExceptionHandler(t, e);
return;
}
try {
ACRA.log.e(LOG_TAG, "ACRA caught a " + e.getClass().getSimpleName() +
" for " + context.getPackageName(), e);
if (ACRA.DEV_LOGGING) ACRA.log.d(LOG_TAG, "Building report");
performDeprecatedReportPriming();
// 生成并发送report
new ReportBuilder()
.uncaughtExceptionThread(t)
.exception(e)
.endApplication()
.build(reportExecutor);
} catch (Throwable fatality) {
// ACRA failed. Prevent any recursive call to ACRA.uncaughtException(), let the native reporter do its job.
ACRA.log.e(LOG_TAG, "ACRA failed to capture the error - handing off to native error reporter" , fatality);
reportExecutor.handReportToDefaultExceptionHandler(t, e);
}
}
}
参见代码可以知道,acra通过设置默认ExceptionHandler来捕获异常。
并把自己设置为处理对象。
LastActivityManager
是用来记录最后展示的Activity的,通过application.registerActivityLifecycleCallbacks
来实现记录功能的。ACRA可以在崩溃的时候弹出Dialog,所以需要记住最后的Activity。
ReportExecutor
主要业务逻辑关注execute()方法.
该类主要负责调用CrashReportDataFactory采集数据,
调用CrashReportPersister对崩溃数据进行持久化,
调用SenderServiceStarter运行Service发送的报告。
ApplicationStartupProcessor
封装一些App启动时可能执行的任务
class ApplicationStartupProcessor{
void deleteUnsentReportsFromOldAppVersion(){
//app版本更新后,一般会修掉老的崩溃等问题,
//所以当老版本更新到新版本后,可以将老版本记录的日志全部删除掉
}
void deleteAllUnapprovedReportsBarOne(){
//unapproved的文件夹内的文件,只保留最新创建的日志文件,其他的全部删除掉。
}
void sendApprovedReports(){
//调用SenderServiceStarter开启Service进行崩溃日志的发送。
}
}
ReportLocator
关于ACRA对日志文件位置的处理主要是ReportLocator
来设置的。
acra内部使用文件对崩溃日志进行保存,该类用来获取文件夹的名字。
内部有两个文件夹acra-unapproved(未处理),acra-approved(处理过)
分别用来保存未处理及处理过的崩溃文件。
采集内容
崩溃采集,必然需要采集崩溃及手机的相关信息。
ACRA中涉及到崩溃相关信息的主要有如下一些类。
ReportBuilder,ReportPrimer,CrashReportDataFactory,CrashReportData,
LogCatCollector,DropBoxCollector,ReportUtils,UUID,
Installation,ConfigurationCollector,DumpSysCollector,ReflectionCollector,
DisplayManagerCollector,DeviceFeaturesCollector,settingsCollector,
LogFileCollector,MediaCodecListCollector,ThreadCollector.
ACRA获取全部数据,涉及到的类比较多。下面逐个分析。
ReportBuilder
对throwable,message,自定义信息,以及exception的简单封装。
主要方法为build(),通过build方法调用ReportExecutor.execute()方法,
在ReportExcutor中进行真正的crash采集以及调用发送Service
ReportPrimer
用来设置崩溃时候,用户需要保存的一些用户自定义的信息。
比如崩溃时候在此类中设置一些用户账号等相关信息。
该类中设置的相关内容会一起发送到服务端,从而更好的定位一些崩溃信息。
CrashReportDataFactory,CrashReportData
CrashReportDataFactory类用来实例化CrashReportData。
其中最重要的方法为createCrashData()方法,使用该方法来组拼CrashReportData。
CrashReportData继承EnumMap,其中保存的数据的key为各种上传时候的key,
对应的值为崩溃的相关信息。后面的流程中该类中的值会通过CrashReportPersister类写入file文件。
LogCatCollector
用来获取logcat日志中的相关信息,执行Logcat命令,读取命令输出信息。
class LogCatCollector{
public String collectLogCat(){
//根据所传参数不同组拼不同的logcat命令
//主要组拼出的命令为
//1.logcat -t 100 -v time
//2.logcat -t 100 -v time -b radio
//1.logcat -t 100 -v time -b events
}
}
logcat -b events
05-18 19:45:46.158 31191 31191 I auditd : type=1400 audit(0.0:505001): avc: denied { search } for comm="PerfFgMonitor" name="1711" dev="proc" ino=18618 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:r:radio:s0 tclass=dir permissive=0
logcat -b radio
05-18 19:44:39.343 1711 1785 D RILJ : [9679]< RIL_REQUEST_GET_CELL_INFO_LIST [CellInfoWcdma:{mRegistered=YES mTimeStampType=oem_ril mTimeStamp=1283159923921792ns CellIdentityWcdma:{ mMcc=460 mMnc=1 mLac=53529 mCid=101852154 mPsc=438} CellSignalStrengthWcdma: ss=8 ber=99}] [SUB0]
05-18 19:44:39.345 1711 1975 D GsmSST : [GsmSST] SST.getAllCellInfo(): X size=1 list=[CellInfoWcdma:{mRegistered=YES mTimeStampType=oem_ril mTimeStamp=1283159923921792ns CellIdentityWcdma:{ mMcc=460 mMnc=1 mLac=53529 mCid=101852154 mPsc=438} CellSignalStrengthWcdma: ss=8 ber=99}]
05-18 19:44:39.346 1711 1975 D GsmSST : [GsmSST] getCellLocation(): X ret WCDMA info=[53529,101852154,438]
05-18 19:44:43.068 1711 1927 D SubscriptionController: [getPhoneId]- no sims, returning default phoneId=2147483647
其实相信大部分人不太清楚logcat的相关命令。
针对以上的三条命令做如下解释
logcat -t 100 -v time
-t 限制打印100行内容
-v time 设置日志输出格式。打印日志的为:打印日期->触发时间->优先级(E,W,V)->tag->出问题进程的pid
关于日志输出格式的介绍参见此处日志输出格式。
logcat -b [options] 切换打印log的内容级别
- radio radio/telephony相关log
- events events-related相关log
- main 默认的log
DropBoxCollector
通过DropBoxManager读取系统系统的日志信息
DropBoxManager,很多人应该也没接触过。
android系统实际上是有三种日志打印的。log EventLog DropBox
,关于三种log的介绍参见此处。
三种log的介绍
关于DropBoxManager的相关内容可以参见此处。dropboxManager介绍
class DropBoxCollector{
public String read(){
//通过DropBoxService获取系统的DropBoxManager
//读取所有预先定义的不同tag对应的日志内容
}
}
ReportUtils
封装的各种工具类,用来获取系统相关的信息
public getAvailableInternalMemorySize(){
//通过StatFs类获取可用内存block数量及每个block的size
//block_size * free_block_count = 可用内存数
}
public getTotalInternalMemorySize(){
//通过StatFs类获取所有内存block数量及每个block的size
//block_size * total_block_count = 总内存数
}
public getDeviceId(){
//通过TelephonyManager获取deviceId
//GSM手机对应与IMEI
//CDMA手机对应与ESN或MEID
}
public getApplicationFilePath(){
//通过context.getFilesDir()获取当前app的绝对路径
//'/data/user/0/yftx.net.oschina.git.gradlesample/files'
}
public getLocalIpAddress(){
//通过NetworkInterface 获取当前设备的ip
}
public getTimeString(){
//通过Calendar类获取当前时间
}
UUID
java.util包中提供的类,用来生成唯一字符串的类。
Installation
用来生成唯一身份串的类。
class Installation{
void id(){
//获取的id用来标记用户的身份。
//具体算法可以参见android blog中的解释。
//http://android-developers.blogspot.com/2011/03/identifying-app-installations.html
}
}
ConfigurationCollector
通过反射系统的Configuration
类,获取系统相关参数。
class ConfigurationCollector{
void collectConfiguration(Context context){
//通过 context.getResources().getConfiguration()获取configration对象,
//并用反射获取该类中的相关信息
}
}
DumpSysCollector
通过执行dumpsys meminfo xxxpid 来分析内存
关于dumpsys的介绍参见此:dumsys相关介绍
class DumpSysCollector{
void collectMemInfo(){
//执行dumsys 相关命令
}
}
ReflectionCollector
相当于Util类,主要通过反射获取传过来的类的一些信息。
class ReflectionCollector{
void collectConstants(){
//通过反射获取系统的相关信息
//acra中主要获取Build,Build.Version中的相关数据
}
}
DisplayManagerCollector
主要用来获取手机显示相关的数据
class DisplayManagerCollector{
void collectDisplays(){
//通过Display类获取屏幕宽,高,方向等显示相关的参数
}
}
DeviceFeaturesCollector
通过PackageManager获取系统相关特性。比如glEsVersion等
class DeviceFeaturesCollector{
void getFeatures(){
//通过PackageManager获取系统相关特性。比如glEsVersion等
}
}
SettingsCollector
使用反射获取android.provider.Settings.x中的相关内容。
class SettingsCollector{
void collectSystemSettings(){
//获取系统Settings类中的相关信息
}
void collectSecureSettings(){
//获取Settings.Secure中的相关信息
}
void collectGlobalSettings(){
//获取Settings.Global中的相关信息
}
}
LogFileCollector
获取用户自己保存的相关的log文件,使用该接口可以让acra结合logback-android这类类库相结合。
很多做android的同学都没有做过java web开发,并且android的Log接口也还算好用,再加上客户端编程和服务端编程系统的不同,所以可能理解不了logback-android这样库的意义。
实际上logback-android这类库主要就是可以指定log输出的位置,以及log的打印级别。
关于java开发中log的重要性可以参见此文章,java log的意义
MediaCodecListCollector
主要用来获取系统支持哪些音视频类型等媒体相关的。
ThreadCollector
获取崩溃线程的相关信息。
class ThreadCollector{
void collect(Thread t){
//获取线程t的相关信息,id,name,priority,groupName
}
}
ACRA中用到的其他一些获取异常的方法
getStackTracehash(Throwable th){
//通过组拼Error的className及MethodName生成的字符串
//获取该字符串的hash值
//服务端可以根据该值做崩溃分类
}
结语
本部分内容主要包括
- ACRA如何配置(服务端,客户端的配置)
- 崩溃信息相关内容如何采集,涉及到的关键类。
后面的部分会继续分析如何将生成的file发送到服务端。
网友评论