类型

C语言的基础类型、枚举、结构体、联合体在Swift中都有对应。

其中基础类型是一一对等的。其命名方式对C中的类型采取驼峰式命名之后，加上前缀字母C。

例如：

• int 变成 CInt；
• unsigned char 变成 CUnsignedChar；
• unsigned long long 变成 CUnsignedLongLong；

其中，只有有三个表示宽字符的类型是特殊的：

• wchat_t 变成 CWideChar；
• char16_t 变成 CChar16；
• char32_t 变成 CChar32；

这些在Swift对应的基础类型都是typealias，在Swift应应使用typealias类型而不直接使用原生类型。

变量

全局变量/常量也同样映射到Swift的全局变量/常量中。

枚举、结构体、联合体

C中的枚举只是一个普通的基础常量，除非使用NS_×_ENUM、NS_OPTIONS关键字修饰来定义枚举才会映射到Swift中的结构体，但基本使用跟Swift的枚举无异。

结构体则可以直接映射到Swift的结构体。

联合体则是映射到一个结构体中。

函数

C语言的函数基本能映射到Swift的函数中，除了不支持不固定参数函数，作为替代方案，Swift支持映射va_list表示的可变参数列表。

使用CF_SWIFT_NAME还能把C函数重命名甚至并入extension中。

指针

Swift的指针都带有Unsafe关键字，表示其使用在编译期可能是不可预测的。

Apple Developer 文档里有 C 指针和 Swift 指针的对应表：

除此以外，Swift还有几种指针表达方式：

• UnsafeBufferPointer、UnsafeMutableBufferPointer、UnsafeRawBufferPointer、UnsafeMutableRawBufferPointer
• OpaquePointer

Buffer

它相当于在原始内存空间上添加一个view，以步幅（MemoryLayout<T>.stride）单位，以集合的方式访问底层内存。对应C语言的就是数组的访问。

OpaquePointer

对于在C回调函数中要传递Swift的对象时，这些对象可能无法桥接到C的类型，这时就要用到OpaquePointer。

转换Swift对象为指针需要用到Unmanaged。

var fooObj = Foo()
// 创建Unmanaged<Foo>实例
let unmanagedFoo = Unmanaged.passRetained(fooObj)
// 转换成OpaquePointer，该指针可直接传递到void *的C指针中
let unmanagedPtr = unmanagedFoo.toOpaque()

// 传递到C函数
aFuncWithCallback(unmanagedPtr) {
    (ptr: UnsafeMutableRawPointer?) -> Void in
    // 创建Unmanaged<Foo>，并转换为Foo类型
    let fooObj =
        Unmanaged<Foo>.fromOpaque(ptr!).takeUnretainedValue()
    print(fooObj.foo)
}

Unmanaged创建和转换都有Retained和Unretained版本，对应的是指是否引用计数操作。Pass方法是否+1引用计数；take方法是否-1引用计数。

字符串指针

C中表示字符串的 char *，桥接到Swift会变成 UnsafeMutablePointer<Int8>，可以通过相应的构造方法创建String类型。

指针转换

方法参数是指针

调用将指针作为参数的函数时，可以使用隐式转换来传递兼容的指针类型或使用隐式桥接来传递指向变量或数组内容的指针。

若是常量指针参数（UnsafePointer<Type>），可以直接传递：字符串、指定类型数组、指定类型的inout表达式。

若是可变指针参数（UnsafeMutablePointer<Type>），可以直接传递：指定类型数组的inout表达式、指定类型的inout表达式。

向下隐式转换

指针在作为函数参数传递时，可以隐式转换：

• 不可变指针 -> 可变指针
• 类型指针 -> 原始指针

Raw可以直接兼容没有Raw的类型指针。如：需要UnsafeRawPointer类型参数时，可以直接传递UnsafePointer<Type>。

隐式桥接

类型变量/常量、数组、字符串，在传递给指针参数时会进行隐式桥接。

Swift基本类型 -> 指针

即用指针访问Swift变量/常量。

使用withUnsafexxxPointer函数，在闭包中用指针临时访问指向的变量/常量。

注意：在闭包中得到的指针不要返回出去。因为这是随外部变量/常量的生命周期影响，会因为其变量/常量销毁而变成野指针。

顶级函数：

// 指向具体类型变量的类型指针
func withUnsafePointer<T, Result>(to value: inout T, _ body: (UnsafePointer<T>) throws -> Result) rethrows -> Result
func withUnsafeMutablePointer<T, Result>(to value: inout T, _ body: (UnsafeMutablePointer<T>) throws -> Result) rethrows -> Result

// 以字节为单位访问，注意闭包中的参数是Buffer类型
func withUnsafeBytes<T, Result>(of value: inout T, _ body: (UnsafeRawBufferPointer) throws -> Result) rethrows -> Result
func withUnsafeMutableBytes<T, Result>(of value: inout T, _ body: (UnsafeMutableRawBufferPointer) throws -> Result) rethrows -> Result

数组中的应用

• withUnsafeBytes、withUnsafeMutableBytes
• withUnsafeBufferPointer、withUnsafeMutableBufferPointer

// withUnsafeMutableBytes应用
var numbers: [Int32] = [0, 0]
var byteValues: [UInt8] = [0x01, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00]

numbers.withUnsafeMutableBytes { destBytes in
    byteValues.withUnsafeBytes { srcBytes in
        destBytes.copyBytes(from: srcBytes)
    }
}
// numbers == [1, 2]

// withUnsafeBytes应用
var numbers = [1, 2, 3]
var byteBuffer: [UInt8] = []
numbers.withUnsafeBytes {
    byteBuffer.append(contentsOf: $0)
}
// byteBuffer == [1, 0, 0, 0, 0, 0, 0, 0, 2, 0, 0, 0, 0, ...]

// withUnsafeBufferPointer应用
let numbers = [1, 2, 3, 4, 5]
let sum = numbers.withUnsafeBufferPointer { buffer -> Int in
    var result = 0
    for i in stride(from: buffer.startIndex, to: buffer.endIndex, by: 2) {
        result += buffer[i]
    }
    return result
}
// 'sum' == 9

// withUnsafeMutableBufferPointer应用
var numbers = [1, 2, 3, 4, 5]
numbers.withUnsafeMutableBufferPointer { buffer in
    for i in stride(from: buffer.startIndex, to: buffer.endIndex - 1, by: 2) {
        buffer.swapAt(i, i + 1)
    }
}
print(numbers)
// Prints "[2, 1, 4, 3, 5]"

字符串中的应用

• withCString
• withUTF8

Data中的应用

• withUnsafeBytes
• withUnsafeMutableBytes

指针类型转换

注意Swift中的指针类型不存在继承关系。

类型指针 -> 原始指针

直接用原始指针的构造方法进行转换，如果是作为入参，则无需转换直接传递即可。

原始指针 -> 类型指针

永久绑定：bindMemory、assumingMemoryBound，两者操作的类型必须一致。

这种方式需要从原始指针调用，如果是类型指针要转换类型，则须转换为原始指针，再调用绑定类型方法。bindMemory会导致原来的类型指针是未定义的，如果修改后兼容原来。

临时转换访问：withMemoryRebound，该方法的访问发生在闭包参数中。

访问指向的值

若是类型指针（UnsafePointer<Type>），可直接访问pointee，可读写。

若是原始指针（UnsafeRawPointer），使用load方法，返回指定偏移的具体类型。只读。

当然对于可变原始指针（UnsafeMutableRawPointer），有对应的写入方法：

• copyMemory：从其他原始指针拷贝字节数据
• storeBytes：写入具体类型

C指针使用注意

在 Core Foundation 里，几乎所有用 Create 和 Copy 开头的函数，只要它们返回一个非托管的对象，我们几乎总是应该使用 takeRetainedValue() 方法来读取。

Unmanaged - NSHipster

参考

• Manual Memory Management | Apple Developer Documentation
• C Interoperability | Apple Developer Documentation

• littleEndian
• bigEndian
• byteSwapped：字节序翻转，即大端->小端，或小端->大端

若是整数值等于小端序的结果，则说明该平台是小端序的。

当然字节序是在该类型大小是大于1字节的才有效果。

Core Fundation也提供了一系列字节序的操作，如较常用的把原本数据的大端序、小端序转换为主机序：

• CFSwapInt32BigToHost
• CFSwapInt32LittleToHost

一般我们都是事先知道数据是用哪种字节序编码的，这是编码时约定的，而解码时则需要把某些数据还原成可读的值，这就涉及不同平台字节序的转换。

参考

• Byte-Order Utilities | Apple Developer Documentation

Swift则取消了Runtime这个能力，让Swift称为一门静态语言。Swift语言的对象方法调用基本在编译期间就被确定，可以看做是一种硬编码形式的调用实现。这种机制加快了程序的运行速度、减少程序包体积，但在编译连接优化功能开启时反而又会出现增大包提及的情况。Swift在编译连接期间采用的是空间换时间的优化策略，以提高运算行速度为主要优化考虑点。

OC类对象方法调用

OC对象调用方法都通过消息发送的objc_msgSend完成，并至少传入调用对象和对象方法名称作为参数，方法根据对象找到类结构信息，通过方法名来找到最终调用的方法函数地址，并最终完成函数的调用。这是OC Runtime的实现机制，同时也是OC对多态的实现。

Swift类对象

Swift类对象按其基类可分为：

• 从NSObject及其子类派生的类。
• SwiftObject派生的类（SwiftObject是隐藏的类，不会在源代码中体现）。

Swift类对象内存布局和OC类内存布局相似。都是在最开始部分有一个isa指针，指向类的描述信息。Swift类的描述信息结构继承自OC类的描述信息，但没有完全使用其中的属性，对于方法的调用主要是使用其中扩展的序函数表的区域。

Swift对象实例都是在堆内存中创建，与OC一致。Swift类在实例化时，会生成堆内存分配和初始化函数，形式为：

模块名.类名.__allocating_init(类名,初始化参数)

与OC一致，Swift类实例也是通过引用计数管理生命周期，所以也会在编译时插入swift_retain、swift_release函数，当前引用计数为0后，就调用生成的西沟和销毁函数，形式为：

模块名.类名.__deallocating_deinit(对象)

Swift方法调用

Swift类定义的方法可分为：

• OC类派生类并重写的方法
• 扩展中定义的方法
• 类中定义的一般方法

对于这三种方法，系统采用的处理和调用机制是完全不一样的。

OC类派生类并重写的方法

这些方法还是与OC类原本方法的调用机制一致，即也是使用objc_msgSend调用。

扩展中定义的方法

这里的扩展中定义的方法是不包含重写OC基类的方法。这种方法调用时在编译期就决定的，即在调用方法时，直接使用硬编码的函数地址。这也决定了扩展中的方法无法在运行时做替换和改变。

同时这类方法的符号信息不保存到类的描述信息中，也决定了派生类中不能重写扩展中的定义的方法，即不支持多态。

类中定义的一般方法

Swift在未开启编译链接优化时，对象的方法调用实现机制和C++的虚函数调用机制类似。Swift为每个类都建立一个虚函数表的数组结构，保存着所以定义的常规成员方法的地址。

在方法调用时，不再想使用objc_msgSend调用传入调用对象和方法名，而是直接调用函数地址，而调用对象则存在x20寄存器中，让代码更加安全。

虽然类中方法在虚函数表中的索引值是在编译期确定的，但基类和派生类虚函数表中相同索引处的函数地址可以不一样，即当子类重写了父类某个方法时，会分别生成两个类的虚函数表，在相同的索引位置保存不同的函数地址实现多态。

另外，为了实现方法重载和运算符重载，函数名字会进行修饰重命名，规则如下：

_$s<模块名长度><模块名><类名长度><类名>C<方法名长度><方法名>yy<参数类型1>_<参数类型2>_<参数类型N>F

Swift的成员变量

OC类的成员变量根据定义顺序排在isa后面，另外还会生成一张变量偏移表，通过偏移来访问成员变量。

Swift简化了对成员变量的访问。直接在编译链接时确定成员变量在对象的偏移位置。且不生成变量编译信息表。

结构体

初始化器与属性默认值在汇编上是一样的。

Swift结构体与C结构体的内存结构是一样的，成员变量内存都是紧挨在一起。

Swift结构体内存结构中没有保存isa，即没有保存结构体信息，因此不支持多态与派生，同时结构体中的所有方法都是通过在编译期硬编码实现的。

类方法和全局函数

Swift类方法和全局函数不存在对象作为参数，即不需要把对象保存到x20寄存器中，所以它就是个简单的C语言普通函数，只是方法名需要进行修饰重命名，所有对类方法和全局函数的调用都是在编译期硬编码为函数地址来调用的。

开启编译链接优化后

开启编译链接优化后，Swift对象方法的调用机制做了很大的优化，最主要是弱化了通过虚函数表来间接调用方法的实现，而是大量改用一些内联的方式来处理方法函数的调用。

对于多态的支持，可能不是通过虚函数来处理，而是通过类型判断，然后用条件语句分支执行方法。

Swift其他特性底层

引用类型与值类型

值类型存在栈中，引用类型存在堆中。若值类型中包含引用类型，则存储的只是引用类型的指针。

延迟存储属性

多线程同时第一次访问lazy属性，是无法保证属性只被初始化一次。

当结构体包含一个延迟存储属性时，只有var才能访问延迟存储属性。因为延迟属性初始化时要改变结构体的内存，而let修饰的结构体要求里面的所以成员都完成初始化，两者相悖。

延迟属性也不能添加属性观察器。

类存储属性

类存储属性默认就是lazy修饰，且能有let修饰成常量，会在第一次使用的时候才初始化。类存储属性时多线程安全的（系统底层会有加锁处理）。这其中调用了swift_once函数，内部调用了dispatch_once函数。

类存储属性实际上是全局变量。

输入输出参数

inout参数本质是地址传递（引用传递）。在汇编使用leaq传递地址，而一般参数则是使用movq传递值。

限制：

• 不能有默认值
• 需要时左值。

对于有属性观察器以及计算属性，在get/set输入输出参数时，也会触发相关的方法调用。

所以，如果实参有物理内存地址，且有设置属性观察器，则直接把实参的内存地址传入参数（实参进行引用传递）。

如果实参是计算属性或设置了属性观察器，则采取Copy In Copy Out的做法：在调用该函数时，先复制实参的值，产生副本（可以理解成getter操作），将副本的内存地址传入参数（副本进行引用传递），在函数内部修改副本的值，函数返回后，再将副本的值覆盖实参的值（可以理解为setter操作）。

函数重载

返回值不参与函数重载。

内联函数

开启编译器优化后，编译器会将某些函数转为内联函数，即把函数展开成函数体。但以下情况不会被自动内联：

• 函数体较长
• 包含递归调用的函数
• 包含动态派发的函数

闭包

闭包的定义：一个函数和它所捕获的变量/常量环境组合起来。

闭包函数会把捕获的变量存储到堆中动态申请的内存空间上。存储的信号包含类型描述信息、引用计数信息、具体值。每次闭包函数调用，都会动态申请一段新的堆内存在存放新的捕获变量。若没有捕获变量，则不回分配堆空间。

内存布局如下：

所以闭包的内存布局与实例对象很相似：共享方法、各自管理自己的成员变量。

空合并运算符??默认值是个自动闭包，这可以在可以解包的情况下不调用默认值的逻辑。

public func ?? <T>(optional: T?, defaultValue: @autoclosure () throws -> T?) rethrows -> T?

参考

• Swift底层原理探索5----闭包 - 掘金
• Swift5.0 的 Runtime 机制浅析 - 掘金

1. 后端把要发送的消息、目标设备标识打包，发送给APNS。
2. APNS在已注册推送服务的设备列表中，查找符合标识的设备，把消息发送到设备。
3. 设备把发送来的消息传递给相应的App，按照设定弹出推送通知。

细节

注册过程：

1. 设备链接APNs并携带设备UUID；
2. 连接成功后，APNs经过打包和处理产生deviceToken返回到注册的设备。
3. 设备把deviceToken发送到自己服务器。

推送过程：

1. 设备装有App，且有网络的情况下，APNs会验证deviceToken，成功后会处于一个长连接。
2. 后端发送消息时，后端按照指定格式进行打包，结合deviceToken一起发送到APNs。
3. APNs把新消息发送到设备，然后根据设定弹出推送通知。

KVC和KVO都属于键值编程，而且底层实现机制都是isa-swizzing。

设值流程

1. 按顺序查找setKey:、_setKey:方法，找到方法则传递参数，调用方法。否则继续。
2. 调用accessInstanceVariablesDirectly方法。
   • YES：默认，查找成员变量：
     1. 按照_key、_isKey、key、isKey 的顺序查找，找到了就直接赋值。
   • NO：进入下一步。
3. 调用setValue:forUndefinedKey:方法，并抛出NSUnknownKeyException异常。

setValue:forUndefinedKey:方法的默认实现就是抛出异常，所以可以通过重写该方法避免抛出异常。

取值流程

基本与设值流程一致，只是把set关键字改成get。

1. 按顺序查找getKey、key、isKey、_key方法，找到方法则直接调用。否则继续。
2. 调用accessInstanceVariablesDirectly方法。
   • YES：默认，查找成员变量：
     1. 按照_key、_isKey、key、isKey 的顺序查找，找到了就直接取值。
   • NO：进入下一步。
3. 调用valueForUndefinedKey:方法，并抛出NSUnknownKeyException异常。

参考

• KVC那点儿事 | 殷永振

在OC中，所有NSObject子类的所有属性（包括计算属性）都支持KVO；而在Swift中，只有在@objc dynamic修饰的属性（包括计算属性）才支持KVO，即使用@objc dynamic修饰的属性与OC行为一致。

KVC和KVO都属于键值编程，而且底层实现机制都是isa-swizzing。

KVO和NSNotificationCenter都是iOS观察着模式的一种实现。KVO对被监听对象无侵入性，即无需修改代码即可支持监听。

使用

注册监听：

[bankInstance addObserver:personInstance forKeyPath:@"accountBalance" options:NSKeyValueObservingOptionNew | NSKeyValueObservingOptionOld context:NULL];

bankInstance是变更发出的对象。personInstance是响应变更的对象。@"accountBalance"是bankInstance的key path。

选项是多选的，影响change字典内容和生成通知的方式。

• new：change字典包含新值
• old：change字典包含旧值
• initial：注册监听时即发送变更通知
• prior：在变更通知前发送一次变更前的通知，即每个变更两次通知，一个willChange，一个didChange

change字典的键：

• kind：改变类型
  • setting：对象或集合赋值替换
  • insertion：对象插入到集合属性中
  • removal：对象从集合中移除
  • replacement：对象从集合中替换
• new：新值
• old：旧值
• indexes：插入/移除/替换对象的索引
• prior：标识该通知是willChange的，否则是didChange的

new、old可以时单个对象，也可以时对象集合，表示集合时表示移除/替换的对象。

移除监听可在这两个时机完成：

• 不需要监听时。
• 被观察对象、观察者对象销毁时。被观察对象与观察者对象常常具有相同的生命周期。

使用注意：

• 移除监听的调用角色与注册监听保持一致。

• 多次注册监听导致多次响应。didChnage变更通知的顺序与注册顺序相反，即以先进后出的顺序调用。

• 注册监听与移除监听必须保持配对，多了少了都会导致异常崩溃。但iOS 11以上不会崩溃。

手动处理变更通知

1. 在被观察对象（如上面的BankObject）重写+automaticallyNotifiesObserversForKey:方法（默认返回YES，即默认所有键值都会通知变更），定义需要手动控制的属性。记得在不需要修改的key上返回super方法。
2. 在需要发送通知的地方调用：
   • 一对一：willChangeValueForKey:、didChangeValueForKey:
   • 有序一对多：willChange:valuesAtIndexes:forKey:、didChange:valuesAtIndexes:forKey:
   • 无序一对多：willChangeValueForKey:withSetMutation:usingObjects:、didChangeValueForKey:withSetMutation:usingObjects:

如果没有重写相关通知方法，则只会在initial选项生效。

手动处理变更通知的应用场景：

• 筛选通知，如去重、控制通知发送时机。
• 多个键的通知一起发送。

注册依赖键

需要在被观察对象（如上面的BankObject）重写+keyPathsForValuesAffectingValueForKey:方法或+keyPathsForValuesAffecting<Key>方法，返回给定key依赖的key path集合。记得在不需要修改的key上返回super方法。

注意：+keyPathsForValuesAffecting<Key>方法在Swift中要声明为@objc。否则不会识别。这种方法还可以用于在分类添加依赖键。

注册集合监听

对不可变集合采用一对一的对象赋值方式更新，对于可变集合，访问集合时，不能直接访问对应属性，需要使用mutableArrayValueForKey:类似的方法取出集合，对取出的集合进行增删改都会出发变更通知。

集合注册依赖键比较麻烦，需要使用KVC的方式。

新特性与坑

Swift重新封装了注册和移除监听的方式：

// 注册与取消
func observe<Value>(_ keyPath: KeyPath<_KeyValueCodingAndObserving, Value>, options: NSKeyValueObservingOptions = [], changeHandler: @escaping (_KeyValueCodingAndObserving, NSKeyValueObservedChange<Value>) -> Void) -> NSKeyValueObservation
func invalidate()

// 使用
weather.observe(\.text, options: [.initial, .new, .old, .prior], changeHandler: printSwiftKVOReponse)

iOS 11以下使用时，需要主动置空NSKeyValueObservation或调用invalidate方法。

Swift的KVO方式弱化了observer的存在，而是使用block接收变更通知。并返回一个token，用token进行取消注册。进而替代原有的注册与取消监听的方式。而其他方法observing对象的方法基本不变。

另外@objc dynamic只支持与OC共用的类型，像Swift的枚举、结构体、元组都不支持。

监听OC的枚举类型还会出问题，导致change的所有值都为空，而使用传统的注册监听方式是正常的。

即使测试中监听可选类型的属性也会导致上述问题。

KVO实现原理

使用runtime创建被观察对象的子类，重写sttter，附加KVO通知逻辑，然后把isa指针指向创建的子类并重写相关方法，实现对原本对象的替换。

在运行时根据原类创建一个中间类，这个中间类是原类的子类，并动态修改当前对象的isa指向中间类，并将class方法重写，返回原类的Class。当修改实例对象属性时，会调用Foundation的_NSSetXXXValueAndNotify函数，函数先调用willChangeValueForKey:，然后调用父类原来的setter方法修改值，最后是didChangeValueForKey:，这些方法触发Observer的监听方法。

触发机制

所以，基于原理得知，所有调用属性setter的都会触发KVO通知，所以KVC也会触发KVO，但直接修改成员变量则不会。

注意：使用KVC能对没有setter的属性，甚至成员变量修改值，这都会触发相同keyPath的KVO通知。

参考

• 在Swift中使用KVO：Using Key-Value Observing in Swift
• 关于KVO看这篇就够了 | 殷永振

• 全局变量：不会捕获到block内部，直接访问。
• auto基本类型的局部变量，捕获到block内部，生成成员变量来存储，以值传递的方式访问。
• static类型的局部变量：捕获到block内部，生成成员变量来存储，以指针方式访问。
• 对象类型的局部变量：连同它的所有权修饰符一起捕获。

变量捕获修饰符

• __weak是为了防止循环引用。在block中访问weak指针，当对象被释放时，指针置空，变成nil调用相关方法。
• __strong是为了延长生命周期。这里用在block和目标对象存在相互引用的关系才有效，且赋值的是weak指针，作用是使其引用计数+1。相当于声明了个局部变量。
• __block是为了在block内部可以修改外部的变量。
  • 如果想用__block解决循环引用，必须要在block中将其修饰的变量置空。

- (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event {
    [self dismissViewControllerAnimated:true completion:nil];
    
    __weak typeof(self) _self = self;
    TestViewController *tmp = self;
    self.block = ^{
        // 1⃣️
        // 注意声明是发生在这里，即weak self指向的对象还没被销毁的时候
        __strong typeof(_self) s_self = _self; // 同下
        // TestViewController *s_self = _self;
        // TestViewController *s_self = tmp; // 还是导致循环引用
        dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(1 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
            // 2⃣️
            NSLog(@"block属性延时weak: %@, strong: %@", _self, s_self);
            // weak == strong != nil
        });
    };
    self.block();
}

注意，给__strong变量赋值的弱引用必须在弱引用指向的对象还没被销毁的时候完成赋值，否则拿到的弱引用是个nil。

另外，如果只是在1⃣️处定义并赋值了强引用对象，而在2⃣️处没有使用，则2⃣️处访问的弱引用也是空的。

底层数据结构

block本质也是一个OC对象，内部也有个isa指针。封装了函数调用以及调用环境。

参考

• OC 底层探索 - Block 详解 - 掘金

class与object_getClass：

• 实例class = object_getClass(self)
• 类class返回自身；object_getClass(类对象)返回元类。

实现：

// 判断当前对象、类的isa指向是不是类、原类
+ (BOOL)isMemberOfClass:(Class)cls {
    return object_getClass((id)self) == cls;
}
- (BOOL)isMemberOfClass:(Class)cls {
    return [self class] == cls;
}

// 判断当前对象、类的isa是不是类、元类或者其子类类型
+ (BOOL)isKindOfClass:(Class)cls {
    for (Class tcls = object_getClass((id)self); tcls; tcls = tcls->superclass) {
        if (tcls == cls) return YES;
    }
    return NO;
}
- (BOOL)isKindOfClass:(Class)cls {
    for (Class tcls = [self class]; tcls; tcls = tcls->superclass) {
        if (tcls == cls) return YES;
    }
    return NO;
}

Class object_getClass(id obj)
{
    if (obj) return obj->getIsa();
    else return Nil;
}

显然isKindOfClass范围更大，当调用对象和参数都是类时，类对象的isa指向元类对象，而其元类的superclass指向class对象，所以满足条件返回YES。所以[instance/class isKindOfClass:[NSObject class]];都返回 1。

@interface Person : NSObject
@end
......
    BOOL res1 = [[NSObject class] isKindOfClass:[NSObject class]];
    BOOL res2 = [[NSObject class] isMemberOfClass:[NSObject class]];
    BOOL res3 = [[Person class] isKindOfClass:[Person class]];
    BOOL res4 = [[Person class] isMemberOfClass:[Person class]];

    NSLog(@"%d,%d,%d,%d", res1, res2, res3, res4);
......

    // 1,0,0,0

TaggedPointer专门用来存储小的对象，如NSNumber、NSDate、NSString。其存储的不是地址，而是真正的值，所以它直接存储到栈中。

引入：

对于指针类型，其长度足够存储一些短小的值，而不必操作堆分配与管理内存。对于大的值，即超过指针类型长度的，则还是在堆中分配内存。所以对于小的值指针内容就包含值，而大的值才是堆内存地址。

