Flutter课程(1)：Flutter介绍与环境搭建

最新推荐文章于 2024-06-25 01:41:52 发布

yzpyzp

最新推荐文章于 2024-06-25 01:41:52 发布

阅读量303

点赞数

分类专栏： Android Flutter

本文链接：https://blog.csdn.net/yzpbright/article/details/115496811

版权

Android 同时被 2 个专栏收录

624 篇文章 17 订阅

订阅专栏

Flutter

42 篇文章 0 订阅

订阅专栏

课程主题：

了解Flutter是什么，为什么能”火”起来?
为什么要学习Flutter？
Flutter的环境搭建

跨平台开发

在传统的原生开发中，一般都要维护Android、iOS两个开发团队，版本迭代时，无论人力成本，还是测试成本都会变大。这一点可能对于我们普通的android程序员感受并不深，或者说我们不care这一点。但是站在公司的角度上，如果能够有一套代码，直接就能够开发出android的apk和ios的ipa，是不是意味着我只需要拥有开发维护这套代码的一个团队就可以了？从人力成本上来说，可以让我少发一些工资。而在开发的角度，一套代码也能够很好的完成复用、测试以及UI风格的统一。而Flutter正是这样一个能够让我们跨平台开发的框架。

Flutter作为一门相对年轻的技术，对于原生开发的岗位可能并不会那么多，但是对于原生开发的工程师，大家对于这么年轻的Flutter技术的起点并不会差距太大。所以这是不是我们的一个机会呢？

总结：

传统的原生开发一般都要维护Android、iOS两个开发团队，版本迭代时，无论人力成本，还是测试成本都会变大。
使用Flutter开发，真正的一套代码多端使用，增加代码复用，降低人力和开发成本。

在这里插入图片描述

使用Flutter的公司：
今日头条
腾讯
阿里
美团
网易
……

移动平台发展史

2011年第一季度，Android在全球的市场份额首次超过塞班系统，跃居全球第一。2011年，移动互联网各种应用开始普及，用户习惯慢慢养成。从2011年到如今，移动互联网实实在在的影响着我们日常生活中的点点滴滴。在互联网草莽兴起的年代，只要能用Android提供的SDK完成一个简单界面的编写就能找到一份不错的工作。但是移动互联网慢慢进入下半场，已经没有了高速发展期的红利，在如今我们移动互联网从业人员更应该从各个方面不断强化自己的技能。

第一阶段:原生开发

在早期的移动开发中，面对这个崭新的方向，人们都处于摸索节点，那时候大家都在进行原生的开发。但是谁都不想放过移动互联网这块蛋糕。Web开发人员的数量远远多于移动互联网开发人员，同时由于原生开发的成本与动态化渐渐无法满足要求。同时原生开发维护成本大、开发周期长，动态化能力弱，所以人们都在寻找跨平台的方案，希望能够只需要一个团队维护一份代码，就能够完成Android与IOS的开发需求。

总结：

开发成本大
原生开发一般都要维护Android、iOS两个开发团队，版本迭代时，人力成本，开发成本，测试成本都会变大。
动态化需求
当需求发生变化时，纯原生应用大多数需要通过版本升级来更新内容，不发版也可以更新应用内容的需求就变的迫在眉睫。

第二阶段:H5

早在2008年，就有一款叫做“PhoneGap”的框架获了奖并开始支持Android平台。现在我们说的PhoneGap一般指的是"Cordova"。它是PhoneGap贡献给Apache后的开源项目，是从PhoneGap中抽离出的核心代码，是驱动PhoneGap的核心引擎。两者维护的是共同的一份源代码组件，只有名字和包名不一样。PhoneGap是一个采用HTML，CSS和JavaScript来完成跨平台开发的技术，当时PhoneGap宣称接近原生性能。然而它的工作原理是基于WebView，然后利用JavaInterface来完成与原生代码的交互。我们称这种工具为WebView JavaScript Bridge(JsBridge)。这种方式，能够很好的解决跨平台与动态更新的需求。但是，我们都知道android WebView的渲染效率很差，同时JavaScript是解释型语言，它不需要编译，在运行时候解释执行，这就导致JavaScript的执行性能太低了。同时因为android自身的问题，使用WebView过程中消耗的内存，没有办法在不需要使用的时候进行及时的回收，这样会导致我们的可用内存越来越少，最终OOM。

cordova工作机制：
在这里插入图片描述

WebView担任JavaScript与原生API之间通信的Bridge桥梁。
用于在JavaScript与原生之间通信的工具称之为WebView JavaScript Bridge(JsBridge)。
WebView性能堪忧

代码实现

核心就是依WebView

布局文件中需要一个WebView：
在这里插入图片描述
需要启用JavaScript
然后传递给WebView相应的JavaScriptInterface，参数是一个Java对象和一个字符串，Java对象就是做相应的原生代码写的逻辑，字符串就是表示这个JavaScriptInterface的名字，名字可以随便取，JavaScript通过这个名字可以调用Android原生的Java对象的方法：
在这里插入图片描述
例子中Java对是AndroidPlatform，名字是"android"。

