Rust 学习资源 /2022/01/18/rust-study-resource/ 博主发现咸鱼咸鱼着居然到 2022 年了，忽然良心不安，因此先从这篇比较水的资源总结开始吧！

这篇文章主要是总结下学 Rust 参考过的资料，会随着博主对 Rust 的关注随缘更新。

基础

进阶

有潜力的教程

练习实战的小项目

游戏开发相关

其他领域相关

Rust 动态

各种汇总（Awesome 系列）

Podcast

博客

  • https://llever.com/
    • 包含很多 Rust 周报及相关博文的翻译，不过现在好像不更新了。
  • 芽之家
    • 同样是包含很多 Rust 周报及相关博文的翻译，同样好像不更新了😓

博客 RSS

名称订阅链接
This Week in Rusthttps://this-week-in-rust.org/atom.xml
Read Rusthttps://readrust.net/all/feed.rss
Rust Reddit Hothttps://reddit.0qz.fun/r/rust/hot.json
Rust.cchttps://rustcc.cn/rss
Awesome Rust Weeklyhttps://rust.libhunt.com/newsletter/feed
Rust精选https://rustmagazine.github.io/rust_magazine_2021/rss.xml
Rust on Mediumhttps://medium.com/feed/tag/rust
Rust GameDev WGhttps://gamedev.rs/rss.xml
知乎专栏-时光与精神小屋https://rsshub.app/zhihu/zhuanlan/time-and-spirit-hut
酷熊 Amos fasterthanlihttps://fasterthanli.me/index.xml
pretzelhammer/rust-bloghttps://www.ncameron.org/blog/rss/
Nick Cameronhttps://github.com/pretzelhammer/rust-blog/releases.atom
FOLYDhttps://folyd.com/blog/feed.xml
Alex Chihttps://www.skyzh.dev/posts/index.xml

作为参考的学习路线

各种方法入门

noxasaxon/learning_rust.md

jondot/rust-how-do-i-start

路线1

Rust Study RoadMap

作者在文中提供了两种学习路线。

路线2

  1. 通读 Rust by Example，把其中的例子都自己运行一遍，特别是对其中指出的错误用法也调试一遍。

  2. 通读 The Rust Programming Language，在进行了第一步后，已经基本对 Rust 的常用概念有所了解了，这个时候再读这本官方教程，进一步理解某些细节。

  3. 行了，到这一步后你就可以尝试做一个项目了，然后在做项目的过程中你一定会需要各种各样的库，请到 Crates上搜索，寻找适合你需求的 crate，了解它们的用法，必要时查阅它们的源码。一开始写实际代码时，你肯定会很痛苦，Rust 编译器一定会不断地折磨你，这个时候不要放弃，返回去再看 Rust by Example和The Rust Programming Language，然后终有通过编译的那一刻，恭喜你，入坑了！

常用站点

其他资料

本文参考

]]> Rust 游戏开发 Rust 用 Rust 实现简单的光线追踪 /2021/05/05/rust-raytrace/ 学 Rust 十来天了，自己被这个语言惊艳到，就跟着教程 Ray Tracing in One Weekend 写了个很简陋的光线追踪示例练习，项目在 Latias94/rust_raytracing。

学这门语言的时候，感觉就是上手容易遇到很多新概念，容易学不下去，跟编译器作斗争…不过作为一个还很新的系统编程语言，工具链如文章、包管理、格式化、编译器等很完善，官方教程很棒，社区也很活跃。

学 Rust 的契机其实是在 V2EX 上看到有人在纠结学 Go 还是 Rust，底下的帖子也有不少夸 Rust 语言的，因此自己也开始关注 Rust 语言。后来发现 Rust 的用武之地非常广，Github 上还能找到不少 Rust 做的游戏引擎，其中一部分主打 ECS 功能，例如：bevyengine/bevy 、Ralith/hecs 等。

学习 Rust 语言，其实也是在了解一个现代化的语言该有的样子，了解 C++ 或其他语言部分设计上的不足，以及 Rust 是打算如何从根源解决这些问题的。这部分我作为一个初学者，不打算展开讲。大家有空可以了解一下 Rust 语言，看看官方的教程《Rust 程序设计语言》。

总而言之，我觉得光线追踪的教程可以作为学一门新语言后严肃学习的项目，做完成就感也满满！

顺便推荐一篇好文：新技术学习不完全指北：以 Rust 为例。

最后放下示例的渲染图：

1200*800 渲染图

五一劳动节快乐！

]]> 图形学 游戏开发 Rust 3D 数学 24 天像素画从入门到放弃 /2021/04/18/learn-pixel-art/ 前不久十分厌学，想着是不是学废了，就想找到其他的东西学学，于是有一天周日尝试了同时入门 Blender 和 像素画。

建模其实和 Unity 用初始模型搭积木差不多，入门也还好。但是自己从小就是对美术绝缘，只有初中的时候会和其他同龄人一样照着漫画书瞎画。后来就直到现在，因此开始画像素画的时候还是十分不适应，感觉每一个点都是为无用艺术界添砖加瓦。

后来决定画像素画的契机是听播客介绍到一个码农姐姐为了做游戏坚持 100 天画像素画，于是少年那颗不知天高地厚的心怦然地燃烧起来。

教练！我想学画画！

兴起

作为一个资深松鼠症患者，Steam 里早已经躺着不知道什么时候打折入手的像素画神器 “Asprite”，我原本以为一辈子再也不会下载它，这就是命运的安排吧。

很多软件能画像素画，毕竟像素画就只是由点构成的，不过好的工具能事半功倍。用习惯 PS 的美术朋友可能会选择继续用 PS 改笔触画像素画，对于我来说，功能太多的软件反而会打压我的一时兴起的兴趣，于是我跟着 Aseprite！超方便的像素画软件初学者教程 花半小时大概清楚 Aseprite 有的功能。

Aseprite 是收费的，在 Github 开源 ，如果你想自己编译，可以参考 [GUIDE] How to build Aseprite from source. (Aseprite free & legal) 。我是在 Steam 上买的，现在看了看是 70 元，买了 Win、Mac、Linus 都能用，不需要自己分开编译，更新也会更方便些。

自己一开始跟着 Youtube 博主的视频教程入门，其中有前面 Aseprite 初学者教程的作者 MortMort、开了 Pixel 101 系列教程的 Pixel Pete 等。

我喜欢看视频教程入门的原因有几点：

  1. 我想看他们是怎么开始构思一幅画的（像素画的型）
  2. 画像素画的过程（先画什么后画什么，颜色如何选择）
  3. 对软件的使用，如何适当地使用软件的功能更快地画出你想要的画。
  4. 了解像素画独有的技巧，如：像素抖动等

一开始我看的是 Pixel 101 的前几个教程，Pixel Pete 在像素极其有限的情况下很快就能画出不同的物品，让我知道精准控制地像素就能通过不同颜色影响画在人们脑海中的想象。

因此我对像素画的理解就是：易入门、精准控制少量颜色和少量像素、费时少易出货，需要的基础也比原画板绘少非常多。

由于我当前工作室的游戏就是像素风格，因此问了几位原画同事，都说像素画是最简单的，他们一开始有原画基础，临摹下像素画的画法，很快就都能上手画像素画了。

于是我决定开始 100 天像素画挑战，每天花一个小时左右鼠绘像素画。

学习

第一天开始画之后，我发现很多问题：

  • 一个像素能表现的东西是有限的，我要决定这个像素应该表现成什么，从而决定是什么颜色。
  • 像素画的分辨率十分低，阴影过渡和线条可能会非常生硬，画太多又会有色块现象。
  • 像素画中颜色的数量要有限制，阴影可以用两到三个颜色过渡，太多颜色会很乱。

于是找了本书 《Make Your Own Pixel Art》 参考，这本书面对的是没绘画基础的新手，用的软件也是 Aseprite。这本书讲的非常详细，我印象最深的就是我需要先学会画出不同基本模型的光照，例如圆柱、正方体等，这些形状和光照会画之后，再将它们组合起来，创造出自己的物品或角色。

对于调色板的颜色，可以在 Lospec 中选一些经典的颜色，这样我们暂时不用考虑颜色的对比、饱和度挑选等，先限制自己在调色板中用色，后期学颜色理论（Color Theory）了再自己配色。

下面是第三天时做的书中的练习，给出一个角色的剪影，我来上色。

第三天

第五天我尝试画自己的角色，画布是 $ 64 × 64 $ ，主题是太空。其中用到刚学的像素抖动，星星的表示，不过有些光影的地方还是错的。

于是每天画画，时不时尝试不同风格的像素画，中途还尝试了下画动画帧。每天也会用 Eagle 收集一下参考用的素材，这个软件看动画帧也非常方便。

Eagle

挑战途中，我还找了一些素材参考，其中十分有用的是风农翻译的蔚蓝主美 Pedra Medeiros 的一系列像素画教程：saint11像素宝典 和 JKLLIN 的像素画学习系列。像素宝典里面还教了很多游戏中很有用的动画帧画法，比如攻击时的准备帧、不同风格如光魔法和黑暗魔法的表现等。

如果还想深入，我十分推荐 Michael Azzi 写的 Pixel Logic 这本书，B 站的物暗先生汉化过。这本书里面介绍了很多像素画的专有概念，还引用了很多像素游戏作为参考，如果想做一个像素游戏，你能从中获益很多。

我还经常逛逛 Twitter 的像素画标签，如：pixelart、ドット絵等，Artstation 的 Pixel Art 画，还有 Deviant Art 的 Pixel Art 主题。找到参考的同时，还能进一步找到自己喜欢的风格，这样可以跟着画的作者进一步了解这种风格的像素画画法。

放弃

直到第 24 天我决定放弃，其实还是时间的问题，回到家自己的时间也就两三个小时，有时候纠结一下颜色和参考，一堆时间就过去了，我希望把时间更多地重新放在技术上。

当然这 24 天我也是收获了不少，对像素画有了基本的了解，对颜色也开始有了那么点概念。工作中做游戏系统原型的时候都能不等美术资源，自己随便画图凑合用了 hhh。游戏开发者在学像素画的时候，也能请教下工作室中的美术，以后说不定还能靠着自己的像素画做独立开发，一箭双雕！

大家在一开始画的时候从小图画起，$ 16 × 16 $ 到 $ 64 × 64 $ 的画布就已经足够了，这样的画布也不需要绘画板，鼠绘就足够了，我相信画到一定程度，就会知道自己需不要一个绘画板了。

最后

本文作为学习过程的记录，希望能给读者激起学像素画的兴趣，避免走一些弯路。博主学像素画也是为了点一下独立开发的技能，虽然画的不怎么样，至少不怕画画了！

如果你对我 24 天的像素画感兴趣，可以点击下方按钮，或者博客右上角的相对应的标签查看。

Group Image Gallery
像素画

像素画挑战

]]> 游戏开发 绘画 Compute Shader 简介 /2021/04/17/compute-shader/ 做游戏的时候，我们经常要面对各种优化问题。DOTS 技术栈的出现提供了一种 CPU 端的多线程方案，那么我们是否也能将一些计算转到 GPU 上面，从而平衡好对 CPU 和 GPU 的使用呢？对我而言，以前使用 GPU 无非是通过写 vert/frag shader、做好渲染相关的设置等操作，但实际上我们还能使用 GPU 的计算能力来帮我们解决问题。Compute Shader 就是我们跟 GPU 请求计算的一种手段。

本文将从并行架构开始，依次讲解一个最简单的 Compute Shader的编写、线程与线程组的概念、GPU 结构和其计算流水线，并讲解一个鸟群 Flocking 的实例，最后介绍 Compute Shader 的应用。全文较长，读者可以通过目录挑想看的看。

Compute Shader 也和传统着色器的写法十分不一样，写传统 Shader 写怕了的同学请放心~

介绍

当今的 GPU 已经针对单址或连续地址的大量内存处理（亦称为流式操作，streaming operation）进行了优化，这与 CPU 面向内存随机访问的设计理念则刚好背道而驰。再者，考虑到要对顶点与像素分别进行单独的处理，因此 GPU 现已经采用了大规模并行处理架构。例如，NVIDIA 公司开发的 “Fermi” 架构最多可支持 16 个流式多处理器（streaming multiprocessor, SM），而每个流式处理器又均含有 32 个 CUDA 核心，也就是共 512 个 CUDA 核心。

CUDA 与 OpenCL 其实就是通过访问 GPU 来编写通用计算程序的两组不同的 API。

CPU compare GPU

现代的 CPU 有 4-8 个 Core，每个 Core 可以同时执行 4-8 个浮点操作，因此我们假设 CPU 有 64 个浮点执行单元，然而 GPU 却可以有上千个这样的执行单元。仅仅只是比较 GPU 和 CPU 的 Core 数量是不公平的，因为它们的职能不同，组织形式也不同。

显然，图形的绘制优势完全得益于 GPU 架构，因为这架构就是专为绘图而精心设计的。但是，一些非图形应用程序同样可以从 GPU 并行架构所提供的强大计算能力中受益。我们将 GPU 用于非图形应用程序的情况称为通用 GPU 程序设计（通用 GPU 编程。General Purpose GPU programming, GPGPU programming）。当然，并不是所有的算法都适合由 GPU 来执行，只有数据并行算法（data-parallel algorithm） 才能发挥出 GPU 并行架构的优势。也就是说，仅当拥有大量待执行相同操作的数据时，才最适宜采用并行处理。[1]

粒子系统是一个例子，我们可简化粒子之间的关系模型，使它们彼此毫无关联，不会相互影响，以此使每个粒子的物理特征都可以分别独立地计算出来。

对于 GPGPU 编程而言，用户通常需要将计算结果返回 CPU 供其访问。这就需将数据由显存复制到系统内存，虽说这个过程的速度较慢（见下图），但是 GPU 在运算时所缩短的时间相比却是微不足道的。 针对图形处理任务来说，我们一般将运算结果作为渲染流水线的输入，所以无须再由 GPU 向 CPU 传输数据。例如，我们可以用计算着色器（Compute Shader）对纹理进行模糊处理（blur），再将着色器资源视图（shader resource view，DirectX 的概念），与模糊处理后的纹理相绑定，以作为着色器的输入。

CPU 与 GPU 的数据传输

计算着色器虽然是一种可编程的着色器，但 Direct3D 并没有将它直接归为渲染流水线中的一部分。虽然如此，但位于流水线之外的计算着色器却可以读写 GPU 资源。从本质上来说，计算着色器能够使我们访问 GPU 来实现数据并行算法，而不必渲染出任何图形。正如前文所说，这一点即为 GPGPU 编程中极为实用的功能。另外，计算着色器还能实现许多图形特效——因此对于图形程序员来说，它也是极具使用价值的。前面提到，由于计算着色器是 Direct3D 的组成部分，也可以读写 Direct3D 资源，由此我们就可以将其输出的数据直接绑定到渲染流水线上。

计算着色器并非渲染流水线的组成部分，但是却可以读写GPU 资源。而且计算着色器也可以参与图形的渲染或单独用于 GPGPU 编程

最简单的 Compute Shader

现在我们来看看一个最简单的 Compute Shader 的结构。

Unity 右键 → Create → Shader → Compute Shader 就可以创建一个最简单的 Compute Shader。

Compute Shader 文件扩展名为 .compute，它们是以 DirectX 11 样式 HLSL 语言编写的。

1
2
3
4
5
6
7
8
9
10
#pragma kernel CSMain

RWTexture2D<float4> Result;

[numthreads(8,8,1)]
void CSMain(uint3 id : SV_DispatchThreadID)
{
    // 为了演示，我把模板中下面这行改了
    Result[id.xy] = float4(0, 1, 1, 1.0);
}

第 1 行：一个计算着色器资源文件必须包含至少一个可以调用的 compute kernel，实际上这个 kernel 对应的就是一个函数，该函数由 #pragma 指示，名字要和函数名一致。一个 Shader 中可以有多个内核，只需定义多个 #pragma kernel functionName 和对应的函数即可，C# 脚本可以通过 kernel 的名字来找到对应要执行的函数（ shader.FindKernel(functionName)）。

第 3 行： RWTexture2D 是一种可供 Compute Shader 读写的纹理，C# 脚本可以通过 SetTexture() 设置一个可读写的 RenderTexture 供 Compute Shader 修改像素颜色。其中 RW 代表可读写。

第 5 行：numthreads 设置线程组中的线程数。组中的线程可以被设置为 1D、2D 或 3D 的网格布局。线程组和线程的概念下文会提到。

第 6 行：CSMain 为函数名，需要和 pragma 定义的 kernel 名一一对应。一个函数体代表一个线程要执行的语句，传进来的 SV_DispatchThreadID 是三维的线程 id，下文会提到。

第 9 行：根据当前线程 id 索引到可读写纹理对应的像素，并设置颜色。

C# 脚本这边

1
2
3
4
5
6
7
8
9
10
11
12
private void InitShader()
{
    _image = GetComponent<Image>();
    _kernelIndex = computeShader.FindKernel("CSMain");
    int width = 1024, height = 1024;
    _rt = new RenderTexture(width, height, 0) {enableRandomWrite = true};
    _rt.Create();

    _image.material.SetTexture("_MainTex", _rt);
    computeShader.SetTexture(_kernelIndex, "Result", _rt);
    computeShader.Dispatch(_kernelIndex, width / 8, height / 8, 1);
}

第 4 行：一个 Compute Shader 可能有多个 Kernel，这里根据名字找到需要的 KernelIndex，这样脚本才知道要把数据送给哪一个函数运算。

第 6、7 行：创建一个支持随机读写的 RenderTexture 。

第 10 行：为 Compute Shader 设置要读写的纹理。

第 11 行：设置好要执行的线程组的数量，并开始执行 Compute Shader。线程组数量的设置下文会提到。

将 Compute Shader 在 Inspector 赋值给脚本，然后将脚本挂在一个有 Image 组件的 GameObject 下，就能看到蓝色的图片。

简单的着色器示例

到现在我们应该大概明白了：

  • kernel 函数里面执行的是一个线程的要执行的逻辑。
  • 我们需要设置线程组的数量（Dispatch）、和线程组内线程的数量（numthreads）。
  • 我们可以为 Compute Shader 设置纹理等可读写资源。

那么什么是线程组和线程呢？我们又该如何设置数量？

如何划分工作：线程与线程组

在 GPU 编程的过程中，根据程序具体的执行需求，可将 线程 划分为由 线程组（thread group） 构成 的网格（grid）。

numthread 和 Dispatch 的三维 Grid 的设置方式只是方便逻辑上的划分，硬件执行的时候还会把所有线程当成一维的。因此 numthread(8, 8, 1) 和 numthread(64, 1, 1) 只是对我们来说索引线程的方式不一样而已，除外没区别。

线程组构成的 3D 网格

下图是 Dispatch(5,3,2)， numthreads(10,8,3) 时的情况。

注意下图 Y 轴是 DirectX 的方向，向下递增，而 Compute Shader 中 Y 轴是相反的，向上递增，这里参考网格内的结构和线程组与线程的关系即可。

线程组 3D 网格

上图中还显示了 SV_DispatchThreadID 是如何计算的。

不难看出，我们能够根据需求定义出不同的线程组布局。例如，可以定义一个具有 X 个线程的单行线程组 [numthreads(X, 1, 1)] 或内含 Y 个线程的单列线程组 [numthreads(1, Y, 1)]。

还可以通过将维度 z 设为 1 来定义规模为 X×YX × Y 的 2D 线程组，形如 [numthreads(X, Y, 1)]。我们应结合所遇到的具体问题来选择适当的线程组布局。

例如当我们处理 2D 图像时，需要让每一个线程单独处理一个像素，就可以定义 2D 的线程组。假设我们 numthreads 设置为 (8, 8, 1)，那么一个线程组就有 8×88×8 个线程，能处理 8×88×8 的像素块（内含 64 个像素点）。

那么如果我们要处理一个 texResolution×texResolutiontexResolution × texResolution 分辨率的纹理，那么需要多少个线程组呢？

x 和 y 方向都需要 texResolution/8texResolution / 8 个线程组。

可以通过线程组来划分要处理哪些像素块（8×88×8）

线程组解释

线程组解释

numthreads 有最大线程限制，具体查阅不同平台的文档：numthreads 。

前面介绍了如何设置线程组和线程的数量，现在介绍线程组和线程在硬件的运行形式。

线程组的 GPU 之旅

Fermi 架构

Ampere 架构

我们知道 GPU 会有上千个“核心”，用 NVIDIA 的说法就是 CUDA Core。

  • SP：最基本的处理单元，streaming processor，也称为 CUDA core。最后具体的指令和任务都是在 SP 上处理的。GPU 进行并行计算，也就是很多个 SP 同时做处理。我们所说的几百核心的 GPU 值指的都是 SP 的数量；
  • SM：多个 SP 加上其他的一些资源组成一个 streaming multiprocessor。也叫 GPU 大核，其他资源如：warp scheduler，register，shared memory 等。SM 可以看做 GPU 的心脏（对比 CPU 核心），register 和 shared memory 是 SM 的稀缺资源。CUDA 将这些资源分配给所有驻留在 SM 中的 threads。因此，这些有限的资源就使每个 SM 中 active warps 有非常严格的限制，也就限制了并行能力。

这些核心被组织在流式多处理器（streaming multiprocessor, SM）中，一个线程组运行于一个多处理器（SM）之上。每一个核心同一时间可以运行一个线程。

流式多处理器（streaming multiprocessor, SM）是 Nvidia 的说法，AMD 对应的单元则是 Compute Unit。

因此，对于拥有 16 个 SM 的 GPU 来说，我们至少应将任务分解为 16 个线程组，来让每个多处理器都充分地运转起来。但是，要获得更佳的性能，我们还应当令每个多处理器至少拥有两个线程组，使它能够切换到不同的线程组进行处理，以连续不停地工作（线程组在运行的过程中可能会发生停顿，例如，着色器在继续执行下一个指令之前会等待纹理的处理结果，此时即可切换至另一个线程组）。

SM 会将它从 Gigathread 引擎（NVIDIA 技术，专门管理整个流水线）那收到的大线程块，拆分成许多更小的堆，每个堆包含 32 个线程，这样的堆也被称为：warp (AMD 则称为 wavefront)。多处理器会以 SIMD32 的方式（即 32 个线程同时执行相同的指令序列）来处理 warp，每个 CUDA 核心都可处理一个线程。

“Fermi” 架构中的每个多处理器都具有 32 个 CUDA 核心。

每一个线程组都会被划分到一个 Compute Unit 来计算，线程组中的线程由 Compute Unit 中的 SIMD 部分来执行。
如果我们定义 numthreads(8, 2, 4)，那么每个线程组就有 8×2×4=648×2×4=64 个线程，这一整个线程组会被分成两个 warp，调度到单个 SIMD 单元计算。

Memory Stall（内存延迟）

单个 SM 处理逐个 warp，当一个 warp 暂时需要等待数据的时候，就可以先换其他 warp 继续执行。

如何设置好线程组的大小

我们应当总是将线程组的大小设置为 warp 尺寸的整数倍。让 SM 同时容纳多个 warp，能够以防一些情况。例如有时候为了等待某些数据就绪，你不得不停下来。比如说，我们需要通过法线纹理贴图来计算法线光照，即使该法线纹理已经在 Cache 中了，访问该资源仍然会有所耗时，而如果它不在 Cache 中，那就更加耗时了。用专业术语讲就是 Memory Stall（内存延迟）。与其什么事情也不做，不如将当前的 Warp 换成其它已经准备就绪的 Warp 继续执行。[2]

Dispatch/Thread Group SIze Heuristics

上图来自：DirectCompute Lecture Series 210: GPU Optimizations and Performance

NVIDIA 在 Maxwell 更改了 SM 的组织方式，即 SMM——全新的 SM 架构。每个 SM 分为四个独立的处理块，每个处理块具备自己的指令缓冲区、调度器以及 32 个 CUDA 核心。因此 Maxwell 中可以同时运行 4 个以上的 Warp，实际上，在 GTC2013 大会上的一个 CUDA 优化视频里讲到，在常用 case 中推荐使用 30 个以上的有效 Warp，这样才能确保 Pipeline 的满载利用率。
—— Guohui Wang

NVIDIA 公司生产的图形硬件所用的 warp 单位共有 32 个线程。而 ATI 公司采用的 “wavefront” 单位则具有 64 个线程，且建议为其分配的线程组大小应总为 wavefront 尺寸的整数倍。另外，值得一提的是，不管是 warp 还是 wavefront，它们的大小在未来几代中都有可能发生改变。

总之，每个 SM 的操作度是 warp，但是每个 SM 可以同时处理多个 warp。然后因为有内存等待（memory stall）的问题，同一个 thread block 有可能需要等待内存才做，因此可以使用多个线程组交叉运行。warp 对我们是不可见和不可编程的，我们可编程的只有线程组。[3]

还可以参考 GPU Open 中 Compute Shader 部分。

GPU Compute Unit

接下来我们看一下 GPU 内部的结构，这里的内容来自 Compute Shaders: Optimize your engine using compute / Lou Kramer, AMD，Lou Kramer 以 AMD 的 GCN 架构为例，介绍了 GPU 大体的结构。

这里 GCN 就是一个 Compute Unit，Vega 64 显卡有 64 个 Compute Unit。

gpu-talk-1

GCN 有 4 个 SIMD-16 单元（即 16 个线程同时执行相同的指令序列）。

gpu-talk-2

线程间交流

多个线程组间的交流

上面提到，线程并不能访问其他组中的共享内存。如果线程组需要互相交流，那么就需要 L2 cache 来支持。但是 L2 cache 性能肯定会有折扣，因此我们要保证组间的交流尽可能少。

gpu-talk-3

单个线程组内的交流

如果单个线程组内线程需要互相交流，则需要 Local Data Share (LDS) 来完成。

gpu-talk-4

LDS 会被其他着色阶段（shader stage）使用，例如像素着色器就需要 LDS 来插值。但是 Compute Shader 的用途和传统着色器不一样，不是必须要 LDS，因此我们可以随意地使用 LDS。

1
2
3
4
5
6
7
8
9
10
groupshared float data[8][8];

[numthreads(8,8,1)]
void main(ivec3 index : SV_GroupThreadID)
{
  data[index.x][index.y] = 0.0;
  GroupMemoryBarrierWithGroupSync();
  data[index.y][index.x] += index.x;
  …
}

需要组内共享的变量前加 groupshared ，同时为了保证其他线程也能读到数据，我们也需要通过 Barrier 来保证他们读的时候 LDS 里面有需要的数据。

LDS 比 L1 cache 还快！

Vector Register 和 Scalar Register

如果有些变量是线程独立的，我们称之为 “non-uniform” 变量。（如果一个线程组内有 64 个线程，就要存 64 份数据）

如果有些变量是线程间共享的，我们称之为 “uniform” 变量，例如线程组 id 是组内每个线程都一样的。（每个线程组内只存 1 份数据）

“non-uniform” 变量会被储存到 Vector Register（VGPR, vector general purpose register）中。

“uniform” 变量会被储存到 Scalar Register（SGPR, scalar general purpose register）中。

gpu-talk-5

如果用了过多 “non-uniform” 变量导致 Vector Register 装不下，就会导致分配给 SIMD 的线程组数量降低。

与传统着色器执行流程的异同

Vert-Frag Shader

  1. 首先 Command Processor 会收集并处理所有命令，发送到 GPU，并告知下一步要做什么。

  2. Draw() 命令发送后，Command Processor 告知 Graphics Processor 要做的事情。

    我们可以将 Graphics Processor 看作是输入装配器（Input Assembler）的硬件对应的部分。

  3. 然后类似于顶点着色器这些就会被送到 Compute Unit 去计算，处理完会到 Rasterizer (光栅器)，并返回处理好的像素到 Compute Unit 执行像素着色（Pixel shader）。

  4. 最后才会输出到 RenderTarget 。

下图中，AMD 显卡架构中的 Compute Unit 相当于 nVIDIA GPUs 中的流式多处理器（streaming multiprocessor, SM）。

gpu-talk-6

Compute Shader

  1. 首先 Command Processor 仍会收集并处理所有命令，发送到 GPU。
  2. 我们不需要传数据到 Graphics Processor，因为这不是一个 Graphics Command，而是直接传到 Compute Unit。
  3. Compute Unit 开始处理 Compute Shader，输入可以有 constants 和 resources（对应 DirectX 的 Resource 可以绑定到渲染管线的资源，例如顶点数组等），输出可以有 writable resources（UAV, Unordered Access View 能被着色器写入的资源视图）。

总结

因此，如果我们用了 Compute Shader，可以不通过渲染管线，跳过 Render Output，使用更少硬件资源，利用 GPU 来完成一些渲染不相关的工作。

gpu-talk-7

此外，Compute Shader 的流水线需要的信息也更少。

gpu-talk-8

Boids 示例

讲完了理论，这里来看看我们在 Unity 中使用 Compute Shader 来做一个鸟群（Boids）的 demo。

群落算法可以参考：Boids (Flocks, Herds, and Schools: a Distributed Behavioral Model)

代码示例地址：Latias94/FlockingComputeShaderCompare

群落算法简单来讲，就是模拟生物群落的自组织特性的移动。

Craig Reynolds 在 1986 年对诸如鱼群和鸟群的运动进行了建模，提出了三点特征来描述群落中个体的位置和速度：

  1. 排斥（separation）：每个个体会避免离得太近。离得太近需要施加反方向的力使其分开。
  2. 对齐（Alignment）：每个个体的方向会倾向于附近群落的平均方向。
  3. 凝聚（Cohesion）：每个个体会倾向于移动到附近群落的平均位置。

在这个示例中，我们可以将每一只鸟的位置和方向用一个线程来计算，Compute Shader 负责遍历这只鸟的周围鸟的信息，计算出这只鸟的平均方向和位置。C# 脚本则负责每一帧传入凝聚（Cohesion）的位置、经过的时间，再从 Compute Shader 获取每一只鸟的位置和朝向，设置到每一只鸟的 Transform 上。

设置数据

文章开头的例子中，脚本给 Shader 设置了 RWTexture2D<float4> ，让 Compute Shader 能直接在 Render Tecture 设置颜色。

对于其他类型的数据，我们首先要定义一个结构（Struct），再通过 ComputeBuffer 与 Compute Shader 交流数据。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
// FlockingGPU.cs
struct Boid
{
    public Vector3 position;
    public Vector3 direction;
};
public class FlockingGPU : MonoBehaviour
{
    public ComputeShader shader;
    private Boid[] _boidsArray;
    private GameObject[] _boids;
    private ComputeBuffer _boidsBuffer;
    // ...
    void Start()
    {
        _kernelHandle = shader.FindKernel("CSMain");

        uint x;
        // 获取 Compute Shader 中定义的 numthreads
        shader.GetKernelThreadGroupSizes(_kernelHandle, out x, out _, out _);
        _groupSizeX = Mathf.CeilToInt(boidsCount / (float) x);
        // 塞满每个线程组，免得 Compute Shader 中有线程读不到数据，造成读取数据越界
        _numOfBoids = _groupSizeX * (int) x;

        InitBoids();
        InitShader();
    }

    private void InitBoids()
    {
        // 初始化 _Boids GameObject[]、_boidsArray Boid[]
    }

    void InitShader()
    {   // 定义大小，鸟的数量和每个鸟结构的大小，一个 Vector3 就是 3 * sizeof(float)
        // 10000 只鸟，每只占6 * 4 bytes，总共也就占 0.234mib GPU 显存 
        _boidsBuffer = new ComputeBuffer(_numOfBoids, 6 * sizeof(float));
        _boidsBuffer.SetData(_boidsArray); // 设置结构数组到 Compute Buffer 中
        // 设置 buffer 到 Compute Shader，同时设置要调用的计算的函数 Kernel
        shader.SetBuffer(_kernelHandle, "boidsBuffer", _boidsBuffer);
        shader.SetFloat("boidSpeed", boidSpeed); // 设置其他常量
        shader.SetVector("flockPosition", target.transform.position);
        shader.SetFloat("neighbourDistance", neighbourDistance);
        shader.SetInt("boidsCount", boidsCount);
    }
    // ...
    void OnDestroy()
    {
        if (_boidsBuffer != null)
        {    // 用完主动释放 buffer
            _boidsBuffer.Dispose();
        }
    }
}

获取数据

在开头最简单的 Compute Shader 一节中，我介绍了需要 Dispatch 去执行 Compute Shader 的 Kernel。

下面的 Update，设置了每一帧会变的参数，Dispatch 之后，再通过 GetData 阻塞等待 Compute Shader kernel 的计算结果，最后对每一个 Boid 结构赋值。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// FlockingGPU.cs
public class FlockingGPU : MonoBehaviour
{
    // ...
    void Update()
    {   // 设置每一帧会变的变量
        shader.SetFloat("deltaTime", Time.deltaTime);
        shader.SetVector("flockPosition", target.transform.position);
        shader.Dispatch(_kernelHandle, _groupSizeX, 1, 1); // 调用 Compute Shader Kernel 来计算
        // 阻塞等待 Compute Shader 计算结果从 GPU 传回来
        _boidsBuffer.GetData(_boidsArray);
        for (int i = 0; i < _boidsArray.Length; i++)
        {   // 设置鸟的 position 和 rotation
            _boids[i].transform.localPosition = _boidsArray[i].position;
            if (!_boidsArray[i].direction.Equals(Vector3.zero))
            {
                _boids[i].transform.rotation = Quaternion.LookRotation(_boidsArray[i].direction);
            }
        }
    }
}

在 Compute Shader 中，也要定义一个 Boid 结构和相对应的 RWStructuredBuffer<Boid> 来用脚本传来的 Compute Buffer。Shader 主要就是对一只鸟遍历一定范围内的鸟群的信息，计算出结果返回给脚本。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
// SimpleFlocking.compute
#pragma kernel CSMain
#define GROUP_SIZE 256

struct Boid
{   // Compute Shader 也定义好相关的结构
    float3 position;
    float3 direction;
};

RWStructuredBuffer<Boid> boidsBuffer; // 允许读写的数据 buffer
float deltaTime;
float3 flockPosition;

[numthreads(GROUP_SIZE,1,1)]
void CSMain(uint3 id : SV_DispatchThreadID)
{
    Boid boid = boidsBuffer[id.x];
    // ...
    for (int i = 0; i < boidsCount; i++)
    {
        if (i == id.x)
            continue;
        Boid tempBoid = boidsBuffer[i];
        // 通过周围的鸟的信息，计算经过三个特性后，这一只鸟的方向和位置。
        // ...
    }
    // ...
    boid.direction = lerp(direction, normalize(boid.direction), 0.94);
    boid.position += boid.direction * boidSpeed * deltaTime;
    // 设置数据到 Buffer，等待 CPU 读取
    boidsBuffer[id.x] = boid;
}

Dispatch 之后 GetData 是阻塞的，如果想异步地获取数据，Unity 2019 新引入一个 API：AsyncGPUReadbackRequest ，可以让我们先发送一个获取数据的请求，再每一帧去查询数据是否计算完。也有同学用了测出第一次调用耗时较多等问题，具体可以参考：Compute Shader 功能测试（二）。

下面是 100 只鸟的结果：

100只鸟的结果

通过 Compute Shader，我们可以通过 Compute Shader 在 GPU 直接计算好需要计算的东西（例如位置、mesh 顶点等），并与传统着色器共享一个 ComputeBuffer ，直接在 GPU 渲染，这样就省去渲染时 CPU 再次传数据给 GPU 的耗时。我们也可以将 Compute Shader 计算后的数据返回给 CPU 再做额外的计算。总而言之，Compute Shader 十分灵活。

CPU 端计算 vs GPU 端计算

假设我们在 CPU 端不用任何 DOTS，直接在每个 Update 中 for 每个鸟计算朝向和位置，这样性能是非常差的。

下图是把计算都放到 C# Update 中的 Profile：

C# 每个 Update 中直接计算

如果放到 Compute Shader 计算，每个 Update 更新数据，这样 CPU 消耗小了很多。

Compute Shader 计算，每个 Update 更新数据

感兴趣的朋友可以对比下 FlockingCPU.cs 和 FlockingGPU.cs 的代码，会发现两者的代码其实十分相似，只不过前者把 for loop 放到脚本，后者放到了 Compute Shader 中而已，因此如果大家觉得有一些地方十分适合并行计算，就可以考虑把这部分计算放到 GPU 计算。

Profile Compute Shader

我们可以通过 Profiler 来看 GPU 利用情况，通常这个面板是隐藏的，需要手动打开。

也可以通过 RenderDoc 来看，这里不展示。

boid-profile-3

优化：DrawMeshInstanced

前面我们用 Instantiate 来初始化鸟群，其实我们也能通过 GPU instancing 来优化，用 Graphics.DrawMeshInstanced 来实例化 prefab。这个优化未包含在 Github 例子中，这里提供思路。

boid-profile-4

这么做的话，位置和旋转都要在传统 shader 中计算成变换矩阵应用在顶点上，因此为了防止 Compute Shader 数据传回 CPU 再传到 GPU 的传统 shader 的开销，需要两个 Shader 共享一个 StructuredBuffer 。

这样如果要给模型加动画的话，还得提前烘焙动画，将每一帧动画的顶点和当前帧数提前传到 vertex shader(or surface shader) 里做插值，这样做的话还能根据鸟的速度去控制动画的速率。

应用

  • 遮挡剔除（Occlusion Culling）
  • 环境光遮蔽（Ambient Occlusion）
  • 程序化生成：
    • terrain heightmap evaluation with noise, erosion, and voxel algorithms
  • AI 寻路
    • Compute Shader 做寻路有点不太好的就是往往游戏（CPU）需要知道计算结果，因此还要考虑 GPU 返回结果给 CPU 的延时。可以考虑做 CPU 端并行的方案，例如用 Job System。
  • GPU 光线追踪
  • 图像处理，例如模糊化等。
  • 其他你想放到 GPU，但是传统着色器干不了的并行的解决方案。

原神

Unity线上技术大会-游戏专场｜从手机走向主机 -《原神》主机版渲染技术分享

Genshin 主机渲染管线简介

解压预烘焙的 Shadow Texture

在离线制作的时候，对于烘焙好的 shadow texture 做一个压缩，尽量地去保持精度，运行的时候解压的速度也非常快，用 Compute Shader 去解压的情况，1K×1K 的 shadow texture，解压只需要 0.05 毫秒。

解压预烘焙的 Shadow Texture

做模糊处理

在进行模糊处理的时候，每个像素需要采取周边多个像素的数值进行混合，可以看到，如果使用传统的 PS，每个像素都会需要多次贴图采样，且这些采样结果实际上是可以在相邻其他像素的计算中进行重用的，因此为了进一步提升计算性能，《原神》这里的做法是将模糊处理放到 Compute Shader 中来完成。

具体的做法是，将相邻像素的采样结果存储在 局部存储空间（Local Data Share） 中，之后再模糊的时候取用，一次性完成四个像素的模糊计算，并将结果输出。[4]

天涯明月刀

《天涯明月刀》手游引擎技术负责人：如何应用GPU Driven优化渲染效果？| TGDC 2020

gpu-driven-compute-1

做遮挡剔除（Occlusion Culling）时，CPU 只能做到 Object Level，而 GPU 可以通过切分 Mesh 做进一步的剔除。

gpu-driven-compute-2

知乎上也有人尝试了实现：Unity实现GPUDriven地形。

斗罗大陆

三七研发，这款被称作 “目前最原汁原味的”《斗罗大陆》3D 手游都用到了哪些 Unity 技术？

利用 Compute Shader 对所有美术贴图逐像素对比，筛选出大量的重复、相似、屯余、大透明的贴图。

Clay Book

基于3D SDF 体渲染的黏土游戏：Claybook Game。

演讲：DD2018: Sebastian Aaltonen - GPU based clay simulation and ray tracing tech in Claybook

动图：https://gfycat.com/gaseousterriblechupacabra

Jelly in the sky

Finished my compute shader based game 这帖子的哥们写了六千多行 HLSL 代码做了一个完全在 GPU 执行的基于物理模拟的游戏。

Steam：Jelly in the sky on Steam

动图：https://gfycat.com/validsolidcanine

开源项目

缺点

虽然 Unity 帮我们做了跨平台的工作，但是我们仍然需要面对一些平台差异。

本小节内容大部分来自 Compute Shader : Optimize your game using compute。

  • 难 Debug
  • 数组越界，DX 上会返回 0，其它平台会出错。
  • 变量名与关键字/内置库函数重名，DX 无影响，其他平台会出错。
  • 如果 SBuffer 内结构的显存布局与内存布局不一致，DX 可能会转换，其他平台会出错。
  • 未初始化的 SBuffer 或 Texture，在某些平台上会全部是 0，但是另外一些可能是任意值，甚至是NaN。
  • Metal 不支持对纹理的原子操作，不支持对 SBuffer 调用 GetDimensions。
  • ES 3.1 在一个 CS 里至少支持 4 个 SBuffer（所以，我们需要将相关联的数据定义为 struct）。
  • ES 从 3.1 开始支持 CS，也就是说，在手机上的支持率并不是很高。部分号称支持 es 3.1+ 的 Android 手机只支持在片元着色器内访问 StructuredBuffer。
    • 使用 SystemInfo.supportsComputeShaders 来判断支不支持[5]

最后

我相信 Compute Shader 这个词不少读者应该都会在其他地方见过，但是大都觉得这个技术离我们还很远。我身边的朋友问了问也没怎么了解过，更不要说在项目上用了，这也是这篇文章诞生的原因之一。

当我们面临使用 DOTS 还是 Compute Shader 的抉择时，更应该从项目本身出发，考虑计算应该放在 CPU 还是 GPU，Compute Shader 中跟 GPU 沟通的开销是否能够接受。读者也可以参考下 Unity Forum 中相关的讨论：Unity DOTS vs Compute Shader。

开始碎碎念，去年的年终总结也没写，今年到现在就憋出一篇文章，十分不应该。其实也是自己没什么好分享的，自己还需要多学习。当然也很高兴通过博客认识到不同朋友，这是我写作的动力，谢谢你们。

参考

  1. 《DirectX 12 3D 游戏开发实战》第13章 计算着色器 ↩︎

  2. Render Hell —— 史上最通俗易懂的GPU入门教程（二） ↩︎

  3. 知乎 - “问个CUDA并行上的小白问题，既然SM只能同时处理一个WARP，那是不是有的SP处于闲置？”的评论 ↩︎

  4. 米哈游技术总监分享：《原神》主机版渲染技术要点和解决方案 ↩︎

  5. ComputeShader 手机兼容性报告 ↩︎

]]> 游戏开发 游戏开发 Shader 博客新增公开笔记部分 /2020/10/03/add-note-section-to-blog/ 我认为博客应该放一些经过思考的、实践的、适合读者阅读的文章，自己有时候也会在看其他视频教程或文章时记一些笔记。有些笔记本身不太适合分享出来，因为做笔记不可避免的会按照自己的思路和现有知识来定制，可能和别人注意重点不太一样。

因此我打算将一些比较成文的、有结构性的、有参考价值的笔记分享出来，这也能锻炼我把笔记组织成文的能力。

这些公开的笔记我放在独立的一个 Notion 页面中，这个页面可以点击博客上方的公开笔记，或者这个链接找到：公开笔记。

Notion 本身对公式、排版都比较友好，但是打开可能要科学上网，我是懒得把这些文章往博客搬了…不过用 Notion 有个好处就是，我对公开笔记的编辑都能实时更新到。

正文太空了也不好，就放个我笔记的主页图吧~

]]> 游戏开发 3D数学 图形学常见的变换推导 /2020/07/26/transformation/ 注意：由于这个博客主题对 MathJax 支持不好，部分推导转用图片代替，或者可以移步我的 Notion 笔记：Transformation。

本文是 Games101-现代计算机图形学入门 第三和第四节课的笔记，文中对二维变换、三维变换、视图变换、正交投影和透视投影做了推导，相关视频在下方。

GAMES101-Lecture03 Transformation

GAMES101-Lecture04 Transformation Cont.

本文同时参考了《Unity Shader 入门精要》的第四章，作者公开了第四章的 PDF，可以在下面下载到。

candycat1992/Unity_Shaders_Book

闫老师的推导十分简洁易懂，我也尽量把过程补充到文章中，读者看了我相信肯定也能跟着思路把变换公式推导出来。

在读本文的过程中，也推荐参考上面提到的视频和 pdf 互相参考，本文是视频中推导的详细笔记，冯乐乐的 pdf 中虽然没有投影变换的推导，但是在很多地方都把理论讲的十分清晰，例如必要的数学基础和各种图形学概念的讲解。

线性变换

x′=ax+by y′=cx+dy\begin{array}{l}x^{\prime}=a x+b y \\\ y^{\prime}=c x+d y\end{array}

如果我们可以把变换写成这样一种形式，矩阵乘以输入坐标等于输出坐标，这样可以叫做线性变换。

[x′ y′]=[ab cd][x y]\left[\begin{array}{l}x^{\prime} \\\ y^{\prime}\end{array}\right]=\left[\begin{array}{ll}a & b \\\ c & d\end{array}\right]\left[\begin{array}{l}x \\\ y\end{array}\right]

x′=Mx\mathbf{x}^{\prime}=\mathbf{M} \mathbf{x}

Scale Matrix

Transformation%206c54d524cd134bc0943ed5335afa2508/Untitled.png

x′=sx y′=sy\begin{array}{l}x^{\prime}=s x \\\ y^{\prime}=s y\end{array}

其变换矩阵：

[x′ y′]=[s0 0s][x y]\left[\begin{array}{l}x^{\prime} \\\ y^{\prime}\end{array}\right]=\left[\begin{array}{ll}s & 0 \\\ 0 & s\end{array}\right]\left[\begin{array}{l}x \\\ y\end{array}\right]

Scale (Non-Uniform)

x y 可以不均匀地缩放

201.png

[x′ y′]=[sx0 0sy][x y]\left[\begin{array}{l}x^{\prime} \\\ y^{\prime}\end{array}\right]=\left[\begin{array}{ll}s_{x} & 0 \\\ 0 & s_{y}\end{array}\right]\left[\begin{array}{l}x \\\ y\end{array}\right]

Reflection Matrix

202.png

Horizontal reflection:

x′=−x y′=y\begin{array}{l}x^{\prime}=-x \\\ y^{\prime}=y\end{array}

[x′ y′]=[−10 01][x y]\left[\begin{array}{l}x^{\prime} \\\ y^{\prime}\end{array}\right]=\left[\begin{array}{cc}-1 & 0 \\\ 0 & 1\end{array}\right]\left[\begin{array}{l}x \\\ y\end{array}\right]

Shear Matrix

203.png

2D Rotation Matrix

204.png

205.png

齐次坐标

Translation

平移变换非常特殊。

206.png

x′=x+tx y′=y+ty\begin{array}{l}x^{\prime}=x+t_{x} \\\ y^{\prime}=y+t_{y}\end{array}

写出来简单，但是两个式子不能写成线性变换的形式。

[x′ y′]=[ab cd][x y]\left[\begin{array}{l}x^{\prime} \\\ y^{\prime}\end{array}\right]=\left[\begin{array}{ll}a & b \\\ c & d\end{array}\right]\left[\begin{array}{l}x \\\ y\end{array}\right]

只能写成：

[x′ y′]=[ab cd][x y]+[tx ty]\left[\begin{array}{l}x^{\prime} \\\ y^{\prime}\end{array}\right]=\left[\begin{array}{ll}a & b \\\ c & d\end{array}\right]\left[\begin{array}{l}x \\\ y\end{array}\right]+\left[\begin{array}{l}t_{x} \\\ t_{y}\end{array}\right]

因此平移变换并不是线性变换。

但是我们不希望将平移变换看作一个特殊的例子，那么有没有办法将缩放、错切、平移等变换用一种统一的方式来表示？

在计算机科学，永远要考虑 “Trade-Off”。数据结构中不同降低时间复杂度的办法都会引入空间复杂度。如果两者都能低就很好，但更多时候是非此即彼的事情。“No Free Lunch Theory”。

207.png

引入齐次坐标，可以通过增加一个维度来将平移变换也写成矩阵乘一个点的形式。

向量具有平移不变性，因此后面是 (x, y, 0)，平移变换后也不变。

我们也可以通过 w 分量来推出我们操作的结果：

Valid operation if w-coordinate of result is 1 or 0

  • vector + vector = vector
  • point – point = vector
  • point + vector = point
  • point + point = ??

Affine Transformations 仿射变换

Affine map = linear map + translation

(x′ y′)=(ab cd)⋅(x y)+(tx ty)\left(\begin{array}{l}x^{\prime} \\\ y^{\prime}\end{array}\right)=\left(\begin{array}{ll}a & b \\\ c & d\end{array}\right) \cdot\left(\begin{array}{l}x \\\ y\end{array}\right)+\left(\begin{array}{l}t_{x} \\\ t_{y}\end{array}\right)

Using homogenous coordinates:

(x′ y′ 1)=(abtx cdty 001)⋅(x y 1)\left(\begin{array}{l}x^{\prime} \\\ y^{\prime} \\\ 1\end{array}\right)=\left(\begin{array}{ccc}a & b & t_{x} \\\ c & d & t_{y} \\\ 0 & 0 & 1\end{array}\right) \cdot\left(\begin{array}{l}x \\\ y \\\ 1\end{array}\right)

2D Transformations

Scale

S(sx,sy)=(sx00 0sy0 00 1 )\mathbf{S}\left(s_{x}, s_{y}\right)=\left(\begin{array}{ccc}s_{x} & 0 & 0 \\\ 0 & s_{y} & 0 \\\ 0 & 0 & \text { 1 }\end{array}\right)

Rotation

R(α)=(cos⁡α−sin⁡α0 sin⁡αcos⁡α0 001)\mathbf{R}(\alpha)=\left(\begin{array}{ccc}\cos \alpha & -\sin \alpha & 0 \\\ \sin \alpha & \cos \alpha & 0 \\\ 0 & 0 & 1\end{array}\right)

Translation

T(tx,ty)=(10tx 01ty 001)\mathbf{T}\left(t_{x}, t_{y}\right)=\left(\begin{array}{ccc}1 & 0 & t_{x} \\\ 0 & 1 & t_{y} \\\ 0 & 0 & 1\end{array}\right)

逆变换

209.png

2010.png

2011.png

因此变换顺序是很重要的，不满足交换律。

R45⋅T(1,0)≠T(1,0)⋅R45R_{45} \cdot T_{(1,0)} \neq T_{(1,0)} \cdot R_{45}

矩阵是从右到左运算的：

T(1,0)⋅R45[x y 1]=[101 010 001][cos⁡45∘−sin⁡45∘0 sin⁡45∘cos⁡45∘0 001][x y 1]T_{(1,0)} \cdot R_{45}\left[\begin{array}{l}x \\\ y \\\ 1\end{array}\right]=\left[\begin{array}{ccc}1 & 0 & 1 \\\ 0 & 1 & 0 \\\ 0 & 0 & 1\end{array}\right]\left[\begin{array}{ccc}\cos 45^{\circ} & -\sin 45^{\circ} & 0 \\\ \sin 45^{\circ} & \cos 45^{\circ} & 0 \\\ 0 & 0 & 1\end{array}\right]\left[\begin{array}{l}x \\\ y \\\ 1\end{array}\right]

矩阵没有交换律，但有结合律。

三维变换

齐次坐标系下的三维变换可以写成下面的形式

(x′ y′ z′ 1)=(abctx defty ghitz 0001)⋅(x y z 1)\left(\begin{array}{l}x^{\prime} \\\ y^{\prime} \\\ z^{\prime} \\\ 1\end{array}\right)=\left(\begin{array}{llll}a & b & c & t_{x} \\\ d & e & f & t_{y} \\\ g & h & i & t_{z} \\\ 0 & 0 & 0 & 1\end{array}\right) \cdot\left(\begin{array}{l}x \\\ y \\\ z \\\ 1\end{array}\right)

Scale

S(sx,sy,sz)=(sx000 0sy00 00sz0 0001)\mathbf{S}\left(s_{x}, s_{y}, s_{z}\right)=\left(\begin{array}{cccc}s_{x} & 0 & 0 & 0 \\\ 0 & s_{y} & 0 & 0 \\\ 0 & 0 & s_{z} & 0 \\\ 0 & 0 & 0 & 1\end{array}\right)

Translation

T(tx,ty,tz)=(100tx 010ty 001tz 0001)\mathbf{T}\left(t_{x}, t_{y}, t_{z}\right)=\left(\begin{array}{cccc}1 & 0 & 0 & t_{x} \\\ 0 & 1 & 0 & t_{y} \\\ 0 & 0 & 1 & t_{z} \\\ 0 & 0 & 0 & 1\end{array}\right)

Rotation

绕轴旋转

Rotation around x-, y-, or z-axis

Rx(α)=(1000 0cos⁡α−sin⁡α0 0sin⁡αcos⁡α0 0001)\mathbf{R}_{x}(\alpha)=\left(\begin{array}{cccc}1 & 0 & 0 & 0 \\\ 0 & \cos \alpha & -\sin \alpha & 0 \\\ 0 & \sin \alpha & \cos \alpha & 0 \\\ 0 & 0 & 0 & 1\end{array}\right)

Ry(α)=(cos⁡α0sin⁡α0 0100 −sin⁡α0cos⁡α0 0001)\mathbf{R}_{y}(\alpha)=\left(\begin{array}{cccc}\cos \alpha & 0 & \sin \alpha & 0 \\\ 0 & 1 & 0 & 0 \\\ -\sin \alpha & 0 & \cos \alpha & 0 \\\ 0 & 0 & 0 & 1\end{array}\right)

Rz(α)=(cos⁡α−sin⁡α00 sin⁡αcos⁡α00 0010 0001)\mathbf{R}_{z}(\alpha)=\left(\begin{array}{cccc}\cos \alpha & -\sin \alpha & 0 & 0 \\\ \sin \alpha & \cos \alpha & 0 & 0 \\\ 0 & 0 & 1 & 0 \\\ 0 & 0 & 0 & 1\end{array}\right)

2012.png

绕着 x 轴旋转，说明 y 和 z 都是在进行旋转的，但 x 不变。因此绕 x 轴的旋转矩阵相比二维的旋转矩阵，第一行是不变的。中间部分和二维旋转矩阵一样。

绕 y 轴旋转不一样，这里涉及到我们要如何思考轴的相互顺序。

根据右手螺旋定则，x 叉乘 y 得到 z，y 叉乘 z 得到 x。但 z 叉乘 x 才能得到 y，是反的，因此 Ry 部分不一样。

Rodrigues’ Rotation Formula

我们能够解决一些简单的问题，复杂的问题可以转化成一些简单问题的组合。

给定根据三个轴的旋转，能否将某一个方向旋转到任意一个方向上去？

2013.png

Rotation by angle α round axis n

有人将任意一个旋转分解成通过 x y z 轴分别做旋转。

R(n,α)=cos⁡(α)I+(1−cos⁡(α))nnT+sin⁡(α)(0−nzny nz0−nx −nynx0)\mathbf{R}(\mathbf{n}, \alpha)=\cos (\alpha) \mathbf{I}+(1-\cos (\alpha)) \mathbf{n} \mathbf{n}^{T}+\sin (\alpha)\left(\begin{array}{ccc}0 & -n_{z} & n_{y} \\\ n_{z} & 0 & -n_{x} \\\ -n_{y} & n_{x} & 0\end{array}\right)

证明过程可以参考闫令琪老师的证明：

GAMES101_Lecture_04_supp.pdf

公式给了我们一个旋转矩阵，定义中给了我们一个旋转轴 n 和旋转角度 α。旋转角度好理解，但旋转轴似乎不能这么简单地定义。因为一个旋转轴首先跟起点有关系，然后跟方向有关系，只给一个向量是不是不太合适？

假如说沿着 y 轴旋转，跟沿着 x 和 n 各等于 1 并且也是沿着 y 方向的向量。方向一样，但起点不一样，结果肯定也是不一样的。因此我们说沿着某个轴的方向旋转，就默认了是过原点的，这样起点就在原点上，方向就是 n 方向。

那么如果轴 n 可以平移怎么办？那么我们可以将其进行变换的分解。如果我们要沿着任意轴旋转且轴的起点不在原点，我们可以将所有的东西移到起点为原点的条件下，再旋转，再移回去。

四元数相关

我们上面所用到的旋转矩阵是不太适合做插值的，例如二维旋转 10 度的旋转矩阵加二维旋转 20 度的旋转矩阵求平均，不能得到二维旋转 15 度的旋转矩阵。四元数在这方面方便很多。

View/Camera Transformation 视图变换

定义相机

2014.png

定义一个相机需要三个变量，位置，朝向，和一个向上的方向。

视图变换

2015.png

当相机和要拍的东西一起移动的时候，那拍出来的相片是一样的。也就是说，当我们移动物体时，只要同时以相同的方式移动相机，没有相对位置，那么得出来的结果就是一样的。

如果我们将相机放在一个固定的位置上，那么所有东西在移动时，都可以认为是其他东西在移动，而相机一直在原点不动。相机永远往 -z 方向看，以 y 轴为向上方向（右手坐标系，符合 OpenGL 传统）。这是约定俗成的。相机放在原点有很多好处，能简化计算。

从坐标空间的角度来看，就是将物体和相机从世界空间转到观察空间（摄像机空间）。

2016.png

我们要将相机移到原点，就需要先把相机中心 e 平移到原点，还得把观察的方向 g 移到 -z 上，再把向上方向 t 旋转到 y 方向上，把 g X t 的方向移到 x 方向上。

下面将这系列操作转为矩阵操作。

求视图变换矩阵

  1. 先把相机中心 e 平移到原点

Tview=[100−xe 010−ye 001−ze 0001]T_{v i e w}=\left[\begin{array}{cccc}1 & 0 & 0 & -x_{e} \\\ 0 & 1 & 0 & -y_{e} \\\ 0 & 0 & 1 & -z_{e} \\\ 0 & 0 & 0 & 1\end{array}\right]

平移矩阵写好后，接下来写旋转矩阵。

  1. 把观察的方向 g 旋转到 -z 上，把向上方向 t 旋转到 y 方向上，g X t (g 叉乘 t)的方向旋转到 x 方向上
  • Rotate g to -z , t to y, g X t To x （世界空间到观察空间）
  • Consider its inverse rotation: x to g X t , y to t, z to -g （观察空间到世界空间）

我们可以反过来写，例如把 x 轴 (1,0,0 ) 旋转到 g X t 方向上的旋转矩阵，就比 g X t 移到 x 轴的旋转矩阵要好写很多，而这两个旋转矩阵是互逆的。写出 x 轴旋转到 g X t 方向的旋转矩阵后，再求其逆变换就是我们所需要的 g X t 移到 x 轴的旋转矩阵。

x to g X t , y to t, z to -g 的旋转矩阵就是：

这里 z to -g 是因为我们定义相机的坐标空间为右手坐标系。

Rview−1=[xg^×t^xtx−g0 yg^×t^yty−g0 zg^×t^ztz−g0 0001]R_{v i e w}^{-1}=\left[\begin{array}{cccc}x_{\hat{g} \times \hat{t}} & x_{t} & x_{-g} & 0 \\\ y_{\hat{g} \times \hat{t}} & y_{t} & y_{-g} & 0 \\\ z_{\hat{g} \times \hat{t}} & z_{t} & z_{-g} & 0 \\\ 0 & 0 & 0 & 1\end{array}\right]

要验证也很简单，用该旋转矩阵变换 x 轴就能得到 g X t 的方向。

那么我们的旋转矩阵就能通过对上面的矩阵求逆得出：

因为旋转矩阵是正交矩阵，因此要求逆矩阵，对其转置即可。

Rview=[xg^×t^yg^×t^zg^×t^0 xtytzt0 x−gy−gz−g0 0001]R_{v i e w}=\left[\begin{array}{cccc}x_{\hat{g} \times \hat{t}} & y_{\hat{g} \times \hat{t}} & z_{\hat{g} \times \hat{t}} & 0 \\\ x_{t} & y_{t} & z_{t} & 0 \\\ x_{-g} & y_{-g} & z_{-g} & 0 \\\ 0 & 0 & 0 & 1\end{array}\right]

这样我们世界空间到观察空间的变换矩阵就能得出来了：M_view=R_view·T_view

其中 V_g×t 为 g×t 的向量，V_e 为相机原点。

相机需要进行这种变换，变换到约定俗成的位置（原点）上去，那么其他所有物体也需要做这样的变换，这样相对运动不变。这个就是视图变换。

模型变换和视图变换经常一起被称为模型视图变换（ModelView Transformation）。

Projection Transformation 投影变换

Projection in Computer Graphics

  • 3D to 2D
  • Orthographic projection
  • Perspective projection

2017.png

Perspective projection vs. orthographic projection

2018.png

Orthographic Projection 正交投影

方法一

A simple way of understanding

  • Camera located at origin, looking at -Z, up at Y (looks familiar?)
  • Drop Z coordinate
  • Translate and scale the resulting rectangle to [−1,1]2[-1,1]^{2}

2019.png

将坐标中的 z 扔掉，如何区分物体的前和后？

感兴趣可以参考 Catlikecoding Render 1 中 Orthographic Camera 部分。

方法二

In general, we want to map a cuboid [l, r] x [b, t] x [f, n] to the “canonical (正则、规范、标准)” cube [-1,1]^3

我们在 x 轴上定义左和右 [l, r] （左比右小），y 轴上定义下和上 [b, t]（下比上小），z 轴上定义远和近 [f, n]（远比近小）。

不管 x, y 多大，都将其映射到 [-1, 1] 之间。这也是个约定俗成的事情，能方便计算。这样任何空间中的长方体，都可以映射成一个标准的立方体。

这也是**标准化设备坐标（NDC）**的定义。

上面的左比右小是相对于 x 轴来说的，下比上小是相对于 y 轴说的，但 z 轴上不太直观，因为我们推导的 NDC 是右手坐标系，（相机）看的是 -z 方向，因此一个面离我们远，说明 z 值更小。离我们近，说明 z 值更大。

2020.png

在标准化设备坐标系中 OpenGL 使用的是左手坐标系，因为左手系在这一点上会比较方便。但也会造成别的问题：x × y ≠ z。

这里可以参考：LearnOpenGL 进入3D 的 右手坐标系 部分。

Slightly different orders (to the “simple way”)

  • Center cuboid by translating 移到原点
  • Scale into “canonical” cube 映射到 [-1, 1]，也就是缩放

Translate (center to origin) first, then scale (length/width/height to 2) 因为 -1 到 1 的长度就是 2。

因此我们可以用一个平移矩阵和缩放矩阵来求出正交投影矩阵，先平移，再缩放：

如果把长方体范围缩成立方体，物体不会被拉伸吗？
会，这就涉及到另外一个变换。在所有变换做完之后，还要做一个视口变换，还要做一次拉伸。

Perspective Projection 透视投影

  • Most common in Computer Graphics, art, visual system
  • Further objects are smaller
  • Parallel lines not parallel; converge to single point

2021.png

2022.png

平行线就是永不相交的两条线，但照片上铁轨是平行的，却交于一点。透视投影的情况下，一个平面相当于被投影到了另外一个平面上，这种情况下就不是平行线了。

Recall

  • Before we move on
  • Recall: property of homogeneous coordinates
    • (x, y, z, 1),(k x, k y, k z, k !=0), (x z, y z, z^2, z !=0) all represent the same point (x, y, z) in 3D
      • 只要一个点乘于一个不为零的 k，那么它们还是一个点。那么我们还可以将其乘以 z，其表示的点还是空间中同样的点。下面我们会用到。
    • e.g. (1, 0, 0, 1) and (2, 0, 0, 2) both represent (1, 0, 0)
  • Simple, but useful

怎么做透视投影

How to do perspective projection

  • First “squish” the frustum into a cuboid (n→n, f→f) (M_persp→ortho)
  • Do orthographic projection ( M_ortho, already known!)

2023.png

透视投影的视锥体中，远的平面比近的平面要大。

我们可以把远的平面往里“挤”，“挤”到同一高度且同近平面大小，“挤”成空间中的长方体，再做正交投影就解决了。

我们已经知道正交投影怎么做了，因此剩下的就是“挤”这个操作。

在这个过程中，需要规定：

  • 近平面上任何一个点不变。
  • Z 值不变
  • 远平面的中心也不会发生变化

求出任何一个点挤压后的 x’, y’ 值

要做“挤”的操作，首先要知道任何一个点的 x, y 值是怎么变化的。因为我们任何一个面都要挤成近平面大小，我们也可以将 (x,y,z) 投影到近平面上求出变换后的 x’, y’ 值。对于 x, y 值来说，这种变换是线性的。

因此，在视锥体的上面一部分中，我们可以通过相似三角形求出变换后的 x’, y’ 值。（z’ 值不是线性变化的，后面会提到）

2024.png

上图中，n 为近平面的 z 值，z 为任何一个点(x,y,z)中的 z 值。

挤压后的 y’ 值，我们可以通过相似三角形原理得出：

y′=nzyy^{\prime}=\frac{n}{z} y

同理可得挤压后的 x’ 值：

x′=nzxx^{\prime}=\frac{n}{z} x

在齐次坐标系中，对于变换后的 (x’, y’, z’) 我们只剩下 z’ 未知。

这里给矩阵乘了 z，其表示的点还是空间中同样的点。

也就是说 (x,y,z,1) 经过 Mpersp→ortho 矩阵“挤压”后，会被映射到 (nx,ny,??,z)：

Mpersp→ortho(4×4)(x y z 1)=(nx ny  unknown  z)M_{p e r s p \rightarrow o r t h o}^{(4 \times 4)}\left(\begin{array}{c}x \\\ y \\\ z \\\ 1\end{array}\right)=\left(\begin{array}{c}n x \\\ n y \\\ \text { unknown } \\\ z\end{array}\right)

根据上式，我们可以得出部分的 Mpersp→ortho 矩阵：

Mpersp→ortho=(n000 0n00 ???? 0010)M_{p e r s p \rightarrow o r t h o}=\left(\begin{array}{llll}n & 0 & 0 & 0 \\\ 0 & n & 0 & 0 \\\ ? & ? & ? & ? \\\ 0 & 0 & 1 & 0\end{array}\right)

对于 z，我们不知道 z 会怎么变，我们只规定了近的平面上和远的平面上 z 不变。

Observation: the third row is responsible for z’

  • Any point on the near plane will not change
    • 近平面的点不变，对于任何 (x,y,n,1) 运算完了一定还是 (x,y,n,1)
  • Any point’s z on the far plane will not change
    • 远平面的点，虽然 x, y 会变化，但是 z 没有变。

求出任何一个点挤压后的 z’ 值

由“近平面的点不变，对于任何 (x,y,n,1) 运算完了一定还是 (x,y,n,1)”可得：

这里给矩阵乘了 n，其表示的点还是空间中同样的点。

因此 Mpersp→ortho 第三行一定是 (0,0,A,B) 的形式，因为：

由上式可得：

An+B=n2A n+B=n^{2}

前面我们已经知道第三行前两个数是 0。

我们前面已经规定了远平面的中心经过 Mpersp→ortho 变换后也不会发生变化。

另外一个等式可以用远平面可以用其特殊的中心点得出，给中心点再乘个 f 可得：

平截头体（Frustum）被压缩成长方体以后，内部的点的 z 值是更偏向于近平面还是更偏向于远平面？

可以参考 ScratchAPixel 的 The Perspective and Orthographic Projection Matrix

2025.png

Depth Precision Visualized

定义视锥

前面提到了长方体近平面的 l, r, b, t，有没有更好的方法去定义这些呢？

vertical field-of-view (fovY) and aspect ratio

我们现实中相机有视角的定义，也就是可以看到的角度的范围，也就是 field of view。广角相机就是可视角度比较大，对于视锥体来说，就是张的比较开。

垂直的可视角度就是 fovY。而相机的长宽比就是 aspect ratio。

我们也可以通过 fovY 和 aspect ratio，来推出水平的可视角度。

2026.png

How to convert from fovY and aspect to l, r, b, t?

2027.png

完成推导正交投影矩阵

2028.png

正交投影没有 fovY，在 Unity 中，正交投影的参数由 Camera 组件中的参数 Size, Near, Far（Viewport Rect 暂时忽略）和 Game 视图的横纵比（aspect ratio）共同决定。

这里的 Near 是近裁面的距离，也就是 -n，Far 同理，等于 -f。

Size 属性用来更改视锥体竖直方向上高度的一半，也就是前面近平面的高度 t。

由此可得正交投影近远平面的高度 t-b 为：2·Size=2·t

正交投影近远平面的宽度 r-l 为：

Aspect⋅近远平面的高度=2⋅Aspect⋅Size=2⋅Aspect⋅tAspect\cdot \text{近远平面的高度}=2\cdot Aspect\cdot Size=2\cdot Aspect\cdot t

2029.png

注意：这里的 n 和 f 是 -z 轴上的，代表近裁面和远裁面的 z 值，值为负数。

完成推导透视投影矩阵

前面已经得出：

注意：这里的 n 和 f 是 -z 轴上的，代表近裁面和远裁面的 z 值，值为负数。

通常我们透视投影的参数除了近裁面远裁面的距离外，还会有 fov 和 Aspect，且 r+l=0，因此整理公式可得：

后记

在长文的最后，我强烈推荐大家也手推一下各种变换，n, f 取 -z 轴上的 z 值或绝对值（也就是距离）得出来的变换矩阵也不一样，都推导一遍可以理解更深刻。

此外，我们也可以开始实现一个简单的 CPU 软光栅渲染器，我近期也在准备写一个软光栅，把必要的过程都推导一遍，到时候再写博文分享一下。

]]> 图形学 游戏开发 3D数学 2020年5月技术导读 /2020/05/23/2020-05-tech-reading/ 最近一直在思考自己在技术学习上是否过于低效的问题。出现这个问题的缘由是，自己工作下班之后没多少精力和时间去留给自己学习。本来就有限的时间，如果还没有合适的学习计划，而是一昧凭兴趣去学一些离自己目标方向比较远的东西，可能会事倍功半。

就我而言，自己目前的水平更像是“磨”出来的，东学学西学学，什么都有点印象，但是专业方向的知识之间的连接却非常离散。读研的时候有大量时间给我“磨”，总归能学会点什么，但工作则不一样。

例如一本《Shader 入门精要》目前看了两次，但仍然害怕离开书来写 Shader。再者，一门技术很久不用，再拿起来也需要时间。为此，我总结了三点原因：

  1. 工作中很少用到，游戏有特效师，自己也不会主动地思考怎样的 Shader 能为游戏带来更好的效果。
  2. 学的时候只光看了，跟着书敲了，但一直没有走出书本，去自己实现自己想要的功能。
  3. 觉得 Shader 像 CSS 一样，要记各种东西，凭经验实现效果，而这种知识自己最容易不用就忘。（当然这是错的，这也是为什么我在上期导读选择跟 Games101 图形学课程打基础）

基于上面的原因，导读也是偏向自己打基础的方面。

上一期的博文在：《2020年4月技术导读》

书籍

《软技能2：软件开发者职业生涯指南》

豆瓣地址

其实正如上文所说，我学东西靠的是“磨”，但这并不是什么好的学习方式。而且除去编程，作为一个开发者，我们仍然有很多“软技能”需要注意，例如自己的职业规划、如何发现技能短板、如何推进职业生涯等等。

我相信不止是我，很多开发者也在不断地摸索如何成为一个目标中资深且专业的开发者。而本月出版的这本书就是为这方面而量身定做的，是著名的《软技能》的第二版。这本书目前看到的翻译都十分优秀，每次开卷都有益。如果你也想专注于自己的职业发展，我十分推荐这本书。

下面是书中介绍的十步学习法，自己根据它来调整了下学习计划：

十步学习法

公开课

Games101 图形学入门

这门公开课我已经在上期导读中提到：《2020年4月技术导读》，再次提到是因为经过学习，我认为课程中理论部分讲的深入浅出，而且也能了解到当下流行的图形技术和它们是怎么跟我们所学的联系在一起。

闫老师提到他的学习方式是：Why, What then How，课程也是按照这种思路来设计的。先问为什么要学这个东西，然后问学的是什么，最后了解这东西具体是怎么运作的、怎么用。How 部分是最不重要的，也是最容易忘的部分，我们只需把握好 Why 和 What 部分即可。

那课程是怎么把知识点联系起来的呢，就凭借一个个 Why 来连接。拿光线追踪来举例，下面是我做的笔记：

光线追踪笔记截图

如果你对笔记感兴趣，我也将其分享了出来：《光线追踪》。

The Cherno 的游戏引擎教程

油管地址

B站搬运地址

教学版引擎仓库地址

Up 主 The Cherno 在自己的 CPP 和 OpenGL 教程之后，再基于两者推出了游戏引擎教程。引擎的仓库是跟着视频教程的进度而推进的，有兴趣的可以了解下。

The Missing Semester of Your CS Education

课程地址

B站搬运地址

这门公开课是通过知乎专栏《6.NULL：恨不相逢“未嫁时”》了解到的。

Classes teach you all about advanced topics within CS, from operating systems to machine learning, but there’s one critical subject that’s rarely covered, and is instead left to students to figure out on their own: proficiency with their tools. We’ll teach you how to master the command-line, use a powerful text editor, use fancy features of version control systems, and much more!

简而言之，这门课不是教计算机的理论，而是介绍一些常用的工具，让你在面对问题的时候有更多的手段。自己可以看看一些不熟悉的主题查漏补缺。

MIT 教授 Gilbert Strang 「线性代数」课程

课程地址

这门公开课是通过知乎专栏《86岁还在录网课：MIT教授Gilbert Strang最新「线性代数」课程上线》了解到的。

这门课程在今年录制，目前有 6 个视频讲座，对于之前录制的课程也可以在 B 站找录播，例如：麻省理工公开课：线性代数。

具体介绍可以看知乎专栏，自己对于这门课程优先级比较低，线代遇坎儿了再学。

其他计算机公开课

有网友总结了国外的计算机课程，还附上了视频链接，可以参考《电子工程和计算机科学系》。

文章

  • 图形程序学习经历
    • 文章作者认为从图形 API 开始从底向上了解硬件做的事情到摸透一整个流程是个好的学习过程，其中也给出了很多有价值的参考资料。作者声称能以较快速度在两个月满足工作要求，完成图形程序入门的知识体系。
  • Entity Component System for Unity: Getting Started
    • Ray Wenderlich 的教程通常会提供初始项目，手把手带你写代码，加上独特风格的配图，很适合用来入门某个技术。这次带来的是 Unity ECS 的入门，用 Entities 包实现一个坦克射击游戏。
  • Fixing Performance Problems - 2019.3
    • Unity 发表的关于解决性能问题的教程，里面有很多小知识点，对初学者可能有帮助。虽然之前好像看过，但这是 2019.3 版本的。
  • Cache的基本原理
    • 作者图文并茂地讲解了缓存内部是如何运作的，Visio 手绘风格的图画也很清晰明了。对缓存感兴趣的还可以进一步关注作者的专栏。
  • Refactoring.Guru
    • 这网站也图文并茂地介绍了重构、 设计模式、 SOLID 原则 （单一职责、 开闭原则、 里氏替换、 接口隔离以及依赖反转） 以及其他和智能编程主题相关的内容。
  • 每位程式設計師都該知道的記憶體知識
  • Zero allocation code in C# and Unity
    • 文章作者开源过叫 Svelto 的 ECS 框架，这篇文章是他对 Zero allocation 代码（也就是自己管理内存）的理解，也介绍了相关的概念、书籍和很多查看内存分配的工具，对想了解 DOTS 的同学可以阅读一下。

最后

其实本篇导读相当一部分在讲的是我个人怎么样看待自己目前学习情况，每次导读中所有的内容我其实只能看完一部分，怎么样更高效地学和怎么样更好地平衡生活是我最近不断思考的问题。当然了，我不会放弃。

这次导读分享的多是游戏内存、缓存、图形学相关的内容，自己没分享过某种具体实现的 Shader 的文章，是因为我认为自己基础要先打好，这也是我对其他 Shader 课程的态度。希望这次分享能对读者有帮助。

]]> 导读 游戏开发 2020年4月技术导读 /2020/04/13/2020-04-tech-reading/ 首先，感谢所有将自己时间贡献在知识分享的人们。

本文将简单地介绍下最近我看到的想学的、有意思的教程、视频等，内容不仅限于游戏开发。大家可以做个参考，说不定其中就能找到适合自己的教程，进一步打算接下来的学习。

这个文章类型和之前写的都不一样，一方面有自己时间少、沉淀不够、不能持续输出的原因，另一方面是因为这些东西都比较碎，也不好在记录生活的微博上发布一些专业的东西。至于这个导读会不会成为一个系列来更新，还要看看我有没有足够东西来分享啦。

书籍

《程序员修炼之道（第2版）》

豆瓣地址

在我经过了入门阶段之后，发现很多以前学的很多教程，都很难在工作中进行参考。恰巧云风翻译的第二版已经出版了，里面的内容让我对编程“修炼”有了更深的理解。

投资知识，收益最佳。
——本杰明·富兰克林

http://img.frankorz.com/invest-knowledge.png

学习学习再学习！

游戏开发：世嘉新人培训教材

豆瓣地址

这本书我从 17 年等到现在，三年了，拿到手之后觉得所有的等待都是值得的。

从第一章就能看出作者踏实的编程功底和力求和对优化的不倦追求。一个命令行推箱子游戏从过程式的实现，到运用 C++风格的面向对象的实现，到章节末为了讲解底层内存存储结构而把项目中所有变量都存在一个内存数组中的实现。从中作者讲解基础的 C++ 语法、位运算、指针和引用的异同等概念。

接下来的章节，作者还讲解 2D 图形处理、状态、碰撞、数学等等游戏密不可分的章节，由于作者都为章节提供了类库，因此不必担心书是否会过时，读者只需踏踏实实跟着作者打基础即可。

虽然我很少写 C++，也清楚学 C++ 在游戏开发中是逃不开的，干脆就啃这本书的同时把 C++ 也给上手了，一箭双雕！

Data-Oriented Design

一本深度讲解面向数据设计的书籍，当你熟悉了面向对象编程，可以尝试看看这本书，用一种不同的思维方式看待你的数据。Unity 开发者在 ECS 正式版公布之前，也可以先深入了解一下面向数据设计的模式。

作者在其网站公开了书籍内容，地址为：Data-Oriented Design

同时也可以参考这篇导读：Highly recommended read : dataorienteddesign.com/dodbook

公开课

图形学

零基础如何学习计算机图形学？——闫令琪的回答

游戏编程类书籍涉及的内容太杂，不适合用作专门学习图形学的参考资料。OpenGL / Shader 确实是应该学习的内容，但是以我的理解来看，更适合先入门图形学基础之后再去进一步学习，这样会简单很多。这也是我个人的理念：我们要学的是图形学，而不是图形学 API，这两者应该完全分开看待。另外 OpenGL / Shader 这块学多了会容易让人产生理解偏差，觉得图形学就等于实时渲染（当然是错的，但是很多人真的这么认为！）。

于是闫老师发布了一门公开课：“GAMES101: 现代计算机图形学入门”。

本课程将全面而系统地介绍现代计算机图形学的四大组成部分：（1）光栅化成像，（2）几何表示，（3）光的传播理论，以及（4）动画与模拟。每个方面都会从基础原理出发讲解到实际应用，并介绍前沿的理论研究。通过本课程，你可以学习到计算机图形学背后的数学和物理知识，并锻炼实际的编程能力。

官网：GAMES101: 现代计算机图形学入门

B站录播：GAMES101-现代计算机图形学入门-闫令琪

课程作业系统：GAMES2020在线课程：计算机图形学（闫令琪）课程作业系统

国外 MIT CMU 部分课程翻译

Simviso 是一个翻译国外课程的民间组织，目前已经翻译了：MIT 6.004 计算机组成原理、MIT 6.824 分布式系统 2020、CMU数据库15-445/645、斯坦福编译原理 等顶级教程。他们接下来的翻译计划也在 simviso 国外MIT CMU 斯坦福计算机科班顶级课程翻译系列 中提到。（我在想这一段字的知识浓度得有多高 Orz）

原理性的东西参考这些教程最好不过了，我们还可以跟着课程手写一个数据库、CPU 等等。

教程

Custom SRP

Catlike Coding > Custom SRP

Catlike Coding 的教程一向是从基础讲到进阶应用，在 SRP 的主题中，他写了不少基于 Unity 2019 版本的自定义渲染流水线的教程，目前还在持续更新。

Ray Tracing In One Week

跟着 Ray Tracing In One Week 系列教程一步步来做个光线追踪器，也可以在学完上面图形学公开课中的光线追踪部分后来看这个教程作为补充。这个教程也可以用 Unity 来做，例如我的 Latias94/RayTracingInOneWeekWithUnity，虽然只跟到第八章 = =。

跟完这个教程之后，如果对进一步的 DOTS、优化方面学习感兴趣的话，我还提供了下面四篇文章/项目作为参考。

Go 语言探索万物原理

了解了当前使用的技术，可以扩宽领域，学习一些和项目不相关的东西，说不定会带来灵感。

老司机带你飞系列

Github 地址：happyer/distributed-computing

  1. 《老司机带你用 Go 语言实现 MapReduce 框架》
  2. 《老司机带你用 Go 语言实现 Raft 分布式一致性协议》
  3. 《老司机带你用 Go 语言实现 Paxos 算法》
  4. 《老司机带你用 Go 语言实现分布式数据库》

7 天用 Go 动手写/从零实现系列

Github 地址：geektutu/7days-golang

  1. 7天用Go从零实现Web框架 - Gee
  2. 7天用Go从零实现分布式缓存 GeeCache
  3. 7天用Go从零实现ORM框架 GeeORM

视频

文章

  • Ray Wenderlich - Introduction to Shaders in Unity
    • Ray Wenderlich 的教程通常会提供初始项目，手把手带你写代码，加上独特风格的配图，很适合用来入门某个技术。这次带来的是如何写 Unity Shaders，实现一个简单的水流 Shader。

最后

看了看内容，这次分享的视频和文章都偏少了，其实主要是想分享前面的书籍和公开课，有机会的话有价值的视频和文章我也会多关注，并且分享到导读中。如果你喜欢这系列，或者想对这个系列有其他的想法，欢迎在评论区告诉我。

]]> 导读 游戏开发 《图解 C# 教程 第5版》与性能优化 /2020/01/31/illustrated-csharp-and-performance/ 这本书仍然是入门 C# 最好的一本书。

这本书新版出来的时候我十分关注，于是英子姐送了一本给我，本文也是答应英子姐所写的一篇文章。她一开始还问我“你现在还需要看这本入门书吗？”，我认为是的。工作了遇到了不少问题，大都跟自己基础不牢有关系。

这本书以图形为载体，生动地介绍了 C# 语言本身。其中图形对我们了解 C# 语法在内存中的本质十分有帮助，异步、异常等章节中的处理流程图也很清晰明了，这也是我看重的一点。

本文会从本书出发，简单讲讲代码优化的一些点。

在内存中的形态

为什么要了解 C# 在内存中的形态呢？

书中第四章介绍内存区域的栈中，有一句话说的很好：

作为程序员，你不需要显式地对它做任何事情。但了解栈的基本功能可以更好地了解程序在运行时在做什么，并能更好地了解 C# 文档和著作。

游戏开发中，除了业务逻辑，我们还会更关注游戏的性能本身。我们需要保证游戏能流畅运行在大部分机型上，保证每一帧能流畅地播放，例如 CPU 需要处理渲染代码、物理模拟、动画回调等等，其中我们的代码也有可能引起性能问题。我们需要更了解执行代码的代价，例如：

  • 这些代码产生了多少 GC
  • GC 只会产生一次还是每帧都会产生
  • 在极端情况下代码的性能如何
  • 是否使用了正确的数据结构
  • Unity API 或者一些库 API 的背后到底做了什么
  • …

这本书相对上一版多了 .Net Core, C# 7.0 语法的讲解，对于我而言，重温的是第 4、7、11、13、15、17、19 和 27 章节，这些内容是我工作中经常要接触、着手优化的地方。书中对于异步编程也介绍地很好，但对于我来说，反射、异步编程、新增语法等到以后有需要再看也不迟。

脚本的性能优化，无非是用更合适的代码去实现需求，不必要的内存都给我吐出来！（注：作者在生活中并没有这么吝啬）

下面会列举一些代码写法的性能对比。

结构和类

这其实也是用栈还是用堆的考量。

垃圾回收

Unity 用的是 mono 虚拟机，其堆的内存是通过垃圾回收算法 Boehm GC 来管理的，其不分代（Non-generational）和非压缩式（Non-compacting）的特性，导致了我们平常要注意避免加载过多的小内存，从而内存碎片化（Memory fragmentation）。

  • 分代：大块内存、小内存、超小内存分在不同内存区域来进行管理。此外还有长久内存，当有一个内存很久没动的时候会移到长久内存区域中，从而省出内存给更频繁分配的内存。
  • 压缩式：当有内存被回收的时候，压缩内存会把下图空的地方重新排布。
    compacting.png
  • 内存碎片化：内存过多小内存，导致大内存不能有效地被使用。
    memory fragmentation

具体可以参考 Unity 文档 Understanding the managed heap

同时也推荐高川老师的演讲：浅谈 Unity 内存管理，和我看视频时的笔记：笔记。

用结构还是类

这里推一篇微软官方文档：Choosing Between Class and Struct

引用类型被分配在堆上并被垃圾回收算法管理，值类型则分配在栈上，栈会按需 unwind 来释放他们。因此，值类型的释放比引用类型的释放开销要小。

书中 11.9 小节还提到：

对结构进行分配的开销比创建类实例小，所以使用结构代替类有时可以提高性能，但要注意装箱和拆箱的高昂代价。

值类型数组的分配和释放比引用类型数组的分配和释放开销也更小。

除了最基本的修改值类型和引用类型的区别外，要注意的是传递参数或者返回返回值的时候，值类型都会隐性地被创建，这可能也会产生没想到的内存开销。

从 .Net 内存分配成本的角度来说，类的对象储存的内存首先需要分配 4 个字节作为对象头字节（object header word），跟着再分配 4 个字节作为方法表指针（method table pointer），这些字段是服务于 JIT 和 CIL 的，是隐藏的分配成本。

保留在堆中所需的内存还会根据操作系统位数来决定：

  • 32 位系统中，堆上的对象会对齐到最近 4 字节的倍数，因此如果一个对象只有一个 byte 成员，也需要对齐占 4 个字节，因此这个对象总共占堆上 12 个字节。
  • 64 位系统中，堆上的对象会对齐到最近 8 字节的倍数，方法表指针和对象头字节也会分别占 8 字节的内存。

（注：平常开发我们不需要这么抠门，上面只是一个小知识点。）

大多时候我们都会用类型来实现设计模式、框架的设计，那什么时候使用结构体呢？我们可以遵循微软爸爸的建议：

  • 逻辑上表示单个值
  • 大小小于 16 个字节
  • 不会改变值
  • 不需要经常装箱拆箱

对于一些特定的场景下，我们也可以享受值类型数组在内存中线性排布的福利，例如内存连续、SIMD 等。Unity 的 DOTS 技术栈就是一个很好的例子。

推荐阅读：

  • 在C#中使用Struct代替Class
  • 作者用 DOTS（结构体、Job System、Burst）实现 A 星寻路实现性能飞跃：y2b 搜 “Pathfinding in Unity DOTS!”

装箱

第 17 章介绍了转换，其中提到了装箱拆箱。那么装箱的代价有多大呢？我们可以做个测试：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
public const int Iterations = 100_000;

// 其他地方初始化了 Iterations 大小的随机数组
private int[] numberArr = null; 

protected override bool MeasureTestA()
{
// 设定大小以避免自动扩容带来的性能消耗
    Stack stack = new Stack(Iterations); 
    for (int i = 0; i < Iterations; i++)
    {
        stack.Push(numberArr[i]); // int -> object 装箱
    }

    return true;
}

protected override bool MeasureTestB()
{
    Stack<int> genericStack = new Stack<int>(Iterations);
    for (int i = 0; i < Iterations; i++)
    {
        genericStack.Push(numberArr[i]);
    }

    return true;
}

profiler

查看 Profiler 可以看到，调用十次 TestA 产生了 26.7MB GC，用了 267.22 毫秒；调用十次 TestB 只产生了 3.8MB GC，用了 20.92 毫秒。因此大量的装箱拆箱会导致不必要的性能消耗，而有些消耗则是完全可以避免的。

我的 Rider 插件 Heap Allocations Viewer 也会提示我 TestA 中存在装箱的情况。

rider-boxing-plugin

最后

写到这里，发现还很多东西没讲完就已经这么多篇幅了…

大家对于平常代码的不同写法也可以测试下性能，例如：

  • foreach 和 for
  • 装箱和拆箱
  • 一维数组、多维数组（矩形数组）和交错数组（Jagged Arrays）
    • 这里还是强调下尽量使用一维数组，实在需要用多维数组的话，可以改用交错数组
  • 通过 for 循环复制数组和 Array.CopyTo 方法
  • 字符串拼接，string 和 Stringbuilder
  • 反射和 DynamicMethod
  • …

上面装箱的截图中的测试项目我也上传了 Github：Latias94/UnityCsharpPerformanceTest，不用 Unity 的同学也可以参考下实际的测试代码：UnityCsharpPerformanceTest/Assets/Scripts，自己写个命令行项目来跑下对比。

当然我们开发中还是要以需求的变化为主，不能过早优化从而破坏代码的扩展性。

]]> Unity 游戏开发 2019 年的收获与成长 /2019/12/04/2019-year-end-summary/ 今年发生了很多事情，博客也因此从七月停更到了现在，实在惭愧…现在趁着年终，赶紧抓住 2019 年的尾巴了，来总结下我的这一年。

本文真的会很啰嗦，但是希望能帮到希望用 Unity 恰饭或者其他技术恰饭的同学。

毕业

今年的上半年完成了研究生的学业，结束了留学生涯。

我的专业课程比较松，总共两年要修 16 节课的学分，但是必修课只有四节，因此我可以尽可能的选择有实战的课程。这边课程的大作业大多需要团队协作，但是有些 IT 研究生同学是跨专业过来的，不是很能写代码，所以有时候挺考验自身能力的（笑。 我组完队一般都希望能把大作业的规模做大些，一方面是作业能拿比较好的分数，另一方面是求职的时候可以拿出能往简历上放的项目经验。

毕业后我发现这种选择是对的，我的队友在毕业后还问我们的线上项目怎么开不起来了，他们也到了找工作的时间，还让我帮忙看了看简历。澳洲工作是很休闲的，大部分下午五六点就能下班。身边同学也在努力地留下来，考 PTE、CCL 考试凑分拿 PR。自己因为还是想做游戏，澳洲环境不太好，就回了国。

从面试到工作

由于课程结束三个月后才能参加毕业典礼拿到毕业证，当时我对求职还不太上心，还想等着春招。但是又不想在家里混吃混喝，就开始每天刷刷面试题，学学感兴趣的，同时也开始在某直聘找工作，打算每周面试一次，接触下当前的就业形势，同时查漏补缺。

第一周

第一周面试了家一百多人的游戏公司，一上来要求三十分钟解一道 Leetcode hard 的题…好不容易解出来了，又要求递归改迭代，又问有没有能优化的点。之后还问了些逻辑题，这时候挺庆幸自己复习了《程序员面试经典（第5版）》（第六版刚出噢），基本还能 hold 住场面，但是后来分析算法的时间复杂度分析的十分糟糕，于是就没有然后了…

当天十分沮丧，恰巧面试的地方和一个主美朋友工作的地方很接近，就约了个饭。他开导我说：”拿美术来说，不同公司也会需要不同的美术：古风游戏自然需求专精画古风的，科幻游戏需求的美术风格很明显也不一样。再面试几家就好，今天面试只代表公司不适合你。“我听了很有道理！于是继续不务正业学了喜欢的东西，简单复习复习算法，刷了刷题。

第二周

第二周又接到另一个游戏公司 HR 的面试邀请，面试时直接来了三个面试官，两个程序大佬一个制作人。很明显的，面试风格都不一样。他们事先看了我的简历，看了我的博客。刚好第一周的时候更新了一篇 DOTS 的博文，于是他们一开始就让我介绍下 Unity 的 DOTS 技术栈是什么，还有一些概念细节。后来的其他问题很明显能感觉他们在考察我知识的广度，例如图形学，我简历上提到的 C# 热更新等。

刚好那段时间”不务正业“地跟着《自己动手实现Lua》写了一半的 Lua 虚拟机，于是问到对 Lua 是否熟悉的时候，我就提了一嘴最近在学的东西，接着又展开新的问答。整个过程中，我觉得面试官的风格和第一周公司的面试风格完全不一样，但是有些地方还是答得不够好，于是又在家瞎学。

一周后，我拿到第二家公司的 Offer，成为了公司工具人。

我觉得从面试就能看出公司关注的是开发人员的哪些方面，如主美朋友所说，如果不愿意改变自己学习的风格，那就找到需求这种风格的公司，接下来的工作也印证了这一点。

上面提到的内容

了解代码的另一面

入职后，才发现公司写了一套自己的 C# 热更新，这种热更新是和 xLua 一样的注入式热更，跟 ET 框架分两个项目跑的还不一样（下文会解释）。有意思的是，在我入职过了几个月后，xLua 作者也开源了C# 注入式的热更新项目：InjectFix，作者还配套写了一套 IL 的运行时，听说性能还比 ILRuntime 更好些。

感兴趣的可以先看看 xLua 作者的讲解：

先前基于 ILRuntime 的热更新，例如 ET 框架，大多是分两个项目，主项目和热更项目，热更项目放一些需要经常修改的战斗逻辑、UI 界面等。这样可以直接把热更项目都放在 ILRuntime 上跑，整个项目都能热更，十分方便，但是这样十分依赖 ILRuntime 的性能。

那么注入式的热更有什么区别呢？我们给每个函数前加 if 判断，如果 ILRuntime 上跑的（能热更的）DLL里面有对应的方法，就执行热更的方法，这样 ILRuntime 的性能问题也能避免开来，因为我们可能只有需要热更的函数在 ILRuntime 上面跑，而不是整个项目。

那么，古尔丹，代价是什么呢？
——格罗玛什·地狱咆哮

代价就是能热更的东西极其局限，只能热更函数、和新增的类等。

在了解原因之前，我们先来看看例子，假设我们游戏就这么多代码：

1
2
3
4
5
6
7
8
9
10
// Unity 2019.2 之前，Scripting Runtime Version: .Net 3.5 Equivalent(Deprecated)
public class TestIL : MonoBehaviour
{
    void Start()
    {
        int[] arr = {1, 2, 3, 4};
        Action action = () => Debug.Log("Hello IL");
        action();
    }
}

上面是看上去如古天乐平平无奇的代码，当我们用 dnSpy 反编译 Library\ScriptAssemblies\Assembly-CSharp.dll 后会发现：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
public class TestIL : MonoBehaviour
{
...
private void Start()
{
int[] array = new int[]
{
1, 2, 3, 4
};
Action action = delegate()
{
Debug.Log("Hello IL");
};
action();
}

// 编译器生成的匿名函数
[CompilerGenerated]
private static void <Start>m__0()
{
Debug.Log("Hello IL");
}

[CompilerGenerated]
private static Action <>f__am$cache0;
}

编译器为我们的 Action 生成了匿名函数，那也就是说如果我需要更改 Debug.Log 中打印的字符串，我只需在热更 DLL 中提供：修改后的函数 + 编译器生成的匿名函数就 okay 了？实际上没那么简单，因为编译器又作妖了。

1
2
3
4
5
6
void Start()
{
    int[] arr = {1, 2, 3, 4};
    Action action = () => Debug.Log("Hello " + arr[0]); // 修改打印
    action();
}

再次查看反编译后的 DLL：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
private void Start()
{
int[] arr = new int[]
{
1, 2, 3, 4
};
Action action = delegate()
{
Debug.Log("Hello " + arr[0]);
};
action();
}

[CompilerGenerated]
private sealed class <Start>c__AnonStorey0
{
public <Start>c__AnonStorey0()
{
}

internal void <>m__0()
{
Debug.Log("Hello " + this.arr[0]);
}

internal int[] arr;
}

由于 action 中引用了局部变量，mono 编译器将本该生成的匿名方法生成了匿名类，并在调用的时候传入 arr int 数组。

现在我们调整下我们的热更新策略：如果我们检测到编译器生成的匿名函数，将其转换成匿名类，再把这个新增的类复制到热更 DLL 中。

还是有问题！

这时候就需要认识 C# 的中间语言—— MSIL（又称 IL），每句 C# 代码都可以转换成可读性较好的类似于机器代码的 IL 代码。

当我们查看 Start 函数的 IL 代码时：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
.method private hidebysig 
instance void Start () cil managed 
{
.maxstack 4
.locals init (
[0] class TestIL/'<Start>c__AnonStorey0',
[1] class [System.Core]System.Action
)

IL_0000: newobj    instance void TestIL/'<Start>c__AnonStorey0'::.ctor()
IL_0005: stloc.0
IL_0006: nop
IL_0007: ldloc.0
IL_0008: ldc.i4.4
IL_0009: newarr    [mscorlib]System.Int32
IL_000E: dup       // 下面这串是什么？怎么又引用了另外一个类？
IL_000F: ldtoken   field valuetype '<PrivateImplementationDetails>'/'$ArrayType=16' '<PrivateImplementationDetails>'::'$field-1456763F890A84558F99AFA687C36B9037697848'
IL_0014: call      void [mscorlib]System.Runtime.CompilerServices.RuntimeHelpers::InitializeArray(class [mscorlib]System.Array, valuetype [mscorlib]System.RuntimeFieldHandle)
IL_0019: stfld     int32[] TestIL/'<Start>c__AnonStorey0'::arr
IL_001E: ldloc.0
IL_001F: ldftn     instance void TestIL/'<Start>c__AnonStorey0'::'<>m__0'()
IL_0025: newobj    instance void [System.Core]System.Action::.ctor(object, native int)
IL_002A: stloc.1
IL_002B: ldloc.1
IL_002C: callvirt  instance void [System.Core]System.Action::Invoke()
IL_0031: ret
} // end of method TestIL::Start

在 dnSpy 中找了找，发现了 PrivateImplementationDetails 类：

dnspy

这看起来应该是这个数组被存到了某个地方，这个类只是提供了 id 告诉 IL 这个数组应该在哪找？通过查询 Roslyn 编译器的文档，发现了这个类的注释：”The main purpose of this class so far is to contain mapped fields and their types.“ 所以我们要热更的话，还需要将 PrivateImplementationDetails 类复制到热更 DLL 中。

我们怎么分析代码是否是匿名函数呢？Mono.Cecil 就是一套基于 IL 分析程序集的库，我们可以通过这个库来判断哪些方法不能热更等，这又是另外一个话题，略过不提。

以上只是注入热更的一个小插曲，但是涉及的东西就已经与一开始 Start 方法中的三行代码相去甚远了。如果我们还要支持重载函数的热更，泛型类中函数的热更，就更是让人掉头发的话题，涉及的 IL 十分复杂。

现代的高级语言为我们封装了太多东西，提供了方便编程的语法糖，但也为我们知根知底的学习方式设立了门槛。

但是当我们了解了 IL 中间语言的话，我们以后面对”在匿名函数引用 for 循环中变量的行为会诡异“等问题的时候，我们可以直接反编译 DLL 来看代码真正的面目是怎么样的。

不小心写了足以充当一篇文章的内容，但是我想表达的是：

  • 对于游戏开发者，我们有必要对自己的代码做了什么有充分的了解，谨慎运用语法糖，这样才能充分掌握游戏的性能。
  • 虽说我们远远没达到造 InjectFix 轮子的程度，但是了解该技术的根基——IL，再尝试根据其他文档来分析，能让我们更好的了解这个框架的背后，了解这种热更新的优缺点。

上面提到的内容

  • InjectFix C# 热更新
  • dnSpy .Net 反编译编辑器
  • Mono.Cecil 基于 IL 分析程序集的库，dnSpy 也是基于这个库来分析的。

自顶向下，再自底向上

游戏开发很多技术都倚重于硬件的能力，因此我们有必要对这些硬件的实现和原理有所了解。但这方面也是我的弱点，我个人喜欢按照兴趣来学，因此我的总结的方法是：自顶向下，再自底向上。

就如上面热更新的例子一般，自顶向下就是揭开抽象的面纱，从感兴趣的框架或库的应用入手，逐步通过各种方式来了解底层的原理。

拿 DOTS 技术栈做例子，ECS 的编程模式保证数据线性地排列在内存中，恰好能内存 cache 缓存命中率，从而得到更高效的数据读取。更多细枝末节可以先放一旁，例如 Shared components 这种与理念不相符的共享组件是怎么实现的。

知道了内存 cache 缓存命中率在其中发挥巨大作用后，我刷知乎还发现，Disruptor 库为了对齐 128 个字节方便 CPU cache line 用，选择浪费空间提高缓冲命中率。

到底内存的结构是怎么样的？缓存命中率又是什么？字节对齐又是什么？为什么这样的做法能提高性能？带着种种疑问，我们开始自底向上地了解内存结构。

从感兴趣的应用入手，了解硬件底层，这样不至于太枯燥。学到一定程度，当我们把知识网中重要的几个概念都了解之后，我们可以再阅读相关操作系统的书，将周边的知识点与之前比较大的概念相连接，互相印证，从而结成结实的知识图谱。

一开始我想重新捡起《编码：隐匿在计算机软硬件背后的语言》这本书，这本书从手电筒聊天开始，依次讲了摩斯电码、二进制、再到继电器电路、组合成 CPU 等等，能解答我的疑惑，但是后来发现节奏偏慢。于是又看了 Crash Course Computer Science（计算机科学速成课） 中讲 CPU 的一集，觉得节奏非常好，通过 12 分钟视频讲解除法电路、缓存、流水线设计、并行等概念，揭开计算机一层一层的抽象，我认为这是自底向上最好的教材。另外在知乎刷到一篇文章：《带你深入理解内存对齐最底层原理》也是很好的佐料。

了解了硬件原理之后，这种优化能带到实践中吗？一维数组的顺序访问比逆序访问要快，那么二维数组呢？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
public class TestCache : MonoBehaviour
{
private const int LINE = 10240;
private const int COLUMN = 10240;

void Start()
{
int[,] array = new int[LINE, COLUMN];
Stopwatch stopwatch = new Stopwatch();
stopwatch.Start();
for (int i = 0; i < LINE; i++)  // 344 ms
{
for (int j = 0; j < COLUMN; j++)
{
array[i, j] = i + j; // 一行一行访问
}
}

stopwatch.Stop();
Debug.Log("用时1：" + stopwatch.ElapsedMilliseconds + " ms"); 
stopwatch.Restart();
for (int i = 0; i < LINE; i++) // 1274 ms
{
for (int j = 0; j < COLUMN; j++)
{
array[j, i] = i + j; // 一列一列访问
}
}

stopwatch.Stop();
Debug.Log("用时2：" + stopwatch.ElapsedMilliseconds + " ms");
}
}

一行一行访问和一列一列访问的效率很明显不一样，自此，我们自底向上地把对硬件的了解反映到了实际编码中。

由于自己就是兴趣导向的学习，所以学东西难免有所偏科，但是我认为只要感兴趣的够多，就不怕偏科（笑。每个人有自己学习的节奏，在这里只是提供一种思路。

上面提到的内容

找到适合自己的学习方式

说起来容易，但是要运用之前，我首先需要知道学习这种知识的途径有哪些，才能从中选择最适合自己的学习方式。

拿 Unity 中的渲染来说，我能通过相关官方文档来学，能通过看博文来了解，也能通过 Direct3D、OpenGL 相关教程来学，或者重新拿起图形学的书本，因为都会涉及到渲染流水线的知识。

那么怎么样的才算是适合自己的学习方式呢？有的同学可能喜欢先把理论吃一遍再来实战，我喜欢通过动手来了解。我尝试跟着 LearnOpenGL 教程和一些 Shader 教程来学习渲染管线的知识，也初识 Batch（批次）、GPU Instancing 等名词，但是不同教程都有不同侧重：Shader 教程可能着重教你如何实现各种效果，而图形学课程可能对这些名词的背后实现语焉不详。

之后一直压着疑惑使用着这些技术，我后来又发现了一些选择：要不自己写一套软渲染器？又或者我可以通过 Unity 新出的 Scriptable Render Pipeline（可编程渲染管线）来自定义一套自己的渲染管线？这似乎已经很靠近我想学的东西了，再考虑自己的时间和兴趣，我决定跟着 catlikecoding 的 SRP 教程写一个可编程渲染管线，尝试以一种较底层的角度来了解渲染管线相关的实现。

上面提到的内容

啰嗦了这么多，其实只是想分享下我学习的经验：正所谓曲高和寡，越是进阶的知识点，教程风格越五花八门，当然也会越少人写。每个人有自己的学习风格，尽量多拓展自己的知识来源，不要将自己限制在国内教程和书籍中。

如何扩展知识来源呢？

有了选择，就可以根据自己兴趣爱好来跟着学习，想办法把他们学到脑子里！

先写，再优化

工作后的这段时间我一直在思考，我距离独立造轮子还差多少能力。先写框架划分模块？还是先实现功能？如何写出高内聚低耦合的代码？抛去代码可读性和模块的划分不谈，写出一个轮子最基本的功能对于我可能都是一个难题。

我的工位在写出热更新的大佬的旁边，一开始大佬说招我的原因，是希望我能接受他的热更新框架，继续维护。可惜自己能力不够，看懂了实现，但是却无从下手，之后也就不了了之。不过有段时间，我问大佬问题问到什么程度呢？我一转头瞄下他，他就会划着电脑椅过来等我提问…

大佬在工作室中负责战斗以外的技术攻坚，有需求的话就会主动去学，去实现，C# 热更新框架就是他的作品。后来团队觉得可能要通过帧同步来防外挂，他又开始看相关的论文，文章来从头写，虽然到现在团队还没用上。耳濡目染之下，我也会跟着大佬去看帧同步相关的内容，有时候当当小黄鸭，帮他查漏补缺。

**对于造轮子，有需求，有思路，就先开始写！**这是我这段时间从大佬身上学到的一点。例如他认为我们 UI 的数据不好管理，于是参考了《Flux 架构》和其他文章，准备将这种理念与 Unity 结合，于是他又开新坑了。

他给我的评价是：知识面较广，好学，就是不肯开始写。

说的没错，太多考虑反而会束手束脚，适得其反。先把功能写出来，设计模式按照经验来划分，能用了再优化，这是功利的做法，但也是能让人顾虑少地造轮子的做法。

新的开始

工作的节奏和上学完全不一样，虽说是 9.5 6.5 5，但是两个小时的通勤仍然让我措手不及。公司下班吃完饭，回到家九点，随便看点啥就十一点了，早上还得八点多起…

daxiong

最后尝试更换了出行方式，从地铁改成坐巴士上班，这样有位置坐，才能静下心看看书。尽量把阅读安排在通勤时间上，这样才能勉强保持学的进度。

工作方面压力也还行，平常有时间的话能关注下业务逻辑以外的东西。例如有一次运营拿来一个我们游戏的脚本样本，我花了点时间解包，学了学反编译，再让负责战斗的大佬针对性地做了点预防。这个过程对我而言也是新的经验，其中应对 iOS 外挂时借鉴了图灵的《九阴真经：iOS黑客攻防秘籍》的思路。

前不久转了正，算是给学生时代交了份答卷。随着见识的增长，自己对博文和代码又有了更高的要求。见识了“好”的文章后，自己怎么写才能组织好文章，才能更好地讲述一些知识点？

我们需要放下书本，去实践，去体验，去观察，去琢磨，去尝试，去创造，去设计，去stay hungry, stay foolish。
号称终极快速学习法的费曼技巧，究竟是什么样的学习方法？

学习、实践、总结、再清楚地解说一件事，并将其写成博文，这是我对我下一阶段的要求。其中学习总结的速度也得跟上，我已经看到有读者抱怨我博客断更了……

今年读过的书：

明年想更深入多线程、内存布局、和渲染相关的话题。

加油吧，感谢 2019 年帮助过我的所有人。

]]> Unity 游戏开发 洞明 Unity ECS 基础概念 /2019/07/14/clarify-ecs-basic-concept/ 虽然网络上已经有不少 ECS 文档的汉化，但自己读官方文档的时候也会产生不少疑问，为此通过查询各种资料，写下本文。

本文从 ECS 官方文档出发，加之内存布局结构的讲解，力求读者能够和博主一起吃透 ECS 中的基本概念。同时建议读者可以先读读我的上一篇博文《Unity DOTS 走马观花》的 ECS 部分，本文不再复述前文已经提到过的相关概念。

ECS 与 Job System

我认为有必要重申其两者的关系。

  • Job System 能帮我们方便地写出线程安全的多线程代码，其中每个任务单元称为 Job。
  • ECS，又称实体组件系统。与传统的面向对象编程相比，ECS 是一种基于数据设计的编程模式。前文从内存结构分析了 OOP 模式的缺点，也提到了 ECS 是怎么样基于数据的设计内存结构的。

Job System 是 Unity 自带的库，而要使用 ECS 我们需要从 Package Manager 中安装 “Entities” 预览包。这两者虽说完全是两种东西，但是他们能很好地相辅相成：ECS 保证数据线性地排列在内存中，这样通过更高效的数据读取，能有效提升 Job 的执行速度，同时也给了 Burst 编译器更多优化的机会。

Entities（实体）

在 World中， EntityManager 管理所有实体和组件。

当你需要创建实体和为其添加组件的时候， EntityManager会一直跟踪所有独立的组件组合（也就是原型 Archetype）。

创建实体

最简单的方法就是在编辑器直接挂一个 ConvertToEntity 脚本，在运行时中把 GameObject 转成实体。

在编辑器中挂脚本，GameObject 会在运行时中转成实体

在编辑器中挂脚本，GameObject 会在运行时中转成实体

脚本中，你也可以创建系统（System）并在一个 Job 中创建多个实体，也可以通过 EntityManager.CreateEntity 方法来一次生成大量 Entity。

我们可以通过下面四种方法来创建一个实体：

  • 用 ComponentType 数组创建一个带组件的实体
  • 用 EntityArchetype 创建一个带组件的实体
  • 用 Instantiate 复制一个已存在的实体和其当前的数据，
  • 创建一个空的实体然后再为其添加组件

也可以通过下面的方法一次性创建多个实体：

  • 用 CreateEntity 来创建相同原型（archetype）的实体并填满一个 NativeArray （要多少实体就提前设定好 NativeArray 的长度）
  • 用 Instantiate 来复制一个已存在的实体并填满一个 NativeArray
  • 用 CreateChunk 来显式创建内存块（Chunks），并且填入自定数量的给定原型的实体

增加和移除组件

实体被创建之后，我们可以增加和移除其组件。当我们这样做的时候，相关联的原型（Archetype）将会被改变， EntityManager 也需要改变内存布局，将受影响的数据移到新的内存块（new Chunk of memory），同时也会压缩原来内存块中的组件数组。

对实体的修改会带来内存结构的改变。

实体的修改包括：

  • 增加和移除组件
  • 改变 SharedComponentData的值
  • 增加和删除实体

这些操作都不能放到 Job 中执行，因为这些都会改变内存中的数据结构。因此我们需要用到命令（Commands）来保存这些操作，将这些操作存到 EntityCommandBuffer 中，然后在 Job 完成后再依次执行 EntityCommandBuffer 中储存的操作。

World（世界）

每一个 World 包含一个 EntityManager 和一系列的 ComponentSystem。一个世界中的实体、原型、系统等都不能被另外一个世界访问到。你可以创建很多 World ，例如通常我们会使用或创建一个负责主要逻辑运算的 simulation World 和负责图形渲染的 rendering World 或 presentation World。

当我们点击运行按钮进入 Play Mode 时，Unity 会默认创建一个 World，并且增加项目中所有可用的 ComponentSystem。我们也可以关闭默认的 World 从而自己创建一个。

  • Default World creation code (see file: Packages/com.unity.entities/Unity.Entities.Hybrid/Injection/DefaultWorldInitialization.cs)
  • Automatic bootstrap entry point (see file:Packages/com.unity.entities/Unity.Entities.Hybrid/Injection/AutomaticWorldBootstrap.cs)

Components（组件）

ECS 中的组件是一种结构，可以通过实现下列接口来实现：

  • IComponentData
  • ISharedComponentData
  • ISystemStateComponentData
  • ISharedSystemStateComponentData

EntityManager 会组织所有实体中独立的组件组合成不同的原型（Archetypes），还会将拥有同样原型的所有实体的组件（数据）储存到一起，都放到同一个**内存块（Chunks）**中。

如果你为一个实体新增了一个组件，那么其原型就改变了，实体的数据也需要从原来的内存块移到新的内存块，因为只有相同原型的实体数据才会放到相同的内存块中。

一个原型由很多个内存块组成，这些内存块中存的都是拥有相同原型的实体。

General Purpose Component（普通用途组件）

这里指的是最普通的组件，可以通过实现 IComponentData 接口来创建。

IComponentData 不存储行为，只储存数据。IComponentData 还是一个结构体（Struct）而不是一个类（Class），这意味着被复制时默认是通过值而不是通过引用。

通常我们会用下面的模式来修改组件数据：

1
2
3
4
5
6
var transform = group.transform[index]; // Read
    
transform.heading = playerInput.move; // Modify
transform.position += deltaTime * playerInput.move * settings.playerMoveSpeed;

group.transform[index] = transform; // Write

IComponentData 结构不包含托管对象（managed objects）的引用，所有IComponentData 被存在无垃圾回收的块内存（chunk memory）中。

你可能还听过一种组件是不包含数据、只用来标记的“Tag”组件（Tag component），其用途也很广，例如我们可以轻易地给实体加标记来区分玩家和敌人，这样系统中能更容易通过组件的类型来筛选我们想要的实体。如果我们给一个内存块（Chunk）中的所有实体都添加"Tag“组件的话，只有内存块中对应的原型会修改，不添加数据，因此官方也推荐利用好”Tag“组件。

See file: /Packages/com.unity.entities/Unity.Entities/IComponentData.cs.

Shared components（共享组件）

Shared components 是一种特殊的组件，你可以把某些特殊的需要共享的值放到 shared component 中，从而在实体中与其他组件划分开。例如有时候我们的实体需要共享一套材质，我们可以为需要共享的材质创建 Rendering.RenderMesh，再放到 shared components 中。原型中也可以定义 shared components，这一点和其他组件是一样的。

1
2
3
4
5
6
7
8
9
[System.Serializable]
public struct RenderMesh : ISharedComponentData
{
    public Mesh                 mesh;
    public Material             material;

    public ShadowCastingMode    castShadows;
    public bool                 receiveShadows;
}

当你为一个实体添加一个 shared components 时， EntityManager 会把所有带有同样 shared components 的实体放到一个同样的内存块中（Chunks）。shared components 允许我们的系统去一并处理相似的（有同样 shared components 的）实体。

内存结构

每个内存块（Chunk）会有一个存放 shared components 索引的数组。这句话包含了几个要点：

  1. 对于实体来说，有同样 SharedComponentData 的实体会被一起放到同样的内存块（Chunk）中。
  2. 如果我们有两个存储在同样的内存块中的两个实体，它们有同样的 SharedComponentData 类型和值。我们修改其中一个实体的 SharedComponentData 的值，这样会导致这个实体会被移动到一个新的内存块中，因为一个内存块共享同一个数组的 SharedComponentData 索引。事实上，从一个实体中增加或者移除一个组件，或者改变 shared components 的值都会导致这种操作的发生。
  3. 其索引存储在内存块而非实体中，因此 SharedComponentData 对实体来说是低开销的。
  4. 因为内存块只需要存其索引，SharedComponentData 的内存消耗几乎可以忽略不计。

因为上面的第二个要点，我们不能滥用 shared components。滥用 shared components 将让 Unity 不能利用好内存块（Chunk），因此我们要避免添加不必要的数据或修改数据到 shared components 中。我们可以通过 Entity Debugger 来监测内存块的利用。

拿上一段 RenderMesh 的例子来说，共享材质会更有效率，因为 shared components 有其自己的 manager 和哈希表。其中 manager 带有一个存储 shared components 数据的自由列表（freelist），哈希表可以快速地找到相应的值。内存块里面存的是索引数组，需要找数据的时候就会从 Shared Component Manager 中找。

其他要点

  • EntityQuery 可以迭代所有拥有相同 SharedComponentData 的实体
  • 我们可以用 EntityQuery.SetFilter() 来迭代所有拥有某个特定 SharedComponentData 的实体。这种操作开销十分低，因为 SetFilter 内部筛选的只是 int 的索引。前面说了每个内存块都有一个SharedComponentData 索引数组，因此对于每个内存块来说，筛选（filtering）的消耗都是可以忽略不计的。
  • 怎么样获取 SharedComponentData 的值呢？EntityManager.GetAllUniqueSharedComponentData<T> 可以得到在存活的实体中（alive entities）的所有的泛型 T 类型的SharedComponentData 值，结果以参数中的列表返回，你也可以通过其重载的方法获得所有值的索引。其他获取值的方法可以参考 /Packages/com.unity.entities/Unity.Entities/EntityManagerAccessComponentData.cs。
  • SharedComponentData 是自动引用计数的，例如在没有任何内存块拥有某个SharedComponentData 索引的时候，引用计数会置零，从而知道要删除SharedComponentData 的数据 。这一点就能看出其在 ECS 的世界中是非常独特的存在，想要深入了解可以看这篇文章《Everything about ISharedComponentData》。
  • SharedComponentData 应该尽量不去更改，因为更改 SharedComponentData 会导致实体的组件数据需要复制到其他的内存块中。

你也可以读读这篇更深入的文章《Everything about ISharedComponentData》。

System state components（系统状态组件）

SystemStateComponentData 允许你跟踪系统（System）的资源，并允许你合适地创建和删除某些资源，这些过程中不依赖独立的回调（individual callback）。

假设有一个网络同步 System State，其监控一个 Component A 的同步，则我只需要定义一个 SystemStateComponent SA。当 Entity [有 A，无 SA] 时，表示 A 刚添加，此时添加 SA。等到 Entity [无 A，有 SA] 时,表示 A 被删除（尝试销毁Entity 时也会删除 A）。
《浅入浅出Unity ECS》 BenzzZX

SystemStateComponentData 和 SystemStateSharedComponentData 这两个类型与 ComponentData 和 SharedComponentData 十分相似，不同的是前者两个类型都是系统级别的，不会在实体删除的时候被删除。

Motivation（诱因）

System state components 有这样特殊的行为，是因为：

  • 系统可能需要保持一个基于 ComponentData 的内部状态。例如已经被分配的资源。
  • 系统需要通过值来管理这些状态，也需要管理其他系统所造成的状态改变。例如在组件中的值改变的时候，或者在相关组件被添加或者被删除的时候。
  • “没有回调”是 ECS 设计规则的重要元素。

Concept（概念）

SystemStateComponentData 普遍用法是镜像一个用户组件，并提供内部状态。

上面引用的网络同步的例子中，A 就是用户分配的 ComponentData，SA 就是系统分配的 SystemComponentData。

下面以 FooComponent （ComponentData）和 FooStateComponent（SystemComponentData）做主要用途的示例。前两个用途已经在前面的网络同步例子中呈现过。

检测组件的添加

如果用户添加 FooComponent 时，FooStateComponent 还不存在。FooSystem 会在 update 中查询，如果实体只有 FooComponent 而没有 FooStateComponent,，则可以判断这个实体是新添加的。这时候 FooSystem 会加上 FooStateComponent 组件和其他需要的内部状态。

检测组件的删除

如果用户删除 FooComponent 后，FooStateComponent 仍然存在。FooSystem 会在 update 中查询，如果实体没有 FooComponent 而有 FooStateComponent,，则可以判断 FooComponent 已经被删除了。这时候 FooSystem 会给删除 FooStateComponent 组件和修改其他需要的内部状态。

监测实体的删除

通常 DestroyEntity 这个方法可以用来：

  1. 找到所有由某个实体 ID 标记的所有组件
  2. 删除那些组件
  3. 回收实体 ID 以作重用

然而，DestroyEntity 无法删除 SystemStateComponentData 。

在你删除实体时，EntityManager 不会移除任何 system state components，在它们没被删除的时候，EntityManager 也不会回收其实体的 ID 。这样允许系统（System）在一个实体被删除的时候，去整理内部的状态（internal state），也能清理关联着实体 ID 的相关的资源和状态。实体 ID 只会在所有 SystemStateComponentData 被删除的时候才被重用。

Dynamic Buffers（动态缓冲）

DynamicBuffer 也是组件的一种类型，它能把一个变量内存空间大小的弹性的缓冲（variable-sized, “stretchy” buffer）和一个实体关联起来。它内部存储着一定数量的元素，但如果内部所占内存空间太大，会额外划分一个堆内存（heap memory）来存储。

动态缓冲的内存管理是全自动的。与 DynamicBuffer 关联的内存由 EntityManager 来管理，这样当DynamicBuffer 组件被删除的时候，所关联的堆内存空间也会自动释放掉。

上面的解释可能略显苍白，实际上 DynamicBuffer 可以看成一个有默认大小的数组，其行为和性能都和 NativeArray（在 ECS 中常用的无 GC 容器类型）差不多，但是存储数据超过默认大小也没关系，上文提到了会创建一个堆内存来存储多的数据。DynamicBuffer 可以通过 ToNativeArray 转成 NativeArray 类型，其中只是把指针重新指向缓冲，不会复制数据。

【Unity】ECSで配列を格納する Dynamic Buffers 这篇文章中，作者用DynamicBuffer 来储存临近的圆柱体实体，从而更方便地与这些实体交互。

定义缓冲

1
2
3
4
5
6
7
8
9
10
11
12
13
// 8 指的是缓冲中默认元素的数量，例如这例子中存的是 Integer 类型
// 那么 8 integers （32 bytes）就是缓冲的默认大小
// 64 位机器中则占 16 bytes
[InternalBufferCapacity(8)]
public struct MyBufferElement : IBufferElementData
{
    // 下面的隐式转换是可选的，这样可以少写些代码
    public static implicit operator int(MyBufferElement e) { return e.Value; }
    public static implicit operator MyBufferElement(int e) { return new MyBufferElement { Value = e }; }

    // 每个缓冲元素要存储的值
    public int Value;
}

可能有点奇怪，我们要定义缓冲中元素的结构而不是 Buffer 缓冲本身，其实这样在 ECS 中有两个好处：

  1. 对于 float3 或者其他常见的值类型来说，这样能支持多种 DynamicBuffer 。我们可以重用已有的缓冲元素的结构，来定义其他的 Buffers。
  2. 我们可以将 Buffer 的元素类型包含在 EntityArchetypes 中，这样它会表现得像拥有一个组件一样。例如用 AddBuffer() 方法，可以通过 entityManager.AddBuffer<MyBufferElement>(entity); 来添加缓冲。

Systems（系统）

系统负责将组件数据从一个状态（state）通过逻辑处理到下一个状态。例如系统可以根据帧间隔和实体的速度，在当前帧更新所有移动实体的位置。

世界初始化后提供了三个系统组（system groups），分别是 initialization、simulation 和 presentation，它们会按顺序在每帧中执行。

系统组的概念会在下文提到。

ComponentSystem（组件系统）

ComponentSystem 通常指 ECS 实体组件系统中最基本的概念 System，它提供要执行的操作给实体。

ComponentSystem 不能包含实体的数据。从传统的开发模式来看，它与旧的 Component 类有点相似，不过 ComponentSystem 只包含方法。

一个 ComponentSystem 负责更新所有匹配组件类型的实体。例如：系统可以通过条件过滤来获得所有拥有 Player 标记（Tag）和位置（Translation）的实体，再对获得的一系列 Player 实体进行处理。其中这种条件过滤由 EntityQuery 结构定义。

要注意的是，ComponentSystem 只在主线程中执行。

我们可以通过继承 ComponentSystem 抽象类来定义我们的系统。

See file: /Packages/com.unity.entities/Unity.Entities/ComponentSystem.cs.

JobComponentSystem（任务组件系统）

前文提到了 ECS 能很好的和 JobSystem 一起合作，那么这个类型就是一个很好的例子。ComponentSystem 只在主线程中执行，而 JobComponentSystem 则能在多线程中执行，更能利用多核的优势。

自动化的 Job 依赖管理

JobComponentSystem 能帮我们自动管理依赖。原理很简单，来自不同系统的 Job 可以并行地读取相同类型的 IComponentData。如果其中一个 Job 正在写（write）数据，那么所有的 Job 就不能并行地执行，而是设定它们的依赖来安排执行顺序。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public class RotationSpeedSystem : JobComponentSystem
{
    [BurstCompile]
    struct RotationSpeedRotation : IJobForEach<Rotation, RotationSpeed>
    {
        public float dt;

        public void Execute(ref Rotation rotation, [ReadOnly]ref RotationSpeed speed)
        {
            rotation.value = math.mul(math.normalize(rotation.value), quaternion.axisAngle(math.up(), speed.speed * dt));
        }
    }

    // 所有对 Rotation 读/写的和对 RotationSpeed 进行写操作的
        // 已经排程的 Job 会自动放到 JobHandle 类型的依赖句柄 inputDeps 中
        // 在方法中，我们也需要把自己的 Job 依赖加进句柄中，并在方法末尾返回回来。
    protected override JobHandle OnUpdate(JobHandle inputDeps)
    {
        var job = new RotationSpeedRotation() { dt = Time.deltaTime };
        return job.Schedule(this, inputDeps);
    } 
}

怎么运行的？

所有 Jobs 和系统会声明它们会读/写哪些组件类型（ComponentTypes）。JobComponentSystem 返回的 JobHandle 依赖句柄会自动注册到 EntityManager 中，以及所有包含读或写（reading or writing）信息的类型中。

这样如果一个系统对 Component A 进行写操作而之后另一个系统会对其进行读操作， JobComponentSystem 会查询读取（reading）的类型列表，然后传给你一个依赖。依赖包含第一个系统返回的 JobHandle，也就是包含“一个系统对 Component A 进行写操作”这个依赖，并将其作为第二个系统的参数传入。

JobComponentSystem 简单地按照需求维护一个依赖链，这样不会对主线程造成影响。但是如果一个非 Job 的 ComponentSystem 要存取（access）相同的数据会怎么样呢？因为所有的存取都是声明好的，因此对于所有 ComponentSystem 需要进行存取的组件类型（component type）相关联的 Jobs，ComponentSystem 都会先自动完成这些相关的 Jobs，再在 OnUpdate 中调用依赖。

依赖管理是保守的（conservative）和确定性的（deterministic）

依赖管理是保守的。 ComponentSystem 只是简单的跟踪所有使用的 EntityQuery，然后基于 EntityQuery 存储需要读或写的类型。

当在一个系统中分发多个 Jobs 的时候，依赖必须被发送到所有 Jobs 中，即使不同的 Jobs 可能需要更少的依赖。如果这里被证明有性能问题，那最好的解决方法是将系统一分为二。

依赖管理的手段也是保守的。它通过提供一个非常简单的 API 来允许确定性和正确的行为。

Sync points（同步点）

所有结构性的变化都有确切的同步点（hard sync points）。 CreateEntity、Instantiate、 Destroy、 AddComponent、 RemoveComponent、SetSharedComponentData 都有一个确切的同步点。这代表所有通过 JobComponentSystem 排期的 Jobs 都会在创建实体之前自动完成。

例如，在一帧中间的 EntityManager.CreateEntity 可能带来较大的停滞，因为所有在世界中的提前排期好的 Jobs 都需要完成。

如果要在游戏中避免上面提到的停滞，可以使用 EntityCommandBuffer。

Multiple Worlds（多个世界）

所有世界（World）都有自己的 EntityManager ，因此 JobHandle 依赖句柄的集合都是分开的。一个世界中的确切的同步点（hard sync points）不会影响另外一个世界。因此，对于流式传输和程序化生成的场景，最后在一个世界中创建实体然后移到另一个世界作为一个事务（transaction）并在帧的开始执行。

对于上面的问题可以参考 ExclusiveEntityTransaction 和 System update order。

Entity Command Buffer（实体命令缓冲）

EntityCommandBuffer 解决了两个重要问题：

  1. 在 Job 中无法访问 EntityManager，因此不能通过它来管理实体。
  2. 当你使用 EntityManager 时（例如创建一个实体），你会使所有已被注入的数组和 EntityQuery 无效。（这里注入的概念大概是指：系统中可以设定某个过滤条件，给过滤条件加上 [inject] 后，系统会在启动时为这个属性根据条件注入数据，这样就能得到我们想要的数据。会无效是因为你修改了实体数据，那么结果可能会发生改变。）

EntityCommandBuffer 的抽象允许我们去把需要对数据的更改（changes）排好队，这个更改可以来自主线程或者 Jobs，这样数据可以晚一点在主线程接受更改，从而将其和获取数据分离开来。

我们有两种方法来使用 EntityCommandBuffer ：

  • 在主线程 update 的 ComponentSystem 子类有一个 PostUpdateCommands（其本身是一个EntityCommandBuffer ） 可以用，我们只要简单地把变化按顺序放进去即可。在系统的 Update 调用之后，它会立刻自动在世界（World）中进行所有数据更改。这样可以防止数组数据无效，API 也和 EntityManager 很相似。
1
2
3
4
5
6
7
8
PostUpdateCommands.CreateEntity(TwoStickBootstrap.BasicEnemyArchetype);
PostUpdateCommands.SetComponent(new Position2D { Value = spawnPosition });
PostUpdateCommands.SetComponent(new Heading2D { Value = new float2(0.0f, -1.0f) });
PostUpdateCommands.SetComponent(default(Enemy));
PostUpdateCommands.SetComponent(new Health { Value = TwoStickBootstrap.Settings.enemyInitialHealth });
PostUpdateCommands.SetComponent(new EnemyShootState { Cooldown = 0.5f });
PostUpdateCommands.SetComponent(new MoveSpeed { speed = TwoStickBootstrap.Settings.enemySpeed });
PostUpdateCommands.AddSharedComponent(TwoStickBootstrap.EnemyLook);
  • 对于 Jobs 来说，我们必须从主线程的 EntityCommandBufferSystem 中请求一个 EntityCommandBuffer，再传到 Job 里面让其调用。 每当 EntityCommandBufferSystem 进行 update，命令缓冲都会在主线程中重新把更改按创建的顺序执行一遍。这样允许我们集中进行内存管理，也保证了创建的实体和组件的确定性。

Entity Command Buffer Systems（实体命令缓冲系统）

在一个系统组中，有一个 Entity Command Buffer Systems 运行在所有系统组之前，还有一个运行在所有系统组之后。比较建议的是我们可以用已存在的命令缓存系统（command buffer system）之一，而不用创建自己的，这样可以最小化同步点（sync point）。

在 ParallelFor jobs 中使用 EntityCommandBuffers

在 ParallelFor jobs 使用 EntityCommandBuffer 存 EntityManager 的命令（command）时， EntityCommandBuffer.Concurrent 接口能保证线程安全和确定性的回放（deterministic playback）。

1
2
3
4
5
6
7
// See file: /Packages/com.unity.entities/Unity.Entities/EntityCommandBuffer.cs.
public Entity CreateEntity(int jobIndex, EntityArchetype archetype = new EntityArchetype())
{
    ...
    m_Data->AddCreateCommand(chain, jobIndex, ECBCommand.CreateEntity,  index, archetype, kBatchableCommand);
    return new Entity {Index = index};
}

EntityCommandBuffer.Concurrent 的公共方法都会接受一个 jobIndex 参数，这样能回放（playback）已经按顺序保存好的命令。 jobIndex 作为 ID 必须在每个 Job 中唯一。从性能考虑，jobIndex 必须是传进 IJobParallelFor.Execute() 的不断增长的 index。除非你真的知道你传的是啥，否则最安全的做法就是把参数中的 index 作为 jobIndex 传进去。用其他 jobIndex 可能会产生正确的结果，但是可能在某些情况下会有严重的性能影响。

1
2
3
4
5
6
7
8
9
10
11
12
namespace Unity.Jobs
{
    [JobProducerType(typeof (IJobParallelForExtensions.ParallelForJobStruct<>))]
    public interface IJobParallelFor
    {
    /// <summary>
    ///   <para>Implement this method to perform work against a specific iteration index.</para>
    /// </summary>
    /// <param name="index">The index of the Parallel for loop at which to perform work.</param>
    void Execute(int index);
    }
}

System Update Order（系统更新顺序）

组件系统组（Component System Groups）其实是为了解决世界（World）中各种 update 的顺序问题。一个系统组中包含了很多需要按照顺序一起 update 的组件系统（component systems），可以来指定它成员系统（member system）的 update 顺序。

和其他系统一样， ComponentSystemGroup 也继承自 ComponentSystemBase ，因此系统组可以当成一个大的“系统”，里面也用 OnUpdate() 函数来更新系统。它也可以被指定更新的顺序（在某个系统的之前或之后更新等，下文会讲），并且也可以嵌入到其他系统组中。

默认情况下， ComponentSystemGroup 的 OnUpdate() 方法会按照成员系统（member system）的顺序来调用他们的 Update()，如果成员系统也是一个系统组，那么这个系统组也会递归地更新它的成员系统。总体的系统遵循树的深度优先遍历。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// See file: /Packages/com.unity.entities/Unity.Entities/ComponentSystemGroup.cs.
protected override void OnUpdate()
{
    if (m_systemSortDirty)
        SortSystemUpdateList();

    foreach (var sys in m_systemsToUpdate)
    {
        try
        {
            sys.Update();
        }
        catch (Exception e)
        {
            Debug.LogException(e);
        }
        if (World.QuitUpdate)
            break;
    }
}

System Ordering Attributes（系统顺序属性）

  • [UpdateInGroup] 指定某个系统成为一个 ComponentSystemGroup 中的成员系统。如果没有用这个属性，这个系统会自动被添加到默认世界（default World）的 SimulationSystemGroup 中。
  • [UpdateBefore] 和 [UpdateAfter] 指定系统相对于其他系统的更新顺序。这两个系统必须在同一个系统组（system group）中，前文说到系统组也可以嵌套，因此只要两个系统身处同一个根系统组即可。
    • 例子：如果 System A 在 Group A 中、System B 在 Group B 中，而且 Group A 和 Group B 都是 Group C 的成员系统，那么 Group A 和 Group B 的相对顺序也决定着 System A 和 System B 的相对顺序，这时候就不需要明确地用属性标明顺序了。
  • [DisableAutoCreation] 阻止系统从默认的世界初始化中创建或添加到世界中。这时候我们需要显式地创建和更新系统。然而我们也可以把这个系统和它的标记（tag）加到 ComponentSystemGroup 的更新列表中（update list），这样这个系统会正常地自动更新。

Default System Groups（默认系统组）

默认世界（default World）包含 ComponentSystemGroup 实例的层次结构（hierarchy）。在 Unity Player Loop 中会添加三个根层次（root-level）的系统组。

下图中打开 Entity Debugger，也能看到这三个系统组和其顺序。

这三个系统组各司其职， InitializationSystemGroup 做初始化工作， SimulationSystemGroup 在 Update 中做主要的逻辑运算， PresentationSystemGroup 做图形渲染工作。

如果勾选 “Show Full Player Loop” 项，还能看到完整的游戏主循环，以及系统组执行的顺序。

下面列表也展示了预定义的系统组和其成员系统：

  • InitializationSystemGroup （在游戏循环（Player Loop）的 Initialization 层最后 update）
    • BeginInitializationEntityCommandBufferSystem
    • CopyInitialTransformFromGameObjectSystem
    • SubSceneLiveLinkSystem
    • SubSceneStreamingSystem
    • EndInitializationEntityCommandBufferSystem
  • SimulationSystemGroup（在游戏循环的 Update 层最后 update）
    • BeginSimulationEntityCommandBufferSystem
    • TransformSystemGroup
      • EndFrameParentSystem
      • CopyTransformFromGameObjectSystem
      • EndFrameTRSToLocalToWorldSystem
      • EndFrameTRSToLocalToParentSystem
      • EndFrameLocalToParentSystem
      • CopyTransformToGameObjectSystem
    • LateSimulationSystemGroup
    • EndSimulationEntityCommandBufferSystem
  • PresentationSystemGroup（在游戏循环的 PreLateUpdate 层最后 update）
    • BeginPresentationEntityCommandBufferSystem
    • CreateMissingRenderBoundsFromMeshRenderer
    • RenderingSystemBootstrap
    • RenderBoundsUpdateSystem
    • RenderMeshSystem
    • LODGroupSystemV1
    • LodRequirementsUpdateSystem
    • EndPresentationEntityCommandBufferSystem

P.S. 内容可能在未来有更改

Multiple Worlds（多个世界）

前文多处提到默认的世界，实际上我们可以创建多个世界。同样的组件系统（component system）的类可以在不同的世界中初始化，而且每个实例都可以处于不同的同步点以不同的速度进行update。

当前没有方法手动更新一个世界中的所有系统，但是我们可以控制哪些系统被哪个世界控制，和它们要被加到哪个现存的世界中。自定义的世界可以通过实现 ICustomBootstrap 接口来创建。

Tips and Best Practices（提示与最佳实践）

  • **用 [UpdateInGroup] 为你的系统指定一个 ComponentSystemGroup 系统组。**如果没有用这个属性，这个系统会自动被添加到默认世界（default World）的 SimulationSystemGroup 中。
  • **用手动更新循环（manually-ticked）的 ComponentSystemGroups 来 update 在主循环中的系统。**添加 [DisableAutoCreation] 阻止系统从默认的世界初始化中创建或添加到世界中。这时候我们可以在主线程中调用 World.GetOrCreateSystem() 来创建系统，调用 MySystem.Update() 来 update 系统。如果你有一个系统要在帧中早点或者晚点运行，这种做法能更简单地把系统插到主循环中。
  • **尽量使用已存在的 EntityCommandBufferSystem 而不是重新添加一个新的。**因为一个 EntityCommandBufferSystem 代表一个主线程等待子线程完成的同步点（sync point），如果重用一个在每个根系统组（root-level system group）中预定义的 Begin/End 系统，就能节省多个同步点所带来的额外时间间隔（可以回去看同步点小节的示意图，同步点的位置是由最晚执行完的子线程所决定的）。
  • **避免放自定义的逻辑到 ComponentSystemGroup.OnUpdate() 中。**虽然 ComponentSystemGroup 功能上和一个组件系统（component system）一样，但是我们应该避免这么做。因为它作为一个系统组，在外面不能马上知道成员系统是否已经执行了 update，因此推荐的做法是只让系统组当一个组（group）来用，而把逻辑放到与其分离的组件系统中，再定好该系统与系统组的相对顺序。

最后

自己才刚考完试，所以计划的文章一直拖到现在。ECS 对我而言充满着吸引力，可能有些程序员也会对性能特别执着吧，它就像魔法一样，完全不同的开发模式，还需要我们深入了解内存的结构。尽管 ECS 可能在工作中对我是一种屠龙技，但有些知识啊，学了就已经很开心了~

我的毕业季也到来了，有空的话可能会写写 Demo 把剩下的实践部分补完，当然计划也可能搁浅。不管怎么样，希望本文对 ECS 同好有所帮助，有问题也欢迎在评论指出。

参考

]]> Unity 游戏开发 ECS Unity DOTS 走马观花 /2019/05/07/simple-talk-unity-dots/ The Big Picture

简单介绍 Data-Oriented Technology Stack (DOTS, 数据导向型技术栈) ，其包含了 C# Job System、the Entity Component System (ECS) 和 Burst。

特点

DOTS 要实现的特点有：

  • **性能的准确性。**我们希望的效果是：如果循环因为某些原因无法向量化，它应该会出现编译器错误，而不是使代码运行速度慢 8 倍，并得到正确结果，完全不报错。
  • 跨平台架构特性。我们编写的输入代码无论是面向 iOS 系统还是 Xbox，都应该是相同的。
  • 我们应该有不错的迭代循环。在修改代码时，可以轻松查看为所有架构生成的机器代码。机器代码“查看器”应该很好地说明或解释所有机器指令的行为。
  • 安全性。大多数游戏开发者不把安全性放在很高的优先级，但我们认为，解决 Unity 出现内存损坏问题是关键特性之一。在运行代码时应该有一个特别模式，如果读取或写入到内存界限外或取消引用 Null 时，它能够提供我们明确的错误信息。

其中向量化指的是 Vectorization。

向量化的相关介绍：

Burst

Unity 构建了名为 Burst 的代码生成器和编译器。

当使用 C# 时，我们对整个流程有完整的控制，包括从源代码编译到机器代码生成，如果有我们不想要的部分，我们会找到并修复它。我们会逐渐把 C++ 语言的性能敏感代码移植为 HPC# （高性能 C#，下文会提到）代码，这样会更容易得到想要的性能，更难出现 Bug，更容易进行处理。

如果 Asset Store 资源插件的开发者在资源中使用 HPC# 代码，资源插件在运行时代码会运行得更快。除此之外，高级用户也会通过使用 HPC# 编写出自定义高性能代码而受益。

ECS Track: Deep Dive into the Burst Compiler - Unite LA

Burst 对于 HPC# 更详细的支持可以在下面找到：

Burst User Guide

深入栈

向量化（Vectorization）无法进行的常见情况是，编译器无法确保二个指针不指向相同的内存，即混淆情况（Alias）。Alias 的问题在 Unity GDC 中也有一个演讲提到过：Unity at GDC - C# to Machine Code。

Collections 类就是为了解决这个问题而诞生的，里面包含 NativeList、NativeHashMap<TKey, TValue>、NativeMultiHashMap<TKey, TValue> 和 NativeQueue 四种额外的数据结构。

两个 NativeArray 之间从不会发生混淆这种情况，这也是为什么我们将会经常使用这些数据结构。我们可以在 Burst 中运用这个知识，使它不会由于害怕两个数组指针指向相同内存而放弃优化。

Unity 还编写了 Unity.Mathemetics 数学库，提供了很多像 Shader 代码的数据结构。Burst 也能和这数学库很好的工作，未来 Burst 将能够为 math.sin() 等计算作出牺牲精度的优化。

对于 Burst 而言，math.sin() 不仅是要编译的 C# 方法，Burst 还能理解出 sin() 的三角函数属性，同时知道 x 值较小时会出现 sin(x) 等于 x 的情况，并了解它能替换为泰勒级数展开，以便牺牲特定精度。

跨平台和架构的浮点准确性是 Burst 未来的目标。

传统模式的问题

传统模式指的是什么呢？

  • 跟 MonoBehaviours 打交道
  • 数据和其处理过程耦合在一起
  • 高度依赖引用类型

问题一：数据分布在内存的各个角落

离散的数据导致搜索效率十分低下，还有 Cache Miss 的问题，这个问题可以参考下面的链接：

ECS 的泛泛之谈

问题二：很多不必要的数据也被提供了

例如当我们要调用 Transform 时，可能实际上我们只需要 position 和 rotation 两个属性来移动 gameObject，但是其他不需要的数据也被提供给了 gameObject。

问题三：低效的单线程数据处理

传统模式只使用单线程来按顺序一个一个地处理数据和操作，这样十分低效。

高性能 C＃（HPC#）

当我们使用 C# 语言时，仍然无法控制数据在内存中如何进行分布，但这是我们提升性能的关键点。

除此之外，标准库面向的是“堆上的对象”和“具有其它对象指针引用的对象”。

也就是意味着，当处理性能敏感代码时，我们可以放弃使用大部分标准库，例如：Linq、StringFormatter、List、Dictionary。禁止内存分配，即不使用类，只使用结构、映射、垃圾回收器和虚拟调用，并添加可使用的部分新容器，例如：NativeArray 和其他集合类型。

我们可以在越界访问时得到错误和错误信息，以及使用 C++ 代码时的调试器支持和编译速度。我们通常把该子集称为高性能 C# 或 HPC#。

它可以被总结为：

  • 大部分的原始类型（float、int、uint、short、bool…），enums，structs 和其他类型的指针
  • 集合：用 NavtiveArray<T> 代替 T[]
  • 所有的控制流语句（除了 try、finally、foreach、using）
  • 对 throw new XXXException(...) 给予基础支持

Job System

Job System 是针对上述传统模式问题的一种解决方式。例如下图可以把发射子弹看成一个 Job，从而用多线程来并行地处理发射操作。

目前主流的 CPU 有 4-6 个物理核心，8-12 个逻辑核心，多线程处理将能够更好地发挥 CPU 的性能。

传统的多线程问题也有很多：

  • 线程安全的代码十分难写
  • 竞态条件，也就是计算结果依赖于两个或更多进程被调度的顺序
  • 低效的上下文切换，切换线程的时候十分耗时

而 Job System 就是专注解决上面问题的一个方案，这样我们就能享受着多线程的好处来开发游戏。当然了，我们也要写出正确的 ECS 代码，熟悉新的开发模式。

解决的多线程问题

**C++ 和 C# 都无法为开发者编写线程安全代码提供太多帮助。**即使在今天，拥有多个核心游戏消费级硬件发展至今已经过去了十年，但依旧很难有效处理使用多个核心的程序。

数据冲突，不确定性和死锁是使多线程代码难以编写的挑战。Unity 想要的特性是“确保代码调用的函数和所有内容不会在全局状态下读取或写入”。Unity 希望应该让编译器抛出错误来提醒，而不是属于“程序员应遵守的准则”，Burst 则会提供编译器错误。

Unity 鼓励 Unity 用户编写 “Jobified” 代码：将「所有需要发生的数据转换」划分为 Job。

Job 会明确指定使用的只读缓冲区和读写缓冲区，尝试访问其它数据会得到编译器错误。Job 调度程序会确保在 Job 运行时，任何程序都不会写入只读缓冲区。Unity 也会确保在 Job 运行时，任何程序都不会读取读写缓冲区。

如果调度的 Job 违反了这些规则，我们会得到运行时错误（通常这种错误会在竞态条件出现时得到）。错误信息会说明，你正在尝试调度的 Job 想要读取缓冲区 A，但你之前已经调度了会写入缓冲区 A 的 Job ，所以如果想要执行该操作，需要把之前的 Job 指定为依赖。

Entity Component System

Unity 一直以组件的概念为中心，例如：我们可以添加 Rigidbody 组件到游戏对象上，使对象能够向下掉落。我们也可以添加 Light 组件到游戏对象上，使它可以发射光线。我们添加 AudioEmitter 组件，可以使游戏对象发出声音。

我们实现组件系统的方法并没有很好地演变。过去我们使用面向对象的思维编写组件系统，导致组件和游戏对象都是“大量使用 C++ 代码”的对象，创建或销毁它们需要使用互斥锁修改“id 到对象指针”的全局列表。

通过使用面向数据的思维方式，我们可以更好地处理这种情况。我们可以保留用户眼中的优良特性，即只需添加组件就可以实现功能，而同时通过新组件系统取得出色的性能和并行效果。

这个全新的组件系统就是实体组件系统 ECS。简单来说，如今我们对游戏对象进行的操作可用于处理新系统的实体，组件仍称作组件。那么区别是什么？区别在于数据布局。

ECS 数据布局

ECS 使用的数据布局会把这些情况看作一种非常常见的模式，并优化内存布局，使类似操作更加快捷。

组件（Component）

首先要明确的是这里的“组件”与上文提到的 Rigidbody “组件”是不一样的概念。ECS 中的组件只会存单纯的数据，不参与任何逻辑运算，逻辑运算会交由系统（System）来处理。

原型（Archetype）

ECS 会在内存中对带有相同组件（Component）集的所有实体（Entity）进行组合。ECS 把这类组件集称为原型（Archetype）。

下图的原型就是由 Position 组件、Velocity 组件、Rigidbody 组件和 Renderer 组件组成的。

如果一个实体只有三个组件（不同于前面提到的原型），那么那三个组件就组成了一个新的原型。

下面的图来自 Unite LA 的一次演讲的讲义， 很遗憾那次演讲没有录制下来。讲义可以在这里找到。

ECS 以 16k 大小的块（Chunk）来分配内存，每个块仅包含单个原型中所有实体的组件数据。

一个帖子中有人提供了更加形象的内存布局图，例如上半部分的原型由 Position 组件和 Rock 组件组成，其中整个原型占了一个块（Chunk），两个组件的数据分别存在两个数组中，里面还带着组件数据对应的实体的信息。

每个原型都有一个 Chunks 块列表，用来保存原型的实体。我们会循环所有块，并在每个块中，对紧凑的内存进行线性循环处理，以读取或写入组件数据。该线性循环会对每个实体运行相同的代码，同时为 Burst 创造向量化（Vectorization，可以参考 StackOverflow 的问题）处理的机会。

每个块会被安排好内存中的位置，以便于快速从内存得到想要的数据，详情可以参考下面的文章。

Unity2018 ECS 框架 Entities 源码解析（二）组件与 Chunk 的内存布局 - 大鹏的专栏

实体（Entity）

实体是什么？实体只是一个 32 位的整数 key （和一些额外的数据例如 index 和 version 实体版本，不过在这里不重要），所以除了实体的组件数据外，不必为实体保存或分配太多内存。实体可以实现游戏对象的所有功能，甚至更多功能，因为实体非常轻量。

实体的性能消耗很低，所以我们可以把实体用在不适合游戏对象的情况，例如：为粒子系统内的每个单独粒子使用一个实体。

实体本身不是对象，也不是一个容器，它的作用是把其组件的数据关联到一起。

系统（System）

我们不必使用用户的 Update 方法搜索组件，然后在运行时对每个实例进行操作，使用 ECS 时我们只需静态地声明：我想对同时附带 Velocity 组件和 Rigidbody 组件的所有实体进行操作。为了找到所有实体，我们只需找到所有符合特定“组件搜索查询”的原型即可，而这个过程就是由系统（System）来完成的。

很多情况下，这个过程会分成多个 Job ，使处理 ECS 组件的代码达到几乎 100% 的核心利用率。ECS 会完成所有工作，我们只需要提供对每个实体运行的代码即可。我们也可以手动处理块迭代过程（IJobChunk）。

当我们从实体添加或移除组件时，ECS 会切换原型。我们会把它从当前块移动到新原型的块，然后交换之前块的最后实体来“填补空缺”。

在 ECS 中，我们还要静态声明要对组件数据进行什么处理，是 ReadOnly 只读还是 ReadWrite 读写（Job System 一小节提到过的两种缓冲区）。通过确定仅对 Position 组件进行读取，ECS 可以更高效地调度 Job ，其它需要读取 Position 组件的 Job 不必进行等待。

大体上，实体提供纯粹的数据给系统，系统根据自己所需要的组件来获得相应的满足条件的实体，最后系统再通过多线程来基于 Job System 来处理数据。

这种数据布局也解决了 Unity 长期以来的困扰，即：加载时间和序列化的性能。现在从大型场景加载或流式处理 ECS 数据的时间，不会比从硬盘加载和使用原始字节多多少。

优点

总的来说，ECS 有以下好处：

  • 为性能而生
  • 更容易写出高度优化和可重用的代码
  • 更能充分利用硬件的性能
  • 原型的数据被紧密地排列在内存中
  • 享受 Burst 编译器带来的魔法

缺点

对 ECS 的常见观点是：ECS 需要编写很多代码。因此，实现想要的功能需要处理很多样板代码。现在针对移除多数样板代码需求的大量改进即将推出，这些改进会使开发者更简单地表达自己的目的。

Unity 暂时没有实现太多这类改进，因为 Unity 现在正专注于处理基础性能。

太多样板代码对 ECS 游戏代码没有好处，我们不能让编写 ECS 代码比编写 MonoBehaviour 更麻烦。
——Unity

而为网页游戏而生的基于 ECS 的 Project Tiny 已经实现了部分改进，例如：基于 lambda 函数的迭代 API。

最后

由于自己空闲时间不多，只能囫囵吞枣地拼凑出这样一篇笔记。上面大部分文字都是来自 Unity 的博文介绍，自己加了其他的内容帮助理解。本文从内存布局介绍了 ECS 的概念，也介绍了 Job System 和 Burst。我相信走过一遍文章之后，能清楚 Unity 对数据驱动的未来开发趋势的布局，也能更加容易从 Unity ECS Sample 中理解如何实践 ECS。

参考

]]> Unity 游戏开发 ECS 属于 Unity 的 Flutter——UIWidgets /2019/04/01/uiwidgets-practice/ 介绍

UIWidgets 是 Unity 的一个插件包，是一个从 Google 的移动 UI 框架 Flutter 演变过来的 UI 框架。

相对于原生开发的高开发成本（不同平台都需要不同的一套代码），Flutter、React-Native 等这种跨平台 UI 框架应运而生。

Flutter 自 2018 年 3 月发布以来，社区不断壮大。由于 Flutter 自身设计理念的出色，Unity 中国已经着手将其移植过来。当然了，也因为这两个东西都非常的年轻，因此开发的时候都像开荒一样。

框架图

Flutter 有自己的一套渲染系统，那么 Unity 作为一个游戏引擎，底层的图形 API 用自己的一套东西就行了，因此移植过来更方便了。

Flutter 框架结构

UIWidgets 框架结构

执行效率

这里提一些基础的知识：

Batch 就是 DrawCall 的另一种说法，了解渲染流水线的同学会知道流水线在 CPU 与 GPU 之间通信时，一般有三个步骤：

  1. 把数据加载到显存中。
  2. 设置渲染状态。
  3. 调用 Draw Call

Draw Call 就是一个调用命令，让 CPU 告诉 GPU 要怎么样用给定的渲染状态和输入的顶点信息来计算。Batch 里面装着顶点信息，也就是 DrawCall 中 GPU 需要的顶点信息。

DrawCall 可以在 Profiler 中看，Batches 可以在 Stats 窗口看，大家可以仔细看看上面动图（右键在新标签页打开图片）里面的数据变化。

在我随便写的一个例子中间，可以看到 Batches 数只有 1 。即使在有动画的时候 Batches 会多一点，但动画停止后 DrawCall 和 Batches 都马上下来了。这也有我这个应用写的太简单的原因，但是这种效率还是非常值得期待的。

组件树

学过前端的同学应该熟悉组件树，这里就不介绍了。

为了更高的渲染效率，Unity 采用了 Render Object Compositiing 的技术。

如果一个子树没有发生改变，Unity 就会将其渲染到一个离屏的 Render Texture 上缓存下来，需要的时候再将其贴到屏幕上。

相比之下，以前的做法是，Canvas 只要有 UI element 改动了，整个 Canvas 都需要重新绘制。即使也有一种优化做法是准备两个 Canvas 分别绘制动态 UI element 和 静态 UI element，但这样也存在很多手动管理的地方。

另外一方面，你可能也意识到了，我们不需要再管什么用同一个材质等等来优化图的合批，UIWidgets 会自动来管理这些事情。这方面也跟 FairyGUI 非常像，开发者能专注在生产效率上，让插件来管理麻烦的事情。

优点

  • 能开发游戏以外的 APP
  • 游戏中的 UI
  • 新的用户体验
  • 不用管渲染过程，提升效率
  • 因为是 Unity 的插件，可以轻松加各种粒子效果和其他骚操作。
  • 一套代码能跑在游戏中、APP 中、网页中和 Unity 的 Editor 窗口中。（开发者还用其做了一个 Unity 中文文档的网站，一套代码能用在网页上和 APP 端）
  • 在静态页面进行降帧的优化，有动画效果再把帧率提上来。
  • 和 Flutter 的 API 几乎一样，可以参考 Flutter 教程来用 UIWidgets 搭应用。

缺点

  • 无论是 Flutter 还是 UIWidgets 都还很年轻，有很多组件 UIWidgets 还没移植过来（GridView、Circle Avatar 等等）
  • 官方示例、文档还没完善
  • 开发时是开荒模式，所以可能忍不住直接转用 Flutter 去了…

我的示例

这里借用了 ミライ小町 的模型，所以代码窗口大小会比较大。（项目里面还有ミライ小町的跳舞动画 animation！）

项目仓库：Latias94/UIWidget-Practice

UIWidgets：UnityTech/UIWidgets

官方讲解录播：[官方直播] UIWidgets - 不止游戏！如何使用 Unity 开发跨平台应用

]]> Unity 游戏开发 不越狱在 iOS 12.113.3 设备安装 Kodi /2019/01/13/install-kodi-with-tweakbox/ 2020 年 2 月 11 日更新另外一种方法

今天一不小心发现 Kodi 这个播放神器居然还有 iPad 版！

但是苹果 App Store 不允许 Kodi 应用商家，于是自己在网上找了些方法：

  1. 越狱（手动再见）
  2. 下载官方提供的安装包用 Xcode 打包进去（太麻烦）
  3. 国内同步助手等提供的“VIP 服务”，购买服务后，用它们提供企业证书来下载（吃相难看）
  4. …

2020 年 2 月 11 日更新

最近又想装回 Kodi，但是 Tweakbox 自己用不了了，于是找了找发现了 AppCake。

AppCake 声称能在越狱和非越狱的手机上使用，直接在设备上给应用签名。

  1. 手机 Safari 打开 https://iphonecake.com/app/，点 Install。
  2. 安装描述文件
  3. 打开应用后应该还要再要你安装另一个描述文件用来给应用签名
  4. Tweaked Tab 标签页中下载安装 Kodi!

介绍 Tweakbox

最终发现了国外一个不错的免费服务：Tweakbox，官方介绍也很令人振奋：

TweakBox is an app store where you can download apps for iOS devices that are not available in the official Apple app store. TweakBox App is completely free and it has tons of features that make it a very popular choice among the other third party app stores.

简而言之，Tweakbox 允许你：

  • 不需要越狱，苹果 ID
  • 下载部分 Appstore 上没有或者付费的软件和游戏
  • 下载部分主流的修改增强版软件和游戏

安装

  1. iPhone 和 iPad 设备上在 Safari 浏览器中进入网页 Download
  2. 点 “Install Now” 按钮安装描述文件
  3. 然后就会下载 Tweakbox 应用
  4. 打开设置 -> 通用 -> 描述文件与设备管理 -> TweakBox 点击信任
  5. 之后就能打开 Tweakbox 应用来安装应用了！
  6. 打开 Tweakbox，点击屏幕上方的 Apps 选项，点击 Tweakbox Apps 一列，Kodi 应用就在其中。

发现 Kodi!

点进去 install 就能下载应用了，下载完还需要再次去信任描述文件才能使用。

唯一有点缺陷的是 Kodi 有时会弹出插屏广告，断网使用即可。

汉化参考：KODI 播放器 V17 设置中文

更多

前面说到 Tweakbox 还能安装其他实用的应用：

增强版 Spotify

碎碎念

周更博客真的难 = =，有些主题觉得没比别人写的好，于是就不想写了…

这周先水过去，再次赞下 Tweakbox！

]]> 工具癖 iPad APP Unity 开源双端框架 ET 中初尝热更新技术 /2019/01/06/hotfix-introduction-of-unity-et-framework/ ET 框架简介

正所谓时势造英雄，在 Web 开发领域或者传统软件开发领域中，人们把经过千锤百炼的代码总结出一套开发框架，从而提高开发效率，让开发者能更专注于业务本身。对于游戏领域而言，不同游戏需求的东西也不一样：有的游戏对性能有着苛刻要求，有的游戏需要快速地迭代出来，有的游戏需要联网热更新等等。因此不同的游戏框架应运而生。

例如：

  • Game Framework 是一个基于 Unity 引擎的游戏框架，主要对游戏开发过程中常用模块进行了封装，很大程度地规范开发过程、加快开发速度并保证产品质量。
  • QFramework 一套渐进式的快速开发框架。框架内部积累了多个项目的在各个技术方向的解决方案。
  • Entitas 一套基于 C# 和 Unity 的实体组件系统。
  • Entities Unity 官方的实体组件系统实现，不过还是 Beta 版本，详细介绍可以查看官网。
  • StrangeIoC 一套基于 C# 和 Unity 的控制反转 (Inversion-of-Control) 框架。

今天介绍的是 ET 框架。

ET是一个开源的游戏客户端（基于unity3d）服务端双端框架，服务端是使用C# .net core开发的分布式游戏服务端，其特点是开发效率高，性能强，双端共享逻辑代码，客户端服务端热更机制完善，同时支持可靠udp tcp websocket协议，支持服务端3D recast寻路等等

ET 框架能让我们只用 C# 就能搞定前后端，热更新方面也采用了基于 C# 的 IL 运行时——ILRuntime， 贯彻了 “珍爱生命，远离 Lua” 这句话。目前自己接触的大多是客户端部分，因此服务器方面不做介绍。

框架文件结构

ET 官网 本身给了很多介绍，我们可以克隆 Git 仓库到本地。

下面来看看每个文件夹的作用：

客户端文件结构

本文主要来介绍客户端，因此进入到 Unity 文件夹，文件夹结构如下：

当前 Master 分支目前需要 Unity 2018.3 以上版本。使用之前需要参考下官方的 运行指南。

在 VS 中重新编译，或者 Rider Rebuild 一下项目。Scene 选择 Scenes\Init.unity，点 Play 按钮应该就能成功运行，看到登陆界面。

组件设计

ET 框架使用了组件的设计，一切都是实体（Entity）和组件（Component），官方文档 组件设计 介绍的很详细。

看完文档，我们来看看项目代码的启动入口。

这个 Init.cs 文件，在 Model 文件夹下。可能有同学注意到 Hotfix 文件夹下也有一个 Init.cs 文件，而且这两个文件夹的结构大同小异，两边都有一些相同的文件，而它们只是命名空间不一样。这是因为我们用到 ILRuntime，而 ILRuntime 最好不要跨域继承。

Model/Init.cs 文件中

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
private async ETVoid StartAsync()
{
try
{
...
// 添加了组件，就赋予了各种功能。
// 例如加了 Timer 组件，就有了计时功能
Game.Scene.AddComponent<TimerComponent>();
...

// 下载热更用的 AssetBundle 包
await BundleHelper.DownloadBundle();
// 加载热更用的dll等文件，调用 Hotfix/Init.cs
Game.Hotfix.LoadHotfixAssembly();

// 加载配置
Game.Scene.GetComponent<ResourcesComponent>().LoadBundle("config.unity3d");
Game.Scene.AddComponent<ConfigComponent>();
// 加载后卸载相应的 AB 包
Game.Scene.GetComponent<ResourcesComponent>().UnloadBundle("config.unity3d");
Game.Scene.AddComponent<OpcodeTypeComponent>();
Game.Scene.AddComponent<MessageDispatcherComponent>();

Game.Hotfix.GotoHotfix();

Game.EventSystem.Run(EventIdType.TestHotfixSubscribMonoEvent, "TestHotfixSubscribMonoEvent");
}
...
}

通过组件设计，可以轻易地加载组件和卸载组件，例如我可以写一个心跳包组件来每隔30秒发送一个心跳包到服务器，当我需要这个组件的时候，可以直接 AddComponent，不需要的时候可以 RemoveComponent 移除组件。

登陆界面的热更新启动过程

接下来看到 Hotfix/Init.cs 文件中

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
public static void Start()
{
try
{
// 注册热更层回调
ETModel.Game.Hotfix.Update = () => { Update(); };
ETModel.Game.Hotfix.LateUpdate = () => { LateUpdate(); };
ETModel.Game.Hotfix.OnApplicationQuit = () => { OnApplicationQuit(); };
...
// 加载热更配置
ETModel.Game.Scene.GetComponent<ResourcesComponent>().LoadBundle("config.unity3d");
Game.Scene.AddComponent<ConfigComponent>();
ETModel.Game.Scene.GetComponent<ResourcesComponent>().UnloadBundle("config.unity3d");

UnitConfig unitConfig = (UnitConfig)Game.Scene.GetComponent<ConfigComponent>().Get(typeof(UnitConfig), 1001);
Log.Debug($"config {JsonHelper.ToJson(unitConfig)}");
// 发送事件来启动界面
Game.EventSystem.Run(EventIdType.InitSceneStart);
}
...
}

来看看发送的事件，代码在
Hotfix\Module\Demo\UI\UILogin\System\InitSceneStart_CreateLoginUI.cs

1
2
3
4
5
6
7
8
9
10
11
12
13
14
namespace ETHotfix
{
// 用 Attribute 来注册事件
[Event(EventIdType.InitSceneStart)]
public class InitSceneStart_CreateLoginUI: AEvent
{
public override void Run()
{
UI ui = UILoginFactory.Create();
// 这里就是启动登陆界面的地方，界面可以直接 add 或者 remove
Game.Scene.GetComponent<UIComponent>().Add(ui);
}
}
}

再来看看一个界面是怎么生成的，代码在 Hotfix\Module\Demo\UI\UILogin\System\UILoginFactory.cs

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public static UI Create()
{
 ...
    ResourcesComponent resourcesComponent = ETModel.Game.Scene.GetComponent<ResourcesComponent>();
// 让资源组件读取登陆界面的 AB 包
    resourcesComponent.LoadBundle(UIType.UILogin.StringToAB());
// 从 AB 包拿到登陆界面的 GameObject
    GameObject bundleGameObject = (GameObject) resourcesComponent.GetAsset(UIType.UILogin.StringToAB(), UIType.UILogin);
    GameObject gameObject = UnityEngine.Object.Instantiate(bundleGameObject);

    UI ui = ComponentFactory.Create<UI, string, GameObject>(UIType.UILogin, gameObject, false);
// 添加登陆界面组件
    ui.AddComponent<UILoginComponent>();
    return ui;
...
}

来看看登陆界面组件，代码在 Hotfix\Module\Demo\UI\UILogin\Component\UILoginComponent.cs

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public class UILoginComponent: Component
{
private GameObject account;
private GameObject loginBtn;

public void Awake()
{
// 通过引用来获取 UI 组件，再为其添加点击事件
ReferenceCollector rc = this.GetParent<UI>().GameObject.GetComponent<ReferenceCollector>();
loginBtn = rc.Get<GameObject>("LoginBtn");
loginBtn.GetComponent<Button>().onClick.Add(OnLogin);
this.account = rc.Get<GameObject>("Account");
}

public void OnLogin()
{ // 有兴趣可以再进去看看 OnLoginAsync，其中登陆的 Session 连接了服务器地址 127.0.0.1:10002
LoginHelper.OnLoginAsync(this.account.GetComponent<InputField>().text).Coroutine();
}
}

服务器地址存在了 Tools 菜单中的全局配置，上面的资源路径则是热更新服务器的地址。

游戏运行后，在 Hierarchy 界面中也可以看到组件的结构，其中 uilogin.unity3d 就是登陆界面的 AB 包引用：

这就是通过热更新逻辑生成的界面，也就是说，上面的代码让我们可以通过热更新来给应用加载各种界面和改写页面跳转逻辑，当然还可以通过热更来增加修改游戏逻辑和功能。

如果不喜欢这种页面加载方式，可以考虑不使用 Hotfix/Init.cs 中的 Game.Scene.AddComponent<UIComponent>(); 这个 UIComponent，而使用其他 UI 组件，例如主仓库中的 FairyGUI 分支，让 FairyGUI 来单独负责 UI 界面。这里也可以看出基于组件的框架的灵活性，我以后也会出文章单独介绍 FairyGUI。

热更新切换

首先看看作者的介绍：

7.客户端热更新一键切换
因为ios的限制，之前unity热更新一般使用lua，导致unity3d开发人员要写两种代码，麻烦的要死。之后幸好出了ILRuntime库，利用ILRuntime库，unity3d可以利用C#语言加载热更新dll进行热更新。ILRuntime一个缺陷就是开发时候不支持VS debug，这有点不爽。ET框架使用了一个预编译指令ILRuntime，可以无缝切换。平常开发的时候不使用ILRuntime，而是使用Assembly.Load加载热更新动态库，这样可以方便用VS单步调试。在发布的时候，定义预编译指令ILRuntime就可以无缝切换成使用ILRuntime加载热更新动态库。这样开发起来及其方便，再也不用使用狗屎lua了
8.客户端全热更新
客户端可以实现所有逻辑热更新，包括协议，config，ui等等

预编译指令指的就是在 Player Setting 中，上图右下角箭头指着的地方。当前有两个预编译指令，通常在开发中，可以只填写 NET452，这样可以得到完整的堆栈信息来调试程序。还有一个预编译指令 ASYNC，加上后，应用就会从前面填写的热更新服务器下载热更包，该指令在后文会提到。

在国内环境下，手机游戏热更新的需求较强烈。市场上手机系统普遍分成 Android 和 iOS 阵营，其中 iOS 不支持 JIT 热更，因此 ET 框架给了两种选择：ILRuntime 热更新和 Mono 热更新。

两者概念可以参考文末的参考链接，在这里不多说。

体验热更新

体验热更新之前，先把项目切到 Android 平台。

按照下图配置 Mono 热更新：

确保 Scripting Backend 为 Mono，下面预编译宏去掉 ILRuntime，加上 ASYNC，按下回车键执行变更。ASYNC 说明我们现在的热更新资源从资源服务器中获取，这里的热更新资源包括 Res 文件夹、Bundles 文件夹、Hotfix 文件夹中的代码等。在这个例子中，登陆界面的代码就已经写在热更新文件夹中了，我们将尝试通过热更新来展示登陆界面。

点击 Play 按钮，会有两个报错：

第二个 Log 信息展示了应用想要获取资源的热更资源服务器地址，这个地址可以在 Tools 菜单的全局配置中找到。报错信息提示找不到终端主机。报错是理所当然的，因为我们还没有启动本地服务器。

首先要生成热更新文件，在 Tools 菜单中点击打包工具，如下图所示：

平台选择当前的 Android 平台，目前不需要打包应用，所以无视第一个单选按钮。

前面的思维导图提到了 ET 根目录的 Release 文件夹存的就是热更新资源文件。打包工具也会把打包后的资源放在 Release 文件夹下。而第二个按钮指的是是否把打包的热更新资源也放在应用中，目前也不需要选择。开启热更新后，应用会比较服务器和本地应用的 Version 文件，计算文件差异后才会下载相关的热更新资源文件。

如果勾选了第二个按钮，打包工具将会把资源也复制到 Assets/StreamingAssets 文件夹下，同时更新 Version 文件，这样我们将不能测试下载热更包的过程。

点击开始打包后，热更文件就生成了：

再点击 Tools 菜单中的 web 资源服务器开启映射了 Release 文件夹的本地文件服务器。

点击 Play 按钮，应用通过下载热更新资源，生成了登陆界面，也把热更资源下载到了应用中，也就是 Assets/StreamingAssets 文件夹。

重新启动 web 资源服务器清除 log 信息，再次运行应用，会发现没有再次下载热更新资源。因为对比了 Version 文件后，应用本地的文件已经不需要更新了。

至此，我们完成了一次完整的热更新。

总结

ET 框架给了我们一种统一的开发体验，提供了方便的热更新切换和调试方案，这足以支撑起一些小游戏的开发需求，有需要的同学可以了解下 ET 框架~

2019 年立了个 Flag：周更技术博客，欢迎督促和交流，也欢迎常来我博客 萤火之森 逛！

参考

]]> 游戏开发 Unity Unity 中用有限状态机来实现一个 AI /2018/06/22/finite-state-machine-in-unity/ 最近在阅读《游戏人工智能编程案例精粹（修订版）》，本文是书中第二章的一篇笔记。

有限状态机（英语：Finite-state machine, 缩写：FSM），是一个被数学家用来解决问题的严格形式化的设备，在游戏业中也常见有限状态机的身影。

对于游戏程序员来说，可以用下面这个定义来了解：

一个有限状态机是一个设备（device），或是一个设备模型（a model of a device）。具有有限数量的状态，它可以在任何给定的时间根据输入进行操作，是的从一个状态变换到另一个状态，或者是促使一个输出或者一种行为的发生。一个有限状态机在任何瞬间只能处在一种状态。
——《游戏人工智能编程案例精粹（修订版）》 Mat Buckland

有限状态机就是要把一个对象的行为分解成易于处理的“块”或者状态。拿某个开关来说，我们可以把它分成两个状态：开或关。其中开开关这个操作，就是一次状态转移，使开关的状态从“关”变换到“开”，反之亦然。

拿游戏来举例，一个 FPS 游戏中的敌人 AI 状态可以分成：巡逻、侦查（听到了玩家）、追逐（玩家出现在 AI 视野）、攻击（玩家进入 AI 攻击范围）、死亡等，这些有限的状态都互相独立，且要满足某种条件才能从一个状态转移到另外一个状态。

有限状态机由三部分组成：

  • 存储任务信息的一些状态（states），例如一个 AI 可以有探索状态、追踪状态、攻击状态等等。
  • 状态之间的一些变换（transitions），转移代表状态的转移，并且描述着状态转移的条件。例如听到了主角的脚步声，就转移到追踪状态。
  • 需要跟随每个状态的一系列行为（actions）。例如在探索状态，要随机移动和找东西。

下图是只有三种状态的 AI 的有限状态机图示：

优缺点

实现有限状态机之前，要先了解它的优点：

  1. 编程快速简单：很多有限状态机的实现都较简单，本文会列出三种实现方法。
  2. 易于调试：因为行为被分成单一的状态块，因此要调试的时候，可以只跟踪某个异常状态的代码。
  3. 很少的计算开销：几乎不占用珍贵的处理器时间，因为除了 if-this-then-that 这种思考处理之外，是不存在真正的“思考”的。
  4. 直觉性：人们总是自然地把事物思考为处在一种或另一种状态。人类并不是像有限状态机一样工作，但我们发现这种方式下考虑行为是很有用的，或者说我们能更好更容易地进行 AI 状态的分解和创建操作 AI 的规则，容易理解的概念也让程序员之间能更好地交流其设计。
  5. 灵活性：游戏 AI 的有限状态机能很容易地由程序员进行调整，增添新的状态和规则也很容易扩展一个 AI 的行为。

有限状态机的缺点是：

  1. 当状态过多时，难以维护代码。
  2. 《AI Game Development》的作者 Alex J. Champandard 发表过一篇文章《10 Reasons the Age of Finite State Machines is Over》

if-then 实现

这是第一种实现有限状态机的方法，用一系列 if-then 语句或者 switch 语句来表达状态。

下面拿那个只有三个状态的僵尸 AI 举例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
public enum ZombieState
{
    Chase, Attack, Die
}

public class Zombie : MonoBehaviour
{
    private ZombieState currentState;

    private void Update()
    {
        switch (currentState)
        {
            case ZombieState.Chase:
                if (currentHealth <= 0)
                {
                    ChangeState(ZombieState.Die);
                }
                // 玩家在攻击范围内则进入攻击状态
                if (PlayerInAttackRange())
                {
                    ChangeState(ZombieState.Attack);
                }
                break;
            case ZombieState.Attack:
                if (currentHealth <= 0)
                {
                    ChangeState(ZombieState.Die);
                }
                if (!PlayerInAttackRange())
                {
                    ChangeState(ZombieState.Chase);
                }
                break;
            case ZombieState.Die:
                Debug.Log("僵尸死亡");
                break;
        }
    }
}

这种写法能实现有限状态机，但当游戏对象复杂到一定程度时，case 就会变得特别多，使程序难以理解、调试。另外这种写法也不灵活，难以扩展超出它原始设定的范围。

此外，我们常需要在进入状态和退出状态时做些什么，例如僵尸在开始攻击时像猩猩一样锤几下胸口，玩家跑出攻击范围的时候，僵尸要“摇摇头”让自己清醒，好让自己打起精神继续追踪玩家。

状态变换表

一个用于组织状态和影响状态变换的更好的机制是一个状态变换表。

当前状态条件状态转移
追踪玩家进入攻击范围攻击
追踪僵尸生命值小于或等于0死亡
攻击玩家脱离攻击范围追踪
攻击僵尸生命值小于或等于0死亡

这表格可以被僵尸 AI 不间断地查询。使得它能基于从游戏环境的变化来进行状态变换。每个状态可以模型化为一个分离的对象或者存在于 AI 外的函数。提供了一个清楚且灵活的结构。

我们只用告诉僵尸它有多少个状态，僵尸则会根据自己获得的信息（例如玩家是否在它的攻击范围内）来处理规则（转移状态）。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
public class Zombie : MonoBehaviour
{
    private ZombieState currentState;

    private void Update()
    {
        // 生命值小于等于0，进入死亡状态
        if (currentHealth <= 0)
        {
            ChangeState(ZombieState.Die);
            return;
        }
        // 玩家在攻击范围内则进入攻击状态，反之进入追踪状态
        if (PlayerInAttackRange())
        {
            ChangeState(ZombieState.Attack);
        }
        else
        {
            ChangeState(ZombieState.Chase);
        }
    }
}

内置规则

另一种方法就是将状态转移规则内置到状态内部。

在这里，每一个状态都是一个小模块，虽然每个模块都可以意识到其他模块的存在，但是每个模块都是一个独立的单位，而且不依赖任何外部的逻辑来决定自己是否要进行状态转移。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
public class Zombie : MonoBehaviour
{
    private State currentState;
    public int CurrentHealth { get; private set; }

    private void Update()
    {
        currentState.Execute(this);
    }

    public void ChangeState(State state)
    {
        currentState = state;
    }

    public bool PlayerInAttackRange()
    {
        // ...游戏逻辑
        return result;
    }
}

public abstract class State
{
    public abstract void Execute(Zombie zombie);
}

public class ChaseState : State
{
    public override void Execute(Zombie zombie)
    {
        if (zombie.CurrentHealth <= 0)
        {
            zombie.ChangeState(new DieState());
        }

        if (zombie.PlayerInAttackRange())
        {
            zombie.ChangeState(new AttackState());
        }
    }
}

public class AttackState : State
{
    public override void Execute(Zombie zombie)
    {
        if (zombie.CurrentHealth <= 0)
        {
            zombie.ChangeState(new DieState());
        }

        if (!zombie.PlayerInAttackRange())
        {
            zombie.ChangeState(new ChaseState());
        }
    }
}

public class DieState : State
{
    public override void Execute(Zombie zombie)
    {
        Debug.Log("僵尸死亡");
    }
}

Update() 函数只需要根据 currentState 来执行代码，当 currentState 改变时，下一次 Update() 的调用也会进行状态转移。这三个状态都作为对象封装，并且都给出了影响状态转移的规则（条件）。

这个结构被称为状态设计模式（state design pattern），它提供了一种优雅的方式来实现状态驱动行为。这种实现编码简单，容易扩展，也可以容易地为状态增加进入和退出的动作。下文会给出更完整的实现。

West World 项目

这项目是关于使用有限状态机创建一个 AI 的实际例子。游戏环境是一个古老西部风格的开采金矿的小镇，称作 West World。一开始只有一个挖金矿工 Bob，后期会加入他的妻子。任何的状态改变或者输出都会出现在控制台窗口中。West World 中有四个位置：金矿，可以存金块的银行，可以解除干渴的酒吧，还有家。矿工 Bob 会挖矿、睡觉、喝酒等，但这些都由 Bob 的当前状态决定。

项目在这里：programming-game-ai-by-example-in-unity/WestWorld/
West World

当你看到矿工改变了位置时，就代表矿工改变了状态，其他的事情都是状态中发生的事情。

Base Game Entity 类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
public abstract class BaseGameEntity
{
    /// <summary>
    /// 每个实体具有一个唯一的识别数字
    /// </summary>
    private int m_ID;

    /// <summary>
    /// 这是下一个有效的ID，每次 BaseGameEntity 被实例化这个值就被更新
    /// 这项目居民较少，采用预定义 id 的方式，可以忽视
    /// </summary>
    public static int m_iNextValidID { get; private set; }

    protected BaseGameEntity(int id)
    {
        m_ID = id;
    }

    public int ID
    {
        get { return m_ID; }
        set
        {
            m_ID = value;
            m_iNextValidID = m_ID + 1;
        }
    }
    // 在 GameManager 的 Update() 函数中调用，相当于实体自己的 Update 函数
    public abstract void EntityUpdate();
}

Miner 类

MIner 类是从 BaseGameEntity 类中继承的，包含很多成员变量，代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
public class Miner : BaseGameEntity
{
    /// <summary>
    /// 指向一个状态实例的指针
    /// </summary>
    private State m_pCurrentState;

    /// <summary>
    /// 旷工当前所处的位置
    /// </summary>
    private LocationType m_Location;

    /// <summary>
    /// 旷工的包中装了多少金块
    /// </summary>
    private int m_iGoldCarried;

    /// <summary>
    /// 旷工在银行存了多少金块
    /// </summary>
    private int m_iMoneyInBank;

    /// <summary>
    /// 口渴程度，值越高，旷工越口渴
    /// </summary>
    private int m_iThirst;

    /// <summary>
    /// 疲倦程度,值越高，旷工越疲倦
    /// </summary>
    private int m_iFatigue;
    
    public Miner(int id) : base(id)
    {
        m_Location = LocationType.Shack;
        m_iGoldCarried = 0;
        m_iMoneyInBank = 0;
        m_iThirst = 0;
        m_iFatigue = 0;
        m_pCurrentState = GoHomeAndSleepTilRested.Instance;
    }

    /// <summary>
    /// 等于 Update 函数，在 GameManager 内被调用，每调用一次就变得越口渴
    /// </summary>
    public override void EntityUpdate()
    {
        m_iThirst += 1;
        m_pCurrentState.Execute(this);
    }
    // ...其他的代码看 Github 项目
}

Miner 状态

金矿工人有四种状态：

  • EnterMineAndDigForNugget：如果矿工没在金矿，则改变位置。在金矿里了，就挖掘金块。
  • VisitBankAndDepositGold：矿工会走到银行并且存储他携带的所有天然金矿。
  • GoHomeAndSleepTilRested：矿工会回到他的小木屋睡觉知道他的疲劳值下降到可接受的程度。醒来继续去挖矿。
  • QuenchThirst：去酒吧买一杯威士忌，不口渴了继续挖矿。
当前状态条件状态转移
EnterMineAndDigForNugget挖矿挖到口袋装不下VisitBankAndDepositGold
EnterMineAndDigForNugget口渴QuenchThirst
VisitBankAndDepositGold觉得自己存够钱能安心了GoHomeAndSleepTilRested
VisitBankAndDepositGold没存够钱EnterMineAndDigForNugget
GoHomeAndSleepTilRested疲劳值下降到一定程度EnterMineAndDigForNugget
QuenchThirst不口渴了EnterMineAndDigForNugget

再谈状态设计模式

之前提到要为状态实现进入和退出这两个一个状态只执行一次的逻辑，这样可以增加有限状态机的灵活性。下面是威力加强版：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public abstract class State
{
    /// <summary>
    /// 当状态被进入时执行这个函数
    /// </summary>
    public abstract void Enter(Miner miner);

    /// <summary>
    /// 旷工更新状态函数
    /// </summary>
    public abstract void Execute(Miner miner);

    /// <summary>
    /// 当状态退出时执行这个函数
    /// </summary>
    public abstract void Exit(Miner miner);
}

这两个增加的方法只有在矿工改变状态时才会被调用。我们也需要修改 ChangeState 方法的代码如下：

1
2
3
4
5
6
7
8
9
public void ChangeState(State state)
{
    // 执行上一个状态的退出方法
    m_pCurrentState.Exit(this);
    // 更新状态
    m_pCurrentState = state;
    // 执行当前状态的进入方法
    m_pCurrentState.Enter(this);
}

另外，每个具体的状态都添加了单例模式，这样可以节省内存资源，不必重复分配和释放内存给改变的状态。以其中一个状态为例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
public class EnterMineAndDigForNugget : State
{
    public static EnterMineAndDigForNugget Instance { get; private set; }

    static EnterMineAndDigForNugget()
    {
        Instance = new EnterMineAndDigForNugget();
    }

    public override void Enter(Miner miner)
    {
        if (miner.Location() != LocationType.Goldmine)
        {
            Debug.Log("矿工：走去金矿");
            miner.ChangeLocation(LocationType.Goldmine);
        }
    }

    public override void Execute(Miner miner)
    {
        miner.AddToGoldCarried(1);
        miner.IncreaseFatigue();
        Debug.Log("矿工：采到一个金块 | 身上有 " + miner.GoldCarried() + " 个金块");
        // 口袋里金块满了就去银行存
        if (miner.PocketsFull())
        {
            miner.ChangeState(VisitBankAndDepositGold.Instance);
        }

        // 口渴了就去酒吧喝威士忌
        if (miner.Thirsty())
        {
            miner.ChangeState(QuenchThirst.Instance);
        }
    }

    public override void Exit(Miner miner)
    {
        Debug.Log("矿工：离开金矿");
    }
}

看到这里，大家应该都会很熟悉。这不就是 Unity 中动画控制器 Animator 的功能吗！

没错，Animator 也是一个状态机，有和我们之前实现十分相似的功能，例如：添加状态转移的条件，每个状态都有进入、执行、退出三个回调方法供使用。

我们可以创建 Behaviour 脚本，对 Animator 中每一个状态的进入、执行、退出等方法进行自定义，所以有些人直接拿 Animator 当状态机来使用，不过我们在下文还会为我们的状态机实现扩展更多的功能。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public class NewState : StateMachineBehaviour {
    // OnStateEnter is called when a transition starts and the state machine starts to evaluate this state
    //override public void OnStateEnter(Animator animator, AnimatorStateInfo stateInfo, int layerIndex) {
    //
    //}

    // OnStateUpdate is called on each Update frame between OnStateEnter and OnStateExit callbacks
    //override public void OnStateUpdate(Animator animator, AnimatorStateInfo stateInfo, int layerIndex) {
    //
    //}

    // OnStateExit is called when a transition ends and the state machine finishes evaluating this state
    //override public void OnStateExit(Animator animator, AnimatorStateInfo stateInfo, int layerIndex) {
    //
    //}
    // ...
}

使 State 基类可重用

由于上面四个状态是矿工独有的状态，如果要新建不同功能的角色，就有必要创建一个分离的 State 基类，这里用泛型实现。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public abstract class State<T>
{
    /// <summary>
    /// 当状态被进入时执行这个函数
    /// </summary>
    public abstract void Enter(T entity);

    /// <summary>
    /// 旷工更新状态函数
    /// </summary>
    public abstract void Execute(T entity);

    /// <summary>
    /// 当状态退出时执行这个函数
    /// </summary>
    public abstract void Exit(T entity);
}

状态翻转（State Blip）

这个项目其实有点像模拟人生这个游戏，其中有一点有意思的是，当模拟人生的主角做某件事时忽然要上厕所，去完之后会继续做之前停止的事情。这种返回前一个状态的行为就是状态翻转（State Blip）。

1
2
3
private State<T> m_pCurrentState;
private State<T> m_pPreviousState;
private State<T> m_pGlobalState;

m_pGlobalState 是一个全局状态，也会在 Update() 函数中和 m_pCurrentState 一起调用。如果有紧急的行为中断状态，就把这行为（例如上厕所）放到全局状态中，等到全局状态为空再进入当前状态。

1
2
3
4
5
6
7
8
9
10
11
12
13
public void StateUpdate()
{
    // 如果有一个全局状态存在，调用它的执行方法
    if (m_pGlobalState != null)
    {
        m_pGlobalState.Execute(m_pOwner);
    }

    if (m_pCurrentState != null)
    {
        m_pCurrentState.Execute(m_pOwner);
    }
}

StateMachine 类

通过把所有与状态相关的数据和方法封装到一个 StateMachine 类中，可以使得设计更为简洁。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
public class StateMachine<T>
{
    private T m_pOwner;
    private State<T> m_pCurrentState;
    private State<T> m_pPreviousState;
    private State<T> m_pGlobalState;

    public StateMachine(T owner)
    {
        m_pOwner = owner;
    }

    public void SetCurrentState(State<T> state)
    {
        m_pCurrentState = state;
    }

    public void SetPreviousState(State<T> state)
    {
        m_pPreviousState = state;
    }

    public void SetGlobalState(State<T> state)
    {
        m_pGlobalState = state;
    }

    public void StateMachineUpdate()
    {
        // 如果有一个全局状态存在，调用它的执行方法
        if (m_pGlobalState != null)
        {
            m_pGlobalState.Execute(m_pOwner);
        }

        if (m_pCurrentState != null)
        {
            m_pCurrentState.Execute(m_pOwner);
        }
    }

    public void ChangeState(State<T> newState)
    {
        m_pPreviousState = m_pCurrentState;
        m_pCurrentState.Exit(m_pOwner);
        m_pCurrentState = newState;
        m_pCurrentState.Enter(m_pOwner);
    }

    /// <summary>
    /// 返回之前的状态
    /// </summary>
    public void RevertToPreviousState()
    {
        ChangeState(m_pPreviousState);
    }

    public State<T> CurrentState()
    {
        return m_pCurrentState;
    }

    public State<T> PreviousState()
    {
        return m_pPreviousState;
    }

    public State<T> GlobalState()
    {
        return m_pGlobalState;
    }

    public bool IsInState(State<T> state)
    {
        return m_pCurrentState == state;
    }
}

新人物 Elsa

第二个项目会演示之前的改进。Elsa 是矿工 Bob 的妻子，她会清理小木屋和上厕所（老喝咖啡）。其中 VisitBathroom 状态是用状态翻转实现的，即上完厕所要回到之前的状态。

项目地址：programming-game-ai-by-example-in-unity/WestWorldWithWoman/

West World With Woman

消息功能

好的游戏实现趋向于事件驱动。即当一件事情发生了（发射了武器，主角发出了声音等等），事件会被广播给游戏中相关的对象。

整合事件（观察者模式）的状态机可以实现更灵活的需求，例如：一个足球运动员从队友旁边通过时，传球者可以发送一个（延时）消息，通知队友应该什么时候到相应位置来接球；一个士兵正在开枪攻击敌人，忽然一个队友中了流弹，这时候队友可以发送一个（即时）消息，通知士兵立刻救援队友。

Telegram 结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public struct Telegram
{
    public BaseGameEntity Sender { get; private set; }
    public BaseGameEntity Receiver { get; private set; }
    public MessageType Message { get; private set; }
    public float DispatchTime { get; private set; }
    public Dictionary<string, string> ExtraInfo { get; private set; }

    public Telegram(float time, BaseGameEntity sender, BaseGameEntity receiver, MessageType message,
        Dictionary<string, string> extraInfo = null) : this()
    {
        Sender = sender;
        Receiver = receiver;
        DispatchTime = time;
        Message = message;
        ExtraInfo = extraInfo;
    }
}

这里用结构体来实现消息。要发送的消息可以作为枚举加在 MessageType 中，DispatchTime 是决定立刻发送还是延时发送的时间戳，ExtraInfo 能携带额外的信息。这里只用两种消息做例子。

1
2
3
4
5
6
7
8
9
10
11
12
public enum MessageType
{
    /// <summary>
    /// 矿工让妻子知道他已经回到小屋了
    /// </summary>
    HiHoneyImHome,    
    /// <summary>
    /// 妻子通知矿工自己什么时候要将晚饭从烤箱中拿出来
    /// 以及通知矿工食物已经放在桌子上了
    /// </summary>
    StewReady,
}

发送消息

下面是 MessageDispatcher 类，用来管理消息的发送。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
/// <summary>
/// 管理消息发送的类
/// 处理立刻被发送的消息，和打上时间戳的消息
/// </summary>
public class MessageDispatcher
{
    public static MessageDispatcher Instance { get; private set; }

    static MessageDispatcher()
    {
        Instance = new MessageDispatcher();
    }

    private MessageDispatcher()
    {
        priorityQueue = new HashSet<Telegram>();
    }

    /// <summary>
    /// 根据时间排序的优先级队列
    /// </summary>
    private HashSet<Telegram> priorityQueue;

    /// <summary>
    /// 该方法被 DispatchMessage 或者 DispatchDelayedMessages 利用。
    /// 该方法用最新创建的 telegram 调用接受实体的消息处理成员函数 receiver
    /// </summary>
    public void Discharge(BaseGameEntity receiver, Telegram telegram)
    {
        if (!receiver.HandleMessage(telegram))
        {
            Debug.LogWarning("消息未处理");
        }
    }

    /// <summary>
    /// 创建和管理消息
    /// </summary>
    /// <param name="delay">时间的延迟（要立刻发送就用零或负值）</param>
    /// <param name="senderId">发送者 ID</param>
    /// <param name="receiverId">接受者 ID</param>
    /// <param name="message">消息本身</param>
    /// <param name="extraInfo">附加消息</param>
    public void DispatchMessage(
        float delay,
        int senderId,
        int receiverId,
        MessageType message,
        Dictionary<string, string> extraInfo)
    {
        // 获得消息发送者
        BaseGameEntity sender = EntityManager.Instance.GetEntityFromId(senderId);
        // 获得消息接受者
        BaseGameEntity receiver = EntityManager.Instance.GetEntityFromId(receiverId);
        if (receiver == null)
        {
            Debug.LogWarning("[MessageDispatcher] 找不到消息接收者");
            return;
        }

        float currentTime = Time.time;
        if (delay <= 0)
        {
            Telegram telegram = new Telegram(0, sender, receiver, message, extraInfo);

            Debug.Log(string.Format(
                "消息发送时间: {0} ，发送者是：{1}，接收者是：{2}。消息是 {3}",
                currentTime,
                sender.Name,
                receiver.Name,
                message.ToString()));
            Discharge(receiver, telegram);
        }
        else
        {
            Telegram delayedTelegram = new Telegram(currentTime + delay, sender, receiver, message, extraInfo);
            priorityQueue.Add(delayedTelegram);

            Debug.Log(string.Format(
                "延时消息发送时间: {0} ，发送者是：{1}，接收者是：{2}。消息是 {3}",
                currentTime,
                sender.Name,
                receiver.Name,
                message.ToString()));
        }
    }

    /// <summary>
    /// 发送延时消息
    /// 这个方法会放在游戏的主循环中，以正确地和及时地发送任何定时的消息
    /// </summary>
    public void DisplayDelayedMessages()
    {
        float currentTime = Time.time;
        while (priorityQueue.Count > 0 &&
               priorityQueue.First().DispatchTime < currentTime &&
               priorityQueue.First().DispatchTime > 0)
        {
            Telegram telegram = priorityQueue.First();
            BaseGameEntity receiver = telegram.Receiver;

            Debug.Log(string.Format("延时消息开始准备分发，接收者是 {0}，消息是 {1}",
                receiver.Name,
                telegram.Message.ToString()));
            // 开始分发消息
            Discharge(receiver, telegram);
            priorityQueue.Remove(telegram);
        }
    }
}

DispatchMessage 函数会管理消息的发送，即时消息会直接由 Discharge 函数发送到接收者，延时消息会进入队列，通过 GameManager 游戏主循环，每一帧调用 DisplayDelayedMessages() 函数来轮询要发送的消息，当发现当前时间超过了消息的发送时间，就把消息发送给接收者。

处理消息

处理消息的话修改 BaseGameEntity 来增加处理消息的功能。

1
2
3
4
5
6
7
8
9
10
11
12
13
public abstract class BaseGameEntity
{
    // ... 省略无关代码
    public abstract bool HandleMessage(Telegram message);
}

public class Miner : BaseGameEntity
{
    public override bool HandleMessage(Telegram message)
    {
        return m_stateMachine.HandleMessage(message);
    } 
}

StateMachine 代码也要改：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public class StateMachine<T>
{
    public bool HandleMessage(Telegram message)
    {
        if (m_pCurrentState != null && m_pCurrentState.OnMessage(m_pOwner, message))
        {
            return true;
        }
    
        // 如果当前状态没有代码适当的处理消息
        // 它会发送到实体的全局状态的消息处理者
        if (m_pCurrentState != null && m_pGlobalState.OnMessage(m_pOwner, message))
        {
            return true;
        } 
        return false;
    }
}

State 基类也要修改：

1
2
3
4
5
6
7
8
9
10
public abstract class State<T>
{
    /// <summary>
    /// 处理消息
    /// </summary>
    /// <param name="entity">接受者</param>
    /// <param name="message">要处理的消息</param>
    /// <returns>消息是否成功被处理</returns>
    public abstract bool OnMessage(T entity, Telegram message);
}

Discharge 函数发送消息给接收者，接收者将消息给他 StateMachine 的 HandleMessage 函数处理，消息最后通过 StateMachine 到达各种状态的 OnMessage 函数，开始根据消息的类型来做出处理（例如进行状态转移）。

具体实现请看项目代码：programming-game-ai-by-example-in-unity/WestWorldWithMessaging/

West World With Messaging

这里实现的场景是：

  1. 矿工 Bob 回家后发送 HiHoneyImHome 即时消息给他的妻子 Elsa，提醒她做饭。
  2. Elsa 收到消息后，停止手上的活儿，开始进入 CookStew 状态做饭。
  3. Elsa 进入 CookStew 状态后，把肉放到烤炉里面，并且发送 StewReady 延时消息提醒自己在一段时间后拿出烤炉中的肉。
  4. Elsa 收到 StewReady 消息后，发送一个 StewReady 即时消息给 Bob 提醒他饭已经做好了。如果 Bob 这时不在家，命令行将显示 Discharge 函数中的 Warning “消息未处理”。Bob 在家，就会开心地去吃饭。
  5. Bob 收到 StewReady 的消息，状态转移到 EatStew，开始吃饭。

总结

有时候我们可能会用到多个状态机来并行工作，例如一个 AI 有多个状态，其中包括攻击状态，而攻击状态又有不同攻击类型（瞄准和射击），像一个状态机包含另一个状态机这种层次化的状态机。当然也有其他不同的使用场景，我们不能受限于自己的想象力。

本文根据《游戏人工智能编程案例精粹（修订版）》进行了 Unity 版本的实现，我对有限状态机也有了更清晰的认识。阅读这本书的同时也会把 Unity 实现放到下面的仓库地址中，下篇文章可能会总结行为树的知识，如果没看到请督促我~

项目地址：programming-game-ai-by-example-in-unity

引用

]]> 游戏开发 Unity 2D 像素风平台游戏 Aretha’s Journey /2018/06/17/arethas-journey/ 继《我设计的第一个桌游》后，这次带来的是电子游戏的作业—— 2D像素平台游戏 Aretha’s Journey。

游戏背景

来自潘达尼亚的女孩 Aretha 已经离乡别井几年了，回乡之际，发现族人们都被神所诅咒而变成了石头，原因是他们的族人曾尝试反抗神。于是 Aretha 便踏上拯救家园之路…

游戏截图

美术风格采用了像素风，游戏一共有五关，第一关为教学关，第五关为 Boss 战，截图如下：

Stage01

Stage02

Stage03

Stage04

Stage05

游戏介绍

游戏类型是常见的平台游戏。主角可以收集金币，去商人那购买"遗物"（Relic），遗物可以看做是一种装备，穿上能提供一些特殊增益，例如增加血上限、打怪吸血等。本来想设计成 Roguelike 中众多能提供不同能力的道具，但苦于时间不足，因此在游戏中只设计了几个能购买的遗物，有些遗物能在宝箱里面随机开出来。

游戏地图是用 Unity 2017 的新特性 TileMap 做的，镜头使用 2D Cinemachine。现在回看作品，其实这一类型的游戏并不难，但是我们团队除了我都是第一次接触 Unity，踩过不少坑，也导致到 Due 的时候很多东西都没做完。

我负责了游戏中除战斗系统外的编程任务，例如：Game Loop、Item Respawn、角色状态、背包系统等功能。可以说很多代码都是重用性很高的，但自己以前没有积累，所以做这游戏的时候也只能从零开始做，在编程中逐渐模块化系统代码。

Showcase

不过很开心的是，游戏被入选到学校的 Student Games Showcase 里面，这个 Showcase 里还有其他同学期其他同学所做的优秀的游戏作品。大家有兴趣的话可以在这个网站查看2018年的入选游戏：Student Games 。我们游戏在 Showcase 的评委投票和公开投票中都获得第二名的成绩，自己和小组都是很开心的~

猜猜我们组在哪~

评委投票

结语

游戏下载：Aretha-s-Journey

总而言之，游戏设计课认识不少新朋友，也收获了很多，自己在游戏开发的路上又往前走了一步。

Flag: 以后博客会更新得勤一些，学了啥就写啥，不能等到吃透了一个东西再放上来= =。

Thank you for playing my game.

]]> 游戏设计 我设计的第一个桌游 /2018/04/13/first-board-game/ 很久没写文章了，这次带来的是游戏设计课中的桌游大作业。

小组成员在第一节课就随机分好了，我们一开始选择每人准备一个桌游原型，然后共同选择一个原型来深入设计，最后一起选择了我的设计原型。

第一版设计

第一版地图

我的设计是：每个玩家初始有 4 HP，四个玩家从左下角通过掷骰子的方式在地图的点上往终点走，先到终点者胜，HP为零时需要从起点重新开始。地图中有四种不同功能的点，玩家到达某个点时会触发相应效果：

  • 黑点：无特殊效果
  • 绿点：休息点，回 1 HP
  • 红点：陷阱点，拿一张陷阱卡，立即使用来接受惩罚，如： 扣血、禁一回合等效果
  • 黄点：宝物点，拿一张宝物卡，可以在当前回合使用，也可以藏起来等以后的回合使用，如：回血、其他玩家倒退三步、禁某玩家一回合等效果

原型的灵感主要来自于最近常玩的 “Slay the Spire” 中的地图，玩家通过选择不同的道路抉择，目标是活着打败关底 BOSS。在第一版设计中，整个的PVE设计下，也考虑了 PVP 因素：两个玩家走到同一个点时可以进行决斗，每人 -1 HP。由于步数主要依赖于随机的骰子得来的数字，所以道路不能设计太多，尽量增加玩家相遇的机会。同时在较长的支路中，宝物点较多，陷阱点也较多，机遇与风险并存。

这样设计的话，我们主要考虑地图设计的平衡和去扩展卡牌的效果即可。

但是问题也来了：

  • 总有运气出奇好的玩家一路趋吉避凶，什么挫折都没遇到就到终点了
  • 玩家死了之后就要回到起点重新开始，没干劲继续玩了
  • 游戏性不足，现有的游戏元素还是太少，主要靠骰子和抓牌时的运气，玩家要考虑的实际上不多

第二版设计

针对前面的第一点问题，新增了“地形”的设计：

地形不是一个能走的点，效果只有在玩家走过（在点上走跨越地形）时触发。相对于点的设计，地形是一个“必须触发”的设计。每个玩家在跨过山脉的时候必须 -1 HP，遇到龙窟的时候也能必得一张宝物卡，这样降低了运气的成分，提高了功能卡的利用率。

对于上面的第二个问题，我们通过设计“旅馆”的一种地形，玩家走过 +1 HP，同时可以当做玩家的重生点，玩家死后可以从路过的旅馆重生。

针对第三个问题，我们新增了英雄卡的设计。每个英雄有不同能力，例如坦克天生带 5 HP，一些特殊的英雄还能根据现有元素设计能力。我们也新增了 AP（攻击力）和装备卡的设计，注入更多的 RPG 元素。

成品

地图

英雄卡

装备卡及卡背

陷阱卡

陷阱卡太多就不放上来了，效果主要是退几步、禁一回合、丢到所有的卡牌回到最近的起点等等。

宝物卡

效果主要有：

  • 回血
  • 偷别人一张卡（宝物卡或者装备卡）
  • 其他玩家退三步
  • 多一次掷骰子行动的机会
  • +1 HP 并再拿一张宝物卡
  • 每个玩家拿一张宝物卡（增加卡牌利用率）
  • 和某玩家决斗！（增加 PVP 的存在感）
  • …

说明书中部分内容

结语

在昨天晚上的游戏设计课里，每个小组都要玩别的小组做的桌游并打分，在五分满分的前提下，参与的小组给我们游戏大多打了四分以上，主要进行游戏设计部分的我还是很开心的！！！在文尾再次感谢小组成员所付出的努力，特别是主要进行美术设计的韩国小哥。

下一个大作业做电子游戏，准备做 Roguelike，有什么好的建议也可以在评论区提出~

]]> 游戏设计 寻路算法-贪婪最佳优先算法 /2017/12/16/greedy-best-find-search/ 最近开始接触寻路算法，对此不太了解的话建议读者先看这篇文章《如何快速找到最优路线？深入理解游戏中寻路算法》 。

所有寻路算法都需要一种方法以数学的方式估算某个节点是否应该被选择。大多数游戏都会使用启发式（heuristic） ，以 h(x) 表示，就是估算从某个位置到目标位置的开销。理想情况下，启发式结果越接近真实越好。

——《游戏编程算法与技巧》

今天主要说的是贪婪最佳优先搜索（Greedy Best-First Search），贪心算法的含义是：求解问题时，总是做出在当前来说最好的选择。通俗点说就是，这是一个“短视”的算法。

为什么说是“短视”呢？首先要明白一个概念：曼哈顿距离。

曼哈顿距离

曼哈顿距离被认为不能沿着对角线移动，如下图中，红、蓝、黄线都代表等距离的曼哈顿距离。绿线代表欧氏距离，如果地图允许对角线移动的话，曼哈顿距离会经常比欧式距离高。

img

在 2D 地图中，曼哈顿距离的计算如下：

img

贪婪最佳优先搜索的简介

贪婪最佳优先搜索的每一步，都会查找相邻的节点，计算它们距离终点的曼哈顿距离，即最低开销的启发式。

贪婪最佳优先搜索在障碍物少的时候足够的快，但最佳优先搜索得到的都是次优的路径。例如下图，算法不断地寻找当前 h（启发式）最小的值，但这条路径很明显不是最优的。

img

贪婪最佳优先搜索“未能远谋”，大多数游戏都要比贪婪最佳优先算法所能提供的更好的寻路，但大多数寻路算法都是基于贪婪算法，所以了解该算法很有必要。

首先是节点类，每个节点需要存储上一个节点的引用和 h 值，其他信息是为了方便算法的实现。存储上一个节点的引用是为了像一个链表一样，最后能通过引用得到路径中所有的节点。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public class Node
{
// 上一个节点
public Node parent;
// 节点的 h(x) 值
public float h;
// 与当前节点相邻的节点
public List<Node> adjecent = new List<Node>();
// 节点所在的行
public int row;
// 节点所在的列
public int col;
// 清除节点信息
public void Clear()
{
parent = null;
h = 0.0f;
}
}

下面是图类，图类最主要的任务就是根据提供的二维数组初始化所有的节点，包括寻找他们的相邻节点。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
// 图类
public class Graph
{
public int rows = 0;
public int cols = 0;
public Node[] nodes;

public Graph(int[, ] grid)
{
rows = grid.GetLength(0);
cols = grid.GetLength(1);

nodes = new Node[grid.Length];
for (int i = 0; i < nodes.Length; i++)
{
Node node = new Node();
node.row = i / cols;
node.col = i - (node.row * cols);
nodes[i] = node;
}

// 找到每一个节点的相邻节点
foreach (Node node in nodes)
{
int row = node.row;
int col = node.col;
// 墙，即节点不能通过的格子 
// 1 为墙，0 为可通过的格子
if (grid[row, col] != 1)
{
// 上方的节点
if (row > 0 && grid[row - 1, col] != 1)
{
node.adjecent.Add(nodes[cols * (row - 1) + col]);
}
// 右边的节点
if (col < cols - 1 && grid[row, col + 1] != 1)
{
node.adjecent.Add(nodes[cols * row + col + 1]);
}

// 下方的节点
if (row < rows - 1 && grid[row + 1, col] != 1)
{
node.adjecent.Add(nodes[cols * (row + 1) + col]);
}

// 左边的节点
if (col > 0 && grid[row, col - 1] != 1)
{
node.adjecent.Add(nodes[cols * row + col - 1]);
}
}
}
}
}

在算法类中，我们需要记录开放集合和封闭集合。开放集合指的是当前步骤我们需要考虑的节点，例如算法开始时就要考虑初始节点的相邻节点，并从其找到最低的 h(x) 值开销的节点。封闭集合存放已经计算过的节点。

1
2
3
4
// 开放集合
public List<Node> reachable;
// 封闭集合，存放已经被算法估值的节点
public List<Node> explored;

下面是算法主要的逻辑，额外的函数可以查看项目源码。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
public Stack<Node> Finding()
{
    // 存放查找路径的栈
    Stack<Node> path;
    Node currentNode = reachable[0];
  // 迭代查找，直至找到终点节点
    while (currentNode != destination)
    {
        explored.Add(currentNode);
        reachable.Remove(currentNode);
      // 将当前节点的相邻节点加入开放集合
        AddAjacent(currentNode);
// 查找了相邻节点后依然没有可以考虑的节点，查找失败。
        if (reachable.Count == 0)
        {
            return null;
        }
      // 将开放集合中h值最小的节点当做当前节点
        currentNode = FindLowestH();
    }
    // 查找成功，则根据节点parent找到查找到的路径
    path = new Stack<Node>();
    Node node = destination;
    // 先将终点压入栈，再迭代地把node的前一个节点压入栈
    path.Push(node);
    while (node.parent != null)
    {
        path.Push(node.parent);
        node = node.parent;
    }
    return path;
}

除此以外还有些展示算法的类，代码不在这里展出。下面是算法执行的截图，其中白色格子为可走的格子，灰色格子是不可穿越的，红色格子为查找到的路径，左上角格子为查找起点，右上角格子为查找终点。

small

big

后一个实例也展现了其"短视"的缺点，红线走了共65个格子，但蓝箭头方向只走了45个格子。

最后

还有一种方案就是直接计算起点到终点的路径，这样可以节省一点计算开销。如下方右图，左图为广度优先算法。

img

本项目源码在 Github-PathFindingDemo 。
了解了贪婪最佳优先算法后，下一篇文章会在本文基础上讲A* 寻路。

参考资料

]]> 游戏开发 3D数学基础-矩阵变换（二） /2017/09/24/matrix-transformation-2/ 2020年7月26日更新：
最近对变换重新学习整理了，文章在：图形学常见的变换推导。

上一篇笔记3D 数学基础-向量运算基础和矩阵变换记录了一些向量和矩阵运算的基础，和一些矩阵基本的变换。这篇笔记主要介绍了平移变换、齐次坐标、平移和旋转变换的组合、法线变换和改变坐标系。

平移（Translation）

前一篇文章总结了旋转、缩放等变换，这里介绍一下平移变换。

假如我们需要把 X 坐标从 x 变换到 x + 5，我们需要构造什么样的变换矩阵来实现平移呢？

[x′y′z′]=[?][xyz]=[x+5yz]\begin{bmatrix}x' \\ y' \\ z' \end{bmatrix}=\begin{bmatrix} & & \\ & ? & \\ & & \end{bmatrix}\begin{bmatrix}x \\ y \\ z \end{bmatrix}=\begin{bmatrix}x+5 \\ y \\ z \end{bmatrix}

要注意的是，变换矩阵不能包含 x、y、z 等坐标变量。例如要得到 x + 5，那么矩阵的第一个行向量不能是 $$(1, 0, 5/z)$$，因为变换的一个重要性质是变换矩阵保持不变。

我们可以给矩阵多加一个维度 w，令其等于 1，这样就不需要用到 x、y、z 这些坐标变量了。

[x′y′z′w′]=[1005010000100001][xyz1]=[x+5yz1]\begin{bmatrix}x' \\ y' \\ z' \\ w' \end{bmatrix}=\begin{bmatrix} 1 & 0 & 0 & 5\\ 0 & 1 & 0 & 0\\ 0 & 0 & 1 & 0\\ 0 & 0 & 0 & 1 \end{bmatrix}\begin{bmatrix}x \\ y \\ z \\ 1 \end{bmatrix}=\begin{bmatrix}x+5 \\ y \\ z \\ 1 \end{bmatrix}

这里引用到了齐次坐标的概念。

齐次坐标

齐次坐标表示是计算机图形学的重要手段之一，它既能够用来明确区分向量和点，同时也更易用于进行仿射几何变换。
—— F.S. Hill, JR 《计算机图形学(OpenGL 版)》作者

想要了解三维坐标是怎么样扩展到四维坐标，可以先了解下二维空间中的齐次坐标 $$(x, y, w)$$。

下图的三维坐标中在 $$w=1$$ 处有一个二维平面，则该平面上的二维平面坐标可以表示为 $$(x, y, 1)$$，图中的 $$(1.0, 0.8, 1.0)$$ 就是一个在该二维平面上的点。对于不在二维平面上的点，我们则将其投影到二维平面上，所以齐次坐标 $$(x, y, w)$$ 映射到实际二维平面上的点为 $$(x/w, y/w)$$，例如另外一个点 $$(2.5, 2.0, 2.5)$$ 在 $$w=1$$ 二维平面投影得到的点为 $$(1.0, 0.8)$$。

同理，三维空间的点可以认为是在四维空间中 $$w=1$$ 的“平面”上，所以齐次坐标 $$(x, y, z, w)$$ 映射到三维空间上的点为 $$(x/w, y/w, z/w)$$，这也就是点的非齐次坐标。

[xyzw]=[x/wy/wz/w1]\begin{bmatrix}x \\ y \\ z \\ w \end{bmatrix}=\begin{bmatrix}x/w \\ y/w \\ z/w \\ 1 \end{bmatrix}

四维齐次坐标的任何常量缩放会得到相同的结果，也就是说，它包含了点的非齐次坐标所有可能的缩放（还记得上面图中的两个点吗？），w 可以等于任何数值：

  • 如果 w > 0，这表示一个真实物理世界的点，我们可以用 x，y，z 三个坐标除以 w 得到这个真实的点。
  • 如果 w = 0，这表示一个无穷远处的点。在实际应用中，通常表示一个向量。

齐次坐标的优点：

  • 让我们可以同时考虑所有的变换，如平移、观察、旋转、透视投影等。（如果我们要做缩放变换，可以直接变换 x、y、z 的值并且保持 w 不变。）
  • 整个渲染管线都以 4 * 4 的齐次坐标矩阵以及对应的四维向量为基础，只有在最后要表示真实点的位置的时候，才需要把齐次坐标变为非齐次。（计算机里除法是个非常复杂的操作，需要花费更多的时间周期，但齐次坐标只需在渲染管线最后一步做除法。）
  • 不会出现特殊情况。有时考虑判断直线是否相交，当它们平行的时候，有些公式会出错，但无穷远点已经在齐次坐标中约定了 w=0。
  • 四阶矩阵和齐次坐标是计算机图形软件和硬件中普遍使用的标准。

下面表示的是一个点向量加上一个平移变量：

P′=TP=[100Tx010Ty001Tz0001][xyz1]=[x+Txy+Tyz+Tz1]=P+TP{}'=TP=\begin{bmatrix} 1 & 0 & 0 & T_{x}\\ 0 & 1 & 0 & T_{y}\\ 0 & 0 & 1 & T_{z}\\ 0 & 0 & 0 & 1 \end{bmatrix}\begin{bmatrix}x \\ y \\ z \\ 1 \end{bmatrix}=\begin{bmatrix}x+T_{x} \\ y+T_{y} \\ z+T_{z} \\ 1 \end{bmatrix}=P+T

有时候平移矩阵 T 内的左上角部分会直接用单位矩阵来表示，其中 $$I_{3}$$ 表示 3 * 3 的单位矩阵。

T=[100Tx010Ty001Tz0001]=[I3T01]T=\begin{bmatrix} 1 & 0 & 0 & T_{x}\\ 0 & 1 & 0 & T_{y}\\ 0 & 0 & 1 & T_{z}\\ 0 & 0 & 0 & 1 \end{bmatrix}=\begin{bmatrix} I_{3} & T\\ 0 & 1 \end{bmatrix}

组合平移和旋转变换

当要对一个点进行两种变换的时候，就会涉及到变换顺序的问题，是先平移再旋转，还是先旋转再平移？

先旋转再平移

P′=(TR)P=MP=RP+TP{}'=\left ( TR \right )P=MP=RP+T

其中 T 为平移矩阵，R 为旋转矩阵，矩阵 P 通过平移再旋转后得到矩阵 P’。注意，在上面的公式中做的是标准的向量计算，在计算时才用齐次坐标计算。

由于我们使用的是列矩阵，矩阵的阅读顺序应该从右到左。也就是说对于 TR 这个旋转矩阵而言，（TR）P 这个操作，就是对矩阵 P 先 R 旋转，再进行 T 平移。

M=[100Tx010Ty001Tz0001][R11R12R130R21R22R230R31R32R3300001]=[R11R12R13TxR21R22R23TyR31R32R33Tz0001]=[RT01]M=\begin{bmatrix} 1 & 0 & 0 & T_{x}\\ 0 & 1 & 0 & T_{y}\\ 0 & 0 & 1 & T_{z}\\ 0 & 0 & 0 & 1 \end{bmatrix}\begin{bmatrix} R_{11} & R_{12} & R_{13} & 0\\ R_{21} & R_{22} & R_{23} & 0\\ R_{31} & R_{32} & R_{33} & 0\\ 0 & 0 & 0 & 1 \end{bmatrix}=\begin{bmatrix} R_{11} & R_{12} & R_{13} & T_{x}\\ R_{21} & R_{22} & R_{23} & T_{y}\\ R_{31} & R_{32} & R_{33} & T_{z}\\ 0 & 0 & 0 & 1 \end{bmatrix}=\begin{bmatrix} R & T \\ 0 & 1 \end{bmatrix}

MP=[RT01][P001]=[RPT01]=RP+TMP=\begin{bmatrix} R & T \\ 0 & 1 \end{bmatrix}\begin{bmatrix} P & 0 \\ 0 & 1 \end{bmatrix}=\begin{bmatrix} RP & T \\ 0 & 1 \end{bmatrix}=RP+T

先平移再旋转

P′=(RT)P=MP=R(P+T)=RP+RTP{}'=(RT)P=MP=R(P+T)=RP+RT

M=[R11R12R130R21R22R230R31R32R3300001][100Tx010Tx001Tx0001]=[R3×3R3×3T3×101×31]M=\begin{bmatrix} R_{11} & R_{12} & R_{13} & 0\\ R_{21} & R_{22} & R_{23} & 0\\ R_{31} & R_{32} & R_{33} & 0\\ 0 & 0 & 0 & 1 \end{bmatrix}\begin{bmatrix} 1 & 0 & 0 & T_{x}\\ 0 & 1 & 0 & T_{x}\\ 0 & 0 & 1 & T_{x}\\ 0 & 0 & 0 & 1 \end{bmatrix}=\begin{bmatrix} R_{3\times 3} & R_{3\times 3}T_{3\times 1}\\ 0_{1\times 3} & 1 \end{bmatrix}

MP=[R3×3R3×3T3×101×31][P001]=[RPRT01]=RP+RTMP=\begin{bmatrix} R_{3\times 3} & R_{3\times 3}T_{3\times 1}\\ 0_{1\times 3} & 1 \end{bmatrix}\begin{bmatrix} P & 0\\ 0 & 1 \end{bmatrix}=\begin{bmatrix} RP & RT\\ 0 & 1 \end{bmatrix}=RP+RT

对比先平移再旋转的结果，可以看到不同的地方是 T 变成了 RT，也就是说旋转也施加在了平移的方向上。在下图中可看到小人在 Y 轴方向发生了平移，所以先旋转再平移可能会更容易得到理想的结果，但两种变换组合都是可行的。（在 gluLookAt 的推导中需要先做平移，gluLookAt 是 OpenGL 中观察变换的一个关键函数。）

法线变换

在图形学中曲面法线的方向也很重要。

法线（Normal）

法线是始终垂直于某平面的虚线。在数学几何中法线指平面上垂直于曲线在某点的切线的一条线。
——百度百科

切线的位置实际上就是曲面上的几何位置，因此它们的变换矩阵和曲面的变换矩阵保持一致。

t→Mtt\rightarrow Mt

而法线变换是另外一个矩阵，我们称之为 Q。

n→Qn  Q=?n\rightarrow Qn~~Q=?

法线必须垂直于这些切线，因此法线和切线的点积等于 0。

nTt=0n^{T}t=0

变换后法线和切点依然互相垂直，可得：

(Qn)T=(nTQT)(Mt)=0(Qn)^{T}=(n^{T}Q^{T})(Mt)=0

在该等式中，只有当 $$Q^{T}M=I$$ 时，矩阵才容易求解。

nTQTMt=0⇒QTM=In^{T} Q^{T} M t=0 \Rightarrow Q^{T} M=I

最后可得法线变换公式，其中 $$M^{-1}$$ 只对左上角的 3 * 3 矩阵求逆和转置：

Q=(M−1)TQ=(M^{-1})^{T}

要进行法线变换，这个公式要施加在曲面上所有的法线上。

另外要注意的是法线是一个向量，不会随着平移而改变，因此平移变换对法线没影响。

改变坐标系

在图中，点 (2, 1) 要平移到 (1, 1) 处，可以直接把点向左平移，也可以看成是坐标系的改变，将坐标系向右平移。

引出坐标系的概念是因为，在很多情形下，我们需要一个特定的物理位置在不同的坐标系间变换，例如上一篇文章正交坐标系中所举的例子。下图中，有世界坐标系、相机坐标系和点 P。

点 P 在两个坐标系中的坐标是不同的，而在图形学中，我们经常要做这样的变换。

如果我们在世界坐标系中有一个点，要计算出其在相机坐标系中的位置，则要同时考虑相机旋转的坐标系、相机的位置和观察的位置（视点）。

在二维空间下的旋转中能看到二维旋转矩阵的推导过程，在此基础上，可以看作坐标系向右旋转了θ度，这样点 P 就在新坐标系中到达目标位置 P’ 了。

这样我们就能通过旋转矩阵来得到新的 uv 坐标系了！

[uv]=[cosθ−sinθsinθcosθ][xy]\begin{bmatrix} u\\v \end{bmatrix}=\begin{bmatrix} cos\theta & -sin\theta \\ sin\theta & cos\theta \end{bmatrix}\begin{bmatrix} x\\y \end{bmatrix}

之前讨论的都是三维的变换，下篇笔记会介绍图形学中的观察（Viewing）。3D 数学基础知识有点枯燥，但这是入门图形魔法的必经之路。

参考资料

]]> 图形学 游戏开发 3D数学 3D数学基础-向量运算基础和矩阵变换 /2017/09/22/basic-of-vector-and-matrix-transformation/ 2020年7月26日更新：
最近对变换重新学习整理了，文章在：图形学常见的变换推导。

最近在跟公开课 edx 的 Computer Graphics（想一起学的告诉我！），这篇笔记主要介绍了图形学中会用到的比较基础的3D数学，重拾大学线性代数知识。

基础运算

点积（Dot Product）

将向量相乘得到一个标量
可以通过两个向量除以它们的模得到两个向量之间的夹角

用途：

  • 求两个向量之间的夹角（光源和表面之间夹角的余弦值对于投影来说非常重要）
  • 找到一个向量在另一向量上的投影也非常重要（比如我们想知道一个点在新的坐标系下的坐标）。
  • 点积在笛卡尔坐标系下很有用

a⃗⋅b⃗=∥a∥∥b∥cos⁡θ\vec{a} \cdot \vec{b}=\|a\|\|b\| \cos \theta

叉积（Cross Product）

将向量相乘得到一个正交向量（垂直于向量a和向量b）

a×b=−b×a∥a×b∥=∥a∥∥b∥sin⁡θ\begin{array}{l}{a \times b=-b \times a} \\ {\|a \times b\|=\|a\|\|b\| \sin \theta}\end{array}

叉积所得到的向量的方向可以通过右手坐标系来得到：

用右手食指代表叉积中前一个向量，用中指代表叉积中后一个向量，则大拇指的方向就是叉积得到的向量方向。这简单的方法能提醒你：将进行叉积的两个向量顺序调换的话，得到的向量方向会相反。


叉积可以用向量 a 的对偶矩阵来完成，所以可以将它表示成A星(A*)乘以b，其中A*是向量a的对偶矩阵（共轭转置）。

正交坐标系

正交基和坐标系对于表示点的位置非常重要，因为在图形学中，我们通常需要很多不同的坐标系，来表示点在不同参照物下的位置。例如：要表示自己身前一台电脑的位置，可以在自己的位置建立一个坐标系来表示电脑的位置；要表示北极的位置时，用地球的坐标系表示北极的位置会更容易。


矩阵

图形学中矩阵很重要，因为大多数变换都涉及一个矩阵乘以一个向量，矩阵可以用来变换点。下面简单的列一下矩阵的性质，更多的性质可以参考下维基页面矩阵。

矩阵相乘

矩阵相乘时，乘积处(i,j)处的元素是：第一个矩阵的 i 行和第二个矩阵 j 列的点积，这也是为什么要求第一个矩阵的列数等于第二个矩阵的行数。

矩阵转置

[123456789101112]T=[147102581136912]\left[\begin{array}{ccc}{1} & {2} & {3} \\ {4} & {5} & {6} \\ {7} & {8} & {9} \\ {10} & {11} & {12}\end{array}\right]^{T}=\left[\begin{array}{cccc}{1} & {4} & {7} & {10} \\ {2} & {5} & {8} & {11} \\ {3} & {6} & {9} & {12}\end{array}\right]

[abcdefghi]T=[adgbehcfi]\left[\begin{array}{lll}{a} & {b} & {c} \\ {d} & {e} & {f} \\ {g} & {h} & {i}\end{array}\right]^{T}=\left[\begin{array}{lll}{a} & {d} & {g} \\ {b} & {e} & {h} \\ {c} & {f} & {i}\end{array}\right]

[xyz]T=[xyz][xyz]T=[xyz]\left[\begin{array}{lll}{x} & {y} & {z}\end{array}\right]^{T}=\left[\begin{array}{l}{x} \\ {y} \\ {z}\end{array}\right] \quad\left[\begin{array}{l}{x} \\ {y} \\ {z}\end{array}\right]^{T}=\left[\begin{array}{lll}{x} & {y} & {z}\end{array}\right]

(AB)T=BTAT(\mathbf{A B})^{T}=\mathbf{B}^{\mathrm{T}} \mathbf{A}^{\mathrm{T}}

矩阵的逆

(MT)−1=(M−1)T\left(\mathbf{M}^{\mathrm{T}}\right)^{-1}=\left(\mathbf{M}^{-1}\right)^{\mathrm{T}}

(M1M2⋯Mn−1Mn)−1=Mn−1Mn−1−1⋯M2−1M1−1\left(\mathbf{M}_{1} \mathbf{M}_{2} \cdots \mathbf{M}_{n-1} \mathbf{M}_{n}\right)^{-1}=\mathbf{M}_{n}^{-1} \mathbf{M}_{n-1}^{-1} \cdots \mathbf{M}_{2}^{-1} \mathbf{M}_{1}^{-1}

∣M−1∣=1/∣M∣\left|\mathbf{M}^{-1}\right|=1 /|\mathbf{M}|

矩阵与矩阵的逆相乘得到单位矩阵：

M(M−1)=M−1M=I\mathbf{M}\left(\mathbf{M}^{-1}\right)=\mathbf{M}^{-1} \mathbf{M}=\mathbf{I}

矩阵变换

缩放

二维空间下和三维空间下的缩放很简单，直接乘上相应的缩放倍数即可。


切变

旋转

二维空间下的旋转

二维空间下，物体的旋转可以靠矩阵在X方向的变换于矩阵在Y方向的变换叠加得到，但不适用于三维空间。

下面是推导过程：

这三种矩阵变换不符合交换律，也就是说变换的顺序改变会得到不同的结果，要恢复变换的话也要从最后一次变换开始恢复。（Unity 的默认变换顺序是先缩放，再旋转，最后平移）

三维空间下的旋转

下图分别给出了绕 Z 轴旋转、X 轴旋转和 Y 轴旋转的变换矩阵：

二维旋转可以看作是绕着 Z 轴的特殊旋转，因为 Z 轴保持不变。因此 Rz（绕着 Z 轴的旋转）可以直接在二维空间旋转矩阵外的 Z 轴处填充 1 和 0 来使用，同理可得绕X轴的旋转矩阵和 Y 轴的旋转矩阵。

绕任意轴旋转

在这其中，三个正交向量（相互垂直）可以构成一个旋转矩阵，这样就可以将点映射到新的坐标系下。这个概念非常重要，因为在图形学中常常需要这样的变换，如把每个3D模型的顶点的法线从模型空间转到剪裁空间（不同的坐标系）再统一进行计算。

这个旋转矩阵的逆只需要将 XYZ 轴换成 u，v，w 即可。

详见罗德里格旋转公式

下一篇笔记会写更多关于三维空间下的矩阵变换。

参考资料

]]> 图形学 游戏开发 3D数学 Windows 效率软件推荐 /2017/08/05/recommandation-of-some-efficient-software/ 用了几年苹果电脑之后，最近开始用回 Windows 系统，找到一些十分好用的效率向的工具，同时受 效率必备，软件推荐 启发，写篇文章推荐一下。

ShareX

ShareX 是一款主打捕获屏幕、文件分享、和生产力的开源工具。下面是我用 ShareX 来录制软件界面的 GIF 动图，可以看看其丰富的功能。

和 QQ 自带的截图功能和国人开发的 Snipaste 不同，ShareX 的截图不仅仅止于截图后进行批注。ShareX 除了支持和 Snipaste 相似的捕捉窗格（活动的窗口、窗口内的元素等）截图功能外，还支持各种后续的动作，形成一个动作链以节省时间。

截图

例如截完图后可以打开编辑窗口编辑，同时保存图片到自定的目录和剪贴板等等，自己可以自定义其动作链。建议勾选复制到剪贴板，文后会完成一个利用快捷键完成截图上传的动作链（你也可以直接配置截图完进行上传，看个人习惯）。

上传

ShareX 的上传分为图片上传、文字上传和 URL 短链分享。图片可以上传到不同的图床：Imgur、Google Photos、TinyPic 等等，同样的，文件也可以上传到不同的文件共享网站：Dropbox、OneDrive 等，不过软件内置的多是国外的服务。开放性十足的 ShareX 还允许开发者共享自定义上传插件，这些上传插件可以在 CustomUploaders 里找到。

图片上传

由于不同上传的设置类似，这里只写图片上传的一些个人配置。

我自己使用的图床是开放了 API 的 SM.MS 图床，这图床背后的大佬就是卖 t.tt 域名给罗永浩的那位，据他说自己的流量多的用不完就拿来做点公益项目…SM.MS 图床的上传插件可以在 这里 下载，下载后双击即可导入。导入后可以在软件界面的 [上传至…] -> [上传至…设置] -> 左列表最底端的自定义上传者，在目标类型选上 Image uploader 再点更新就能完成上传插件的配置。

接着在 [上传至…] 选项里勾选好对应的上传插件就完成配置了。

上传后的动作

与截图后的动作类似，上传后的动作也十分实用，这里我只选了 URL 复制到剪贴板。

动作链

目前截图、上传这两动作都已经配置好，可以开始配置快捷键了。

快捷键

这里我增加了一个从剪贴板上传的快捷键，这样的话 [快捷键截图] -> 截图保存到剪贴板 -> [快捷键上传] -> 剪贴板内的截图上传到相应图床 -> 返回图片 URL 到剪贴板的动作链就完成了。这对于经常在电脑写东西的我来说很实用，在写这篇文章时也利用这软件节省了不少时间。

你可以在 ShareX 官网 进行下载，其文件托管在 github。

QuickLook

macOS 系统内置了一个好用的功能，就是空格查看文件内容，现在 QuickLook 也为 Windows 提供类似的体验。

空格查看 markdown 文件

空格查看代码文件

空格查看压缩包

你可以在 QuickLook 官网 下载安装包，QuickLook 也能在 Windows 应用商店 下载。

Zeal

受 macOS 平台上 Dash 代码 API 文档查询软件的启发，Zeal 是一款免费开源的支持 Windows 和 Linux 系统的代码 API 文档查询软件。

丰富的文档

查询关键词

与编辑器联动

开发者为 Atom、VSCode、Jetbrain 全家桶 IDE 等提供了相关的插件，例如 Atom 的 atom-dash，VSCode 的 Dash，Jetbrain 全家桶的 Dash。

有了这些插件，你可以做到在写 Python 代码的时候，调用快捷键查询 Zeal 中 Python 文档对应的 API。

你可以在 Zeal 官网 获得 Zeal。

结语

上面提到的三款效率软件都是开源并能免费下载使用，现在越发钦佩开源者了~

]]> 效率 自己的阅读兴趣 /2017/08/04/my-reading-habit/ 本文是为了响应图灵社区自己的兴趣爱好的撰文活动，搬来博客刷下活跃度。

番茄土豆

才发现自己的完成番茄数就在不久前破千了！趁着活动还在，来社区写一篇文章总结下。

翻了翻番茄的记录，最早的番茄是在今年的2月10日凌晨完成的，直至今天共过了175天，这么算来一天才完成5.73个番茄，这远远达不到自己当初设定每天八个番茄的目标，但是这习惯也算是坚持下来了。自己当初使用 番茄土豆 记录番茄的初衷，就是想从懒散的生活节奏中挤出一点时间，分给阅读、学习、写作和英语（除去上课的时间）。现在看统计图，阅读占了其中一大半的时间。

阅读时间

自己阅读了将近248个小时，显然阅读已经成为了我的兴趣爱好。

自己看书看的题材很广泛、也很狭窄。广泛的是编程什么领域都会看一点，编程语言如 Swift、Golang、Python等，技术如算法、前端向的 Angular、后端向的 Rails on Ruby、Django、移动端的 iOS 等等，狭窄的就是很少去看计算机外的书。

现在看来，什么都想了解的兴趣能够让你翻开一本书，但是兴趣太广泛则不是什么好事情，自己现在还没有构建技术栈。好处也有，什么都略懂一点，这也是自己社区简介中 “全栈 Hello World 工程师” 的由来。如今这学期又要学网络和游戏开发（又要学习新领域…），苦也~

前段时间在简书读过一篇文章 为什么我们不再购买技术类书籍，我赞同其中“除读书外还有很多学习技术的途径”，但不认同其中的“技术书籍无用论”。当然，这些学习途径本身就不能拿来比较，因为 有价值的是这些载体其中承载的知识，不同类型的知识有不同的作用。对于一些 bug 的报错、紧跟技术潮流的资讯、小知识点等，我一向喜欢从别人的博客或者问题的回答中寻找答案。而对于一连串成体系的知识点，我更青睐去阅读相关的评价较高的技术书籍。系统地阅读，能够使我理解和构建好这门技术的体系结构，从而打好自己的基础，而这往往是作者在写书前就需要花心思构建好的大纲所体现出来的。

但是阅读技术书籍也容易使我走进一些误区。读完一本技术书的充实感容易使我“飘飘然”，误认为自己已经搞定了一本书，不去下手写代码，从而变成一个“花瓶”程序员。再者，书上的代码和经验往往是正确的，自己跟着作者的思路写代码，能很快地了解一门技术背后的逻辑和设计，却让读者丧失了思考、推理逻辑的过程。因此，我更喜欢去阅读书中带习题、倾向于引导读者思考的书籍，这样能时刻警醒自己，不要沉溺于莫名的“技术满足感”之中。

当我习惯了阅读之后，无论是学校上课，还是深入一些领域，我都更倾向于参考相关的好书。一方面，对于一个知识点，我喜欢把老师的描述和其他书中作者的描述相对比，以作查漏补缺。另一方面，上课前看其他书提前预习将要教授的知识点，能够使我跟着老师的思路去思考，而不会被生疏的名词、知识点打断了自己上课思考的过程。自己前天的游戏开发课就是使用 Unity3D 来教授，自己提前看了眼大纲，找了本书预习了 C# 和 Unity3D 开发的一些简单的概念和过程。后来的上机课顺利地把一周的作业以满分的标准完成（老师有给出作业的完成标准，按照完成程度打分），还能抽出时间问读书过程中和写代码过程中不懂的问题，而不是浪费时间在提问基础知识上。

晒晒六月份放假的时候写的一些日记，那时候在刷图灵书。

日记

以前图灵半价、京东亚马逊优惠买的书，我一定会回来翻阅你们的！

感谢图灵社区，提供这么多高质量的技术书籍翻译，一些书还拿到了电子版权出了电子版，真是海外党福音~最后希望大家能开卷有益！

]]> 学习 《流畅的 Python》读书笔记 /2017/07/01/fluent-python-note/ 两个问题

学了 Python 基础就够了吗？

前言的引言给出了答案：

要不这样吧，如果编程语言里有个地方你弄不明白，而正好又有个人用了这个功能，那就开枪把他打死。这比学习新特性要容易些，然后过不了多久，那些活下来的程序员就会开始用 0.9.6 版的 Python，而且他们只需要使用这个版本中易于理解的那一小部分就好了（眨眼） 。
—— Tim Peters
传奇的核心开发者， “Python 之禅”作者

这本书的目的是什么？

第十一章的杂谈里给出了答案：

这正是本书的主要目的：着重讲解这门语言的基本惯用法，让你的代码简洁、高效且可读，把你打造成熟练的 Python 程序员。

另外本书的前言里也有提及书本的目标读者和非目标读者。

如果你才刚刚开始学 Python，本书的内容可能会显得有些“超纲”。比难懂更糟的是，如果在学习 Python 的过程中过早接触本书的内容，你可能会误以为所有的 Python 代码都应该利用特殊方法和元编程（metaprogramming）技巧。我们知道，不成熟的抽象和过早的优化一样，都会坏事。

对内容的一些评价

从书目录结构来看，作者的眼界十分开阔，每章最后有小结、延伸阅读、和相关的一些杂谈。书的前一部分从 Python 特性出发，参考了很多语言的相关做法和实现，来解释 Python 的设计。

书中时常引用一些参考资料，有些是邮件列表里的讨论、维基百科、一些十分优秀的程序员的撰写的文章和演讲视频。这意味着你可以在某一个概念看到不同的观点，看到优秀的程序员是怎么思考一个问题的。

作者从1998年成为了 Python 程序员，是巴西一家培训机构的共同所有者，也为巴西的媒体、银行和政府部门教授 Python 课程，由此可见本书的代码会是十分透彻和浅显易懂的，事实也的确如此。从代码示例来看，作者为大部分代码提供了 doctest 测试，并且在为某一个知识点提供代码示例时，追求的是简单、直接，同时示例的难度是循序渐进的。加上作者在大部分代码行提供了说明，让读者能十分流畅地理解概念。（对比：《Go 程序设计语言》讲复数语法时用 Mandelbrot 图像作为示例，苦笑）

对翻译的一些评价

整体翻译还是不错的，几百页的书的勘误也才十多个，部分术语可能还要参考书里的术语翻译表，个人认为容易弄混的有特性（properties）和属性（attributes），还有函数（function）和方法（method）。后者的区别可以参考Difference between a method and a function，简单的说法就是函数（function）定义在类外面，而方法（method）定义在类里面，是类的一部分。两者也可以根据是否独立于对象来判断。

黄志斌：这本书第2次印刷时已经把“期物”改为“future”了。

P21 前面那种方式显然能够节省内存。 前者指的是 genexp，即生成器表达式。

章节简介

这本书的结构十分优秀，每一章节都有前言和小结，因此章节简介我偏向于写些零散的知识点和个人感受，会比较乱。大部分章节的章节简介最后会有个人阅读时做的笔记，章节简介没提及的内容可以看看我的笔记。

全部的笔记还可以在这里找到：Latias94/fluent-python-notes

第一章

第一章作者就介绍了 Python 中的特殊方法，特殊方法也是贯穿这本书的基础。

读这本书之前，自己通常会遇到__init__、__new__、__name__ == '__main__'等等的带双下划线的特殊方法，但是通过零散的知识点很难形成体系，而这本书涵盖了绝大部分的特殊方法，并且分章节详细地讨论其背后特殊方法的作用，而这一章就是了解特殊方法的第一步。

作者提到了合理的字符串表示形式：__repr__ 和 __str__。前者方便我们调试和记录日志，后者则是给终端用户看的。

作者开篇就提出了两个问题，第一个问题是：

为什么说 Python 最好的品质之一是一致性？

并且在第十二页给出了答案：

不能让特例特殊到开始破坏既定规则。

第二个问题是：

len(collection) 和 collection.len() 有什么不同？和“Python 风格” （Pythonic）有什么关系？

核心开发者 Raymond Hettinger 的答案是：

实用胜于纯粹
practicality beats purity
——《The Zen of Python》

作者给出解释：

len 是特殊方法，是为了让 Python 自带的数据结构可以走后门，abs 也是同理。（解释：因为如果 x 是一个内置类型的实例，len(x)的背后会用 CPython 直接从 C 结构体中读取对象的长度，不调用任何方法，以至于 len(x) 会非常快。）
…
这种处理方式在保持内置类型的效率和保证语言的一致性之间找到了一个平衡点，也印证了“Python 之禅”中的另外一句话：“不能让特例特殊到开始破坏既定规则。”

从这两个问题就能看出作者想要强调的是：「Python 风格 无处不在」。为了更好地理解 Python 实现，最好了解 Python 的设计风格。

笔记传送门：特殊方法

第二章

第二三四章主讲 Python 数据结构及其背后的实现，而第二章主要讲了可变类型与不可变类型的区别。

要想写出准确、高效和地道的 Python 代码，对标准库里的序列类型的掌握是不可或缺的。数据结构的产生就是为了满足各种不同的需求，例如能让用户在不复制内容的情况下操作同一个数组的不同切片的 memoryview，能高效处理矩阵、矢量等高级数值运算的 NumPy 和专为线性代数、数值积分和统计学而设计并基于 NumPy 的 SciPy。计算机科学家主要抽象了几大数据类型：字典、数组、列表等，这些数据类型都有不同的使用环境，使用好这些工具能让你事半功倍、节省不必要的消耗。

另外，在读这本书的前几天，我刚好在 Segmentfault 里面看到一个问题 python小白 问关于a+=a 和a=a+a的区别，当时看完答案还有点似懂非懂的感觉，而读完这章我能完全理解其区别所在了。

扩展阅读：problem-solving-with-algorithms-and-data-structure-using-python 中文版

笔记传送门：序列构成的数组

第三章

前一章提到了列表、元组这两种序列，以及它们的生成器表达式。这一章则介绍了散列表的基本概念、其背后的算法和由散列表实现的数据类型：字典和集合。

  • 由于字典是由散列表实现的，因此字典的键必须是可散列的。
  • set 类型本身不是可散列的（因为 set 是可变的），但其元素必须可散列。（这也是为什么 list 不能作为字典键的原因）
  • frozenset 是可散列的。
  • 散列表的实现导致它实现的数据类型效率很高，但这是以牺牲空间的代价所带来的。

“优化往往是可维护性的对立面”
由于字典使用了散列表，而散列表又必须是稀疏的，这导致它在空间上的效率低下。举例而言，如果你需要存放数量巨大的记录，那么放在由元组或是具名元组构成的列表中会是比较好的选择；最好不要根据 JSON 的风格，用由字典组成的列表来存放这些记录。用元组取代字典就能节省空间的原因有两个：其一是避免了散列表所耗费的空间，其二是无需把记录中字段的名字在每个元素里都存一遍。

笔记传送门：字典和集合

第四章

目前没遇到过编码问题，不看。

第五章

第五章的主题是：高阶函数没这么重要了。

先来一段吐槽：

Lundh 提出的 lambda 表达式重构秘笈如果使用 lambda 表达式导致一段代码难以理解，Fredrik Lundh 建议像下面这样重构。
(1) 编写注释，说明 lambda 表达式的作用。
(2) 研究一会儿注释，并找出一个名称来概括注释。
(3) 把 lambda 表达式转换成 def 语句，使用那个名称来定义函数。
(4) 删除注释。
摘自“Functional Programming HOWTO”

现在函数式编程十分流行，但 Python 独特的语法使得 lambda、map、filter 和 reduce 这些函数没这么重要了，因为我们有 sum、all 等归约函数，还有 sorted、min、max 和 functools 这样的内置的高阶函数。

最后（5.10.2小节）讲了一个和函数柯里化（Currying）十分相像的概念——偏函数（Partial Application），这两者概念其实不一样。

笔记传送门：一等函数

第六章

作者从策略模式开始，讨论了一等函数在设计模式中的角色，并用一等函数简化了设计模式的实现方式，以此来展示 Pythonic 的设计模式应该是什么样子的。

扩展阅读：设计模式的python实现

笔记传送门：使用一等函数实现设计模式

第七章

第七章介绍了装饰器和闭包，作者给闭包下了一个清晰的定义：

闭包指延伸了作用域的函数，其中包含函数定义体中引用、但是不在定义体中定义的非全局变量。函数是不是匿名的没有关系，关键是它能访问定义体之外定义的非全局变量。

作者用一个闭包实例和作用相同的类来比较，引出了自由变量（free variable）的概念，以此指出闭包与普通函数不一样的地方——闭包会保留定义函数时存在的自由变量的绑定。在此之后，再引出可变类型与不可变类型对自由变量的影响，从而引出可能导致闭包失效的原因（第二章的主题：可变类型与不可变类型的区别），同时给出了解决办法：nonlocal 声明。

本章结尾的杂谈提到了「一般来说，实现“装饰器”模式时最好使用类表示装饰器和要包装的组件。」，也就是通过实现 __call__ 方法的类来实现装饰器。遗憾的是本书只通过函数来解说装饰器以助于理解，类装饰器没有提及多少。

笔记传送门：函数装饰器和闭包

第八章

不可变集合不变的是所含对象的标识。

第八章中，作者从「元组是不可变的，但是其中的值可以改变」引申到浅复制和深复制的区别。

浅复制带来的影响可以参考 example（点 foward 显示下一步）

作者还提到了两个容易忽略的函数参数引用问题：

  1. 不要使用可变类型作为参数的默认值
  2. 防御可变参数

最后一节讨论垃圾回收、del 命令，以及如何使用弱引用“记住”对象，而无需对象本身存在。

另外这章有意思的地方在于作者提到了一个常见的说法错误：「对引用式变量来说，说把变量分配给对象更合理，反过来说就有问题。毕竟对象在赋值之前就创建了。」

笔记传送门：对象引用、可变性和垃圾回收

第九章

要构建符合 Python 风格的对象，就要观察真正的 Python 对象的行为。
——古老的中国谚语

第九章主要讲如何编写 Pythonic 的对象。作者从构建一个 Vector 类型来介绍符合 Python 风格的类需要注意的地方，例如__repr__不要硬编码类名、类属性的私有化、格式规范微语言、散列化要注意的条件等。

作者还讲了构建一个可散列的类型所需要实现的条件：

  1. 正确的实现__hash__和__eq__方法
  2. 不一定要实现只读属性，但是要保证实例的散列值绝不能变化。

类属性用于为实例属性提供默认值。Django 的类视图也大量用到了这个特性。

个人十分喜欢名称改写（属性的私有化）中的一张示意图：
「避免意外访问，但不能防止故意做错事。」，以此来提醒名称改写所实现的私有化自身的缺陷。

笔记传送门：符合 Python 风格的对象

第十章

不要检查它是不是鸭子、它的叫声像不像鸭子、它的走路姿势像不像鸭子，等等。具体检查什么取决于你想使用语言的哪些行为。 （comp.lang.python，2000 年 7 月 26 日）
——Alex Martelli

其中介绍了鸭子类型，指忽略对象的真正类型，转而关注对象有没有实现所需的方法、签名和语义。在 Python 中指免使用 isinstance 检查对象的类型。

如果我想实现一个序列，可以实现__init__、__len__、__getitem__等一序列的方法，使其行为像序列，那么这就是一个序列，这也就是人们所称的鸭子类型（duck typing）。

自己的理解：要明白自己希望的鸭子有哪些特性，只要我实现出来了，那么这就是鸭子。

Tips:

  • 可以用 dir(slice) 来查看序列的属性
  • 当 Python 库文档查询不到方法的文档的时候，可以尝试用 help(slice.indices) 来查询。（ 直接查询__doc__属性的信息 ）

第四小节讲可切片的序列需要关注的两个问题：

  1. 如果创建的序列内部由数组（或其他序列）实现，那么就要考虑切片对象的实现：切片返回的是自创建的序列对象 还是数组（或其他序列）？如果需要考虑，就是在 __getitem__ 方法里修改其实现方式。

  2. 动态存取属性，使序列能通过名称访问序列的属性（v.x,v.y代替v[0],v[1]）。也提到了实现 __getitem__ 时可能会产生的问题，和解决方法。

章节末尾的杂谈提到了要遵循 KISS 原则（Keep it simple, stupid），不要过度设计协议。

笔记传送门：序列的修改、散列和切片

第十一章

本章讨论的话题是接口：从鸭子类型的代表特征动态协议，到使接口更明确、能验证实现是否符合规定的抽象基类（Abstract Base Class，ABC）

我们可能不需要写抽象基类，但是阅读本章能够教我们怎么阅读标准库和其他包中的抽象基类源码。

其中，作者引用了 Alex Martelli 的一篇文章，用表型系统学(phenetics)和支序系统学（cladistics）用水禽来类比抽象基类。(⊙﹏⊙)b

其中有第十章提到的「鸭子类型」，还有以前没提过的、描述一种新的 Python 编程风格的「白鹅类型」（goose typing）。

白鹅类型指，只要 cls 是抽象基类，即 cls 的元类是 abc.ABCMeta，就可以使用 isinstance(obj, cls)。

对此，作者在章节小结里面提到：

借助「白鹅类型」，可以使用抽象基类明确声明接口，而且类可以子类化抽象基类或使用抽象基类注册（无需在继承关系中确立静态的强链接），宣称它实现了某个接口。

本章最后还介绍了和 Go 语言协议的功能十分类似的 __subclasshook__ 方法。

笔记传送门：接口：从协议到抽象基类

第十二章

分析 GUI 工具包 Tkhinter 的多重继承，并且展开分析了多次继承所带来的「菱形问题」，以及 Python 对应的解决方案——方法解析顺序（Method Resolution Order，MRO)，最后作者给了八条关于处理多重继承的建议。

9.5.1. Multiple Inheritance 里面提到了继承顺序是深度优先从左至右不重复。

For most purposes, in the simplest cases, you can think of the search for attributes inherited from a parent class as depth-first, left-to-right, not searching twice in the same class where there is an overlap in the hierarchy.

笔记传送门：继承的优缺点

第十三章

第十三章介绍了重载运算符的时候要考虑多重情况。

In the face of ambiguity, refuse the temptation to guess.
面对太多的可能，不要尝试猜测。（ZoomQuiet禅译）
——《The Zen of Python》

我们要严谨地对待可能会出现的操作数。

对于为什么需要重载运算符，在杂谈中作者提到了对于一部分人来说，重载运算符是十分重要的，符合人类直觉的表示法十分重要，例如金融工作会接触到一些由不同类型的参数（整数、或其他精度的数字）组成的公式。相比于不支持运算符重载的 Go 与 Java 语言，Python 采取了折中的方式，允许重载运算符，也有一些限制，如：不能重载内置类型的运算符、不能新建运算符、一些运算符也不能重载（is、and、or、not）。

笔记传送门：正确重载运算符

第十四章

作者分别介绍了迭代器、生成器表达式和生成器函数，并详细地列举了每个标准库生成器函数的用法。

前面介绍过 Python 内置的数据类型，如列表和元组，能让我们高效地访问数据集，但这些序列只能表示已知且长度有限的数据集。要表示无限长度的数据集，例如斐波拉契数列，就需要用到新的构造方式，这也是本章的话题的由来。

扫描内存中放不下的数据集时，我们要找到一种惰性获取数据项的方式，即按需一次获取一个数据项。这就是迭代器模式（Iterator pattern） 。

其中作者依然很注意用词，生成器是 “yields or produces” 生成值，而不是 “returns” 返回值，这样有助于理解生成器获取结果的过程，因为生成器不是以「常规」方式返回值的。

笔记传送门：可迭代的对象、迭代器和生成器

第十五章

介绍了 else 的三种用法与上下文管理器和 with 的作用，作者用__enter__、__exit__等方法手动地实现了一个上下文管理器，还介绍了 @contextmanager 作为另外一种更优雅的实现上下文管理器的方法。其中 @contextmanager 的 yield 语句也引出了第十六章中协程的概念。

笔记传送门：上下文管理器和else块

第十六章

建议看第十六、十七、十八章之前先理解五个概念：线程、进程、协程、并发和并行。

自己参考了：

在本章中，作者介绍了如何构建协程，和协程的一些使用场景，章节末尾，作者举了一个离散事件仿真示例，说明如何使用生成器代替线程和回调，实现并发。

在前些章节的基础上，作者在这章提到 yield 可以看做是控制流程的方式，即 yield 能获取值（.send(foo)），也能产出值（foo = yield），还能不获取和产出值（yield 后没有表达式）。因此，我们能用它来构建协程。

不管数据如何流动，yield 都是一种流程控制工具，使用它可以实现协作式多任务：协程可以把控制器让步给中心调度程序，从而激活其他的协程。

除了调用 .send(...) 方法发送数据，本章还介绍使用 yield from 结构驱动的生成器函数。

扩展阅读：

笔记传送门：协程

第十七章

并发是计算机科学中最难的概念之一（通常最好别去招惹它） 。
——David Beazley Python 教练和科学狂人

在第十七章，作者用一个下载国旗图片的例子来介绍网络下载的三种风格：依序下载、concurrent.futures 模块（ThreadPoolExecutor 和 ProcessPoolExecutor 类）实现的并发下载和 asyncio 包实现的并发下载。作者还介绍了阻塞性 I/O 和 GIL，最后介绍了如何借助 concurrent.futures.ProcessPoolExecutor 类使用多进程。

future 指一种对象，表示异步执行的操作。

早期的计算机从单用户操作系统（同一时间只能运行一个任务）转变成多任务操作系统（同一时间可以运行多个任务），又由于多任务操作系统中程序经常抢夺系统资源而引发死锁这种缺陷，在 20 世纪 60 年代，计算机科学家就开始探索并发编程的道路，并发指交替执行多个任务，解决的就是前面提到的多任务操作系统的缺陷。直到现在，很多编程语言都为并发提供了支持，其中包括原生支持并发的 Go 语言，和有相关模块支持的 Python。

并发（concurrency）不是并行（parallelism）。并行是让不同的代码片段同时在不同的物理处理器上执行。并行的关键是同时做很多事情，而并发是指同时管理很多事情，这些事情可能只做了一半就被暂停去做别的事情了。在很多情况下，并发的效果比并行好，因为操作系统和硬件的总资源一般很少，但能支持系统同时做很多事情。
——《Go 语言实战》

笔记传送门：使用future处理并发

第十八章

并发是指一次处理多件事。
并行是指一次做多件事。
二者不同，但是有联系。
一个关于结构，一个关于执行。
并发用于制定方案，用来解决可能（但未必）并行的问题。
——Rob Pike Go 语言的创造者之一

第十八章中，作者主要介绍了新的并发编程方式，对比了 asyncio.Task （协程）对象与 threading.Thread （线程）对象的区别，包括 Python 包使用方式的区别和中断时协程与线程的区别：锁的保留。章节尾，作者介绍了 asyncio 包的使用和并发编程需要注意的地方。

笔记待补

第十九章

第十九章主要介绍了动态属性编程。

1
2
3
4
5
6
7
8
>>> class Foo(object):
...     pass
... 
>>> foo = Foo()
>>> foo.a = 3
>>> Foo.b = property(lambda self: self.a + 1)
>>> foo.b
4

这就叫做动态属性（dynamic attribute），不同于属于静态语言的 Java 需要依靠 setter 和 getter 方法，Python 能十分方便地设置属性和读取属性。

作者拿 FrozenJSON 类做例子：把嵌套的字典和列表转换成嵌套的 FrozenJSON 实例和实例列表。FrozenJSON 类的代码展示了如何使用特殊的 __getattr__ 方法（处理属性的函数）在读取属性时即时转换数据结构。

作者还介绍了很多处理属性的属性和函数以及利用特性(@properties)来修改设置属性和读取属性的方式。

笔记传送门：动态属性和特性

第二十章

有时候看书看着就忘了一些名词是什么了，因此参考了下【译】Python描述符指南，描述符类就是实现描述符协议的类。

相比于第十九章中利用特性（@properties）来修改属性的存取逻辑，第二十章主要介绍了描述符——对多个属性运用相同存取逻辑的一种方式。两者的区别是特性有时更合适和简单，而描述符更灵活。这章还介绍了覆盖型与非覆盖型描述符的对比，最后也给出了使用描述符的建议和优缺点。

笔记传送门：属性描述符

第二十一章

（元类）是深奥的知识，99% 的用户都无需关注。如果你想知道是否需要使用元类，我告诉你，不需要（真正需要使用元类的人确信他们需要，无需解释原因） 。
——Tim Peters
Timsort 算法的发明者，活跃的 Python 贡献者

上面是第二十一章的引言，我听从这位传奇开发者的建议，没有看。

总结

整本书都在强调如何最大限度地利用 Python 标准库以及讲述 Python 背后的设计思想。身处众多动态编程语言中间，Python 无疑是独行独立的，这也是为什么很多 Python 开发者骄傲地宣称自己是一名 Pythonista。

自己只是不求甚解地通读了一遍书，学到了很多，但书中仍有太多不熟悉的知识点。因为假期不多了，只能等日后二刷这本书。过一遍这本书最大的收获莫过于在面对问题的时候，自己的工具箱又多了不少工具，即使这工具还不太「趁手」。其中感受最深的就是现在看一些 Segmentfault 或 StackOverflow 问题的答案的时候不再那么毫无头绪，并开始试着从前辈们的角度思考问题。另外书中多次提到 Django 的一些实现方式，对自己日后读源码的时候有帮助。

仓促本身就是最要不得的态度。当你做某件事的时候，一旦想要求快，就表示你再也不关心它，而想去做别的事。
——罗伯特 · M · 波西格 《禅与摩托车维修艺术》

自己的确因为阅读计划的期限而读的仓促了一些，这句话放到文尾，提醒自己在读下一本书的时候，尽量做到静下心来。

]]> 读后感 Python 笔记 《流畅的 Python》读书笔记 /2017/07/01/go-learning-source/ 两个问题

学了 Python 基础就够了吗？

前言的引言给出了答案：

要不这样吧，如果编程语言里有个地方你弄不明白，而正好又有个人用了这个功能，那就开枪把他打死。这比学习新特性要容易些，然后过不了多久，那些活下来的程序员就会开始用 0.9.6 版的 Python，而且他们只需要使用这个版本中易于理解的那一小部分就好了（眨眼） 。
—— Tim Peters
传奇的核心开发者， “Python 之禅”作者

这本书的目的是什么？

第十一章的杂谈里给出了答案：

这正是本书的主要目的：着重讲解这门语言的基本惯用法，让你的代码简洁、高效且可读，把你打造成熟练的 Python 程序员。

另外本书的前言里也有提及书本的目标读者和非目标读者。

如果你才刚刚开始学 Python，本书的内容可能会显得有些“超纲”。比难懂更糟的是，如果在学习 Python 的过程中过早接触本书的内容，你可能会误以为所有的 Python 代码都应该利用特殊方法和元编程（metaprogramming）技巧。我们知道，不成熟的抽象和过早的优化一样，都会坏事。

对内容的一些评价

从书目录结构来看，作者的眼界十分开阔，每章最后有小结、延伸阅读、和相关的一些杂谈。书的前一部分从 Python 特性出发，参考了很多语言的相关做法和实现，来解释 Python 的设计。

书中时常引用一些参考资料，有些是邮件列表里的讨论、维基百科、一些十分优秀的程序员的撰写的文章和演讲视频。这意味着你可以在某一个概念看到不同的观点，看到优秀的程序员是怎么思考一个问题的。

作者从1998年成为了 Python 程序员，是巴西一家培训机构的共同所有者，也为巴西的媒体、银行和政府部门教授 Python 课程，由此可见本书的代码会是十分透彻和浅显易懂的，事实也的确如此。从代码示例来看，作者为大部分代码提供了 doctest 测试，并且在为某一个知识点提供代码示例时，追求的是简单、直接，同时示例的难度是循序渐进的。加上作者在大部分代码行提供了说明，让读者能十分流畅地理解概念。（对比：《Go 程序设计语言》讲复数语法时用 Mandelbrot 图像作为示例，苦笑）

对翻译的一些评价

整体翻译还是不错的，几百页的书的勘误也才十多个，部分术语可能还要参考书里的术语翻译表，个人认为容易弄混的有特性（properties）和属性（attributes），还有函数（function）和方法（method）。后者的区别可以参考Difference between a method and a function，简单的说法就是函数（function）定义在类外面，而方法（method）定义在类里面，是类的一部分。两者也可以根据是否独立于对象来判断。

黄志斌：这本书第2次印刷时已经把“期物”改为“future”了。

P21 前面那种方式显然能够节省内存。 前者指的是 genexp，即生成器表达式。

章节简介

这本书的结构十分优秀，每一章节都有前言和小结，因此章节简介我偏向于写些零散的知识点和个人感受，会比较乱。大部分章节的章节简介最后会有个人阅读时做的笔记，章节简介没提及的内容可以看看我的笔记。

全部的笔记还可以在这里找到：Latias94/fluent-python-notes

第一章

第一章作者就介绍了 Python 中的特殊方法，特殊方法也是贯穿这本书的基础。

读这本书之前，自己通常会遇到__init__、__new__、__name__ == '__main__'等等的带双下划线的特殊方法，但是通过零散的知识点很难形成体系，而这本书涵盖了绝大部分的特殊方法，并且分章节详细地讨论其背后特殊方法的作用，而这一章就是了解特殊方法的第一步。

作者提到了合理的字符串表示形式：__repr__ 和 __str__。前者方便我们调试和记录日志，后者则是给终端用户看的。

作者开篇就提出了两个问题，第一个问题是：

为什么说 Python 最好的品质之一是一致性？

并且在第十二页给出了答案：

不能让特例特殊到开始破坏既定规则。

第二个问题是：

len(collection) 和 collection.len() 有什么不同？和“Python 风格” （Pythonic）有什么关系？

核心开发者 Raymond Hettinger 的答案是：

实用胜于纯粹
practicality beats purity
——《The Zen of Python》

作者给出解释：

len 是特殊方法，是为了让 Python 自带的数据结构可以走后门，abs 也是同理。（解释：因为如果 x 是一个内置类型的实例，len(x)的背后会用 CPython 直接从 C 结构体中读取对象的长度，不调用任何方法，以至于 len(x) 会非常快。）
…
这种处理方式在保持内置类型的效率和保证语言的一致性之间找到了一个平衡点，也印证了“Python 之禅”中的另外一句话：“不能让特例特殊到开始破坏既定规则。”

从这两个问题就能看出作者想要强调的是：「Python 风格 无处不在」。为了更好地理解 Python 实现，最好了解 Python 的设计风格。

笔记传送门：特殊方法

第二章

第二三四章主讲 Python 数据结构及其背后的实现，而第二章主要讲了可变类型与不可变类型的区别。

要想写出准确、高效和地道的 Python 代码，对标准库里的序列类型的掌握是不可或缺的。数据结构的产生就是为了满足各种不同的需求，例如能让用户在不复制内容的情况下操作同一个数组的不同切片的 memoryview，能高效处理矩阵、矢量等高级数值运算的 NumPy 和专为线性代数、数值积分和统计学而设计并基于 NumPy 的 SciPy。计算机科学家主要抽象了几大数据类型：字典、数组、列表等，这些数据类型都有不同的使用环境，使用好这些工具能让你事半功倍、节省不必要的消耗。

另外，在读这本书的前几天，我刚好在 Segmentfault 里面看到一个问题 python小白 问关于a+=a 和a=a+a的区别，当时看完答案还有点似懂非懂的感觉，而读完这章我能完全理解其区别所在了。

扩展阅读：problem-solving-with-algorithms-and-data-structure-using-python 中文版

笔记传送门：序列构成的数组

第三章

前一章提到了列表、元组这两种序列，以及它们的生成器表达式。这一章则介绍了散列表的基本概念、其背后的算法和由散列表实现的数据类型：字典和集合。

  • 由于字典是由散列表实现的，因此字典的键必须是可散列的。
  • set 类型本身不是可散列的（因为 set 是可变的），但其元素必须可散列。（这也是为什么 list 不能作为字典键的原因）
  • frozenset 是可散列的。
  • 散列表的实现导致它实现的数据类型效率很高，但这是以牺牲空间的代价所带来的。

“优化往往是可维护性的对立面”
由于字典使用了散列表，而散列表又必须是稀疏的，这导致它在空间上的效率低下。举例而言，如果你需要存放数量巨大的记录，那么放在由元组或是具名元组构成的列表中会是比较好的选择；最好不要根据 JSON 的风格，用由字典组成的列表来存放这些记录。用元组取代字典就能节省空间的原因有两个：其一是避免了散列表所耗费的空间，其二是无需把记录中字段的名字在每个元素里都存一遍。

笔记传送门：字典和集合

第四章

目前没遇到过编码问题，不看。

第五章

第五章的主题是：高阶函数没这么重要了。

先来一段吐槽：

Lundh 提出的 lambda 表达式重构秘笈如果使用 lambda 表达式导致一段代码难以理解，Fredrik Lundh 建议像下面这样重构。
(1) 编写注释，说明 lambda 表达式的作用。
(2) 研究一会儿注释，并找出一个名称来概括注释。
(3) 把 lambda 表达式转换成 def 语句，使用那个名称来定义函数。
(4) 删除注释。
摘自“Functional Programming HOWTO”

现在函数式编程十分流行，但 Python 独特的语法使得 lambda、map、filter 和 reduce 这些函数没这么重要了，因为我们有 sum、all 等归约函数，还有 sorted、min、max 和 functools 这样的内置的高阶函数。

最后（5.10.2小节）讲了一个和函数柯里化（Currying）十分相像的概念——偏函数（Partial Application），这两者概念其实不一样。

笔记传送门：一等函数

第六章

作者从策略模式开始，讨论了一等函数在设计模式中的角色，并用一等函数简化了设计模式的实现方式，以此来展示 Pythonic 的设计模式应该是什么样子的。

扩展阅读：设计模式的python实现

笔记传送门：使用一等函数实现设计模式

第七章

第七章介绍了装饰器和闭包，作者给闭包下了一个清晰的定义：

闭包指延伸了作用域的函数，其中包含函数定义体中引用、但是不在定义体中定义的非全局变量。函数是不是匿名的没有关系，关键是它能访问定义体之外定义的非全局变量。

作者用一个闭包实例和作用相同的类来比较，引出了自由变量（free variable）的概念，以此指出闭包与普通函数不一样的地方——闭包会保留定义函数时存在的自由变量的绑定。在此之后，再引出可变类型与不可变类型对自由变量的影响，从而引出可能导致闭包失效的原因（第二章的主题：可变类型与不可变类型的区别），同时给出了解决办法：nonlocal 声明。

本章结尾的杂谈提到了「一般来说，实现“装饰器”模式时最好使用类表示装饰器和要包装的组件。」，也就是通过实现 __call__ 方法的类来实现装饰器。遗憾的是本书只通过函数来解说装饰器以助于理解，类装饰器没有提及多少。

笔记传送门：函数装饰器和闭包

第八章

不可变集合不变的是所含对象的标识。

第八章中，作者从「元组是不可变的，但是其中的值可以改变」引申到浅复制和深复制的区别。

浅复制带来的影响可以参考 example（点 foward 显示下一步）

作者还提到了两个容易忽略的函数参数引用问题：

  1. 不要使用可变类型作为参数的默认值
  2. 防御可变参数

最后一节讨论垃圾回收、del 命令，以及如何使用弱引用“记住”对象，而无需对象本身存在。

另外这章有意思的地方在于作者提到了一个常见的说法错误：「对引用式变量来说，说把变量分配给对象更合理，反过来说就有问题。毕竟对象在赋值之前就创建了。」

笔记传送门：对象引用、可变性和垃圾回收

第九章

要构建符合 Python 风格的对象，就要观察真正的 Python 对象的行为。
——古老的中国谚语

第九章主要讲如何编写 Pythonic 的对象。作者从构建一个 Vector 类型来介绍符合 Python 风格的类需要注意的地方，例如__repr__不要硬编码类名、类属性的私有化、格式规范微语言、散列化要注意的条件等。

作者还讲了构建一个可散列的类型所需要实现的条件：

  1. 正确的实现__hash__和__eq__方法
  2. 不一定要实现只读属性，但是要保证实例的散列值绝不能变化。

类属性用于为实例属性提供默认值。Django 的类视图也大量用到了这个特性。

个人十分喜欢名称改写（属性的私有化）中的一张示意图：
「避免意外访问，但不能防止故意做错事。」，以此来提醒名称改写所实现的私有化自身的缺陷。

笔记传送门：符合 Python 风格的对象

第十章

不要检查它是不是鸭子、它的叫声像不像鸭子、它的走路姿势像不像鸭子，等等。具体检查什么取决于你想使用语言的哪些行为。 （comp.lang.python，2000 年 7 月 26 日）
——Alex Martelli

其中介绍了鸭子类型，指忽略对象的真正类型，转而关注对象有没有实现所需的方法、签名和语义。在 Python 中指免使用 isinstance 检查对象的类型。

如果我想实现一个序列，可以实现__init__、__len__、__getitem__等一序列的方法，使其行为像序列，那么这就是一个序列，这也就是人们所称的鸭子类型（duck typing）。

自己的理解：要明白自己希望的鸭子有哪些特性，只要我实现出来了，那么这就是鸭子。

Tips:

  • 可以用 dir(slice) 来查看序列的属性
  • 当 Python 库文档查询不到方法的文档的时候，可以尝试用 help(slice.indices) 来查询。（ 直接查询__doc__属性的信息 ）

第四小节讲可切片的序列需要关注的两个问题：

  1. 如果创建的序列内部由数组（或其他序列）实现，那么就要考虑切片对象的实现：切片返回的是自创建的序列对象 还是数组（或其他序列）？如果需要考虑，就是在 __getitem__ 方法里修改其实现方式。

  2. 动态存取属性，使序列能通过名称访问序列的属性（v.x,v.y代替v[0],v[1]）。也提到了实现 __getitem__ 时可能会产生的问题，和解决方法。

章节末尾的杂谈提到了要遵循 KISS 原则（Keep it simple, stupid），不要过度设计协议。

笔记传送门：序列的修改、散列和切片

第十一章

本章讨论的话题是接口：从鸭子类型的代表特征动态协议，到使接口更明确、能验证实现是否符合规定的抽象基类（Abstract Base Class，ABC）

我们可能不需要写抽象基类，但是阅读本章能够教我们怎么阅读标准库和其他包中的抽象基类源码。

其中，作者引用了 Alex Martelli 的一篇文章，用表型系统学(phenetics)和支序系统学（cladistics）用水禽来类比抽象基类。(⊙﹏⊙)b

其中有第十章提到的「鸭子类型」，还有以前没提过的、描述一种新的 Python 编程风格的「白鹅类型」（goose typing）。

白鹅类型指，只要 cls 是抽象基类，即 cls 的元类是 abc.ABCMeta，就可以使用 isinstance(obj, cls)。

对此，作者在章节小结里面提到：

借助「白鹅类型」，可以使用抽象基类明确声明接口，而且类可以子类化抽象基类或使用抽象基类注册（无需在继承关系中确立静态的强链接），宣称它实现了某个接口。

本章最后还介绍了和 Go 语言协议的功能十分类似的 __subclasshook__ 方法。

笔记传送门：接口：从协议到抽象基类

第十二章

分析 GUI 工具包 Tkhinter 的多重继承，并且展开分析了多次继承所带来的「菱形问题」，以及 Python 对应的解决方案——方法解析顺序（Method Resolution Order，MRO)，最后作者给了八条关于处理多重继承的建议。

9.5.1. Multiple Inheritance 里面提到了继承顺序是深度优先从左至右不重复。

For most purposes, in the simplest cases, you can think of the search for attributes inherited from a parent class as depth-first, left-to-right, not searching twice in the same class where there is an overlap in the hierarchy.

笔记传送门：继承的优缺点

第十三章

第十三章介绍了重载运算符的时候要考虑多重情况。

In the face of ambiguity, refuse the temptation to guess.
面对太多的可能，不要尝试猜测。（ZoomQuiet禅译）
——《The Zen of Python》

我们要严谨地对待可能会出现的操作数。

对于为什么需要重载运算符，在杂谈中作者提到了对于一部分人来说，重载运算符是十分重要的，符合人类直觉的表示法十分重要，例如金融工作会接触到一些由不同类型的参数（整数、或其他精度的数字）组成的公式。相比于不支持运算符重载的 Go 与 Java 语言，Python 采取了折中的方式，允许重载运算符，也有一些限制，如：不能重载内置类型的运算符、不能新建运算符、一些运算符也不能重载（is、and、or、not）。

笔记传送门：正确重载运算符

第十四章

作者分别介绍了迭代器、生成器表达式和生成器函数，并详细地列举了每个标准库生成器函数的用法。

前面介绍过 Python 内置的数据类型，如列表和元组，能让我们高效地访问数据集，但这些序列只能表示已知且长度有限的数据集。要表示无限长度的数据集，例如斐波拉契数列，就需要用到新的构造方式，这也是本章的话题的由来。

扫描内存中放不下的数据集时，我们要找到一种惰性获取数据项的方式，即按需一次获取一个数据项。这就是迭代器模式（Iterator pattern） 。

其中作者依然很注意用词，生成器是 “yields or produces” 生成值，而不是 “returns” 返回值，这样有助于理解生成器获取结果的过程，因为生成器不是以「常规」方式返回值的。

笔记传送门：可迭代的对象、迭代器和生成器

第十五章

介绍了 else 的三种用法与上下文管理器和 with 的作用，作者用__enter__、__exit__等方法手动地实现了一个上下文管理器，还介绍了 @contextmanager 作为另外一种更优雅的实现上下文管理器的方法。其中 @contextmanager 的 yield 语句也引出了第十六章中协程的概念。

笔记传送门：上下文管理器和else块

第十六章

建议看第十六、十七、十八章之前先理解五个概念：线程、进程、协程、并发和并行。

自己参考了：

在本章中，作者介绍了如何构建协程，和协程的一些使用场景，章节末尾，作者举了一个离散事件仿真示例，说明如何使用生成器代替线程和回调，实现并发。

在前些章节的基础上，作者在这章提到 yield 可以看做是控制流程的方式，即 yield 能获取值（.send(foo)），也能产出值（foo = yield），还能不获取和产出值（yield 后没有表达式）。因此，我们能用它来构建协程。

不管数据如何流动，yield 都是一种流程控制工具，使用它可以实现协作式多任务：协程可以把控制器让步给中心调度程序，从而激活其他的协程。

除了调用 .send(...) 方法发送数据，本章还介绍使用 yield from 结构驱动的生成器函数。

扩展阅读：

笔记传送门：协程

第十七章

并发是计算机科学中最难的概念之一（通常最好别去招惹它） 。
——David Beazley Python 教练和科学狂人

在第十七章，作者用一个下载国旗图片的例子来介绍网络下载的三种风格：依序下载、concurrent.futures 模块（ThreadPoolExecutor 和 ProcessPoolExecutor 类）实现的并发下载和 asyncio 包实现的并发下载。作者还介绍了阻塞性 I/O 和 GIL，最后介绍了如何借助 concurrent.futures.ProcessPoolExecutor 类使用多进程。

future 指一种对象，表示异步执行的操作。

早期的计算机从单用户操作系统（同一时间只能运行一个任务）转变成多任务操作系统（同一时间可以运行多个任务），又由于多任务操作系统中程序经常抢夺系统资源而引发死锁这种缺陷，在 20 世纪 60 年代，计算机科学家就开始探索并发编程的道路，并发指交替执行多个任务，解决的就是前面提到的多任务操作系统的缺陷。直到现在，很多编程语言都为并发提供了支持，其中包括原生支持并发的 Go 语言，和有相关模块支持的 Python。

并发（concurrency）不是并行（parallelism）。并行是让不同的代码片段同时在不同的物理处理器上执行。并行的关键是同时做很多事情，而并发是指同时管理很多事情，这些事情可能只做了一半就被暂停去做别的事情了。在很多情况下，并发的效果比并行好，因为操作系统和硬件的总资源一般很少，但能支持系统同时做很多事情。
——《Go 语言实战》

笔记传送门：使用future处理并发

第十八章

并发是指一次处理多件事。
并行是指一次做多件事。
二者不同，但是有联系。
一个关于结构，一个关于执行。
并发用于制定方案，用来解决可能（但未必）并行的问题。
——Rob Pike Go 语言的创造者之一

第十八章中，作者主要介绍了新的并发编程方式，对比了 asyncio.Task （协程）对象与 threading.Thread （线程）对象的区别，包括 Python 包使用方式的区别和中断时协程与线程的区别：锁的保留。章节尾，作者介绍了 asyncio 包的使用和并发编程需要注意的地方。

笔记待补

第十九章

第十九章主要介绍了动态属性编程。

1
2
3
4
5
6
7
8
>>> class Foo(object):
...     pass
... 
>>> foo = Foo()
>>> foo.a = 3
>>> Foo.b = property(lambda self: self.a + 1)
>>> foo.b
4

这就叫做动态属性（dynamic attribute），不同于属于静态语言的 Java 需要依靠 setter 和 getter 方法，Python 能十分方便地设置属性和读取属性。

作者拿 FrozenJSON 类做例子：把嵌套的字典和列表转换成嵌套的 FrozenJSON 实例和实例列表。FrozenJSON 类的代码展示了如何使用特殊的 __getattr__ 方法（处理属性的函数）在读取属性时即时转换数据结构。

作者还介绍了很多处理属性的属性和函数以及利用特性(@properties)来修改设置属性和读取属性的方式。

笔记传送门：动态属性和特性

第二十章

有时候看书看着就忘了一些名词是什么了，因此参考了下【译】Python描述符指南，描述符类就是实现描述符协议的类。

相比于第十九章中利用特性（@properties）来修改属性的存取逻辑，第二十章主要介绍了描述符——对多个属性运用相同存取逻辑的一种方式。两者的区别是特性有时更合适和简单，而描述符更灵活。这章还介绍了覆盖型与非覆盖型描述符的对比，最后也给出了使用描述符的建议和优缺点。

笔记传送门：属性描述符

第二十一章

（元类）是深奥的知识，99% 的用户都无需关注。如果你想知道是否需要使用元类，我告诉你，不需要（真正需要使用元类的人确信他们需要，无需解释原因） 。
——Tim Peters
Timsort 算法的发明者，活跃的 Python 贡献者

上面是第二十一章的引言，我听从这位传奇开发者的建议，没有看。

总结

整本书都在强调如何最大限度地利用 Python 标准库以及讲述 Python 背后的设计思想。身处众多动态编程语言中间，Python 无疑是独行独立的，这也是为什么很多 Python 开发者骄傲地宣称自己是一名 Pythonista。

自己只是不求甚解地通读了一遍书，学到了很多，但书中仍有太多不熟悉的知识点。因为假期不多了，只能等日后二刷这本书。过一遍这本书最大的收获莫过于在面对问题的时候，自己的工具箱又多了不少工具，即使这工具还不太「趁手」。其中感受最深的就是现在看一些 Segmentfault 或 StackOverflow 问题的答案的时候不再那么毫无头绪，并开始试着从前辈们的角度思考问题。另外书中多次提到 Django 的一些实现方式，对自己日后读源码的时候有帮助。

仓促本身就是最要不得的态度。当你做某件事的时候，一旦想要求快，就表示你再也不关心它，而想去做别的事。
——罗伯特 · M · 波西格 《禅与摩托车维修艺术》

自己的确因为阅读计划的期限而读的仓促了一些，这句话放到文尾，提醒自己在读下一本书的时候，尽量做到静下心来。

]]> 读后感 Python 笔记 Go 语言的网络编程简介 /2017/04/29/go-from-tcp-to-http/ 本文通过 Go 语言写几个简单的通信示例，从 TCP 服务器过渡到 HTTP 开发，从而简单介绍 net 包的运用。

TCP 服务器

首先来看一个 TCP 服务器例子

tcp-write/main.go
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
package main

import (
"fmt"
"log"
"net"
)

func main() {
// net 包提供方便的工具用于 network I/O 开发，包括TCP/IP, UDP 协议等。
// Listen 函数会监听来自 8080 端口的连接，返回一个 net.Listener 对象。
li, err := net.Listen("tcp", ":8080")
// 错误处理
if err != nil {
log.Panic(err)
}
// 释放连接，通过 defer 关键字可以让连接在函数结束前进行释放
// 这样可以不关心释放资源的语句位置，增加代码可读性
defer li.Close()

// 不断循环，不断接收来自客户端的请求
for {
// Accept 函数会阻塞程序，直到接收到来自端口的连接
// 每接收到一个链接，就会返回一个 net.Conn 对象表示这个连接
conn, err := li.Accept()

if err != nil {
log.Println(err)
}
// 字符串写入到客户端
fmt.Fprintln(conn, "Hello from TCP server")

conn.Close()
}
}

在对应的文件夹下启动服务器

1
$ go run main.go

模拟客户端程序发出请求，这里使用 netcat 工具，也就是 nc 命令。

1
2
$ nc localhost 8080
Hello from TCP server

通过 net 包，我们可以很简单的去写一个 TCP 服务器，代码可读性强。

TCP 客户端

那么我们能不能用 Go 语言来模拟客户端，从而连接前面的服务器呢？答案是肯定的。

tcp-read/main.go
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
package main

import (
"fmt"
"io/ioutil"
"log"
"net"
)

func main() {
// net 包的 Dial 函数能创建一个 TCP 连接
conn, err := net.Dial("tcp", ":8080")
if err != nil {
log.Fatal(err)
}
// 别忘了关闭连接
defer conn.Close()
// 通过 ioutil 来读取连接中的内容，返回一个 []byte 类型的对象
byte, err := ioutil.ReadAll(conn)
if err != nil {
log.Println(err)
}
// []byte 类型的数据转成字符串型，再将其打印输出
fmt.Println(string(byte))
}

运行服务器后，再在所在的文件夹下启动客户端，会看到来自服务器的问候。

1
2
$ go run main.go
Hello from TCP server

TCP 协议模拟 HTTP 请求

我们知道 TCP/IP 协议是传输层协议，主要解决的是数据如何在网络中传输。而 HTTP 是应用层协议，主要解决的是如何包装这些数据。

下面的七层网络协议图也能看到 HTTP 协议是处于 TCP 的上层，也就是说，HTTP 使用 TCP 来传输其报文数据。

七层网络协议图

现在我们写一个基于 TCP 协议的服务器，并能模拟。在这其中，我们需要模拟发送 HTTP 响应头信息，我们可以用 curl -i 命令先来查看一下其他网站的响应头信息。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
$ curl -i "www.baidu.com"
HTTP/1.1 200 OK  # HTTP 协议及请求码
Server: bfe/1.0.8.18# 服务器使用的WEB软件名及版本
Date: Sat, 29 Apr 2017 07:30:33 GMT  # 发送时间
Content-Type: text/html   # MIME类型
Content-Length: 277# 内容长度
Last-Modified: Mon, 13 Jun 2016 02:50:23 GMT
...  # balabala
Accept-Ranges: bytes

<!DOCTYPE html>  # 消息体
<!--STATUS OK--><html>
...
</body> </html>

接下来，我们尝试写出能输出对应格式响应内容的服务器。

tcp-server-for-http/main.go
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
package main

import (
"fmt"
"log"
"net"
)

func main() {
li, err := net.Listen("tcp", ":8080")
if err != nil {
log.Fatalln(err.Error())
}
defer li.Close()

for {
conn, err := li.Accept()
if err != nil {
log.Fatalln(err.Error())
continue
}
// 函数前添加 go 关键字，就能使其拥有 Go 语言的并发功能
// 这样我们可以同时处理来自不同客户端的请求
go handle(conn)
}
}

func handle(conn net.Conn) {
defer conn.Close()
// 回应客户端的请求
respond(conn)
}

func respond(conn net.Conn) {
// 消息体
body := `<!DOCTYPE html><html lang="en"><head><meta charet="UTF-8"><title>Go example</title></head><body><strong>Hello World</strong></body></html>`
// HTTP 协议及请求码
fmt.Fprint(conn, "HTTP/1.1 200 OK\r\n")
// 内容长度
fmt.Fprintf(conn, "Content-Length: %d\r\n", len(body)) 
// MIME类型
fmt.Fprint(conn, "Content-Type: text/html\r\n")
fmt.Fprint(conn, "\r\n")
fmt.Fprint(conn, body)
}

go run main.go 启动服务器之后，跳转到 localhost:8080，就能看到网页内容，并且用开发者工具能看到其请求头。

最简单的 HTTP 服务器

几行代码就能实现一个最简单的 HTTP 服务器。

simple-http/main.go
1
2
3
4
5
6
7
package main

import "net/http"

func main() {
    http.ListenAndServe(":8080", nil)
}

打开后会发现显示「404 page not found」，这说明 HTTP 已经开始服务了！

ListenAndServe

Go 是通过一个函数 ListenAndServe 来处理这些事情的，这个底层其实这样处理的：初始化一个server 对象，然后调用了 net.Listen(“tcp”, addr)，也就是底层用 TCP 协议搭建了一个服务，然后监控我们设置的端口。

《Build web application with golang》astaxie

前面我们已经对 TCP 服务器有点熟悉了，而 HTTP 使用 TCP 来传输其报文数据，接下来看看如何用 net/http 包来实现在其上的 HTTP 层。

查文档可以发现 http 包下的 ListenAndServe 函数第一个参数是地址，而第二个是 Handler 类型的参数，我们想要显示内容就要在第二个参数下功夫。

ListenAndServelink
1
func ListenAndServe(addr string, handler Handler) error

再次查文档，得知 Handler 是一个接口，也就是说只要我们给某一个类型创建 ServeHTTP(ResponseWriter, *Request) 方法，就能符合接口的要求，也就实现了接口。

http.Handlerlink
1
2
3
type Handler interface {
        ServeHTTP(ResponseWriter, *Request)
}
servehttp/main.go
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
package main

import (
"fmt"
"net/http"
)
// 创建一个 foo 类型
type foo struct {}
// 为 foo 类型创建 ServeHTTP 方法，以实现 Handle 接口
func (f foo) ServeHTTP(w http.ResponseWriter, r *http.Request) {
fmt.Fprintln(w, "Implement the Handle interface.")
}

func main() {
// 创建对象，类型名写后面..
var f foo
http.ListenAndServe(":8080",f)
}

运行代码后打开能看到输出的字符串。

*http.Request

上面我们实现的小服务器里，我们无论访问 localhost:8080 还是 localhost:8080/foo 都是一样的页面，这说明我们之前设定的是默认的页面，还没有为特定的路由(route)设置内容。

路由这些信息实际上就存在 ServeHTTP 函数的第二个参数 *http.Request 中， *http.Request 存放着客户端发送至服务器的请求信息，例如请求链接、请求方法、响应头、消息体等等。

现在我们可以把上面的代码改造一下。

serveHTTP/main.go
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
package main

import (
"fmt"
"net/http"
)
// 创建一个 foo 类型
type foo struct {}
// 为 foo 类型创建 ServeHTTP 方法，以实现 Handle 接口
func (f foo) ServeHTTP(w http.ResponseWriter, r *http.Request) {
// 根据 URL 的相对路径来设置网页内容（不优雅）
switch r.URL.Path {
case "/boy":
fmt.Fprintln(w, "I love you!!!")
case "/girl":
fmt.Fprintln(w, "hehe.")
default:
fmt.Fprintln(w, "Men would stop talking and women would shed tears when they see this.")
}

func main() {
// 创建对象，类型名写后面..
var f foo
http.ListenAndServe(":8080",f)
}

再优雅一点

我们可以用 HTTP 请求多路复用器(HTTP request multiplexer) 来实现分发路由，而http.NewServeMux() 返回的 *ServeMux 对象就能实现这样的功能。下面是 *ServeMux 的部分源码，能看到通过 *ServeMux 就能为每一个路由设置单独的一个 handler 了，简单地说就是不同的内容。

ServeMuxlink
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
type ServeMux struct {
mu    sync.RWMutex         // 读写锁
m     map[string]muxEntry  // 路由信息（键值对）
hosts bool                 // 是否包含 hostnames
}

type muxEntry struct {
explicit bool     // 是否精确匹配
h        Handler  // muxEntry.Handler 是接口
pattern  string   // 路由
}

type Handler interface {
ServeHTTP(ResponseWriter, *Request)
}

用 *ServeMux 来写一个例子。

newServeMux/main.go
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
package main

import (
"fmt"
"net/http"
)

type boy struct{}

func (b boy) ServeHTTP(w http.ResponseWriter, r *http.Request) {
fmt.Fprintln(w, "I love you!!!")
}

type girl struct{}

func (g girl) ServeHTTP(w http.ResponseWriter, r *http.Request) {
fmt.Fprintln(w, "hehe.")
}

type foo struct{}

func (f foo) ServeHTTP(w http.ResponseWriter, r *http.Request) {
fmt.Fprintln(w, "Men would stop talking and women would shed tears when they see this.")
}

func main() {
var b boy
var g girl
var f foo

// 返回一个 *ServeMux 对象
mux := http.NewServeMux()  
mux.Handle("/boy/", b)
mux.Handle("/girl/", g)
mux.Handle("/", f)
http.ListenAndServe(":8080", mux)
}

这样就能为每一个路由设置单独的页面了。

再再优雅一点

http.Handle(pattern string, handler Handler) 还能帮我们简化代码，它默认创建一个 DefaultServeMux，也就是默认的 ServeMux 来存 handler 信息，这样就不需要 http.NewServeMux() 函数了。这看起来虽然没有什么少写多少代码，但是这是下一个更加优雅方法的转折点。

defaultServeMux/main.go
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
package main

import (
"fmt"
"net/http"
)

type boy struct{}

func (b boy) ServeHTTP(w http.ResponseWriter, r *http.Request) {
fmt.Fprintln(w, "I love you!!!")
}

type girl struct{}

func (g girl) ServeHTTP(w http.ResponseWriter, r *http.Request) {
fmt.Fprintln(w, "hehe.")
}

type foo struct{}

func (f foo) ServeHTTP(w http.ResponseWriter, r *http.Request) {
fmt.Fprintln(w, "Men would stop talking and women would shed tears when they see this.")
}

func main() {
var b boy
var g girl
var f foo

http.Handle("/boy/", b)
http.Handle("/girl/", g)
http.Handle("/", f)
http.ListenAndServe(":8080", nil)
}

再再再优雅一点

http.HandleFunc(pattern string, handler func(ResponseWriter, *Request)) 可以看做 http.Handle(pattern string, handler Handler) 的一种包装。前者的第二个参数变成了一个函数，这样我们就不用多次新建对象，再为对象实现 ServeHTTP() 方法来实现不同的 handler 了。下面是 http.HandleFun() 的部分源码。

http.HandleFun()link
1
2
3
4
5
6
7
8
9
func HandleFunc(pattern string, handler func(ResponseWriter, *Request)) {
// 同样利用 DefaultServeMux 来存路由信息
DefaultServeMux.HandleFunc(pattern, handler)
}

func (mux *ServeMux) HandleFunc(pattern string, handler func(ResponseWriter, *Request)) {
// 是不是似曾相识？
mux.Handle(pattern, HandlerFunc(handler))
}

用 http.HandleFun() 来重写之前的例子。

handleFun/main.go
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
package main

import (
"fmt"
"net/http"
)

func boy(w http.ResponseWriter, r *http.Request) {
fmt.Fprintln(w, "I love you!!!")
}

func girl(w http.ResponseWriter, r *http.Request) {
fmt.Fprintln(w, "hehe.")
}

func foo(w http.ResponseWriter, r *http.Request) {
fmt.Fprintln(w, "Men would stop talking and women would shed tears when they see this.")
}

func main() {
http.HandleFunc("/boy/", boy)
http.HandleFunc("/girl/", girl)
http.HandleFunc("/", foo)
http.ListenAndServe(":8080", nil)
}

HandlerFunc

另外，http 包里面还定义了一个类型 http.HandlerFunc，该类型默认实现 Handler 接口，我们可以通过 HandlerFunc(foo) 的方式来实现类型强转，使 foo 也实现了 Handler 接口。

HandlerFunclink
1
2
3
4
5
6
type HandlerFunc func(ResponseWriter, *Request)

// 实现 Handler 接口
func (f HandlerFunc) ServeHTTP(w ResponseWriter, r *Request) {
f(w, r)
}
handleFun/main.go
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
package main

import (
"fmt"
"net/http"
)

func boy(w http.ResponseWriter, r *http.Request) {
fmt.Fprintln(w, "I love you!!!")
}

func girl(w http.ResponseWriter, r *http.Request) {
fmt.Fprintln(w, "hehe.")
}

func foo(w http.ResponseWriter, r *http.Request) {
fmt.Fprintln(w, "Men would stop talking and women would shed tears when they see this.")
}

func main() {
// http.Handler() 的第二个参数是要实现了 Handler 接口的类型
// 可以通过类型强转来重新使用该函数来实现
http.Handle("/boy/", http.HandlerFunc(boy))
http.Handle("/girl/", http.HandlerFunc(girl))
http.Handle("/", http.HandlerFunc(foo))
http.ListenAndServe(":8080", nil)
}

结尾

本文从搭建 TCP 服务器一步步到搭建 HTTP 服务器，展示了 Go 语言网络库的强大，我认为 Go 语言是熟悉网络协议的一个很好的工具。自己从熟悉了拥有各种 feature 的 Swift 语言之后再入门到看似平凡无奇的 Go 语言，经历了从为语言的平庸感到惊讶不解到为其遵循规范和良好的工业语言设计而感到惊叹和兴奋的转变。

最后希望本文能为有基础的同学理清思路，也能吸引更多同学来学习这门优秀的语言。

]]> Go 聊聊慕课与时间管理工具 /2017/03/29/mooc-and-pomotodo/ 在图灵社区活动「分享学习方法」中写了这篇文章，现在搬运过来，浅浅地普及下慕课这种学习新方式和目前所选用的时间管理工具。

MOOC

我以前有过看视频学编程的时光，视频里老师写一点代码，我就写一点代码。如今想起来这种方法虽然浪费时间，但是对小白而言是一个很好的入门方法，能够有效的让小白熟悉 IDE 和手把手入门编程。

MOOC 则是最近又让我眼前一亮的学习方式，其代表有：Coursera、Edx 、Udacity等。同样是看视频学习，Coursera 使用了短视频+限时作业+考试的方法来让学生能轻松上课的同时，用 deadline 督促学生。其次付费证书和其课堂论坛也是亮点，你上完一个课程，可以付费购买课程的证书以彰显你的努力，论坛则是开放给全球各地上同样一节课的学生。Coursera 里有部分课程都是有中文字幕的，例如普林斯顿大学的「Algorithms」课。算法红宝书《算法（第4版）》的作者就是这门课的老师，Robert Sedgewick 老师在课程中给的图例和制作的动画都十分清晰精致，并且配合课件能循序渐进地分解算法。其中小课程一般一节讲一个算法或知识点，内容充实并且需要学生课下消化。这种方式和看《算法（第4版）》结合起来，学习效率事半功倍。PS：上课的同时也请完成红宝书中的课后练习。

我认为 MOOC 可贵的一个地方还是它的课程质量，因为国外 CS 课程的授课老师往往同时有很强的 academic 和 industry 的背景，所以课程通常会兼顾深度和实用性。美国大学一门课收费大约在五千刀左右，所以请努力争取白赚这些钱吧~

在这里随便列举几门课程：有被称为第一神课的「程序设计语言」、斯坦福密码学大牛 Dan Boneh 讲的「Cryptography I」、Coursera 创始人吴恩达讲的「机器学习」等等。

遗憾的是 Coursera 改版之后删除了很多经典神课，例如以 CSAPP 为教材的「The Hardware/Software Interface」，斯坦福大学的编译原理课「Compilers」、斯坦福的另外一门偏理论的算法课「Algorithms: Design and Analysis」等等，这些课程需要自己去学校官网上找，或者去 Youtube 看视频。同时科学上网会有更好的上课体验，另外英语的学习也是很有必要的，毕竟不是门门课都有志愿者翻译成中文。

PS: 斯坦福大学也有自己的 mooc 网站，Stanford Online

已经翻译了的公开课也有志愿者搬运到了 B 站（汗…）、网易公开课、学堂在线等平台。例如哈佛大学的计算机入门课「计算机科学 cs50」、麻省理工学院的「算法导论」课、线性代数神课「线性代数的本质」、用 Python 讲解的计算机科学入门课「计算机科学和Python编程导论」、B 站 UP 主翻译的斯坦福密码学课「密码学」、微软信仰中心翻译的「UWP 开发入门教程」等等。

更多课程及查看评分：
mooc 学院
Coursera课程下载和存档计划四：计算机科学基础公开课
三大 MOOC 网站：Coursera 与 Udacity 和 edX 比较，哪个更适合中国人？你有何经验分享？

番茄工作法

近年来时间管理话题变得十分火热，番茄工作法大家应该都耳熟能详了，我就不详细介绍了。很多番茄工作法的应用如雨后春笋般出现，由于受限于单平台，我没有坚持使用下来。今天推荐一款我在用一段时间的「番茄土豆」服务，番茄土豆拥有全平台应用，涵盖了我的苹果本、iPhone 和 iPad。另外一点就是能方便地回溯自己的番茄时间。

例如下面是在 Coursera 上算法课的统计，右下角统计了时间。

下面是最近看书学 Go 语言的记录。

查看自己花在阅读上的时间。

我认为每完成一个番茄就记录这段时间所做的事，这样能够培养主动记录的习惯，也方便自己对时间的统计分析。建议在记录任务的时候分配好标签，记录完整在做的事情，这样利用很短的时间就能代替追踪时间的效果。

一般免费版就足够用了，我购买了高级版是因为能够补充线下没有统计的番茄时间，高级版对于学生或教师有半价。

总结

学习方法太多了，我敢写在这的都是我感觉的确对我有帮助的方法。自己也是个菜鸟，还在探索自己的学习方法。现在越学习越清楚英语的重要性，希望大家学好英语，这样你可用的学习资源也会多出几十倍来，而不需要靠别人翻译拾人牙慧。

]]> 学习 装饰器模式（Swift） /2017/02/20/decorator-in-swift/

阅读《大话设计模式》和《精通 Swift 设计模式》中的装饰器模式，本文为笔记。

简介

装饰器模式，可以用于在运行时选择性地修改对象的行为，在处理无法修改的类时能发挥其强大的能力。

我们可以在想修改对象的行为时，又不想修改对象所属的类或其使用者，就可以使用装饰器模式。如果想修改对象的类实现，则不推荐使用装饰器模式，此时直接修改类往往更简单。

例子

阅读前请下载 OS X 命令工具行初始项目 Decorator_start，项目中注释较详细，如有问题请联系我。

项目地址：Decorator_in_Swift

初始项目 UML 图

Purchase 类表示顾客在商店买了什么，其中定义了两个属性来存储商品名称和价格，还有两个计算属性把信息提供给外界。

CustomerAccount 类表示一组 Purchase 对象，代表了顾客所购买的商品，addPurchase(Purchase)方法代表顾客购买了新商品。

Options 类中包含三个类，为前两个类提供了礼品服务，例如：2 元的礼品包装、1 元的彩带和 5 元的礼品配送。这里利用继承在 Options 类创建了三个装饰器类解决一个小问题——在不修改原来的两个类时添加了礼品服务功能。

Purchase 类和 CustomerAccount 类实现了创建一个用户对象，然后买一个特定价格的商品，如：张三购买了 10 元的帽子。后三个类则扩展了功能，能为每一个商品增加一个礼品服务的选项，如：张三购买了有彩带包装的 10 元的帽子。

但是已有的代码实现不了为一个商品添加多个礼品服务，如：张三购买了有礼品和彩带包装的 10 元的帽子。

源码运行结果：

1
2
3
4
Purchase Red Hat, Price ￥10.00
Purchase Scarf, Price ￥20.00
Purchase Scarf + delivery, Price ￥25.00
Total due: ￥55.00

装饰器模式

装饰器模式通过创建装饰器类解决上述组合问题（礼品包装+彩带、礼品包装+彩带+礼品配送等），装饰器类是指用于封装原始类并改变其行为的类。

装饰器类提供的 API 和封装的原始类相同，为了创建其他组合，装饰器还可以封装其他装饰器。

这里的单个礼品服务类 Options.swift 可以看做是一个小小的装饰器。

装饰器模式

实现

装饰器类需要继承无法修改的类，来创建一个拥有该类所有方法和属性的类，用来替换原始类的功能。装饰器需要定义一个用来存储被封装对象的私有属性，从而为外界提供该对象的基本功能。

Options.swift

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
/// 装饰器
class BasePurchasDecorator : Purchase {
  private let wrappedPurchase: Purchase
  
  init(purchase: Purchase) {
    wrappedPurchase = purchase
    super.init(product: purchase.description, price: purchase.totalPrice)
  }
}

/// 礼品包装
class PurchaseWithGiftWrap : BasePurchasDecorator {
  override var description: String {
    return "\(super.description) + giftwrap"
  }
  
  override var totalPrice: Float {
    return super.totalPrice + 2
  }
}

/// 礼带
class PurchaseWithRibbon : BasePurchasDecorator {
  override var description: String {
    return "\(super.description) + ribbon"
  }
  
  override var totalPrice: Float {
    return super.totalPrice + 1
  }
}

/// 礼品配送
class PurchaseWithDelivery : BasePurchasDecorator {
  override var description: String {
    return "\(super.description) + delivery"
  }
  
  override var totalPrice: Float {
    return super.totalPrice + 5
  }
}

这里在开头创建了一个继承自 Purchase 类的礼品服务的基类 BasePurchasDecorator，并把原有礼品服务类的父类修改成了它。在 BasePurchasDecorator 类中，不仅定义了一个私有属性 wrappedPurchase 来保存 Purchase 对象（增加新功能小节能看到用途），还会对礼品服务类的属性（description 和 totalPrice）进行处理，以供继承的子类去根据自身的配送描述和价格修改其内容。

main.swift 修改为

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
let account = CustomerAccount(name: "Joe")
account.addPurchase(Purchase(product: "Red Hat", price: 10))
account.addPurchase(Purchase(product: "Scarf", price: 20))
// 礼品配送服务
//account.addPurchase(PurchaseWithDelivery(product: "Scarf", price: 20))
// 带礼品配送服务的20元围巾
account.addPurchase(
  PurchaseWithDelivery(purchase:
    Purchase(product: "Scarf", price: 20)))
    
// 带礼品包装和礼品配送服务的25元太阳眼镜
account.addPurchase(
  PurchaseWithDelivery(purchase:
    PurchaseWithGiftWrap(purchase:
      Purchase(product: "Sunglasses", price:25))))

account.printAccount()
1
2
3
4
5
Purchase Red Hat, Price ￥10.00
Purchase Scarf, Price ￥20.00
Purchase Scarf + delivery, Price ￥25.00
Purchase Sunglasses + giftwrap + delivery, Price ￥32.00
Total due: ￥87.00

增加新功能

如果我们还想要用装饰器为原对象增加新的方法或属性，例如节日打折，我们可以继续定义一个折扣装饰器 DiscountDecorator，并创建子类实现不同折扣。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
/// 新增了折扣功能的装饰器
class DiscountDecorator: Purchase {
  private let wrappedPurchase: Purchase
  
  init(purchase: Purchase) {
    self.wrappedPurchase = purchase
    super.init(product: purchase.description, price: purchase.totalPrice)
  }
  
  override var description: String {
    return super.description
  }
  
  /// 优惠了多少元
  var discountAmount: Float {
    return 0
  }
  
  /// 判断产品是否适用折扣优惠，计算已用折扣数
  func countDiscounts() -> Int {
    var total = 1
    // 注意这里对象本身就已经是一个折扣，wrappedPurchase 是折扣后跟着的purchase对象，还是折扣的话折扣数+1
    if let discounter = wrappedPurchase as? DiscountDecorator {
      total += discounter.countDiscounts()
    }
    return total
  }
}

/// 黑色星期五打8折
class BlackFridayDecorator: DiscountDecorator {
  override var totalPrice: Float {
    return super.totalPrice - discountAmount
  }
  
  override var discountAmount: Float {
    return super.totalPrice * 0.20
  }
}

/// 清仓大甩卖打3折
class EndOfLineDecorator: DiscountDecorator {
  override var totalPrice: Float {
    return super.totalPrice - discountAmount
  }
  
  override var discountAmount: Float {
    return super.totalPrice * 0.70
  }
}

其中我们根据 wrappedPurchase 属性是否继承自折扣装饰器，来判断方法所包含的对象是否是有折扣的商品。例如下面代码中的 EndOfLineDecorator(Purchase) 方法所包含的对象： BlackFirdayDecorator(purchase: PurchaseWithDelivery(purchase: PurchaseWithGiftWrap(purchase: Purchase(product: "Towel", price: 12)))) 有黑五折扣的礼品配送和礼品包装服务的12元太阳眼镜。

main.swift 中新增用了折扣的商品的代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
//... 忽略部分代码

// 带礼品配送+礼品包装服务的12元太阳眼镜共19元，3折加8折后4.56元。
account.addPurchase(
  EndOfLineDecorator(purchase:
    BlackFridayDecorator(purchase:
      PurchaseWithDelivery(purchase:
        PurchaseWithGiftWrap(purchase:
          Purchase(product: "Towel", price: 12))))))

account.printAccount()

// 输出每个商品的折扣数
for purchase in account.purchases {
  if let discountPurchase = purchase as? DiscountDecorator {
    print("\(discountPurchase) has \(discountPurchase.countDiscounts()) discounts")
  } else {
    print("\(purchase) has no discounts")
  }
}
1
2
3
4
5
6
7
8
9
10
11
Purchase Red Hat, Price ￥10.00
Purchase Scarf, Price ￥20.00
Purchase Scarf + delivery, Price ￥25.00
Purchase Sunglasses + giftwrap + delivery, Price ￥32.00
Purchase Towel + giftwrap + delivery, Price ￥4.56
Total due: ￥91.56
Red Hat has no discounts
Scarf has no discounts
Scarf + delivery has no discounts
Sunglasses + giftwrap + delivery has no discounts
Towel + giftwrap + delivery has 2 discounts

UML 图

如果想要让折扣只作用在产品价格而不对礼品服务做影响，也是很简单的。

main.swift

1
2
3
4
5
6
7
// 带礼品配送+礼品包装服务的12元太阳眼镜共19元，黑五8折只对产品价格有效，之后再打清仓3折后4.98元。
account.addPurchase(
  EndOfLineDecorator(purchase:
    PurchaseWithDelivery(purchase:
      PurchaseWithGiftWrap(purchase:
        BlackFridayDecorator(purchase:
          Purchase(product: "Towel", price: 12))))))
1
2
3
4
...
Purchase Towel + giftwrap + delivery, Price ￥4.98
...
Towel + giftwrap + delivery has 1 discounts

计算折扣数的时候有点小问题，但是价格是对的。

用装饰器的时候需要谨慎，要评估对应用其他部分带来哪些影响，特别是已经使用了其他装饰器的情况下。

合并装饰器

装饰器可以为原始类新增新功能，也能合并装饰器。

注意：

  • 装饰器的作用应该是增强或者拓展原始类的功能，而不是给现有的 API 渗透功能。
  • 小项目中直接用多个独立的装饰器类会比较简单，对于复杂的项目会不便于维护，所以将相关联的装饰器类合并会比较合适。

Options.swift

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
/// 合并装饰器
class GiftOptionDecorator: Purchase {
  private let wrappedPurchase: Purchase
  private let options: [Option]
  
  enum Option {
    case giftWrap
    case ribbon
    case delivery
  }
  
  init(purchase: Purchase, options: [Option]) {
    self.wrappedPurchase = purchase
    self.options = options
    super.init(product: purchase.description, price: purchase.totalPrice)
  }
  
  override var description: String {
    var result = wrappedPurchase.description
    for option in options {
      switch option {
      case .giftWrap:
        result = "\(result) + giftwrap"
      case .ribbon:
        result = "\(result) + ribbon"
      case .delivery:
        result = "\(result) + delivery"
      }
    }
    return result
  }
  
  override var totalPrice: Float {
    var result = wrappedPurchase.totalPrice
    for option in options {
      switch option {
      case .giftWrap:
        result += 2
      case .ribbon:
        result += 1
      case .delivery:
        result += 5
      }
    }
    return result
  }
}

main.swift

1
2
3
4
5
6
7
// 利用合并装饰器实现：带礼品配送+礼品包装服务的12元太阳眼镜共19元，3折加8折后4.56元。
account.addPurchase(EndOfLineDecorator(purchase:
  BlackFridayDecorator(purchase:
    GiftOptionDecorator(purchase:
      Purchase(product: "Towel", price: 12),
                        options: [GiftOptionDecorator.Option.giftWrap,
                                  GiftOptionDecorator.Option.delivery]))))
1
2
3
4
...
Purchase Towel + giftwrap + delivery, Price ￥4.56
...
Towel + giftwrap + delivery has 2 discounts

完整项目 UML 图

结果一样，但是实现方式简洁了不少。

合并装饰器的优点是能把类的核心职责和装饰功能区分开，去除相关类重复的装饰逻辑。

总结

完整的项目放在 Decorator_end。

如果我们错误地实现了装饰器模式，那么装饰器所做的修改会对所有对象产生影响，或者另应用多出一些和对象无关的功能。

如增加新功能小节中所提及的，实现装饰器模式后，要注意装饰顺序，否则不同的折扣就应用到不同的范围上了。

重申一遍，装饰器模式是在已有功能上加更多功能的一种方式，不能修改原始类的已有功能和属性。

]]> 设计模式 Swift IRB 中操作 MongoDB /2017/02/16/mongodb_operate_in_irb/

又在 Coursera 里面选了门课坑自己

最近又学了很多东西，其中记不住的做笔记记下来，这篇文章是为 Ruby on Rails 运用 MongoDB 做准备。

基础命令

Mac 下安装 MongoDB 可以参考 Mac下使用brew安装mongodb。

启动数据库

1
% mongod

进入命令行模式

1
% mongo

导入 MongoDB 提供的示例数据

示例数据下载

在 json 文件所在的文件夹下导入数据库。

1
% mongoimport --db test --collection zips --drop --file zips.json

irb Shell 中的一些基础操作

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
irb
2.3.3 :001 > require 'mongo'
 => true
2.3.3 :002 > db = Mongo::Client.new('mongodb://localhost:27017')
D, [2017-02-16T00:06:03.651134 #39047] DEBUG -- : MONGODB | Topology type 'unknown' initializing.
D, [2017-02-16T00:06:03.651314 #39047] DEBUG -- : MONGODB | Server localhost:27017 initializing.
D, [2017-02-16T00:06:03.654477 #39047] DEBUG -- : MONGODB | Topology type 'unknown' changed to type 'single'.
D, [2017-02-16T00:06:03.654581 #39047] DEBUG -- : MONGODB | Server description for localhost:27017 changed from 'unknown' to 'standalone'.
D, [2017-02-16T00:06:03.654674 #39047] DEBUG -- : MONGODB | There was a change in the members of the 'single' topology.
 => #<Mongo::Client:0x70333621287660 cluster=localhost:27017>
2.3.3 :003 > db = db.use('test')
 => #<Mongo::Client:0x70333622110940 cluster=localhost:27017>
2.3.3 :004 > db.database.name
 => "test"
2.3.3 :005 > db.database.collection_names
D, [2017-02-16T11:11:07.299786 #39047] DEBUG -- : MONGODB | localhost:27017 | test.listCollections | STARTED | {"listCollections"=>1, "cursor"=>{}, "filter"=>{:name=>{"$not"=>/system\.|\$/}}}
D, [2017-02-16T11:11:07.326259 #39047] DEBUG -- : MONGODB | localhost:27017 | test.listCollections | SUCCEEDED | 0.025663000000000002s
 => ["zips"]
2.3.3 :006 > db[:zips].find.first
D, [2017-02-16T11:12:51.044213 #39047] DEBUG -- : MONGODB | localhost:27017 | test.find | STARTED | {"find"=>"zips", "filter"=>{}}
D, [2017-02-16T11:12:51.059517 #39047] DEBUG -- : MONGODB | localhost:27017 | test.find | SUCCEEDED | 0.015213s
 => {"_id"=>"01001", "city"=>"AGAWAM", "loc"=>[-72.622739, 42.070206], "pop"=>15338, "state"=>"MA"}

Win 系统下可以用 system('cls') 命令来清空 irb shell
Mac OS X 和 Linux 系统可以用 Ctrl + L 来清空屏幕

精简输出

1
2
3
4
2.3.3 :008 > Mongo::Logger.logger.level = ::Logger::INFO
 => 1
2.3.3 :009 > db[:zips].find.first
 => {"_id"=>"01001", "city"=>"AGAWAM", "loc"=>[-72.622739, 42.070206], "pop"=>15338, "state"=>"MA"}

Create and Read

介绍 CRUD 增查改删操作的前两步操作

"C"reate

  • Select a collection on the client and call insert_one or insert_many
  • insert_one: insert one document to collection
  • insert_many: insert multiple documents to the collection

insert_one

1
db[:zips].insert_one(:_id => "100",:city => "city01", :loc => [ -76.05922700000001, 39.564894], :pop => 4678,:state => "MD")

用 find 和 count 来搜索数据

1
db[:zips].find(:city => "city01").count

插入一项数据，并且测试该项数据的存在

1
2
3
4
5
6
2.3.3 :010 > db[:zips].insert_one(:_id => "100",:city => "city01", :loc => [ -76.05922700000001, 39.564894], :pop => 4678,:state => "MD")
 => #<Mongo::Operation::Result:70333617635280 documents=[{"n"=>1, "ok"=>1.0}]>
2.3.3 :011 > db[:zips].find(:city => "city01").count
 => 1
2.3.3 :012 > db[:zips].find(:city => "city01").to_a
 => [{"_id"=>"100", "city"=>"city01", "loc"=>[-76.059227, 39.564894], "pop"=>4678, "state"=>"MD"}]

insert_many

1
2
3
4
5
6
7
8
db[:zips].insert_many([
{ :_id => "200", :city => "city02",
  :loc => [ -74.05922700000001, 37.564894 ], 
  :pop => 2000, :state => "CA" },
{ :_id => "201", :city => "city03", 
  :loc => [ -75.05922700000001, 35.564894 ],
  :pop => 3000, :state => "CA" }
])

同时插入多项数据

1
2
3
4
5
6
7
8
9
10
11
12
13
2.3.3 :013 > db[:zips].insert_many([
2.3.3 :014 >       { :_id => "200", :city => "city02",
2.3.3 :015 >           :loc => [ -74.05922700000001, 37.564894 ],
2.3.3 :016 >           :pop => 2000, :state => "CA" },
2.3.3 :017 >       { :_id => "201", :city => "city03",
2.3.3 :018 >           :loc => [ -75.05922700000001, 35.564894 ],
2.3.3 :019 >           :pop => 3000, :state => "CA" }
2.3.3 :020?>     ])
 => #<Mongo::BulkWrite::Result:0x007fefa58136d8 @results={"n_inserted"=>2, "n"=>2, "inserted_ids"=>["200", "201"]}>
2.3.3 :021 > db[:zips].find("city" => "city02").to_a
 => [{"_id"=>"200", "city"=>"city02", "loc"=>[-74.059227, 37.564894], "pop"=>2000, "state"=>"CA"}]
2.3.3 :022 > db[:zips].find("city" => "city03").to_a
 => [{"_id"=>"201", "city"=>"city03", "loc"=>[-75.059227, 35.564894], "pop"=>3000, "state"=>"CA"}]

"R"ead

  • find command
  • find – returns a cursor object – allows us to iterate over the selected document(s)
  • Can be used with query criteria
1
2
3
4
5
6
7
8
9
# basic find
db[:zips].find(:city => "BALTIMORE")
# find first
db[:zips].find.first
db[:zips].find(:state => "MD").first
# find with double conditions and count them
db[:zips].find(:state => "NY", :city => "GERMANTOWN").count
# find distinct
db[:zips].find.distinct(:state)

使用 pp (pretty-printing) 来美化命令行的输出，并且找到符合条件的第一项

1
2
3
4
5
6
7
8
9
2.3.3 :035 > require 'pp'
 => true
2.3.3 :036 > pp db[:zips].find(:state => "NY", :city => "GERMANTOWN").first
{"_id"=>"12526",
 "city"=>"GERMANTOWN",
 "loc"=>[-73.862451, 42.1219],
 "pop"=>4061,
 "state"=>"NY"}
 => {"_id"=>"12526", "city"=>"GERMANTOWN", "loc"=>[-73.862451, 42.1219], "pop"=>4061, "state"=>"NY"}

Cursor Iterations

print all

1
db[:zips].find().each { |r| puts r }

pretty printing

1
2
require 'pp'
db[:zips].find().each { |r| pp r }

Projection

  • Limits the fields to return from all matching documents
  • We can specify inclusion or exclusion.
  • _id is automatically included by default.
  • true or 1: inclusive
  • false or 0: exclusive

限制返回项的输出，例如只输出 state 属性，_id 是默认输出的，我们也可以取消输出 _id 项。

1
2
3
4
2.3.3 :040 > db[:zips].find({:state => "MD"}).projection(state:true).first
 => {"_id"=>"20331", "state"=>"MD"}
2.3.3 :041 > db[:zips].find({:state => "MD"}).projection(state:true, _id:false).first
 => {"state"=>"MD"}

Paging

  • Paging is accomplished with skip and limit
  • skip(n) - tells mongodb that it should skip ‘n’ results
  • limit(n) - instructs mongodb that it should limit the result length to ‘n’ results

limit

限制搜索只有三项输出

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
2.3.3 :044 > db[:zips].find.limit(3).each{ |r| pp r}
{"_id"=>"01001",
 "city"=>"AGAWAM",
 "loc"=>[-72.622739, 42.070206],
 "pop"=>15338,
 "state"=>"MA"}
{"_id"=>"01002",
 "city"=>"CUSHMAN",
 "loc"=>[-72.51565, 42.377017],
 "pop"=>36963,
 "state"=>"MA"}
{"_id"=>"01005",
 "city"=>"BARRE",
 "loc"=>[-72.108354, 42.409698],
 "pop"=>4546,
 "state"=>"MA"}
 => #<Enumerator: #<Mongo::Cursor:0x70333637935980 @view=#<Mongo::Collection::View:0x70333616708020 namespace='test.zips' @filter={} @options={"limit"=>3}>>:each>

skip

跳过前三项，显示后三项

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
2.3.3 :045 > db[:zips].find.skip(3).limit(3).each { |r| pp r}
{"_id"=>"01007",
 "city"=>"BELCHERTOWN",
 "loc"=>[-72.410953, 42.275103],
 "pop"=>10579,
 "state"=>"MA"}
{"_id"=>"01008",
 "city"=>"BLANDFORD",
 "loc"=>[-72.936114, 42.182949],
 "pop"=>1240,
 "state"=>"MA"}
{"_id"=>"01010",
 "city"=>"BRIMFIELD",
 "loc"=>[-72.188455, 42.116543],
 "pop"=>3706,
 "state"=>"MA"}
 => #<Enumerator: #<Mongo::Cursor:0x70333639364960 @view=#<Mongo::Collection::View:0x70333639398700 namespace='test.zips' @filter={} @options={"skip"=>3, "limit"=>3}>>:each>

Sort

sort - Specifies the order in which the query returns matching documents.

{ field: value }

1 for Ascending, -1 for Descending.

搜索后以城市名升序输出，若改为{:city => -1 }则为逆序输出。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
2.3.3 :046 > db[:zips].find.limit(3).sort({:city => 1 }).each { |r| pp r}
{"_id"=>"42601",
 "city"=>"AARON",
 "loc"=>[-85.199114, 36.812827],
 "pop"=>270,
 "state"=>"KY"}
{"_id"=>"16820",
 "city"=>"AARONSBURG",
 "loc"=>[-77.387977, 40.876944],
 "pop"=>100,
 "state"=>"PA"}
{"_id"=>"31794",
 "city"=>"ABAC",
 "loc"=>[-83.498867, 31.451722],
 "pop"=>27906,
 "state"=>"GA"}
 => #<Enumerator: #<Mongo::Cursor:0x70333639793460 @view=#<Mongo::Collection::View:0x70333626982300 namespace='test.zips' @filter={} @options={"limit"=>3, "sort"=>{"city"=>1}}>>:each>

Advanced Find

Find By Criteria

  • ‘lt’ & ‘gt’
  • Evaluations
  • Regex
  • Exists
  • Not
  • Type

lt and gt

lt -> less than
gt -> great than

找到城市名比「P」小的，且比「B」大的三项

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
2.3.3 :049 > db[:zips].find(:city => {:$lt => 'P', :$gt => 'B'}).limit(3).to_a.each { |r| pp r};nil
{"_id"=>"01002",
 "city"=>"CUSHMAN",
 "loc"=>[-72.51565, 42.377017],
 "pop"=>36963,
 "state"=>"MA"}
{"_id"=>"01005",
 "city"=>"BARRE",
 "loc"=>[-72.108354, 42.409698],
 "pop"=>4546,
 "state"=>"MA"}
{"_id"=>"01007",
 "city"=>"BELCHERTOWN",
 "loc"=>[-72.410953, 42.275103],
 "pop"=>10579,
 "state"=>"MA"}
=> nil

小 Tips：
我们已经用 pp 来格式化输出了，可以在语句结尾加;nil来精简额外的输出，如上所示。

Regex

Regex – supports regular expression capabilities for pattern matching strings in queries.

用正则表达式匹配城市名含有 X 的项

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
2.3.3 :052 > db[:zips].find(:city => {:$regex => 'X'}).limit(3).each {|r| pp r};nil
{"_id"=>"01240",
 "city"=>"LENOX",
 "loc"=>[-73.271322, 42.364241],
 "pop"=>5001,
 "state"=>"MA"}
{"_id"=>"01537",
 "city"=>"NORTH OXFORD",
 "loc"=>[-71.885953, 42.16549],
 "pop"=>3031,
 "state"=>"MA"}
{"_id"=>"01540",
 "city"=>"OXFORD",
 "loc"=>[-71.868677, 42.11285],
 "pop"=>9557,
 "state"=>"MA"}
 => nil

X& :Displays cities ending with X
^X :Displays cities starting with X
^[A- E] :Displays cities that match the regex (A to E)

$exist

Will check to see of the document exists when the boolean is true

mongo 中的 documents 可能会没有一些 values，我们可以用$exist来找出存在相关 values 的项。

找出 :city 属性不为空的三项

1
2
3
4
5
2.3.3 :053 > db[:zips].find(:city => {:$exists => true}).projection({:_id => false}).limit(3).to_a.each {|r| pp r}
{"city"=>"AGAWAM", "loc"=>[-72.622739, 42.070206], "pop"=>15338, "state"=>"MA"}
{"city"=>"CUSHMAN", "loc"=>[-72.51565, 42.377017], "pop"=>36963, "state"=>"MA"}
{"city"=>"BARRE", "loc"=>[-72.108354, 42.409698], "pop"=>4546, "state"=>"MA"}
 => [{"city"=>"AGAWAM", "loc"=>[-72.622739, 42.070206], "pop"=>15338, "state"=>"MA"}, {"city"=>"CUSHMAN", "loc"=>[-72.51565, 42.377017], "pop"=>36963, "state"=>"MA"}, {"city"=>"BARRE", "loc"=>[-72.108354, 42.409698], "pop"=>4546, "state"=>"MA"}]

$not

$not performs a logical NOT operation
Selects the documents that do not match the

找到 :pop 属性不大于9500的项

1
2
3
4
5
6
7
8
9
10
11
2.3.3 :012 > db[:zips].find(:pop =>{'$not' => {'$gt' => 9500}}).projection({_id:false}).limit(3).to_a.each {|r| pp r};nil
{"city"=>"BARRE", "loc"=>[-72.108354, 42.409698], "pop"=>4546, "state"=>"MA"}
{"city"=>"BLANDFORD",
 "loc"=>[-72.936114, 42.182949],
 "pop"=>1240,
 "state"=>"MA"}
{"city"=>"BRIMFIELD",
 "loc"=>[-72.188455, 42.116543],
 "pop"=>3706,
 "state"=>"MA"}
 => nil

$type

$type - selects the documents where the value of the field is an instance of the specified numeric BSON type.

简而言之，$type的作用就是验证相关属性的类型。这在我们不知道数据类型的时候很好用，我们可以在 BSON Types 页面中查看各数字代表着什么，例如 1 代表 Double 类型，2 代表 String 类型。

在下面示例中，:state 属性应是 String 类型，所以 :&type => 2 会有结果。:&type => 1没有结果，是因为 :state 不是 Double 类型。

1
2
3
4
2.3.3 :014 > db[:zips].find({:state=> {:$type => 2}}).first
 => {"_id"=>"01001", "city"=>"AGAWAM", "loc"=>[-72.622739, 42.070206], "pop"=>15338, "state"=>"MA"}
2.3.3 :015 > db[:zips].find({:state=> {:$type => 1}}).first
 => nil

Replace, Update and Delete

介绍 Replace 和 CRUD 的后两项操作

  • replace_one
  • update_one
  • update_many
  • delete_one
  • delete_many
  • upsert

Replace

replace_one

replace_one – Replace a document in the collection according to the specified parameters.

替换:_id => "101"项的所有信息

1
2
3
4
5
6
2.3.3 :017 > db[:zips].insert_one(:_id => "101", :city => "citytemp", :loc => [ -76.05922700000001, 39.564894 ], :pop => 4678, :state => "MD" )
 => #<Mongo::Operation::Result:70126374694180 documents=[{"n"=>1, "ok"=>1.0}]>
2.3.3 :018 > db[:zips].find(:_id =>"101").replace_one(:_id => "101", :city => "city02", :loc => [ -78.22, 36.22 ], :pop => 2000, :state => "MD" )
 => #<Mongo::Operation::Result:70126384942080 documents=[{"n"=>1, "nModified"=>1, "ok"=>1.0}]>
2.3.3 :019 > db[:zips].find(:_id => "101").to_a
 => [{"_id"=>"101", "city"=>"city02", "loc"=>[-78.22, 36.22], "pop"=>2000, "state"=>"MD"}]

"U"pdate

update_one

update_one – Update a single document in the collection according to the specified arguments.

只更新单项中的属性，例如改城市名或同时更改多个属性

1
2
3
4
5
6
7
8
2.3.3 :022 > db[:zips].find(:_id => "101").update_one(:$set => {:city => "name2"})
 => #<Mongo::Operation::Result:70126374531300 documents=[{"n"=>1, "nModified"=>1, "ok"=>1.0}]>
2.3.3 :023 > db[:zips].find(:_id => "101").to_a
 => [{"_id"=>"101", "city"=>"name2", "loc"=>[-78.22, 36.22], "pop"=>2000, "state"=>"MD"}]
2.3.3 :024 > db[:zips].find(:_id => "101").update_one(:$set => {:city => "name3", :loc => [ 11.11, 11.11 ]})
 => #<Mongo::Operation::Result:70126373842240 documents=[{"n"=>1, "nModified"=>1, "ok"=>1.0}]>
2.3.3 :025 > db[:zips].find(:_id => "101").to_a
 => [{"_id"=>"101", "city"=>"name3", "loc"=>[11.11, 11.11], "pop"=>2000, "state"=>"XX"}]

update_many

update_many – Updates single or multiple documents in the collection according to the specified arguments.

更新多项属性，例如把所有州名为MD的项中的州名更改为XX

1
2
3
4
5
6
7
8
2.3.3 :026 > db[:zips].find(:state => 'MD').count
 => 422
2.3.3 :027 > db[:zips].find(:state => 'MD').update_many(:$set => {:state => 'XX'})
 => #<Mongo::Operation::Result:70126374300980 documents=[{"n"=>422, "nModified"=>422, "ok"=>1.0}]>
2.3.3 :028 > db[:zips].find(:state => 'MD').count
 => 0
2.3.3 :029 > db[:zips].find(:state => 'XX').count
 => 422

"D"elete

delete_one

delete_one – will delete a single document in the collection according to the specified arguments.

删除之前添加的城市名为 name3 的项

1
2
3
4
5
6
2.3.3 :005 > db[:zips].find(:city => 'name3').count
 => 1
2.3.3 :006 > db[:zips].find(:city => 'name3').delete_one()
 => #<Mongo::Operation::Result:70293222869840 documents=[{"n"=>1, "ok"=>1.0}]>
2.3.3 :007 > db[:zips].find(:city => 'name3').count
 => 0

delete_many

delete_many – deletes single or multiple documents in the collection according to the specified arguments.

删除所有州名为XX的项

1
2
3
4
5
6
2.3.3 :009 > db[:zips].find(:state => 'XX' ).count
 => 421
2.3.3 :010 > db[:zips].find(:state => 'XX' ).delete_many()
 => #<Mongo::Operation::Result:70293222986380 documents=[{"n"=>421, "ok"=>1.0}]>
2.3.3 :011 > db[:zips].find(:state => 'XX' ).count
 => 0

upsert

If upsert is true and no document matches the query criteria, update() inserts a single document.

如果把 upsert （更新插入）设为 true，即使没有找到相关的项（条件不满足），也会执行 update_one来创建一个项

1
2
3
4
5
6
7
8
9
10
11
12
2.3.3 :014 > db[:zips].find(:city => "ODENVILLE1").count
 => 0
2.3.3 :015 > db[:zips].find(:city => "ODENVILLE2").count
 => 0
2.3.3 :016 > db[:zips].find(:city =>"ODENVILLE1").update_one({:$set => {:city => "ODENVILLE2"}}, :upsert => true)
 => #<Mongo::Operation::Result:70293217700720 documents=[{"n"=>1, "nModified"=>0, "upserted"=>[{"index"=>0, "_id"=>BSON::ObjectId('58a5746b62b11bdc607226a8')}], "ok"=>1.0}]>
2.3.3 :017 > db[:zips].find(:city => "ODENVILLE1").count
 => 0
2.3.3 :018 > db[:zips].find(:city => "ODENVILLE2").count
 => 1
2.3.3 :019 > db[:zips].find(:city => "ODENVILLE2").to_a
 => [{"_id"=>BSON::ObjectId('58a5746b62b11bdc607226a8'), "city"=>"ODENVILLE2"}]
]]> MongoDB Ruby iOS 动画笔记 /2017/01/22/ios-animations-note/ 大坑未填完，发布下博文降低罪恶感…

人生的意义就是不断地挖坑，并不断地去填补。
——猫冬

本文为《iOS Animations by Tutorials》笔记上篇，代码用 swift 3 编写。

动画属性

简单的动画

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
@IBOutlet var heading: UILabel!

override func viewDidAppear(_ animated: Bool) {
  super.viewDidAppear(animated)
      UIView.animate(withDuration: 0.5, delay: 0.3, options: [], animations: {
    // 动画后位置 
    self.heading.center.x += self.view.bounds.width
  }, completion: nil)
}

override func viewWillAppear(_ animated: Bool) {
  super.viewWillAppear(animated)
  // 动画前位置
  heading.center.x -= view.bounds.width
}

上面这段代码的作用是把在屏幕左边的标题通过动画移动到相应位置。

这里使用了动画方法：animate(withDuration:delay:usingSpringWithDamping:initialSpringVelocity:options:animations:completion:)

  • withDuration: 动画持续时间。
  • delay: 动画开始前的延迟时间，值为0时动画效果立刻显示。
  • options: 表现动画的一系列方式，如淡入淡出等，可以直接用[]表示无动画选项。
  • animations: 代码块中提供你的动画效果，注意代码块中无参数和返回值。
  • completion: 动画执行后要干什么。

位置和大小

我们可以通过改变一个 view 的位置和 frame 来实现放大、收缩或者移动效果。

  • frame: 该 view 在父view坐标系统中的位置和大小。
  • bounds: 该 view 在本地坐标系统中的位置和大小。
  • center: 想要移动 view 到一个新位置时改变该属性。

关于frame 和 bounds 的更详细的区别可以参考ios view的frame和bounds之区别（位置和大小）。

外观

我们可以通过改变背景色或透明度来改变 view 的外观。

  • backgroundColor: 改变背景颜色
  • alpha: 改变该属性来创造淡入淡出效果

形变

  • transform: 在动画块中改变该属性可以去使 view 旋转、改变 view 大小或位置。

动画选项

options 能让你知道 UIKit 是怎么创建我们的动画的，下面是一系列声明在 UIViewAnimationOptions 集中的动画选项，可以以不同形式来结合，并在我们的动画中使用。

重复

  • .repeat: 这选项能让你的动画循环起来。
  • .autoreverse: 这选项只能和 .repeat 放在一起使用，作用是重复播放动画，然后逆向播放动画。

repeat and .autoreverse

1
2
3
4
UIView.animate(withDuration: 0.5, delay: 0.4,
               options: [.repeat, .autoreverse], animations: {
  self.password.center.x += self.view.bounds.width
}, completion: nil)

动画缓动

就像火车出站的时候会加速，到站时会减速一样，我们也可以给动画加上缓入缓出效果。

  • .curveLinear: 没有加速也没有减速。
  • .curveEaseIn: 在动画开始时加速。
  • .curveEaseOut: 在动画结束时减速。
  • .curveEaseInOut: 动画开始时加速，结束时减速。

.curveEaseInOut

弹性

像弹簧一样，动画也能实现这种来回弹动，最终停止在 point B 的效果。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
override func viewWillAppear(_ animated: Bool) {
  super.viewWillAppear(animated)
 
  loginButton.center.y += 30.0
  loginButton.alpha = 0.0
}

override func viewDidAppear(_ animated: Bool) {
  super.viewDidAppear(animated)

  UIView.animate(withDuration: 0.5, delay: 0.5, usingSpringWithDamping: 0.5, 
    initialSpringVelocity: 0.0, options: [], animations: { 
    self.loginButton.center.y -= 30.0
    self.loginButton.alpha = 1.0
  }, completion: nil)
}

spring

这里用了新的动画方法：animate(withDuration:delay:usingSpringWithDamping:initialSpringVelocity:options:animations:completion:)

  • usingSpringWithDamping: 控制阻尼系数，接受值在0.0和1.0之间，靠近0.0能创建一个有弹性的动画，靠近1.0能创建一个僵硬的效果。
  • initialSpringVelocity: 控制动画的速率，表示在一秒中动画所走的距离占总距离的比率。例如，动画中的距离为200 points，我们想达到100 pt/s的速度，则用0.5做值。数值越大移动越快。

过渡

当你想通过动画来增加一个 view 或移除一个 view 的时候，你仍然可以使用前面提到的方法，这里将会告诉你如何使用过渡（transitions）来动画显示 view 中一系列的改变。

Transitions are predefined animations you can apply to views. These predefined animations don’t attempt to interpolate between the start and end states of your view. Instead, you’ll design the animations so that the various changes in state appear natural.

增加一个 view

和前面一样，我们也是调用类似的方法，不同的是这次将会选择一个预先定义好的过渡效果并在 animation container view 中显示动画。

过渡通过 container view 来显示，在动画播放的时候其他新的 view 将会作为子view加入其中。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
var animationContainerView: UIView!

override func viewDidLoad() { 
  //创建 animation container 
  animationContainerView = UIView(frame: view.bounds)
  animationContainerView.frame = view.bounds
  view.addSubview(animationContainerView!)
}

override func viewDidAppear(_ animated: Bool) { 
  super.viewDidAppear(animated)
  
  // 创建新的 view 
  let newView = UIImageView(image: UIImage(named: "banner")!)
  newView.center = animationContainerView.center
  
  // 通过过渡把新的 view 加入其中
  UIView.transition(with: animationContainerView, duration: 0.33,
                    options: [.curveEaseOut, .transitionFlipFromBottom],
                    animations: {
                      self.animationContainerView.addSubview(newView)
  }, completion: nil )
}

上面的代码可以看到，过渡的方法比之前看过的方法多了一个参数「view」，就是指要把过渡效果加入其中的 container view。另外未见过的还有.transitionFlipFromBottom，这也是定义好的过渡选项，显示的是一个底部翻转的效果，下面还列出所有的过渡动画选项。

1
2
3
4
5
6
7
.transitionFlipFromLeft 
.transitionFlipFromRight 
.transitionCurlUp 
.transitionCurlDown 
.transitionCrossDissolve 
.transitionFlipFromTop 
.transitionFlipFromBottom

移除 view

代码和增加 view 类似，不过这次调用的是removeFromSuperview()方法。

1
2
3
4
5
UIView.transition(with: animationContainerView, duration: 0.33,
                  options: [.curveEaseOut, .transitionFlipFromBottom],
                  animations: {
                    self.newView.removeFromSuperview()
}, completion: nil )

隐藏/显示 view

到目前，我们只知道过渡效果要区分 view 的层次，这也是为什么我们需要一个 container view 的原因。对于隐藏或显示一个 view 的时候，我们可以通过用要隐藏或显示的 view 来当做动画容器（animation container）。

1
2
3
4
5
6
// 通过过渡隐藏 newView，
UIView.transition(with: self.newView, duration: 0.33,
                  options: [.curveEaseOut, .transitionFlipFromBottom],
                  animations: {
                    self.newView.isHidden = true
}, completion: nil )

用一个 view 来取代另一个 view

1
2
3
// 从 oldView 变为 newView
UIView.transition(from: oldView, to: newView, duration: 0.33, 
  options: .transitionFlipFromTop, completion: nil)

更酷的动画

  1. Crossfade animation: 淡入淡出动画，把一张图片与另一张图片混合的动画效果。
  2. Cube transition animation: 立方体过渡动画，创建伪 3D 的过渡效果。
  3. Fade and bounce transition: 淡入淡出和反弹过渡，与简单动画的结合有一些不同。

Crossfade animation

如果需要把一张图片直接变成另外一张图片，之前的淡入淡出就不太好用了，因为能看到中间的淡入淡出效果。

楼主的坑已经不想填了，看到这的朋友可以参考：
iOS 核心动画高级技巧 ：iOS Core Animation: Advanced Techniques 的译本，由 OC 编写

]]> iOS基础 Swift iOS 动画 Core Data 笔记[上篇] /2017/01/16/core-data-note-1/

Core Data 应该被当成一个对象图管理系统来正确使用，得益于其内建的缓存和对象管理机制，它在很多方面比其他数据库实际上反而更快。抽象级别更高的 API 可以让你专注于优化 APP 里关键部分的性能，而不是从头一开始来实现如何持久化。

《Core Data》ObjC中国

本文为《Core Data by Tutorials》笔记上篇，代码用 swift 3 编写。等这系列写完会根据 ObjC 的《Core Data》 补充笔记，另外也推荐斯坦福课程 Developing iOS 9 Apps with Swift 中的第十课《Core Data》，用来大致地学习下 Core Data 重要的知识点，本文也有部分笔记参考了这课程。

下面的代码只给其中关键部分，请指教。由于笔记是给自己看的，部分地方可能会跳跃性比较大。

入门

Core Data 是 Apple 为 iOS、OS X、watchOS 和 tvOS 而设计的对象图管理(object graph management)和数据持久化框架。

  • entity 是 Core Data 中的类定义，也称为「实体」。例如一个雇员或一个公司。在一个关系型数据库中，一个 entity 类似于一张表。
  • attribute 是跟一个特定 entity 相关的一系列信息，例如一个 Employee entity 可以有属性如：雇员的名字，地址和薪水。在一个数据库中，一个 attribute 类似于一个表中特定的 field。
  • relationship 是很多 entities 之间的连接，也称为「关系」。在 Core Data 中，两个 entities 之间的关系叫做一对一关系，一个和多个 entities 之间则称为一对多关系。例如，一个管理者和一组雇员可以有一个一对多关系，然而一个单独的雇员与他的上司会有一个一对一关系。

保存数据

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
func save(name: String) {
  guard let appDelegate = UIApplication.shared.delegate as? AppDelegate else {
    return
  }
  
  // 1
  let managedContext = appDelegate.persistentContainer.viewContext
  
  // 2
  let entity = NSEntityDescription.entity(forEntityName: "Person", in: managedContext)!
  
  let person = NSManagedObject(entity: entity, insertInto: managedContext)
  
  // 3
  person.setValue(name, forKey: "name")
  
  // 4
  do {
    try managedContext.save()
    people.append(person)
  } catch let error as NSError {
    print("Could not save. \(error), \(error.userInfo)")
  }
}

  1. 从 Core Data 中保存或恢复数据之前，都要用到NSManagedObjectContext。managed object context 就像一个内存「暂存器」用来处理 managed objects。

    把一个新的 managed object 加进一个 managed object context，如果满意这些修改，我们可以直接在 managed object context 中「commit」 这些修改然后保存起来。

  2. 创建一个新的 managedObject 然后保存到 context 中。

  3. 保存键值对。

  4. commit 改动。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// Save test bow tie
  let bowtie = NSEntityDescription.insertNewObject(forEntityName: "Bowtie", into: self.persistentContainer.viewContext) as! Bowtie
  bowtie.name = "My bow tie"
  bowtie.lastWorn = NSDate()
  
  // Retrieve test bow tie
  do {
    let request = NSFetchRequest<Bowtie>(entityName: "Bowtie")
    let ties = try self.persistentContainer.viewContext.fetch(request)
    let sample = ties.first
    print("Name: \(sample?.name), Worn: \(sample?.lastWorn)")
  } catch let error as NSError {
    print("Fetching error: \(error), \(error.userInfo)")
  }

提取数据

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// 在 viewDidLoad() 之前执行
override func viewWillAppear(_ animated: Bool) {
  super.viewWillAppear(animated)
  
  // 1 从 application delegate 中获取它 persistent container 的引用并得到 NSManagedObjectContext
  guard let appDelegate = UIApplication.shared.delegate as? AppDelegate else {
    return
  }
  
  let managedContext = appDelegate.persistentContainer.viewContext
  
  // 2 FetchRequest 可以有不同方式去获取数据
  let fetchRequest = NSFetchRequest<NSManagedObject>(entityName: "Person")
  
  // 3 获取数据
  do {
    people = try managedContext.fetch(fetchRequest)
  } catch let error as NSError {
    print("Could not fetch. \(error), \(error.userInfo)")
  }
}

NSManagedObject 子类

之前通过获取应用 delegate 的 managed object context 来获得访问权限，现在可以把 managed object context 当做一个属性在类和类之间传送。
这样 ViewController 可以不需要知道它来自哪就使用它，链式传递 context，这样能使代码变得简洁。

传递 viewContext

AppDelegate.swift

1
2
3
4
5
6
7
8
9
10
11
var window: UIWindow?

func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {
  guard let vc = window?.rootViewController as? ViewController else {
    return true
  }
  
  vc.managedContext = persistentContainer.viewContext
  
  return true
}

搜索

ViewController.swift

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
var managedContext: NSManagedObjectContext!

// MARK: - View Life Cycle
override func viewDidLoad() {
  super.viewDidLoad()
  
  // 1 导入 plist 数据
  insertSampleData()
  
  // 2 搜索条件
  let request = NSFetchRequest<Bowtie>(entityName: "Bowtie")
  let firstTitle = segmentedControl.titleForSegment(at: 0)!
  request.predicate = NSPredicate(format: "searchKey == %@", firstTitle)
  
  do {
    // 3 获取数据 [Bowtie]
    let results = try managedContext.fetch(request)
    
    // 4 展示数据
    populate(bowtie: results.first!)
  } catch let error as NSError {
    print("Counld not fetch \(error), \(error.userInfo)")
  }
}

校验数据

Core Data Stack

栈(Stack)由四个 Core Data 类组成：

  • NSManagedObjectModel
  • NSPersistentStore
  • NSPersistentStoreCoordinator
  • NSManagedObjectContext

清楚栈的工作是很有必要的，例如要从旧的数据库迁移数据。

下面是 objc 的《Core Data》中的一幅图，定义的有些不一样：

The persistent store

  1. NSQLiteStoreType 依靠一个 SQLite 数据库，这是仅有的 non-atomic 的 Core Data 支持的，轻量级、有效率的储存。通常 Xcode 的 Core Data 默认模板就是用这个。
  2. NSXMLStoreType 依靠一个 XML 文件，这让它有很好的可读性。store type 是 atomic 的，所以他可以有大储存 footprint。只在 OS X 上可用。
  3. NSBinaryStoreType 依靠一个二进制文件，像 NSXMLStoreType ，它的 store type 也是是 atomic 的，所以二进制文件必须被读取进内存，之后才能使用它。你将很少看到这类型的 persistent store。
  4. NSInMemoryStoreType 是 in-memory persistent store type。某种程度上讲，这不是真的可持久的，终止应用或关掉手机，存储在内存中的数据就会消失，尽管这像是跟 Core Data 的目的背道而驰，但这 in-memory persistent stores 对单元测试和某些缓存有帮助。

The persistent store coordinator

NSPersistentStoreCoordinator 是 managed object model 和 persistent store 的桥梁。它理解 NSManagedObjectModel，也知道怎么去从 NSPersistentStore 传消息和获取消息。

NSPersistentStoreCoordinator 同时隐藏了实现 persistent store 或 stores 配置的细节，有两个原因：

  1. NSManagedObjectContext 没必要知道怎么去保存到一个 SQLite 数据库、XML 文件或者一个定制增量存储(custom incremental store)。
  2. 如果你有多个 persistent stores，那么 persistent store coordinator 会提供一个统一的接口去管理 context。至于 context 的管理，它经常和一个单独的、聚合的 persistent store 交互。

The managed object context

日常使用中，你会经常使用 NSManagedObjectContext，可能只有在用 Core Data 使用一些更高级的功能时才会看到其他三个部分。

理解 context 如何工作也是很重要的：

  • 一个 context 是一个 in-memory 暂存器用来处理你的 managed object。
  • 你会用一个 managed object context 来做所有关于 Core Data objects 的事情。
  • 只当你在 context 上调用save()，所有的改动才会影响到储存卡中的数据。

更重要的还有：

  • context 管理着创建 objects 或获得 objects 的生命周期。这生命周期的管理包含很强大的功能如挑错、逆关系处理(inverse relationship handling) 和校验数据。
  • 一个 managed object 不能离开相关的 context 而存在。实际上，一个 managed object 和它的 context 是很紧密联系在一起的，每个 managed object 都会有一个它的 context 的引用，例如：
    let managedContext = employee.managedObjectContext
  • context 是区域性的。一旦一个 managed object 关联上一个特定的 context，它将会一直在它生命周期中关联同样的 context。
  • 一个应用可以有多于一个 context。然而一个 context 是暂存在内存中的，你可以同时取出同样的 Core Data object 到两个不同的 context。
  • context 不是线程安全的，这同样适用于一个 managed object。你只能在它们被创建的相同的线程中使用 context 和 managed objects 。

The persistent store container

在 iOS 10 中，NSPersistentContainer 是一个新的类，它能管理所有四个 Core Data stack 类——the managed model, the store coordinator, the persistent store 和 managed context。

实例：遛狗

Dog Walk.xcdatamodeld

其中狗对遛狗这个行为是一对多的关系，而遛狗行为对狗而言是一对一的关系，如下图：

新建一个Core Data Stack
CoreDataStack.swift

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
import Foundation
import CoreData

class CoreDataStack {
  private let modelName: String
  
  init(modelName: String) {
    self.modelName = modelName
  }
  
  // 只有这个不加 private 是因为 managed context 是 stack 的唯一的入口
  lazy var managedContext: NSManagedObjectContext = {
    return self.storeContainer.viewContext
  }()
  
  private lazy var storeContainer: NSPersistentContainer = {
    // initialization
    let container = NSPersistentContainer(name: self.modelName)
    // 读取 persistent stores
    container.loadPersistentStores { (storeDescription, error) in
      if let error = error as NSError? {
        print("Unresolved error \(error), \(error.userInfo)")
      }
    }
    return container
  }()
 
  func saveContext () {
    guard managedContext.hasChanges else { return }
    do {
      try managedContext.save()
    } catch let error as NSError {
      print("Unresolved error \(error), \(error.userInfo)")
    }
  }
}

AppDelegate.swift

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
import UIKit
import CoreData

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate {

  var window: UIWindow?
  lazy var coreDataStack = CoreDataStack(modelName: "Dog Walk")
  
  func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {
    guard let navController = window?.rootViewController as? UINavigationController,
      let viewController = navController.topViewController as? ViewController else {
        return true
    }
    viewController.managedContext = coreDataStack.managedContext
    return true
  }
  
  // MARK: 进入后台前或终止前，应用会用CoreDataStack.swift 中的 saveContext() 保存数据变更
  func applicationDidEnterBackground(_ application: UIApplication) {
    coreDataStack.saveContext()
  }
  
  func applicationWillTerminate(_ application: UIApplication) {
    coreDataStack.saveContext()
  }
}

ViewController.swift

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
import UIKit
import CoreData

class ViewController: UIViewController {

  // MARK: - Properties
  lazy var dateFormatter: DateFormatter = {
    let formatter = DateFormatter()
    formatter.dateStyle = .short
    formatter.timeStyle = .medium
    return formatter
  }()
  var currentDog: Dog?
  var managedContext: NSManagedObjectContext!

  // MARK: - IBOutlets
  @IBOutlet var tableView: UITableView!

  // MARK: - View Life Cycle
  override func viewDidLoad() {
    super.viewDidLoad()

    tableView.register(UITableViewCell.self, forCellReuseIdentifier: "Cell")
    
    let dogName = "Fido"
    let dogFetch: NSFetchRequest<Dog> = Dog.fetchRequest()
    dogFetch.predicate = NSPredicate(format: "%K == %@", #keyPath(Dog.name), dogName)
    
    do {
      let results = try managedContext.fetch(dogFetch)
      if results.count > 0 {
        // Fido found, use Fido
        currentDog = results.first
      } else {
        // Fido not found, create Fido
        currentDog = Dog(context: managedContext)
        currentDog?.name = dogName
        try managedContext.save()
      }
    } catch let error as NSError {
      print("Fetch error: \(error) description: \(error.userInfo)")
    }
  }
}

// MARK: - IBActions
extension ViewController {

  @IBAction func add(_ sender: UIBarButtonItem) {
    let walk = Walk(context: managedContext)
    walk.date = NSDate()
    
    // 把新的 Walk 插进 Dog's walks 中
//    if let dog = currentDog, let walks = dog.walks?.mutableCopy() as? NSMutableOrderedSet {
//      walks.add(walk)
//      dog.walks = walks
//    }
    // 和上面注释的代码同样效果
    currentDog?.addToWalks(walk)
    
    // 保存
    do {
      try managedContext.save()
    } catch let error as NSError {
     print("Save error: \(error) description: \(error.userInfo)")
    }
    
    tableView.reloadData()
  }
}

// MARK: UITableViewDataSource
extension ViewController: UITableViewDataSource {

  func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
    guard let walks = currentDog?.walks else {
      return 1
    }
    return walks.count
  }

  func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
    let cell = tableView.dequeueReusableCell(withIdentifier: "Cell", for: indexPath)
    guard let walk = currentDog?.walks?[indexPath.row] as? Walk,
      let walkDate = walk.date as? Date else {
        return cell
    }
    cell.textLabel?.text = dateFormatter.string(from: walkDate)
    return cell
  }

  func tableView(_ tableView: UITableView, titleForHeaderInSection section: Int) -> String? {
    return "List of Walks"
  }
}
// 删除数据
  func tableView(_ tableView: UITableView, commit editingStyle: UITableViewCellEditingStyle, forRowAt indexPath: IndexPath) {
    guard let walkToRemove = currentDog?.walks?[indexPath.row] as? Walk,
      editingStyle == .delete else {
        return
    }
    // managed context 中 删除数据
    managedContext.delete(walkToRemove)
    
    do {
      try managedContext.save()
      //表中删除行
      tableView.deleteRows(at: [indexPath], with: .automatic)
    } catch let error as NSError {
      print("Saving error: \(error), description: \(error.userInfo)")
    }
  }
  //tableView 左划删除
  func tableView(_ tableView: UITableView, canEditRowAt indexPath: IndexPath) -> Bool {
    return true
  }

总结：
从CoreDataStack.swift可以看到，我们新建了个 Core Data Stack 来管理 context，其中 managed context 由初始化后的 NSPersistentContainer 类实例的 .viewContext 属性获取。另外AppDelegate.swift也用到CoreDataStack.swift中的saveContext()方法来保存数据变更。至此，我们完成通过 Stack 来对数据增删改查，第一阶段结束。

Intermediate Fetching

前面我们都是一下子获取所有搜索到的数据，这节讲的是如何更好地获取数据。

本节目标：

  • 只获取想要的数据
  • 用 predicate 限制获取到的数据
  • 避免屏蔽 UI，转为在后台获取数据
  • 在 persistent store 中通过直接更新 object 来避免不必要的数据获取。

NSFetchRequest

之前获取数据都是先创建一个 NSFetchRequest 实例，配置好搜索范围然后再在 context 上获取数据。但实际上，我们有五种不同的方法来实现操作。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// 1
let fetchRequest1 = NSFetchRequest<Venue>()
let entity = NSEntityDescription.entity(forEntityName: "Venue", in: managedContext)!
fetchRequest1.entity = entity

// 2 第一种写法的缩写形式
let fetchRequest2 = NSFetchRequest<Venue>(entityName: "Venue")

// 3 第二种写法的缩写形式 fetchRequest()方法被定义在 Venue+CoreDataProperties.swift
let fetchRequest3: NSFetchRequest<Venue> = Venue.fetchRequest()

// 4 从 NSManagedObjectModel 中获取数据
let fetchRequest4 = managedObjectModel.fetchRequestTemplate(forName: "venueFR")

// 5 和第四种写法类似，但这里多了一些参数去限制获取结果。
let fetchRequest5 = managedObjectModel.fetchRequestFromTemplate(withName: "venueFR", substitutionVariables: ["NAME" : "Vivi Bubble Tea"])

获取不同结果的类型

NSFetchResult 不仅仅是一个简单的工具，实际上，它可以说是 Core Data 框架中的瑞士军刀。

你可以用它来获取单独的数据，对数据进行统计，例如：平均数、最小值、最大值等等。

NSFetchRequest 有个属性叫 resultType，

  • .managedObjectResultType：返回 managed objects（默认值）
  • .countResultType：返回满足抓取要求的数据数量
  • .dictionaryResultType：这是一个获取所有返回数据的类型，能返回经过不同计算后的数据。
  • .managedObjectIDResultType：代替完整的 managed object 返回唯一识别(unique identifiers)。

例如：获取其数量！

拿第二点 .countResultType 来说，有的人可能会直接获取所有的 managed objects 之后再调用数组的count属性得到 object 的数量。但是一旦要获取一个城市的人口数量的时候，先获取所有人口的 object 再得到数量这样显然对内存是很不友好的，这时候通过 .countResultType 获取结果的数量会更有效率。

例如，我想获得价格分类只有一个「$」的珍珠奶茶店数量，我们给 fetchRequest 配置好 resultType 结果类型属性，在配置好 predicate 查询范围后，就可以直接从 countResult.first!.intValue 得到。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
var coreDataStack: CoreDataStack!
lazy var cheapVenuePredicate: NSPredicate = {
  return NSPredicate(format: "%K == %@", #keyPath(Venue.priceInfo.priceCategory), "$")
}()

//...

// 获取数量并配置 label
func populateCheapVenueCountLabel() {
  // 抓取的是数量 所以是 NSNumber
  let fetchRequest = NSFetchRequest<NSNumber>(entityName: "Venue")
  // 返回满足抓取要求的数据数量
  fetchRequest.resultType = .countResultType
  // 只抓取一个 $ 的
  fetchRequest.predicate = cheapVenuePredicate
  
  do {
    let countResult = try coreDataStack.managedContext.fetch(fetchRequest)
    // 获取数量
    let count = countResult.first!.intValue
    firstPriceCategoryLabel.text = "\(count) bubble tea places"
  } catch let error as NSError {
    print("Could not fetch \(error), \(error.userInfo)")
  }
}

当然我们还可以有不同的搜索数量的方式，这里我们获得价格分类有三个「$」的珍珠奶茶店数量。和以前一样先把搜索范围定位所有的 Venue object，然后在获取结果的时候点名只获取数量。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
lazy var expensiveVenuePredicate: NSPredicate = {
  return NSPredicate(format: "%K == %@", #keyPath(Venue.priceInfo.priceCategory), "$$$")
}()

//...

func populateExpensiveVenueCountLabel() {
  // 构建获得 Venue object 的请求
  let fetchRequest: NSFetchRequest<Venue> = Venue.fetchRequest()
  
  // 获得三个 $ 的
  fetchRequest.predicate = expensiveVenuePredicate
  
  do {
    // 用 count 属性获取数量
    let count = try coreDataStack.managedContext.count(for: fetchRequest)
    thirdPriceCategoryLabel.text = "\(count) bubble tea places"
  } catch let error as NSError {
    print("Could not fetch \(error), \(error.userInfo)")
  }
}

例如：获取后计算！

第三点的.dictionaryResultType 能能返回经过不同计算后的数据，同样的我们通过 NSExpression 来实现一些简单的计算。下图是 API 文档中的部分属性，供参考。

例如，我们要搜索所有珍珠奶茶的优惠数量，我们同样没有必要找出所有相关的属性再自己求和，Core Data 可以帮我们完成任务。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
func populateDealsCountLabel() {
  // 1 .dictionaryResultType 告诉 fetchRequest 要进行计算
  let fetchRequest = NSFetchRequest<NSDictionary>(entityName: "Venue")
  fetchRequest.resultType = .dictionaryResultType
  
  // 2 创建一个 NSExpressionDescription 去请求求和后的数据，然后把这个请求过程的名字定为 sumDeals
  let sumExpressionDesc = NSExpressionDescription()
  sumExpressionDesc.name = "sumDeals"
  
  // 3 构建表达式 一开始说明要计算的数据来源是 specialCount（优惠的数量）
  // 然后说明计算方式为"sum:"求和，结果为 integer32AttributeType 类型
  let specialCountExp = NSExpression(forKeyPath: #keyPath(Venue.specialCount))
  sumExpressionDesc.expression = NSExpression(forFunction: "sum:", arguments: [specialCountExp])
  sumExpressionDesc.expressionResultType = .integer32AttributeType
  
  // 4 配置 fetchRequest
  fetchRequest.propertiesToFetch = [sumExpressionDesc]
  
  // 5 返回字典类型数据，再按之前的名字取出对应的值
  do {
    let results = try coreDataStack.managedContext.fetch(fetchRequest)
    let resultDict = results.first!
    let numDeals = resultDict["sumDeals"]!
    numDealsLabel.text = "\(numDeals) total deals"
    
  } catch let error as NSError {
    print("Could not fetch \(error), \(error.userInfo)")
  }
}

managedObjectResultType

剩下一个类型是.managedObjectResultType，当你用这类型去获取结果的时候，结果会是一个NSManagedObjectID组成的数组，而不是原来的 managed objects。一个NSManagedObjectID是一个managed object 的压缩的统一标识，作用就像数据库中的主键一样。

在 iOS 5，人们通常通过 ID 来获取数据，因为NSManagedObjectID是线程安全的，而且通过用它能帮助开发者实现并发线程限制模型(thread confinement concurrency model)。

现在线程限制对于很多并发模型来说已经过时了，通过 object ID 来获取数据的做法也在逐渐减少。

目前我们尝试过关于获取数据的不同方式，但是有时候我们需要限制获取的数据数量，我们有时没有必要去一次性获取所有对象图(object graph)，这样对内存也不友好。

我们有不同方式去限制获取结果的数量，例如NSFetchRequest支持获取的批次数量 (fetching batches)。我们可以用fetchBatchSize、fetchLimit、fetchOffset去控制获取批次数量的行为。

1
2
3
4
5
let request = NSFetchRequest(entityName: "Item")
request.fetchBatchSize = 20
request.fetchLimit = 100
request.sortDescriptors = [sortDescriptor]
request.predicate = ...

例如数据库有1000个「item」，上面的代码限制了请求，一次获取20个 item，并且将会在获取100个 item 之后停止继续获取数据。

Core Data 也尝试通过一种名叫「faulting」的技术去减少内存消耗，一个 fault 是一个占位符，用来表示 managed object 没有被完全送进内存里面。

最后，限制对象图的另外一种方法是用 predicates，就像之前做的一样。

Faulting

Faulting 可以看做是 Core Data 的一种懒加载，简单地说就是 object 的一些属性只会在你需要的时候才会去获取。

1
2
3
for user in twitterUsers {
print("fetched user \(user)")
}

我们可能看不到 user 的 name 属性被打印出来（我们可能只会看到「unfaulted object」，这依赖于 Core Data 是否已经提前获取了属性），但如果我们像下面这么做…

1
2
3
for user in twitterUsers {
print("fetched user named \(user.name)")
}

我们一定能够从数据库中获取所有的 TwitterUsers，因为我们实际上在获取 NSManagedObject 的数据（其属性）。

排序

NSFetchRequest 另外一个强大的功能就是能帮你排序好数据，它是通过 NSSortDescriptor 来实现的。这样的排序是在 SQLite 层面的，而不是在内存中，所以这让 Core Data 中的排序即快又有效率。

现在要实现根据珍珠奶茶店的名字升序、降序、距离、价格来排序，首先定义好 NSSortDescriptor。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// 按名字排序
lazy var nameSortDescriptor: NSSortDescriptor = {
  let compareSelector = #selector(NSString.localizedStandardCompare(_:))
  return NSSortDescriptor(key: #keyPath(Venue.name),
                          ascending: true,
                          selector: compareSelector)
}()

// 按距离排序
lazy var distanceSortDescriptor: NSSortDescriptor = {
  return NSSortDescriptor(key: #keyPath(Venue.location.distance),
                          ascending: true)
}()

// 按价格排序
lazy var priceSortDescriptor: NSSortDescriptor = {
  return NSSortDescriptor(key: #keyPath(Venue.priceInfo.priceCategory),
                          ascending: true)
}()

初始化一个 NSSortDescriptor 的实例需要做三件事：有一个 key path 去指出要排序的属性路径(数据库表中：表→属性，表→表→属性等等)，要求升序或降序， 一个可选的选择器(option selector)去实现比较操作。

如果你之前用过 NSSortDescriptor，你可能知道有一种基于块的(block-based) API 可以把比较器(comparator)代替为选择器(seletor)。遗憾的是，Core Data 不支持通过这种方法来定义一个 sort descriptor。

同样的 Core Data 也不支持 NSPredicate 中基于块的(block-based)方法，原因是过滤和分类操作是在 SQLite 数据库中完成的，所以 predicate/sort descriptor 不得不去很好的匹配数据并写成 SQLite 语句。

另外，NSString.localizedStandardCompare(_:) 是苹果推荐用来根据符合当前语言环境(the current locale)的语言规则来排序，这可以更好地去处理一些特殊字符，例如 bien sûr :]

在tableView(didSelectRowAt:)方法中完成赋值，「Search」按钮事件为触发ViewController.swift中的委托方法。

FilterViewController.swift

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
/// 定义一个委托方法：当用户选择一个新的过滤操作时候(sort/filter combination)，会通知委托。
protocol FilterViewControllerDelegate: class {
  func filterViewController(filter: FilterViewController,
                            didSelectPredicate predicate: NSPredicate?,
                            sortDescriptor: NSSortDescriptor?)
}

class FilterViewController: UITableViewController {
//...
}

// MARK: - UITableViewDelegate
extension FilterViewController {

  override func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
    guard let cell = tableView.cellForRow(at: indexPath) else {
      return
    }
    
    // Price section
    switch cell {
    //Sort By section
    case nameAZSortCell:
      selectedSortDescriptor = nameSortDescriptor
    case nameZASortCell:
      selectedSortDescriptor = nameSortDescriptor.reversedSortDescriptor
                               as? NSSortDescriptor
    case distanceSortCell:
      selectedSortDescriptor = distanceSortDescriptor
    case priceSortCell:
      selectedSortDescriptor = priceSortDescriptor
    default:
      break
    }
    
    cell.accessoryType = .checkmark
  }
}

// MARK: - IBActions
extension FilterViewController {

  @IBAction func saveButtonTapped(_ sender: UIBarButtonItem) {
    delegate?.filterViewController(filter: self,
                                   didSelectPredicate: selectedPredicate,
                                   sortDescriptor: selectedSortDescriptor)
    
    dismiss(animated: true)
  }
}

ViewController.swift 中补充委托方法。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// MARK: - FilterViewControllerDelegate
extension ViewController: FilterViewControllerDelegate {
  func filterViewController(filter: FilterViewController, didSelectPredicate predicate: NSPredicate?, sortDescriptor: NSSortDescriptor?) {
    fetchRequest.predicate = nil
    fetchRequest.sortDescriptors = nil
    
    fetchRequest.predicate = predicate
    
    if let sr = sortDescriptor {
      fetchRequest.sortDescriptors = [sr]
    }
    //获取数据并 reload tableView
    fetchAndReload()
  }
}

异步获取数据

当你看到这里，我好消息和坏消息要告诉你。好消息是我们已经说了很多关于 NSFetchRequest 可以做的事，坏消息是我们每次获取数据都会屏蔽主线程，直到获取到数据。

当你屏蔽了主线程，屏幕就会变得不可交互，还会产生一些其他的问题，之前没有感觉到屏蔽主线程的感觉，是因为我们获取的数据还太少。iOS 8 中，Core Data 有一个 API 能让我们长时间在后台获取数据，获取到数据后还能得到一个回调方法。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
// 不先初始化的话 回调方法会报错
var venues: [Venue] = []

// 父类是 NSPersistentStoreRequest 而不是 NSFetchRequest
var asyncFetchRequest: NSAsynchronousFetchRequest<Venue>!

// MARK: - View Life Cycle
override func viewDidLoad() {
  super.viewDidLoad()
  
  // 1 准备获取数据
  fetchRequest = Venue.fetchRequest()
  
  // 2 用 fetchRequest 和回调完成请求，数据在 result.finalResult 中
  asyncFetchRequest = NSAsynchronousFetchRequest<Venue>(fetchRequest: fetchRequest) {
    [unowned self] (result: NSAsynchronousFetchResult) in
    guard let venues = result.finalResult else {
      return
    }
    self.venues = venues
    self.tableView.reloadData()
  }
  
  // 3 执行异步请求
  do {
    try coreDataStack.managedContext.execute(asyncFetchRequest)
  } catch let error as NSError {
    print("Could not fetch \(error), \(error.userInfo)")
  }
}

还要注意的是要获取的 venues 实例，由于现在获取数据是异步的，所以获取数据的步骤会在 table view 初始化之后再执行，所以要先初始化好实例，不然不能解包实例，应用会报错。

另外，如果要取消获取数据的请求(fetch request)，可以调用NSAsynchronousFetchResult的cancel()方法。

批量更新(Batch updates)

有时候我们需要从 Core Data 中获取数据是去改变一个单独的属性(attribute)，改动后，我们还要去 commit 回 persistent store。但如果我们想要去一次性更新十万计的数据呢？这将会消耗大量的时间和内存去只更新一个属性。

iOS 8 中，有一个新的方法能不从内存中获取所有数据来完成更新数据：batch updates。这新的技术能绕过 NSManagedObjectContext 来直接操作 persistent store。通常批量更新的做法就像邮件客户端中的「Mark all as read」功能一样。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// MARK: - View Life Cycle
override func viewDidLoad() {
  super.viewDidLoad()
  
  let batchUpdate = NSBatchUpdateRequest(entityName: "Venue")
  batchUpdate.propertiesToUpdate = [#keyPath(Venue.favorite) : true]
  
  batchUpdate.affectedStores = coreDataStack.managedContext
    .persistentStoreCoordinator?.persistentStores
  
  batchUpdate.resultType = .updatedObjectsCountResultType
  
  do {
    let batchResult = try coreDataStack.managedContext
      .execute(batchUpdate) as! NSBatchUpdateResult
    print("Records updated \(batchResult.result!)")
  } catch let error as NSError {
    print("Could not fetch \(error), \(error.userInfo)")
  }
}

运行应用后显示：Records updated 30

批量删除

iOS 9 中，NSBatchDeleteRequest 能帮我批量删除数据，如批量更新一样，不需要把数据读取到内存再操作，而且父类也是 NSPersistentStoreRequest。

我们在回避 NSManagedObjectContext，所以批量更新或批量删除时，我们不会进行数据验证。数据的改动不会影响我们的 managed context，所以在用一个 persistent store request 之前要验证好数据。

NSFetchedResultsController

之前我们都是把 Core Data 和 UITableView 放在一起用，Core Data，提供了一个类来专门处理这种使用方式：NSFetchedResultsController。NSFetchedResultsController 是一个 controller，但是它不是一个 view controller，它没有界面，它的目的在于帮助开发者通过抽象大部分代码更容易地在 table view 上同步数据。

实例：世界杯

下面的代码是关于一个世界杯胜场计数的应用示例。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
var fetchedResultsController: NSFetchedResultsController<Team>!

// MARK: - View Life Cycle
override func viewDidLoad() {
  super.viewDidLoad()
  // 1 fetchRequest 是万能的
  let fetchRequest: NSFetchRequest<Team> = Team.fetchRequest()
  
  // 2 初始化 fetchedResultsController
  fetchedResultsController = NSFetchedResultsController(
    fetchRequest: fetchRequest,
    managedObjectContext: coreDataStack.managedContext,
    sectionNameKeyPath: nil,
    cacheName: nil)
  
  // 3 开始获取数据
  do {
    try fetchedResultsController.performFetch()
  } catch let error as NSError {
    print("Fetching error: \(error), \(error.userInfo)")
  }
}

这里有点奇怪的是 NSFetchedResultsController 没有返回什么值就可以获取数据了，其实 NSFetchedResultsController 既是 fetch request 的包装，也是一个获取数据用的 container，我们可以从中获取到数据。例如我们可以通过fetchedObject属性或object(at:)方法来获得。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
// MARK: - Internal
extension ViewController {

  func configure(cell: UITableViewCell, for indexPath: IndexPath) {

    guard let cell = cell as? TeamCell else {
      return
    }

    let team = fetchedResultsController.object(at: indexPath)
    cell.flagImageView.image = UIImage(named: team.imageName!)
    cell.teamLabel.text = team.teamName
    cell.scoreLabel.text = "Wins: \(team.wins)"
  }
}

// MARK: - UITableViewDataSource
extension ViewController: UITableViewDataSource {
// section 数 
  func numberOfSections(in tableView: UITableView) -> Int {
    guard let sections = fetchedResultsController.sections else {
      return 0
    }
    return sections.count
  }

  func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
    guard let sectionInfo = fetchedResultsController.sections?[section] else {
      return 0
    }
    return sectionInfo.numberOfObjects
  }

  func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {

    let cell = tableView.dequeueReusableCell(withIdentifier: teamCellIdentifier, for: indexPath)
    configure(cell: cell, for: indexPath)

    return cell
  }
}

// MARK: - UITableViewDelegate
extension ViewController: UITableViewDelegate {
//点击后胜场加一，保存数据到 Core Data，并重载 tableview
  func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
    let team = fetchedResultsController.object(at: indexPath)
    team.wins = team.wins + 1
    coreDataStack.saveContext()
    tableView.reloadData()
  }
}

section

到了这步，启动应用的话还会报'An instance of NSFetchedResultsController requires a fetch request with sort descriptors'的错，因为我们使用 NSFetchedResultsController，它需要我们给它提供至少一个 sort descriptor，才能知道如何整理数据。与之前不一样的是，前面获取数据的时候可以不提供 sort descriptor。

于是在之前的基础上加上 sort descriptor，这里同时增加了三种排序。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
// MARK: - View Life Cycle
override func viewDidLoad() {
  super.viewDidLoad()
  // 1 fetchRequest 是万能的
  let fetchRequest: NSFetchRequest<Team> = Team.fetchRequest()
  
  // 必须提供至少一个 sort descriptor
  let zoneSort = NSSortDescriptor(key: #keyPath(Team.qualifyingZone), ascending: true)
  let scoreSort = NSSortDescriptor(key: #keyPath(Team.wins), ascending: false)
  let nameSort = NSSortDescriptor(key: #keyPath(Team.teamName), ascending: true)
  fetchRequest.sortDescriptors = [zoneSort, scoreSort, nameSort]
  
  // 2 初始化 fetchedResultsController
  fetchedResultsController = NSFetchedResultsController(
    fetchRequest: fetchRequest,
    managedObjectContext: coreDataStack.managedContext,
    sectionNameKeyPath: nil,
    cacheName: nil)
  
  // 3 开始获取数据
  do {
    try fetchedResultsController.performFetch()
  } catch let error as NSError {
    print("Fetching error: \(error), \(error.userInfo)")
  } 
}

如果在前面viewDidLoad()方法中更改下 fetchedResultsController 的 sectionNameKeyPath，就可以直接按照相关的字符串分类，例如这里把国家按照大洲分类。注意前面的 sort descriptor 也要加上相应的分类，例如let zoneSort = NSSortDescriptor(key: #keyPath(Team.qualifyingZone), ascending: true)，否则分类顺序会错乱。

1
2
3
4
5
6
// 2 初始化 fetchedResultsController
fetchedResultsController = NSFetchedResultsController(
  fetchRequest: fetchRequest,
  managedObjectContext: coreDataStack.managedContext,
  sectionNameKeyPath: #keyPath(Team.qualifyingZone),
  cacheName: nil)

再增加一个委托方法提供 section 的标题：

1
2
3
4
func tableView(_ tableView: UITableView, titleForHeaderInSection section: Int) -> String? {
  let sectionInfo = fetchedResultsController.sections?[section]
  return sectionInfo?.name
}

缓存

NSFetchedResultsController 提供了缓存功能，只要在之前的viewDidLoad()方法中更改下fetchedResultsController的 cacheName 就能实现了。

1
2
3
4
5
fetchedResultsController = NSFetchedResultsController(
  fetchRequest: fetchRequest,
  managedObjectContext: coreDataStack.managedContext,
  sectionNameKeyPath: #keyPath(Team.qualifyingZone),
  cacheName: "worldCup")

我们要注意缓存是把数据缓存到硬盘中，和 Core Data 的 persistent store 是分开的。如果我们要更改获取的数据，或者不一样的 sort descriptor 等等导致缓存无效的时候，我们必须用deleteCache(withName:)删除现有缓存，或者换一个缓存名。

数据控制

前面更新数据的方法就是调用 table view 的reloadData()方法，其实 NSFetchedResultsController 直接给我们提供了委托方法，让我们可以在数据改动的时候直接更新 table view。

gif

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
// MARK: - NSFetchedResultsControllerDelegate
extension ViewController: NSFetchedResultsControllerDelegate {
  // 数据将会改变，调用 beginUpdates() 方法
  func controllerWillChangeContent(_ controller: NSFetchedResultsController<NSFetchRequestResult>) {
    tableView.beginUpdates()
  }
  
  // 球队相关数据改变
  func controller(_ controller: NSFetchedResultsController<NSFetchRequestResult>, didChange anObject: Any, at indexPath: IndexPath?, for type: NSFetchedResultsChangeType, newIndexPath: IndexPath?) {
    switch type {
    case .insert:
      tableView.insertRows(at: [newIndexPath!], with: .automatic)
    case .delete:
      tableView.deleteRows(at: [indexPath!], with: .automatic)
    case .update:
      let cell = tableView.cellForRow(at: indexPath!) as! TeamCell
      configure(cell: cell, for: indexPath!)
    case .move:
      tableView.deleteRows(at: [indexPath!], with: .automatic)
      tableView.insertRows(at: [newIndexPath!], with: .automatic)
    }
  }
  
  // 数据完成改变，应用变化。
  func controllerDidChangeContent(_ controller: NSFetchedResultsController<NSFetchRequestResult>) {
    tableView.endUpdates()
  }
  
  // section 相关数据改变
  func controller(_ controller: NSFetchedResultsController<NSFetchRequestResult>, didChange sectionInfo: NSFetchedResultsSectionInfo, atSectionIndex sectionIndex: Int, for type: NSFetchedResultsChangeType) {
    let indexSet = IndexSet(integer: sectionIndex)
    
    switch type {
    case .insert:
      tableView.insertSections(indexSet, with: .automatic)
    case .delete:
      tableView.deleteSections(indexSet, with: .automatic)
    default: break
    }
  }
}

未完待续

Todo:

  • 多线程
  • 数据库迁移
  • Optimistic locking (deleteConflictsForObject)
  • Rolling back unsaved changes
  • Undo/Redo
  • Staleness (how long after a fetch until a refetch of an object is required?)
  • …

如同上面的列表所示，本文没涉及的话题还很多，但会随着自己的学习逐渐补充。如何去保持 Core Data 高性能的最佳实践，如何正确地组合使用它，是使用 Core Data 的挑战所在。

]]> iOS基础 Swift iOS Core Data 用 Workflow 把知乎答案存到 Instapaper /2016/11/05/workflow-of-zhihu-to-instapaper/ 随着 Instapaper 宣布免费，我开始尝试使用这款应用。这款应用很适合我，唯独抓取的时候对知乎支持不太好，有强迫症的我尝试解决它，其中比较有效的方法是：右上角菜单「Safari 打开」-打开阅读器视图-发邮件至 Instapaper 邮箱。但是这依旧有点麻烦了，我后来找到 Mercury 这个服务，并用 Workflow 解决了这问题。

Workflow 特点

  • 支持知乎答案抓取（答案太短可能会抓取失败）
  • 知乎专栏文章和其他网站直接原生添加到 Instapapaer
  • 清除知乎答案内的知乎超链接跳转

前提

注册 Mercury

Mercury 是一个免费的在线文本解析网站，允许我们提供网址并得到 JSON 格式的解析结果。我们需要使用它们的服务，所以要注册个账号得到 API KEY 来配置 Workflow 使用。

首先进入 Mercury ，点击右上角的「SIGN UP FOR FREE」。注册完成并验证邮箱后，就能看到你专属的 API KEY 了。

配置 Workflow

你可以在下面获取到我写的 Workflow。

Workflow V5 下载

点击「GET WORKFLOW」，应该就能把这 workflow 保存到你应用当中了。

配置 Mercury API KEY 和邮箱

KEY 我们已经拿到了，另外需要的 Instapaper 的邮箱地址可以在 How to Save 中找到Instapaper接收邮件的邮箱地址。

把 Workflow 往下拉，找到注释，把 KEY 和 Instapaper 接收邮件的邮箱分别填到「Text」框中和「Email Address」框中。

IMG_0177

然后把 Workflow 拉到中间，找到绿色的「Ask When Run」圈圈，删除后添加自己用来发邮件的个人邮箱。再往下拉到 Workflow 四分之三的位置，同样配置好个人邮箱。第一次使用 Workflow 的同学需要授权邮箱应用，另外要注意的是邮箱服务器、用户名、密码都确认无误仍然提示 incorrect 的话，直接保存就好了，运行 Workflow 发送邮件无效后再修改。

IMG_0178

Workflow 中共有四次要配置的地方，并且要在 Workflow 应用中对 Instapaper 授权，都配置完毕要在 Workflow 应用中运行一次，获得对新下载的 Workflow 运行的许可。

运行

知乎答案

操作：右上角菜单-复制链接-运行 Workflow

最后

自己实在等不到知乎官方支持 Instapaper 的那天了，于是写了这个 Workflow 。拿到 Matrix 内测资格后，这个 Workflow 已经是第五个版本了，相对比较完善。如果有什么疑问或者建议，请在评论区指出，我会尽快回复。

另外 Workflow 中对知乎答案的支持都是通过其他服务抓取数据而来，所以抓取时相当于下载一次网络数据，再用邮件发出，对于图片较多的答案或专栏会耗费较多流量。

注意事项：

  • Workflow 对当前复制的文字中是否含有「http」判断是否为链接
  • 如果不能运行请换其他邮箱测试（确保邮箱的SMTP、IMAP地址、端口号和邮箱密码正确，QQ 邮箱需要生成授权码来当密码使用）
  • 运行后会清除当前剪贴板
  • 图片越多，发送邮件速度越慢，耗费流量越多
  • 已知不支持新浪文章
  • 该方法需要重新下载网页数据并发邮件，使用的时候请注意流量消耗
  • 如果有运行 Workflow 时自动打开应用再运行的现象，尝试重启设备
  • Workflow 点击运行后就会在后台运行，不用死等
  • 如还是发送空邮件，且以上所有问题都排除了，那就是知乎答案过长，例如这篇知乎答案，导致 Mercury 解析超时…

找到解决方法，马上写博文分享这也是一种强迫症吧哈哈哈(´ ˘ `๑)

]]> 工具癖 Workflow macOS 上管理书的一些分享 /2016/10/24/manage-books-on-macOS/

在生活中，我时不时会买一些书，包括电子书和实体书。随着书籍的增多，我作为一个工具控也有着自己一套管理书籍的方式，在这里与大家分享。

本文不会涉及电子书解密与分享，仅作经验分享。

电子书

随着亚马逊的大力推广，我较关注的技术书也因其时效性多以电子书形式发布，电子书实际上占用了我生活中所购买书的一大部分。

下图是我所经历亚马逊一些较大的优惠，其中第二个限时优惠更是允许我不到 8 元买到四本接近百元的电子书(亚马逊药丸！！)。我也经常从图灵社区购买一些技术书籍，图灵社区提供的是未加密的电子书，加之一些网友也有分享自制的电子书，因此能很方便地放到不同工具中阅读和管理。

我们所经常遇到的电子书格式通常有 Mobi、Epub、PDF 等格式，阅读 PDF 我推荐使用 PDF Expert 2，其余类型电子书我推荐用 Clearview 阅读，epub 用 iBook 阅读也是不错的体验，Mobi 也能放到 Kindle for mac 上阅读。

豆瓣读书也提供了一个很好的管理书籍的平台，也方便书友写书评和交流。

书

Calibre

Calibre 是一款强大的免费开源电子书管理软件，支持 macOS、Windows、Linux。作者几乎每两周就会更新一次软件，这里是开源地址。

编辑书籍元数据

下载元数据

转换书籍

Calibre 转换书籍也方便，能自定义字体、字体大小、自动检测增加目录、更改页面设置等，转 PDF 的时候注意下页面边距和行距。

多种分类方便搜索

在电子书右键选择 Calibre 打开后，Calibre 会把电子书复制到你设置的仓库中，根据作者名分类，编辑的书籍元数据也会储存到一起。仓库也能备份成一个文件，防止电子书丢失，方便转移。

推送电子书

发送邮件的配置可以参考邮箱网页版的设置页面中STMP服务器项填写。

点击测试邮件发送按钮后会尝试发送一个内容为“Test mail from calibre”的邮件到亚马逊接收推送的电子邮箱，稍等片刻若收到如下图的邮件则说明测试成功。

其中接收电子书推送的邮箱可以在管理我的内容和设备中“我的设备”或“设置”中找到。

同时别忘了把你的邮箱添加到“已认可的发件人电子邮箱列表”中，否则 Kindle 将会接收不到推送，该页面可以在同页面的“设置”底部。

大概在半小时过后我的 Kindle 应用才同步到这本电子书，另外我只给 iPad 的 kindle 推送邮箱推送后，全部设备的 Kindle 应用云端上都可以看到这本电子书，还是很方便的。

更多Calibre 技巧可以参考Calibre 使用教程，本文仅作抛砖引玉。

实体书

京东抽奖得的 200-100 图书券、会员每月可得的 200-80 勋章券，还有亚马逊时不时的活动，我对买实体书完全没有抵抗力…

实体书的管理可能没电子书管理这么有必要，我们仍然可以管理书籍读书状态，拥有的书籍信息。这里要介绍的是一款新生的工具——Shelf。

macOS 上在书籍方面有很多出色的工具，不仅仅是管理书籍，更多的是创作文字、阅读、制作电子书等各方面的工具。iPhone 上也有很多方便管理实体书的 App，例如：美丽阅读、藏书阁等，通过扫书籍条形码添加书籍再管理。这方面也是不同设备的优点吧，我认为 macOS 实际上更适合写书评、读后感之类的创造性行为。

小脚本

买书时我喜欢参考豆瓣网的评分，但是我不喜欢复制书名再打开新的页面搜索，有个小脚本可以帮到我们。

这个油猴脚本需要浏览器插件支持，详情如下：

  1. Microsoft Edge 14以上：Tampermonkey。
  2. Firefox 及相关的浏览器：Greasemonkey。
  3. Google Chrome、Chromium 及相关的浏览器：Tampermonkey。
  4. Opera (版本 15 及更晚)：Tampermonkey 或者 Violentmonkey。
  5. Opera 版本 12 及更早原生支持用户脚本。但 Violentmonkey 能提供更友好的界面和更好的兼容性。
  6. Safari： Tampermonkey

装完插件后到这安装脚本 Douban Book Bar [安装此脚本]->[安装]

脚本适用于：图灵社区、京东、亚马逊中国、当当、多看、苏宁易购、文轩和 China-pub

祝买书快乐！

总结

“买书如山倒，读书如抽丝”这句话很适合我，本博文只为买书提供了一个管理方法的整理，关键还是”读书”。

前不久我写了篇关于macOS 上的时间跟踪软件的文章，直到今天我写完本文章，心情是挺苦恼的，因为我能帮别人节省的仅仅是找书的时间。我真正想做到的是让人读书，估计得自己还有很长一段路要走。(一刹那宛如鲁迅再生，毅然弃医从文！！)

有了挤出来的时间，有了最好的阅读工具，有了方便的书籍管理工具，我们距离读书还差点什么呢？

]]> 工具癖 APP macOS macOS 上的时间跟踪软件 /2016/10/21/new-time-tracking-app-on-macOS/

时间统计法-不是一个节俭的计划工作者的预算，而是向时间自我剖析，对时间的崇敬。

《奇特的一生》格拉宁

今天在 Next 上发现又一款时间追踪软件横空出世了，所以对几个 macOS 上的时间追踪软件做个总结。近年以来，可以看到很多时间方面的应用遍地开花：Todo 类、番茄钟、备忘事项、日历等等，可以看出来人们对自己的时间越来越看重，如何掌握和使用好碎片时间，是当今一个热门的主题。而时间追踪类软件是其中一个较低调的类别，我目前遇到的大多是帮助你知道时间是如何花掉的，所以这类软件还需要一个会分析时间的使用者。

时间管理

RescueTime

RescueTime 是一款易用的多平台时间追踪软件，支持 macOS、Windows、Android、Chrome、FireFox 等(iOS 版尚在开发中)，它可以挂在电脑后台自动追踪时间，生成时间报表，Pro 版可以禁用消极网页、设定目标、设定提醒等。

我曾经在 V2EX 社区上发起过一次调查：你会为什么样的网络服务付费？，其中 RescueTime 也能占一席之地，我认为这是能代表一些东西的。

如图可以看到 RescueTime 把你的行为分成几类，大多数行为能够自动判断消极或者积极(知乎居然是积极的我很不信服…)。当然了，行为的类别和积极性都可以编辑，例如你可以把一些经常使用但未归类的网页编辑好属性，更好的监控你的时间，另外 RescueTime 还能每天晚上主动推送每日的追踪报告。

日视图：

周视图：

RescueTime 中详细的时间报表让你明白时间去哪儿了，上图右下角可以编辑行为的积极性和类别噢。值得注意的是基础的报表统计功能免费用户就能使用，因此是控制时间入门的好选择。

Pro用户的屏蔽消极网页功能，可以不用改 hosts 了…

(我这里就是今天消极时间到达半小时自动开始专注状态，把要本博文要查的一些网站都给屏蔽掉了…)

喜欢工作流的同学可以尝试下 RescueTime 提供的 API

想要尝试Pro用户版的可以通过这个推荐链接注册，获得两星期的高级用户功能解锁，如果你想买一年，建议去数码荔枝买国人专供的99元一年，而不是原本坑爹的72美刀一年。

Timing

如果你不喜欢 RescueTime 那种把数据上传到服务器统计的感觉，你可以尝试下Timing，Timing 可以看做离线版的 RescueTime。

详细的网站、文件地址记录，还支持播放记录等

支持数据导出

点击这里可以查看更详细的支持软件列表

相比 RescueTime，Timing 只是单纯地记录时间，唯一会联网的操作可能就是升级软件了…你可以在 Mac App Store 花253元购买，不过在数码荔枝里面这 APP 是99元。

我以前购买The 2016 All-Star Mac Bundle的时候剩了一个，自己已经有一个了，如果不介意Registration Email是我邮箱的话，我打算50元出售这个 Key，有意的可以发邮件给我：superfrankie621@gmail.com。

TopTracker

TopTracker 就是我今天在 Next 上看到的令人惊喜的一个时间追踪软件，为什么说是惊喜呢？因为它是完全免费的！免费万岁！！

TopTracker 适用于macOS、Windows、Linux。不过 TopTracker 是属于主动记录的时间追踪软件，你可以创建一个事件，开始做了就让软件开始记录，做完再停止。TopTracker 是设计给自由职业者的，所以会多一些团队协作的功能。例如下面可以邀请成员来到 Project 中，互相查看工作进度。

你可以在网页上操作

也可以在客户端上操作

你还可以把忙时没记录的事件补充进去

网页版也能记录事件，还能够查看桌面端查看不了的时间报表。

注意：这软件有个让我费解的功能就是会自动截图，在使用的过程中出现一个“是否同意截图”的框，拒绝后你的状态就是短暂变成 Offline。你可以在设置中设置自动模糊Blur Screenshots Before Upload，也可以主动删除截图文件夹，否则上传截图到服务器的行为会让一些用户炸毛，这里先打预防针。

总而言之 TopTracker 的功能较类似 iOS 上各种时间记录 App，例如时间块、iHour 等等，团队协作方面类似 macOS 上的奇妙清单。个人认为相对于传统的手打表格记录时间(洪荒气息扑面而来！)，TopTracker 也不失为一个好的选择，因为不是每个人都会每天在电脑面前呆十小时以上，每天尝试有意识地记录时间，一周下来再详细设定计划如何利用好荒废掉的时间，不过太琐碎的事情(比如5分钟以内)都记录的话反而会是一种累赘，最重要的是养成习惯再调整自己。

总结

做个总结吧，RescueTime 免费提供的功能其实就已经足够使用了，目标和屏蔽网站这种高级功能按需购买吧(我已经剁手了！)。

另外 macOS 上的时间追踪软件还有Qbserve、Tyme 2、Time Sink等等，大家可以自己找找评测看，其中Tyme 2设置较繁琐，但是提供的接口也多。总之我把相对最好用最实惠的这三款时间追踪软件推荐给你们了，当然成效不是看工具而是看使用者如何使用。经常使用iPhone 的也可以尝试使用时间块和 iHour 培养记录时间的习惯，女生也可以把记录时间当成记账一样，细水长流嘛~

博文写到这里我 RescueTime 分数已经从65升到71了哈哈哈，还弹出来自己设的提醒，积极行为到达三小时发送自定义通知~

希望你们能够通过这些足够好的工具管理好碎片时间，认真分析什么时间适合做什么。例如坐公交搭地铁就不要看要动脑筋的书，有大块的空闲时间也不要拿来浪费到无聊事情上。

有趣无趣
烧脑高度专注力(看算法书、写博客)高度专注力(背单词、写代码)
中度专注力(TED,纪录片,科普书)
中度专注力(游戏)
不烧脑低度专注力(和朋友聊天)低度专注力(打扫卫生、整理文件)
低度专注力(刷美剧、刷朋友圈、刷知乎)低度专注力(删苹果广告、备份文件、整理收藏夹)

最后推荐 怎样用 Mac 和 iPhone 高效学习？-胖子邓的回答，共勉之~

]]> 工具癖 APP macOS 用JSONExport一键生成JSON Model /2016/10/17/powerful-jsonexport/ 以前跟着《第一行代码》入门 Android 的时候，学过几个解析 JSON 的方法，一个一个按 key 名找、建对象存等等，解析的工具也很多，以前对 JSON 不熟悉，这也浪费了我很多时间。现在刚入门 iOS 没多久就让我看到神器 JSONExport，解析 JSON 从此只是几行代码的事情~

JSONExport 是一个运行在 macOS 上通过 JSON 字符串转为 model 的开源工具，支持 Java、Objective-C 和 Swift。我发现了这工具之后忍不住用 Charles 到处抓 API 测试，这是后话~

每次学完了都觉得很基础…还是记下来吧…

工具

JSONExport 的项目地址在这：JSONExport
不过项目需要自己编译，嫌麻烦的可以直接下载我汉化好的 JSONExport ，如果失效请在评论留言，下面是界面：

左边把 JSON 字符串放入，右下角选择要生成的 Model 即可。

使用

这里我使用豆瓣图书 Api V2的 API 做示范。

根据提供的 API ，假如我想获得十个书名为"ios 开发"的书籍名，可以构建 URL 为"https://api.douban.com/v2/book/search?count=10&q=ios%20%E5%BC%80%E5%8F%91"，在网页中打开获得 JSON 字符串。

遇到的坑：

  • JSON 字符串中含有中文可能会被说明“无效 JSON”，转成unicode再放到工具里去用吧，例如：在线unicode转中文，或者用下图的 Paw。
  • Mac App Store 中也有同名工具，应该是别人直接修改原作者后上传的，能够根据 JSON 地址提取 JSON 数据，不过也是一搜中文就闪退。
  • JSONExport 没生成正确的 Model 就重启吧。

复制至JSONExport中，右下角按需选择，这里我用 Swift - Struct 做示范。

之后点右下角保存，把这六个文件拷到项目中就能直接使用了！我们可以直接构建一个 Struct。

BookInfo.swift

1
2
3
4
5
6
7
struct BookInfo {
    var images = ""
    var title = ""
    var isbn13 = ""
    var url = ""
    var summary = ""
}

这里我只需要图片、标题、isbn13、url和简介，接下来在 ViewController 中新建个方法获取数据，这里用了用 Swift 写的第三方网络库 Just。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
let searchUrl = "https://api.douban.com/v2/book/search?count=10&q=ios%20%E5%BC%80%E5%8F%91"//搜索"ios 开发"
var booklist : [BookInfo] = []

override func viewDidLoad() {
   super.viewDidLoad()
   loadList()
}
    
func loadList() {
   Just.get(searchUrl) { (r) in
       guard let json = r.json as? NSDictionary else {
           print("没有数据啊！！！")
           return
       }
       
       let books = SearchBook(fromDictionary: json).books!
       
       self.booklist = books.map({ (book) -> BookInfo in
           //数组转换数组 直接在 map 中用闭包
           return BookInfo(images: book.images.large, title: book.title, isbn13: book.isbn13, url: book.url, summary: book.summary)
       })

       dump(self.booklist)
       
       OperationQueue.main.addOperation {
           self.tableView.reloadData()
           self.refreshControl?.endRefreshing()
       }
   }
}

如果 Xcode 自动提示没有提供初始化语句，可以在刚刚的 BookInfo.swift 中自动补全代码，再剪切过来用。

运行后可以看到 dump 的数据已经出来了：

其实本文到这就差不多了，主要注意 JSON 中数组和这里生成 Model 的关系。最后附上一个小 Demo ，还没加搜索框，没用完解析的数据，将就看吧…_(:ｪ｣∠)_

项目可以参照这里 Donban-demo-with-JSONExport

]]> iOS基础 Swift iOS JSON Swift 算法查找篇笔记 /2016/10/12/Swift-Algorithms-1/

未完工
尚缺 k-th Largest Element、Selection Sampling、Union-Find

简介

这是一系列关于Swift语言的算法笔记，Swift版本为3.0，参考的教程来自 Swift Algorithms Club 。

所有的代码可以直接在Xcode的Playground中运行，前面的算法较简单，主要说说算法的基础、思路和一些Swift语言的特性，我十分推荐你把这里的算法独自实现一遍。

另外这里可以下载 Swift Algorithms Club 算法教程的Epub文件！ 点我下载

大 O 符号

大O符号（英语：Big O notation）是一种算法复杂度的相对表示方式。

这个句子里有一些重要而严谨的用词：

  • 相对(relative)：你只能比较相同的事物。你不能把一个做算数乘法的算法和排序整数列表的算法进行比较。但是，比较2个算法所做的算术操作（一个做乘法，一个做加法）将会告诉你一些有意义的东西。

  • 表示(representation)：大O(用它最简单的形式)把算法间的比较简化为了一个单一变量。这个变量的选择基于观察或假设。例如，排序算法之间的对比通常是基于比较操作(比较2个结点来决定这2个结点的相对顺序)。这里面就假设了比较操作的计算开销很大。但是，如果比较操作的计算开销不大，而交换操作的计算开销很大，又会怎么样呢？这就改变了先前的比较方式。

  • 复杂度(complexity)：如果排序10,000个元素花费了我1秒，那么排序1百万个元素会花多少时间？在这个例子里，复杂度就是相对其他东西的度量结果。

简单地说，O 表示法能给你一个算法的运行时间和它使用的内存量的粗略表示，这两种表示分为时间复杂度和空间复杂度，不过我们通常用 O 来表示时间复杂度，即一个算法执行的快慢。

大 O名字说明
O(1)常数这是最好的。 该算法不管有多少数据，总是花费相同的时间。 示例：通过索引查找数组的元素。
O(log n)对数特别好。 该算法将每次迭代的数据量减半。 如果你有100个元素，它需要大约7个步骤来找到答案。 有1000个，需要10个步骤。 100万个只需要20步。 即使对于大量的数据，这也是超快的。 示例：二进制搜索。
O(n)线性，次线性很好。 如果你有100个元素，需要100个步骤。 元素个数增加一倍，该算法花费的时间会是两倍。 示例：顺序搜索。
O(n log n)线性对数体面的表现。 这比线性稍差，但不太差。 示例：最快的通用排序算法。
O(n^2)平方有点慢。 如果你有100个元素，要执行100 ^ 2 = 10,000步骤。 加倍的元素数量使其慢四倍（因为2平方等于4）。 示例：使用嵌套循环的算法，如插入排序。
O(n^3)立方很慢。 如果你有100元素，会是100 ^ 3 = 1,000,000步骤。 输入大小加倍使其慢8倍。 示例：矩阵乘法。
O(2^n)指数特别慢。 你想避免这些算法，但有时你没有选择。 添加一个元素就会使运行时间加倍。 示例：旅行推销员问题。
O(n!)阶乘无法忍受的慢。 一百万年也运行不完。

简介

Linear Search，又称线性查找、顺序查找。在给定的数组中，我们会遍历所有的元素，并逐个对比是否与要找的特定元素相等，找到即停止查找，返回特定元素的索引，反之继续遍历对比直至对比完最后一个元素。

目标：从一个数组查找到一个元素

代码

1
2
3
4
5
6
func linearSearch<T: Equatable>(_ array: [T], _ object: T) -> Int? {
  for (index, obj) in array.enumerated() where obj == object {
    return index
  }
  return nil
}

放进playground中测试：

1
2
let array = [5, 2, 4, 7]
linearSearch(array, 2) //返回1

这是最简单的一个查找了，这里说说Swift的语言特性。

<T: Equatable> 中 T 指泛型，而 Equatable 是Swift标准库中定义的一个协议，该协议要求任何遵循该协议的类型必须实现等式符 == 及不等符 !=，从而能对该类型的任意两个值进行比较。所有的 Swift 标准类型自动支持 Equatable 协议。

Int? 中的 ? 是指返回的值是 Optional 的，如果查找找到值就返回索引值，找不到就返回 nil，Optional 特性让一个值能同时兼容两种情况。

enumerated()是一个实例方法，返回的是键值对 (n, x)，n 表示一个连续的从0开始的正整数，x 表示对应的元素。

1
2
3
4
5
6
7
8
9
let array = [5, 2, 4, 7]
for (index, obj) in array.enumerated() {//返回一个 array 拷贝
print("\(index) -> \(obj)")
}

//0 -> 5
//1 -> 2
//2 -> 4
//3 -> 7

性能

线性查找的效率是O(n)^Big O notation。在最差的情况，我们需要把全部元素都比较一边，最好的情况是我们第一次就查找到相同元素。

简介

Binary Search，就是著名、高效并应用广泛的二分查找算法。

目标：快速地从一个数组查找到一个元素

代码

通常情况下，Swift 的indexOf()方法已经足够好了：

1
2
3
let numbers = [11, 59, 3, 2, 53, 17, 31, 7, 19, 67, 47, 13, 37, 61, 29, 43, 5, 41, 23]

numbers.indexOf(43)  // returns 15

内置的indexOf()方法实现了一个线性查找，实现方式类似以下代码：

1
2
3
4
5
6
7
8
func linearSearch<T: Equatable>(_ a: [T], _ key: T) -> Int? {
    for i in 0 ..< a.count {
        if a[i] == key {
            return i
        }
    }
    return nil
}

测试：

1
linearSearch(numbers, 43)  // returns 15

这代码其实和一开始的线性查找差不多，但是线性查找效率不太高，平均都要搜索半个数组，如果数组足够大，查找将会变得很慢。

分而治之

凡邦之有疾病者，疕疡者造焉，则使医分而治之，是亦不自医也。
──清·俞樾《群经平议·周官二》

分而治之方法与软件设计的模块化方法非常相似。为了解决一个大的问题，可以：

  1. 把它分成两个或多个更小的问题
  2. 分别解决每个小问题
  3. 把各小问题的解答组合起来，即可得到原问题的解答。小问题通常与原问题相似，可以递归地使用分而治之策略来解决。

在本算法中，我们需要用这策略去不断的拆分数组，直到找到特定元素。另外二分查找的效率是O(log n)，也就是对一个有着1,000,000个元素的数组只要将近20步就能找到特定元素，因为log_2(1,000,000) = 19.9，十亿个元素也只需要30步就能完成查找！

听起来爽，但是二分查找有个缺点，就是数组必须是排序好的，不过这通常不是一个问题。

二分查找是怎么操作的呢？

  • 把排序好的数组平分成两部分，把特定元素与中间键比较，看特定元素应该会在数组左部分（较小）、右部分（较大）或直接相等。
  • 如果在数组左部分，则把数组切剩下左部分，继续进行二分查找。
  • 这里使用了递归，切分的是数组范围range

先来看看代码吧：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
func binarySearch<T: Comparable>(_ a: [T], key: T, range: Range<Int>) -> Int? {
    if range.lowerBound >= range.upperBound {
        // 如果经过不断的数组切分，导致范围下界大于等于范围上界，则说明找不到特定元素
        return nil

    } else {
        // 计算从哪划分数组
        let midIndex = range.lowerBound + (range.upperBound - range.lowerBound) / 2

        // 如果中间键（索引为midIndex）比特定元素大，说明特定元素在数组左部分(range.lowerBound ..< midIndex)
        if a[midIndex] > key {
            return binarySearch(a, key: key, range: range.lowerBound ..< midIndex)

        // 如果中间键（索引为midIndex）比特定元素小，说明特定元素在数组右部分(midIndex + 1 ..< range.upperBound)
        } else if a[midIndex] < key {
            return binarySearch(a, key: key, range: midIndex + 1 ..< range.upperBound)

        } else {
        // 如果中间键（索引为midIndex）与特定元素相等，说明找到啦！
            return midIndex
        }
    }
}

测试1：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
let numbers = [2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67]

binarySearch(numbers, key: 43, range: 0 ..< numbers.count)  // gives 13

//要查找的特定元素：43
//第1次查找
//--数组：[2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67]
//--查找范围：0..<19
//--中间键是：29
//第2次查找
//--数组：[31, 37, 41, 43, 47, 53, 59, 61, 67]
//--查找范围：10..<19
//--中间键是：47
//第3次查找
//--数组：[31, 37, 41, 43]
//--查找范围：10..<14
//--中间键是：41
//第4次查找
//--数组：[43]
//--查找范围：13..<14
//--中间键是：43
//--查找到，索引为13

测试2：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
let numbers = [2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67]

binarySearch(numbers, key: 24, range: 0 ..< numbers.count)  // gives nil

//要查找的特定元素：24
//第1次查找
//--数组：[2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67]
//--查找范围：0..<19
//--中间键是：29
//第2次查找
//--数组：[2, 3, 5, 7, 11, 13, 17, 19, 23]
//--查找范围：0..<9
//--中间键是：11
//第3次查找
//--数组：[13, 17, 19, 23]
//--查找范围：5..<9
//--中间键是：19
//第4次查找
//--数组：[23]
//--查找范围：8..<9
//--中间键是：23
//第5次查找
//--数组：[]
//--查找范围：9..<9
//--找不到！不干了！

这其中使用了 Comparable 协议，没有这协议，泛型和其他值是不能比较的， Comparable 协议就是说明T是可比较的。

测试1中用线性查找的话要查找13次，测试2中用线性查找要查找19次，而二分查找分别只用4次和5次就完成查找，能感受算法的威力吗~

迭代和递归

二分查找是递归的因为我们每次查找都是相同的逻辑，当然用迭代去实现将会更加有效率，因为不需要一次一次地调用函数（考虑下内存空间！）。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
func binarySearch<T: Comparable>(_ a: [T], key: T) -> Int? {
    var lowerBound = 0
    var upperBound = a.count
    while lowerBound < upperBound {
        let midIndex = lowerBound + (upperBound - lowerBound) / 2
        if a[midIndex] == key {
            return midIndex
        } else if a[midIndex] < key {
            lowerBound = midIndex + 1
        } else {
            upperBound = midIndex
        }
    }
    return nil
}

测试：

1
2
3
let numbers = [2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67]

binarySearch(numbers, key: 43)  // gives 13

最后

由于数组必须要先排序，排序和查找的时间加在一起算的话，二分查找耗时可能比顺序查找还多，因此二分查找适合在那种只用排序一次而要查找很多次的情况。

Count Occurrences

简介

Count Occurrences 就是计数，有时候我们需要计算一个数字出现的次数。当然我们可以用线性查找从头查到尾，这样这种计数的效率是O(n)，当然如果我们修改一下二分查找，也能把计数的效率提高到O(log n)，别忘了二分查找的条件是数组排序好。

目标：计算一个特定元素在一个排序好的数组中出现的次数

代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
func countOccurrencesOfKey(_ key: Int, inArray a: [Int]) -> Int {
  func leftBoundary() -> Int {
    var low = 0
    var high = a.count
    while low < high {
      let midIndex = low + (high - low)/2
      if a[midIndex] < key {
        low = midIndex + 1
      } else {
        high = midIndex
      }
    }
    return low
  }
  
  func rightBoundary() -> Int {
    var low = 0
    var high = a.count
    while low < high {
      let midIndex = low + (high - low)/2
      if a[midIndex] > key {
        high = midIndex
      } else {
        low = midIndex + 1
      }
    }
    return low
  }
  
  return rightBoundary() - leftBoundary()
}

测试：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
let a = [ 0, 1, 1, 3, 3, 3, 3, 6, 8, 10, 11, 11 ]

countOccurrencesOfKey(3, inArray: a)  // returns 4

//右边界第1次查找
//--划分范围后的数组：[0, 1, 1, 3, 3, 3, 3, 6, 8, 10, 11, 11]
//--索引为6的中间键：3
//--查找范围：0..<12
//右边界第2次查找
//--划分范围后的数组：[6, 8, 10, 11, 11]
//--索引为9的中间键：10
//--查找范围：7..<12
//右边界第3次查找
//--划分范围后的数组：[6, 8]
//--索引为8的中间键：8
//--查找范围：7..<9
//右边界第4次查找
//--划分范围后的数组：[6]
//--索引为7的中间键：6
//--查找范围：7..<8
//low值为：7
//---------------
//左边界第1次查找
//--划分范围后的数组：[0, 1, 1, 3, 3, 3, 3, 6, 8, 10, 11, 11]
//--索引为6的中间键：3
//--查找范围：0..<12
//左边界第2次查找
//--划分范围后的数组：[0, 1, 1, 3, 3, 3]
//--索引为3的中间键：3
//--查找范围：0..<6
//左边界第3次查找
//--划分范围后的数组：[0, 1, 1]
//--索引为1的中间键：1
//--查找范围：0..<3
//左边界第4次查找
//--划分范围后的数组：[1]
//--索引为2的中间键：1
//--查找范围：2..<3
//low值为：3

带print版二分查找计数

这里使用二分查找方式计数的技巧就是找到特定元素出现的左右边界，当然我们这次要查找的不是特定元素3，而是索引为2的1（左边界）和索引为7的6（右边界）。我们通过不断把左边界和特定元素比较，在第n-1次查找中，范围中的数组upperbound就是左边界，同理右边界在第n-1次查找中，范围中的数组lowerbound就是右边界。如果左边界和右边界都返回0，则代表找不到特定元素。

这是运用算法解决问题的一次实践。

跑个题，我在高中的时候是个小课代表，老师通常会把一叠改好的按学号排序的试卷交给我发放给全班同学。我记得同学各自的学号，查找的时候我会估摸着同学的学号，然后在一叠试卷中的相应位置抽出一张来。不是，放进去，试卷对应的学号小了，我就继续往后估摸位置再抽一张，直到找到为止，这很像二分查找吧！

Select Minimum / Maximum

最大值或最小值

Select Minimum / Maximum，选择最小值或最大值，也是我们会遇到的情况。

目标：在一个未排序的数组中找到最小值或最大值

🌰

举个栗子，我们要在一个未排序的数组[ 8, 3, 9, 4, 6 ]中找到最大值。

  1. 找到第一个元素8，存储为最大值
  2. 找到下一个元素3，比较现有最大值8，3<8，所以最大值8不变
  3. 找到下一个元素9，比较现有最大值8，9>8，所以最大值赋值为9
  4. 重复步骤直到所有元素遍历一遍

最小值和以上步骤类似，每次储存较小值即可。

代码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
func minimum<T: Comparable>(_ a: [T]) -> T? { 
  //本来swift2的写法是(var a:[T])直接定义一个可变数组..3.0不可用
  var array = a 
  guard !array.isEmpty else {
    return nil //如果数组不是不空，就不返回 nil....
  }

  var minimum = array.removeFirst()
  for element in array {
    minimum = element < minimum ? element : minimum
  }
  return minimum
}

func maximum<T: Comparable>(_ array: [T]) -> T? {
  var array = a
  guard !array.isEmpty else {
    return nil
  }

  var maximum = array.removeFirst()
  for element in array {
    maximum = element > maximum ? element : maximum
  }
  return maximum
}

测试：

1
2
3
let array = [ 8, 3, 9, 4, 6 ]
minimum(array)   // return 3
maximum(array)   // return 9
Swift标准库

然而 Swift 标准库已经给我们提供了查最大值或最小值的方法

1
2
3
let array = [ 8, 3, 9, 4, 6 ]
array.min()   // This will return 3
array.max()// This will return 9

最大值和最小值

如果我们要同时查找最大值和最小值呢？

🌰

如果我们要同时在一个未排序的数组[ 8, 3, 9, 6, 4 ]同时查找最大值和最小值，我们需要两两比较其中的元素。

  1. 找到第一个元素8，同时存储为最大值和最小值
  2. 由于数组中有奇数个数组，当移除元素8之后，剩下[3, 9]和[6, 4]这两对子数组
  3. 在第一个子数组[3, 9]中，比较两数大小。3较小，与当前最小值8比较，3<8，因此把最小值赋值为3。9较大，与当前最大值8比较，9>8，因此把最大值赋值为9。
  4. 第二个子数组[6, 4]中，比较两数大小。4较小，与当前最小值3比较，4>3，因此最小值不变。6较大，与当前最大值9比较，6<9，因此最大值不变。
  5. 最大值为9，最小值为3。
代码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
func minimumMaximum<T: Comparable>(_ a: [T]) -> (minimum: T, maximum: T)? {
  var array = a
  guard !array.isEmpty else {
    return nil
  }

  var minimum = array.first!
  var maximum = array.first!

  let hasOddNumberOfItems = array.count % 2 != 0
  if hasOddNumberOfItems {
    array.removeFirst()
  }

  while !array.isEmpty {
    let pair = (array.removeFirst(), array.removeFirst())
    if pair.0 > pair.1 {
      if pair.0 > maximum {
        maximum = pair.0
      }
      if pair.1 < minimum {
        minimum = pair.1
      }
    } else {
      if pair.1 > maximum {
        maximum = pair.1
      }
      if pair.0 < minimum {
        minimum = pair.0
      }
    }
  }
  return (minimum, maximum)
}

测试：

1
2
3
4
let array = [ 8, 3, 9, 4, 6 ]
let result = minimumMaximum(array)!
result.minimum   // This will return 3
result.maximum   // This will return 9

hasOddNumberOfItems确保数组一直能够被两两分组，实际上数组元素在 while 循环中一直在被两个两个地 remove，同时在做比较大小并赋大小值。

k-th Largest Element Problem

简介

k-th Largest Element Problem，是查找一个数组中第 k 个较大的元素的问题。

例如，第一个较大的元素是数组中的最大值，如果数组有 n 个元素，那么第 n 个较大的元素就是该数组的最小值，中位数就是第 n/2 个较大的元素。

naive solution

下面的算法是 semi-naive (较幼稚…?)的，从第一次排序好数组后，时间复杂度为O(n log n)，并且额外用了 O(n)的空间复杂度。

1
2
3
4
5
6
7
8
9
func kthLargest(a: [Int], k: Int) -> Int? {
  let len = a.count
  if k > 0 && k <= len {
    let sorted = a.sort()
    return sorted[len - k]
  } else {
    return nil
  }
}

在这方法中，a 是接受输入的数组，k 是返回第 k 个较大的数。

举个例子，设 k = 4，输入数组为
[ 7, 92, 23, 9, -1, 0, 11, 6 ]
一开始没有直接的办法去找第 k 个较大的数，首先我们需要排序好数组。
[ -1, 0, 6, 7, 9, 11, 23, 92 ]
现在我们需要拿到索引为a.count - k的元素。
a[a.count - k] = a[8 - 4] = a[4] = 9
当然了，如果要找第 k 个较小的数，我们会用a[k]。

A faster solution

这里有一种结合了二分查找和快速排序的算法，时间复杂度能达到 O(n)。

还记得二分查找不断的划分一半数组吗？这样能快速地靠近要查找的元素，这里我们也需要这么做。

快速排序也划分数组，它把所有较小的元素移到中轴的左边，较大的元素放在右边。

]]> iOS基础 算法 未完工 打造属于自己的RSS源 /2016/10/01/rss-tutor/ 阅读是一个主动寻求知识的过程，在如今碎片信息充斥着我们生活中的时代，我们需要清楚自己想要获取什么，把有限的时间放在消化信息上，而不是放在获取信息的途径上。如今我们可以通过各种 APP、公众号、聚合信息网站获取相对大众并符合自己的信息，但也有缺点：我需要下载这么多个 APP 去看新闻和文章吗？这些网站就拥有所有我想知道的吗？当然，像「即刻」、「Flipboard」这种阅读聚合类应用适当地缓解了这样的矛盾，但是这些信息源真的已经足够适合自己了吗？当初我找到了解决方法，也一直使用到现在，这个方法就是订阅 RSS 源。

本篇文章将简介 RSS，初步订阅适合自己的 RSS 源，并对于一部分不提供 RSS 订阅的网站，我们为其创建 RSS 源并订阅。

RSS

RSS（Really Simple Syndication，简易信息聚合）是一种消息来源格式规范，表达了「聚合真的很简单」这样的愿景，我们可以将其看作是一种定制个性化推送信息的服务。

macOS 客户端

我推荐 Reeder 3，因其功能足且美观，还支持iOS平台，付费。

另外 Leaf 也不错。

Windows 客户端

自己不使用 Windows，根据你必读的 RSS 订阅源有哪些？不负责地推荐 FeedDemon。

其他平台

RSS 平台提供了更广泛的服务，例如查找网站的 RSS 源并订阅，查看热门订阅源，管理分类订阅源等。优秀的 RSS 平台有 Feedly、Inoreader 等，由于不可描述的原因，国内这些平台连接速度会较慢，所以我给了一下两种推荐：

入门的话推荐国产的深蓝阅读，支持 iOS、Android 平台。

✨进阶推荐 Inoreader 官网 评测
Inoreader 也支持 iOS、Android、Windows Phone 平台，也有对应的浏览器插件。

Ioreader 推荐的第三方 RSS 阅读器。

RSS 阅读器只是显示 RSS 内容的一个平台，因此选自己喜欢的就好，我们的重点是如何获取适合自己的 RSS 源。

RSS源

常见网站 RSS 订阅位置

我们可以再去到自己常去的网站，看看有没有提供RSS订阅。例如少数派首页，我搜索rss，就找到了RSS源。

再例如在一些博客中，WIFI 一样的图标就是 RSS 订阅地址，不认识的话现在就记下来吧~

我们可以直接复制链接地址到阅读器中，这样就能简单的订阅 RSS 了。

播客

Feed Flipper 可以把 iTunes 的播客链接转成 RSS 源地址。

作者另外一个项目 Cloud Flipper 能把 SoundCloud 转成 RSS。

关于中文播客网站的订阅可以参考如何获取喜马拉雅、荔枝FM、考拉FM等中文播客RSS源。

Medium

Medium 是国外版的「简书」，里面有很多独特而优质的内容和天才般的作家，单独拿出来讲是因为我实在是太喜欢 Medium 了！

注：这里使用的是 Safari 插件（macOS 专属）—— Syndicate

RSS 搜索利器

如果不依赖平台自带的 RSS 源搜索功能，我们也有其他选择。

浏览器插件

前面介绍了 Safari 的 RSS 源查找插件 Syndicate，这里介绍一个 Chrome 浏览器的插件——RSS Subscription Extension。

微广场

微广场提供微信公众号的RSS订阅，免费用户可订阅10个内容源。

RSS源推荐

你必读的 RSS 订阅源有哪些？ 这里已经总结了很多优秀的订阅源。

例如：

名称RSS地址
知乎每日精选http://www.zhihu.com/rss
读书笔记http://www.write.org.cn/feed
褪墨http://feed.mifengtd.cn/

不再阐述太多，适合自己的才是最好的。

创建RSS源

部分网站可能比较看重 PV 值，就是希望用户主动进入他们的网站，或者其他原因不提供 RSS 源，这时候就需要我们使用 feed43 的服务来为我们扫平障碍。国内网站似乎不太热衷主动提供 RSS 订阅地址，这点国外做的较好。

Step 1

首先点进 feed43 右上角 Create Account 注册，登录完之后到主页点击 Create new feed 来创建自己的RSS源。接下来我将会用科学人|果壳网来做示范。

我们把http://www.guokr.com/scientific/复制进 Step 1的 Address，编码会自动选择，如果出现乱码可以尝试utf-8或其他编码，之后点击 Reload。

Step 2

我们可以看到页面的源码，看到这不要慌，这些都有套路。

像上面的图一样，红框中就是我们想要获取的单条信息。其中文章都是一块一块的，样子一样，变的只是其中的文字内容、图片地址，所以相应的代码块也是相似的。我们要清楚的就是想要获取的信息，例如：标题、图片、简介。

网页源代码是一层一层的，我们首先定位到大红框单个文章块的代码块。简单点可以直接 Ctrl+F 查询其中的标题，例如弱光子。

如果不容易找到文章所在的代码块的话可以搜索下一个文章标题来找到代码之间的分界点，现在总结下找到的代码。

1
2
3
4
5
6
7
8
9
10
11
<div class="article">
...无关代码...
<h3>
<a class="article-title" href="http://www.guokr.com/article/441758/" target="_blank" data-gaevent="scientific_title:v1.1.1.1:scientific">“弱光子人体安检仪”会损害健康吗？</a>
</h3>
...无关代码...
<a href="http://www.guokr.com/article/441758/" target="_blank" data-gaevent="scientific_image:v1.1.1.1:scientific"><img data-height="188" data-width="330" src="http://3.im.guokr.com/iTOiB3e1WalZmxiYApnzUIzxRoZcw6AHj2fjxVTRncNKAQAAvAAAAEpQ.jpg"></a>
...无关空格...
<p class="article-summary">成都双流机场使用的“弱光子人体安检仪”，其实是一种X射线成像装置，这种仪器会对人体健康产生什么影响，目前尚无法验证。而在安检中应该使用何种仪器，则不只是个科学问题。</p>
...无关空格...
</div>

你还可以用 Chrome 或其他浏览器来找到文章对应的代码块。

注意HTML标记符号是两两对应的，在截取的时候尽量保持完整，例如：<h3>标题代码</h3>、<a href...></a>、<p ..>简介内容</p>。

在feed43中，我们会用到两种代码块：{ % }和{*}，其中{ % }替换你想获取的内容，{*}用来省略无关代码。

注意，由于文章某些发布限制，{ % }大括号中间应没有空格，如下面代码所示

替换之后得到：

1
2
3
4
5
6
7
<div class="article">{*}
<h3>{*}
<a class="article-title" href="{*}" target="_blank" data-gaevent="scientific_title:v1.1.1.1:scientific">{%}</a>{*}
</h3>{*}
<a href="{%}" target="_blank" data-gaevent="scientific_image:v1.1.1.1:scientific"><img data-height="{*}" data-width="{*}" src="{%}"></a>{*}
<p class="article-summary">{%}</p>{*}
</div>

注意：

  • <div>到</div>之间就是一个层，注意保留对应文章代码块的完整
  • 两个标签中间有空格可以直接用{*}代替
  • 上面文章链接出现了不止一次，可以只找一个，其他忽略
  • 观察代码，图片宽高不一致，所以data-height和data-width处参数要用{*}忽略
  • class=""可以看作为小套路，一般代码块对应的参数都是一致的，例如标题对标题，内容对内容。
  • 网站中每个代码层之间可能会有冗余的空格存在（例如<div> 和下一个<div>之间），所以多用{*}替换你觉得出错的地方。（<div>...</div>{*}<div>...</div>）

点击 Extract，可以看到想要的信息都被找出来了，接下来就是用这些信息去组成RSS文章的界面。

Step 3

把对应的文章标题、文章链接标记块填到对应区域，当然你可以自定义每个文章的标题、链接、内容，这里我们用我们获取到的。

<center>...</center>表示居中代码块中的元素，<img src="">是图片标签，中间填入图片链接以显示图片，<br>表示换一行。你还可以在内容内再添加一个指向文章的链接，例如<a href="{ %2 }">链接显示文字</a>，更多标签可以参考HTML图片标签左下角的标签列表。

点击Preview来到 Step 4 收获成果。

Step 4

把地址添加到 RSS 阅读器上

我们可以直接点击标题跳转到网页（其他阅读器可能不一样），现在说说 feed43 的注意事项。

注意

feed43 爬取限制

免费的计划是六小时刷新一次 RSS 地址，也就是六小时才更新一次内容，有需要的可以购买计划，不过一般够用了。

feed43 爬取失败部分原因

  • 需要登录才看到内容的网页，例如一些论坛。
  • 内容由 JS 方式生成
  • 网站禁止了 feed43 ip 的访问，即403错误。
  • 网站不支持IE浏览器

RSS 全文输出

全文输出即是直接从文章链接提取内容，并替代与链接匹配的介绍内容，例如上文中科学人文章的简介和其文章内容。我在看 RSS 订阅源内容时一般先看标题与简介，对内容感兴趣的话才去查看原文内容，我认为这也是体现 RSS 获取信息效率的一方面。这里也给出 RSS 全文输出的教程，让大家有更多选择。

Free Full RSS

这里我用 Free Full RSS 做示范。

创建成功后，会得到新的 RSS 订阅地址。科学人 | 果壳网 全文输出RSS源地址

效果：

其他全文输出网站

名称网址
Full Text RSS Feed Builder完全免费
fivefilters抠门的免费计划，有付费计划。
FULL CONTENT RSS限时免费 KEY，过时失效

自制 RSS 源用途

学会了制作 RSS 源，那么我们能做什么有趣的事情呢？！

订阅自己关注的网站、有价值的博客、买买买信息、政府机关部门（？）、播客等等。

例如自己用 Feed43 做了些 RSS 源：
缺书网来获取买书优惠信息，RSS 源地址。
图灵社区关注新出版的技术书籍，RSS 源地址。

想要了解更多关于 RSS 可以看看这篇文章 使用 RSS 可以做什么你未曾想过的事。

总结

2013年 Google Reader 关闭，谷歌给的原因是用户流失，这最主流的RSS阅读器的退出似乎说明了 RSS 已经快要成为一个过时的阅读方式。这种阅读方式减少了网站和用户之间的交流，也不太适应短信息的节奏（想想你会用 RSS 刷微博吗？）。往大了看这是当今社会的节奏，人们更喜欢刷微博、刷朋友圈。海量的碎片信息会导致人们喜欢浅浅尝一口，而缺少深度的思考，逐渐迷失在海量的信息流中。生活离不开阅读，我们可能不能变成万事通，但我们可以更有效率地去获取自己想要的信息。

如果你看到这，或许可以考虑尝试下这种阅读方式？RSS 源贵精不贵多，先养成习惯，并判断这些信息对于自己的价值。

另外如果你根据本文成功创建了自己的 RSS 源，或者有疑问，请在本文评论中告诉我，欢迎分享你的 RSS 地址和经验。

]]> 工具癖 RSS Hexo 博客补丁 /2016/09/30/Hexo-patch/ 本博客部分修改内容

注：原文的主题为 Next，现在在使用 Even，所以配置可能有些地方不一样。

小建议

hexo new "标题" 的时候尽量取英文标题，在文章中再用 title: 指定中文标题，这样未来改标题好改，相应文章的多说评论也不会消失。

Github Pages 中增加 README.md

很多朋友的 hexo 博客都是建在 Github 上的，作为一个项目，README.md文件能够在 Github 上介绍博客的一些信息，但是贸然把文件放到 source 文件夹中会被 hexo 检测并转为 html 文档，我们在站点配置文件中跳过即可。

1
2
skip_render:
  - README.md

网站底部字数统计

安装 hexo-wordcount
npm install hexo-wordcount --save

在（博客主目录）/themes/next/layout/_partials/footer.swig中最后加上

1
2
3
4
<div class="theme-info">
  <div class="powered-by"></div>
  <span class="post-count">博客全站共{{ totalcount(site) }}字</span>
</div>

更多参考：hexo-wordcount

添加文章更新时间

修改（博客主目录）/themes/next/layout/_macro/post.swig文件，在<span class="post-time">...</span>标签后添加

1
2
3
4
5
6
7
8
{%if post.updated and post.updated > post.date%}
  <span class="post-updated">
&nbsp; | &nbsp; {{ __('post.updated') }}
<time itemprop="dateUpdated" datetime="{{ moment(post.updated).format() }}" content="{{ date(post.updated, config.date_format) }}">
  {{ date(post.updated, config.date_format) }}
</time>
  </span>
{% endif %}

根据博客配置文件中的 language 参数修改对应的语言配置文件（博客主目录）/themes/next/languages/zh_Hans.yml

1
2
post:
  updated: 更新于

修改主题配置文件（博客主目录）/themes/next/_config.yml，增加一行

1
display_updated: true

写文章的时候可以直接在文章开头设置更新时间

1
updated: 2016-10-14 10:53:09

没有这参数的话将会显示md文件的修改日期

本地搜索

安装 hexo-generator-search
npm install hexo-generator-search --save

编辑主目录下站点配置文件_config.yml加入

1
2
3
search:
  path: search.xml
  field: post

添加音乐

歌曲

在markdown文件中要添加音乐处加入iframe标签

1
<iframe frameborder="no" border="0" marginwidth="0" marginheight="0" width=330 height=86 src="http://music.163.com/outchain/player?type=2&auto=0&id=34578162&height=66"></iframe>

需要居中可以在外添加<center>标签

1
2
3
<center>
<iframe frameborder="no" border="0" marginwidth="0" marginheight="0" width=330 height=86 src="http://music.163.com/outchain/player?type=2&id=34578162&auto=0&height=66"></iframe>
</center>

其中id后数字为网易云音乐歌曲id，可以从Music处搜索歌名，例如搜索memories，我选择了MEMORIES - 『MEMORIES』- ALAN WALKER之后到达 http://music.daoapp.io/player?song=34578162 ，song后数字便是歌曲id。另外高度宽度可以自己根据博客样式更改，auto = 0是不自动播放，需要自动播放请改为auto = 1。

你也可以直接从网易云音乐官网中搜索到歌曲，再生成外链播放器。有些版权保护的歌曲或歌单不支持生成外链，可以直接像上面的方法一样查 id 改代码即可。

示例：

歌单

操作和上面一样，搜索后选择歌单，找到id再替换。

1
<iframe frameborder="no" border="0" marginwidth="0" marginheight="0" width=330 height=450 src="http://music.163.com/outchain/player?type=0&id=144236857&auto=0&height=430"></iframe>

示例：

其他高深玩法参考 163music-APlayer-you-get-docker

歌词

要带歌词的话需要用到适用于 Hexo 的 Aplayer。
如果歌词、音乐文件、音乐图片保存到博客服务器中，请参考上面的链接进去设置 post asset folders，这里用外链做例子。

安装 Aplayer：
npm install --save hexo-tag-aplayer

使用：

参数：

  • title : 音乐标题
  • author : 歌手名
  • url: 音乐文件路径
  • picture_url: 可选，音乐图片路径
  • narrow: 可选，狭窄的样式
  • autoplay: 可选，自动播放，不支持移动浏览器
  • width:xxx : 可选，前缀 width:，播放器的宽度 (默认: 100%)
  • lrc:xxx : 可选，前缀 lrc:，LRC 文件路径

例子：

建议使用七牛云存文件，直接用文件外链来设置，其中歌词文件内容参照 lrc 格式填写。

        
        
添加思维导图
利用之前App store 限免过的iOS版 MindNode，制作完导图之后，选择在MyMindNode上共享。
IMG_0165
上传文件后得到网址，打开后选择右上角导出按钮->Embed。
这里选择宽度和高度，再如添加音乐一样添加iframe标签即可，示例参考：2016年书单、公开课 。
本博客动态背景
在 百度云 下载particle.js，并移动到（博客主目录）/themes/next/source/js/src 文件夹下。
然后在（博客主目录）/themes/next/source/layout/_layout.swig中的最后body标签上添加
1
<script type="text/javascript" src="/js/src/particle.js"></script>
控制首页中文章显示量
在要显示的文字后添加<!--more-->，例如本文章：
1
2
3
4
5
6
7
8
---
title: Hexo 博客补丁
date: 2016-09-30 22:46:29
tags: [hexo]
---

本博客大部分的修改都在这里找到喔！
<!--more-->
]]>
      
      
      
        
            
             Hexo 
            
        
      
    
    
    
    
    
      利用iPad Pro学习方面的探索
      
      /2016/09/29/iPad-Pro%20study/
      
        
前几天趁着Apple教育优惠买了9.7inch的iPad Pro 附送耳机，还买了个smart cover。昨天在香港剁手了Apple pencil，对深挖iPad Pro潜能做了些探索，在这里总结下。
iPad Pro是否有必要买？
这个问题其实要从产品定位说起。对于我而言，我已经有iPhone 6 、Macbook 和 Kindle，我买了iPad Pro，就是想让它承担一些三者都不擅长或不方便的事情，例如看电子书，其中PDF为主(kindle对pdf体验差、我也不会在外出的时候带Macbook看，手机屏幕太小)、看视频(四个喇叭，大屏幕，爽！)、玩游戏(自己不太玩)、轻量的文字编辑(我没买键盘，因为觉得买了不如直接带Macbook)、手写笔记(本帖主题)、图片处理和绘画(真的很惊艳)等等。总而言之就是“带出去不麻烦的重量”+“一本书的大小”+“iOS系统”+“众多精致优秀的应用”。如果你觉得这些优点你愿意花五千多换取，那么你就不会买回来再抱怨iPad Pro也就那样。另外我入手的是128G，32G很容易满的相信我！
考虑到 iPad Pro 过剩的性能，如果没有触控笔的需求，可以考虑性价比更高的 iPad mini 或 iPad Air 2。
当然iPad Pro取代不了操作系统，它只是一种需求的折中处理方式，就像你不可能在其上进行大量的Excel编辑、视频编辑等，摆对iPad的位置，否则只会徒生烦恼。
应用方面我应该会另外写一帖出来，先放些链接待整理。
【知乎】怎样利用 iPad 学习？
【知乎】如何装备一个学术型的 iPad ？
【知乎】有哪些适合大学生使用的 app？
支持手写的笔记软件
iPad Pro上的笔记软件非常多，评测也多，我简单放放一些链接，诸君自取。下面软件没提价格的就是免费的。
【推荐】手写笔记软件Notability，Notes Plus，Noteshelf，Upad横评
【知乎】iPad 是否可以取代纸质笔记本？
【知乎】iPad 笔记应用 UPad、Noteshelf、goodNotes 哪个更值得买？
【知乎】学生党，用到 PDF 的时候较多，各位觉得 iOS 设备上相对好用的PDF应用有哪些？
【知乎】如何利用 iPad 高效学习？
手写笔记专题 Notability简评及和同类软件比较
经过自己试用Notability、Notes Plus、Upad3、GoodNotes，最后自己选用Notability。
Notability
iOS、Mac端都齐了，经常降价，有限免记录，50元。
优点：
  • 支持PDF导入
  • 录音功能强：能分段录音，录音还能索引到，点击录音会跳转到相应笔记记录(未测试)。
  • 编辑功能强：基本的标记功能都有，能插入基本的图片拍照、图形、Web片段和便签。长按会出现放大框供手写，编辑后也容易修改。
  • 导出功能强：支持大部分国外网盘，还支持WebDAV(这代表支持国内的坚果云网盘)，输出格式有PDF(压缩包内另有m4a格式录音)、RTF、Notability的原生格式。
  • 有Mac客户端，能在客户端上再次编辑。
  • 稳定
缺点：
  • 笔刷略少，只有铅笔和标记笔。
  • 导出不保留原文件
  • 模板少
  • 耗电
点评：
很全面的一款笔记软件，国外965的评价达到4星。其中录音功能是亮点，编辑功能也不弱，单单录音方面我觉得就是我心中最想要的笔记。
这个网站能够下载一些pdf模板…
下面其他软件就一句带过，或者点上面的链接进去看评测。
Notes Plus手写棒，Upad3模板多，GoodNotes较中庸。另外还有一款MarginNote听说是学术神器，做笔记还有思维导图…未测试，留个坑。
跨平台的笔记系统
笔记方面两大巨头印象笔记和OneNote分开说是因为他们比较适合当作一个“笔记系统”，就是我们可以通过上面几个软件搞定完一篇笔记之后可以放进去重新整理、分类、加标签等。上面说的笔记软件都是偏重手写和标记，其中的标记包括了PDF的标记和图片的标记，也就是我们可以通过一些扫描类的APP扫描PPT获得图片再在上面做手写笔记等(这里推荐Readdle家的Scanner Pro)，OCR(图片识别成文字)方面推荐刚限免过的TextGrabber。
笔记系统方面参考：
从卡片柜到OneNote
【知乎】如何构建自己的笔记系统？
其实涉及到印象笔记和OneNote的话有能有很多方面的对比了…
OneNote
优点：
  • 功能齐全
  • 如果想建立自己的知识体系(无限层次的笔记系统)
  • 丰富的格式支持
  • 免费
缺点：
  • iOS、Mac端功能不全
  • onedrive同步慢
我曾在知乎写过一篇关于OneNote的答案，想入门可以看看:)
【知乎】怎样用好 OneNote？
印象笔记
优点：
  • 界面精致
  • 功能够用，移动端也很方便
  • 同步快
  • 有丰富的第三方接口
缺点：
  • 笔记层次只有三层
  • 每月免费上传空间只有60M
  • 免费用户只能授权两台机器
  • 原生不支持markdown
总结
总而言之，OneNote特点是功能强大，印象笔记强调的是用得爽。
如果你喜欢层次分明，很注重每个笔记的结构，和关联的附件等等的强大功能，OneNote适合你。
如果你喜欢知识片段或文章的收集和搜索(还能搜索图中的文字)，互联网上文章的摘抄(印象笔记强大的剪藏插件)，喜欢小巧精致实用这些特色的，印象笔记适合你。
(自己还有点偏见就是笔记就要用大公司的，小公司动不动就倒闭这咋整？)
实际上，这两个笔记软件并不排斥，还能和很多应用配合。其中的OneNote更是可以单独作为笔记软件用，支持手写。另外我们还可以想象下日常生活中的应用：
实例一
我在图书馆看书，看到某一页，“唔，非常有感悟！”，我会用Scanner Pro去扫描下来，还想要在上面手写些笔记的话，导入到Notability补充一些笔记，搞定了我导出到印象笔记加标签分类。如果你习惯用强大的OneNote，还能把印象笔记当成第一步知识的分类，再在OneNote构建你的笔记系统。这部分在上面的从卡片柜到OneNote有很详细的说明。
实例二
我事先有老师的PPT讲义，我事先在电脑把PPT导入的Readdle家的Documents 5(文件管理应用，我iPad的文件都存在内，能随时导出到其他应用操作)，或者直接导入Notability，上课的时候我可以一边录音一边做些标记，课后根据录音整理笔记，再导入到你的笔记系统：印象笔记或OneNote。
在这里也介绍下PDF Expert，之前不和笔记软件放一起是因为他是一款优秀的PDF阅读器和标记软件。
PDF 阅读和批注
PDF Expert
PDF Expert是iOS版刚出时限免收的(没错就是炫耀！)，现价68元。
优点：
  • 支持大量PDF标记(Notability和其他笔记软件只支持手写的荧光笔，PDF Expert还支持选中文字标记)
  • 支持众多网盘，包括WebDAV(包括国内的坚果云)
  • PDF加密、压缩。
  • 阅读时的目录、书签都很人性化。
  • 长按能加录音、图像、文字、笔记。
  • 有Mac客户端，能在客户端进行二次编辑，
  • 支持简单的裁剪，文本语音等。
缺点：
  • 录音没有索引，只能自己记得插入录音时的文本位置去查找。
云同步方面建议国外用dropbox或其他的国外网盘，国内用坚果云(国内唯一支持WebDAV，介绍点我)，我现在百度云存资源，坚果云配合PDF Expert、Notability、Scanner Pro等软件存文档(注意文档和资源的差别)，OneDrive(配合hosts勉强能用)配合OneNote。
这款软件和Notability其实不太一样，Notability注重会议、课堂或其他录音场合时做笔记，还支持导入网页视图等(维基百科或你能想到的，缺点是不能对视图进行编辑)，而PDF Expert注重阅读的体验和对PDF进行一些更漂亮的批注。
其实阅读和标注方面还有很多不错的软件，例如几乎万能的GoodReader、专注批注的iAnnotate PDF等，但Readdle公司的PDF Expert足够精致和优秀！
Flexcil
Flexcil 是最近找到一款不错的免费应用，主要功能是对 PDF 文件提供标注和笔记需求。
优点：
  • 对 PDF 做的笔记(注意不是标注)能够整理到一起
  • 支持 Apple pencil
  • 手势强大，用手标记或复制文字图片到笔记中非常快捷
  • 对触控笔的支持同样强大方便
缺点：
  • 只主打对 PDF 写笔记的功能
扫描文档
扫描文档我推荐Readdle家的Scanner Pro, 易用，我就不横向对比其他应用了，大家看效果就好。最低曾到1元，现价25.
图一的蓝框是自动选中的，能够自己再次移动，另外Scanner Pro 支持OCR，不过又慢又差。还支持自动上传和处理流程，其中自动上传网盘除了国外的著名网盘外还有OneNote、Evernote、WebDAV(国内的坚果云)。缺点是在黄光下支持不好，尽量在光线充足下照相。
同类型的应用还推荐扫描全能王，如今还在限免，估计赚钱方向放在自家云空间上了。扫描效果可能没Scanner Pro好，但是OCR又快又棒！如果有这种需求的不妨选择他。他有自己的一套云空间供上传文件，另外上传还支持百度云网盘(亮点)，可惜不支持WebDAV。
对比
Scanner Pro
这应用的亮点是能在照相的时候动态框选文字，如果你手稳的话框选一小段时间会自动照相，很人性化。
照完相能在编辑的地方重选区域，我这里是直接按软件识别的文档照相po出来。
全能扫描王
这里是照完相自动选中的框，文档图是锐化过的，可以对比下。
文字识别就是意外之喜了。
总结
如果你们观察仔细的话，会看到Scanner Pro框选中上面一个带页码的横线是弯曲的，处理之后自动整平了。漫画处也能看出来，我认为他的算法比全能扫描王好，全能扫描王强在和TextGrabber相当的OCR文字且免费，但不支持WebDAV。
OCR识别文字
识别文字我使用TextGrabber，该应用前不久免费，现价30。
偶尔有用哈~
查询单词释义
查单词倚重的是词库，权威的词库对一些专业而言重要性更是不言而喻。在这里我推荐扩展性极强的欧路词典Pro，1元你买不了吃亏买不了上当(也有免费版的)，词库只要你找得到就是你的能耐。话不多说放截图：
依次是红宝书、柯林斯英汉双解、Dictionary.com的词典…还能加有道在线翻译啊牛津啊什么的。词库点我
词典方面还推荐免费的Merriam-Webster Dictionary，有道也不错。
思维导图
思维导图不多介绍，可以给自己整理思路脉络，iPad版的思维导图中有两款很优秀：Mindnode 68元，iThoughts 78元。前者漂亮，后者功能全，以前用的是后者，现在使用MindNode，因为可以把思维导图嵌入到博客~实例
Mindnode:
iThoughts:
免VPN上谷哥搜索
学习怎么能不谷鸽？！
原理：利用Surge+host配置实现免SS或VPN上谷歌，够用就好！ 配置点我
支持Dropbox、OneDrive等，不过稳妥起见，还是建议使用国内的网盘，因为前者ip容易被封(经测试Dropbox ip被封了不少…)。
浏览器
在iPad上，浏览器除了经常听见的Safari、QQ浏览器、Chrome、Opera等，其实还有不错的选择。
Safari有下载功能，但是却没有下载管理。这点下面两个浏览器都做的不错，自带扩展+下载。
Mercury
下载地址
支持部分扩展、下载列表、阅读列表、用户代理、无痕浏览等等。
唯一的不足是广告拦截功能要钱…
iCabMobile
下载地址 12元
这里的扩展名改成模块，也是为一些app提供了支持，下载功能、分页功能、设置中很多项可以调，具体请自己测试。
好用的画图工具
这里介绍的是Paper 53，留心官网的话你们应该能在Apple pencil的介绍页上看到这款app的推荐！
这简直就是标识利器！又萌又好看！
有时候我们不需要秒天秒地的Procreate、photoshop，只是简单的给一张图加批注，或者简单画画表格、图案，小巧的paper 53就是你的选择！
前不久里面的笔刷已经全部免费，此时不入手更待何时？！
特别是画一些简图、图表插入到你的笔记中，不要太方便！
计算工具
WolframAlpha 18元，需联网，学术神器，自己看功能。
有数 12元，颜值还行的计算器。
GeoGebro 动态教学软件，推荐给理工狗。
还有Matlab啊Calcbot啊自己去试吧不贴链接了。
课程表
iStudiez Pro 才18！！！！！
毕业了才有iPad我真是追悔莫及…这个应用也有Mac版，你可以把所有考试、老师、作业、课程表等信息录入，配合日历使用，能追踪你整个学期的学业情况！为了用得上这个应用我打算考个研！学生日常必备！！
阅读方式
这里再总结下哈，如今网上的电子书大多分扫描版和非扫描版(主要为PDF文件)，非扫描版就是所谓的文字版，玩kindle的应该都知道一些格式：亚马逊主推的Mobi、AZW，还有Epub和PDF(TXT无排版，不考虑)。
这些格式你可以直接用Kindle for iPad 看，除了PDF。
  • Epub，直接放iBooks上看，或者用多看阅读看也行，都能作批注，后者功能多些。Documents 5 也能看和批注，非常神奇…
  • Mobi，建议下个Calibre转换下格式，当然Kindle.app看也行。
  • AZW，同上。
  • PDF，用PDF Expert看，上文已经介绍很多，重点是能用笔批注。
对我而言如果是小说之类批注不会太多的我会直接多看上看，Kindle看也行，主要看批注能否导出。
如果有需要批注较多的文件，我就直接用Calibre转PDF放PDF Expert上看，Apple pencil批注也是很方便的~(主要是因为不这样用我会觉得那只七百多的笔白买了你懂吧)
分屏做笔记
我觉得分屏做笔记不如直接在PDF上批注或者iPad看文档电脑来写。当然真的要分屏的话紧凑是肯定的，12.9的体验也高不到哪去，这些事情还要靠应用来配合。下面我举个PDF Expert+Notability的例子大家看看：
右边Notability可以双指缩放笔记大小，手指长按或者点放大镜有缩放模式可以直接写，右边蓝色框是续写区域，在续写区域写完停顿后续写区域框会向右移动继续提供空白区域手写。
在左边的PDF Expert里右上角的按钮出现了之前没说过的文字重排功能(当然你也可以双指缩放去看文档)，但不支持扫描版(就是图片)。点击后的效果如下图：
格式没了，不过可以调字体和大小。
受屏幕限制，笔记体验的确会差点，纠结这方面的建议考虑是否经常在桌上使用，是否需要这么大屏幕而且分屏做笔记。前一个问题是考虑到12.9的重量会让你只想放桌面上用、后一个问题如果你真的真的很依赖分屏做笔记那就直接12.9不要纠结了。
通知面板
  • N stats 管理流量很直观，又免费！直接用iphone版的就好。
  • OmniFocus 258元，内购128元…其实以前感觉GTD的概念比较“玄学”，现在觉得还是挺好用的。生活中如果琐碎事太多，交给软件管理是很明智的选择，不过入门有学习成本，建议去少数派专题看看。
  • aTimeLogger 2 25元，能管理你生活的一切所用时间，比较适合对自己时间管理十分严格的同学把玩！
  • Calendars 5 45元，也是Readdle家的日历软件，限免入的(哈哈哈哈哈哈爽啊)，能自动同步日历中的事件。上面就是Keep健身制定计划时候自动导入的日历，这里能直接显示出来，一条龙服务！(不用原生日历是因为日历的widget在面板上太丑…)
时间管理
其实时间管理这块推荐我纠结了蛮久的，一是不是所有人都喜欢管理自己的时间，二是市面上To-do list类的应用数不胜数(优秀的有如“潮汐”，“BeFocus Pro”等)，三是这类软件主观性略强，每个人可能习惯的管理方式都不一样。今天我来推荐一个新生的，较全面的时间监控软件Timetrack.io。上面我推荐过aTimeLogger 2，这款软件则是同一个作者写的，功能更甚，加入了番茄钟，收费采取的是订阅制。测评点我
功能不多说，点测评看。我的用法主要是给自己每天定一个目标，例如今天要读四小时的书，那我可以开始读的时候用软件开始计时，其中还能选择番茄钟模式。通过这种碎片时间，达到完成小目标的效果。(当然吃饭睡觉这些不用监控啦，监控你觉得必要的就好，例如工作、学习等)
记录历史
目标页，你可以制定适合条件的监控时间(例如学习一块，也可以用标签计算)
软件一开始使用的时候可能有些复杂，但是有心整理自己生活的同学可以尝试下~
widget和aTimeLogger 2差不多，订阅是6个月18元。不过目前大家可以先下应用，注册完之后email给作者邮箱 support@timetrack.io 获取一年专业版使用资格(用英文哈，邮件里带上你的账户邮箱)。
有人说iPad没啥用，有人说iPad必不可少，我觉得这是iPad有没有真正进入到你生活中的区别。当然再好的应用也只是工具，关键还要看使用工具的人，再好的工具也拦不住你刷漫画看段子哈> w <
公开课
只推两个，从iPad体验和知识获取方面都是最佳应用！
网易公开课
网易良心作，大名鼎鼎得大家可能都耳闻过，但是实在是太！好！用！了！
支持离线下载(满速)、调整字幕、记录播放位置等，世界名校有名的课程很多都找得到！(多嘴一句学iOS的话可以去找找斯坦福白胡子爷爷的课哈，里面也有，iOS8的)当然也要感谢无私的字幕组！
Coursera
国外很火热的慕课平台，上完课还有认证证书！不过大多只有英文字幕，自己挑吧！
deadline 就是你学习的动力！
其他
类似的还有学堂在线，给小孩子学的课程推荐可汗学院，编程的还有慕课网。
慕课方面还推荐一个网站课程图谱，对慕课信息整理非常全面的一个网站，楼主只能帮你到这了！其他的自己挖掘吧哈！
稍后阅读
人们生活越发繁忙，很多好文章不能及时看，稍后阅读类应用解决的就是这类痛点，让人们暂时存下网页，空闲时再查看信息。
通常来说稍后阅读有两大应用：1、Instapaper  2、Pocket
这两类应用对多平台都有很好的支持， 电脑端有各种浏览器插件能够支持保存网页内容，其中 Pocket 还有 macOS 客户端。鉴于 Pocket 收费，而 Instapaper 前不久宣布免费，这里介绍 Instapaper。
收集英文文章的时候会提供更美观的字体
IMG_0193
应用内支持阅读文本信息，调整字体、字体大小、背景色，添加喜欢和归档文章
IMG_0190
另外国内部分网站提高了反爬虫技术，所以一些网站例如知乎、新浪文章等等都会阻止这类应用的抓取。
我自己写了一个 Workflow ，支持收集知乎答案、知乎专栏、微信公众号文章和其他普通网站的文章到 Instapaper，暂时不支持新浪文章，有需要的可以看看博客中另外一篇文章：用 Workflow 把知乎答案存到 Instapaper
PDF写笔记新选择
有天无意发现了这个免费的应用——Flexcil
之前说过 PDF Expert 是一个最佳的 PDF 阅读应用，但是这里 Flexcil 解决的痛点就是能在阅读 PDF 的同时在另外一块区域中写笔记！
偷个懒拿苹果商店的图片放在这…
这应用厉害的地方在于极其丰富的手势，和对 Apple Pencil 的支持，所以要玩转这个应用，手势一定要先熟悉！
IMG_0191
IMG_0192
IMG_0198
应用的功能就这么简单，笔记本里面可以新建笔记本，整理笔记，书籍里面存放 PDF 文件，这样的免费应用简直良心~
限免渠道
收集限免应用这个坏习惯导致我成为松鼠症患者，不过这样能让你尽量不花钱的前提下找到额外的适合你的应用。我忽然想说这个就是因为我几乎上面大部分应用都是限免和冰点入的，Notability经常冰点到1元，其他的也偶尔半价。
1、Appzapp Pro
iPad最方便最全面的搜集限免冰点应用，能看历史价格，可以加降价提醒。
2、爱应用助手
国内应用，主打精品应用限免冰点推荐。
3、AppShopper
和Appzapp类似的国外应用，功能差不多，缺点是只有iPhone版。
4、AppSo
国内应用，主打精品应用推荐，也有部分限免信息，缺点只有iPhone版。
5、少数派
国内网站，主打移动设备上应用测评，有时候也会有优惠活动和限免信息，有很多有深度的精品文章。
6、反斗限免
这个网站就厉害了，啥限免信息都有，Windows、Mac、iOS、电子书、字体、游戏等，udemy的课程限免也有…RSS订阅也方便。
保持专注
这是因为看到知乎的一篇答案让我有感而发。我们使用的软件太多，而不是太少
例如单单手写笔记应用就有这么多种，我们真的都需要吗？新闻资讯类我真的都要下几个客户端去看吗？
  • 我以前会在众多效率工具中迷失，追求做到极致的应用，后来发现浪费其上的时间还不如好好看一本书。
  • 我以前会迷茫的去寻求一款最适合自己的背单词应用和慕课应用，都下载下来，大部分却没打开过。
  • 我以前会在使用印象笔记和OneNote中纠结其功能，但是自己连笔记都很少记。
软件再好，但你不用，只会剩下自己莫名的成就感。
其实我上面说了这么多，不是让各位都用用看，而是节省时间，从我的帖子中直接找到最适合自己的应用，并使用下去，真正用在生活之中。
确定好自己的需求，选择最适合自己的应用，在适合的时间使用它，并享受它给你带来的便利，这就够了！
这里贴一张那位知乎答主的图
在各种场景下找到可以充分利用这段时间的专注力的方式，例如你想用坐地铁公交的时间拿来背单词(高度专注力)，但是效果不佳，我是不是可以看看TED(中度专注力)？当然每个人的使用方式都不一样，最重要是找到适合自己的，并履行下去。
总结
截至目前我也只是浅浅的说了自己围绕PDF文件学习的一些处理方案，也准备初步搭建自己的笔记系统，没有谈及一些学术方面和阅读方面的APP应用。另外Apple pencil很优秀，用到目前，没有手腕的误触现象。部分电容笔不支持屏蔽手腕误触，写字要悬着写，希望买触控笔的时候能考虑下这方面。题外话，画图方面的procreate配合Apple pencil简直爆炸，但是楼主不会画画啊TAT…
这里放一张上午寄过来的TEN DESIGN夹子照片，这样IPAD夹起来还能配合Dust Display作为Macbook的扩展屏！
这夹子叫“Ten One Design Mountie”
购买链接：Amazon 具体的样子看这 v2ex
夹子的力道是分摊的，对不同型号的设备也提供的不同的橡胶替换，总得来说没想象中那么脆弱。
对于笔记来说，iPad作为一个过渡产品，我建议应用在考虑实用的同时，兼顾考虑跨平台这一方面，同样应用跨平台，说明也能在电脑端编辑你的批注，扩展更多的功能等。中间的云储存按自己需求选择坚果云、百度云或dropbox。重点是稳定，易用！
非常感谢你读到这里，如果有什么见解和疑问也请在评论提出，我进行会逐渐补充点图片和加入自己对iPad学习的想法，充分利用iPad Pro改变自己。
最后
不要安装聊天应用！！！
不要安装聊天应用！！！
不要安装聊天应用！！！
]]>
      
      
      
        
            
             iPad 
            
        
      
    
    
    
    
    
      iOS学习资源集合
      
      /2016/09/24/iOS-learning-source/
      
        
总结个人在学习 iOS 的过程中遇到的精品资源，包含书籍、视频、网站等，一切等待我去探索的好物，主要以Swift 3.0为主。
视频
视频简介
Developing iOS 10 Apps with Swift斯坦福白胡子老爷爷最新的 iOS10 和 Swift 3.0 课程。创建于 2017年1月24日，预计时长9周。
Developing iOS 9 Apps with Swift斯坦福白胡子老爷爷的 iOS9 和 Swift 课程，现在 GitHub 只翻译到第三节课。
Developing iOS 8 Apps with Swift斯坦福白胡子老爷爷的 iOS8 和 Swift 课程，已经翻译完成 GitHub
SwiftV课堂国内一个Swift视频学习站
pomo.tv国外一个收集关于Mac、iOS 和 Swift视频的网站
Principle UI/UX Animation TutorialsSketchTV 在 Youtube 上录制的 Principle (交互原型设计软件) 视频，Principle 相关中文文档，官方文档
YouTube 频道
频道名简介
Brian AdventFollow me around and learn iOS and macOS Development by examples.
The Swift GuyOn this channel I put out tutorials, and other types of videos that are relevant to the Swift programming language.
CodeWithChrisLearn how to make an app with Swift and Xcode and how to turn your app idea into a reality!
Jared DavidsonIOS Developer / How to Make Apps
Lets Build That AppI’ll do my best to teach you how to build working apps from the AppStore, i.e. YouTube, Facebook, FB Messenger, etc.
Mark MoeykensFree iOS, Xcode and Swift tutorials!
Harry Ng主要是 OSX 的教程
书籍
书名简介
中文版 Apple 官方 Swift 教程《The Swift Programming Language》国人发起的官方教程翻译，目前更新到Swift 3.0 Github Start Developing iOS Apps (Swift)
iOS 10 by tutorialsraywenderlich精品书籍，付费
Beginning iOS 10 Programming with Swiftappcoda精品书籍，付费
iOS 10 App 程式設計實力超進化實戰攻略和楼上电子书对应的湾湾翻译版
iOS Programming: The Big Nerd Ranch Guide 5th EditionThe Big Nerd Ranch Guide 推崇困难式学习，该系列书的第四版中译获得豆瓣9.0的高分，目前第六版更新到iOS 10和Swift 3.0，十分值得学习，付费
Core Image for Swift学习 Core Image 框架，付费
Beginning iPhone Development with Swift 3 Exploring the iOS SDKApress精品书，本系列中译名为精通iOS编程。这版本讲iOS 10和Swift 3.0，付费
ios核心动画高级技巧iOS Core Animation: Advanced Techniques中文译本，由 OC 编写
KKBOX iOS/Mac OS X 基本開發教材這份教材是為了 KKBOX iOS/Mac OS X 開發部門的新人訓練所設計，目的是培養 出可以開發、維護 KKBOX 的 iOS 與 Mac OS X 版本，以及我們其他軟體產品的工程師。本书由 OC 编写
A GUIDE TO IOS ANIMATION 2.0一本关于 iOS 动画的独具匠心的交互式电子书，付费
Hacking With Swift免费在线 Swift 教程
Design+Code学习 iOS 开发设计最好的书籍，付费
Design Then Code学会设计和开发 iOS 应用，付费。中文翻译
网站
网站名简介
Swift Resources苹果官方为开发者提供的 Swift 学习资源
SwiftGG国内走心的Swift翻译组，翻译了很多高质量文章
Swift 官方网站Swift的开源阶段成果和使用指导
swift-evolutionSwift改进的最新进度
Ray Wenderlich专注苹果开发，创造大量有价值的开发资源如文章、视频、播客、书籍等。Swift文章区 iOS文章区
LearnSwift.tips国外一个学习Swift资源列表网站
objcobjc.io是一个专门为iOS和OS X开发者提供的深入讨论技术的平台,文章含金量很高。
objc中国objc翻译组，Github
APPCoda 台湾APPCoda 中教程的翻译，APPCoda 也是专注苹果开发的网站，有自己的电子书和开发教学文章，RSS
NSHipster翻译NSHipster 关注被忽略的 Objective-C、Swift 和 Cocoa 特性，这里是NSHipster的翻译组网站
CocoChina国内苹果开发中文社区
伯乐在线国内分享iOS和Swift开发的网站
各大iOS资源合集
Github简介
WWDC非官方的 WWDC app for macOS
trip-to-iOS6000+star的iOS学习资料整理
SwiftGuide1W+star的swift语言学习资源指南
TimLiu-iOS4000+star的iOS开发常用三方库、插件、知名博客汇总
awesome-ios-cn1W5+star的 awesome-ios 中译版
awesome-swift9000+star的Swift资源集合
open-source-ios-apps1W+star的开源iOS应用集合
swift-algorithm-club8000+star的Swift算法和数据结构集合，由raywenderlich创建。
15DaysofAnimationsinSwift2000+star学习用swift写动画的项目
iOS 开发学习笔记OneNote笔记，onepkg格式可在win版导入OneNote，笔记适合刚入门的 iOS 开发或有 C 、 OC 基础的同学。
iOSBlogCN中文 iOS/Mac 开发博客列表
iOS-Source-Code-Analyze深入解析 iOS 开源项目 http://draveness.me
相关的教程
名称简介
A Primer on Bézier Curves关于贝塞尔曲线的教程
some-ios-tutorials-with-swiftyrq110 翻译的一些使用 Swift 的 iOS 教程 Gitbook
RxSwift 系列教程靛青K 发布的 RxSwift 系列教程
iOS10 Day-by-Day一个介绍 iOS 10 API 的系列教程
iOS9 Day-by-Day一个介绍 iOS 9 API 的系列教程
《Xcode Server and Continuous Integration Guide》中文版使用Xcode Server进行持续集成，About Continuous Integration in Xcode的翻译，GitBook地址
ios-good-practicesiOS 开发最佳实践
iOS Human Interface GuidelinesiOS 人机界面指南，中文翻译
Swift编码规范来自 Ray Wenderlich 的 Swift 编码规范
Xcode Markup Formatting学习 Xcode 中如何使用 Markup Formatting
Quartz Composer学习QC 学习路线，关于 iOS 的一些动态交互
iOS 核心动画高级技巧iOS Core Animation: Advanced Techniques 的译本，由 OC 编写
Google Interview University一套完整的学习手册帮助自己准备 Google 的面试
RSS
我关注的一些 RSS 源，博客方面关注较少。
名称Feed 源
Swift – Ray Wenderlichhttps://www.raywenderlich.com/category/swift/feed
AppCoda 台湾http://www.appcoda.com.tw/feed/
Big Nerd Ranchhttps://www.bignerdranch.com/rss
Swift GG 翻译组http://swift.gg/atom.xml
移动开发前线http://mobilefrontier.github.io/index.xml
Medium-Swift Programminghttps://medium.com/feed/swift-programming/
Medium-iOS App Developmenthttps://medium.com/feed/ios-os-x-development/
掘金-iOShttps://api.prprpr.me/xitu/ios
IOS – 伯乐在线http://ios.jobbole.com/feed/
CocoaChinahttp://www.cocoachina.com/cms/rss.php
MrPeak杂货铺http://mrpeak.cn/feed.xml
OneV’s Denhttps://onevcat.com/feed.xml
干货集中营http://gank.io/feed
关于 Medium 上的文章 RSS 可以参考 RSS/Atom feed for medium.com blog tag。
<未完待续>
]]>
      
      
      
          
           iOS基础 
          
      
      
      
        
            
             Swift 
            
             iOS 
            
             Objective-C 
            
        
      
    
    
    
    
    
      阳历转阴历算法
      
      /2016/02/04/%E9%98%B4%E5%8E%86%E7%AE%97%E6%B3%95/
      
        概述
毕设要做万年历，但是对阴阳历了解不多，在此总结。
阳历
阳历，就是“太阳历”，是依据太阳的变化（严格来说，应该是地球围绕太阳运动时，人在地球上所观测到的太阳的变化）来修订的历法，以地球绕太阳一圈的时间为一年。
小时候老师教过：“一三五七八十腊，三十一天永不差”。
阳历有很强的规律性，每年12个月，1、3、5、7、8、10、12月都为31天，2月份平年28天，闰年29天，其余月份为30天。是否闰年也好算，能被100整除的年份中能被400整除的是闰年，不能被100整除的年份中能被4整除的是闰年。
阴历
简介
阴历，也就是“月亮历”，是依据月亮的变化来修订的历法。月亮每经历一次从圆到缺的循环，就是一个月。我国古人常把月亮叫做“太阴”，所以也叫“阴历”。
阴历全年12个月的总天数是354.3672天，它同季节变化的周期——阳历1年365.2422天)相差约11天。阴历分大小月：大月30天、小月29天。由于这样算与阳历有差别，会不能正确反映季节，我国就创造了一种带有一定阳历成分的阴历———“阴阳合历”，也就是农历，又叫夏历（夏朝开始的）。
阴历同阳历一年相差11天。因此，农历每3年需要闰（增加）1个月，5年闰2个月，7年闰3个月，19年闰7个月，周而复始，有闰月的那一年就被称为闰年。这种设置闰月的方法叫“19年7闰法”。
因此，阴历平年12个月，闰年13个月。
算法
这根本就没规律嘛！！
所以我们要从观测阴历的天文台处得到阴历数据，网上大多是1900年到2100年的数据(根本不是万年历啊摔(/ﾟДﾟ)/)。那么我们先从数据入手。
数据
网上搜集：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
0x04bd8,0x04ae0,0x0a570,0x054d5,0x0d260,0x0d950,0x16554,0x056a0,0x09ad0,0x055d2,//1900-1909
 0x04ae0,0x0a5b6,0x0a4d0,0x0d250,0x1d255,0x0b540,0x0d6a0,0x0ada2,0x095b0,0x14977,//1910-1919
 0x04970,0x0a4b0,0x0b4b5,0x06a50,0x06d40,0x1ab54,0x02b60,0x09570,0x052f2,0x04970,//1920-1929
 0x06566,0x0d4a0,0x0ea50,0x06e95,0x05ad0,0x02b60,0x186e3,0x092e0,0x1c8d7,0x0c950,//1930-1939
 0x0d4a0,0x1d8a6,0x0b550,0x056a0,0x1a5b4,0x025d0,0x092d0,0x0d2b2,0x0a950,0x0b557,//1940-1949
 0x06ca0,0x0b550,0x15355,0x04da0,0x0a5b0,0x14573,0x052b0,0x0a9a8,0x0e950,0x06aa0,//1950-1959
 0x0aea6,0x0ab50,0x04b60,0x0aae4,0x0a570,0x05260,0x0f263,0x0d950,0x05b57,0x056a0,//1960-1969
 0x096d0,0x04dd5,0x04ad0,0x0a4d0,0x0d4d4,0x0d250,0x0d558,0x0b540,0x0b6a0,0x195a6,//1970-1979

0x095b0,0x049b0,0x0a974,0x0a4b0,0x0b27a,0x06a50,0x06d40,0x0af46,0x0ab60,0x09570,//1980-1989
 0x04af5,0x04970,0x064b0,0x074a3,0x0ea50,0x06b58,0x055c0,0x0ab60,0x096d5,0x092e0,//1990-1999
 0x0c960,0x0d954,0x0d4a0,0x0da50,0x07552,0x056a0,0x0abb7,0x025d0,0x092d0,0x0cab5,//2000-2009
 0x0a950,0x0b4a0,0x0baa4,0x0ad50,0x055d9,0x04ba0,0x0a5b0,0x15176,0x052b0,0x0a930,//2010-2019
 0x07954,0x06aa0,0x0ad50,0x05b52,0x04b60,0x0a6e6,0x0a4e0,0x0d260,0x0ea65,0x0d530,//2020-2029
 0x05aa0,0x076a3,0x096d0,0x04bd7,0x04ad0,0x0a4d0,0x1d0b6,0x0d250,0x0d520,0x0dd45,//2030-2039
 0x0b5a0,0x056d0,0x055b2,0x049b0,0x0a577,0x0a4b0,0x0aa50,0x1b255,0x06d20,0x0ada0,//2040-2049

0x14b63,0x09370,0x049f8,0x04970,0x064b0,0x168a6,0x0ea50, 0x06b20,0x1a6c4,0x0aae0,//2050-2059
 0x0a2e0,0x0d2e3,0x0c960,0x0d557,0x0d4a0,0x0da50,0x05d55,0x056a0,0x0a6d0,0x055d4,//2060-2069
 0x052d0,0x0a9b8,0x0a950,0x0b4a0,0x0b6a6,0x0ad50,0x055a0,0x0aba4,0x0a5b0,0x052b0,//2070-2079
 0x0b273,0x06930,0x07337,0x06aa0,0x0ad50,0x14b55,0x04b60,0x0a570,0x054e4,0x0d160,//2080-2089
 0x0e968,0x0d520,0x0daa0,0x16aa6,0x056d0,0x04ae0,0x0a9d4,0x0a2d0,0x0d150,0x0f252,//2090-2099

0x0d520 //2100
解析
十六进制的数据要转成二进制解析
二进制形式
xxxxxxxxxxxxxxxxxxxx
20-1716-1312-98-54-1
1-4: 表示当年有无闰年，有的话，为闰月的月份，没有的话，为0。
5-16：为除了闰月外的正常月份是大月还是小月，1为30天，0为29天。
注意：从1月到12月对应的是第16位到第5位。
17-20： 表示闰月是大月还是小月，仅当存在闰月的情况下有意义。
例子1
1980年的数据是（十六进制）：0x095b0
二进制：0000 1001 0101 1011 0000
00001001010110110000
20-1716-1312-98-54-1
无意义1-4月5-8月9-12月非闰年
最右边的0000表示1980年没有闰月，所以最左边的0000也没有意义。从1月到12月的天数依次为：30、29、29、30、29、30、29、30、30、29、30、30，共12个月。分别对应16-5位的二进制数，1对30，0对29。
例子2
2017年的数据是：0x15176
二进制：0001 0101 0001 0111 0110
00010101000101110110
20-1716-1312-98-54-1
闰大月1-4月5-8月9-12月闰六月
从1月到12月的天数依次为：29、30、29、30、29、29(六月)、30(闰六月)、29、30、29、30、30、30，共13个月。
使用
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
//传回农历 y年的总天数
//例如2015年农历有354天
private static int yearDays(int y) {
//348为12个月都为平月29日的年总天数
   int i, sum = 348;
   for (i = 0x8000; i > 0x8; i >>= 1) {
       // i >>= 1 化为二进制向右移一位并赋给原值
       // 循环内从16-5位内找 有1则为大月 总天数+1
       if ((lunarInfo[y - 1900] & i) != 0)
           sum += 1;
   }
   return (sum + leapDays(y));
}

//传回农历 y年闰月的天数
private static int leapDays(int y) {
   if (leapMonth(y) != 0) {
       if ((lunarInfo[y - 1900] & 0x10000) != 0)
           //闰大月
           return 30;
       else
       //闰小月
           return 29;
   } else
       return 0;
}

//传回农历 y年闰哪个月 1-12 , 没闰传回 0
private static int leapMonth(int y) {
   //用4-1位与“1111”进行与运算
   return (int) (lunarInfo[y - 1900] & 0xf);
}

//传回农历 y年m月的总天数
private static int monthDays(int y, int m) {
   if ((lunarInfo[y - 1900] & (0x10000 >> m)) == 0)
       return 29;
   else
       return 30;
}

//传回农历 y年的生肖
public String animalsYear(int year) {
   final String[] Animals = new String[]{"鼠", "牛", "虎",
   "兔", "龙", "蛇","马", "羊", "猴", "鸡", "狗", "猪"};
   return Animals[(year - 4) % 12];
}

日历重点是公历和阴历的转换，明后弄懂了再撰文。
转换弄懂了的话到时候结婚算八字都不用翻风水书了呢(￣▽￣)
课外扩展：
八字神煞合婚算法，看看自己中了几枪
]]>
      
      
      
        
            
             算法 
            
        
      
    
    
    
    
    
      iOS 应用程序生命周期
      
      /2015/11/03/iOS-application-life-cycle/
      
        应用生命周期
作为应用程序的委托对象，AppDelegate类在应用生命周期的不同阶段会回调不同的方法。
五种状态
iOS的应用程序一共有5种状态:
  • Not Running(非运行状态)。应用没有运行或被系统终止。
  • Inactive(前台非活动状态)。应用正在进入前台状态，但是还不能接受事件处理。
  • Active(前台活动状态)。应用进入前台状态，能接受事件处理。
  • Background(后台状态)。应用进入后台后，依然能够执行代码。如果有可执行的代码，就会执行代码，如果没有可执行的代码或者将可执行的代码执行完毕，应用会马上进入挂起状态。有的程序经过特殊的请求后可以长期处于Backgroud状态。
  • Suspended(挂起状态)。处于挂起的应用进入一种“冷冻”状态,不能执行代码。如果系统内存不够,系统就把挂起的程序清除掉，为前台程序提供更多的内存，应用会被终止。
iOS应用状态图
应用回调的方法和本地通知
以下是状态跃迁过程中六个应用回调的方法和本地通知：
应用程序的运行状态
我们可以在“AppDelegate.m”文件中查看应用程序运行状态的方法，并为其添加日志输出，其中注释为官方注释，注意理解( ͒•ㅈ• ͒)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
#import "AppDelegate.h"

@interface AppDelegate ()

@end

@implementation AppDelegate

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:
(NSDictionary *)launchOptions {
    // Override point for customization after application launch.
    NSLog(@"%@", @"application:didFinishLaunchingWithOptions:");
    return YES;
}

- (void)applicationWillResignActive:(UIApplication *)application {
    /* Sent when the application is about to move from active to inactive
    state. This can occur for certain types of temporary interruptions
    (such as an incoming phone call or SMS message) or when the user quits
    the application and it begins the transition to the background state.*/
    /* Use this method to pause ongoing tasks, disable timers,
    and throttle down OpenGL ES frame rates. Games should use this method
    to pause the game. */
    NSLog(@"%@", @"applicationWillResignActive:");
}

- (void)applicationDidEnterBackground:(UIApplication *)application {
    /* Use this method to release shared resources, save user data,
    invalidate timers, and store enough application state information to
    restore your application to its current state in case it
    is terminated later.*/
    /* If your application supports background execution,
    this method is called instead of applicationWillTerminate:
    when the user quits.*/
    NSLog(@"%@", @"applicationDidEnterBackground:");
}

- (void)applicationWillEnterForeground:(UIApplication *)application {
    /* Called as part of the transition from the background to the
    inactive state; here you can undo many of the changes made on
    entering the background.*/
    NSLog(@"%@", @"applicationWillEnterForeground:");
}

- (void)applicationDidBecomeActive:(UIApplication *)application {
    /* Restart any tasks that were paused (or not yet started) while
    the application was inactive. If the application was previously in
    the background, optionally refresh the user interface.*/
    NSLog(@"%@", @"applicationDidBecomeActive:");
}

- (void)applicationWillTerminate:(UIApplication *)application {
    /* Called when the application is about to terminate.
    Save data if appropriate. See also
    applicationDidEnterBackground:.*/
    NSLog(@"%@", @"applicationWillTerminate:");
}

@end
打开程序：
按下Home键：
从界面重点图标打开程序：
非运行状态——应用启动场景
场景描述：用户点击应用图标的时候，可能是第一次启动这个应用，也可能是应用终止后再次启动。该场景的状态跃迁过程见下图，共经历两个阶段3个状态：Not running→Inactive→Active。
  • 在Not running→Inactive阶段。调用application:didFinishLaunchingWithOptions:方法，发出 UIApplicationDidFinishLaunchingNotification通知。
  • 在Inactive→Active阶段。调用applicationDidBecomeActive:方法，发出UIApplicationDidBecomeActiveNotification通知。
Active和Inactive的切换
应用程序在前台时有2种状态：Active和Inactive。大多数情况下，Inactive状态只是其他两个状态切换时出现的短暂状态（不是任意两个状态之间的切换都会进入Inactive），如打开应用，它会从Not Running先进入Inactive再进入Active；如前后台应用切换时，Inactive会在Active和Background之间短暂出现。
但是也有其他情况，Active和Inactive可以在前台运行时进行切换，比如系统弹出Alert，此时应用会从Active切换到Inactive，直到用户确认再返回Active；再如用户拉下通知页，也会发生Active和Inactive的切换；还有来电但拒接、双击Home键但返回原应用等都不进入Background，而只是在Active和Inactive切换，这个在下面会讲到~
在应用状态跃迁的过程中，iOS系统会回调AppDelegate中的一些方法，并且发送一些通知。实际上，在应用的生命周期中用到的方法和通知很多。
点击Home键——应用退出场景
场景描述：应用处于运行状态(即Active状态)时，点击Home键或者有其他的应用导致当前应用中断。该场景的状态跃迁过程可以分成两种情况：可以在后台运行或者挂起，不可以在后台运行或者挂起。根据产品属性文件(Info.plist)中的相关属性 Application does not run in background 是与否可以控制这两种状态。如果采用文本编辑器打开Info.plist文件该设置项对应的键是UIApplicationExitsOnSuspend。
程序只要符合以下情况之一，只要进入后台或挂起状态就会终止：
  • iOS4.0以前的系统
  • app是基于iOS4.0之前系统开发的。
  • 设备不支持多任务
  • 在Info.plist文件中，程序包含了UIApplicationExitsOnSuspend 键。
app如果终止了，系统会调用app的代理的方法 applicationWillTerminate: 这样可以让你可以做一些清理工作，你可以保存一些数据或app的状态。这个方法也有5秒钟的限制，超时后方法会返回程序从内存中清除。
注意：用户可以手工关闭应用程序。
添加了UIApplicationExitsOnSuspend键，并设置Yes。打开应用后再按Home键退出：
状态跃迁的第一种情况
应用可以在后台运行或者挂起，共经历3个阶段4个状态:Active → Inactive → Background → Suspended。
  • 在Active→Inactive阶段。调用applicationWillResignActive:方法,发出UIApplicationWillResignActiveNotification通知。
  • 在Inactive→Background阶段。应用从非活动状态进入到后台(不涉及我们要重点说明的方法和通知)。
  • 在Background→Suspended阶段。调用applicationDidEnterBackground:方法，发出UIApplicationDidEnterBackgroundNotification通知。
当应用程序进入后台时，我们应该做些什么呢？
保存用户数据或状态信息，所有没写到磁盘的文件或信息，在进入后台时，最后都写到磁盘去，因为程序可能在后台被杀死，释放尽可能释放的内存。
applicationDidEnterBackgound: 方法有大概5秒的时间让你完成这些任务。如果超过时间还有未完成的任务，你的程序就会被终止而且从内存中清除。如果还需要长时间的运行任务，可以调用  beginBackgroundTaskWithExpirationHandler方法去请求后台运行时间和启动线程来运行长时间运行的任务。
应用程序在后台时的内存使用
在后台时，每个应用程序都应该释放最大的内存。系统努力的保持更多的应用程序在后台同时运行。不过当内存不足时，会终止一些挂起的程序来回收内存，那些内存最大的程序首先被终止。
事实上，应用程序应该的对象如果不再使用了，那就应该尽快的去掉强引用，这样编译器可以回收这些内存。如果你想缓存一些对象提升程序的性能，你可以在进入后台时，把这些对象去掉强引用。
下面这样的对象应该尽快的去掉强引用：
  • 图片对象
  • 你可以重新加载的 大的视频或数据文件
  • 任何没用而且可以轻易创建的对象
在后台时，为了减少程序占用的内存，系统会自动在回收一些系统帮助你开辟的内存。比如：
  • 系统回收Core Animation的后备存储。
  • 去掉任何系统引用的缓存图片
  • 去掉系统管理数据缓存强引用
状态跃迁的第二种情况
应用不可以在后台运行或者挂起，共经历4个阶段5个状态:Active → Inactive → Background → Suspended→ Not running 。
  • 在Active→Inactivd阶段。应用由活动状态转为非活动状态(不涉及我们要重点说明的方法和通知)。
  • 在Inactive→Background阶段。应用从非活动状态进入到后台(不涉及我们要重点说明的方法和通知)。
  • 在Background→Suspended阶段。调用applicationDidEnterBackground:方法，发出UIApplicationDidEnterBackgroundNotification通知。
  • 在Suspended→Not running阶段。调用applicationWillTerminate:方法，发出UIApplicationWillTerminateNotification通知。
iOS在iOS 4之前不支持多任务，点击Home键时，应用会退出并中断；而在iOS 4之后(包括iOS 4)，操作系统能够支持多任务处理，点击Home键应用会进入后台但不会中断(内存不够的情况除外)。
应用在后台也可以进行部分处理工作，处理完成则进入挂起状态。
挂起重新运行场景
挂起状态的应用重新运行。该场景的状态跃迁过程如图2-26所示,共经历3个阶段4个状态:
Suspended → Background → Inactive → Active。
  • Suspended→Background阶段。应用从挂起状态进入后台(不涉及我们讲述的这几个方法和通知)。
  • Background→Inactive阶段。调用applicationWillEnterForeground:方法，发出UIApplicationWillEnterForegroundNotification通知。
  • Inactive→Active阶段。调用applicationDidBecomeActive:方法,发出UIApplicationDidBecomeActiveNotification通知。
内存清除——应用终止场景
场景描述：应用在后台处理完成时进入挂起状态（这是一种休眠状态），如果这时发出低内存警告，为了满足其他应用对内存的需要，该应用就会被清除内存从而终止运行。
内存清除的时候应用终止运行。内存清除有两种情况，可能是系统强制清除内存，也可能是由使用者从任务栏中手动清除（即删掉应用）。内存清除后如果应用再次运行，上一次的运行状态不会被保存，相当于应用第一次运行。
在内存清除场景下，应用不会调用任何方法，也不会发出任何通知。
参考文章
iOS应用程序生命周期(前后台切换,应用的各种状态)详解
《iOS开发指南：从零基础到App Store上架（第2版 ）》
]]>
      
      
      
          
           iOS基础 
          
      
      
      
        
            
             iOS 
            
             Objective-C 
            
        
      
    
    
    
    
    
      欢迎来到萤火之森
      
      /2015/10/28/%E6%AC%A2%E8%BF%8E%E6%9D%A5%E5%88%B0%E8%90%A4%E7%81%AB%E4%B9%8B%E6%A3%AE/
      
        1
欢迎来到 萤火之森！
欢迎👏
今天很荣幸的加入了全球最大的同性交友网站，并且很感谢hexo模板的作者给了我这个机会能让我在Github Pages上建立自己的博客，很感谢next主题的作者iissnan，这主题让我耳目一新，让我知道前端的无限能力。（我这里想输入颜文字，脑一抽去app store搜应用…真的有唉！！(▰˘◡˘▰) ~）
总而言之呢~ 微博广告多，微信自拍多，facebook没人看。
ヾ(◍’౪`◍)ﾉﾞ
人呐，总有那么一瞬间，想把身边所经历、所学习、所感悟给写下来，埋在某个地方。
既然进了程序员的坑，就是学到死的命 …"〆´◡ฺ｀｡） ，萤火之森这名字蛮喜欢的~ 不做那为万世开太平的人，只为代码之神继之所学。乌拉！！！！！！！
博客更改记录
16年10月13日 增加部署至Coding，国内直接走Coding Pages，速度提升。
]]>