制作framework遇到的问题与总结

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.承载的内容范畴：

(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不用去管

本人是使用第二种方法解决遇到的问题