我如何用 Windows 开发 —— 2021 我的开发环境

由于搭载 macOS 的设备越来越昂贵且槽点颇多,加上微软近些年开始发力开发者体验,我的工作环境已经从 MacBook 切换到了运行 Windows 系统的非苹果机器。这是多方面因素决定的:平时玩的游戏需要在 Windows 上运行,桌面环境也是 Windows 的比较舒适耐用。

使用 Windows 进行开发工作虽说并不像在 macOS 上那样可以使用诸多 POSIX 标准的工具,但鉴于硬件性能的提升和虚拟化技术的成熟,使用虚拟机或者 WSL2 也未必是不可接受的方案。此外,随着 Visual Studio Code 的 Remote 功能越发完善,在 Windows 的窗口环境下享受和 Linux 一样的开发体验也并非不可能。

当然,使用 Windows 开发完全是个人选择;本文并不打算讨论 Windows 对比其它操作系统的优劣,只是在此简单介绍我如何在 Windows 桌面上进行我的开发工作,希望对因为种种原因选择使用 Windows 工作的读者能有所启发。

需求

在讨论开发环境之前,我们首先得讨论开发的需求是什么。我个人写的东西还挺杂的,大部分时候使用 Visual Studio Code 写 TypeScript, JavaScript 和 PHP。除此之外,我有时候会使用 Android Studio 写 Java/Kotlin,或者用 Goland 写 Go,又或者使用 Visual Studio 2019 写 C#。此外,我还需要运行 DataGrip 之类的数据库管理软件、kubectl 之类的集群管理软件,还需要使用 ssh 登录数台远程主机。我的个人项目几乎都使用 docker 进行部署,因此 docker 也必不可少。

总体来说,我需要:

  • Visual Studio Code
  • Visual Studio
  • JetBrains IDE,包括:
    • Android Studio
    • Goland
    • DataGrip
  • 终端、zsh
  • docker

了解了自己的需求之后,就能根据自己的需求来考察选项。

OS

如标题所述,我的宿主机基本上是 Windows 操作系统,一般是最新的 Release 或者 Beta 版本,比如在写作文章的时候是 Windows 11 (Pro) Insider Beta。这目前是为了使用 wslg,在 Windows 11 正式发布之后我多半会切换到稳定版上。

鉴于平日打交道的服务器多半是 Debian 或者 Ubuntu 这类 Linux 发行版,本地开发环境上有一个 Linux 的机器很重要,我称之为 Linux dev box。在这个 Linux dev box 内的操作系统上,我选择使用 ArchWSL 提供的 ArchLinux 镜像作为日常的 dev box 使用,这主要是考虑到 ArchLinux 的软件包比较新,而且 AUR 上有很多方便的包可以选择使用。在非生产环境下,使用 ArchLinux 的体验还是不错的。

虚拟化

Linux dev box – WSL2

在 Windows 宿主机上运行 Linux box 是很简单的事情,而且你有诸多选择:以 VirtualBox 为代表的虚拟机方案;WSL1;WSL2。我的选项是 WSL2,你可能觉得 WSL2 和虚拟机也没什么区别,事实上几乎如此,只是省去了不少自己对虚拟机做的集成配置。WSL1 曾经是我梦想中的方案,但 WSL1 作为日常使用的子系统还是有其种种问题,其环境和物理或者 KVM 虚拟化的 Linux 还是有所区别,IO 也令人发指。

一个比较常见的问题是 systemd,众所周知 WSL 不管是 1 还是 2 都不支持直接启用 systemd,大概是因为微软自己启动的缘故。虽然没有官方的支持,但使用 genie 提供的 bottled 方案也并不是一个很难接受的选择,事实上体验基本与 systemd 一致——当然如果你需要的某些复杂高级功能工作不正常,那当我没说。听说 wsl2-hacks 也是个办法,但我没有尝试过。

