flutter做壁纸,flutter设置背景图片

Android图形渲染原理上

对于Android开发者来说，我们或多或少有了解过Android图像显示的知识点，刚刚学习Android开发的人会知道，在Actvity的onCreate方法中设置我们的View后，再经过onMeasure，onLayout，onDraw的流程，界面就显示出来了；对Android比较熟悉的开发者会知道，onDraw流程分为软件绘制和硬件绘制两种模式，软绘是通过调用Skia来操作，硬绘是通过调用Opengl ES来操作；对Android非常熟悉的开发者会知道绘制出来的图形数据最终都通过GraphiBuffer内共享内存传递给SurfaceFlinger去做图层混合，图层混合完成后将图形数据送到帧缓冲区，于是，图形就在我们的屏幕显示出来了。

但我们所知道的Activity或者是应用App界面的显示，只属于Android图形显示的一部分。同样可以在Android系统上展示图像的WebView，Flutter，或者是通过Unity开发的3D游戏，他们的界面又是如何被绘制和显现出来的呢？他们和我们所熟悉的Acitvity的界面显示又有什么异同点呢？我们可以不借助Activity的setView或者InflateView机制来实现在屏幕上显示出我们想要的界面吗？Android系统显示界面的方式又和IOS，或者Windows等系统有什么区别呢？……

去探究这些问题，比仅仅知道Acitvity的界面是如何显示出来更加的有价值，因为想要回答这些问题，就需要我们真正的掌握Android图像显示的底层原理，当我们掌握了底层的显示原理后，我们会发现WebView，Flutter或者未来会出现的各种新的图形显示技术，原来都是大同小异。

我会花三篇文章的篇幅，去深入的讲解Android图形显示的原理，OpenGL ES和Skia的绘制图像的方式，他们如何使用，以及他们在Android中的使用场景，如开机动画，Activity界面的软件绘制和硬件绘制，以及Flutter的界面绘制。那么，我们开始对Android图像显示原理的探索吧。

在讲解Android图像的显示之前，我会先讲一下屏幕图像的显示原理，毕竟我们图像，最终都是在手机屏幕上显示出来的，了解这一块的知识会让我们更容易的理解Android在图像显示上的机制。

图像显示的完整过程，分为下面几个阶段：

图像数据→CPU→显卡驱动→显卡（GPU）→显存（帧缓冲）→显示器

我详细介绍一下这几个阶段：

实际上显卡驱动，显卡和显存，包括数模转换模块都是属于显卡的模块。但为了能能详细的讲解经历的步骤，这里做了拆分。

当显存中有数据后，显示器又是怎么根据显存里面的数据来进行界面的显示的呢？这里以LCD液晶屏为例，显卡会将显存里的数据，按照从左至右，从上到下的顺序同步到屏幕上的每一个像素晶体管，一个像素晶体管就代表了一个像素。

如果我们的屏幕分辨率是1080x1920像素，就表示有1080x1920个像素像素晶体管，每个橡素点的颜色越丰富，描述这个像素的数据就越大，比如单色，每个像素只需要1bit，16色时，只需要4bit，256色时，就需要一个字节。那么1080x1920的分辨率的屏幕下，如果要以256色显示，显卡至少需要1080x1920个字节，也就是2M的大小。

刚刚说了，屏幕上的像素数据是从左到右，从上到下进行同步的，当这个过程完成了，就表示一帧绘制完成了，于是会开始下一帧的绘制，大部分的显示屏都是以60HZ的频率在屏幕上绘制完一帧，也就是16ms，并且每次绘制新的一帧时，都会发出一个垂直同步信号（VSync）。我们已经知道，图像数据都是放在帧缓冲中的，如果帧缓冲的缓冲区只有一个，那么屏幕在绘制这一帧的时候，图像数据便没法放入帧缓冲中了，只能等待这一帧绘制完成，在这种情况下，会有很大了效率问题。所以为了解决这一问题，帧缓冲引入两个缓冲区，即 双缓冲机制 。双缓冲虽然能解决效率问题，但会引入一个新的问题。当屏幕这一帧还没绘制完成时，即屏幕内容刚显示一半时，GPU 将新的一帧内容提交到帧缓冲区并把两个缓冲区进行交换后，显卡的像素同步模块就会把新的一帧数据的下半段显示到屏幕上，造成画面撕裂现象。

