在 Swift 里安全管理指针

在 Swift 里安全管理指针

请跟随我们一起深入了解 Swift 中的不安全指针类型。了解每种类型的要求以及正确使用方法。我们将探讨一下指针类型、下拉切换至原始指针以及最终通过绑定内存来完全规避指针类型安全。本部分为 WWDC20 的“不安全 Swift”的后续内容。为充分利用，你应该熟悉 Swift 和 C 程序设计语言。

资源
- Manual Memory Management
- - 高清视频
  - 标清视频
相关视频

WWDC20
- 不安全的 Swift
下载

（你好 WWDC 2020）你好欢迎来到 WWDC （ANDREW TRICK SWIFT 编译器工程师）你好我是 Andy 我会向你讲解《在 Swift 里安全管理指针》的指南这次讲座直接建立在同样来自 WWDC 20 的《Unsafe Swift》讲座上在那次讲座里我们定义了不安全操作即在某些输入上有着未定义行为的操作这一次我将更深入地讲解在与以往不同的安全区域外编程 Swift 的细节这些细节一般并不是应用编程员所需要担心的安全管理指针意味着我们需要知道它们可能会变得不安全的所有方式我会将大部分的时间都用在讲解类型安全上这是 C 里未定义行为的源通常大家都对它知之甚少我会向你们解释能够给予 Swift 相同低层级功能的 API 以及如何利用它们来避免未定义行为我们可以将指针安全看作是一系列的层级每下一层你就越需要确保你所编写的代码是正确的所以我建议你尽可能地在最高安全层级里编写代码（安全层级）第一级是安全代码 Swift 的一大目标是为编写代码提供不需要任何不安全建构的新方法 Swift 有着非常强大的类型系统这个系统能提供丰富的弹性和性能 Swift 的 API 集合、切片和迭代器提供了很多你可能想要从指针那里获取的功能而在代码安全这方面完全不使用指针是一个好策略但是 Swift 的另一重大目标是通过不安全语言达成高效互用性要做到这点 Swift 需要提供以不安全 API 形式所呈现的低层级可表达性这些将会通过它们的类型或函数名称前缀 “Unsafe” 来表示 Swift 的 UnsafePointer 让你负责承担使用指针的某些危险而无需担心类型安全如果你需要将某些原始内存用作一连串的字节 Swift 提供了 UnsafeRawPointer 选项利用原始内存加载和存储值使你有责任了解类型的布局在最深的层级里 Swift 提供了一些 API 以将内存绑定到类型上只有当你使用这些最低层级的 API 时你需要承担管理指针类型安全的所有责任而不是 Swift 让我来解释一下何谓安全层级吧安全代码不一定就是正确的代码但是它的运作是可预料的在大多数的情况下如果一个编程错误可能会引发不可预料的行为时编译器将会捕获它至于那些无法在编译时被捕获的错误运行检查也能通过诊断使程序立即崩溃它就不会再继续通过不正确的假设了
所以安全代码其实就和强制执行错误有关如果你不使用任何被标记成不安全的 Swift 类型或者 API 而且你用心地管理线程安全的话你就会知道你已经全面执行了可预料的行为在不安全的 Swift 代码里可预料的行为并没有被全面执行所以你就需要肩负额外的职责测试依然可以带来有用的诊断但是诊断的层级取决于你所选择的安全层级不安全的标准库 API 在调试版本里具有断言功能这能捕获某种特定的无效输入添加你自己的预置条件以确认不安全假设也是很好的做法你可以通过进行多次运行检查启用诸如 Address Sanitizer 等的 Sanitizer 来反复测试 Sanitizer 诊断是绝佳的省时利器它能够精准定位漏洞但是不会捕获所有的未定义行为当你没有在测试中发现错误时它们可能会引发出乎意料的运行行为那可能会是一个难以调试的崩溃其发生的原因远非通过研究问题的根源所在就能解决或者可能比崩溃还糟糕你的程序可能会做错事甚至破坏用户数据崩溃固然是不好的体验但是破坏或弄丢数据就更糟糕了你越是冒险进入更低层级的不安全区域你越是难以发现这些错误而且这些症状也会越来越难以理解这些症状可能完全不会显现一直等到漏洞出现为止你才发现（指针安全）来看看指针来了解代码能够如何变得不安全吧 Swift 是为了不使用指针就能进行编程而设计的而如果能了解为什么它们并不安全我们就能更明白为什么避免它们会是一个好策略可是如果你必须使用低层级 API 直接访问内存的话了解你要如何自己管理安全的不同方面也很实用你可能需要指向存储容量来获取变量指向数组的元素或者指向你直接分配的内存在你指向该对象前指针需要稳定的内存位置你指向的稳定存储容量只有有限的生命周期原因就在于它要么超出范围要么就是因为你直接解除分配了内存但是你的指针值也有自己的生命周期当指针的生命周期超过存储容量的生命周期时任何对它的访问尝试都会是未定义的这就是指针变得不安全的首要原因但是这并非唯一一个对象可以由一连串的元素所组成通过添加偏移量至指针它就可以移动到不同的内存地址这是去到不同元素地址的有效方法可如果添加或减去太多的偏移量的话这会指向不属于相同对象的内存访问一个超越其对象边界的指针是未定义的在这次的讨论中我们会专注于另一个易于被忽视的安全方面指针有属于它们自己的类型它们和内存里的值类型并不相同我们要如何确保这些类型是一致的如果它们不一致又会发生什么事？当我们请求一个指向 Int16 类型存储容量的指针时我们会得回一个指向 Int16 的指针目前为止一切顺利我们可以看到要在 Swift 里使指针指向错误类型是挺困难的那么我们用不同类型覆盖相同内存的话现在这是 Int32 这个时候我们会有一个指向正确 Int32 类型的指针但是我们的 Int16 指针可能还逗留着访问旧的 Int16 类型指针就会是未定义行为因为现在指针类型和内存内类型不一致了你可能会疑惑未定义的行为怎么可能比程序崩溃还要糟糕而且指针类型怎么可能导致这点呢？要了解这点我们先来看看一些非常不安全的代码吧
我不希望任何人编写出这样的代码但是你想象不到一个从 C 接入并且还能调用部分旧 C 代码的 Swift 代码能做出什么能够做出惊人之举的代码确实会看起来很惊人但是我们还不需要彻底搞懂这些低层级的类型来研究问题想象我们有个拼贴结构体它包含一个指向内存部分图像数据的独立指针以及指向图像数量的另一属性这个类型可能是从 C 导入进来的
我们也有一个 addImages 函数它可以将图像数据编写进内存里并增加一个图像数量
当我们调用 addImages 时我们想要它更新拼贴结构体的图像数量但是却出现了结构体的 imageCount 类型即 Int 与指向 UInt 32 的函数参数指针不匹配的情况
而安全的做法会是创建正确类型的新数量变量并使用 Swift 的整数转换可在这里这复杂的代码行创建了一个直接指向我们结构体的指针之后这个代码需要再次读取图像数量并将它交给 saveImages 问题就出在运行时这个数量很可能是零这意味着这个程序已经悄无声息地丢失了所有图像
将 Int 类型配给数量属性以及 UInt 32 类型配给指针这个举动示意了编译器一件事即那些值存在于不同的内存对象里编译器收不到 Int 对象的任何更新所以它只能重复使用零这个初始化值在实践中编译器可以允许错误因此这样一个示例应该不会出什么大事但是我们无法预料将会发生的事对于编译器来说类型信息是假设所基于的一个事实一旦编译器做出了不好的假设这可以渗透编译器的传输管道并以突发的方式显示因此两种版本的编译器可以导致不同的程序行为指针类型的漏洞可以导致你的程序出现异常行为甚至会通过比崩溃还糟糕的形式出现但使它们变得更可怕的是它们很少会被注意到表面上程序可能会看起来很正常暗地里一个漏洞却在里面徘徊数年根本没人注意到之后可能当有人对源做出安全且看似无害的更改时问题才得以揭发或者问题也有可能在一次例行的编译器升级时而被注意到实际上根本没人改过代码但是你的程序却开始出现异常指针类型安全的挑战早在 Swift 诞生之前就存在知道如何在 C 里面正确地使用指针类型需要非常深厚的语言规格知识
你可以在以下部分找到相关讨论分别是 “strict aliasing” 和 “type punning” 幸运的是你不需要搞明白这些规则就能安全地使用 Swift 指针虽说将指针从 Swift 传递进 C 是挺常见的但是 Swift 指针至少需要和 C 一样严格以便安全地进行互用 Swift 的 UnsafePointer 给你提供了 C 指针的大多数低层级功能作为交换你需要管理对象的生命周期和边界 “Unsafe Swift” 讲座解释过如何做到这点但是你不需要负责类型安全 UnsafePointer 的泛型类型参数会在编译时被强制执行这使之成为一个 typesafe API 来看看 Swift 对指针类型安全的规则以了解它的操作原理吧 UnsafePointer 的类型参数表示着期望保存在内存里的值类型我们将这称为类型指针在 Swift 里针对类型指针的规则是严格而简单的从概念上来说内存状态包括和内存位置绑定的类型该内存位置只能保存该类型的值作为一个 typesafe API Unsafe- Pointer 只从内存里读取该类型的值而 UnsafeMutablePointer 只读取或编写该类型的值
觉得指针类型并不重要只要字节在内存里布局正确就好拥有这种想法是正常的在 C 里把指针投射成不同类型两个指针持续地指向同一个内存是很常见的可是这在 C 里到底合不合法则取决于几种特别的个例
在 Swift 里访问一个类型参数不和其内存位置绑定类型所匹配的指针一直以来都是一个未定义行为为避免这个问题 Swift 不允许在熟悉的 C 风格里投射指针通过这样的方法在编译时 Swift 类型系统会强制执行指针类型没有必要存储额外的运行信息内存里的额外类型信息或执行额外的运行检查来看看内存是如何被绑定至一个类型并且类型指针从何而来吧如果你声明一个 Int 类型的变量并请求一个指向变量存储容量的指针你会得回一个和变量声明一致的 pointertoInt 数组存储容量和数组元素类型绑定所以显然的请求一个进入数组存储容量的指针会给你一个指向数组元素类型的指针你也可以通过调用 UnsafeMutablePointer 上的静态分配方法来直接分配内存分配将内存绑定至它的类型参数并将类型指针返回到新内存里这和变量以及数组的指针不同如状态图表所示即便内存还未保存任何初始化值内存已经被绑定至一个类型了你可以使用分配所给予的类型指针以便只针对正确的类型进行初始化内存在初始化状态下内存可以被重新分配分配会暗地里取消初始先前的内存内值并将内存重新初始成相同类型的新值你可以使用同一类型指针取消初始内存在那个时候内存依然会绑定至相同类型但它却可以安全地解除分配通过变量和数组存储容量这些步骤都会由 Swift 自动处理通过直接分配你将负责管理内存的初始化状态但 Swift 依然会确保类型安全由于类型指针遵循简单却严格的规则基本上你不会有两个指向同一内存位置却有着不同类型的活跃指针不过来看看复合类型的情况吧在这个示例中我们拥有一个包含 MyStruct 值的内存块我们可以获取一个指向结构体外层的指针或者指向其属性的指针而这两种指针同时都是有效的我们可以访问任意其中一个而无需更改内存绑定的类型这依然遵照了相同的指针安全基本规则当内存绑定至一个复合类型时它也会有效地和该类型的成员绑定因为它们都存在于内存的布局里
Swift 的类型指针能让你直接访问内存但是仅限于类型安全的范围里你不能拥有两个指向同一内存却拥有不同类型的类型指针因此如果你的目标是将内存字节重新诠释成不同类型你就需要使用一个低层级的 API
UnsafeRawPointer 让你能够参考一连串的字节而无需指定它们可能代表的值类型你将控制内存布局有了原始指针后当你从内存加载字节时你可以将字节诠释成类型值想象一下使用类型指针将内存块初始化成 Int64 将类型指针投射成原始指针这件事一直都是可行的在原始指针上的操作只能看到内存里的一连串字节内存的绑定类型是无关紧要的你可以请求该原始指针加载任意类型它会通过读取所需的字节数以及将它们汇编成指定类型而做到这点打个比方当我们将加载调用成 UInt 32 四个字节会从当前的地址加载并生成一个 UInt 32 值你甚至可以加载一个较小的类型只要考虑到目标平台的字节序即可你也可以使用原始指针将值的字节编写进内存里存储字节和加载字节是不对等的因为前者会调整内存内值与使用类型指针的分配不同存储原始字节并不会取消初始内存内的先前值所以这就变成了你的责任你要确保内存并不含有任何对象引用在这个示例中在原始指针上调用 storeBytes 将会从 UInt 32 值里提取四个字节并将它们编写进一个内存内 Int64 值的上四个字节中当字节被编写进内存后它们就会被重新诠释成内存的绑定类型因此你依然可以使用已经指向内存内值的类型指针来访问它我们不能将一个原始指针投射回去成为类型指针因为这么做会导致其和内存的绑定类型不一致这种情况下我们得到的结果会是一个指向 Int64 的指针和另一个指向 UInt 32 的指针以重叠内存从类型指针进行投射并不是获取原始指针的唯一途径 withUnsafeBytes API 会在其闭包期间公开作为原始缓冲区的变量存储容量 UnsafeRawBufferPointer 是字节的集合就像 UnsafeBufferPointer 是类型值的集合一样在这里缓冲区计数是变量类型字节里的大小集合索引是字节偏移量而读取编入索引的元素会给你该字节的 UInt8 值你也可以调整变量的原始存储容量 withUnsafeMutableBytes 会给你可变字节的集合这样你就可以将 UInt8 值存储在特定的字节偏移量里就像数组有一个 withUnsafeBufferPointer 方法一样它也有一个 withUnsafeBytes 方法这个方法能将原始存储容量公开给数组元素缓冲区大小是被元素步幅倍增过的数组数量某些字节可以因元素对齐方式而进行填充基础数据类型通常都会被用来传送字节集合数据也有 withUnsafeBytes 方法这个方法会在其闭包期间公开基础的原始指针在这里我们使用这个方法在选定的字节偏移量里读取了特定的元素类型即 UInt32 你可以直接分配原始内存只需通过调用 UnsafeMutable- RawPointer 上的静态分配方式即可在这里你会肩负起用字节计算内存大小和对齐方式的责任经过原始分配后内存状态既不初始化也不绑定至类型要想通过原始指针初始化内存你需要指定该内存将会保存的值类型初始化会将内存绑定至该类型并返回类型指针过渡到初始化内存的过程只在一个方向上进行要想取消初始内存你需要知道内存内值的类型所以你不能使用原始指针取消初始你可以使用经初始化返回的类型指针来进行取消初始我们已经看过了类型指针的内存状态图表只要内存是未初始化状态你就可以使用原始指针来解除分配内存对解除分配来说内存是否已绑定至类型并不重要使用类型指针进行内存分配会更为安全和方便因此这理应是首选以下的示例会解释你可能想要分配原始存储容量的原因比方说我们想在同一个相接的内存块上存储不同长度的无关联类型经过计算字节和对齐方式的总容量后我们调用分配的原始版本这会给我们提供一个去到字节相接块的原始指针现在我们可以将内存的一部分初始化成标头这会给我们提供一个指向标头类型的指针
添加了标头的字节偏移量后我们可以将剩余的字节初始化成整数这给我们提供了另一个类型指针它会指向只保存着整数的内存区域这个存储分配技术对实施诸如 Set 和代码字典等标准库类型来说是非常有用的但它通常不是你想要接触的东西大致上来说原始指针是一款有力的工具它在实施高性能数据结构方面非常有效但是我们并不应该过度地公开它们当你对字节偏移量进行微调时需格外留心通常当你拥有外部生成的字节缓冲区并且想将这些字节解码成 Swift 类型时你就会想要使用原始指针通过使用 UnsafeRawBuffer- Pointer 的加载 API 我们会先读取一个描述符以此确定后续数据的大小和类型我们会在字节偏移量增加的情况下对加载 API 进行更多调用每一次都要指定我们想要从流里解码的类型原始指针保留了类型安全的一个重要层级你需要在使用它们时负责内存布局但它们不会影响何时能合法使用类型指针因此使用原始指针并不会让它在使用相同内存和类型指针时变得危险在最深的层级里 Swift 提供了公开内存绑定类型的 API 当你使用这些 API 时你将全面负责指针类型的安全在开始使用这些层级前先看看你是否能使用高层级的 API 你会知道你是否在回避指针类型的强制执行因为你需要明确地调用一个表示内存绑定类型的 API
回避类型安全的危险就在于你会很容易地就在使用类型指针的代码里引入未定义行为
你依然只需遵守一个规则即类型指针的访问需和内存绑定类型一致这是一条简单却不容易遵守的规则因为代码的各项部分都需要一致的内存类型而编译器却无法为你提供指导来看看你为什么会使用如此危险的 API 并注意看看为什么以下每一个用途都是安全的在极少数的情况下代码很可能不会保留类型指针
如果说我们只有原始指针可是我们却非常肯定内存绑定至什么类型呢？我们应该要能够告诉 Swift 我们很清醒并取回我们的类型指针在这个示例中我们有一个保留原始内存的容器但同时我们也有一个变量即 pointsToInt 这会让我们知道内存是否只能保存整数值在我们的原始指针上调用 assumingMemoryBound to 并给予它作为参数的 Int 类型能够帮助我们取回整数的类型指针我们知道这个方法很安全因为当我们分配内存时内存是绑定至 Int 类型的只有当你确定内存已经被绑定至你想要的类型时你才可以调用 assumingMemoryBound to 这不会在运行时被检查这只是请求编译器做出假设的一个方法所以你需要为该假设的正确性负责以下是另一个我们需要 assumingMemoryBound to 的例子这一次我们要调用 C API pthread_create 首先我们要利用定制的 ThreadContext 类型来初始化一个情境指针当我们调用 pthread_create 时我们向它传递了我们的情境指针但是当 pthread_create 在新线程里回调至我们的启动例程时它只给了我们一个原始指针针对回调 C 函数声明了一个开始参数这个函数将作为 UnsafeMutable- RawPointer 而被导入有时这样的事会在 C 发生而我们没有办法把它变成一般的 typesafe 在这种情况下我们知道我们可以调用 assumingMemoryBound to 来恢复一个类型情境指针这样做是安全的当我们在上面几行代码分配它时我们就已经将这个类型与内存绑定在过去几个示例中原本的指针类型被清除了有时侯我们有一个类型指针但是它却位于类型组合的错误层级在这里我们有一个可以把指针带去整数的函数如果我们有 Int 的元组我们就能够将指向元组元素的指针传递进该函数里要带一个指针进入元组的存储容量我们需要调用 withUnsafePointer 但这样做会给回我们一个指向元组类型的指针而这个指针和我们的函数类型并不兼容内存一次只能绑定至一个类型但由于元组类型是复合类型因此将内存绑定至元组类型意味着内存也将绑定至元素类型我们知道使用指向整数的指针进行元组存储属于 typesafe 但是我们需要使用 typeunsafe API 来取得这种指针类型首先我们要构建一个原始指针有意地清除我们元组指针的类型然后我们就能像之前一样调用 assumingMemoryBound to 来创建一个指向整数的指针把指针降低至一个成员类型对于这样的事来说编程员需要拥有对复合类型布局的知识 Swift 的实施能确保拥有相同元素的元组按照标准样式进行布局一个值接着另一个并完全依照元素类型的步幅来看看结构体属性是如何应用这一点的吧同样的我们拥有一个函数它是指向整数的指针但是这一次我们所拥有的是带有整数属性的结构体而非元组 withUnsafePointer 给我们一个指向结构体外层的类型指针通过使用 MemoryLayout API 我们可以计算该值属性的字节偏移量通过将结构体指针投射成原始指针并添加该字节偏移量我们就能取得指向值属性的原始指针属性的内存永远都会和该属性所声明的类型绑定所以要调用 assumingMemoryBound to 来获取指向整数的指针是安全的大致上来说我们无法保障结构体属性的布局所以当你取得指向结构体属性的指针时你只能将它指向该属性的单一值指向结构体属性是很常见的因此幸运的是我们有一个可以避免不安全 API 的简易方法当你将属性传递成 in-out 参数时编译器会暗地里将它转换成该函数参数所声明的不安全指针类型 assumingMemoryBound to 会让编译器对内存的绑定类型进行一个不经检查的假设其实 bindMemory API 可以让你更改内存的绑定类型如果内存位置并没有和任何一个类型绑定它就会让内存和该类型进行首次绑定如果内存已经绑定至一个类型那它就会重新绑定该类型这样一来之前内存里的所有值都会采用新类型比方说我们分配一个内存块以保存两个 UInt16 值然后我们再请求指向该内存块的原始指针通过在该原始指针上调用 bindMemory 我们会在原地将该类型更改成单一 Int32 值这只是一个按位转换所以你不会遇到在进行普通类型转换时所遇到的安全检查事实上没有任何事需要在运行时发生 bindMemory 是对编译器的一个声明声明说类型已经在该内存位置上改变了 bindMemory 会返回一个 Int32 指针我们现在应该要用它来访问内存访问旧 UInt16 指针是未定义的在程序的任何一个地方里内存位置都只会绑定至单一类型更改内存绑定类型并不会从物理方面上调整内存但你应该要将这件事想象成更改内存状态的全局属性出于两个原因这并不是 typesafe 第一它在原地重新诠释了原始字节所以就和你使用原始指针一样你从 Swift 那里承担起了对内存里类型布局的责任但是重新绑定内存比使用原始指针更危险因为前者会使现有的类型指针都失效它们的指针地址依然是有效的但是当内存绑定至错误类型时访问它们就会是未定义的当你将指针指入存储容量要寻找声明了类型的对象时例如变量、数组或其他集合类型使用该指针来重新绑定内存会使该对象本身失效 bindMemory API 确实是 Swift 里的一个低层级语言基元它并不适合常规代码不过在现实中你确实会经历到需要重新绑定内存类型的情况这通常会发生在你拥有多个外部 API 和不同类型的数据并且不想来回地复制数据时这往往会和 C API 一起出现在那里指针类型安全并没有被仔细地考虑到在这里我们拥有一个使用 UInt8 指针的函数以及指入 Int8 类型内存的指针 Swift 会强制执行指针类型所以它不允许我们将指针传进该函数里我们可以分配具有正确类型的新内存块并复制该数据针对指针类型来说这种做法很安全但相对较慢由于我们只需要在调用期间重新诠释内存我们可以使用 Swift 的 withMemoryRebound to API 和 UnsafePointer 一样 withMemoryRebound to 也会给你一个在其闭包范围内绝对有效的指针我们知道在闭包范围内重新绑定内存是安全的因为我们的 Int8 指针不会在闭包范围内的任何地方被使用当闭包返回后 withMemoryRebound to 会将内存重新绑定回原本的 Int8 类型这使其能够不随类型指针访问周围代码我们只需在闭包内进行代码推论就能证明它是可以被安全使用的对周围代码来说 withMemoryRebound to API 使绑定内存变得安全但它有着一些非常严格的限制因为这些限制你可能依然需要直接调用 bindMemory 当你这么做时请使用相同的方法来推论安全只有当你处于可控范围内并知道代码不会使用旧指针来访问相同内存时你才可以使用 bindMemory 来获取指针当超出范围后你要确保在其他代码使用先前所取得的指针来访问相同内存前你已经将内存重新绑定至原本类型来回顾一下 memorybinding API 吧 assumingMemoryBound to 是将原始指针恢复成类型指针的方法这很危险因为你需要知道内存是否已经被绑定至该类型 bindMemory 是一个低层级基元它可以更改内存的绑定类型状态当类型指针在代码里的其他位置上被访问时它会变得更加危险因为它可能会引起未定义行为相对来说 withMemoryRebound to 在必要时暂时性地绑定内存显得安全多了它在调用不认同相同类型的 C API 并且不需要复制基础内存方面也非常实用
bindMemory API 最常见的错误用例是只从内存里读取一个不同类型这样的代码会调用 bindMemory 来获取它想要读取某个类型的指针该类型指针只用来读取一个值但是在创建该指针的过程中我们已经更改了内存状态甚至可能使其他指针失效了当你只想要重新诠释一个类型时 UnsafeRawPointer 的加载 API 是避免指针类型隐患的不二之选你只需要承担内存布局的责任这个方法什么时候都能成功因此如果你有指向内存的类型指针你可以将它投射至原始指针而如果你有一个变量、数组或数据对象 withUnsafeBytes 方法能让你直接访问原始缓冲区比方说你想将内存区域的视图换成具有特定元素类型的元素序列但是基础存储容量已经被公开为原始指针并且代码的不同部分可能会将其视为不同的类型其实你可以轻易地在该原始指针周围创建一个包装来保留你的元素类型就把它称为 BufferView 吧我们会在名称前添加 Unsafe 前缀这样我们就不需要自动管理内存而且我们还会限制调试版本的边界检查要在原始缓冲区上创建一个 BufferView 我们会根据元素步幅计算出该缓冲区可容纳的元素数量当然我们也会添加预置条件以确认该缓冲区具有正确的字节和对齐方式数量现在要想读取编入索引的元素我们只需计算其字节偏移量并请求原始缓冲区加载我们的元素类型即可由于从原始内存进行加载对指针类型而言是安全的我们就无需担心其他代码要怎样浏览这个内存 BufferView 让我们在保留元素类型的同时能够安全地重新诠释字节序列这样就不必用到类型指针了结束之前让我们回顾一下处理指针类型的策略吧最好的策略就是尽可能地避免使用指针
在极少数情况下你需要将相同的内存位置重新诠释成不同的类型你就必须要谨慎选择由于类型指针必须和内存绑定类型匹配所以你最好不要使用它们来重新诠释类型这可能会很难记住因为 C 代码通常都会通过投射指针类型来处理这件事
可是 Swift 却是通过提供基于原始指针的 API 来处理的
即便是在纯 Swift 代码中这些都是非常有用的 API 打个比方你可能需要从字节流里解码值或者你可能需要实施诸如 Set 或代码字典等的容器以便在相接的内存里保存不同类型本次分享和 Swift 里的指针类型安全有关我希望你受益匪浅并从中了解到它其实不如外表看起来那样神秘莫测感谢收看

