Flutter底层兼容（flutter 嵌入原生）

本篇文章给大家谈谈Flutter底层兼容，以及flutter 嵌入原生对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享Flutter底层兼容的知识，其中也会对flutter 嵌入原生进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、Flutter开发 解决iOS编译不兼容Swift
• 2、flutter与原生交互方法和底层原理分析
• 3、Flutter Channel底层原理分析
• 4、Flutter 启动页的前世今生适配历程
• 5、为什么说移动端的未来是Flutter？
• 6、基于Weex的Flutter项目框架

Flutter开发 解决iOS编译不兼容Swift

在进行Flutter开发过程中Flutter底层兼容，很容易出现iOS原生端编译不成功的问题，比如出现Undefined symbol:__swift_FORCE_LOAD_$_swfitCoreLocation
出现这种情况的时候，为没有导入swift头文件导致编译不成功，解决办法为Flutter底层兼容：

1、新建选中Runner右键New File  选择Swift File

2、点击create的时候会出现选择Xcode  - Create Bridging Header 

3、随后会创建一个Runner-Bridging-Heading.h的文件

4、正常运行项目即可
一般此情况多出现在第一次运行iOS的情况，为导入过支持Swift后XCode没有进行兼容导致的问题。

flutter与原生交互方法和底层原理分析

1.环境准备， 参考链接
2.添加国内环境配置： 参考链接
3.新建

name: String类型，代表Channel的名字，也是其唯一标识符。
messager：BinaryMessenger类型，代表消息信使，是消息的发送与接收的工具。
codec: MessageCodec类型或MethodCodec类型，代表消息的编解码器。

fluuter中的MessageCodec用于二进制格式数据与基础数据之间的编解码。BasicMessageChannel所使用的编解码器就是MessageCodec。
iOS中，名称为FlutterMessageCodec，是一个协议，定义了两个方法：encode接收一个类型为id的消息，将其编码为NSData类型，而decode接收NSData类型消息，将其解码为id类型数据。
MessageCodec有多种不同的实现：

与MessageCodec不同的是，MethodCodec用于MethodCall对象的编解码，一个MethodCall对象代表一次从Flutter端发起的方法调用。MethodCall有2个成员变量：String类型的method代表需要调用的方法名称，通用类型(Android中为Object，iOS中为id)的arguments代表需要调用的方法入参
由于处理的是方法调用，故相比于MessageCodec，MethodCodec多了对调用结果的处理。当方法调用成功时，使用encodeSuccessEnvelope将result编码为二进制数据，而当方法调用失败时，则使用encodeErrorEnvelope将error的code、message、detail编码为二进制数据
​ MethodCodec有两种实现：

Flutter Channel底层原理分析

百度网盘flutter 见46-Flutter Channel

Flutter 提供三种Channel用作Flutter与iOS原生平台之间的数据传递

1.FlutterBasicMessageChannel: 用作频繁与原生交互

2.FlutterMethodChannel:用来调用方法，双向通讯

3.FlutterEventChannel：数据流通讯

三种Channel,都有以下成员变量

1.name: Channel 的唯一标识

在Flutter应用中，通常存在多个Platform Channel,使用name区分不同的Channel

2.messenger: 消息信使(BinaryMessenger)

负责Flutter与原生之间的相互通讯
 [methodChannel setMethodCallHandler:^(FlutterMethodCall * _Nonnull call, FlutterResult  _Nonnull  result) {

  }];

setMethodCallHandler方法，MethodCallHandler放在FlutterBinaryMessageHandler中
创建一个FlutterMethodChannel，通过 setMethodCallHandler来进行消息处理，最终会为FlutterMethodChannel绑定一个FlutterBinaryMessageHandler，并以FlutterMethodChannel的name作为key，保存在一个Map结构中

先创建 FlutterEngine-FlutterViewController-FlutterMethodChannel,

调用setMethodCallHandler方法时，会进入FlutterEngine的setMessageHandlerOnChannel:binaryMessageHandle:中，在进入PlatformMessageRouter中进行储存

