pbxprojHelper–Xcode 工程文件助手

pbxprojHelper 可以帮你快速配置 Xcode 工程文件,省去麻烦的人工手动操作。项目开源,使用 Swift 开发,详细介绍请见使用说明。除了 Mac App 外还提供了命令行工具 pbxproj,它集成了 pbxprojHelper 的核心功能,同样简易实用。

因为 README_ZH 中对使用方法已经讲得很详细了,这里重点说的是产品方案和技术实现。

产品方案

为什么造这个工具?

在开发公司的项目时,check out 代码到本地后需要修改工程文件。比如更改证书和 Bundle Identifier、删除一些编译不过的 Target,修改 Build Settings 等配置。重复手动修改这些配置的场景很多:

  1. 第一次 check out 新的分支,需要使用自己的配置。
  2. 增删代码文件前会先 revert project.pbxproj 文件,修改完成后再 commit。此时本地工程文件需要重新配置。
  3. 没有增删代码文件但 project.pbxproj 文件有冲突(conflict),需要先 revert 后重新配置工程文件。
  4. 一些自动化流程(比如 CI)每次执行都需要特定的编译选项和证书来编包。

而我本人最常遇到的场景是 1 和 2,因为不能用公司的证书配置来编译,一些跟苹果开发者账号相关的功能导致一些 target 编译不过,还有些 debug 模式下需要设置的编译选项。所以每次都需要手动修改 Xcode 工程配置,很是麻烦。

需求!

可以说开发这个工具一开始完全就是为了解决我个人的痛点的,基本没考虑做成功能强大的通用工具。虽然做的事情比较小众,但也能满足一批苹果开发者的需求了。我把需求分为以下几点:

  1. 将程序员对工程文件做出的配置修改记录下来,并保存成 JSON 文件
  2. 下次使用时直接导入 JSON 文件,将配置修改应用到当前的工程文件上
  3. 支持回滚操作
  4. 支持工程文件内容的预览、过滤
  5. 快速切换最近使用的工程
  6. 提供命令行工具

可以说 1 和 2 是刚需,也是常用功能。3、4 和 5 是辅助功能,6 是附加需求。我平时最常碰到的需求点就是 2 和 5 了。

技术实现

关于 Xcode 工程文件的介绍,请参考我之前写的 Let’s Talk About project.pbxproj。本篇文章可以算作是它的续集。

我把工程文件相关的底层方法都封装在 PropertyListHandler 类中,它们跟界面无关。还有一些工具类和方法写到 Utils 文件中。

对比工程文件

想要记录工程文件的修改是很难的,所以只能是比较下两个工程文件的差异。这里不是对比文件那种简单的 diff 操作,而是要记录具体针对哪个配置项做了『增删改』。

工程文件的内容可以比作一颗多叉树,的根节点是字典,其余中间节点都是字典的键。数组的元素肯定是字符串(叶子节点),字典的键值对则可能继续拓展出子树,也可能是叶子节点。在拿到两个工程文件的数据后,就需要对两棵树的每个层级进行对比。对比两颗树的差异算法不难实现,核心思想是:在对比中间节点时,如果内容相同那就递归比较下一层,否则就记为『增』或『删』

而比较同一层级中间节点的差异,直接用 Set 是最方便的了。我将两棵树的差异保存在字典 difference 中,在内嵌方法中又实现了个尾递归。递归过程中需要记录中间节点作为路径,因为生成的路径需要保存到对比结果中。

这段看似很长的代码其实逻辑超级简单,就是分别针对字典和数组两种情况进行比较而已,弱智的一逼。需要注意的是数组内容作为叶子节点,只存在『增』和『删』两种情况。

每次递归都将 parentKeyPath 与当前节点的值 key. 拼接在一起。也就是说最后得到的路径是 A.B.C 这种格式。

可以看出生成的对比结果是个字典,包含三个键值对,键分别是 insertremovemodify,值为字典。

