約定：

• 默認 Android 平臺，32位應用
• Flutter 版本 1.20

背景

Flutter 接入後，內存的水位升高，oom是較突出的問題。

通過理清以下幾個關鍵問題，可幫助我們更全面認識 Flutter 內存管理，提高解決問題的效率。

• Flutter 內存由幾部分構成？
• new space, old space 內存是如何分配，管理的？
• external 堆內存是怎麼分配，回收的？
• gc 觸發的入口，時機，條件？

Flutter內存佈局

Flutter 內存邏輯上按分配來源可分為4部分：

• VirtualMemory ：Dart Vm內部“內存分配器”實現，通過map/munmap接口獲取內存； heap  new space , old space 內存分配，釋放都經過它。
• Dart_Handle : Dart Vm 與 外部c/c++ 內存傳遞的“不透明”指針，裡面包含一個heap內對象。external部分內存實際不分配在heap上。
• map/unmap : engine其他模塊直接從系統獲取內存，例如skia，gpu等
• malloc/free : 其他通過標準內存分配器分配的內存

Dart Heap 管理的是 VirtualMemory，external 這2部分內存。

Dart Heap 內存管理

Dart Heap 分代管理內存，新生代gc算法是 Mark-Copying ，老生代gc結合使用 Mark-Sweep, Mark-Compact算法。

Dart Heap 能完全控制 VirtualMemory 部分內存釋放，間接控制 external 部分內存的釋放（後面描述）。

Dart Vm 對象指針 -- ObjectPtr

ObjectPtr 表示對象在堆中都地址，信息豐富，堆中拷貝，移除，gc發生時遍歷被引用對象都通過它進行。

Heap中對象 size 要求是雙字（8字節）倍數，因此最低 2 / 3 位可以用來表示其他含義：

• 0 bit : 是否有效heap對象地址，1 - 有效heap地址，0 表示一個small int，>>1 則可得到數值
• 2 bit : 對象分佈，0 - old generation, 1 - new generation

ObjectPtr 封裝對象地址，包含判斷有效對象指針，new/old 對象判斷等。

ObjectLayout 是所有Dart對象的頂級父類，包含一個Tags對象，實質是一個uint_t，Heap 對象內存模型上都是以Tags對象開始的。Tags按bits分佈：

• class id : 對象類型id
• size : 對象大小，size位域值 << 3 可計算出；如果超出範圍，則通過 ObjectLayout::HeapSizeFromClass() 方法計算，例如一個數組對象
• gc 輔助信息：存儲gc過程中間保存信息

ObjectPtr 與 ObjectLayout 關係

通過 ObjectPtr 可獲得對象 類型，大小，新/老 生代，gc 狀態信息。那怎麼遍歷被引用的對象呢？

假設定義一個Dart 類：

class ClassA {
  ClassB _classB;
  ClassC _classC;
}

其在內存中佈局示意如下：

    intptr_t instance_size = HeapSize();
    uword obj_addr = ToAddr(this);
    uword from = obj_addr + sizeof(ObjectLayout);
    uword to = obj_addr + instance_size - kWordSize;
    const auto first = reinterpret_cast<ObjectPtr*>(from);
    const auto last = reinterpret_cast<ObjectPtr*>(to);

通過上面簡單計算，就可以遍歷被引用的 ClassB， ClassC 對象了。Dart gc時候遍歷被引用對象用的就是這個方法。

分代內存管理

核心類

Heap 表示Vm的heap，對象分配，釋放都是從這裡開始，通過Scavenger，PageSpace分別管理 “新生代”，“老生代”內存。

內存分配的核心類是 VirtualMemory，通過封裝系統 map/munmap 接口從系統分配大塊內存，在“析構” 方法中將內存歸還給系統。

最右邊部分是gc相關類，Mark-Copying, Mark-Sweep, Mark-Compact 算法具體實現。

新生代內存管理

內存分配

新生代有2個半區：from, to。內存分配都是從to區分配，回收從from區回收。

SmiSpace管理半區內存的分配，涉及幾個角色：

