人生百年几今日，今日不为真可惜。

背景通过前面的文章深入理解InheritedWidget和文章深入理解Notification，我们知道Flutter原生提供了两种组件之间数据共享的组件自上而下的共享数据方式采用InheritedWIgdt，自下而上的数据共享方式采用Notification，如果是跨页面共享数据呢？跨页面/组件共享状态的管理方式比较多，比如全局时间总线EventBus，它是一个第三方的插件，使用观察者模式实现，通过它可以实现跨组件状态同步。但是它有两个缺点：必须显示定义各种事件，不好管理需要手动注册和取消注册，

背景不管是刚写Flutter开发还是Flutter开发的老将，相信对BuildContext一定不陌生。那么BuildContext是什么呢？为什么我们每次StatelessWidget.build(context)，State.build(context)在调用build的时候都需要传入一个BuildContext呢？本文主要讲下BuildContext来龙去脉，已经它的使用场景。常见的BuildContext场景首先我们一起来看看BuildContext的使用场景，相信做过Flutter开发的同

文章目录背景Element分类核心源码分析Element.updateChildElement.inflateWidgetElement.upateStatelessElement.updateStatefulElement.updateProxyElement.updateRenderObjectElement.updateSingleChildRenderObjectElement.updateMultiChildRenderObjectElement.updateElement.mountCompon

背景Flutter提供了用于Widget间共享数据的InheritedWidget，当InheritedWidget发生变化时，它的子树中所有依赖了它的数据的Widget都会进行rebuild，这使得开发者省去了维护数据同步逻辑的麻烦。InheritedWidget看名字就是一个Widget，那么它是如何做到数据共享，如何做到通知更新的呢？下面我们一起来看看。InheritedWidget用法InheritedWidget用法分为以下几个步骤；自定义Widget继承自InheritedWidget