为了解决撕裂问题，就需要在收到垂直同步的时候才将帧缓冲中的两个缓冲区进行交换。Android4.1黄油计划中有一个优化点，就是CPU和GPU都只有收到垂直同步的信号时，才会开始进行图像的绘制操作，以及缓冲区的交换工作。

我们已经了解了屏幕图像显示的原理了，那么接着开始对Android图像显示的学习。

从上一章已经知道，计算机渲染界面必须要有GPU和帧缓冲。对于Linux系统来说，用户进程是没法直接操作帧缓冲的，但我们想要显示图像就必须要操作帧缓冲，所以Linux系统设计了一个虚拟设备文件，来作为对帧缓冲的映射，通过对该文件的I/O读写，我们就可以实现读写屏操作。帧缓冲对应的设备文件于/dev/fb* ，*表示对多个显示设备的支持， 设备号从0到31，如/dev/fb0就表示第一块显示屏，/dev/fb1就表示第二块显示屏。对于Android系统来说，默认使用/dev/fb0这一个设帧缓冲作为主屏幕，也就是我们的手机屏幕。我们Android手机屏幕上显示的图像数据，都是存储在/dev/fb0里，早期AndroidStuio中的DDMS工具实现截屏的原理就是直接读取/dev/fb0设备文件。

我们知道了手机屏幕上的图形数据都存储在帧缓冲中，所以Android手机图像界面的原理就是将我们的图像数据写入到帧缓冲内。那么，写入到帧缓冲的图像数据是怎么生成的，又是怎样加工的呢？图形数据是怎样送到帧缓冲去的，中间经历了哪些步骤和过程呢？了解了这几个问题，我们就了解了Android图形渲染的原理，那么带着这几个疑问，接着往下看。

想要知道图像数据是怎么产生的，我们需要知道 图像生产者 有哪些，他们分别是如何生成图像的，想要知道图像数据是怎么被消费的，我们需要知道 图像消费者 有哪些，他们又分别是如何消费图像的，想要知道中间经历的步骤和过程，我们需要知道 图像缓冲区 有哪些，他们是如何被创建，如何分配存储空间，又是如何将数据从生产者传递到消费者的，图像显示是一个很经典的消费者生产者的模型，只有对这个模型各个模块的击破，了解他们之间的流动关系，我们才能找到一条更容易的路径去掌握Android图形显示原理。我们看看谷歌提供的官方的架构图是怎样描述这一模型的模块及关系的。

如图， 图像的生产者 主要有MediaPlayer，CameraPrevier，NDK，OpenGl ES。MediaPlayer和Camera Previer是通过直接读取图像源来生成图像数据，NDK（Skia），OpenGL ES是通过自身的绘制能力生产的图像数据； 图像的消费者 有SurfaceFlinger，OpenGL ES Apps，以及HAL中的Hardware Composer。OpenGl ES既可以是图像的生产者，也可以是图像的消费者，所以它也放在了图像消费模块中； 图像缓冲区 主要有Surface以及前面提到帧缓冲。

Android图像显示的原理，会仅仅围绕 图像的生产者 ， 图像的消费者 ， 图像缓冲区 来展开，在这一篇文章中，我们先看看Android系统中的图像消费者。

SurfaceFlinger是Android系统中最重要的一个图像消费者，Activity绘制的界面图像，都会传递到SurfaceFlinger来，SurfaceFlinger的作用主要是接收图像缓冲区数据，然后交给HWComposer或者OpenGL做合成，合成完成后，SurfaceFlinger会把最终的数据提交给帧缓冲。

那么SurfaceFlinger是如何接收图像缓冲区的数据的呢？我们需要先了解一下Layer（层）的概念，一个Layer包含了一个Surface，一个Surface对应了一块图形缓冲区，而一个界面是由多个Surface组成的，所以他们会一一对应到SurfaceFlinger的Layer中。SurfaceFlinger通过读取Layer中的缓冲数据，就相当于读取界面上Surface的图像数据。Layer本质上是 Surface和SurfaceControl的组合 ，Surface是图形生产者和图像消费之间传递数据的缓冲区，SurfaceControl是Surface的控制类。

