欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

Android 虛擬機中的內存分配與OOM問題詳解

 更新時間:2022年09月02日 16:27:30   作者:Android社區(qū)  
這篇文章主要為大家介紹了Android 虛擬機中的內存分配與OOM問題詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪

背景知識

Android中每個App默認情況下是運行在一個獨立進程中的, 而這個獨立進程正是從Zygote孵化出來的VM進程, 也就是說, 也就是說每個Android APP在運行時會啟動一個Java虛擬機。

并且系統(tǒng)會給它分配固定的內存空間(手機廠商會根據(jù)手機的配置情況來對其進行調整)。

一、Android VM的內存空間

Android是一個多任務系統(tǒng), 為了保證多任務的運行, Android給每個App可使用的Heap大小設定了一個限定值.

這個值是系統(tǒng)設置的prop值, 保存在System/build.prop文件中. 一般國內的手機廠商都會做修改, 根據(jù)手機配置不同而不同, 可以直接打開查看與修改。

其中和虛擬機內存相關的主要有以下三個:

1 . dalvik.vm.heapstartsize

– App啟動后,系統(tǒng)分配給它的Heap初始大小,隨著App使用可增加。

2 . dalvik.vm.heapgrowthlimit

– 默認情況下, App可使用的Heap的最大值, 超過這個值就會產生OOM.

3 . dalvik.vm.heapsize

– 如果App的manifest文件中配置了largeHeap屬性, 那么App可使用的Heap的最大值為此項設定值。

 <application
    android:largeHeap="true">
    ...
</application>

所以對于同一個手機,不開啟largeHeap屬性時與多進程時,每個APP的虛擬機分配的內存的上限都是heapgrowthlimit。

1.查看內存的API

Android在ActivityManager類中提供了API可以運行時獲取這些屬性值,如下:

//ActivityManager的getMemoryClass()獲得內用正常情況下內存的大小,即heapgrowthlimit的值
//ActivityManager的getLargeMemoryClass()可以獲得開啟largeHeap最大的內存大小,即heapsize的指
ActivityManager activityManager = (ActivityManager)context.getSystemService(Context.ACTIVITY_SERVICE);
activityManager.getMemoryClass();
activityManager.getLargeMemoryClass();

二、Android VM內存分配流程

虛擬機分配內存的具體源碼可以AOSP的Heap.cpp文件中查看:

/* Try as hard as possible to allocate some memory.
 */
static void *tryMalloc(size_t size)
{
    void *ptr;
//TODO: figure out better heuristics
//    There will be a lot of churn if someone allocates a bunch of
//    big objects in a row, and we hit the frag case each time.
//    A full GC for each.
//    Maybe we grow the heap in bigger leaps
//    Maybe we skip the GC if the size is large and we did one recently
//      (number of allocations ago) (watch for thread effects)
//    DeflateTest allocs a bunch of ~128k buffers w/in 0-5 allocs of each other
//      (or, at least, there are only 0-5 objects swept each time)
    ptr = dvmHeapSourceAlloc(size);
    if (ptr != NULL) {
        return ptr;
    }
    /*
     * The allocation failed.  If the GC is running, block until it
     * completes and retry.
     */
    if (gDvm.gcHeap->gcRunning) {
        /*
         * The GC is concurrently tracing the heap.  Release the heap
         * lock, wait for the GC to complete, and retrying allocating.
         */
        dvmWaitForConcurrentGcToComplete();
    } else {
      /*
       * Try a foreground GC since a concurrent GC is not currently running.
       */
      gcForMalloc(false);
    }
    ptr = dvmHeapSourceAlloc(size);
    if (ptr != NULL) {
        return ptr;
    }
    /* Even that didn't work;  this is an exceptional state.
     * Try harder, growing the heap if necessary.
     */
    ptr = dvmHeapSourceAllocAndGrow(size);
    if (ptr != NULL) {
        size_t newHeapSize;
        newHeapSize = dvmHeapSourceGetIdealFootprint();
//TODO: may want to grow a little bit more so that the amount of free
//      space is equal to the old free space + the utilization slop for
//      the new allocation.
        LOGI_HEAP("Grow heap (frag case) to "
                "%zu.%03zuMB for %zu-byte allocation",
                FRACTIONAL_MB(newHeapSize), size);
        return ptr;
    }
    /* Most allocations should have succeeded by now, so the heap
     * is really full, really fragmented, or the requested size is
     * really big.  Do another GC, collecting SoftReferences this
     * time.  The VM spec requires that all SoftReferences have
     * been collected and cleared before throwing an OOME.
     */
//TODO: wait for the finalizers from the previous GC to finish
    LOGI_HEAP("Forcing collection of SoftReferences for %zu-byte allocation",
            size);
    gcForMalloc(true);
    ptr = dvmHeapSourceAllocAndGrow(size);
    if (ptr != NULL) {
        return ptr;
    }
//TODO: maybe wait for finalizers and try one last time
    LOGE_HEAP("Out of memory on a %zd-byte allocation.", size);
//TODO: tell the HeapSource to dump its state
    dvmDumpThread(dvmThreadSelf(), false);
    return NULL;
}

