CrashHanlder基本功能汇总

Basic:

• 1.异常信息捕获(un-checked exception)
• 2.异常信息写入本地文件(信息顺序写入)
• 3.异常文件打包上传（上传退避策略：超过文件数量阈值，比较上次上传时间，崩溃上传，上传依赖网络环境，退避策略，开启服务提升优先级）
• 4.多进程日志保存（设置独立进程）
• 5.提供基本log打印接口,可用于追踪调用流程。如Logger.e()，Logger.d();
• 6.demo展示，自测。
  Note：模块3和4在设计之初考虑独立性，低耦合，能够被其他类库如ANR，电量，流量等上报库使用

Options:

1.异常归类
2.异常等信息的展示，可模仿leakcanary
CrashWoodpecker
3.收集本次异常出发时的内存，cup，以及各种硬件等基本情况，AndroidPerformanceMonitor
4.允许外部调用者补充异常信息。如NPE异常，调用者可补充当时调用的使用场景。

参考文献：
Google ACRA
CustomActivityOnCrash
Bugsnag
Bugtags

排期：

调研期（总结调研，并梳理成文档）：

调研Google的开源崩溃日志上传库Google ACRA，主要调研异常收集逻辑已经崩溃后的处理行为以和上传策略。在Google play上有超过53K的App在使用该库，所以还是很有参考价值的（这个library比较庞大，如时间紧迫可能需要一天的buffer）。 - 1Day

调研崩溃后可重启的类库Recovery - 1Day

调研github上一个崩溃时可自定义展示界面的libraryCustomActivityOnCrash - 1Day

调研Bugsnag，Bugtags，主要参考其收集崩溃日志的逻辑 - 2Day

调研leakcanary，CrashWoodpecker，AndroidPerformanceMonitor，抛出崩溃信息的同时，可弹出对话框，点击进入展示Activity，并dump设备信息。- 2Day

调研总结，梳理文档，记录必要代码和library的整体设计思路- 2Day

开发期：

1. 类库创建与基本结构搭建，方案定型（如结构分层以及需要对release版本预先设计no-op的实现版本等） - 1Day
2. 捕获异常信息（仅Java层，目前不考虑native），提供异常白名单或过滤功能- 2Day。
3. 异常信息写入文件，提供初始化函数。（option：目前崩溃日志文件的内容展示，消息条目间无任何分隔符，不具备有好的可读性，非常的杂乱，普通消息之间甚至与崩溃信息间无法清晰的分辨，可以考虑后续的优化以及如何更高效的读写文件）- 2Day
4. 压缩文件，开发上传功能。- 2Day
5. 开发文件上传的退避策略。（如，优先选择WiFi环境上传，弱网标记，文件数量阈值设定，设置最小上传间隔）- 2Day
6. dump设备有效信息，如CPU，内存，手机型号等（note：需考虑API版本的兼容与权限问题）。- 2Day
7. 提供基本的Logger工具类，用于打印日志信息到logcat或者写入文件。- 2Day
8. 独立进程(开发独立进程和跨进程通信的经验较匮乏，如遇到尖锐问题需要至少一天的buffer)- 2Day
9. 异常信息展示（note：可参考上面提到的Leakcanary，Blockcanary，CrashWoodpecker等）
10. demo，自测 - 2Day
11. 部分扩展功能，如生成Trace文件，异常类型归类可后续进行开发。在次不进行排期。