阅读 519

从mixin机制理解Flutter App启动

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 机制