• Thread : Isolate 內部每個線程都會關聯一個page，從page中快速分配內存
• SmiSpace : 以鏈表結構管理所有分配出來的page；gc就是對該鏈表中的page進行
• page_cache : 緩存gc回收的page
• VirtualMemory : 分配新的page

內存分配步驟如下，成功則不再往下執行：

1. 從當前線程關聯的page中優先分配，空間足夠則成功返回
2. 從SmiSpace管理的page中找一個空閒的page或者空間足夠的page進行重新綁定，並進行內存分配
3. 從page_cache中獲取一個新的page，進行分配
4. 則通過VirtualMemory從系統分配一個新的page

內存分配成功後，會對返回的對象內存進行 tagged 操作，使其滿足通過 ObjectPtr 尋址。針對 SmiSpace gc後，釋放的page歸還到page_cache。

注意點：

• max_capacity_in_words_ (默認32位8M，64位16M) 管理新生代最大內存，超出範圍，則新生代內存分配失敗，嘗試從老生代進行分配
• 每個page=512KB，page_cache最大緩存32個page，其餘gc時歸還給系統
• 新生代最大對象256KB，大於該值則從老生代分配largePage中分配

新生代gc

SemiSpace* Scavenger::Prologue() {
    ...
    SemiSpace* from = to_;
    to_ = new SemiSpace(NewSizeInWords(from->max_capacity_in_words()));
    ...
}
      

gc 第一步交換  from，to 半區，針對 from 區進行，而gc結束後，除了歸還到page_cache緩存中的pages，其他都會隨著 from 出棧，析構 方法中釋放。新的對象在to區中進行分配。

新生代gc採取代是 Semispace collector 分配器，對象拷貝基於Cheney算法，下面2圖描述了算法過程。其主要步驟：

• 廣度搜索優先，拷貝Roots直接引用到to區
• 拷貝對象到to區時，需要進行forward操作，在from區的舊對象中保存拷貝後to區的新地址；在後續拷貝時，如果有引用到該對象，則需要調整引用地址
• scan在to區最初始位置，拷貝完Roots後，從scan開始遍歷，將to區中對象內部引用的對象進行 回收 或者 拷貝。通過“Dart Vm對象描述“中方法遍歷被引用的對象

老生代內存管理

內存分配

老生代內存分配主要角色：

• PageSpace : 保存所有從 VirtualMemory 中分配過來的page，gc就是對該鏈表中page進行
• free_list : 類似內存管理”夥伴系統“算法，將 VirtualMemory 中分配的 page 地址打散，以 16Byte * n 大小分為 128 個鏈表，例如分配16Byte內存，則直接從第1個鏈表中返回一段內存地址
• VirtualMemory :分配新的page

內存分配步驟如下，成功則不再往下：

1. 通過 size / 16 計算對應落在的區間，如果由空閒空間則分配成功
2. 嘗試從下一級更大內存鏈表中分配內存
3. 分配成功，嘗試將分配剩餘的內存重新放到更小內存區鏈表中
4. 不再繼續嘗試，直接從128最大區中進行內存分配
5. 同3
6. 直接從 VirtualMemory 中分配新內存

注意：

• free_list 中負責 64KB 以下內存分配；更大內存通過 largePage 進行分配，管理較簡單，一個page分配給1個對象，gc回收直接使用Mark-Sweep算法。largePage size大小根據需要分配的size而定，並與系統pageSize對齊（4K），可見這種情況特別浪費內存，可能造成比較多的內存碎片。

  intptr_t PageSpace::LargePageSizeInWordsFor(intptr_t size) {
    // 根據需分配size計算，並以4k page對齊
    intptr_t page_size = Utils::RoundUp(size + OldPage::ObjectStartOffset(),
                                        VirtualMemory::PageSize());
    return page_size >> kWordSizeLog2;
  }​

• 老生代中也會分配 code 緩存，這部分會增加一些權限控制，不細述
• max_capacity_in_words_ 控制 old space 最大容量，默認 1.5G （30G 64位）

老生代gc

老生代通過Mark-Sweep，Mark-Compact 算法進行內存回收。Sweep 每次回收都會進行，但Compact需要滿足一定條件才進行。下圖簡單描述了算法的過程，其主要步驟：

