Reason: image not found。错误原因为加载framework失败。如果直接搜索image not found,得到的解决办法无非就是在build phases中将*.framework的status改为optional。方法虽然不会再报此错, 但是当framework中有categories时,在使用categories中的方法后,却又会产生unrecognized selector sent to class的crash。因此,此方法不适合解决包含有categories的framework。
经过大概一天的摸查,得到解决信息如下:
1. framework默认为dynamic library, 将framework工程中,build settings中的mach-o type改为static library。前提是framework中未引用其他的原生dynamic library。如:libsqlite3.0.tbd等,否则编译无法通过
2. 在使用framework的项目工程中,加入framework到embed frameworks。加入步骤为:General-->先删除Linked Frameworks and Libraries中该framework-->Embedded Binaries中加入该framework,此时 Linked Frameworks and Libraries中产生的framework不用去管
本人是使用第二种方法解决遇到的问题
经过大概一天的摸查,得到解决信息如下:
静态库
链接时完整地拷贝至可执行文件中,被多次使用就有多份冗余拷贝。
动态库
链接时不复制,程序运行时由系统动态加载到内存,供程序调用,系统只加载一次,多个程序共用,节省内存。
总结来说:其实就是加载时机和加载次数的不同。
1.承载的内容范畴:
(1)StaticLibrary的产出物只是一个.a文件,为二进制执行文件。分享给别人的时候,头文件、静态资源文件需要另外提供。
(2)Framework为一站式分享方案,其实是一个文件夹,其中包含代码签名、头文件、二进制执行文件、静态资源文件等。
2.头文件搜索路径的区别:StaticLibrary需要设置头文件搜索路径,Framework不需要。
3.当存在对外部代码库依赖的时候
(1)StaticLibrary:能够只引用外部库的头文件,调用外部库的公开方法,而不引入其库实现,实现与引用库的分离部署。
(2)Framework:要引用一个外部库,就必须要将此外部库的实现放入Framework内编译才可以。如果要想达到StaticLibrary的效果,可以使用运行时方式调用。
4.运行环境(对3的理解升级)
(1)StaticLibrary:共享其运行环境,假如其运行环境中包换库中同一个类,会发生代码冲突,必须剥离其中一方的此类,然后共享此类。
(2)Framework:与其运行环境隔离,假如其运行环境中包换库中同一个类,不会发生冲突,同名的两个类会在各自的环境中独立运行,互不干扰,哪怕是单例类。
5.综合3和4,现总结在多方合作开发的时候,负责库实现的人员,如何选择使用Framework还是StaticLibrary
(1)假如不想在同一个App中包含多份三方库(减小包大小),可以使用StaticLibrary,库本身和App共享第三方库。但是产出物的结构可能会比较乱。
(2)假如不想考虑和App的代码冲突问题,库本身独立使用需要的库,想提供比较好的库结构,可以使用Framework。但是假如库本身和App都使用了同一个三方库,会存在两份三方库,会增加包大小。
1. framework默认为dynamic library, 将framework工程中,build settings中的mach-o type改为static library。前提是framework中未引用其他的原生dynamic library。如:libsqlite3.0.tbd等,否则编译无法通过
2. 在使用framework的项目工程中,加入framework到embed frameworks。加入步骤为:General-->先删除Linked Frameworks and Libraries中该framework-->Embedded Binaries中加入该framework,此时 Linked Frameworks and Libraries中产生的framework不用去管
本人是使用第二种方法解决遇到的问题