-
研发效率:最大化代码复用,减少多端差异的适配工作量,降低开发成本,专注业务开发,实现“write once,run everywhere”的终极目标。效率提升是贯穿整个业务的生命周期线,即便业务上线后,可持续降低后续的维护成本,加快新feature的迭代速度,这是一个持续的效率收益。当然,这里不得不说,任何一门新技术在开发启动学习阶段会有一些成本,但上手后的收益是长期的。
-
动态化:突破渠道的更新频率,可快速迭代新功能,这一点不仅是跨平台技术的诉求,也是Native技术必备的杀手锏,这也是评估跨端技术的一个重要考核点。
-
多端一致性:好产品在多端UI设计上,往往是整体风格统一,所以业务方采用原生各自独立开发完成后,还需额外花不少时间来修改UI以保证多端一致性;可见,各端独立实现开发方式,带来的效率滞后,不仅仅是Android和iOS各开发一份代码的工作量,还有双端UI的一致性对齐的工作。
-
性能体验:一般地,跨端技术方案拥有以上多重优势,但在性能方面比原生流畅更差些。牺牲部分体验换来效率提升,这一点也是情理之中,试想一下,跨平台技术方案同时兼得这4点,那么原生技术恐怕已退出历史舞台,早已是跨平台技术的天下,所以往往跨平台技术的性能优劣便成为核心指标。
-
Web技术:主要依赖于WebView的技术,功能支持受限,性能体验很差,比如PhoneGap、Cordova、小程序。
-
原生渲染:使用JavaScript作为编程语言,通过中间层转化为原生控件来渲染UI界面,比如React Native、Weex。
-
自渲染技术:自行实现一套渲染框架,可通过调用skia等方式完成自渲染,而不依赖于原生控件,比如Flutter、Unity。
-
第一阶段,采用WebView技术绘制界面的Hybrid混合开发技术,通过JS Bridge 将系统部分能力暴露给 JS 调用,其缺点是性能较差,功能受限,扩展性差,不适合交互复杂的场景,比如Cordova。
-
第二阶段,针对WebView界面性能等问题,于是绘制交还原生渲染,仅仅通过JS调用原生控件,相比WebView技术性能体验更好,这是目前绝大部分跨平台框架的设计思路,比如React Native、Weex。另外,最近小程序也比较火,第一和第二阶段的融合,依然采用WebView作为渲染容器,通过限制Web技术栈的子集,规范化组件使用,并逐步引入原生控件代表WebView渲染,以提升性能。
-
第三阶段,虽然通过桥接技术使用原生控件解决了功能受限问题,提升性能体验,但相比原生体验差距还是比较大,以及处理平台差异性非常耗费人力。于是Flutter提出自带渲染引擎的解决方案,尽可能减少不同平台间的差异性, 同时媲美原生的高性能体验,因此业界对 Flutter有着极高的关注度。
-
高效率:采用dart语言编写代码,虽然刚开始上手需要点时间,但熟练后效率比较高。一套代码适用多个平台(Android、iOS、Web),以及高效的Hot Reload能快速辅助调试;
-
动态化:2017年3月苹果下发警告邮件,禁止JSPatch等 iOS App热更新方案,从此iOS动态化成为一个不宜公开讨论的话题。同样地,Flutter引擎在某一个官方版本对动态化做过一些尝试,但后续基于风险考虑移除,当然并没有阻碍大家对技术的探索,这里不方便展开讨论;
-
高一致性:实现UI像素级的控制,Flutter渲染引擎依靠跨平台Skia图形库来实现,仅依赖系统图形绘制相关的接口,比如未来Android会支持vulkan,iOS会支持metal,这些都是通过skia封装调用。可最大程度上保证不同平台的体验一致性,见下图所示。
-
高性能:渲染性能优于现有的各种跨平台框架,可媲美原生性能的跨平台技术方案,Dart代码执行效率比JS高,通过AOT编译成平台原生代码,渲染采用自渲染skia方案,既不需要JS Bridge桥接,也不需要Art虚拟机参与。再从渲染原理来看看Flutter的高性能的底气在哪里。
-
Android原生框架,通过调用Java Framework层,再调用到skia来渲染界面;
-
其他跨平台方案(如RN),通过JSBridge中间层来将JS写的APP转换成相应的原生渲染逻辑,可见比Native代码增加了更多逻辑,性能逊色差于原生框架;
-
Flutter框架,APP通过调用Dart Framework层,再直接调用到skia来渲染界面,并没有经过原生Framework过程,可见其渲染性能并不会弱于Native技术,这是一个性能上限很高的跨平台技术。
-
Flutter Framework层:用Dart编写,封装整个Flutter架构的核心功能,包括Widget、动画、绘制、手势等功能,有Material(Android风格UI)和Cupertino(iOS风格)的UI界面, 可构建Widget控件以及实现UI布局。
-
Flutter Engine层:用C++编写,用于高质量移动应用的轻量级运行时环境,实现了Flutter的核心库,包括Dart虚拟机、动画和图形、文字渲染、通信通道、事件通知、插件架构等。引擎渲染采用的是2D图形渲染库Skia,虚拟机采用的是面向对象语言Dart VM,并将它们托管到Flutter的嵌入层。shell实现了平台相关的代码,比如跟屏幕键盘IME和系统应用生命周期事件的交互。不同平台有不同的shell,比如Android和iOS的shell。
-
FlutterActivity.java的onCreate过程,通过FlutterJNI的AttachJNI()方法来初始化引擎Engine、Dart虚拟机、Isolate、taskRunner等对象。再经过层层处理最终调用main.dart中main()方法,执行runApp(Widget app)来处理整个Dart业务代码。
-
Flutter引擎启动中会创建有4个TaskRunner以及创建虚拟机,分别来看看它们的工作原理。
-
Step 1: 检查task,当task队列不为空,先执行一个task;
-
Step 2: 检查microTask,当microTask不为空,则执行microTask;不断循环Step 2 直到microTask队列为空,再回到执行Step 1。
-
Platform Task Runner:运行在Android或者iOS的主线程,尽管阻塞该线程并不会影响Flutter渲染管道,平台线程建议不要执行耗时操作;否则可能触发watchdog来结束该应用。比如Android、iOS都是使用平台线程来传递用户输入事件,一旦平台线程被阻塞则会引起手势事件丢失。
-
UI Task Runner: 运行在ui线程,比如1.ui,用于引擎执行root isolate中的所有Dart代码,执行渲染与处理Vsync信号,将widget转换生成Layer Tree。除了渲染之外,还有处理Native Plugins消息、Timers、Microtasks等工作;
-
GPU Task Runner:运行在gpu线程,比如1.gpu,用于将Layer Tree转换为具体GPU指令,执行设备GPU相关的skia调用,转换相应平台的绘制方式,比如OpenGL, vulkan, metal等。每一帧的绘制需要UI Runner和GPU Runner配合完成,任何一个环节延迟都可能导致掉帧;
-
IO Task Runner:运行在io线程,比如1.io,前3个Task Runner都不允许执行耗时操作,该Runner用于将图片从磁盘读取出来,解压转换为GPU可识别的格式后,再上传给GPU线程。为了能访问GPU,IO Runner跟GPU Runner的Context在同一个ShareGroup。比如ui.image通过异步调用让IO Runner来异步加载图片,该线程不能执行其他耗时操作,否则可能会影响图片加载的性能。
-
isolate堆是运该isolate中代码分配的所有对象的GC管理的内存存储;
-
vm isolate是一个伪isolate,里面包含不可变对象,比如null,true,false;
-
isolate堆能引用vm isolate堆中的对象,但vm isolate不能引用isolate堆;
-
isolate彼此之间不能相互引用;
-
每个isolate都有一个执行dart代码的Mutator thread,一个处理虚拟机内部任务(比如GC, JIT等)的helper thread;可见,isolate是拥有内存堆和控制线程,虚拟机中可以有很多isolate,但彼此之间内存不共享,无法直接访问,只能通过dart特有的Port端口通信;isolate除了拥有一个mutator控制线程,还有一些其他辅助线程,比如后台JIT编译线程、GC清理/并发标记线程。
-
StatelessWidget:内部没有保存状态,UI界面创建后不会发生改变;
-
StatefulWidget:内部有保存状态,当状态发生改变,调用setState()方法会触发StatefulWidget的UI发生更新,对于自定义继承自StatefulWidget的子类,必须要重写createState()方法。
-
Widget是为Element描述需要的配置, 负责创建Element,决定Element是否需要更新。Flutter Framework通过差分算法比对Widget树前后的变化,决定Element的State是否改变。当重建Widget树后并未发生改变, 则Element不会触发重绘,则就是Widget树的重建并不一定会触发Element树的重建。
-
Element表示Widget配置树的特定位置的一个实例,同时持有Widget和RenderObject,负责管理Widget配置和RenderObject渲染。Element状态由Flutter Framework管理, 开发人员只需更改Widget即可。
-
RenderObject表示渲染树的一个对象,负责真正的渲染工作,比如测量大小、位置、绘制等都由RenderObject完成。
-
Animate: 遍历_transientCallbacks,执行动画回调方法;
-
Build: 对于dirty的元素会执行build构造,没有dirty元素则不会执行,对应于buildScope()
-
Layout: 计算渲染对象大小和位置,对应于flushLayout(),这个过程可能会嵌套再调用build操作;
-
Compositing bits: 更新具有脏合成位的任何渲染对象, 对应于flushCompositingBits();
-
Paint: 将绘制命令记录到Layer, 对应于flushPaint();
-
Compositing: 将Compositing bits发送给GPU, 对应于compositeFrame()。
-
编译技术如何将dart代码转换为AST(抽象语法树),如何汇编转换为机器码,打包成产物是什么?
-
Flutter这台引擎如何发动的,怎么跟Native原生系统衔接运行,如何识别产物并加载到内存?
-
引擎启动后,TaskRunner如何分发任务,跟原生系统消息机制有什么关系?
-
Dart虚拟机如何管理内存,跟isolate又有什么关系?
-
开发者编写的Widget控件如何渲染到屏幕上?
-
Flutter如何通过plugin支持移动设备提供的服务?
作者:袁辉辉,安卓知名博主、CSDN博主「Gityuan」,热衷于研究Android系统架构与内核技术,对Android系统框架有着深刻理解与丰富的实战经验。 扫描下方二维码,查看博主更多精彩分享!
热 文 推 荐
☞做好以下四点,拒做 “ 空心 ” 程序员 | CSDN 博文精选
☞【10.23头条】阿里云存储负责人吴结生:安全可靠是云存储立身之本, 智能技术将激活存储技术新变革
☞推荐系统中的前沿技术研究与落地:深度学习、AutoML与强化学习 | AI ProCon 2019
☞超强攻略! 40道高频区块链面试题大放送, 年底跳槽看过来!| 博文精选
☞这个卷走175个国家和地区45亿英镑的“加密女王”忽然失踪,骗局崩盘
文章评论