jiisd/YHFlutterAdapter

pod lib lint 将产物更新至私有库, i386 验证不通过问题讨论

Opened this issue · 7 comments

plugin 原生代码部分 无法依赖 到 flutter.framework 的头文件哦~~

jiisd commented

部分版本的 CocoaPods 会出现 'Flutter/Flutter.h' file not found,该问题已经修复,请更新至最新代码🙂

我的意思是 lint不过的 不是podinstall

jiisd commented

该次 commit b5262dc 就是解决的这个问题哈,多谢反馈🤝

只要依赖了 Flutter.framework 理论上就无法lint过了 因为lint 要检查i386架构,但是flutter.framework不支持i386

jiisd commented

现在 Demo 里面随带的是 release 版本的产物,具体包含的架构细节如下,如果只是为了查看 Demo 效果,建议使用真机运行。

Flutter.framework/Flutter: Mach-O universal binary with 3 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [arm64]

App.framework/App: Mach-O universal binary with 2 architectures: [arm_v7:Mach-O dynamically linked shared library arm_v7] [arm64]

这也只是个技术方案样例探讨~

实际开发过程中可以在类似于 YHFlutterSDK 对应的 pod 仓库内使用不同的分支来存储 debug 或者 release 版本的产物包,业务方自身选择性的生成更新并指向自己需要的,或者新创建一个单独维护自己业务线的 YHFlutterSDK 仓库都是可以的。

恩,感谢回复,按照你说的做的话,那主工程只能通过git地址加branch的方式 依赖 产物pod了,不能有效的进行版本管理。 我的想法是每次完成产物,把产物pod 推到私有仓库,主工程podfile直接版本号依赖就好。 现在是pod lib lint 一定会检查i386架构,所以一直过不去

jiisd commented

OK,我们现在的使用方式就是【把产物 pod 推到私有仓库,主工程 podfile 直接版本号依赖】的方式,但是只有发版之后的稳定版本才会打 tag,那个验证不过的问题有下面几种策略可以屏蔽该验证,但也只限于这种纯产物库的修改,别的私有库建议还是要保证能够通过验证。

  1. 按照 pod 仓库的索引规则建立对应的目录结构和文件,git push 推上去即可;
  2. 自己创建一个新的 SDK 工程,把对应的调用接口的地方调整为空实现,然后自己生成一个 i386 的库(说白了就是个为了验证通过的空壳子而已),用 lipo 命令合并到对应的库中;
  3. 直接修改验证的 validator.rb 文件源码