🎉 A framework for improving android 32bit app stability. (Alleviate crashes caused by insufficient virtual memory)

一行代�?解决 Android 32�?应用因虚拟内存�?足导致的 libc:abort(signal 6)

目�?国内的 Android App 大多数还是32�?架构，仅�??供了 arm-v7a 的动�?链接库，市�?�上大多数手机都是64�?的 CPU，App 通常都�?行在兼容模�?下，�?�以使用完整的 4GB 虚拟内存，但是国内应用一般都是集万�?�功能于一身，�?�?�业务越�?�越�?�?�(内置webview�?�?程�?�?高清大图�?短视频等等)，以�?�部分内存泄�?，4GB 的内存越�?�越�?够用了。

从去年(2020)开始，�?�大头部应用的 Native Crash 开始暴增，通常 Top1 都是 libc:abort，通过上报的 maps �?��?，虚拟内存地�?�空间大部分接近了 4GB，console logs 中也有大�?的 GL Errors: Out of memory(12)。

针对此问题，一般首先能想到的就是排查内存泄�?问题，但往往收效甚微，多�?�是因为�?�?�业务的�?�展，确实是需�?这么多虚拟内存。诚然通过�?�级64�?架构�?�以把地�?�空间上�?扩充到512GB，但是因为�?��?原因(包大�?�?维护�?本等等)，目�?大部分应用尚未完�?�?�级，所以在这里�??供一�?新的�?路。

(还是推�??大家尽快把自己的应用�?�级到64�?架构哦~ 至少是�?�ABI架构，32�?版本中�?�以继续�?留 Patrons 用于�??�?�存�?用户的体验。)

通过一系列技术手段实现�?行期间动�?调整Region Space预分�?的地�?�空间，释放出最多900MB(根�?�实际情况调整�?�数)虚拟内存给到 libc:malloc，增加了接近30%的地�?�上�?，大幅度给应用续命。

详细介�?：阿里开�? Patrons：大型 32 �? Android 应用稳定性�??�?� 50% 的“黑科技�?

编译patrons模�?� or 使用以下中心仓库的�??标，主工程�?赖该模�?�产物，在�?�适的时机进行�?始化：

   repositories {
        mavenCentral()
   }
   dependencies {
         implementation 'com.alibaba:patrons:1.1.0'
   }

    com.alibaba.android.patronus.Patrons.init(context, null);

1. SDK 本身会带�?�多少接入�?本(包大�?�?稳定性)：包大�?增加20k左�?�，�?�以忽略�?计；关键逻辑中会有多层�?护，�?会引�?�新的崩溃。

2. SDK 兼容性怎么样：在 Android 8�?8.1�?9�?10�?11�?12 共 6 个主�?版本生效，覆盖率接近 99.9%。在未兼容机型中�?会生效，亦�?会产生新的崩溃。

3. 使用�?�就能根治 Abort 么：肯定�?能，因为 Abort 的�?因很多，虽然32�?应用多�?�是因为虚拟内存�?足，但是也�?�能存在其他问题，适�?性还是�?具体情况具体分�?。