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對其進行擴充套件。
我們對例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，是不是很像。呼叫鏈如圖：
由於是通過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，最終顯示到螢幕。整個熱身幀繪製流程如圖：
總結
(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 排版