这篇文章主要讲述两个知识点

  • 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那么我就用这个分离模块。

让 Objective-C 库支持 Swift Package Manager_Swift

cQ87NN

上图就是我们项目目前的工程结构。

我们目前所做的就是内部的数据收集平台,我当时想着用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和所依靠的库下载到本地,目录如下。

让 Objective-C 库支持 Swift Package Manager_Swift _02

image-20200819150332170

你为我为什么要都在一个目录,因为这是经验,为了更好的做本地依赖。

我们先从最底层依赖MFSJSONEntity开始支持Swift Package Manager。

我们在MFSJSONEntity这个目录下面执行下面的命令,对于快速到对应目录打开终端,强力推荐Go2Shell这个软件,谁用谁知道。

swift package init --name MFSJSONEntity

执行完毕,对应目录如下。

让 Objective-C 库支持 Swift Package Manager_Swift _03

image-20200819150849077

我们把自动生成的Sources这个目录删除,因为存在源文件目录,我们不能尽量不要破坏之前的目录结构。

让 Objective-C 库支持 Swift Package Manager_Swift _04

image-20200819151004150

我们用最新的Xcode正式版本(目前最新11.6)打开Package.swift这个文件。

让 Objective-C 库支持 Swift Package Manager_Swift _05

image-20200819151215552

你会发现Xcode没有任何的Scheme,这是因为源文件目录被我们删除了,因为缺少删除了源文件导致的,所以不要慌。

我们修改Package.swift文件,增加一行,来指明源文件的路径。

让 Objective-C 库支持 Swift Package Manager_Swift _06

image-20200819151523847

此时我们的库已经可以编译了,不要忘记删除MFSJSONEntityTests.swift自动生成的测试用例,不然会报错。

让 Objective-C 库支持 Swift Package Manager_Swift _07

image-20200819151706091

虽然编译通过了,但是我们的库里面任何Api都没有,这到底是怎么一回事呢?为了这个疑问,当时我可是查询了很久。

Swift Package Manager的Target有一个叫做publicHeadersPath的参数,是需要设置暴露的头文件的。

我们新建一个文件夹叫做include,把需要暴露的头文件都复制到里面,我们再次修改Package.swift文件。

让 Objective-C 库支持 Swift Package Manager_Swift _08

image-20200819153518880

我们在看看我们的库

让 Objective-C 库支持 Swift Package Manager_Swift _09

image-20200819153552586

已经自动生成我们暴露头文件的类和方法,但是为什么我们添加了include文件夹之后,就连Package.swift都没修改就可以了,一定满脸疑问吧。

因为publicHeadersPath默认的地址就是就是path/include,默认path的路径是Sources/package_name。现在我们修改了,那么现在publicHeadersPath的默认路径就变成了MFSJSONEntity/include。

你们是不是也发现了,include文件夹的头文件是我们复制过来的。但是对于需要改动头文件难道还要我们重新的复制,这样的维护也太糟糕了。

我是在SDWebImage这个库发现这个秘密的,下载下来看到是替身。我就开始用替身,发现不行,后来我才知道这是Liunx的软连接。

我们在终端到include这个目录,并删除之前复制的头文件。

让 Objective-C 库支持 Swift Package Manager_Swift _10

image-20200819155126187

我们执行下面的命令创建一个软连接

ln -s ../MFSJSONEntity.h MFSJSONEntity.h
让 Objective-C 库支持 Swift Package Manager_Swift _11

image-20200819155427316

我们将所有我们需要公开的头文件创建软连接,创建之后的目录结构如下。

让 Objective-C 库支持 Swift Package Manager_Swift _12

image-20200819155519314

此时我们发现我们的库已经会自动生成类和方法,这样以后修改维护起来是不是就十分方便了。

MFSJSONEntity这个库支持完毕之后,我们开始修改MFSCache这个库支持。具体的操作和MFSJSONEntity是一样的,只有一部分做了修改。我只说一下做了修改的地址。

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

    • 修改前

      让 Objective-C 库支持 Swift Package Manager_Swift _13

      image-20200819161954674

    • 修改后

      让 Objective-C 库支持 Swift Package Manager_Swift _14

      image-20200819162250503

  • Package.swift的内容

    让 Objective-C 库支持 Swift Package Manager_Swift _15

    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的库目录如下

让 Objective-C 库支持 Swift Package Manager_Swift _16

image-20200819180055036

我们看到UMengCommon这个库并不支持Module

让 Objective-C 库支持 Swift Package Manager_Swift _17

image-20200819180119417

我们在和Headers目录下面创建文件夹Modules在Modules下面创建module.modulemap文件。

让 Objective-C 库支持 Swift Package Manager_Swift _18

image-20200819180158997

我们用Xcode编辑module.modulemap如下

framework module UMCommon {
    umbrella header "UMCommon.h"
    export *
    module * {export *}
}

对于这个库来说,还是没有支持。因为主目录下面都是软连接方式,我们也创建Modules软连接到主目录。

让 Objective-C 库支持 Swift Package Manager_Swift _19

image-20200819174632280

我们将UMCommon所需要暴露的头文件写在UMCommon.h文件里面

#import <UMCommon/UMConfigure.h>
#import <UMCommon/MobClick.h>
#import <UMCommon/UMRemoteConfig.h>
#import <UMCommon/UMRemoteConfigSettings.h>

制作XCFramework

让 Objective-C 库支持 Swift Package Manager_Swift _20

image-20200819180531244

我们新建一个工程,将制作出来的UMCommon.xcframework拖拽到工程看一下效果。

让 Objective-C 库支持 Swift Package Manager_Swift _21

OC工程效果

让 Objective-C 库支持 Swift Package Manager_Swift _22

Swift项目

支持Swift Package Manager

当导入显示Module不存在时候请一定清理DerivedData,我就傻傻的怀疑做了很多实验,导致我精神失常了,都开始怀疑人生了。

新建一个Swift Package Manager的库,目录结构如下。

让 Objective-C 库支持 Swift Package Manager_Swift _23

image-20200820143646674

我们修改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: &quot;MyLibrary&quot;,
    products: [
        // Products define the executables and libraries produced by a package, and make them visible to other packages.
        .library(
            name: &quot;MyLibrary&quot;,
            targets: [&quot;UMCommon&quot;]),
    ],
    dependencies: [
        // Dependencies declare other packages that this package depends on.
        // .package(url: /* package url */, from: &quot;1.0.0&quot;),
    ],
    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: &quot;UMCommon&quot;, path: &quot;UMCommon.xcframework&quot;),
        .testTarget(
            name: &quot;MyLibraryTests&quot;,
            dependencies: [&quot;UMCommon&quot;]),
    ]
)

我们在测试文件调用

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(&quot;&quot;)
    }

    static var allTests = [
        (&quot;testExample&quot;, testExample),
    ]
}

支持作者

这篇文章来自于 《君赏的百味书屋(iOS开发心得)》,这个专栏由君赏负责维护,他是一位有着七年多iOS开发经验的 iOS 开发工程师,有比较丰富的经验。同时他也对独立开发,自动化涉及比较多,也喜欢研究一些围绕iOS比较偏知识。

这个专栏是君赏个人技术博客,用来分享平时开发的技术难点和学习心得,每一篇都用心去书写,每一篇都有质量保证。点击【阅读原文】,订阅专栏,就可以支持作者啦~

参考资料