性能优化之稳定性优化

提高代码质量

代码审查

android lint 代码检测

Crash监控

java层Crash监控

虚拟机为每个进程都设置一个默认的UncaughtExceptionHandler，用于处理本进程未被try catch的Exception

因此需实现UncaughtExceptionHandler接口

/**
 * 虚拟机为每个进程都设置一个默认的UncaughtExceptionHandler，用于处理本进程未被try catch的Exception
 */
public class CrashHandler implements Thread.UncaughtExceptionHandler {
    private static final String TAG = CrashHandler.class.getSimpleName();

    private Thread.UncaughtExceptionHandler mDefaultHandler;

    public CrashHandler() {
        //获取系统默认的异常处理器
        mDefaultHandler = Thread.getDefaultUncaughtExceptionHandler();
        //传入自定义的UncaughtExceptionHandler，将当期实例设为系统默认的异常处理器
        Thread.setDefaultUncaughtExceptionHandler(this);
    }

    /**
     * 当出现没有被atch的异常时，就会回调这个方法
     *
     * @param t 出现未捕获异常的线程
     * @param e 未捕获的异常
     *             
     *可以在这里记录crach日志并上报服务器，也可以执行一些个性化的异常处理操作
     */
    @Override
    public void uncaughtException(Thread t, Throwable e) {

        //导出异常信息到SD卡
        //上传服务器

        //打印出当前调用栈信息
        e.printStackTrace();

        //如果系统提供了默认的异常处理器，则交由系统处理，否则由我们自己处理
        if (mDefaultHandler != null) {
            mDefaultHandler.uncaughtException(t, e);
        } else {
            android.os.Process.killProcess(android.os.Process.myPid());
            System.exit(1);
        }
    }
}

Native层Crash监控

• adb pull /data/anr/trace.txt获取trace.txt文件
• 利用analyza stack trace 工具分析trace.txt文件

ANR

即应用无响应

发生ANR有以下几种类型

• 对输入事件5s内无响应
• 广播接收者在特定时间（原生系统默认10S）内无法处理完成
• 服务在特定时间（原生系统默认20S）内无法处理完成

根本原因：

• 自身逻辑缺陷，导致主线程堵塞、死锁
• 其他进程CPU占用高，当前应用进程无法抢占到CPU时间

实现ANR监控思路：计算dispatchMessage前后时间差

提高进程优先级

进程的重要性优先级：（越往后的就越容易被系统杀死）

前台进程

进程持有一个正在与用户交互的Activity。
进程持有一个Service，Service调用了startForeground()
进程持有正执行一个生命周期回调的Service（onCreate、onStartCommand或者onDestroy）
进程持有一个BroadcastReceiver，正在执行它的 onReceive() 方法。

可见进程

如果一个进程不含有任何前台的组件，但仍可被用户在屏幕上所见。

服务进程

一个进程中运行着一个service，这个service是通过startService()开启的，（例如，在后台播放音乐或从网络下载数据）

后台进程

空进程

提高进程优先级途径：

利用Notification提升进程优先级

利用系统广播

https://www.jianshu.com/p/df766d5573a5Android 进程保活

利用第三方应用广播拉活

利用系统Service机制拉活

方案设计：

该方案将Service的onStartCommand方法的返回值设置为START_STICKY，利用系统机制在Service挂掉后自动拉活。

适用范围：

下面这两种情况无法进行拉活：

• 1、Service在第一次被异常杀死后会在5秒内重启，第二次被杀死后会在10秒重启，第三次杀死后会在20秒重启，但是一旦在短时间内Service被杀死的次数达到5次，则系统不再拉起。
• 2、进程被取得Root权限的管理工具或系统工具通过foreStop停止掉，则无法重启。

利用JobScheduler机制拉活

在android开发中，我们为了节约电池电量，经常要在稍后的某个时间点或者满足某个特定的条件时去执行某个任务，例如网络状态连接到wifi状态时执行某些网络请求，或者每隔24小时，进行一项特定的操作。

SyncAdapter