Enki's Notes

macOS 开启 Web 服务器

2019-07-11T07:46:25.000Z

macOS 系统下自带了 Apache 和 PHP 环境，如果有需要的话，以下命令来控制服务器的启动、重启与停止：

# 启动 Apache 服务器
$sudo apachectl start
# 重启 Apache 服务器
$sudo apachectl restart
# 停止 Apache 服务器
$sudo apachectl stop

Apache 服务一些信息：

Web 跟目录在： /Library/WebServer/Documents
配置文件路径：/etc/apache2

将文件放至 Web 根目录下用户即可方法，服务的运行端口的配置都可以在 httpd.conf 找到配置项。

开启 PHP 模块：

找到并打开配置文件 /etc/apache2/httpd.conf
搜索 libphp 字样找到类似 #LoadModule php7_module libexec/apache2/libphp7.so 的配置项
去除前面的 # 字样来开启 PHP 模块
执行 sudo apachectl restart 命令来重启 Apache 服务器

mac 平台 git 命令自动补全

2019-06-05T01:19:37.000Z

安装 brew

如果有安装 brew 则跳过该步骤，执行如下命令进行安装：

1	$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

安装 bash-completion

执行 brew list 查看是否安装了 bash-completion 如果没有则执行以下命令进行安装：

1	$ brew install bash-completion

下载 git 源码

这里需要用到 git 仓库中一个文件，需要将 git clone 到本地，使用以下命令下载 git 仓库源码：

1	$ git clone https://github.com/git/git.git

下载完成后，需要将 contrib/completion/ 目录下的 git-completion.bash 文件复制到当前用户根目录下：

1	$ cp git-completion.bash ~/.git-completion.bash

配置环境

在 ~/.bash_profile 文件（如果没有则需要手动创建）中添加以下代码：

1
2
3

if [ -f ~/.git-completion.bash ]; then
  . ~/.git-completion.bash
fi

在 ~/.bashrc 文件（如果没有则需要手动创建）中添加以下内容：

1	source ~/.git-completion.bash

~/ 表示当前用户的根目录

重启终端后使用 tab 键来补全 git 命令。

方差、标准差、均方差、均方误差

2018-12-14T03:00:22.000Z

方差是在概率论和统计学中衡量随机变量或一组数据时离散程度的度量。概率论中方差用来度量随机变量和其数学期望（即均值）之间的偏离程度。统计中的方差（样本方差）是每个样本值与全体样本值的平均数之差的平方值的平均数。方差可以用来描述变量的波动程度。

方差在统计学和概率分布中各有不同的定义，并有不同的公式。在统计学中，方差用来计算每一个变量（观察值）与总体均数之间的差异。为避免出现离均差总和为零，离均差平方和受样本含量的影响，统计学采用平均离均差平方和来描述变量的变异程度。总体方差计算公式：

σ 的平方表示总体方差，X 表示变量，μ 表示总体的均值，N 表示总体样本数量。在实际项目中，总体均值难以得到时，应用样本统计量替代总体参数，经校正后，样本方差的计算公式：

σ 的平方表示样本方差，X 表示变量，{X_i … X_n} 表示样本均值，N 表示样本数量。之所以除以 N-1 而不是 N，是因为这样能使我们以较小的样本集更好地逼近总体的标准差，即统计上所谓的「无偏估计」。由于方差是数据的平方，与检测值本身相差太大，难以直观的衡量，所以常用方差开根号换算回来，就成了标准差（Standard Deviation）用 σ 表示，公式如下：

例如存在以下 python 代码:

import numpy as np 
data1 = [10, 30, 40, 50, 10]
data2 = [5, 20, 25, 80, 10]
print(np.mean(data1), np.var(data1), np.std(data1))
print(np.mean(data2), np.var(data2), np.std(data2))

输出结果：

1 2	28.0 256.0 16.0 28.0 726.0 26.94438717061496

可以看出两组数据的均值都是 28.0 但是方差以及标准差都是不一样，方差或标准差的值越大反应了数据波动就越大，反之则越稳定。

标准差在中文坏境中也被称为均方差，但不同于均方误差（mean squared error），均方误差是样本数据值偏离真实样本数据值的平方和的平均数，也即误差平方和的平均数，计算公式形式上接近方差，它的开方叫均方根误差，均方根误差才和标准差形式上接近。例如用 X 表示样本值，x 表示真实值，那么均方误差可用以下公式表示：

那么均分根误差可用以下公式表示：

在机器学习中均方误差可以用来作为模型的损失函数，用来预测和回归，均方误差越小，说明模型预测的越准确，反之则越不准确。总的来说，均方差是数据样本与均值的关系，而均方误差是数据样本与真实值之间的关系，在实际工作中根据需要来选择使用均方差还是均方误差。

同步 WebRTC 主仓库

2018-11-14T01:29:01.000Z

之前在 WebRTC iOS&OSX 库的编译介绍了如何下载和编译 WebRTC 的源码，但是很多时候可能只需要查看最新 WebRTC 的源码，并不需要下载庞大的第三方库以及编译依赖。

WebRTC 的仓库是使用 Git 来管理的，地址为 https://chromium.googlesource.com/external/webrtc/ 所以我们只需要 clone 到本地就好了（前提得备好梯子），如下命令：

1	git clone https://chromium.googlesource.com/external/webrtc

同步到本地后，你会发现只有 master、infra/config 以及 lkgr 几个分支，其中 master 是官方的主开发分支了，每天都有大量的代码提交，但并没有类似的 M70 的分支或者 tag。

我们可以修改仓库的 .git/config 文件，在 [remote "origin"] 节中添加以下内容：

1	fetch = +refs/branch-heads/:refs/remotes/origin/

修改后内容如下：

[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
        ignorecase = true
        precomposeunicode = true
[remote "origin"]
        url = https://chromium.googlesource.com/external/webrtc
        fetch = +refs/heads/*:refs/remotes/origin/*
        fetch = +refs/branch-heads/*:refs/remotes/origin/*
[branch "master"]
        remote = origin
        merge = refs/heads/master

之后就可以用 git branch -av 来查看远程分支了，当然也可以 checkout 到其他分支。

使用脚本自动同步至 GitHub

WebRTC 的更新还是非常频繁的，可以使用 python 脚本将自动同步至 GitHub 上，首先在自己的 GitHub 空间中创建用于存储 webrtc 的仓库，然后在 webrtc 源码目录下执行以下命令，用于关联 GitHub 仓库：

1	$ git remote add github git@github.com:xxxx/webrtc.git

这样 webrtc 就存在两个远程仓库，使用以下脚本来同步两个仓库，脚本如下：

#!/usr/bin/env python3
import os
import subprocess
import re
remote_repo = 'github'
webrtc_path = "xxxx"
def execute_shell(cmd):
    print('$ ' + cmd)
    (status, output) = subprocess.getstatusoutput(cmd)
    if (len(output) > 0):
        print(output)
    return (status, output)
def sync_tag(name, commit):
    execute_shell('git tag -a m%s %s -m m%s' % (name, commit, name))
    execute_shell('git push %s --tags' % (remote_repo))
def sync_branch(name, commit):
    execute_shell('git checkout -b ' + name + ' ' + commit)
    execute_shell('git checkout ' + name)
    execute_shell('git pull origin ' + name)
    execute_shell('git push ' + remote_repo + ' ' + name)
def sync_repo(path):
    os.chdir(path)
    execute_shell('git checkout master')
    execute_shell('git fetch')
    execute_shell('git pull origin')
    (status, output) = subprocess.getstatusoutput('git br -av')
    if status != 0:
        print('webrtc path error with code:', status)
        return None
    pattern = re.compile(r'remotes/origin/(\S+)\s+([a-zA-Z0-9]{10})\s+', re.M)
    results = pattern.findall(output)
    for (branch, commit) in results:
        sync_branch(branch, commit)
    execute_shell('git checkout master')
def main():
    sync_repo(webrtc_path)
if __name__ == '__main__':
    main()

脚本中的 remote_repo 就是指 GitHub 的远程仓库的名字，webrtc_path 就是 webrtc 源码目录，完成配置后，执行脚本就可以同步两个仓库了，这可能需要点时间。我已经在我的 GitHub 空间中进行了同步，有需要的自取。

Mac OSX 鼠标键盘事件的监听和模拟

2018-09-12T11:15:45.000Z

最近完成了 Mac OSX 平台下的远程控制功能，期间找了不少资料，这里做个总结，主要涉及到一下知识点：

OSX 的事件机制
OSX/iOS 响应链者链
鼠标事件的监听及模拟（鼠标单击、双击、拖动、滚动等事件）
键盘事件的监听及模拟（包括组合键的模拟）
Keycode 键盘编码（统一 Windows、OSX、浏览器端键盘按键的编码值）

事件分发机制

在 OSX 系统中鼠标和键盘的活动事件都会产生底层的系统事件，首先传递到 IOKit 框架处理后存储到队列中，通知 Window Server 服务层处理。Window Server 存储到 FIFO 优先队列中，然后逐一转发到当前活动窗口或者能响应这个事件的应用程序去处理。

在 OSX 或者 iOS 程序中，都会有一个 Main Run Loop 的线程，RunLoop 循环中会遍历 event 消息队列，逐一分发这些事件到应用中合适的对象去处理。具体来说就是调用 NSApp 的 sendEvent: 方法发送消息到NSWindow，NSWindow 再分发到 NSView 视图对象，由其鼠标或键盘事件响应方法去处理。

事件响应链

在 OSX 和 iOS 程序中响应者链是 Application Kit 事件处理架构的中心机制，它由一系列链接在一起的响应者对象组成，事件或者动作消息可以沿着这些对象进行传递。如果一个响应者对象不能处理某个事件或动作，也就是说，它不响应那个消息，或者不认识那个事件，则将该消息重新发送给链中的下一个响应者。消息沿着响应者链向上、向更高级别的对象传递，直到最终被处理（如果最终还是没有被处理，就会被抛弃）。

事件响应者 Responders 类为核心应用程序架构的三个主要模式或机制定义了一个接口：

它声明了一些处理事件消息（也就是源自用户事件的消息，比如象鼠标点击或按键按下这样的事件）的方法。
它声明了数十个处理动作消息的方法，它们和标准的键绑定（比如那些在文本内部移动插入点的绑定）密切相关。动作消息会被派发到目标对象；如果目标没有被指定，应用程序会负责检索合适的响应者。
它定义了一套在应用程序中指派和管理响应者的方法。这些响应者组成了我们所知道的响应者链，即一系列响应者，事件或动作消息在它们之间传递，直到找到能够对它们进行处理的对象。

当 Application Kit 在应用程序中构造对象时，会为每个窗口建立响应者链。响应者链中的基本对象是NSWindow 对象及其视图层次。在视图层次中级别较低的视图将比级别更高的视图优先获得处理事件或动作消息的机会。NSWindow 中保有一个第一响应者的引用，它通常是当前窗口中处于选择状态的视图，窗口通常把响应消息的机会首先给它。对于事件消息，响应者链通常以发生事件的窗口对应的 NSWindow 对象作为结束，虽然其它对象也可以作为下一个响应者被加入到 NSWindow 对象的后面。

从层级上看离观察者最近的视图优先响应事件，通过 view 的 hitTest 方法检测，满足 hitTest 方法的的子视图优先响应事件。

NSApplication, NSWindow, NSDrawer, NSWindowController, NSView 以及继承于 NSView 的所有控件对象都直接或间接继承了 Responders 类，所以这些类都能处理鼠标和键盘事件。

iOS 程序相比于 OSX 程序会有点不一样：

OSX 程序可能存在多个窗口，会有多个响应者链，iPhone 的应用程序就一个窗口，所以只会有一个响应者链。
在 iOS 程序中与加速计、陀螺仪和磁力计相关的运动事件不遵循响应者链，Core Motion 会将这些事件直接传递给我们指定的对象。有关更多信息，可以参看 Core Motion Framework。

事件的监听方法

鼠标键盘事件的监听有多种方法，第一种方法是重写事件响应者 Responders 对应的方法来获取对应的事件；第二是通过重写 NSWindow 的 sendEvent: 方法；第三是通过的 NSEvent 提供静态方法来监听对应的事件：

+ (nullable id)addGlobalMonitorForEventsMatchingMask:(NSEventMask)mask handler:(void (^)(NSEvent*))block`
+ (nullable id)addLocalMonitorForEventsMatchingMask:(NSEventMask)mask handler:(NSEvent* __nullable (^)(NSEvent*))block
+ (void)removeMonitor:(id)eventMonitor

NSEvent 提供的静态方法可以用监听整个系统的事件或者当前应用程序内的事件。全局事件是异步过程因此无法修改事件，应用程序内的消息可以在捕获到消息后，修改事件然后继续交由响应者链中下一个响应者处理。

鼠标事件监听

这里介绍鼠标的一下事件处理方法和注意事项：

左/右键的按下抬起事件
左键的双击（或者多击事件）
左键或者右键的拖拽事件
鼠标移动事件
鼠标的滚动事件

前面介绍了三种监听事件的方法，这里使用重写 Responders 的方法来监听鼠标事件：

- (void)mouseDown:(NSEvent *)event;
- (void)rightMouseDown:(NSEvent *)event;
- (void)mouseUp:(NSEvent *)event;
- (void)rightMouseUp:(NSEvent *)event;
- (void)mouseMoved:(NSEvent *)event;
- (void)mouseDragged:(NSEvent *)event;
- (void)rightMouseDragged:(NSEvent *)event;
- (void)scrollWheel:(NSEvent *)event;

鼠标按键的按下抬起事件，只要判断一下 NSEvent 的 type 属性即可知道。

当前鼠标的位置信息可通过 locationInWindow 属性来获取，该坐标是当前 Window 窗口的坐标，其中包含了 Window 窗口标题栏的高度，所以如果要想获取当前鼠标在当前 NSView 中的位置，需要做一次坐标转换，可以调用 NSView 的 convertPoint: 方法来转换坐标。

鼠标左键的 按下 - 抬起 两个连续的动作被定义为单击事件，clickCount 属于用于描述当前点击的次数。在模拟鼠标双击时，需要用到该字段值，而不能用连续两次点击事件来模拟双击。

监听鼠标的移动事件时需要设置一个跟踪区域，只有在跟踪区域内的鼠标移动事件才会触发。可以通过 NSView 的 - (void)addTrackingArea:(NSTrackingArea *)trackingArea 方法来设置跟踪区域。同时需要重写 - (void)updateTrackingAreas 方法，当跟踪区域发送改变时，需要手动将之前的跟踪区域移除，再添加新的跟踪区域。

鼠标的拖拽事件是指用户按下鼠标左键或右键移动鼠标，当拖拽事件发生时 mouseMoved: 事件将不会触发。

鼠标的滚动可以通过 deltaX 和 deltaY 两个属性来获取分别在水平方向和垂直方向的滚动偏移。

OSX 的坐标系统以左下角为 (0,0) 右上角为 (x_max, y_max)

键盘事件的监听

键盘事件的监听也使用重写事件响应者 Responders 对应的方法来实现，需要重写的方法如下：

1
2
3

- (void)keyDown:(NSEvent *)event;
- (void)keyUp:(NSEvent *)event;
- (void)flagsChanged:(NSEvent *)event;

键盘事件重写上述方法外还需要重写以下方法：

1	- (BOOL)acceptsFirstResponder;

该方法用来说明是否成为响应者链的第一个响应者，这里需要返回 YES 表示成为第一响应者，否则无法监听键盘消息。

NSEvent 的 characters 描述了当前键盘按键的字符，keyCode 描述了按键的值，每个按键的 keyCode 值定义可以在 Carbon/HIToolbox/Events.h 文件中找到对应的按键的宏定义。

在 keyDown: 和 keyUp: 方法中可以监听到大部分的按键的消息，但一些控制键需要通过 flagsChanged: 方法来处理，当 NSEventModifierFlags 定义的按键状态发送改变时，该方法就会被触发。这里需要注意的是大小写锁定键 NSEventModifierFlagCapsLock 只有当大写锁定或者取消锁定时，该方法才会被调用，并不会因为 CapsLock 按键按下或者抬起时触发。

keyCode 值在 Windows 和浏览器上都有对应的键盘按键的值的定义，当需要与其他平台进行通信时，例如远程控制时，可以将 Mac 下的 keyCode 值转换成浏览器 JS 上的对应值定义，因为浏览器和 Windows 平台的定义是一致的。

CGEventSourceKeyState(kCGEventSourceStateHIDSystemState, kVK_CapsLock) 方法可以用来获取按键是否处于按下状态。

鼠标键盘事件的模拟

OSX 下的鼠标和键盘事件模拟需要用到 CoreGraphics 及 Carbon 框架，在 CoreGraphics 框架中定义了一些用于创建底层事件的方法，Carbon 框架定义了一些跟键盘相关的宏和方法。

在模拟鼠标或者键盘事件时，都需要使用 CGEventSourceCreate(CGEventSourceStateID stateID) 方法来创建事件源，事件源类型定义了 3 个类型，如下：

typedef CF_ENUM(int32_t, CGEventSourceStateID) {
  kCGEventSourceStatePrivate = -1,
  kCGEventSourceStateCombinedSessionState = 0,
  kCGEventSourceStateHIDSystemState = 1
};

kCGEventSourceStatePrivate：代表专门的应用，如远程控制程序可以生成和跟踪事件源状态独立于其他进程。
kCGEventSourceStateCombinedSessionState：该状态表反映了所有事件源的组合状态发布到当前用户的登录会话。如果您的程序发布的事件在一个登录会话，您应该使用这个源状态当你创建一个事件源。
kCGEventSourceStateHIDSystemState：该状态表反映了组合硬件输入源从 HID 系统硬件层面发送的事件源。生成的事件。就是外接键盘或者 macbook 本机键盘以及一些系统定义的按键点击事件。

这里自己封装了鼠标事件、鼠标滚动事件及键盘事件的方法，需要引入及头文件

1. 模拟鼠标事件：

void PostMouseEvent(CGMouseButton button, CGEventType type, const CGPoint &point, int64_t clickCount)
{
    CGEventSourceRef source = CGEventSourceCreate(kCGEventSourceStatePrivate);
    CGEventRef theEvent = CGEventCreateMouseEvent(source, type, point, button);
    CGEventSetIntegerValueField(theEvent, kCGMouseEventClickState, clickCount);
    CGEventSetType(theEvent, type);
    CGEventPost(kCGHIDEventTap, theEvent);
    CFRelease(theEvent);
    CFRelease(source);
}

左键单击模拟：

1 2	PostMouseEvent(kCGMouseButtonLeft, kCGEventLeftMouseDown, CGPointZero, 1); PostMouseEvent(kCGMouseButtonLeft, kCGEventLeftMouseUp, CGPointZero, 1);

左键双击模拟：

PostMouseEvent(kCGMouseButtonLeft, kCGEventLeftMouseDown, CGPointZero, 1);
PostMouseEvent(kCGMouseButtonLeft, kCGEventLeftMouseUp, CGPointZero, 1);
PostMouseEvent(kCGMouseButtonLeft, kCGEventLeftMouseDown, CGPointZero, 2);
PostMouseEvent(kCGMouseButtonLeft, kCGEventLeftMouseUp, CGPointZero, 2);

拖拽事件： 如果是拖拽事件，例如左键拖拽事件，则需要先发送左键的 kCGEventLeftMouseDown 事件，然后连续发送 kCGEventLeftMouseDragged 事件，再发送 kCGEventLeftMouseUp 事件，代码如下：

PostMouseEvent(kCGMouseButtonLeft, kCGEventLeftMouseDown, CGPointZero, 1);
PostMouseEvent(kCGMouseButtonLeft, kCGEventLeftMouseDragged, CGPointZero, 1);
...
PostMouseEvent(kCGMouseButtonLeft, kCGEventLeftMouseDragged, CGPointZero, 1);
PostMouseEvent(kCGMouseButtonLeft, kCGEventLeftMouseUp, CGPointZero, 1);

模拟其他鼠标事件，将枚举值修改一下即可。

2. 模拟鼠标滚动事件

void PostScrollWheelEvent(int32_t scrollingDeltaX, int32_t scrollingDeltaY)
{
    CGEventSourceRef source = CGEventSourceCreate(kCGEventSourceStatePrivate);
    CGEventRef theEvent = CGEventCreateScrollWheelEvent(source, kCGScrollEventUnitPixel, 2, scrollingDeltaY, scrollingDeltaX);
    CGEventPost(kCGHIDEventTap, theEvent);
    CFRelease(theEvent);
    CFRelease(source);
}

鼠标滚轮事件只要传入水平和垂直方向的偏移即可实现。

3. 模拟键盘事件

void PostKeyboardEvent(CGKeyCode virtualKey, bool keyDown, CGEventFlags flags)
{
    CGEventSourceRef source = CGEventSourceCreate(kCGEventSourceStatePrivate);
    CGEventRef push = CGEventCreateKeyboardEvent(source, virtualKey, keyDown);
    CGEventSetFlags(push, flags);
    CGEventPost(kCGHIDEventTap, push);
    CFRelease(push);
    CFRelease(source);
}

键盘事件的模拟需要注意的就是 CGEventFlags flags 参数，该参数用来模拟组合键的实现，类型定义如下：

typedef CF_OPTIONS(uint64_t, CGEventFlags) { /* Flags for events */
  /* Device-independent modifier key bits. */
  kCGEventFlagMaskAlphaShift =          NX_ALPHASHIFTMASK,
  kCGEventFlagMaskShift =               NX_SHIFTMASK,
  kCGEventFlagMaskControl =             NX_CONTROLMASK,
  kCGEventFlagMaskAlternate =           NX_ALTERNATEMASK,
  kCGEventFlagMaskCommand =             NX_COMMANDMASK,
  /* Special key identifiers. */
  kCGEventFlagMaskHelp =                NX_HELPMASK,
  kCGEventFlagMaskSecondaryFn =         NX_SECONDARYFNMASK,
  /* Identifies key events from numeric keypad area on extended keyboards. */
  kCGEventFlagMaskNumericPad =          NX_NUMERICPADMASK,
  /* Indicates if mouse/pen movement events are not being coalesced */
  kCGEventFlagMaskNonCoalesced =        NX_NONCOALSESCEDMASK
};

