一、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实时调试；
做完这些正常开发是可以了，至于打包需要更改什么再续。
