yaheng

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

该次 [ commit b5262dc](https://github.com/jiisd/YHFlutterAdapter/commit/b5262dc74596d00101bd7903fcb79a38524fbddf) 就是解决的这个问题哈，多谢反馈🤝

现在 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...

OK，我们现在的使用方式就是【把产物 pod 推到私有仓库，主工程 podfile 直接版本号依赖】的方式，但是只有发版之后的稳定版本才会打 tag，那个验证不过的问题有下面几种策略可以屏蔽该验证，但也只限于这种纯产物库的修改，别的私有库建议还是要保证能够通过验证。 1. 按照 pod 仓库的索引规则建立对应的目录结构和文件，git push 推上去即可； 2. 自己创建一个新的 SDK 工程，把对应的调用接口的地方调整为空实现，然后自己生成一个 i386 的库（说白了就是个为了验证通过的空壳子而已），用 lipo 命令合并到对应的库中； 3. [直接修改验证的 validator.rb 文件源码](https://www.jianshu.com/p/9d32368ae3b2)；

首先感谢对该工具的关注。 关于疑问中提到的对比数据的问题，最近和设计朋友对接核实，我们将目前项目中已经使用了 PDF 类型的素材图重新导出 PNG 格式的文件再次进行详细的对比，发现这种情况下 PDF 文件大概为 PNG 格式图标文件大小的 1/3 ~ 1/2 左右。对于 DEMO 中的对比，是使用原项目中已经存在的素材直接拿出来对比的结果，没有进行更多的比较从而得出了不具有普遍代表性的数据，是笔者的失误。 目前在我们的具体项目使用过程中，同时也发现并不是所有的素材图都适合使用 PDF 文件代替，像刚提到的复杂的切图，或者有局部半透明的图片，例如下面的图标：  这时候就使得 PDF 格式出图不会那么的灵活，还是使用 PNG 格式出图更为方便（PS:设计基友给的原话👀） 简单来说对于常规 APP 中大多数的不复杂的图标或者简单的单色图标(例如3D Touch)来说使用该工具还是很方便的。

任何方案都有一些客观的优缺点，就像 SVG 的素材资源也很小，但加载复杂图像内存飙升、耗时较久，使用 PDF 对于简单图标的加载，并且显示尺寸并非固定的场景相对来说还是比较实用的，如果是内容元素比较多的素材确实不建议使用 PDF 方案，需要根据自己的需求场景衡量。

目前开源分享的重点在于混合开发的集成思路，这个示例程序中的 `yh_demo_page ` 就是在 Dart 代码中的简单匹配，通用界面路由跳转相关的逻辑还在整理中🙂

只是为了跑 Demo 的话，可以将 Podfile 中的依赖更改为本地形式，再执行 pod install ``` pod 'YHFlutterSDK', :path => '../YHFlutterSDK' pod 'YHFlutterAdapter', :path => '../YHFlutterAdapter' pod 'YHFlutterPlugin', :path => '../YHFlutterPlugin' ```