前面在屏幕图像显示原理中讲到，为了防止图像的撕裂，Android系统会在收到VSync垂直同步时才会开始处理图像的绘制和合成工作，而Surfaceflinger作为一个图像的消费者，同样也是遵守这一规则，所以我们通过源码来看看SurfaceFlinger是如何在这一规则下，消费图像数据的。

SurfaceFlinger专门创建了一个EventThread线程用来接收VSync。EventThread通过Socket将VSync信号同步到EventQueue中，而EventQueue又通过回调的方式，将VSync信号同步到SurfaceFlinger内。我们看一下源码实现。

上面主要是SurfaceFlinger初始化接收VSYNC垂直同步信号的操作，主要有这几个过程：

经过上面几个步骤，我们接收VSync的初始化工作都准备好了，EventThread也开始运转了，接着看一下EventThread的运转函数threadLoop做的事情。

threadLoop主要是两件事情

mConditon又是怎么接收VSync的呢？我们来看一下

可以看到，mCondition的VSync信号实际是DispSyncSource通过onVSyncEvent回调传入的，但是DispSyncSource的VSync又是怎么接收的呢？在上面讲到的SurfaceFlinger的init函数，在创建EventThread的实现中，我们可以发现答案—— mPrimaryDispSync 。

DispSyncSource的构造方法传入了mPrimaryDispSync，mPrimaryDispSync实际是一个DispSyncThread线程，我们看看这个线程的threadLoop方法

DispSyncThread的threadLoop会通过mPeriod来判断是否进行阻塞或者进行VSync回调，那么mPeriod又是哪儿被设置的呢？这里又回到SurfaceFlinger了，我们可以发现在SurfaceFlinger的 resyncToHardwareVsync 函数中有对mPeriod的赋值。

可以看到，这里最终通过HWComposer，也就是硬件层拿到了period。终于追踪到了VSync的最终来源了， 它从HWCompser产生，回调至DispSync线程，然后DispSync线程回调到DispSyncSource，DispSyncSource又回调到EventThread，EventThread再通过Socket分发到MessageQueue中 。

我们已经知道了VSync信号来自于HWCompser，但SurfaceFlinger并不会一直监听VSync信号，监听VSync的线程大部分时间都是休眠状态，只有需要做合成工作时，才会监听VSync，这样即保证图像合成的操作能和VSync保持一致，也节省了性能。SurfaceFlinger提供了一些主动注册监听VSync的操作函数。

可以看到，只有当SurfaceFlinger调用 signalTransaction 或者 signalLayerUpdate 函数时，才会注册监听VSync信号。那么signalTransaction或者signalLayerUpdate什么时候被调用呢？它可以由图像的生产者通知调用，也可以由SurfaceFlinger根据自己的逻辑来判断是否调用。

现在假设App层已经生成了我们界面的图像数据，并调用了 signalTransaction 通知SurfaceFlinger注册监听VSync，于是VSync信号便会传递到了MessageQueue中了，我们接着看看MessageQueue又是怎么处理VSync的吧。

MessageQueue收到VSync信号后，最终回调到了SurfaceFlinger的 onMessageReceived 中，当SurfaceFlinger接收到VSync后，便开始以一个图像消费者的角色来处理图像数据了。我们接着看SurfaceFlinger是以什么样的方式消费图像数据的。

VSync信号最终被SurfaceFlinger的onMessageReceived函数中的INVALIDATE模块处理。

INVALIDATE的流程如下：

handleMessageTransaction的处理比较长，处理的事情也比较多，它主要做的事情有这些

handleMessageRefresh函数，便是SurfaceFlinger真正处理图层合成的地方，它主要下面五个步骤。

我会详细介绍每一个步骤的具体操作

