Apple 现在面临着一个抉择：继续维护浑身“补丁”早已过了“而立之年”的 HFS+ 文件系统，还是全新开发一套文件系统

显然，相比于前者高昂的维护成本，后者来得更划算一些

在去年的 WWDC 上，苹果在深思熟虑之后做出了这个抉择，发布了全新设计的文件系统：APFS（ Apple File System ），这意味着使用了 20 年的 HFS+ 文件系统将被逐步替代

我们知道，HFS 的历史已经有30多年，诞生在软盘和机械硬盘时代，很多特性已经不适用如今大多数企业和用户所需要的一些基本功能，比如：纳秒级时间戳、校验、稀疏文件等

从 Snow Leopard 开始，Apple 就有转向 ZFS（最为先进的文件系统之一）的想法

但是由于后来 Sun 被 Oracle 收购，该项目后来就搁置了

直到今年，Apple 终于又将新的文件系统提上日程

下面，差评君从开发者的角度，通过 Sierra 中的一些文档、开发者网站中提供的资料和一些实例，来与大家聊一聊 APFS 存在的意义和它与 HFS+ 的区别

这篇文章主要面向对于 macOS 内部文件系统机制感兴趣的朋友们，对于 Mac 新手和无硬件基础的读者们来说可能不是很友好

对于一部我们手中完整的 Mac 产品来说，它的组成部分大致可以分成三层：1、处在最底层的 Hardware 层；2、底层之上的 Core OS “ Darwin ” 层；3、顶层图形用户界面的 GUI 部分，即 “ Aqua ” 层

就上面提到的这几部分的层级关系，我们可以画一张图表示一下：我们要讨论的APFS 和 HFS+ 文件格式属于第二层，即 “ Darwin ” 核心系统层中最底部 Mach 层嵌套的 BSD 系统中的 File Systems 部分

这套类 Unix 的 BSD 系统由加州大学伯克利分校在 1977 年至 1995 年开发，在之前 NeXT 公司成功开发了由 Mach3 、BSD 以及 I/O Kit 的混合内核之后，Apple 将其很好地移植到了 macOS 上，这部分从 2000 年的 Mac OS X 和 iOS 的基础 “ Darwin ” 发布后就一直沿用至今

对于 File System ，我们知道它向上服务 Application 和 Users ，向下服务 Storage Device Diver 和 Device

正是这样的层级关系，差评君在试图寻找系统目录下的 File System 描述文件时，无意间发现了这个 apfs
fs 的彩蛋包（ path :: /System/Library/Filesystems/apfs
fs ），通过创建时间我们可以知道它是在 2017 年 6 月 21 日被添加进来的

当然，我们按常理也可以判断出来：新文件格式的开发一定不会脱离旧有的文件格式环境

换句话说，APFS 的开发是要依赖于 HFS+ 的文件格式下才可以实现的

正是因为这种原因，APFS 一定会继承 HFS+ 的全部功能

打开文件包，我们可以从 Resource 文件夹下看到有关 APFS 格式的一些指令现在已经封装好已经可以通过 Terminal 调用了

我们尝试打开一个 newfs_apfs
fs ，可以发现其中的概述部分还处于缺失状态，可见截止到 2017 年 6 月 21 日，这个文件系统从去年开始就一直处在紧锣密鼓地开发之中，至少这个文件呈现给用户的就是这个样子

我们接着这个文件，还可以从中窥见一些端倪：新的 APFS 格式可以为文件添加密码

作为文件系统安全性保障的加密功能是 WWDC 上特别强调的，同时也是不同于 HFS+ 格式的一大改动

相较于 HFS+ 的全盘加密，APFS 则提供了统一密钥加密，针对敏感元数据单独密钥加密和多密钥加密的功能，这样哪怕用户设备物理安全受到威胁，依然可以保障数据的完整性

下面差评君就简单地说一说经过半天的测试，这套 APFS 文件系统的表现

首先我们需要创建一个 APFS 文件格式环境，由于在 10
12
6 版本下似乎关闭了 disktuil 后 createContainer 指令的调用，所以现在网上的方法都已经失效了

不过，通过浏览开发者文档，差评君发现可以通过 Terminal 结合 hdiutil 相关命令来进行环境的创建，这里创建的过程就不赘述了

最终我们生成了一个 30GB 大小的 Apple 稀疏磁盘映像 Media ，挂载到了外置优盘中

通过 diskutil 相关命令，我们可以检验到的确生成了 APFS 的 Container 和一个名称为 I_am_APFS 的 APFS 卷宗

我们通过 diskutil apfs list 命令列出当前系统中所有的APFS 卷宗信息：可以看到的是，这里与目前普通 HFS+ 宗卷不太相同

首先，一个 GPT 分区，如 disk4 被标示为一个 APFS Container，这其实是将整个分区作为一个逻辑分区区域

通过 APFS Physical Store 也可以看到这一点

然后，该分区上有一个名为 I_am_APFS 的宗卷，设备名称为 disk4s1

在测试时我们以大家最常用的复制操作为例：采用控制变量的方法，在同一块优盘中同时生成了 APFS 和 HFS+ 两种格式的 Container

下面我们用一部1
5 GB 的 mkv 文件进行数据传输速度测试：通过测试，这部视频拷贝至 APFS 格式系统内和 HFS+ 格式系统内分别用了 20 秒和 10 秒

为什么 HFS+ 速度反而会比 APFS 快了一倍？由于我们使用的是第三方外置存储设备，对于 APFS 的支持不是很好，这也说明了另一个问题：苹果新的文件系统如何被第三方厂商支持，这种转型一定是需要时间的，而时间的长短或许取决于在 APFS 正式推出后对用户体验的改善情况的好坏

由于改变了存储逻辑，在复制文件时无论多少份都几乎只占用一份的空间大小

新复制的文件通过地址索引链接的方法指向原始文件，或者说它们更像是一种并行的关系

比如在 APFS 格式下将 1
5 GB 的电影复制十份，占用的大小依旧是 1
5 GB

这种机制更像是现在网盘厂商在维护硬盘空间时常用的查重机制，而 APFS 或许使用了一种与网盘厂商校验 MD5 不同的方法来进行查重

我们通过开发者文档可以了解到，这套 APFS 文件系统对大小写敏感

这也就意味着有许多软件在新文件系统下将无法安装使用，典型代表就是 Adobe 全系列软件

另外，由于APFS 不支持目录硬链接，所以它现在不兼容 Time Machine 功能，希望以后能够针对 Time Machine 提供更高效的序列化机制

总结一下，现在这套脱胎换骨的 APFS 已经具备与 BSD HAMMER、Linux btrfs，或 OpenZFS 等现代化文件系统不相上下的功能和特性

对于 APFS 在下一个系统版本 “ High Sierra ” 中的表现，让我们拭目以待

其实不止 macOS ，下一版本的 iOS 11 也很有可能搭载 APFS 文件系统，这对使用小容量存储设备的用户来说是一个利好消息