存储内容：值+标记

面试题

执行以下两段代码，有什么区别？

dispatch_queue_t queue = dispatch_get_global_queue(0, 0);
for (int i = 0; i < 1000; i++) {
    dispatch_async(queue, ^{
        self.name = [NSString stringWithFormat:@"abcdefghij"];
    });
}

会崩溃，因为该name为__NSCFString类型，存储在堆上，是个常规对象，需要维护引用计数。通过setter赋值，异步并发调用会有多条线程执行[_name release]，连续release两次就会造成对象的过度释放。

dispatch_queue_t queue = dispatch_get_global_queue(0, 0);
for (int i = 0; i < 1000; i++) {
    dispatch_async(queue, ^{
        self.name = [NSString stringWithFormat:@"abcdefghi"];
    });
}

正常，该name为NSTaggedPointerString类型，在objc_release函数中会判断指针是不是TaggedPointer类型，是的话就不对对象进行release操作，也就避免了过度释放对象。

参考

• iOS Tagged Pointer (源码阅读必备知识) - 掘金
• 深入理解Tagged Pointer · 唐巧的博客
• iOS - 老生常谈内存管理（五）：Tagged Pointer - 掘金
• iOS内存管理之Tagged Pointer-InfoQ

objc_msgSend调用方法的本质是通过isa指针找到该类，然后寻找方法，找到后调用。如果没有找到则通过superClass找到父类，继续查找方法。

对象结构体中的isa指向类对象。类对象的isa指向元类。元类的isa指向NSObject的元类。

对象方法是保存在类对象的结构体中，所以调用实例方法时，要去类对象中查找。以此类推，类方法也是如此。

实例对象存放isa指针以及示例变量，通过isa指针可以找到实例对象所属的类对象。类中存放着方法列表。方法列表中SEL作为key，IMP作为value。在编译期间，根据方法名字会生成唯一的标识SEL。IMP是指向最终函数实现的函数指针。整个Runtime的核心是objc_msgSend函数，通过给类发送SEL传递消息，找到匹配的IMP再获得最终的实现，并执行方法。

消息发送阶段：

1. 判断receiver是否为空，是则直接返回，否则继续。
2. 从receiverClass的缓存中，查找方法找到则调用方法，否则继续。
3. 从receiverClass的class_rw_t中查找方法，如果找到了则缓存下来，调用方法，否则继续。
4. 去父类的缓存和class_rw_t中查找，步骤同上，找到了则缓存下来，没有则继续往上找父类，都没有则消息发送阶段结束，进入第二阶段：动态方法解析。

动态方法解析阶段：

调用-/+resolveClassMethod:，在方法中调用class_addMethod函数添加SEL对应的方法实现IMP。以上方法中没有处理，则进入第三阶段：消息转发。

消息转发阶段：

1. 判断-/+forwardingTargetForSelector:的返回值，非空则调用objc_msgSend(返回值, SEL)，向返回值发送消息。返回空则继续。
2. 调用-/+methodSignatureForSelector:方法，如果返回不为空，则调用-/+forwardInvocation:方法中处理。若本类无法处理则继续往父类查询。如果返回空，则继续。
3. 调用-doesNotRecognizeSelector:方法。

注意：只能对运行时动态创建的类添加成员变量（ivars），不能向已存在的类添加成员变量。因为在编译时只读的class_ro_t结构体就被确定下来，其包含了分配对象的空间大小，在运行时不可改变。

NSProxy

NSProxy和NSObject是同一层级的，可以理解为NSProxy是一个基类，都遵循了NSObject协议。NSProxy就是专门用来解决重点对象转发的问题。

与NSObject接收消息流程不一样，NSProxy简化了其中的流程：

1. [proxyObj message]
2. 到proxyObj类对象寻找对应的方法，找到调用。否则继续。
3. 尝试调用resolveClassMethod进行动态方法解析
4. 尝试进入父类对象递归查找方法，找到调用。否则继续。
5. 尝试调用forwardingTargetForSelector进行消息转发。返回空则继续。
6. 尝试调用methodSignatureForSelector+forwardInvocation进行消息转发。

所以对于处理消息转发，它比NSObject更高效。也阐明了该类的使用方式就是实现消息转发的两个方法即可。

注意，无需调用init方法。

#import "CLProxy2.h"

@implementation CLProxy2

+(instancetype)proxyWithTarget: (id)target {
	// NSProxy对象不需要调用init，因为它本来就没有init方法，直接alloc之后就可以使用
    CLProxy2 *proxy = [CLProxy2 alloc];
    proxy.target = target;
    return proxy;
}


-(NSMethodSignature *)methodSignatureForSelector:(SEL)sel {
    return [self.target methodSignatureForSelector:sel];
}

-(void)forwardInvocation:(NSInvocation *)invocation {
    invocation.target = self.target;
    [invocation invoke];
}

@end

isa

从arm64架构开始，isa变成了一个共用体（union）结果，使用位域来存储更多信息。

union isa_t {
    isa_t() { }
    isa_t(uintptr_t value) : bits(value) { }

    Class cls;
    uintptr_t bits;
    struct {
        ISA_BITFIELD;  // defined in isa.h
    };
};

define ISA_BITFIELD                                                      \
      uintptr_t nonpointer        : 1;   //指针是否优化过                                   \
      uintptr_t has_assoc         : 1;   //是否有设置过关联对象，如果没有，释放时会更快                                   \
      uintptr_t has_cxx_dtor      : 1; 	 //是否有C++的析构函数（.cxx_destruct），如果没有，释放时会更快                                     \
      uintptr_t shiftcls          : 33; //存储着Class、Meta-Class对象的内存地址信息 \
      uintptr_t magic             : 6;  //用于在调试时分辨对象是否未完成初始化                                     \
      uintptr_t weakly_referenced : 1;  //是否有被弱引用指向过，如果没有，释放时会更快                                     \
      uintptr_t deallocating      : 1;  //对象是否正在释放                                     \
      uintptr_t has_sidetable_rc  : 1;  //引用计数器是否过大无法存储在isa中                                     \
      uintptr_t extra_rc          : 19 //里面存储的值是引用计数器减1
#   	define RC_ONE   (1ULL<<45)
#   	define RC_HALF  (1ULL<<18)

• nonpointer：0：普通指针，存储着Class、Meta-Class对象的内存地址；1：优化过，使用位域存储更多的信息。
• has_assoc：是否有关联过对象。否：释放更快。
• has_cxx_dtor：是否有C++析构函数（.cxx_destruct）。否：释放更快。
• shiftcls：存储着Class、Meta-Class对象的内存地址信息。
• magic：调试时分辨是否完成初始化。
• weakly_referenced：是否被弱引用指向过。否：释放更快。
• deallocating：对象是否正在释放。
• extra_rc：引用计数器-1。
• has_sidetable_rc：引用计数器是否过大无法存储在isa中。1：引用计数器会存储在SideTable类的属性中。

void *objc_destructInstance(id obj) 
{
    if (obj) {
        //是否有C++的析构函数
        bool cxx = obj->hasCxxDtor();
        //是否有设置过关联对象
        bool assoc = obj->hasAssociatedObjects();
        //有C++的析构函数，就去销毁
        if (cxx) object_cxxDestruct(obj);
         //有设置过关联对象，就去移除管理对象
        if (assoc) _object_remove_assocations(obj);
        
        obj->clearDeallocating();
    }

    return obj;
}

class

struct objc_object {
    Class _Nonnull isa  OBJC_ISA_AVAILABILITY;
};

struct objc_class : objc_object {
    // Class ISA;
    Class superclass;
    cache_t cache;    //方法缓存
    class_data_bits_t bits;    // 用于获取具体的类的信息
}

method_array_t、property_array_t、protocol_array_t是可读写的二维数组，包含了类的初始内容、分类内容。

如：method_array_t包含多个一位数组method_list_t，method_list_t里面存放多个method_t，method_t存放在方法imp指针、名称、类型等信息。

method_t

方法、函数的封装。

struct method_t {
    SEL name; // 函数名
    const char *types; // Type Encoding 编码(返回值类型，参数类型)
    MethodListIMP imp; // 指向函数的指针(函数地址)

    struct SortBySELAddress :
        public std::binary_function<const method_t&,
                                    const method_t&, bool>
    {
        bool operator() (const method_t& lhs,
                         const method_t& rhs)
        { return lhs.name < rhs.name; }
    };
};

IMP：函数的具体实现。

SEL：方法、函数名，底层结构与char *类似。可以通过@selector()和sel_registerName()获得。可以通过sel_getName()和NSStringFromSelector()转成字符串。名字相同的方法，SEL也是相同的。

class_ro_t

描述的是类的初始内容，其中的baseMethodList、baseProtocols、ivars、baseProperties是只读的一维数组。

cache_t

方法缓存。用哈希表缓存调用过的方法，可以提高方法查找速度。

当方法缓存太多的时候，超过了表容量的3/4的时候，就要扩容为原来的2倍。

类的本质

一个NSObject的本质是包含一个isa指针的结构体：

struct NSObject_IMPL {
	Class isa;
};

而其子类是在isa指针的基础上再加上自身的成员变量：

struct Student_IMPL {
    struct NSObject_IMPL NSObject_IVARS;
    int _age;
    int _no;  
};

所以一个子类的底层结构体是其父类结构体里的所有成员变量 + 子类自身定义的成员变量所组成的结构体。

class_getInstanceSize：获取OC类实例对象的实际大小。这个大小可以理解为该实例对象至少需要的空间大小，实际分配大小需要使用malloc_size。

malloc_size：得到一个指针指向的内存空间大小，这是系统为这个对象最终分配的内存大小。

所以回到问题：一个NSObject对象占用多少内存？

• 系统分配了16字节（通过malloc_size获取）；
• NSObject内部只使用了8个字节来存放isa指针变量。

对象的种类

OC对象主要分为3类：

• 实例对象（instance）
• 类对象（class）
• 元类对象（meta-class）

实例对象通过类alloc方法创建出来。存放的信息：

• isa指针（指向类）。
• 成员变量。

类对象在内存中是唯一。的类对象用来描述一个实例对象，存放信息：

• isa指针（指向元类）和superclass指针
• 属性
• 对象方法
• 协议
• 成员变量

元类对象在内存中也是唯一的。元类对象用来描述一个类对象，存放信息：

• isa指针和superclass指针（指向该类父类的元类）
• 类方法

类和元类都是objc_class（继承自objc_object），也有isa指针，也是对象。

元类的superclass指向基类的类对象，者决定了：

当我们调用一个类方法时，会通过类的isa指针找到元类，在元类中查找有无该类方法，如果没有则通过superclass逐级查询父元类，一直找到基类的元类，如果还没有，则去找基类中的同名的实例方法实现。

super

class Person: NSObject {}
class Student: Person {
    override init() {
        super.init()
        print("className: \(self.className), super.className: \(super.className)")
        // FoundationSwift.Student, FoundationSwift.Student
        print("superclass: \(self.superclass!), super.superclass: \(super.superclass!)")
        // superclass: Person, super.superclass: Person
    }
}

从上面发现， super和self调用的结构都是相同的。

super调用方法实际上是调用了objc_msgSendSuper(arg, SEL)函数。重点是第一个参数，其类型是__rw_objc_super：

//♥️♥️♥️C++中间代码里的定义
struct __rw_objc_super { 
	struct objc_object *object; 
	struct objc_object *superClass; 
	__rw_objc_super(struct objc_object *o, struct objc_object *s) : object(o), superClass(s) {} 
};

//⚠️⚠️⚠️objc源码中的定义
/// Specifies the superclass of an instance. 
struct objc_super {
    /// Specifies an instance of a class.
    __unsafe_unretained _Nonnull id receiver;

    /// Specifies the particular superclass of the instance to message. 
#if !defined(__cplusplus)  &&  !__OBJC2__
    /* For compatibility with old objc-runtime.h header */
    __unsafe_unretained _Nonnull Class class;
#else
    __unsafe_unretained _Nonnull Class super_class;
#endif
    /* super_class is the first class to search */
};

objc_super结构体成员：

• id receiver：消息接收者，实参传递的就是self，即Student对象。
• Class super_class：父类。

id objc_msgSendSuper(struct objc_super *super, SEL op, ...)

• struct objc_super *super：结构体指针，内容是{消息接收者（recv）， 消息接收者的父类类对象（[[recv superclass] class]）}。objc_msgSendSuper会将消息接收者的父类对象作为消息查找的起点。
• SEL op：要查找的方法。

所以说，调用super与调用self的不同只是super把查找方法的起点改为从父类开始而已，所以像一些父类没有实现，而NSObject基类实现的方法，两者调用结果无异，因为最终的消息接收者还是self，即当前对象。

若要想super和self调用方法结果不一致，必须是当前类和父类都实现了相同的方法，若只有父类实现了，就都是父类的结果。这与一般方法查找父类实现的逻辑一致。

参考

• OC对象的本质（上）：OC对象的底层实现原理 - 掘金
• OC对象的本质（中）：OC对象的种类 - 掘金
• OC对象的本质（下）—— 详解isa&superclass指针 - 掘金
• 深入理解 Objective-C Runtime 机制 - 掘金

isa指针

//***********♦️♦️CLPerson♦️♦️************
@interface CLPerson : NSObject
@property (nonatomic, copy) NSString *name;
-(void)print;
@end

@implementation CLPerson
-(void)print {
    NSLog(@"My name's %@", self.name);
}
@end

//***********🥝🥝ViewController.m🥝🥝************ 

@implementation ViewController
- (void)viewDidLoad {
    [super viewDidLoad];
    
    id cls = [CLPerson class];
    void *obj = &cls;
    [(__bridge id)obj print]; 
}
@end

最终输出结果：

My name's <ViewController: 0x7fce43e08aa0>

为什么print可以被调用

因为：

• 实例对象 = 指向类的指针
• cls指向类，obj指向cls，相当于obj是指向类的指针。

所以(__bridge id)obj就相当于实例变量的效果。

为什么打印是<ViewController: 0x7fce43e08aa0>

首先self.name就是通过指针调用的self->_name。

实例对象底层是一个结构体，存放isa指针和成员变量列表，因为指针在arm64位上占8位，name又是CLPerson的第一个成员，所以self->_name就是基于对象地址往高地址偏移8位读取的内存。

栈空间是存放被调用函数内部所定义的局部变量的。先定义的局部变量在栈底高地址。所以上述代码的局部变量布局为：

这里隐藏了个细节：[super viewDidLoad];。该代码的底层调用是：

objc_msgSendSuper(
    (__rw_objc_super){
        (id)self, 
        (id)class_getSuperclass(objc_getClass("ViewController"))},
    @selector(viewDidLoad));

相当于cls的高地址方向还有一个self局部变量，就ViewController实例对象，所以self->_name指向的就是cls的上一个局部变量，即高地址方向偏移8位——ViewController实例对象。

扩展：类似的，如果没有[super viewDidLoad];就会出现BAD_ACCESS错误。如果cls前面多了个OC对象局部变量，则打印该局部变量。注意还是需要前面有个OC对象，否则还是会BAD_ACCESS。

更多扩展：iOS探索 isa面试题分析 - 掘金

autoreleasepool

@interface ViewController ()
{
    __weak NSString *string_weak;
}

@end

@implementation ViewController

- (void)viewDidLoad {
    [super viewDidLoad];
    
    // 各场景
    
    NSLog(@"string: %@ %s", string_weak,__func__);
}
- (void)viewWillAppear:(BOOL)animated{
    [super viewWillAppear:animated];
    NSLog(@"string: %@ %s", string_weak,__func__);
}

- (void)viewDidAppear:(BOOL)animated{
    [super viewDidAppear:animated];
    NSLog(@"string: %@ %s", string_weak,__func__);
}

场景一

NSString *str =  [NSString stringWithFormat:@"https://ityongzhen.github.io/"];
string_weak = str;

// 输出
string: https://ityongzhen.github.io/ -[ViewController viewDidLoad]
string: https://ityongzhen.github.io/ -[ViewController viewWillAppear:]
string: (null) -[ViewController viewDidAppear:]

1. 创建对象，ref=1，并添加到当前的autoreleasepool中；
2. 赋值到局部变量，ref+1=2；
3. viewDidLoad方法返回，局部变量被回收，ref-1=1；
4. viewDidLoad和viewWillAppear在同一个RunLoop中，所以还能访问；viewDidLoad已经是下一个RunLoop，已经被释放。

场景二

@autoreleasepool {
    NSString *str =  [NSString stringWithFormat:@"https://ityongzhen.github.io/"];
    string_weak = str;
}

// 输出
string: (null) -[ViewController viewDidLoad]
string: (null) -[ViewController viewWillAppear:]
string: (null) -[ViewController viewDidAppear:]

1. 创建对象，ref=1；
2. 赋值到局部变量，ref+1=2；
3. 离开作用域域，ref-1=1；
4. 离开autoreleasepool，调用release，ref-1=0，对象释放。

所以后序在viewDidLoad方法中访问的对象已经被释放。

场景三

NSString *str = nil;
@autoreleasepool {
    str =  [NSString stringWithFormat:@"https://ityongzhen.github.io/"];
    string_weak = str;
}

// 输出
string: https://ityongzhen.github.io/ -[ViewController viewDidLoad]
string: (null) -[ViewController viewWillAppear:]
string: (null) -[ViewController viewDidAppear:]

1. 创建对象，ref=1；
2. 赋值到局部变量，ref+1=2；
3. 离开autoreleasepool，调用release，ref-1=1，对象释放。
4. viewDidLoad方法返回时，ref-1=0，对象被释放。

所以在viewDidLoad方法中访问对象时，还能访问，离开方法后就无法访问。

注意

• 如果字符串过短，会变成存储在栈的TaggedPointer，无需引用计数管理，在所有方法中都可以访问。
• 类似的，如果字符串位@"..."形式，则存储到常量区，也无需引用计数管理，在所有方法中也都可以访问。

对于栈上的内存，会在离开作用域后被回收。

更多

• 深入浅出 Runtime（五）：相关面试题 - 掘金

编译完，每个分类都会生成一个category_t结构体，里面存储名称、对象方法列表、类方法列表、协议方法列表、属性列表。

struct category_t {
    const char *name;
    classref_t cls;
    struct method_list_t *instanceMethods;
    struct method_list_t *classMethods;
    struct protocol_list_t *protocols;
    struct property_list_t *instanceProperties;
    // Fields below this point are not always present on disk.
    struct property_list_t *_classProperties;

    method_list_t *methodsForMeta(bool isMeta) {
        if (isMeta) return classMethods;
        else return instanceMethods;
    }

    property_list_t *propertiesForMeta(bool isMeta, struct header_info *hi);
};

在合并分类的时候，其方法列表等不会覆盖原来类中的方法，是共存的。但分类的方法在前面，原来类的方法在后面，调用的时候，就会调用分类中的方法，如果多个分类的相同方法，后编译的分类会被调用。

如果想要执行被“覆盖”的类定义方法，可以逆序遍历方法列表，第一次取得的就是类定义的方法：

- (void)foo{   
  [类 invokeOriginalMethod:self selector:_cmd];
}

+ (void)invokeOriginalMethod:(id)target selector:(SEL)selector {
    uint count;
    Method *list = class_copyMethodList([target class], &count);
    for ( int i = count - 1 ; i >= 0; i--) {
        Method method = list[i];
        SEL name = method_getName(method);
        IMP imp = method_getImplementation(method);
        if (name == selector) {
            ((void (*)(id, SEL))imp)(target, name);
            break;
        }
    }
    free(list);
}

类对象/元类对象才是最终存储分类实例/类方法、属性、协议的地方。

扩展问题

Category的原本使用场景

区分不同的功能模块，使用分类单独实现。

Category的实现原理

分类编译后是category_t结构体，里面存储着分类的对象方法、类方法、属性、协议信息，在程序运行时，Runtime会把分类的数据合并到类信息（类对象、元类对象）中。

Category与Extension的区别

Extension在编译的时候，其数据已经包含在类信息中。Category在运行时才会把数据合并到类信息中。

Category为什么不能添加成员变量

category_t结构体只能存储属性，但没有存储objc_ivar_list结构体，没有用存储成员变量的地方，所以不能添加成员变量。

+load方法的执行

Runtime在加载类和分类的时候，会调用所有的+load方法，即使没有该类还没使用。

调用方式：函数地址直接调用。

调用时机：加载类和分类时调用一次，只会调用一次。

+load方法调用顺序：

1. 调用类的+load
   • 按照编译顺序进行；
   • 先调父类，再调子类；
2. 按照编译顺序调用分类的+load方法。

先去调用类的+load方法，若有父类则先调用父类的+load方法，再去调用分类的+load方法。

+initialize方法的执行

+initialize需要在使用（调用方法）类的时候才会调用。其调用顺序跟普通方法一致，即若有分类实现的+initialize方法，则调用分类的方法。

调用方式：objc_msgSend调用。

调用时机：在类第一次接收到消息时调用，所以父类可能会执行多次（只有父类实现了+initialize方法，而子类没有实现）。

参考

• 详解iOS中分类Cateogry | 殷永振
• iOS底层系列：Category - 掘金
• Objective-C之Category的底层实现原理 - 掘金

相关API：

// objc/runtime.h
/** 给一个对象设置关联对象
object: 需要添加关联的源对象
key: 关联值的唯一key
value: 关联的具体值
policy: 关联的策略 (类似声明properties的参数)
*/
void objc_setAssociatedObject(id object, const void *key, id value, objc_AssociationPolicy policy)

/** 获取某个对象的某个关联对象
object: 需要获取关联的源对象
key: 关联值的唯一key
*/
id objc_getAssociatedObject(id object, const void *key)

/** 移除对象的关联对象
 object: 需要移除的源对象
*/
void objc_removeAssociatedObjects(id object) 

应用场景：

• 给系统类、第三方类添加属性。
• 使用RETAIN_NONATOMIC关联类型的对象关联目标对象，以监听目标对象的生命周期。

实现原理

组成部分：

• AssociationsManager：管理一个AssociationsHashMap。
• AssociationsHashMap：用objc_setAssociatedObject传入的object为基础，进行一些其他操作后作为Key，ObjectAssociationMap为Value。
• ObjectAssociationMap：用objc_setAssociatedObject传入的key作为Key，ObjcAssociation为Value。

对象关联的对象在-dealloc调用的object_dispose函数中释放。

参考

• iOS 底层原理03: Category, 关联对象 - 掘金

• Key：对象
• Value：weak指针数组

当该对象dealloc方法被调用时，Runtime会以该对象为key，从SideTable的weak_table哈希表中，找到对应的weak指针列表，然后吧其中的weak指针逐个置为nil。

底层细节

使用weak修饰的对象，底层调用了objc_initWeak函数。里面获取weak指针地址和对象地址传递到下一层函数存储。最终存储到SideTable中的weak_table哈希表。

struct SideTable {
    spinlock_t slock; // 锁
    RefcountMap refcnts; // 指向对象引用计数的哈希表（仅在未开启isa优化或在isa优化下isa_t引用计数溢出时才会用到）
    weak_table_t weak_table; // 存储对象若引用指针的哈希表
}

struct weak_table_t {
    weak_entry_t *weak_entries; // 用于存储哈希数组
    size_t    num_entries;
    uintptr_t mask;
    uintptr_t max_hash_displacement;
};

参考

• iOS底层原理：weak的实现原理 - 掘金

解决：转换成 .cer 格式。

openssl x509 -in xxx.crt -inform PEM -out xxx.cer -outform DER

• 只支持二进制证书，不支持 base64 证书。

若用文本编辑器打开的证书是长这样的：

-----BEGIN CERTIFICATE-----
MIIGCDCCA/CgAw……
-----END CERTIFICATE-----

iOS 不支持 PEM 格式的证书，需要转换成 DER 二进制格式。

原理：将文本中的 base64 String 解 base64，得出的 data 再转 string。

最保险方法：

使用系统的钥匙串访问，导入证书，再导出即可。

使用代码支持 PEM 证书

安卓是直接支持 PEM 格式证书，为了兼容 iOS 以及减少证书文件的维护成本，在 iOS 端，可以通过代码从解密后的 PEM 证书中抽取格式支持的证书二进制数据。

PEM，Privacy Enhanced Mail，一般为文本格式，以 -----BEGIN... 开头，以 -----END... 结尾。中间的内容是 BASE64 编码。这种格式可以保存证书和私钥，有时我们也把PEM 格式的私钥的后缀改为 .key 以区别证书与私钥。

可见 PEM 证书是个文本，且既然有 BEGIN END 包裹，那么可能会有多个证书。所以可以给 NSData 增加一个扩展：

@property (nonatomic, strong, readonly) NSArray<NSData *> *tool_pemBins;

实现也很简单，使用正则表达式析出 BEGIN END 包裹的内容，去除换行，然后 BASE64 解码。

// NSData+Tool
- (NSArray<NSData *> *)tool_pemBins {
    NSMutableArray *array = NSMutableArray.array;
    
    NSString *string = [[NSString alloc] initWithData:self encoding:NSUTF8StringEncoding];
    for (NSString *substring in [string tool_substringsMatchedRx:@"^-*BEGIN \\w*-*$([\\s\\S]*)^-*END \\w*-*$"]) {
        NSString *content = substring;
        content = [content stringByReplacingOccurrencesOfString:@"\n" withString:@""];
        NSData *data = [[NSData alloc] initWithBase64EncodedString:content options:0];
        [array addObject:data];
    }
    
    return array.copy;
}

// NSString+Tool
- (NSRegularExpression *)tool_rx {
    NSRegularExpressionOptions options = NSRegularExpressionCaseInsensitive | NSRegularExpressionAnchorsMatchLines;
    return [NSRegularExpression regularExpressionWithPattern:self options:options error:NULL];
}
- (NSArray<NSString *> *)tool_substringsMatchedRx:(NSString *)rx {
    NSMutableArray *array = NSMutableArray.array;
    NSArray *results = [rx.tool_rx matchesInString:self options:0 range:NSMakeRange(0, self.length)];
    for (NSTextCheckingResult *result in results) {
        for (int i = 1; i < result.numberOfRanges; i++) {
            NSRange range = [result rangeAtIndex:i];
            if (range.location == NSNotFound || range.length == 0) continue;
            [array addObject:[self substringWithRange:range]];
        }
    }
    return array.copy;
}

做这个的时候，时间都花在正则表达式的匹配上了，因为 iOS 的正则表达式跟 sublime text 编辑器的正则表达式搜索有细微的差别，语法似乎也支持得不够全面，因此需要在 iOS 上做不断修整。

参考资料