应用 JSON 配置

因为生成的 JSON 配置文件具有一定格式,所以必须按照格式规则来应用这些配置到工程文件中。最关键的是在上一步中生成的路径格式为 A.B.C,且路径内容是未知的,需要实时处理。所以我写了个方法来解析路径,步入到路径最底层后提供闭包来对路径的值进行修改。假设 keyPath 为路径字符串内容,方法实现如下:

这个方法会将当前层级(index)路径的节点作为键(key),并查找字典中该键对应的值(nextValue)。然后递归遍历下一层,直至步入到路径(keypath)最末端。此时会执行传入的 complete 闭包,并将结果作为该方法的返回值。这样在对路径最末端的节点值做出修改后就可以逐层同步上去,最后完成对整条路径的修改。

如果能直接给 value[A][B][C] 赋值就好了,但是这是不可能的。因为路径内容是未知的,这样的代码不可能写死的,只能动态地递归进去,并在调用后将修改内容返回上层。

之前提到过 JSON 文件格式中包含三种命令:insertremovemodify。所以在实现 complete 方法的时候需要针对这三种命令分别处理,每种命令还要区分字典和数组两种数据类型。这里处理的逻辑基本是上一步的逆逻辑,很容易理解。

因为 JSON 文件内容层级较深,所以需要先遍历最外面的字典。一共有三个键值对,分别对应 insertremovemodify 三个命令(command)及其参数(arguments)。每种命令的参数都是由『(路径:字典或数组)』这样格式的键值对组成。路径对应的值的类型需要与 JSON 文件中一样。

在遍历的同时修改工程文件数据的内容,这里使用了 Swift 的嵌套方法和尾随闭包语法。这总语法虽然用着爽,但是对代码的可读性也有所降低。

操作工程文件

可以用 PropertyListSerialization 来(反)序列化 project.pbxproj 文件的内容:

将工程文件数据写入磁盘表面上看起来是一件再简单不过的事情,但其实这里面包含编码问题和备份机制。

编码问题

直接把工程文件数据写入文件后,中文会有乱码。需要做的是把中文内容的 Unicode 的标量值提取出并转成 numeric character reference(NCR)。”dddd” 的一串字符是 HTML、XML 等 SGML 类语言的转义序列(escape sequence),它们不是『编码』。

下面的方法可以将生成的工程文件中文内容替换成 NCR:

备份机制

既然是要生成新的工程文件来替换原来的工程文件,备份机制肯定不能少。当前的备份机制仅仅备份上次修改的文件,这是考虑到备份历史文件会占用大量磁盘的问题。比如大一些的工程文件可能占用10M 甚至更多的空间,频繁操作产生的备份会很多。

在生成备份文件和使用备份文件还原时,都需要获取到当前工程文件对应的备份文件 URL。真正的主角 project.pbxproj 被包含在工程文件(夹)内部,所以要根据文件后缀名来决定如何处理。下面的私有方法会将传入的 URL 引用参数修改为真正的 project.pbxproj 文件 URL,并返回备份文件的 URL:

一个方法只干一件事,这个方法设计的很不好,干了两件事,别学我这么做。我这么做是为了省代码量。(狡辩,逃)

预览和过滤工程文件内容

主界面如下,在展示所有数据的同时,可以在 Filter 文本框中输入关键词来过滤数据:

11mainwindow2x

预览

关于如何使用 NSOutlineView 展示数据,不想多说,查文档写 UI 谁都会。

我定义了一个数据结构 Item 来表示 NSOutlineView 中每行节点的数据:

因为有了 parent 指向父节点,可以递归搜寻到某个 Item 对象所处的路径(keypath):

这样就可以实现双击某行数据时,自动将当前数据的路径写入 Pasteboard 中。

过滤

过滤关键字的重点就是判断一个 Item 及其子节点中是否包含此关键字,此时需要依然是需要 DFS 递归查找关键字。

