时间很快，如今已经是2021年伊始了。虽然已经很久没有写过文章，但是，面对2020年，我总还纠结着要说些什么。

2020最大的主题就是变化。不仅有意料之中的变化，更多是意料之外的变化。

疫情

说到变化，总也绕不过的就是疫情。

我的2020年是以一次滑雪作为开始，在那场滑雪之后，我还在畅想在结束毕业论文写作之后，毕业前的时间我应该怎样度过，是要趁着有闲逛上大半个中国，还是省一些钱躲在实验室里啃啃买来一直没读的大黑书。

放假回家后，就开始盘算：工作后肯定没法在家待太长时间，不妨这次放假在家里多待几天，多陪陪家人（多睡睡懒觉），不到交论文的那天，坚决不回学校。

然而现实远超我的想象，不仅交论文的那天没能回学校，甚至到了毕业那天，都不能回去。

事情的起因还是一月份开始听说有一种类似SARS的病毒已经开始悄然传播，那时候感觉病毒还很远，和我没有关系；直到除夕前一天，武汉封城，全国人民在家过年，我开始知道它的名字叫新冠病毒，而且十分严重，和我们每个人每天的生活息息相关；后面，我又通过躲在手机屏幕后的暗暗观察，发现这件事情不仅改变了我的计划，改变了中国人的生活，甚至整个人类都与此息息相关；而直到一年后的今天，疫情依旧不知疲倦地在全球蔓延。

是呀，仿佛离我们很遥远的事情，在短短一年内变成了每个人所面临的现实，这对于一直沿着一条可被经验预测的道路前行的我来说，的确是一种震撼。

另外还有一个比较深刻的感受，是“正常化偏误”。之前听的比较多的一个例子是一个小镇旁边有一座火山，那里的居民居然在火山爆发以后觉得问题不会那么严重，没有逃跑，导致伤亡惨重。我想我一定不会这么蠢，一定要最开始就逃走。但是，当疫情来临的时候，我在最开始就觉得应该是要买口罩了吧？但是又觉得会不会没这么糟，现在就去买口罩会不会显得自己很异类？就这样拖延了两天，发现城里已经几乎买不到正常价格的口罩了。过后，我才醒悟过来，原来自己也随时可能变成眼看着火山灰把自己掩埋的那个人，这也是我2020年学到的第一个教训：当你觉得应该行动的时候，就一定要开始行动，不要在乎别人眼里你是怎样的。

病情

在疫情不太紧急的四月份，在家赋闲，于是给自己送给一台手术作为生日礼物。人生第一次手术还挺成功，我的胆囊和矿泉水瓶盖大的结石永远地离我而去。不多说，希望看到这里的每一个人都能按时吃早饭，健康饮食吧。

毕业

在开始读研的时候，我预想了无数种毕业时候我会做些什么，至少应该和卤蛋同学补上之前本科毕业没拍成的毕业照。但万万没想，这次毕业没有聚餐，没有毕业照，甚至都没有亲手拿到打印出的沉甸甸的论文，只有腾讯会议上大家还算灿烂的笑容（毕竟所有同学都顺利毕业）。

毕业以后我的一个愿望是等疫情结束，能回到陪伴我三年时间的小灰楼302去逛逛，找潘老师以及师弟师妹们聊聊天，可惜变化永远都是猝不及防——当时老纪说的多年前位于澡堂三层的上古实验室居然变成了我们如今的新去处。

工作

人呐就是不知道，自己就不可预料。我绝对不知道，我作为一个搞网络搞SDN的，怎么就来做云原生了。

说实话，福厂的工作节奏还是有点快，让摸了七年鱼的我花了很久去适应了。不过好在我遇到了一群非常nice的同事，特别是几位师兄，从他们那里学习到了非常密集的知识，让我从一个无法无天的野生程序猿变成了一个（自认为）还算及格的底层工程师。

这半年来，我的工作主要集中在和容器沙箱相关的技术之中，从一个虚拟化的门外汉，到看见了门槛之所在。另外，通过熟读Firecracker源码，也让我对Rust和microVM有了一个全新的认识。

读书or视频

今年唯一的遗憾就是没有阅读太多的书，特别是很多书读到一半就放下，并没有读完。分析是两个方面的原因：一是由于生活模式的切换，自由时间变少，时间碎片化严重，没有相对较长的时间和精力来进行阅读；另一方面是B站使用时间显著增长，妄图通过对知识区视频的学习跳过读书快速获取知识。

这里可以借这个机会稍微聊聊我对B站的体会：在深度使用B站接近1年后，就知识区和科技区来看，UP主的数目持续增多，优质稿件也不断变多，这就吸引我每天花费大把的精力在观看所关注UP主的视频上，甚至都不敢去刷推荐流，很担心又看上哪个新的up主，想去追视频但是已经没有时间了。我不知道这是好事还是坏事，但是对B站来说绝对是一件好事，每天都会冒出许多新的创作者，分享许多奇奇怪怪的新内容，而且这也的确能够吸引观看者花费更多注意力在B站上面。这一切的一切，让我想起了刚上大学时候的微信公众号，嗯，熟悉的感觉又回来了。

还是说回读书，我认为能够进行较长时间专注的阅读，特别是大部头的书，对我来说还是十分重要的。因为视频中的知识点往往都比较零散，而且很难讲深，构成体系，只能作为谈资泛泛去听。所以，我认为系统性地读书还是十分必要的，接下来我一定得压缩每天在B站上花费的时间，重新回来读书中来。

希望接下来的一段时间，先把剩下的半本《红楼梦》读完。

一点思考

论2020年对我影响最大的人，莫过于温铁军和他的《八次危机》了。在B站看见他的视频后，发现他的思想理论和主流观点差别很大，但是又有一种吸引我不断去看他的演讲去思考他说过的每一句话的魅力。原因很简单，我逐渐意识到，他说的可能才是对的。

回想起来，印象最深的莫过于“代价”和“矛盾”，大到国家发展现代化需要代价，维持现有制度也需要代价，小到个人，过上好日子需要代价，不被别人支配更需要代价。大概就是只要你想要改变现状，就总要付出点你当下拥有的资源，以便让你在未来的时空里拥有你想要的资源。之前中学老师的一句口头禅“出来混，总是要还的”大概就是这个现象的通俗版本吧。和代价孪生的是“矛盾”，因为代价总是需要牺牲一些来成全另一些，那么牺牲者与被牺牲者之间就会产生矛盾，那么我想这也可能也是导致矛盾在不同的时期动态变化的一个原因。正因为代价和矛盾的不断转换，推动了事物的不断发展，个人是这样，国家和世界也都是这样。

结语

昨天午睡的时候做了一个梦，梦见自己在搬家，搬家的对象中有一个大箱子，很难搬走。箱子里装的是一个游戏，游戏的在一些城堡中发生，城堡的主人既希望继续战斗，赢得更大的城堡，又担心自己进攻的时候自己的城堡被别人抢走。我纠结了很久，决定让主人公继续战斗，并终于搬走了这个箱子。但是做完这个决定后，感受到了无尽的空虚与劳累，就仿佛做了一个多大的选择一样。紧接着，突然惊醒，意识到这个城堡小游戏的经历原来可能是自己前一天晚上没睡好而在纠结是否要起床的投影。可真的就只是这样么？我想也不尽然。总之，既然已经在梦中做出了选择，就不如在2021继续践行吧。

Flags

最后是每年的保留节目，立Flag，希望明年都能完成：

• 分享至少5篇较为优质的内容
• 对领域内技术的认知上有明显提升，具有一定的专业性和深度
• 维持学习状态，保持对世界的好奇心，对世界的认知上更进一步
• 阅读，至少5本较篇幅较长的著作，减少看视频的时间
• 锻炼身体，体重维持在80kg以下
• 多陪陪家人，每周和家人通话

使用Qemu对Linux内核进行调试是一种较为便捷的方式，近日进行了一番实践，并将大致步骤与其中一些小坑记录了下来。

环境

由于放长假赋闲在家，所以手头只有一台装有MacOS的MBP可用，而Linux内核的开发与调试使用Linux环境下会比较方便，所以就使用VMware Fusion创建了一台安装有Ubuntu 18.04系统的虚拟机。由于编译Linux内核及相关软件需要的资源较多，所以为虚拟机配置了双核CPU、2GB内存和20GB磁盘空间（笔记本本身资源有限），但实际使用（特别是物理内存和硬盘）捉襟见肘，于是又在系统中添加了3GB的SWAP内存并扩容了20GB的磁盘空间（其实还是不太够）才解决问题。

编译Linux内核

首先，尝试对内核进行编译，在编译前需要使用通过KConfig启动内核的调试配置。

下载内核源码

由于Linux内核代码量非常大，且由于国内网络大家都懂的原因，所以的下载内核源码是一项较为复杂的体力活动。

