关于iOS-SDK那些事

• 背景

• 项目构建

• 瘦身

• 注意事项

• 小结

背景

最近一直在负责公司SDK的事宜，随着公司业务的发展，对于有些公司内部可能有许多的项目或者对外有业务上的来往，需要将公司的某一个功能模块或者公共组件打成Framework或着.a来提供给别的项目或者公司来使用，特别是在一些垂直领域如身份证识别，银行卡扫描，视频认证等。

项目构建

本文讲解的是的是基于Cocoapods管理的私有库工程。

工程目录

1. Target构建

Target目录

这里总共建立了 4个 Target，我们逐个进行讲解。

第一个就是我们要构建的Framework

创建时需要选择此处

选择Cocoa Touch Framework

修改生成的 Mach-O格式，因为动态库也可以是以 Framework形式存在，所以需要设置，否则默认打出来的是动态库。将 target->BuildSetting->Mach-o Type设为 Static Library（默认为 Dynamic Library)

Mach-o参数设置

关于底下这些参数我们可以使用默认的

架构参数设置

依赖关系<Link Binary With Libraries>：
1.制作Framework可以包含.a，也可以包含Framework<只需将Framework的.o目标集合文件拖进来>。
2.对于Cocoapods管理的Framework的Target和Single View Application形成的Target是有区别的，Single View Application形成的Cocoapods会为我们自动依赖libPods.a,对于Framework需要我们手动将各个模块的.a添加进来。
3.关于第三方，需要和合作方确定好第三方的版本，对于合作方没有的要协商好是对方给工程中去添加，还是自己在打SDK时一起打进去。

第二个就是我们配合Framework使用的Bundle

创建时需要选择此处

Bundle创建

创建完成后需要将这里的参数修改下

Combine High Resolution Artwork 或 COMBINE_HIDPI_IMAGES
这两项一个是OSX下的名字,一个是iOS下的名字,改为NO才可以存图片,不然存进去是tiff。

从iOS8开始，就可以利用Framework将资源打入进去，这也是优于.a的一个地方，你也可以只需要Framework就可以，但是这里为什么还要单独创建一个Bundle来管理呢？
主要是因为你做出来的SDK可能用于不同的项目，不同的项目对于肤色的要求有变化，这样单独拿出来一套就可以实现对于不同的项目,根据需求可以实现盲操作去替换图片，不需要再去每个私有库中挨个替换。

/**
第一种思路因为[NSBundle mainBundle]拿到的是我们应用的主Bundle，而我们的***.Bundle是其中一部分，因此我们可以先从主Bundle中将我们的
***.Bundle拿出来，然后取资源时将所用的Bundle写成***.Bundle即可。
*/
//返回的是***.Bundle
#define RESOURCE_BUNDLE [NSBundle bundleWithPath:[[NSBundle mainBundle] pathForResource:@"***" ofType:@"bundle"]]
//返回的是UIImage
#define IMAGE(imageName) [UIImage imageNamed:imageName inBundle:RESOURCE_BUNDLE compatibleWithTraitCollection:nil]
//返回的是资源文件路径NSString
#define FILEPATH_STRING(fileName,type) [RESOURCE_BUNDLE pathForResource:fileName ofType:type]

/**
第二种思路可以将Bundle看作一个文件夹在原来我们访问资源的方式上，多加一条路径即可。
*/
UIImage *image = [UIImage imageNamed:@"***.bundle/loadingicon"];
NSString *path = [[NSBundle mainBundle] pathForResource:@"***.bundle/Info" ofType:@"plist"];

当然你也可以两种结合起来使用
这里需要注意：
1.如果你的是xib,storyboard默认是从主Bundle中去找资源，因此你需要在代码里面重新实现下。
2.对于SDK是非常不建议使用xib,storyboard的因为维护成本太高，尤其是在彼此使用的Xcode版本不同兼容的iOS版本不同，有时是需要重新修改参数。

第三个就是我们用来检验Framework，Bundle的Demo

对于此Target我们可以直接依赖Framework,Bundle来检验，这里我们只需要先各自Commad+B后直接将依赖关系添加进来就可以。

Framework添加依赖关系

Bundle添加依赖关系

你也可以在 Podfile中让此 Target和负责打 Framework的Target添加同样的依赖。
建议使用第二种，这样的是直接源码依赖，每次直接运行就可以，第一种还需要每次修改完代码后运行前先 Clear下，因为 Framework是有缓存的，它不参与编译阶段。

第四个就是我们用来负责打包的Aggregate脚本。

这里首先需要说说关于架构的事情。

1、模拟器架构:2种
       i386   : 32位架构      4S ~ 5
       x86_64 : 64位架构      5S ~ 现在的机型
2、真机架构: 3种
       armv7 : 32位架构       3GS ~ 4S
       armv7s: 特殊的架构      5 ~ 5C   <此架构已被Apple废弃掉，因此我们在打SDK时可以不兼容>
       amr64 : 64位架构       5S ~ 现在的机型

关于架构我们可以看官方的这幅图，也看可以从这里查看详情。

架构分布图

