从mixin机制理解Flutter App启动

    技术2022-07-11  113

    文章目录

    1-mixin机制1.1-前言1.2-mixin特性 2-runApp启动2.1-binding初始化2.2-绑定根节点2.3-绘制热身帧 总结

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

    Processed: 0.013, SQL: 10