重点参考链接：
制作动态及静态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}"
fi
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工程子目录中)。
2.2.2 framework中依赖的系统库，在业务工程中也必须引用
framework中依赖的所有系统库，在业务工程中也必须引用，不然就会报错。
3 参考链接
framework的合并
http://blog.csdn.net/smking/article/details/24434819
WWDC2014之iOS使用动态库framework
http://blog.csdn.net/yongyinmg/article/details/41517665
Xcode编译链接问题汇总(持续更新中....)
http://blog.csdn.net/nogodoss/article/details/46048417
