【IOS开发进阶系列】Framework制作专题

江中散人_Jun

发布于 2023-10-16 11:38:33

4660

发布于 2023-10-16 11:38:33

文章被收录于专栏：云原生布道专栏

重点参考链接：

制作动态及静态Framework

http://blog.csdn.net/yongyinmg/article/details/41513917

http://years.im/Home/Article/detail/id/52.html

有没有写SDK或者要将一些常用的工具类做成Framework的经历? 你或许自己写脚本完成了这项工作，相信也有很多的人使用 iOS-Universal-Framework ，随着xCode6的发布，相信小伙伴们已经都知道了，xCode6支持做Framework了. 同时iOS-Universal-Framework开发者也宣布不在继续维持此项目的开发，建议开发者使用xCode6制作，目前网上也有很多制作iOS Framework的资料，但大多都不够详细，接下来本文会详情介绍一下在xcode6下制作iOS Framework.

关于静态库和动态库的概念，网上资料很多，这里不做叙述，只讲解制作过程。

1 Framework使用

1.1 制作步骤

1.1.1 创建iOS动态库

新建工程并选择默认Target为Cocoa Touch Framework, 如图:

做编码工作，在这里我简单的写了一个Utils的类，并写了一个log方法

设置开放的头文件:Framework中有些类可能是一些私有的辅助工具，不需要使用者看到，在这里只需要把开放出去的类放到Public下, 如图

这样生成的Framework的Headers目录下也只能看到Public的头文件

编码完成之后，直接Run就能成功生成Framework文件了，选择xCode->Window->Organizer->Projects->Your Project, 打开工程的Derived Data目录，这样就能找到生成的Framework文件了，如图:

1.1.2 新建测试工程，使用生成的Framework

将Framework文件导入到测试工程，调用Framework中的代码

MyUtils *utils = [MyUtils new];

[utilslog:@"didFinishLaunchingWithOptions"];

运行报错(Reason: Image Not Found)：

为什么会这样的？因为我们做的是动态库，在使用的时候需要额外加一个步骤,要把Framework同时添加到‘Embedded Binaries’中：

注意: 在xCode6之前是没有这个选项的(我没发现)，所以理论上xCode5及之前的版本无法使用xCode6下生成的Framework动态库。

到这里，假定你整个过程都是使用的模拟器做的，那看上去会很顺利。这时候尝试将测试工程部署到真机上，问题来了：

ld: warning: ignoring file/work/ios/MyFrameworkTest/MyFrameworkTest/MyFramework.framework/MyFramework,file was built for x86_64 which is not the architecture being linked (armv7):/work/ios/MyFrameworkTest/MyFrameworkTest/MyFramework.framework/MyFramework

Undefined symbols for architecture armv7:

"_OBJC_CLASS_$_MyUtils", referenced from:

objc-class-ref in AppDelegate.o

ld: symbol(s) not found for architecturearmv7

clang: error: linker command failed withexit code 1 (use -v to see invocation)

为什么会这样？错误提示已经很明显了，因为我们制作动态库的时候，选的设备是模拟器，如果选真机的话，那生成的库也只能在真机上使用，那我们该怎样制作一个通用的动态库呢? 简单的方法是分别生成模拟器和真机上运行的库，然后在合并，这个方法，在每次生成动态库的时候，过程都会很繁琐，下面我们用一个脚本来自动完成它。

1.1.3 制作通用动态库

新建Aggregate Target

添加script到新建的Target

# Sets thetarget folders and the final framework product.

# 如果工程名称和Framework的Target名称不一样的话，要自定义FMKNAME

# 例如: FMK_NAME = "MyFramework"

FMK_NAME=${PROJECT_NAME}

# Install dirwill be the final output to the framework.

# The followingline create it in the root folder of the current project.

INSTALL_DIR={SRCROOT}/Products/{FMK_NAME}.framework

# Working dirwill be deleted after the framework creation.

WRK_DIR=build

DEVICE_DIR={WRK_DIR}/Release-iphoneos/{FMK_NAME}.framework

SIMULATOR_DIR={WRK_DIR}/Release-iphonesimulator/{FMK_NAME}.framework

#-configuration ${CONFIGURATION}

# Clean andBuilding both architectures.

xcodebuild -configuration "Release" -target "${FMK_NAME}" -sdk iphoneos clean build

xcodebuild -configuration "Release" -target "${FMK_NAME}" -sdk iphonesimulator clean build

# Cleaning theoldest.

if [ -d"${INSTALL_DIR}" ]

then

rm -rf"${INSTALL_DIR}"

mkdir -p"${INSTALL_DIR}"

cp -R "

# Uses the LipoTool to merge both binary files (i386 + armv6/armv7) into one Universal finalproduct.