解析如下：

kCGEventFlagMaskAlphaShift：大小写锁定键是否处于开启状态
kCGEventFlagMaskShift：Shift 键是否按下
kCGEventFlagMaskControl：Control 键是否按下
kCGEventFlagMaskAlternate：Alt 键是否按下，对应 Mac 键盘的 option 键
kCGEventFlagMaskCommand：Command 键是否按下，对应 Windows 的 WIN 键
kCGEventFlagMaskHelp：Help 键
kCGEventFlagMaskSecondaryFn：Fn 键
kCGEventFlagMaskNumericPad：数字键盘
kCGEventFlagMaskNonCoalesced：没有任何键按下

如果有多个控制键同时按下，则使用位运算的或 | 加上对应的键值即可。例如模拟 Command + Control + S:

1 2	PostKeyboardEvent(kVK_ANSI_S, true, kCGEventFlagMaskCommand \| kCGEventFlagMaskControl) PostKeyboardEvent(kVK_ANSI_S, false, kCGEventFlagMaskNonCoalesced)

大小写锁定键，无法通过 kVK_CapsLock 按键的按下和抬起事件来模拟大小键的锁定，同时按键上的 LED 灯也是不会有变化的。

参考资料

H264/SVC Temporal Scalability

2018-05-23T09:46:10.000Z

在多人远程会议或直播系统中，参与的用户可能处于不同的网络环境（有线、Wifi、3G、4G）中，网络质量各不一致，为了所有用户可进行远程会议或者直播的观看，简单的做法就是降低发送端的视频码流，这样不管网络质量好坏，参与的用户都将观看低码率的视频流。这种方案缺点在于大部分网络较好的用户会被少数的网络较差的用户给拖累。这里介绍 H264 编码器中的 Temporal Scalability 机制来优化该方案。

Temporal Scalability 是 H264/SVC 编码器中的概念，意思为时间上可伸缩的，在实际编码中编码器进行了分层编码，可简单的理解为 编码器对同一组输入的数据进行编码，可以输出不同帧率的码流，例如当前编码器输入帧率为 30fps 的流，编码器可同时输出多个码流，例如同时输出 3 层码流，从而可以得到不同帧率的码流。

这里的 3 层码流是有依赖关系，比如输出有 A、B、C 3 层码流，单独的发送 A 层则得到低帧率的码流例如 5fps，如果同时发送 A 和 B 两层码流，则能得到相对较高的码流例如 15fps，如果同时发送 ABC ，则能得到最高的码流例如 30fps。

在具体应用中便可以根据用户的网络质量来分配不同码率的视频流，这样网络质量较好的用户能看到高帧率的视频流，而网络较差的用户则看到低帧率的视频流。如下图所示：

在 H264/SVC 编码器中进行了分层编码，例如上图描述编码端同时将所有的码流层发送至服务器，如果用户网络质量非常好，服务器将所有层的码流数据转发至该用户例如 Receiver2；如果用户网络非常差，则只需要将低层级码流数据转发给该用户例如 Receiver1。实际项目中可根据接收端带宽情况，转发对应码率的流即可。

编码器的支持

Temporal Scalability 机制并不是所有的编码都支持的，Apple 平台下（包括iOS和MacOS）的硬件编解码框架 VideoToolbox 是不支持的该特性的，因为没有看到任何的可设置的参数或者 API 接口。Android 平台下硬件编解码框架 MediaCodec 在 API 21 一下是不支持的，在 API 21 时添加了对 KEY_TEMPORAL_LAYERING 编码属性的配置，但只支持 VP8 编码格式 H264 编码格式不支持（毕竟 Android 和 VPx 都是属于 Google 的产品）。Android 下有需要了解详情的可以查看 MediaFormat 类的说明。

在两大主流的移动平台上，硬件编码器都是不支持 H264/SVC Temporal Scalability 特性，如果要在移动平台上使用该特性只能使用软编码器，可以使用开源的 openh264 编解码库，代码托管在 GitHub 上对应的地址为 openh264 ，其中有该项目的介绍和使用方法。

x264 编码器当前还不支持 Temporal Scalability 特性。

在 openh264 中使用 SEncParamExt 结构体来对编码进行参数的配置，Temporal Scalability 的特性使用 iTemporalLayerNum 字段来配置，用来指定输出多少层，这里最大只支持 4 层。

使用 EncodeFrame 方法进行 H264 的编码后可以得到 SFrameBSInfo 的输出结果，该结构体以及关联的结构体的定义如下：

typedef struct {
  int           iLayerNum;
  SLayerBSInfo  sLayerInfo[MAX_LAYER_NUM_OF_FRAME];
  EVideoFrameType eFrameType;
  int iFrameSizeInBytes;
  long long uiTimeStamp;
} SFrameBSInfo, *PFrameBSInfo;
typedef struct {
  unsigned char uiTemporalId;
  unsigned char uiSpatialId;
  unsigned char uiQualityId;
  EVideoFrameType eFrameType;
  unsigned char uiLayerType;
  int   iSubSeqId;
  int   iNalCount;
  int*  pNalLengthInByte;
  unsigned char*  pBsBuf;
} SLayerBSInfo, *PLayerBSInfo;

在 SLayerBSInfo 结构体的 uiTemporalId 字段用来描述当前编码后的数据流属于哪一层。openh264 的使用可查看其它文档。

openh264 对 H264/SVC 的支持，不仅在时间维度上，并且也在空间和质量维度上都有支持。

openh264 中 temporal layer 的输出顺序与帧率

在 openh264 的内部，存在一张表，用来记录每一层的输出顺序，可以在 encoder_data_tables.cpp 中找到内容如下：

const uint8_t   g_kuiTemporalIdListTable[MAX_TEMPORAL_LEVEL][MAX_GOP_SIZE + 1] = {
  {
    0, 0, 0, 0, 0, 0, 0, 0,
    0
  },  // uiGopSize = 1
  {
    0, 1, 0, 0, 0, 0, 0, 0,
    0
  },  // uiGopSize = 2
  {
    0, 2, 1, 2, 0, 0, 0, 0,
    0
  },  // uiGopSize = 4
  {
    0, 3, 2, 3, 1, 3, 2, 3,
    0
  }  //uiGopSize = 8
};

解析如下：

iTemporalLayerNum 的值为 1 时，使用 uiGopSize = 1 的配置，即每一帧为一组，每一组的 uiTemporalId 值为 0
iTemporalLayerNum 的值为 2 时，使用 uiGopSize = 2 的配置，即每两帧为一组，每一组中对应的
uiTemporalId 为 [0, 1]
iTemporalLayerNum 的值为 3 时，使用 uiGopSize = 4 的配置，即每四帧为一组，每一组中对应的
uiTemporalId 为 [0, 2, 1, 2]
iTemporalLayerNum 的值为 4 时，使用 uiGopSize = 8 的配置，即每 8 帧为一组，每一组中对应的
uiTemporalId 为 [0, 3, 2, 3, 1, 3, 2, 3]

根据上述描述以及输入的帧率可计算每一层的帧率是多少，例如在 30fps 下分两层输出，则 T0 帧率为 15fps；分 3 层时，每 4 帧组则有完整 7 组，则 T0 的帧率有 7 + 1 = 8fps，T1 的帧率有 8 + 7 = 15fps，T2 则有 30fps；分 4 层的情况可按相同的方法计算每一层的帧率。

RTP 数据包的封装

Temporal Scalability 属于 H264/SVC 的范畴，在封装成 RTP 包时也有对应的标准做法，但流程相对复杂，有兴趣的同学可以了解以下资料：

大致的思想是将基本层（低帧率）和增强层（高帧率）的层通过不同的 payload 分开传输，同时两个通道分别使用不同的 QoS 机制来保证传输的质量。

除了上述的较为复杂的做法外也可以使用 RTP 的扩展头来实现，在 RTP 头后面添加一个扩展头用来描述当前数据包的 temporal layer id，这样服务器就能区分 RTP 包分别属于哪个层级，从而根据客户端的网络质量来转发不同的帧率的码流。具体的做法可参考其他资料。

总结

H264/SVC 是以 H264/AVC 为基础，利用了AVC 编解码器的各种高效算法工具，在语法和工具集上进行了扩展，所以 H264/SVC 时间可扩展性完全向后兼容 H.264/AVC，即当使用 SVC 编码出多层的码流时，AVC 的编码器也是可以正常解码的。当 Temporal Scalability 帧率降低一半时，比特率通常不会降低一半，因为低层级的帧可能是其他高层级帧的参考帧，编码器会为其分配更多的码流。

由于编码端到服务器以及服务器到接收端的码流有了更灵活的传输方式，结合网络上其他的优化方案，可以衍生出更多的优化方案，例如针对低层级的丢包重传、缓存低层级的帧等。

可惜的是在 iOS 和 Android 两大主流移动平台上，对应的硬件编码器都不支持该特性，不过在分辨率不高的场景下还是可以尝试使用软编码器来实现的。一些时候用户更偏向于接受低分辨率的图像而需要更流畅的画面，这时候 Temporal Scalability 机制并不能达到要求，后续将介绍 H264/SVC 中的空间分层来解决该问题。

参考资料

Apple 平台下的 VideoToolBox 框架

2018-03-24T05:17:16.000Z

VideoToolBox 是一个低级的框架，可直接访问硬件的编解码器。它能够为视频提供压缩和解压缩的服务，同时也提供存储在 CoreVideo 像素缓冲区的图像进行格式的转换。该框架在 iOS(8.0)/macOS(10.8)/tvOS(10.2) 以后才被开放出来，在这之前都是不能使用的。

VideoToolBox 框架为我们提供的接口都是以 C 语言函数形式提供的，并且以会话 Session 方式来进行管理，这些接口分为以下几个类别：

VTCompressionSession：提供数据压缩的会话
VTDecompressionSession：提供数据解压缩的会话
VTPixelTransferSession：提供数据格式转换的会话
VTMultiPassStorage&VTFrameSilo：提供多通道压缩的会话
VTSession&Utilities：针对会话的管理以及辅助的函数

这里主要针对 VTCompressionSession 以及 VTDecompressionSession 两个方面的介绍。由于 VideoToolBox 可进行多种格式的压缩以及解压缩，下文都是以 H264 编码格式进行介绍和举例。

VTCompressionSession 编码器

编码器的使用主要有以下四个流程：

使用 VTCompressionSessionCreate 函数来创建编码器的 session。
使用 VTSessionSetProperty 方法来对编码器进行配置。
使用 VTCompressionSessionEncodeFrame 方法来进行数据的编码，并在回调函数中进行编码后的数据处理。
使用 VTCompressionSessionCompleteFrames 来完成数据的编码。
最后使用 VTCompressionSessionInvalidate 以及 CFRelease 来释放资源和内存。

编码器的创建

OSStatus VTCompressionSessionCreate(
	CFAllocatorRef allocator, 
	int32_t width, int32_t height, 
	CMVideoCodecType codecType, 
	CFDictionaryRef encoderSpecification, 
	CFDictionaryRef sourceImageBufferAttributes, 
	CFAllocatorRef compressedDataAllocator, 
	VTCompressionOutputCallback outputCallback, 
	void *outputCallbackRefCon, 
	VTCompressionSessionRef  _Nullable *compressionSessionOut);

参数介绍：

CFAllocatorRef allocator：内存的构造器，默认传递 NULL 即可
int32_t width, int32_t height：指定编码器的宽高，传入源数据的宽高即可
CMVideoCodecType codecType：编码器的类型，H264 使用 kCMVideoCodecType_H264 或者 avc1 字符
CFDictionaryRef encoderSpecification：编码规范，传递 NULL 让 VideoToolbox 选择
CFDictionaryRef sourceImageBufferAttributes：设置源图像缓冲区属性
CFAllocatorRef compressedDataAllocator：指定一个编码后数据的构造器，传递 NULL 即可
VTCompressionOutputCallback outputCallback：数据编码后的回调接口
void *outputCallbackRefCon：回调函数的自定义参数
VTCompressionSessionRef _Nullable *compressionSessionOut：输出参数，构造好的编码器 Session

编码器的参数配置

编码器的参数是多维度的，都是可以单独的配置，使用下面的函数进行编码器的参数配置：

OSStatus VTSessionSetProperty(
	VTSessionRef session, 
	CFStringRef propertyKey, 
	CFTypeRef propertyValue);

参数介绍：

VTSessionRef session：编码器
CFStringRef propertyKey：属性字段的 Key
CFTypeRef propertyValue：属性的值

可配置的属性有多种类型如下：

流配置

kVTCompressionPropertyKey_Depth：编码器颜色的像素深度，例如 16 位 RGB 或者 24 位 RGB
kVTCompressionPropertyKey_ProfileLevel：编码比特流的配置文件和级别
kVTCompressionPropertyKey_H264EntropyMode：H.264 压缩的熵编码模式，可以设置为 CAVLC 或者 CABAC

更改默认熵模式可能导致与请求的配置文件和级别不兼容的配置。在这种情况下的结果是未定义的，可能包括编码错误或不合规的输出流。

缓冲区配置

kVTCompressionPropertyKey_NumberOfPendingFrames：压缩会话中待处理帧的数量
kVTCompressionPropertyKey_PixelBufferPoolIsShared：指示公共像素缓冲池是否在视频编码器和会话客户端之间共享
kVTCompressionPropertyKey_VideoEncoderPixelBufferAttributes

预期值配置

kVTCompressionPropertyKey_ExpectedDuration：压缩会话的预期总持续时间（如果已知）
kVTCompressionPropertyKey_ExpectedFrameRate：预期的帧速率，如果知道的话
kVTCompressionPropertyKey_SourceFrameCount：源 frame 的数量，如果已知

帧相关

kVTCompressionPropertyKey_AllowFrameReordering：指示是否启用了帧重新排序
kVTCompressionPropertyKey_AllowTemporalCompression：指示是否启用时间压缩
kVTCompressionPropertyKey_MaxKeyFrameInterval：关键帧之间的最大间隔，也称为关键帧速率。
kVTCompressionPropertyKey_MaxKeyFrameIntervalDuration：从几个关键帧到下一个关键帧的最长持续时间
kVTEncodeFrameOptionKey_ForceKeyFrame：指示当前帧是否被强制为关键帧

硬件加速

kVTCompressionPropertyKey_UsingHardwareAcceleratedVideoEncoder：指示是否使用硬件加速视频编码器
kVTVideoEncoderSpecification_RequireHardwareAcceleratedVideoEncoder：指示是否需要硬件加速编码
kVTVideoEncoderSpecification_EnableHardwareAcceleratedVideoEncoder：指示是否允许硬件加速视频编码

码率控制

kVTCompressionPropertyKey_AverageBitRate：期望的平均比特率，以比特/秒为单位
kVTCompressionPropertyKey_DataRateLimits：
kVTCompressionPropertyKey_MoreFramesAfterEnd：指示压缩会话的帧是否以及如何与其他压缩帧连接以形成更长的序列
kVTCompressionPropertyKey_MoreFramesBeforeStart：指示压缩会话的帧是否以及如何与其他压缩帧连接以形成更长的序列
kVTCompressionPropertyKey_Quality：所需的压缩质量，该值应该被指定为 0.0 到 1.0 的范围，其中 low = 0.25，normal = 0.50，high = 0.7 5和 1.0 表示支持编码器的无损压缩