5:44 - Images: undefined behavior can lead to data loss

struct Image {
    // elided...
}

// Undefined behavior can lead to data loss…
struct Collage {
    var imageData: UnsafeMutablePointer<Image>?
    var imageCount: Int = 0
}

// C-style API expects a pointer-to-Int
func addImages(_ countPtr: UnsafeMutablePointer<UInt32>) -> UnsafeMutablePointer<Image> {
    // ...
    let imageData = UnsafeMutablePointer<Image>.allocate(capacity: 1)
    imageData[0] = Image()
    countPtr.pointee += 1
    return imageData
}

func saveImages(_ imageData: UnsafeMutablePointer<Image>, _ count: Int) {
    // Arbitrary function body...
    print(count)
}

var collage = Collage()
collage.imageData = withUnsafeMutablePointer(to: &collage.imageCount) {
    addImages(UnsafeMutableRawPointer($0).assumingMemoryBound(to: UInt32.self))
}
saveImages(collage.imageData!, collage.imageCount) // May see imageCount == 0

10:06 - Direct memory allocation

func directAllocation<T>(t: T, count: Int) {
    let tPtr = UnsafeMutablePointer<T>.allocate(capacity: count)
    tPtr.initialize(repeating: t, count: count)
    tPtr.assign(repeating: t, count: count)
    tPtr.deinitialize(count: count)
    tPtr.deallocate()
}

