Skip to main content

喜欢 ChromeOS?那就一起吃早午茶吧

· 28 min read

前言

即使到了 2020 年,同时支持触屏和键盘的二合一设备和使用“网络代替本地”的 ChromeOS 都仍然是十分小众的概念,甚至有点凉。其中原因有很多,比如二合一设备无论使用 Android 还是 Windows 体验都很别扭,而如果你尝试本文即将提到的 ChromeOS,你会发现它的使用门槛对于一般消费者而言太高了。ChromeOS 作为一个以 Chrome 浏览器为核心的操作系统,只能承担比较轻量的使用情景,相比三大主流操作系统缺少了很多第三方支持。但是如果你恰好有一个比较轻量的使用需求,又能够迈过 ChromeOS 的使用门槛,我相信你将会获得舒适的使用体验,这也是本文写作的缘由。 ChromeOS 的优势是具有包括 Chrome 浏览器生态和 Android 应用生态的谷歌全家桶生态支持,属于 PC 中最好的 PAD,(即使苹果布局 IpadOS,仍然是)PAD 中最好的 PC,最适合 ChromeOS 的设备就是可拆卸键盘的二合一设备,而我使用的则是二合一设备的标杆:Surface 写到这里前言就可以结束了,下面是免责声明 本文不适用于 NVIDIA CPU 设备和不支持 UEFI 的设备 ChromeBook 用户,FydeoOS 用户,CloudReady 用户可以跳过前半部分内容
不推荐任何没有 Linux 或 EFI 基础的用户尝试本文操作,不推荐在非二合一设备上安装 ChromeOS,不推荐将 ChromeOS 作为唯一系统
如果你所在的地区无法访问谷歌服务,请不要尝试安装 ChromeOS,你可以选择 FydeOS(这条没给钱
在安装和使用过程中如果有任何重要数据,做好备份
本人设备是 Surface Pro 3 - i5 版,建议其他型号用户安装前检查是否有兼容性报告

回顾

我对于 ChromeOS 算是比较熟悉了,在一年前还没有 brunch 项目时使用过基于 ChromiumOS 二次开发的 FydeOS,也尝试过 Project Croissant,在我之前的文章中有所记录。那时最大的问题是 SP3 的 WIFI 模块驱动不正常,影响使用。后来在被吃掉的 2020 年上半年,Brunch Framework 项目出现了,所以当我开始着手使用 brunch 时已经有人测试过了在 SP3 上的兼容性,螃蟹没吃成,但是坑少了也是件好事。 我在通过 brunch 安装 ChromeOS 之后第一时间测试了硬件兼容性,对于 SP3 测试的重点就是 WIFI 稳定性和睡眠支持,结果很完美:WIFI 没有出现过异常,电池睡眠12小时不掉电正常唤醒。typecover 和 pen 也正常,唯一一个我发现的异常就是前置摄像头,不过 SP3 这种素质的摄像头没有也不会影响使用。但是在近几天的使用过程中出现了一些不易排查的小毛病,比如电池电量有时会停止刷新;typecover 插入检测有时会失败;从睡眠唤醒有时按一下电源键即可,有时又需要按多次电源键。总的来说仍然不适合对系统稳定性要求较高的用户。

正题

一顿香甜的早午茶

Brunch Framework 可以说是一个改变了非官方 ChromeOS 体验的项目,在此之前的各种二次开发项目不是兼容性有缺陷就是功能有缺陷,brunch 在不修改系统功能的前提下实现了兼容性更强的硬件适配,具体的实现方式可以自行查看源代码。而 brunch repo 的数据也很有意思,截至本文写作时拥有 500 star 、 50 fork,还有 460 issue,可见尝试 brunch 的人还是很多的。issue 中有一份 SP3 设备兼容性报告写到 brunch 对 SP3 的兼容性出奇地好,所以我就直接上手开始安装了。 我选择的是 Windows + ChromeOS 双系统方案,因为这个方案很常见而 brunch 对这个方案的描述并不详细,所以还是值得一提的,其他安装方式就请读者自己尝试了。

准备工作

  • Windows 的安装就略过了,硬盘全抹然后交给安装镜像自己分区。
  • 一个 ext4 分区,这里给一个参考,我给 ChromeOS 准备的是 64GB 存储空间,ext4 分区的大小是 65.3GB。不要问多出来的去哪了,被我吃了
  • 一个 ChromeOS 的恢复镜像。根据 brunch 的建议,4代以上英特尔 CPU 使用 rammus(即 ASUS Chromebook Flip C434)的恢复镜像,但是 brunch 提供的恢复镜像查找网站疑似关闭,如果打不开可以寻找类似的网站,它们提供的都是谷歌官方的下载地址。
  • brunch 的 release 文件
  • 一个 Linux shell 环境,无论是哪个发行版、WSL 还是 Android,只要你会用就行
  • 一个用来刷写 LiveCD 的 U 盘

如果你使用的是3代及以前的 intel CPU 设备或 AMD CPU 设备,你需要根据 brunch 的描述选择其他恢复镜像

制作包含 brunch 的恢复镜像

进入你的 Linux shell 环境,来到存放恢复镜像和 brunch 的位置,保证这个位置有至少 14GB 的可用空间

sudo tar zxvf brunch_< version >.tar.gz
sudo bash chromeos-install.sh -src < path to the ChromeOS recovery image > -dst chromeos.img

然后用你喜欢的方式把生成的恢复镜像刷写到 U 盘上,这一步就算完成了

安装系统到硬盘

从上一步得到的 LiveCD 引导启动,如果你没有关闭 Secure Boot 的话会出现警告,然后你沿着OK->Enroll key from disk->EFI-SYSTEM->brunch.der->Continue操作一番之后重启再次引导就会进入系统了。 进入欢迎页面后为了不浪费时间可以直接以访客模式进入桌面,打开 Chrome 浏览器按CTRL+ALT+T进入 crosh,再输入shell进入 bash 命令行,接着挂载 ext4 分区并写入镜像

mkdir -p ~/tmpmount
# 这里就用到了前面提到的那个 ext4 分区
sudo mount < the destination partition (ext4 or ntfs) which will contain the disk image > ~/tmpmount
sudo bash chromeos-install -dst ~/tmpmount/chromeos.img -s < size you want to give to your chromeos install in GB (system partitions will take around 10GB, the rest will be for your data) >

脚本运行完毕后会输出 grub 的启动配置,建议你把这个配置保存起来,官方提供的方式是保存到 LiveCD 的引导配置里

# select GRUB configuration and CTRL+SHIFT+C
sudo edit-grub-config
# paste the text (CTRL+SHIFT+V) after the second line
# save & exit

然后就可以卸载分区了

安装 rEFInd 引导器

这一步是可选的,但是 rEFInd 它真的很好用,强烈推荐。

rEFInd 是一个 EFI 引导器,有比 grub 更好的界面和触屏支持,但是不能用于引导 brunch。然而众所周知只要配置写得好,EFI 就可以链式启动,所以我们配置使用 rEFInd 作为首选引导器,如果需要使用 ChromeOS 则由 rEFInd 引导 grub 引导 ChromeOS 启动。配置完成后的 rEFInd 和 ChromeOS 搭配起来会有很无缝的使用体验。 从官网可以获得二进制压缩文件,接下来的步骤可以在 LiveCD 中操作也可以在 Windows 中操作(但是 Windows 对 EFI 分区的文件操作并不友好)。 首先挂载 EFI 分区,把 LiveCD 中的 grub 放到 EFI 中,前文提到的 grub 启动配置也加到配置文件的第一启动顺位中,然后将下载的 refind 放到 EFI 中

  1. 修改 refind.conf,查找enable_touch并删除前面的井号
  2. 你肯定会嫌弃 rEFInd 默认主题丑的,在 github 搜索 refind-theme 可以找到第三方主题,但是换主题的事可以在它能够正常工作之后再做
  3. rEFInd 会将 ChromeOS 显示为 Linux 的小企鹅 logo,如果你想要显示 Chrome 的 logo 的话手动配置一下启动入口和对应 logo 就可以了
  4. 如果你需要 Secure Boot 支持,根据官方教程配置即可,我选择的方案是 Shim
  5. 修改 UEFI 启动顺序,将 refind.efi 设为第一位(如果你配置了 Secure Boot 支持则为对应的 efi 文件)

配置好之后 EFI 大概是这样的

现在你可以丢掉 LiveCD,重启电脑了

rEFInd-regular 主题

进入系统

成功从硬盘引导之后,完成 ChromeOS 的初始设置,登录谷歌账号,就可以正式开始使用了。 建议这个时候先测试一下系统对各个硬件的支持情况,如果没有什么重大 bug,那么我们就可以进入下一节的日常使用了。

一台丝滑的触屏 PC

如你所见,本文不是介绍 ChromeOS 的软文,所以有关系统本身的各种功能就不再罗列了,只提几个我认为值得注意的地方。

  1. 首先是触摸板的使用体验个人认为比 Windows 下舒服一些,可能是触摸屏适配的连带效果吧。在 Chrome 浏览器中单指点击左键;双指点击右键、上下滑滚动、滚到顶部后继续下滑刷新(需要配置)、左右滑向前向后进;三指点击中键、左右滑切换标签页、上下滑打开关闭虚拟桌面菜单。在部分安卓应用中也有一定的触摸板支持,所以完全没有接鼠标的必要。
  2. 输入法是 ChromeOS 的一个痛点,系统自带的输入法能凑活用,安卓容器的输入法可以触屏用但是不能正常配合键盘使用。
  3. 浏览器和安卓应用都可以通过 fcm 推送通知,但你使用的安卓应用不一定支持 fcm。

系统安装完成了,那我们日常使用的软件怎么办呢?ChromeOS 给我我们很多选择:

  1. 使用 Chrome 浏览器插件或应用
  2. 使用 Android 容器(ARC++)
  3. 使用 Linux 容器(Crostini)
  4. 使用 CrossOver for ChromeOS

下面我们逐个挖掘一下各个使用方式

Chrome 到底能做到什么程度

Chrome 插件是无论在哪个系统都会用得到的东西,这里只说一个Tampermonkey也就是国内俗称油猴脚本的插件,ChromeOS 上很多优化体验的方法都要依靠这个插件,比如触摸屏视频优化,还有下面会提到的对 PWA 的体验优化。

说一说 PWA,以 Discord 为例

我很早就认识到了 Chrome 在浏览器领域的霸主地位,也知道谷歌一直在推动 PWA 的发展,但是真正改变了我对 Chrome 认知的是 Discord。 打开 discord 首页,登录账号就会进入 discord 网页应用,网页应用和客户端长得没什么区别,右键打开的菜单也不是浏览器该有的菜单而是应用内的菜单,进入语音频道浏览器会提醒你是否授权访问麦克风,打开屏幕分享,浏览器会让你选择要分享的屏幕或窗口,窗口放在后台的时候如果有新消息浏览器会通过系统通知提醒。这一切听起来顺理成章,但放在几年前这种事情根本不可想象,因为归根结底,你打开的只是一个网页(严格来说,这种程度的 PWA 支持已经不是传统意义上的网页了)。

通过上面的例子就可以看出当前的 Chrome 浏览器已经能够在一定程度上代替客户端了,同时得益于 Chrome 对资源缓存的执着,使用网页应用时对网络的要求也不是非常高。在 ChromeOS 中,只要在打开的网页上打开浏览器菜单,选择更多工具-创建快捷方式-勾选在窗口中打开-确定,Chrome 就会尽量将这个网页当作应用来处理。如果你对 discord 做这个操作的话会发现生成的快捷方式图标并不清晰,窗口的顶栏依旧是浏览器默认的白色,针对这一点我编写了一个 UserScript,你可以在我的博客找到它的介绍和下载地址。

目前提供了比较好的全套 PWA 办公服务的公司并不多,除了谷歌自家还有以擅于给别人写软件闻名的微软。在跨平台这个概念上微软是十分领先的,比如硬是把 android 平台的 office 做出了 PC 的味道(后面还会再提)。我本人的大部分工作依赖的是微软的生态,所以在这方面尝试比较多,如果你依赖谷歌的生态的话体验应该会更好。office 的网页版都支持了 PWA,其中 onedrive 和 outlook 使用体验都很好,而 word、powerpoint、excel、onenote 作为功能复杂的应用都不是很适合在网页上使用,顶栏颜色的问题依旧可以使用脚本解决

你的安卓平板不一定是安卓平板

还有可能是 ChromeBook

ChromeOS 所用的 Android Runtime 具有高效的 arm to x86 指令集转换,使得 ChromeOS 获得了安卓应用生态的支持,只要在 ChromeOS 中启用容器就可以看到熟悉的 Google Play,而 ChromeOS 中 Google Play 缺失的应用并不多,所以如果有哪个应用的网页版无法满足你,还可以用安卓版来弥补。 我安装的安卓应用不算多,比如没有网页版的酷安,可以与手机同时在线的 QQHD,还有 Microsoft Office,Office 应用是目前为数不多的对宽屏优化的安卓应用,在宽屏下 UI 与 Windows 版本很相似,但是功能没有那么完整,而且需要 Office 365。 作为一个优秀的安卓开发者,微软还适配了窗口模式的顶栏颜色,而绝大部分应用都是默认的黑色

不如先试一试 ChromeBrew

如果你知道 HomeBrew,那你就知道了 ChromeBrew brunch 默认启用了开发者模式,如果你不是开发者,可能不会对本小节感兴趣,甚至需要关闭开发者模式 ChromeBrew 是社区为 Chrome 编写的包管理器,经过四年的发展目前已经非常完善了,支持的软件包也越来越丰富。与 Linux 容器不同,crew 是安装在 ChromeOS 本身的命令行环境中的,就是那个你在安装阶段使用CTRL+ALT+T打开的命令行环境。因为 ChromeOS 部分路径只读,所以 crew 会把文件放在 /usr/local 下,由于 ChromeOS 阉割了大量命令行工具,所以 crew 的安装耗时也比较长,安装操作倒是简单,一行即可

wget -q -O - https://raw.github.com/skycocker/chromebrew/master/install.sh | bash

使用 ChromeBrew 还是 Crostini 更多的还是要看个人喜好,前者可以让你更方便地在系统层面操作,后者清除数据的成本更低。仅仅一个包管理器可能并不会让人抛弃 Crostini,但是如果再加上一个强大的编辑器呢?接下来我们介绍在前面的截图中多次出现的 VScode

我不知道喜欢 VScode 的人有多少,我只知道我是其中之一。在其他平台,你可能因为有更喜欢的编辑器而放弃 VScode,而在 ChromeOS 里 VScode 大概是唯一选择了。如果你使用 crew 或者 crostini 安装 vscode,你会发现它对于触摸屏的支持十分差,只能响应最简单的点击事件。但是我们还有另一个选择。 VScode 是基于 electron 开发的开源软件,开源特性使得修改源码成为可能。而 electron 是一个以 Chromium 作为前端,Node.js 作为后端的跨平台应用框架,发布应用时将两端打包成一个可执行文件供用户使用,这使得拆分 VScode 成为可能。即使你不熟悉前端技术栈,也可以想到我们可以把 VScode 的后端单独运行,然后将独立的 Chrome 浏览器作为前端使用,按照这个思路我们可以把后端放在任意一个拥有网络支持的 Linux 环境中,前端可以放在任意一个可以访问到后端的位置。理论很简单,实现起来还是有一定难度的,但幸运的是已经有人做到了:

code-server 项目

考虑到一年前的 code-server 使用方法已经不适用于现在,下面介绍的使用方式也可能在某个未来不再适用 以下使用的是系统命令行环境,并且会将 code-server 配置为开机自启动 code-server 的配置稍微有一点复杂,首先让我们抛弃官方的安装方式,直接下载 release 文件并放到一个路径中,这里以/opt为例

wget https://github.com/cdr/code-server/releases/download/ <version> /code-server- <version> -linux-x86_64.tar.gz
tar -zxvf code-server- <version> -linux-x86_64.tar.gz
mv -r code-server- <version> -linux-x86_64 /opt

然后为 code-server 编写 upstart 配置

# /etc/init/code-server.conf
start on started system-services
stop on stopping system-services
respawn

exec sudo -u chronos /opt/code-server/node /opt/code-server

保存后重启系统,回到命令行环境,检查~/.config/code-server路径是否存在,(如果不存在还可以检查一下/mnt/stateful_partition/encrypted/chronos/user/.config/code-server路径,)在该路径下保存着 code-server 自动生成的配置文件,打开配置文件可以修改监听地址和前端的访问密码。修改之后在命令行执行sudo restart code-server,在浏览器中打开对应的端口即可看到 code 页面。

code-server 出于某些原因不能使用 VScode 的 logo,但是作为用户我们可以自己修改回去。首先我们修改 PWA 的 logo

cd /opt/code-server/src/browser/media
curl https://code.visualstudio.com/favicon.ico -o vscode-favicon.ico
vim manifest.json
# 修改 icon src 的文件名为 vscode-favicon.ico

此时删除 code-server 页面的所有缓存重新加载并点击地址栏的安装应用看到的应该就是 VScode 的 logo 了,如果还想修改页面内的 logo 可以使用我编写的脚本,同样可以在我的博客上找到。 现在我们得到了一个像模像样的“vscode-server”,你可以尝试以下它的各种功能,与官方的客户端版本没什么差别。但是在我使用的时候我发现它的默认设置和 VScode 有些许不同,比如在 VScode 中自动保存默认关闭,而在这里是默认开启,不过这些都取决于你的个人喜好。code-server 同样适用官方的插件中心,但相比客户端版本会缺失部分插件。

一个便携开发环境

装好了 ChromeBrew 和 code-server,一个轻量开发环境就初具雏形了。现在按照你的需要安装一些 code 插件,在 code 里调出 bash,用 crew 安装你需要的软件包,运行你的代码,只要你的代码对标准 Linux 系统环境没有严重的依赖,剩下的应该就是性能问题了。 如果你的项目有基于 X11 的图形界面,那你大概不会正常的看到它打开,你需要一个 sommelier 来将 X11 应用的窗口投影到 ChromeOS 的桌面环境中(crew 提供的 vscode 就是如此实现的)。

如果你觉得 code 的开发环境太轻量了,即使是二合一设备也应该能运行 JetBrains 全家桶才行,那只需要下载 Linux 版本使用上面提到的 sommelier 投影窗口即可。 如果你不只是开发者,还是个艺术创作者,需要使用 Adobe 全家桶,请注意最开始安装系统的时候我们使用的是双系统方案,重启到 Windows 即可。

似乎不需要再介绍 crostini 了

经过上面的一系列配置,似乎已经解决了很多棘手的问题,而且相比系统环境,crostini 需要额外的启动时间,我本人是没有启用 crostini 的。 和安卓容器类似,crostini 也是在设置中启用,等待系统自动安装即可,一般来说 crostini 的使用会比系统命令行容易一些,也更难对系统造成损伤,如果你想要了解高级操作可以参考Arch Wiki:如何在 Crostini 中安装 Arch Linux

可以尝试的 CrossOver

CrossOver 是基于 wine 的商业软件,wine 的目的是在非 Windows 环境中运行为 Windows 编写的软件,CrossOver for ChromeOS 通过 Google Play 分发,可以实现在 ChromeOS 上运行常用的 Windows 软件,虽然会有各种各样的小毛病,不过也值得一试。 不过就像前面提到的,我们是使用的是双系统安装方案,ChromeOS 作为日用系统可以给你更好的操作体验,但如果你要开始进行一些 ChromeOS 无法胜任的工作,何不直接重启系统到 Windows 中使用呢?

结语

其实结尾没什么好说的,这篇文章中提到的很多内容和我一年前写的有关 ChromeOS 的文章没什么区别,只是经过几个版本的更迭,有关 ChromeOS 的项目更加成熟,让我有了再写一篇的想法。我仍然是经常带着 Surface 出门,再加一只充电宝足以应付一天的使用,熟练地在触摸板或触摸屏上划来划去,遇到 ChromeOS 无法解决的问题就悄悄地切换到 Windows 再切回来,想要给别人安利却又不敢。或许有了这篇“万字使用说明”,会有人尝试 ChromeOS 并感受到我所感受到的舒适与纠结。