运行时

kVTCompressionPropertyKey_RealTime：表示是否建议视频编码器实时执行压缩
kVTCompressionPropertyKey_MaxH264SliceBytes：H.264编码的最大片大小
kVTCompressionPropertyKey_MaxFrameDelayCount：在压缩器必须输出压缩帧之前允许压缩器保持的最大帧数

以上参数并不是都要设置，保持默认值即可。

数据的编码

在进行数据的编码之前，可手动调用下面的方法来申请必要的资源，如果不手动调用，则会在第一次进行数据编码时自动调用：

1	OSStatus VTCompressionSessionPrepareToEncodeFrames(VTCompressionSessionRef session);

该函数调用一次之后，后续的调用将是无效的调用。使用一下方法来进行数据的编码：

OSStatus VTCompressionSessionEncodeFrame(
	VTCompressionSessionRef session, 
	CVImageBufferRef imageBuffer, 
	CMTime presentationTimeStamp, 
	CMTime duration, 
	CFDictionaryRef frameProperties, 
	void *sourceFrameRefCon, 
	VTEncodeInfoFlags *infoFlagsOut);

参数解析：

VTCompressionSessionRef session：编码器的 session
CVImageBufferRef imageBuffer：待编码的数据
CMTime presentationTimeStamp：待编码数据时间戳。当前时间戳必须大于前一个
CMTime duration：待编码数据的持续时间（画面的持续时间），可传入 kCMTimeInvalid
CFDictionaryRef frameProperties：指定编码当前帧属性的键/值对。一些属性将会影响后续的编码帧
void *sourceFrameRefCon：传递给回调函数的自定义数据
VTEncodeInfoFlags *infoFlagsOut：

当需要主动停止编码时，可调用下面方法来强制停止编码器：

1
2
3

OSStatus VTCompressionSessionCompleteFrames(
	VTCompressionSessionRef session, 
	CMTime completeUntilPresentationTimeStamp);

编码器资源释放与销毁

编码器的销毁需要调用一下两个方法来进行

1	void VTCompressionSessionInvalidate(VTCompressionSessionRef session);

该方法用来释放编码器占用的内存资源，在调用一下方法来释放 session 本身的内存资源：

1	void CFRelease(CFTypeRef cf);

VTDecompressionSession 解码器

解码器的使用与编码器类似，大致流程如下：

使用 VTDecompressionSessionCreate 方法来创一个解码器。
使用 VTSessionSetProperty 或者 VTSessionSetProperties 来对解码器进行配置。
使用 VTDecompressionSessionDecodeFrame 来进行数据的解码。
使用 VTDecompressionSessionInvalidate 以及 CFRelease 来对资源的释放。

解码器的创建

OSStatus VTDecompressionSessionCreate(
	CFAllocatorRef allocator, 
	CMVideoFormatDescriptionRef videoFormatDescription, 
	CFDictionaryRef videoDecoderSpecification, 
	CFDictionaryRef destinationImageBufferAttributes, 
	const VTDecompressionOutputCallbackRecord *outputCallback, 
	VTDecompressionSessionRef  _Nullable *decompressionSessionOut);

参数介绍：

CFAllocatorRef allocator：构造器，传 NULL 即可
CMVideoFormatDescriptionRef videoFormatDescription：源数据的格式设置
CFDictionaryRef videoDecoderSpecification：解码器的规范，可使用 NULL 让 VideoToolbox 自动选择
CFDictionaryRef destinationImageBufferAttributes：缓冲区配置，NULL 保存默认即可
const VTDecompressionOutputCallbackRecord *outputCallback：用来配置解码后的回调函数以及自定义数据
VTDecompressionSessionRef _Nullable *decompressionSessionOut：输出参数用来存储解码器的 session

解码器的参数配置

OSStatus VTSessionSetProperty(
	VTSessionRef session, 
	CFStringRef propertyKey, 
	CFTypeRef propertyValue);

参数介绍：

VTSessionRef session：编码器
CFStringRef propertyKey：属性字段的 Key
CFTypeRef propertyValue：属性的值

可配置的选项：

解码器行为

kVTDecompressionPropertyKey_RealTime：设置解码器是否实时解码数据

数据的解码

OSStatus VTDecompressionSessionDecodeFrame(
	VTDecompressionSessionRef session, 
	CMSampleBufferRef sampleBuffer, 
	VTDecodeFrameFlags decodeFlags, 
	void *sourceFrameRefCon, 
	VTDecodeInfoFlags *infoFlagsOut);

参数介绍：

VTDecompressionSessionRef session：解码器的 session
CMSampleBufferRef sampleBuffer：包含一个或者多个待解码帧的 buffer
VTDecodeFrameFlags decodeFlags：设置标记为，来影响解码器的解码行为，可传 0
void *sourceFrameRefCon：传递给回调函数的自定义数据
VTDecodeInfoFlags *infoFlagsOut：输出参数，解码的一些标志位，可传 NULL

VTDecodeFrameFlags 与 VTDecodeInfoFlags 的定义如下：

typedef CF_OPTIONS(uint32_t, VTDecodeFrameFlags) {
	kVTDecodeFrame_EnableAsynchronousDecompression = 1<<0,
	kVTDecodeFrame_DoNotOutputFrame = 1<<1,
	kVTDecodeFrame_1xRealTimePlayback = 1<<2, 
	kVTDecodeFrame_EnableTemporalProcessing = 1<<3,
};
typedef CF_OPTIONS(UInt32, VTDecodeInfoFlags) {
	kVTDecodeInfo_Asynchronous = 1UL << 0,
	kVTDecodeInfo_FrameDropped = 1UL << 1,
	kVTDecodeInfo_ImageBufferModifiable = 1UL << 2,
};

解码器的资源释放以及销毁

解码器的资源释放与销毁也编码器类似，依次调用下面两个方法：

1 2	void VTDecompressionSessionInvalidate(VTDecompressionSessionRef session); void CFRelease(CFTypeRef cf);

基本数据类型

CVPixelBuffer：编码前和解码后的图像数据结构。
CMBlockBuffer：编码后 NALU 数据结构。
pixelBufferAttributes：字典设置.可能包括Width/height、pixel format type、• Compatibility (e.g., OpenGL ES, Core Animation)
CMVideoFormatDescription：图像存储方式，编解码器等格式描述。
CMSampleBuffer：存放编解码前后的视频图像的容器数据结构。
CMTime：时间戳相关。时间以 64-bit/32-bit 的形式出现。

CVPixelBuffer

CVPixelBufferRef 是 Core Video 框架中定义的数据类型，用来描述一张图片的内存空间，它的定义可以从 API 文档或者头文件中可以查找到定义如下：

1 2	typedef CVImageBufferRef CVPixelBufferRef; typedef CVBufferRef CVImageBufferRef;

而 CVBufferRef 本质上就是一个 void * 的指针，至于 void * 具体是什么样的数据类型，则只有系统才知道，我们则不需要关心。CVPixelBufferRef 描述了一张图片的内存空间，对于该图片的属性可以通过对应的 C 语言函数来获得，例如图片的宽、高、图片的格式通过以下函数来获取：

1
2
3

size_t CVPixelBufferGetWidth(CVPixelBufferRef pixelBuffer);
size_t CVPixelBufferGetHeight(CVPixelBufferRef pixelBuffer);
OSType CVPixelBufferGetPixelFormatType(CVPixelBufferRef pixelBuffer);

CVPixelBufferRef中的图片格式可以有 RGB 或者 YUV 的格式，这两种图片格式都可以有多种模式，对于 RGB 以及 YUV 可以参考之前的文章。

对于 YUV 格式的处理，可以先通过 Boolean CVPixelBufferIsPlanar(CVPixelBufferRef pixelBuffer); 函数来判断是否为 Planar 模式。若是 Planar，则通过 size_t CVPixelBufferGetPlaneCount(CVPixelBufferRef pixelBuffer); 获取 YUV Plane 数量，然后由 `void CVPixelBufferGetBaseAddressOfPlane(CVPixelBufferRef pixelBuffer, size_t planeIndex);* 得到相应的通道的存储地址。在进行编码时从摄像头采集的数据就已经是CVPixelBufferRef格式的数据了，只需要将该数据传入编码器即可。对于解码器输出的就是YUV格式的CVPixelBufferRef的数据。对于后续的渲染可以将YUV转成RGB模式进行渲染，也可以将CVPixelBufferRef转成OpenGL所需要的texture然后进行渲染。也可以转成CIImage或者UIImage` 对象进行处理。

CMBlockBuffer

与 CVPixelBufferRef 类似 CMBlockBufferRef 也是对内存块的封装描述，在 H264 编码器中用来存储编码后的图像数据，通常是一系列的 nalu 数据。CMBlockBufferRef 管理的内存可以是不连续的内存块，也可能是对其他内存的引用，而 CMBlockBufferRef 隐藏了这些细节，通过对应的函数来对内存进行操作，比如追加内存，获取内存数据等。相关的操作函数可查看 API 文档。

CMSampleBuffer

编解码前后的视频图像均封装在 CMSampleBuffer 中，如果是编码后的图像，以 CMBlockBuffe 方式存储；解码后的图像，以 CVPixelBuffer 存储。CMSampleBuffer 里面还有另外的时间信息 CMTime 和视频描述信息 CMVideoFormatDesc

参考资料

C++ 实现的 Dispatch Queue

2018-03-10T11:35:45.000Z

iOS/Mac 平台下 apple 提供了非常好用的 dispatch_queue 能够很方便的进行线程的管理以及各个线程之间的切换（当然还有很多其他特性）。虽说 C++ 的标准库中提供了很多线程管理的方法，但相比于 dispatch_queue 还是弱爆了。由于项目中会经常用到，GitHub 上找了一些类似的实现都不太理想，于是自己实现了一版简单的主要支持一下特性：

支持并发调用，并支持并发的任务处理
支持任务的同步执行和异步执行
可创建指定数量的任务线程
执行同步任务时，在任务线程中可继续执行同步任务而不卡死
同一任务可重复执行
支持 lambda 表达式
支持任务线程的安全退出

结构设计

上图是 DispatchQueue 类结构图，结构比较简单，DispatchQueue 是核心抽象类；QueueTask 就是任务的抽象基类了，ClosureTask 类是一个模板类，主要用来实现 lambda 表达式；DisruptorImp 与 MutexQueueImp 则是两个具体的 DispatchQueue 的实现，disruptor 包是一个第三方库，后面会有详细介绍，。

DispatchQueue 抽象类的定义

以下是 DispatchQueue 接口的定义和实现：

class DispatchQueue {
public:
    DispatchQueue(int thread_count) {}
    
    virtual ~DispatchQueue() {}
    
    template ::value>::type* = nullptr>
    void sync(const T &task) {
        sync(std::shared_ptr(new ClosureTask(task)));
    }
    
    void sync(std::shared_ptr task) {
        if( nullptr != task ) {
            sync_imp(task);
        }
    }
    
    template ::value>::type* = nullptr>
    int64_t async(const T &task) {
        return async(std::shared_ptr(new ClosureTask(task)));
    }
    
    int64_t async(std::shared_ptr task) {
        if ( nullptr != task ) {
            return async_imp(task);
        }
        return -1;
    }
    
protected:
    virtual void sync_imp(std::shared_ptr task) = 0;
    
    virtual int64_t async_imp(std::shared_ptr task) = 0;
};

DispatchQueue 是基于建造者模式进行设计，将同步方法、异步方法对 lambda 表达式的支持，放在父类中实现，因为这部分代码相对固定，而具体的同步与异步的实现都推迟到子类中实现，因为这部分可以有不同的实现方式。抽象的父类相对简单，只实现了对 lambda 的支持，在来看看 QueueTask 的类设计如下：

class QueueTask {
public:
    QueueTask() : _signal(false) {}
    virtual ~QueueTask() {}
    
    virtual void run() = 0;
    virtual void signal() {
        _signal = true;
        _condition.notify_all();
    }
    virtual void wait() {
        std::unique_lock  lock(_mutex);
        _condition.wait(lock, [this](){ return _signal; });
        _signal = false;
    }
    
    virtual void reset() {
        _signal = false;
    }
private:
    bool _signal;
    std::mutex _mutex;
    std::condition_variable _condition;
};
template 
class ClosureTask : public QueueTask {
public:
    explicit ClosureTask(const T& closure) : _closure(closure) {}
private:
    void run() override {
        _closure();
    }
    T _closure;
};

virtual void run() = 0 是纯虚函数用来给子类重载，signal()/wait() 是两个具体方法用来支持任务的同步执行，在生产线程中执行 wait() 方法用来等待当前任务执行完成，而在任务线程中 QueueTask 执行完成后会调用 signal 来通知生产线程完成等待。reset 方法可以让该任务执行完成后重置内部状态，以便可继续将当前任务添加都队列中。ClosureTask 模板类则用来包装 lambda 表达式。

基于 std::mutex/std::queue 的实现

基于标准库实现的思路很简单，使用标准库中提供的 std::mutex 和 std::queue ，在进行插入任务和执行任务时，对任务队列进行加锁操作，这里使用递归锁 std::recursive_mutex 而非 std::mutex。具体实现代码如下：

class MutexQueueImp : public DispatchQueue {
public:
    MutexQueueImp(int thread_count)
        : DispatchQueue(thread_count),
        _cancel(false),
        _thread_count(thread_count) {
        for ( int i = 0; i < thread_count; i++ ) {
            create_thread();
        }
    }
    ~MutexQueueImp() {
        _cancel = true;
        _condition.notify_all();
        for ( auto& future : _futures ) {
            future.wait();
        }
    }
    
    void sync_imp(std::shared_ptr task) override {
        if ( _thread_count == 1 && _thread_id == std::this_thread::get_id() ) {
            task->reset();
            task->run();
            task->signal();
        } else {
            async_imp(task);
            task->wait();
        }
    }
    
    int64_t async_imp(std::shared_ptr task) override {
        _mutex.lock();
        task->reset();
        _dispatch_tasks.push(task);
        _mutex.unlock();
        _condition.notify_one();
        return 0;
    }
    
private:
    
    MutexQueueImp(const MutexQueueImp&);
    
    void create_thread() {
        _futures.emplace_back(std::async(std::launch::async, [&]() {
            _thread_id = std::this_thread::get_id();
            while (!_cancel) {
                
                {
                    std::unique_lock  work_signal(_signal_mutex);
                    _condition.wait(work_signal, [this](){
                        return _cancel || !_dispatch_tasks.empty();
                    });
                }
                
                while (!_dispatch_tasks.empty() && !_cancel) {
                    _mutex.lock();
                    if ( _dispatch_tasks.empty() ) {
                        _mutex.unlock();
                        break;
                    }
                    std::shared_ptr task(_dispatch_tasks.front());
                    _dispatch_tasks.pop();
                    _mutex.unlock();
                    if ( nullptr != task ) {
                        task->run();
                        task->signal();
                    }
                }
            }
        }));
    }
    
private:
    std::vector> _futures;
    std::queue> _dispatch_tasks;
    std::recursive_mutex _mutex;
    bool _cancel;
    std::mutex _signal_mutex;
    std::condition_variable _condition;
    int _thread_count;
    std::thread::id _thread_id;
};

该类除了实现父类的sync_imp/async_imp 方法外，还有用来创建线程的 create_thread 方法，该方法每调用一次可以产生一个新的任务线程；在类的析构方法中会停止当前所有线程，并等待线程的安全退出。

在 MutexQueueImp 实现中，是典型的 生产者-消费者 线程模型，在 async_imp 方法中将任务插入到队列中，并通知任务线程；任务线程接收到任务加入队列的信号后，循环的从任务队列中取出任务，当所有任务处理完成，进入到休眠模式，直到下一个任务加入队列。

在 sync_imp 方法中会判断当前线程是否为任务线程，如果是任务线程，并且只有一个任务线程时，则直接执行任务，以免造成当前线程等待自己的情况，以免造成死锁。

基于 disruptor 的实现

Disruptor 最初是在 Java 上被发明的，这里使用它的 C++ 实现版本原理和 Java 版本是一致的。但由于 Disruptor 是基于 发布者-订阅者 的分发模型，所以当一个任务来到时，所以等待的线程，都将被唤醒，该任务可能被多个线程同时执行，在当前我们的 Dispatch Queue 中是不被允许的，所以只有在单线程时，才会使用 Disruptor 来作为 Dispatch Queue 的实现，以确保高效和正确性。

C++ 版本的阻塞等待工具类 BlockingStrategy 的实现有错误，无法唤醒，所以不要使用 BlockingStrategy 作为等待策略。

以下是 disruptor 实现的主要代码：

class DisruptorImp : public DispatchQueue {
    
public:
    DisruptorImp()
        : DispatchQueue(1),
        _cancel(false) {
        _sequencer = new DisruptorSequencer(_calls);
        create_thread();
    }
    
    ~DisruptorImp() {
        _cancel = true;
        int64_t seq = _sequencer->Claim();
        (*_sequencer)[seq] = nullptr;
        _sequencer->Publish(seq);
        _future.wait();
        delete _sequencer;
    }
    
private:
    void sync_imp(std::shared_ptr task) override {
        if ( _thread_id == std::this_thread::get_id() ) {
            task->reset();
            task->run();
            task->signal();
        } else {
            async_imp(task);
            task->wait();
        }
    }
    
    int64_t async_imp(std::shared_ptr task) override {
        task->reset();
        int64_t seq = _sequencer->Claim();
        (*_sequencer)[seq] = task;
        _sequencer->Publish(seq);
        return 0;
    }
    
    void create_thread() {
        _future = std::async(std::launch::async, [&]() {
            _thread_id = std::this_thread::get_id();
            this->run();
        });
    }
    
    void run() {
        int64_t seqWant(disruptor::kFirstSequenceValue);
        int64_t seqGeted, i;
        std::vector dependents;
        disruptor::SequenceBarrier* barrier;
        
        disruptor::Sequence handled(disruptor::kInitialCursorValue);
        dependents.push_back(&handled);
        _sequencer->set_gating_sequences(dependents);
        dependents.clear();
        barrier = _sequencer->NewBarrier(dependents);
        
        while (!_cancel)
        {
            seqGeted = barrier->WaitFor(seqWant);
            for (i = seqWant; i <= seqGeted; i++)
            {
                std::shared_ptr task((*_sequencer)[i]);
                (*_sequencer)[i] = nullptr;
                handled.set_sequence(i);
                if ( nullptr != task ) {
                    task->run();
                    task->signal();
                }
            }
            seqWant = seqGeted + 1;
        }
        
        delete barrier;
    }
    
private:
    DisruptorSequencer *_sequencer;
    std::array, disruptor::kDefaultRingBufferSize> _calls;
    bool _cancel;
    std::future _future;
    std::thread::id _thread_id;
};

