前言：
作者本人负责公司的APM监控模块，因为工作的原因，对ANR，crash等流程研究的比较多，最近在打造APM监控平台的时候，顺带对DropBox的实现原理进行了一定的学习和研究，发现了一些妙用，因此写这篇文章来分享。
本系列分为两篇文章，
1.DropBox系列-安卓DropBox介绍：主要介绍DropBox的一些实现原理。
2.DropBox系列-利用DropBox打造车载系统APM框架：主要介绍利用DropBox打造一个面向所有APP的稳定性监控框架。
PS：本文的代码以安卓9（SDK=28）的源码来介绍，因为目前车载开发基本上都是以安卓9为基础来定制的，而且DropBox对于那些拥有系统权限的APP来讲意义更大一些。
一.车载系统APM框架介绍
1.1为什么要单独搞一套APM框架
为什么要做单独搞一套APM监控框架？直接用现成的bugly，友盟，KOOM不可以吗？为什么要重复的造轮子呢？
我的理解是这样的，如果有合适的轮子，自然是最完美的，但是目前的这些轮子，也许对我们来说并不是最适合的，原因有三，如下：
1.侵入性问题。直接使用现成的APM框架是可以的，但是并不是最好的选择。现有的互联网大厂的APM框架对于APP是有侵入性的，不但影响APP的包体积大小，而且有可能会影响APP性能的，甚至有可能接入监控框架导致出现性能问题，比如接入bugly造成IO异常。
2.完整性问题。单一的某一个框架，并不能完整的记录我们所需要的所有目标。比如bugly只能记录崩溃/ANR(6.0以上ANR功能失效)/错误数量，KOOM专注于内存状态的监控，没有一个大一统的框架可以帮我们监控到所有我们想要的数据。
3.接入成本问题。我们的车机上有一百多个应用，假设一个应用接入bugly需要半天时间（接入+测试 +验证），那么100个应用就需要50个工作日，成本可以见一般。
1.2 APM框架介绍
作为车载系统开发，我们有着定制framework这一得天独厚的优势，所以，我们可以针对freamwork层做一些不影响原有逻辑的注入，来实现对所有APP的APM监控。
车载APM就是基于原理去做的，它作为一个单独的APP存在，使用观察者模式，发现APP应用出现异常的时候，主动去补货异常日志进行上报，从而做一个观察者，对所有的APP应用进行稳定性监控。
二.安卓异常处理机制及指标监控
2.1 java崩溃流程简介
具体流程可以参考这一篇文章，本章只是简介。android源码学习-android异常处理机制_失落夏天的博客-CSDN博客_android 异常处理
安卓应用程序发生异常后，会一层一层的上报，最终上报到Thread的dispatchUncaughtException方法中：
-
public final
void
dispatchUncaughtException(
Throwable e) {
-
Thread.
UncaughtExceptionHandler initialUeh =
-
Thread.
getUncaughtExceptionPreHandler();
-
if (initialUeh !=
null) {
-
try {
-
initialUeh.
uncaughtException(
this, e);
-
}
catch (
RuntimeException |
Error ignored) {
-
// Throwables thrown by the initial handler are ignored
-
}
-
}
-
getUncaughtExceptionHandler().
uncaughtException(
this, e);
-
}
initialUeh用来记录崩溃信息，其实现类在安卓中是RuntimeInit.LoggingHandler，用来记录一些崩溃的信息。
而getUncaughtExceptionHandler()返回的是RuntimeInit.KillApplicationHandler，这个就是我们APP中真正去处理崩溃的实现类，我们看一下这个实现类：
-
private
static
class
KillApplicationHandler
implements
Thread.UncaughtExceptionHandler {
-
private
final LoggingHandler mLoggingHandler;
-
-
...
-
public
KillApplicationHandler
(LoggingHandler loggingHandler) {
-
this.mLoggingHandler = Objects.requireNonNull(loggingHandler);
-
}
-
-
@Override
-
public
void
uncaughtException
(Thread t, Throwable e) {
-
try {
-
ensureLogging(t, e);
-
if (ActivityThread.currentActivityThread() !=
null) {
-
ActivityThread.currentActivityThread().stopProfiling();
-
}
-
-
// Bring up crash dialog, wait for it to be dismissed
-
ActivityManager.getService().handleApplicationCrash(
-
mApplicationObject,
new
ApplicationErrorReport.ParcelableCrashInfo(e));
-
}
-
...
-
}
-
...
-
}
主要做了三件事：
-
生成错误信息；
-
通过binder通知到AMS的handlerApplicationCrash方法；
-
删掉当前进程，完成应用的彻底退出。
AMS的handlerApplicationCrash方法中收到崩溃信息后，会通过DroxBoxManagerSerivice服务完成最终崩溃信息的记录和持久化，最终存储到data/system/dropbox文件夹下，这一块我们就不详细赘述了，我们只要支持，所有APP的崩溃，都会通知到AMS即可。
所以，我们只要在AMS中加上适当的钩子，完成崩溃消息的转发，就可以记录所有APP的java层崩溃（native崩溃另讲，检测机制不一样）。
2.2 ANR监控原理
具体原理可以参考这一篇文章，本章仍是简介。ANR系列之一：ANR显示和日志生成原理讲解_失落夏天的博客-CSDN博客
导致ANR的场景有很多种，比如输入事件无响应，广播事件无响应，Service中超时等等，具体类型和超时时间如下(下图中的某些时间其实是有问题的)。
无论哪种类型的ANR，最终都会通知到AnrHelper.appNotResponding方法中，所以我们从这个流程开始往下看。
经过种种转发，最终的执行逻辑在ProcessErrorSatetRecord方法中，主要会执行下面三大块逻辑：
1.收集ANR信息
2.保存ANR日志
3.弹出ANR显示框
2.3 APP启动速度监控原理
APP启动，主要分为四部分：
-
Laucher或其它应用通知AMS，显式或者隐式的去启动相应的Activity。
-
如果Activity所对应的APP进程不存在，则会走进程创建流程，通知Zygote去fork产生对应的进程，APP进程产生后，回调通知AMS。
-
AMS通知APP一侧去加载对应的APK文件，以及创建和初始化Application及其它必要元素。
-
AMS通知APP一侧去创建，初始化，以及最终显示Activity。
至此，整个启动流程结束，整个流程的时间可以理解为通俗理解上的冷启动时间。
完整的APP启动流程图如下：
所以，针对开始和结束分别设置一个钩子，那么两者之间的时间差，就是我们所需要冷启动时间了。
开始的事件很容易设置，AMS的中的startActivityWithFeature方法。
结束的事件相对会麻烦一些。因为最后的绘制流程，是APP进程和surfaceFlingger进程的通信，并不经过system_server进程。所以我们这里退而求其次，把APP进程把Window注册到WindowManager的事件作为结束的点，从而求出其中的差值。
这样，和标准意义上的冷启动流程，会有一些误差。这个误差就是Activity在onResume之后，首次measure，layout和draw的时间，这个误差理论上不会很大，除非是十分复杂的多层嵌套布局，或者ViewPager的不当使用。这一块的计算，我们放到后续再进行优化。
2.4 APP绘制卡顿监控
和上面说的监控首次绘制原理一样，APP绘制的流程除了注册Window，其余的渲染，以及vsync信息，都是surfaceFlingger进程来控制的。这一块需要想办法对surfaceFlingger进行一定的注入。这一项，我们一样放到后续进行相关的探索。
2.5 APP运行状态监控
APP运行状态包含很多指标，比如内存使用率，线程数，FD数量等等，这些数量的超标都会导致最终的OOM。KOOM和kensor两个框架都是对这些指标进行监控的。一样，我们放到后续在对这些指标进行相关的探索。
三.实现方案踩坑
3.1 车载系统APM架构设计
按照由简入难的原则，第一期的目标，我们先打算只实现崩溃和ANR两种异常指标的监控。
我们基于对系统代码改动量最小的原则，采用C/S的架构来设计。
首先我们通过一个独立的APP来实现异常信息的采集，分析和上报的工作，这个APP来实现绝大多数的逻辑。而系统侧只负责通知，即发生了异常之后，通知APP即可，不做其他任何的逻辑处理。这样对系统侧的修改就会尽可能的小。整体架构图设计如下：
接下来，我们该尝试，系统侧发现了异常之后，如何通知APP了。
3.2 和系统通讯方案尝试
方案1：信号量通讯
ANR系列之一：ANR显示和日志生成原理讲解_失落夏天的博客-CSDN博客
这篇文章中，我们有介绍，发现了ANR之后，系统会去主动采集最近使用进程的java层堆栈状态，而这种采集的通讯使用的是信号量，即系统发送一个信号量，APP侧接受了之后就开始采集自身的堆栈。APP侧并不止发生ANR的那一个，最近使用的APP也都会进行采集。
所以，我们只要在保证我们的APM_APP在最近使用的APP列表中，这样发生了ANR之后，我们只要监听这个信号量就知道发生ANR了。目前友盟和腾讯其实使用的就是这种方案。
优势：系统代码改动量很小，只需要添加一行代码，把APM_APP添加到最近使用列表中。
缺陷：ANR和Crash的实现方案就不统一了，因为Crash无法使用信号量。
因为设计初衷，还是希望crash和anr走一样的机制，这样方便后续的维护，所以信号量这个方案第一个被放弃。
方案2：binder通讯
由上面的流程我们可以知道，只要发生了crash，一定会通知AMS的handlerApplicationCrash方法，而ANR一定会通知AnrHelper的appNotResponding方法。
所以，可以通过APM_APP向系统注册一个binder引用。在上述的两个方法中，系统通过binder引用把异常信息传递给APM_APP。这样，就可以完成异常的监控了。
优势：监听是实时的，而且对于APP侧来说接口是一个，方法统一了。
缺陷：对系统的侵入性较大，而且一旦APM_APP被系统杀死，是完全无感知的。
这个方案需要修改系统源码，虽然作为车载系统开发修改源码是完全可以实现的，但是不利于后续的扩展，因为不同车型的系统源码都要改一遍。而且APM_APP是一个后台服务，一旦低内存被杀死，就不能继续进行异常的监听了。
所以这个方案作为一个备选，看是否有更好的方案再说。
方案3：文件夹监听
我们通过上面的原理流程可以得到，无论ANR还是crash，其实最终都会通知到DropBox去生成对应的异常日志文件。dropbox文件夹地址：data/system/dropbox，所以我们是否可以通过监听这个文件夹的变化，从而实现对异常信息的监听呢？
这样做有几个问题，首先是SELinux权限问题，普通APP是无法完成对这个文件夹的监听的。
但是对于车载系统开发来说问题不大，SELinux权限可以配置的。主动关掉SELinux后在进行尝试，最终发现这个方案不太可行。
首先监听crash文件是没有问题的，但是监听ANR文件的时候，由于ANR的生成文件是一个压缩包，所以通过FileObserver监听的时候，收到ANR类型的压缩文件会导致监听完全失效。而且这个方案和方案2存在一样的问题，一旦APM_APP进程挂掉，是无感知的，就无法监控后面异常信息了。
方案4：动态广播
通过上一篇文章的阅读
https://blog.csdn.net/rzleilei/article/details/128328967
我们知道dropbox完成异常信息的存储之后，会发送一个DropBoxManager.ACTION_DROPBOX_ENTRY_ADDED类型的广播，所以，我们只要注册一个广播接收器来接受这个广播，这样收到了这个广播之后，我们在去主动读取dropbox文件夹下对应的异常文件，就可以知道具体的异常信息了。
说干就干，主动尝试了一把，动态广播的方式是可以的。但是静态广播的方式，会提示：Background execution not allowed: receiving Intent错误。权限的问题，哪怕已经申请了对应的权限，还是不行。
动态广播的话，还是存在APM_APP进程被杀死的场景。但是这已经是一个很好的方向了。因为这个方案对系统侧是0侵入，所以完全不用考虑适配不同车机系统的场景。而且crash和ANR的异常类型上报统一是完全可以保证的。
方案5：静态广播
静态广播会在发送广播的时候创建对应的进程，所以是可以保活的，因为这无疑是最理想的方向。既然上面说到会提示权限的问题，那么我们就尝试去解决静态广播权限的问题。
具体的错误信息如下：
12-09 16:58:31.732 1251 1296 W BroadcastQueue: Background execution not allowed: receiving Intent { act=android.intent.action.DROPBOX_ENTRY_ADDED flg=0x10 (has extras) } to com.xxx.apm/.broadcast.DropBoxBroadcast报错的代码如下：
-
if (!skip) {
-
final
int allowed = mService.getAppStartModeLocked(
-
info.activityInfo.applicationInfo.uid, info.activityInfo.packageName,
-
info.activityInfo.applicationInfo.targetSdkVersion,
-1,
true,
false,
false);
-
if (allowed != ActivityManager.APP_START_MODE_NORMAL) {
-
// We won't allow this receiver to be launched if the app has been
-
// completely disabled from launches, or it was not explicitly sent
-
// to it and the app is in a state that should not receive it
-
// (depending on how getAppStartModeLocked has determined that).
-
if (allowed == ActivityManager.APP_START_MODE_DISABLED) {
-
Slog.w(TAG,
"Background execution disabled: receiving "
-
+ r.intent +
" to "
-
+ component.flattenToShortString());
-
skip =
true;
-
}
else
if (((r.intent.getFlags()&Intent.FLAG_RECEIVER_EXCLUDE_BACKGROUND) !=
0)
-
|| (r.intent.getComponent() ==
null
-
&& r.intent.getPackage() ==
null
-
&& ((r.intent.getFlags()
-
& Intent.FLAG_RECEIVER_INCLUDE_BACKGROUND) ==
0)
-
&& !isSignaturePerm(r.requiredPermissions))) {
-
mService.addBackgroundCheckViolationLocked(r.intent.getAction(),
-
component.getPackageName());
-
Slog.w(TAG,
"Background execution not allowed: receiving "
-
+ r.intent +
" to "
-
+ component.flattenToShortString());
-
skip =
true;
-
}
-
}
-
}
flag=16，package=nulll,comonent=null。所以唯一的判断条件就是isSignaturePerm(r.requiredPermissions)。requiredPermissions其实应该是READ_LOGS的权限，但是APM_APP即使申请到了这个权限，仍然会提示这个错误。所以我们看一下isSignaturePerm这个方法：
-
final
boolean
isSignaturePerm
(String[] perms) {
-
if (perms ==
null) {
-
return
false;
-
}
-
IPackageManager
pm
= AppGlobals.getPackageManager();
-
for (
int
i
= perms.length-
1; i >=
0; i--) {
-
try {
-
PermissionInfo
pi
= pm.getPermissionInfo(perms[i],
"android",
0);
-
if ((pi.protectionLevel & (PermissionInfo.PROTECTION_MASK_BASE
-
| PermissionInfo.PROTECTION_FLAG_PRIVILEGED))
-
!= PermissionInfo.PROTECTION_SIGNATURE) {
-
// If this a signature permission and NOT allowed for privileged apps, it
-
// is okay... otherwise, nope!
-
return
false;
-
}
-
}
catch (RemoteException e) {
-
return
false;
-
}
-
}
-
return
true;
-
}
系统竟然判断的是android包名是否具有这个权限，有点扯，不理解为什么判断的是系统包名，而不是APP包名。但是没有办法我们只能另外找办法。
继续往上照，发现allowed != ActivityManager.APP_START_MODE_NORMAL这里还有一个判断。也就是说allowed如果等于ActivityManager.APP_START_MODE_NORMAL，就不用走后面的判断了，我们朝着这个方向进行尝试。
最终发现在ActivityManagerService的appRestrictedInBackgroundLocked方法中有这样一个判断：
-
// Apps that target O+ are always subject to background check
-
if (packageTargetSdk >= Build.VERSION_CODES.O) {
-
if (DEBUG_BACKGROUND_CHECK) {
-
Slog.i(TAG,
"App " + uid +
"/" + packageName +
" targets O+, restricted");
-
}
-
return ActivityManager.APP_START_MODE_DELAYED_RIGID;
-
}
targetSDK>=26，就直接返回APP_START_MODE_DELAYED_RIGID。所以，我们把APM_APP的targetSDK改为25在进行尝试，发现果然可行。
至此，和系统通讯方案的尝试终于有了结论，我们最终决定使用静态广播的方式来实现，它具有以下几大优势：
1.保活。哪怕APM_APP被杀死，下次广播来的时候系统也会帮忙重新启动对应进程。
2.对系统完全没有侵入性，0改动，移植到其它车型的系统也完全可用。
3.ANR和CRASH上报方案是一致的，不需要区别对应，方便后续维护管理。
四.车载系统APM框架设计和实现
前面探索出来了实现的原理，则最终实现起来就简单的多，
主要分为3个模块：
1.dropbox广播注册者：负责接收异常信息；
2.DB存储：负责记录已经上报过的日志信息；
3.上报模块：负责具体异常信息的上报。
4.1 异常信息接收
创建广播接收者
首先，创建一个广播接收者DropBoxBroadcast。
在onReceive方法中，会接受到系统传递过来的两个参数，分别为tag和time。
tag的形式为：data_app_crash或者data_app_anr，
time就是时间戳的形式。
两个参数一组合，就可以得到文件名，两者以tag@time的方式进行组合。
广播接收到，就意味着异常日志文件已经生成完成，我们直接去解析对应的异常文件，得到我们想要的参数进行上报即可。
需要注意的是，ANR类型的日志文件是gz格式的，需要进行解压缩后才能读取和使用。
广播注册
然后，通过静态注册的方式注册一个广播接收者，action为android.intent.action.DROPBOX_ENTRY_ADDED。
-
<receiver
-
android:name=
".broadcast.DropBoxBroadcast"
-
android:exported=
"true">
-
<intent-filter>
-
<action android:name="android.intent.action.DROPBOX_ENTRY_ADDED" />
-
</intent-filter>
-
</receiver>
4.2 兜底方案处理
虽然我们的广播是可以保活的，但是为了考虑种种情况，我们还是做了一个兜底方案。
即APP启动之后，通过线程延时去读区dropbox中的所有文件，和本地已经上传成功的做对比，找出来那些没有上传过的，进行上传。
转载：https://blog.csdn.net/AA5279AA/article/details/127286409