静态库、动态库、framework、xcframework、use_frameworks!的作用、关联核心SDK工程和测试(主)工程、设备CPU架构

1.1库的概念

库：程序代码的集合，编译好的二进制文件加上头文件供使用，共享程序代码的一种方式。

1.2库的分类

根据开源情况分为：开源库（能看到具体实现）、闭源库（只公开调用的的接口，是编译后的二进制文件，看不到具体实现，使用时链接即可。）

闭源库分为：动态库.td（之前叫.dylib）或.framework为后缀文件 和 静态库.a或.lib或.framework为后缀文件

.a纯二进制文件，.framework有二进制文件，还有资源文件。

.a 要有 .h 文件以及资源文件配合， .framework 文件可以直接使用。总的来说，.a + .h + sourceFile = .framework。所以创建静态库最好还是用.framework的形式

1.3动态库与静态库的区别 

动态库：编译时只存指向动态库的引用，链接时不复制，运行时由系统只动态加载一次到内存，不影响程序体积，多程序共用节省内存。

iOS App的动态库存放在.app bundle下的Frameworks 文件夹。

iOS平台 在 iOS8 之前，苹果不允许第三方框架使用动态方式加载，从 iOS8 开始允许开发者有条件地创建和使用动态框架，这种框架叫做 Cocoa Touch Framework。 虽然同样是动态框架，但是和系统 framework 不同。（关键字：iOS8+允有条件建和用动态库，CTF与系统f不同）

app 中使用 Cocoa Touch Framework 制作的动态库 在打包和提交 app 时会被放到 app main bundle 的根目录 中，运行在沙盒里，而不是系统中。不同的 app 就算使用了同样的 framework，但还是会有多份的框架被分别签名，打包和加载。

不过 iOS8 上开放了 App Extension 功能，可以为一个应用创建插件，这样主app和插件之间共享动态库还是可行的。

使用原理：

以 OS X 为例，当 App 启动时，操作系统内核会将 App

代码和数据载入新进程(也就是操作系统为 App创建的新进程)的地址空间。与此同时呢，操作系统内核也会把动态加载器(Dynamic Loader)载入进程，由动态加载器来完成加载App依赖的动态库。不过在启动阶段，动态加载器只会根据静态链接器中记录的

App 已链接的依赖库的名字，然后使用依赖库的 install name来查找它们是否在文件系统中存在。如果不存在或不兼容，App启动过程会中断。动态库被完全载入内存，是在代码里使用它的时候。所以相对静态库来说，使用动态库链接的App 启动过程会更快。

优点：

1）不会被加载复制到可执行文件中，按需加载，可以加快App启动。

2）维护更新方便，只要api不变，动态库变更，依赖动态库的App无需重新编译。因为重新编译主要是App的可执行文件部分，而动态库不属于其中，而是独立的，可动态加载。

缺点：有外部依赖，即程序运行期间还需要动态库的存在。

静态库：链接时会被完整的复制到可执行文件中，被多次使用就多次拷贝

编译时被直接拷贝到目标程序的可执行文件

使用原理：App自身的代码被编译成目标文件后，通过静态链接器将App的目标文件与静态库合并，并生成可执行文件。这样，App自身代码生成的目标文件与静态库都被拷贝到可执行文件中，从而让静态库也成为了App可执行文件的一部分。

特点：

1）App启动时就全部加入内存，由于使用的是静态库，不需要从外部链接加载，所以加载速度很快，但是又因为增加了内容过多导致启动速度慢。

2）静态库文件会被静态链接器链接并复制到生成的可执行文件中，导致可执行文件增大，占用内存也会增多

3）由于静态库是制作好的二进制库，如果发生变更，需要重新编译，给维护带来不便。

1.4 查看framework是动态库还是静态库，检查framework支持的架构

.framework可以是动态库也可以是静态库，系统默认设置为Dynamic，如果需要静态库需要在BuildSettings里搜索Mach-O Type改成Static Library  .a静态库  

1.4.1查看framework是动态库还是静态库（xcode6下默认是动态库）

cd framework所在目录

查看framework是动/静态库：

file framework下的二进制文件（一般与framework同名）

 静态库包含“current ar archive random library”字样。动态库包含“dynamically linked shared library”字样

静态库包含“current ar archive random library”字样。动态库包含“dynamically linked shared library”字样

1.4.2检查framework支持的架构

检查framework支持的架构：

lipo -info 该framework名称

要公开的头文件Targets->BuildPhases->Headers可以设置Public暴露在外的头文件、Private、Project

1.4.3实际使用：新建framework

1.新建 项目 选CocoaTouch Framework类型

2.设定Deployment Target部署目标

3.framework默认是动态库，但若不需要使用动态库，可以在build Settings里搜索Mach-O Type设置为Static Library静态库

若必须使用动态库，则需要在类库的工程中的General 或其他位置做如下配置 Embed Framworks（现在Xcode版本里是Embed App Extennsionns） 添加framwork

Linked Binary With Libraries(连接二进制与库) 与  Embedded Framework的区别：前者不会拷贝到 App 里的，Embedded ( 嵌入式的)Framework会拷贝到 App 里。

4.引入源码并设置SDK用户可见的文件然后编译 ，在Build Phases的Headers中设置可见的放在public里，不可见的放在project里

