一、共同点：
两者其实都是静态库。
二、区别
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都使用了同一个三方库，会存在两份三方库，会增加包大小。
![[分布式] ------ 全局唯一id生成之雪花算法（Twitter_Snowflake）](http://pic.xiahunao.cn/[分布式] ------ 全局唯一id生成之雪花算法（Twitter_Snowflake）)
![[分布式一致性协议] ------ raft协议的解释与理解](http://pic.xiahunao.cn/[分布式一致性协议] ------ raft协议的解释与理解)
各类型在服务端的验证规则)
![[线程池] ------ 形象的描述线程池，用一个特好记的例子来记忆](http://pic.xiahunao.cn/[线程池] ------ 形象的描述线程池，用一个特好记的例子来记忆)