14:24 - Using a raw pointer to read from Foundation Data

import Foundation

func readUInt32(data: Data) -> UInt32 {
    data.withUnsafeBytes { (buffer: UnsafeRawBufferPointer) in
        buffer.load(fromByteOffset: 4, as: UInt32.self)
    }
}

let data = Data(Array<UInt8>([0, 0, 0, 0, 1, 0, 0, 0]))
print(readUInt32(data: data))

14:37 - Raw allocation

func rawAllocate<T>(t: T, numValues: Int) -> UnsafeMutablePointer<T> {
    let rawPtr = UnsafeMutableRawPointer.allocate(
            byteCount: MemoryLayout<T>.stride * numValues,
            alignment: MemoryLayout<T>.alignment)
    let tPtr = rawPtr.initializeMemory(as: T.self, repeating: t, count: numValues)
    // Must use the typed pointer ‘tPtr’ to deinitialize.
    return tPtr
}

15:43 - Contiguous allocation

func contiguousAllocate<Header>(header: Header, numValues: Int) -> (UnsafeMutablePointer<Header>, UnsafeMutablePointer<Int32>) {
    let offset = MemoryLayout<Header>.stride
    let byteCount = offset + MemoryLayout<Int32>.stride * numValues
    assert(MemoryLayout<Header>.alignment >= MemoryLayout<Int32>.alignment)
    let bufferPtr = UnsafeMutableRawPointer.allocate(
            byteCount: byteCount, alignment: MemoryLayout<Header>.alignment)
    let headerPtr = bufferPtr.initializeMemory(as: Header.self, repeating: header, count: 1)
    let elementPtr = (bufferPtr + offset).initializeMemory(as: Int32.self, repeating: 0, count: numValues)
    return (headerPtr, elementPtr)
}

