try {
var byte = ByteArray(10000000 * 1024 * 1024)
} catch (ignore: OutOfMemoryError) {
}
首先我们来了解一下,什么是 Error。
在 Java 中,可以被 try-catch
语句捕获的,都是 Throwable 的子类,分为 Error 和 Exception。
其中只有 Exception 可以被捕获,例如最常见的 NullPointException。因为当发生 Error 时,通常表示当前的执行环境,已经无法恢复,通常会直接导致线程终止甚至 JVM 终止。此时再通过 try-catch
捕获这个 Error,也无法恢复运行状态,即捕获毫无意义。
而这里提到的 OutOfMemoryError 也是一个 Error。原则上触发它时,执行环境已经无法恢复,不应该由应用层代码去捕获这个错误。具体可以参见之前的文章《Java 异常捕获》。
接下来,我们再来理清楚 OOM 产生的原因。
OOM 产生的原因很多,比较常见的,有申请大段连续的内存、堆内存不足、程序调用栈内存不足申请更多内存时,都有可能触发 OOM。
多数情况,OOM 触发时,只是压死骆驼的最后一根稻草。也许只是一个简单的申请内存的操作,但此时 JVM 中,已经没有更多内存可分配,并且 GC 也无法缓解,就会引发 OOM。
例如上面这种 OOM,其实就是开启了一个新页面,在页面的布局中加载了一个本地资源,直接导致触发 OOM 了。
那么是不是所有的 OOM 都不能被捕获?其实也有特殊的场景。
想通过 try-catch 成功捕获 OOM,需要 2 个先决条件:
加载一个大图 Bitmap、构造一个大数组对象等,都算是申请大段连续的内存。
当满足这 2 个条件时,触发的 OOM 才是可以被 catch 的。
这种技巧,已经在一些开源库中使用。例如 Volley 中,ImageRequest 中,就有这样一段代码。
在处理图片时,若捕获到 OOM,则放弃此次操作。此时并不会影响程序的正常执行,也就是这个 OOM 被成功 catch 住了。
正如前面说过,触发 Error 时,它的执行环境已经无法恢复。此时会导致线程终止甚至 JVM 终止,这种 Error 不应该由我们应用层去捕获。
理论上我们不应该去主动 catch OOM。哪怕在此处 catch 住了,可 App 当前的执行状态也已经处于「濒危」状态。如果不采取措施,此时不崩,换一个地方也会崩,逃的了初一,逃不过十五。
正确的做法是,主动去管理内存。图片是吃内存的大户,而如果 App 内统一了图片加载库,例如 Glide,在内存吃紧的时候,就可以通过 Glide 主动释放掉一些内存,让 App 恢复到健康的状态。
OOM 作为一个 Error,在某些条件下是可以被 catch 的。仅针对我们可控的代码,并且在 try 块中,由于申请大段连续内存的情况下,触发的 OOM,才是可以被 catch 的。
当 catch 住 OOM 时,应该主动释放一些可控的内存,做好内存管理,避免在后续的操作中,在其他操作中又触发 OOM,导致崩溃。
毕竟,出来混迟早是要还的。
本文对你有帮助吗?留言、好看、转发是最大的支持,谢谢!
Refrence:
-- End --
本文对你有帮助吗?留言、转发、点好看是最大的支持,谢谢!
推荐阅读:
把RecyclerView撸出花儿来,自定义无限循环的LayoutManager