另外,由于微软的奇葩设计,在每次 Windows 启动的时候 WSL2 都会被随机分配到完全随机的网段,这会导致不少问题。我遇到的主要是 Windows 下的防火墙难以配置WSL2 内连宿主机 IP 不稳定;还有选到和 docker 等虚拟环境冲突的网段导致路由错乱。前两个问题我通过一些脚本来解决,我把他们放到了 GitHub 的 oott123/work-on-windows 上供读者参考;而最后一个问题我也通过了一些办法解决,后文提到 docker 的时候再仔细说。

用上 WSL2 之后,wslg 也变得很简单,只需要 export DISPLAY=:0 并且 export WAYLAND_DISPLAY=wayland-0 就可以让 Linux 桌面程序显示成 Windows 窗口了。不过在我这边,wslg 的剪贴板不一定工作,我找到了一个 issue,但看起来没什么帮助的样子。之后也许要尝试自己去做剪贴板同步了。

如果你不想使用 Insider 系统来启用 wslg,也可以试试第三方方案 X410 。X410 ( X for 10 ) 是一款商业化的 X Server,相比 VcXserv 有更好的 HiDPI 支持,同时体验也更加流畅。官网有一些非常详尽的教程,例如和 WSL2 配合使用的和 Hyper-V 配合使用的,都可以看看。

Windows dev box – Windows 10

基于某种“不想在宿主机上安装开发环境”的奇怪洁癖矫情,我没有在我的宿主机器上安装 Visual Studio 、Android Studio 等开发环境,而是选择使用 VMWare 创建了一个虚拟机,并在虚拟机内安装。这台虚拟机里安装了 Visual Studio、Windows SDK、Android Studio 和 Visual Studio Code 等等 IDE 或编辑器。

因为使用频率比较低,所以也没咋配置,直接用 VMWare 开干了。实际体验只能说尚可接受,操作起来还是偶有迟滞的感觉,反正用得不多,懒得管了。

开发环境

IDE / SDK

鉴于我有两个 dev box ,那么某个 IDE 或者环境该在哪个 box 里安装无疑成了需要选择的事情。目前,我的基本准则是,能在 WSL2 里安装的,都在 WSL2 里安装:

  • Visual Studio – 宇宙第一 IDE 只支持 Windows,所以在 Windows box 里安装
  • Android Studio – WSL2 连实体机不方便,所以在 Windows box 里安装
  • Goland / DataGrip – WSL2 里安装,wslg 使用
  • Sublime Merge – WSL2 里安装,wslg 使用
  • nodejs, yarn, php 等命令行开发环境 – WSL2 里安装

Visual Studio Code

Visual Studio Code 的 Remote 功能是本世纪以来最伟大的发明。
—— 三三・自己说的

早在 coder 发布 code-server 的时候,我就搭建了一套用于日常开发;后来 vscode 发布了官方支持的 Remote 功能之后,我也就随之迁移到了 Remote 上进行开发。之前还需要通勤的时候,无论在公司还是在家里,都可以用 vscode remote 连接到自己的服务器摸一些东西;现在的话主要用于在 Windows 上连接 WSL 开发。

显然,我的 Visual Studio Code 是安装在宿主机上的;但使用体验和安装在 Linux 上并没有什么分别,一切都很顺滑。

Windows Terminal

我平时使用 Windows Terminal 作为我的 shell,大概配置成这个样子:

这张图片展示了使用 Windows Terminal 连接 WSL2 运行 neofetch 的结果。

在 Windows Terminal 中,为 WSL2 的 Profile 设置开始路径为 \\wsl$\Arch\home\oott123 这样的目录,就可以实现打开新标签的时候切换到 WSL 的家目录了,在这里就可以方便地存放自己的代码和开发环境了。注意不要把代码放到 /mnt/c/ 之类的地方去,否则你的 IO 会很惨。我平时使用 zsh 作为默认 shell,在 WSL2 里也是能直接使用的,就和普通的 Linux 系统没什么区别了。

另外,我使用了修改过的 zsh-notify 插件,配合 BurntToast实现命令错误/长时间任务完成推送 Windows 通知的功能。虽然由于偷懒,没有去检测当前焦点窗口是否在 shell 中导致命令报错的时候稍微有点吵之外,其实还挺好用的。

