android app crash排查系列

背景 当你使用下面代码不断分配内存时，最终导致物理内存耗尽，手机所有应用进程被杀死。 在一次 crash问题排查过程中，现象是crash但是并没有crash日志的捕获，后面排查到就是内存泄露导致的lo

背景 团队达到一定规模时，需要更加完善crash堆栈信息来进行自动分配和快速定位问题。所以做了堆栈超级解析功能 方案实现流程 该方案的优点，除去打通 gitlab 流程以外，完全可以做到本地化，拿到m

背景：版本灰度出现了handler相关奇怪的crash，不管是init,poll,wake都会出现类似crash 问题分析 Looper::wake 看上去是mWakeEventFd write时出问

背景 应用中后台过度资源导致的退出占比在2%左右。 源码搜索(基于Android 13) 观察日志大部分是抛出以下格式日志。 "excessive cpu 8020 during 300091 dur

多进程问题导致crash ,apk&so 异常不兼容导致crash,渲染问题导致crash,处理Webview crash 相关的报表,webview 预创建提速

背景： 新版包打release包后启动mp4 不可用。 新版本release包 异常 新版本debug包 正常 老版本release包 正常 新版本debug包 正常 新老apk解压后对比 大小 md

crash问题千奇百怪,涉及到厂商相关的代码我们该如何去分析。 如何通过现有crash信息分析尝试复现crash? 如何快速获取到厂商crash相关代码? 如何通过反编译和trace手段快速分析代码逻

背景： 在我们平常开发中经常会遇到一些framework, system_process, art中的一些问题。很多时候我们是需要翻阅代码去查看问题。但是很容易因为某个分支判断不对走错路。 掌握调试技

背景： 当线上数据配置异常时，客户端代码未做好兜底走到异常分支就可能触发crash，如果在启动阶段就可能导致大面积的crash 目的： 降低线上crash发生到修复期间的影响，熔断导致crash的业务

背景 随着稳定性治理和性能优化的深入，发现现有trace在有些方面已经很难满足排查问题的需要 比如更深层次的启动优化,framework crash排查，release包trace查看,竞品流程分析等

遇到问题 java.lang.OutOfMemoryError: pthread_create(1040KB stack) failed: Out of Memory 查看系统抛出异常过程 art/r

hprof文件不仅仅只能排查oom,还能帮助我们排查验证一些奇奇怪怪的问题，下面是仅举了两个例子。希望通过这几个例子能拓宽大家排除crash的思路。 案例一 可以先思考一下，遇到以下线上偶现的cras