• 從Roots深度遍歷所有對象，並進行標記
• 重新計算被標記的對象的拷貝地址，則新地址
• 遍歷對象，如果引用了被標記的對象，需要更新對其的引用地址
• 拷貝對象

算法的實現細節較多，這裡不詳細展開。

External 內存

核心類

Dart_Handle

Dart_Handle 可分為3類: LocalHandle 臨時本地對象， PersistentHandler，FinalizablePersistentHandle 生存期與isolate同等。每個Handle都有1個 ObjectPtr 對象，這個對象指向的是保存在Dart Heap堆中堆對象。

重點是 FinalizablePersistentHandle ，它有一個指針：void * peer。這個 peer 指向一個在 c/c++ 分配，在Dart Heap 外部的對象。通過 peer 和 ObjectPtr，將這個c/c++對象與Dart Vmd堆heap對象關聯起來。如上圖中 新生代對象 A，關聯的內存實際分配在VM的別處，Dart Heap external 對這種內存的大小進行了統計，但並不由heap來分配。這樣做帶來的好處是可以將這個 c/c++ 對象的釋放託管給Dart Gc，Flutter中典型應用： image ，Layer 等：例如 Image對象，其關聯瞭解碼後的c/c++緩存，在Widget銷燬的時候，Image對象被回收，c/c++層的解碼內存也得到釋放。

FinalizablePersistentHandles 也是一類GC Roots，gc的時候，如果其 ObjectPtr 指向的對象沒有被標記，則觸發回收 peer 指向的對象，本質上是 c/c++ 智能指針引用計數-1操作，如果計數為0才會真正釋放 peer 指向的對象。所有這裡就會存在釋放失敗的場景，例如 image 的解碼對象被 Handle 引用，同時又被 engine skia或者其他引用了，那在gc的時候，仍然無法釋放這個對象，這也是為什麼Observatory裡面看到image被釋放回收了，但內存不一定降下來的原因。

zone

zone 中主要是用於分配一些小對象，這些對象的內存也不從heap中分配，通過Segment直接從系統分配，例如一個獲取一個字符串。在gc時機，會對整個zone的內存一起釋放。

GC管理

dart_api.h 對外暴露 Dart VM 接口，Flutter通過調用以下接口可觸發gc。

/**
 * Notifies the VM that the embedder expects to be idle until |deadline|. The VM
 * may use this time to perform garbage collection or other tasks to avoid
 * delays during execution of Dart code in the future.
 *
 * |deadline| is measured in microseconds against the system's monotonic time.
 * This clock can be accessed via Dart_TimelineGetMicros().
 *
 * Requires there to be a current isolate.
 */
DART_EXPORT void Dart_NotifyIdle(int64_t deadline);

/**
 * Notifies the VM that the system is running low on memory.
 *
 * Does not require a current isolate. Only valid after calling Dart_Initialize.
 */
DART_EXPORT void Dart_NotifyLowMemory();

Dart_NotifyIdle

deadline是傳給Dart_NotifyIdle()參數，表示在這個時間限制內完成gc。gc耗時計算方法為：“堆使用字大小 / 每個字gc耗時“。

bool Scavenger::ShouldPerformIdleScavenge(int64_t deadline) {
  ...
  // 計算gc完成後時間點
  int64_t estimated_scavenge_completion =
      OS::GetCurrentMonotonicMicros() +
      used_in_words / scavenge_words_per_micro_;
  // 必須在 deadline 前完成
  return estimated_scavenge_completion <= deadline;
}

scavenge_words_per_micro_ 默認值為 40（根據flutter在Nexus4 上測試獲得），後續計算根據最近4次 堆使用字和gc耗時 取平均值。

void Scavenger::Epilogue(SemiSpace* from) {
  ...
  // Update estimate of scavenger speed. This statistic assumes survivorship
  // rates don't change much.
  intptr_t history_used = 0;
  intptr_t history_micros = 0;
  ASSERT(stats_history_.Size() > 0);
  for (intptr_t i = 0; i < stats_history_.Size(); i++) {
    history_used += stats_history_.Get(i).UsedBeforeInWords();
    history_micros += stats_history_.Get(i).DurationMicros();
  }
  if (history_micros == 0) {
    history_micros = 1;
  }
  scavenge_words_per_micro_ = history_used / history_micros;
  ...
}

