关于flutter适配的信息
Flutter中屏幕适配,尺寸设置
1、 新版本Flutter SDK 引入了 extension的机制。可以对某个class 进行扩展。(swift中有类似机制)
创新互联-专业网站定制、快速模板网站建设、高性价比梁山网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式梁山网站制作公司更省心,省钱,快速模板网站建设找我们,业务覆盖梁山地区。费用合理售后完善,十载实体公司更值得信赖。
2、屏幕适配一直是一个老生常谈的问题,随着机型越来越多,适配的场景也越来越复杂。
3、之前有了解过 微信小程序的适配方案,个人一直感觉是一个比较好的方式( iPhone6为标准尺寸)下面????将引用小程序的方案来进行对 Flutter的尺寸设置。
size_fit.dart 文件
double_extension.dart 文件
int_extension.dart 文件
通过上面的设置,在不同设备上,展示的widget的尺寸就会不一样了。
Flutter_图片分辨率适配及批量拓展使用
flutter开发中,图片的引用是必不可少的,所以为了提高效率和精准度,我们需要对不同分辨率的手机使用相对应的切图图片,本章介绍如何进行 图片分辨率适配 和 图片批量拓展处理 。
flutter中会首先根据系统的devicePixelRatio(每一个逻辑像素包含多少个原始像素,可以通过MediaQueryData.devicePixelRatio来得到)来找对应倍数的文件夹下的图片,如果没有对应倍数,找最接近的。
所以在flutter项目中,我们需要构建对应的倍数像素文件夹
之后再pubspec.yaml中,配置assets文件后就可以使用了(如使用"assets/images/jay.png",会自动适配该像素下最接近的jay图片)。
使用flutter-img-sync插件批量化处理,具体操作如下
目前还不能处理gif、webp等格式的图片,而且如果和上边介绍的不同像素比适配方案一起使用的话,由于进行了精准定位,所以指定图片后就不能进行像素适配,这是目前还存在的较大问题,所以目前两者方案只能暂时取一使用。
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 警告:
为什么会弃用?
其实这个提议是在 这个 issue 上,然后通过 这个 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 Android端集成排坑 - armeabi 适配 & FlutterBoost
Flutter可以算是当下最火热的新技术之一,我现在所在团队也准备将Flutter技术应用到线上工程中。
关于混合工程,官方文档其实写的已经比较清楚了,按着文档走一般问题不大,
但是有一点值得注意的是,Flutter工程引入的库的gradle的 buildTypes 要与原工程保持一致,如果不一致需要手工添加。
进入正题,现在Flutter官方默认只提供armeabi-v7a、arm64-v8a、x86和x86-64,其中x86和x86-64是为模拟器准备的。目前我们使用的SDK大部分只使用了armeabi架构,直接使用我们会遇见找不到 libflutter.so,libapp.so 的情况,所以我们需要对FlutterSDK做一定的改造。
首先我们要了解下Flutter编译产物,因为不同版本产物是不同的,这里我们只针对Flutter 1.9.1-hotfixes来说。除了资源文件之外,Flutter打包会生成两个非常重要的so库,他们分别是 libflutter.so,libapp.so 。其中 libflutter.so 是Flutter的SDK产物而 libapp.so 正是我们编写的dart文件的产物。默认情况下,这两个文件都会出现在armeabi-v7a中,因此我们要作出对应的改造。
libflutter.so 位于FlutterSDK中,这里顺带提一句,除了这对不同CPU架构,它还分为Debug版和Release版,它们的区别在于Debug是为JIT编译方式打造的,体积较大而Release是为AOT编译方式打造的,体积很小。对 libflutter.so 的改造,只要将其移动文件路径即可,运行以下脚本即可,此脚本来自美团分享的Flutter文章。
移动完了 libflutter.so 之后我们打包发现, libapp.so 仍然会出现在armeabi-v7a中,所以第二部我们就是移动 libapp.so 。这个需要更改 flutter.gradle ,我们在 flutter.gradle 的45行可以看到如下定义,它定义了我们的环境。
在524行我们可以看到,abiValue的取值就是根据上述定义值。
所以结论很简单,只要将
private static final String ARCH_ARM32 = "armeabi-v7a";
改为
private static final String ARCH_ARM32 = "armeabi";
就可以完成对与 libflutter.so 的移动。
前期工作我们都做好了,打成aar就非常简单了
直接使用 flutter build aar --target-platform android-arm
打出来后可以解压检查下 libflutter.so,libapp.so 是否都在armeabi文件夹下即可。
说完了armeabi适配问题,这里下说下有关于有关于FlutterBoost的接入。这个东西接入有两点要注意。
在主app内加上即可,常规操作,强制统一support包的版本号
注释flutter.gradle第655行。因为编译过程中,会去初始化插件项目的buildType下面的debug配置,而插件项目下并未配置debug,导致报错。
如果发现文章中有错误或者有更好的解决方案欢迎指正留言,当然如果本篇文章帮助你解决了问题,也不要吝啬你的感谢。谢谢各位。
网页题目:关于flutter适配的信息
文章网址:http://myzitong.com/article/dsddeph.html