一 重写全局异常处理：
1 是过滤掉一些已知的无法处理的
问题，比如TimeoutException 这种无法根除只能缓解的问题可以直接catch掉
2 是 一些无法继续的问题可以直接杀死重启，一些影响不是很大的，可以局部还原
比如：
public class MyUncaughtExceptionHandler implements Thread.UncaughtExceptionHandler {
private static final String TAG = "MyUncaughtExceptionHandler";
@Override
public void uncaughtException(Thread thread, Throwable ex) {
ex.printStackTrace();
if (null != thread) {
LogUtils.e("killProcess thread name is " + thread.getName());
}
LogUtils.e(ex);
Log.e(TAG, "MyUncaughtExceptionHandler_Exception: " + Log.getStackTraceString(ex));
if (null != thread && "FinalizerWatchdogDaemon".equalsIgnoreCase(thread.getName()) && ex instanceof TimeoutException) {
//https://segmentfault.com/a/1190000019373275
LogUtils.e("FinalizerWatchdogDaemon TimeoutException");
} else {
LogUtils.e("MyUncaughtExceptionHandler ", "Crash: " + ex.getMessage());
//Process.killProcess(Process.myPid()); todo
}
}
}二 使用工具代码扫描：比如sonar，lint，有新功能的时候可以跑一跑，大部分提示都不需要关注。
但是可以自定义一些规则（基于本项目容易出错的规则可以配置下，比如序列化里面是否都支持序列化，是否有new thread的现象）
三 增加监控指标，内存在一些页面下合理范围是多少，线程数的合理范围是多少
查看内存：adb shell dumpsys meminfo xxx（包名）
查看线程数：adb shell cat /proc/pid（进程号）/status
这两个指标多了，会影响到内存，内存太大就会导致app不稳定。
（我曾在自己的项目上跑monkey的时候，跑了个脚本监控，感觉还是之前的单例太多了，当时适当减少了一些单例的生命周期）
四 代码质量相关总结
我这里主要分几个部分进行问题总结：
1 内存优化及泄露 2 anr，native相关问题总结 3 app启动问题，冻屏，黑屏总结 4 日常高频问题总结
一分类就很多，整完这些就要处理 android相关问题总结，java相关问题总结部分，尽量分开来，别混在一起。
主要以自己以往处理的问题做总结。但感觉这样分类有点不好。因为回忆及查阅自己的资料时候，发现既有也有，怕是遗漏，无法分类的很多哦。
哪有那么多时间 反复查看。头疼
网上能搜到的，就不要写了，加个关键字，链接啥的就过了。
接下来看下泄露吧，搞得最多的就是泄露了。
一般的泄露，可以直接通过分析hprof文件直接找到，这里就不再写，写下特殊情况下的
找不到明显泄露的，可以直接按照包名分类，查看下对应目录下的对象数量，按大小排序
一个个过滤，会发现一些对象不应该是多个的，或一个页面只应该对应两个的，里面却出现了三个，那一般看下引用堆栈，往往能够发现内存异常，或回收慢的问题
如果代码比较熟悉，可以直接搜相关的对象名字，看下对象数量，一般可以快速定位泄露问题或
回收慢的问题。
这是个笨方法，但对那些出现一次或难复现的问题也是一种方式，比如我会保存一些对象的名字
routeoption，pathinfo，poiforrequest，VariantPathWrap，DrivePathAccessor，
等这些对象经常容易出问题。
有些对象有个特点，当前流程有用，且流程分散，释放了就出问题，留着下次再来的时候容易忘记释放之前的，一般我会下次来赋值之前，将老的释放掉，再赋值给它新的。
有些和业务流程相关的，比如绘制，看不到对象，直接放native了，只能代码里监控，不能超过500个，要及时监控，及时释放(clearitems)。