Dart_NotifyIdle 方法觸發的時機有2個：

• vsync 信號來臨，兩幀間隔之間觸發，deadline 為處理完 BeginFrame() 後到下一幀到來的時間間隔（16ms - BeginFrame耗時）
• 如果連續3幀時間（51ms）都沒有 requestFrame 發出，觸發gc，deadline 為 100ms

Heap收到 Dart_NotifyIdle() 信號，需要滿足相應的條件才會執行真正的gc操作。條件的判斷主要有2個維度：

• 能夠在滿足deadline內完成gc操作
• 是否達到gc條件的內存閥值 
  • new space 閥值
    • idle_scavenge_threshold_in_words_ ： 與 new_gen_semi_max_size 大小一樣，默認 8M（16M 64位）
  • old space 閥值：（old space 閥值包含external部分內存）
    • idle_gc_threshold_in_words_ ： 初始化為0，每次gc後重新評估 : "gc後使用內存 + 2* OldPageSize"，OldPageSize = 512KB
    • soft_gc_threshold_in_words_ ：初始化為0，每次gc後重新評估：
      • 32位與 hard_gc_threshold_in_words_  相等
      • 64位該值 = hard_gc_threshold_in_words_  - Max( new space /2, hard_gc_threshold_in_words_ /20 )
    • hard_gc_threshold_in_words_ : 
      • 依賴配置，在每次gc完成後，重新計算 hard_gc_threshold_in_words_，根據gc回收內存量，滿足下面限制下計算新的值
        • garbage_collection_time_ratio_ ：FLAG_old_gen_growth_space_ratio，控制gc耗時佔比，默認配置3%，例如計算1次gc耗時方式：（（本次gc耗時） / （本次gc結束耗時 - 上次gc結束耗時））*  100%
        • heap_growth_max_ ：FLAG_old_gen_growth_rat，控制old space 1次最大增大pages數。pageSize = 512KB，默認配置 280
        • desired_utilization_  ：1 - FLAG_old_gen_growth_space_ratio，FLAG_old_gen_growth_space_ratio 配置表示每次gc後要求剩餘的free空間佔比。默認配置為 20%
      • 重新計算策略：
        • 如果自上次gc後，old space 堆上實際使用內存增加，則根據 FLAG_old_gen_growth_space_ratio 條件計算出需要增加的 grow_pages
          • 如果增加使用的內存，且回收的garbage = 0，這時候說明內存需求量較大，則本次增加 growth = max(heap_growth_max_，grow_pages)
          • 如果garbage > 0，說明有垃圾產生，增加內存主要滿足 FLAG_old_gen_growth_space_ratio 設置；另外如果 gc耗時超過 garbage_collection_time_ratio_  的控制，說明 gc 較損耗性能，則適當增加free的空間，分配更多的空間，增大下次gc的閥值，減少整體gc的次數。根據本次產生垃圾的速度，預估下次產生垃圾的量，滿足：garbage_collection_time_ratio_ <= 下次垃圾量/old space總大小，計算出一個增量 local_grow_heap，如果 local_grow_heap > heap_growth_max_，則取：growth = max(local_grow_heap, grow_pages)，否則 growth = local_grow_heap
        • 如果自上次gc後，old space 堆上實際使用內存沒有增加，那條件自上次調整後，依舊滿足，growth = 0
    • 最後 hard_gc_threshold_in_words_ = gc後內存佔用 + growth * pageSize，每個page 512KB
    • idle_gc_threshold_in_words_ < soft_gc_threshold_in_words_ <= hard_gc_threshold_in_words_

基於上面控制參數，判斷流程如下：從上到下是 強->弱 降序排列，gc在滿足條件情況下，儘量回收更多的垃圾。

Dart_NotifyLowMemory

如果系統內存過低，可通過embedding FlutterJNI.java 中提供的接口觸發：

