从mixin机制理解Flutter App启动

Super鸣
2,540 阅读15分钟

1-mixin机制

1.1-前言

  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这种语法糖用起来爽。转到正题：

（PS:kotlin类委托配合动态代理可以实现接口的选择性实现，有兴趣可以看看读源码-LeakCanary2.4解析中2.2章节。）

  • 在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。其实Flutter还维护一个semantic tree语义树，页面构建的时候会根据各Widget的语义描述构建一棵semantic tree语义树。例如我们在Image组件中配置semanticLabel语义内容，用户在IOS/Android手机开启无障碍功能时，触摸到该Image时通过语义树查找到对应的语义描述交给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()绘制首帧的工作了。不调用scheduleWarmUpFrame()，按理说也是可以渲染的，那热身帧的意义是什么呢？。

  • (1)前面window.scheduleFrame发起绘制请求是在收到Vsync信号后才开始的，app初始化时为了节省时间并未等待Vsync信号直接开始绘制，最多可以节省16.6ms(60Hz屏幕刷新率)等待时间。
  • (2)在热身帧绘制结束前通过加锁来屏蔽期间的屏幕指针事件处理及_taskQueue中的回调，保证在绘制过程中不会再触发新的重绘。
  • (3)在预热帧绘制结束后调用resetEpoch()来重置时间戳，避免热重载情况从预热帧到热重载帧的时间差，导致隐式动画的跳帧情况。

  和普通绘制一样，热身帧也是通过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 机制

avatar
文章
阅读
粉丝

友情链接：