比较flutter,比较勾人的女网名

做混合的话Uniapp和Flutter我应该学哪个啊?

Uniapp目前比较成熟,而且用的是Vue语法,学习成本比较低,而且行业里面用的也比较广泛,而Flutter的话,学习成本略高,因为要学习新的语言,还有就是目前生态不是特别完备,等他再发展发展吧。黑马程序员官网有成套免费视频哦,有什么不懂的可以直接过去学习。您的采纳是对我成长的鞭策

古城ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景,ssl证书未来市场广阔!成为创新互联建站的ssl证书销售渠道,可以享受市场价格4-6折优惠!如果有意向欢迎电话联系或者加微信:18980820575(备注:SSL证书合作)期待与您的合作!

Android原生和Flutter使用过程的差异对比(二)

1、常用布局的对比

使用下来其他组件大致还算方便,但是相对布局而言使用便利程度上Android原生完胜,ConstraintLayout内部的所有子View可以设置互相之间的位置依赖关系。

而Flutter的Stack组件内部的Children只能通过外层包裹 Align后 固定位置,比如 Alignment.topLeft、Alignment.bottomRight 等。遇到复杂的堆叠布局需要通过外层包裹 Positioned 组件后设置固定的 top 和 left 距离以达到效果,内部子组件之间无法设置位置关联关系。

2、一些常用属性设置上的差异:

Margin外边距

Android:直接在布局文件对View设置android:layout_marginStart、android:layout_marginTop

Flutter:需嵌套 Container 组件并在内部设置具体的 margin 值

Padding内边距

Android:TextView、ImageView、各种Layout都可以直接在属性上设置android:paddingStart

Flutter:需嵌套 Padding 组件并在内部设置具体的值

组件的可见性

Android:每个view都可以通过setVisibility来设置可见、隐藏或者隐藏但占位

Flutter:没有单独设置组件是否显示的api,只能通过 bool 值控制是否添加该组件

事件监听

Android:常规的setOnClickListener和setOnLongClickListener设置单击和长按事件

Flutter:在需要添加事件监听的组件外层嵌套 InkWell 或 GestureDetector 并设置 onTap 等

3、生命周期

Android:

Activity和Fragment各自有完整的生命周期链路onCreate、onStart、onResume、onPause、onDestroy等

Flutter:

万物皆组件,组件继承 WidgetsBindingObserver 并重写 didChangeAppLifecycleState 函数进行监听

退回桌面依次执行inactive 》= paused,此时界面不可见用户不可操作,从桌面重新进入app执行resumed,状态较少如需在某些条件下触发特定操作可能要找别的方案,比如发通知之类的

Android原生和Flutter使用过程的差异对比(一)

1、界面搭建过程中各种大小单位

Android:通常采用dp设置View宽高(和px像素的换算关系是dp值 × density逻辑密度),sp设置字体大小(会随着系统字体设置的大小而改变)。

Flutter:没有具体的大小单位描述, 和尺寸相关的MediaQueryData类中较为重要的几个值如下:

(一)devicePixelRatio(设备像素比),对应Android中的density

(二)size.width和height,设备的逻辑像素宽高,并非绝对物理像素(例如iphone6的设备像素比是2,通过size获取到的逻辑像素宽高为375  ×  667,实际物理像素则为750 × 1334,即分辨率)

(三)textScaleFactor:单位逻辑像素字体像素数,默认为1,设置成1.5则字体变大50%,如果想让Text组件的字体大小不随系统设置的变化而变化,需将这个值设定成固定值1

UI适配解决方案:

1、采用ScreenUtil插件,初始化时候传入设计稿大小,当发现一屏显示的大小有差异时候采用插件提供的setWidth和setHeight来设置具体的宽高(会根据设计稿大小和实际设备逻辑像素宽高比进行缩放)。

2、TextButton、Text等按钮和文本组件,通过设置字体大小和内边距来控制整体的宽高,而非固定其宽高。

2、本地资源文件的引用方式

Android:图片通常存放在res/mipmap或res/drawable下,不同分辨率对应不同后缀名,如mipmap-hdpi、mipmap-xhdpi