DisruptorImp 类的结构与 MutexQueueImp 基本一致，只有换成了 Disruptor 实现，至于对 Disruptor 的使用可参看文章后面的链接即可。最后 DispatchQueue 接口对象的创建使用一下方法来创建：

std::shared_ptr create(int thread_count) {
    if ( 1 == thread_count ) {
        return std::shared_ptr(new DisruptorImp());
    } else {
        return std::shared_ptr(new MutexQueueImp(thread_count));
    }
}

总结

DispatchQueue 可以说满足了基本的线程管理的需要，配合 lambda 表达式，使用起来也非常方便了。当然你也把它当做线程池来使用。后续如果有需要可以方便的扩展其他特性例如：延迟执行、任务之间的依赖关系等，完整的代码可在我的 GitHub 上找到。

参考资料

Android 对 C++ Runtime 的支持

2017-12-20T12:50:24.000Z

近期将项目中的 webrtc 代码与官方最新的 m63 分支进行了同步，由于之前的代码比较老，这次升级后，webrtc 的代码结构相对来说有了很多的调整和变化，再加上对 webrtc 代码的修改和代码的添加，索性依照 m63 分支的 gn 脚本使用 cmake 重写了 webrtc 的编译脚本。在编译 android 平台时遇到一些 c++ 标准库中的函数无法进行链接的问题，于是了解了一下 android 对 c++ 标准库的支持。

Android 对 C++ 基础库的实现有多个版本，具体的版本可以在 NDK 目录下的 sources/cxx-stl 子目录中查看，我当前使用的版本是 android-ndk-r12b 子目录内容如下：

drwxr-xr-x  10 Enki  staff   340 12  7 18:05 gabi++
drwxr-xr-x   5 Enki  staff   170 12  7 17:29 gnu-libstdc++
drwxr-xr-x  16 Enki  staff   544 12  7 17:37 llvm-libc++
drwxr-xr-x   8 Enki  staff   272 12  7 17:12 llvm-libc++abi
drwxr-xr-x  16 Enki  staff   544 12  7 18:37 stlport
drwxr-xr-x   9 Enki  staff   306 12  7 20:47 system

gabi++：该库不支持 C++ 标准库，但加入了对异常和 RTTI 的支持。
gnu-libstdc++：GNU 标准 C++ 运行时库（libstdc++-v3），同样支持异常和 RTTI。
llvm-libc++：该版本是 LLVM libc++ 的一个移植版本，支持 C++ 的所有特性。
stlport：该库也提供 C++ 所有的特性支持，它是开源项目 STLPort 的一个 android 移植版本
system：默认最小的 C++ 运行库，这样生成的应用体积小，内存占用小，但部分功能将无法支持

在 NDK 目录中都有预编译好的静态库和动态库，在实际项目中，只要链接对应的库即可。在使用 cmake 脚本的项目中可以使用 ANDROID_STL 宏来指定需要链接的库，在使用 MK 项目中可以使用 APP_STL 宏来指定链接的库例如：

# cmake
-DANDROID_STL=c++_static
# Application.mk
APP_STL:= c++_static

链接库可选值有如下几种：

stlport_static：stlport 作为静态库
stlport_shared：stlport 作为动态库，这个可能产生兼容性和部分低版本的 Android 固件
c++_static：stdlib 作为静态库链接
c++_shared：stdlib 作为动态库链接
gnustl_static：使用 GNU libstdc++ 作为静态库
system：使用默认的最小的 C++ 运行库

在 android 平台下编译 m63 分支时，原来使用的是 gnustl_static 版本的标准库，在新的 m63 分支中使用了一些诸如 std::strtoll() 的方法（还使用了一些其他方法也 gnustl_static 中没有实现的），而在 gnustl_static 版本的标准库中，并没有提供该函数的实现，从而导致 android 平台下无法链接 webrtc 库。这里使用了 c++_static 替换了 gnustl_static 来解决链接的问题。

NDK 中提供了不同版本，不同的版本有不同的特性，有些体积大提供更丰富的特性和标准函数的支持，一些体积小占用空间少，可根据具体的项目需求来选择，随着不 NDK 版本的升级，特性也会有改动。

图像编码与 H264 基础知识

2017-11-26T06:23:58.000Z

RGB 颜色模型

图像的采集可以通过摄像头或者截取屏幕来获取的图像数据。一幅图像可以看作为一个二维的矩阵，其中矩阵中的每一个点被称为像素。像素的颜色可以通过红、绿、蓝来表示，也就是常说的 3 基色。如下图所示：

每个像素可以用不同的数据位数来表示，常用的量化位数有 16 位、24 位、32 位等，24 位最好理解，就是 RGB 的各个分量各占 8 位，取值范围为 0 ~ 255；32 位则是 24 位的基础上增加了透明度的量化位数，也是 8 位，用来表示当前像素的透明度，根据透明的位置可以分为 RGBA 和 ARGB；16 位可以分为 565 和 555 两种模式，565 则表示绿色分量占 6 位，红色和蓝色各占 5 位，555 模式则丢弃一位不用，RGB 各个分量占 5 位。量化位数越多，所能表示颜色的层次也越多，颜色则越丰富。

在表示图像的二维的矩阵中，宽和高两个维度中像素的数量称为分辨率，通常用 宽 x 高 来表示，例如下面分辨率为 4 x 4 的图像。

图像还有另一个属性就是宽高比，例如常见的 16:9、4:3、21:9 等，这里通常指显示宽高比（DAR），同样像素也有不同的宽高比，称之为像素长宽比（PAR）。

YUV 颜色模型与冗余删除

一张 1280x720 分辨率的图片，如果使用 RGB 颜色模型存储话，24 位量化位数的情况下需要 1280 720 3(24bit) = 2.6M 空间来存储一张图片，如果是 32 位则需要 1280 720 4(24bit) = 3.5M 存储空间，而我们的眼睛对于亮度相比于颜色更敏感，例如一下图片：

区域 A 与区域 B，是相同的颜色，第一张很难区分出来，这跟我们人眼的构造相关，人眼更加注意光线明亮度。所以针对这一特点存在另一种颜色模型 YUV 颜色模型，YUV 颜色模型中，其中的 Y 分量表示的是明亮度(Luminance、Luma)， U、V 表示的是色度 (Chrominance/Chroma)，如下图：

该模型下可以采用不同的量化位数来表示亮度以及色度，所以存在不同到模式：4:4:4、4:2:2、4:1:1、4:2:0、4:1:0 和 3:1:1 六种不同的模式。在使用 4:2:0 模式时，同样的图片相比 RGB 模式，所用的内存减少一半。RGB 可以和 YUV（YCbCr）进行转换，公式如下：

# 第一步计算亮度
Y = 0.299R + 0.587G + 0.114B
# 一旦有了亮度，可以分割颜色（色度蓝色和红色）：
Cb = 0.564(B - Y)
Cr = 0.713(R - Y)
# 也可以通过使用 YCbCr 进行转换，甚至获得 RGB
R = Y + 1.402Cr
B = Y + 1.772Cb
G = Y - 0.344Cb - 0.714Cr

采样率、码率、帧以及场的概念

图像则是对模拟信号进行采样量化后获得，而视频则是由一系列的图像组成，采集时图像的分辨率及量化位数越高，所能表达的信息越多，画面则越清晰。视频存在一个采样频率的属性，即单位时间内采样的次数。视频的采样频率也受人眼的限制，通常在每秒 20 ~ 30 帧之间。当采样频率在每秒 10~20 帧时，对于快速运动的图像，人眼可以感觉到不流畅，而采样频率提高到 20~30 帧时，人眼看起来比较流畅了。如果将采样频率在提高，人眼是很难感觉这种差异的，这也是目前电影拍摄时使用 24 帧或者 30 帧采样频率的原因。

显示视频所需要的每秒位数称作为比特率，也叫码率。计算公式为 `比特率=宽 高 位深度 每秒帧数`* 例如，如果我们不采用任何类型的压缩，每秒 30 帧，每像素 24 位，480x240 分辨率的视频将需要 82,944,000位/秒或 82.944 Mbps（30x480x240x24）。

当比特率几乎恒定时，称为恒定比特率（CBR），但它也可以变化，然后称为可变比特率（VBR）。下图显示了一个受限的VBR，在帧为黑色时不会花太多位。

视频采样中通过逐行扫描得到一幅完整的图像称之为一帧，通常帧频率为 25 帧（PAL制）、30 帧每秒（NTSC制），而通过隔行扫描（奇、偶数行），那么一帧图像就被分成两场，通常场频为 50Hz（PAL制）、60Hz（NTSC制）。这是在早起，工程师们提出的一种技术，能够在不消耗额外的带宽的情况下，使得显示器的感知帧率倍增。这种技术称为隔行视频；它基本上在 1 帧中发送一半的屏幕，而在下一帧中发送另一半。

今天视频的显示主要使用逐行扫描技术。逐行是显示、存储或发送运动图像的方法，其中每帧的所有行被依次绘制。

H264 编码

当需要存储视频或者网络传输时，无论是使用 RGB 还是 YUV 格式，所需要的码率和存储空间都是非常大的，例如一个分辨率为 1280 x 720 ，24 位量化位数，采样频率为每秒 30 帧，一个小时的视频则需要 1280 x 720 x 3 x 30 x 60 x 60 = 278G 的空间来存储该视频。而在显示或网络传输该视频时所需要的码率为 1280 x 720 x 24 x 30 = 632Mbps，这么大数据量很难实际应用，因为网络带宽和硬盘存储空间都是非常有限的。

针对以上问题则需要对视频进行编码压缩，而 H264 是其中一种编解码标准；H264 由视频编解码器 H.261 发展而来的，它诞生于 1990 年（技术上为 1988 年），其设计工作的数据速率为 64 kbit / s。它已经使用了色度子采样，宏块等方面的想法。在 1995 年，H.263 视频编解码器标准被公布，并持续延续至 2001 年。

2003 年，第一版 H.264/AVC 完成。同一年，一家名为 TrueMotion 的公司将其视频编解码器作为免版税的有损视频压缩称为 VP3。2008 年，Google 收购了该公司，同年发布了 VP8。2012 年 12 月，Google 发布了 VP9，大约有 3/4 的浏览器市场（包括手机）支持。

AV1 是一种新的视频编解码器，免版税并且开放源代码，由 AOMedia 联盟设计，该组织包括：谷歌，Mozilla，微软，亚马逊，Netflix，AMD，ARM，NVIDIA，英特尔，思科等等，编解码器的第一个版本 0.1.0 于 2016 年 4 月 7 日发布。

H264 编解码方法

去除数据统计冗余：H264采用两种熵编码方式：CAVLC （基于上下文的可变字长编码）和 CABAC（基于上下文的二进制算数编码），CAVLC 实现相对简单，编码效率高，但压缩率要比 CABAC 低 15% 左右，CABAC 复杂度高，可以分场景采用不同的熵编码，让视频压缩后的平均码长接近信源熵值。

去除空间冗余：去除空间冗余则仅考虑本帧的数据而不考虑相邻帧之间的冗余信息，这实际上与静态图像压缩类似。帧内一般采用有损压缩算法，由于帧内压缩是编码一个完整的图像，所以可以独立的解码、显示。帧内压缩一般达不到很高的压缩，跟编码 jpeg 差不多。除此以外，H264采用变换编码的方式，将残差从空间域利用 DCT(离散余弦变换)变换到频率域，结合差异量化编码方式，更进一步的去除空间冗余。

去除时间冗余：相邻几帧的数据有很大的相关性，或者说前后两帧信息变化很小的特点。也即连续的视频其相邻帧之间具有冗余信息，根据这一特性，压缩相邻帧之间的冗余量就可以进一步提高压缩量，减小压缩比。帧间压缩也称为时间压缩（Temporal compression），它通过比较时间轴上不同帧之间的数据进行压缩。帧间压缩一般是无损的。帧差值（Frame differencing）算法是一种典型的时间压缩法，它通过比较本帧与相邻帧之间的差异，仅记录本帧与其相邻帧的差值，这样可以大大减少数据量。

去除人眼视觉冗余：H264编码器的输入图像或视频的色彩空间采样格式一般为 YUV420，不同于 RGB 采样，YUV420 利用人眼视觉对像素亮度分量更敏感，而色度分量没那么敏感，进一步将图像或视频的色度分量做 2:1 的采样，4 个亮度分量，2 个色度分量，另外，H264 采用量化编码的有损编码方式，也正是利用了人眼视觉对高频细节部分不敏感的理论基础，将残差系数低频部分采用更细的量化参数，而高频部分则粗化量化，一般的视频压缩失真也正是这个阶段产生。

除了以上是 H264 所使用的技术，还使用了以下方法：

帧分组（GOP）：在 H264 中图像以序列为单位进行组织，一个序列是一段图像编码后的数据流，以 I 帧开始，到下一个 I 帧结束。当运动变化比较少时，一个序列可以很长，因为运动变化少就代表图像画面的内容变动很小，所以就可以编一个 I 帧，然后一直 P 帧、B 帧了，可以有效的降低码率。当运动变化多时，一个序列就需要设置的比较小，比如就包含一个 I 帧和 3、4 个 P 帧，这样可以控制 P 帧和 B 帧的大小。

帧类型的定义：将每组内各帧图像定义为三种类型，即 I 帧（IDR）、B 帧和 P 帧；I 帧是帧内编码帧，I 帧表示关键帧，可以理解为这一帧画面的完整保留， I 帧特点：

它是一个全帧压缩编码帧。它将全帧图像信息进行 JPEG 压缩编码及传输；
解码时仅用 I 帧的数据就可重构完整图像；
I 帧描述了图像背景和运动主体的详情；
I 帧不需要参考其他画面而生成；
I 帧是 P 帧和 B 帧的参考帧，其质量直接影响到同组中以后各帧的质量；
I 帧是帧组 GOP 的基础帧（第一帧），在一组中只有一个 I 帧；
I 帧不需要考虑运动矢量；
I 帧所占数据的信息量比较大。

P 帧是前向预测编码帧。P 帧表示的是这一帧跟之前的一个关键帧（或 P 帧）的差别，解码时需要用之前缓存的画面叠加上本帧定义的差别，生成最终画面。P帧是以 I 帧或 P 帧为参考帧，在参考帧中找出 P 帧的差异 P 帧特点:

P 帧采用运动补偿的方法传送它与前面的 I 或 P 帧的差值及运动矢量（预测误差）；
解码时必须将 I 帧中的预测值与预测误差求和后才能重构完整的 P 帧图像；
P 帧属于前向预测的帧间编码，它只参考前面最靠近它的 I 帧或 P 帧；
P 帧可以是其后面 P 帧的参考帧，也可以是其前后的 B帧 的参考帧；
由于 P 帧是参考帧，它可能造成解码错误的扩散；
由于是差值传送，P 帧的压缩比较高。

B 帧是双向预测内插编码帧。B 帧是双向差别帧，也就是 B 帧记录的是本帧与前后帧的差别，换言之，要解码 B 帧不仅要取得之前的缓存画面，还要解码之后的画面，通过前后画面的与本帧数据的叠加取得最终的画面。 B 帧以前面的 I 或 P 帧和后面的 P 帧为参考帧，B 帧特点：

B 帧是由前面的 I 或 P 帧和后面的 P 帧来进行预测的；
B 帧传送的是它与前面的 I 或 P 帧和后面的 P 帧之间的预测误差及运动矢量；
B 帧是双向预测编码帧；
B 帧压缩比最高，因为它只反映丙参考帧间运动主体的变化情况，预测比较准确；
B 帧不是参考帧，不会造成解码错误的扩散。

I、P、B 各帧是根据压缩算法的需要，是人为定义的，它们都是实实在在的物理帧。

一般来说，I 帧的压缩率是 7（跟 JPG 差不多），P 帧是 20，B 帧可以达到 50。

B 帧的使用会导致解码的延时，因为需要参考前后帧，同时也会增加 CPU 负担。

P 帧和 B 帧不会越过 I 帧（IDR图像）去参考其他帧。

H264 的编码参数

H264 的编码的实现存在很多的控制参数，不同的编码器实现可能有一些特殊的参数可供设置，不同的控制参数得到不同的输出结果，以便适应不同的应用场景，这里介绍一些通用的参数，后续在介绍一些具体编码器以及应用时，在对一些参数进行详细的说明。

H.264 Profiles：Profile 用于确定编码过程中帧间压缩使用的算法，常见的 H264 编码 Profile 有如下 3 种：

1、Baseline Profile (BP)：只支持 I/P 帧，无交错（Progressive）和 CAVLC，主要用于计算能力有限的应用环境，一般用于低阶或需要额外容错的应用，比如视频通话、手机视频等；
优势：编解码开销较小，速度快，适用于视频会议等延时敏感的场景或者解码能力不够的环境。
不足：同等码率下，Baseline 的画质最差。

2、Main Profile (MP)：支持 I/P/B 帧，无交错（Progressive）和交错（Interlaced），同时提供对于 CAVLC 和 CABAC 的支持，用于主流消费类电子产品规格如低解码（相对而言）的 MP4、便携的视频播放器；
优势：CABAC 的支持和 B 帧的引入，相同码率下画质相对 Baseline 有 15% 的提升。
不足：运算量上和画质相对于 HiP 没有太大优势，绝大部份情况下已经被 HiP 取代。

3、High Profile (HiP)：在 Main 的基础上增加了 8x8 内部预测、自定义量化、无损视频编码和更多的 YUV 格式（如4：4：4）用于广播，高清电视及视频碟片存储（HiP被采纳为 HD DVD 和蓝光的编码标准）。
优势：8x8 内部预测的引入使得 HiP 能够较好的编码快速移动的场景、支持码流之间有效的切换（SP 和 SI 片）、改进误码性能。

CAVLC 和 CABAC 是两种不同的熵编码（一种无损，变长编码数据压缩方案）形式，CAVLC 效率高压缩比低，CABAC 反之。

除此之外还存一下类别：

High 10 Profile (Hi10P)：超越目前主流的消费型产品能力，此 profile 建立在 High Profile 之上，多了支援 10 bit 的精度，色彩更精准。以影片压制而言，将 High Profile (8 bit) 影片重新编码输出为 H.264 High 10 Profile ，虽然色彩精度不会变，但至少压缩率比输出 High Profile (8 bit) 还要高。

High 4:2:2 Profile (Hi422P)：针对专业领域应用，此 profile 建立在 High 10 Profile 之上，多了支援 4:2:2 色彩取样，位元深度达 10 bit。

High 4:4:4 Predictive Profile (Hi444PP)：此 profile 建立在 High 4:2:2 Profile 之上，多了支援 4:4:4 色彩取样，位元深度达 14 bit，并且支援高效率无损重新编码，且每张画面编码为三个独立的色彩平面。