合成前预处理会判断Layer是否发生变化，当Layer中有新的待处理的Buffer帧（mQueuedFrames0），或者mSidebandStreamChanged发生了变化， 都表示Layer发生了变化，如果变化了，就调用signalLayerUpdate，注册下一次的VSync信号。如果Layer没有发生变化，便只会做这一次的合成工作，不会注册下一次VSync了。

重建Layer栈会遍历Layer，计算和存储每个Layer的脏区， 然后和当前的显示设备进行比较，看Layer的脏区域是否在显示设备的显示区域内，如果在显示区域内的话说明该layer是需要绘制的，则更新到显示设备的VisibleLayersSortedByZ列表中，等待被合成

rebuildLayerStacks中最重要的一步是 computeVisibleRegions ，也就是对Layer的变化区域和非透明区域的计算，为什么要对变化区域做计算呢？我们先看看SurfaceFlinger对界面显示区域的分类：

还是以这张图做例子，可以看到我们的状态栏是半透明的，所以它是一个opaqueRegion区域，微信界面和虚拟按键是完全不透明的，他是一个visibleRegion，除了这三个Layer外，还有一个我们看不到的Layer——壁纸，它被上方visibleRegion遮挡了，所以是coveredRegion

对这几个区域的概念清楚了，我们就可以去了解computeVisibleRegions中做的事情了，它主要是这几步操作：

相关问答

Q1: 程序员的开源月刊《HelloGitHub》第 68 期

HelloGitHub 分享 GitHub 上有趣、入门级的开源项目。

这里有实战项目、入门教程、黑 科技 、开源书籍、大厂开源项目等，涵盖多种编程语言 Python、Java、Go、C/C++、Swift...让你在短时间内感受到开源的魅力，对编程产生兴趣！

1、 toybox ：该项目将 200 多个常用的 Linux 命令行工具，做成一个可执行文件。从而可以让 Android 这种原本不支持 Linux 命令的系统，也得以用上 ls、find、ps 等命令。还可以用于快速构建最小的 Linux 环境

2、 the_silver_searcher ：比 ack 更快的命令行搜索工具。速度快、功能强大、使用简单，支持 Linux、Windows、macOS 操作系统，还能够整合进 Vim 和 Emacs 等编辑器

3、 WindTerm ：支持 SSH/Telnet/Serial/Shell/Sftp 的终端工具。虽然该软件完全免费，但部分代码尚未完全开源，对安全敏感的同学可以再观望下

4、 wavefunctioncollapse ：基于波函数坍缩 (WFC) 算法，实现的无限城市示例。城市里有房子、楼梯、树木、连接房屋的通道，你可以在城市中自由移动、跳跃、飞行，但不论你怎么移动都找不到尽头，因为这座城市会无限延伸

5、 NETworkManager ：管理和解决网络问题的工具。它集成了 IP 和端口扫描、WiFi 分析器、跟踪路由、DNS 查询等工具

6、 ppsspp ：能够运行在 Android 和 PC 上的开源 PSP 模拟器

7、 leocad ：用来创建虚拟乐高模型的 CAD 工具。适用于 Windows、Linux 和 macOS 系统

8、 csshake ：用 CSS 实现抖动效果

9、 MangoDB ：真正开源的 MongoDB 替代品。它底层采用 PostgreSQL 作为存储引擎，用 Go 语言实现了 MongoDB 协议，所以几乎兼容所有的 MongoDB 库，迁移起来毫无负担。如果你用不到 MongoDB 的高级功能，还受限于它的开源协议，那么这个项目可作为 MongoDB 的开源替代方案。它才刚刚起步，建议观望一段时间或做足测试再用于生产环境

10、 caddy ：用 Go 编写的轻量级 Web 服务器。它相较于 Apache、Nginx 这些知名 Web 服务器，独特点在于提供了编译好的可执行文件，实现了真正的开箱即用。无需任何配置即可拥有免费的 HTTPS、自动把 Markdown 文件转化成 HTML 等人性化的功能。如果是搭建中小型的 Web 服务，它完全够用而且省时省心

11、 croc ：可以让任意两台计算机，安全方便地传输文件和文件夹的工具。轻松实现端到端加密的跨平台文件传输，还支持多文件传输、传输中断和恢复等功能