• https://www.jianshu.com/p/74465973da5e
• SSL 证书格式普及，PEM、CER、JKS、PKCS12

• 使用 NSPointerArray 存储 weak delegate；
• 使用 NSHashTable 存储 weak delegate；
• 使用 NSProxy 进行转发；
• 使用 NSObject 封装 target 和 selector，进行遍历调用。

本文讨论的是最后一种，但可以结合 NSProxy 进行高效的转发。

实现原理

对象封装 weak target，和 selector，使用数组存储这个封装对象，在回调的地方，遍历数组调用各个代理方法。

封装对象命名

• Delegator

结合 NSProxy 便捷消息转发

NSProxy 可以实现消息的转发，具体可见 YYWeakProxy 的实现，其可以实现消息转发以达到，调用 proxy 的方法，直接就是调用 target 的方法。

如果结合了 NSProxy，则可以少一层存储和调用 selector 的逻辑。

QMUI 的多代理

QMUI 的多代理实现有点巧妙，其使用方法注入，对 delegate 的 setter 和 getter 属性进行修改，变成调用其容器中的多代理方法。

而其容器也进行了封装，具体看 QMUIMultipleDelegates 的实现。

iOS 可以通过 UTI 来进行转换。UTI 是什么呢，用过 Media 相关的框架的同学可能不会陌生。需要了解的同学，可浏览以下资料： - Uniform Type Identifier Concepts - Uniform Type Identifier

具体实现代码如下：

/// extension -> UTI
NSString *UTIForExtension(NSString *extension) {
    //Request the UTI via the file extension
    NSString *theUTI = (__bridge_transfer NSString *)UTTypeCreatePreferredIdentifierForTag(kUTTagClassFilenameExtension, (__bridge CFStringRef)(extension), NULL);
    return theUTI;
}

/// 匹配 UTI
BOOL extensionConformToUTI(NSString *extension, CFStringRef theUTI) {
    NSString *preferredUTI = UTIForExtension(extension);
    return (UTTypeConformsTo((__bridge CFStringRef) preferredUTI, theUTI));
}

BOOL extensionLikelyImage(NSString *extension) {
    return extensionConformToUTI(extension, CFSTR("public.image"));
}
BOOL extensionLikelyAudio(NSString *extension) {
    return extensionConformToUTI(extension, CFSTR("public.audio"));
}
BOOL extensionLikelyMovie(NSString *extension) {
    return extensionConformToUTI(extension, CFSTR("public.movie"));
}

🎁彩蛋

顺便的，给出 UTI 与 mimeType 的转换，以及相关的实用函数。

/// UTI -> mimeType
NSString *mimeTypeForUTI(NSString *aUTI) {
    CFStringRef theUTI = (__bridge CFStringRef) aUTI;
    CFStringRef mimeType = UTTypeCopyPreferredTagWithClass(theUTI, kUTTagClassMIMEType);
    return (__bridge_transfer NSString *)mimeType;
}

/// 元素唯一字典
NSArray *uniqueArray(NSArray *anArray) {
    NSMutableArray *copiedArray = [NSMutableArray arrayWithArray:anArray];
    for (id object in anArray)     {
        [copiedArray removeObjectIdenticalTo:object];
        [copiedArray addObject:object];
    }
    return copiedArray;
}

NSArray *conformanceArray(NSString *aUTI) {
    NSMutableArray *results = [NSMutableArray arrayWithObject:aUTI];
    NSDictionary *dictionary = utiDictionary(aUTI);
    id conforms = dictionary[(__bridge NSString *)kUTTypeConformsToKey];
    
    // No conformance
    if (!conforms) return results;
    
    // Single conformance
    if ([conforms isKindOfClass:[NSString class]]) {
        [results addObjectsFromArray:conformanceArray(conforms)];
        return uniqueArray(results);
    }
    
    // Iterate through multiple conformance
    if ([conforms isKindOfClass:[NSArray class]]) {
        for (NSString *eachUTI in (NSArray *) conforms)
            [results addObjectsFromArray:conformanceArray(eachUTI)];
        return uniqueArray(results);
    }
    
    // Just return the one-item array
    return results;
}

NSArray *allExtensions(NSString *aUTI) {
    NSMutableArray *results = [NSMutableArray array];
    NSArray *conformance = conformanceArray(aUTI);
    for (NSString *eachUTI in conformance)     {
        NSDictionary *dictionary = utiDictionary(eachUTI);
        NSDictionary *extensions = dictionary[(__bridge NSString *)kUTTypeTagSpecificationKey];
        id fileTypes = extensions[(__bridge NSString *)kUTTagClassFilenameExtension];
        
        if ([fileTypes isKindOfClass:[NSArray class]])
            [results addObjectsFromArray:(NSArray *) fileTypes];
        else if ([fileTypes isKindOfClass:[NSString class]])
            [results addObject:(NSString *) fileTypes];
    }
    
    return uniqueArray(results);
}

NSArray *allMIMETypes(NSString *aUTI) {
    NSMutableArray *results = [NSMutableArray array];
    NSArray *conformance = conformanceArray(aUTI);
    for (NSString *eachUTI in conformance) {
        NSDictionary *dictionary = utiDictionary(eachUTI);
        NSDictionary *extensions = dictionary[(__bridge NSString *)kUTTypeTagSpecificationKey];
        id fileTypes = extensions[(__bridge NSString *)kUTTagClassMIMEType];
        
        if ([fileTypes isKindOfClass:[NSArray class]])
            [results addObjectsFromArray:(NSArray *) fileTypes];
        else if ([fileTypes isKindOfClass:[NSString class]])
            [results addObject:(NSString *) fileTypes];
    }
    
    return uniqueArray(results);
}

NSDictionary *utiDictionary(NSString *aUTI) {
    NSDictionary *dictionary = (__bridge_transfer NSDictionary *)UTTypeCopyDeclaration((__bridge CFStringRef) aUTI);
    return dictionary;
}

框架层：

• NSDate 属于Foundation
• CFAbsoluteTimeGetCurrent() 属于 CoreFoundatio
• CACurrentMediaTime() 属于 QuartzCore

本质区别：

NSDate 或 CFAbsoluteTimeGetCurrent() 返回的时钟时间将会会网络时间同步，从时钟偏移量的角度。

mach_absolute_time() 和 CACurrentMediaTime() 是基于内建时钟的，能够更精确更原子化地测量，并且不会因为外部时间变化而变化（例如时区变化、夏时制、秒突变等），但它和系统的 uptime 有关，系统重启后其值会被重置。CACurrentMediaTime 方法获取到的时间，是手机从开机一直到当前所经过的秒数。类似的，CADisplayLink 的时间戳也是使用该概念的时间（HostTime）。

常见用法：

NSDate、CFAbsoluteTimeGetCurrent()常用于日常时间、时间戳的表示，与服务器之间的数据交互 其中 CFAbsoluteTimeGetCurrent() 相当于 [[NSDate data] timeIntervalSinceReferenceDate];

CFAbsoluteTimeGetCurrent() 常用于测试代码的效率。

object file是个有结构的位元块。这些位元块包含程序代码】准备给Linker和Loader使用的相关信息。

查看object file：

objdump -macho -section-headers /bin/ls

object file的形式：

• Relocatable：包含可以在编译时被其他Relocatable链接的代码和数据，以生成Executable。多个Relocatable可被封装成.a（archive）静态库（static library、static archive）。
• Executable：可以载入内存的执行的指令集合。链接器会把静态库中的代码给定一个固定的load地址，并包含（copies and relocates）进Executable中。且每个Executable使用静态库都要拷贝一份静态库。
• Shared：一种特殊形式的Relocatable，类似动态库。不并入任何Executable，可在多个Executable之间共享。
• Bundle：在macOS中长作为插件使用。

macOS支持的可执行格式

通用二进制格式

通用二进制格式（Universal Binary、Fat Binary）。Apple提出这个是为了解决一些历史问题。macOS，更确切地说是OS X，最早是基于PPC架构的，后来才移植到Intel架构（OSX Tiger 10.4.7开始），通用二进制格式可以在PPC和x86两种处理器上执行。即，对多架构二进制文件的打包集合文件。

macOS的多架构二进制文件就是适配不同架构的Mach-O文件。

Mach-O

Mach-O（Mach Object File Format）是苹果平台OS上的可执行文件格式，类似于Linux和大部分UNIX的原声格式ELF（Extensible Firmware Interface）。

文件格式

Mach-O格式主要由以下3部分组成：

• Mach-O头（Mach-O Header）：描述了Mach-O的CPU架构、文件类型、加载命令等信息。
• 加载命令（Load Command）：描述了文件中数据的具体组织结构，不同的数据类型使用不同的加载命令表示。
• 数据（Data）：存储每个段（Segment）的数据。段拥有一个或多个Section，存储数据和代码，与ELF文件中的段类似。

参考

• Mach-O 文件格式探索 · GitBook
• 深入剖析Macho (1) | SatanWoo
• ObjC 中国 - Mach-O 可执行文件

静态库

静态库（Static Libraries），多个目标文件（object file）的打包集合。

特点：

• 静态库会直接嵌入到App的Mach-O中。
• 编译时已经链接，启动时不需要二次查找。因此App启动更快。
• 每个Executable使用都要拷贝一份静态库。

构建设置

• Linking-Math-O Type: Static Library
• Dead Code Stripping: No

动态库

动态库（动态链接库、Dynamic Libraries、Shared Library、Shared Object），同样也是目标文件的集合，与静态库区别的是嵌入App的方式和在App加载的方式。

特点：

• 以独立文件嵌入App包中。
• App的Mach-O中只包含其引用信息，使用的时候才进行动态链接和加载。可在两个时机载入，并动态分配一段地址：
  • App载入时（load time）：启动时加载，称为动态链接库。
  • App运行时（run time）：启动后加载，称为动态加载库。
• 多个Executable使用都不会进行拷贝。可独立更新。

只有系统库或在macOS上的动态库才有以上自由选择载入时机的特性，在iOS中，只能通过Embedding Frameworks的方式使用动态库，并在启动时载入与链接动态库。而其链接动态库也是造成启动时间长的原因。

在iOS的多个Executable可以是App和Extension，他们可以共用包中的framework。

列出所有动态链接的库：

otool -L <PathToArchive>/Products/Applications/<AppName>.app/<AppBinary>

区分

使用file命令输出对应的Mach-O信息：

静态库：current ar archive random library

动态库：dynamically linked shared library

性能差异

待定。

framework

framework时一个有着特定结构的文件夹，里面包含各种共享的资源。如：静态库/动态库、头文件、模块信息和资源（例如storyboard、xib、图像文件和本地化字符串）。

其中framework里面的object file类型决定了其可用的资源：

静态库：只能使用其中的头文件、模块信息。

动态库：可全部使用，即除了头文件、模块信息，还能嵌入资源。

集成方式

集成到App时有以下两个选项：

• Linked：仅链接。启动时链接则勾选，否则要运行时才链接则不勾选。
• Embedded：拷贝到App包中的framework目录。

对于静态库和动态库framework有不同的选择：

静态库：Linked。因为静态库已经拷贝到App的Executable Mach-O文件中，Embed是没意义的，虽然Xcode允许这样做。

动态库：Linked（iOS可选，macOS必选） + Embedded

动态更新动态库

这里的动态更新是针对于已编译的包的动态更新，不是运行时的动态更新。

首先对于iOS，上App Store的App是不允许动态更新动态库的，因为在iOS中使用动态库只能通过framework形式，而上App Store会进行签名，其中就包含对framework的哈希，即上架后，就不允许改变其framework。而动态更新framework的方式可以在in house和develop模式下使用。

iOS 利用 Framework 进行动态更新.md

CocoaPods中的使用

Podfile：

• use_frameworks!：当前范围使用framework。可以指定动态库、静态库。
  • use_frameworks! :linkage => :dynamic
  • use_frameworks! :linkage => :static

Podspec：

• spec.static_framework = true：当使用use_frameworks!标记时，使用静态库framework。
• 引用系统库：
  • spec.frameworks = 'QuartzCore', 'CoreData'
  • spec.libraries = 'xml2', 'z'
• 引用外部库：
  • spec.vendored_frameworks = 'MyFramework.framework', 'TheirFramework.framework'
  • spec.vendored_libraries = 'libProj4.a', 'libJavaScriptCore.a'

动态库巧用

减少静态库的依赖拷贝

通过前面我们知道可执文件（主程序或者动态库）在构建的链接阶段，遇到静态库，吸附进来；遇到动态库，打标记，彼此保持独立。

正因为动态库是保持独立的，那么可以自定义一个动态库把依赖的静态库吸附进来。对外整体呈现的是动态库特性。其他的组件依赖我们自定义的动态库，由于隔离性的存在，不会出现问题。

这个思路在处理项目组件化的时候非常有用，尤其是在使用Swift的项目中。

处理静态库之间的符号冲突

背景：需要知道，在打包IPA的时候，最终静态库会被连接到最终的那个可执行文件中。所以如果多个静态库拥有了相同的符号必定会产生符号冲突。

静态库的符号和动态库库符号可以隔离，进而避免了链接时产生的符号冲突。

这一点在处理一些由于底层三方库源码不能手动修改（比如boringssl与openssl）的时候，非常有用。

参考

• 翻译-在应用程序中嵌入framework.md
• 年轻人，听说你想使用Framework.md
• iOS动态库、静态库及使用场景、方式 - 简书

本文档介绍了如何使用音频队列服务（Audio Queue Services），这是Core Audio的Audio Toolbox框架中的一个C语言编程接口。

什么是音频队列服务

在iOS和Mac OS X中，音频队列服务提供了一种直接、低开销的的方式来录制和播放音频。这也是向iOS和Mac OS X程序中添加录制和播放功能所推荐使用的技术。

音频队列服务允许你录制和播放以下格式的音频：

• Linear PCM（线性PCM）。
• 任何你正在进行开发的苹果平台所原生支持的压缩格式。
• 任何用户已经安装相应编码器的其他格式。

音频队列服务是高级的。它让程序使用录音和播放设备（比如麦克风和扬声器）而不需要了解硬件接口的知识。也可以让你使用复杂的编码器而不用了解编码器的工作机制。

同时，音频队列服务也支持一些高级功能。提供了高精度的时间控制来支持播放进度和同步。你可以使用它来同步多个音频队列以及让视频和音频同步。

注意：音频队列服务提供了一些类似于之前在Mac OS X中Sound Manager提供的功能，它附加了例如同步的功能，Sound Manager在Mac OS X10.5中已经废弃了，并且不能和64位程序一起工作，苹果建议新的Mac OS X程序使用音频队列服务并将旧的程序用音频队列服务来替换Sound Manager。

音频队列服务是纯C接口的，你可以把它使用在Cocoa和Mac OS X命令行工具中，为了使你更加专注于音频队列服务，本文档中的示例代码通过使用Core Audio SDK中的C++类进行了简化，然而，无论是这个SDK还是C++语言都不是使用音频队列服务所必需的。

什么是音频队列？

在iOS和Mac OS X中，音频队列是一个用来录制和播放音频的软件对象，使用AudioQueueRef不透明数据类型来表示（在AudioQueue.h头文件中声明）。

音频队列完成以下工作：

• 连接音频硬件
• 内存管理
• 根据需要为已压缩的音频格式引入编码器
• 媒体的录制或播放

你可以将音频队列配合其他Core Audio的接口使用，再加上相对少量的自定义代码就可以在程序中创建一套完整的数字音频录制或播放解决方案。

音频队列架构

所有的音频队列都含有相同的基础结构，包含以下几部分：

• 一组音频队列缓冲区（audio queue buffers），每个音频队列缓冲区都是一个存储音频数据的临时仓库。
• 一个缓冲区队列（buffer queue），一个包含音频队列缓冲区的有序列表。
• 一个你自己编写的音频队列回调函数（audio queue callback）。

架构很大程度上依赖于这个音频队列是用来录制还是用来播放的。不同之处在于音频队列如何连接到它的输入和输入，还有它的回调函数所扮演的角色。

用来录制的音频队列

用于录制的的音频队列，使用AudioQueueNewInput函数创建，如图1-1的结构。

图1-1 用于录制的的音频队列

用于录制的音频队列的输入端一般连接到外部的音频硬件上，比如说麦克风。在iOS中，音频来自于由用户连接的设备：内置的麦克风或者耳机麦克风，如在Mac OS X下，音频来自于由用户在系统首选项中设置的系统默认音频输入设备。

用于录制的音频队列的输入端利用了你自己写的回调函数，当录制音频到磁盘上的时候，回调函数将存有从音频队列中接收到的新的音频数据的缓冲区写入到音频文件中。然而，用于录制的音频队列也可以用其他方法来使用。你也可以使用其中一种，比如说，在一个实时的分析仪中，在这种情况下，你的回调函数会直接向程序提供音频数据，而不是将它写入磁盘。

更多关于该回调的知识，参阅The Recording Audio Queue Callback Function。

每一个音频队列，无论是用于录制还是用于播放，都有一个或多个音频队列缓冲区。这些缓冲区排列在一个特殊的被称为缓冲区队列（buffer queue）的序列中。如图所示，音频队列缓冲区是按照他们被填充的顺序编号的——这也是和把他们交付给回调函数的顺序是相同的。有关音频队列是如何使用缓冲区，参阅The Buffer Queue and Enqueuing。

用于播放的音频队列

用于播放的音频队列，使用AudioQueueNewOutput函数创建，如图1-2结构。

图1-2 用于播放的音频队列

在用于播放的音频队列中，回调函数是在输入端的，这个回调函数的职责就是从磁盘（或其他来源）中获取音频数据，然后将它交付给音频队列。当没有更多音频数据需要播放的时候告诉音频队列停止。更多关于这个回调函数的知识，参阅The Playback Audio Queue Callback Function。

用于播放的音频队列的输出端一般都是连接到外部的音频设备的，比如说扬声器。在iOS中，音频通过用户选择的设备播放，如接收者是耳机。在Mac OS X中，默认情况下，音频会通过用户在系统首选项中设置的默认音频输出设备中输出。

音频队列缓冲区

音频队列缓冲区（audio queue buffer）是一个AudioQueueBuffer类型的数据结构（在AudioQueue.h头文件中声明）：

typedef struct AudioQueueBuffer {
    const UInt32   mAudioDataBytesCapacity;
    void *const    mAudioData;
    UInt32         mAudioDataByteSize;
    void           *mUserData;
} AudioQueueBuffer;
typedef AudioQueueBuffer *AudioQueueBufferRef;

上述代码中的mAudioData字段，指向了缓冲区本身：一个用来当作暂时存放录制或播放音频数据的容器的内存，其他字段中的数据用来辅助音频队列管理这个缓冲区。

音频队列可以使用任意数量的缓冲区。一般情况下设置为3，这样就可以让一个缓冲区忙于将数据写入磁盘，同时另一个缓冲区在填充新的音频数据，第三个缓冲区在需要做磁盘I/O延迟补偿的时候使用。图1-3展示了这个过程。

音频队列负责对它的缓冲区进行内存管理：

• 当调用AudioQueueAllocateBuffer函数的时，音频队列创建一个缓冲区。
• 当通过调用AudioQueueDispose函数释放一个音频队列的时，这个音频队列释放掉它拥有的缓冲区。

这提高了添加到程序中录制和播放功能的健壮性。同时它也帮助你优化资源的使用。

关于AudioQueueBuffer数据结构的完整描述，参阅_Audio Queue Services Reference。_

缓冲区队列和入队

传递给音频队列的缓冲区队列，顾名思义就是音频队列服务（Audio Queue Services），在Audio Queue Architecture中，将提及缓冲区队列，一个缓冲区的有序列表，其中描述了音频队列对象如何配合回调函数在录制或播放的过程中管理缓冲区队列。尤其是入队音频队列，即缓冲区队列对音频队列缓冲区的附加操作。无论是在实现录制或者播放，入队都是你在回调函数中需要执行的任务。

录制过程

当进行录制时，一个音频队列缓冲区填充了从输入设备（如麦克风）中获取的音频数据。缓冲区队列中的其他缓冲区将在当前缓冲区的末尾依次排队等待填充音频数据。

音频队列将按照缓冲区填充的顺序把已填充过音频数据的缓冲区交付给你的回调函数。图1-3展示了当使用音频队列录制时的过程。

图1-3 录制过程

1. 录制开始，音频队列用获取的数据填充缓冲区。
2. 第一个缓冲区填充完毕，音频队列调用回调函数来处理这个被填充满的缓冲区（缓冲区一）。
3. 回调函数将缓冲区的内容写到音频文件中。同时，音频队列将另一个缓冲区（缓冲区二）填充新获取的数据。
4. 回调函数将刚刚写入磁盘的缓冲区（缓冲区一）入队，使它重新重新回到被填充的队列。
5. 音频队列再一次调用回调函数，处理下一个填充完毕的缓冲区（缓冲区二）。
6. 回调函数将这个缓冲区的内容写入到音频文件。

这种稳定状态会一直持续到用户停止录制。

播放过程

当进行播放的时候，音频队列缓冲区将被传送到输出设备（如扬声器）。缓冲区队列中其他的缓冲区讲按顺序排在当前缓冲区末尾等待播放。

音频队列将已经播放过的音频数据按照他们播放的顺序交付给你的回调函数，回调函数将新的音频数据读取到一个缓冲区中，然后将它入队。图1-4展示了当使用音频队列播放时的过程。

图1-4 播放过程

1. 程序启动用于播放的音频队列，程序对每一个音频队列缓冲区调用回调函数，填充这些缓冲区并且将它们加入缓冲区队列。
2. 启动操作会确保当程序调用AudioQueueStart函数之后，播放可以立即执行。
3. 音频队列将第一个缓冲区（缓冲区一）交付给输出设备。当第一个缓冲区被播放完毕之后，用于播放的音频队列就进入了一个稳定的循环状态。
4. 音频队列开始播放下一个缓冲区（缓冲区二）。
5. 调用回调函数，处理刚刚播放完的那个缓冲区（缓冲区一）。
6. 这个回调函数从音频文件中读取数据填充缓冲区然后入队播放。

控制播放过程

音频队列缓冲区总是按照他们入队的顺序进行播放，然而，在播放过程中，音频队列服务提供了AudioQueueEnqueueBufferWithParameters函数来进行一些控制，这个函数有以下功能：

• 设置缓冲区的精确播放时间，这可以实现音频同步。
• 截断音频队列缓冲区开头或结尾的帧，这可以让你去除开头或结尾的静音。
• 在缓冲区的粒度上设置播放增益。

关于更多播放增益的信息，参阅Audio Queue Parameters，如果要了解对AudioQueueEnqueueBufferWithParameters函数的完整描述，参阅_Audio Queue Services Reference_。

音频队列回调函数

一般来说，使用音频队列服务的大部分编程任务都在编程音频队列回调函数上。

在录制或播放过程中，音频队列将反复调用它所拥有的音频队列回调函数。调用的时间间隔取决于音频队列缓冲区的容量，一般来一说这个时间在半秒到几秒。

无论对于录制或者播放，音频队列回调的一个职责就是返回一个缓冲区队列的音频队列缓冲区。回调函数使用AudioQueueEnqueueBuffer函数将一个缓冲区加入到缓冲区队列的末尾。对于播放来说，你也可以使用AudioQueueEnqueueBufferWithParameters函数来获得更多的控制。

用于录制的音频队列的回调函数

本节介绍了一般情况下（将音频录制到磁盘上）的回调函数。以下是用于录制的回调函数的原型（在AudioQueue.h头文件中声明）：

AudioQueueInputCallback (
    void                               *inUserData,
    AudioQueueRef                      inAQ,
    AudioQueueBufferRef                inBuffer,
    const AudioTimeStamp               *inStartTime,
    UInt32                             inNumberPacketDescriptions,
    const AudioStreamPacketDescription *inPacketDescs
);

用于录制的音频队列，在调用回调函数的时候，提供了把下一组音频数据写入到文件的一切信息：

• inUserData：通常是一个用来保存音频队列和它的缓冲区状态信息的自定义结构，或者一个音频文件对象 （AudioFileID类型）表示正在写入的文件，或者该文件的音频格式信息。
• inAQ：是调用回调函数的音频队列。
• inBuffer：是一个被音频队列填充新的音频数据的音频队列缓冲区，它包含了回调函数写入文件所需要的新数据。数据已经根据你在自己指定的自定义结构（由inUserData参数传入）中指定的格式格式化。更多信息，可参阅Using Codecs and Audio Data Formats。
• inStartTime：是缓冲区中的首个采样的参考时间，对于基本的录制，你的回调函数不会使用这个参数。
• inNumberPacketDescriptions：是inPacketDescs参数中包描述符（packet descriptions）的数量，如果你正在录制一个VBR（可变比特率（variable bitrate））格式，音频队列将回调该参数给你，这个参数可以让你传递给AudioFileWritePackets函数。CBR（常量比特率（constant bitrate）） 格式不使用包描述。对于CBR录制，音频队列会设置这个参数并且将inPacketDescs这个参数设置为NULL。
• inPacketDescs：是一组对应于缓冲区中采样的包描述符，音频队列提供了这个参数的值，如果音频文件是VBR格式的，回调函数可以将这个值传递给AudioFileWritePackets函数（在AudioFile.h头文件中声明）。

如果要了解更多关于用于录制的回调函数的信息，参阅Recording Audio和Audio Queue Services Reference。

用于播放的音频队列的回调函数

本节介绍了一般情况下（从磁盘文件播放音频的回调函数。 下面是用于播放的回调函数的原型（在AudioQueue.h头文件中声明）：

AudioQueueOutputCallback (
    void                  *inUserData,
    AudioQueueRef         inAQ,
    AudioQueueBufferRef   inBuffer
);

用于播放的音频队列，在调用回调函数的时候，提供了从文件读取下一组音频数据所需的信息：

• inUserData：一般来说是一个你创建的包含音频队列和它的缓冲区的的状态信息的自定义结构；或者一个音频文件对象 （AudioFileID类型）表示要写入的文件；或者文件的音频数据格式信息。 在播放音频队列的情况下，回调函数会在这个结构体中用一个字段保持对当前包的索引。

• inAQ：调用这个回调函数的音频队列。

• inBuffer：一个音频队列缓冲区，由音频队列提供，回调将填充从正在播放的文件中读取的下一组数据。

如果程序在播放VBR数据，回调函数需要得到正在播放的音频数据的包数据，它通过调用AudioFileReadPackets函数来实现，这个函数声明于AudioFile.h头文件，回调函数随后把包信息放到自定义的数据结构中，以供音频队列使用。

关于播放回调的更多信息，参阅Playing Audio和Audio Queue Services Reference。

使用编码和音频数据格式