第一种方法是直接Clone Linux源码的Git仓库，当前，其仓库大约为3.7GB。在通过内核官网(https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/)或者GitHub(https://github.com/torvalds/linux)进行Clone的过程中，经常会遇到连接断开的情况，非常捉急。而如果通过国内镜像源，如清华Kernel Git镜像进行Clone的时候，最开始速度飞快，但是后面速度会越来越慢。因此，如果不像我这样头铁的话，不建议使用这样的方式下载Kernel的源码。

另一种较为简单的方式是下载特定版本的源码，这些源码的tarball包可以从内核官网或者镜像站获得。我在实验中使用的内核版本为4.19，gz压缩包的大小约为150MB。

配置内核

如果是使用Git Clone的方式获取的内核源码，需要通过git checkout v4.19将内核源码置位4.19版本。

在编译之前，首先需要安装相关的依赖（如果提示缺少其它依赖按需安装即可）

1

sudo apt install libncurses5-dev libssl-dev bison flex libelf-dev gcc make openssl libc6-dev

在编译之前，需要使用KConfig对内核编译选项进行配置，在内核文件夹下，使用make menuconfig（命令行界面）或make gconfig（基于gtk的图形化界面）对内核进行配置。在配置时，需要打开如下选项：

1
2
3

Kernel hacking -> Kernel debugging
Kernel hacking -> KGDB:kernel debugger
Kernel hacking -> Compile time checks and compiler options -> Provide GDB scripts for kernel debugging

并保证如下选项没有开启：

1

Kernel hacking -> Compile time checks and compiler options -> Reduce debugging information

在退出配置后，可以发现内核目录中生成了一个名为.config的配置文件。

编译内核

配置完成后，就可以使用make编译内核，在多核CPU中可以使用make -jx启动多线程编译（x为启动的线程数）。

如果一切正常，在漫长的等待后，内核将编译完成。编译会在内核根目录下生成vmlinux 文件，它是编译出的原始内核文件（含有调试信息），而会在arch/x86/boot/bzImage目录下生成压缩后的内核文件（当然是在编译的体系结构为x86的情况下）。

编译安装GDB和Qemu

由于内核调试所需的GDB和Qemu版本可能会比apt源中的版本高，所以，最好自行编译安装这些软件。

编译安装GDB

首先，从官网(http://www.gnu.org/software/gdb/download/)下载GDB的源码并解压（这里使用的是官网中最新的GDB 9.1），需要注意的是，网上有些博客中提到需要修改GDB的源码，其实是不必要的，报错的原因是没有自动检测到目标体系结构的类型，所以只需设置该类型即可。

解压后进入GDB文件夹，执行下列指令，即可完成编译安装：

1
2
3
4
5

mkdir build 
cd build
../configure
make -j4
sudo make install

最后，通过使用gdb -v确定gdb的版本是否为9.1，如果是，则说明安装成功。

编译安装Qemu

首先，从官网下载(https://www.qemu.org/download/#source)Qemu的源码并解压（这里使用的是Qemu 5.0.0）。

由于在Ubuntu GUI中使用Qemu还需要多媒体图形库SDL，所以需要首先使用apt安装sdl：

1

sudo apt install libsdl2-2.0-0 libsdl2-dev libsdl2-gfx-1.0-0 libsdl2-gfx-dev libsdl2-image-2.0-0 libsdl2-image-dev 

进入Qemu目录后，执行./configure检查系统配置并生成Makefile，需要注意检查的时候是否检测到了SDL的支持，其输出的部分内容如下所示：

1
2
3
4
5
6
7
8

profiler          no
static build      no
SDL support       yes (2.0.8)
SDL image support yes
GTK support       no 
GTK GL support    no
VTE support       no 
TLS priority      NORMAL

然后执行make && make install即可完成Qemu的编译与安装。

在安装完Qemu后，会生成如qemu-xxx和qemu-system-xxx的一系列命令，用于仿真不同体系结构的用户态应用和操作系统，可以通过如qemu-system-x86_64 --version命令确认Qemu是否安装成功。

制作ROOTFS

在内核启动后需要一个带有init程序的rootfs，所以在调试内核前需要制作一个rootfs。

构建基于initrd的rootfs

initrd是一种位于内存的根文件系统，它可以在硬盘被驱动之前载入系统。这里为了方便，只将一个简单的程序写入initrd，并将其作为init程序（即系统启动后的第一个用户态进程）。除此之外，也可以使用busybox作为initrd中的init程序。

创建一下简单的c程序，命名为fakeinit.c。

1
2
3
4
5
6
7
8
9
10
11

#include <stdio>
int main()
{
    printf("hello world!");
    printf("hello linux!");
    printf("hello world!");
    printf("hello linux!");
    fflush(stdout);
    while(1);
    return 0;
}

然后使用gcc编译这段代码，在编译的时候需要使用静态链接，并且如果如果在配置内核的时候没有启用64位支持（64-bit kernel），则需要将代码编译为32位程序，方法是在gcc命令行中添加-m32选项。

编译命令如下：

1
2

gcc --static -o fakeinit fakeinit.c
gcc --static -o fakeinit fakeinit.c -m32 (编译为32位可执行程序)

在编译后，使用cpio程序进行打包：

1

echo fakeinit | cpio -o --format=newc > initrd_rootfs.img

这样，一个基于initrd的rootfs即制作完成。

构建基于硬盘镜像的rootfs

这里使用busybox构建基于硬盘镜像的rootfs。其中，busybox是一个集成了数百个Linux常用命令和工具的单个软件，在对内核进行测试的时候非常方便，号称“The Swiss Army Knife of Embedded Linux”。

下载编译busybox

首先，从官网(https://busybox.net/downloads/)下载busybox的源码并解压（这里使用的是最新的busybox-1.31.1）。

在解压并进入busybox文件夹后，首先使用make gconfig或make menuconfig对其进行配置，需要启用如下选项：

1

Settings -> Build Options -> Build static binary (no shared libs)

如果需要将其编译为32位版本，则需要将-m32命令填入如下选项：

1
2

Settings -> Build Options -> Additional CFLAGS
Settings -> Build Options -> Additional LDFLAGS

与内核相同，在退出后，会在目录中生成一个名为.config的配置文件。

然后，使用make命令编译busybox。

使用busybox创建rootfs

首先，创建一个空的磁盘镜像文件，然后将其格式化：

1
2

dd if=/dev/zero of=./busybox_rootfs.img bs=1M count=10
mkfs.ext3 ./busybox_rootfs.img

然后，挂载刚刚创建的磁盘镜像（需要使用loop设备）：

1
2

mkdir rootfs_mount
sudo mount -t ext3 -o loop ./busybox_rootfs.img ./rootfs_mount

接着，在busybox源码目录中，将编译好的busybox目标文件安装到rootfs文件夹：

1

make install CONFIG_PREFIX=/path/to/rootfs_mount/

最后，配置busybox的init，并卸载rootfs：

1
2
3
4
5

mkdir /path/to/rootfs_mount/proc
mkdir /path/to/rootfs_mount/dev
mkdir /path/to/rootfs_mount/etc
cp busybox-source-code/examples/bootfloppy/* /path/to/rootfs_mount/etc/
sudo umount /path/to/rootfs_mount

现在，一个基于busybox的rootfs磁盘镜像就制作成功了。

使用Qemu和GDB调试内核

使用Qemu启动内核

由于编译的内核体系结构为x86，所以使用qemu-system-x86_64程序来载入并启动内核。

如果使用intird作为rootfs，则具体命令为：

1
2
3
4
5
6

qemu-system-x86_64 \
  -kernel ./linux/arch/x86/boot/bzImage \  # 指定编译好的内核镜像
  -initrd ./rootfs/initrd_rootfs.img \  # 指定rootfs
  -serial stdio \ #指定使用stdio作为输入输出
  -append "root=/dev/ram rdinit=/fakeinit console=ttyS0 nokaslr" \ # 内核参数，指定使用initrd作为rootfs，禁止地址空间布局随机化
  -s -S # 指定Qemu在启动时暂停并启动gdb server，等待gdb的连入（端口默认为1234）

如果使用磁盘镜像作为rootfs，则具体命令为：

1
2
3
4
5
6

qemu-system-x86_64 \
  -kernel ./linux/arch/x86/boot/bzImage \
  -hda ./rootfs/busybox_rootfs.img \ # 指定磁盘镜像
  -serial stdio \
  -append "root=/dev/sda console=ttyS0 nokaslr" \ # 内核参数，指定root磁盘，禁止地址空间布局随机化
  -s -S

使用GDB调试内核

最后一步，由于刚刚Qemu开启了远程调试，所以只需要将gdb通过连入即可：

1

gdb ./linux/vmlinux # 指定调试文件为包含调试信息的内核文件

如果此时直接在gdb调试器中使用target remote:1234连入Qemu的gdb server，则会出现报错Remote ‘g’ packet reply is too long，这是由于gdb没有正确识别调试目标的体系结构造成的（有些博客认为需要修改源代码屏蔽这个错误，实际上是不必要的），所以只需要在远程attach之前使用set arch i386:x86-64:intel设置目标体系结构即可。

例如，你希望在start_kernel函数设置断点进行调试，则在启动Qemu后，gdb的命令如下：

1
2
3
4
5
6

gdb ~/linux/vmlinux
(gdb) set arch i386:x86-64:intel
(gdb) add-auto-load-safe-path ~/linux
(gdb) target remote:1234
(gdb) b start_kernel
(gdb) c

可以发现，内核在启动后被中断在start_kernel函数上。

后记

内核文档

在内核的文档中，有一篇详细讲解了如何使用GDB调试内核。

该文档的最新版本可见于内核的官网：https://www.kernel.org/doc/html/latest/dev-tools/gdb-kernel-debugging.html。

而具体的版本就需要在内核源码中编译文档了，例如html版本的文档可以使用make htmldocs进行编译，在启动HTTP服务器后，可以在浏览器中进行访问，例如，http://127.0.0.1:8000/dev-tools/gdb-kernel-debugging.html。

参考来源

本文参考了两篇较为优质的博客：

• 用QEMU来调试内核 – 亲身体验篇
• 利用VS Code+Qemu+GDB调试Linux内核

最近在项目中遇到需要在 NodeJS 中调用 C++代码的问题，在此略作总结。

主要方案

在 NodeJS 中，和其他语言编写的代码通信主要有两种方案：

• 使用 AddOn 技术，使用 C++为 NodeJS 编写一个拓展，然后在代码中调用其他语言所编写的源码 or 动态库
• 使用 FFI（Foreign Function Interface）技术，直接在 Node 中引入其他语言所编写的动态链接库

在对这两种方式进行比较后，发现这两种方式各有优劣。

首先，AddOn 技术比较通用，它可以使用 C++代码来拓展 Node 的行为，很多库都是使用这种方式来完成一些比较底层操作（比如和操作系统的一些通信）的。但是它写起来比较麻烦，要编写一个 C++项目，还要按照 NodeJS 的规范 export 相应的函数，而且每次安装的时候都需要进行编译（以适应本地 Node 的版本）。如果只是调用一个 DLL，那就还需要在项目里重新包装一遍 DLL 的接口。

如果使用 FFI 技术，限制就会比较多,首先，它只能调用其他动态库，如果你想使用 C/C++完成更多功能的话，还需要再封装一层 DLL，另外，它只支持_cdecl调用约定（也就是 DLL 在导出的时候一定要标记用_cdecl编译命令），不支持_stdcall或者_fastcall调用。但是调用起来就会很方便，可以直接在 JS 代码中声明 DLL 的接口就可以了。

综上比较，如果只调用第三方 DLL（而且恰好是_cdecl导出），使用 FFI 就再合适不过了（虽然性能可能会有一定的损失，而且调试起来会有困难）。

其实，从理论上来讲，FFI 也是基于 AddOn 技术的，只是它可以帮你把在 JS 中定义的接口直接转换成 C 语言的接口，并利用 NodeJS 的 Buffer 内存，将其同载入的 DLL 共享。当然由于 FFI 的这种通用性，也导致了一定的性能损失。

下面就以在 Windows 平台上使用 FFI 为例，简单聊一下如何使用 NodeJS 和 C++编译而成的 DLL 通信吧。

FFI 使用准备

安装 NodeJS

可能你的环境中已经有 NodeJS 了，但是，如果是最新版本，在安装 FFI 的时候会出现各种兼容性的问题（比如编译无法通过，虽然已经有人提供了 patch，但是还没有被 merge 进主分支，为了避免出现 bug，还是暂时不用为妙）。所以可以安装 LTS 版本代替。

另外，还需要注意要调用的 DLL 是 32 位还是 64 位的，Node 的版本需要和 DLL 的版本匹配。因为如果 64 位 Node 调用了 32 位的 DLL，是无法成功装载的，反之亦然。

安装 Windows 的 C++工具链

这里有两种方案：

• 安装 Visual Studio，并安装相应的工具链。如果使用 VS 2019 版本的话，需要安装 C++桌面开发和 Windows SDK 相关的工具（Node v10 现在只支持 v141 版本的 MSVC），这种方式便于后续的调试工作（虽然也很艰难）
• 在安装 Node 之后，使用管理员权限运行 Powershell，并全局安装 windows-build-tools，参考命令 npm install --global --production windows-build-tools

安装 node-gyp

node-gyp 是一个 Node 中基于 gyp 的跨平台的编译工具，用于编译其他库。

在安装的时候，需要使用 VC 的工具链，所以如果没有把工具链放在全局变量中，需要打开 VS 的Developer Powershell安装，该命令行一般在开始菜单的 Visual Studio 文件夹中。

参考命令：npm install -g node-gyp

安装 FFI 及 REF

下面的步骤依旧需要 VC 工具链，所以可能依旧需要在Developer Powershell中执行（建议常备该窗口，后面只要涉及到编译安装的命令都需要用到）。

安装 FFI 及相关工具的时候如果没有 VC 工具链，则会直接安装二进制代码，这样可能会出现包的 ABI 版本和 NodeJS 的 ABI 版本不符合的情况（在下面的 Tips 中会提到）。

现在，切换到项目的文件夹中，安装下面的包。其中，ffi 包是用以支持 FFI 功能的，ref 包是用以支持指针功能（原理是通过 Node 的 Buffer 内存，将 JS 的结构和 C 结构相互转换的）的，ref-*是用以支持高级结构的（比如数组和结构体）

1
2
3
4

npm install ffi -s
npm install ref -s
npm install ref-array -s
npm install ref-struct -s

除此之外，如果想支持 VC 中常见的 wchar 类型，还可以安装 ref-wchar 包。

安装 electron-rebuild 包

如果是 electron 项目，还推荐安装 electron-rebuild 包，该包可以遍历 node_modules 目录下的所有包，并将其重新编译。

然后，推荐在 package.json 中配置 electron-rebuild 的命令：

1
2
3

"scripts": {
  "rebuild": "./node_modules/.bin/electron-rebuild"
}

之后执行在需要重新编译的时候只需要执行npm run rebuild即可。

使用方式

简单概览

可以查看如下官方示例：

1
2
3
4
5
6

var ffi = require('ffi')

var libm = ffi.Library('libm', {
  ceil: ['double', ['double']]
})
libm.ceil(1.5) // 2

在引入 FFI 后，使用 FFI 调用了 libm 库（可能这个示例只能在类 Unix 系统中使用），一般拓展名为 libm.so，系统会在系统目录下搜索这个动态库，并将它使用动态链接器载入到 node 进程中。

接着，程序声明了 libm 库中的一个方法 ceil（向上取整），其中，该函数的返回值是 double 类型（第一重数组中的 doule），而该函数的入参也是一个 double 类型的值（第二重数组中的 double）。

最后，直接使用libm.ceil方法即可调用动态库中的函数，并返回正确的值。

这只是一个 FFI 的简单用例，更复杂的用法（主要是异步调用和回调函数）可以参考 FFI 的实例页https://github.com/node-ffi/node-ffi/wiki/Node-FFI-Tutorial。

类型

FFI 的类型系统其实记住了 ref 库的类型，ref 库的类型系统基于 NodeJS 的 Buffer 内存，可以根据 Buffe 中数据的类型对 Buffer 内存中的数据进行访问和修改。

ref 自带的数据类型都是基本类型，比如 int 类型、bool 类型或者 string 类型。所有类型可以参考 ref 的wiki。

ref 中的多数类型都有简写，比如ref.types.int可以简写为int。

需要注意的是，char*可以写为string，对应的 ref 类型为ref.types.CString。值得注意的是，string 在 JS 中是基本类型，在 C 中却是引用类型。

对于指针类型，ref 提供了一个方法ref.refType()来得到，比如int*类型就可以使用ref.refType('int')得到。当然，为了省事，也可以直接用int*表示。

而对指针解引用，ref 库也提供了一个deref()方法。只要在对应类型的变量上使用该方法，就可以得到指针指向内容的变量。比如一个指向int*类型的 JS 变量 a_pointer，那么我们如果想得到具体的整数值，就可以使用a_pointer.deref()方法。

相反的，如果想获取某个变量的地址，就需要对某个变量使用ref()方法。

需要注意掌握类型与变量值的区别，使用ref.types、ref.refType或者是下面会提到的ref_struct({...})获得的类型，而如果想获得某个类型的变量，有两个方法，一个是从 FFI 函数的返回值中获取，另一个是在 Buffer 中开辟一个空间，来存放类型为所获得类型的变量，下面会具体讲到。

如果需要在 NodJS 的 Buffer 中开辟长度为某个类型的空间，可以使用ref.alloc()函数，只要将类型名传入即可。比如，想开辟一个类型为 int 的内存，就可以使用ref.alloc('int')得到。

此外，还有以下几点需要注意：

• 如果开辟类型为字符串的内存，推荐使用方法 ref.allocCString，其参数为一个 JS 的字符串。因为 C 语言的字符串在末尾有一个\0标识符，所以用这个方法可以更安全地得到 C 字符串。
• 如果在 C 语言中值为 NULL，则在 JS 中对应的值为 ref.NULL。
• 如果遇到指针类型，可以统一用'void'或者ref.types.void表示。
• 如果要表示一个函数的指针，可以使用'pointer'表示。

对于复合类型，比如数组或者结构体，ref 库本身没有提供相应的支持，需要使用 ref-array 和 ref-struct 库来实现，具体可以参考这两个库的文档。

另外，对于 Windows API 中较为常见的宽字符 wchar 类型，也有一个基于 ref 的库 ref-wchar 进行支持。

最后，附上 ref 的文档http://tootallnate.github.io/ref/，具体的 API 都可以在这里进行查阅。

调用外部符号

假设我们有如下 C 代码（并把它写的复杂一些）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

/* main.c */
typedef struct t_s_t{
    int a;
    char b;
} t_s;

__declspec(dllexport) int add_one(int a) {
    return a + 1;
}

__declspec(dllexport) void struct_test(t_s** t_s_p) {
    *t_s_p = (t_s *)malloc(sizeof(t_s));
    (*t_s_p)->a = 1;
    (*t_s_p)->b = 'd';
}

上面的代码中，声明了一个结构体t_s，以及两个函数add_one和struct_test。其中，函数前面的__declspec标记表示声明该函数为导出函数。VC 默认导出 C 函数时是用_cdecl调用约定。

其中，add_one方法的作用显而易见，是将传入参数加一再返回。而struct_test函数的作用是先在堆上开辟一个大小为生面声明结构体的内存空间，然后将该内存空间的指针赋给传入的参数，并将该结构体赋值。（这里的代码其实不够严谨，没有进行内存回收，但这不是本文的重点，所以先不做讨论）

需要注意的是，如果是 C++代码，需要使用extern "C"标记导出，否则会因为符号修饰和调用约定的问题导致无法通过源代码中的符号找到该函数。

我们可以使用 VS 的Developer Powershell对上述源码进行编译：

1
2

cl /c main.c
Link /dll main.obj

编译后将生成 main.dll，我们在后面会用到这个动态库。

针对上述 C 函数，我们有如下 JS 代码，并假设和 C 代码在同一文件夹下：

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

/* index.js */
const ffi = require('ffi')
const ref = require('ref')
const ref_struct = require('ref-struct')

const t_s = ref_struct({
  a: ref.types.int,
  b: ref.types.char
})

const t_s_ref = ref.refType(t_s)

const test_ffi = ffi.Library(__dirname + '\\main', {
  add_one: ['int', ['int']],
  // aka 'add_one': [ref.types.int, ['int']],
  struct_test: ['void', ['pointer']]
  // aka 'struct_test': ['void', [t_s_ref]],
})
const result = test_ffi.add_one(20)
console.log(result) //21

t_s_p = ref.alloc(t_s_ref)
test_ffi.struct_test(t_s_p)
console.log(t_s_p)
console.log(t_s_p.deref())
console.log(t_s_p.deref().deref()) //a->1, b->'d'

首先，在代码中声明了一个结构体t_s,和 C 语言中的t_s*类型相对应。然后，我们还得到了结构体t_s的一个引用t_s_ref，和 C 语言中的t_s**类型对应。为什么在 C 语言中都多了一层指针呢？其原因和前面的字符串一样。

然后，声明了 test_ffi 变量，它调用了 ffi.Library 方法，该方法返回了 JS 中 DLL 的句柄和函数的声明，通过该变量可以进行 DLL 的调用。该方法有两个参数，一个是动态库的名称（可以略去拓展名 dll），另一个就是描述 C 语言函数的符号及其参数的对象。

该列表在上面已经简单介绍过了，对象的 key 是函数名，value 是一个数组，数组中第一个元素为函数的返回值的类型，第二个元素为另一个数组，它里面包含了函数的入参的类型。这些类型就用到了上一节中介绍的基于 ref 包的类型系统，类型可以用字符串表示，也可以用代码表示，可以参考代码中 aka 的注释。

接下来，代码通过test_ffi.add_one调用了 C 语言动态库中的add_one函数，可以看出，调用的方式和 JS 中的函数并无二致。但是需要注意参数类型千万不能传错，特别要注意 C 语言的 string 类型和 JS 中的 string 类型不同，要按照前文提到的方法进行转换。

然后，代码使用 ref.alloc 方法为 t_s_ref 变量开辟了一个内存空间（注意这只是一个指针大小的空间，并非结构体大小），并将该地址赋给 t_s_p 变量，然后将该变量传递给 struct_test 函数。因为 t_s_p 是一个二重指针，所以需要解两次引用，才能得到结构体真实的值。

回调函数

回调函数可以使用ffi.Callback()函数声明，该函数的第一个参数为返回值，第二个参数为入参列表，第三个参数为真实回调函数的闭包。

比如一个回调函数的定义如下，该函数会得到用户名和 id，并返回动作是否执行成功：

1

typedef int(*callback)(int, const char*);

那么，在 ffi 中，就可以使用如下方式声明该回调函数：

1
2
3
4

const callback_function = ffi.Callback('int', ['int', 'string'], (id, username) => {
  // do something
  return 1
})

在声明之后，需要将该回调函数做为参数传入某个函数：

1
2
3
4
5
6

test_ffi.set_a_callback(callback_function)

// Make an extra reference to the callback pointer to avoid GC
process.on('exit', function() {
  callback_function
})

特别需要注意的是，设置完回调函数以后一定要保证该函数在 JS 中还存在一个引用（比如上面讲该函数的一个引用放在了 NodeJS 的 exit 事件中，这也是比较经典的做法）。否则，该函数将会被 NodeJS 的 GC 析构。其表现是：在程序刚开始执行的时候一切正常，但是执行了一会儿之后在调用这个回调函数，程序就会异常退出。如果用 VS 去对程序 Debug，就会发现该程序可能访问了非法指针，这是因为 DLL 代码中也存放了该回调函数的指针，但是在 JS 中该指针指向的地址因为没有被 JS 中的代码引用，所以被 CG 被释放，这样 DLL 中代码调用该地址的函数的时候，就会访问到非法的内存。

一些 Tips

DLL 的调试方法

在使用 ffi 的过程中，可能发现最大的问题就是程序难以调试。特别在面对 DLL 的时候，就像针对一个黑盒操作一样，虽然已经对着头文件将他的 API 使用 FFI 翻译为 JS 的代码，但还是难以确定传参或返回值是否正确，在 C++的代码中该参数是否正确传入，传入后是否正确执行等等。这就需要一个能够调试的方法。

一个比较好用的方式是使用宇宙第一 IDE Visual Studio 的 Attach（附加）到进程的方式进行调试。但这种调试方法的前提是手中有 DLL 的源码或 PDB（符号）文件（如果没有的话就只能看到出现异常的代码附近的反汇编的代码了，而通常这些异常都是内存错误引起的，其实它附近的数据可能没有多大的意义）。

如果手上有源文件，那么首先打开工程，然后在 NodeJS 载入 DLL 之后，就可以在启动工程的时候选择“附加到进程”，在对话框中选择 NodeJS 进程即可进入调试界面。在调试界面里，可以插入断点，也可以看到断点附近的内存。

如果手上没有源文件，但是有 PDB 文件（或者少量的源码），可以使用 VS 打开一个空工程，然后在调试的设置中添加符号文件的位置，这样也可以进行断点调试，在调试的过程中可以查看代码有没有命中断点，在命中断点时，会引导你载入项目文件，如果有的话可以选择，否则可以查看断点附近的反汇编代码。

具体的调试方法可以参考 MSDN 文档：https://docs.microsoft.com/en-us/visualstudio/debugger/attach-to-running-processes-with-the-visual-studio-debugger?view=vs-2019，在这里就不过多叙述了。

如何载入在其他文件夹中的 DLL

如果 JS 文件和 DLL 文件不在同一文件夹中，可能会出现载入失败，会出现类似于“Dynamic Linking Error: Win32 error 126”的错误提示。

这时，就需要将 DLL 文件夹的路径放在系统寻找动态链接库的 PATH 中，但是 FFI 并没有提供此类接口。不过，好在 Windows API 提供了 SetDllDirectoryA 这个接口用以切换该进程中寻找 DLL 的 PATH，可以使用如下代码完成这个操作：

1
2
3
4

const kernel32_ffi = ffi.Library('kernel32', {
  SetDllDirectoryA: ['bool', ['string']]
})
kernel32_ffi.SetDllDirectoryA(your_custom_dll_directory)

一些链接时候的错误提示

上面已经提到，如果动态库不在 PATH 中的话，会出现无法找到动态库的情况，这时候会报“Dynamic Linking Error: Win32 error 126”的错误，在另外一些时候，只要没有找到动态库，都会报该错误。如果出现该错误，就需要检查动态库的名称是否正确，检查动态库的版本是否正确（比如 32 位 Node 使用了 64 位的 DLL）等。

另外，还有一个“Dynamic Linking Error: Win32 error 127”错误比较常见，该错误指没有在 DLL 中找到对应的符号，这可能就需要检查在 ffi 中声明的函数名是否正确以及是否 DLL 版本有偏差了。

在 Electron 中使用 FFI

由于每一个 Electron 的版本是基于相应的 Node 和 Chrome 版本构建的，所以在使用 FFI 之前需要根据所使用的 Electron 版本安装本地的 NodeJS 版本，否则 FFI 可能会和 Node 版本不匹配，导致提示 ABI 版本不一致：xx was compiled against a different Node.js version using NODE_MODULE_VERSION x. This version of Node.js requires NODE_MODULE_VERSION xx（NodeJS 使用 NODE_MODULE_VERSION 来辨别 ABI 版本）。

这种情况下，可以使用前文提到的electron-rebuild对项目中的所有插件进行重新编译（需要注意本地 NodeJS 的 ABI 版本一定要和 Electron 中 NodeJS 的 ABI 版本一致）。

另外，需要注意的是，Electron 5 以上的版本使用了 NodeJS 12 的 ABI，但是当前的 Ref 库并不支持该 ABI，会导致编译失败。不过已经有人提交了 pull request 进行修复，相信之后会有一个可用的版本出来。

另外，也有了 NAPI 版本的 FFI 和 Ref，分别名为ffi-napi和ref-napi，和 ref 相关的包，比如 array 和 struct 拓展，也有了相应的 NAPI 版本，命名规则同上。使用 NAPI 的 Node C++ 拓展接口相对稳定，是今后的趋势。

最后，Electron 版本可以在https://electronjs.org/releases/stable中查看，而 NodeJS 及其 ABI 的版本可以在https://nodejs.org/en/download/releases/中查看。

一些资源

最后，在这里放上最近踩坑时候经常使用到的一些资源吧：

• ref 文档：http://tootallnate.github.io/ref/
• ffi 文档：https://github.com/node-ffi/node-ffi/wiki/Node-FFI-Tutorial
• 基于 ffi 的 win32 api：https://github.com/waitingsong/node-win32-api
• v2ex 中的 node-ffi 食用指南（难吃）：https://www.v2ex.com/amp/t/474611

引用是C++相对于C而引入的一个重要特性，它使得许多地方的语法变得更加简洁，但是它们的底层究竟是怎么实现的呢？

在Wikipedia中，对指针有如下介绍：

In computer science, a pointer is a programming language object that stores the memory address of another value located in computer memory. A pointer references a location in memory, and obtaining the value stored at that location is known as dereferencing the pointer.

从定义可以看出，指针从本质上来讲就是一个变量，其中所存储的就是其他变量的地址。 而C语言中的指针非常灵活，它可以任意指向某一个地址，不论这个地址究竟是否存在，或它究竟存储的是否为指针所代表类型的数据。

那么也不难想到，指针在实现的时候也是内存里的一个变量，它存有其他变量的地址。

在Wikipedia中，对引用有如下介绍：

In computer science, a reference is a value that enables a program to indirectly access a particular datum, such as a variable’s value or a record, in the computer’s memory or in some other storage device. The reference is said to refer to the datum, and accessing the datum is called dereferencing the reference.

In the C++ programming language, a reference is a simple reference datatype that is less powerful but safer than the pointer type inherited from C. The name C++ reference may cause confusion, as in computer science a reference is a general concept datatype, with pointers and C++ references being specific reference datatype implementations. The definition of a reference in C++ is such that it does not need to exist. It can be implemented as a new name for an existing object (similar to rename keyword in Ada).

从上面的定义可以看出，在C++中，引用可以狭义地认为是某一个变量的别名，它本身是并不存在的。

基于以上说法，我就一度认为引用只是C++编译器在编译时的一些黑魔法，它在运行的时候将两个解析到的符号链接成了一个，从而完成了引用，而在编译之后，引用与本体就是一个变量（一个寄存器或栈上的值）。

但是,事实却打了我的脸。

我们通过以下程序进行检验：

1
2
3
4
5
6
7
8

int main()
{
    int a = 0;
    int *pa = &a;
    int &ra = a;
    ++(*pa);
    ++ra;
}

该程序声明了一个变量a，然后分别声明指针pa指向a的地址，生命引用ra指向a，最后分别使用指针和地址对a进行了一次自加操作。

接下来，使用gcc -S test.cpp -o test.s -O0将上面的C++程序编译为汇编，看一下这些操作具体都是怎么实现的。(环境为MacOS，LLVM 10.0.1)

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

.section__TEXT,__text,regular,pure_instructions
.build_version macos, 10, 14sdk_version 10, 14
.globl_main                   ## -- Begin function main
.p2align4, 0x90
_main:                                  ## @main
.cfi_startproc
## %bb.0:
; 保护现场
pushq%rbp
.cfi_def_cfa_offset 16
.cfi_offset %rbp, -16
; 保存栈指针
movq%rsp, %rbp
.cfi_def_cfa_register %rbp
; 设置返回值为0
xorl%eax, %eax
; int a = 0
movl$0, -4(%rbp)
; t0 = &a
leaq-4(%rbp), %rcx
; int *pa = t0
movq%rcx, -16(%rbp)
; int &ra = t0
movq%rcx, -24(%rbp)
; t0 = pa
movq-16(%rbp), %rcx
; t1 = *t0 = *pa
movl(%rcx), %edx
; ++t1
addl$1, %edx
; *t0 = *pa = t1
movl%edx, (%rcx)
; t0 = &ra = &a
movq-24(%rbp), %rcx
; t1 = *t0 = *(&ra) = ra = a
movl(%rcx), %edx
; ++t1
addl$1, %edx
; *t0 = *(&ra) = ra = a = t1
movl%edx, (%rcx)
; 恢复现场
popq%rbp
; 返回
retq
.cfi_endproc
                                        ## -- End function

.subsections_via_symbols

我已经将汇编中的关键代码加上了注释，可以看出，变量a，指针pa，以及引用ra都位于栈上，index分别在-4、-16、-24。需要注意的是，引用并不是直接复用了变量a的-4(%rbp)地址，而是像指针一样，使用了一个新地址，并且将leaq计算得到的a的地址写入了其中。

而在进行自加的时候，除了最开始将指针中的内容拷贝到寄存器中所用的地址不同以外，指针和引用所使用的方式是完全相同的。

这个结果令我非常意外，编译器其实是将开发者对引用的操作翻译成了对指针的操作。

最后，发现现代编译器还是很聪明的，如果将优化级别调到更高，就会发现它直接将中间的计算过程全部简化，直接返回，这是因为计算结果并没有任何输出，它是不必要的。如果将上面的代码从main函数转移到其他函数中，编译器这时虽然不能放弃计算其中的数值，但还是做了尽力的优化，直接返回结果（movl $2, %eax）。

进一步的实验

在文章发出后，有同学提出了质疑，认为可能只是MacOS上gcc编译器的特定操作，并不具有普适性，所以我在Linux和Windows上重复了上述实验。

在Linux环境中（发行版为Ubuntu 18.04，gcc版本为7.5.0）使用相同指令编译后得到的汇编码如下所示：

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

.file"test_ref.cpp"
.text
.globlmain
.typemain, @function
main:
.LFB0:
.cfi_startproc
; 保护现场
pushq%rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
; 保存栈指针
movq%rsp, %rbp
.cfi_def_cfa_register 6
subq$32, %rsp
movq%fs:40, %rax
movq%rax, -8(%rbp)
; 设置返回值为0
xorl%eax, %eax
; int a = 0
movl$0, -28(%rbp)
; t0 = &a
leaq-28(%rbp), %rax
; int *pa = t0
movq%rax, -24(%rbp)
; t0 = &a
leaq-28(%rbp), %rax
; int &ra = t0
movq%rax, -16(%rbp)
; t0 = pa
movq-24(%rbp), %rax
; t1 = *t0 = *pa
movl(%rax), %eax
; t2 = *t0 + 1
leal1(%rax), %edx
; t0 = pa
movq-24(%rbp), %rax
; *t0 = *pa = t2 = *t0 + 1
movl%edx, (%rax)
; t0 = ra
movq-16(%rbp), %rax
; t1 = *t0 = *pa
movl(%rax), %eax
; t2 = *t0 + 1
leal1(%rax), %edx
; t0 = ra
movq-16(%rbp), %rax
; *t0 = *ra = t2 = *t0 + 1
movl%edx, (%rax)
; 返回值设置为0
movl$0, %eax
movq-8(%rbp), %rcx
xorq%fs:40, %rcx
je.L3
call__stack_chk_fail@PLT
.L3:
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.sizemain, .-main
.ident"GCC: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0"
.section.note.GNU-stack,"",@progbits

可以看出与MacOS中gcc的编译结果基本相同。

在Windows环境中（Windows 10，vs2019，cl版本为19.23.28106.4），可以使用命令cl /Od /FA .\test_ref.cpp对源码进行编译，可以得到汇编代码如下：

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

; Listing generated by Microsoft (R) Optimizing Compiler Version 19.23.28106.4 

TITLEC:\Users\jason\test\test_ref.cpp
.686P
.XMM
include listing.inc
.modelflat

INCLUDELIB LIBCMT
INCLUDELIB OLDNAMES

PUBLIC_main
; Function compile flags: /Odtp
_TEXTSEGMENT
_ra$ = -12; size = 4
_pa$ = -8; size = 4
_a$ = -4; size = 4
_mainPROC
; File C:\Users\jason\test\test_ref.cpp
; Line 2
pushebp
movebp, esp
subesp, 12; 0000000cH
; Line 3
movDWORD PTR _a$[ebp], 0
; Line 4
leaeax, DWORD PTR _a$[ebp]
movDWORD PTR _pa$[ebp], eax
; Line 5
leaecx, DWORD PTR _a$[ebp]
movDWORD PTR _ra$[ebp], ecx
; Line 6
movedx, DWORD PTR _pa$[ebp]
moveax, DWORD PTR [edx]
addeax, 1
movecx, DWORD PTR _pa$[ebp]
movDWORD PTR [ecx], eax
; Line 7
movedx, DWORD PTR _ra$[ebp]
moveax, DWORD PTR [edx]
addeax, 1
movecx, DWORD PTR _ra$[ebp]
movDWORD PTR [ecx], eax
; Line 8
xoreax, eax
movesp, ebp
popebp
ret0
_mainENDP
_TEXTENDS
END

cl编译器的汇编代码格式和gcc略有不同，但含义相近，并且可以比较轻易地通过上面标出的代码行数确定汇编代码的含义。可以看出，它使用的方法也和前两种相同。

这里再进一步，引入知乎上“XZiar”同学的评论，她的评论更加深入地理解其中的机制：

其实不是说“把引用解释成指针”吧。

在机器码层面，也不存在指针，只存在地址（指针其实还隐含了类型信息）。变量这个概念也是不存在的，只有“无格式数据”，被带格式的指令操作而已。

所以你看到引用和指针的效果一样，是因为在机器码层面，没有多余的信息去表明他们的区别了。

而在语言层面，引用的确可以理解为const指针

另外，她针对为什么汇编代码中引用把地址复制了一遍也进行了更深入的解释：

另外引用把地址复制一遍也是很正常的，编译器也的确没法在编译期完全分析出引用的具体指向。考虑如下代码：

int a=0,b=1; int& c = flag ? a : b;

引用只不过因为const所以不能被重置，但具体指向什么，是可以运行期决定的。

到这里，对于指针和引用底层实现的探索也基本结束了，可以看出，在不启用编译器优化的情况下，主流编译器都会选择将C++中的引用解释为“const指针”。

但是，如果在启动编译器优化的情况下会是如何呢？在MacOS中，将源代码中的返回值改为a后（为了防止编译器优化后认为没有输出于是什么都不做），同时将编译器优化选项调整为O1和O2，其结果是相同的，如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

.section__TEXT,__text,regular,pure_instructions
.build_version macos, 10, 15sdk_version 10, 15, 4
.globl_main                   ## -- Begin function main
.p2align4, 0x90
_main:                                  ## @main
.cfi_startproc
## %bb.0:
pushq%rbp
.cfi_def_cfa_offset 16
.cfi_offset %rbp, -16
movq%rsp, %rbp
.cfi_def_cfa_register %rbp
movl$2, %eax
popq%rbp
retq
.cfi_endproc
                                        ## -- End function

可以看出汇编版本的代码中省略了所有和指针、引用及内存操作相关的代码，直接将返回值设置为2。

从这里可以看出，编译器的作用是将语言编写的代码翻译为合理的汇编代码，只要汇编代码可以源代码的真实意图执行即可。由于机器码可以表达的概念有限（基本上就是对于寄存器和内存的运算），而高级语言可以表达的概念十分多样，所以编译器就需要将高级语言中的各种复杂概念映射（也可以看做是翻译）为机器码中的简单概念，映射的过程可能会有多种方案，其最终选择是由编译器来决定的。在C++指针和引用的翻译中，主流的C++编译器都选择将它们映射为机器码中的地址，而舍弃了其中的类型信息。

Intro

倏忽之间，又过去了一年。是时候向 2018 说一声再见了。

今年，我只在写 年关随笔 时立了一个 Flag，要练习深度写作，至少每个月输出一篇文章。可惜因为暑假时候偷懒，这个 Flag 也并没有达成。不过，我还是要在 2019 重新立起这样一个 Flag —— 2019 年每个月至少输出一篇文章，可以是技术，可以是随笔，也可以是观点。希望明年这个时候再回来看，不要像今年一样打脸。

再说回 2018。这一年相比前些年，在我的努力下，节奏逐渐慢了下来，让我有了许多时间静下心来思考、做事，也有时间和爱人相处、与朋友侃大山（至少在十一月之前是这样的）。同时，这一年又并不像以往那么顺遂，让我明白了人力有限，世间有太多力所不能及之事。

时光·记忆

在大自然面前，没有什么是能够永恒的。人不能够，事不能够，城也不能够，甚至文明也不能够。

在奶奶走后，我每每做梦都会回到小时候，梦见亲人们都在，他们都能和谐相处；梦见家乡没有衰败，还有很多人居住；梦见我很强，能够办到一切事情。

可惜梦中和现实却每每都是相反的。我无力改变太多，但至少可以做些什么。眼下能做的事情，就是把家乡的景，家乡的事儿多记录一些，等多年后，这里变成一片荒山野岭，无人问津的时候，人们还是能从我只字片语的记录之中，知道有这样一个地方，曾经有这样一批人，为了祖国的建设，把最好的青春和无尽的才华都奉献在这西北的茫茫荒山之中。

我在这里贴上几张年初所拍的照片吧。

这两张是白银市老城区白天和晚上的景观，拍摄于白银市人民医院综合楼楼顶。白银市从今年开始增加了许多城市亮化的工程，在白天看来就是一个暮气沉沉的工业老城，但是在晚上看来尤其漂亮。

下面的照片均是在西北铜加工厂（884）社区拍摄。

这是 884 附近的一座山，山上有一块形状酷似像狮子的石头，所以小时候我们都管这个山叫做“狮子山”。不过可能由于石头连年风化，已经随时会滚落下来，才有人在山脚下立了块标识危险牌子。

这是一条通往旁边村子的路，货车多半可能是准备进入大山深处，去拉从山中开采的石灰石。水泥路已经被一辆辆超载的大货车压得几乎没有了。

这是西北铜加工厂的正门（有两个，这是其一），在当年国企兴旺之时，上下班的时候人们进进出出摩肩接踵，但是现在物是人非，已经看不到什么人进出厂区的大门了。

这是通向厂门的桥，当年为了让职工可以在发洪水的时候安全上下班，就修了两座连通厂区和家属区的桥。桥下还有一个足球场，在发洪水的时候用作泄洪（我们称为“沙沟”），这两座桥似乎一个名为“兴旺桥”，一个名为“振兴桥”，但是年久失修，现在已经是两座危桥了。

这是奶奶之前工作过的食堂，由于年久失修，们都已经被水泥封了起来。透过门缝，还能看见火红的标语，一刹那间仿佛又回到了当年。

这是西铜的职工浴池，我们都叫大澡堂。前几年浴池终于也关闭了，我只能透过蒙着厚厚灰尘的玻璃撇入浴室的一角，找到当年的回忆。

这是当年“达利居”饭庄（之后改名为西铜宾馆）的舞厅。据说西铜鼎盛的时期，会有许多年轻的男男女女穿梭在其中。不过我记事的时候已经没有什么人了。

这是一座无名小山上凉亭的一角。当时厂里希望把这座山修成一座公园，于是修整了山道，修建了几座凉亭。不过还没修好，就已经开始亏损，这座公园也就只剩下这两个凉亭了。

以上都是我在西铜或者说是白银记忆的一个小角落，还有大量我的、同学的、长辈们的记忆有待挖掘。现在的西铜，已经破败不堪。一眼望去，只有一座座废弃的建筑和一望无际的荒山。一路走去，已经很少能碰见朝气蓬勃的年轻人，只有沟壑纵横的长辈们。这座城因他们而生，也注定会随着他们离去而消失殆尽。所以，我能做的，就是尽量用图片和文字来保留着座终将消失的城，留住他们珍贵的记忆。

出游

相比前几年，今年出行的地方没有那么多，但是每个地方都很值得好好留念。正所谓——世界很大，不能只看去了哪里，还要看是和谁一起去的。

苏州

2018 年出行的第一站是苏州，这也是我走过得祖国河山中最喜欢的地方之一。苏州不仅有数不尽的美丽景致，更有独特且很有内涵的地方文化，更有令人适宜的生活环境。更重要的呐，这还是和卤蛋同学第一次一起出远门旅行。刚好还欠卤蛋同学一个游记，就先在这里简要地写一下好了。

苏州城区不大，只靠地铁和公交在一个小时之内都可以到达。但是在城内逛游的时候真的可以感受到就像它的园林一般的一步一景。走着走着，就会出现一座很漂亮的古桥，又向前走两步，就到了一个小有名气的私家园林，再向前一看，发现这不是一家百年老字号嘛（快快快去吃好吃的别看了）。

另外，苏州话也非常有特色。虽然我听不懂，但是可以感到说话的人都还挺温柔的（就算骂人都骂的很柔），在苏州评弹里就更能体现了，每一个曲调都很柔美，让它所表达的故事格外的柔美。当地人也都十分热心，问路时候可以感受到他们十分有耐心，说话比较慢，令人舒适感倍增。当然，这也从侧面体现了他们生活比较安逸，节奏比较慢。

下面，我贴几张比较有意思的照片好了。

这是刚到苏州时候，沿着一条街向虎丘走，卤蛋同学在街边特别激动，左拍拍右拍拍。我刚好留意到他们街头布置得很细心，很能为街道环境和有宠物的人着想，在墙边设立了宠物便纸箱。

街角一转，居然到了到了河边。河边灰白色的天空衬着灰白色的墙，倒映在水里，十分宁静。这时，船夫划着一艘游船从远处徐徐开来，扰乱了湖水，也令人在心中荡起了浅浅的涟漪。

虎丘山中的一个沟壑。虽然小，但也有了一种悬崖峭壁的感觉，沟底的水中映出来天上的雨滴，植物颜色十分撞眼，犹如通往世外桃源的一条幽径。

市内的一座不知名公园。远望时感觉画面十分饱满，而近观又感到场景十分开阔，眼睛都舍不得多眨一下，生怕错过哪一处的美景。

苏州评弹剧场内部。老师底蕴深厚，唱腔优美。很多字发的都是古音，所以需要有一块屏幕向观众展示唱词。每唱一曲都会一下子把我带入古代天堂般繁华的苏州，置身闹市之中，但又让我进入心流。

黄天源的苏州小吃。如果苏州糕点说自己第二好吃，怕是没有什么地方敢说自己是第一了。不过最让我惊喜的是苏面，这是我除了牛肉面以外第二个感到能百吃不厌的面了。

除了这些，在苏州还有许多有趣的见闻，而且都还有许多没有去到的地方。以后可以有缘再见咯。

天津

在暑假的时候去了一趟天津。我在这次旅行中得到了一个惊人结论——天津和北京一样热。所以以后夏天还是老老实实待在实验室吹空调好了。

即使这么热，天津之眼还是要排很久的队，所以就随手拍了张照。

天津之行的时候还是我和卤蛋同学在一起一周年的纪念日，于是——再回来以后我受宠若惊呆若木鸡地收到了卤蛋同学送的花（hmmm 这应该也是人生中的第一束花），拿到花以后我甚至不知道该把它放在哪里，是不是应该把它插到水桶里养起来。

灵山

高中地理曾经学过——海拔每升高 100 米，气温下降 0.6 摄氏度。这大概是我在灵山之行中最直观的感受了。灵山是北京第一高峰，在门头沟区，几乎已经到了北京同河北的交界处，需要驱车三个小时才能赶到。

灵山是同潘老师、林博以及卤蛋同学我们一行四人去的。去爬山的时候天还是挺热的，所以我带了一件坛服去御寒。刚开始爬的时候我还很跳腾，但是到了一半左右，山势变陡，狂风大作，气温骤降。已经冷到了骨子里，无奈只好作罢。

灵山上的风景与山下迥异，像极了西北高原，居然出现了驴子和牦牛。下面是在灵山拍摄的一些照片。

活动

今年我也刻意减少了很多不必要的活动。在这说说几个比较有意思的吧。

Hack for Good

我最开心的不是又参与了一次 Hachathon，而是 Hackathon 成为了俱乐部每年的例行活动（而且这一场还是卤蛋同学参与办的）。

这次 Hachaton 弹幕派作为合作方参与到了其中，并且我也带团队来和大家一起 Hack 了两天，成果显著，做好了小程序和控制面板上线前的最后准备。

SDN 大赛

还有一件值得一提的事情是搞了两年的 SDN 大赛终于以二等奖为结果圆满收官。比赛中强哥、天骄、高钱、格格这些队友都十分给力，另外加上小雨姐和潘老师的助攻，让我们成功杀入了决赛圈。

现在看来，我做了一年的 P4 实验系统也随着这个比赛到了的尾声。一年以来，我总是在不断地在这个系统的 Bug 和 Debug 中度过，每天总是担心训练效果不是很理想（事实证明效果的确也不理想）。前些日子，基于这个系统的 INT 遍历算法中了一篇 Infocom，也算是这套系统的最大成就吧。

技术

今年最令我担心的就是我的技术了。因为离工作的日子越发的近，我却还是没有一门能拿得出手的技术。这些年来，我做了挺多多，了解了挺多，都是项目要用到什么就去学习什么，一直没有给自己找到一个能够系统深入的方向，说起来也很是惭愧。

不过下半年也算是有一个好的开始吧。我开始去刷 Leetcode（刷过的题目都可以在博客中的leetcode 板块看到），去看一些框架的源码，开始做 Go 语言的项目，去了解容器和一些 Linux 协议栈相关的知识。现在看来，能做的就只能是再接再厉，不要再掉链子了。

弹幕派

在这里我也给弹幕派做一个年终总结吧。

去年一年，弹幕派的增长效果还不错。在推广营销投入几乎为 0 ，且前有夹击后有追兵的情况下，靠着之前的老本，在用户量和营收上都得到了明显的增长。

在今年一年，一共有数万个用户注册了弹幕派账号，成功举办了几千场大大小小的活动。一共有数十万人参与到了活动现场的弹幕互动中，产生了数百万条弹幕，并产生了数万个付费订单。另外，弹幕派网站创造了数百万的 PV 和几十万的 UV。这在互联网公司看来可能都不算什么，但是对于我们团队来说，是一个不小的进步。

我们也投入了大量的精力在研发上面。我们在去年年初就将系统迁移到了 Swarm 集群中，并配置了半自动的编码、发布、测试、预览、上线的环境，经过一年的实践，系统运行良好。而在前端层面，我们将原有的多种技术栈进行了整合，都迁移到了以 Vue 为基础的技术栈中，这样团队成员在不同项目之间切换就变得游刃有余。而后端我们继续沿用了 Laravel+Workerman 的架构，并感到目前还远远没有到达天花板。

今年的状况就是这样，期待明年可以有更强劲的增长吧。

一些小事儿

今年有两次去同学家里做客的经历。一次是同卤蛋同学一起去胃寒家，一起做了一大桌菜（感谢心灵手巧的胃寒和蓉蓉）；另一次是自己去牧野家，一起吃了一顿史上最小的小火锅（感谢牧野和小团子的精心准备）。

吃腻了学校的食堂，有时候觉得能和爱人在自己家里做饭吃（特别是再和朋友一起煮一锅热气腾腾的火锅，一起聊聊天），的确是很开心的。所以我有时候也开始对未来在外面打拼的时光充满期待。谁知道呢，或许也是一座围城吧。

年中的时候我也拿到了驾照，不过今年唯一一次路驾还是和牧野，从中关村开到了学校。以后有机会还得多开车，向着老司机的行列迈进。

年末的时候玩了今年的唯一一款游戏《古剑奇谭 3》，虽然游戏只花了 99，但是我体验到了几倍于价格的诚意。游戏画面精美，优化十分到位，我在大一时候买的 Y400 在现在还能基本流畅地进行游戏，即时战斗也颇为精彩。而在游戏中，文明的光芒、历史的厚重与人类的传承在我的眼前徐徐展开，而主角之间那种的真情也让我倍感舒适。比起之前玩的仙侠类的 RPG，古剑三的进步不止一点点。最近有机会我想专门写一篇相关的文章。

沉重的话题

2018 年这一年，有很多人离开了我。包括我的亲人，以及许多敬重的人。

奶奶是 2 月份走的，现在每每想起心中依旧难以平静。而在这之后，这一年难过的事情就没有中断。

回忆了一下，逝去的科学巨匠有霍金和高锟。霍金的黑洞理论其价值非我所能评论，但是他的《时间简史》以及《果壳中的宇宙》陪伴了我整个少年时期。而高锟所发明的光纤正构成了我们现在有线通信的根基。他们的逝世是全人类的一大损失，随着他们的离开，科学世界的光芒也变得暗淡了许多。搜索后我才知道，仅 2018 年，就有 31 名两院院士离开了我们。这怕是绝无仅有的。他们共和国的栋梁，他们的贡献深刻地影响着我们的生活，我深切缅怀他们。

除他们外，还有许多社会知名人士也相继逝世，他们许多人对我们的社会有着深刻的影响。联合国秘书长安南是一个小时候经常听到的名字，他所在的时候，也是联合国知名度最高的时候，他纵横捭阖，致力于解决国际争端，给全人类一个美好的世界。著名主持人李咏的去世也勾起了我对童年的回忆，在印象中，他是一个每天都很欢乐，手持锤子打电话砸金蛋的主持人，但从没想过他会这么快就离开这个世界。而他和哈林的爱情故事，更令我十分动容。除此之外，对文化影响很深的还有金庸、李敖和曾仕强。金庸无需我多言，小时候看的很多武侠小说和电视剧都出自他手，他告诉了我什么是江湖，也给我带来了无数乐趣。李敖和曾仕强是台湾的两位思想家。其中，曾仕强《易经》可能是百家讲坛最受欢迎的节目之一了，他讲的内容大多记不得了，但是他那种睿智而又儒雅的风格令我印象深刻。

最后，还有田家炳先生。田家炳先生在国内可能没有邵逸夫那么有名，但是他也捐助了无数学校，让这些学校可以改建校舍，购置教具，相互交流，提升教学质量。我所读的高中就是一所田家炳中学在上高中的时候，我们体验到了新的教学楼，用上了很高级的电子白板。而在我们毕业后，学校也将土操场进行了翻新，还新建了装备齐全的科学楼。这其中有很大程度上都是由于他老人家。作为一名田家炳中学的学生，听到他逝去的消息，我的心情相当沉痛。

而我们国家也正在经历“百年未有之大变局”。这一年随着贸易战开打，经济局势开始变得紧张起来。随着数字货币、互联网借贷和共享单车的迅速衰落，互联网产业也迎来了变数很大的一个时期。独角兽们即使股票纷纷破发，也要流血上市，而下半年来更是处处风传裁员浪潮。这一年注定是一场场艰难的战役。

The End

不论如何，时间是不会停下来等人的。现在，2018 年已经过去，2019 年已经到来。该面对的还是要面对，该承受的也要去承受。

上面所回忆的事情，不论好事坏事，不论是否开心，也只是生活中事情的一少部分，生活中更多的事情，是稀松平常，甚至结束以后就会忘记的。但是，这些事情其实才是生活的主旋律。倘若可以在这些事情之中发现美，生活也就会有更多的乐趣了。

2019 注定依旧是很有悬念的一年，不能守成，还需不断奋斗。加油吧！

问题 1 键盘弹起后会遮挡键盘上方的内容

在微信浏览器中，如果需要模拟一个类似微信聊天的窗口，那么一般情况下需要将输入框使用 fixed 定位放置在页面最下方。就像这样：

但是，在 IOS 中的虚拟键盘和 Android 里是不同的。在 IOS 中，虚拟键盘弹出以后，键盘上面的输入提示会比键盘弹出慢半拍，所以就会导致输入法的提示框将正常页面挡住的情况。

这时候，就需要在键盘弹出后，等待一段时间（几百毫秒），然后再将页面的滚动条进行调整，就可以让页面弹到键盘之上。

假设页面布局如下（使用了 Vue 框架），其中 Dialogues 组件是可以滚动的聊天内容，PageFooter 是使用 fixed 定位在页面底部的输入框：

1
2
3
4
5
6
7
8
9
10

<div id="index">
    <div id="mainPanel">
      <div id="dialogueContent">
        <Dialogues></Dialogues>
      </div>
    </div>
    <footer>
        <PageFooter></PageFooter>
    </footer>
</div>

然后，就可以在监听到软键盘打开事件（比如 dialogueContent 中 input 元素的 onclick 或者 onchange 事件）后，执行下面的语句，让 dialogContent 的滚动条向下滚动,这样里面的内容就不会被覆盖了。

1
2
3
4
5
6
7

let dialogueContent = document.querySelector('#dialogueContent')
setTimeout(function() {
    dialogueContent.scrollTop = dialogueContent.scrollHeight
    setTimeout(function() {
        dialogueContent.scrollTop = dialogueContent.scrollHeight
    }, 250)
}, 250)

至于为什么要触发两次呢，是因为 IOS 手机种类比较多，从五六年前 iPhone5s 到最新的 iPhoneXR 都有人在用，每种手机的响应速度也各不相同，有些手机可能在第一个 250ms 内还没有完成键盘弹出的工作，所以可以再加一个定时器来兼容旧的手机。

但问题也依旧存在，就是 fixed 定位的输入框在软键盘弹出以后就不会像 Android 一样固定在页面底部，而是可以上下滑动，类似于 absolute 定位。这时，可以将 body 设置为 absolute 定位，然后再将 MainPage 使用 absolute 定位于 body 底部。

问题 2 在虚拟键盘收起以后 body 定位的问题

紧接着，第二个问题就出现了。在点击虚拟键盘右上角的“完成按钮以后”，页面下方并没有回弹，而是定在了原来软键盘上方的位置，必须在页面上滑动两下才可以触发回弹。（特别是在大屏的 IOS 手机上）

大概是这样：

而在将 body 设置为 absolute 以后，情况更加离奇。页面 UI 是回弹了，但是触控事件响应的位置是没有回弹的，依旧是软键盘打开区域的上方。解决方法同样是必须在页面上方华东两下才能回弹。

大概是这样：

最开始的想法是去监听 resize 事件，如果软键盘收回，就强行调整 body 的高度，但是发现软键盘的弹出和收回并不会触发该事件，只得作罢。

最终，找到了一篇解决 类似问题的文章，才找到了解决方案。

大致思路就是在键盘收回以后，主动触发浏览器对页面的重绘操作。如何进行呢？只需要在监听到 onblur 事件以后，让页面滚动到原来的位置即可。

比如，组件模板中的 HTML 为

1

<input type="text" placeholder="发送内容" v-model="content" @blur="resizeWindow">

然后可以在 JS 的 methods 中添加一个函数：

1
2
3

resizeWindow() {
    document.body.scrollTop = document.body.scrollTop
}

这样，输入框在失去焦点以后会触发页面的重绘，刚刚的问题就随之而解了。

在前端调试的时候，跨域一直都是一个比较麻烦的问题，这个在之前的文章关于跨域问题的一个解决方法中其实已经讨论了一些可以使用的方法。

如果要使用 JSONP，第一是需要修改的地方比较多，而且也不太符合前端发展的大趋势，如果使用 CORS 的话并没有 application/json 类型。而且更重要的是这只是在前端调试时候的需求，并不是在上线以后的需求，所以对后端有太多的入侵也不好。

所以就有一个念想突然在大脑中闪过——加入有一个代理不就可以解决这个问题了？但是又想了一下写起来还挺麻烦，于是就被搁置了。 直到前几天 Stone 提到其实 webpack-dev-server 早就想到并且已经帮我们实现了。

于是，我就在一个 Vue 项目中进行测试，发现真的很赞，既可以本地 Server 热加载，还可以直接跨域调用远程 API，完美解决了之前遇到的所有问题。

接下来我简要介绍一下步骤（以一个 Vue 脚手架建立的 webpack 项目为例）：首先检查build/webpack.dev.conf.js中是否有

1

proxy: config.dev.proxyTable,

这个配置项，如果被注释掉，请打开注释，如果没有，请加入到 devServer 对象中 然后在 config/index.js 中的 dev 对象中加入 proxyTable 配置项：

1
2
3
4
5
6
7

proxyTable: {
  '/**': {
  target: 'http://api.xxx.com',
  changeOrigin: true,
  secure: false
  }
},

前面的键 /** 意思是代理所有请求，如果代理某些请求，可以将其改为诸如 /api 之类的字符串。

后面的 target 就是要代理到的网站，changeOrigin 的意思就是把 http 请求中的 Origin 字段进行变换，在浏览器接收到后端回复的时候，浏览器会以为这是本地请求，而在后端那边会以为是在站内的调用。

这样，通过这个简单的配置，就完美地解决了跨域的问题。

之后，在直接运行

1

npm run dev

的时候，就可以将测试前端中的 ajax 请求代理到后端服务器进行测试啦！

最后，贴上官方文档，具体的配置大家可以参考这里：
https://webpack.js.org/configuration/dev-server/#devserver-proxy

这个周就要立夏了，在这个夏天我要战胜它，也战胜自己。

周末和老弟遛弯聊天，他跟我谈及一个严肃而单纯的问题：既然毒品能给人带来快感，那为什么不人人都去吸毒呢？

我假装成一副胸有成竹的模样，“好问题！不过先别讲这个，我要和你谈谈音乐。我还记得上次和你去国家大剧院听新年音乐会时候你的表现。”

为什么谈音乐呢？我无非是希望引导他去认识到音乐之美，而审美判断是“无利害而生愉悦”，从而认识到有比毒品更自由的获得快瑟之感的方式——艺术或者说是道德。

我几乎成功了。

“那么这种愉悦和那种愉悦有何区别？”这个话题绕不开道德。

“而且你刚刚在讲，美的理想和道德的理念是同一的。那么假设一个人没有（像我们世人一样的）道德，那么他是不是也无法感受到艺术之美，那么他只能从毒品之类的东西中获得物质的快感？而凭什么人人都有这样的道德呢？”

我再令他去想为什么国家和法律如此“暴力”：道德次序的维持需要暴力，暴力保证了次序，也保证了减少暴力。所以毒品和问题需要暴力解决。

“但是，道德又有什么意义呢？你用暴力去维系道德又有什么意义呢？”

“因为人需要自由。人向往自由。音乐可以让人获得自由，道德可以，而毒品不行！”

但自由又有什么意义呢？什么才是自由呢？

我有些歇斯底里，不过在五月份，话题也总是绕不开它。

“你说向往自由，但是佛陀获得了自由，所以他领会到了空。但是空，不会太无聊点了么？”

“所以你想要的意义不就是来自于欲望，这能让你不那么无聊。”

“但是欲望和自由是不是就矛盾了？”

所以人生大概就是痛苦的吧。