18:03 - Using assumingMemoryBound(to:) to recover a typed pointer

func takesIntPointer(_: UnsafePointer<Int>) { /* elided */ }

struct RawContainer {
    var rawPtr: UnsafeRawPointer
    var pointsToInt: Bool
}

func testContainer(numValues: Int) {
    let intPtr = UnsafeMutablePointer<Int>.allocate(capacity: numValues)
    let rc = RawContainer(rawPtr: intPtr, pointsToInt: true)
    // ...
    if rc.pointsToInt {
        takesIntPointer(rc.rawPtr.assumingMemoryBound(to: Int.self))
    }
}

18:40 - Calling pthread_create

// Use assumingMemoryBound to recover a pointer type from a (void *) C callback.
/*
func pthread_create(_ thread: UnsafeMutablePointer<pthread_t?>!,
    _ attr: UnsafePointer<pthread_attr_t>?,
    _ start_routine: (UnsafeMutableRawPointer) -> UnsafeMutableRawPointer?,
    _ arg: UnsafeMutableRawPointer?) -> Int32
*/
import Darwin

struct ThreadContext { /* elided */ }

func testPthreadCreate() {
    let contextPtr = UnsafeMutablePointer<ThreadContext>.allocate(capacity: 1)
    contextPtr.initialize(to: ThreadContext())
    var pthread: pthread_t?
    let result = pthread_create(
            &pthread, nil,
            { (ptr: UnsafeMutableRawPointer) in
                let contextPtr = ptr.assumingMemoryBound(to: ThreadContext.self)
                // ... The rest of the thread start routine
                return nil
            },
            contextPtr)
}