Flutter 启动页的前世今生适配历程

APP 启动页在国内是最常见也是必备的场景，其中启动页在 iOS 上算是强制性的要求，其实配置启动页挺简单，因为在 Flutter 里现在只需要：

一般只要配置无误并且图片尺寸匹配，基本上就不会有什么问题， 那既然这样，还有什么需要适配的呢？

事实上大部分时候 iOS 是不会有什么问题， 因为 LaunchScreen.storyboard 的流程本就是 iOS 官方用来做应用启动的过渡；而对于 Andorid 而言，直到 12 之前 windowBackground 这种其实只能算“民间”野路子 ，所以对于 Andorid 来说，这其中就涉及到一个点：

所以下面主要介绍 Flutter 在 Android 上为了这个启动图做了哪些骚操作～

在已经忘记版本的“远古时期” ， FlutterActivity 还在 io.flutter.app.FlutterActivity 路径下的时候，那时启动页的逻辑相对简单，主要是通过 App 的 AndroidManifest 文件里是否配置了 SplashScreenUntilFirstFrame 来进行判断。

在 FlutterActivity 内部 FlutterView 被创建的时候，会通过读取 meta-data 来判断是否需要使用 createLaunchView 逻辑 ：

是不是很简单，那就会有人疑问为什么要这样做？我直接配置 Activity 的 android:windowBackground 不就完成了吗？

这就是上面提到的时间差问题， 因为启动页到 Flutter 渲染完第一帧画面中间，会出现概率出现黑屏的情况，所以才需要这个行为来实现过渡 。

经历了“远古时代”之后， FlutterActivity 来到了 io.flutter.embedding.android.FlutterActivity ， 在到 2.5 版本发布之前，Flutter 又针对这个启动过程做了不少调整和优化，其中主要就是 SplashScreen 。

自从开始进入 embedding 阶段后， FlutterActivity 主要用于实现了一个叫 Host 的 interface ，其中和我们有关系的就是 provideSplashScreen 。

默认情况下它会从 AndroidManifest 文件里是否配置了 SplashScreenDrawable 来进行判断 。

默认情况下当 AndroidManifest 文件里配置了 SplashScreenDrawable ，那么这个 Drawable 就会在 FlutterActivity 创建 FlutterView 时被构建成 DrawableSplashScreen 。

DrawableSplashScreen 其实就是一个实现了 io.flutter.embedding.android.SplashScreen 接口的类，它的作用就是：

之后 FlutterActivity 内会创建出 FlutterSplashView ，它是个 FrameLayout。

FlutterSplashView 将 FlutterView 和 ImageView 添加到一起， 然后通过 transitionToFlutter 的方法来执行动画，最后动画结束时通过 onTransitionComplete 移除 splashScreenView 。

所以整体逻辑就是：

当然这里也是分状态：

当然这个阶段的 FlutterActivity 也可以通过 override provideSplashScreen 方法来自定义 SplashScreen 。

看到没有，做了这么多其实也就是为了弥补启动页和 Flutter 渲染之间， 另外还有一个优化，叫 NormalTheme 。

通过该配置 NormalTheme ，在 Activity 启动时，就会首先执行 switchLaunchThemeForNormalTheme(); 方法将主题从 LaunchTheme 切换到 NormalTheme 。

大概配置完就是如下样子， 前面分析那么多其实就是为了告诉你，如果出现问题了，你可以从哪个地方去找到对应的点 。

讲了那么多， Flutter 2.5 之后 provideSplashScreen 和 io.flutter.embedding.android.SplashScreenDrawable 就被弃用了，惊不喜惊喜，意不意外，开不开心 ？

通过源码你会发现，当你设置了 splashScreen 的时候，会看到一个 log 警告：

为什么会弃用？
其实这个提议是在 https://github.com/flutter/flutter/issues/85292 这个 issue 上，然后通过 https://github.com/flutter/engine/pull/27645 这个 pr 完成调整。

大概意思就是： 原本的设计搞复杂了，用 OnPreDrawListener 更精准，而且不需要为了后面 Andorid12 的启动支持做其他兼容，只需要给 FlutterActivity 等类增加接口开关即可 。