音频队列服务根据采用的编解码器在音频格式之间进行转换。录制或播放程序可以使用任意已经安装过相应编码器的格式，不需要写自定义的代码来处理各种音频格式。尤其是你的回调函数不需要知道其数据格式。

每个音频队列在AudioStreamBasicDescription结构体中都有一个字段表示音频数据格式。当你在mFormatID字段中指定格式时，音频队列会使用相应的解码器。然后指定采样率和声道数，这些就是所有你需要做的。设置音频数据格式的示例，参阅Recording Audio和Playing Audio。

用于录制的音频队列按照图1-5中的流程使用已安装的编码器。

图1-5 在录制音频的时候进行音频格式转换

1. 程序告诉音频队列开始录制，同时也告诉它所要使用的音频格式。
2. 音频队列获取新的音频数据，并且根据你指定的格式使用相应的编码器转换音频数据。然后音频队列调用回调函数，将适当的格式化过的音频数据放进缓冲区中。
3. 回调函数将格式化后的音频数据写入磁盘。回调函数不需要知道数据格式。

用于播放的音频队列按照图1-6的流程使用已安装的编码器。

图1-6 在播放过程中进行音频格式转换

1. 程序告诉音频队列开始播放，同时也告诉了它将要播放放的音频文件的数据格式。
2. 音频队列调用回调函数来从音频文件中读取音频数据。回调函数按照它的原始格式将音频数据交付给音频队列。
3. 音频队列使用对应的解码器将音频交付给目标输出设备。

音频队列可以使用任意已安装的编码器，无论是Mac OS X原生的还是第三方的。你可以通过指定音频队列的AudioStreamBasicDescription结构体中四字节编码ID来指定将要使用的编码器。该字段的使用示例，参阅Recording Audio。

Mac OS X包含大量的编码器，在CoreAudioTypes.h头文件中的format IDs枚举值中列出，并且记录在_Core Audio Data Types Reference_中。你可以使用Audio Toolbox框架中AudioFormat.h头文件中的接口来查询当前系统可用的编码器。你可以使用Fiendishthngs程序来显示系统的编码器，该示例代码可以从http://developer.apple.com/samplecode/Fiendishthngs/获得。

音频队列控制和状态

音频队列的生命周期从创建到废弃。程序管理器生命周期，且控制音频队列的状态，通过使用AudioQueue.h头文件中的六个函数：

• Start（AudioQueueStart）：初始化录制或者播放。
• Prime （AudioQueuePrime）：对于播放, 在调用AudioQueueStart之前调用这个函数，以确保有数据可立即用于音频队列的播放。这个函数不在录制中使用。
• Stop（AudioQueueStop）：调用这个函数来重置音频队列 （参考下面对AudioQueueReset的描述），然后停止录制或播放。当没有更多的数据要播放时，播放音频队列回调调用该函数。
• Pause（AudioQueuePause）：调用这个函数可以在不影响缓冲区和不重置音频队列的情况下停止录制或播放。如果需要恢复，调用AudioQueueStart函数。
• Flush （AudioQueueFlush）：在对最后一个音频队列缓冲区进行排队后调用，以确保所有缓冲的数据以及所有正在处理的音频数据被记录或播放。
• Reset （AudioQueueReset）：调用这个函数可以立即让音频队列静音。移除之前调度过的缓冲区，并且重置所有解码器和DSP状态。

你可以在同步或异步模式下使用AudioQueueStop函数：

• 同步：立刻停止，不考虑之前缓冲的音频数据。
• 异步：在所有已入队的缓冲区播放或录制完毕之后再停止。

所有这些函数的完整描述和同步异步停止音频队列的更多信息，参阅_Audio Queue Services Reference_。

音频队列参数

音频队列通过参数（parameters）调整配置。每个参数都使用枚举值作为键，浮点数作为值。参数一般于播放，不用于录制。

在Mac OS X v10.5中，只有播放增益参数。可以通过使用kAudioQueueParam_Volume常量来获取或设置它的值，它的有效范围在0.0（静音）到1.0（单位增益）。

程序可以通过以下两种方法来设置音频队列参数：

• 对于每一个音频队列，使用AudioQueueSetParameter函数，这可以让你直接改变音频队列的设置，这个改变是立刻生效的。
• 对于每一个音频队列缓冲区，调用AudioQueueEnqueueBufferWithParameters函数。这可以让你在将音频队列缓冲区入队的时候设置音频队列设置。这种修改只会在播放音频队列缓冲区的时候生效。

这两种情况下，音频队列的参数设置会一直保留到你改变它们为止。

可以通过调用AudioQueueGetParameter函数来获取音频队列当前的参数。该函数的完整描述和获取和设置参数值的方法，参阅_Audio Queue Services Reference_。

总结

• 音频队列工作：
  • 连接音频硬件
  • 内存管理
  • 根据需要为已压缩的音频格式引入编码器
  • 媒体的录制或播放
• 使用音频队列的基本组成：
  • 一组音频队列缓冲区，每个缓冲区临时存储音频数据。
  • 缓冲区队列。
  • 音频队列回调函数。
• 音频队列按用途分类：
  • 录制
    • 输入端：音频输入硬件。
    • 输出/回调：音频数据
  • 播放
    • 输入/回调：获取音频数据并交付给音频队列。且当没有更多音频数据要播放时停止音频队列。
    • 输出：音频输出设备。
• 音频队列缓冲区数量一般设置为3，对应录制：一个用于写入磁盘，一个填充新音频数据，一个在需要磁盘I/O延迟补偿时使用。
• 音频队列管理了音频队列缓冲区的生命周期/内存：AudioQueueAllocateBuffer创建，AudioQueueDispose释放音频队列时也一起释放其缓冲区。
• 播放过程通过AudioQueueEnqueueBufferWithParameters来实现播放控制：
  • 设置缓冲区的精确播放时间，这可以实现音频同步。
  • 截断音频队列缓冲区开头或结尾的帧，这可以让你去除开头或结尾的静音。
  • 在缓冲区的粒度上设置播放增益。
• 音频队列服务的编码大部分都在其回调函数上。录制使用AudioQueueInputCallback函数原型，播放使用AudioQueueOutputCallback函数原型。
• 回调函数调用的间隔取决于缓冲区的容量。
• 音频队列回调的任务是返回队列缓冲区。使用AudioQueueEnqueueBuffer入队缓冲区。
• 音频队列在录制和播放过程中都可以进行格式转换。回调函数不需要知道音频格式，因为音频编码器都是提前给音频队列配置的。
• 音频队列的状态控制：
  • Start（AudioQueueStart）：初始化录制或者播放。
  • Prime （AudioQueuePrime）：仅用于播放, 在调用AudioQueueStart之前调用这个函数，以确保有数据可立即用于音频队列的播放。
  • Stop（AudioQueueStop）：调用这个函数来重置音频队列 （参考下面对AudioQueueReset的描述），然后停止录制或播放。当没有更多的数据要播放时，回调中调用该函数。
  • Pause（AudioQueuePause）：调用这个函数可以在不影响缓冲区和不重置音频队列的情况下停止录制或播放。如果需要恢复，调用AudioQueueStart函数。
  • Flush （AudioQueueFlush）：在对最后一个音频队列缓冲区进行排队后调用，以确保所有缓冲的数据以及所有正在处理的音频数据被记录或播放。
  • Reset （AudioQueueReset）：调用这个函数可以立即让音频队列静音。移除之前调度过的缓冲区，并且重置所有解码器和DSP状态。

注意：本章介绍了基于ANSI-C的播放实现，并使用了Mac OS X Core Audio SDK的C++类。有关Objective-C的示例，参阅iOS Dev Center中的_SpeakHere_示例代码。

要把播放功能添加到程序中，通常需要执行以下步骤：

1. 定义一个自定义结构体来管理状态、格式和路径信息。
2. 编写音频队列回调函数来执行实际的播放。
3. 编写代码以确定音频队列缓冲区的合适大小。
4. 打开音频文件进行播放，然后确定其音频数据格式。
5. 创建一个播放音频队列并进行相关配置。
6. 分配和排队音频队列缓冲区。告诉音频队列开始播放。完成后，播放回调函数告诉音频队列停止。
7. 处理音频队列，释放资源。

本章的剩余部分详细介绍了每个步骤。

定义结构体管理状态

首先，定义一个结构体，将用它来管理音频格式和音频队列状态信息，如清单3-1所示：

清单3-1 播放音频队列的自定义结构体

static const int kNumberBuffers = 3;                              // 1
struct AQPlayerState {
    AudioStreamBasicDescription   mDataFormat;                    // 2
    AudioQueueRef                 mQueue;                         // 3
    AudioQueueBufferRef           mBuffers[kNumberBuffers];       // 4
    AudioFileID                   mAudioFile;                     // 5
    UInt32                        bufferByteSize;                 // 6
    SInt64                        mCurrentPacket;                 // 7
    UInt32                        mNumPacketsToRead;              // 8
    AudioStreamPacketDescription  *mPacketDescs;                  // 9
    bool                          mIsRunning;                     // 10
};

结构体中大多数字段与用于录制的自定义结构体几乎相同，如Define a Custom Structure to Manage State所述。例如，mDataFormat字段保存正在播放的文件格式。录制时，类似的字段保存了写入磁盘的文件格式。

以下是该结构体各字段介绍：

1. 设置要使用的音频队列缓冲区数量。如Audio Queue Buffers所述，3个通常是不错的选择。
2. AudioStreamBasicDescription结构体（来自CoreAudioTypes.h）表示正在播放的文件的音频数据格式。该格式由mQueue字段指定的音频队列使用。 mDataFormat字段通过查询音频文件的kAudioFilePropertyDataFormat属性来填充该字段，如Obtaining a File’s Audio Data Format所述。 有关AudioStreamBasicDescription结构体的详细信息，参阅_Core Audio Data Types Reference_。
3. 程序创建的播放音频队列。
4. 一个数组，包含指向音频队列管理的音频队列缓冲区的指针。
5. 代表程序播放的音频文件的对象。
6. 每个音频队列缓冲区的大小（以字节为单位）。该值在音频队列创建之后和开始之前，由DeriveBufferSize函数计算。参阅Write a Function to Derive Playback Audio Queue Buffer Size。
7. 音频文件中下一个要播放的数据包索引。
8. 每次调用音频队列的播放回调函数时，要读取的数据包数量。就像bufferByteSize字段一样，在音频队列创建之后和开始之前，由DeriveBufferSize函数计算该值。
9. 对于VBR音频数据，该字段是正在播放的文件的数据包描述数组。对于CBR数据，该字段为NULL。
10. 一个布尔值，表示音频队列是否正在运行。

编写播放音频队列回调函数

下面，编写一个播放音频队列回调函数。该回调函数执行三项主要任务：

• 从音频文件中读取指定数量的数据，并将其放入音频队列缓冲区中。
• 把音频队列缓冲区排队到缓冲区队列中。
• 当没有更多数据要从音频文件中读取时，告诉音频队列停止。

本节展示来一个回调声明示例，分别描述各个任务，最后给出完整的播放回调函数。有关播放回调函数的作用，参阅图1-4。

播放音频队列回调声明

清单3-2展示了一个播放音频回调函数的示例声明，AudioQueueOutputCallback在AudioQueue.h声明为：

清单3-2 播放音频队列回调声明

static void HandleOutputBuffer (
    void                 *aqData,                 // 1
    AudioQueueRef        inAQ,                    // 2
    AudioQueueBufferRef  inBuffer                 // 3
)

下面是该代码的工作方式：

1. 通常，aqData是包含定义音频队列状态信息的自定义结构体。如Define a Custom Structure to Manage State所述。
2. 持有该回调函数的音频队列。
3. 音频队列缓冲区，回调函数通过从音频文件中读取，来填充数据。

从文件读取到音频队列缓冲区

播放音频队列回调函数的第一个操作是从音频文件中读取数据并将其放在音频队列缓冲区中，如清单3-3所示。

清单3-3 从音频文件读取到音频队列缓冲区

AudioFileReadPackets (                        // 1
    pAqData->mAudioFile,                      // 2
    false,                                    // 3
    &numBytesReadFromFile,                    // 4
    pAqData->mPacketDescs,                    // 5
    pAqData->mCurrentPacket,                  // 6
    &numPackets,                              // 7
    inBuffer->mAudioData                      // 8
);

下面是该代码的工作方式：

1. AudioFileReadPackets函数（在AudioFile.h中声明），从音频文件读取数据并将其放入缓冲区中。
2. 要读取的音频文件。
3. 用false表示该函数在读取时不应缓存数据。
4. 输出时，是从音频文件读取的音频数据字节数。
5. 输出时，是从音频文件中读取的数据包描述数组。对于CBR数据，该参数输入NULL。
6. 从音频文件中读取第一个数据包的索引。
7. 输入时，是要从音频文件读取的数据包数量。输出时，是实际读取的包数量。
8. 在输出时，填充的音频队列缓冲区包含从音频文件读取的数据。

排队音频队列缓冲区

现在已经从音频文件中读取数据并将其放在音频队列缓冲区中，回调函数让缓冲区入队，如清单3-4所示。进入缓冲区队列后，缓冲区的音频数据可用于音频队列发送到输出设备。

清单3-4 从磁盘中读取后排队音频队列缓冲区

AudioQueueEnqueueBuffer (                      // 1
    pAqData->mQueue,                           // 2
    inBuffer,                                  // 3
    (pAqData->mPacketDescs ? numPackets : 0),  // 4
    pAqData->mPacketDescs                      // 5
);

下面是该代码的工作方式：

1. AudioQueueEnqueueBuffer函数把音频队列缓冲区添加到缓冲区队列。
2. 持有缓冲区队列的音频队列。
3. 要排队的音频队列缓冲区。
4. 音频队列缓冲区数据中的数据包数量。对于不使用数据包描述的CBR数据，设为0。
5. 对于使用数据描述的压缩音频数据格式，数据包描述在缓冲区中。

停止音频队列

回调函数最后一个操作是检查是否有更多的数据，要从正在播放的音频文件中读取。在发现文件结尾后，回调函数告诉音频队列停止，如清单3-5所示。

清单3-5  Stopping an audio queue

if (numPackets == 0) {                          // 1
    AudioQueueStop (                            // 2
        pAqData->mQueue,                        // 3
        false                                   // 4
    );
    pAqData->mIsRunning = false;                // 5
}

下面是该代码的工作方式：

1. 检查AudioFileReadPackets函数（由之前的回调函数调用）读取的数据包数量是否为0。
2. AudioQueueStop函数停止音频队列。
3. 要停止的音频队列。
4. 播放所有排队的缓冲区后，异步停止音频队列。参阅Audio Queue Control and State。
5. 设置结构体标志，表示播放已完成。

完整播放音频队列回调函数

清单3-6展示了完整播放音频队列回调的基本代码。和本文档的其他示例代码一样，该清单代码不包含错误处理。

清单3-6 一个播放音频队列回调函数

static void HandleOutputBuffer (
    void                *aqData,
    AudioQueueRef       inAQ,
    AudioQueueBufferRef inBuffer
) {
    AQPlayerState *pAqData = (AQPlayerState *) aqData;        // 1
    if (pAqData->mIsRunning == 0) return;                     // 2
    UInt32 numBytesReadFromFile;                              // 3
    UInt32 numPackets = pAqData->mNumPacketsToRead;           // 4
    AudioFileReadPackets (
        pAqData->mAudioFile,
        false,
        &numBytesReadFromFile,
        pAqData->mPacketDescs, 
        pAqData->mCurrentPacket,
        &numPackets,
        inBuffer->mAudioData 
    );
    if (numPackets > 0) {                                     // 5
        inBuffer->mAudioDataByteSize = numBytesReadFromFile;  // 6
       AudioQueueEnqueueBuffer ( 
            pAqData->mQueue,
            inBuffer,
            (pAqData->mPacketDescs ? numPackets : 0),
            pAqData->mPacketDescs
        );
        pAqData->mCurrentPacket += numPackets;                // 7 
    } else {
        AudioQueueStop (
            pAqData->mQueue,
            false
        );
        pAqData->mIsRunning = false; 
    }
}

下面是该代码的工作方式：

1. 实例化后提供给音频队列的自定义结构体，包含要播放的音频文件对象（类型为AudioFileID），以及各种状态数据。参阅Define a Custom Structure to Manage State。
2. 如果音频队列已停止，则立即返回。
3. 一个变量，用于保存从正在播放的文件中读取的音频数据字节数。
4. 使用要从正播放的文件中读取的数据包来初始化numPackets变量。
5. 测试是否从文件中检索了一些音频数据。如果是，则让新填充的缓冲区入队；否则停止音频队列。
6. 告诉音频队列缓冲区结构体已读取数据的字节数。
7. 根据读取的数据包数量增加数据包索引。

编写函数计算播放音频队列缓冲区大小

音频队列服务希望你的程序为使用的音频队列缓冲区指定大小，如清单3-7所示。它得出的缓冲区大小足以容纳给定的音频时长。

创建播放音频队列后，你将在程序中调用DeriveBufferSize函数，作为后续音频队列分配缓冲区的先决条件。参阅Write a Function to Derive Recording Audio Queue Buffer Size。为了播放，还需要：

• 在每次回调函数调用AudioFileReadPackets函数，得出要读取的数据包数量。
• 设置缓冲区大小的下限，以避免过多的磁盘访问。

这里的计算考虑了从磁盘读取的音频数据格式。该格式包括了可能影响缓冲区大小的所有因素，例如音频通道数量。

清单3-7 得出播放音频队列缓冲区大小

void DeriveBufferSize (
    AudioStreamBasicDescription &ASBDesc,                            // 1
    UInt32                      maxPacketSize,                       // 2
    Float64                     seconds,                             // 3
    UInt32                      *outBufferSize,                      // 4
    UInt32                      *outNumPacketsToRead                 // 5
) {
    static const int maxBufferSize = 0x50000;                        // 6
    static const int minBufferSize = 0x4000;                         // 7
 
    if (ASBDesc.mFramesPerPacket != 0) {                             // 8
        Float64 numPacketsForTime =
            ASBDesc.mSampleRate / ASBDesc.mFramesPerPacket * seconds;
        *outBufferSize = numPacketsForTime * maxPacketSize;
    } else {                                                         // 9
        *outBufferSize =
            maxBufferSize > maxPacketSize ?
                maxBufferSize : maxPacketSize;
    }
 
    if (                                                             // 10
        *outBufferSize > maxBufferSize &&
        *outBufferSize > maxPacketSize
    )
        *outBufferSize = maxBufferSize;
    else {                                                           // 11
        if (*outBufferSize < minBufferSize)
            *outBufferSize = minBufferSize;
    }
 
    *outNumPacketsToRead = *outBufferSize / maxPacketSize;           // 12
}

下面是该代码的工作方式：

1. 音频队列的AudioStreamBasicDescription结构体。
2. 正在播放的音频文件中最大数据包的预估大小。你可以通过kAudioFilePropertyPacketSizeUpperBound属性ID，使用AudioFileGetProperty函数（在AudioFile.h中声明）得出该值。参阅Set Sizes for a Playback Audio Queue。
3. 为每个音频缓冲区指定大小（以秒为单位）。
4. 在输出时，是每个音频队列缓冲区的大小（以字节为单位）。
5. 在输出时，是在每次播放音频队列回调时，从文件读取的音频数据包的数量。
6. 音频队列缓冲区大小的上限（以字节为单位）。在该示例中，上限设为320 KB。这相等于以96 kHz采样率，大约持续5秒的24位立体声音频。
7. 音频队列缓冲区大小的下限（以字节为单位）。在该示例中，下限设为16 KB。
8. 对于定义每个数据包固定帧数的音频数据格式，需要得出音频队列缓冲区大小。
9. 对于没定义每个数据包固定帧数的音频格式，需要根据最大数据包大小和设置的上限得出合理的音频队列缓冲区大小。
10. 如果得出的缓冲区大小大于设置的上限，则考虑预估的最大数据包大小，并将其调整为边界值。
11. 如果得出的缓冲区大小低于设置的下限，则将其调整为下限。
12. 计算每次调用回调时从音频文件读取的数据包数量。

打开音频文件进行播放

现在，使用以下步骤打开音频文件进行播放：

1. 获取一个表示要播放的音频文件的CFURL对象。
2. 打开文件。
3. 获取文件的音频数据格式。

获取音频文件的CFURL对象

清单3-8展示了如何为要播放的音频文件获取CFURL对象。在下一步中使用CFURL对象，打开文件。

清单3-8 获取音频文件的CFURL对象

CFURLRef audioFileURL =
    CFURLCreateFromFileSystemRepresentation (           // 1
        NULL,                                           // 2
        (const UInt8 *) filePath,                       // 3
        strlen (filePath),                              // 4
        false                                           // 5
    );

下面是该代码的工作方式：

1. CFURLCreateFromFileSystemRepresentation函数（在CFURL.h中声明），创建一个CFURL对象，该对象表示要播放的文件。
2. 用NULL或kCFAllocatorDefault，表示使用当前默认的内存分配器。
3. 想要转换为CFURL的文件系统路径。在生产代码中，通常会从用户获取filePath值。
4. 文件系统路径中的字节数。
5. false值表示filePath代表文件，而不是目录。

打开音频文件

清单3-9展示了如何打开音频文件进行播放。

清单3-9 打开音频文件进行播放

AQPlayerState aqData;                                   // 1
 
OSStatus result =
    AudioFileOpenURL (                                  // 2
        audioFileURL,                                   // 3
        fsRdPerm,                                       // 4
        0,                                              // 5
        &aqData.mAudioFile                              // 6
    );
 
CFRelease (audioFileURL);                               // 7

下面是该代码的工作方式：

1. 创建AQPlayerState自定义结构体实例（参阅Define a Custom Structure to Manage State）。打开音频文件进行播放时，可以使用该实例存放音频文件对象（类型为AudioFileID）。
2. AudioFileOpenURL函数（在AudioFile.h中声明），打开要播放的文件。
3. 要播放文件的引用。
4. 与正在播放文件一起使用的文件权限。可用权限在文件管理器的File Access Permission Constants枚举中定义。在该示例中，请求读取文件的权限。
5. 可选文件类型hint。这里的0表示该示例未使用该功能。
6. 在输出时，对音频文件的引用将放在自定义结构体的mAudioFile字段。
7. 释放在第一步创建的CFURL对象。

获取文件的音频数据格式

清单3-10展示了如何获取文件的音频数据格式。

清单3-10 获取文件的音频数据格式

UInt32 dataFormatSize = sizeof (aqData.mDataFormat);    // 1
 
AudioFileGetProperty (                                  // 2
    aqData.mAudioFile,                                  // 3
    kAudioFilePropertyDataFormat,                       // 4
    &dataFormatSize,                                    // 5
    &aqData.mDataFormat                                 // 6
);

下面是该代码的工作方式：

1. 获取在查询音频文件有关音频数据格式时要使用的预期属性值大小。
2. AudioFileGetProperty函数（在AudioFile.h中声明），获取音频文件中指定属性的值。
3. 音频文件对象（类型为AudioFileID），表示要获取其音频数据格式的文件。
4. 用户获取音频文件的数据格式的属性ID。
5. 输入时，是描述音频文件的数据格式的AudioStreamBasicDescription结构体的预期大小。输出时，是其实际大小。播放程序不需要使用该值。
6. 在输出时，从音频文件获得AudioStreamBasicDescription结构体的完整音频数据格式。该行通过把文件的音频数据格式存储在音频队列的自定义结构体中，将其应用于音频队列。

创建播放音频队列

清单3-11展示了如何创建播放音频队列。注意，AudioQueueNewOutput函数使用了在之前步骤中配置的自定义结构体和回调函数，以及要播放文件的音频数据格式。

清单3-11 创建播放音频队列

AudioQueueNewOutput (                                // 1
    &aqData.mDataFormat,                             // 2
    HandleOutputBuffer,                              // 3
    &aqData,                                         // 4
    CFRunLoopGetCurrent (),                          // 5
    kCFRunLoopCommonModes,                           // 6
    0,                                               // 7
    &aqData.mQueue                                   // 8
);

下面是该代码的工作方式：

1. AudioQueueNewOutput函数创建一个新的播放音频队列。
2. 设置要播放音频队列的音频数据格式。参阅Obtaining a File’s Audio Data Format。
3. 和播放音频队列一起使用的回调函数。参阅Write a Playback Audio Queue Callback。
4. 播放音频队列的自定义数据结构体。参阅Define a Custom Structure to Manage State。
5. 当前的run loop，将在其调用音频队列回调函数。
6. run loop模式。通常设为kCFRunLoopCommonModes。
7. 保留参数，必需为0。
8. 在输出时，新分配的播放音频队列。

设置播放音频队列大小

接下来，设置播放音频队列的一些大小值。在为音频队列分配缓冲区时，以及开始读取音频文件之前，请使用这些大小值。

本节中的代码清单展示了如何设置：

• 音频队列缓冲区大小。
• 每次调用播放音频队列回调函数时要读取的数据包数量。
• 数组大小，用于保存一个缓冲区的音频数据的数据包描述。

设置缓冲区大小和要读取的数据包数量

清单3-12展示了如何使用之前编写的DeriveBufferSize函数（参阅Write a Function to Derive Playback Audio Queue Buffer Size）。这里的目的是为每个音频队列缓冲区设置一个大小（以字节为单位），并确定每次调用播放音频队列回调函数时要读取的包数量。

该代码使用最大数据包大小的保守预估值，Core Audio通过kAudioFilePropertyPacketSizeUpperBound属性提供了该预估值。在大多数情况下，比起花时间读取整个音频文件以获得实际的最大数据包大小，使用这种近似（但快速）的技术更好。

清单3-12 设置播放音频队列缓冲区的大小和要读取的数据包数量

UInt32 maxPacketSize;
UInt32 propertySize = sizeof (maxPacketSize);
AudioFileGetProperty (                               // 1
    aqData.mAudioFile,                               // 2
    kAudioFilePropertyPacketSizeUpperBound,          // 3
    &propertySize,                                   // 4
    &maxPacketSize                                   // 5
);
 
DeriveBufferSize (                                   // 6
    aqData.mDataFormat,                              // 7
    maxPacketSize,                                   // 8
    0.5,                                             // 9
    &aqData.bufferByteSize,                          // 10
    &aqData.mNumPacketsToRead                        // 11
);

下面是该代码的工作方式：