具體流程如下:

  • 嘗試分配,如果成功則返回,失敗則轉入步驟2
  • 判斷是否gc正在進行垃圾回收,如果正在進行則等待回收完成之后,嘗試分配。如果成功則返回,失敗則轉入步驟3
  • 自己啟動gc進行垃圾回收,這里gcForMalloc的參數(shù)是false。所以不會回收軟引用,回收完成后嘗試分配,如果成功則返回,失敗則轉入步驟4
  • 調用dvmHeapSourceAllocAndGrow嘗試分配,這個函數(shù)會擴張堆的大小,失敗轉入步驟5
  • 進入回收軟引用階段,這里gcForMalloc的參數(shù)是ture,所以需要回收軟引用。然后再調用dvmHeapSourceAllocAndGrow嘗試分配,如果失敗則拋出OOM

小結

所以產生OOM時,一定是java的堆中 已有的內存 + 申請的內存 >= heapgrowthlimit導致的,不會因為手機目前物理內存是否緊張而改變 - 當物理內存非常緊張時系統(tǒng)會通過LowMemory Killer殺掉一些低優(yōu)先級的進程。

相應的,物理內存非常充足的情況也會有OOM的情況發(fā)生。

三、出現(xiàn)OOM的建議解決方案

當APP出現(xiàn)OOM時,建議可以從以下兩個方向來處理:

1 . 排查內存泄露問題

  • 排查各個功能是否內存泄露情況,可以通過Android Studio中的MemoryMonitor功能進行分析,Memory Monitor也集成了HPROF Viewer和Allocation Tracker可以分析內存快照與內存分配追蹤。另外推薦一個工具,square公司開源的leakcanary,非常簡潔好用。

  • 排查進程初始化時就直接申請并常駐內存的對象以及其他功能里申請的static對象或者單例對象的必要性。

2 . 內存優(yōu)化

按照谷歌在youtube上發(fā)布的性能優(yōu)化典范之內存篇,優(yōu)化各功能的內存,或可參照 胡凱的總結 。

大致有以下這些,具體請參見原文:

  • 謹慎使用large heap
  • 綜合考慮設備的內存閾值與其他因素設計合適的緩存大小
  • onLowMemory與onTrimMemory
  • 資源文件需要選擇合適的文件夾進行存放
  • Try catch某些大內存分配的操作
  • 謹慎使用static對象
  • 特別留意單例對象中不合理的持有
  • 珍惜Services資源
  • 優(yōu)化布局層次,減少內存消耗
  • 謹慎使用“抽象”編程
  • 使用nano protobufs序列化數(shù)據(jù)
  • 謹慎使用依賴注入框架
  • 謹慎使用多進程
  • 使用ProGuard來剔除不需要的代碼
  • 謹慎使用第三方libraries

考慮不同的實現(xiàn)方式來優(yōu)化內存占用

  • 注意Activity的泄露
  • 考慮使用Applicaiton Context代替Activity Context
  • 注意臨時Bitmap對象的及時回收
  • 注意監(jiān)聽器的注銷
  • 注意緩存容器里的對象泄露
  • 注意Webview的泄露

注意Cursor對象的及時關閉

  • 復用系統(tǒng)自帶的資源
  • ListView中對ConvertView的復用
  • Bitmap對象的復用
  • 避免在ondraw方法里執(zhí)行對象的創(chuàng)建

StringBuilder代替String

  • 使用更加輕量的數(shù)據(jù)結構
  • 避免在Android里使用enum
  • 減少Bitmap對象的內存占用

使用更小的圖片

  • 減少對象的內存占用
  • 內存對象的重復利用
  • 避免對象的內存泄露
  • 內存使用策略的優(yōu)化

以上就是Android 虛擬機中的內存分配與OOM問題詳解的詳細內容,更多關于Android虛擬機內存分配OOM的資料請關注腳本之家其它相關文章!

相關文章

最新評論