背景我们在进行Flutter开发过程中，几乎每一个Widget都会有一个可选参数——Key。但是我们却很少去传这个值，既然我们可以不用传，那么这个Key作用到底是什么呢？问题下面我们先来看看这样一个场景：void main() => runApp(MyApp());class MyApp extends StatelessWidget { @override Widget build(BuildContext context) { return MaterialApp(

背景在之前的文章【Flutter原理】三棵树的诞生与核心流程一文中，我们第一次接触到了buildOwner，也就是在WidgetsBinding对象的attachRootWidget(widget rootWidget)方法中，我们现在来回顾一下： void attachRootWidget(Widget rootWidget) { _readyToProduceFrames = true; _renderViewElement = RenderObjectToWidgetAdapte

文章目录背景Widgets系统分类核心源码WidgetStatelessWidgetStatefulWidgetStatesetStateInheritedWidgetRenderObjectWidget总结背景相信我们在Flutter开发过程中接触最多的无疑就是Widget了，通过Widget我们可以实现诸多功能：描述UI的层级结构定制UI的各色样式，国际化（font， color， theme）定义UI布局方式（padding，center等）数据共享（事件传递）(notification

背景上一文深入理解InheritedWidget我们知道，InheritedWidget的数据共享方式是父Widget到子Widget的逐层传递，适用于父Widget状态变更通知子widget变更的场景；那么本文讲解的Notification正好相反了，数据的的流动方式就是从子Widget向上传递只父Widget，适用于子widget状态变化，通知上层做相应处理的场景。Notification用法Notification用法分为以下几个步骤；自定义一个通知类，需要继承自Notification类；

文章目录背景RenderObject分类创建驱动驱动小结：布局绘制文章小结背景Widget，Element，RenderObject可以说是Flutter Framework的三个核心成员，本文我们一起来学习下RenderObject。宏观上来讲，一个RenderObject就是我们之前说的三棵树之一RenderObject Tree中的一个对象，它的职责主要有三个：布局，绘制，命中测试。其中命中测试在之前的文章一文深入了解Flutter事件机制有过详细的分析，本文我们主要来讲解其它两点：布局和绘制。

Flutter 是如何工作的？什么是Widgets, Elements, BuildContext, RenderObject, Bindings…阅读难度：初级介绍刚开始接触 Flutter 的时候，互联网上很难找到相关的资料，尽管也有不少相关的文章，但几乎没有关于 Flutter 内部实现的。Widgets, Elements, BuildContext 究竟是什么？为什么 Flutter 执行效率那么高？执行的时候，为什么有时候会出现不符合预期的结果？经常提到的树，究竟是什么？当你在开发一

背景Flutter作为一个跨平台的UI开发框架，有着自己独立的一套UI框架已经渲染引擎，那么它肯定有着自己一套独立的事件机制，用于分发管理各种各样的点击，双击，滑动等等事件，本文从Android平台层原生视图FlutterView出发，来探讨一下Flutter中的的事件分发机制。文章目录背景Flutter事件从哪来onTouchEventdispatchPointerDataPacketonPonterDataPacket_handlePointerDataPackethandlePointerEven

背景我们知道Flutter作为一个跨平台框架，那么必定存在着Native到Dart，Dart到Native之间的双工通信问题。本文我们一起来看看Flutter 平台通信相关原理。三种通信方式Flutter 官方提供三种 Platform 与 Dart 端消息通信方式，他们分别是 MethodChannel、BasicMessageChannel、EventChannel。他们都是全双工通信，他们的主要区别是：MethodChanel：用于传递方法调用(Method invocation)，一次性通

文章目录背景三棵树的来源时序图attachRootWidget分析attachToRenderTree分析mount分析总结背景相信写过Flutter的开发同学都知道，我们的Flutter UI是由各色各样的Widget组成。一般情况下很少只绘制单个widget的情况。那么如何有效的编排widget的结构，以及高效的将这些widget描述信息交给Flutter Engine，从而渲染出可媲美原生UI的性能的。本文我们就来探究下widget背后三棵树的来龙去脉。三棵树的来源从前面的文章"Flutte

通过上一篇Flutter实践分析之——平台整合Hybrid Composition我们对平台视图的原理有了一定的了解，我们知道FlutterMutatorView是平台视图PlatofrmView的parentView，那么我们再抛出几个疑问：一个widget tree中多个PlatformView的时候，是对应一个还是多个FlutterMutatorView？widget tree中多个PlatformView重叠的时候，是对应一个还是多个FlutterMutatorView？在widget tr

文章目录背景如何接入Hybrid composition1. 新建原生工程和Flutter Module2. 新建native_view_example.dart文件3. 在main.dart文件中显示4. 新建NativeView5. 新建NativeViewFactory6. 注册平台视图Hybrid Composition原理分析FlutterImageView分析PlatformViewLink分析PlatformViewController分析AndroidViewSurface分析Platfor

前言之前了解了flutter从启动到view的创建流程，本文一起来分析下Flutter Android端FlutterActivity和FlutterFragment代码流程分析。Flutter Android在创建新Flutter项目的时候并没有看到FlutterActivity/FlutterFragment，原因是Flutter Android的源码主要在maven端，也就是：io.flutter:flutter_embedding_xxx包中，配置地方是在flutter.gradle，可查看文章

文章目录前言Flutter渲染模式FlutterSurfaceView分析FlutterTextureView分析FlutterImageView分析FlutterRender分析FlutterView分析总结（类图，架构图）类关系图架构图前言​ 通过前面文章的分析我们了解到FlutterActivity的显示最终是通过FlutterView进行渲染。本文我们深入FlutterView的源码来具体分析下Flutter UI是如何一步步显示到Activity，又是如何跟Flutter Engine关联，

​ Flutter APP跟其他应用程序一样，入口也是在main方法，其内部就是一行代码，调用runAppp方法，将我们定义的根widget添加到界面上。作为Flutter的入口函数，我们有必要了解其背后的工作原理，runApp都做了些啥，能让我们的widget显示在界面上，同事支持各种事件操作，界面刷新等。首先我们来看看runApp源码：// App是一个widget，是Flutter应用启动以后要展示的第一个组件void runApp(Widget app) { // 1. 确保Widgets

首先手动创建一个hello_project的Flutter Project，再一步步跟着源码走按照惯例我们首先查找是否有自定义的Application，发现Flutter Project没有自定义Application，然后我们再来看MainActivity.ktclass MainActivity: FlutterActivity() {}MainActivity代码无比简单，我们继续看FlutterActivity.java（Google官方都推Kotlin了，FlutterActivity居