Docker

在 WSL2 里安装 docker 也是一件有两个选择的事情:使用 Docker Desktop,或者直接安装 docker daemon。我曾经选择了前者,还用上了非常酷炫和魔法的 WSL2 daemon,直到它出现了不少问题,最后由于我的 Arch 内核太新出现了一个我修不好的问题,一气之下就把它整个删掉了,安装了正常的 docker daemon。

前文提到过,WSL2 启动的时候会随机选择网段,有时候会选到和 docker 等虚拟环境冲突的网段导致路由错乱。后来我在 Windows 内创建一个和 docker 同网段的虚拟网卡之后,Hyper-V 似乎就很聪明地避开了这个网段,问题得以解决。

打开设备管理器,选择操作-添加过时硬件,依次选择安装手动从列表选择的硬件、网络适配器、Microsoft、Microsoft KM-TEST,并确认即可
使用设备管理器添加 KM-TEST 虚拟网卡

体验

在 Microsoft 大力拥抱开源社区的今天,使用 Windows 作为开发环境已经不是令人难以接受的事情了——当然前提是你使用 WSL2,我不会真的在 Windows 这样的 OS 上做开发的。微软的 Windows 虽然从来都广受诟病,但它的桌面环境体验不是其它竞争者(是的,我是说 Linux。你说什么 m 什么 OS 是啥,我听不见)可以比拟的。如果说曾经基于 BSD 内核的 macOS 拥有类似 UNIX 的开发体验,那么 WSL2 则是 99.9% 的 Linux 开发体验,这对于我来说是非常重要且舒适的。是的,绝对不是因为我要用 Windows 打游戏。

因为基于虚拟机的 dev box 使得备份和迁移变得异常方便,全虚拟化环境的拟真也能带来许多优势,而 WSL2 和 Windows 的集成也足够顺滑,所以我想,在可以预见的将来,我的开发环境仍然会首选宿主机 Windows + Linux / Windows dev box 的模式来配置。

zshrc 启动速度分析和优化

由于常年不科学的使用和随便塞东西,我的 .zshrc 里有太多太多的各类语言、SDK 的启动逻辑,因而它逐渐变得不堪重负起来。今天终于受不了了,我决定对它进行整理,移除部分太慢的代码,并且将部分不需要实时加载的东西懒加载。

速度优化的前期准备

要开始优化,首先需要有科学的评估速度的方法,这将使我们能够找到速度的瓶颈。

测算总启动速度

使用 time 命令,可以测算 zsh 的启动时间:

$ \time zsh -i -c exit
        6.62 real         3.23 user         2.29 sys

可以看到,我的 zsh 启动时间需要 6.62 秒,可以说是十分糟糕的速度了。作为对比,不加载任何启动命令脚本的 zsh 启动速度飞快,甚至只需要 0.01 秒:

$ \time zsh --no-rcs -i -c exit
        0.01 real         0.00 user         0.00 sys

设定优化目标

一个合理而可以达到的目标对速度优化也至关重要。今天,我的目标是不修改第三方代码的情况下,将加载时间优化到一秒以内,而尽量不损失任何功能。我们评估时间所用的方法就如同上文所述,以 time 测算的 real 时间为准。

找到速度瓶颈

找到速度瓶颈的方法通常是运行“性能评估”,也就是 Profile。由于 zshrc 是一个 zsh 脚本,我需要寻找一些 zsh 脚本的 profile 方法。

一番查找之后,找到了 Profiling zsh shell scripts 这篇文章。按照文章中描述的方法,我们在 .zshrc 的最前面加入:

PS4=$'\\\011%D{%s%6.}\011%x\011%I\011%N\011%e\011'
exec 3>&2 2>/tmp/zshstart.$$.log
setopt xtrace prompt_subst

在最后面加入:

unsetopt xtrace
exec 2>&3 3>&-

然后执行 zsh -i -c exit 让 zsh 运行一遍初始化。执行完成后,你应该可以在 /tmp 下看到输出的结果:

