【Android自动化】移动端App--OOM崩溃的评估验证_移动端崩溃原因

移动端app常见崩溃类型大致体现在：

• 空指针
• 数组越界
• 插件化框架
• 系统崩溃
• 第三方插件\sdk调用
• oom等

在实际项目中OOM崩溃已可以从代码提交上就可以感知到，在测试验证中可以清晰的定位到是什么原因引起的OOM；

oom崩溃常见类型

1、java.lang.OutOfMemoryError:  no stack trace available
2、java.lang.OutOfMemoryError：GC overhead limit exceeded
3、java.lang.OutOfMemoryError：Direct buffer memory
4、java.lang.OutOfMemoryError：unable to create new native thread
5、java.lang.OutOfMemoryError: Failed to allocate
1
2
3
4
5

根据代码的提交，对比老版本的改动，若常驻加载出现改动，可能由于保活，内置插件新增的一些策略，保证应用在启动时同时唤起某类功能等等；

1.测试点：

• 评估影响范围，此类提交若安装包变大，
• 可能的原因UI，底层so，内置插件so改变等；
• 若常驻进程有改变需注意常驻进程是否增加陌生的线程；
• 应用内存是否可以正常的释放； 常驻存活的情况耗电情况的验证；

2.测试机型：

• 可以针对低版本机型上的内存情况进行监控；
• 市场上主流机型，华为，三星，OPPO等做主流测试机性能测试；

3.测试内容：

• 快速进入退出，对内存，CPU，线程，流量进行监控

• 启动时间：冷热启动，UI启动

• 主功能入口进入，并返回主界面静置1段时间，截取并记录；

• 安装包速度；

• 安装包大小，dex，so文件是否改变，内置插件增加情况；

• 涉及商业化相关的策略，需要与开发讨论，并设计接近用户使用的测试场景，进行功能，性能的监控；

• 稳定性测试（monkey），定时构建，每2小时执行一次，执行测试时间为1小时，对每个activity进行快速点击操作，记录崩溃日志；

• 测试结果同步：
  1.将性能数据做新老版本前后对比；
  2.内存，CPU波动情况需要考虑整体情况做结论；
  3.启动时间对比上波动情况；
  4.安装包大小，内置插件对比情况；
  5.内存折线图的反馈；
  6.将出现的崩溃信息一并同步给相关负责人；

**例：**

```java
java.lang.OutOfMemoryError: Failed to allocate a 414722 byte allocation with 63904 free bytes and 624KB until OOM
	at dalvik.system.VMRuntime.newNonMovableArray(Native Method)
	at android.graphics.BitmapFactory.nativeDecodeStream(Native Method)
	at android.graphics.BitmapFactory.decodeStreamInternal(BitmapFactory.java:650)
	at android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:626)
	at android.graphics.BitmapFactory.decodeFile(BitmapFactory.java:402)
	at android.os.Handler.handleCallback(Handler.java:754)
	at android.os.Handler.dispatchMessage(Handler.java:95)
	at android.os.Looper.loop(Looper.java:165)
	at android.os.Handler.handleCallback(Handler.java:754)
	at android.os.Handler.dispatchMessage(Handler.java:95)
	at android.app.ActivityThread.main(ActivityThread.java:6365)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:883)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:773)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

此类明显为内存不足问题，因此内存无法释放

oom崩溃，根据crash内容可以分析出，由于手机系统空间不足导致插件未能释放掉，出现了oom崩溃。

此外，通过上述测试内容同样也测试出了其他类型的OOM崩溃：

Caused by: java.lang.OutOfMemoryError: OutOfMemoryError thrown while trying to throw OutOfMemoryError; no stack trace available
android.view.InflateException: Binary XML file line #44: Binary XML file line #44: Error inflating class com.tencent.mm.common.ui.other.CommonGuideView
Caused by: android.view.InflateException: Binary XML file line #44: Error inflating class com.tencent.mm.common.ui.other.CommonGuideView
1
2
3

此时就要主要版本发布后，线上用户的崩溃情况了，在首次发布后应多关注相关类型的崩溃，评估是否进行修复，或由于产品需求原因可以对其进行加白处理，若对用户日活以及用户数量有影响需要响应并及时解决~

下一章节继续分享崩溃定位~