打包静态库

一、静态库与动态库的区别

静态库格式:.a(iOS8之前), .framework(later iOS8)
动态库格式: .tbd(iOS9), .dylib(iOS9之前),.framework

区别:
静态库和动态库是相对编译期和运行期的:静态库在程序编译时会被链接到目标代码中,程序运行时将不再需要改静态库;而动态库在程序编译时并不会被链接到目标代码中,只是在程序运行时才被载入,因为在程序运行期间还需要动态库的存在。

(1).动态库:多个应用程序共享内存中的同一分库文件,节省内存资源,效率相对较高
(2).静态库需要分别导入
注意:上架不能使用除苹果官方意外提供的动态库


二、创建静态库(以创建.framework为后缀的静态库为例)
1.直接创建静态库 File -> New -> Project ->Framework & Library ,

注意:选择Cocoa Touch Static Library 可创建.a后缀的静态库。

  1. 创建一个类,提供一个方法以及实现。

3.在默认创建的头文件中导入我们新创建的类的头文件,便于我们以后使用该库里面的类时直接导入StaticLibrary.h文件即可。

4.设置需暴露的头文件
工程文件名 -> Targets -> Build Phases -> Headers,将工程中要暴露的头文件拖至Public下:

5.默认编译为动态库,要改为编译成静态库
工程文件名 -> Targets -> Build Settings -> Mach-o Type 改为 Static Library


6.生成静态库
(1)选择64位的模拟器进行编译, 生成模拟器环境下的静态库
(2)选择真机编译,生成真机环境下的静态库

选择Products下的文件,右键Show in Finder进行查看,StaticLibrary.framework即为生成的静态库。


7.选择合适的静态库库导入到工程即可。

注意:(1)在模拟器测试的工程需导入模拟器环境下生成的静态库,在真机上测试的工程需导入真机环境下生成的静态库,不能同时将模拟器环境下生成的与真机环境下生成的相同的静态库导入到同一工程。

(2)若静态库中使用了分类,在导入静态库的时候需要在 工程文件 -> Targets -> Build Settings -> Other Linker Flags 添加-ObjC

8 .合并静态库
我们为了满足导入静态库的工程可同时编译在模拟器环境下以及真机环境下,而不重复的删除与导入模拟器以及真机环境下生成的静态库,我们可以将两种环境生成的静态库进行合并。
打开终端命令工具
  1. 显示静态库信息
           lipo -info 静态库路径  
     2. 合并静态库
            lipo -create 模拟器静态库路径 真机静态库路径 -output 目的路径(如 :/Users/yangqin/Desktop/lib/YQTest,YQTest为合并之后的名称)

注意:
(1)合并之后的大小基本等于合并之前的静态库大小之和,如果上架只需导入真机环境下生成的静态库。
(2)上文模拟器静态库路径为静态中与库同名的文件的路径,如下图:

  1. 将合并之后的生成的文件替换.framework中的与库同名的文件。
  2. 将修改后的.framework库导入到要使用的工程文件中即可使用。


三、在发布环境下生成静态库

上文中生成的静态库是在编译的环境下生成的静态库,我们任然可以在发布的环境下生成静态库。

1.修改编译环境 Edit Scheme  ->  Run  -> Info ->Build Configuration 改为Release

注意:release与debug的区别
(1)debug会保留调试信息,不会优化代码;
(2)release不保留,但是会优化代码,打包出来的文件的代码可能会小于Debug,且运行效率更高

四、向库中添加资源
一般我们静态库中可能会使用一些图片类的资源这时我们需一个设置束,并将图片等资源放入.bundle资源文件中。在使用该静态库时需要将.bundle文件与.framework文件一起导入至工程目录中。
Command + N,选择Resource -> Setting Boundle 创建一个.bundle资源文件。


五、可测试静态库

上述描述的生成静态库方法生成的静态库不能直接运行进行测试,我们需要将其导入另一个工程中才能进行测试。我们可以创建一个直接可用于测试的静态库。

1.commnd + shift + N 创建一个新工程,选择工程文件 -> TARGETS下面的加号,如下图所示:

选择Framework & Library -> Cocoa Touch Framework ,输入库名创建一个库。


创建完成后如下图所示,其余过程与上面生成不可用于测试的静态库一致

注意:
1.如果项目中需要添加动态库,需导入在Targets -> General -> Embedded Binaries下
2.如果打包的静态库使用到了其他的框架,在使用该静态库的工程中,仍然需要导入其他框架

打包成.a为后缀的静态库时,需要把.a的库文件以及相关头文件一起导入工程文件中

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
打包静态库时,如果该库依赖于其他的静态库,那么在打包过程中必须考虑到所有依赖库也被一并包含进来。这通常涉及到以下步骤: 1. **识别依赖库**: 首先,确定你的静态库(假设名为`libA.a`)需要哪些其他静态库。这可能包括操作系统提供的库、第三方库或是你自己项目的其他库。 2. **添加依赖库**: 将这些依赖库(如`libB.a`, `libC.a`等)添加到你的构建流程中。在构建`libA.a`时,你应该能够链接到这些依赖库。这意味着在构建命令中增加相应的库文件路径和名称,如: ``` ar rcs libA.a source_files_in_libA.o gcc -shared -o libA.so -Wl,-Bstatic -lB -Wl,-Bdynamic -lC -o libA.so ``` 或者如果你使用的是静态库,你可能会直接链接它们而不需要生成共享库(`.so`文件): ``` ar rcs libA.a source_files_in_libA.o -lB -lC ``` 这里,`source_files_in_libA.o`表示`libA.a`内部的实际目标文件。 3. **考虑编译选项**: 根据每个库的文档,选择正确的编译选项,以确保依赖库能够在你的平台上正确构建。有时候,某些库需要特定的编译标志来启用或禁用某些特性。 4. **管理库路径**: 如果依赖库不在当前目录下,你需要在编译时指定其完整路径,比如在上述示例中的`-lB`和`-lC`就是指明要链接的库名。 5. **复制文件**: 最终,当`libA.a`被打包时,你需要将所有依赖库也一起复制进最终的发布包内,这样在用户安装或部署此静态库时,所有的依赖都能自动获取和使用。 6. **版本兼容性**: 确保你使用的库版本与你的应用需求相符,并且考虑版本更新带来的潜在变化,如API改变或依赖项的变化。 通过以上步骤,你可以确保在打包静态库时不仅包含了核心功能,还包含了必要的依赖库,使得用户在部署时不必额外寻找或安装依赖库。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值