Flutter:需在pubspec.yaml中配置,如下图所示

如果只配置父级目录例如(assets/images/common_status)则无法再存放不同尺寸的图片。不同尺寸的图片需建立对应的2.0x、3.0x目录后存放,设备在读取时候会自行根据分辨率去找对应的图片,弊端是每有一张图片就需在pubspec.yaml文件中声明这些图片

Flutter 与 iOS 原生 webView 对比

本文对比的是 UIWebView、WKWebView、flutter_webview_plugin(在iOS中使用的是WKWebView)的加载速度,内存使用情况。

测试网页打开的速度,只需要获取 WebView 在开始加载网页和网页加载完成时的时间戳,时间戳的差即为打开网页的时间

为了使差异更明显,我们选择较为复杂的 新浪首页 进行加载的对比,为了减小网络对加载速度的影响,我们让手机连接同一个网络,分别进行 10 次测试然后取平均值,另外,我们需要关闭 WebView 的缓存,防止缓存对加载速度产生影响

下面使笔者进行 10 次测试所得到的数据

结果让我有点惊讶,一直以为 WKWebView 会是个王者。结果看,速度上 WKWebView 略慢一点,不过总体差异不大(该结果仅仅是测试新浪的结果,仅供参考啦)

在这里,笔者又加了一个测试,尝试记录从 viewController 的 viewDidLoad 到 webview 的 didFinish 时间,测试了新浪的数据,如下:

UIWebViewA : 4970、3808、3815、4250、3556 avg(4079.8) (加载完所有页面)

UIWebViewB : 4103、3124、3070、3256、2835 avg(3277.6)(加载sina完毕)

WKWebView : 3672、3032、2892、2912、2739 avg(3049.4)

flutter_webView : 4532、3901、4310、3496、3378 avg(3923.4)

其中可以看到,webView 有两行,UIWebViewB 的数据就是加载 sina 主站的时间;UIWebViewA 的数据是因为在加载完 sina 主站之后,新浪又加载了一个 ,所以导致总时间延长,不过即使按照 UIWebViewB 的数据来比较,也是 wkWebView 略胜一筹。

此处可以看出 flutter_webView 使用的是 wkwebView,所以它吃亏的主要原因是 flutter 包了一层。

结论:

速度(didStart - didFinish) UIWebView flutter_webview WKWebView

速度(viewDidLoad - didFinish)WKWebView UIWebView flutter_webview

这里查看内存使用的是 xcode 的 debug session 中的 memory。

首先看之前测试时,连续打开十次新浪的内存情况

接着我们在看一下打开淘宝首页的内存情况

从图上可以看出,WKWebView 在内存方面有很大的优势啊,UIWebView 的内存是真的伤啊,然后 debug 看了一下 flutter_webView,他使用的就是原生的 webView 。

他相比较原生 WKWebView 的内存开销稍大一点,从测试表现来看,一般大个 30 MB 左右。

结论:内存 WKWebView flutter_webview UIWebView

可以在 html5test 中对浏览器的兼容性进行评分,通过测试发现得分分别如下

因为 flutter 里使用的就是 WK,所以和原生的 WKWebView 一样都是 444 分,比 UIWebView 的 437 略胜一筹

结论:兼容性 WKWebView = flutter_webview UIWebView

UIWebView : 速度相比较 WKWebView 稍快一点,但是内存是一大硬伤,所以只要条件允许,就不推荐使用了

WKWebView : 速度略慢一点,不过差别不大,总体可以接受。是比UIWebView更好的选择,推荐使用。

flutter_webView_plugin :在iOS中使用的就是原生的WKWebView,所以总体和 native WKWebView 表现差不多。如果是混编项目中,因为它被包了一层,所以页面加载上存在一定的劣势,所以混编项目中仍然推荐使用 WKWebView。不过如果从多端考虑、以及项目可迁移等,那么使用也未尝不可,就是维护成本要增加一些,需要维护两套 webView。这个就需要根据自己的情况自己取舍了。

为什么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,比较勾人的女网名
文章位置:http://myzitong.com/article/dsgieje.html