让 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是一样的，只有一部分做了修改。我只说一下做了修改的地址。

• 将源代码文件全部放在同一个文件夹

• 修改前

  

• 修改后

  

• Package.swift的内容

  我们按照同样的方法将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拖拽到工程看一下效果。

OC工程效果

Swift项目

支持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),
    ]
}

参考资料

[1]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

本文由哈喽比特于4年以前收录，如有侵权请联系我们。
文章来源：https://mp.weixin.qq.com/s/1gzhAKR1thtoOUleqQ8oQQ