一、cocopods版本升到1.10.0以上
创新互联服务项目包括四方台网站建设、四方台网站制作、四方台网页制作以及四方台网络营销策划等。多年来,我们专注于互联网行业,利用自身积累的技术优势、行业经验、深度合作伙伴关系等,向广大中小型企业、政府机构等提供互联网行业的解决方案,四方台网站推广取得了明显的社会效益与经济效益。目前,我们服务的客户以成都为中心已经辐射到四方台省份的部分城市,未来相信会继续扩大服务区域并继续获得客户的支持与信任!
二、podfile添加这些(flutter_module路径和.git路径相同)
三、命令行cd到 flutter_module 下,执行 flutter pub get
四、pod下面添加“ install_framework "${PODS_ROOT}/../../flutter_module/.ios/Flutter/App.framework" ”
在flutter官网上推荐了iOS项目中两种混编方式:
笔者在采用两种集成方式的过程中,因为iOS项目结构设计导致这两种简单的集成方式都有些麻烦,所以在实践中更改和优化了集成方式,使之在笔者的项目中能够更加简单和快速的集成。
问题:在不更改flutter tool中相关脚本的前提下,添加的Script Phase中的脚本相对路径错误,如果只是开发,手动更改下路径就可以了,但是在考虑到CI中不能每次在pod install之后都去更改,所以在开发调试中采用该集成方式,结合flutter attach的方式去调试。
通过编译相关的 xcframework + Cocoapods私有库的集成方式在CI中集成,这样QA的CI不需要配置flutter的相关依赖
根据flutter编译工具的提示: 上面的编译命令是打包flutter工程项目和插件的产物,在实际开发过程中可以发现是否引入了依赖Native的插件会导致贬义编译产物的不同。
根据上面的对比:
第一部分:基础的 Flutter Engine + Flutter App 编译后的产物 Flutter.xcframwork -- Flutter引擎的包 App.xcframework -- 工程项目对应的AOT的编译产物 第二部分:三方插件的注册中心 FlutterPluginRegistrant.xcframework -- 第三方插件的注册中心,其实是Native + iOS通信的集合 第三部分:依赖iOS Native的原生 FMDB . xcframwork path_provider_ios.xcframework sqflite.xcframework -- cached_network_image依赖的原生实现
根据上面的编译产物可以知道Flutter和App是编译后必有的包,后面的两个部分完全是服务于三方插件的,到这可以解答第二个问题:笔者App的混编过程中混编插件失效是因为笔者在NativeApp中重写了Flutter的容器,使用了FlutterEngineGroup动态创建多引擎去对应进入不同的功能模块,混合插件是因为重写过程中没有通过GeneratedPluginRegistrant注册插件,所以需要在Native的Flutter容器中注册插件,使之生效。
在这为什么使用commit的hash作为flutter-libs的依赖,因为pod install的时候会有缓存,除了版本好,commit hash也能保证每次CI编译通过 pod install 来更新flutter-libs依赖产物
完成!!!
1.XCode10.3,CocoaPods1.7.5, Flutter 1.8.4-pre.65(一定是master channel,不能是stable), 根据标题中的环境对应的版本自行升级,如版本高太多的话不敢保证一定会成功。
2.参照官方文档的iOS部分很快就构建好了,于是Commod+B构建,可是马上会遇到第一个坑,如下图:
ld: warning: directory not found for option '-L/Users/wang/Library/Developer/Xcode/DerivedData/test_flutter-dbqsilcpjusqpadpdwvgsoqctumw/Build/Products/Debug-iphonesimulator/FlutterPluginRegistrant'
ld: library not found for -lFlutterPluginRegistrant
clang: error: linker command failed with exit code 1 (use -v to see invocation)
我晕这是什么鬼啊,尝试了各种方式都无效:
怀疑是没有找到静态库 lib(FlutterPluginRegistrant.a),工程目录和flutter_module目录以及flutterSDK的安装目录都搜遍了,也没有发现这个文件。。。。。。
于是怀疑是新版本的Flutter将FlutterPluginRegistrant.a移除了,根本就不存在这个文件,接下来在宿主iOS工程下的Pods目录中的『Pods-test_flutter.debug.xcconfig』文件中搜索" FlutterPluginRegistrant ",果然发现了一些线索
接下来将 带有 『 FlutterPluginRegistrant 』内容的部分全部删除( Pods-test_flutter.debug.xcconfig也如法炮制 ),修改后的配置如下:
接下来Command+B再次构建,奇迹发生了,刚才的错误消失了,继续往下走,
参照官方文档将 Appdelegate.m文件改为如下内容
Command+B走起,然而第二个坑来了,
Undefined symbols for architecture x86_64:
"_OBJC_CLASS_$_GeneratedPluginRegistrant", referenced from:
objc-class-ref in AppDelegate.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
彻底晕倒,这又是什么鬼。。。自习一看才发试一个经典错误,原来是编译期的符号表$_GeneratedPluginRegistrant在链接期间找不到,由于GeneratedPluginRegistrant是在FlutterPluginRegistrant中定义的,这更加说明了FlutterPluginRegistrant.a根本不存在,于是接下去到刚才用命令"flutter create -t module --org com.example flutter_module"构建的 flutter_module 目录中去搜索文件GeneratedPluginRegistrant(mac系统下用finder搜索小伙伴们一定都会了),果然有所收获,在../flutter_module/.ios/Flutter/FlutterPluginRegistrant/Classes/目录下发现了两个文件GeneratedPluginRegistrant.h和GeneratedPluginRegistrant.m,这下就好办了,在宿主工程中把这两个文件添加进来,方式任意,可以reference也可以copy过来。
二话不说马上Command+B构建工程,大功告成!!可以来支烟庆祝一下了!
希望此文可以帮助迷茫中的你走出困境,现在网上关于这个错误的解决方案少之甚少,如果看到这里,此时你的问题已经得到解决了!!
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,导致报错。
如果发现文章中有错误或者有更好的解决方案欢迎指正留言,当然如果本篇文章帮助你解决了问题,也不要吝啬你的感谢。谢谢各位。
1.在项目目录执行 flutter create -t module XXX(flutter模块名) ;
2.修改Podfile,设置path,关联podhelper.rb,注意采用 load File.join() ,不采用之前的eval语句,在target do下install;
3.执行pod install;
4.修改AppDelegate为FlutterAppDelegate;
5.初始化并注册FlutterEngine;
6.vscode里flutter attach实时调试;
做完这些正常开发是可以了,至于打包需要更改什么再续。
售后响应及时
7×24小时客服热线数据备份
更安全、更高效、更稳定价格公道精准
项目经理精准报价不弄虚作假合作无风险
重合同讲信誉,无效全额退款