在这里插入图片描述
JavaScript代码通过"android"调用AndroidPlatform的toast方法

是不是感觉好方便啊，只要传递一个java对象给webview，然后JavaScript代码就可以直接调用java对象的方法了，但是这种方案必须依赖webview，这就导致了很多问题：

android的webview渲染效率很差，加载页面渲染页面非常缓慢。不同的webview可能还有兼容性问题
JavaScript是解释型语言，它不需要编译，在运行时候解释执行，这就导致JavaScript的执行性能太低了
同时因为android自身的问题，使用WebView过程中消耗的内存，没有办法在不需要使用的时候进行及时的回收，这样会导致我们的可用内存越来越少，最终OOM。

这就导致了依赖webview的跨平台开发方案性能很低。

java是混合类型，jvm是解释执行字节码的，但是对于热点代码会编译执行。
编译型语言的缺点是不能跨平台，但是执行效率非常高，比如C/C++。
解释型语言可以跨平台，但是执行效率低，需要在运行时一行行解释执行，比如java，java是跨平台的，但是jvm不是跨平台的，不同操作系统的jvm是不一样的，但是用java写的程序可以在各种操作系统上执行，正式通过jvm实现的。

第三阶段:跨平台

为了突破使用WebView进行渲染的性能问题，2015年4月，Facebook开源了JS框架 React 在原生移动应用平台的衍生产物——React Native。RN将渲染交给原生，而不是直接在HTML中完成。

我们编写的依旧是JavaScript代码。这时候，我们使用JS写好UI后，会组成一个Virtual DOM。然后通过Bridge将VD发给原生层去进行UI的创建。这种方式看起来与原生开发非常相似，我们在进行原生开发的时候，写好XML布局再由Java对这个布局XML进行解析，然后通过反射创建对应的View，这个XML就是一个界面的配置文件。而使用RN，我们的配置则由XML变成了JS编写。不同的是我们在原生开发中，xml是静态的配置，而RN中要更新UI，又需要经历一次Bridge传递的过程。同时如果需要在RN中调用原生API也需要通过bridge来进行传递。这样导致需要频繁的跨桥调用，bridge 的成本太高了。

就是RN不再通过webview进行渲染，而是把js代码通过bridge发给Android原生层，然后Android原生层把js代码转为各种Android原生View(比如TextView，Button等)来进行渲染页面，就像Android解析XML文件生成各种TextView，Button等视图一样的原理。但是用RN写的页面只要页面上有任何更新都需要通过bridge这一层才能传递给Android原生层，比如页面的各种动态效果，动画，滑动等，这就导致了性能也低。

虽然RN底层是使用原生进行绘制，但是毕竟中间多了一层Bridge，也就是多了一层中介，你租房是希望能直接与房东进行交流还是和中介公司？很显然，去中介公司进行租房，你将花费一些代价。所以RN多了一层中介——Bridge，它绝无可能与原生的性能相媲美，但是为了跨平台，这点代价不是致命的。你会因为中介需要多付中介费，就完全靠自己去找房东个人租房子吗？

RN工作机制：
在这里插入图片描述

H5 作为第二阶段的性能瓶颈，RN通过桥梁完成原生绘制，以达到更优的性能。
JavaScript通过 bridge 传递到native完成原生绘制， bridge 的成本高，因为需要频繁的跨桥调用，导致卡顿等性能问题。

有没有一种开发页面的语言，在不同平台上编译后就生成对应平台的可以直接执行的代码？
Flutter就是这种原理。

什么是Flutter

之前我们了解到，现有的跨平台技术的工作机制。根据之前的了解，我们是不是设想如果拥有一个框架，我们编写的代码直接会根据打包的平台编译为此平台本身的原生代码，在运行时期直接执行这些编译后的原生代码，就和我们进行原生开发一样，不再需要Bridge来担任中介的角色，是不是能够拥有最优秀的性能？

跨平台框架

RN，WEEX是类似的原理
Flutter

Flutter介绍

Flutter是谷歌的移动UI框架，可以快速在iOS和Android上构建高质量的原生用户界面。Flutter可以与现有的代码一起工作。在全世界，Flutter正在被越来越多的开发者和组织使用，并且Flutter是完全免费、开源的。

从官方的介绍中，能看出三个关键点：

跨平台移动UI框架
与现有的代码一起工作
完全免费、开源

第一点：移动端跨平台，一般指的就是Android与IOS两大平台。值得我们讨论的是除了Android、IOS之外，Flutter它还是一个叫做"Fuchsia"的操作系统主要的UI开发框架。

Fuchsia是Google开发的继Android和Chrome OS之后的第三个系统。外界都在猜测它会取代Android，但是也只是猜测而已。

第二点：与现有的代码一起工作。这意味着，Flutter可以支持进行"混合开发"，我们的项目如果一开始是使用原生的形式开发的，在后续业务功能的实现上，如果我们希望能够利用到跨平台的优势，那么Flutter它可以运行在我们原有代码的基础上，通过嵌入Flutter来进行项目开发，可以逐步过渡，而不需要整个项目都迁移到Flutter。

