從mixin機制理解Flutter App啟動

Super鳴發表於2020-07-01
FlutterAPP

1-mixin機制

1.1-前言

轉載請註明出處：https://juejin.im/post/5efbf499e51d4534b979050c

  mixin機制並非dart獨創，在其他前端語言中也有很廣泛應用。但對於一個剛開始看Flutter原始碼的客戶端開發來說，各種mixin直接勸退，不得不先惡補下mixin。
  mixin首要特性就是實現函式複用，所以在開始mixin機制解析前，先從第一個問題出發：

  • 怎麼實現函式的複用?

  對應面嚮物件語言來說，通常的做法就是繼承，即在基類中實現某個函式，子類繼承該基類就可使用函式了。舉個例子：狗和鷹都可以移動，通過在基類Animal中實現moveTo方法，Dog和Eagle繼承後都能使用moveTo方法了

class Animal {
    void moveTo(){...//Do some thing}
}
class Dog extends Animal{}
class Eagle extends Animal{}
複製程式碼

  但通過繼承的方式實現函式複用會有另外一個問題。即函式是與基類耦合的，子類繼承了基類後就繼承了基類的所有方法和屬性。如果汽車要複用moveTo方法的話顯然繼承Animal是不合適的，由此引申出問題2：

  • 怎麼才能只複用Animal的moveTo方法而不繼承其他方法和屬性？

  首先肯定要把moveTo方法從Animal中解耦出來，定義一個介面CommonBehavior來實現。在java8及Kotlin的介面支援函式的預設實現，java8需要default關鍵字。kotlin介面定義的方法同樣支援預設實現，不過為了相容java之前的版本，採用的是編譯時生成一個靜態類，通過呼叫靜態類的靜態方法moveTo方法來實現。

interface CommonBehavior {
    defalut void moveTo(){...//Do some Thing}
}
class Dog implements CommonBehavior{}
複製程式碼

  此外Koltin還可以通過類委託來實現方法複用。除了介面外，還需宣告一個moveTo具體實現的委託類BehaviorDelegate。

interface CommonBehavior {
    fun moveTo()
}
class BehaviorDelegate : CommonBehavior {
    override fun moveTo(){...//Do some thing}
}
class Dog : CommonBehavior by BehaviorDelegate()
複製程式碼

  Kotlin類委託機制就不再詳述了，原理是通過代理實現。Java當然也是可以通過代理實現的，不過沒有by這種語法糖用起來爽。轉到正題：

  • 在Dart中怎麼去實現程式碼複用呢？