$ ls -l /tmp/zshstart*.log
-rw-r--r-- 1 oott123 wheel 470745 Jun  9 16:26 /tmp/zshstart.8854.log

这个日志文件已经可以看了,只不过,人类似乎很难阅读……万幸的是,文章的作者也给出了一个工具,用于把输出的文件转换为 KCachegrind 可读的 callgrind 文件。然而,它是 OCaml 写的,也没有提供预编译二进制文件,我们必须先安装 OCaml 来编译运行它。为了速度,那就装吧!

由于我们在 macOS 下工作,通过 brew 可以很轻松的安装 OCaml、opam和 QCacheGrind(这里使用 QCacheGrind,效果和 KCachegrind 应该一样):

brew install ocaml
brew install opam
brew install qcachegrind --with-graphviz

然后使用作者提供的工具 zshprof 将日志文件生成 callgrind 文件,并使用 QCacheGrind 打开它:

git clone https://github.com/raboof/zshprof.git
cd zshprof
opam init # 完了,我们还没开始优化,又有一个程序往 .zshrc 里写东西了……这就是为什么它越来越卡
eval `opam config env`
opam install ocamlfind

# ocamlfind ocamlopt -linkpkg -thread -package str ZshXtraceToCallgrind.ml
ocamlfind ocamlopt -linkpkg Callgrind.ml -linkpkg ZshXtrace.ml -thread -package str ZshXtraceToCallgrind.ml
./a.out < /tmp/zshstart.8854.log > zsh.callgrind
qcachegrind zsh.callgrind

记住这个艰辛的过程,我们在优化途中会经常运行它,以检查优化效果。

打开 QCacheGrind,找到你的 zshrc 文件的源码,点击按 micros 排序:

QCacheGrind 主界面,其中显示了每行源码的耗时。

(由于我个人将自己的所有 rc 代码都写到了一个叫 .shellrc 的文件里,因此这里的截图是 .shellrc 这个文件的。)

很显然,大量类似 dvmphp-version 这样的版本管理工具初始化命令和他们的补全函数消耗了绝大多数时间。我们就从这些函数入手,优化我们的 shell 加载速度。

移除不必要的进程创建

不看不知道,一看吓一跳。就拿下面两句来看:

[[ -s "$(brew --prefix dvm)/dvm.sh" ]] && source "$(brew --prefix dvm)/dvm.sh"
[[ -s "$(brew --prefix dvm)/bash_completion" ]] && source "$(brew --prefix dvm)/bash_completion"

光这两句,就执行了 4 次 brew --prefix dvm,而这个命令在我的机器上执行一次需要 0.7 秒:

$ \time brew --prefix dvm > /dev/null
        0.71 real         0.37 user         0.19 sys

为了加载 dvm 而执行的 brew 就用掉了 4*0.71=2.84 秒,这还不算 dvm 本身的加载时间!而对于我而言,brew --prefix dvm 的结果执行一万次也不会改变,一定是 /usr/local/opt/dvm ——因为我知道我不会移动默认的 prefix 位置。那么,将 brew --prefix 命令都替换为字符串:

[[ -s "/usr/local/opt/dvm/dvm.sh" ]] && source "/usr/local/opt/dvm/dvm.sh"
[[ -s "/usr/local/opt/dvm/bash_completion" ]] && source "/usr/local/opt/dvm/bash_completion"

再跑个分试试:

$ \time zsh -i -c exit
        1.62 real         0.93 user         0.69 sys

哇,真是成效显著,一下就从 6.62 秒缩短到了 1.62 秒,整整减少了 5 秒钟!

移除 brew 之后 QCacheGrind 的样子

重新跑一次 profile,也可以看到,那些明显拖慢启动速度的项目已经没有了。顺便吐槽下:Ruby 和 brew 启动也太慢了吧……

现在,我们还剩下一些别的命令初始化和命令补全的耗时。这些命令看起来很好,只是他们的内部耗时相对较大。

懒加载命令和补全功能