H.264 Level： Level 是对视频本身特性的一些描述(码率，分辨率，fps等)，Level 越高，视频的码率、分辨率、fps 越高。Level 也表示了对播放设备的解码性能要求，值越高，代表播放设备解码性能要求越高，相对的输出影片的压缩率也越越高。

iOS 设备对 Profile 和 Level 的支持
H.264 Baseline 3.0: All devices.
H.264 Baseline 3.1: iPhone 3G and later, and iPod touch 2nd generation and later.
H.264 Main profile 3.1: iPad (all versions), Apple TV 2 and later, and iPhone 4 and later.
H.264 Main Profile 4.0: Apple TV 3 and later, iPad 2 and later, and iPhone 4S and later.
H.264 High Profile 4.0: Apple TV 3 and later, iPad 2 and later, and iPhone 4S and later.
H.264 High Profile 4.1: iPad 2 and later and iPhone 4S and later.

关于 Profile 和 Level 更详细资料可参考 WiKi 百科的 H.264/MPEG-4 AVC 资料。

GOP 长度：一个 key frame (IDR) 到下一个 key frame 的范围。表示关键帧的间隔，一个序列的第一个图像叫做 IDR 图像（立即刷新图像），IDR 图像都是 I帧图像。当解码器解码到 IDR 图像时，立即将参考帧队列清空，将已解码的数据全部输出或抛弃，重新查找参数集，开始一个新的序列。这样，如果前一个序列出现重大错误，在这里可以获得重新同步的机会。IDR 图像之后的图像永远不会使用 IDR 之前的图像的数据来解码。

Constant Quantizer (QP)：恒定量化值（Constant Quantizer）可以用来控制图像编码的品质。编码器中一般可以这是最大值和最小值。比较低的数值会得到比较高的品质。

Maximun B-frame：当设定 B 帧时，重复部分比较多/变化较少的 Frames 会被编码为 B 帧此值限制 B 帧的最大连续数量。

Reference frame (ref)：设定一个 P 帧所能参考的帧的数量，ref 会影响播放相容性。

码率控制(Bitrate Control)：CBR（恒定码率）、VBR（动态码率）；码率控制实际上是一种编码的优化算法，它用于实现对视频流码流大小的控制。目的在于同样的视频编码格式，码流大，它包含的信息也就越多，那么对应的图像也就越清晰，反之亦然。VBR 码流控制方式可以降低图像动态画面少时候的带宽占用，CBR 控制方式码流稳定，图像状态较稳定。他们为了解决的是不同需求下的不同应用。

AVC 与 SVC

AVC 实际上是 H.264 协议的别名。SVC 是 scalable video coding，有的翻译成分层，有的翻译成分级；SVC 是以 H264/AVC 为基础，利用了AVC编解码器的各种高效算法工具，在语法和工具集上进行了扩展，支持分级特性的码流，包括空域（分辨率）可分级、时域（帧率）可分级和质量可分级；从而可产生不同帧速率、分辨率或质量等级的解码视频。

自从 H.264 协议中增加了 SVC 的部分之后，人们习惯将不包含 SVC 的 H.264 协议那一部分称为 AVC，而将 SVC 这一部分单独称为 SVC。所以提到 AVC 的时候，需要根据具体情况判断到底是指 H.264 协议还是指协议中不包含 SVC 的那一部分。

为此，具备 H.264 SVC 编码的视频会议系统，在保证高效的视频压缩性能的基础上，视频广播端可以通过一次编码产生具有不同帧率、分辨率的视频压缩码流，以适应不同网络带宽、不同的显示屏幕和终端解码能力的应用需求，从而有效地避免了视频会议系统中 MCU 上复杂而昂贵的转码。

H.264 SVC 与以往传统视频协议 H.264AVC 的区别表

项目	H264/AVC	H264/SVC
视频会议可以容忍的网络丢包率	< 2~3 %	< 20%
对网络的要求	专线	共享线路
视频会议延迟	400ms	< 200ms
视频会议实时性	非实时性交互	实时性交互
HD 会议室终端开销	昂贵	普及型

分级编码的应用

1、监控领域：监控视频流一般产生 2 路，1 路质量好的用于存储，1 路用于预览。用 SVC 编码器可以产生 2 层的分级码流，1 个基本层用于预览，1 个增强层保证存储的图像质量是较高的。使用手机远程监控预览的情况下，可以产生一个低码率的基本层。

2、视频会议：视频会议终端利用 SVC 编出多分辨率，分层质量，会议的中心点替代传统 MCU 二次编解码方法改为视频路由分解转发。也可在网络丢包环境下利用时域可分级，抛弃部分时域级实现网络适应性。在云视讯领域 SVC 也有想像空间。

3、流媒体IPTV应用：服务器可以根据不同的网络情况丢弃质量层，保证视频的流畅。

4、兼容不同网络环境和终端的应用

分级的优缺点

优点：分级码流优点是应用非常灵活，可以根据需要产生不同的码流或者提取出不同的码流。使用 SVC 实现一次分层编码比用 AVC 编多次更高效。分层编码有技术优势，新的编码器 H.265 也使用了分层思想，可以实现灵活的应用，也可提高网络适应性。

缺点：分级码流的解码复杂度增加。基本层是 AVC 兼容码流，编码效率没有影响。在同样的条件下，分级码流比单层码流的压缩效率要低 10% 左右，分级层数越多，效率下降越多，现在的 JSVM 编码器最多支持 3 个空域分级层。在同样的条件下，分级码流比单层码流的解码计算复杂度高。SVC 是 2007 年 10 月才做为正式标准，兼容性和对通性远没有 AVC 好，所以 SVC 实际应用不是广泛。

参考资料

iOS 静态库中的 Category 运行时错误

2017-09-13T03:49:24.000Z

最近在弄 iOS 下的音视频 SDK 的移植和适配，该 SDK 是基于 WebRTC 项目但并未使用官方的 ninja 编译脚本，而是使用的 cmake 作为编译工具。在 WebRTC 的音频模块中引用了一个 UIDevice 的 Category 来做设备类型的判断，编译和链接都没有出现问题，但在运行时出现了 selector not recognized 的异常。该异常可以从我之前的《iOS 运行时之消息转发机制》文章中了解到，由于对象接收到了一个无法处理该 selector ，经过消息转发后还未得到处理，会在 doesNotRecognizeSelector 方法中抛出的异常。

Category 以及一些其他的工具类被编译在一个基础的静态库中，在音频模块中引用该静态库，除了 Category 代码其他所有的代码都能正常编译、链接以及运行，但唯独 Category 在运行时出现了错误，由于 Category 的 Objective-C 语言的特性，最开始我以为需要为编译器添加针对 Category 的参数，找了很久也没找到针对 Category 特性的编译参数，无奈之下只好求助 stackoverflow ，最终找到了根本原因和解决方法。

编译/链接过程

编译器在编译的过程中首先会将 .c/.cc/.cpp/.m/.mm 的源文件编译成后缀为 .o 的对象文件，源文件与对象文件是一一对应的，对象文件中包含了符号、代码以及数据，对象文件是不能被系统加载并使用的。当在编译生成静态库时，这些所有的对象文件，都会被封装到 .a(archive) 文件，可以理解为一个归档文件，也就是我们平常使用的静态库。

当需要生产二进制文件或是动态库时，编译器会对静态库 .a(archive) 文件进行处理；编译器将获取静态库中所以的符号表，并检查哪些符号被引用，只有被引用的对象文件才会被链接器真正的加载并处理。例如在静态库中有 10 个对象文件，但被引用到只有 2 个，则链接器只加载被引用的 2 个对象文件，未被使用到的 8 个对象文件则会被忽略。

在 C/C++ 语言中，这种机制可以很好的工作，因为 C/C++ 语言会尽可能的在编译期去做这些事。在 Objective-C 语言中非常依赖运行时特性，Category 就是基于运行时实现，但它并不会像类或者函数一样被创建链接符号，编译器在检查符号表时便不能检查到 Category 对应的符号表，从而 Category 的对象文件就不能被正常的加载，在运行时便无法找到对应的 selector 。

解决方案

基于上述的原因，网上存在 5 种解决方法：

在编译选项 Other Linker Flags 中添加 -all_load，用于会告诉编译器 对于所有静态库中的所有对象文件，不管里面的符号有没有被用到，全部都载入，这种方法可以解决问题，但是会产生比较大的二进制文件。
添加编译选项 -force_load 并指定路径，-force_load $(BUILT_PRODUCTS_DIR)/ 这种方法和 -all_load 类似，不同的是它只载入指定的静态库。
在编译选项 Other Linker Flags 中添加 -ObjC，这个标识告诉编译器 如果在静态库的对象文件中发现了 Objective-C 代码，就把它载入，Category 中肯定会存在 Objective-C 代码。该方法与前两张类似，只是将加载的范围减少了。
另一种解决方法是新版本 Xcode 里 build setting 中的 Perform Single-Object PreLink，如果启用这个选项，所有的对象文件都会被合并成一个单文件（这不是真正的链接，所以叫做预链接），这个对象文件（有时被称做主对象文件 master object file）被添加到静态库中。现在如果主对象文件中的任何符号被认为是在使用，整个主对象文件都会被认为在使用，这样它里面的 Objective-C 部分就会被载入了，当然也包括 Category 对应的对象文件。
最后一种解决方法是在 Category 的源文件里添加 Fake symbol，并确保以某种方法在编译时引用了该 Fake symbol，这会使得 Fake symbol 对象文件被加载时它里面 Category 代码也会被载入。该方法可以控制哪些 Category 可以被正常加载，同时也不需要添加编译参数做特殊处理。

在 64 位的 Mac 系统或者 iOS 系统下，链接器有一个 bug，会导致只包含有 Category 的静态库无法使用 -ObjC 标志来加载 Objective-C 对象文件。

问题的处理

我这里用的是最后一种方法来解决该问题，原因在于前 4 种都会增加二进制文件的体积，在第三方使用当前 SDK 时需要手动设置编译参数，会给第三方带来不好的使用体验。为了使用方便可定义一下宏：

#define FIX_CATEGORY_BUG_H(name) \
@interface FIX_CATEGORY_BUG_##name : NSObject \
+(void)print; \
@end
#define FIX_CATEGORY_BUG_M(name) \
@implementation FIX_CATEGORY_BUG_##name \
+ (void)print {} \
@end
#define ENABLE_CATEGORY(name) [FIX_CATEGORY_BUG_##name print]

在 Category 的头文件中使用 FIX_CATEGORY_BUG_H() 宏来声明一个 Fake symbol ，在 Category 的实现文件中使用 FIX_CATEGORY_BUG_M() 宏来实现该 Fake symbol。最后在找一处运行 ENABLE_CATEGORY() 宏，可以是初始化方法中，也可以是其他任何地方，只要确保它能被正常调用，目的在于该 Fake symbol 确保编译器能正常加载它。

总结

在 iOS/Mac 平台下，包含 Category 的静态库无法被正常加载，原因在于 Category 是 Objective-C 语言的特性，编译器并不会为它生成链接符号，在链接过程中便无法找到该对象文件的引用关系，链接器将会直接忽略掉 Category 对应的对象文件，从而在运行时无法找到相应的 selector。解决该问题的目标就是让链接器加载 Category 对应的对象文件，一种方法是添加编译参数让编译器加载所有的对象文件或是加载指定的对象文件；另一种方法是在 Category 的对象文件中添加 Fake symbol ，当 Fake symbol 被加载时 Category 的对象文件便一同被加载。

参考资料

WebRTC 的丢帧策略

2017-07-29T09:35:15.000Z

最近在弄一个 Android 平台下远程桌面项目，是基于 WebRTC 框架实现的，由于平台限制，芯片是用的特定厂商的芯片，桌面采集以及 H264 硬编码都是芯片厂商提供方案，能够有很好性能表现。在将桌面的采集以及 H264 的编码库整合到 WebRTC 框架中时，发现的存在画面延时的问题，于是对 WebRTC 的编解码框架的源码进行了分析，了解到 WebRTC 的两个特性。

在 WebRTC 中有很多可以控制视频帧率和码率的行为，这里介绍一下当视频采集过快以及编码器输出码率过高时，WebRTC 主动丢帧的策略。这里采集过快是指视频采集的速度大于编码器处理的速度。例如视频采集线程每秒采集 30 帧，而编码线程每秒只能处理 15 帧，这时候就出现了采集过快或者说是编码器太慢。编码器输出码率过高，是指编码器的输出码率大于设定的最高输出码率值，例如设置编码器码率为 1024kbps，而实际产生的码率是 1500kbps 这时候就出现了输出码率过高的情况。本文主要介绍上述两种情况下 WebRTC 是如何实现丢帧行为的。

下图是这次涉及到一些类的结构图，如果要在 WebRTC 源码中找对对应的文件，直接搜索类名称即可。WebRTC 的源码由于在墙外，我这里为了后续方便拷贝了一份到我的 GitHub 空间中，点击这里可以找到源码。

采集过快时的丢帧策略

在 WebRTC 中视频或者桌面图像的采集和图像的编码线程各自是独立线程进行工作的，采集线程会将采集好的图像打包成 VideoFrame 对象，这里的 VideoFrame 封装了经过转换的 YUV 数据而非 RGB 数据， VideoFrame 在经过一系列的周转后，最终会在 ViEEncoder 类中得到处理，在 ViEEncoder 类一部分工作是将数据从采集线程 post 到编码线程中，这里就会涉及到多线程间协作的问题。

这里用的是 rtc::TaskQueue 队列类，在 ViEEncoder 类内部，会将所有跟编码器相关的操作都将打包成一个 Task 扔到队列中，确保所有的操作都是顺序执行的。在 onFrame() 方法中接收到采集线程传进来的 VideoFrame 对象，并将其打包成一个 EncodeTask 对象放入队列中。代码片段如下：

void ViEEncoder::OnFrame(const VideoFrame& video_frame) {
    ...
    last_captured_timestamp_ = incoming_frame.ntp_time_ms();
    encoder_queue_.PostTask(std::unique_ptr(new EncodeTask(
      incoming_frame, this, rtc::TimeMicros(), log_stats)));
}

EncodeTask 是一个内部类，代码非常少，这里就直接贴上来了：

class ViEEncoder::EncodeTask : public rtc::QueuedTask {
 public:
  EncodeTask(const VideoFrame& frame,
             ViEEncoder* vie_encoder,
             int64_t time_when_posted_us,
             bool log_stats)
      : frame_(frame),
        vie_encoder_(vie_encoder),
        time_when_posted_us_(time_when_posted_us),
        log_stats_(log_stats) {
    ++vie_encoder_->posted_frames_waiting_for_encode_;
  }
 private:
  bool Run() override {
    RTC_DCHECK_RUN_ON(&vie_encoder_->encoder_queue_);
    RTC_DCHECK_GT(vie_encoder_->posted_frames_waiting_for_encode_.Value(), 0);
    vie_encoder_->stats_proxy_->OnIncomingFrame(frame_.width(),
                                                frame_.height());
    ++vie_encoder_->captured_frame_count_;
    if (--vie_encoder_->posted_frames_waiting_for_encode_ == 0) {
      vie_encoder_->EncodeVideoFrame(frame_, time_when_posted_us_);
    } else {
      // There is a newer frame in flight. Do not encode this frame.
      LOG(LS_VERBOSE)
          << "Incoming frame dropped due to that the encoder is blocked.";
      ++vie_encoder_->dropped_frame_count_;
    }
    if (log_stats_) {
      LOG(LS_INFO) << "Number of frames: captured "
                   << vie_encoder_->captured_frame_count_
                   << ", dropped (due to encoder blocked) "
                   << vie_encoder_->dropped_frame_count_ << ", interval_ms "
                   << kFrameLogIntervalMs;
      vie_encoder_->captured_frame_count_ = 0;
      vie_encoder_->dropped_frame_count_ = 0;
    }
    return true;
  }
  VideoFrame frame_;
  ViEEncoder* const vie_encoder_;
  const int64_t time_when_posted_us_;
  const bool log_stats_;
};

第一段代码生成 EncodeTask 后直接调用 PostTask 方法将其放入队列中，该代码是在采集线程中执行的。在 EncodeTask 的构造方法中会对 posted_frames_waiting_for_encode_ 属性执行一次自增操作，用来记录待编码的帧数。

EncodeTask 的 Run 方法是在 rtc::TaskQueue 的队列线程中执行的，方法中的条件判断可以理解为，当队列中只有当前一个待编码的帧时，才进行编码，否则丢弃当前帧并记录被丢弃帧的数量。由于是一个队列，采集的帧会被依次存入队列中，如果编码线程处理不过来时，编码线程将队列中的待编码的帧依次丢弃，直到最后一帧，然后调用 EncodeVideoFrame 方法进入下一步的编码处理。

编码器码率过高时的丢帧策略

采集过快时，会在 ViEEncoder 类中处理，而输出码率过高时则是在 VideoSender 类中处理。数据会沿着 EncodeVideoFrame 方法，数据会经过 VideoSender 类的 AddVideoFrame 方法，在该方法中存在以下逻辑：

