本篇文章给大家谈谈flutter底层原理,以及flutter 底层对应的知识点,希望对各位有所帮助,不要忘了收藏本站喔。
今天给各位分享flutter底层原理的知识,其中也会对flutter 底层进行解释,如果能碰巧解决你现在面临的问题,别忘了关注本站,现在开始吧!
本文目录一览:
Flutter Channel底层原理分析
百度网盘flutter 见46-Flutter Channel
Flutter 提供三种Channel用作Flutter与iOS原生平台之间的数据传递
1.FlutterBasicMessageChannel: 用作频繁与原生交互
2.FlutterMethodChannel:用来调用
方法,双向通讯
3.FlutterEventChannel:数据流通讯
三种Channel,都有以下成员变量
1.name: Channel 的唯一标识
在Flutter应用中,通常存在多个Platform Channel,使用name区分不同的Channel
2.messenger: 消息信使(BinaryMessenger)
负责Flutter与原生之间的相互通讯
[methodChannel setMethodCallHandler:^(FlutterMethodCall * _Nonnull call, FlutterResult _Nonnull result) {
}];
setMethodCallHandler方法,MethodCallHandler放在FlutterBinaryMessageHandler中
创建一个FlutterMethodChannel,通过 setMethodCallHandler来进行消息处理,最终会为FlutterMethodChannel绑定一个FlutterBinaryMessageHandler,并以FlutterMethodChannel的name作为key,保存在一个Map结构中
先创建 FlutterEngine-FlutterViewController-FlutterMethodChannel,
调用setMethodCallHandler方法时,会进入FlutterEngine的setMessageHandlerOnChannel:binaryMessageHandle:中,在进入PlatformMessageRouter中进行储存
flutter与原生交互方法和底层原理分析
1.环境准备, 参考链接
2.添加国内环境
配置: 参考链接
3.新建
name: String类型,代表Channel的名字,也是其唯一标识符。
messager:BinaryMessenger类型,代表消息信使,是消息的发送与接收的工具。
codec: MessageCodec类型或MethodCodec类型,代表消息的编解码器。
fluuter中的MessageCodec用于二进制格式数据与基础数据之间的编解码。BasicMessageChannel所使用的编解码器就是MessageCodec。
iOS中,名称为FlutterMessageCodec,是一个协议,定义了两个方法:encode接收一个类型为id的消息,将其编码为NSData类型,而decode接收NSData类型消息,将其解码为id类型数据。
MessageCodec有多种不同的实现:
与MessageCodec不同的是,MethodCodec用于MethodCall对象的编解码,一个MethodCall对象代表一次从Flutter端发起的方法调用。MethodCall有2个成员变量:String类型的method代表需要调用的方法名称,通用类型(Android中为Object,iOS中为id)的arguments代表需要调用的方法入参
由于处理的是方法调用,故相比于MessageCodec,MethodCodec多了对调用结果的处理。当方法调用成功时,使用encodeSuccessEnvelope将result编码为二进制数据,而当方法调用失败时,则使用encodeErrorEnvelope将error的code、message、detail编码为二进制数据
MethodCodec有两种实现:
二、Flutter的渲染机制以及setState()背后的原理
开始FrameWork层会通知Engine表示自己可以进行渲染了
flutter底层原理,在下一个Vsync信号到来之时,Engine层会通过Windows.onDrawFrame回调Framework进行整个页面的构建与绘制。每次收到渲染页面的通知后,Engine调用Windows.onDrawFrame最终交给_handleDrawFrame()方法进行处理。最后会走到 WidgetsBinding.drawFrame() = buildOwner.buildScope(renderViewElement) = _dirtyElements[index].rebuild() = performRebuild() 这里会触发当前element的widget的build方法= updateChild() 注意这里已经是子节点进行接下来的操作了= 子节点update() = 子节点rebuild() = 子节点performRebuild() ...
小结
flutter底层原理:所以说在widget树中,越高层的 build() 里调用 setState() 会导致遍历所有的子节点=遍历所有子节点的子节点...
话术总结: setState() 会将当前的 element 标记为 脏 ,并交由 buildOwner ,由 buildOwner 加入自己的 脏列表中 ,等收到页面渲染的通知后(这里
流程简略掉),会调用 buildOwenr. buildScope () ,这里会遍历 脏列表 然后每一个都会调用 rebuild() , rebuild() 又会调用 performRebuild() , performRebuild() 则会调用 build() 方法重建当前的 element ,然后调用 updateChild () 开始更新子节点,进而触发子节点的 rebuild() 方法,进行下一轮的周期...一直到最后一个节点
最近公司做技术分享写的文章的demo
Flutter中的InheritedWidget状态管理
1.InheritedWidget是什么?
InheritedWidget是Flutter中非常重要的一个功能型组件,它提供了一种数据在widget树中从上到下传递、共享的方式,比如我们在应用的根widget中通过InheritedWidget共享了一个数据,那么我们便可以在任意子widget中来获取该共享的数据!这个特性在一些需要在widget树中共享数据的场景中非常方便!如Flutter SDK中正是通过InheritedWidget来共享应用主题(Theme)和Locale (当前语言环境)信息的。
InheritedWidget和React中的context功能类似,和逐级传递数据相比,它们能实现组件跨级传递数据。InheritedWidget的在widget树中数据传递方向是从上到下的,这和通知Notification的传递方向正好相反。
2.源码分析
InheritedWidget
先来看下InheritedWidget的源码:
abstract class InheritedWidget extends ProxyWidget { const InheritedWidget({ Key key, Widget child }): super(key: key, child: child); @override InheritedElement createElement() =InheritedElement(this); @protected bool updateShouldNotify(covariant InheritedWidget oldWidget);}
它继承自ProxyWidget:
abstract class ProxyWidget extends Widget { const ProxyWidget({ Key key, @required this.child }) : super(key: key); final Widget child;}
可以看出Widget内除了实现了createElement方法外没有其他操作了,它的实现关键一定就是InheritedElement了。
InheritedElement 来看下InheritedElement源码
class InheritedElement extends ProxyElement { InheritedElement(InheritedWidget widget) : super(widget); @override InheritedWidget get widget = super.widget; // 这个Set记录了所有依赖的Elementfinal Map<Element, Object _dependents = HashMap<Element, Object();
//该方法会在Element mount和activate方法中调用,_inheritedWidgets为基类Element中的成员,用于提高Widget查找父节点中的InheritedWidget的效率,它使用HashMap缓存了该节点的父节点中所有相关的InheritedElement,因此查找的时间复杂度为o(1) @override void _updateInheritance() {final Map<Type, InheritedElement incomingWidgets = _parent?._inheritedWidgets;if (incomingWidgets != null) _inheritedWidgets = HashMap<Type, InheritedElement.from(incomingWidgets); else _inheritedWidgets = HashMap<Type, InheritedElement(); _inheritedWidgets[widget.runtimeType] = this; }
//该方法在父类ProxyElement中调用,看名字就知道是通知依赖方该进行更新了,这里首先会调用重写的updateShouldNotify方法是否需要进行更新,然后遍历_dependents列表并调用didChangeDependencies方法,该方法内会调用mardNeedsBuild,于是在下一帧绘制流程中,对应的Widget就会进行rebuild,界面也就进行了更新 @override void notifyClients(InheritedWidget oldWidget) { assert(_debugCheckOwnerBuildTargetExists('notifyClients'));for (Element dependent in _dependents.keys) { notifyDependent(oldWidget, dependent); } }
其中_updateInheritance方法在基类Element中的实现如下:
void _updateInheritance() {
_inheritedWidgets = _parent?._inheritedWidgets;
}
总结来说就是Element在mount的过程中,如果不是InheritedElement,就简单的将缓存指向父节点的缓存,如果是InheritedElement,就创建一个缓存的副本,然后将自身添加到该副本中,这样做会有两个值得注意的点:
InheritedElement的父节点们是无法查找到自己的,即InheritedWidget的数据只能由父节点向子节点传递,反之不能。
如果某节点的父节点有不止一个同一类型的InheritedWidget,调用inheritFromWidgetOfExactType获取到的是离自身最近的该类型的InheritedWidget。
看到这里似乎还有一个问题没有解决,依赖它的Widget是在何时被添加到_dependents这个列表中的呢?
回忆一下从InheritedWidget中取数据的过程,对于InheritedWidget有一个通用的约定就是添加static的of方法,该方法中通过inheritFromWidgetOfExactType找到parent中对应类型的的InheritedWidget的实例并返回,与此同时,也将自己注册到了依赖列表中,该方法的实现位于Element类,实现如下:
@overrideT dependOnInheritedWidgetOfExactType
// 这里通过上述mount过程中建立的HashMap缓存找到对应类型的InheritedElement final InheritedElement ancestor = _inheritedWidgets == null ? null : _inheritedWidgets[T];if (ancestor != null) { assert(ancestor is InheritedElement);return dependOnInheritedElement(ancestor, aspect: aspect); } _hadUnsatisfiedDependencies = true; return null;}
@overrideInheritedWidget dependOnInheritedElement(InheritedElement ancestor, { Object aspect }) { assert(ancestor != null);
// 这个列表记录了当前Element依赖的所有InheritedElement,用于在当前Element deactivate时,将自己从InheritedElement的_dependents列表中移除,避免不必要的更新操作 _dependencies ??= HashSet<InheritedElement(); _dependencies.add(ancestor); ancestor.updateDependencies(this, aspect);return ancestor.widget;}
3.如何使用InheritedWidget
1)、创建一个类继承自Inheritedwidget
class InheritedContext extends InheritedWidget{ final InheritedTestModel inheritedTestModel; InheritedContext({ Key key, @required this.inheritedTestModel, @required Widget child}): super(key: key, child: child);static InheritedContext of (BuildContext context) { return context.dependOnInheritedWidgetOfExactType<InheritedContext(); } @override bool updateShouldNotify(InheritedContext oldWidget) { return inheritedTestModel != oldWidget.inheritedTestModel; }}
2)、InheritedTestModel类为数据容器(这里定义了一个List<int数据源)
class InheritedTestModel{ final List _list; InheritedTestModel(this._list); List getList(){ return _list; }}
class ArrayListData{ static List _list ;static List getListData (){ _list = new List(); _list .add(1); _list .add(2); _list .add(3); _list .add(4);return _list ; }}
3)、定义一个Widget 使用 InheritedContext类的数据 InheritedTestModel
class ListDemo extends StatefulWidget{ @override State createState() { return new ListDemoState(); }}class ListDemoState extends State<ListDemo{List _list; InheritedTestModel _inheritedTestModel; Timer _timer; Duration oneSec = const Duration(seconds: 1); @override void initState() { _list = ArrayListData. getListData (); _inheritedTestModel = new InheritedTestModel(_list); _timer = Timer.periodic(oneSec, (timer) { _doTimer(); }); } void _doTimer() { for(int i = 0; i < _list.length; i++){ _list[i] = _list[i]+ 1; } setState(() { _inheritedTestModel = new InheritedTestModel(_list); }); }Widget _buildBody() { return Container(child: ListDemo2(), ); } @override Widget build(BuildContext context) { return InheritedContext(inheritedTestModel: _inheritedTestModel, child: Scaffold(appBar: AppBar(title: Text("ListDemo"), actions: <Widget[ IconButton(icon: Icon(Icons. add ), ) ],), body: _buildBody(), ), ); } @override void dispose() { super.dispose();if (_timer != null) { _timer.cancel(); } }}
4)、在ListDemo中通过Timer更新InheritedTestModel 中的数据,然后再下一个Widget中获取更新的数据作为展示
class ListDemo2 extends StatefulWidget{ @override State createState() { return new ListDemoState2(); }}class ListDemoState2 extends State<ListDemo2{InheritedTestModel _inheritedTestModel; Widget _buildListItem(BuildContext context,int index) { return Container(height: 50, width: 100, alignment: Alignment. center , child: Text(_inheritedTestModel.getList()[index].toString()), ); }Widget _buildBody() { _inheritedTestModel = InheritedContext. of (context).inheritedTestModel;return Container(child: ListView.builder(itemBuilder:(context, index)=_buildListItem(context,index),itemCount: _inheritedTestModel.getList().length,), ); } @override Widget build(BuildContext context) { return _buildBody(); }}
这样就可以在父widget中更新数据,子View不需任何操作直接从数据容器InheritedTestModel 中获取到更新后的新数据
这是一个数据共享的简单的例子,基本的流程,大致就是A去更新B的数据,A和B有一个共同的父类,实现数据的共享
4.上面说了原理和基本的使用,但是在实际项目当中,我当然不建议这样来使用,Google 已经为我们封装好了功能更加强大的插件Provider,其内部原理就是基于InheritedWidget来实现的,我们理解了基本原理,可以更好的在项目中运用Provider
关于flutter底层原理和flutter 底层的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站。
flutter底层原理的介绍就聊到这里吧,感谢你花时间阅读本站内容,更多关于flutter 底层、flutter底层原理的信息别忘了在本站进行查找喔。
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。
暂时没有评论,来抢沙发吧~