1. AudioFileGetProperty函数（在AudioFile.h中声明），获取音频文件的指定属性的值。这里，可以用它来获取要播放文件中音频数据包大小的保守上限值（以字节为单位）。
2. 要播放的音频文件对象（类型为AudioFileID）。参阅Opening an Audio File。
3. 用于获取音频文件中数据包大小的保守上限的属性ID。
4. 输出时，kAudioFilePropertyPacketSizeUpperBound属性的大小（以字节为单位）。
5. 输出时，要播放的文件的数据包大小的保守上限（以字节为单位）。
6. DeriveBufferSize函数（在Write a Function to Derive Playback Audio Queue Buffer Size中描述），设置来缓冲区大小和每次调用回调函数时要读取的数据包数量。
7. 要播放的文件的音频数据格式。参阅Obtaining a File’s Audio Data Format。
8. 来自第5行的音频文件最大数据包大小的预估值。
9. 每次音频队列缓冲区应保留的音频时长（以秒为单位）。此处设置半秒是个不错的选择。
10. 在输出时，每个音频队列缓冲区大小（以字节为单位）。该值放在音频队列的自定义结构体中。
11. 在输出时，是在每次播放音频队列回调时要读取的数据包数量。该值也放在音频队列的自定义结构体中。

给数据包描述数组分配内存

现在，给数组分配内存，以保存一个缓冲区的音频数据的数据包描述。CBR数据不使用数据包描述，因此CBR的情况（清单3-13中的步骤3）非常简单。

清单3-13 给数据包描述数组分配内存

bool isFormatVBR = (                                       // 1
    aqData.mDataFormat.mBytesPerPacket == 0 ||
    aqData.mDataFormat.mFramesPerPacket == 0
);
 
if (isFormatVBR) {                                         // 2
    aqData.mPacketDescs =
      (AudioStreamPacketDescription*) malloc (
        aqData.mNumPacketsToRead * sizeof (AudioStreamPacketDescription)
      );
} else {                                                   // 3
    aqData.mPacketDescs = NULL;
}

下面是该代码的工作方式：

1. 确定音频文件的数据格式是VBR还是CBR。在VBR数据中，bytes-per-packet或frames-per-packet值的一个或两个是可变的，因此列出在音频队列的AudioStreamBasicDescription结构体中这两个值为0的情况。
2. 对于包含VBR数据的音频文件，则为数据包描述数组分配内存。根据每次播放回调调用时要读取的音频数据包数量，计算所需内存。参阅Setting Buffer Size and Number of Packets to Read。
3. 对于包含CBR数据的音频文件（例如线性PCM），音频队列不使用数据包描述数组。

给播放音频队列设置Magic Cookie

某些压缩音频格式（例如MPEG 4 AAC）利用结构体来包含音频元数据。这些结构体称为magic cookies。使用音频队列服务以这种格式播放文件时，需要从音频文件中获取magic cookie，然后在开始播放之前应用到音频队列中。

清单3-14展示了如何从文件中获取magic cookie并将其应用到音频队列。你需要在开始播放之前调用该函数。

清单3-14 为播放音频队列设置magic cookie

UInt32 cookieSize = sizeof (UInt32);                   // 1
bool couldNotGetProperty =                             // 2
    AudioFileGetPropertyInfo (                         // 3
        aqData.mAudioFile,                             // 4
        kAudioFilePropertyMagicCookieData,             // 5
        &cookieSize,                                   // 6
        NULL                                           // 7
    );
 
if (!couldNotGetProperty && cookieSize) {              // 8
    char* magicCookie =
        (char *) malloc (cookieSize);
 
    AudioFileGetProperty (                             // 9
        aqData.mAudioFile,                             // 10
        kAudioFilePropertyMagicCookieData,             // 11
        &cookieSize,                                   // 12
        magicCookie                                    // 13
    );
 
    AudioQueueSetProperty (                            // 14
        aqData.mQueue,                                 // 15
        kAudioQueueProperty_MagicCookie,               // 16
        magicCookie,                                   // 17
        cookieSize                                     // 18
    );
 
    free (magicCookie);                                // 19
}

下面是该代码的工作方式：

1. 设置magic cookie数据的预估大小。
2. 接收AudioFileGetPropertyInfo函数的结果。如果成功，该函数返回NoErr，等同于布尔值false。
3. AudioFileGetPropertyInfo函数（在AudioFile.h中声明），获取指定属性值的大小。可以用它来设置保存属性值的变量大小。
4. 音频文件对象（类型为AudioFileID），表示要播放的音频文件。
5. 表示音频文件的magic cookie数据的属性ID。
6. 输入时，magic cookie数据的预估大小。输出时，是其实际大小。
7. 用NULL表示不关心该属性的读/写访问权限。
8. 如果音频文件确实包含magic cookie，则分配内存保存它。
9. AudioFileGetProperty函数（在AudioFile.h中声明），获取指定属性的值。在这里，它将获取音频文件的magic cookie。
10. 音频文件对象（类型为AudioFileID），表示要播放的以及要获取magic cookie的音频文件。
11. 音频文件的magic cookie数据的属性ID。
12. 输入时，magicCookie使用AudioFileGetPropertyInfo函数获得变量的大小。输出时，将是magic cookie的实际大小（以写入magicCookie变量的字节数为单位）。
13. 输出时，音频文件的magic cookie。
14. AudioQueueSetProperty函数给音频队列设置属性。在这里，它将给音频队列设置magic cookie，使其于要播放的音频文件中的magic cookie相匹配。
15. 要为其设置magic cookie的音频队列。
16. 音频队列的magic cookie的属性ID。
17. 要播放文件中的magic cookie。
18. magic cookie的大小（以字节为单位）。
19. 释放分配给magic cookie的内存。

分配和准备音频队列缓冲区

现在，请求之前创建的（参阅Create a Playback Audio Queue）音频队列来准备一组音频队列缓冲区，如清单3-15所示。

清单3-15 分配和准备音频队列缓冲区进行播放

aqData.mCurrentPacket = 0;                                // 1
 
for (int i = 0; i < kNumberBuffers; ++i) {                // 2
    AudioQueueAllocateBuffer (                            // 3
        aqData.mQueue,                                    // 4
        aqData.bufferByteSize,                            // 5
        &aqData.mBuffers[i]                               // 6
    );
 
    HandleOutputBuffer (                                  // 7
        &aqData,                                          // 8
        aqData.mQueue,                                    // 9
        aqData.mBuffers[i]                                // 10
    );
}

下面是该代码的工作方式：

1. 数据包索引设为0，以便当前音频队列回调函数填充缓冲区（步骤7）时，是从音频文件的开头开始。
2. 分配和准备一组音频队列缓冲区（kNumberBuffers设置为3，参阅Define a Custom Structure to Manage State）。
3. AudioQueueAllocateBuffer函数通过为其分配内存来创建音频队列缓冲区。
4. 分配缓冲区的音频队列。
5. 新音频队列缓冲区大小（以字节为单位）。
6. 输出时，把新的音频队列缓冲区添加到自定义结构体的mBuffers数组中。
7. HandleOutputBuffer是播放音频队列的回调函数。参阅Write a Playback Audio Queue Callback。
8. 音频队列的自定义结构体。
9. 要调用其回调的音频队列。
10. 要传递给音频队列回调的缓冲区。

设置音频队列播放增益

在音频队列开始播放之前，通过音频队列参数机制设置其增益，如清单3-16所示。有关参数机制的更多信息，可参阅Audio Queue Parameters。

清单3-16 设置音频队列的播放增益

Float32 gain = 1.0;                                       // 1
    // Optionally, allow user to override gain setting here
AudioQueueSetParameter (                                  // 2
    aqData.mQueue,                                        // 3
    kAudioQueueParam_Volume,                              // 4
    gain                                                  // 5
);

下面是该代码的工作方式：

1. 在0（静音）和1（单元增益）之间设置增益。
2. AudioQueueSetParameter函数设置音频队列的参数值。
3. 要设置参数的音频队列。
4. 要设置的参数ID。kAudioQueueParam_Volume用于设置音频队列增益。
5. 要应用于音频队列的增益设置。

启动和运行音频队列

前面的代码已经为播放文件做了准备。下面是启动音频队列和维护run loop，如清单3-17所示。

清单3-17 启动和运行音频队列

aqData.mIsRunning = true;                          // 1
 
AudioQueueStart (                                  // 2
    aqData.mQueue,                                 // 3
    NULL                                           // 4
);
 
do {                                               // 5
    CFRunLoopRunInMode (                           // 6
        kCFRunLoopDefaultMode,                     // 7
        0.25,                                      // 8
        false                                      // 9
    );
} while (aqData.mIsRunning);
 
CFRunLoopRunInMode (                               // 10
    kCFRunLoopDefaultMode,
    1,
    false
);

下面是该代码的工作方式：

1. 设置自定义结构体标志，表示音频队列正在运行。
2. AudioQueueStart函数在其自身的线程上启动音频队列。
3. 要开始的音频队列。
4. 用NULL表示因队列应立即开始播放。
5. 定义轮询自定义结构体的mIsRunning字段，以检查音频队列是否已经停止。
6. CFRunLoopRunInMode函数运行包含音频队列线程的run loop。
7. 对run loop使用默认模式。
8. 把run loop的运行时间设置为0.25秒。
9. 用false表示run loop应在指定的时间内继续。
10. 音频队列停止后，再运行一次run loop，以确保当前正在播放的音频队列缓冲区有足够时间完成。

播放后的清理

播放文件后，处理音频队列，关闭音频文件，并释放所有剩余资源，如清单3-18所示。

清单3-18 播放音频文件后清理

AudioQueueDispose (                            // 1
    aqData.mQueue,                             // 2
    true                                       // 3
);
 
AudioFileClose (aqData.mAudioFile);            // 4
 
free (aqData.mPacketDescs);                    // 5

下面是该代码的工作方式：

1. AudioQueueDispose函数处理音频队列及其所有资源，包括缓冲区。
2. 要处理的音频队列。
3. 用true表示同步处理音频队列。
4. 关闭播放的音频文件。AudioFileClose函数在AudioFile.h中声明。
5. 释放用于保存数据包描述的内存。

总结

• 使用AudioQueue实现播放功能，一般步骤：
  1. 定义一个自定义结构体来管理状态、格式和路径信息。
  2. 编写音频队列回调函数来执行实际的播放。
  3. 编写代码以确定音频队列缓冲区的合适大小。
  4. 打开音频文件进行播放，然后确定其音频数据格式。
  5. 创建一个播放音频队列并进行相关配置。
  6. 分配和排队音频队列缓冲区。告诉音频队列开始播放。完成后，播放回调函数告诉音频队列停止。
  7. 处理音频队列，释放资源。

注意：本章介绍了基于ANSI-C的录制的实现，并且使用了MAC OS X中Core Audio SDK中了一些C++类，如果想了解基于Objective-C的例子，请参考iOS Dev Center中的_SpeakHere_例子。

要把录制功能添加到程序中，一般都要进行以下几个步骤：

1. 定义一个自定义的结构体来管理状态、格式以及路径信息等。
2. 编写音频队列回调函数来执行实际的录制工作。
3. （可选）编写代码来为音频队列缓冲区选择一个合适的大小。如果你将要录制的格式使用了magic cookies，你需要编写相应的代码来配合使用。
4. 填充自定义结构体中的各个字段，包括指定音频队列将要录制到的文件的数据流、文件路径。
5. 创建一个用于录制的音频队列并且让音频队列创建一系列的音频队列缓冲区，同时创建一个将要写入的文件。
6. 通知音频队列开始录制。
7. 录制完毕之后，通知音频队列停止录制，然后释放掉它，同时它会释放掉它所拥有的缓冲区。

本章的剩余部分将详细描述上述的每一个步骤。

定义一个管理状态的结构体

使用音频队列服务来开发一个音频录制解决方案的时候，第一步就是定义一个结构体。将使用这个结构体来管理音频格式和音频队列状态信息。清单2-1展示了这个这样的一个结构体。

清单2-1 一个用于录制的音频队列的结构体

static const int kNumberBuffers = 3;                            // 1
struct AQRecorderState {
    AudioStreamBasicDescription  mDataFormat;                   // 2
    AudioQueueRef                mQueue;                        // 3
    AudioQueueBufferRef          mBuffers[kNumberBuffers];      // 4
    AudioFileID                  mAudioFile;                    // 5
    UInt32                       bufferByteSize;                // 6
    SInt64                       mCurrentPacket;                // 7
    bool                         mIsRunning;                    // 8
};

下面是这个结构体中每个字段的说明：

1. 要使用的音频队列缓冲区的数量。
2. 一个AudioStreamBasicDescription结构体（来自CoreAudioTypes.h），表示将要写入磁盘的音频数据的格式，音频队列缓冲区使用这个格式来指定它的mQueue字段。mDataFormat字段是由你的程序初始化的，参阅Set Up an Audio Format for Recording。可以通过查询音频队列的kAudioQueueProperty_StreamDescription属性来更新这个字段的值，参阅Getting the Full Audio Format from an Audio Queue。在Mac OS X v10.5中要使用kAudioConverterCurrentInputStreamDescription。 关于AudioStreamBasicDescription结构体的详细信息，请参阅_Core Audio Data Types Reference_。
3. 由程序创建的音频队列。
4. 一个指向由音频队列所管理的音频队列缓冲区的指针数组。
5. 一个表示程序录制音频时写入的文件的音频文件对象。
6. 每个音频队列缓冲区的字节大小。它的值在随后的例子中的DeriveBufferSize函数中计算出来，它在音频队列创建后，开始录制音频前计算出来，参阅Write a Function to Derive Recording Audio Queue Buffer Size。
7. 从当前音频队列缓冲区写入文件的第一个包（packet）的索引。
8. 一个布尔值，表示音频队列是否在运行中。

编写用于录制的音频队列的回调函数

接下来，编写一个用于录制的回调函数，这个函数主要做两个事情：

• 将新填充进音频队列缓冲区的内容写入你正在录制的文件中。
• 将刚才已经将内容写入文件的音频队列缓冲区入队到缓冲区队列。

下面展示了一个回调函数声明的列子，然后分别描述这两个任务，最后展示一个完整的用于录制的回调函数。关于用于录制的音频队列回调函数所扮演的角色，可以参考图1-3。

用于录制的音频队列回调函数的声明

清单2-2是一个用于录制的音频队列回调函数声明，是在AudioQueue.h中声明的AudioQueueInputCallback：

清单2-2  用于录制的音频队列回调函数声明

static void HandleInputBuffer (
    void                                *aqData,             // 1
    AudioQueueRef                       inAQ,                // 2
    AudioQueueBufferRef                 inBuffer,            // 3
    const AudioTimeStamp                *inStartTime,        // 4
    UInt32                              inNumPackets,        // 5
    const AudioStreamPacketDescription  *inPacketDesc        // 6
)

下面是该代码的工作方式：

1. 一般来说，aqData是一个自定义的数据结构，包含了音频队列的状态信息，参阅Define a Custom Structure to Manage State。
2. 拥有该回调函数的音频队列。
3. 包含录制数据的音频队列缓冲区。
4. 音频队列缓冲区中第一个采样的时间（对于简单的录制是不需要的）。
5. inPacketDesc字段中包描述的数量，如果是0，表明这是个CBR数据。
6. 对于压缩数据格式如果需要包描述，包描述是由编码器产生的。

将音频队列缓冲区中的数据写入磁盘

用于录制的音频队列回调函数要做的第一件事情就是把音频队列缓冲区中的内容写入磁盘。这个缓冲区就是音频队列从输入设备最新输入的音频数据。这个回调函数使用AudioFile.h中声明的AudioFileWritePackets函数。如清单2-3所示。

清单2-3 将音频队列缓冲区数据写入磁盘

AudioFileWritePackets (                     // 1
    pAqData->mAudioFile,                    // 2
    false,                                  // 3
    inBuffer->mAudioDataByteSize,           // 4
    inPacketDesc,                           // 5
    pAqData->mCurrentPacket,                // 6
    &inNumPackets,                          // 7
    inBuffer->mAudioData                    // 8
);

下面是该代码的工作方式：

1. AudioFileWritePackets函数（在AudioFile.h声明），把缓冲区的内容写入音频数据文件中。
2. 音频文件对象（类型为AudioFileID）表示要写到的音频文件。pAqData变量是指向清单2-1描述的数据结构的指针。
3. 使用false值来表达写入是函数不应缓存数据。
4. 正在写入的音频数据的字节数。inBuffer变量音频队列传递给回调函数的音频队列缓冲区。
5. 音频数据包描述数组。NULL值表示不需要数据包描述（例如，CBR音频数据）。
6. 要写入的第一个数据包的索引。
7. 输入时，表示要写入的数据包数量。输出时，表示实际写入的数据包数量。
8. 将新的音频数据写入音频文件。

排队音频队列缓冲区

现在，音频队列缓冲区的音频数据已经被写入音频文件，回调对缓冲区进行排队，如清单2-4所示。一旦回到缓冲区队列中，缓冲区就处于排队状态，准备接受更多传入的音频数据。

清单2-4 写入磁盘后排队音频队列缓冲区

AudioQueueEnqueueBuffer (                    // 1
    pAqData->mQueue,                         // 2
    inBuffer,                                // 3
    0,                                       // 4
    NULL                                     // 5
);

下面是该代码的工作方式：

1. AudioQueueEnqueueBuffer函数把音频队列缓冲区添加到音频队列的缓冲区队列中。
2. 把指定的音频队列缓冲区添加到音频队列。pAqData变量指向清单2-1描述的数据结构指针。
3. 要排队的音频队列缓冲区。
4. 音频队列缓冲区数据中的数据包描述数量。设为0，因为该参数未用于录制。
5. 数据包描述数组，描述音频队列缓冲区的数据。设为NULL，因为该参数未用于录制。

一个完整的音频录制的音频队列回调函数

清单2-5展示了完整的音频录制中音频队列回调函数的基本形式。与本文档的其他代码一样，该清单不包括错误处理。

清单2-5 一个音频录制的音频队列回调函数

static void HandleInputBuffer (
    void                                 *aqData,
    AudioQueueRef                        inAQ,
    AudioQueueBufferRef                  inBuffer,
    const AudioTimeStamp                 *inStartTime,
    UInt32                               inNumPackets,
    const AudioStreamPacketDescription   *inPacketDesc
) {
    AQRecorderState *pAqData = (AQRecorderState *) aqData;               // 1
 
    if (inNumPackets == 0 &&                                             // 2
          pAqData->mDataFormat.mBytesPerPacket != 0)
       inNumPackets =
           inBuffer->mAudioDataByteSize / pAqData->mDataFormat.mBytesPerPacket;
 
    if (AudioFileWritePackets (                                          // 3
            pAqData->mAudioFile,
            false,
            inBuffer->mAudioDataByteSize,
            inPacketDesc,
            pAqData->mCurrentPacket,
            &inNumPackets,
            inBuffer->mAudioData
        ) == noErr) {
            pAqData->mCurrentPacket += inNumPackets;                     // 4
    }
   if (pAqData->mIsRunning == 0)                                         // 5
      return;
 
    AudioQueueEnqueueBuffer (                                            // 6
        pAqData->mQueue,
        inBuffer,
        0,
        NULL
    );
}

下面是该代码的工作方式：

1. 实例化时提供给音频队列对象的结构体，包含代表要记录到其中的音频文件的对象，以及各种状态数据。参阅Define a Custom Structure to Manage State。
2. 如果音频队列缓冲区包含CBR数据，则需要计算缓冲区的数据包数量。该数值等于缓冲区中数据的总字节除以每个数据包固定的字节数。对于VBR数据，音频队列在调用回调时会提供缓冲区中的数据包数量。
3. 把缓冲区的内容写入到音频数据文件中。有关详细的说明，参阅Writing an Audio Queue Buffer to Disk。
4. 如果成功写入音频数据，需要增加音频数据文件的数据包索引，以准备写入下一个缓冲区的音频数据。
5. 如果音频队列已停止，则返回。
6. 入队该写入音频文件的音频队列缓冲区。有关详细的说明，参阅Enqueuing an Audio Queue Buffer。

编写函数计算用于录制的音频队列缓冲区大小

音频队列服务希望程序为使用的音频队列缓冲区指定大小。清单2-6展示了一种执行该操作的方法。它得出的缓冲区大小足以容纳给定的音频时长。

该计算考虑了要录制到的音频数据格式。该格式包含可能影响缓冲区大小的所有因素，例如音频通道的数量。

清单2-6 得出音频录制的音频队列缓冲区的大小

void DeriveBufferSize (
    AudioQueueRef                audioQueue,                  // 1
    AudioStreamBasicDescription  &ASBDescription,             // 2
    Float64                      seconds,                     // 3
    UInt32                       *outBufferSize               // 4
) {
    static const int maxBufferSize = 0x50000;                 // 5
 
    int maxPacketSize = ASBDescription.mBytesPerPacket;       // 6
    if (maxPacketSize == 0) {                                 // 7
        UInt32 maxVBRPacketSize = sizeof(maxPacketSize);
        AudioQueueGetProperty (
                audioQueue,
                kAudioQueueProperty_MaximumOutputPacketSize,
                // in Mac OS X v10.5, instead use
                //   kAudioConverterPropertyMaximumOutputPacketSize
                &maxPacketSize,
                &maxVBRPacketSize
        );
    }
 
    Float64 numBytesForTime =
        ASBDescription.mSampleRate * maxPacketSize * seconds; // 8
    *outBufferSize =
    UInt32 (numBytesForTime < maxBufferSize ?
        numBytesForTime : maxBufferSize);                     // 9
}

下面是该代码的工作方式：

1. 配置缓冲区大小的音频队列。
2. 音频队列的AudioStreamBasicDescription结构体。
3. 为每个音频队列缓冲区指定的大小（以秒为单位）。
4. 在输出时，每个音频队列缓冲区的大小（以字节为单位）。
5. 音频队列缓冲区大小上限（以字节为单位）。在该示例中，上限设为320 KB。这相当于以96 kHz的采样率采集5秒的24位立体声音频。
6. 对于CBR音频数据，则从AudioStreamBasicDescription结构体中获取固定的数据包大小。使用该值作为最大数据包大小。 该赋值会有副作用，这取决于要录制的音频数据时CBR还是VBR。如果是VBR，则音频队列的AudioStreamBasicDescription会把bytes-per-packet设为0。
7. 对于VBR音频数据，查询音频队列以获取最大的数据包估算大小。
8. 得出缓冲区大小（以字节为单位）。
9. 如果需要，把缓冲区大小限制为之前设置的上限。

设置音频文件Magic Cookie

某些压缩的音频格式（例如MPEG 4 AAC），利用结构体包含音频元数据。这些结构体称为magic cookies。使用音频队列服务以这种格式录制时，必须先从音频队列中获取magic cookie，然后再将其添加到音频文件中，然后开始录制。

清单2-7展示了如何从音频队列中获取magic cookie，并将其应用于音频文件中。代码会在录制之前调用该函数，然后在录制后再次调用，因为某些编解码器会在录制停止时更新magic cookie数据。

清单2-7 给音频文件设置magic cookie

OSStatus SetMagicCookieForFile (
    AudioQueueRef inQueue,                                      // 1
    AudioFileID   inFile                                        // 2
) {
    OSStatus result = noErr;                                    // 3
    UInt32 cookieSize;                                          // 4
 
    if (
            AudioQueueGetPropertySize (                         // 5
                inQueue,
                kAudioQueueProperty_MagicCookie,
                &cookieSize
            ) == noErr
    ) {
        char* magicCookie =
            (char *) malloc (cookieSize);                       // 6
        if (
                AudioQueueGetProperty (                         // 7
                    inQueue,
                    kAudioQueueProperty_MagicCookie,
                    magicCookie,
                    &cookieSize
                ) == noErr
        )
            result =    AudioFileSetProperty (                  // 8
                            inFile,
                            kAudioFilePropertyMagicCookieData,
                            cookieSize,
                            magicCookie
                        );
        free (magicCookie);                                     // 9
    }
    return result;                                              // 10
}

下面是该代码的工作方式：

1. 用于录制的音频队列。
2. 录制到的音频文件。
3. 结果变量，表达该函数是成功还是失败。
4. 用于保存magic cookie数据大小的变量。
5. 从音频队列获取magic cookie数据大小，并存储在cookieSize变量中。
6. 分配一个字节数据来保存magic cookie信息。
7. 通过查询音频队列的kAudioQueueProperty_MagicCookie属性获取magic cookie。
8. 设置录制到的音频文件的magic cookie。AudioFileSetProperty函数在AudioFile.h头文件中声明。
9. 释放临时magic cookie变量的内存。
10. 返回该函数的成功或失败状态。

设置音频格式进行录制

本节介绍如何为音频队列设置音频数据格式。音频队列使用该格式记录到文件。

要设置音频数据格式，需要指定：

• 音频数据格式类型（如线性PCM、AAC等）
• 采样率（如44.1 kHz）
• 音频通道数（如2，立体声）
• 位深（如16位）
• 每数据包帧数量（如线性PCM，每包一帧）
• 音频文件类型（如CAF、AIFF等）
• 文件类型所需的音频数据格式的详细信息

清单2-8写死了用来录制的音频格式的每个属性值。在生产代码中，通常允许用户部分或全部指定音频格式。无论采用哪种方式，目标都是填充AQRecorderState自定义结构体的mDataFormat字段，参阅Define a Custom Structure to Manage State中的自定义结构体。

清单2-8 指定音频队列的音频数据格式

AQRecorderState aqData;                                       // 1
 
aqData.mDataFormat.mFormatID         = kAudioFormatLinearPCM; // 2
aqData.mDataFormat.mSampleRate       = 44100.0;               // 3
aqData.mDataFormat.mChannelsPerFrame = 2;                     // 4
aqData.mDataFormat.mBitsPerChannel   = 16;                    // 5
aqData.mDataFormat.mBytesPerPacket   =                        // 6
   aqData.mDataFormat.mBytesPerFrame =
      aqData.mDataFormat.mChannelsPerFrame * sizeof (SInt16);
aqData.mDataFormat.mFramesPerPacket  = 1;                     // 7
 
AudioFileTypeID fileType             = kAudioFileAIFFType;    // 8
aqData.mDataFormat.mFormatFlags =                             // 9
    kLinearPCMFormatFlagIsBigEndian
    | kLinearPCMFormatFlagIsSignedInteger
    | kLinearPCMFormatFlagIsPacked;

下面是该代码的工作方式：