lipo -create"{SIMULATOR_DIR}/{FMK_NAME}"-output "{INSTALL_DIR}/{FMK_NAME}"

rm -r "${WRK_DIR}"

open"${INSTALL_DIR}"

选中新建的Target，Run, 如果没有异常的话，会自动弹出生成的Framework文件

这样生成的动态库就能同时支持模拟器和真机了

1.1.4 xCode6下制作通用静态库

上面我们也提到了，这样生成的动态库恐怕很难在xCode5上使用，那我们为什么非要用动态库呢，一般情况下不是用静态库就好了吗？ So Easy!只需要修改一个参数即可生成静态库了。

使用静态库的话，就可以把Framework从‘Embedded Binaries’中删除了。亲测在xCode5下可用。把新生成的库导入到测试工程，试试在模拟器和真机上运行，一切OK。

不巧，如果你用的真机是iPhone5 C, 那悲剧又要发成了，生成的Framework竟然不支持armv7s,不知是xCode6的bug，还是因为苹果认为使用armv7s的设备太少，可以不支持了.xCode6新建工程，默认的Architectures竟然不包含armv7s。

想要生成的库支持armv7s,把armv7s添加到Architectures中，重新生成Framework即可

判断一个Framework支持哪些架构

我们该怎么验证生成的Framework支持哪些平台呢，总不能一个个测试吧？当然不用。下面的命令是加上armv7s前后生成的framework的对比：

Yearsdembp:Products Years$ lipo -info ./MyFramework.framework/MyFramework

Architectures in the fat file: ./MyFramework.framework/MyFramework are:i386 x86_64 armv7 arm64

Yearsdembp:Products Years$ lipo -info ./MyFramework.framework/MyFramework

Architectures

in the fat file: ./MyFramework.framework/MyFramework are: armv7 armv7s i386

x86_64 arm64

2 使用问题

2.1 多Framework工程引用正确方式

2.1.1 多Framework工程引用原理机制

Framework工程依赖关系举例：

b.f依赖于a.f

C.f依赖于a.f

d.f依赖于a.f, b.f, c.f

业务工程test.proj

如果直接在业务工程中引用这些工程生成的framework，那么每个framework都会直接把依赖库也引入进来，因为b/c彼此的共同依赖关系并没有梳理，从而造成同一个framework被多次重复引用。

所以对于此种情况，即便是b.f工程内部，也不能直接引用a.Framework生成的库，而应该通过添加在TargetDependencies添加的方式来进行引用，这样，a/b/c/d库的依赖关系在编译时能得到统一梳理，避免重复引用问题。

2.1.2 Framework的正确添加方法(不行，未解决重复引用问题)

直接在Link Library With Libraries一项中新增Framework文件的方法不可取，在引用存在依赖关系的几个库时，回报大量duplicate symbol重复标识错误。

正确引用方法是：

1、直接将工程拖入 “LinkLibrary With Libraries”一栏，然后在Target Dependencies一栏添加Framework引用。

2、在业务工程中添加所有Framework依赖的系统库；

3、在Header Search Paths中补充framework工程引用目录(对于上一层的使用../testFramework，recursive选项)；

正确添加方法示意图：

Framework Search Paths路径添加项：

Header Search Paths路径添加项：

错误添加方法示意图：

2.1.3 引用单Framework工程方法(ok)

直接将Framework工程的Products目录下构建的*.framework库拖入目标工程的拖入 “LinkLibrary With Libraries”一栏即可，即使该framework也引用了其他framework，也不需要额外添加，仅添加这一个framework即可。

如果直接将framework工程拖入LinkBinary With Libraries一项，编译时就会报错：

Undefined symbols forarchitecture arm64

2.2 多工程引用问题

2.2.1 基于多Framework工程的引用导致duplicatesymbol的问题

对于存在多个通用工程，且通用工程内部存在彼此依赖的关系时，如果在一个业务工程中直接以LinkBinary With Libraries的形式引用Framework，会导致duplicatesymbol重复引用的问题，例如：

b.f依赖于a.f

C.f依赖于a.f

d.f依赖于a.f, b.f, c.f

而test.project直接以Link Binary With Libraries的形式引用d.f工程生成的framework时，就会导致重复引用问题，原因也很简单，因为b.f编译生成framework时引入了a.f时，而c.f编译时也会引入a.f，由此在d.f中同时引用b.f与a.f时，就会造成循环引用问题了。

解决方案是：

在各个工程中引用依赖framework工程时，只声明在TargetDependencies中(这需要将依赖工程置于当前Framework工程子目录中)，也在d.f工程的TargetDependencies中引入a/b/c的生成Framework(这也需要将依赖工程a/b/c置于当前d工程子目录中)。而在业务工程buss.proj中引用d_build(这也需要将依赖工程d置于当前buss工程子目录中)。