12、 jnativehook ：获取键盘和鼠标事件的 Java 库。轻松监听按键、鼠标移动、点击等事件

13、 spider-flow ：用流程图的方式编写爬虫的平台。无需写代码就可以快速完成一个简单的爬虫

14、 greenDAO ：高性能的 Android ORM 库。拥有体积小、易于使用、支持数据库加密等特点，通过它 Android 开发者可以采用面向对象的方式操作数据库，不需要再手写和拼接 SQL 啦

15、 vue-color-avatar ：纯前端实现的矢量风格头像生成网站。可以通过搭配不同的素材，生成个性化头像。该项目使用 Vite + Vue3 开发，能够帮助前端初学者熟悉 Vue3 语法并掌握项目搭建的相关知识

16、 colorfu ：自动生成由文字/颜色/图片/纹理元素组成的壁纸

17、 pm2 ：Node.js 的进程管理工具。它容易上手操作简单，可以有效地提高 Node.js 程序运行的稳定性，支持自动重启、负载均衡、不停服务重启、性能监控等功能，多用于生产环境中管理、监控 Node.js 进程

18、 automa ：通过图形化界面拖拽功能模块，实现浏览器自动操作的扩展工具。轻松实现自动填表、截图、定时执行等操作。让浏览器自动完成预设工作流的插件，从而减少重复性操作提高效率

19、 PyWebIO ：快速构建 Web 应用的 Python 工具。通过该项目你可在不写 HTML、CSS、JS 代码的前提下，仅用 Python 快速完成一个包含数据展示、表单的小型 Web 应用页面

20、 pottery ：以 Python 的方式操作 Redis 的库。忘记那些 Redis 命令吧，只要你知道如何使用 Python 字典，那么你就会用这个库操作 Redis

21、 zulip ：完全开源的企业级即时通讯项目。后端采用 Python 语言实现性能足够强大，功能齐全相当于开源、免费的 Slack，拥有拖拽上传文件、代码高亮、Markdown 语法、应用整合、容易接入的 API 等功能，还支持 Web、PC、iOS 和 Android 主流平台，众多知名企业都在用，能够有效地提高团队沟通和办公效率。同时该项目对新手用户友好，如果你想加入一个不错的 Python 开源项目，推荐你花时间研究下它一定会有所收获

22、 webssh ：简单的 SSH 连接服务器的 Python Web 应用。该项目后端采用 Tornado Web 框架和 Python SSH 库 paramiko，前端是 TypeScript 写的命令行前端组件 Xterm.js 实现。整个项目简单还具有实用价值，可作为 Python Web 的实战项目学习

23、 django-debug-toolbar ：Django 的调试工具栏。可显示当前请求和响应有关的各种调试信息，包括耗时、SQL、配置、性能等信息

24、 hyperfine ：命令行基准测试工具。可用来查看和对比命令的耗时，支持多次运行的统计分析、结果导出等功能

25、 xcode-dev-cleaner ：用于清理各种 Xcode 的缓存数据，释放存储空间。注意是清除 Xcode 缓存数据，不是卸载 Xcode 哈

26、 toml ：更易读和易于维护的配置文件格式。如果你厌倦了 INI 的局限性、层层嵌套的 JSON 和 YAML 令人心惊胆战的缩进语法，不防给 TOML 一个机会，它支持多种数据类型、抛弃了缩进和嵌套，而且众多流行编程语言都有对应的库。TOML 已经足够成熟，绝对值得一试

27、 waka-readme-stats ：自动在 GitHub 个人首页展示编程时长的工具。该项目通过 WakaTime 记录用户在 IDE 的使用时间，统计编程时长和数据，然后采用 GitHub Action 自动获取并动态更新到 GitHub 个人首页。轻而易举地展示自己的编程时长

28、 PathPlanning ：常见的路径规划算法集合。项目包含了 Python 代码实现、运行过程动画以及相关论文

29、 howdy ：为 Linux 系统提供人脸识别解锁电脑的工具。通过电脑内置的摄像头和红外设备，实现了类似 Windows Hello 风格的身份认证，可用于登陆、锁屏、sudo 等任何需要输入密码的地方

