移动端的未来为什么是Flutter?( 四 )


Flutter配有丰富的可定制的Android、iOS和Material Design组件(实际上,我们已经被告知Flutter是Material Design中具有最高保真度之一的实现),我们使用Flutter的可定制特点来构建这些组件库,以匹配多个平台上的原生组件的外观和感觉 。程序开发人员可以使用相似的可定制性功能进一步调整小组件以满足他们的需求 。
更多关于响应式视图
现有的响应式web视图库都引入了虚拟DOM,DOM代表HTML的文档对象模型 。JavaScript用DOM提供的API来操纵表现为一个元素树的HTML文档 。虚拟DOM是使用编程语言中的对象(在这种情况下为JavaScript)创建的DOM的抽象版本 。
在响应式Web视图(由 ReactJS和其他系统实现)中,虚拟DOM是不可变的,每次更改,所有的东西都得重建 。系统将虚拟DOM与真正的DOM进行比较,生成一组最小的更改,然后执行这些更改,以更新真正的DOM 。最后,平台重新绘制真实的DOM到画布中 。

移动端的未来为什么是Flutter?

文章插图
 
这听起来增加了很多额外的工作,但它是值得的,因为操纵HTML DOM是非常耗费系统资源的 。
React Native 也做类似的工作,但是是在移动应用程序当中进行的 。它会操控移动平台上的原生组件而不是DOM 。它构建一个UI组件的虚拟树,与原生组件进行比较,并只更新已更改的部件 。
移动端的未来为什么是Flutter?

文章插图
 
请记住,React Native必须通过桥接器与原生部件进行通信,因此,UI组件的虚拟树可以帮助保持传递桥的最小值,同时还允许使用原生部件 。最后,一旦更新了本机部件,平台就会将它们渲染到画布上 。
React Native是移动开发的一大进步,并且是Flutter的灵感来源,但Flutter更进一步 。
移动端的未来为什么是Flutter?

文章插图
 
回想一下,在Flutter中,UI组件和渲染器已经从平台中集成到用户的应用程序中 。没有系统UI组件可以操作,所以原来虚拟控件树的地方现在是真实的控件树 。Flutter渲染UI控件树并将其绘制到平台画布上 。这很好,既简单又快 。此外,动画发生在用户空间中,因此应用程序(因此开发人员)可以对其进行更多的控制 。
Flutter渲染器本身很有趣:它使用几个内部树结构来渲染只需要在屏幕上更新的UI组件 。例如,渲染器使用“ 使用合成的结构重绘”(这意味着比使用屏幕上的矩形区域更有效) 。不变的UI控件,即使是那些已经移动的UI控件,仅需在内存中做极其细微的改动,速度当然超级快 。这就是为什么Flutter的滚动性能如此之高,即使在很复杂的滚动场景中 。
要进一步了解Flutter渲染器,我推荐这个视频 。你也可以看看代码,因为Flutter是开源的 。当然,您可以自定义或甚至替换整个堆栈,包括渲染器,合成器,动画,手势识别器,当然还有widgets 。
Dart编程语言
因为Flutter 像使用响应式视图的其他系统一样,刷新每个新框架的视图树,它会创建许多只能在一帧(六十分之一秒)内存在的对象 。幸运的是,Dart使用“generational garbage collection ”对于这样的系统来说是非常有效的,因为对象(特别是寿命短的)消耗资源相对较少 。此外,可以使用单个pointer bump来完成对象的分配 。这是一个快速且不需要锁定的pointer bump 。这有助于避免UI 卡顿 。
Dart还有一个“tree shaking ”编译器,它只包含你在应用程序中需要的代码 。即使您只需要一个或两个,您也可以随意使用大型的UI控件库 。
热重载
Flutter最受欢迎的功能之一是其快速,保留程序状态的热重载 (hot reload) 。您可以在Flutter应用程序运行时对其进行更改,重新加载应用程序的代码,将其从之前的操作位置继续下去 。一次热重载通常用不到一秒钟 。如果您的应用遇到错误,您通常可以修复错误,然后继续,就像错误从未发生过 。即使你必须完全重新加载,它也是很快速的 。
移动端的未来为什么是Flutter?

文章插图
 
开发人员告诉我们,这可以让他们“绘制”他们的应用程序,一次更改,然后几乎立即可以看到结果,而无需重新启动应用程序 。
兼容性
因为UI组件(和这些UI组件的渲染器)是您的应用程序的一部分,而不是平台的一部分,不需要“兼容库 ” 。您的应用程序不仅可以正常工作,而且在最近的操作系统版本Jelly Bean以后的安卓系统和 8.0以后的iOS系统上也是一样的。这显著降低了在旧版本操作系统上测试应用程序的需求 。此外,你的App有很大可能与未来的操作系统版本兼容 。


推荐阅读