（譯）你沒必要擔憂Dart的垃圾回收器

你沒必要擔憂Dart的垃圾回收器（譯）

在學習Flutter的過程當中，咱們知道Widget只是最終渲染對象（RenderObject）的配置文件，它會在build的時候頻繁的銷燬和建立，那麼，咱們不須要擔憂他的建立和銷燬帶來的性能問題嗎？

其實大可沒必要，由於Dart針對Flutter的Widget的建立和銷燬專門作過優化，這也是Flutter在多種語言中選擇Dart的一個重要因素，甚至咱們還能夠刻意利用這一點。

下面這篇文章解析了Dart的GC（Garbage Collector），對它作了個翻譯以及部份內容的解析，包括一些排版，有不對的地方你們多多指正。

原文地址：https://medium.com/flutter/flutter-dont-fear-the-garbage-collector-d69b3ff1ca30

Flutter使用Dart做爲開發語言和運行時機制，Dart一直保留着運行時機制，不管是在調試模式（debug）仍是發佈模式（release），可是兩種構建方式之間存在很大的差別。

• 在調試模型下，Dart將全部的管道（須要用到的全部配件）所有裝載到設備上：運行時，JIT（the just-in-time）編譯器/解釋器（JIT for Android and interpreter for iOS），調試和性能分析服務。
• 在發佈模式下，會除去JIT編譯器/解釋器依然保留運行時，由於運行時是Flutter App的主要貢獻者。

debug和release

Dart的運行時包括一個很是重要的組件：垃圾回收器，它主要的做用就是分配和釋放內存，當一個對象被實例化（instantiated）或者變成不可達（unreachable）。

在Flutter運行過程當中，會有不少的Object。

• 在StatelessWidget在渲染前（其實上還有StatefulWidget），他們被建立出來。
• 當狀態發生變化的時候，他們又會被銷燬。
• 事實上，他們又很短的壽命（lifespan）。
• 當咱們構建一個複雜的UI界面時，會有成千上萬這樣的Widgets。

因此，做爲Flutter開發者，咱們須要擔憂垃圾回收器不能很好的幫助咱們管理這些嗎？（是否是會帶來不少的性能問題呢）

• 當Flutter頻繁的建立和銷燬這些Widget（Objects），咱們是否須要很迫切的限制這種行爲呢？
• 很是廣泛，對於新的Flutter開發者來講，當一個Widget的狀態不須要改變時，他們會建立引用的Widget，來替代State中的Widget，以便於不會被銷燬或者重建。

不須要這樣作

擔憂Dart的GC是沒有任何事實根據的（沒有必要），這是由於它分代（generational）架構和實現，可讓咱們頻繁建立和銷燬對象有一個最優解。在大多數狀況下，咱們只須要Flutter引擎按照它的方式建立和銷燬這些Widgets便可。

Dart的GC

Dart的GC是分代的（generational）和由兩個階段構成：the young space scavenger（scavenger針對年輕一袋進行回收） and parallel mark sweep collectors（sweep collectors針對老一代進行回收）

註解：事實上V8引擎也是這樣的機制

調度安排（Scheduling）

爲了讓RG最小化對App和UI性能的影響，GC對Flutter引擎提供了hooks，hooks被通知當Flutter引擎被政策到這個App處於閒置的狀態，而且沒有用戶交互的時候。這就給了GC一個空窗期來運行它的手機階段，而且不會影響性能。

垃圾收集器還能夠在那些空閒間隔內進行滑動壓縮（sliding compaction），從而經過減小內存碎片來最大程度地減小內存開銷。

空閒時GC

階段一：Young Space Scavenger

這個階段主要是清理一些壽命很短的對象，好比StatelessWidget。當它處於阻塞時，它的清理速度遠快於第二代的mark、sweep方式。而且結合調度，完成能夠消除程序運行時的暫停現象。

本質上來說，對象在內存中被分配一段連續的、可用的內存空間，直接被分配完爲止。Dart使用bump pointer（註解：若是像malloc同樣，維護free_list再分配，效率很低。）分配新的空間，處理過程很是快。

分配了新對象的新空間，被爲兩部分，稱之爲semi spaces。一部分處於活動狀態，另外一部分處於非活動狀態。新對象分配在活動狀態，一旦填充完畢，依然存活的Object，就會從活動狀態copy到非活動狀態，而且清除死亡的Object。這個時候非活動狀態變成了活動狀態，上面的步驟一次重複。（註解：GC來完成上面的步驟）

爲了肯定哪些Object是存活的或死亡的，GC從根對象開始檢測它們的應用。而後將有引用的Object（存活的）移動到非活動狀態，直接全部的存活Object被移動。死亡的Object就被留下；

有關此的更多信息，請查看Cheney算法。

img

階段二：Parallel Marking and Concurrent Sweeping

當對象達到必定的壽命（在第一階段沒有被GC回收），它們將被提高由第二代收集器管理的新內存空間：mark-sweep。

這個階段的GC有兩個階段：第一階段，首先遍歷對象圖（the object graph），而後標記人在使用的對象。第二階段，將掃描整個內存，而且回收全部未標記的對象。

這種GC機制在標記階段會阻塞，不能有內存變化和UI線程也會被阻塞。可是因爲短暫的對象在Young Space Scavenger階段以及被處理，全部這個階段很是少出現。不過因爲Flutter能夠調用收集時間，影響的性能也會被見到最低。

可是若是引用程序不遵照分代的機制，反而這種狀況會常常發生。可是因爲Flutter的Widget的機制，全部這種狀況不常常發生，可是咱們仍是須要了解這種機制。

Isolate

值得注意的是，Dart中的Isolate機制具備私有堆的概念，彼此是獨立的。每一個Isolate有本身單獨的線程來運行，每一個Isolate的GC不影響其餘線程的性能。使用Isolate是避免阻塞UI和減輕密集型任務的好方法（註解：耗時操做可使用Isolate）。

總結

到這裏你應該明白：Dart使用了強大的分代GC，以最大限度的減小Flutter中GC帶來的性能影響。

因此，你不須要擔憂Dart的垃圾回收器，這個反而是咱們應用程序的核心所在。

備註：全部內容首發於公衆號，以後除了Flutter也會更新其餘技術文章，TypeScript、React、Node、uniapp、mpvue、數據結構與算法等等，也會更新一些本身的學習心得等，歡迎你們關注

公衆號