30、 The-Open-Book ：开源的电子水墨屏阅读设备。动手能力强的同学可跟着这个项目，从焊电路板开始亲手制作出一个类 Kindle 的 4.2 英寸阅读设备

31、 fl_chart ：Flutter 图表库。它支持折线图、条形图、饼图、散点图和雷达图

32、 ugo-compiler-book ：《从头开发一个迷你 Go 语言》该书教你从头实现迷你 Go 语言，内容包含了词法解析、语法树构建、函数闭包、接口、CGO 的实现等内容

33、 archbase ：教科书《计算机体系结构基础》第三版

34、 spring-in-action-v6-translate ：《Spring 实战第 6 版》中文翻译

35、 best_AI_papers_2021 ：2021 年必看的人工智能论文列表。该项目不是简单的罗列论文，它不仅包含相关论文的代码、效果展示，还有深入的文章和讲解视频。通过学习这些前沿的人工智能论文，提前了解 AI 在未来更多可能性

36、 AnimeGANv2 ：可以将图片和视频转换成漫画风格的工具。采用的是神经风格迁移+生成对抗网络（GAN）的组合，转换速度快

感谢您的阅读，如果觉得内容还不错的话 求赞、求分享 ，您的每一次支持都将让 HelloGitHub 变得更好！

Q2: flutter中的controller是做什么的？

用来控制controller对应widget的各种各样交互行为以及状态变化的控制（类似于widget本身只是一个静态的物品，而通过对controller的操作控制让这个widget活了起来）

Q3: Flutter 启动页的前世今生适配历程

APP 启动页在国内是最常见也是必备的场景，其中启动页在 iOS 上算是强制性的要求，其实配置启动页挺简单，因为在 Flutter 里现在只需要：

一般只要配置无误并且图片尺寸匹配，基本上就不会有什么问题， 那既然这样，还有什么需要适配的呢？

事实上大部分时候 iOS 是不会有什么问题， 因为 LaunchScreen.storyboard 的流程本就是 iOS 官方用来做应用启动的过渡；而对于 Andorid 而言，直到 12 之前 windowBackground 这种其实只能算“民间”野路子 ，所以对于 Andorid 来说，这其中就涉及到一个点：

所以下面主要介绍 Flutter 在 Android 上为了这个启动图做了哪些骚操作～

在已经忘记版本的“远古时期” ， FlutterActivity 还在 io.flutter.app.FlutterActivity 路径下的时候，那时启动页的逻辑相对简单，主要是通过 App 的 AndroidManifest 文件里是否配置了 SplashScreenUntilFirstFrame 来进行判断。

在 FlutterActivity 内部 FlutterView 被创建的时候，会通过读取 meta-data 来判断是否需要使用 createLaunchView 逻辑 ：

是不是很简单，那就会有人疑问为什么要这样做？我直接配置 Activity 的 android:windowBackground 不就完成了吗？

这就是上面提到的时间差问题， 因为启动页到 Flutter 渲染完第一帧画面中间，会出现概率出现黑屏的情况，所以才需要这个行为来实现过渡 。

经历了“远古时代”之后， FlutterActivity 来到了 io.flutter.embedding.android.FlutterActivity ， 在到 2.5 版本发布之前，Flutter 又针对这个启动过程做了不少调整和优化，其中主要就是 SplashScreen 。

自从开始进入 embedding 阶段后， FlutterActivity 主要用于实现了一个叫 Host 的 interface ，其中和我们有关系的就是 provideSplashScreen 。

默认情况下它会从 AndroidManifest 文件里是否配置了 SplashScreenDrawable 来进行判断 。

默认情况下当 AndroidManifest 文件里配置了 SplashScreenDrawable ，那么这个 Drawable 就会在 FlutterActivity 创建 FlutterView 时被构建成 DrawableSplashScreen 。

DrawableSplashScreen 其实就是一个实现了 io.flutter.embedding.android.SplashScreen 接口的类，它的作用就是：

之后 FlutterActivity 内会创建出 FlutterSplashView ，它是个 FrameLayout。