19:26 - Pointing to tuple elements

func takesIntPointer(_: UnsafePointer<Int>) { /* elided */ }

func testPointingToTuple() {
    let tuple = (0, 1, 2)
    withUnsafePointer(to: tuple) { (tuplePtr: UnsafePointer<(Int, Int, Int)>) in
        takesIntPointer(UnsafeRawPointer(tuplePtr).assumingMemoryBound(to: Int.self))
    }
}

20:26 - Pointing to struct properties

func takesIntPointer(_: UnsafePointer<Int>) { /* elided */ }

struct MyStruct {
    var status: Bool
    var value: Int
}

func testPointingToStructProperty() {
    let myStruct = MyStruct(status: true, value: 0)
    withUnsafePointer(to: myStruct) { (ptr: UnsafePointer<MyStruct>) in
        let rawValuePtr =
                (UnsafeRawPointer(ptr) + MemoryLayout<MyStruct>.offset(of: \MyStruct.value)!)
        takesIntPointer(rawValuePtr.assumingMemoryBound(to: Int.self))
    }
}

21:17 - bindMemory(to:capacity:) invalidates pointers

func testBindMemory() {
    let uint16Ptr = UnsafeMutablePointer<UInt16>.allocate(capacity: 2)
    uint16Ptr.initialize(repeating: 0, count: 2)
    let int32Ptr = UnsafeMutableRawPointer(uint16Ptr).bindMemory(to: Int32.self, capacity: 1)
    // Accessing uint16Ptr is now undefined
    int32Ptr.deallocate()
}