// Add one raw video frame to the encoder, blocking.
int32_t VideoSender::AddVideoFrame(const VideoFrame& videoFrame,
                                   const CodecSpecificInfo* codecSpecificInfo) {
  ...
  
  if (_mediaOpt.DropFrame()) {
     LOG(LS_VERBOSE) << "Drop Frame "
                     << "target bitrate "
                     << encoder_params.target_bitrate.get_sum_bps()
                     << " loss rate " << encoder_params.loss_rate << " rtt "
                     << encoder_params.rtt << " input frame rate "
                     << encoder_params.input_frame_rate;
     post_encode_callback_->OnDroppedFrame();
     return VCM_OK;
  }
  
  ...
  
  int32_t ret =
      _encoder->Encode(converted_frame, codecSpecificInfo, next_frame_types);
  if (ret < 0) {
    LOG(LS_ERROR) << "Failed to encode frame. Error code: " << ret;
    return ret;
  }

DropFrame 方法是 MediaOptimization 类的一个方法，用来判断是否丢弃当前帧。 MediaOptimization 类实际上并不直接处理该逻辑，而是交给关联的 FrameDropper 类对象进行处理。MediaOptimization 类主要任务是依赖于编码后的数据对象来计算和记录当前输出码率、帧率以及一些其他信息，这里介绍该类其他两个主要方法：

void SetEncodingData(int32_t max_bit_rate, uint32_t bit_rate, uint16_t width, uint16_t height, uint32_t frame_rate, int num_temporal_layers, int32_t mtu)

该方法用来初始一些配置参数，例如最大码率、帧率等，另一个方法就是：

int32_t UpdateWithEncodedData(const EncodedImage& encoded_image);

该方法用来接收编码后的 EncodedImage 对象，该对象包含了编码的数据，以及长度时间等信息。至于该方法什么时候会被调用，以及在哪里被调用，这里就不介绍了，因为涉及到编码类的一些结构，比较复杂，有时间单独写一篇专门介绍 WebRTC 的编解码模块的框架结构。

FrameDropper 类的声明如下：

// The Frame Dropper implements a variant of the leaky bucket algorithm
// for keeping track of when to drop frames to avoid bit rate
// over use when the encoder can't keep its bit rate.
class FrameDropper {
 public:
  FrameDropper();
  explicit FrameDropper(float max_time_drops);
  virtual ~FrameDropper() {}
  // Resets the FrameDropper to its initial state.
  // This means that the frameRateWeight is set to its
  // default value as well.
  virtual void Reset();
  virtual void Enable(bool enable);
  // Answers the question if it's time to drop a frame
  // if we want to reach a given frame rate. Must be
  // called for every frame.
  //
  // Return value     : True if we should drop the current frame
  virtual bool DropFrame();
  // Updates the FrameDropper with the size of the latest encoded
  // frame. The FrameDropper calculates a new drop ratio (can be
  // seen as the probability to drop a frame) and updates its
  // internal statistics.
  //
  // Input:
  //          - frameSizeBytes    : The size of the latest frame
  //                                returned from the encoder.
  //          - deltaFrame        : True if the encoder returned
  //                                a key frame.
  virtual void Fill(size_t frameSizeBytes, bool deltaFrame);
  virtual void Leak(uint32_t inputFrameRate);
  // Sets the target bit rate and the frame rate produced by
  // the camera.
  //
  // Input:
  //          - bitRate       : The target bit rate
  virtual void SetRates(float bitRate, float incoming_frame_rate);
  
  ...
}

可以了解到 FrameDropper 类是一个漏斗算法的一种变体实现，当编码器无法保证比特率时，用来跟踪何时应该丢弃帧。具体的算法实现代码我没有细看，有兴趣的同学可以看看，从方法的输入参数可以推测，计算模型跟时间、帧率、数据量以及是否为关键帧几个参数相关。可以理解为通过计算之前编码后的实际码率，来判断当前是否丢弃帧的。

从上面的分析可以了解到在 VideoSender::AddVideoFrame 方法中，间接的依赖了 FrameDropper 类的漏斗算法模型，来处理是否丢弃当前帧。从而确保输出码率不大于设定的值。

总结

当采集过快或者编码过慢都可能导致编码队列中存在很多待处理的帧，从而导致码率过高或者画面延时很大（可能还取决于编码器）。主动丢弃一些帧行，可以有效的控制码率和画面延时，代价就是损失帧率。在一些情况下编码器的输出码率并不能达到预先设定的值，从而导致码率过高增加了网络负担，第二种丢帧行为可以根据实际的码率来控制最终的码率，而非通过参数来调整。

可能有些人会有疑问，为什么采集就会过快呢？编码器可以通过参数设定码率，为何又不能按要求输的给定的码率呢？这里从两方面来表达我个人的看法。第一个问题可以从软件设计原则角度来解析，采集模块与编码模块可以说是两个相对独立的模块，两个模块分别独立工作，各自都不需要依赖对方的具体实现，知道的细节越少越好。简单的说就是依赖接口编程，而非具体实现。第二个问题也比较好解析，H264 的编码参数有很多例如帧率、码率、Qp、Profiles 级别等一些参数，并且一些参数之间相互影响，一些特定的编码器可能还存在一些特定的编码参数。在配置参数时可能存在一些不合理的情况。编解码器（暂且为H264）可以有两种实现方式，一种是硬编码，依赖于一些特点硬件设备；另一种是纯软件算法实现；软编码相对来说稳定，硬编解码在不同平台下存在差异，尤其是 Android 设备下，差异更大。

iperf 的介绍和使用

2017-06-06T12:31:58.000Z

iperf 是一个网络性能测试工具，做服务开发或者测试的同学，接触的可能比较多。因为最近有用到这个工具，并且这个工具做的非常不错，这里记录一下工具的使用方法。iperf 是个开源并且跨平台的软件，代码托管在 GitHub 上，可以从 Releases 找到各个发行版本，也可以去官网下载各个平台的版本。使用 iperf 时，需要分别运行服务端和客户端，在测试是最好保证两个端的软件版本一致，这样会免去一些没必要的麻烦。

下载好后，可以先在本机做一个简单的回环测试，结果如下：

# 运行服务端
$ ./iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size:  128 KByte (default)
------------------------------------------------------------
[  4] local 127.0.0.1 port 5001 connected with 127.0.0.1 port 54817
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec  35.1 GBytes  30.1 Gbits/sec
# 运行客户端
$ ./iperf -c 127.0.0.1
------------------------------------------------------------
Client connecting to 127.0.0.1, TCP port 5001
TCP window size:  144 KByte (default)
------------------------------------------------------------
[  4] local 127.0.0.1 port 54817 connected with 127.0.0.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec  35.1 GBytes  30.1 Gbits/sec

默认情况下，会使用 TCP 连接，绑定在 5001 端口上，可以从上述结果看到，当前本机的带宽为 30.1 Gbits/sec 。

主要参数信息

适用于服务端/客户端

-f 指定数据显示格式 [k|m|K|M] 分别表示 Kbits、Mbits、KBytes、MBytes，默认是 Mbits
-l 读写缓冲区的大小，默认是 8K
-u 使用 udp 协议
-i 以秒为单位统计带宽值
-m 显示最大的 TCP 数据段大小
-p 指定服务端或者客户端的端口号
-w 指定 TCP 窗口大小
-B 绑定道指定的主机地址或接口
-C 兼容旧版本
-M 设置 TCP 数据包的最大 MTU 值
-V 传输 IPV6 包

适用于服务端

1
2
3

-s 以服务器模式启动
-U 单线程 UDP 模式
-D 以守护进程模式运行

适用于客服端

-c 以客户端模式运行，并指定服务端的地址
-b 指定客户端通过 UDP 协议发送信息的带宽，默认为 1Mbit/s
-d 同时进行双向传输测试
-n 指定传输的字节数
-r 单独进行双向传输测试
-t 指定 iperf 测试的时间，默认 10s
-F 指定要传输的文件
-L 指定一个端口，服务利用这端口与客户端连接
-P 指定客户端到服务器的连接数，默认是 1
-T 指定 ttl 值

用 -u 参数来指定使用 UDP 协议，需要在 -p 参数之前指定

测试之前确保防火墙为关闭状态

网络性能测试

TCP 协议测试带宽

# 运行服务端
$ iperf -s
# 运行客户端
$ iperf -c 172.18.142.62 -i 1 -t 10
------------------------------------------------------------
Client connecting to 172.18.142.62, TCP port 5001
TCP window size:  129 KByte (default)
------------------------------------------------------------
[  4] local 172.18.98.209 port 57809 connected with 172.18.142.62 port 28756
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0- 1.0 sec   384 KBytes  3.15 Mbits/sec
[  4]  1.0- 2.0 sec   256 KBytes  2.10 Mbits/sec
[  4]  2.0- 3.0 sec   256 KBytes  2.10 Mbits/sec
[  4]  3.0- 4.0 sec   256 KBytes  2.10 Mbits/sec
[  4]  4.0- 5.0 sec   512 KBytes  4.19 Mbits/sec
[  4]  5.0- 6.0 sec  1.12 MBytes  9.44 Mbits/sec
[  4]  6.0- 7.0 sec  1.12 MBytes  9.44 Mbits/sec
[  4]  7.0- 8.0 sec  1.12 MBytes  9.44 Mbits/sec
[  4]  8.0- 9.0 sec  1.25 MBytes  10.5 Mbits/sec
[  4]  9.0-10.0 sec  1.12 MBytes  9.44 Mbits/sec
[  4]  0.0-10.1 sec  7.50 MBytes  6.25 Mbits/sec

使用 TCP 协议进行测试时，需要注意的就是 TCP 窗口大小，可以使用 -w 参数指定，网络通道的容量 capacity = bandwidth * round-trip time，而理论 TCP 窗口大小就是网络通道的容量。例如，网络带宽为 40Mbit/s，回环路径消耗时间是 2ms，那么 TCP 的窗口大小不小于 40Mbit/s×2ms = 80kbit = 10Kbytes 。

UDP 协议测试带宽

# 运行服务端
$ iperf -u -s
# 运行客户端
$ iperf -c 172.18.142.62 -u -i 1 -t 10 -b 30M
------------------------------------------------------------
Client connecting to 172.18.142.62, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 9.00 KByte (default)
------------------------------------------------------------
[  4] local 172.18.98.209 port 53220 connected with 172.18.142.62 port 28756
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0- 1.0 sec  3.58 MBytes  30.0 Mbits/sec
[  4]  1.0- 2.0 sec  3.58 MBytes  30.0 Mbits/sec
[  4]  2.0- 3.0 sec  3.58 MBytes  30.0 Mbits/sec
[  4]  3.0- 4.0 sec  3.58 MBytes  30.0 Mbits/sec
[  4]  4.0- 5.0 sec  3.58 MBytes  30.0 Mbits/sec
[  4]  5.0- 6.0 sec  3.57 MBytes  30.0 Mbits/sec
[  4]  6.0- 7.0 sec  3.58 MBytes  30.0 Mbits/sec
[  4]  7.0- 8.0 sec  3.58 MBytes  30.0 Mbits/sec
[  4]  8.0- 9.0 sec  3.58 MBytes  30.0 Mbits/sec
[  4]  9.0-10.0 sec  3.58 MBytes  30.0 Mbits/sec
[  4]  0.0-10.0 sec  35.8 MBytes  30.0 Mbits/sec
[  4] Sent 25511 datagrams
[  4] Server Report:
[  4]  0.0-11.6 sec  13.6 MBytes  9.83 Mbits/sec   1.971 ms 15786/25497 (62%)
[  4]  0.0-11.6 sec  140 datagrams received out-of-order

上述命令指定了客户端以 30Mbit/s 速度发送数据，由于 UDP 协议是无连接不可靠的，并且只管发包，不确保包在服务端是否接收到，所以需要查看服务报告才能确定当前网络性能数据。如果在不知道当前网络带宽的情况下，需要不断的调整参数值，并且查看丢包率，来确定当前网络性能情况。如果你当前是远程登录到服务器上进行测试的，可以从小到大的方式进行测试，否则很容易导致服务当前带宽被占满。

参考资料

Dnsmasq 介绍与使用

2017-05-23T06:06:00.000Z

上一个星期在查找一个设备无法解析公司内部域名的问题，最终查出来问题是在网关设备上运行的 Dnsmasq 服务没有正确的配置上游 DNS 服务器，导致内网域名无法被正常的解析。在这期间对 DNS协议 又重新学习了一番，并且对 Dnsmasq 服务有了一些了解，结合网上一些资料，对 Dnsmasq 提供的 DNS 和 DHCP 服务的配置做一些总结和备忘。

Dnsmasq 是一个开源的项目，可以在 thekelleys 上找到最新版本和源码，它能提供 DNS 、DHCP、TFTP、PXE 等功能。Dnsmasq 的 DNS 服务工作原理是，当接收到一个 DNS 请求是， Dnsmasq 首先会查找 /etc/hosts 文件，如果没有查找到，会查询本地 DNS 缓存记录，如果还是未找到对应的记录，则会将请求装发到 /etc/resolv.conf 文件中定义的上游 DNS 服务器中，从而实现对域名的解析。

基于上述原理，我们可以在 /etc/hosts 文件中添加本地内网的域名解析，从而实现本地内网的域名解析。同时我们还可以使用 Dnsmasq 来为一些特定的域名指定 DNS 服务器，或者阻止某些域名的访问。由于 Dnsmasq 会缓存上游 DNS 服务的查询记录，从而可以提高访问过的网址的连接速度。

默认情况下，Dnsmasq 会从 /etc/dnsmasq.conf 读取配置项，我们也可以使用 -C 的启动参数来指定配置文件。下面介绍一下常用的 DNS 和 DHCP 服务的配置参数。

通用配置项

# 服务运行的网卡，如果有多个话，可在再次添加一条记录
interface=eth1
interface=wlan0
# 指定服务不在以下网卡上运行
except-interface=eth0
# 指定监听的 IP 地址，多个 IP 地址可用 `,` 分割(默认是监听所有网卡)
listen-address=192.168.8.132
# 开启日志选项，记录在 /var/log/debug 中
log-queries
  
# 指定日志文件的路径，路径必须存在，否则会导致服务启动失败
log-facility=/var/log/dnsmasq.log
 
# 异步log，缓解阻塞。
log-async=20

DNS 服务配置参数

# 指定 DNS 服务的端口（默认53），设置为 0 表示关闭 DNS 服务，只使用 DHCP 服务
port=53
# 指定一个 hosts 文件，默认是从 /etc/hosts 中获取
addn-hosts=/etc/banner_add_hosts
# 表示不使用 /etc/hosts 配置文件来解析域名
no-hosts
# 指定上游 DNS 服务列表的配置文件，默认是从  /etc/resolv.conf 中获取
resolv-file=/etc/dnsmasq.d/upstream_dns.conf
# 表示严格按照上游 DNS 服务列表一个一个查询，否则将请求发送到所有 DNS 服务器，使用响应最快的服务器的结果
strict-order
# 不使用上游 DNS 服务器的配置文件 /etc/resolv.conf 或者 resolv-file 选项
no-resolv
# 不允许 Dnsmasq 通过轮询 /etc/resolv.conf 或者其他文件来动态更新上游 DNS 服务列表
no-poll
# 表示对所有 server 发起查询请求，选择响应最快的服务器的结果
all-servers
# 指定 dnsmasq 默认查询的上游服务器
server=8.8.8.8
server=114.114.114.114
# 指定 .cn 的域名全部通过 114.114.114.114 这台国内DNS服务器来解析
server=/cn/114.114.114.114
# 给 *.apple.com 和 taobao.com 使用专用的 DNS
server=/taobao.com/223.5.5.5
server=/.apple.com/223.6.6.6
# 增加一个域名，强制解析到所指定的地址上，dns 欺骗
address=/taobao.com/127.0.0.1
# 设置DNS缓存大小(单位：DNS解析条数)
cache-size=500

/etc/resolv.conf 文件样例

1 2	nameserver 114.114.114.114 nameserver 8.8.8.8

/etc/hosts 文件样例

1
2
3

127.0.0.1         localhost 
192.168.101.107   web.gz.cvte.com web01
192.168.101.103   hrm.gz.cvte.com web02

DHCP 服务配置参数

# 指定分配的 IP 端和续约时间
dhcp-range=192.168.1.50,192.168.1.100,12h
# 同上，指定了子网掩码
dhcp-range=192.168.8.50,192.168.8.150,255.255.255.0,12h
# 指定网关地址
dhcp-option=3,192.168.0.1
# 指定 DNS 服务器，net:eth1 用来指定网卡
dhcp-option=net:eth1,6,114.114.114.114，8.8.8.8
dhcp-option=net:wlano,6,114.114.114.114，8.8.8.8
# DHCP 所在的 domain
domain=gz.cvte.com
# 静态地址绑定
dhcp-host=00:0C:29:5E:F2:6F,192.168.1.201,os02
dhcp-host=00:0C:29:15:63:CF,192.168.1.202,os03
# 忽略一下 MAC 地址主机的请求
dhcp-host=11:22:33:44:55:66,ignore
# 租期保存文件
dhcp-leasefile=/var/lib/dnsmasq/dnsmasq.leases

dhcp-option 常用取值及含义

option	option 作用
1	设置子网掩码选项
3	设置网关地址选项
6	设置DNS服务器地址选项
12	设置域名选项
15	设置域名后缀选项
33	设置静态路由选项。该选项中包含一组有分类静态路由（即目的地址的掩码固定为自然掩码，不能划分子网），客户端收到该选项后，将在路由表中添加这些静态路由。如果存在Option121，则忽略该选项
44	设置NetBios服务器选项
46	设置NetBios节点类型选项
50	设置请求IP选项
51	设置IP地址租约时间选项
52	设置Option附加选项
53	设置DHCP消息类型
54	设置服务器标识
55	设置请求参数列表选项。客户端利用该选项指明需要从服务器获取哪些网络配置参数。该选项内容为客户端请求的参数对应的选项值
58	设置续约T1时间，一般是租期时间的50%
59	设置续约T2时间。一般是租期时间的87.5%
60	设置厂商分类信息选项，用于标识DHCP客户端的类型和配置
61	设置客户端标识选项
66	设置TFTP服务器名选项，用来指定为客户端分配的TFTP服务器的域名
67	设置启动文件名选项，用来指定为客户端分配的启动文件名
77	设置用户类型标识
121	设置无分类路由选项。该选项中包含一组无分类静态路由（即目的地址的掩码为任意值，可以通过掩码来划分子网），客户端收到该选项后，将在路由表中添加这些静态路由
148	EasyDeploy中Commander的IP地址
149	SFTP和FTPS服务器的IP地址
150	设置TFTP服务器地址选项，指定为客户端分配的TFTP服务器的地址

dhcp-option 遵循RFC 2132（Options and BOOTP Vendor Extensions)，可以通过 dnsmasq –help dhcp 来查看具体的配置很多高级的配置，如 iSCSI 连接配置等同样可以由 RFC 2132 定义的 dhcp-option 中给出。

参考资料

WebRTC iOS&OSX 库的编译

2017-05-12T05:04:36.000Z

安装 Depot_tools

git 命令获取 depot_tools：

1	$ git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git

配置坏境变量

1 2	$ echo "export PATH=$PWD/depot_tools:$PATH" > $HOME/.bash_profile $ source $HOME/.bash_profile

检测配置是否成功

1	$ echo $PATH

安装 ninja

ninja 是 WebRTC 的编译工具，我们需要对其进行编译，步骤如下：

1
2
3

$ git clone git://github.com/martine/ninja.git
$ cd ninja/
$ ./bootstrap.py

复制到系统目录（也可配置坏境变量）

1 2	$ sudo cp ninja /usr/local/bin/ $ sudo chmod a+rx /usr/local/bin/ninja

下载源代码

WebRTC 源码托管在 Google Source ，在 Release Notes 中选择需要的版本，这里选择最新的 M57 版本

设置要编译的平台到环境变量中：

1	$ export GYP_DEFINES="OS=ios"

不同机型的编译参数：

# 32位真机
$ export GYP_DEFINES="OS=ios target_arch=arm"
# 64位真机
$ export GYP_DEFINES="OS=ios target_arch=arm64"
# 32位模拟器
$ export GYP_DEFINES="OS=ios target_arch=ia32"
# 64位模拟器
$ export GYP_DEFINES="OS=ios target_arch=x64"
# OSX
$ export GYP_DEFINES="OS=mac target_arch=x64"
# 配置输出路径
$ export GYP_GENERATOR_FLAGS="output_dir=out_xxx"