1. 创建AQRecorderState结构体实例。结构体的mDataFormat字段包含一个AudioStreamBasicDescription结构体。在mDataFormat字段中设置的值提供了音频队列的初始音频格式，这也是记录到文件的音频格式。在清单2-10中，你可以获得音频格式的完整规范，Core Audio根据格式类型和文件类型提供了相关规范。
2. 把音频数据格式类型定义为线性PCM。有关可用数据格式的完整列表，可参阅_Core Audio Data Types Reference_。
3. 把采样率设为44.1 kHz。
4. 通道数设为2。
5. 每个通道位深设为16。
6. 每个数据包字节数和每帧字节数设为4（即2个通道乘以每个样本2个字节）。
7. 每个数据包帧数量设为1。
8. 文件类型设为AIFF。参阅AudioFile.h头文件的类型，可获得可用类型的完整列表。可以指定任意已安装的解码器的文件类型，如Using Codecs and Audio Data Formats所述。
9. 设置指定文件类型所需的格式标志。

创建一个录制音频队列

现在，在设置了录制黑白你函数和音频数据格式之后，创建和配置用于录制的音频队列。

创建录制音频队列

清单2-9展示了如何创建录制音频队列。注意，AudioQueueNewInput函数使用在之前步骤中配置的回调函数、自定义结构体和音频数据格式。

清单2-9 创建录制音频队列

AudioQueueNewInput (                              // 1
    &aqData.mDataFormat,                          // 2
    HandleInputBuffer,                            // 3
    &aqData,                                      // 4
    NULL,                                         // 5
    kCFRunLoopCommonModes,                        // 6
    0,                                            // 7
    &aqData.mQueue                                // 8
);

下面是该代码的工作方式：

1. AudioQueueNewInput函数创建一个新的录制音频队列。
2. 录制的音频数据格式。参阅Set Up an Audio Format for Recording。
3. 于录制音频队列一起使用的回调函数。参阅Write a Recording Audio Queue Callback。
4. 录制音频队列的自定义数据结构体。参阅Define a Custom Structure to Manage State。
5. 调用回调函数的run loop。使用NULL指定默认行为，回调函数将在内部的音频队列中的线程执行。这时典型的用法，允许音频队列在程序的用户界面线程等待用户停止录制的同时进行录制。
6. run loop模式。通常使用kCFRunLoopCommonModes。
7. 保留参数，必须为0。
8. 在输出时，新分配的录制音频队列。

从音频队列获取完整的音频格式

当音频队列创建后（参阅Creating a Recording Audio Queue），AudioStreamBasicDescription可能比你填写的更完整，尤其是压缩格式。要获取完整的格式描述，调用清单2-10的AudioQueueGetProperty函数。创建要录制到的音频文件时，需使用完整的音频格式（参阅Create an Audio File）。

清单2-10 从音频队列获取音频格式

UInt32 dataFormatSize = sizeof (aqData.mDataFormat);       // 1
 
AudioQueueGetProperty (                                    // 2
    aqData.mQueue,                                         // 3
    kAudioQueueProperty_StreamDescription,                 // 4
    // in Mac OS X, instead use
    //    kAudioConverterCurrentInputStreamDescription
    &aqData.mDataFormat,                                   // 5
    &dataFormatSize                                        // 6
);

下面是该代码的工作方式：

1. 获取在查询音频队列有关其音频数据格式时要使用的预期属性值大小。
2. AudioQueueGetProperty函数获取音频队列中指定属性的值。
3. 用于获取音频数据格式的音频队列。
4. 用于获取音频队列的数据格式值的属性ID。
5. 在输出时，从音频队列获得的AudioStreamBasicDescription结构体形式的完整音频数据格式。
6. 输入时，是AudioStreamBasicDescription的预期大小。输出时，是其实际大小。在录制程序中不需要使用该值。

创建音频文件

创建并配置音频队列后，将创建一个音频文件，把音频数据记录到音频文件中，如清单2-11所示。音频文件使用之前存储在音频队列的自定义结构体中的数据格式和文件格式规范。

清单2-11 创建一个音频文件进行录制

CFURLRef audioFileURL =
    CFURLCreateFromFileSystemRepresentation (            // 1
        NULL,                                            // 2
        (const UInt8 *) filePath,                        // 3
        strlen (filePath),                               // 4
        false                                            // 5
    );
 
AudioFileCreateWithURL (                                 // 6
    audioFileURL,                                        // 7
    fileType,                                            // 8
    &aqData.mDataFormat,                                 // 9
    kAudioFileFlags_EraseFile,                           // 10
    &aqData.mAudioFile                                   // 11
);

下面是该代码的工作方式：

1. CFURLCreateFromFileSystemRepresentation函数（在CFURL.h头文件中声明），创建一个CFURL对象，该对象表示要录制到其中的文件。
2. 使用NULL或kCFAllocatorDefault，使用当前默认的内存分配器。
3. 想要转换为CFURL的文件系统路径。在生产代码中，通常会从用户获取filePath值。
4. 文件系统路径中的字节数。
5. false值表示filePath代表文件，而不是目录。
6. AudioFileCreateWithURL函数（来自AudioFile.h头文件），创建一个新的音频文件，或初始化一个现有文件。
7. 用于创建新的音频文件或使用现在文件进行初始化的URL。该URL是从第一步CFURLCreateFromFileSystemRepresentation获得的。
8. 新文件的文件类型。在本章的示例代码中，之前已通过kAudioFileAIFFType设置为AIFF类型。参阅Set Up an Audio Format for Recording。
9. 将记录到文件中的音频数据格式，指定为AudioStreamBasicDescription结构体。在本章的示例代码中，也已在“Set Up an Audio Format for Recording”中进行了设置。
10. 如果文件已存在，则删除该文件。
11. 在输出时，音频文件对象（AudioFileID类型）表示要录制到的音频文件。

设置音频队列缓冲区大小

在准备在录制是使用一组音频队列缓冲区之前，调用之前的DeriveBufferSize函数（参阅Write a Function to Derive Recording Audio Queue Buffer Size）。可以把该大小分配给正在使用的录制音频队列，如清单2-12所示：

清单2-12 设置音频队列缓冲区大小

DeriveBufferSize (                               // 1
    aqData.mQueue,                               // 2
    aqData.mDataFormat,                          // 3
    0.5,                                         // 4
    &aqData.bufferByteSize                       // 5
);

下面是该代码的工作方式：

1. DeriveBufferSize函数（定义在Write a Function to Derive Recording Audio Queue Buffer Size），设置合适的音频队列缓冲区大小。
2. 配置缓冲区大小的音频队列。
3. 在录制的文件的音频数据格式。参阅Set Up an Audio Format for Recording。
4. 每个音频队列缓冲区应保留的秒数。此处设置半秒是个不错的选择。
5. 在输出时，每个音频队列缓冲区的大小（以字节为单位）。该值放在音频队列的自定义结构体中。

准备一组音频队列缓冲区

现在，请求音频队列（在Create a Recording Audio Queue创建的）准备一组音频队列缓冲区。清单2-13展示了如何操作。

清单2-13 准备一组音频队列缓冲区

for (int i = 0; i < kNumberBuffers; ++i) {           // 1
    AudioQueueAllocateBuffer (                       // 2
        aqData.mQueue,                               // 3
        aqData.bufferByteSize,                       // 4
        &aqData.mBuffers[i]                          // 5
    );
 
    AudioQueueEnqueueBuffer (                        // 6
        aqData.mQueue,                               // 7
        aqData.mBuffers[i],                          // 8
        0,                                           // 9
        NULL                                         // 10
    );
}

下面是该代码的工作方式：

1. 遍历分配和入队每个音频队列缓冲区。
2. AudioQueueAllocateBuffer函数请求音频队列分配音频队列缓冲区。
3. 执行分配并持有缓冲区的音频队列。
4. 分配的新音频队列缓冲区的大小（以字节为单位）。参阅Write a Function to Derive Recording Audio Queue Buffer Size。
5. 在输出时，是新分配的音频队列缓冲区。指向缓冲区的指针放在和音频队列一起使用的自定义结构体中。
6. AudioQueueEnqueueBuffer函数把音频队列缓冲区添加到缓冲区队列的末尾。
7. 向其添加缓冲区的缓冲区队列的音频队列。
8. 正在入队的音频队列缓冲区。
9. 缓冲区入队时未使用该参数。
10. 缓冲区入队时未使用该参数。

录制音频

有了前面的代码，录制过程显得格外简单，如清单2-14所示。

清单2-14 录制音频

aqData.mCurrentPacket = 0;                           // 1
aqData.mIsRunning = true;                            // 2
 
AudioQueueStart (                                    // 3
    aqData.mQueue,                                   // 4
    NULL                                             // 5
);
// Wait, on user interface thread, until user stops the recording
AudioQueueStop (                                     // 6
    aqData.mQueue,                                   // 7
    true                                             // 8
);
 
aqData.mIsRunning = false;                           // 9

下面是该代码的工作方式：

1. 初始化数据包索引为0，在音频文件的开头开始录制。
2. 在自定义结构体中设置标志，以指示音频队列正在运行。录制音频队列回调函数使用该标志。
3. AudioQueueStart函数在其自己的线程上启动音频队列。
4. 音频队列开始。
5. 使用NULL表示音频队列应立即开始录制。
6. AudioQueueStop函数停止并重置录制音频队列。
7. 音频队列停止。
8. 使用true来同步停止。有关同步和异步的说明，参阅Audio Queue Control and State。
9. 在自定义结构体中设置标志，以表示音频队列还没运行。

录制后清理

完成录制后，需要处理音频队列并关闭音频文件，如清单2-15所示。

清单2-15 录制后清理

AudioQueueDispose (                                 // 1
    aqData.mQueue,                                  // 2
    true                                            // 3
);
 
AudioFileClose (aqData.mAudioFile);                 // 4

下面是该代码的工作方式：

1. AudioQueueDispose函数处理音频队列及其所有资源，包括缓冲区。
2. 要处理的音频队列。
3. 使用true来同步（即立即）处理音频队列。
4. 关闭用于录制的音频文件。AudioFileClose函数在AudioFile.h头文件中声明。

总结

• 使用录制功能一般步骤：
  1. 定义自定义结构体来管理状态、格式以及路径信息等。
  2. 编写回调函数来执行实际的录制数据处理。
  3. 填充自定义结构体中的各个字段，包括录制到的文件的数据流、文件路径。
  4. 创建音频队列、音频队列缓冲区、要写入的文件。
  5. 通知音频队列开始录制。
  6. 录制完毕后，通知音频队列停止录制，然后释放。这同时会释放它所拥有的所有缓冲区。
• 对于使用OC、Swift代码，可以直接把结构体的字段直接分散到类定义中。
• 录制回调函数任务：
  • 把填充进音频队列缓冲区的内容写入到文件。
  • 把写入文件的音频队列缓冲区排队到队列中。这样才可以接受更多数据。
• 回调函数中的const AudioStreamPacketDescription *inPacketDesc包含VBR包描述的数量（mVariableFramesInPacket），如果是0则表示这是CBR数据。该数据来自编码器。
• 每个音频队列缓冲区时长可以设置为0.5秒。

《图解HTTP》里面的内容虽然不深，但覆盖范围较广，用于面试也基本足够。之前整理在幕布的笔记太精简了，现在再读一遍，要补充的东西还是挺多的。

所以说这本书的内容更多的是一个引子、导读，更多的细节还是需要再去翻查资料。

与互联网相关联的协议集合起来总称。

TCP/IP 分层管理

1. 应用层。给用户提供应用服务。如：FTP、DNS、HTTP。
2. 传输层。给应用层提供处理网络连接中的两台计算机之间的数据传输。如：TCP、UDP。
3. 网络层/网络互连层。处理在网络上流动的数据包。在众多的传输路线中做出选择。如：IP。
4. 数据链路层/网络接口层。处理连接网络的硬件部分。

数据包是网络传输的最小数据单位。

TCP/IP 通信传输流

通过分层顺序与对方网络通信。

发送端从应用层往下走：

• 发送数据：应用层 -> 传输层 -> 网络层 -> 链路层
• 每经过一层都打上一层的首部信息，层层封装。

接收端则从链路层往上走，一直到达服务器：

• 接收到数据：链路层 -> 网络层 -> 传输层 -> 应用层
• 每经过一层就将对应的首部消掉，层层解封装。

以HTTP举例：

1. 发送端/客户端在应用层（HTTP协议）发出一个HTTP请求。
2. 为了方便传输，在传输层（TCP协议）把应用层收到的数据（HTTP请求报文）进行分割，并在各个报文上标记序号、端口号，然后转发给网络层。
3. 在网络层（IP协议），增加作为通信目的地的MAC地址后转发给链路层。
4. 接收端/服务器在链路层接收到数据，按序往上发送，一直到应用层，才算真正接收到HTTP请求。

每一层的交互通过打上首部信息和消去首部信息（封装与解封装），发送端/客户端把应用层数据层层封装，到接收端/服务器才层层解封装拿到应用层数据。

IP协议

IP，Internet Protocol，网络层。负责把各种数据传输到对方。其中两个重要条件是IP地址和MAC地址。

IP地址指明被分配到的地址；MAC地址指明网卡所属的固定地址。IP地址依赖MAC地址，通常不在发送端与接收端不在同一个局域网时，往往通过ARP协议进行多台计算机和网络设备中转。

中转时，利用下一站中转设备的MAC地址来搜索下一个中转目标。

ARP的作用时解析地址，根据通信方的IP地址反查出对应的MAC地址。

TCP 协议

TCP协议，传输层，提供可靠的字节流服务。

为确保数据能到达目标，会进行三次握手策略建立连接：

为什么握手要三次，挥手却要四次呢？

那是因为握手的时候并没有数据传输，所以服务端的 SYN 和 ACK 报文可以一起发送，但是挥手的时候有数据在传输，所以 ACK 和 FIN 报文不能同时发送，需要分两步，所以会比握手多一步。

DNS服务

DNS服务，Domain Name System，应用层，提供域名到IP地址之间的解析服务。

若直接通过IP访问则不需要经过DNS服务。

URL 与 URI

• URL（Uniform Resource Location），统一资源定位符。
  • 是 URI 的子集。表达的是一个位置。
• URI（Uniform Resource Identifier），统一资源标识符。

URI格式：

http://user:pass@www.example.com:80/dir/index.html?uid=1#ch1

• http：协议方案名
• user:pass：登录认证信息
• www.example.com：服务器地址
• 80：服务器端口号
• dir/index.html：带层级的文件路径
• uid=1：查询字符串
• ch1：片段标识符

HTTP是无状态协议

HTTP本质是无状态的。为了更快地处理大量事务，确保协议的可伸缩性。HTTP协议对于发送过的请求或响应都不做持久化处理。有新的请求发送时，就会有新的响应产生。

使用Cookies可以创建有状态的会话。把Cookies添加到头部中，创建一个会话让每次请求都能共享相同的上下文信息，达成相同的状态。

实际的数据状态可能存在服务器中，但通过 Cookie 将一个 id 信息传到客户端，并由客户端持久化，客户端通过 id 就可获得数据的状态。

使用方法告知意图

通过HTTP请求方法，简单告知请求的意图。

• GET：获取资源。
• POST：传输实体的主体。通过body传输数据。
• PUT：传输文件。但该方法不存在验证机制，任何人都可以上传文件，存在安全性问题。
• HEAD：获取报文首部。用于确认URI的有效性以及资源更新的日期时间等。
• DELETE：删除文件。与PUT对应，但也没有验证机制，存在安全性问题。
• OPTIONS：查询服务器支持的方法。
• TRACE：追踪路径。容易引发跨站攻击，通常不会用到。
• CONNECT：要求用隧道协议连接代理。要求在与代理服务器通信时建立隧道，实现用隧道协议进行TCP通信。主要是用SSL和TSL协议把通信内容加密后经网络隧道传输。

持久连接节省通信量

大量的 TCP 连接建立和断开，都会加载通信量的开销。为此，推出了持久连接（HTTP Persistent Connections，也称为 HTTP Keep-alive 或 HTTP connection reuse）方法。

只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。

持久化使得多数请求以管线化（pipelining）方式发送成为可能。这样就能够做到同时并行发送多个请求。

组成

报文首部、报文主体（可选）

报文首部组成：

• 请求行
  • 请求方法、URI、HTTP 版本
• 状态行
  • 响应结果的状态码、原因短语、HTTP 版本
• 首部字段
  • 通用首部（General Heaader Fields）
    • 请求报文和响应报文都会使用的首部。
  • 请求首部（Request Header Fields）
    • 发送请求报文使用的首部。补充了请求的附加内容、客户端信息、响应内容相关优先级等信息。
  • 响应首部（Response Header Fields）
    • 返回响应报文时 使用的首部。补充了响应的附加内容，也会要求客户端附加额外的内容信息。
  • 实体首部（Entity Header Fields）
    • 针对请求报文和响应报文的实体部分使用的首部。补充了资源内容更新时间等与实体有关的信息。
• 其他（HTTP 协议未定义的其他内容）

具体的请求报文与响应报文：

请求报文组成：

• 请求方法
• 请求URI
• 协议版本
• 可选请求首部字段
• 内容实体

响应报文组成：

• 协议版本
• 状态码
• 解析状态码的原因短语
• 可选的响应首部字段
• 实体主体

报文主体与实体主体

报文（message）：是 HTTP 通信的基本单位，由 8 个组字节流（octet sequence，其中 octet 为 8 个比特）组成，通过 HTTP 通信传输。

实体（entity）：作为请求或响应的有效载荷数据（补充项）被传输，其内容由实体首部和实体主体组成。

通常报文主体等于实体主体，仅当传输中进行编码操作时，实体主体的内容发生变化。

通过编码提升传输速度

HTTP在传输数据时可以原样直接传输，但也可以在传输过程中通过编码提升传输速度。但编码需要计算机来完成，虽然会提升传输速率，但也会因此需要更多的CPU资源。

压缩传输的内容编码

服务器在实体内容上压缩，客户端接收并解压实体。

常用的内容编码：

• gzip，GUN zip
• compress，UNIX系统的标准压缩
• deflate，zlib
• identity，不进行压缩

分割发送的分块传输编码

把实体内容分块。每一块都会用十六进制来标记块的大小，而实体主体的最后一块会使用“0(CR+LF)”来标记。

多部分对象集合

发送的一份报文主体可含有多类型实体，通常是图片或文本文件等上传时使用。多部份对象集合包含的对象如下：

• multipart/form-data
  • 在 Web 表单文件上传时使用。
• multipaprt/byteranges
  • 状态码 206，响应报文包含了多个范围的内容时使用。

iOS中URLSession的uploadTask默认实现只适合PUT方法上传文件，要是要multipart/form-data上传，还需要自己拼接内容实体。

范围请求

应用：断点下载、上传。

用到首部字段Range来指定资源的字节范围。

内容协商

客户端和服务器端就响应的资源内容进行交涉，然后提供给客户端最合适的资源。内容协商会以语言、字符串、编码方式等为基准判断响应的资源。即使用以下首部字段：

• Accept
• Accept-Charset
• Accept-Encoding
• Accept-Language
• Connet-Language

协商技术分类：

• 服务器驱动协商（Server-driven Negotiation）
  • 以请求的首部字段为参考，在服务端自动处理。
• 客户端驱动协商（Agent-driven Negotiation）
  • 从浏览器显示的可选项列表中手动选择。
• 透明协商（Transparent Negotiation）
  • 上面两者的结合体，由各自进行内容协商的一种方法。

通信数据转发程序

这些应用程序和服务器可以将请求转发给通信线路的下一站服务器，并且能接收从那台服务器发送的响应，再转发给客户端。

代理

有转发功能的应用程序。接收由客户端发送的请求并转发给服务器，同时也接收服务器返回的响应并转发给客户端。

分类基准：

• 缓存代理，CDN
• 透明代理
  • 不对报文进行任何加工的代理，反之称为非透明代理。

网关

转发其他服务器通信数据的服务器，接收从客户端发送来的请求时，它就像自己拥有资源的源服务器一样对请求进行处理。

网关能使通信线路上的服务器提供非 HTTP 协议服务。

隧道

在相隔甚远的客户端和服务器两者进行中转，并保持双方通信连接的应用程序。

不会去解析 HTTP 请求，保持原样中转给之后的服务器。隧道会在通信双方断开连接时结束。

缓存

缓存是指代理服务器或客户端本地磁盘内保存的资源副本。利用缓存可以减少对源服务器的访问，节省了通信流量和通信时间。

缓存分类：

• 服务器缓存，通过缓存代理服务器实现。当代理转发从服务器返回的响应时，本身就会保存一份副本，下次请求就可以从代理服务器响应。
• 客户端缓存。通过临时网络文件缓存响应资源。

若缓存有效则使用缓存，否则请求源服务器，请求新资源。

注意在iOS中，使用URLSession的GET请求，会自动使用URLCache进行缓存响应资源。根据服务器的响应头部字段自动缓存和更新资源。

• 通信使用明文（不加密），内容可能会被窃听。
• 不验证通信的身份，因此有可能遭遇伪装。
• 无法验证报文的完整性，所以有可能篡改。

未加密的协议都会出现类似的问题。

HTTPS = HTTP + 加密 + 认证 + 完整性保护

HTTPS 是身披 SSL 外壳的 HTTP。HTTPS 并非是应用层的一种新协议，只是 HTTP 通信接口部分用 SSL 和 TLS 协议代替而已。

原本HTTP直接和TCP通信；使用SSL时，先和SSL通信，再由SSL和TCP通信。

SSL是独立于HTTP协议的，应用层的其他协议也可以配合SSL协议实现网络安全。

相互交换密钥的公开密钥加密技术

SSL使用公开密钥加密的加密处理方式。公开密钥加密使用一对非对称的密钥——公钥、私钥。

公钥加密，私钥解密。客户端持有公钥，用私钥对发送的信息加密；服务器持有私钥，用私钥对客户端发送的密文解密。

注意：客户端的私钥是服务器事先传递过去的，即服务器先生成一对公钥私钥，把私钥发送到客户端，客户端才能用私钥进行加密。

在HTTPS中，对称加密与非对称加密混合使用。因为非对称加密适合加密小量数据，一般数据应使用对称加密进行加密解密。所以在HTTPS中，使用非对称加密的是对称密钥，即客户端把对称密钥用私钥加密发送到服务器，后续服务器用对称密钥加密解密一般的消息。

确保服务端公钥安全

因为客户端需要用服务端的公钥进行加密，所以首先要确保客户端能拿到正确的服务端公钥。公钥在下发的时候会被替换劫持，这里通过第三方认证机（CA）构确认公钥的正确性。

认证的方式通过数字签名校验实现，简单来说就是CA私钥加密HASH（通过内容生成），公钥解密得出HASH，比对从收到的内容生成的HASH是否相等。

这个过程如下：

前提准备：

• 客户端提前安装了CA的公钥。
• 服务端获取CA颁发的证书。
  1. 服务端生成一对公钥、私钥，私钥自己存着，公钥最终要传给客户端。
  2. 把公钥登记到CA，CA对公钥内容做HASH，对HASH值用CA私钥加密，密文+公钥打包成证书发送给服务器。

校验流程：

1. 服务端发送公钥证书给客户端；
2. 客户端对证书中的密文用CA的公钥解密得出HASH，对证书中的公钥内做HASH，对比两个HASH值。正确则提取公钥存到客户端。
3. 客户端使用服务端的公钥加密与服务器传输，开始加密通信。使用上述的混合加密方式，即非对称加密交换对称加密密钥，然后双方使用对称密钥进行加密通信。

RSA公钥、私钥的作用助记

既然是加密，那肯定是不希望别人知道我的消息，所以只有我才能解密，所以可得出公钥负责加密，私钥负责解密；同理，既然是签名，那肯定是不希望有人冒充我发消息，只有我才能发布这个签名，所以可得出私钥负责签名，公钥负责验证。

数字签名就是使用私钥对数据摘要进行签名，并附带和数据一起发送。可以起到防篡改、防伪装、防否认的作用。

证书则是由CA机构自己的私钥签发的数字签名。解决的签名的权威性问题，奠定了信任链的基础。

HTTPS安全通信过程

服务端已经生成公钥、私钥，并通过CA获得公钥证书。客户端已经事先安装CA公钥。

具体过程：

1. 客->服，Handshake: ClientHello

• 客户端通过发送 Client Hello 报文开始 SSL 通信。
• 报文中包含客户端支持的 SSL 的指定版本、加密组件（Clipher Suite）列表（所使用的加密算法及密钥长度等）。

2. 服->客，Handshake: ServerHello

• 服务器进行 SSL 通信，以 Server Hello 报文作为应答。
• 和客户端一样，在报文中包含 SSL 版本以及加密组件。
• 服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。

3. 服->客，Handshake: Certificate

• 服务器发送 Certificate 报文。报文中包含公钥证书。

4. 服->客，Handshake: ServerHelloDone

• 最后服务器发送 Server Hello Done 报文通知客户端，最初阶段的 SSL 握手协商部分结束。

5. 客->服，Handshake: ClientKeyExchange

• 第一次握手结束后，客户端以 Client Key Exchange 报文作为回应。
• 报文中包含通信加密中使用的一种称为 Pre-master secret 的随机密码串，该密码已用步骤 3 的公钥进行加密。

6. 客->服，ChangeCipherSpec

• 客户端继续发送 Change Cipher Spec 报文。告诉服务器之后的通信将采用该密码进行加密。

7. 客->服，Handshake: Finished

• 客户端发送 Finished 报文。该报文包含链接至今全部报文的整体校验值。
• 这次握手协商成功的标准是服务器能正确解密该报文。

8. 服->客，ChangeClipherSpec
9. 服->客，Handshake: Finished
10. 客->服，Application Data（HTTP）

• 客户端和服务端的 Finished 报文交换完毕后，SSL 连接建立完成。从此开始发送 HTTP 请求。

11. 服->客，Application Data（HTTP）

• 应用层协议通信，发送 HTTP 响应。

12. 客->服，Alert: warning, close notify

• 由客户端断开连接。

参考：HTTPS加密流程理解 - fengf233 - 博客园

单向认证与双向认证

上述的HTTPS基本流程就是单向认证，即指认证服务端的证书。单向认证中需要额外代码的情况往往是服务器下发的证书是CA颁发的，而是自签的，所以在检验服务端私钥证书时就要自定义的逻辑。

而双向认证，则是在ServerHelloDone前，发送来自客户端的公钥证书，服务端收到后用根证书解密客户端证书，取出客户端私钥。双向认证在确保了服务端的正确性，也确保了客户端的正确性。

两者过程对比：

单向认证：

1. 客->服，发起HTTPS连接请求，把SSL协议版本发送给服务端。
2. 服->客，发送服务端把本机公钥证书（server.crt）。
3. 客，校验公钥证书（server.crt），取出服务端公钥。
4. 客->服，并发送用服务端公钥加密的随机生成密钥R。
5. 服，用私钥（server.key）解密得出密钥R。
6. 服<->客，用密钥R进行加密通信。

双向认证：

