让 Objetive-C 库支持 Swift Package Manager
这篇文章主要讲述两个知识点（ps.标题有个拼写错误，非常抱歉）
Objective-C源码库支持Swift Package Manager将源码打包成 XCFramework支持Swift Package Manager(目前Swift5.3还没正式发布这个功能只能在Beta版本测试)
这两个方面我都按照实际的例子进行讲解
将 Objective-C 项目库支持 Swift Package Manager
Swift Package Manager这个东西之前不温不火，是因为竟然只能在命令行才可以使用，这就导致了iOS的项目一直用不了。
据我所知应该是在Xcode11.4版本支持了对于iOS项目的支持，我们公司新项目是5月25号启动的。我就使用最新的Swift5.2语法+Cocoapods进行托管。
但是随着项目的第一个版本的完善，虽然只有大概写了2万行的代码。可以麻雀虽小，五脏俱全。老板需要让项目进行模块化分离，好用于将来的项目。
最近几年的WWDC我一直都在关注,但是因为视频都不支持中文字幕，我只能在Youtube进行观看，让英语自动翻译成中文。后来幸亏有了小专栏的WWDC内参，虽然我也第一时候看了很多Session，但是还是没有大神分析的到位。
对于模块化分离，对于之前的做法就是做成Cocoapods私有库，但是我觉得制作Cocoapods私有库十分的麻烦，对于前期的代码修改和新建新增或者删除来说。
我想着iOS既然已经支持了Swift Package Manager那么我就用这个分离模块。
上图就是我们项目目前的工程结构。
我们目前所做的就是内部的数据收集平台，我当时想着用Cocoapods还是Swift Package Manager做的时候，因为我共项目分离的网络库等都是基于Swift Package Manager，我也只好硬着头皮用Swift Package Manager来做这个数据收集平台。
我们的数据收集平台需要获取到设备的唯一ID，而且对于重新安装不能发生改变。我在网上找Swift的库没找到，只看中了一个四年前写的OC库MFSIdentifier[1]。
这个MFSIdentifier库只支持Cocoapods进行集成，但是我的数据收集的库不是Cocoapods托管的也没有办法像之前直接依赖第三方。
那么能不能把OC的库用Swift Package Manager进行托管，我的库进行依赖呢。答案是肯定，是支持的。
经过几天的一直查询资料和实验，终于找到一种方法，让我把MFSIdentifier这个库进行托管实验成功。
这中间离不开著名库的思路，比如SDWebImage[2]。
我们将MFSIdentifier和所依靠的库下载到本地，目录如下。
你为我为什么要都在一个目录，因为这是经验，为了更好的做本地依赖。
我们先从最底层依赖MFSJSONEntity开始支持Swift Package Manager。
我们在MFSJSONEntity这个目录下面执行下面的命令，对于快速到对应目录打开终端，强力推荐Go2Shell这个软件，谁用谁知道。
swift package init --name MFSJSONEntity
执行完毕，对应目录如下。
我们把自动生成的Sources这个目录删除，因为存在源文件目录，我们不能尽量不要破坏之前的目录结构。
我们用最新的Xcode正式版本(目前最新11.6)打开Package.swift这个文件。
你会发现Xcode没有任何的Scheme，这是因为源文件目录被我们删除了，因为缺少删除了源文件导致的，所以不要慌。
我们修改Package.swift文件，增加一行，来指明源文件的路径。
此时我们的库已经可以编译了，不要忘记删除MFSJSONEntityTests.swift自动生成的测试用例，不然会报错。
虽然编译通过了，但是我们的库里面任何Api都没有，这到底是怎么一回事呢？为了这个疑问，当时我可是查询了很久。
Swift Package Manager的Target有一个叫做publicHeadersPath的参数，是需要设置暴露的头文件的。
我们新建一个文件夹叫做include，把需要暴露的头文件都复制到里面，我们再次修改Package.swift文件。
我们在看看我们的库
已经自动生成我们暴露头文件的类和方法，但是为什么我们添加了include文件夹之后，就连Package.swift都没修改就可以了，一定满脸疑问吧。
因为publicHeadersPath默认的地址就是就是path/include，默认path的路径是Sources/package_name。现在我们修改了，那么现在publicHeadersPath的默认路径就变成了MFSJSONEntity/include。
你们是不是也发现了，include文件夹的头文件是我们复制过来的。但是对于需要改动头文件难道还要我们重新的复制，这样的维护也太糟糕了。
我是在SDWebImage这个库发现这个秘密的，下载下来看到是替身。我就开始用替身，发现不行，后来我才知道这是Liunx的软连接。
我们在终端到include这个目录，并删除之前复制的头文件。
我们执行下面的命令创建一个软连接
ln -s ../MFSJSONEntity.h MFSJSONEntity.h
我们将所有我们需要公开的头文件创建软连接，创建之后的目录结构如下。
此时我们发现我们的库已经会自动生成类和方法，这样以后修改维护起来是不是就十分方便了。
MFSJSONEntity这个库支持完毕之后，我们开始修改MFSCache这个库支持。具体的操作和MFSJSONEntity是一样的，只有一部分做了修改。我只说一下做了修改的地址。
将源代码文件全部放在同一个文件夹
修改前
image-20200819161954674 修改后
image-20200819162250503 Package.swift的内容image-20200819170852791 我们按照同样的方法将
MFSIdentifier也支持Swift Package Manager。MFSIdentifier这个我就不细说了，不懂的可以留言。
将二进制库支持Swift Package Manager(beta)
⚠️因为对于二进制的支持只有在Swift5.3版本才支持，所以我们这个功能在目前正式版本还不支持。
我的数据上报库需要在底层将数据上报到UMeng平台，但是UMeng是二进制，对于Swift Package Manager的二进制支持只能用未来将要发布的XCFramework支持了。
对于将源代码和现有的库转成XCFramework十分的简单，只需要用我写的转换程序XCFrameworkBuild。
XCFrameworkBuild
这个库可以支持将源代码打包成XCFramework和将现有的Framework和.a转成XCFramework的格式。
安装
brew install mint
mint install josercc/XCFrameworkBuild@master xcbuild -f
使用
使用说明请查看说明文档[3]
将现有的库支持Module
我们下载的UMeng的库目录如下
我们看到UMengCommon这个库并不支持Module
我们在和Headers目录下面创建文件夹Modules在Modules下面创建module.modulemap文件。
我们用Xcode编辑module.modulemap如下
framework module UMCommon {
umbrella header "UMCommon.h"
export *
module * {export *}
}
对于这个库来说，还是没有支持。因为主目录下面都是软连接方式，我们也创建Modules软连接到主目录。
我们将UMCommon所需要暴露的头文件写在UMCommon.h文件里面
#import <UMCommon/UMConfigure.h>
#import <UMCommon/MobClick.h>
#import <UMCommon/UMRemoteConfig.h>
#import <UMCommon/UMRemoteConfigSettings.h>
制作XCFramework
我们新建一个工程，将制作出来的UMCommon.xcframework拖拽到工程看一下效果。
支持Swift Package Manager
当导入显示
Module不存在时候请一定清理DerivedData，我就傻傻的怀疑做了很多实验，导致我精神失常了，都开始怀疑人生了。
新建一个Swift Package Manager的库，目录结构如下。
我们修改Package.swift
// swift-tools-version:5.3
// The swift-tools-version declares the minimum version of Swift required to build this package.
import PackageDescription
let package = Package(
name: "MyLibrary",
products: [
// Products define the executables and libraries produced by a package, and make them visible to other packages.
.library(
name: "MyLibrary",
targets: ["UMCommon"]),
],
dependencies: [
// Dependencies declare other packages that this package depends on.
// .package(url: /* package url */, from: "1.0.0"),
],
targets: [
// Targets are the basic building blocks of a package. A target can define a module or a test suite.
// Targets can depend on other targets in this package, and on products in packages which this package depends on.
.binaryTarget(name: "UMCommon", path: "UMCommon.xcframework"),
.testTarget(
name: "MyLibraryTests",
dependencies: ["UMCommon"]),
]
)
我们在测试文件调用
import XCTest
import UMCommon
final class MyLibraryTests: XCTestCase {
func testExample() {
// This is an example of a functional test case.
// Use XCTAssert and related functions to verify your tests produce the correct
// results.
MobClick.event("")
}
static var allTests = [
("testExample", testExample),
]
}
支持作者
这篇文章来自于 《君赏的百味书屋(iOS开发心得)》，这个专栏由君赏负责维护，他是一位有着七年多iOS开发经验的 iOS 开发工程师，有比较丰富的经验。同时他也对独立开发，自动化涉及比较多，也喜欢研究一些围绕iOS比较偏知识。
这个专栏是君赏个人技术博客，用来分享平时开发的技术难点和学习心得，每一篇都用心去书写，每一篇都有质量保证。点击【阅读原文】，订阅专栏，就可以支持作者啦~
参考资料
MFSIdentifier: https://github.com/maxfong/MFSIdentifier
[2]SDWebImage: https://github.com/SDWebImage/SDWebImage/blob/master/Package.swift
[3]说明文档: https://github.com/josercc/XCFrameworkBuild/blob/master/README.md