创建工作路径并执行下面的语句：

1 2	$ fetch --nohooks webrtc_ios $ gclient sync -r 52b6562a10b495cf771d8388ee51990d56074059 --force

上面的 commit id 是 M57 版本最后一次 commit id，可以从 Release Notes 中找到，可替换成自己所需的版本的 commit id 或者直接使用最新的 commit id

执行上述命令就会去下载对应的 WebRTC 的源码、构建工具链以及依赖的第三方库，由于是国外网站，并且是 Google，请自备梯子，我这边翻墙后大概 2 个小时就下完了源码。

编译库文件

iOS 版本的编译

ninja 是 WebRTC 的编译平台，iOS 版本我们可以使用自带的编译脚本，这样就不需要自己编译和安装 ninja，默认情况行，脚本会编译 3 个平台机型的库文件，以及一个各个平台的集合库，脚本也可以指定编译成 .a 的库文件或者 .framework，命令如下：

1 2	$ cd src/webrtc/build/ios/ $ ./build_ios_libs.sh

不同的版本，编译脚本的路径会有不一样。编译完成后，如果没有指定输出路径，则会在 out_ios_libs 目录下生成所需要的 WebRTC.framework，子目录中会有对应平台单独的 WebRTC.framework，根目录下的则支持所有平台，目录结构如下：

drwxr-xr-x   3 Enki  staff   102  5  9 16:49 WebRTC.dSYM/		[符号表文件]
drwxr-xr-x   6 Enki  staff   204  5  9 16:49 WebRTC.framework/	[支持所有平台]
drwx------  14 Enki  staff   476  5  9 16:39 arm64_libs/		[真机 64 位]
drwx------  14 Enki  staff   476  5  9 16:30 arm_libs/			[真机 32 位]
drwx------  14 Enki  staff   476  5  9 16:49 x64_libs/			[模拟器 64 位]

Mac 版本的编译

下载源码：

1
2
3

$ export GYP_DEFINES="OS=mac"
$ fetch --nohooks webrtc_ios
$ gclient sync -r 52b6562a10b495cf771d8388ee51990d56074059 --force

Mac 没有现成的编译脚本，我们只能通过 gn 来生成对应的 ninja 编译脚本，然后通过 ninja 脚本来编译，用如下命令来生成对应的 ninja 项目文件：

1	$ gn gen out/mac_x64 --args='target_os="mac" target_cpu="x64" is_component_build=false'

可以添加 –ide=xcode 参数来生成 Xcode 的项目文件，使用 Xcode 来进行编译。

编译源码：

1	$ ninja -C out/mac_x64 rtc_sdk_objc

上述命令 out/mac_x64 则是 ninja 项目文件的路径，rtc_sdk_objc 则是要编译的目标，可以通过以下命令来查看目标列表：

1	$ gn ls out/mac_x64

其他平台源码下载

Windows

1 2	$ fetch --nohooks webrtc $ gclient sync

Linux

1
2
3

$ export GYP_DEFINES="OS=linux"
$ fetch --nohooks webrtc_android
$ gclient sync

Windows 和 Linux 都使用 ./build/install-build-deps.sh 脚本进行编译即可。

Android

1
2
3

$ export GYP_DEFINES="OS=android"
$ fetch --nohooks webrtc_android
$ gclient sync

Android 使用 ./build/install-build-deps-android.sh 脚本进行编译。

生成 Example 并运行

执行以下命令，用于生成 ninja 的编译脚本：

1	$ gn gen out/mac_x64 --args='target_os="mac" target_cpu="x64" is_component_build=false'

用以下命令可用来编译并生成可执行的二进制文件：

1	$ ninja -C out/mac_x64 AppRTCMobile

执行之后可在 out/mac_x64 目录生成可执行的 AppRTCMobile 文件，双击即可运行。效果如下图：

通过修改 --args='target_os="mac" target_cpu="x64" 参数来生成其他平台的 Example。

参考资料

iOS 运行时之消息转发机制

2017-04-21T06:49:54.000Z

今天写一篇老生常谈的话题 —— Objective-C 的消息转发机制。Objective-C 下所有的方法调用都可以理解为，给一个对象发送一个消息。一个对象接收到消息后，会从当前类的方法列表或者父类的方法列表查找到对应的方法实现（IMP）来处理该消息。大致流程如下：

通过 NSObject 的 isa 指针找到对应的 Class
在 Class 的方法列表中找到对应的 selector
如果在当前 Class 中未能找到 selector 则往父类的方法列表中继续查找
如果能找到对应的 selector 则去执行对象的方法实现（IMP）

在上述流程中如果不能找对对应的 selector 时，这时候就会进入消息转发机制。消息转发机制可分为两个阶段，在这两个阶段中，有 3 次机会来处理之前未能处理 selector，越往后所花费的代价将越大，处理的灵活程度也就越高。如下图所示：

第一阶段

第一阶段也可称之为 动态方法解析 阶段，在该阶段中，可以动态的为类添加一个方法，从而让动态添加的方法来处理之前未能处理的消息。可重写类以下方法：

1	+ (BOOL)resolveInstanceMethod:(SEL)sel

如果是类的静态方法，可重写以下方法：

1	+ (BOOL)resolveClassMethod:(SEL)sel

SEL 就是未能处理的 selector，返回值为 BOOL 表示是否增加了新的方法来处理该 selector。在当前阶段处理未知 selector 的前提是，你已经准备好了新的方法来处理该 selector，等着运行时将方法动态添加到类中即可，该阶段一般用来实现 @dynamic 属性。

第二阶段

如果在第一该阶段中为能处理未知的 selector，运行时将进入第二阶段消息的转发，在该阶段中我们可以将未知的 selector 转发给其他对象来处理。运行时提供两次机会，来做消息的转发，第一次是重写以下方法：

1	- (id)forwardingTargetForSelector:(SEL)aSelector

该方法的 SEL 就是未能处理的 selector，返回值类型为 id 用来指定 selector 处理的对象，运行时将会把未能处理的 SEL 转发给该对象。该阶段我们可以将 selector 转发到类中的其他对象来处理，从而实现 代理模式。如果不重写该方法，运行时将把方法调用的所有细节封装到 NSInvocation 对象中，进入完整的消息转发机制中，运行时将继续调用一下方法来进行消息的派发：

1 2	- (NSMethodSignature )methodSignatureForSelector:(SEL)aSelector - (void)forwardInvocation:(NSInvocation )anInvocation

方法中的 NSInvocation 参数，包含了所有方法调用的细节，包括 selector/target/参数 等，重写该方法后我们可以将 anInvocation 转发给多个对象来处理该消息。在该阶段我们可以用来实现 “多重继承” 或者多重代理等。

如果在两个阶段都不做任何处理的话，运行时将会把 selector 交由 doesNotRecognizeSelector 方法来处理，从而抛出异常导致 Crash ，异常信息一般如下：

1	-[* ]:unrecognized selector sent to instance 0x****

重写 respondsToSelector 方法

Objective-C 中 respondsToSelector 方法可以用检查类对象是否能够处理对应的 selector，当我们通过消息转发机制来处理 selector 时， respondsToSelector 并不能按原意正常工作了，这时候需要重写类的 respondsToSelector 方法，用来告诉方法调用者对应的 selector 是能够被处理的。如果是在 动态方法解析 阶段使用 class_addMethod 来为类动态添加方法，则不需要重写 respondsToSelector 。

消息转发特性的应用场景

为 @dynamic 实现方法

使用 @synthesize 可以为 @property 自动生成 getter 和 setter 方法（现 Xcode 版本中，会自动生成），而 @dynamic 则是告诉编译器，不用生成 getter 和 setter 方法。当使用 @dynamic 时，我们可以使用消息转发机制，来动态添加 getter 和 setter 方法。当然你也用其他的方法来实现。

代理模式实现

看完 Objective-C 的消息转发机制，相信很多朋友都能想到 代理模式。对 代理模式 不熟悉或者不明白的应用场景的同学，可以自行去学习一下 代理模式。同时 Objective-C 提供了 NSProxy 类可以用来做动态代理。

多重继承

学过 C++ 的同学都支持，C++ 是支持多继承的，子类可以从多个类继承，从而获得多个类所有的特性。在消息转发的最后一次处理机会中，运行时会产生一个 NSInvocation 对象，进入到完整的消息转发机制中，在该流程中我们将 selector 转发到不同的对象中处理，便可以达到 “多重继承” 的特性。做法是在类的构造方法中，构造一个或者多个需要继承的对象，将未能处理的 selector 转发到对应的对象中处理即可。

样例代码在这里

小结

当接收无法处理的 selector 时，则进入消息转发流程
消息转发流程可分为两阶段，一共有 3 次机会来处理未知的 selector
第一阶段为 动态方法解析 阶段，用来为类动态添加方法，第二阶段才是正在的消息转发阶段，该阶段可以将未知的 selector 转发到一个或者多个对象中来处理
消息转发流程完成后，都不做任何处理的话，这进入 doesNotRecognizeSelector 方法从而抛出异常
如果将消息转发到其他对象来处理，则需要重写 respondsToSelector 方法来保证该方法正常工作
NSProxy 类是基于消息转发机制来实现的动态代理模式
消息转发机制可用来实现 @dynamic 属性、代理模式、多重继承等

iOS 运行时之 Associative(关联)

2017-02-18T04:42:00.000Z

iOS 下有很多运行时特性，这里介绍一下 Associative(关联) 这个运行时特性，以及它一些使用场景。Associative 意思为关联，能够将两个对象建立一种关系。这种关系是一种 从属 关系，也就是说有一个 关联者 和一个 被关联者。比如说我们可以将一个 NSString 对象关联到一个 UIView 对象上。这里的 NSString 对象就是 被关联者, UIView 对象就是 关联者。

在 objc/runtime.h 文件中，找到 Associative 相关的 API 定义，如下：

/** 
 * Sets an associated value for a given object using a given key and association policy.
 * 
 * @param object The source object for the association.
 * @param key The key for the association.
 * @param value The value to associate with the key key for object. Pass nil to clear an existing association.
 * @param policy The policy for the association. For possible values, see “Associative Object Behaviors.”
 * 
 * @see objc_setAssociatedObject
 * @see objc_removeAssociatedObjects
 */
OBJC_EXPORT void objc_setAssociatedObject(id object, const void *key, id value, objc_AssociationPolicy policy)
    OBJC_AVAILABLE(10.6, 3.1, 9.0, 1.0);
/** 
 * Returns the value associated with a given object for a given key.
 * 
 * @param object The source object for the association.
 * @param key The key for the association.
 * 
 * @return The value associated with the key \e key for \e object.
 * 
 * @see objc_setAssociatedObject
 */
OBJC_EXPORT id objc_getAssociatedObject(id object, const void *key)
    OBJC_AVAILABLE(10.6, 3.1, 9.0, 1.0);
/** 
 * Removes all associations for a given object.
 * 
 * @param object An object that maintains associated objects.
 * 
 * @note The main purpose of this function is to make it easy to return an object 
 *  to a "pristine state”. You should not use this function for general removal of
 *  associations from objects, since it also removes associations that other clients
 *  may have added to the object. Typically you should use \c objc_setAssociatedObject 
 *  with a nil value to clear an association.
 * 
 * @see objc_setAssociatedObject
 * @see objc_getAssociatedObject
 */
OBJC_EXPORT void objc_removeAssociatedObjects(id object)
    OBJC_AVAILABLE(10.6, 3.1, 9.0, 1.0);

同时还提供以下枚举类型的定义：

/**
 * Policies related to associative references.
 * These are options to objc_setAssociatedObject()
 */
typedef OBJC_ENUM(uintptr_t, objc_AssociationPolicy) {
    OBJC_ASSOCIATION_ASSIGN = 0,           /**< Specifies a weak reference to the associated object. */
    OBJC_ASSOCIATION_RETAIN_NONATOMIC = 1, /**< Specifies a strong reference to the associated object. 
                                            *   The association is not made atomically. */
    OBJC_ASSOCIATION_COPY_NONATOMIC = 3,   /**< Specifies that the associated object is copied. 
                                            *   The association is not made atomically. */
    OBJC_ASSOCIATION_RETAIN = 01401,       /**< Specifies a strong reference to the associated object.
                                            *   The association is made atomically. */
    OBJC_ASSOCIATION_COPY = 01403          /**< Specifies that the associated object is copied.
                                            *   The association is made atomically. */
};

API 解析

void objc_setAssociatedObject(id object, const void *key, id value, objc_AssociationPolicy policy) API 为我们提供了将两个对象建立关联关系的能力，参数解析为：

id object：指定 关联者
id value：指定 被关联者
const void *key：被关联者 的 KEY 值，方便后续可以通过该 KEY 值找到该 被关联者
objc_AssociationPolicy policy: 该参数作用用来表示 被关联者 的引用策略，也就是内存如何进行管理的，可通过上述定义的枚举类型来设置。

id objc_getAssociatedObject(id object, const void *key) API 可以通过之前设置的 KEY 值，来获取 被关联者 对象，参数解析如下：

id object：关联者 对象
const void *key：要获取的 被关联者 的 KEY 值，一个 关联者 可以被关联多对象，一个 关联者 也可以是 被关联这，可以通过不同的 KEY 来获取不同的 被关联者 对象。

void objc_removeAssociatedObjects(id object) 该 API 可以移除一个 关联者 对象所有的 被关联者。当需要移除特定的对象时，我们可以使用 objc_setAssociatedObject 方法并指定 id value 参数对象为空即可。

以上就是关于 Associative(关联) 特性相关的 API 介绍了，下面介绍一下常用的使用场景。

Associative 特性的应用

剪切板的信息复制

在一些时候我们希望用户可以长按文案信息，弹出系统的复制菜单，提供文案信息的复制功能，比如长按 UITableViewCell 提供复制详情的功能，在 iOS 下我们可以使用 UIMenuController 类来显示系统菜单，同时为该 UITableViewCell 添加长按手势，代码如下：

// 添加长按手势
UILongPressGestureRecognizer *longPressGR = [[UILongPressGestureRecognizer alloc] initWithTarget:self action:@selector(handleLongPress:)];
[cell addGestureRecognizer:longPressGR];
// 手势处理
- (void)handleLongPress:(UILongPressGestureRecognizer *) longPressGR {
    UIMenuController *menu = [UIMenuController sharedMenuController];
    [menu setTargetRect:longPressGR.view.frame inView:self.view];
    [menu setMenuVisible:YES animated:YES];
}
// UIMenuController 相关
- (BOOL)canBecomeFirstResponder {
    return YES;
}
- (BOOL)canPerformAction:(SEL)action withSender:(id)sender {
    if ( action == @selector(copy:) ) {
        return YES;
    }
    return NO;
}
- (void)copy:(UIMenuController *)menu {
    UIPasteboard *pasteboard = [UIPasteboard generalPasteboard];
}

从上述代码可以看到，复制信息的逻辑处理是在 copy: 方法中，但是在该方法中，并不能访问到 cell.detailTextLabel 对象，在该场景中，我们可以使用 Associative 特性将 UITableViewCell 对象关联到 UIMenuController 对象中，再在 copy: 方法中获取到被关联对象，从而获取到 UITableViewCell 对象，进而访问 cell.detailTextLabel.text。添加代码如下：

// 处理手势时，添加如下代码
objc_setAssociatedObject(menu, @"UITableViewCell", longPressGR.view, OBJC_ASSOCIATION_RETAIN_NONATOMIC);
// 处理 copy 时，添加如下代码，来获取被关联的 UITableViewCell 对象
objc_getAssociatedObject(menu, @"UITableViewCell");
pasteboard.string = cell.detailTextLabel.text;

上述场景中，并不一定非得用 Associative 特性来实现，还有很多可行的方法，这里为大家提供一种方法，并且该方法还算是比较优雅的。

其他一些应用场景

另一个常见的应用场景就是，为一个系统类或是一个第三方的类添加一个属性时，可以结合 Category 为类添加一个属性，当然也可以使用继承来达到目的。在一些特殊场景下，比如想知道一个系统内部对象或者第三方对象是何时被释放时，我们可以为该对象关联一个自定义的对象，并且使用 OBJC_ASSOCIATION_RETAIN_NONATOMIC 来指定内存管理策略，当关联者被释放是，被关联者也会跟着被释放，这样可以在我们自定义的对象中，知道感兴趣的对象何时被释放的。在调试一些内存问题时，该方法还是蛮有用的。

Protocol Buffer 简介与使用

2017-02-17T06:58:27.000Z

Protocol Buffer(简称Protobuf或PB)是由 Google 开发的，原本用来解决索引服务器的请求、响应协议，后面才对外使用和开源的，它是一种数据交换格式，与 XML 和 JSON 相比，它是一种二进制格式，避免了各种文本格式转换的问题，并且更体积更小、速度更快使用更简单方便，还自带部分数据压缩功能，在网络传输时可以减少数据流量。同时它也是与平台和语言无关的，尤其在网络数据交换方面，使得它越来越流行。

Protobuf 是一个开源项目，项目托管在 GitHub 上，链接为:https://github.com/google/protobuf，源码包含两部分内容：

PB基础库：用来完成对象模型与数据模型之前的转换
PB编译器：源码生成器，用来将 .proto 文件转换成对应语言的对象模型的源码

Protobuf 截止目前最新版本为 3.2.0-alpha-1 版本，在 3.0.0 版本之前也就是 2.6.1 版本时官方只支持 C++/Java/Python 三种语言，3.0.0 版本之后才逐步支持其他语言。在这之前如果其他语言需要用到 Protobuf 都是通过第三方扩展来实现的，目前官方以及支持以下编程语言：

Language	Source
C++ (include C++ runtime and protoc)	src
Java	java
Python	python
Objective-C	objectivec
C#	csharp
JavaNano	javanano
JavaScript	js
Ruby	ruby
Go	golang/protobuf
PHP	php

备注：后续将使用最新版本3.2.0-alpha-1以及 Objective-C 语言作为示例

Protobuf 编译器

Protobuf 编译器在于将 .proto 文件转成对应语言的对象模型的源代码，可以从 GitHub 上下载源代码在本地进行编译，然后生成 Protobuf 编译器，也可以从 GitHub 上下载已经编译好的编译器。

下载链接为：https://github.com/google/protobuf/releases

如果是源码的话需要确保一下工具已经安装：

1	autoconf automake libtool curl make g++ unzip

执行以下几个步骤进行编译和安装：

# 生成 configure 文件
$ ./autogen.sh
# 配置 makefile
$ ./configure
# 编译
$ make
$ make check
# 安装编译后的二进制文件
$ sudo make install