接下来就是打包了，其中上面第一个 Target之所以可以使用默认的架构就是因为我们在发给合作方时要提供 Release版本的(因为当前图中模拟器打出来 Debug中只包含当前架构)，关于 Release和 Debug二者的区别这里不做说明，你可能会发现对于 Release和 Debug版本打出的 Framework大小没有多大变化，但是二者提供给合作方之后,对方打出的 ipa大小变化是比较明显的，我这边相差 4到 5M的样子，这个差值如果要让你通过删代码和减小资源来弥补是一件很困难的事情。
下来我们来创建一个 Aggregate

Aggregate创建

添加一个 Run Scipt项

添加Run Scipt

直接可以将底下的脚本粘贴进去,此脚本会在你的工程目录下创建一个 Products文件夹当你构建好之后，会自动 Open。

if [ "${ACTION}" = "build" ]
then
INSTALL_DIR=${SRCROOT}/Products/${PROJECT_NAME}.framework

DEVICE_DIR=${BUILD_ROOT}/${CONFIGURATION}-iphoneos/${PROJECT_NAME}.framework

SIMULATOR_DIR=${BUILD_ROOT}/${CONFIGURATION}-iphonesimulator/${PROJECT_NAME}.framework


if [ -d "${INSTALL_DIR}" ]
then
rm -rf "${INSTALL_DIR}"
fi

mkdir -p "${INSTALL_DIR}"

cp -R "${DEVICE_DIR}/" "${INSTALL_DIR}/"

lipo -create "${DEVICE_DIR}/${PROJECT_NAME}" "${SIMULATOR_DIR}/${PROJECT_NAME}" -output "${INSTALL_DIR}/${PROJECT_NAME}"
open "${SRCROOT}/Products"
fi

打包的流程：
1.先各在模拟器和Generic iOS Device下Command+B一份出来，注意区分Release和Debug模式。

Release和Debug模式

2.然后在相同的模式Release或Debug下去运行Aggregate。
这个是利用脚本去打，我们自己也可以手动利用命令在终端中去实现。
当你打出来后就可以看到下面的模块

Framework包含的模块

你可以使用 lipo -info来查看你的二进制文件包含的框架
其中核心就是 .o 格式的目标集合文件，我们可以使用命令来进行查看

lipo *** -thin armv7 -output ***_armv7
ar -x

首先需要从我们刚刚打出来的包中剥离出来一种架构出来(当然你也可以只Command+B一种架构来)

剥离某一中架构

查看所有的.o文件

查看.o文件

发现这里有个 __.SYMDEF文件

利用cat命令可以查看
cat __.SYMDEF

当执行完后会在终端中输出一大串，会发现这个是我们的类的名称，但不包含Category和Extension的信息，但是你发现在.o中是能找到拓展的，此时是否想到了为什么对于SDK中如果有Category时需要 Build Settings中找到 Other Linker Flags，并加上 -ObjC ，原因就在这里， -ObjC相当于一个标记，告诉在链接阶段要去链接整个.o文件，并非是只链接__.SYMDEF所罗列出来的。

瘦身

如果你的Framework是从主包中脱离出来的一个模块，或者你的Framework已经迭代了好多个版本，难免会有许多的冗余。一般合作方对于包的大小都有要求，因此我们可以从这几个方面去入手。
1.从资源文件下手剔除不必要的资源，如图片，xib ，音视频等。
这里我们可以使用LSUnusedResources,找出Framework中没有使用的资源将其删掉。
2.也可以利用TinyPNG对项目要用的图片进行压缩。
3.可以从项目中的文件入手，利用LinkMap软件可以清晰的看到每个类的大小，这为我们删除类提供了依据，也可以利用上面.o的方法来查看，利用软件更加直观方便。
4.可以通过设置关于打Framework相关参数，如打Release版本的。

注意事项

1.对于Framework中里面建议不要使用hook方法，一般情况下我们用的比较多的就是利用Category去重载系统类的+(void)load方法,然后对某个类的某些方法交换实现，因为+(void)load方法的执行时机是在入口函数main中去执行，它的影响是全局的，这样的话你交换实现的代码就会影响到合作方，或许当你Review此段代码时觉得里面写的恰好给对方没有造成什么影响，代码很健壮而且也没有发现在此处有Crash现象出现过，哈哈，没有出现可能是在你们的项目中没有出现，但是不排除此处的代码放到对方的项目中在某些特定的条件下就没有Crash，如果对方的项目是个日活超过百万级的项目那就比较严重了，假如你是重载交换了UIViewController生命周期的某个方法，想想对方的每个视图出现都要到你这里来转一圈，所以还是存在一定的风险的。
2.由于Objective-C没有命名空间,关于Framework中的命名，一定要按照苹果的命名规范来，否则冲突的可能性还是很大的，一般情况下对于类名大家都能做到规范，但是对于Catergory、Extention或者 extern等，就时常不太严谨,此时如果恰好方法名重复，就会造成方法实现替代的冲突，对于这种情况是发生在运行时的，也就是说如果测试没有覆盖到则可能将此问题附带上线。

我们可以在工程中这样进行搜索Catergory。

项目中搜索类别

小结

1.尽量不要用xib,storyboard不同版本Xcode打包维护成本较高。
2.打包时Xcode版本尽量小于等于合作方的版本,可以避免一些宏找不到的问题。
3.同一份代码使用不同的Xcode版本打出来的大小是不一样的。
4.最终上线时要使用Release版的。
5.命名严格的按照Apple的命名规范来。