  Dart中沒有interface關鍵字，而是用mixin進行混合，將moveTo抽離到一個mixin修飾的CommonBehavior。這樣就能通過混入CommonBehavior直接使用moveTo方法了。

class Animal{}
mixin CommonBehavior{
  moveTo(){...//Do some thing};
}
class Dog extends Animal with CommonBehavior {}
複製程式碼

1.2-mixin特性

  實現程式碼複用只是mixin的基本功能，mixin還有其他強大的特性。
  混入多個mixin時會向前覆蓋，即後混入的mixin類中的方法會覆蓋前面繼承或混入的相同方法。我們先來看一個簡單的例1

//例1
class SuperClass{
 fun()=>print('SuperClass');
}
mixin MixA{
  fun()=>print('MixA');
}
mixin MixB{
 fun()=>print('MixB'); 
}
class Child extends SuperClass with MixA,MixB {}
main(){
  Child child = Child();
  child.fun();
}
複製程式碼

執行後的結果：
  MixB
  先混入的MixA含有fun()，覆蓋了SuperClass的fun()。而後混入的MixB也有fun()，覆蓋了MixA的方法，最終呼叫的是MixB的fun()方法。由此也可以知道後混入的mixin類的方法是最先呼叫的。為了驗證這一呼叫順序我們對例1進行如下改動：

//例2
class SuperClass{
  fun(){
    print('-->SuperClass.fun()');
    print('-->SuperClass');
  }

}
mixin MixA on SuperClass{
  fun(){
    print('-->MixA.fun()');
    super.fun();
    print('-->MixA');
  }
}
mixin MixB on SuperClass{
  fun(){
    print('-->MixB.fun()');
    super.fun();
    print('-->MixB');
  }
}
class Child extends SuperClass with MixA,MixB {}
main(){
  Child child = Child();
  child.fun();
}
複製程式碼

輸出結果：

-->MixB.fun()
-->MixA.fun()
-->SuperClass.fun()
-->SuperClass
-->MixA
-->MixB
複製程式碼

  由輸出結果可以看出通過mixin機制的呼叫關係，在形式上實現了類似"多繼承"一樣的繼承鏈。
  這裡使用了mixin on。mixin MixA on SuperClass 這樣支援在MixA中像繼承一樣通過super來呼叫SuperClass的方法。同時也限定了要混入MixA的類必須繼承自SuperClass。
  在繼承關係方面，輸出結果給人一種child-->MixB-->MixA-->SuperClass繼承關係的錯覺，其實不然。混合機制相當於在SuperClass的頂層混入mixin類並生成一個新類，類似於Android中的幀佈局SuperClass屬於最下層父佈局，mixin類屬於其中的子元素，mixin類之間並無父子關係相互解耦。後加入的mixin類在“幀佈局”中層級越靠上，會覆蓋下層的相同位置方法。用虛擬碼來描述上面例子中的繼承關係：

class SuperMixA = SuperClass with MixA;
class SuperMixAMixB = SuperMixA with MixB;
class Child extends SuperMixAMixB {}
複製程式碼

  這種"繼承鏈"如下圖所示，Child最終繼承的是在Super、MixA、MixB的一個混合，Child 的例項child 型別 屬於Super、MixA、MixB的混合，用型別判讀is得到的結果都是ture。但MixA與MixB直接卻並沒有直接關係，這也就符合了開閉原則，在不修改Child的基礎上通過mixin對其進行擴充套件。
mixin機制 (1).png

  我們對例2稍加修改，就更接近Flutter App啟動過程的呼叫關係了：

//例3
class SuperClass{
  SuperClass() {
    print('-->SuperClass init');
    fun();
  }
  fun(){
    print('-->SuperClass.fun() start');
    print('-->SuperClass.fun() end');
  }

}
mixin MixA on SuperClass{
  fun(){
    print('-->MixA.fun() start');
    super.fun();
    print('-->MixA.fun() end');
  }
}
mixin MixB on SuperClass{
  fun(){
    print('-->MixB.fun() start');
    super.fun();
    print('-->MixB.fun() end');
  }
}
class Child extends SuperClass with MixA,MixB {
  Child() {
    print('-->Child init');
  }
}
main(){
  Child child = Child();
}
複製程式碼

輸出結果：

-->SuperClass init
-->MixB.fun() start
-->MixA.fun() start
-->SuperClass.fun() start
-->SuperClass.fun() end
-->MixA.fun() end
-->MixB.fun() end
-->Child init
複製程式碼

  至此，mixin機制的講解就先告一段落，這些都是便於我們理解第2章講到的Flutter App啟動初始化過程。至於mixin其實還有其他相關特性，沒有建構函式、with還可以混入非mixin類等等，這裡就不再展開了。

2-runApp啟動

  FlutterApp啟動過程在Android中主要是從

  • FlutterApplication.onCreate完成載入引擎libflutter.so、註冊JNI方法等
  • FlutterActivity.onCreate中通過FlutterJNI的attachJNI來初始化引擎Engine、Dart VM、UI/GPU/IO執行緒初始化等
  • main.dart 中runApp

  本文主要是結合mixin機制從main.dart中的main()開始，講解dart層面的初始化啟動過程

void main() => runApp(MyApp());
複製程式碼

  接著是binding.dart中的runApp()，這裡是核心。這裡也是runApp啟動的三個主流程，我們從這三行程式碼來一一解析。

void runApp(Widget app) {
  WidgetsFlutterBinding.ensureInitialized()
    ..scheduleAttachRootWidget(app)
    ..scheduleWarmUpFrame();
}
複製程式碼

2.1-binding初始化

  WidgetsFlutterBinding.ensureInitialized()其實就是一個獲取WidgetsFlutterBinding單例的過程，真正的初始化實現程式碼在其7個mixin中。7個mixin分別完成不同部分的初始化工作，且根據mixin機制具有嚴格的先後呼叫鏈關係。至於這7個mixin的具體分工我們後面再細說。

class WidgetsFlutterBinding extends BindingBase with GestureBinding, ServicesBinding, SchedulerBinding, PaintingBinding, SemanticsBinding, RendererBinding, WidgetsBinding {
 static WidgetsBinding ensureInitialized() {
    if (WidgetsBinding.instance == null)
      WidgetsFlutterBinding();
    return WidgetsBinding.instance;
  }
}
複製程式碼

  WidgetsFlutterBinding繼承了BindingBase，而mixin是沒有建構函式的。所以先執行了父類BindingBase建構函式。

BindingBase() {
  developer.Timeline.startSync('Framework initialization');
  assert(!_debugInitialized);
  initInstances();
  assert(_debugInitialized);
  assert(!_debugServiceExtensionsRegistered);
  initServiceExtensions();
  assert(_debugServiceExtensionsRegistered);
  developer.postEvent('Flutter.FrameworkInitialization', <String, String>{});
  developer.Timeline.finishSync();
}
複製程式碼

  7個mixin都重寫了initInstances()方法，BindingBase.initInstances()會從最後混入的WidgetsBinding進行呼叫，而WidgetsBinding的initInstances函式中先通過super向上呼叫，屬於後續遍歷，所以呼叫順序和函式邏輯執行順序是相反的。回過頭看看第1章最後的例3，是不是很像。呼叫鏈如圖：
mixin2.png
  由於是通過super實現了後序遍歷的呼叫，所以函式的邏輯執行順序是相反的，BindingBase的initInstances先執行,然後是GestureBinding...最後到WidgetsBinding，依次完成了各mixin的相關初始化工作。
  (1)GestureBinding.initInstances 手勢事件繫結。進行一些變數初始化。GestureBinding中主要處理觸螢幕指標事件的分發以及事件最終回撥處理。

void initInstances() {
  super.initInstances();
  _instance = this;
  //將事件處理回撥賦值給window，供window收到螢幕指標事件後呼叫
  window.onPointerDataPacket = _handlePointerDataPacket;
}
複製程式碼

  這裡將事件處理回撥_handlePointerDataPacket賦值給window，供window收到螢幕指標事件後呼叫。window類似Android中的WindowManager，是framework層與engine層處理螢幕相關事件的橋樑。
  發生螢幕指標事件後會回撥window.onPointerDataPacket即這裡的_handlePointerDataPacket。_handlePointerDataPacket中會先呼叫hitTest進行命中測試。GestureBinding及RenderBinding都實現了hitTest方法，按照mixin順序會優先呼叫RenderBinding.hitTest。RenderBinding.hitTest會從renderTree的根節點遞迴呼叫命中測試，返回命中的深度最大的節點到根節點路徑上的所有節點。然後再執行dispatchEvent根據返回的hitTest命中節點列表遍歷分發事件，事件分發的順序是先子節點後父節點最終到根節點，類似前端的事件冒泡機制。
  (2)ServicesBinding.initInstances Flutter與Platform通訊服務繫結。

void initInstances() {
  super.initInstances();
  _instance = this;
  //構建一個_DefaultBinaryMessenger例項用於platform與flutter層通訊,訊息信使
  _defaultBinaryMessenger = createBinaryMessenger();
  //window設定監聽回撥，處理platform傳送的訊息
  window.onPlatformMessage = defaultBinaryMessenger.handlePlatformMessage;
  initLicenses();
  //設定處理platform傳送的系統訊息
  SystemChannels.system.setMessageHandler(handleSystemMessage);
}
複製程式碼

  ServicesBinding主要就是platform與flutter層通訊相關服務的初始化，BinaryMessenger作為二者之間通訊的信使，在這裡被初始化，且同樣是交給window來處理訊息。最後設定處理system訊息handleSystemMessage，而ServicesBinding的handleSystemMessage是空實現，PaintingBinding及WidgetsBinding都實現了該方法。呼叫順序是WidgetsBinding.handleSystemMessage-->PaintingBinding.handleSystemMessage-->ServicesBinding.handleSystemMessage。同樣是通過super後續遍歷呼叫，先在PaintingBinding中處理系統字型變動事件，後在WidgetsBinding中處理系統傳送的記憶體緊張訊號。
  (3)SchedulerBinding.initInstances 繪製排程繫結

void initInstances() {
  super.initInstances();
  _instance = this;
  //設定AppLifecycleState生命週期回撥
  SystemChannels.lifecycle.setMessageHandler(_handleLifecycleMessage);
  //根據生命週期變化設定window處理回撥
  //resumed || inactive狀態時才允許響應Vsync訊號進行繪製
  readInitialLifecycleStateFromNativeWindow();
  //debug編譯模式時統計繪製流程時長，開始、執行、構建、光柵化。
  if (!kReleaseMode) {
    int frameNumber = 0;
    addTimingsCallback((List<FrameTiming> timings) {
      for (final FrameTiming frameTiming in timings) {
        frameNumber += 1;
        _profileFramePostEvent(frameNumber, frameTiming);
      }
    });
  }
}
複製程式碼

  SchedulerBinding.initInstances 主要就是註冊監聽了flutter app的生命週期變化事件，根據生命週期狀態決定是否允許發起繪製任務。而SchedulerBinding的作用就是在window監聽到Vsync訊號後，通過SchedulerBinding來發起繪製任務。
  (4)PaintingBinding 繪製繫結。除了前面講的監聽系統字型變化事件，這裡主要是在繪製熱身幀之前預熱Skia渲染引擎。

void initInstances() {
  super.initInstances();
  _instance = this;
  //初始化圖片快取
  _imageCache = createImageCache();
  if (shaderWarmUp != null) {
    //第一幀繪製前的預熱工作
    shaderWarmUp.execute();
  }
}
複製程式碼

  (5)SemanticsBinding.initInstances 渲染輔助類繫結。SemanticsBinding主要負責關聯語義樹與Flutter Engine。

void initInstances() {
  super.initInstances();
  _instance = this;
  _accessibilityFeatures = window.accessibilityFeatures;
}
複製程式碼

  (6)RendererBinding.initInstances 渲染繫結，RendererBinding是render tree 與 Flutter engine的粘合劑，因為它持有了render tree的根節點renderView。

void initInstances() {
  super.initInstances();
  _instance = this;
  //初始化PipelineOwner管理渲染流程
  _pipelineOwner = PipelineOwner(
    onNeedVisualUpdate: ensureVisualUpdate,
    onSemanticsOwnerCreated: _handleSemanticsOwnerCreated,
    onSemanticsOwnerDisposed: _handleSemanticsOwnerDisposed,
  );
  //設定window回撥，處理螢幕引數、文字縮放因子、亮度等變化時回撥。
  window
    ..onMetricsChanged = handleMetricsChanged
    ..onTextScaleFactorChanged = handleTextScaleFactorChanged
    ..onPlatformBrightnessChanged = handlePlatformBrightnessChanged
    ..onSemanticsEnabledChanged = _handleSemanticsEnabledChanged
    ..onSemanticsAction = _handleSemanticsAction;
  //初始化一個RenderView作為render tree的根節點，作為渲染流水線執行入口
  initRenderView();
  //設定是否根據render tree生成語義樹
  _handleSemanticsEnabledChanged();
  assert(renderView != null);
  //繪製流水線回撥
  addPersistentFrameCallback(_handlePersistentFrameCallback);
  initMouseTracker();//滑鼠監聽
}
複製程式碼

  回過頭看看(1)GestureBinding.initInstances方法中的事件處理，呼叫的就是這裡的renderView.hitTest從根節點開始命中測試的。正因為RenderBinding建立並持有了RenderView例項，所以GestureBinding中通過mixin機制將RenderBinding的hitTest方法混入，從而可以實現命中測試，相當於需要用到命中測試的地方都通過mixin委託給RenderBinding來實現了。
  addPersistentFrameCallback將繪製處理回撥_handlePersistentFrameCallback加入到Persistent型別回撥列表，_handlePersistentFrameCallback中的drawFrame方法是實現繪製流水線的地方，包括佈局和繪製流程，後面繪製熱身幀會用到。
  (7)WidgetsBinding.initInstances 元件繫結

void initInstances() {
  super.initInstances();
  _instance = this;
  assert(() {
    _debugAddStackFilters();
    return true;
  }());
 //初始化BuildOwnder，處理需要繪製的Element的構建工作
  _buildOwner = BuildOwner();
  //通過SchedulerBinding初始化window的onBeginFrame、onDrawFrame回撥
  //如果app可見，通過window.scheduleFrame向engine發起繪製請求
  buildOwner.onBuildScheduled = _handleBuildScheduled;
  //語言環境變化處理
  window.onLocaleChanged = handleLocaleChanged;
  //platform訪問許可權變化處理
  window.onAccessibilityFeaturesChanged = handleAccessibilityFeaturesChanged;
  //處理系統傳送的push/pop頁面請求
  SystemChannels.navigation.setMethodCallHandler(_handleNavigationInvocation);
  FlutterErrorDetails.propertiesTransformers.add(transformDebugCreator);
}
複製程式碼

  WidgetsBinding屬於最外層的mixin，作為處理Widget相關事件的入口。在初始化過程中主要是生成了BuildOwner例項，以及window的onBeginFrame、onDrawFrame回撥，後面渲染流程會用到。
  BindingBase先通過按順序執行7個mixin的initInstances方法，完成了相關初始化工作，以及兩個重要類的例項化PipelineOwner、BuildOwner。然後就是執行了initServiceExtensions方法,實現了該方法的mixin按呼叫順序為WidgetsBinding-->RendererBinding-->SchedulerBinding-->ServicesBinding主要就是在debug模式下注冊相關擴充服務。

2.2-繫結根節點

  ensureInitialized完成後，就開始執行scheduleAttachRootWidget(app)將使用者傳入的Widget繫結到一個跟節點並構建三棵樹。

void scheduleAttachRootWidget(Widget rootWidget) {
  Timer.run(() {
    attachRootWidget(rootWidget);
  });
}
複製程式碼

  由於是元件相關，attachRootWidget具體的實現在WidgetsBinding裡

void attachRootWidget(Widget rootWidget) {
  _readyToProduceFrames = true;
  _renderViewElement = RenderObjectToWidgetAdapter<RenderBox>(
    container: renderView,
    debugShortDescription: '[root]',
    child: rootWidget,
  ).attachToRenderTree(buildOwner, renderViewElement as RenderObjectToWidgetElement<RenderBox>);
}
複製程式碼

  類似Android中將DecorView與ViewRootImpl繫結，通過ViewRootImpl來作為檢視操作根節點入口。Flutter中也是將app的主widget（即使用者定義的MyApp）和根節點繫結。其中render tree的根節點就是前面初始化流程中RendererBinding.initInstances過程建立的RenderView，RenderView是繼承自RenderObject的，所以還需要建立Element和Widget與之關聯，而建立的Element和Widget分別對應另外兩棵樹的根節點。
  (1)先是通過傳入的MyApp及RenderView例項化了一個RenderObjectToWidgetAdapter物件，而RenderObjectToWidgetAdapter是繼承自RenderObjectWidget，即建立了Widget樹的根節點。
  (2)createElement建立根element，並通過BuildOwner構建需要構建的element

RenderObjectToWidgetElement<T> attachToRenderTree(BuildOwner owner, [ RenderObjectToWidgetElement<T> element ]) {
  if (element == null) {
    owner.lockState(() {
      //建立了一個RenderObjectToWidgetElement例項作為element tree的根節點
      element = createElement();
      assert(element != null);
      //繫結BuildOwner
      element.assignOwner(owner);
    });
    //標記需要構建的element，並rebuild
    owner.buildScope(element, () {
      element.mount(null, null);
    });
    SchedulerBinding.instance.ensureVisualUpdate();
  } else {
    element._newWidget = this;
    element.markNeedsBuild();
  }
  return element;
}
複製程式碼

2.3-繪製熱身幀

  繫結完根節點後，就開始立即執行scheduleWarmUpFrame()繪製首幀的工作了。前面window.scheduleFrame發起繪製請求是在收到Vsync訊號後才開始的，app初始化時為了節省時間並未等待Vsync訊號直接開始繪製，所以叫熱身Frame。和普通繪製一樣，熱身幀也是通過handleBeginFrame、handleDrawFrame這兩個回撥來進行繪製流程，在前面WidgetBinding初始化時將這兩個回撥交給了window，具體程式碼邏輯是在SchedulerBinding。

void scheduleWarmUpFrame() {
  if (_warmUpFrame || schedulerPhase != SchedulerPhase.idle)
    return;
  _warmUpFrame = true;
  Timeline.startSync('Warm-up frame');
  final bool hadScheduledFrame = _hasScheduledFrame;
  // Timer任務會加入到event queue
  // 所以在執行繪製前先處理完microtask queue中的任務
  Timer.run(() {
    assert(_warmUpFrame);
  // 繪製Frame前工作，主要是處理Animate動畫
    handleBeginFrame(null);
  });
  // 繪製前有機會執行完microtask queue
  Timer.run(() {
    assert(_warmUpFrame);
    // 開始Frame繪製
    handleDrawFrame();
    resetEpoch();
    _warmUpFrame = false;
    if (hadScheduledFrame)
      //後續Frame繪製請求
      scheduleFrame();
  });
  lockEvents(() async {
    await endOfFrame;
    Timeline.finishSync();
  });
}
複製程式碼

  handleBeginFrame處理動畫相關邏輯，動畫回撥後並不立即執行動畫，而是改變了animation.value，並呼叫setSate()來發起繪製請求。動畫的過程就是在Vsync訊號到來時根據動畫進度計算出對應的value，而對應的Widget也會隨著animation.value的變化而重建，從而形成動畫，是不是和Android的屬性動畫原理差不多。

void handleBeginFrame(Duration rawTimeStamp) {
    ...
    _hasScheduledFrame = false;
    try {
      // 處理回撥前設定為瞬態
      _schedulerPhase = SchedulerPhase.transientCallbacks;
      final Map<int, _FrameCallbackEntry> callbacks = _transientCallbacks;
      _transientCallbacks = <int, _FrameCallbackEntry>{};
      //處理Animation回撥
      callbacks.forEach((int id, _FrameCallbackEntry callbackEntry) {
        if (!_removedIds.contains(id))
          _invokeFrameCallback(callbackEntry.callback, _currentFrameTimeStamp, callbackEntry.debugStack);
      });
      _removedIds.clear();
    } finally {
        //回撥處理完，設定為中間態，即先處理microTask任務佇列
      _schedulerPhase = SchedulerPhase.midFrameMicrotasks;
    }
}
複製程式碼

  handleBeginFrame處理完後，會優先處理microTask任務佇列。然後才是event Task，window.onDrawFrame()，對應SchedulerBinding.handleDrawFrame()。（Timer任務會加入到event queue，flutter的事件處理機制是優先處理micro queue中任務）

void handleDrawFrame() {
    try {
      // 處理Persistent型別回撥,主要包括build\layout\draw流程
      _schedulerPhase = SchedulerPhase.persistentCallbacks;
      for (FrameCallback callback in _persistentCallbacks)
        _invokeFrameCallback(callback, _currentFrameTimeStamp);
    
      // 處理Post-Frame回撥，主要是狀態清理，準備排程下一幀繪製請求
      _schedulerPhase = SchedulerPhase.postFrameCallbacks;
      final List<FrameCallback> localPostFrameCallbacks =
          List<FrameCallback>.from(_postFrameCallbacks);
      _postFrameCallbacks.clear();
      for (FrameCallback callback in localPostFrameCallbacks)
        _invokeFrameCallback(callback, _currentFrameTimeStamp);
    } finally {
        //處理完成，狀態idle
      _schedulerPhase = SchedulerPhase.idle;
      _currentFrameTimeStamp = null;
    }
}
複製程式碼

  WidgetsBinding.drawFrame()為Persistent型別的一個回撥，在前面講到的RendererBinding初始化時通過addPersistentFrameCallback中加入了RendererBinding.drawFrame，所以這裡也是用到了mixin機制，在WidgetsBinding.drawFrame()中完成元件的構建任務，在RendererBinding.drawFrame完成元件的佈局、繪製任務。是不是分工明確。

//WidgetsBinding.drawFrame()
void drawFrame() {
   try {
    if (renderViewElement != null)
      //呼叫BuildOwner.buildScope開始構建
      buildOwner.buildScope(renderViewElement);
      //呼叫RendererBinding.drawFrame，開始佈局、繪製階段。
    super.drawFrame();
    //從element tree中移除不需要的element，unmount
    buildOwner.finalizeTree();
  } finally {
     ...
  }
}
複製程式碼

  繪製流程結束後會產生這一幀的資料Scene，由window.render交給Engine，最終顯示到螢幕。整個熱身幀繪製流程如圖：
繪製.png

總結

(1) mixin機制在FlutterApp啟動過程可謂秀的飛起，通過如上分析也得到了mixin機制帶來的優勢有哪些：

  • 高內聚低耦合。適合應用於需要多個功能模組配合完成的場景，將功能模組通過mixin解耦，各模組職責單一，相互之間不直接引用。
  • 程式碼複用。通過混入模組，就可以像呼叫自身方法一樣呼叫混入模組的方法。
  • 保證呼叫順序。mixin配合super呼叫，可以實現同名方法的“繼承鏈”式呼叫，保證序列執行順序。


(2)Flutter App的啟動過程總結：

  • ensureInitialized 通過7個mixin 按順序完成相關初始化工作
  • scheduleAttachRootWidget 繫結app 應用啟動Widget到根節點，主要是render tree的根節點RenderView，RenderView又關聯了widget tree 的根節點和 element tree的根節點
  • scheduleWarmUpFrame 立即完成首幀繪製


參考文章：
[1] Dart: What are mixins?
[2] Dart 2 Mixin Declarations
[3] 徹底理解 Dart mixin 機制

本文使用 mdnice 排版

相關文章