1. 同上（客->服，发起HTTPS连接请求，把SSL协议版本发送给服务端）。
2. 同上（服->客，发送服务端把本机公钥证书（server.crt））。
3. 同上（客，校验公钥证书（server.crt），取出服务端公钥）。
4. 客->服，把自己的公钥证书（client.crt）发送给服务端。
5. 服，用根证书（root.crt）解密客户端公钥证书，拿到客户端公钥。
6. 客->服，发送自己支持的加密方案。
7. 服->客，根据双端能力，选择双方都能接受的加密方案，使用客户端公钥加密后发送。
8. 客->服，使用私钥解密加密方案，生成随机密钥R，使用服务端公钥加密后发送。
9. 同上5（服，用私钥（server.key）解密得出密钥R）。
10. 同上6（服<->客，用密钥R进行加密通信）。

参考：

• HTTPS双向认证指南 - 简书
• HTTPS单向认证、双向认证、抓包原理、反抓包策略 - yaphetsfang - 博客园

SSL和TLS

SSL 先有，TSL 是以 SSL 为原型开发的协议，有时会统一称该协议为 SSL。

不推荐一直使用HTTPS

• 与明文通信相比，加密通信会消耗更多的 CPU 及内存资源。所以敏感信息才使用 HTTPS 加密通信。
• 证书的费用开销。

• 密码。只有本人才会知道的字符串信息。
• 动态令牌。仅限本人持有的设备内显示的一次性密码。
• 数字令牌。仅限本人（终端）持有的信息。
• 生物认证。指纹和虹膜等本人的生理信息。
• IC 卡等。仅限本人持有的信息。

HTTP使用的认证方式：

• BASIC认证，基本认证。
• DIGEST认证，摘要认证。
• SSL客户端认证。
• FromBase认证，基于表单认证。

BASIC 认证

base64 发送明文密码。

问题：

• 明文传输，可窃听。
• 一般浏览器无法实现认证注销操作。
• 缺乏灵活，安全性差。

DIGEST 认证

使用质询（challenge/reponse），但不直接发送明文密码。

一开始一方先发送认证要求给对方，接着使用从另一方接收到的质询码计算生成响应码。最后将响应码返回给对方进行认证。

SSL 客户端认证

借由 HTTPS 的客户端证书来完成认证的方式，没错，这里就是上面的双向认证。步骤：

1. 接收到需要认证资源的请求，服务器会发送 Certificate Request 报文，要求客户端提供客户端证书。
2. 用户选择将发送的客户端证书后，客户端会把客户端证书以 Client Certificate 报文发送给服务器。
3. 服务器验证客户端证书通过后，方可领取证书内客户端的空开密钥，然后开始 HTTPS 加密通信。

双因素认证（Tow-factor authentication）

• SSL 客户端认证通常会和基于表单认证组合形成一种双因素认证。

  • SSL 客户端证书：认证客户端计算机

  • 密码：用来确定这是用户本人的行为

• 一条连接上只可发送一个请求。
• 请求只能从客户端开始。客户端不可以接收除响应以外的指令。
• 请求、响应首部未经压缩就发送。首部信息越多延迟越大。
• 发冗长的首部。每次相互发送相同的首部造成的浪费较多。
• 可任意选择数据压缩格式。非强制压缩发送。

SPDY

SPDY 的出现正是为了解决这些问题，SPDY 没有完全改写 HTTP 协议，而是在 TCP/IP 的应用层与传输层之间通过插入会话层的形式运作。同时，SPDY 规定通信中使用 SSL。

• HTTP - 应用层
• SPDY - 会话层
• SSL - 表示层
• TCP - 传输层

使用 SPDY 后，HTTP 协议额外获得以下功能：

• 多路复用流。一个 TCP 连接上，处理所有的 HTTP 请求。
• 赋予请求优先级。
• 压缩 HTTP 首部。
• 推送功能。这样服务器可直接发送数据，而不必等待客户端请求。
• 服务器提示功能。服务器可以主动提示客户端请求所需的资源。由于在客户端发现资源之前就可以获知资源的存在，因此在资源已缓存等情况下，可以避免发送不必要的请求。

然而 SPDY 也不是完美的，也还有一些未解决的问题：

• 只是将单个域名（IP 地址）的通信多路复用，所以当使用多个域名下的资源时，效果将受到限制。
• 还有一些不是 HTTP 协议导致的问题，如 web 内容的编写方式。

WebSocket

WebSocket是Web浏览器与Web服务器之间全双工通信。

这是一套独立协议，一旦 Web 服务器与客户端之间建立起 WebSocket 协议的通信连接，之后所有的通信都依靠这个专用协议进行。通信过程中可相互发送 JSON、XML、HTML 或图片等任意格式的数据。

但由于是建立在 HTTP 基础上的协议，连接的发起方仍是客户端，而一旦 WebSocket 通信连接后，不论服务器还是客户端，任意一端都可直接向对方发送报文。

建立连接时还是用HTTP协议请求、响应完成握手，后续就不再发送HTTP数据帧，而是WebSocket独立数据帧。

特点：

• 推送功能。服务器可直接发送数据，不必等客户端的请求。
• 减少通信量。只要建立起 WebSocket 连接，就希望一直保持连接状态。而且 WebSocket 的首部信息也少，连接次数、通信量都相应减少。
• 建立在TCP协议之上，服务端实现比较容易。
• 与HTTP协议有良好兼容性，默认端口相同，握手阶段也是用HTTP协议，不容易被屏蔽。
• 可以发送文本，也可以发送二进制。
• 没有同源限制，客户端可以与任意服务器通信。

HTTP/2.0

新的概念

帧：数据通信的最小单位，以二进制压缩格式存放内容。来自不同数据流的帧可以交错发送，然后根据每个帧头的数据流标识符重新组装。帧信息包含：类型、长度、标记、流标识、palyload。

消息：HTTP/2.0中逻辑上的HTTP消息，如请求和响应，消息由一个或多个帧组成。

流：连接中的虚拟信道，可以承载双向消息传输，包含1或多条消息。每个流有唯一整数标识符。为了防止两端双向流标识符冲突，客户端发起的流具有奇数ID，服务端发起的流具有偶数ID。特点：

• 双向性：同一流内，可以同时发送和接收数据。
• 有序性：流中传输二进制帧，帧在流上的被发送和被接收都是按序进行的。
• 并行性：流中的二进制帧都并行传输的，无需按序等待。帧可以乱序发送，然后再根据每个帧首部的流标识符重新组装。
• 流的创建和关闭可以被客户端或服务端任意一方执行。

连接：包含1或多个流，所有通信都在一个TCP连接上完成。该连接可以承载任意数量的双向数据流。

二进制分帧

把传输信息分为Header帧和Data帧，对应HTTP/1.x的首部信息和实体信息。

多路复用/共享连接

HTTP/1.x中虽然可以通过长连接在一个连接中发起多个请求，并处理每个请求的响应。但客户端在同一域名下的请求会有一定数量限制，超出会被阻塞，要实现多流并行，只能开启多个TCP连接。

HTTP/2.0单个TCP连接可以承载任意数量的双向数据流，并且可以并处请求和响应，实现单个连接的多路复用、共享连接。

首部压缩

HTTP/2.0在客户端和服务端使用首部表来跟踪和存储之前发送的键值对，对于相同的数据，不在重复发送。

首部表在HTTP/2.0连接期间始终存在，由客户端和服务端共同渐进更新。

请求优先级

每个流都可以带上一个31 bit的优先值。服务器可以根据流的优先级，控制资源分配。

服务端推送

服务端可以对客户端请求发送多个响应，服务端向客户端推送资源无需明确发起请求。这可以让在遵循同源的情况下，不同的页面可以共享缓存资源。

概述

CMSampleBuffer是一个包含零个或多个压缩或未压缩（compressed or uncompressed），特定媒体类型的样本（音频、视频、多路复用等）。

一个CMSampleBuffer可以包含以下之一的核心数据：

• CMBlockBuffer，包含一个或多个媒体样本。
• CVImageBuffer，是对CMSampleBuffer流格式描述的引用，包含每个媒体样本的大小、时序信息，以及缓冲区级别和样本基本的附件。

sample buffer可以包含样本级别和缓冲区级别的附件。样本级别附件与缓冲区的每个样本（帧）相关联，并包含诸如时间戳和视频帧相关信息。缓冲区级别附件提供有关缓冲区整体的信息，如播放速度和消费缓冲区时执行的操作。

数据来源

• 通过采集设备（摄像头、麦克风）采集的音频或视频数据。

// AVCaptureVideoDataOutputSampleBufferDelegate、AVCaptureAudioDataOutputSampleBufferDelegate
optional func captureOutput
(_ output: AVCaptureOutput, 
 didOutput sampleBuffer: CMSampleBuffer, 
 from connection: AVCaptureConnection)

• 读取视频文件的输出流AVAssetReaderOutput。

func copyNextSampleBuffer() -> CMSampleBuffer?

• ARKit ARSessionObserver输出捕获的audio sample buffer。

optional func session
(_ session: ARSession, 
 didOutputAudioSampleBuffer audioSampleBuffer: CMSampleBuffer)

• VTCompressionSession硬编码作为VTCompressionOutputCallback输出。

typealias VTCompressionOutputCallback = 
(UnsafeMutableRawPointer?, 
 UnsafeMutableRawPointer?, 
 OSStatus, 
 VTEncodeInfoFlags, 
 CMSampleBuffer?) -> Void

注意：

Clients of CMSampleBuffer must explicitly manage the retain count by calling CFRetain and CFRelease, even in processes using garbage collection.

数据输出

• AVAssetWriter保存视频AVAssetWriterInput。

func append(_ sampleBuffer: CMSampleBuffer) -> Bool

• AVSampleBufferDisplayLayer展示解码后的sample buffer。

func enqueue(_ sampleBuffer: CMSampleBuffer)

数据结构

无论是读取还是采集，output的videoSetting的kCVPixelBufferPixelFormatTypeKey字段控制sample buffer的mediaSubType输出的色彩格式，转换色彩格式有GPU参与，性能较高，可按需设置。

创建

- (void)appendVideoPixelBuffer:(CVPixelBufferRef)pixelBuffer withPresentationTime:(CMTime)presentationTime
{
    CMSampleBufferRef sampleBuffer = NULL;
    CMFormatDescriptionRef outputFormatDescription = NULL;
    CMVideoFormatDescriptionCreateForImageBuffer( kCFAllocatorDefault, pixelBuffer, &outputFormatDescription );


    CMSampleTimingInfo timingInfo = {0,};
    timingInfo.duration = kCMTimeInvalid;
    timingInfo.decodeTimeStamp = kCMTimeInvalid;
    timingInfo.presentationTimeStamp = presentationTime;

    OSStatus err = CMSampleBufferCreateForImageBuffer( kCFAllocatorDefault, pixelBuffer, true, NULL, NULL, outputFormatDescription, &timingInfo, &sampleBuffer );
    if ( sampleBuffer ) {
        // do some thing
        CFRelease( sampleBuffer );
    }
    else {
        NSString *exceptionReason = [NSString stringWithFormat:@"sample buffer create failed (%i)", (int)err];
        @throw [NSException exceptionWithName:NSInvalidArgumentException reason:exceptionReason userInfo:nil];
    }
}
// CMSampleBufferCreateReady与CMSampleBufferCreate相同，只是dataReady始终为true，因此不需要传递makeDataReadyCallback或refcon。

信息存取

get：

按解码顺序排列帧。

• dataBuffer: CMBlockBuffer?
• imageBuffer: CVImageBuffer?
• decodeTimeStamp: CMTime：首个sample的DTS。
• outputDecodeTimeStamp: CMTime：outputPTS + (DTS - PTS) / SpeedMultiplier
• presentationTimeStamp: CMTime
• outputPresentationTimeStamp: CMTime
• duration: CMTime
• outputDuration: CMTime：(D - trimDAtStart - trimDAtEnd) / SpeedMultiplier
• numSamples: Int
• formatDescription: CMFormatDescription?
• sampleTimingInfos() throws -> [CMSampleTimingInfo]：包含DTS、PTS和Duration
• sampleAttachments: CMSampleBuffer.SampleAttachmentsArray

set：

• setDataBuffer：视频、音频压缩数据
• setOutputPresentationTimeStamp

参考资料

• CMSampleBuffer 分析 - 简书

CVPixelBuffer 创建与转换

读取原始的像素数组

通过 CVPixelBufferGetBaseAddress 可以获得像素数组的指针，该数组中的每个元素应该被解释为 unsigned char。参考如下代码：

CVPixelBufferRef pixelBuffer;
// 假设我们已经有了一个 pixelBuffer
// 通过如下 API 拿到该图像的宽、高、每行的字节数、每个像素的字节数
size_t w = CVPixelBufferGetWidth(pixelBuffer);
size_t h = CVPixelBufferGetHeight(pixelBuffer);
size_t r = CVPixelBufferGetBytesPerRow(pixelBuffer);
size_t bytesPerPixel = r/w;
OSType bufferPixelFormat = CVPixelBufferGetPixelFormatType(pixelBuffer);
NSLog(@"GEMFIELD whrb: %zu - %zu - %zu - %zu - %u",w,h,r,bytesPerPixel,bufferPixelFormat);
// 通过如下 API 拿到 CVPixelBufferRef 的图像格式：
// 比如：kCVPixelFormatType_24RGB、kCVPixelFormatType_32BGRA
OSType bufferPixelFormat = CVPixelBufferGetPixelFormatType(pixelBuffer);
// 准备开始读取裸的像素数组了
CVPixelBufferLockBaseAddress( pixelBuffer, 0 );
// gemfield_buffer 就是裸的数组
const unsigned char* gemfield_buffer = (const unsigned char*)CVPixelBufferGetBaseAddress(pixelBuffer);
// 这里你可以对该数组进行读取和处理
......
// 结束
CVPixelBufferUnlockBaseAddress( pixelBuffer, 0 );

使用原始的像素数组创建

CVPixelBufferRef pixelBuffer = NULL;
int width=319;
int height=64;
CVPixelBufferCreateWithBytes(kCFAllocatorDefault,width,height,kCVPixelFormatType_24RGB,x.get(),3 * width, NULL, NULL, NULL, &pixelBuffer);

转换为 UIImage

可以使用下面的例子来把 CVPixelBufferRef 转换为 UIImage：

// 假设我们已经有了一个 pixelBuffer
CVPixelBufferRef pixelBuffer;
CIImage *ciImage = [CIImage imageWithCVPixelBuffer:pixelBuffer];
CIContext *temporaryContext = [CIContext contextWithOptions:nil];
CGImageRef syszux_cgiimg = [temporaryContext createCGImage:ciImage fromRect:CGRectMake(0, 0,CVPixelBufferGetWidth(pixelBuffer),CVPixelBufferGetHeight(pixelBuffer))];
UIImage *syszux_uiimg = [UIImage imageWithCGImage:syszux_cgiimg];
CGImageRelease(syszux_cgiimg);

使用 UIImage 创建

UIImage 是 CGImage 的 wrapper，通过 CGImage 拿到图像的宽、高信息。然后在一个 context 中，通过 CGContextDrawImage 函数来将 CGImage“渲染”出来，这个时候原始的像素数就保存在了 context 中 CVPixelBufferRef 指向的 baseAddress 上了。

代码如下所示：

- (CVPixelBufferRef)syszuxPixelBufferFromUIImage:(UIImage *)originImage {
    CGImageRef image = originImage.CGImage;
    NSDictionary *options = [NSDictionary dictionaryWithObjectsAndKeys:
                             [NSNumber numberWithBool:YES], kCVPixelBufferCGImageCompatibilityKey,
                             [NSNumber numberWithBool:YES], kCVPixelBufferCGBitmapContextCompatibilityKey,
                             nil];
    CVPixelBufferRef pxbuffer = NULL;
    CGFloat frameWidth = CGImageGetWidth(image);
    CGFloat frameHeight = CGImageGetHeight(image);
    CVReturn status = CVPixelBufferCreate(kCFAllocatorDefault,
                                          frameWidth,
                                          frameHeight,
                                          kCVPixelFormatType_32ARGB,
                                          (__bridge CFDictionaryRef) options,
                                          &pxbuffer);
    NSParameterAssert(status == kCVReturnSuccess && pxbuffer != NULL);
    CVPixelBufferLockBaseAddress(pxbuffer, 0);
    void *pxdata = CVPixelBufferGetBaseAddress(pxbuffer);
    NSParameterAssert(pxdata != NULL);
    CGColorSpaceRef rgbColorSpace = CGColorSpaceCreateDeviceRGB();
    CGContextRef context = CGBitmapContextCreate(pxdata,
                                                 frameWidth,
                                                 frameHeight,
                                                 8,
                                                 CVPixelBufferGetBytesPerRow(pxbuffer),
                                                 rgbColorSpace,
                                                 (CGBitmapInfo)kCGImageAlphaNoneSkipFirst);
    NSParameterAssert(context);
    CGContextConcatCTM(context, CGAffineTransformIdentity);
    CGContextDrawImage(context, CGRectMake(0,
                                           0,
                                           frameWidth,
                                           frameHeight),
                       image);
    CGColorSpaceRelease(rgbColorSpace);
    CGContextRelease(context);
    CVPixelBufferUnlockBaseAddress(pxbuffer, 0);
    return pxbuffer;
}

深拷贝

- (void)captureOutput:(AVCaptureOutput *)captureOutput didOutputSampleBuffer:(CMSampleBufferRef)sampleBuffer fromConnection:(AVCaptureConnection *)connection {
       CVPixelBufferRef pixelBuffer = CMSampleBufferGetImageBuffer(sampleBuffer);
       // Get pixel buffer info
       const int kBytesPerPixel = 4;
       CVPixelBufferLockBaseAddress(pixelBuffer, 0);
       int bufferWidth = (int)CVPixelBufferGetWidth(pixelBuffer);
       int bufferHeight = (int)CVPixelBufferGetHeight(pixelBuffer);
       size_t bytesPerRow = CVPixelBufferGetBytesPerRow(pixelBuffer); 
       uint8_t *baseAddress = CVPixelBufferGetBaseAddress(pixelBuffer);
       // Copy the pixel buffer
       CVPixelBufferRef pixelBufferCopy = NULL;
       CVReturn status = CVPixelBufferCreate(kCFAllocatorDefault, bufferWidth, bufferHeight, kCVPixelFormatType_32BGRA, NULL, &pixelBufferCopy);
       CVPixelBufferLockBaseAddress(pixelBufferCopy, 0);
       uint8_t *copyBaseAddress = CVPixelBufferGetBaseAddress(pixelBufferCopy);
       memcpy(copyBaseAddress, baseAddress, bufferHeight * bytesPerRow);
       // Do what needs to be done with the 2 pixel buffers
}

若需要对帧做基本处理，可以只是 vImage 对其解码后数据处理。

CVPixelBufferPool

CVPixelBufferPool，主要是实现了 CVPixelBuffer 中的 IOSurface 的复用与回收。

压缩属性

压缩属性都是以kVTCompressionPropertyKey_Xx命名，所以下面的属性名都省略了其前缀kVTCompressionPropertyKey_。

码流配置

Depth：像素深度。

该属性仅由视频编码器支持，用于与特定像素格式（例如，16位RGB、24位RGB）绑定的格式。

ProfileLevel：码流配置和级别。

配置文件和级别常量

H264EntropyMode：用于H.264压缩的熵编码模式。

如果H.264编码器支持，该属性控制编码器是否应使用基于上下文的自适应变长编码（CAVLC）或基于上下文的自适应二进制算术编码（CABAC）。CABAC通常能提供更好的压缩，但代价是更高的计算开销。默认值是针对编码器的，可能会根据其他编码器的设置而改变。

注意：改变默认的熵模式可能会导致配置与要求的配置文件和级别不兼容。这种情况下的结果是不确定的，可能包括编码错误或不符合要求的输出流。

• kVTH264EntropyMode_CABAC
• kVTH264EntropyMode_CAVLC

缓冲区

NumberOfPendingFrames：压缩会话中待处理的帧的数量。该值可能会异步减少。

PixelBufferPoolIsShared：布尔值，表示视频编码器和会话客户端之间是否共享公共像素缓冲池。

false表示视频编码器和客户端的像素缓冲区属性不兼容，使用单独的缓冲池。

VideoEncoderPixelBufferAttributes：视频编码器的像素缓冲区属性。使用这些属性来为源像素缓冲区创建一个像素缓冲区池。

清洁光圈和像素长宽比

AspectRatio16x9：布尔值，表示DV视频流是否应设置16x9标志。

此属性由DV25/50系列编码器支持。

false时，图片长宽比为4:3。true时，图片长宽比为16:9。无论哪种方式，都会使用一个固定的长宽比（具体数值取决于格式是NTSC还是PAL）。

CleanAperture：编码帧的清洁光圈。

如果视频编码器执行特定的清洁光圈，这个属性是只读的（VTSessionSetProperty(_:key:value:)将返回kVTPropertyReadOnlyErr）。洁净孔径将在输出样本的格式描述中设置，并可能影响源帧的缩放。NULL是这个属性的一个有效值，意味着清洁孔径是全宽和全高。

FieldCount：场类型，表示帧应该是逐行编码（1）还是隔行编码（2）。

在输出样本的格式描述上设置的，可能会影响源帧的缩放。NULL是这个属性的一个有效值。

FieldDetail：隔行扫描帧的场排序。

如果视频编码器执行特定的场排序，这个属性将是只读的（VTSessionSetProperty(_:key:value:)返回kVTPropertyReadOnlyErr）。字段细节是在输出样本的格式描述上设置的，并可能影响源帧的缩放。NULL是这个属性的一个有效值。

PixelAspectRatio：编码帧的像素长宽比。

如果视频编码器强制执行特定的像素长宽比，该属性将是只读的（VTSessionSetProperty(_:key:value:) 返回 kVTPropertyReadOnlyErr）。像素长宽比是在输出样本的格式描述上设置的，并可能影响源帧的缩放。NULL是这个属性的有效值，意味着方形像素（1:1）。

ProgressiveScan：布尔值，表示DV视频流是否应设置逐行标志。

DV25/50系列编码器支持此属性。如果是假的，内容被编码为隔行扫描。如果为真，则内容被编码为渐进式。此属性的值可固定 kVTCompressionPropertyKey_FieldCount 和 kVTCompressionPropertyKey_FieldDetail 属性。

颜色

ColorPrimaries：压缩内容的颜色原色。

TransferFunction：压缩内容的转换函数。

YCbCrMatrix：用于压缩内容的YCbCr矩阵。

ICCProfile：用于压缩内容的ICC配置文件。

预期值

ExpectedDuration：压缩会话的预期总时长。

ExpectedFrameRate：预期的帧率。

SourceFrameCount：源帧的数量。

帧依赖

AllowFrameReordering：布尔值，表示是否启用了帧重排。

AllowTemporalCompression：布尔值，表示是否启用了时间压缩。

MaxKeyFrameInterval：关键帧之间的最大间隔，也被称为关键帧率。

MaxKeyFrameIntervalDuration：从一个关键帧到下一个关键帧的最大持续时间，单位是秒。

硬件加速

UsingHardwareAcceleratedVideoEncoder：布尔值，表示是否使用了硬件加速视频编码器。

kVTVideoEncoderSpecification_RequireHardwareAcceleratedVideoEncoder：布尔值，表示是否需要硬件加速编码。

kVTVideoEncoderSpecification_EnableHardwareAcceleratedVideoEncoder：布尔值，表示是否允许硬件加速视频编码（如果可用）。

多重压缩存储

MultiPassStorage：启用多路压缩并为编码器私有数据提供存储。

每帧配置

kVTEncodeFrameOptionKey_ForceKeyFrame：布尔值，表示当前帧是否被强制为关键帧的。

PixelTransferProperties：用于配置VTPixelTransferSession的属性，以便在必要时将源帧从客户端的图像缓冲区转移到视频编码器的图像缓冲区。

速率控制

AverageBitRate：长期期望的平均比特率，单位是比特/秒。

DataRateLimits：对数据速率的零、一或两个硬限制。

MoreFramesAfterEnd：布尔值，表示一个压缩会话的帧是否以及如何与其他压缩帧串联以形成一个更长的系列。

Quality：希望的压缩质量。

RealTime：布尔值，表示是否建议视频编码器进行实时压缩。

MaxH264SliceBytes：H.264编码的最大分片大小。

MaxFrameDelayCount：压缩器在必须输出一个压缩帧之前允许保留的最大帧数。

AVAssetExportSession可以实现简单的导出。

输入：AVAsset

输出：URL

可配置项：

• 格式
  • preset
  • timeRange: CMTimeRange
  • outputFileType: AVFileType
• 限制与优化
  • fileLengthLimit: Int64
  • shouldOptimizeForNetworkUse: Bool
  • canPerformMultiplePassesOverSourceMediaData: Bool、directoryForTemporaryFiles: URL
• 附加
  • audioMix: AVAudioMix
  • videoComposition: AVVideoComposition
  • audioTimePitchAlgorithm: AVAudioTimePitchAlgorithm
  • metadata: [AVMetadataItem]

操作：exportAsynchronously、cancelExport

获取状态：progress、status、error

Reader+Writer

AVAssetReader

管理读取输出。

输入：AVAsset

操作：startReading、cancelReading、添加输出

状态：status、error

AVAssetReaderOutput

输出帧。

输入：AVAssetTrack

配置：alwaysCopiesSampleData: Bool

操作：copyNextSampleBuffer、markConfigurationAsFinal（提前结束）

输出：CMSampleBuffer

具体子类：

• TrackOutput：最常用
  • 输入：AVAssetTrack
  • 配置：
    • outputSettings: [String : Any]
    • audioTimePitchAlgorithm: AVAudioTimePitchAlgorithm
• AudioMixOutput
  • 输入：[AVAssetTrack]
  • 配置：
    • audioSettings: [String : Any]
    • audioMix: AVAudioMix
    • audioTimePitchAlgorithm: AVAudioTimePitchAlgorithm
• VideoCompositionOutput
  • 输入：[AVAssetTrack]
  • 配置：
    • videoSettings: [String : Any]
    • videoComposition: AVVideoComposition、
• SampleReferenceOutput
  • 输入：AVAssetTrack

AVAssetReaderOutputMetadataAdaptor

从TrackOutput输出元数据。

操作：nextTimedMetadataGroup

AVAssetWriter

管理写入输入。

输出：URL

配置：

• outputFileType: AVFileType
• directoryForTemporaryFiles: URL
• metadata: [AVMetadataItem]
• movieFragmentInterval: CMTime
• overallDurationHint: CMTime
• movieTimeScale: CMTimeScale
• shouldOptimizeForNetworkUse: Bool

