书名：Flutter内核源码剖析
ISBN：978-7-115-57546-3
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
著 赵 裕
责任编辑 秦 健
人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
网址 http://www.ptpress.com.cn
读者服务热线：(010)81055410
反盗版热线：(010)81055315
本书系统介绍Flutter跨平台技术的底层原理，横跨Java、C++、Dart 3种编程语言，可以帮助程序员学习前沿的跨平台技术，编写高质量的代码，深刻理解Flutter的内部运行机制。
本书共11章。第1章～第3章讲解阅读Flutter内核源码的前置知识，如何获取和构建源码，以及Dart的高级特性等。第4章～第7章讲解Flutter内核源码的核心内容，涉及Embedder层、Engine层、Framework层等。第8章～第11章基于对Flutter内核源码的分析，探讨如何编写高性能的业务代码，定位代码中的性能瓶颈，使用DevTool等工具的高阶特性，以及底层原理等高级主题。
本书适合对跨平台技术感兴趣的开发人员、前端开发人员、Android/iOS开发人员，希望深入了解Flutter或有性能调优需求的开发人员，对移动端渲染框架感兴趣的开发人员，以及渴望深入了解Flutter底层实现的开发人员阅读。
我因为工作调动才开始全面接触Flutter。在最初的几个月里，我便被Flutter新颖的思路和优良的设计所吸引。但是，作为一个面世才几年且处于快速发展中的框架，对Flutter源码进行剖析的资料实在是稀少而零散。因此，我便萌生了系统研究Flutter源码并以此为内容编写本书的想法。
编写本书一方面是为了在工作上更加得心应手。《庄子·养生主》中讲了一个庖丁解牛的故事，庖丁因为了解了牛的全貌，才能够“恢恢乎其于游刃必有余地矣”。日常开发也是如此。如果对于一门技术的了解下达源码底层、上通设计架构，那么便不会再有解不了的Bug、做不出的需求。如此，可得工作的“养生”之道。
编写本书另一方面也是为了实现自己作为一名技术人员的价值追求。在大学期间，我读过一本书——《早晨从中午开始》，这本书中的一段话一直激励着我不要安于现状，在此分享给每一个有机缘看到本书的人：“是的，只要不丧失远大的使命感，或者说还保持着较为清醒的头脑，就决然不能把人生之船长期停泊在某个温暖的港湾，应该重新扬起风帆，驶向生活的惊涛骇浪中，以领略其间的无限风光。人，不仅要战胜失败，而且还要超越胜利。”
本书采用图解、文字、代码三者结合的方式，全景式地展现了Flutter的底层细节，既可以帮助技术人员系统地掌握Flutter的原理，又可以助力日常开发，帮助开发者写出高质量的代码。
本书并不是一本Flutter的入门书籍，适用的读者人群如下。
本书共11章，虽然每章之间不存在绝对的依赖关系，但仍建议读者按照顺序阅读。每章核心内容及难度如下。
第1章介绍了跨平台发展的历史，属于概念类知识，篇幅不多，难度不大。
第2章介绍了Flutter源码的获取、结构、构建与调试，强烈建议读者动手实践，以获得更深刻的认知。
第3章介绍flutter tool的几个常用命令，虽然和其他章节没有联系，但是日常开发中需要经常涉及这几个命令，建议读者掌握。
第4章介绍了Flutter应用启动的完整流程。第5章介绍了Flutter界面渲染的关键步骤。这两章篇幅较大、难度较大，是本书的核心内容，建议反复阅读以加深理解。
第6章和第7章分别介绍了Flutter中的Box布局和Sliver布局，这部分内容是对第5章的重要补充，也是日常开发中最常接触的部分。这两章仅选取了最具代表性的Widget进行分析，建议读者在此基础上扩展分析自己感兴趣的组件。
第8章介绍了Framework中的其他关键内容，例如动画、手势、路由等，这些都是日常开发中频繁接触的内容，虽然颇有难度，但对于普通开发者至关重要，建议仔细研读掌握。
第9章介绍了调用平台原生能力的底层原理，如果开发者需要频繁接触Add to APP的场景，建议重点掌握该章。
第10章介绍了Engine的两个核心机制，理解它们对于日常开发没有直接的收益，但对于理解前面诸多章节的逻辑大有裨益，建议读者认真阅读掌握。
第11章介绍了两个实践案例，难度不大，但从不同的角度能得到不同的启示，建议读者自行思考解决方案并对比本书给出的解决方案。
本书比较适合有一定Flutter开发基础的读者，不适合作为Flutter入门书籍。此外，本书章节前后引用颇多，涉及的领域也较多，建议读者先按照顺序阅读。
代码印刷出来后可读性会降低，建议读者按照第2章的流程，下载源码，在IDE（Integrated Development Environment，集成开发环境）中阅读源码，在缩进和高亮等功能的帮助下，以获得更好的阅读体验。此外，为了节省篇幅，书中删除了大量的非核心代码（比如日志），因此，读者请自行下载源码，将其作为阅读本书的辅助工具。
需要注意的是，本书的类图、时序图并没有严格遵循统一建模语言（Unified Modeling Language，UML）的规范，而是以表明问题的核心和本质作为第一要义，做了适当精简。
当阅读完本书后，相信读者已经掌握了Flutter世界本质、基础的知识。接下来要做的事情就是在实践中锻炼自己、检验知识，并输出自己的心得。
由于作者的水平有限，编写时间仓促，书中难免会出现一些疏漏之处，恳请读者批评指正。如果你有更多的宝贵意见，欢迎发送邮件至邮箱vimerzhao@gmail.com，期待能够得到你们的真挚反馈。
感谢我大一期间的辅导员冷闯和时任大连理工大学教务处处长的张维平老师，是他们认真负责的工作态度，帮助我解决了转专业过程中遇到的困难，我因此可以在自己感兴趣的领域充实地度过大学时光。
感谢IP和甘爷，是他们在校园招聘中发掘并录用了我，让我有机会从大连来到深圳，并在腾讯这样一家优秀的公司实习。
感谢lorry老师和加淼老师，是他们在我实习期间给予了充分的帮助，我因此得以成功转正。
感谢lorry老师、jim老师和光子老师，是他们积极招募并给予我充分的发挥空间，我因此可以在这半年内全身心地投入与Flutter相关的工作中。
感谢过去两年半在应用宝移动平台、移商团队、微视前端技术中心共事的领导和同事，他们是我在技术上的良师益友，对我的成长进步给予了很多帮助。
感谢人民邮电出版社的编辑秦健老师，他在我过去半年的写作中给予了专业的指导和建议。
赵裕
2021年9月
本书由异步社区出品，社区（https://www.epubit.com/）为您提供相关资源和后续服务。
作者和编辑尽最大努力来确保书中内容的准确性，但难免会存在疏漏。欢迎您将发现的问题反馈给我们，帮助我们提升图书的质量。
当您发现错误时，请登录异步社区，按书名搜索，进入本书页面，单击“提交勘误”，输入勘误信息，单击“提交”按钮即可，如右图所示。本书的作者和编辑会对您提交的勘误进行审核，确认并接受后，您将获赠异步社区的100积分。积分可用于在异步社区兑换优惠券、样书或奖品。
我们的联系邮箱是contact@epubit.com.cn。
如果您对本书有任何疑问或建议，请您发邮件给我们，并请在邮件标题中注明本书书名，以便我们更高效地做出反馈。
如果您有兴趣出版图书、录制教学视频，或者参与图书翻译、技术审校等工作，可以发邮件给我们；有意出版图书的作者也可以到异步社区投稿（直接访问www.epubit.com/contribute即可）。
如果您所在的学校、培训机构或企业想批量购买本书或异步社区出版的其他图书，也可以发邮件给我们。
如果您在网上发现有针对异步社区出品图书的各种形式的盗版行为，包括对图书全部或部分内容的非授权传播，请您将怀疑有侵权行为的链接通过邮件发送给我们。您的这一举动是对作者权益的保护，也是我们持续为您提供有价值的内容的动力之源。
“异步社区”是人民邮电出版社旗下IT专业图书社区，致力于出版精品IT图书和相关学习产品，为作译者提供优质出版服务。异步社区创办于2015年8月，提供大量精品IT图书和电子书，以及高品质技术文章和视频课程。更多详情请访问异步社区官网https://www.epubit.com。
“异步图书”是由异步社区编辑团队策划出版的精品IT专业图书的品牌，依托于人民邮电出版社几十年的计算机图书出版积累和专业编辑团队，相关图书在封面上印有异步图书的LOGO。异步图书的出版领域包括软件开发、大数据、人工智能、测试、前端、网络技术等。
异步社区
微信服务号
本章首先回顾移动端跨平台技术的发展史，其次介绍Flutter的前世今生，最后分析Flutter的运行原理。虽然本书的主要内容是剖析Flutter的源码，但了解这些背景知识，有助于我们对Flutter的底层设计有一个更深刻的认识。
2007年，苹果公司推出了iPhone第一代，其搭载的iPhone OS 1.0即iOS系统的前身。2008年，谷歌公司也推出了其酝酿已久的智能手机操作系统Android 1.0。也就是在这一年的8月，PhoneGap诞生了。经过几年的发展，塞班逐渐退出了历史的舞台，iOS和Android瓜分了移动端的市场份额。至于跨平台技术的历史，则要从和iOS、Android一起诞生的PhoneGap说起。
PhoneGap诞生的原因是一名程序员认为Objective-C的语法过于生硬晦涩，而Web技术已经在PC端取得巨大成功，JavaScript也拥有更多的开发者和社区资源，PhoneGap就这样诞生了。虽然PhoneGap的初衷只是“为跨越Web技术和iPhone之间的鸿沟牵线搭桥”，但是，正如Web浏览器实现了PC端的跨平台一样，可以说PhoneGap为日后的跨平台技术开了先河。
从2010年至今，智能手机替代PC成为主要的互联网服务提供平台，移动端跨平台技术的价值也日渐凸显。在传统的开发模式中，一个产品需求的上线需要Android和iOS双端都进行人力投入，但是开发的却是同样的功能。而且即使是同样的功能，也存在着以下问题。
由此可见，Android和iOS的共同存在让技术团队需要双倍甚至更高的投入，才能覆盖到所有用户。但是平台多样化是市场自由竞争的结果，也是开发人员无法改变而只能主动适应的局面。跨平台技术正是适应这一局面的理想切入点。从技术上来说，跨平台技术在理想状态下可以一次开发、多端运行，有助于产品需求的快速上线，降低了开发人员的人力投入和后续维护成本。从用户体验上来说，跨平台技术可以保证用户在任一平台都获得一致的视觉和交互体验，降低了迁移的成本。从商业价值上来说，跨平台技术就是构筑在操作系统上的二级生态，例如Java借助JVM（Java Virtual Machine，Java虚拟机）的跨平台能力，建立了庞大的技术生态，而微信小程序则借助WebView的跨平台能力，建立了自己的产品生态。
某种意义上，跨平台有着超越其自身技术价值的更大价值：创建生态、引领趋势。因此，脸书公司和谷歌公司先后发力，试图占领这块高地。
移动端是互联网最重要的服务入口，而跨平台技术无论是从提高开发效率还是扩展商业版图上来说，都蕴含着无限的机会，因此也成为科技巨头的必争之地。本节将按照时间顺序，梳理跨平台技术发展的3个阶段。从技术上来说，跨平台技术要解决的问题有两个。
下面将按照时间顺序回顾跨平台演进的3个阶段，以及每个阶段对于以上两个问题的解决方式。
在移动端跨平台技术中，Hybrid指的是同时使用Web和Native（Native指代Android或者iOS平台）技术栈进行混合开发的模式。在Hybrid阶段，比较有代表性的方案是Cordova，PhoneGap由于其商业产品的属性，无法直接为开源社区所用，Cordova可以认为是PhoneGap的开源版本。
下面具体分析Cordova的核心原理。Android和iOS中都搭载有浏览器内核，Cordova以Web技术为基础，实现了与平台无关的UI渲染。而对于Native能力的调用，Android和iOS都会提供JS Bridge接口，因此可以调用原生的各种能力。具体运行原理如图1-1所示。
这个方案的实现成本并不大，但是Web的渲染性能较Native差，而且移动端设备的计算能力比起PC端更是捉襟见肘，因此Hybrid方案在用户体验上大打折扣。相较于PC设备CPU算力充足、网络环境稳定的情况，移动端设备（尤其是早期）往往存在算力有限、网络波动较大等客观情况，而用户体验和商业回报是直接挂钩的。试想一下，如果一个页面从进入到渲染完成需要1s会有多少用户退出？需要3s又会有多少用户退出？当然，Web之所以放弃了一部分性能，也是有原因的：一是为了能动态提供服务；二是为了提供更有表现力的UI（得益于CSS的出现）。在PC端算力充足、网络稳定的前提下，这种设计是利大于弊的，但是在移动端则不然。此外，Web容器还有一个致命问题。PC端的屏幕一般比较大，可以容纳足够的信息，而移动端屏幕大小有限，因而对列表的滑动响应速度和渲染效率要求高，Native的UI框架一般会有针对性的优化，比如Android的RecyclerView，而Web在设计之初就没有考虑这种问题。
图1-1 Hybrid方案运行原理
注意
为什么Web的渲染性能较Native差？作者认为原因主要有两点：一是Web需要动态解析并执行JavaScript（下称JS）脚本（不考虑网络下载时间），而Native的代码往往是已经编译优化过的字节码，甚至是AOT处理过的机器码，因而执行效率更高；二是Web的布局更加复杂，导致渲染一帧需要多次遍历UI组件树，而Native的布局模型有所约束（如Android的LinearLayout只支持线性布局），效率更高。
在Hybrid阶段，除了Cordova外，还有Xamarin、Ionic等框架，可谓百家争鸣。但是，由于Web容器在渲染性能上的固有缺陷，这些方案并没有在用户量巨大的商业APP中广泛应用，因为它们对性能有着更极致的追求。也就是在这种大背景下，脸书公司的React Native于2015年横空出世，当各种Hybrid方案缓过神来时，才发现对面已经站着一个光芒四射的巨人。React Native如其名字所昭示的，有两大特点：一是在框架层面支持前端领域非常流行的React模式；二是放弃低效的Web容器渲染，将上层的UI组件树最终转换为Native平台的原生组件进行渲染。
这个方案看起来十分诱人，对于开发者，React Native保留了完整的前端开发体验；对于用户，React Native通过转换为原生组件保证了Native一致的渲染效率。与这种方案思想类似的也有不少，但知名度和开发者生态均相距甚远，作者将这些方案统一命名为OEM（Original Equipment Manufacturer）方案，因为它们都是在Native的原生组件基础上做了一层包装，进而对开发者屏蔽了平台细节，其核心原理如图1-2所示。
图1-2 OEM方案的核心原理
然而，在2018年6月，爱彼迎公司宣布放弃React Native，主要原因是虽然React Native描绘的跨平台愿景很美好，但是对于很多场景，仍然需要开发者自己去处理平台差异带来的底层细节，如果一个组件React Native没有实现，那么开发者需要自行封装。
显然React Native没有做到彻底的跨平台。
也许是历史的巧合，在2015年React Native以革命者的姿态出现在开源社区时，一位名叫Eric Seidel的谷歌公司的工程师在同年的Dart开发者峰会（Dart Developer Summit）上演示了一个基于代号为Sky的框架开发的App，这在当时并未引起多少人的注意。不知是历史的巧合还是有意而为之，在3年后，曾经意气风发的React Native被爱彼迎公司宣布弃用时，曾经的Sky项目早已改头换面，并在2018年年底发布了1.0的稳定版本，名为Flutter。Flutter和之前所有跨平台技术的不同之处在于自己借助Skia渲染引擎，实现了一套与平台无关的渲染系统，从根本上解决了平台差异导致的一系列问题。自此，跨平台技术进入了第3个阶段——自渲染阶段。而这一次，执牛耳者从脸书公司变成谷歌公司。Flutter的核心之处在于完全接管了UI组件从使用到渲染的全流程，以此根除平台的差异。而对于原生能力的调用，Flutter提供的Platform Channel和JS Bridge并没有本质区别。自渲染方案的核心原理如图1-3所示。
从某种意义上来说，Flutter其实还是基于Hybrid的思想，只是它的渲染框架更适合移动端，而Flutter的核心开发者Eric Seidel在一次采访中也表示，Flutter的灵感来源于一次对浏览器内核精简后的性能测试结果。
图1-3 自渲染方案的核心原理
注意
其实早在Flutter之前，Qt就已经开始了在移动端通过自渲染方式开发跨平台的App的探索，但最后并没有像在PC端那样获得成功，作者认为主要有以下原因。
从2018年到2021年，Flutter的社区蓬勃发展、生态日益完善，虽然Flutter不一定是跨平台技术的最终答案，但是其已经是跨平台发展道路上的一个重要里程碑。图1-4展示了跨平台技术发展的3个阶段中最具代表性的框架在GitHub上的Star（标星）数目对比，可以看出新一代的方案总是能完成对上一代的反超，而当前Flutter已经是大势所趋，本书后面将抽丝剥茧，与读者共飨跨平台技术的最新成果。
图1-4 三大主流跨平台框架的GitHub标星数目对比
仔细分析图1-4可以发现以下信息。
图1-4也完美总结了1.1.3节关于跨平台演进的介绍，每一次线条的交汇都意味着一次技术的突破。由图1-4也可以看出，Flutter无疑代表着当前最受关注、最有希望到达跨平台彼岸的技术。接下来，我们将初步了解Flutter框架。
Flutter在设计之初的目标是成为一个能够在直接和系统底层服务交互的同时，又可在不同平台间代码尽可能复用的高性能UI工具集。基于此，Flutter的目标自然有两个：一是让开发者能够进行高效开发；二是让用户能够获得高性能的体验。为此，Flutter APP在开发期间会运行在Dart VM（以JIT方式运行）上，让开发者使用热重载技术获得代码的即时反馈，而在Flutter APP正式发布时，则会预编译成二进制文件，运行在Dart Precompile（只包括GC等必要功能）上，以获取最佳的性能。此外，Flutter还有一套高效的渲染系统，以保证足够的性能。而这一切是如何实现的呢？下面将逐一了解。
Flutter在软件设计上是一个可灵活扩展的分层架构，Flutter的每个功能组件都以库的形式存在，每个库都依赖于其下一层的库，如图1-5所示。
图1-5 Flutter分层架构
Flutter这样设计的好处是让框架的每一个组件都变得可插拔、可替换。作为一个跨平台框架，这对复用和移植到其他平台非常合适。
注意
相信读者对图1-5有一种似曾相识的感觉，其实Android的架构图乃至OSI网络模型的架构图和Flutter的分层架构设计如出一辙。《UNIX编程艺术》一书对这种设计给出了一个贴切的称呼：正交性。由于正交性的存在，Android才会有层出不穷的定制ROM，OSI才会有各有千秋的协议（如传输层的TCP与UDP）。
下面自底向上地分析Flutter的每一层。Embedder顾名思义是将Flutter嵌入到Native平台，例如Android、iOS，乃至Linux、Windows。Embedder的职责是为渲染UI到Surface、处理单击事件等与底层平台交互的行为提供一个入口。Embedder使用的编程语言取决于具体平台，对Android来说，通常是C++和Java。
Engine是Flutter的核心部分，大部分代码由C++构成。Engine的主要职责是为Flutter合成并渲染屏幕数据，并为此提供了一系列底层基础能力，包括图形绘制（通过Skia）、文字渲染、文件和网络I/O、无障碍支持、平台插件、Dart运行时管理和编译期工具链等。Engine的主要功能通过dart:ui模块和Framework进行双向交互。
通常来说，开发者不需要感知到Engine和Embedder的存在（如果不需要调用平台的系统服务），Framework是开发者需要直接交互的，因而也在整个分层架构模型的最上层。Framework由Dart语言开发，提供了一套现代的、响应式的UI框架，Framework本身也是分层的，自底向上的角色及功能介绍如下。
Flutter受React影响颇深，采用了声明式的UI写法。客户端开发人员已经习惯了命令式的UI写法，一开始可能很不适应Flutter的开发方式，但React思想已经在前端取得了巨大成功，而Flutter作为一个先进的UI开发框架，自然要摆脱命令式的桎梏，引入更先进的开发理念。
既然Flutter使用了React思想，那自然离不开Virtual DOM，扮演这个角色的正是Widget。在Flutter中，可以说万事万物皆Widget。哪怕一个居中的能力，在传统的命令式UI开发中，通常会以一个属性的方式进行设置，而在Flutter中则抽象成一个名为Center的组件。此外，Flutter提倡激进式的组合开发，即尽可能通过一系列基础的Widget构造出你的目标Widget。基于以上两个特点，可以预见Flutter的代码中将充斥着各种Widget，每一帧UI的更新都意味着部分Widget的重建。读者可能会担心，这种设计十分臃肿和低效，其实恰恰相反，这正是Flutter能够进行高性能渲染的基石。Flutter之所以要如此设计也是基于以下两点事实有意而为之。
第5章剖析渲染管道时，读者可以更深刻地体会到Flutter在Framework层面对响应式的支持。
在讨论渲染管道（Rendering Pipeline）之前，首先了解Flutter中的3棵树模型（实际上还有一棵Layer Tree，但由于过于底层，一般不纳入讨论）。Flutter的3棵树模型示意如图1-6所示。
图1-6 Flutter的3棵树模型示意
Widget Tree是开发者能够直接感知到的，但其最终形态和代码会有一些差异，因为部分Widget本身就是由其他Widget构成的。图1-6中Widget Tree的ColoredBox等Widget，虽然开发者没有直接使用，但却存在于最终的Widget Tree中，关于Widget的结构将在第5章详细剖析。每个Widget都会有对应的Element，并存在一棵对应的Element Tree。实际上Element Tree才是内存中真实存在的数据，Widget Tree和Render Tree都是由Element Tree驱动生成的。正是由于这种机制，Element Tree扮演了Flutter中Virtual DOM的管理者角色。Element Tree中，RenderObjectElement类型的节点会产生RendnerObject，并构成最终的Render Tree。对开发者来说，Render Tree是最底层的UI描述，但对Engine来说，Render Tree是Framework对UI最上层、最抽象的描述。
任何一个UI框架，无论是Web还是Android，都会有自己的渲染管道，渲染管道是UI框架的核心，负责处理用户的输入、生成UI描述、栅格化绘制指令、上屏最终数据等。Flutter也不例外。由于采用了自渲染的方式，Flutter的渲染管道是独立于平台的。以Android为例，Flutter只是通过Embedder获取了一个Surface或者Texture作为自己渲染管道的最终输出目标。具体来说，Flutter的渲染管道分为以下7个步骤。
（1）用户输入（User Input）：响应用户通过鼠标、键盘、触摸屏等设备产生的手势行为。
（2）动画（Animation）：基于计时器（Timer）更新当前帧的数据。
（3）构建（Build）：三棵树的创建、更新与销毁阶段，StatelessWidget和State的build方法将在该阶段执行。
（4）布局（Layout）：Render Tree将在这个阶段完成每个节点的大小和位置的计算。
（5）绘制（Paint）：Render Tree遍历每个节点，生成Layer Tree，RenderObject的paint方法将在该阶段执行，生成一系列绘制指令。
（6）合成（Composition）：处理Layer Tree，生成一个Scene对象，作为栅格化的输入。
（7）栅格化（Rasterize）：将绘制指令处理为可供GPU上屏的原始数据。
在以上7个步骤中，用户输入和动画是相对独立的逻辑，一些简单的静态UI不需要处理用户输入，也不需要展示动画，本书将在第8章详细介绍。构建、布局和绘制直接关系到Flutter 3棵树的维护和使用，是Framework的核心功能之一，是深刻理解Flutter底层工作机制的关键所在，本书将在第5章详细剖析。合成和栅格化负责绘制指令的最终消费，主要逻辑在Engine中，本书也将稍加介绍。
注意
本书所讨论的渲染管道是广义的渲染管道，在一些图形学领域，渲染管道则被分成应用、几何、栅格化3个大阶段以及诸多小阶段，并且细节也更侧重于图形学领域。作为一本剖析Flutter源码的书籍，本书侧重点会有所不同：将重点分析3棵树的生成、维护和消费。
虽然Flutter可以做到脱离平台的原生组件自渲染，但是仍然无法摆脱平台而独立存在。以Android为例，Flutter页面通常绘制在FlutterView上，而FlutterView又是FlutterActivity的一部分，所以一个Flutter页面和一个普通的Activity其实没什么两样，第4章将详细分析Flutter的启动流程，在此过程中读者将更深刻地了解Flutter是如何嵌入平台的。
除了被平台启动，Flutter还需要和平台做一些特定的交互，比如调用平台的方法、获取页面的生命周期回调等。对于一些视频、地图组件，其通常只提供了平台特定的SDK，因而Flutter无法使用，Platform View的出现便是为了解决这一问题，它提供了一种机制，可以在一个Flutter页面中渲染平台原生组件。第9章将详细剖析平台交互的底层原理和实现。
“以史为镜，可以知兴替。”本章首先介绍了移动端跨平台技术的发展史，并在此基础上分析出Flutter乃是下一阶段跨平台领域的大势所趋。其次，1.2节提纲挈领地介绍了Flutter框架核心的技术点，更进一步的剖析将在后续章节逐渐展开。
