iOS SDK 开发整理

iOS SDK基础

What?

SDK 开发就是写一堆代码,然后将这些代码打包成一个二进制文件,配合头文件和资源文件,给到别人直接使用。

Why?

  • 对外输出 SDK

如OCR技术、面部识别、声纹识别等功能含有大量专利、商业机密代码,需要打包、混淆后才能提供给外部集成。

  • 内部组件化

依赖管理、加速编译。

How?

相关链接:

iOS 静态库与动态库

知识准备

这里我们来复习下 C 语言的基本功,编译和链接:

  • 编译 Compile: 将我们的源代码文件编译为目标文件;
  • 链接 Link: 将我们的各种目标文件加上一些第三方库,和系统库链接为可执行文件。

由于某个目标文件的符号 ( 可以理解为变量,函数等 ) 可能来自其他目标文件,其实链接 Link 这一步最主要的操作就是 决议符号的地址。

  • 若符号来⾃静态库 ( 本质就是 .o 的集合包 ),将其纳⼊链接产物,并确定符号地址。
  • 若符号来⾃动态库,打个标记,等启动的时候再说 --- 交给 dyld 去加载和链接符号。

相关链接:

归类图

tree

静态库 Static Library

静态库即静态链接库。之所以叫做静态,是因为静态库在编译的时候会被直接拷贝一份,复制到目标程序里,这段代码在目标程序里就不会再改变了。

静态库的好处很明显,编译完成之后,库文件实际上就没有作用了。目标程序没有外部依赖,直接就可以运行。当然其缺点也很明显,就是会使用目标程序的体积增大。

一堆目标文件 ( .o / .obj ) 的打包体

静态库本质上就是一堆函数的集合,所以把相关文件编译成 .o 文件之后,就可以使用 ar 来把这些文件集合成 .a 文件。

下面来个简单的例子演示静态库SDK开发流程:

//例如我们有两份代码文件,需要封装成静态库。 log.c memory.c //把相关文件编译成 .o 文件 ➜ clang -c log.c -o log.o ➜ clang -c memory.c -o memory.o //把 log.o 和 memory.o 塞进 libmylib.a 里面 ➜ ar rcs libmylib.a log.o memory.o

当你生成好 libmylib.a 之后, 编写了一份声明函数接口的头文件 mylib.h,一起发给调用方小伙伴;

调用方小伙伴把 libmylib.amylib.h 放入路径 /my/lib/path

然后写了个 demo.c 调用我们封装好的库,这样把它加进去做编译后的链接:


//把编译好的 libmylib.a 给 demo.c 链接出,输出最终可执行文件 demo.run ➜ clang -o demo.run demo.c -lmylib -L/my/lib/path

当然实际情况没有这么简单,我们 iOS 项目中的库实际上是多种硬件框架(arm64, i386, x84_64 等)编译结果的集合,这种库叫 Universal Binary / Fat Library

可以用过 file 命令查看:


➜ file XXXXXXSDK XXXXXXSDK: Mach-O universal binary with 5 architectures: [arm_v7:current ar archive] [arm64] XXXXXXSDK (for architecture armv7): current ar archive XXXXXXSDK (for architecture armv7s): current ar archive XXXXXXSDK (for architecture i386): current ar archive XXXXXXSDK (for architecture x86_64): current ar archive XXXXXXSDK (for architecture arm64): current ar archive

相关链接:

动态库 Dynamic Library

1. Dynamic Framework

动态库即动态链接库。与静态库相反,动态库在编译时并不会被拷贝到目标程序中,目标程序中只会存储指向动态库的引用。等到程序运行时,动态库才会被真正加载进来。

动态库的优点是,不需要拷贝到目标程序中,不会影响目标程序的体积,而且同一份库可以被多个程序使用(因为这个原因,动态库也被称作共享库)。同时,运行时才载入的特性,也可以让我们随时对库进行替换,而不需要重新编译代码。动态库带来的问题主要是,动态载入会带来一部分性能损失,使用动态库也会使得程序依赖于外部环境。如果环境缺少动态库或者库的版本不正确,就会导致程序无法运行。

系统提供的 Framework 都是动态库,比如 UIKit.framework,具有所有动态库的特性。

2. Embedded Framework

这又是啥??为什么会有这个东西?

我们的苹果爸爸在 iOS 平台上规定不允许存在动态库,并且所有的 IPA 都需要经过苹果爸爸的私钥加密后才能用,基本你用了动态库也会因为签名不对无法加载,(越狱和非 APP store 除外)。于是就把开发者自己开发动态库掐死在幻想中。

直到有一天,苹果爸爸的 iOS 升级到了 8,iOS 出现了APP Extension,swift编程语言也诞生了,由于 iOS 主 APP 需要和 Extension 共享代码,Swift 语言的机制也只能有动态库,于是苹果爸爸尴尬了,不过这难不倒我们的苹果爸爸,毕竟我是爸爸,规则是我来定,我想怎样就怎样,于是提出了一个概念Embedded Framework,这种动态库允许APP 和 APP Extension共享代码,但是这份动态库的生命被限定在一个 APP 进程内。简单点可以理解为 被阉割的动态库。

Embedded Framework,这个是用户可以制作的“动态库”,它是受到 iOS 平台限制(签名机制和沙盒机制限制)的动态库,它具有部分动态特性,比如:

  • Embedded Framework 可以在 Extension可执行文件 和 APP可执行文件 之间共享,但是不能像系统的动态库一样,在不同的 APP(进程) 中共享

  • 系统的 Framework 不需要拷贝到目标程序中,Embedded Framework 最后也还是要拷贝到 APP 中。

本质上讲,Embedded Framework 是动态库,他只是我们给动态库起的一个别名!!!

Embedded Framework 创建详细过程:

参考链接:Xcode10制作 framework详细步骤及坑说明

Xcode创建的静态库和动态度二者使用过程中的差异比较

  • Xcode 配置

Embedded Framework 需要额外的在 Xcode 中进行动态库配置,添加到 Embedded Binraries内。否则会出现 dyld: Library not loaded 错误。

  • ipa 包中表现

二者在 ipa 包中表现也不一致。

静态库和源代码一起,打成一个二进制文件 FrameworkDemo;

而动态库单独放在一个文件夹 Frameworks 中:


➜ FrameworkDemo.app tree . ├── Base.lproj │ ├── LaunchScreen.storyboardc │ └── Main.storyboardc ├── FrameworkDemo //静态库和源码一起被打成 APP 主体的二进制文件了 ├── Frameworks │ └── EmbeddedFramework.framework //动态库单独放在 Frameworks 文件夹下 │ ├── EmbeddedFramework │ ├── Info.plist │ └── _CodeSignature │ └── CodeResources ├── Info.plist ├── PkgInfo └── _CodeSignature └── CodeResources 7 directories, 13 files

动态库和静态库的判断 -- file 工具

动态库


➜ EmbeddedFramework.framework git:(master) ✗ file EmbeddedFramework EmbeddedFramework: Mach-O 64-bit dynamically linked shared library x86_64

静态库


➜ StaticFramework.framework git:(master) ✗ file StaticFramework StaticFramework: current ar archive random library

Framework

Mac OS / iOS 平台,.Framework 仅仅是一种打包方式。和静态库动态库没有直接关系。

标签:framework, dynamic, static