如果出现 /usr/local/Cellar/../Library/ENV/4.3/sed: No such file or directory 错误可以尝试使用 brew reinstall libtool 重新安装 libtool

如果编译成功，就可以使用 proto 命令了，如果是直接下载的 proto 文件，就不需要编译可直接运行。我们可以创建一个 .proto 文件来测试一下环境是否搭建好，样例文件如下：

message User
{
  required int32 uid = 1;        // 用户唯一标识
  required string nickname = 2;  // 用户昵称
  required int32 age = 3;        // 用户年龄
}

如果需要生成 Objective-C 源文件的话，执行以下命令即可：

1	protoc --objc_out=./ ./test.proto

如果环境正常的话，可以在当前目录下生成 Test.pbobjc.h 和 Test.pbobjc.m 两个文件，由于 Protobuf 编译器生成的 Objective-C 源文件是基于 MRC 的，所以如果在 ARC 工程成需要添加 -fno-objc-arc 标签，否则无法通过编译。

Protobuf 基础库

Protobuf 基础库是用来做对象的序列化以及反序列化用的库，也可以从以下地址下载基础库的载源码：

下载链接为：https://github.com/google/protobuf/releases

将下载好的源码拖到对应的工程中即可，同样需要注意的是基础库的源码也是基于 MRC 的，所以也得添加 -fno-objc-arc 标签。同时必须保证基础库和编译器的版本一致，否则也会导致工程无法正常编译。

基础库在 iOS 项目中也可以使用 cocoapods 方式引入，只要在 Podfile 中添加：

1
2
3

# 当前工程支持的 SDK 版本
platform :ios, '7.1'
pod 'Protobuf', '~> 3.1.0'

在项目中使用 Protobuf

将编译器生成的对象的源文件以及基础库导入到工程后，我们就可以使用它们了，示例如下：

// 创建一个 User 对象
User *user = [[User alloc] init];
user.uid = 10086;
user.nickname = @"EnkiChen";
user.age = 28;
    
// 序列化为 Data
NSData *data = [user data];
    
// 反序列化为对象
User *us = [User parseFromData:data error:NULL];
NSLog(@"uid:%d nickname:%@ age:%d", us.uid, us.nickname, us.age);

Protobuf 的优缺点

优点

性能好/效率高：相比于 XML 和 JSON 而言，Protobuf 序列化反序列化速度很快，生成的数据体积更小，适合网络传输
有代码生成机制：可以由编译器自动生成对应语言的类对象文件，无需自己编写解析代码
支持向后/向前兼容：所谓的“向后兼容”（backward compatible），就是说，当模块 B 升级了之后，它能够正确识别模块 A 发出的老版本的协议。所谓的“向前兼容”（forward compatible），就是说，当模块A升级了之后，模块 B 能够正常识别模块 A 发出的新版本的协议。
支持多种语言跨平台：如上文所提到，官方已经支持多种主流语言，并且跨平台

缺点

可读性差：相对于 XML 和 JSON 而言，对象序列化后生成的数据可读性差（二进制格式）
缺乏自描述：XML 和 JSON 是自描述的，而 Protobuf 格式则不是。一段 Protobuf 格式的二进制数据内容，不配合 .proto 文件结构体是看不出来什么作用的。

对于 .proto 文件的编写规则及语法等内容就不介绍了，后续有时间再补上。

HTTP 之 Content-Type

2016-08-29T12:27:25.000Z

在移动端开发中 HTTP 协议经常被用到，但是在面试或者工作中问到客户端和服务器传输业务数据，使用的数据的封装格式是什么以及怎么被封装到 HTTP 协议中时，很少有人能讲明白。

在移动开发中 HTTP 协议为客户端到服务器端，提供了一条数据通道，能够将我们的业务数据传输到服务器，并且从服务器上获取响应数据。在 HTTP 协议头中的 Content-Type 字段描述了 HTTP 的 BODY 体的数据格式，而在 BODY 中可以定义我们业务数据的数据格式。Content-Type 字段可以用很多种类型，具体有哪些可以看这里，并且也可以根据自身业务来自定义，不过这种做法比较少。这次我主要讲解三种格式分别为 application/x-www-form-urlencoded、application/json 以及 multipart/form-data，其他的格式可以自己理解。

下面给各位吃瓜群众介绍上述三种格式在 GET 和 POST 两种请求方法中的区别，为了更直观的看到我们的数据的组织方式，我使用了 Charles 来进行抓包分析。

我们测试的业务需求为：

客户端发起登录请求，服务器进行响应，请求的数据为 user 字段值为 admin； pass 字段值为 123456；
客户端上传一张图片到服务器，字段名为 imageFile，内容为图片的二进制数据。

为了更好的测试，我对 Web 的请求基于 AFNetworking 2.5.0 版本做了一层简单的封装，发起请求的代码：

- (void)webRequest
{
    NSDictionary *bParams = @{ @"user" : @"admin",
                               @"pass" : @"123456"};
    
    NSDictionary *params = @{ kWebServiceMethod     : @"POST",
                              kWebServiceParams     : bParams,
                              kWebServiceIdentifier : kPlatformAccountService,
                              kWebServiceApiUrl     : @"login"};
    
    [CMLWebProxyService webRequestWithParam:params completionHandler:^(NSURLResponse *response, id responseObject, NSError *error) {
        DDLogInfo(@"responseObject:%@", responseObject);
    }];
}

用来指定数据格式的代码封装在了叫 BaseService 的类中，方法如下：

- (NSString *)apiContentType
{
    return @"application/x-www-form-urlencoded";
}

Web 请求的封装的代码（基于 AFNetworking 2.5.0 版本）

+ (NSURLSessionDataTask *)webRequestWithParam:(NSDictionary *) params completionHandler:(void (^)(NSURLResponse *response, id responseObject, NSError *error)) completionHandler
{
    id service = [[CMLServiceFactory sharedInstance] serviceWithIdentifier:params[kWebServiceIdentifier]];
    NSString *urlString = [NSString stringWithFormat:@"%@%@/%@", service.apiBaseUrl, service.apiVersion, params[kWebServiceApiUrl]];
    AFHTTPRequestSerializer *requestSerializer = nil;
    
    if ( [service.apiContentType isEqualToString:@"application/x-www-form-urlencoded"] ) {
        
        requestSerializer = [AFHTTPRequestSerializer serializer];
        
    } else if ( [service.apiContentType isEqualToString:@"application/json"] ) {
        
        requestSerializer = [AFJSONRequestSerializer serializer];
    }
    
    [requestSerializer setValue:@"application/json" forHTTPHeaderField:@"Accept"];
    requestSerializer.timeoutInterval = kWebServiceTimeoutInterval;
    
    NSDictionary *headParams = params[kWebServiceHeadParams];
    [headParams enumerateKeysAndObjectsUsingBlock:^(id  _Nonnull key, id  _Nonnull obj, BOOL * _Nonnull stop) {
        [requestSerializer setValue:obj forHTTPHeaderField:key];
    }];
    
    NSURLRequest *request = nil;·
    NSArray *binParams = params[kWebServiceBinParams];
    if ( binParams != nil && binParams.count != 0 ) {
        request = [requestSerializer multipartFormRequestWithMethod:params[kWebServiceMethod]
                                                          URLString:urlString
                                                         parameters:params[kWebServiceParams]
                                          constructingBodyWithBlock:^(id formData) {
                                              
                                              for ( NSDictionary *binData in binParams ) {
                                                  [formData appendPartWithFileData:binData[kWebBinData]
                                                                              name:binData[kWebBinName]
                                                                          fileName:binData[kWebBinFileName]
                                                                          mimeType:binData[kWebBinMimeType]];
                                              }
                                              
                                          } error:nil];
    } else {
        request = [requestSerializer requestWithMethod:params[kWebServiceMethod] URLString:urlString parameters:params[kWebServiceParams] error:nil];
    }
    
    NSURLSessionDataTask *dataTsk = [[CMLWebProxyService sessionManager] dataTaskWithRequest:request completionHandler:completionHandler];
    
    [dataTsk resume];
    
    return dataTsk;
}

POST 下的数据组织形式

先看看各个格式的抓包的截图，在做对比分析。

application/x-www-form-urlencoded 格式的抓包截图

application/json 格式的抓包截图

multipart/form-data 格式的请求代码以及抓包的截图：

NSDictionary *bParams = @{ @"user" : @"admin",
                              @"pass" : @"123456"};
   
   NSData *imageBin = UIImagePNGRepresentation([UIImage imageNamed:@"avatar_cat"]);
   
   NSDictionary *binPar = @{ kWebBinData : imageBin,
                             kWebBinName : @"imageFile",
                             kWebBinFileName : @"image.png",
                             kWebBinMimeType : @"image/png"
                            };
   
   NSDictionary *params = @{ kWebServiceMethod     : @"POST",
                             kWebServiceParams     : bParams,
                             kWebServiceBinParams  : @[binPar],
                             kWebServiceIdentifier : kPlatformAccountService,
                             kWebServiceApiUrl     : @"login"};

application/x-www-form-urlencoded 格式对请求参数进行了 URL 编码 并将参数放在了 BODY 中；application/json 格式是将参数进行了 JSON 格式的转换，放在了 BODY 中；

前两种都是传的普通的文本数据，如果我们需要同时传输文本数据以及二进制数据时，就得用到 multipart/form-data 编码格式了，可以从图中看到在 HTTP 的头部的 Content-Type 中多了 Boundary 字段，该字段的作用为对多项数据进行分割；截图中 3 个参数都使用了指定的字符串进行了分割，在图片的那一项中也包含了 Content-Type 字段用来描述该项的数据格式为 PNG 图片。如果没有图片参数的话，也可以直接使用 multipart/form-data 格式来进行组织。

用来分割的字符串的值是每次随机生成的。不同的客户生成的字符串长度也会不一样。

GET 下的数据组织形式

HTTP 的 GET 请求方式，是将我们要请求的参数放在 URL 地址后面，所以 GET 方式只支持 application/x-www-form-urlencoded 格式，而 application/json 和 multipart/form-data 不支持的，这个应该比较容易理解。下面是我抓包的截图：

总结

其实抓包截图做对比就很容易理解不同的参数的意义了，在很多情况下后端和前端开发人员都是使用成熟的第三方框架来帮我们做这部分工作，对 HTTP 协议了解的还不够细致，有时候发现在调试接口无法解析数据，其实很有可能 Content-Type 类型不一致导致的。如果觉得文本协议不够精简，也可以使用二进制协议来传输 user 和 pass 字段，比如 protobuf ，只要和服务器端协商好就可以。

两则开发小笔记

2016-07-22T06:22:53.000Z

好久没有写博客了，介绍一下项目中一个 Core Graphics 绘制图片时的效率优化方法，以及记录一下 GCDAsyncSocket 框架在读取网络数据要注意的一个点。

Core Graphics 绘图性能对比

Core Graphics 框架为我们提供了 2D 绘图能力，在使用 Core Graphics 绘制图片时，不同的实现方法使得渲染图片的效率有很大差异，下面是提供两种不同实现方式的对比，看看 Core Graphics 在绘制图片时效率上的差异。

测试方法为自定义一个 UIView，重写- (void)drawRect:(CGRect)rect 方法，在该方法中使用 Core Graphics 方式绘制图片。然后在开启一个定时器不断的调用 - (void)setNeedsDisplay; 方法来计算绘图所使用的时间。

方法一

- (void)awakeFromNib {
    self.coreImage = [UIImage imageNamed:@"IMG_0079.png"];
}
- (void)drawRect:(CGRect)rect {
    struct timeval start , end ;
    gettimeofday(&start, NULL);
    [self.coreImage drawAtPoint:CGPointZero];
    // [self.coreImage drawInRect:CGRectMake(0, 0, 512, 512)];
    gettimeofday(&end, NULL);
    long cost = ((end.tv_sec - start.tv_sec) * 1000000 + end.tv_usec - start.tv_usec ) / 1000 ;
    NSLog(@"cost:%ld", cost);
}

方法二

- (void)awakeFromNib {
    self.coreImage = [UIImage imageNamed:@"IMG_0079.png"];
    CGSize size = self.frame.size;
    UIGraphicsBeginImageContextWithOptions(size, NO, 0.0);
    [self.coreImage drawInRect:CGRectMake(0, 0, size.width, size.height)];
    self.coreImage = UIGraphicsGetImageFromCurrentImageContext();
    UIGraphicsEndImageContext();
}
- (void)drawRect:(CGRect)rect {
    struct timeval start , end ;
    gettimeofday(&start, NULL);
    [self.coreImage drawAtPoint:CGPointZero];
    // [self.coreImage drawInRect:CGRectMake(0, 0, 512, 512)];
    gettimeofday(&end, NULL);
    long cost = ((end.tv_sec - start.tv_sec) * 1000000 + end.tv_usec - start.tv_usec ) / 1000 ;
    NSLog(@"cost:%ld", cost);
}

使用 [self.coreImage drawInRect:CGRectMake(0, 0, 512, 512)]; 方法来进行图片的缩放，大小可自定义，只要跟图片本身大小不一致即可。

对比结果

方法	是否缩放	耗时时间
方法一	NO	10ms ~ 20ms
方法一	YES	100ms ~ 120ms
方法二	NO	1ms ~ 2ms
方法二	YES	30ms ~ 40ms

我测试的手机为 iPhone 6 机型，图片为 iPhone 拍摄的照片，上表的中耗时时间跟图片以及机器有关，看对比结果即可；从对比结果可以知道如果在绘制时绘制的大小跟图片本身大小不一致时，系统会对其进行缩放，从而导致绘制效率变低，如果我们提前将图片缩放到指定大小，从而可以提高在绘制时的效率；使用 UIGraphicsGetImageFromCurrentImageContext 之前有看到过一篇文章提到，该方法会将图片缓存到显存中，从而使得绘制效率的提高，不过这篇文章已经找不到了。

在实际项目中可选择合适的方法的进行优化，比如图片过大可以使用方法二进行缩放，同时可以放到子线程中进行处理，从而提供绘制时的效率。我在实际项目中的需求为图片可能进行缩放，所以我针对图片做了两级缓存，缩放后在子线程中生成缩放后的图片，同时在缩放的过程中使用了 OpenGL 进行渲染。

GCDAsyncSocket 读取数据的注意事项

今天一同事使用 GCDAsyncSocket 在测试一个网络程序，发现使用我给的代码，无法接收到数据。代码大概如下：

- (void)push {
    if (!self.asyncSocket) {
        self.asyncSocket = [[GCDAsyncSocket alloc] initWithDelegate:self delegateQueue:dispatch_get_main_queue()];
    }
    
    if (!self.bufferData) {
        self.bufferData = [[NSMutableData alloc] init];
    }
    
    NSError *err = nil;
    if (![self.asyncSocket connectToHost:PUSH_HOST onPort:PUSH_PORT error:&err]) {
        NSLog(@"I goofed: %@", err);
        return;
    }
}
- (void)socket:(GCDAsyncSocket *)sender didConnectToHost:(NSString *)host port:(UInt16)port {
    NSString *contentString = @"data"
    NSData *data = [contentString dataUsingEncoding:NSUTF8StringEncoding];
    [self.asyncSocket writeData:data withTimeout:-1 tag:PUSH_DATA_TAG];
    [self.asyncSocket readDataToLength:100 withTimeout:-1 buffer:self.bufferData bufferOffset:0 tag:PUSH_DATA_TAG];
}
- (void)socketDidDisconnect:(GCDAsyncSocket *)sock withError:(NSError *)err {
    DDLogWarn(@"SocketDidDisconnect:WithError: %@", err);
}
- (void)socket:(GCDAsyncSocket *)sock didReadData:(NSData *)data withTag:(long)tag {
    DDLogWarn(@"socket:didReadData: %ld", tag);
}

代码流程很简单，客户端在连接上服务器上之后，会给服务器发送一段数据，服务器接收到数据后，在返回一个状态码给到客户端，方法使用上都是正常的；服务器在响应客户端之后，会直接断开连接，上述代码在客户端的实际表现为发送数据到服务器之后，直接就收到断开的回调消息了，并没有接收到服务器响应的数据。

经过测试后发现，- (void)readDataToLength:(NSUInteger)length withTimeout:(NSTimeInterval)timeout buffer:(NSMutableData *)buffer bufferOffset:(NSUInteger)offset tag:(long)tag; 一定要接收到指定数据长度后，才会回调对应的方法，而实际服务器返回给到客户端的数据只有两个字节，导致接收数据的方法无法得到回调，就算是连接被断开后也是无法被回调的，导致上层是没办法获取到对应的数据，针对该问题我们可以使用 - (void)readDataWithTimeout:(NSTimeInterval)timeout buffer:(NSMutableData *)buffer bufferOffset:(NSUInteger)offset tag:(long)tag; 来解决该问题。

所以在使用 GCDAsyncSocket 时得要注意使用合适的方法来获取数据，否则会导致特定情况下无法接收数据回调。

Enki's Notes

macOS 开启 Web 服务器

mac 平台 git 命令自动补全

安装 brew

安装 bash-completion

下载 git 源码

配置环境

方差、标准差、均方差、均方误差

同步 WebRTC 主仓库

使用脚本自动同步至 GitHub

Mac OSX 鼠标键盘事件的监听和模拟

事件分发机制

事件响应链

相关类的解析说明

NSResponder

NSEvent

NSEventType

NSEventModifierFlags

事件的监听方法

鼠标事件监听

键盘事件的监听

鼠标键盘事件的模拟

1. 模拟鼠标事件：

2. 模拟鼠标滚动事件

3. 模拟键盘事件

参考资料

H264/SVC Temporal Scalability

编码器的支持

openh264 中 temporal layer 的输出顺序与帧率

RTP 数据包的封装

总结

参考资料

Apple 平台下的 VideoToolBox 框架

VTCompressionSession 编码器

编码器的创建

编码器的参数配置

流配置

缓冲区配置

预期值配置

帧相关

硬件加速

码率控制

运行时

数据的编码

编码器资源释放与销毁

VTDecompressionSession 解码器

解码器的创建

解码器的参数配置

解码器行为

数据的解码

解码器的资源释放以及销毁

基本数据类型

CVPixelBuffer

CMBlockBuffer

CMSampleBuffer

参考资料

C++ 实现的 Dispatch Queue

结构设计

DispatchQueue 抽象类的定义

基于 std::mutex/std::queue 的实现

基于 disruptor 的实现

总结

参考资料

Android 对 C++ Runtime 的支持

图像编码与 H264 基础知识

RGB 颜色模型

YUV 颜色模型与冗余删除

采样率、码率、帧以及场的概念

H264 编码

H264 编解码方法

H264 的编码参数

AVC 与 SVC

分级编码的应用

分级的优缺点

参考资料

iOS 静态库中的 Category 运行时错误

编译/链接过程

解决方案

问题的处理

总结