动态库制作补充

继上一章后Swift Project制作静态Framework ，有两点需要阐明。

1. 动态库到底能不能用，因为很早前动态库导入app不能过审。
2. 如何可以让Demo和库联动，最好能断点调试bug

iOS的动态库（被阉割的动态库）

iOS平台上规定不允许存在动态库，并且所有的 IPA 都需要经过Apple的私钥加密后才能用，基本你用了动态库也会因为签名不对无法加载，(越狱和非 APP store 除外)。于是就把开发者自己开发动态库成为了天方夜谭。 iOS8之前因为 iOS 应用都是运行在沙盒当中，不同的程序之间不能共享代码，并且iOS是单进程的，也就是某一时刻只有一个进程在运行，那么你写个共享库，给谁共享呢。同时动态下载代码又是被苹果明令禁止的，没办法发挥出动态库的优势，综上所以上动态库也就没有存在的必要了。

但是后来iOS8之后，iOS有了App Extesion特性，而且Swift也诞生了。由于iOS主App需要和Extension共享代码，Swift语言机制也需要动态库，于是苹果后来提出了Embedded Framework，这种动态库允许APP和APP Extension共享代码，但是这份动态库的生命被限定在一个APP进程内。简单点可以理解为被阉割的动态库。 但是这种动态库（Embedded Framework） 和系统的 UIKit.Framework 还是有很大区别，传统的动态库是给多个进程用的，而这里的动态库（Embedded Framework）是给单个进程里面多个可执行文件用的。系统的 Framework 不需要拷贝到目标程序中，我们自己做出来的 动态库（Embedded Framework） 哪怕是动态的，最后也还是要拷贝到 App 中（App 和 Extension 的 Bundle 是共享的）。所以苹果没有直接把这种Embedded Framework称作动态库而是叫Embedded Framework。

上面提到跟Swift也有原因，在Swift的项目中如果要在项目中使用外部的代码，可选的方式只有两种，一种是把代码拷贝到工程中，另一种是用动态 Framework。使用静态库是不支持的。这个问题的根本原因主要是 Swift 的运行库没有被包含在 iOS 系统中，而是会打包进 App 中（这也是造成 Swift App 体积大的原因），静态库会导致最终的目标程序中包含重复的运行库。

开始制作SDK（以动态库为例）

1. 将最开始创建的Framework 和 Demo App 放到同一个目录下，并且创建平行级别的WorkSpace
   ，这里WorkSpace的名字需与Demo App相同。如下

   
   
   工程结构

2. 打开WorkSpace，将工程和Framework都导入。注意： 两者为同级关系

   
   
   image.png
   
   
   统计关系

3. 把Framework添加到App工程中

   
   
   导入Framework

4. 运行即可，在Framework打断点也可以进行调试。这里也就实现了断点调试。

5. 如果要导出Framework给别人使用，需要Edit Scheme，将Debug变为Release

   
   
   截屏2024-12-23 14.23.40.png