23:13 - withMemoryRebound(to:capacity:) API

func takesUInt8Pointer(_: UnsafePointer<UInt8>) { /* elided */ }

func testWithMemoryRebound(int8Ptr: UnsafePointer<Int8>, count: Int) {
    int8Ptr.withMemoryRebound(to: UInt8.self, capacity: count) {
        (uint8Ptr: UnsafePointer<UInt8>) in
        // int8Ptr cannot be used within this closure
        takesUInt8Pointer(uint8Ptr)
    }
    // uint8Ptr cannot be used outside this closure
}

25:49 - BufferView: Layering types on top of raw memory

struct UnsafeBufferView<Element>: RandomAccessCollection {
    let rawBytes: UnsafeRawBufferPointer
    let count: Int

    init(reinterpret rawBytes: UnsafeRawBufferPointer, as: Element.Type) {
        self.rawBytes = rawBytes
        self.count = rawBytes.count / MemoryLayout<Element>.stride
        precondition(self.count * MemoryLayout<Element>.stride == rawBytes.count)
        precondition(Int(bitPattern: rawBytes.baseAddress).isMultiple(of: MemoryLayout<Element>.alignment))
    }

    var startIndex: Int { 0 }

    var endIndex: Int { count }

    subscript(index: Int) -> Element {
        rawBytes.load(fromByteOffset: index * MemoryLayout<Element>.stride, as: Element.self)
    }
}

func testBufferView() {
    let array = [0,1,2,3]
    array.withUnsafeBytes {
        let view = UnsafeBufferView(reinterpret: $0, as: UInt.self)
        for val in view {
            print(val)
        }
    }
}

正在查找特定内容？在上方输入一个主题，就能直接跳转到相应的精彩内容。

提交你查询的内容时出现错误。请检查互联网连接，然后再试一次。

资源

相关视频

WWDC20