注意：编译后在Products下看到对应framework 若想看模拟器和真机的framework通过show in finder查看后往上层文件夹查看  因为在真机和模拟器下生成的framework只能在各自环境下使用，若真机和模拟器都能用需要将两个framework合并：用lipo -create 模拟器framework路径 真机framework路径 -output 新的文件名

1.5 use_frameworks!的作用

swift项目在platform:ios,'9.0'必须有use_frameworks!作用是把第三方库打包成静态库）

use_frameworks!用于指示CocoaPods将指定的依赖项作为框架（‌frameworks）‌来集成到项目中。支持Swift的框架兼容性，‌因为Swift项目默认使用框架形式组织代码。‌集成一些Swift的库或者需要与Swift兼容的库时，Podfile中使用use_frameworks!告诉CocoaPods不要生成静态库（‌.a文件）‌，‌而是生成框架（‌.framework）‌，‌Swift项目就能更容易地导入和使用这些库。‌

例如，‌如果你的项目中使用了Alamofire或Rac即ReactiveCocoa这样的Swift库，‌你可能会在Podfile中使用use_frameworks!来确保Alamofire以框架的形式被集成到你的项目中。‌这样做的好处之一是它允许你的Swift项目利用Swift的包管理特性，‌如更简单的依赖项导入和更好的模块兼容性。‌

在Swift中调用三方库选中target->General->Linked Frameworks and Libraries点击+添加要用的第三方库

1.6 关联核心SDK工程和测试(主)工程

运行调试闭源库 制作之后运行看效果和调试bug，总不可能每次都接入到要用SDK的工程吧，此时就需要专门的测试工程，可通过以下方式关联SDK和测试工程，Products文件夹下是编译后生成的SDK

方式1.添加Targets选择iOS的Application里的Signle View App 可以取消Include Unit/UI Tests

方式2.创建Workspace工作空间，

通过Add将两个工程都添加进去；

（5.11）Add 一个Target后 再添加另一个Target此时需要Close之前的Target才能选择Add Target到workSpace

创建以SDK命名的类；

点测试工程Targets选Build Phases找到Link Binary With Libraries将SDK与其关联起来；

Build Setting里搜索Header Search Paths的值改成SDK工程路径；

SDK的Build Settings搜索Mach-O Type改成Static Library(.Framework可能静态库或动态库，若默认编译器认为Dynamic库需要改成Static库)

1.7 设备的CPU架构(指令集)

模拟器:

4s-5: i386

5s-6s Plus: x86_64

真机(iOS设备):

armv6: iPhone、iPhone 2、iPhone 3G、iPod Touch(第一代)、iPod Touch(第二代)

armv7: iPhone 3Gs、iPhone 4、iPhone 4s、iPad、iPad 2

armv7s: iPhone 5、iPhone 5c 

arm64: iPhone 5s、iPhone 6、iPhone 6 Plus、iPhone 6s、iPhone 6s Plus、iPad Air、iPad Air2、iPad mini2、iPad mini3 及以上版本

如果打armv7s的 4s机型就不支持了， 打 armv7 的 4s-5s 都能跑

添加armv7架构

1.Architectures现在默认是$(ARCHS_STANDARA)即arm64，点+加上armv7

2.在工程文件和storyboard里都将iOS Deployment Target部署目标改成iOS 8.0（若用到SafeArea要取消使用）

遇到问题:illegal text-relocation非法文本重定位   错误解决

这个问题一般是底层库lib的编译问题。设置Build Settting ->Other linker flag 为 -read_only_relocs suppress 意思就是relocs（重定位） suppress（压制） ,不显示重定位错误

到此问题解决，成功编译出armv7架构。

   如果需要解决，那么armv7上32位的编译问题，上述的other linker就不要改了!!!!，使用下面 

尝试修改xcode中的Generate Position-Dependent Code项改成No.

    如果不能解决问题，修改Build Settings中的Strip style将其置为Non-Global Symbols 。

如果不行的话多试下，All symbols是工程默认，动态库默认为DeBugging Symbols，意思是symbols需要加载以使用Debug模式下的各种错误日志信息，以及定位信息

官方文档中对Strip Style的描述：

Defines the level of symbol stripping to be performed on the linked product of the build. The default value is defined by the target’s product type. [STRIP_STYLE]

   All Symbols - Completely strips the binary, removing the symbol table and relocation information. [all, -s]

   Non-Global Symbols - Strips non-global symbols, but saves external symbols. [non-global, -x]

    Debugging Symbols - Strips debugging symbols, but saves local and global symbols. [debugging, -S]

1.8 xcframework

XCFramework:是2019苹果官方提出的Framework的另一种先进格式，可以更方便的表示多个平台和架构的分发二进制库的格式。

需要Xcode11以上支持。

是为更好的支持Mac Catalyst和ARM芯片的macOS。

和传统的Framework相比:1>可以用单个.xcframework文件提供多个平台的分发二进制文件; 2>与Fat Header相比，可以按照平台划分，可以包含相同架构的不同平台的文件; 3>在使用时，不需要再通过脚本去剥离不需要的架构体系。

第三方个推有用到xcframework

 扩展学习：iOS开发app间账号共享与SDK封装iOS开发之App间账号共享与SDK封装 - 青玉伏案 - 博客园

参考文章：Framework与XCFramework的制作 - 习武的个人博客感谢👍🏻