操作：startWriting、finishWriting、cancelWriting、添加输入（组）、startSession、endSession

状态：status、error

AVAssetWriterInput

拼接音视频帧。

输入：CMSampleBuffer

配置：

• mediaType: AVMediaType
• outputSettings: [String : Any]
• sourceFormatHint: CMFormatDescription
• preferredVolume: Float
• transform: CGAffineTransform
• naturalSize: CGSize
• mediaTimeScale: CMTimeScale
• metadata: [AVMetadataItem]
• expectsMediaDataInRealTime: Bool
• marksOutputTrackAsEnabled: Bool
• performsMultiPassEncodingIfSupported: Bool
• preferredMediaChunkAlignment: Int
• preferredMediaChunkDuration: CMTime
• mediaDataLocation: AVAssetWriterInput.MediaDataLocation

操作：拼接帧、markAsFinished、addTrackAssociation

状态：requestMediaDataWhenReady、isReadyForMoreMediaData

AVAssetWriterInputGroup

输入：AVAssetWriterInput

AVAssetWriterInputPixelBufferAdaptor

拼接指定PTS的CVPixelBuffer，并提供CVPixelBufferPool。

输出：AVAssetWriterInput

配置：sourcePixelBufferAttributes: [String : Any]

AVAssetWriterInputMetadataAdaptor

拼接AVTimedMetadataGroup到Input。

输出：AVAssetWriterInput

AVOutputSettingsAssistant

辅助生成音视频配置字典。

组合实现导出

先对AVAsset异步加载"tracks"key。

读取流程：

1. 用AVAsset构建AssetReader；
2. 根据轨道，使用解码配置字典分别创建ReaderOutput；
3. 添加到AssetReader；
4. AssetReader调用startReading开始读取；
5. ReaderOutput循环逐帧调用copyNextSampleBuffer，输出帧，若帧为空则完成或遇到错误。

写入流程：

1. 用输出URL、文件类型创建AssetWriter；
2. 根据轨道类型，使用编码配置字典创建WriterInput；
3. 添加到AssetWriter；
4. AssetWriter调用startWriting、startSession开始写入；
5. WriterInput调用requestMediaDataWhenReady，在其回调中：
   1. isReadyForMoreMediaData == true
   2. WriterInput拼接帧；完成时调用markAsFinished。
6. 各个轨都写入完成时，AssetWriter调用finishWriting完成写入（这会内部调用endSession）。

要想提前结束，调用endSession，再调用finishWriting。

配置字典是关键。

组合使用：

1. 异步读取AVAsset key，进入初始化阶段：
   1. 创建AssetReader，然后AssetWriter。
   2. 取出AssetTrack创建分别创建ReaderOutput和WriterInput。
2. 读取拼接阶段：
   1. AssetReader调用startReading开始读取；AssetWriter调用startWriting、startSession开始写入；
   2. ReaderOutput循环逐帧调用copyNextSampleBuffer，输出帧；WriterInput检查是否就绪，拼接帧；
3. ReaderOutput没有帧了，进入完成阶段：
   1. 检查是否有错误；
   2. AssetWriter调用finishWriting完成写入。

多线程应用：

• 都使用串行队列，分别创建：
  • 主操作队列 ×1
  • 各轨道读写队列 ×N
• 初始化阶段在主队列进行，即在异步读取AVAsset key后进入主操作队列创建各种对象。
• 每个轨道的读帧、写帧操作都在对应的一个队列中进行。
• 使用调度组在所有轨道都读写完成后回调通知。进入各轨道队列前enter，各个轨道读写完成后leave。
• 完成后进入主操作队列，进行收尾工作。

整体关系

Composition：作为内容主体，一个抽象的可编辑的AVAsset子类，提供面向对象的多轨操作。

• CompositionTrack ×N：管理时间，总的音视频轨信息。
  • AssetTrack片段 ×N
  • 轨道的偏好信息：naturalTimeScale、preferredTransform、preferredVolume

AudioMix：附加信息，对音量的描述

• inputParameters：AudioMixInputParameters ×N：描述音量（+时间=渐变）、变速时的音调策略

AudioMixInputParameters的audioTapProcessor可以使用AudioUnit给音频增加效果，但似乎查不到具体的额API文档，可参考：MTAudioProcessingTap with kMTAudio… | Apple Developer Forums、gchilds/MTAudioProcessingTap-in-Swift: Example of creating an MTAudioProcessingTap in Swift4.2。

VideoComposition：附加信息，对画面的描述

• 视频属性控制：

  • frameDuration
  • renderSize
  • colorParimaties
  • colorTransferFunction
  • colorYCbCrMatrix

• 视频操作，通过以下三种方式：

  • instructions：AVVideoCompositionInstructionProtocol ×N

    • VideoCompositionLayerInstruction：提供几种图像以时间点、时间区间/渐变操作

      • opacity

      • transform

      • cropRectangle

  • animationTool：提供与Core Animation的几种交互方式，不能实时预览的，即设置到playerItem看不到效果。

    • 新增一个用CALayer表示的视频轨：init(additionalLayer: CALayer, asTrackID: CMPersistentTrackID)
    • 用CALayer层级关系管理视频轨：init(postProcessingAsVideoLayer: CALayer, in: CALayer)、init(postProcessingAsVideoLayers: [CALayer], in: CALayer)

  • customVideoCompositorClass：自己实现一个VideoComposition，可通过GL、Metal实现自定义的转场

以上API的Mutable版本的类才是可编辑的。

以上的Composition，可用于创建PlayerItem、AssetExportSession。AudioMix、VideoComposition作为属性设置到AssetExportSession、AssetReaderAudioMixOutput、playerItem。

具体API

AVMutableComposition

AVAsset的子类，因此这是最后预览、导出操作的数据对象。

整体操作

对整个composition对象进行整体操作，当然这会涉及多个轨道，除了对整体进行时间伸缩，否则较少使用。

/// 插入空占位
func insertEmptyTimeRange(_ timeRange: CMTimeRange)

/// 插入asset
func insertTimeRange(_ timeRange: CMTimeRange, of asset: AVAsset, at startTime: CMTime) throws

/// 移除时间段的内容，注意这里不会移除既有的轨道。
func removeTimeRange(_ timeRange: CMTimeRange)

/// 伸缩时间，即改变时间区间内所有轨道的时长
func scaleTimeRange(_ timeRange: CMTimeRange, toDuration duration: CMTime)

/// 配置视频画幅尺寸
var naturalSize: CGSize { get set }

轨道操作

大多数操作都是基于轨道。

/// 添加、移除轨道
func addMutableTrack(withMediaType mediaType: AVMediaType, preferredTrackID: CMPersistentTrackID) -> AVMutableCompositionTrack?
func removeTrack(_ track: AVCompositionTrack)

// 其他API只是获取轨道等非常用操作

AVMutableCompositionTrack

一个可修改的轨道。

常用配置属性

/// 视频翻转矩阵
var preferredTransform: CGAffineTransform { get set }

/// 音频轨道音量
var preferredVolume: Float { get set }

/// 其他不太常用的属性
var languageCode: String? { get set }
var extendedLanguageTag: String? { get set }
var naturalTimeScale: CMTimeScale { get set }

增删改查

func insertEmptyTimeRange(_ timeRange: CMTimeRange)
func insertTimeRange(_ timeRange: CMTimeRange, of track: AVAssetTrack, at startTime: CMTime) throws
func insertTimeRanges(_ timeRanges: [NSValue], of tracks: [AVAssetTrack], at startTime: CMTime) throws // 似乎不常用
func removeTimeRange(_ timeRange: CMTimeRange)
func scaleTimeRange(_ timeRange: CMTimeRange, toDuration duration: CMTime)
var segments: [AVCompositionTrackSegment]! { get set }

AVMutableAudioMix

包含混音（目前的混音只有音量调节）参数，所以其对象只有一个属性：

var inputParameters: [AVAudioMixInputParameters] { get set }

AVMutableAudioMixInputParameters

音频混音参数。

/// 创建
convenience init(track: AVAssetTrack?)
/// 创建后也可以修改trackId更变应用的轨道
var trackID: CMPersistentTrackID { get set }

/// 设置音量
func setVolume(_ volume: Float, at time: CMTime)
func setVolumeRamp(fromStartVolume startVolume: Float, toEndVolume endVolume: Float, timeRange: CMTimeRange)

/// 设置音调算法
var audioTimePitchAlgorithm: AVAudioTimePitchAlgorithm? { get set }

AVMutableVideoComposition

控制视频轨道组合行为。

/// 创建
init(propertiesOf asset: AVAsset)

/// 配置视频相关属性
var frameDuration: CMTime { get set }
var renderSize: CGSize { get set }
var renderScale: Float { get set } // 不常用
var colorPrimaries: String? { get set }
var colorTransferFunction: String? { get set }
var colorYCbCrMatrix: String? { get set }

/// 配置视频操作
var instructions: [AVVideoCompositionInstructionProtocol] { get set }
var animationTool: AVVideoCompositionCoreAnimationTool? { get set }
var customVideoCompositorClass: AVVideoCompositing.Type? { get set }

AVMutableVideoCompositionInstruction

提供一个时间范围内的视频组织信息。由一组AVMutableVideoCompositionLayerInstruction对象格式定义的指令组成的。

/// 自顶而下排列的layerInstructions
var layerInstructions: [AVVideoCompositionLayerInstruction] { get set }
var timeRange: CMTimeRange { get set }
var enablePostProcessing: Bool { get set }
var backgroundColor: CGColor? { get set }

AVMutableVideoCompositionLayerInstruction

给视频特效，用于定义给定视频轨道应用的基于时间的模糊、变形、和裁剪效果。从其构建方式可见，其更类似于AVMutableAudioMixInputParameters。

/// 构建
convenience init(assetTrack track: AVAssetTrack)
var trackID: CMPersistentTrackID { get set }

/// 支持的操作
func setOpacity(_ opacity: Float, at time: CMTime)
func setOpacityRamp(fromStartOpacity startOpacity: Float, toEndOpacity endOpacity: Float, timeRange: CMTimeRange)
func setTransform(_ transform: CGAffineTransform, at time: CMTime)
func setTransformRamp(fromStart startTransform: CGAffineTransform, toEnd endTransform: CGAffineTransform, timeRange: CMTimeRange)
func setCropRectangle(_ cropRectangle: CGRect, at time: CMTime)
func setCropRectangleRamp(fromStartCropRectangle startCropRectangle: CGRect, toEndCropRectangle endCropRectangle: CGRect, timeRange: CMTimeRange)

LayerInstruction是应用于一个轨道的，意味着要想在应用特效的时候能看到底下的视频，则需要多个视频轨道。

VideoComposition+CoreAnimation

视频编辑中除了可以叠加轨道，还可以叠加CALayer。这通过VideoComposition的animationTool实现。其类是AVVideoCompositionCoreAnimationTool：

/// 添加额外的图层
convenience init(additionalLayer layer: CALayer, asTrackID trackID: CMPersistentTrackID)

/// 自定义组织视频层与根图层。这里animationLayer是根图层，videoLayer视频层是其子图层，除此以外还可以在animationLayer添加更多子图层。
convenience init(postProcessingAsVideoLayer videoLayer: CALayer, in animationLayer: CALayer)

/// 拷贝视频帧到多个视频层
convenience init(postProcessingAsVideoLayers videoLayers: [CALayer], in animationLayer: CALayer)

在视频中使用CoreAnimation，常需要设置geometryFlipped属性，让其坐标翻转一遍。

通过AVVideoCompositionCoreAnimationTool使用Core Animation时需要注意：

• 用AVCoreAnimationBeginTimeAtZero表示0时间点；
• isRemovedOnCompletion设为false；
• 避免使用与UIView关联的CALayer。

AVAssetExportSession

高级导出类，是个高级API，要想更细化地配置，还是需要AVAssetReader+AVAssetWriter。

构建

init?(asset: AVAsset, presetName: String)

当然可以直接构建后就开始导出。其音视频的转码配置都囊括在presetName中，即既有的方案中去直接套用。

配置

/// 输出文件路径
var outputURL: URL? { get set }

/// 文件类型，准确地来说是容器类型
var outputFileType: AVFileType? { get set }

/// 文件长度限制
var fileLengthLimit: Int64 { get set }

/// 导出时间区间
var timeRange: CMTimeRange { get set }

/// 附带的元数据
var metadata: [AVMetadataItem]? { get set }

/// 混音
var audioMix: AVAudioMix? { get set }

/// 音调算法（在伸缩时长时）
var audioTimePitchAlgorithm: AVAudioTimePitchAlgorithm { get set }

/// 是否为网络播放优化
var shouldOptimizeForNetworkUse: Bool { get set }

/// video composition
 var videoComposition: AVVideoComposition? { get set }

/// custom video compositor
var customVideoCompositor: AVVideoCompositing? { get }

AVFoundation

• AVAssetReader
• AVSampleBufferGenerator

Video Toolbox

• VTDecompressionSession

Core Video

• CVPixelBuffer integration with Metal

使用AVFoundation的AVPlayer、AVAssetExportSession、AVAssetReader和Video Toolbox的VTDecompressSesion都自动进行硬件加速以及CMSampleBuffer的RPC优化。

视频核心数据结构

CVPixelBuffer：原始图像+图像元数据

CMBlockBuffer：任意类型的二进制数据（压缩图像）+元数据

CMSampleBuffer：

• CVPixelBuffer+时间信息+帧元数据（CMFormatDescription）
• CMBlockBuffer+时间信息+帧元数据
• 只包含元数据

IOSurface：不同框架、设备中交换图像数据的高速通道，应用在：

• 不同框架之间：CoreVideo和Metal
• 不同进程之间：解码进程和App进程
• 不同的内存区：显存和内存

CVPixelBufferPool：实现了CVPixelBuffer中的IOSurface的复用与回收。

解码流程

在解码的过程中如果配置的输出格式与原始数据格式不一致，还会发生转码，触发内存拷贝，要尽量避免。

获取解封装后的数据

要想获得解码前的裸数据，即解封装后的裸数据（输出为CMSampleBuffer），可以通过以下方式实现：

• AVAssetReader：创建track ouput时把outputSetting设为nil。
• AVSampleBufferGenerator：只能读出未解码的裸数据。
• 自己生成CMSampleBuffer：把数据读取出来，构建CMBlockBuffer，再加上时间信息，构建出CMSampleBuffer。这样的CMSampleBuffer不带RPC优化。

使用Video Toolbox解码

VTDecompressionSession包含三部分：

• 解码器
• CVPixelBufferPool
• VTPixelTransferSession

使用VTDecompressionSession的步骤：

1. 创建VTDecompressionSession；
2. 通过VTSessionSetProperty配置session；
3. 传递CMSampleBuffer视频帧给session解码。
4. 从回调中获取解码CMSampleBuffer。

虽然回调是异步的，但回调中的逻辑仍会反向影响解码器的性能。常见的做法是把回调中的解码帧用队列缓存起来，在另外的线程处理。

CVPixelBuffer与Metal交互

拿到了解码帧CMSampleBuffer，就可以从中取出CVPixelBuffer，接下来就是如何处理和渲染了，这里使用Metal完成。

CVPixelBuffer与Metal交互方式：

• 直接使用IOSurface。即直接通过从CVPixelBuffer取出的IOSurface创建Metal纹理，但要手动处理IOSurface的内存释放（通过IOSurfaceIncrementUseCount、IOSurfaceDecrementUseCount）。
• 使用CVMetalTextureCache。
  1. 创建CVMetalTextureCache：CVMetalTextureCacheCreate
  2. 通过向CVMetalTextureCache传入CVPixelBuffer创建CVMetalTexture：CVMetalTextureCacheCreateTextureFromImage
  3. 通过CVMetalTexture创建MTLTexture：CVMetalTextureGetTexture

参考

• WWDC20 10090 - 使用 AVFoundation 和 VideoToolBox 做视频处理 － 小专栏

设备帧率与分辨率在帧率大于30fps时，两者有着绑定关系，即不能自由设置。

低帧率模式（fps <= 30）

低帧率模式（fps <= 30）下，帧率和分辨率可以分别自由设置。即设置：

• AVCaptureSession的sessionPreset：设置分辨率及其预设格式。
• AVCaptureDevice的activeVideoMinFrameDuration、activeVideoMaxFrameDuration

高帧率模式（fps > 30）

高帧率模式（fps > 30）下，帧率不能自由设置，需要遍历设备支持的格式，在格式支持的帧率范围选择合适的帧率。为了统一操作，低帧率模式下也可以应用该设置方式。

1. 获取设备对象的formats数组，并进行遍历（也可以进一步获取其中的CMFormatDescription）：
   1. 获取Format的videoSupportedFrameRateRanges数组的首个元素。
   2. 比对AVFrameRateRange的maxFrameRate是否 >= 目标帧率，满足继续，否则跳过循环。
   3. 比对Format的formatDescription.dimensions是否满足要求，满足继续，否则跳过循环。
   4. 锁定设备进入配置：
      1. 设置AVCaptureDevice的activeFormat为当前Format对象；
      2. 设置AVCaptureDevice的activeVideoMinFrameDuration、activeVideoMaxFrameDuration为目标帧率。
   5. 解锁设备完成配置。

AVCaptureSession

排插，用于建立输入、输出图的关系。

提供操作：

• 预设配置
• 增删查输入、输出
• 增删查连接
• 开始、停止运行
• 开始、提交配置

使用注意：

• 方法调用应在一个独立的串行队列中进行，以防止影响主线程和实现同步操作。
• 中断通过通知进行监听。

AVCaptureDevice

采集设备硬件功能的封装。

使用注意：

• 使用硬件功能时，需要判断该功能是否可用；
• 修改设备配置前，需要调用lockForConfiguration进行锁定，以防止外界修改；对应的修改完毕后，调用unlockForConfiguration。

AVCaptureDeviceInput

采集设备作为输入的封装。需要封装成 Input 才能添加会话中。

使用注意：

• 切换设备其逻辑要包裹在AVCaptureSession的beginConfiguration和engdConfiguration中，需要根据设备创建Input，先移除后添加。

AVCaptureOutput

抽象输出类，其根据实际的目标数据的需求会有对应的具体类。 + StillImageOutput：静态图片输出 + 图片输出配置 + 拍照操作 + MovieFileOutput：音视频文件输出 + 文件大小限制 + 录制开始和停止操作 + AudioFileOutput：音频文件输出 + 音频格式配置 + 元数据存取 + AudioDataOutput：原始音频帧输出 + 音频格式配置 + VideoDataOutput：原始音频帧输出 + 视频格式配置 + MetadataOutput：元数据输出，可以实现二维码、人脸识别 + DepthDataOutput：深度数据输出

提供connection获取和坐标转换。具体的类通过不同的代理异步输出数据。

AVCaptureConnection

建立输入和输出的连接，用于控制数据流。只要Input和Output都添加到Session，则可以直接向Output获取Connection。否则需要手动建立连接。

可配置与设备硬件无关的软件处理：videoOrientation、videoScaleAndCropFactor、videoMirroring、videoStabilization。其他的参数需要配置AVCaptureDevice。

AVCaptureVideoPreviewLayer

可直接关联（强引用）AVCaptureSession实现预览。

采集案例

摄像头坐标转换

AVCaptureVideoPreviewLayer 提供摄像头坐标和屏幕坐标的转换方法：

// 屏幕坐标 -> 摄像头坐标
- (CGPoint)captureDevicePointOfInterestForPoint:(CGPoint)pointInLayer;

// 摄像头坐标 -> 屏幕坐标
- (CGPoint)pointForCaptureDevicePointOfInterest:(CGPoint)captureDevicePointOfInterest;

采集会话配置

1. 创建 AVCaptureSession；
2. 设置分辨率；
3. 使用 AVCaptureDevice 方法获取其对应类型的对象；
4. 为设备对象创建 Input；
5. 判断会话能否添加该 Input（因为有可能其他应用在使用该设备），是则添加；可将设备对象/input 存到属性，以备切换设备时做判断。
6. 创建 Output 对象，设置其格式。
7. 判断+添加。可以添加多个 Output。

开始与停止就是调用 Running 相关的方法。

直接 alpha

使用直接 alpha 描述 RGBA 颜色时，颜色的 alpha 值会存储在 alpha 通道中。例如，若要描述具有 60% 不透明度的红色，使用以下值：\((255, 0, 0, 255 × 0.6) = (255, 0, 0, 153)\)。其中153（\(153 = 255 × 0.6\)）指示颜色应具有 60% 的不透明度。

预乘 alpha

使用预乘 alpha 描述 RGBA 颜色时，每种颜色都会与 alpha 值相乘：\((255 × 0.6, 0 × 0.6, 0 × 0.6, 255 × 0.6) = (153, 0, 0, 153)\)。

预乘的好处：

• 混合时可以少一次乘法；
• 关键：只有预测的纹理才能进行Texture Filtering（除非使用最近邻插值）。使得带透明度的图片纹理可以正常进行线性插值。

对于直接alpha转换为预乘alpha的过程，要么预先使用工具进行处理，要么交由GPU处理。

视频或音频数据存储的2种格式packed和planar

假设有一路音频流，有左右两声道的数据。左声道用L表示，右声道用R表示。

存储时，如果是左右声道数据交替存储成一维数组，这种格式称为packed。格式为LRLRLR....LRLR

如果是分开存储成二维数组，这种格式称为planar。格式为LLLLLLLLLLLLLL和RRRRRRRRRRRRR

视频也是如此，但是对于YUV格式的数据，比音频多一种存储方法叫semi-planar，也就是半planar。一共2路存储，Y一路，UV一路，其中UV交叉存储。

视频播放器原理

视频播放器播放一个互联网上的视频文件，需要经过以下几个步骤：解协议，解封装，解码视音频，视音频同步。如果播放本地文件则不需要解协议，为以下几个步骤：解封装，解码视音频，视音频同步。他们的过程如图所示。

flowchart TB
流数据 --解协议--> 封装格式数据;
封装格式数据 --解封装--> 音频压缩数据 --音频解码--> 音频原始数据 --> 音视频同步 --> 视频驱动/设备;
封装格式数据 --解封装--> 视频压缩数据 --视频解码--> 视频原始数据 --> 音视频同步 --> 音频驱动/设备;

其中各个阶段的具体格式：

• 流数据/协议层：HTTP、RTMP、FILE……
• 封装格式：MKV、MP4、FLV、MPEG-TS、AVI……
• 压缩数据：H264、H265、MPEG2、AAC……
• 原始数据：YUV420P、YUV422P、RGB24、PCM……

解协议：将流媒体协议的数据，解析为标准的相应的封装格式数据。视音频在网络上传播的时候，常常采用各种流媒体协议，例如HTTP、RTMP或是MMS等等。这些协议在传输视音频数据的同时，也会传输一些信令数据。这些信令数据包括对播放的控制（播放，暂停，停止），或者对网络状态的描述等。解协议的过程中会去除掉信令数据而只保留视音频数据。例如，采用RTMP协议传输的数据，经过解协议操作后，输出FLV格式的数据。

解封装：将输入的封装格式的数据，分离成为音频流压缩编码数据和视频流压缩编码数据。封装格式种类很多，例如MP4，MKV，RMVB，TS，FLV，AVI等等，它的作用就是将已经压缩编码的视频数据和音频数据按照一定的格式放到一起。例如，FLV格式的数据，经过解封装操作后，输出H.264编码的视频码流和AAC编码的音频码流。

解码：将视频/音频压缩编码数据，解码成为非压缩的视频/音频原始数据。音频的压缩编码标准包含AAC，MP3，AC-3等等，视频的压缩编码标准则包含H.264，MPEG2，VC-1等等。解码是整个系统中最重要也是最复杂的一个环节。通过解码，压缩编码的视频数据输出成为非压缩的颜色数据，例如YUV420P，RGB等等；压缩编码的音频数据输出成为非压缩的音频抽样数据，例如PCM数据。

视音频同步：根据解封装模块处理过程中获取到的参数信息，同步解码出来的视频和音频数据，并将视频音频数据送至系统的显卡和声卡播放出来。

音视频压缩与传统数据压缩

无论是视频还是音频，在传统压缩算法看来，文件中基本么有什么冗余信息，音视频的压缩都是人们对音视频针对性开发压缩算法，去掉实际的冗余信息。

RTSP

该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP提供了一个可扩展框架，使实时数据，如音频与视频的受控、点播成为可能。数据源包括现场数据与存储在剪辑中的数据。该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、多播UDP与TCP提供途径，并为选择基于RTP上发送机制提供方法。

RTMP

RTMP是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据实时传输开发的开放协议，因为是开放协议所以都可以使用。

• RTMP协议用于对象、视频、音频的传输，这个协议建立在TCP协议或者轮询HTTP协议之上。
• RTMP协议就像一个用来装数据包的容器，这些数据可以是FLV中的视音频数据。一个单一的连接可以通过不同的通道传输多路网络流，这些通道中的包都是按照固定大小的包传输的。

HLS

HTTP Live Streaming 把整个流分成一个个基于 HTTP 的文件来下载，每次只下载一些。HLS 协议由三部分组成：HTTP（传输协议）、M3U8（索引文件）、TS（音视频媒体信息）。

编码格式要求：

• 视频编码格式：H264

• 音频的编码格式：AAC、MP3、AC-3

• 视频的封装格式：ts

• 保存 ts 索引的 M3U8 文件

优势：

• 相对于 RTMP 来讲使用了标准的 HTTP 协议来传输数据，可以避免在一些特殊的网络环境下被屏蔽

• 在服务端做负载均衡要简单。因为 HLS 是基于无协议的 HTTP 实现的，客户端只需要按照顺序下载存储在服务器的普通 ts 文件进行播放即可。而 RTMP 是一种有状态协议，很难对视频服务器进行平滑扩展，因为需要为每一个播放视频流的客户端维护状态。

• HLS 协议本身实现了码率自适应，在不同的带宽情况下，设备可以自动切换到最适合自己码率的视频播放。

劣势：

延迟，很难做到 10s 以下，而 RTMP 可以降到 3s~4s。

M3U8

• EXTM3U

  • 首行

• EXT-X-VERSION

  • 格式版本

• EXT-TARGETDURATION

  • 最大切片时长的四舍五入值

• EXT-X-MEDIA-SEQUENCE

  • 直播切片序列

• EXTINF

  • 每个切片时长
  • 下方为分片路径

• EXT-X-ENDLIST

  • 不会产生更多切片，该 M3U8 停止更新

• EXT-X-STREAM-INF

  • 多级 M3U8 文件，支持二级

  • 后接参数：

    • BANDWIDTH，最高码率值
    • AVERAGE-BANDWIDTH，平均码率值

  • 下面接子 M3U8 路径