flutter渲染屏障,flutter渲染引擎
为什么Flutter开发APP性能最接近原生,前端程序员请关注
Flutter是谷歌公司推出的跨终端的开发框架,支持Android、iOS和WEB终端。1.0版在2018年12月5日发布,目前的最新版本是1.5,它采用的开发语言是Dart,Dart也是谷歌开发的计算机编程语言,语法类似C,是编译型语言:
网站建设哪家好,找创新互联!专注于网页设计、网站建设、微信开发、小程序开发、集团企业网站建设等服务项目。为回馈新老客户创新互联还提供了洪山免费建站欢迎大家使用!
hello world例子,打印字符串“Hello World!”:
1、没有桥接层
React Native、Weex等技术都是跨终端的框架,然而性能跟原生App存在很大差距。这是由于它们的工作原理决定的:
React Native、Weex等技术多了一个桥接层,所以界面渲染会慢一些,由于UI渲染非常频繁,想要不卡顿,基本上比较难,性能和用户体验跟原生代码有差距。而这恰恰是Flutter的优势所在:
Dart可以被编译成不同平台的本地代码,让Flutter不通过桥接层直接跟平台通信,自然性能会快一些。
2、编译执行
JavaScript是解释执行的,Dart是编译执行的,性能谁好一目了然。
3、Flutter Engine虚拟机
Flutter是依靠Flutter Engine虚拟机在iOS和Android上运行的,Flutter Engine使用C/C++编写,开发人员通过Flutter框架直接和API在内部进行交互,所以具有输入低延迟和UI渲染高帧速率的特点。除了这特点之外,Flutter还提供了自己的小部件,Flutter小部件是使用从React获取灵感的现代框架构建的。 中心思想是您使用小部件构建UI。
窗口小部件根据其当前配置和状态描述了它们的视图。 当窗口小部件的状态发生更改时,窗口小部件会重建其描述,框架将根据前面的描述进行区分,以确定底层呈现树从一个状态转换到下一个状态所需的最小更改。可以直接在OS平台提供的画布上进行描绘,也就是一些核心类库直接放到虚拟机里面,调用起来更快。
从它的系统结构可以看出,类似安卓的ART(Android Run Time)虚拟机,同样采用AOT(Ahead of TIme)技术,会在APP安装时就编译成机器语言,不再解释执行,从而优化了APP运行的性能。
4、自带渲染引擎
Flutter使用谷歌自己的Skia渲染引擎,而Android系统自带Skia引擎,iOS平台上Flutter也会把Skia引擎打包到APP中,从而实现了高效渲染。而React Native通过桥接层访问原生UI,操作频繁就容易出性能问题。
综合所述,Flutter 是性能最接近原生代码 的一种开发框架,未来也会是构建谷歌Fuchsia应用的主要方式,前途不可限量,唯一的问题就是需要学习一门新的语言:Dart,而有Java或者C#语言基础的程序员会比较容易学习。
Flutter Math发布,使用纯Flutter渲染LaTeX数学公式
介绍一下我最近开发的一个Flutter插件。Flutter Math是一个完全使用Dart和Flutter渲染LaTeX数学公式的插件,可以看作是移植在Dart和Flutter平台上的KaTeX。其支持的LaTeX语法大致与KaTeX相同(少数当前版本暂不支持的语法详见Github仓库),对数学公式的渲染结果几乎像素级还原KaTeX。
相比已有的flutter_tex插件,本插件完全的基于Dart和Flutter,不包含任何WebView和Javascript,性能远超过flutter_tex。大家如果频繁遇到flutter_tex带来的卡顿以及崩溃,欢迎试用Flutter Math。
x = \frac{-b \pm \sqrt{b^2 - 4ac}}{2a}
i\hbar\frac{\partial}{\partial t}\Psi(\vec x,t) = -\frac{\hbar}{2m}\nabla^2\Psi(\vec x,t)+ V(\vec x)\Psi(\vec x,t)
\hat f(\xi) = \int_{-\infty}^\infty f(x)e^{- 2\pi i \xi x}\mathrm{d}x
项目仓库地址: GitHub地址 。目前版本为0.1.1,更多信息以及暂不支持的KaTeX特性欢迎查阅GitHub页面。欢迎打星,欢迎fork!
iOS开发Flutter探索-State状态保存(10)
有时候我们不希望某个页面每次打开时都重新加载,比如就我们之前的Tabbar结构的页面,每当我们在切换Tab的时候都会执行 void initState() ,这就意味着页面每次都会重新渲染,之所以这样就是因为我们的 State 状态没有保存,如下图所示:
[没有状态保存效果图]
给当前 State 类添加一个扩展(这里就用扩展这个词吧,其实类似于iOS下的 Category ),一个系统的扩展类 AutomaticKeepAliveClientMixin ,并重写 wantKeepAlive 方法,让一个普通的 State 类,具有保存状态的能力。
在Dart语法中通过使用 with 关键字来添加扩展:
bool get wantKeepAlive = true; 之后,当前 State 就具备保存能力了,也就意味着重复切换Tab后, void initState() 就不会重复执行了(由原来的 viewWillAppear() 变成了 viewDidLoad() )。
按照上面方式修改后,发现切换Tab后 void initState() 依然重复执行了,这是为什么呐?这里我们看下我们之前 root_page.dart 里面是如何配置我们的tabbar结构的:
这里我们是通过一个 _viewControllers 的List,把4个子页面放在了里面,全局有一个 _currentIndex ,当 onTap 回调后后,更新 _currentIndex 的值,执行 setState () 后, body 对应的 widget 页面发生改变。而问题也就出在这里,当 body 部分发生改变时,根据Flutter的底层渲染逻辑,这里会移除掉之前的 Widget ,并重新创建新的 Widget ,我们之前在 _viewControllers 放的子页面,并不像iOS下是一个实例对象,存在就直接拿来使用。在Flutter 中 setState () 后界面会被重新绘制,而 body 部分只知道我要渲染一个什么样的 widget ,而该类型的 widget 每次都是会重新创建,这也就意味着我们在Tab切换时,每次都是重新创建,所以每次都执行了 initState() 。
显然我们现在的方式是不合理的,那在Flutter中如何管理这样的子页面,而避免重复渲染呐?
这就要用到一个新的部件了: PageView() ,内部的2个关键属性:
子页面切换通过 _controller.jumpToPage(index); 来实现。
这样子页面也就不会重新创建渲染了,我们的状态保存也就能正常实现了。
学习是一个循序渐进的过程,我们总是在踩坑中不断的前行,把坑填平了也就意味着我们在这个新的东西面前立了足,就可能进行更多为什么的探索了。
分享题目:flutter渲染屏障,flutter渲染引擎
文章源于:http://scyanting.com/article/dsedipj.html