FlutterSplashView 将 FlutterView 和 ImageView 添加到一起， 然后通过 transitionToFlutter 的方法来执行动画，最后动画结束时通过 onTransitionComplete 移除 splashScreenView 。

所以整体逻辑就是：

当然这里也是分状态：

当然这个阶段的 FlutterActivity 也可以通过 override provideSplashScreen 方法来自定义 SplashScreen 。

看到没有，做了这么多其实也就是为了弥补启动页和 Flutter 渲染之间， 另外还有一个优化，叫 NormalTheme 。

通过该配置 NormalTheme ，在 Activity 启动时，就会首先执行 switchLaunchThemeForNormalTheme(); 方法将主题从 LaunchTheme 切换到 NormalTheme 。

大概配置完就是如下样子， 前面分析那么多其实就是为了告诉你，如果出现问题了，你可以从哪个地方去找到对应的点 。

讲了那么多， Flutter 2.5 之后 provideSplashScreen 和 io.flutter.embedding.android.SplashScreenDrawable 就被弃用了，惊不喜惊喜，意不意外，开不开心 ？

通过源码你会发现，当你设置了 splashScreen 的时候，会看到一个 log 警告：

为什么会弃用？

其实这个提议是在 这个 issue 上，然后通过 这个 pr 完成调整。

大概意思就是： 原本的设计搞复杂了，用 OnPreDrawListener 更精准，而且不需要为了后面 Andorid12 的启动支持做其他兼容，只需要给 FlutterActivity 等类增加接口开关即可 。

也就是2.5之后 Flutter 使用 ViewTreeObserver.OnPreDrawListener 来实现延迟直到加载出 Flutter 的第一帧。

为什么说默认情况？ 因为这个行为在 FlutterActivity 里，是在 getRenderMode() == RenderMode.surface 才会被调用，而 RenderMode 又和 BackgroundMode 有关心 。

所以在 2.5 版本后， FlutterActivity 内部创建完 FlutterView 后就会执行一个 delayFirstAndroidViewDraw 的操作。

这里主要注意一个参数： isFlutterUiDisplayed 。

当 Flutter 被完成展示的时候， isFlutterUiDisplayed 就会被设置为 true。

所以当 Flutter 没有执行完成之前， FlutterView 的 onPreDraw 就会一直返回 false ，这也是 Flutter 2.5 开始之后适配启动页的新调整。

看了这么多，大概可以看到其实开源项目的推进并不是一帆风顺的，没有什么是一开始就是最优解，而是经过多方尝试和交流，才有了现在的版本，事实上开源项目里，类似这样的经历数不胜数：

Q4: 25.Flutter的ListView监听滚动事件之ScrollController

对于滚动的视图，我们经常需要监听它的一些滚动事件，在监听到的时候去做对应的一些事情。

比如视图滚动到底部时，我们可能希望做上拉加载更多；

比如滚动到一定位置时显示一个回到顶部的按钮，点击回到顶部的按钮，回到顶部；

比如监听滚动什么时候开始，什么时候结束；

在Flutter中监听滚动相关的内容由两部分组成：ScrollController和ScrollNotification。

ScrollController

在Flutter中，Widget并不是最终渲染到屏幕上的元素（真正渲染的是RenderObject），因此通常这种监听事件以及相关的信息并不能直接从Widget中获取，而是必须通过对应的Widget的Controller来实现。

ListView、GridView的组件控制器是ScrollController，我们可以通过它来获取视图的滚动信息，并且可以调用里面的方法来更新视图的滚动位置。

另外，通常情况下，我们会根据滚动的位置来改变一些Widget的状态信息，所以ScrollController通常会和StatefulWidget一起来使用，并且会在其中控制它的初始化、监听、销毁等事件。

我们来做一个案例，当滚动到1000位置的时候，显示一个回到顶部的按钮：

jumpTo(double offset)、animateTo(double offset,...)：这两个方法用于跳转到指定的位置，它们不同之处在于，后者在跳转时会执行一个动画，而前者不会。

ScrollController间接继承自Listenable，我们可以根据ScrollController来监听滚动事件。