// shell/platform/android/io/flutter/embedding/engine/FlutterJNI.java
@Keep
public class FlutterJNI {
  ...
  /**
   * Notifies the Dart VM of a low memory event, or that the application is in a state such that now
   * is an appropriate time to free resources, such as going to the background.
   *
   * <p>This is distinct from sending a SystemChannel message about low memory, which only notifies
   * the running Flutter application.
   */
  @UiThread
  public void notifyLowMemoryWarning() {
    ensureRunningOnMainThread();
    ensureAttachedToNative();
    nativeNotifyLowMemoryWarning(nativePlatformViewId);
  }
  private native void nativeNotifyLowMemoryWarning(long nativePlatformViewId);
  ...
}

 

Jni接口註冊：

bool RegisterApi(JNIEnv* env) {
    ...
    {
        .name = "nativeNotifyLowMemoryWarning",
        .signature = "(J)V",
        .fnPtr = reinterpret_cast<void*>(&NotifyLowMemoryWarning),
    },
    ...
}

最終在Heap中處理，這時候不會進行條件判斷，直接對 new,old space進行垃圾回收

void Heap::CollectMostGarbage(GCReason reason) {
  Thread* thread = Thread::Current();
  CollectNewSpaceGarbage(thread, reason);
  CollectOldSpaceGarbage(
      thread, reason == kLowMemory ? kMarkCompact : kMarkSweep, reason);
}

內部觸發

Dart_NotifyIdle()，Dart_NotifyLowMemory() 都是外部調用Dart Vm接口進行的gc，vm內部在內存分配的時候也會進行gc的嘗試：

1. old space 內存分配失敗時，會嘗試gc，之後再進行內存的分配，再失敗，則報oom
2. 每次分配 external 內存時，new space, old space 都會進行條件的判斷，嘗試觸發gc。

// external 內存，嘗試gc
void Heap::AllocatedExternal(intptr_t size, Space space) {
  ASSERT(Thread::Current()->no_safepoint_scope_depth() == 0);
  if (space == kNew) {
    Isolate::Current()->AssertCurrentThreadIsMutator();
    new_space_.AllocatedExternal(size);
    // new space gc條件
    if (new_space_.ExternalInWords() <= (4 * new_space_.CapacityInWords())) {
      return;
    }
    // Attempt to free some external allocation by a scavenge. (If the total
    // remains above the limit, next external alloc will trigger another.)
    CollectGarbage(kScavenge, kExternal);
    // Promotion may have pushed old space over its limit. Fall through for old
    // space GC check.
  } else {
    ASSERT(space == kOld);
    old_space_.AllocatedExternal(size);
  }

  // old space 條件
  if (old_space_.ReachedHardThreshold()) {
    CollectGarbage(kMarkSweep, kExternal);
  } else {
    CheckStartConcurrentMarking(Thread::Current(), kExternal);
  }
}

 

總結

通過對內存分配來源分析，瞭解了Flutter內存的全貌。歸納下可分2大部分，一部分是Dart Heap管理，另一部分是Heap外的內存（mmap, malloc(其他內存分配器))。

Dart Heap 的內存關聯了 新/老生代Dart對象內存，external部分（Image，Layer 的渲染內存），這些也是Flutter自身內存消耗的主要來源。目前分析主要藉助 Observatory 工具，可以觀察 Heap 內存增長，gc 的變化。

通過 "persistent handles" 分析 external 內存信息，裡面主要是 Image， Layer 相關的內存，"Peer" 是 c/c++ 層的對象指針，Finalizer Callback 是gc回調的方法指針，這裡會對 peer 智能指針進行 -1 計數。

Observatory 工具對 Dart Heap 內存的分析還是挺強大的，結合上面對內存梳理的知識，通過靈活應用這個工具，可以幫助我們很好地解決內存洩漏的問題（具體解決問題case，後面再寫一篇）。

另外暫時沒有對 Heap 進行有效的性能測試：吞吐量，暫停時間，分配速度，使用率。這塊可以根據業務場景而優化其性能。

內存問題有時複雜，oom後內存分配具體去哪？這時候對 Dart Heap 外內存的統計對分析，解決問題也會比較有效。