而第三点完全免费开源，这意味着我们可以完全免费的借助Flutter进行商业App的开发，不用担心任何版权问题。

17年知乎热帖：如何看待百度要求内部全面停止使用 React / React Native?，就是由版权引发的全球风暴，导致BAT等已准备弃用RN。

flutter工作机制：
在这里插入图片描述

Flutter的工作机制和我们预想的一样，他正是通过将它的代码根据不同的平台编译为对应平台的机器码，这样就不需要Bridge的存在了。Flutter自己嵌入了一个 Dart VM，我们编写的代码在Android机子上会被Dart VM编译成ARM的机器码，在Android中就是通过Dart VM所在的libflutter.so完成我们自己编写的代码生成机器码的功能的。
libflutter.so是flutter的C++层的代码，比如渲染引擎，dart vm的代码在libflutter.so中。

Android真机一般都是ARM架构的，模拟器是X86或者x86_64架构的

IOS真机一般也是ARM架构的，模拟器早期都是I386架构的，在5s的模拟器后好像都是x86_64架构的了。

总结：
Flutter是谷歌的移动UI框架，可以快速在iOS和Android上构建高质量的原生用户界面。 Flutter可以与现有的代码一起工作。在全世界，Flutter正在被越来越多的开发者和组织使用，并且Flutter是完全免费、开源的。

在这里插入图片描述

扩展阅读：
Android 五年内要被取代？这里有 Google Fuchsia 的一些真相

Flutter架构

Flutter框架整体拥有两层架构，由上往下，第一层是Framework类库层，提供给我们在开发时所使用的各种Widget、动画等。而第二层则是Engine引擎层，我们上面所说的Dart VM也就处于这一层。

在这里插入图片描述

Flutter发展史

在这里插入图片描述

Flutter特点

类似Flutter这种框架的出现是必然的，现有的跨平台框架，比如RN都是基于JS，由于JS的执行性能，导致跨平台应用性能一直无法突破瓶颈。而Flutter在Debug使用JIT编译，支持热重载，能够提高我们的开发效率，而Release中利用AOT直接编译成机器码，能够达到更好的性能。

热重载是加快开发速度的，就是不需要重新编译整个apk就可以看到更新后的那部分内容，比如你更新了一些UI布局文件的内容，点击运行按钮后热重载可以实现快速在app上看到更新后的UI，而不需要重新编译整个app，也不需要重新安装app，不需要重新启动app，大型项目重新编译整个app是很慢的，要等好久。
原理：开发者的电脑会启动一个websocket，手机或者模拟器连接到这个websocket，代码更新后，只需要把修改的部分发送到手机中运行着的app中，然后app重新加载这部分内容即可。

从设计角度而言，Flutter提供了非常丰富的Widget组件，能够让我们非常轻松的实现Android或者IOS风格的UI效果。比如产品需要Android实现和IOS中的app一样的效果，但是Android平台没有这种系统api可以使用，就需要手动写一大堆代码去实现这个功能，非常耗时间，而使用了flutter就不存在这个问题了，可以使用flutter提供的api，在Android和IOS上达到统一的效果，不需要把精力花在风格统一的事情上面。

Flutter宣称达到了Android和IOS原生平台的性能。这个可能只是宣传需要…Phonegap，RN出来的时候也宣称自己达到了原生的性能，但其实根据它们的实现方案就可以知道根本不可能达到原生的性能，至于Flutter也宣称达到了原生的性能，这个需要开发者和用户的广泛使用后才能知道是否真正达到了原生的性能。但从flutter的实现原理上，虽然是页面代码最终都编译成了原生的代码进行执行，但是还是多了dart vm所在的c++这一层，代码是需要经过dart vm才能执行的，因此，应该还是会有些差距的，但是客观的说，flutter已经是现有的UI跨端开发框架的最优秀的了…

Flutter作为Google官方孵化的项目，拥有更加规范与完善的生态圈，依托官方就是它最大的优势之一。像IOS中的热更新，被苹果官方一句话就让你的努力白费了，但是如果是IOS官方推出的热更新还用担心这样的问题吗？

总结：
在这里插入图片描述

Flutter优势

热重载
页面每次改动，不需要手动去刷新，可自动刷新。即支持开发过程中热重载。
统一的UI
Flutter 提供丰富的内置 UI 组件—— Material Design（针对 Android ）和 Cupertino（适用于 iOS ），不需要担心在众多设备上看起来会有什么不同。

性能对比，从实现原理上，肯定比RN性能好的，主要还是看和原生的性能对比。
与原生性能对比
 与Rn性能对比

文章中可以看出对比：
apk大小：
相同的功能，原生app：1.3M，flutter开发的app：7.5M
这是不可避免的，因为flutter作为第三方开发框架，需要很多的依赖集成到apk中，而且单单是libflutter.so就已经占了很多空间了，而原生app是Android系统就已经存在相关api了。后续可能Android的新版本也会内置一些flutter所需的依赖，那么可能flutter开发的app就没这么大了。

性能：
cpu和内存占用都是比原生的要高点。