为了不影响功能,又不修改第三方代码内部实现,我们无法很好的优化那些非常缓慢的命令初始化过程。但是,大多数情况下,我不会用到其中大多数命令。因此,我希望实现“懒加载”功能,在我首次使用这些功能的时候,zsh 帮我初始化他们。

懒加载的好处是启动快,缺点是运行的时候会比较慢。但这个慢是分散的,不会全部都卡在启动的那几秒钟里,所以我认为效果损失是可以接受的。那么,怎样懒加载他们呢?

一个很简单的方法是,把命令换成一个占位函数,然后在这个函数中再去执行真正的二进制文件。比如:

dvm() {
    # 移除占位
    unfunction "dvm"
    # 加载真正的 dvm
    source "$(brew --prefix dvm)/dvm.sh"
    # 加载 dvm 的补全
    source "$(brew --prefix dvm)/bash_completion"
    # 执行真正的 dvm 命令
    dvm "$@"
}

(上述代码实现参考自:Speed up initial zsh startup with lazy-loading,基于 CC-BY-SA 使用)

但这样,第一次使用 dvm 的时候,就没有命令补全了!于是,命令补全也用同样的方法做懒加载:

__lazycomp_dvm() {
    # 移除占位
    compdef -d dvm
    unfunction dvm
    source "$(brew --prefix dvm)/bash_completion"
}
compdef __lazycomp_dvm dvm

这样,在第一次按 Tab 的时候,就会加载 dvm 的补全。由于不同命令的补全逻辑不一样,所以还是没法第一次执行补全命令,但多按一次 Tab 键至少比多执行一次命令好多了。

把这两个懒加载方法写成函数:

my_lazyload_add_command() {
    local command_name=$1
    eval "${command_name}() { \
        unfunction ${command_name}; \
        _my_lazyload_command_${command_name}; \
        return ${command_name} \"\$@\"; \
    }"
}
my_lazyload_add_comp() {
    local command_name=$1
    local comp_name="_my_lazyload__compfunc_${command_name}"
    eval "${comp_name}() { \
        compdef -d ${comp_name}; \
        unfunction ${comp_name}; \
        _my_lazyload_comp_${command_name}; \
    }"
    compdef $comp_name $command_name
}

再把 dvm 等不太常用的命令初始化逻辑用这两个函数写出来,比如说这样:

_my_lazyload_command_dvm() {
    source "/usr/local/opt/dvm/dvm.sh"
}
_my_lazyload_comp_dvm() {
    source "/usr/local/opt/dvm/bash_completion"
}
my_lazyload_add_command dvm
my_lazyload_add_comp dvm

搞完之后再跑个分试试:

$ \time zsh -i -c exit
        0.37 real         0.24 user         0.18 sys

哇,已经只有 0.37 秒了。再看看 Profile,大头已经到了 oh-my-zsh 里:

最后的 Profile 结果

打开 zsh 一看,确实感觉快多了。试试那些被我们 lazy load 的命令,用起来感觉也没有什么延迟。优化初见成效,收工。

对了,完成之后记得把一开始我们添加到 .zshrc 中的几行 Profile 代码干掉。否则,它会创建一堆临时文件,并且它本身也会影响一点点速度。

如何让你的 .zshrc 更高效

这次优化,也让我看到平时写 shell rc 文件的一些常见误区,这些问题可能导致 shell 启动慢到爆表。总结说来,主要是这几点:

  • 尽量避免在初始化脚本中调用外部进程,特别是脚本语言的解释器,比如 node, ruby。他们的冷启动时间非常长,长到你怀疑人生。
  • 避免重复执行语句,特别是调用外部进程的语句。
  • 避免增加不必要的初始化代码。比如调用 nvm 初始化 node.js 版本。应当利用懒加载或者 avn 等方式来做这个事情,或者干脆写死环境变量。
  • 尽量多使用懒加载,避免加载不必要的函数。

其实今天本来还想顺便把 .zshrc 给模块化,并加入版本控制的,但调优它本身花掉了太多时间,这篇文章也足够长了,就下次再弄吧。