查找关键字需要忽略大小写:

递归查找很容易实现,只不过区分下数组和字典罢了:

最后经过方法嵌套拼装成如下:

快速切换工程文件

下拉列表的 UI 实现很简单,就是一个 NSView 里面放几个 NSTextField。维护常用工程文件列表需要在每次用户选择工程文件后将其加入列表,实现 LRU 算法。

这里对 LRU 缓存的需求跟 自制一款 Mac 平台 URL 辅助工具 这篇文章中的 TFSHelper 的是一样的。我直接把代码搬过来了。我将其放到 Github Gist 上了,可能需要科学上网:LRUCache

下拉列表的点击操作交由 NSClickGestureRecognizer 捕获处理。

构造命令行工具

为了尽可能精简命令行的使用复杂度,我只把最核心的功能封装进去,一共只有这几个命令:

输入的这些参数都需要自己去处理,由此会产生大量条件判断,好在我的不算复杂。需要注意的是参数列表第一个是程序名称(路径)。

在 terminal 中执行 Swift 文件时获取参数内容的方式变了好多次,一开始是 C_ARGCC_ARGV,到了 Swift 1.2 只能使用 Process.arguments,到了 Swift 3 又变了,必须用 CommandLine.arguments

拿到了参数后,我所做的事情只是调用 PropertyListHandler 中已经封装好的工具方法罢了。

不是所有的人都会把 Swift 文件当做脚本去执行,所以还需要创建个 target,打包成可执行程序,这样就不依赖 Swift 命令了。

结果

我使用 pbxprojHelper 的频率十分高,因为开发同一项目的人很多,svn 的分支也多。第一次生成好我的 JSON 配置文件后以后就几乎不用再生成了,不同分支的工程都可以共用这一个 JSON 配置。每次因为种种原因 revert 了 project.pbxproj 文件后,我都可以用它一键配置好我的工程文件,节省了至少 90% 的时间!即便换了个其他分支的工程,也可以在常用列表中迅速切换,不用再次 select 文件。

也正是在一次次的使用中发现了若干 bug 和体验问题,然后不断改进和完善。

感悟

这个项目从开始构思需求到完成基本功能花费了我大概一周的业余时间。

前期调研做了些准备工作后觉得还是有可行性的,并对部分功能需求做了妥协。比如记录工程文件修改内容需要对比新旧两个文件,这就要求使用者先把工程文件保存一份,然后再修改,最后使用 pbxprojHelper 对比两个工程文件的差异。最后生成工程文件的环节也做了妥协,因为无法将数据以 OpenStep 格式写入文件,除非调用 Xcode 私有框架 touch 下工程文件。所以需要用户用 Xcode 打开工程后随意修改下工程再复原即可。就是在这样一次次对功能的妥协下,使得方案的看似不可行变得可行。

这个项目的需求一开始并不明确,是在摸索中一点点确立的。比如一开始根本没有想到过要把修改保存成 JSON 文件,之后想的是让用户手动创建和编写 JSON 配置文件,再之后想的是自动生成 JSON 配置文件。在制定 JSON 配置的内容规则上也是调整了一阵子,几经修改最后定稿。所以说,产品经理下次改需求的时候可以适当理解下,毕竟产品成型的确需要个过程。

摸着石头过河的感觉虽然忐忑,但是我更享受攻城略地般的快感。当时在开发的过程中遇到了一个个难题,当时连自己也不知道能否搞定,很有可能半途而废。但最终还是通过制定策略和实现算法实现了,虽然算法都挺简单并不难,但是能有针对性地给出一些解决方案还是比较有成就感的。

作为一款给自己量身打造的玩票工具,使用 Swift 来开发看起来是当今标配,理所当然。也是趁着玩票的机会温(chong)习(xue)下 Swift,毕竟平时一直用 OC 写 MRC 代码,生怕落后于这个时代。

1 收藏 评论

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部