也就是2.5之后 Flutter 使用 ViewTreeObserver.OnPreDrawListener 来实现延迟直到加载出 Flutter 的第一帧。

为什么说默认情况？ 因为这个行为在 FlutterActivity 里，是在 getRenderMode() == RenderMode.surface 才会被调用，而 RenderMode 又和 BackgroundMode 有关心 。

所以在 2.5 版本后， FlutterActivity 内部创建完 FlutterView 后就会执行一个 delayFirstAndroidViewDraw 的操作。

这里主要注意一个参数： isFlutterUiDisplayed 。

当 Flutter 被完成展示的时候， isFlutterUiDisplayed 就会被设置为 true。

所以当 Flutter 没有执行完成之前， FlutterView 的 onPreDraw 就会一直返回 false ，这也是 Flutter 2.5 开始之后适配启动页的新调整。

看了这么多，大概可以看到其实开源项目的推进并不是一帆风顺的，没有什么是一开始就是最优解，而是经过多方尝试和交流，才有了现在的版本，事实上开源项目里，类似这样的经历数不胜数：

为什么说移动端的未来是Flutter？

Flutter是Google开发的新一代跨平台方案，Flutter可以实现写一份代码同时运行在iOS和Android设备上，并且提供很好的性能体验。Flutter使用Dart作为开发语言，这是一门简洁、强类型的编程语言。Flutter对于iOS和Android设备，提供了两套视觉库，可以针对不同的平台有不同的展示效果。

Flutter原本是为了解决Web开发中的一些问题，而开发的一套精简版Web框架，拥有独立的渲染引擎和开发语言，但后来逐渐演变为移动端开发框架。正是由于Dart当初的定位是为了替代JS成为Web框架，所以Dart的语法更接近于JS语法。例如定义对象构建方法，以及实例化对象的方式等。

在Google刚推出Flutter时，其发展很缓慢，终于在18年发布第一个Bate版之后迎来了爆发性增长，发布第一个Release版时增长速度更快。可以从Github上Star数据看出来这个增长的过程。在19年最新的Flutter 1.2版本中，已经开放Web支持的Beta版。

Flutter不仅仅提供了一套视觉库，在Flutter整体框架中包含各个层级阶段的库。例如实现一个游戏功能，上面一些游戏控件可以用上层视觉库，底层游戏可以直接基于Flutter的底层库进行开发，而不需要调用原生应用的底层库。Flutter的底层库是基于Open GL实现的，所以Open GL可以做的Flutter都可以。

基于Weex的Flutter项目框架

最近在做的一个项目，项目的前期采用Weex开发。但是随着交互复杂度的增加，Weex一处开发多处多处运行的特征并没有很好的体现，相反很多时候我们还是需要做IOS和Android的适配。如今火热的Flutter相比Weex和Rn来说，给出了更好的跨平台解决方案。所以我们设计了一套基于Weex实现，底层跑在Flutter Engine上的框架。

 底层的Runtime采用isolate engine,框架业务逻辑，Dom的解析逻辑和Render逻辑都跑在这里。

 渲染引擎采用Flutter的Skia，彻底剥离了Android和IOS的差异性.
    将Weex VirsualDom的解析都替换成Flutter Widget.

    设计基于Weex2Dart的Brider,使JS和Dart可以相互调用
    weex-demo的性能展示
release环境下采用AOT模式，性能会有质的飞跃。
Android-Release版本只有10m大小
相比Weex和Rn具有更好的性能，同时具有更好的跨平台性

相比Flutter，具有动态部署的能力（Flutter Release采用AoT模式并没有动态部署的能力，即使Debug版本也只是开发环境下才有动态化能力并没有可以实施项目的能力）

只需要会Weex开发或则Rn开发就可以，不需要额外学习Dart，已有的Weex项目可以无缝切换。 关于Flutter底层兼容和flutter 嵌入原生的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 Flutter底层兼容的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于flutter 嵌入原生、Flutter底层兼容的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。