liang2kl's Blog

死亡谷国家公园自驾游记

liang2kl@outlook.com (Liang Yesheng) — Fri, 21 Mar 2025 21:44:00 -0700

最近在计划暑假找时间走一走美西国家公园环线，本来考虑在环线的最后穿过死亡谷回圣地亚哥，但是夏天死亡谷的平均气温接近地狱，不太现实。但死亡谷是一个非常特别的国家公园，而且距离圣地亚哥近，不去有点可惜。于是说走就走，提前不到一个星期极限用脚本抢到了 Furnace Creek 的露营地，买了各种装备，在考完试的第二天就开始了这次自驾。

这次行程没有找人一起，一个原因是我打算在死亡谷住车里露营，超过一个人睡不下；更加根本的原因是我比较喜欢实现自己一些奇怪的想法，与其他人出行必定需要妥协。反正距离不远，而且有 FSD，开车几乎不需要消耗精力，一个人自驾完全没有问题。

准备

第一次自驾+露营没什么经验，因此计划做得比较详细。最头疼的是车的续航问题：我的车是 Model 3 标续，电池衰减后之后只有大概 250 英里的续航，面对长途旅行有点捉襟见肘，因此所有计划都得考虑到两点之间的距离。

首先是对开车和休息的计划。从圣地亚哥直接去死亡谷太远，第一天几乎没有可以游玩的时间，因此最终决定在拉斯维加斯住一晚，第二天大概开 2 个小时就能到死亡谷游客中心，中途经停 Pahrump 充电；最后一天直接从死亡谷开车回家。

其次是确定在死亡谷要玩的几个地方。我根据 Your Guide 的推荐选择了靠近 Furnace Creek 露营地（也是游客中心）附近的五六个观景点和徒步路线，从而避免电量耗尽，因此也没办法到死亡谷的其他区域玩。不过，最热门的景点基本都集中在 Furnace Creek 附近，就两天的行程而言已经是非常充足了。路线确定后需要大概预估一下续航能不能撑得住。我当时预估续航是直接通过 Google Maps 的距离算的，预留了 10 英里的容错空间。最后发现这种方法不是很准确，因为上坡消耗的电量远大于平地，而下坡由于动能回收反而能够增加续航，但整个行程算下来也没有太大误差。最准确的方法是通过特斯拉的 app 或者网页来预估，这个预估考虑了海拔高度的变化，实际测量下来误差大概在 5% 以内。

最后是物资的准备。我带了三张被子，一张当作床垫，另两张来盖。为了体验露营，我还买了一捆木柴生火；事实证明这是一个错误的选择，暂且按下不表。另外，露营灯和手电筒非常重要，因为露营地漆黑一片，伸手不见五指。其他一些极大改善露营体验的物品包括：耳塞、眼罩、露营椅，等等。总之装备多多益善。

出发前还订阅了每月 99 刀的 FSD，并从 v12.5 升级到了 v12.6，表现有非常大的提升。事实证明这 99 刀非常值：这次路上 95% 以上由 FSD 驾驶，在高速和城市道路上几乎没有任何问题；在国家公园里晚上驾驶时偶尔有幽灵刹车的问题，不过因为周围几乎没有车，因此影响不大。总的来说 FSD 极大程度上解放了驾驶员，在 roadtrip 中能够为司机节省宝贵的精力用于游玩。

第一天：圣地亚哥到拉斯维加斯

第一天早上 10 点从圣地亚哥出发，上 15 号公路就可以直达拉斯维加斯，全程在高速最左道上巡航，没有任何心智负担。算上充电，全程大概 5 个半小时，一共 326 英里（521 公里），不算太远。15 号公路上的风景很不错，途径雪山、沙漠、峡谷，第一次开这条路线不会觉得无聊。

I-15 沿途的雪山

我对拉斯维加斯本身没有太多兴趣，到酒店之后直接点了 Panda Express 在房间里吃。之后去隔壁的 Park MGM 看了 Maroon 5 的演唱会，体验、氛围和 Adam 的状态比预期好不少。看完演唱会就回去睡觉了。

Maroon 5 演唱会

第二天：游玩死亡谷

早上 10 点准时从酒店出发，1 小时 10 分钟后到了 Pahrump 充电；30 分钟后充满，再开 40 分钟就到了 visitor center。在里面按惯例买了冰箱贴，拿了地图和指南后就开始去各个地方玩。

第一站去了 Artist’s Palette。去这里的路叫做 Artist’s Drive，是一条先上坡后下坡的单行道，弯道很急，并不是特别好开。这里的地貌由很多小山坡组成，每个山坡由于不同矿物质沉积的缘故显示出迥异的颜色，看上去就像调色盘一般，而 Artist’s Palette 这种特点最为突出，尤为漂亮，因而得此名。

也许是因为下午 3 点的光线没到最佳，现场看到的像是低饱和度的版本，整体偏灰褐色，但仍然很好看。眯上眼睛，朦胧中看到了《千里江山图》的色调。在远处拍完照之后，走到了山丘上近距离观察了一会不同颜色的岩石，像是置身画中一般。

Artist's Palette

沿着路继续往低处开，之前从高处俯视的白色盐碱地逐渐与路面平齐。这片盐碱地叫 Badwater Basin，是北美大陆最低点，海拔 -82 米。后方的岩壁高高耸起，半山腰上却立起了一块标示海平面高度的牌子，十分魔幻，可见此处地势之低。因此，水流进入这片盆地后无法流出，河水累积在盆地底部；而这里极高的蒸发速率使得水分无法长存，残余的盐便形成了一片广阔无垠、纯净的白色盐碱地。

Badwater Basin 的海平面标志

此时气温已经达到 30 度左右，越往盐碱地中心走人越少，到最后只剩下我和一个头发花白但精神矍铄的大叔。来美国半年已经习惯了迎面相遇时跟对方打招呼，上前互相问候一番后，我们开始聊了起来。

我们聊起了死亡谷。他说他上一次来是 20 年前，我问他这里 20 年来有什么变化，他说完全没有。景观没变，但人却经历了 20 年的时光：他上次跟妻子——当时还是女朋友——一起来这里，没钱住公园里的酒店，但 20 年后的现在他住进去了。我打趣说 20 年后我有钱了也回来住酒店，他笑着说一定会的。

他说自己在 18 年去中国出差，去了北京、上海和西安旅游。他说，自己世界各地飞，即使是出差时，也一定要抽出时间在当地转转。他的同事和他一起出差时总是说“这次算了，下次再玩”，但每次都是“next time”，从来没有实现过。他告诫说，要抓住机会去体验世界，人生一眨眼就过去了。我点点头，深以为然。

走在 Badwater Basin 上
拍完这张照片后，跟这位大叔聊了会天

跟大叔话别，我往回开，前往今天的最后一站：Mesquite Flat Sand Dunes。走进沙丘，我有意避开人群，朝着另一个方向走。在独自一人的时候，沙丘仿佛有种魔力，驱使着我不自觉地跑了起来，像个小孩子跌跌撞撞地反复冲上冲下一个又一个斜坡，尽管脚下的沙子不断打滑。

置身沙丘最独特的体验，是从不同角度欣赏光与影投射出的杰作。在落日的照射下，沙丘明暗两面有坚决而果断的分界，而暗面的渐变却像丝绸一样光滑。

走进 macOS Mojave 壁纸

将近日落，我终于走到了附近最高的一个沙丘。沙丘很滑，因此登顶最好的方法是找一个坡度较缓的角度登上顶部的沙脊，然后沿着沙脊走向最高点。在登顶的过程中，踩在完全没有其他人脚印的沙脊上一步一步向上走，整个沙丘为我独占，耳中只有呼呼的风声和自己的脚步声，心中突然涌现一种复杂而莫名的感动。

走在沙丘顶上

到了最高点，拍了几张照片之后，我把相机和手机放在一边，躺在沙脊上，头侧过一边，看着太阳缓缓落下。我没有拍照——相机只能记录下静态的画面，在这种时刻显得力不从心。

躺在沙丘顶上

待到日落后，我继续坐了 10 来分钟就离开了。其实这里的星空是最好看的，我本想坐到星空出现，但无奈接下来还要去 40 分钟以外的 Beatty 充电，一来一回晚上回到露营地已经很晚，就此作罢。充电回来的路上有一件趣事：我的耳朵因为气压的变化产生了和飞机下降过程中同样的不适，可见 Furnace Creek 区域地势之低。

回到营地后，我便开始准备晚上的露营。我首先生了火，在旁边坐着烤火，非常舒服。但是有一个致命的问题：晚上风很大，而且风往车的方向吹，以至于最后睡觉的时候车里面全是碳火的味道。另外，我买的木柴非常不禁烧，大概过半小时就快熄灭了；但烟还持续地散发。总之这篝火非常失败，也是这次旅途唯一一个不太完美的地方。

之后开始铺床。Model 3 的后排座椅不能完全放平，有一个小角度，但影响不大。我买的一张 twin size 的床垫保护罩刚好铺满了后备箱和后座，可见车内的空间足以睡一个安稳觉。

睡车里露营

铺完床之后就做到车外面看星星。死亡谷完全没有光污染，观星效果非常好。我没带三脚架，因此把相机架在椅子上随便拍了几张长曝光之后就单纯用肉眼看了。我完全不懂观星，只认得小学课上介绍的北斗七星；但完全不认得星星也能够轻易地被漫天的繁星震撼。

露营地的星空

看着看着就累了，于是钻进车里面，摇下车窗躺下来对着星空发呆。在车里面放了几首十分应景的音乐；这些唱得滚瓜烂熟的歌词在此情此景之下第一次产生了具体的含义。

Cause all of the stars / are fading away

Just try not to worry / we’ll see them some day

Take what you need / and be on your way

And stop crying your heart out

– Stop Crying Your Heart Out, Oasis

之后顺便看了 F1 中国站的冲刺排位赛，看完后已经是 1 点半了，实在是太累，一闭眼就睡着了。

第三天：返程

为了第二天不用再花 2 个小时去 Beatty 充电，我晚上睡觉的时候没有开空调，而是把车窗开了一条缝。刚睡觉的时候气温在 15 度左右，车内很舒服；到了后半夜沙漠开始展现它可怕的一面，气温骤降，导致我在 5 点的时候被冷醒了。醒来后转念一想，不如直接起床去看日出。这意味着我晚上只睡了 3 个半小时，却要开 6 个小时的车回家；但我做想做的事的时候就是这么疯狂，从不考虑后果。于是，穿上所有最厚的衣服，收拾好床铺，把放在外面的物资全部收拾齐全，就出发了。

大概 6 点到了 Zebriskie Point。这是死亡谷公认最好的日出观赏地，人出乎意料的多，以摄影佬居多，不到六点半就有接近 10 台相机架在三脚架上准备好拍摄了。日出时太阳将远处的高山染成金色，而山脚、山谷底部以及近景的金黄色岩石还处于所谓的蓝调时间内，冷暖对比鲜明，十分漂亮。

从 Zebriskie Point 看向染上金色的群山

本来计划中这一天去 Golden Canyon 进行徒步，但由于起得太早，完全没有体力徒步，就此作罢，于是便准备返程。在离开死亡谷之前，沿着 CA-190 的方向走一段距离后转向右侧，在开了一段不短的距离，并不断爬升高度后，来到了最后一个观景点：Dante’s View。这里可以俯瞰整个死亡谷全貌，底下就是前一天去的 Badwater Basin。有意思的是，这个角度正是《星球大战：新希望》里拍摄塔图因星球上莫斯艾斯利（就是 Han Solo 首次出场的地方）全景的取景地，也算是给这里稍显平淡的景观增添了一番趣味。

在 Dante's View 俯瞰 Badwater Basin

从 Dante’s View 下去，就正式开始返程。回去的路程稍显无聊，在 CA-190 上绝大多数时间内前后没有一辆车，非常容易犯困，特别是在前一天睡眠时间严重不足的情况下——我就好几次差点合上眼。幸好有 FSD 全程驾驶，不然还是非常危险。

6 个小时后，FSD 把我送回到了圣地亚哥，为这次接近完美的旅途划上了句号。

2023 年终总结

liang2kl@outlook.com (Liang Yesheng) — Sat, 30 Dec 2023 00:40:35 +0800

又到了翻相册写总结的时候了。今年做了很多事，去了很多地方；遇到了很多新朋友，也告别了一些老朋友；有了新的目标，也多了新的迷茫。

照片中的 2023

感染新冠

新冠成功防了三年半，终于在今年的五一假期的前几天感染了。到这个时候大家对疫情都已经麻木了，我也没带过口罩，因此感染也是迟早的事情。因为短时间内大量感染，只要在校医院发热门诊发现的阳性病例都强制要到近春园（就在学校里面）隔离。我在去校医院之前就知道这事，但是为了不感染室友就还是去了，然后不出所料被隔离了。

隔离的环境还算可以，没有想象中的单人单间，而是和另一个同学被分到了一个双床房里面。隔离的待遇很好，除了进去的时候发的一个零食大礼包，每天的伙食也非常好，都是一肉两素、加一个鸡蛋、再加一杯饮料的配置。这几天胃口竟然完全没有影响，每天都吃得非常饱，到最后都不舍得走了。

隔离餐 · 2023/4/29

感染期间其实并没有非常严重的症状，发烧两天就退了，第四天开始转阴。中间主要是咳嗽比较厉害，但做其他事情并没有很大的影响。第五天，隔离结束。

抗原检测 · 2023/5/3

好了之后，逐渐感受到了新冠的后遗症，最主要的症状是心动过速，静息心率经常上到 90 - 100，到现在都还没有完全恢复。新冠确实是名不虚传。现在新加坡疫情严重，为了不要再有新的后遗症，我在人多的地方还是选择乖乖地带上口罩，毕竟健康第一，牺牲一点方便和舒适还是值得的。

九字班毕业

因为大二的时候降转到了零字班，今年的毕业季我原来的同学就都毕业了。我借了同学的学士服，找了个时间跟室友和高中同学拍了毕业照。

#608B 毕业照 · 2023/6/25

在未名湖拍毕业照 · 2023/6/25

室友一个个搬出宿舍的时候，不禁鼻子一酸。四年的时间这么快就过去了，原来每天醒来就能看见的面庞，之后还能见多少次呢？

暑研 & 新加坡之旅

今年 8 月，我来到新加坡在 NUS 进行 6 个月的暑研。这是我第一次出国，出发之前多少还是有点忐忑，选择新加坡也是因为生活饮食习惯比较接近，而且可以讲中文，比较容易适应。从广州出发，四个半小时就到了新加坡，其实和去北京差不了多少，完全没有国际旅行的感觉。

到达新加坡 · 2023/7/30

关于气候

新加坡的气候非常有特点（槽点）。我刚来的时候是旱季，基本不怎么下雨，这种时候基本上过了十点之后太阳底下就没法呆了，晒一会儿就有灼痛的感觉；大概 11 月之后到了雨季，这时候又天天下雨，非常烦人。不过如果不下雨的话，新加坡的晚上非常舒服，不太潮湿的空气、轻柔的晚风以及 25 度左右的气温非常宜人。

家附近的日落 · 2023/9/26

圣诞节大雨 · 2023/12/25

到处玩玩

新加坡的 work-life balance 很好，周六日和公共假期不用去实验室，于是就有很多时间到处溜达。和 LT 一起去了新加坡的几乎所有景点：滨海湾花园、鱼尾狮公园、植物园、国家博物馆、圣淘沙、樟宜机场、动物园、牛车水、小印度，等等。新加坡就这么点地方，逛到后面都没地方去了，只能重新去之前去过的地方逛，其实也挺无聊的。

来之前买了个微单，拍了很多照片。

新加坡 CBD（手机拍的）· 2023/8/7

各种活动

新加坡的活动非常多。国庆日在滨海湾有烟花和空军阅兵，去现场凑了凑热闹。人实在是非常多，距离烟花三个小时基本上现场就都满了，过了一会儿就不允许人进来了。

国庆日的人群 · 2023/8/9

暑研正好赶上 F1 新加坡站的比赛，三天的比赛去了两天。比赛前一天参加了维修区，近距离参观了各个车队的 P 房，并且十分幸运地拿到了周冠宇的签名。

F1 维修区参观 · 2023/9/14

平安夜的时候去乌节路凑了个热闹，也是非常多人。其实新加坡没有什么圣诞的气氛，华人为主本来就不怎么过圣诞，另外在热带 20 多度的晚上过圣诞也没有圣诞的感觉。

乌节路圣诞游行 · 2023/12/25

朋友们

一到新加坡就赶上了何老师很长时间以来组织的第一次聚会，在老师家的 condo 烧烤。（全是中国人的组也太友好了😜）

何老师家聚会 · 2023/8/5

我并没有和组里面的同学在同一个实验室里面，而是坐在提供 funding 的 Institute of Data Science。除了可以自由摸鱼（划掉）之外，还认识了一群非常可爱的师兄师姐们（是的，我是实验室里面严格最小的）。非常幸运能够有这么一群哥哥姐姐们帮我融入新加坡的生活，带我到处吃喝玩乐，为我提供帮助和建议，这也让我这个社恐对之后的求学之路中的社交多了一点信心。

IDS 生日会 · 2023/8/29

IDS 年会 · 2023/12/21

关于出国/暑研

今年过年的时候下定了决心出国读研。之前有过几次出国的打算，但最后都因为还对保研心存幻想而无疾而终。我其实是不太喜欢走出舒适区的。倾向于保研，很大程度上是因为出国的准备非常麻烦，而且要面对一个完全陌生的环境。但是，原地踏步的绩点以及对这种过于功利的内卷的厌恶让我不得不考虑其他选择。我并不太想去国内其他地方（比如中科院或者上交）读博，除了内心还是有学历崇拜的思想作祟，也是出于这样一种心理：我在清华已经看到了国内学校的天花板，那么究竟比清华更好的学校是怎么样的？于是，就决定出国看看。

之后的大半年基本都是在围绕出国而做准备。考雅思比较轻松，虽然考口语还是非常紧张，最后也只有 6.5，但是总分 7.5 基本上所有的项目都够了。GRE 一直拖着没考，到最后发现 ETH 今年不需要 GRE 了，其他要求 GRE 的项目也不多，就懒得学了。

因为想要一封海外的推荐信，联系了 NUS 的何老师做暑研，老师要求实习 6 个月以上，想了想下学期如果休学不上课的话也能毕业，就这么定下来了。暑研的收获基本上符合我的预期。我对暑研的期望是经历一段完整的科研，并且对读 PhD 有更深入的感受和认识。我和 Qinbin 在 2 个月内弄出了一篇 LLM 相关的 paper，算是有了第一段完整的科研经历。有意思的是，这反而让我坚定了以后不搞 AI 的决心。这个领域的科研和我的想象相去甚远，我还是更加喜欢踏踏实实地去实现自己想要的东西的感觉——这是我在这次科研中没有体会到的。

对于要不要读 PhD 的问题，我跟很多人聊过，也算是体验过了 PhD 的生活，但是最后还是没有一个定论。我还没有在心理上准备好进行高强度的研究，也不一定喜欢做研究，而且还没有完全找到自己感兴趣的方向。所以，先读个 Master 或许是最合理的选择。

关于游戏

今年玩游戏挺多的。年初买了一台 Xbox Series S 来玩一些 3A 大作，后来又买了一台 3DS 重温任天堂平台上的旧作。

这些是今年新玩的游戏，大致按照喜爱程度排序：

塞尔达传说：王国之泪

平台：Switch
时长：150h

成功超过已经是神的前作，在我心目中是我玩过游戏里面的 No.1。究极手、通天术和时间回溯使得与世界的交互在旷野之息基础上更加富有想象力，剧情的情感共鸣更是系列最佳。最终战我是一边颤抖一边哭着打完的，有段时间的一大乐趣是看各路主播在通关时泪奔的场景。

博德之门 3

平台：PC
时长：100h (未通关)

非常好玩，不仅是因为自由度极高的玩法，极度充实的内容和精细打磨的剧情更是让人惊叹，无愧于年度游戏。玩的时候想得最多的是：这么复杂、这么细致的游戏怎么可能做得出来？

幽灵诡计

平台：3DS (NDS)
时长：约 12h

玩法和剧情完美统一的神作，游戏节奏非常好，美术设计无可挑剔。剧情几度转折，最后一刻的反转让人潸然泪下。

塞尔达传说：众神的三角力量 2

平台：3DS
时长：约 20h

玩的第一部 2D 塞尔达，能够进入墙壁的设计使得解谜设计多了一个维度，非常惊艳。难度还行，就是最后打盖侬的时候手快打断了。

超级马力欧兄弟：惊奇

平台：Switch
时长：5h (未通关)

用任亏券换的游戏，和之前的马力欧相比耳目一新，但在开始玩博德之门之后就搁置了。

皮克敏 4

平台：Switch
时长：约 10h (未通关)

皮克敏 3 我玩了一会就没完了，这次皮克敏 4 画面玩法升级了之后更能玩下去了。游戏本身很有意思，但游戏重复的游玩要素不少，我也实在是没有耐心全收集，没有通关。

Hi-Fi Rush

平台：Xbox
时长：5h (未通关)

音游玩法的动作游戏，很惊艳。

极限竞速：地平线 5

平台：Xbox
时长：56h

最好的赛车游戏，手柄震动的体验非常让人沉浸。开放世界赛车游戏的概念挺有意思，不过世界并没有和赛车比赛真正做到融合。通关之后没有什么动力继续折腾改装之类的东西，就没再玩了。

逆转裁判 3

平台：3DS
时长：约 10h (未通关)

在 3DS 上体验双屏的逆转裁判，但玩着确实是太累了，过了一个案件后就搁置了。

High On Life

平台：Xbox
时长：11h

噱头是枪会说话，游戏其实一般，没有什么新意。

关于音乐

今年还是没有听什么新歌。随着我年龄增大，我喜欢的歌手/乐队都在老去，越来越难听到他们的新歌了。

总结的总结

今年第一次出了国。“到国外去见识不一样的世界”，意味着有机会去见识和之前的经历完全不同的东西，去体验其他文化，理解其他社会的运行逻辑，观察其他国家的运行方式，和具有不同文化背景的人打交道。这往往会带来新的世界观、人生观。

比如，在了解了新加坡的建国历史之后，在对新加坡的国家治理感到赞叹的同时，我反而更对治理中国这样一个幅员辽阔的国家的巨大难度和所面临的挑战有了新的认识。又比如，在和一个新加坡出生的华人大爷聊到中国的发展时，他对“中国永远不可能在科技上超过美国”的坚持让我重新思考，我究竟要在国家发展的过程中扮演什么角色？

在新加坡的这段经历的另一个意义是，在某种程度上第一次离开了清华、特别是贵系的环境，去拥有一种不一样的心态和眼光来审视自己的未来。来这里半年，我已经忘记了之前对于与同辈对比之下的焦虑和被迫内卷的迷茫，也意识到人生远远不止一条“正确”的路。

2024 年，我想去更多的地方看看，去体验不一样的生活，去更加深刻地理解这个世界。

今年 12 月交完申请之后，申请的结果其实就已经决定了。明年的现在，我会在哪里写 2024 年的年终总结呢？

2023 F1 新加坡大奖赛体验

liang2kl@outlook.com (Liang Yesheng) — Tue, 19 Sep 2023 22:34:57 +0800

看完 Netflix 的 Strive to Survive 之后就开始看 F1 比赛了，正好今年新加坡站的比赛在我的暑研时间段内，就决定去现场体验一次比赛。

最开始只买了周日的 Premier Walkabout 票，价格是 418 新币。这张票能够在全场自由走动，好处是便宜（除了只能在 Zone 4 活动的 Walkabout 票之外最便宜的），但缺点是是不能上看台，也就意味着没有固定的座位。这带来了一些不好的体验，下面会详细展开。Anyway，买到票之后就确定可以去现场看了，然后就开始关注相关的活动。

周四：Pit Lane Experience

逛大奖赛官网的时候看到有一个 Pit Lane Experience 的活动，只针对新加坡居民和长期签证的持有者，抽中的人可以免费在周四晚上到维修区和赛道上参观。我参加了抽奖，但没有中。开奖的当天不太甘心，google 了一下发现新加坡最常用的二手交易网站 Carosell 上有很多人在卖票（这其实违反了不能转让或出售门票的规定，但是其实最后并没有任何的检查），就着手买一张票。

Carosell 和闲鱼不一样，是类似于 ebay 的竞价平台，也就是说上面要买到票不只是看卖家想要卖多少钱，还要看其他人愿意出多少钱。一开始的价格还算合理，卖家标的价格大概 S$50 一张，但随着大量买家的竞价，最高的时候炒到了 S$200 一张。这价格就是明抢了，我就没有再尝试买票。之后在小红书上面看到有人抽到票后想找人一起去（抽到的人有 2 张票），就尝试私信找个愿意带我去的人，但是最后都没有回复。

在活动的前一天，Carousell 上面之前联系过的一个卖家突然发消息说可以以 S$85 的价格卖给我，虽然仍然偏高，但是想着机会难得，就买下来了。

当天提前一个小时到现场排队，人已经非常多了。进场之后被告知不能直接进入维修区，继续排队等了一个半小时之后才终于允许进入（这是我唯一一个对新加坡站组织不满意的地方）。放开入场之后前面的人都冲着进场，以期待在人少的时候能够遇到一些车手/占据靠近赛车的位置。

我是最前面冲进去的，到维修区的时候基本上没什么人。快速地走过十家车队的 P 房，看到了阿隆索和汉密尔顿在房间里面。我当时觉得他们应该不会出来和车迷互动，拍了几张照就继续往前走了。尽头是红牛的 P 房，维斯塔潘和佩雷斯都不在，但是正好车队在练习换胎。他们练习的方式是：几个人推着赛车往前，模拟比赛时赛车的行进，到了换胎区之后就是正常的换胎过程。换胎的动静比想象中大得多，把我吓了一跳。

红牛换胎练习

看完换胎后近距离观察了下各家 Pit Wall 的设备，因为不能靠太近，拍了几张照就走了。之后翻到威廉姆斯设备的照片的时候发现了一个有意思的地方：他们有专门的监听阿罗和哈斯无线电的频道：

威廉姆斯偷听阿罗和哈斯的无线电

走了一个来回，突然听到阿罗的 P 房传来一阵尖叫，一看是周冠宇出来了，马上从书包里拿出纸和笔冲过去。因为我距离近而且阿罗人气确实比不上大车队，我挤了一下就挤到了最前面。我挤到前面去的时候小周已经走到另一边了，本来已经对拿到签名不抱期望，但是他到另一侧签完名之后又往这边走过来了。我一边喊着“冠宇，冠宇”，一边~~利用手长的优势~~递出了笔，他看到之后就拿起笔签了名。我当时还算镇定，跟他说了声“恭喜”，因为他刚在几个小时之前成功续约。他非常亲和，认真地回了句“谢谢”，之后走开了。这时候我满脑子都是“钱没白花！”。旁边有一花钱买票的哥们在成功合照之后喊着“It’s not S$50, it’s worth S$5000!”，我听到之后跟着笑了起来。

周冠宇的签名

之后汉密尔顿和勒克莱尔陆续出来签名，因为围在周围的人非常多，而且我有小周签名已经非常满足了，就只是去附近凑了下热闹。

之后来回逛了几圈，因为人实在是太多了，就出到赛道外面了。这时遇到威廉姆斯的人正在把赛车推到指定地点给 FiA 检查，我就跟着他们走了一段路，近距离地观察了赛车，还跟他们说了声“Good luck”。

威廉姆斯赛车

因为实在是热得慌，并且已经很累了，就走了出去，在一号弯坐了下来。一号弯非常漂亮，地上是大面积的新航蓝黄白配色的油漆，天上高架桥横穿而过，配上金黄色的打光，非常特别。

一号弯

周六：三练，演唱会 & 排位赛

周五的练习赛我是在家看的直播。到周六的时候憋不住，就坐地铁到了赛道附近，一方面是想找一下有没有好的免费观赛点，一方面是想在最后时刻淘到一些低价票。

怀着一丝幻想，我走到了横跨一号弯附近赛道的 Benjamin Sheares Bridge，但人行道果不其然被封上了。走这一趟倒不是完全没有收获，在这附近刚好可以看到里面车手的 Meet and Greet 环节的大屏幕，就停下来听了几分钟。

之后我在闲鱼上刷到了一个 600 多块的 zone 4 walkabout 票（原价大约 1100 块），价格非常好，想着既然都来现场了，稍微砍了砍价就买下，接着就进场了。我的第一次 F1 体验就这样提前了一天。

Zone 4 票的好处是非常便宜，但是缺点是没有太多很好的观赛点。想起之前在 Reddit 上看到的 7 号弯是高速直道后的弯道，比较好看，就到了这儿的平台。Walkabout 票是没有座位的，只能和其他人挤在一些观赛平台上看比赛。观赛平台很小，而且只有很矮的几层，在练习赛开始前就挤满了人，我们只能站着，又热又累。旁边的看台上只坐了大概一半的人，但我们不能上去，只能羡慕地干看着。

7 号弯的观赛平台

练习赛开始之后发现这个位置其实很不理想。一方面只能看到弯道的很小一部分，另一方面没有屏幕，无从得知赛道其他地方的情况。不过，第一次看到 F1 赛车在赛道上飞驰是很震撼的：震耳欲聋的引擎声，轮胎融化的橡胶味，以及观众们的欢呼声，都是现场独一无二的体验。

练习赛

一个小时的练习赛结束，我决定换个地方看晚上的排位赛。经过 Padang Stage 的时候 Kings of Leon 的演唱会刚好开始，想着应该不需要这么早去赛道占位置，就进去了。在现场演唱会的音浪、震动和攒动的人头下，我们即使不会跟着唱，没听过，甚至不一定欣赏得来那些歌曲，却都在缓缓降临的夜幕下五光十色的舞台融为一体，不约而同地尽情摇摆。新加坡站的特点是大牌云集的演唱会，它们将比赛推向了一个更加令人沉浸和放松的高潮。

夜幕下的 Kings of Leon 演唱会

排位赛我选的位置是 12 号弯附近、进入 Anderson Bridge 前的平台。这里可以看到 11 和 12 两个弯，并且正对一个大屏幕，可以很清晰地看到排位赛的情况。车手在 11 号弯刹车，加速通过 12 号弯并一路穿过 Anderson Bridge，观赏性十足。

12 号弯的观赛平台

现场的车迷组成很有意思，大部分是法拉利和梅奔的车迷，红牛的车迷不少但是明显少于另两强。红牛的垄断地位让他们自然成为了公敌，当红牛在 Q2 中双车被淘汰时，现场爆发了比赛期间最响亮的掌声。此外，斯托尔撞车、角田短暂排第一和赛恩斯夺杆时现场也是一片热闹。虽然在现场对比赛进程的认知不如看直播，但是伴随着赛车驶过声浪的热烈气氛是只有在现场才能享受的体验。

排位赛结束后有 Post Malone 的演唱会，我没什么兴趣，把票挂在 Carosell 上面，很快就以 S$50 卖出去了，这样一来这张票（等于花了 300 多块钱）拥有了无敌的性价比。

周日：正赛

周日的门票是 premier walkabout，可以在所有区域内活动。由于之前新加坡站一号弯附近出现过很多事故，因此就选择了靠近维修区出口和一号弯的平台。这个平台能看到主直道末端、维修区出口、一号弯以及二和三号弯的部分。这个位置不仅视野好，而且头顶就是立交桥，下午的大部分时间在桥的阴影下，同时正对面就有一块大屏幕。

1 号弯附近的观赛平台

有了前一天的经验，我在入场的最早时间之后大概 15 分钟就到了现场。距离比赛还有五个多小时，但是平台已经几乎快被占满了。看来不只是中国人在卷 :)

到比赛快开始的时候发生了一些冲突。一些后到的观众钻到了前后两排的空间里面，这样一来在那里占了一下午座的观众不乐意了，吵着让他们走开。双方争执了很久，期间有人一直在礼貌地劝双方冷静，最后没有变成太大的冲突，以后来者的离开而结束。这就是 walkabout 票最大的缺点：没有固定的座位，比较好的观赛位置必须早早去占座，导致无法在比赛前去享受各种各样的活动。

比赛开始之前我跟左边的一群统一着装的红牛车迷聊了起来。他们是维斯塔潘的老乡，跟着他参加了很多场大奖赛。跟其中一个车迷聊到红牛前一天不太顺利的排位赛，他脸色一下子就沉了下去。我赶紧打趣说根据传统没准今晚两辆法拉利撞一起 Max 就能拿冠军了，我们一起哈哈大笑起来。

正赛之前赛道上有两场低级别的车赛和车手巡游来消磨时间，五个小时很快就过去了。之后就是本赛季最精彩的一场比赛了：角田退赛、萨金特撞车安全车出动、维斯塔潘连续被超车、维斯塔潘连续超车回去、阿隆索超长的 20 多秒换胎、史诗般的前四名追逐战、拉塞尔最后时刻的撞车。赛恩斯冲线、烟花升起的一刻，所有人无论是否支持法拉利都在为他的完美表现欢呼鼓掌，沉浸在夜色下完美的氛围中回味着比赛，久久没回过神来。

Carlos Sainz P1!

离场的时候，我追上之前聊天的红牛老哥，说“Welcome to China next year!”他虽然略有失望，但还是开心地说“Sure!”。我无比期待明年的中国大奖赛，再一次与这些素不相识但志同道合的朋友们一起享受 F1 给我们带来的兴奋、刺激与感动。

记一次溜入 F1 新加坡大奖赛封闭区域的经历

liang2kl@outlook.com (Liang Yesheng) — Sat, 09 Sep 2023 19:36:40 +0800

起因

自从一个月前通过网飞的纪录片入坑 F1 之后，亲身体验 F1 就加入了我的“不做就会遗憾终身”的列表中（列表的上一个是去 Coldplay 的演唱会，这个愿望如不出意外将在明年离开新加坡前达成）。正好新加坡站的比赛在 9 月进行，于是就买了张周日的门票。我总是觉得只在观众区看比赛不够特别，当看到官方组织的在比赛日前参观维修区通道（pit lane）的活动之后就兴致勃勃地参与了抽奖。

可惜最后没有中奖。不甘心的我打算去现场转转，而我本来也打算这周末去现场考察一下下周比赛的观赛位置，于是在开了一个实验在后台跑之后就出发去现场了。

封闭的赛道

一出地铁站（Promenade 站）就感受到了大奖赛临近的氛围。新加坡站是街道赛，很大一部分赛道是平时的街道，因此这一些街道有明显的特点：道路两侧有非常高的防护栏，防护栏上每隔几米就有一张反光带。随着比赛日的临近，街道附近也开始搭建一些临时设施，如看台、灯光和遮挡没买票的人视线的围栏。

用作赛道的街道，已经搭好了看台，防护栏倒是永久设施

虽然这些街道不可能提前一个星期就封起来，但是赛道的核心部分——主直道、维修区和围场（Paddock）是早早（8月底）就用围栏封闭、不对外开放的。我一开始想尝试进入，但是看到门口有保安看守，且没有发现明显的漏洞后，就作罢了。进入无果后我就只能去最近的新加坡摩天轮考察一下我打算去的观赛点附近的情况了。那里的角度倒是挺好，赛道看得很清楚，而且还有一段看台可以上去。

Paddock 入口，有若干个保安看着

摩天轮附近的看台

溜入封闭区域

只是看一眼赛道当然算不上什么收获，趁着时间还早，我沿着围栏，想碰碰运去看能不能进去。一路上遇到了两个有保安的门口，我抱着试一试的心态问保安能不能进去，在知道我不是里面的 staff 之后都很礼貌地拒绝了我。我也不好意思进一步试探，两次都乖乖地离开了。

两个入口，下面的是三号弯的出口

一路走到 Nicoll Highway 地铁站，我本来已经有点疲惫，要进站回去了，但是还是不甘心，又往回走再找一找有没有机会。

在走到上面图片靠上的圆圈的入口，我终于发现了破绽。这个入口的右边是一条机动车的地下通道，没有人看着，与入口之间由路障隔着，而沿着通道走几步有一些路障之间有空隙，我趁着保安不注意（他们应该根本没有注意这个地方），一侧身就进去了。我撑着伞走了一段路，心脏狂跳，又不敢回头看，好在没有人发现异常。就这样，我成功进入了封闭的区域。

溜进去的路径

赛道、维修区与围场

封闭区域里面的所有人都挂着证件，我心惊胆战地跟着前面的人走。后来发现其实根本没有人管证件的事儿，我胆子就大了起来。

我进去之后的地方是维修区对面的看台，而我最想去的地方是维修区和它后面的围场。我在防护栏外绕着赛道走了一会儿（这也是比赛时观众活动的区域），走到了和外界的隔离处也没找到进入维修区的合法路径，只好回头。

防护栏外

回去的路上发现最后一个弯道的防护栏是开着的（应该是为了让吊车进入赛道），四处张望发现附近人不多之后，我迅速地穿过赛道，终于来到了维修区。

走入赛道

维修区摆满了集装箱，里面是各种配件、器材（赛车本身应该还没运来），不过现场车队的人员还没来，只有本地的工作人员在进行装修。维修区后面是围场，现在已经布置好了鲜花，不过建筑里面还没有东西。

在里面走一圈，想象着在这些地方发生过的那么多戏剧性的事件，还是很有感觉的。

维修区

围场

本来还想到一号弯附近看一下，不过那里在施工的人比较多，最后没有过去。没有什么其他的地方可以看了，就走到围场的出口，疲惫但是满意地离开了。

下周比赛见！

2022 年的一些记忆

liang2kl@outlook.com (Liang Yesheng) — Fri, 30 Dec 2022 22:38:09 +0800

2022 年对于我来说波澜不惊，似乎不值得像去年一样写一篇“年终总结”，那就用流水账的形式把这普通但又不平凡的一年作一个小小的总结。

编程

编程时间从去年 12 月开始用 wakatime 记录，到现在正好一年。

今年仍然是“码力全开”的一年，但更多是完成课内繁杂且繁重的大作业以及做一个目前为止半死不活的科研，并不像去年（和更早之前）那样大部分时间用在自己感兴趣的一些杂七杂八的大小玩意上。主要投入的有：

春季学期
- 软件工程：一个动态配置管理系统
- 人工智能导论：输入法、四子棋、情感分类
- 搜索引擎技术基础：一个简陋的图片搜索引擎
秋季学期
- 计算机组成原理：Risc-V 五级流水 CPU，支持 uCore 操作系统
- 编译原理：一个简单的编译器
- 数据库系统概论：一个支持基本 SQL 的 DBMS

年度最佳瞬间：验收前 1 小时把 bug 完全修好，uCore 跑出来了

虽然这些大作业大部分都是“标准动作”，并没有很多自由发挥的空间，但在其中的收获感觉非常多，比如：

写了/看了几百个小时 C++，对 C++ 的理解深入了很多
在软件工程/科研中学到了不少工程上的规范，并在写数据库的时候实践了一番
造机补全了对硬件的理解空白，以前遇到的很多关于底层的困惑豁然开朗

我觉得，这些课程最重要的作用是对我代码能力的进一步提高。之前自己瞎搞的很多程序，包括 Whiz 和树洞 app，要么没有工程上的规范，要么对计算机系统不够理解而导致写出很多性能上完全不靠谱的代码。在这学期写数据库的过程中，明显感受到开发过程更加严谨规范，性能上也更有把握。

虽然话是这么说，但是这些大作业没有一个是好啃的骨头。客观上说，某些课程一言难尽的文档是造成这一结果的重要原因，但在写这些东西的过程中，在偶尔获得成就感的同时，的确不时感受到一种无力感，内心的想法在这几个状态间不断转移：自己怎么什么都不懂，我真菜/为什么大佬们都能自己搞懂，我真菜/啊我自己搞明白了，我真牛X/啊我实现出来了，我好牛X……现在看来，自己水平还是有的，但也的确和同辈的最高水平有着相当的差距（当然，这是每个清华学生最终都要学会承认的 :)

学习与科研

学习上，一句话：想象不到自己能这么摆。不说了，总之就是一塌糊涂，课没怎么去上，但好像该理解的基本上都理解了……

没准这就是大学学习呢……

《清华大学同学在睡觉》PS：冯老师讲课不差，就是周一早八实在是阴间

另外，由于自己时间管理实在是太烂，科研已经拖了两个月没有动了，也的确不知道该如何继续下去，等考完试再慢慢捋一捋吧……

游戏

自从今年暑假上写沟进行了关于游戏主题的研究之后，之前一直以不打游戏的好学生自居的我突然走上了玩游戏的不归路。本来不怎么玩游戏要归功于我的国行 Switch 买不到什么游戏 + 主力机是 Mac，但自从暑假买了台日版的 Switch Lite（之后又淘了一台二手的普通版 Switch）之后，一切都变了。~~是时候给年度总结加上游戏了。~~

今年主要玩的游戏有：

Splatoon 3：之前很早就被它吸引，“通过墨水占地的射击游戏”这一概念对于习惯于传统射击游戏的玩家来说非常新颖，实际上手之后更觉得惊艳。占据了我绝大部分空闲时间的罪魁祸首。
Baba is You：一款颠覆游戏玩法的神作：通过改变游戏的规则，而不是在规则的约束下达成目标，非常考验思维，很难，现在大概通关了 70%。
Super Mario Maker 2（马力欧制造2）：由于看桀哥直播的缘故，对 2D 马力欧产生了兴趣（之前只玩过 3D 的奥德赛）。可以玩一辈子的马里奥。
逆转裁判：买的二手 Switch 上还保留着的数字版游戏，玩了几十个小时，案件推理十分精彩。之前对这种文字类游戏不太感冒，没想到这么好玩。可惜太花时间，只玩了一半左右。
塞尔达传说：旷野之息：有了日版 Switch 之后把之前没能玩的 DLC 补了一下。

Splatoon 3

100 年前的合照（泪目）

音乐

9 月的时候换了个 Apple Music 账户，所以只有几个月的数据：

今年常听的基本上都是老歌，相比于之前听粤语歌多了不少。之前总觉得粤语歌语调比较低沉，但现在越来越觉得有味道，可能是相比英文歌，还是母语的歌更贴近我的内心吧。另外，还听了很多 Sondheim 的音乐剧。

换了美区的账户之后可以听一些被禁的歌曲了，包括之前很喜欢的、但由于支持港独被大陆封禁的 RubberBand，当时去香港露营现场听过他们的表演。我一直觉得在艺术本身不被用于政治用途的情况下，艺术不应与政治相关，它承载了人的不可封杀的记忆、情感。

一些值得留念的瞬间

6 月 15 日，学校解封后宿舍一起吃的第一次夜宵

小七孔，疫情下看到这样单纯的场景竟有些恍惚

镇远古镇

梵净山

造机（在床上）开始！

圆明园“金秋游”——这竟然是我第一次去圆明园

第一次封楼，分发的晚餐

凌晨五点半的 C 楼：疫情严重，被迫回家，又一个不完整的学期

当我们到达登机口的时候，刚好赶上日出——也许今天，一切都会好起来吧？

在飞机上成为密接，从集中隔离点望向阳江一中

一个人困在家，被迫尝试自己煮饭——还不赖

最后一个瞬间，留给梅西。我错过了他的巅峰，又见证了他的所有至暗时刻。如童话般的结局，是对他绝代无双的球技和人品一份迟到的礼物，我的青春也终于没有了遗憾。

中国主流媒体视角与游戏产业发展的割裂——以《人民日报》游戏相关报道（1989-2021）为例

liang2kl@outlook.com (Liang Yesheng) — Thu, 28 Jul 2022 23:42:15 +0800

本文为 2022 年夏季学期程祥钰老师《写作与沟通》课程游戏主题长文终稿

摘要主流媒体几乎参与了中国游戏产业发展的全过程，但其报道相较于游戏产业的发展而言存在着缺失和偏差，存在着明显的割裂。纵观中国游戏产业发展史，这种割裂长期存在，总体上在缓慢弥合，但最近又有重新加大的趋势。由于主流媒体宣传官方主张、传播主流声音的性质，其与游戏产业的发展存在着产生割裂的必然性，而游戏相关政策与主流舆论对割裂的产生具有重要作用。二者之间割裂的影响具有两面性，游戏产业的健康发展需要主流媒体保持适当的距离。

关键词 游戏；游戏产业；主流媒体；游戏报道；人民日报

主流媒体对游戏¹的报道自其进入中国以来就一直存在。《人民日报》对游戏的间接报道最早可追溯到 1981 年²；此后，随着中国游戏产业的不断发展，《人民日报》对游戏的直接报道数量基本呈递增趋势，目前游戏已成为其热门话题之一。可见，主流媒体几乎参与了中国游戏产业发展的全过程。

然而，尽管主流媒体似乎并未缺席中国游戏行业的发展历史，且主流媒体的视角与中国游戏产业的发展大体上步调一致，但其在某些历史阶段的报道忽略了游戏产业发展的重要历程，且立场存在明显的偏向性；主流媒体的视角与游戏产业的发展之间存在着缺失和偏差。例如，对于 20 世纪 80 年代末到 21 世纪初之间的历史时期，在游戏产业发展史的叙事中，“20 世纪 90 年代新出现的游戏杂志群开始频繁讨论游戏中的文化议题，其核心主张便是如何生产作为文化抵抗媒介的国产游戏。”，自此产生了第一批国产游戏³；而在《人民日报》的叙事中，没有一篇文章提及此历史进程，反之在重复讨论“电子游戏热中的负效应”⁴、“电子游戏的暴力内容对孩子不利”⁵、“青少年沉迷电子游戏现象”⁶等游戏的负面形象。主流媒体的视角并不总是与游戏产业的发展相统一，二者之间存在明显的割裂。

对于媒体报道对游戏的舆论评价所产生的影响，何威等在研究《人民日报》游戏报道的话语变迁时指出，“不论普罗大众、文化精英或政府官员，多少都依赖媒体报道提供素材、主题、框架、观点，来理解和对待游戏及游戏玩家”⁷。具体到主流媒体，汉娜·沃曼在研究西方媒体对中国游戏文化和商业的报道时指出，“官方媒体成为了一种精英象征，代表社会上‘最有发言权’的群体，也因此可以优先影响‘大众的思想’”⁸。正因为《人民日报》等主流媒体反映了官方的态度，且有着巨大的舆论影响力，主流媒体的视角与游戏产业发展之间的割裂，以及这种割裂对中国游戏产业带来的深刻影响，值得关注和反思。

本文将以《人民日报》以游戏为主题的文章⁹为例，从中国主流媒体游戏报道话语演变及游戏产业发展的历史入手，揭示二者之间的割裂性，分析这种关系背后的影响因素，进而探讨这种关系对中国游戏产业的影响。

中国游戏产业发展的过程中，主流媒体的视角看向何处

中国游戏产业发展的历史可以清晰地划分为若干个阶段，每个发展阶段既有标志性的事件作为开端，又有明确的主题贯穿其中。《人民日报》的视角是否能够覆盖中国游戏发展的重大事件，其报道是否能够呈现当时游戏产业发展阶段的现状？我们以中国游戏发展的标志性事件为点、以发展阶段中的主要趋势为线，对《人民日报》游戏报道的视角进行分析。

1981 年北京第一轻工业研究研制出 YQ-1 型游戏机，标志着当代中国游戏史的开端。虽然同年《人民日报》第一次在报道中提到了电子游戏，但距离《人民日报》第一篇以游戏为主题的文章发表还有 8 年时间。在这段时间里，中国游戏产业尚未开始全面发展；电子游戏以学习机的面目出现，其游戏的本质被压抑，与大众尚有一定距离，游戏并未产生足够的社会影响。因此，游戏产业并不足以得到主流媒体的关注，这导致了主流媒体叙事中这段历史中的缺失。

1980 年代末，中国东南沿海逐渐具备规模化的任天堂兼容机生产能力，电子游戏开始成为社会现象¹⁰，自然也逐渐被主流媒体所关注。《人民日报》对游戏的第一篇直接报道（1989 年）便出现在此时期：这篇报道聚焦上海大量游戏机涌现而导致学生沉迷的问题，呼吁有关部门加强管理¹¹，可见此时电子游戏已具有相当的社会影响。值得注意的是，此后 10 年《人民日报》对于游戏的 15 篇报道均停留在其消极的社会影响上，并未关注电子游戏本身或其背后产业的发展，直到1999 年才出现第一篇介绍电子游戏的文章¹²。可见，此时期《人民日报》的游戏报道虽然逐渐增多，但其视角极其局限。这一结论在同一发展阶段的另一个标志性事件及其带来的发展趋势中可以得到印证：1994 年 10 月，金盘公司游戏部发表首款国产游戏《神鹰突击队》；一年后，《电子游戏软件》一篇题为《乌鸦·乌鸦·叫：该谈大陆电子游戏业了》的文章¹³批评了电子游戏中中国文化元素的缺失，引发了游戏界的广泛讨论，从此直到 21 世纪初，游戏国产化成为了中国游戏产业发展的主旋律；然而，如前文所述，这一阶段《人民日报》的视角仍局限在电子游戏产生的影响上，对游戏产业这一关键发展历程完全没有涉及。在强调电子游戏的危害的同时忽视游戏本身及游戏行业的发展现状，主流媒体的报道几乎与游戏产业的发展完全割裂。

2000 年 7 月到 9 月，全国开展电子游戏经营场所的专项治理，出台了持续 14 年之久的“游戏机禁令”¹⁴，从此中国失去游戏软件产业升级的硬件基础，转向代理海外网游的新模式，从此进入长达十几年的网游时代¹⁵。与之前的缺位不同，《人民日报》在此次转变中不仅在场，还起到了十分重要的推动作用：从 2003 年 3 月 3 日开始，《人民日报》以前所未有的频率关注游戏，在专项治理开始前的 3 个月连续刊发 8 篇关于游戏厅现状及其危害的文章，从时间上看这些报道导致了政策的制定和实行；随后的 4 个月中，《人民日报》又刊发了 4 篇文章介绍专项治理的效果；这一年，《人民日报》的全部 13 篇游戏报道均与专项治理相关。值得关注的是，虽然主流媒体的报道仍然局限在游戏的负面影响上，其在游戏产业的此次转折中扮演了一个完全不同的角色，在以往的旁观者、批判者之外，短暂地成为了游戏产业发展的推动者，尽管游戏产业本身在其报道中并未在场。

2001 年开始，中国游戏厂商开始代理国外网络游戏，开启了中国的网游时代。《人民日报》在 2002 年和 2003 年分别对网易推出的国产新网游《大话西游》¹⁶和金山推出的新网游《剑侠情缘网络版》¹⁷进行的报道，是其最早对具体游戏的主题报道；2003 年，《人民日报》发表了一篇解读网络游戏的文章，详细介绍了网友相关的政策和产业发展情况，并强调辩证地看待游戏的影响¹⁸。虽然这只是这个时代开端的几篇报道，但却反映了这个阶段主流媒体与游戏产业关系的明显变化：主流媒体终于主动向游戏产业靠近，游戏产业开始作为主体在主流媒体的报道中出现；主流媒体与游戏产业的对立开始得到缓解，其对游戏产业发展报道的缺失逐渐得到弥补。尽管如此，2009 年之前的主流媒体报道仍然带有对游戏的严重偏见。例如，“网瘾治疗专家”杨永信作为“靠着一颗爱心，挽救深陷泥潭的学子”的“好人”出现在人民日报的报道中¹⁹，尽管此人在当时饱受争议。主流媒体报道立场偏向性严重的问题导致其对游戏产业的报道不够全面客观，主流媒体与游戏产业发展之间的割裂继续存在。

2009 年后，随着“转变经济发展方式”、“科技强国”、“中国文化走出去”等主流叙事的流行，游戏的科技与文化属性成为这一时期《人民日报》报道游戏的主要主题：2009 至 2011 年，“产业经济”框架在游戏报道中占据绝对主流；而 2012 年到 2017 年，“文娱新方式”框架占比陡增，维持在26%至36%之间波动²⁰。可以看到，《人民日报》在这个时期从以往的游戏产业的旁观者变成了参与者，利用自身的舆论影响力服务于国家发展需要塑造舆论话语，有意识地引导游戏产业与国家发展战略接轨。为了达到此目标，《人民日报》对电子游戏危害的讨论相比以往几乎销声匿迹，报道角度也更加多元。以上种种变化，在客观上促进了主流媒体与游戏产业之间的交流，主流舆论与游戏产业之间更加平衡，同时一定程度上缓解了由于立场偏向而导致的割裂。

2017 年，《王者荣耀》风靡全国，带来了新的一轮网络手游热，由此沉寂已久的游戏成瘾话题又重新成为主流议题；相比之下科技创新、文化输出等报道框架虽仍然存在，但明显有所减少。2018 年世卫组织首次将游戏成瘾列为疾病²¹后，《人民日报》在游戏成瘾以外的报道框架进一步被压缩，直到 2021 年仍是如此。主流媒体与游戏产业之间的关系在当下又重新变得紧张，二者之间的割裂有重新加大的趋势。

什么造成了主流媒体与游戏产业发展的割裂

如前文所述，主流媒体与游戏产业发展之间的关系在40多年的中国游戏史中经历了明显的起伏。主流媒体与游戏产业发展之间的割裂，一方面表现在主流媒体对游戏的报道中游戏产业作为主体的缺失，另一方面表现在主流媒体报道话语的偏向性；这种割裂长期存在，总体上在缓慢地弥合，但有重新加大的趋势。这种关系变化的背后，有什么因素对二者之间的割裂产生影响？

首先需要指出的是，以《人民日报》为首的官方媒体的报道角度与游戏产业的发展之间存在产生割裂的必然性，所有对主流媒体与游戏产业关系的影响因素的讨论都必须基于这一前提。《人民日报》是党中央的机关报，其作用是“上连党心，下接民心”²²；《人民日报》并不是为游戏产业服务的，其目的是宣传国家中央主张、传播社会的主流声音，这就导致一旦游戏产业的发展与中央政策导向或主流舆论发生冲突，《人民日报》必然会在一定程度上站在游戏产业的对立面，其报道与游戏产业自身的发展历程必然会产生割裂，这与持小众、个人观点的游戏媒体有着本质的不同。

在这一前提下，通过前文对游戏发展过程的归纳，不难发现游戏相关政策对二者关系的重要影响。一个鲜明的例子是《人民日报》对游戏产业在上世纪 90 年代以及 2012 至 2017 年这两段发展历史截然不同的态度：这两段时期中，游戏产业都致力于将中国文化意象融合到游戏中，然而《人民日报》在前一段时期中完全忽视了游戏产业发展进程，将游戏妖魔化，而在后一段时期中却积极地推动着此进程的发展，游戏的负面报道几乎不再存在。难道 90 年代中国游戏产业的探索没有意义，而 2012 年以后游戏的负面影响就完全消失了吗？显然不是。政策的因素在其中起到了至关重要的作用：第一部与促进国产游戏发展的政策“民族网络游戏出版工程”在 2004 年的网游时代才面世，90 年代主流媒体的报道更多基于社会主流舆论产生；而在 2010 年，“讲好中国故事”、“中国文化走出去”已成为中国文化工作的主流导向²³，同时文化部指导网游厂商发起“家长监护工程”，意在引导未成年人“玩健康的游戏”和“健康地玩游戏”，游戏产业的发展得到了国家战略与政策的支持。尽管此时网游成瘾问题依然严重，对游戏的主流舆论评价仍然呈负面，但显然政策导向对主流媒体话语塑造具有更大的影响力。

另外，由于主流媒体传播的是社会的主流声音，其对游戏产业的报道受社会主流舆论影响较大。这种影响不仅如前文所述体现在报道内容和价值取向上，更隐含在由不同群体舆论话语权的不同而导致的主流媒体报道立场偏向性中。根据何威等的研究，在其所统计的《人民日报》历年对游戏负面报道中，引用专家学者观点的有 49 篇，引用管理部门观点的有 40 篇，而引用玩家的观点仅有 11 篇²⁴。可以看到，在“游戏的负面影响”这一主题下，与游戏产业直接相关的主体的话语权是缺失的，无论是游戏从业人员还是游戏玩家；他们不满与自身话语无法得到关注，却又对此无能为力。游戏杂志《家用电脑与游戏机》在 2000 年 7 月刊登了一篇反驳《光明日报》将游戏称作“电子海洛因”的文章，作者在其中愤怒地抱怨道：

为什么作者宁愿“暗访”地下游戏室三次，却不愿意去一趟正大光明的游戏公司或游戏媒体，甚至多走访一些真正热爱电脑游戏的普通人呢？看来是“非不能也，实不愿也”，既然早就定下了“电子游戏是瞄准孩子的‘电子海洛因’”的标题（或者说是结论），一切就要围绕这个中心服务，如此而已。²⁵

这篇文章是主流媒体与游戏产业之间冲突的直接表达，虽然已有 20 多年的历史，但即使是现在，由舆论话语权不平等导致的主流媒体与游戏产业发展之间割裂的问题也还没有得到较好的改善。这是因为，中国电子游戏在上世纪 90 年代刚刚兴起，而其影响力进一步扩大则是在十年后开始的网游时代。绝大部分出生于游戏流行年代的“游戏原住民”出生于 90 年代或 21 世纪，目前大多为 20 多岁的青少年，对主流舆论的影响力还远未成型，而他们恰恰是与游戏产业联系最为密切、最为庞大的群体，因此长期作为无法发声的、被批评的对象出现在游戏报道中；另一方面，40 多年来塑造主流舆论的群体大多作为旁观者的身份目睹游戏产业的发展，与游戏产业之间存在着天然的距离；即使对于部分人而言这种距离可能随着了解的不断深入而缩短，但大多数人由于主流媒体对游戏形象持续的污名化构建，其与游戏产业的距离只会越来越远，从而进一步加剧主流媒体与游戏产业发展之间的割裂。

总结：如何看待主流媒体与游戏产业发展的割裂

如前所述，主流媒体与游戏产业发展之间的割裂主要表现在主流媒体对游戏的报道中游戏产业作为主体的缺失，以及主流媒体报道话语的偏向性。随着历史进程的推进，主流媒体报道逐渐向游戏产业靠近，报道的价值取向取向也逐渐多元化，但是主流媒体与游戏产业发展之间的割裂是必然存在，而且将长期存在的：游戏易成瘾等特性导致大众舆论关于游戏社会影响的警惕，以及国家意志关于游戏对国家发展的影响的考虑一直存在，而这两者是影响主流媒体报道话语的最重要因素。尽管舆论对游戏的警惕可能会随着主流话语权的变更而放松，有关政策可能会因为游戏与国家发展向契合的属性而对游戏发展更加宽容，但它们背后的决定因素——游戏的消极影响是始终存在的。

与游戏媒体的报道与游戏产业发展较为同步的关系相比，主流媒体与游戏产业之间保持适当的距离在某些方面是有益的。主流媒体对游戏消极影响的关注催生了游戏防沉迷、实名制等机制的产生，在客观上对规范游戏产业的发展起到了一定的作用；同时，主流媒体对游戏产业发展的参与程度越来越高，利用自身舆论影响力引导游戏产业与国家战略接轨，在一定程度上促进了游戏产业的发展。但是，主流媒体对游戏的报道需要避免重新回到以预设立场完全否定游戏价值、无视游戏产业发展历程的状态，这对游戏产业发展，以及游戏与人之间的关系存在着不可忽视的消极影响。

游戏作为复杂的文化、社会现象，其影响必定是多元的。游戏产业的发展需要具有社会和舆论影响力的主流媒体起到化解不同群体之间冲突与矛盾、促进游戏产业与社会发展相统一的作用。保持一定的距离，批判地看待游戏，给出有建设性的意见，不失为达到这一目标的一种行之有效的方法。

如无特别说明，本文中“游戏”专指“电子游戏”，即一切“依靠电子媒体平台而运行的互动游戏”。 ↩︎
戚休：《广州东方宾馆利用外资更新客房效果显著》，1981年05月25日《人民日报》第2版。 ↩︎
邓剑：《中国电子游戏文化的源流与考辨》，《上海文化》2020年第12期，第45页。 ↩︎
刘建华：《电子游戏热中的负效应》，《人民日报》1990年4月4日第6版。 ↩︎
夷水寒：《电子游戏的暴力内容对孩子不利》，《人民日报》1991年2月12日第5版。 ↩︎
马永梅，吴光志，周开荣：《游戏岂能“犯规”——青少年沉迷电子游戏现象扫描》，《人民日报》1993年12月21日第10版。 ↩︎
何威，曹书乐:《从“电子海洛因”到“中国创造”: 〈人民日报〉游戏报道（1981-2017）的话语变迁》，《国际新闻界》第40期，2018年，第58页。 ↩︎
汉娜·沃曼：《西方新闻媒体的“中国-东方主义”：被漫画化的游戏文化和商业》，宋雅文译，见何威、刘梦霏编：《游戏研究读本》，上海：华东师范大学出版社，2020年，第220页。 ↩︎
使用“人民日报图文数据库”对“游戏、网游、网瘾、手游、电竞、电子竞技”进行标题检索，包括新闻、评论、读者来信等所有类别，并剔除无关文章，得到1989年至2021年刊登的共194篇相关文章。 ↩︎
邓剑：《中国当代游戏史的思想谱系：从本土现代化到资本与市场逻辑》，《探索与争鸣》2022年第2期，第166页。 ↩︎
朱丹：《学生入迷，家长忧心——上海街头游戏机成灾》，《人民日报》1989年4月17日第2版。 ↩︎
《电子游戏的分类》，《人民日报》1999年3月14日第7版。 ↩︎
本刊评论员：《乌鸦·乌鸦·叫:该谈大陆电子游戏业了》，《电子游戏软件》1995 年第 4 期。 ↩︎
国务院办公厅等：《国务院办公厅转发文化部等部门关于开展电子游戏经营场所专项治理意见的通知》，2000年6月15日，http://www.gov.cn/gongbao/content/2000/content_60240.htm，2022年7月21日。 ↩︎
邓剑：《中国当代游戏史的思想谱系：从本土现代化到资本与市场逻辑》，《探索与争鸣》2022年第2期，第169页。 ↩︎
周萍：《网易推出网络游戏〈大话西游〉》，《人民日报》2002年1月1日第5版。 ↩︎
崔扬：《国产游戏新出网络版》，《人民日报》2003年7月30日第11版。 ↩︎
任建民：《网络游戏：超越电影票房之后（热点解读）》，《人民日报》2003年12月15日第5版。 ↩︎
刘成友：《道德力量汇聚孔孟之乡——全国道德模范与身边好人现场交流活动侧记》，《人民日报》2009年4月4日第3版。 ↩︎
何威，曹书乐:《从“电子海洛因”到“中国创造”: 〈人民日报〉游戏报道（1981-2017）的话语变迁》，《国际新闻界》第40期，2018年，第71-72页。 ↩︎
世界卫生组织：《国际疾病分类》第11次修订本，https://www.who.int/zh/news-room/spotlight/international-classification-of-diseases。 ↩︎
汪晓东：《让党心和民心贴得更紧——写在习近平总书记“2·19”重要讲话发表3周年之际》，《人民日报》2019年2月19日第1版。 ↩︎
温红彦，李舫：《向世界讲述好中国故事——文化部副部长赵少华谈中华文化“走出去”》，2010年9月30日。 ↩︎
何威，曹书乐:《从“电子海洛因”到“中国创造”: 〈人民日报〉游戏报道（1981-2017）的话语变迁》，《国际新闻界》第40期，2018年，第77页。 ↩︎
王亚晖：《中国游戏风云》，北京：中国发展出版社，2018年11月，第113至114页。 ↩︎

2022 春季学期总结

liang2kl@outlook.com (Liang Yesheng) — Mon, 20 Jun 2022 16:26:00 +0800

春季学期对我来说有一个定律，或者说一个魔咒：学业一塌糊涂，学业之外收获甚多。

20 年的春季学期在家里上课，鬼使神差般地接触了 iOS 开发，从此一整个学期都在写一个 app，上课和下课都在写代码，导致那个学期的绩点异常整齐，除了体育之外全部都是 3.6，排名刷刷地往下掉，还退了微积分和概统。21 年春季学期进行转系，同时在高强度写树洞 app，没什么心思听课，最后离散 (2) 喜提 3.0，绩点进一步雪崩，并且又退了一次微积分（于是大学总共修了三次微积分 A2，唉！）。

但是，这两个学期对于我大学四年有着非常深远的影响。最重要的当然是开始写程序之后逐渐喜欢上了 CS，并直接导致最终转到计算机系；写树洞是第一次接触正经的 C/S 架构的开发，积累了大量的网络、git、前后端等等知识，这也使得我现在的技术能力放在贵系也还算可以（？）。

与之相反，秋季学期在经过前一个春季学期的“惨痛”经历后，往往走向另一个极端：抑制自己在其他地方的兴趣，以 GPA 为首要目标。这当然是有效的，我秋季学期的 GPA 都挺不错；但同时也是无聊的，天天跑图书馆写作业刷题对某些同学来说可能是享受，但我真的不喜欢以提高分数为唯一目的的学习。

我也曾妄想过“小孩子才做选择，我全都要”，每个学期之前都想着如何能够更高效地利用时间，把学业和其他的所有事情都做到极致。然而，这种想法未曾成为现实，主要有几个原因：第一，我时间管理极差，无法利用正常作息下白天和晚上大部分可以利用的时间。第二，我对于我感兴趣的事情往往有着极高的热情，而这种热情往往导致时间安排上极不均衡的优先级，进而导致一些目前阶段可能（或者说表面上）较为重要的任务没有充足的时间完成（用计算机的专业术语来说，starvation /笑）。

尽管在这个学期开学前有想过避免以前春季学期的问题，但很不幸，课内学习不够投入的问题并没有得到解决。现在想来，主要的原因是软工占用了大部分时间，其他课程上得也不舒服：数电 tp 老师讲课风格实在是不喜欢，人智导讲的内容实在是没兴趣，搜索引擎实在是太水，而我又比较喜欢捣鼓软工所用的一些技术……因此很多课都用来写软工了（数电前几周的课、搜索引擎后面的课、人智导大部分的课）。微积分倒是坚持认真听了十几周，但耐不住记 P/F 这一重大利好（终于能在不影响 GPA 的情况下修完微积分了 /哭），在记了 P/F 之后就没听了。

另一个原因，与之前相似，是课外的工作占用了大量的时间，这个学期主要是科研。这个学期开始跟着学长做科研项目，从寒假开始一直在恶补操作系统的知识，后面换方向后又从零开始学习了数据库的知识。等到终于开始上手代码了，花了很多时间调试和修改以前论文的代码，然后考试周就来了，只能搁置。总的来说，这一段科研经历的开端并不是特别顺利，也还没有完全找到自己感兴趣的方向，但总算是开了个头，也算是迈出了一小步。

总之这个学期就这么不太明白地过去了。有很多不好的经历：软工开题后焦虑、软工进展不顺、数电听不懂、数电实验遇到各种问题、人智导没兴趣、科研进展缓慢……同时也有很多美好的回忆：软工助教和用户代表高度评价我们的项目、软工做了一个（自认为）非常精彩的展示、科研开了一个还算可以的头……

和一个学期前相比，我的乐观精神显然消退了不少。或许是因为第一次遇到了对于计算机不太感兴趣或不太擅长的方面，或许是发现在某些方面自己没办法做到某些同学的高度，或许是在读文章时感受到自己的水平与顶尖水平的巨大差距……总之，发现有些事情是自己做不到的，这对于我自己能力的认识，以及对未来的规划都产生了不小的影响。当然，我也时常想起软工被用户代表和 rls 夸上天的时候的那种兴奋感。或许，我还是能够在一些地方找到自己的独特之处的。

至于暑假和下学期，还是花多点时间在科研上吧。如果这条路能走通，那就坚定走下去；如果走不通，那就要及时考虑一下其他道路了。

WWDC22 Sessions 记录

liang2kl@outlook.com (Liang Yesheng) — Wed, 08 Jun 2022 22:27:07 +0800

虽然 iOS 16 和 macOS 13 并没有太大的变化，但是 SDK（特别是 SwiftUI）更新的东西相当多，解决了很多以前开发中的痛点。

目录（根据观看时间顺序，大致按照发布顺序）：

Meet Swift Regex
Meet desktop class iPad
The SwiftUI cookbook for navigation
Hello Swift Charts
What’s new in SwiftUI
What’s new in UIKit
Compose custom layouts with SwiftUI
Swift Charts: Raise the bar
Embrace Swift generics
Design protocol interfaces in Swift

Meet Swift Regex

https://developer.apple.com/videos/play/wwdc2022/110357/

Swift 5.7 新增了强类型的正则表达式类型，自动将字符串转化为需要的类型，支持编译器检查。另外还提供了 RegexBuilder 框架，使用 SwiftUI 所使用的 result builder 语法来写正则表达式，非常具有表达力。编译器帮忙检查的 regex 和强类型的 capture 太香了。

Regex literal，强类型静态正则表达式：

// Regex literals
let digits = /\d+/
// digits: Regex<Substring>

Regex Builder，使用 result builder 构建正则表达式：

// CREDIT 03/02/2022 Payroll from employer $200.23
// CREDIT 03/03/2022 Suspect A $2,000,000.00
// DEBIT 03/03/2022 Ted's Pet Rock Sanctuary $2,000,000.00
// DEBIT 03/05/2022 Doug's Dugout Dogs $33.27

import RegexBuilder
let fieldSeparator = /\s{2,}|\t/
let transactionMatcher = Regex {
 Capture { /CREDIT|DEBIT/ }
 fieldSeparator

 Capture { One(.date(.numeric, locale: Locale(identifier: "en_US"), timeZone: .gmt)) }
 fieldSeparator

 Capture {
 OneOrMore {
 NegativeLookahead { fieldSeparator }
 CharacterClass.any
 }
 }
 fieldSeparator
 Capture { One(.localizedCurrency(code: "USD").locale(Locale(identifier: "en_US"))) }
}
// transactionMatcher: Regex<(Substring, Substring, Date, Substring, Decimal)>}

Named captures，给各个 group 起名（返回的结果是一个 Tuple，因此可以在编译期加上标识）：

let regex = #/
 (?<date> \d{2} / \d{2} / \d{4})
 (?<middle> \P{currencySymbol}+)
 (?<currency> \p{currencySymbol})
/#
// Regex<(Substring, date: Substring, middle: Substring, currency: Substring)>

Meet desktop class iPad

https://developer.apple.com/videos/play/wwdc2022/10069/

针对 iPad 生产力问题作的改进，推出了更像 macOS 的 toolbar。不过，这远远不能解决 iPad 缺少足够 productive 的应用的问题。

https://developer.apple.com/videos/play/wwdc2022/10054/

苹果终于改进了 SwiftUI 上视图导航的逻辑。简单来说就是以前只能傻傻地打开另一个视图而无法获取之前的视图的情况，现在可以获取并可以用程序控制当前所在的层级了。

官方的示例代码：

import SwiftUI

// Pushable stack
struct PushableStack: View {
 @State private var path: [Recipe] = []
 @StateObject private var dataModel = DataModel()

 var body: some View {
 NavigationStack(path: $path) {
 List(Category.allCases) { category in
 Section(category.localizedName) {
 ForEach(dataModel.recipes(in: category)) { recipe in
 NavigationLink(recipe.name, value: recipe)
 }
 }
 }
 .navigationTitle("Categories")
 .navigationDestination(for: Recipe.self) { recipe in
 RecipeDetail(recipe: recipe)
 }
 }
 .environmentObject(dataModel)
 }
}

相比于之前 NavigationLink 提供一个 View，现在可以提供一个用于区分不同目标的值来代替（这样就可以记录栈上的内容）：

NavigationLink(recipe.name, value: recipe)

然后，使用 navigationDestination() 来返回对应的 View：

.navigationDestination(for: Recipe.self) { recipe in
 RecipeDetail(recipe: recipe)
}

使用新的 NavigationStack，我们传递一个 path 来获取当前导航栈上的所有 destination 所对应的值：

NavigationStack(path: $path)

这样，我们可以通过更改 path 来随意更改导航栈：

path.removeAll()

另外，还可以通过 SceneStorage 持久化当前的状态。

Hello Swift Charts

https://developer.apple.com/videos/play/wwdc2022/10136/

官方的图表框架，使用 SwiftUI 快速构建图表，非常简洁。比如，创建折线图：

Chart(partyTasksRemaining) { element in
 LineMark(
 x: .value("Date", element.date, unit: .day),
 y: .value("Tasks Remaining", element.remainingCount)
 )
 .foregroundStyle(by: .value("Category", element.category))
 .symbol(by: .value("Category", element.category))
}

最后效果很不错（也很苹果）：

声明式语法真是太适合做图表了，matplotlib 虽然强大但是画个图挺麻烦的，在想着以后科研能不能用 Swift 画图（

What’s new in SwiftUI

https://developer.apple.com/videos/play/wwdc2022/10052/

除了上面提到的 Swift Charts 和 navigation 之外，这次 SwiftUI 的主要更新还有：

macOS 可以创建单独的、可以控制显示/关闭的窗口了：

@main
struct PartyPlanner: App {
 var body: some Scene {
 WindowGroup("Party Planner") {
 PartyPlannerHome()
 }

 Window("Party Budget", id: "budget") {
 Text("Budget View")
 }
 .keyboardShortcut("0")
 }
}

另外，终于支持状态栏 app 了：

@main
struct PartyPlanner: App {
 var body: some Scene {
 MenuBarExtra("Bulletin Board", systemImage: "quote.bubble") {
 BulletinBoard()
 }
 .menuBarExtraStyle(.window)
 }
}

Resizable sheets

加入了去年 UIKit 新增的可变高度的 sheet：

.sheet(isPresented: $presented) {
 Text("Budget View")
 .presentationDetents([.height(250), .medium])
 .presentationDragIndicator(.visible)
}

其他

其他的更新包括：

macOS 上 Form 新的外观
支持多行的 TextField 和限定行高范围
iPad 支持 Table
可自定义的 toolbar
可自定义的 layout

What’s new in UIKit

https://developer.apple.com/videos/play/wwdc2022/10068/

现在基本不写 UIKit 了，这部分就没怎么记录。比较有意思的是，现在创建 UICollectionView 和 UITableView 可以用 SwiftUI 来写 cell 的 UI 了：

cell.contentConfiguration = UIHostingConfiguration {
 VStack {
 Image(systemName: "wand.and.stars")
 .font(.title)
 Text("Like magic!")
 .font(.title2).bold()
 }
 .foregroundStyle(Color.purple)
}

其他的更新，如新的 toolbar，到暑假可以用来改进一下 Whiz Reader（不过可能用 SwiftUI 重写而不是继续用 UIKit）。

Compose custom layouts with SwiftUI

https://developer.apple.com/videos/play/wwdc2022/10056/

支持自定义布局应该是本次 SwiftUI 最重要的更新了。现在我们可以访问到一些以前获取不到的信息来放置子视图了。

Grid

在介绍自定义布局之前，首先介绍了新增的 Grid 类型，可以构建静态的对齐与网格的布局。

与之前的 LazyHGrid 和 LazyVGrid 不同，Grid 不是懒加载的，因此高/宽是确定的，适合于静态 grid 的构建。

与 VStack 和 HStack 的组合相比，Grid 的各行/列可以自动根据最大元素调整大小，而 VStack 和 HStack 不行。比如，现在可以实现这样一个列表：

左侧的名称一栏自动将宽度调整到适合于最大的 Goldfish，右侧同理。

在以前，使用 VStack 和 HStack 想要实现各列大小一致，只能给各列指定固定的大小。比如，树洞的评论界面大概是这样实现的：
VStack {
 ForEach(comments) { comment in
 HStack {
 Text(comment.name)
 .fixedSize(.horizontal, 20)
 Text(comment.content)
 }
 }
}
当 comment.name 过长时，就会变成两行，非常影响体验。

自定义布局

自定义布局对应一个新的协议：Layout。

Layout 通过两个函数参与布局过程：

func sizeThatFits(
 proposal: ProposedViewSize,
 subviews: Subviews,
 cache: inout Void
) -> CGSize

func placeSubviews(
 in bounds: CGRect,
 proposal: ProposedViewSize,
 subviews: Subviews,
 cache: inout Void
)

第一个函数 sizeThatFits() 通过返回一个大小来告诉父 View 我们需要多少空间；第二个函数 placeSubviews() 将所有的子 View 放置在合适的位置（使用我们在 sizeThatFits 中要求的空间）。

sizeThatFits

我们先来看 sizeThatFits()。它有三个参数：

proposal：父 View 所期望这个布局的大小。我们（可以）根据 proposal 的大小来决定我们最终要占据多少空间，当然也可以忽略
subviews：布局中所有的子 View。这并不是 View 本身，而是它的“代理”（proxy），仅给我们提供必要的信息和接口
cache：可用来缓存中间计算结果

关于 proposal，官方文档是这样介绍的：

A proposed size for the subview. In SwiftUI, views choose their own size, but can take a size proposal from their parent view into account when doing so.

可以看到，proposal 是父视图对子视图大小的“建议”。父视图在进行布局时，将建议的大小传入每个子视图，子视图经过计算返回最终的大小（可以是 proposal 的大小，也可以不是），父视图最终根据子视图返回的大小来进行布局的计算（而不是它所认为的大小，即 proposal）。

我们以官方的例子为例。这个例子实现了一个 EqualWidthHStack，有几个需求：

水平布局
每个子 View 大小相同
每个子 View 的大小都等于最大的子 View

对于这个 layout，sizeThatFits() 如下：

原理很简单：计算子 View 的最大的 size，加上之间的 spacing，即是布局需要的大小。我们通过 LayoutSubview 的 sizeThatFits() 获取每个子 View 的大小，然后计算最大值：

private func maxSize(subviews: Subviews) -> CGSize {
 let subviewSizes = subviews.map { $0.sizeThatFits(.unspecified) }
 let maxSize: CGSize = subviewSizes.reduce(.zero) { currentMax, subviewSize in
 CGSize(
 width: max(currentMax.width, subviewSize.width),
 height: max(currentMax.height, subviewSize.height))
 }

 return maxSize
}

在 sizeThatFits() 中，我们忽略了 proposal，这样在父视图的任何大小下这个布局所占的空间都是一样的。如果需要更灵活的布局，如空间不足时自动缩小，可以根据不同的 proposal 返回不同的大小。

placeSubviews

placeSubviews() 相较于 sizeThatFits() 多了一个参数 bounds，其余参数均相同；我们通过调用 LayoutSubview 的方法来放置子视图。其实完全可以理解为两个函数是同一个函数的两个部分，sizeThatFits() 用于计算视图大小，placeSubviews() 用我们计算好的大小来放置视图；只是因为上层调用是两个不连续的过程，才将它们分开为两个函数。

因此，这两个函数一般具有部分相同的逻辑，比如上面的 maxSize() 和 spacing()，最好将其写到一个新的函数中以便复用，或者直接将中间结果放到 cache 中（待考证）。

实现 EqualWidthHStack 的 placeSubviews() 很简单，我们只需要通过相同的方法计算 maxSize 和 spacing，然后将每个 subView 放置在合适的位置就可以了。这个过程通过 LayoutSubView 的 place() 方法完成。

传递额外信息

这种方式有一个问题：传入的 subviews 只是视图的代理，不带有视图的信息。如果我们需要传递子视图的额外信息用于布局的计算，官方提供了一种（强类型的）方式：

struct Rank: LayoutValueKey {
 static let defaultValue: Int = 1
}

MyLayout(1...10) { rank in
 Text("\(rank)")
 .layoutValue(key: Rank.self, value: rank)
}

使用下标运算符，我们可以从 subview 中获取对应的值：

let ranks = subviews.map { subview in
 subview[Rank.self]
}

这样就实现了额外信息的传递。

自适应布局

有意思的是，官方还实现了一个能够根据可用空间的大小自动调整布局的布局 ViewThatFits：

ViewThatFits {
 EqualWidthHStack {
 Buttons(...)
 }
 VStack {
 Buttons(...)
 }
}

当空间足够时，选择第一个 EqualWidthHStack；空间不够时，选择所需空间更少的 VStack。

其实这个非常 fancy 的布局的实现应该很简单：根据 EqualWidthHStack 和 VStack 的 sizeThatFits() 的返回值，按顺序选择能够在可用空间内放置的一个。当然，我们没办法在自定义排布中选择哪些子视图不显示，因此是没办法完美地手动实现一个类似的容器的（可以通过不给子视图分配空间来实现，不过这样子视图仍然会加载）。

AnyLayout

最后，官方提供了一个 type-erased 的 Layout，即 AnyLayout，可以用于动态改变布局类型：

let layout = isThreeWayTie ? AnyLayout(HStack())
 : AnyLayout(MyRadialLayout())

layout {
 ForEach(pets) { pet in
 Avatar(pet: pet)
 }
}
.animation(...)

另外，由于 layout 中的 View（在这里是若干个 Avatar）在不同的布局下具有相同的 view identity，因此布局变化前后子视图是不变的。通过这一点，我们甚至可以为不同布局的变化加上动画。

Swift Charts: Raise the bar

https://developer.apple.com/videos/play/wwdc2022/10137/

Swift Charts 框架的进阶介绍，主要介绍了一些自定义方法。

增加标注：

指定图表颜色：

自定义刻度：

自定义图表区域：

在图表上添加一层 overlay，可用于交互：

Embrace Swift generics

https://developer.apple.com/videos/play/wwdc2022/110352/

介绍了 Swift 范型的更新，主要针对 protocol。

protocol Animal {
 associatedtype Feed: AnimalFeed
 func eat(_ feed: Feed)
}

struct Farm {
 func feed(_ animal: some Animal) {
 let crop = type(of: animal).Feed.grow()
 let produce = crop.harvest()
 animal.eat(produce)
 }
 func feedAll(_ animals: [any Animal]) {
 for animal in animals {
 feed(animal)
 }
 }
}

上面的代码中有几个关键点：

协议限制在 Swift 5.7 中可以用 opaque type，即 some 关键字表示
可以用 type(of:) 来获取确定的具体类型
在 Swift 5.7 中可使用 any 实现针对 protocol 的类型消除（type erasure）

any 非常实用。之前，数组只能储存同一具体类型的数据，不能储存遵循相同协议而类型不同的数据（主要原因应该是内存大小不同）；在 Swift 5.7 中，使用 any 可以储存遵循某协议的任意类型的数据。现在，数组就不一定直接储存对象本身了。如果对象大小合适（这里不太清楚“合适”的含义，估计是指针大小以内？），可以直接存到数组里，否则存在外面：

这种方式有点像存了一堆指针，但是又不完全是（较小的对象可以直接放在数组内），可能是为了减少虚函数查表的开销？

另外，any 类型可以用于 some，具体类型的获取在运行时完成。这种转换叫做“opening boxes”，即“打开盒子看究竟是什么动物”：

最后，官方建议：

Write some by default

道理很简单，直接调用带 some 参数的函数实际上在编译期是确定了类型的，而 any 在编译期去掉了具体类型的信息，在运行期才能确定，相比之下效率较低。

Design protocol interfaces in Swift

https://developer.apple.com/videos/play/wwdc2022/110353/

在上面 Embrace Swift generics 的基础上，进一步介绍使用新的语言特性设计协议。

Type erasure

和上面类似的例子。当我们使用类型消除时，所有类型变成“上界”（不太明白这个名词的意思…），与之相关的所有泛型都变成对应的上界。

比如，any Animal 调用 produce() 的结果类型为 any Food：

但是，反过来，不能够将某一个符合 associatedtype 的类型作为参数传入一个上界类型的函数中。

比如，Crop() 不能作为 any Animal 的 eat() 的参数：

这里的关键在于，一个具体类型总是可以安全地转换为 any，而 any 不能反过来安全地转换为某一个具体的类型。

Hide implementation details

有时候，我们不希望暴露太多实现细节，比如下面的这个例子：

我们希望使用 LazyFilterSequence 来提高性能，然而并不希望将这个信息暴露在 API 中。Swift 为了解决这个问题，增加了一个叫做 primary associated types 的语法：

Primary associated types 大致的意思是，将 protocol 中与实现细节相关的 associatedtype 使用尖括号暴露出来，从而能够使用 some 或者 any 来表示满足这个 associatedtype 要求的类型。

比如，标准库中的 Collection：

protocol Collection<Element>: Sequence {
 associatedtype Element
}

关于 `type(of:)`

看完视频最主要的疑问是：type(of:) 究竟是完全由运行时决定的，还是有编译器参与的。比如上面的例子：

protocol Animal {
 associatedtype Feed: AnimalFeed
 func eat(_ feed: Feed)
}

func feed(_ animal: some Animal) {
 let crop = type(of: animal).Feed.grow()
 let produce = crop.harvest()
 animal.eat(produce)
}

编译器知道 some Animal 是一个具体的、遵循 Animal 的类型（包括运行时才能确定类型的 any Animal），因此可以确定 type(of: animal).Feed 的类型就是具体类型的 Feed，上面的代码得以通过编译。

但是，脱离了 some 的语境，any 就没有这种机制了：

let animal: any Animal = Cow()
let crop = type(of: animal).Feed.grow()
// error: type of expression is ambiguous without more context
// let crop = type(of: animal).Feed.grow()
// ~~~~~~~~~~~~~~~~~^^^^~~~~~~~

编译器实际上通过 some 给 any 提供了便利，即虽然不能在编译期知道具体的类型，但是可以保证 associatedtype 的正确性，这也是上面所说的“Open boxing”实现的效果。要想利用这种便利，我们需要使用带有 some 参数的函数。

音乐剧 Come From Away 赏析

liang2kl@outlook.com (Liang Yesheng) — Sat, 28 May 2022 14:27:27 +0800

本文为 2022 年春季学期《西方音乐剧史》课程期末作业

《Come From Away》的故事原型是，在 911 事件发生时，加拿大的一个小镇接纳了超过 7000 个因飞行禁令临时降落在此地的乘客。故事本身并不复杂，主要讲述了当地居民尽其所能为滞留乘客提供住宿等帮助、乘客从一开始的恐慌、焦虑到最终融入当地人的生活中，并获得了继续前行的动力。

下面主要从舞台设计和主题表达两个方面进行赏析。

舞台设计

这部音乐剧最令人印象深刻的是对转场、道具和灯光的令人惊叹的设计，可以说充分展现了音乐剧作为舞台表演艺术的魅力。

场景切换

本部音乐剧总体上是刻画群像，涉及到当地居民和乘客等多个群体，并且群体内部又分成很多不同的角色。如何在 Cast 有限的条件下（只有 12 人）演出这么多不同的角色，并且营造本剧“来的人很多”的背景氛围呢？方法很简单：一个演员演多个角色，并在不同场景中切换。但是这种方法有一个最大的问题：如何让观众清楚地知道这个时刻舞台上的演员演的是哪个角色、现在是在哪个场景？

《Come From Away》的方法是，利用服装、道具、灯光等，来主动地为人物提供“背景”，并结合演员的动作和台词，来进行快速的场景切换。

本剧角色和场景切换的速度之快令人瞠目结舌，同时又达到了非常好的效果。比如，在下面这短短三分钟中，一共表现了 6 个场景的情形。

首先，场景是在小镇的酒吧内，大家刚刚得知恐怖袭击的消息：

此时，灯光熄灭，演员打开手电筒，瞬间切换另一个场景：

这里演员使用手电筒营造了光线不强、主要发光源是屏幕的环境，结合台词观众很容易就知道现在场景切换到了塔台上。

接下来的场景是塔台和机长进行交流。首先是塔台上管制员在繁忙地向机长传达必须马上降落的信息：

然后，椅子一转，所有演员面朝观众。这时候，演员以机长的身份分别与塔台交流（这里同时有多架飞机），我们因此可以知道现在场景切换到了飞机的驾驶舱内。

突然，灯光一暗，演员向右转 90 度，瞬间切换到了机舱内乘客们的场景，同时乘务员开始讲话。我们可以看到这里其实还有原先的桌子，实际上是不符合机舱的情况的，但是并不会造成观众的误解。

过了一段时间，演员站起来，抬头向上看，开始在数降落的飞机的数量。这里，场景又切换到了机场的地面上。我们可以看到，后面的部分演员仍然保持之前的坐姿，但由于他们都在向上看，并逐渐站起来，因此这两个场景的过渡非常自然。之前的乘务员脱下帽子和外套，拿起麦克风，摇身一变成为在地面进行报道的记者，毫无违和感。

最后，灯光由冷变暖，场景重新回到室内的酒吧。这里有个细节，切换前各个演员是分散的，而一切换到酒吧后，演员们都朝着镇长聚集，这也加强了对场景的构建。

总的来看，本剧进行场景切换的主要方法有：

演员表演：通过台词、动作和表情演绎不同角色，如机舱内乘客拨动头顶的开关、管制员用严肃的语气进行无线电通话
服装：通过有职业/角色特点的服装区分同一个演员饰演的不同角色
灯光：通过灯光区分不同场景，如室内的酒吧是暖色的，机舱和地面是冷色的，而塔台和驾驶舱是暗的
道具：通过道具（这里主要是椅子）表现空间的特点

上面的片段使用非线性叙事的方法，将“下达降落命令”这一时刻前后不同地点、不同角色的情况，包括角色的身份、心情等串联起来，立体地表现了不同人群在这一时间对事件的反应，颇有概念音乐剧的影子。

同时，演员所表现的是群像特征，而不是特定角色的特点，因此成功地表现了各个群体总体在此刻的境遇。这也使得观众无需将演员与特定角色绑定（除了酒吧的场景），使得场景切换非常自然。

有意思的是，剧组在剧中还故意展示了他们通过这种方式“省人手”的技巧。同一个人戴上眼镜，长了胡子，或者戴上帽子，配上不同的表情，就是不同性格的、不同镇的镇长，引来阵阵笑声：

道具

这部剧除了十几张椅子外几乎没有任何道具。但就是这十几张椅子，剧组把它们玩出了花。这些椅子的最大作用，如前所述，是用于场景构建。下面这两张图非常明显地展示了这点：

将椅子拍成两排，就变成了机舱的座位。

又如，机长在讲述自己的故事时，其余的人围成一圈：

情侣在野外登高时，用凳子构成一条栈道：

这种方式非常有效，因为不同场景的设施具有迥异的几何排布特征，使用凳子表现这些几何特征，就可以让观众迅速识别并沉浸入场景中（同时非常省经费！）。

另外，灯光和服装等设计，以及演员的表演也对舞台效果起了非常大的作用，在这里限于篇幅不再进行深入分析。让我印象比较深刻的有这些场景：

众人进行默哀，此时一束光穿过树林投下来，渲染了庄严的气氛：

这个是乘客和司机坐在校车上，司机脸前有亮光，而乘客的区域是暗的；同时乘客头瘫向一边非常生动地表现了乘客此时是在车上（急转弯），并且非常疲惫：

你很难想象在舞台上能够表演出的比这个更生动形象的场景了。

主题表现

本剧最主要的主题是表现人们在面对灾难时互相帮助的精神，但又不只于此。

剧组使用相同的演员来饰演不同的角色。这里固然有演员人数的考虑，但我相信这其中蕴含了另一层深意。在剧中，同一个演员既是需要住宿的乘客，也是提供帮助的本地人；既是与事件有直接关系的遇难者家属，也是因看到电视画面而产生心理创伤的普通人……在恐怖主义面前，全体人类都是需要帮助的对象。你就是我，我就是你。帮助他人，从另一个角度来看，也是帮助自己。

通过将灾难下的所有人视为一个整体，恐怖主义被放置在了全体人类的对立面。这以一种非常温和，却非常有力的方式蔑视了恐怖主义，即使全剧几乎没有一句台词直接谴责恐怖主义行为。

这也是本剧的主调，即以普通人的视角来审视 911 事件给人们带来的创伤，以及我们从灾难后人们的互相帮助中所看到的人类本性中最珍贵的特质：善良，乐于助人，等等。本剧之所以有很强的感染力，在于它不仅仅赞颂了人类的珍贵特质——这样的话就成“主旋律”“唱颂歌”类型的剧了；它同时通过去世消防员的母亲等角色提醒我们恐怖主义给我们带来的巨大创伤，提醒我们不要忘记每一个亲历者以及背后无数个家庭的痛苦经历。正如镇长的唱段中所言：

Tonight, we honor what was lost, but we also commemorate what we found.

这里有个小插曲，在《Something’s Missing》中，消防员的母亲在得知儿子去世后开口唱“You are here / At the end of the moment…” 的时候，背后拉小提琴的小姐姐忍不住哭了：

大概，共情是人类能够站在一起最重要的原因吧。

其他

这部音乐剧有比较浓的商业音乐剧的气息，比如无处不在的政治正确，以及时不时的玩梗和抛笑话，非常的 entertaining；这部剧也非常“小清新”，并没有激烈的冲突，也没有非常深入的主题挖掘。另一方面，近乎完美的编排、令人眼花缭乱的舞台表现也反映了当下音乐剧商业化、产业化的趋势。当然，这些并不妨碍这部剧成为一部非常优秀的音乐剧作品。

后记

《Come From Away》实际上是我看过的第一部音乐剧。去年官摄版上架 Apple TV+，恰巧我有订阅，之前也或多或少感受过音乐剧的魅力，于是便找了一个周末看了，之后就爱上了音乐剧（并选了《西方音乐剧史》课程 ^_^）。现在感觉自己挺幸运，第一次就能看到这样一部能够将音乐剧的魅力展现得淋漓尽致的剧（并且有 4k 画质和 Dolby Atmos 音效，which is 非常难得）。

当然，上完课之后再重新看一遍这部音乐剧，获得了完全不一样的体验。与之前只能看剧情不同，现在能够看懂一些表现手法了，也能在上面有模有样地分析它究竟好在哪里。希望以后能够继续深入音乐剧的世界。感谢罗老师的指导！

协程上下文切换

liang2kl@outlook.com (Liang Yesheng) — Thu, 26 May 2022 13:02:01 +0800

最近在研究 Arachne 做用户态线程调度的方法。

众所周知，一个线程的状态包括：

PC
一些寄存器（即“上下文”）

切换线程时，需要切换上下文；为了将来能够恢复上下文，在切换时我们需要将当前的上下文保存在某个地方。我们尝试用 C 写一个简单的上下文切换。

上下文切换

进行上下文切换的汇编代码在上汇编课时就讲过：

swapcontext:
# save current context
pushq %r12
pushq %r13
pushq %r14
pushq %r15
pushq %rbx
pushq %rbp
movq %rsp, (%rsi)
# restore previously saved context
movq (%rdi), %rsp
popq %rbp
popq %rbx
popq %r15
popq %r14
popq %r13
popq %r12

上面的代码做了几件事情：

保存当前上下文
1. 将被调用者保存寄存器保存到当前的调用栈上
2. 将当前的栈指针 %rsp 保存到 %rsi 所指向的内存地址上
恢复之前保存的上下文
1. 将栈指针恢复为 %rdi 所保存的另一个协程的栈顶
2. 恢复另一个协程的栈上面保存的被调用者保存寄存器

这里需要理解一个问题：为什么需要保存被调用者保存寄存器？

“被调用者保存寄存器”指的是在调用子过程前后不发生改变的寄存器，即子过程需要在返回前将这些寄存器的值恢复。上面的 swapcontext 是一个过程调用，因此需要遵循这一惯例。然而，与一般的过程调用不同，我们在这里实际上是切换到了另一个上下文中，因此我们实际上是恢复了另一个协程的上下文。

这里可能会产生疑惑：调用者保存寄存器呢？实际上，调用 swapcontext 的过程在调用它之前就已经把调用者保存寄存器保存好了（如果有必要的话）。理解的关键是：swapcontext 是一个过程，而不是内联的汇编代码。

调用栈结构

由于 swapcontext 中会将当前的上下文保存到某个内存地址，我们之后只需要将这个内存地址传入 swapcontext 就可以切换回来了。在这里，我们主要考虑在一开始如何切换到一个指定的函数上；我们需要初始化调用栈，使得 swapcontext 后能够跳转到指定的函数。

不难画出这样的一个调用栈：

 +-----------------------+
 | |
 +-----------------------+
 | Return Address |
 +-----------------------+
 | |
 | Registers |
sp-> | |
 +-----------------------+
 | |
 | |

我们将需要切换到的函数的地址保存在 Return Address 中。在使用 popq 指令恢复所有保存的寄存器后，rsp 指向此函数地址，swapcontext 返回（ret 指令）后便跳转到函数的入口地址。需要注意的是 Return Address 上方需要保留 8 字节的空间。

栈的初始化过程如下：

#define SPACE_FOR_SAVED_REGISTERS 48UL
#define STACK_SIZE 1024UL

void routine2() {
 // ...
}

void *sp2;
char stack[8 + SPACE_FOR_SAVED_REGISTERS + STACK_SIZE];

int main() {
 // Initialize stack for routine2
 sp2 = stack + SPACE_FOR_SAVED_REGISTERS + STACK_SIZE - 2 * sizeof(void *);

 // Set return address
 *(void **)sp2 = routine2;

 // Point to bottom of the register stack
 sp2 = (char *)sp2 - SPACE_FOR_SAVED_REGISTERS;

 //...
}

在这里，我们创建一个栈，并将 routine2 的地址写到相应位置；sp2 指向最后一个储存寄存器值的位置。

此时，stack、sp2 和调用栈的结构如下：

 +-----------------------+
 | |
 +-----------------------+
 | Address of `routine2` |
 +-----------------------+
 | |
 | Registers |
sp2-> | |
 +-----------------------+
 | |
 | |
 | Stack Space |
 | |
stack-> | |
 +-----------------------+

程序

最后，我们写几个简单的上下文切换的 demo。

例子 #1

在这里，我们进行两次上下文切换，从 routine 切换到 routine2，再切换回 routine。

其中，swapcontext 需要加上 noinline 的 attribute，这是为了保证 swapcontext 作为过程被调用。

另外，编译时需要加上 -fomit-frame-pointer，否则编译器在编译时会在过程前后分别加上 pushq %rbp 和 popq %rbp，导致栈结构遭到破坏。

#include <stdio.h>

#define SPACE_FOR_SAVED_REGISTERS 48UL
#define STACK_SIZE 1024UL

void __attribute__((noinline)) swapcontext(void** saved, void** target) {
 asm("pushq %r12\n\t"
 "pushq %r13\n\t"
 "pushq %r14\n\t"
 "pushq %r15\n\t"
 "pushq %rbx\n\t"
 "pushq %rbp\n\t"
 "movq %rsp, (%rsi)");

 asm("movq (%rdi), %rsp\n\t"
 "popq %rbp\n\t"
 "popq %rbx\n\t"
 "popq %r15\n\t"
 "popq %r14\n\t"
 "popq %r13\n\t"
 "popq %r12");
}

void *sp2;
void *sp;
char stack[8 + SPACE_FOR_SAVED_REGISTERS + STACK_SIZE];

void routine() {
 printf("routine()\n");
 // Switch to routine2
 swapcontext(&sp2, &sp);
 printf("routine() end\n");
}

void routine2() {
 printf("routine2()\n");
 // Switch back
 swapcontext(&sp, &sp2);
 // Unreachable
 printf("routine2() end\n");
}

int main() {
 // Initialize stack for routine2
 sp2 = stack + SPACE_FOR_SAVED_REGISTERS + STACK_SIZE - 2 * sizeof(void *);

 // Set return address
 *(void **)sp2 = routine2;

 // Point to bottom of the register stack
 sp2 = (char *)sp2 - SPACE_FOR_SAVED_REGISTERS;

 routine();

 printf("main routine\n");
 return 0;
}

输出如下：

routine()
routine2()
routine() end
main routine

例子 #2

继续尝试一些其他的用法。在这里，我们计算 0 累加至 9 的结果，并在每次循环时都切换一次上下文，然后立刻切换回来。

void routine() {
 printf("routine()\n");
 int sum = 0;

 for (int i = 0; i < 10; i++) {
 sum += i;
 swapcontext(&sp2, &sp);
 }

 printf("sum: %d\n", sum);
}

void routine2() {
 for (;;) {
 printf("routine2()\n");
 swapcontext(&sp, &sp2);
 }
}

输出为：

routine()
routine2()
routine2()
routine2()
routine2()
routine2()
routine2()
routine2()
routine2()
routine2()
routine2()
sum: 45

汇编结果

使用 -O1 编译上面第二个例子（去掉所有 printf），routine 的汇编代码如下：

0000000000000639 <routine>:
639: 55 push %rbp
63a: 53 push %rbx
63b: bb 0a 00 00 00 mov $0xa,%ebx
640: 48 8d 2d f9 09 20 00 lea 0x2009f9(%rip),%rbp # 201040 <sp>
647: 48 89 ee mov %rbp,%rsi
64a: 48 8d 3d 47 0e 20 00 lea 0x200e47(%rip),%rdi # 201498 <sp2>
651: e8 af ff ff ff callq 605 <swapcontext>
656: 83 eb 01 sub $0x1,%ebx
659: 75 ec jne 647 <routine+0xe>
65b: 5b pop %rbx
65c: 5d pop %rbp
65d: c3 retq

可以看到，for 循环使用 %ebx（被调用者保存）进行计数，在调用 swapcontext 前后并没有保存其值。保存这个寄存器是 swapcontext 的责任。

Operating Systems: Three Easy Pieces 学习笔记（五）

liang2kl@outlook.com (Liang Yesheng) — Wed, 25 May 2022 11:44:11 +0800

26 Concurrency: An Introduction

Each thread is very much like a separate process, except for one difference: they share the same address space and thus can access the same data.

State of a single thread:

program counter
private set of registers (context switch is needed)

which are stored in process control block.

Any stack-allocated variables, parameters, return values, and other things that we put on the stack will be placed in what is sometimes called thread-local storage.

26.1 Why Use Threads?

parallelism: speed up using multi-core processors
avoid blocking during I/O

Computers are hard enough to understand without concurrency. Unfortunately, with concurrency, it simply gets worse. Much worse.

26.4 The Heart Of The Problem: Uncontrolled Scheduling

Race condition: the results depend on the timing execution of the code.

Critical section: a piece of code that accesses a shared variable (or more generally, a shared resource) and must not be concurrently executed by more than one thread.

Mutal exclusion: if one thread is executing within the critical section, the others will be prevented from doing so.

27 Interlude: Thread API

27.4 Condition Variables

int pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t *mutex);
int pthread_cond_signal(pthread_cond_t *cond);

To wait for a signal:

pthread_mutex_lock(&lock);
while (ready == 0)
 pthread_cond_wait(&cond, &lock); // will release the lock when sleep
 // and re-acquire before wakeup
pthread_mutex_unlock(&lock);

To send a signal:

pthread_mutex_lock(&lock);
ready = 1;
pthread_cond_signal(&cond);
pthread_mutex_unlock(&lock);

28 Locks

28.4 Evaluating Locks

Criteria:

mutal exclusion
fairness
performance

28.6 A Failed Attempt: Just Using Loads/Stores

Problems:

No mutal exclusion
Poor performance: spin-waiting

The problem: set after test (maybe after an interrupt).

28.7 Building Working Spin Locks with Test-And-Set

Test-and-set instruction (xchg on x86) is something like:

int testAndSet(int *old_ptr, int new) {
 int old = *old_ptr; // fetch old value at old_ptr
 *old_ptr = new; // store ’new’ into old_ptr
 return old; // return the old value
}

Lock and unlock:

void lock(lock_t *lock) {
 while (testAndSet(&lock->flag, 1) == 1)
 ; // spin-wait (do nothing)
}

void unlock(lock_t *lock) {
 lock->flag = 0;
}

28.8 Evaluating Spin Locks

correctness: yes
fairness: no, maybe spinning forever (starvation)
performance: bad in single CPU case

28.9 Compare-And-Swap

int compareAndSwap(int *ptr, int expected, int new) {
 int original = *ptr;
 if (original == expected)
 *ptr = new;
 return original;

28.10 Load-Linked and Store-Conditional

Store-conditional: only succeeds (and updates the value stored at the address just load-linked from) if no intervening store to the address has taken place.

void lock(lock_t *lock) {
 while (loadLinked(&lock->flag) == 1 ||
 storeConditional(&lock->flag, 1) == 0)
 ;
}

28.11 Fetch-And-Add

The pseudo C code:

int fetchAndAdd(int *ptr) {
 int old = *ptr;
 *ptr = old + 1;
 return old;
}

Lock and unlock:

void lock(lock_t *lock) {
 int myTurn = fetchAndAdd(&lock->ticket);
 while (lock->turn != myTurn)
 ;
}

void unlock(lock_t *lock) {
 lock->turn = lock->turn + 1;
}

This ensures progress for all threads.

28.13 A Simple Approach: Just Yield, Baby

Yield is simply a system call that moves the caller from the running state to the ready state, and thus promotes another thread to running. Thus, the yielding thread essentially deschedules itself.

Still costly: context switches.
Still unfair: endless yield loop.

28.14 Using Queues: Sleeping Instead Of Spinning

The real problem with our previous approaches is that they leave too much to chance.

Solaris provides two calls: park() to put a calling thread to sleep, and unpark(threadID) to wake a particular thread as designated by threadID.

typedef struct __lock_t {
 int flag;
 int guard;
 queue_t *q;
} lock_t;

void lock_init(lock_t *m) {
 m->flag = 0;
 m->guard = 0;
 queue_init(m->q);
}

void lock(lock_t *m) {
 while (testAndSet(&m->guard, 1) == 1)
 ; // acquire guard lock by spinning
 if (m->flag == 0) {
 m->flag = 1; // lock is acquired
 m->guard = 0;
 } else {
 queue_add(m->q, gettid());
 setpark();
 m->guard = 0;
 park();
 }
}

void unlock(lock_t *m) {
 while (testAndSet(&m->guard, 1) == 1)
 ; // acquire guard lock by spinning
 if (queue_empty(m->q))
 m->flag = 0; // let go of lock; no one wants it
 else
 unpark(queue_remove(m->q)); // hold lock
 // (for next thread!)
 m->guard = 0;
}

29 Lock-based Concurrent Data Structures

29.1 Concurrent Counters

Approximate counting: record counter values locally, and periodically transfer them to the global counter.

29.2 Concurrent Linked Lists

A hand-over-hand linked list may not be faster than the simple single lock approach, as the overhead of acquiring and releasing every node along the traversal path is high.

29.3 Concurrent Queues

29.4 Concurrent Hash Table

30 Condition Variables

30.1 Definition and Routines

A condition variable is an explicit queue that threads can put themselves on when some state of execution (i.e., some condition) is not as desired (by waiting on the condition); some other thread, when it changes said state, can then wake one (or more) of those waiting threads and thus allow them to continue (by signaling on the condition).

int pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t *mutex);
int pthread_cond_signal(pthread_cond_t *cond);

wait() unlocks a mutex (assumed to be locked) and put the calling thread to sleep; it re-acquires the lock before returning.

int done = 0;
pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t c = PTHREAD_COND_INITIALIZER;

void thr_exit() {
 pthread_mutex_lock(&m);
 done = 1;
 pthread_cond_signal(&c);
 pthread_mutex_unlock(&m);
}

void thr_join() {
 pthread_mutex_lock(&m);
 while (done == 0)
 pthread_cond_wait(&c, &m);
 pthread_mutex_unlock(&m);
}

Some questions:

Why is the done state needed?

If the child runs immediately and calls thr_exit() immediately, then although the child will signal, there is no thread asleep. When the parent calls wait(), it will be stuck.

Why is the mutex needed?

The child might change the state before the parent goes to sleep, and the parent will sleep forever. If there is a mutex, the child can only alter the state after the parent goes to sleep (and thus releasing the mutex).

Always hold the lock while signaling!

30.2 The Producer/Consumer (Bounded Buffer) Problem

Thanks to Mesa semantics, a simple rule to remember with condition variables is to always use while loops.

30.3 Covering Conditions

pthread_cond_broadcast(): waking up all waiting threads; downside: negative performace impact.

Read Phenomena and Isolation Levels

liang2kl@outlook.com (Liang Yesheng) — Thu, 05 May 2022 23:11:19 +0800

Reference: https://en.wikipedia.org/wiki/Isolation_(database_systems)

Isolation is typically defined at database level as a property that defines how or when the changes made by one operation become visible to others.

Read phenomena

Dirty reads

A dirty read (aka uncommitted dependency) occurs when a transaction is allowed to read data from a row that has been modified by another running transaction and not yet committed.

Non-repetable reads

A non-repeatable read occurs when, during the course of a transaction, a row is retrieved twice and the values within the row differ between reads.

Phantom reads

A phantom read occurs when, in the course of a transaction, new rows are added or removed by another transaction to the records being read.

Isolation levels

Of the four ACID properties in a DBMS (Database Management System), the isolation property is the one most often relaxed.

For many database applications, the majority of database transactions can be constructed to avoid requiring high isolation levels (e.g. SERIALIZABLE level), thus reducing the locking overhead for the system.

Serializable

The execution of concurrent SQL-transactions at isolation level SERIALIZABLE is guaranteed to be serializable.

When using non-lock based concurrency control… And also range-locks must be acquired when a SELECT query uses a ranged WHERE clause, especially to avoid the phantom reads phenomenon.

Snapshot isolation

snapshot isolation is a guarantee that all reads made in a transaction will see a consistent snapshot of the database (in practice it reads the last committed values that existed at the time it started), and the transaction itself will successfully commit only if no updates it has made conflict with any concurrent updates made since that snapshot.

Repeatable reads

Range-locks are not managed, so phantom reads can occur.

Read committed

Read locks are released as soon as the SELECT operation is performed, so the non-repeatable reads phenomenon can occur in this isolation level.

Read uncommitted

No read locks. Dirty reads are allowed, so one transaction may see not-yet-committed changes made by other transactions.

Concurrency Control for Database Transactions

liang2kl@outlook.com (Liang Yesheng) — Mon, 11 Apr 2022 23:27:56 +0800

来自 DATABASE SYSTEMS: The Complete Book

Serial and Serializable Schedules

Serial schedule: no mixing of actions from different transactions.

Serializable schedule: if there is a serial schedule S’ such that for every initial database state, the effects of S and S’ are the same.

The details of the transactions do matter, but it is not realistic for the scheduler to concern itself with the details of computation undertaken by transactions.

We only care about the reads $r_T(X)$ and writes $w_T(X)$ performed by the transaction $T$.

Conflict-Serializability

Actions that conflict (i.e. their order may not be swapped):

Two actions of the same transaction.
Two writes of the same database element by different transactions.
A read and a write of the same database element by different transactions.

In other words, for actions from different transactions, they conflict when:

They involve the same database element, and
At least one is a write.

Conflict-equivalent: two schedules can be turned one into the other by a sequence of nonconflicting swaps of adjacent actions.

Conflict-serializable: the schedule is conflict-equivalent to a serial schedule

conflict-serializability $\Rightarrow$ serializability

Precedence: if there are actions $A_1$ of $T_1$ and $A_2$ of $T_2$, such that:

$A_1$ is ahead of $A_2$ in the schedule $S$,
Both $A_1$ and $A_2$ involve the same database element, and
At least one of $A_1$ and $A_2$ is a write action.

then we say that $T_1$ takes precedence over $T_2$ in $S$ ($T_1<_ST_2$).

Any conflict-equivalent serial schedule must have $T_1$ before $T_2$.

If the precedence graph is acyclic, then the schedule is conflict-equivalent.

Proof: for $n$, arrange the schedule by (Actions of $T_i$)(Actions of the other $n-1$ transactions) where $T_i$ is one node without an in arc.

Enforcing Serializability by Locks

The use of lock:

Consistency of Transactions: Actions and locks must relate in the expected ways:
1. A transaction can only read or write an element if it previously was granted a lock on that element and hasn’t yet released the lock.
2. If a transaction locks an element, it must later unlock that element.
Legality of Schedules: Locks must have their intended meaning: no two transactions may have locked the same element without one having first released the lock.

The two-phase locking condition than can ensure conflict-serializability:

In every transaction, all lock actions precede all unlock actions.

A transaction that obeys the 2PL condition is said to be a two-phase-locked transaction, or 2PL transaction.

Proof: for $n$, arrange the schedule by (Actions of $T_i$)(Actions of the other $n-1$ transactions) where $T_i$ is the transaction with the first unlock action $u_iX$.

The risk of deadlock:

Locking Systems With Several Lock Modes

Lock modes:

shared
exclusive

The compatibility matrix:

	Request S	Request X
Currently S	Yes	No
Currently X	No	No

The deadlock problem caused by upgrading locks:

Avoid the problem with a third lock mode: update locks.

An update lock $ul_i(X)$ gives transaction $T_j$ only the privilege to read X, not to write X;
Only the update lock can be upgraded to a write lock later; a read lock cannot be upgraded.

The compatibility matrix:

	Request S	Request X	Request U
Currently S	Yes	No	Yes
Currently X	No	No	No
Currently U	No	No	No

The columns for U and S locks are the same, and the rows for U and X locks are the same.

And now:

An Architecture for a Locking Scheduler

The architecture discussed here: the scheduler insert and release locks.

Part 1: inserts appropriate lock actions ahead of all database-access operations
Part 2: for received action,
1. if the issuing transcation is already delayed, then delay this action
2. otherwise,
  1. if the action is db access (the required locks are already been granted), execute it
  2. if is lock action
    1. if the lock can be granted: modify the lock table
    2. otherwise, request the lock and delay
When a transcation commits or aborts, Part 1 releases all locks held by the transaction; if any transactions are waiting for any of these locks, notify Part 2
Part 2 checks which actions can be executed now

The lock table entry:

The group mode: the most stringent conditions
The waiting bit: at least one transaction is waiting
A list of transactions that hold or waiting for the lock

Hierarchies of Database Elements

Warning locks: useful for hierarchical structure.

	IS	IX	S	X
IS	Yes	Yes	Yes	No
IX	Yes	Yes	No	No
S	Yes	No	Yes	No
X	No	No	No	No

The phantom tuple: one that should have been locked but wasn’t, because it didn’t exist at the time the locks were taken.

Solution: acquire an X lock on the entire relation.

The Tree Protocol

The problem: only one transaction that is not read-only can access the B-tree at any time, because the root node must be locked (at least with an update lock).

Solution: as soon as a transaction moves to a child of the root and observes the (quite usual) situation that rules out a rewrite of the root, we would like to release the lock on the root; but it violates 2PL, so a new protocol is needed.

The tree protocol:

The schedule is legal (i.e. does not violate lock schemes).
A transaction’s first lock may be at any node of the tree.
Subsequent locks may only be acquired if the transaction currently has a lock on the parent node.
Nodes may be unlocked at any time.
A transaction may not relock a node on which it has released a lock, even if it still holds a lock on the node’s parent.

Conclusion: the precedence graph must always be acyclic if the tree protocol is obeyed. Proof:

If two transactions lock several elements in common, then they are all locked in the same order.
If $T_i$ locks the root before $T_j$, then $T_i$ locks every node in common with $T_j$ before $T_j$ does.

Concurrency Control by Timestamps

Two approaches to generate timestamp:

use the system clock
the scheduler maintaining a counter

For the database element $X$:

$RT(X)$: the read time of $X$
$WT(X)$: the write time of $X$
$C(X)$: the commit bit fot $X$, true when the most recent transaction to write $X$ has already commited.

Two kinds of unrealizable behaviours:

The problem with dirty data:

$T$ better delays until $U$ commits.

The commit bit will be false.

The Thomas write rule: the writes can be skipped when a write with a later write-time is already in place (read intention for value written by T is too-late, as the value is written by a logically latter transaction).

The scheduler, in response to a read or write request from a transaction T has the choice of:

Granting the request,
Aborting T and restarting T with a new timestamp
Delaying T and later deciding whether to abort or grant the request.

The rules for timestamp-based scheduling:

The scheduler receives a request $r_T(X)$.
1. $TS(T)\ge WT(X)$: physically realizable.
  1. $C(X)$ is true: grant the request; set $RT(X)$ if $TS(T)>RT(X)$.
  2. $C(X)$ is false: delay until becomes true, or that transaction aborts (to avoid dirty reads).
2. $TS(T)<WT(X)$: physically unrealizable, rollback $T$.
The scheduler receives a request $w_T(X)$.
1. $TS(T) \ge RT(X)$ and $TS(T) > WT(X)$: physically realizable and must be performed (?).
  1. Write $X$,
  2. Set $WT(X) := TS(T)$, and
  3. Set $C(X) := \texttt{false}$.
2. $TS(T) \ge RT(X)$ but $TS(T) < WT(X)$: physically realizable, and
  1. If $C(X)$ is true, ignore the write by T (the thomas write rule);
  2. otherwise, delay T until the previous write operation commits or aborts.
3. $TS(T) < RT(X)$: physically unrealizable, roll back T.
The scheduler receives a request to commit T: find all elements written by T, and set $C(X) := \texttt{true}$; the delayed transactions are allowed to proceed.
The scheduler receives a request to abort T, or to rollback: check all delaying transcation waiting for any element that T wrote to see if they can proceed.

The use of multiversion timestamps: to provide an appropriate version for a read action (the version of X written immediately before T theoretically executed), even if the latest version is written after the transcation.

Comparision of locking and timestamp schemes:

Generally, timestamping is superior in situations where either most transactions are read-only, or it is rare that concurrent transactions will try to read and write the same element. In high-conflict situations, locking performs better.

Locking will frequently delay transactions as they wait for locks.
If concurrent transactions frequently read and write elements in common, then rollbacks will be frequent in a timestamp scheduler.

Concurrency Control by Validation

Validation differs from timestamping principally in that the scheduler maintains a record of what active transactions are doing, rather than keeping read and write times for all database elements.

Denote the write set and read set as $WS(T)$ and $RS(T)$. Transactions are executed in three phases:

Read. The transaction reads from the database all the elements in its read set, and also computes (locally) the results it is going to write.
Validate. The transaction compares its read and write sets with those of other transactions; rollback if fails.
Write. The transaction writes to the database the values for the elements in its write set.

Thus, the validation-based scheduler has an assumed serial order of the transactions to work with, and it bases its decision to validate or not on whether the transactions’ behaviors are consistent with this serial order.

The scheduler maintains three sets:

START: the set of transactions that have started, but not yet completed validation.
VAL: the set of transactions that have been validated but not yet finished the writing in phase 3.
FIN: the set of transactions that have completed phase 3.

Some examples:

A later transaction might read a value before an earlier transaction writes the value.

A later transaction might write before a validated, earlier transaction, as the write of the later one might occur earlier.

Summarization: to validate a transaction T:

Check that $RS(T) \cap WS(U) = \emptyset$ for any previously validated U that did not finish before T started, i.e., if $FIN(U) > START(T)$.
Check that $WS(T) \cap WS(U) = \emptyset$ for any previously validated U that did not finish before T validated, i.e., if $FIN(U) > VAL(T)$.

Comparison of Three Concurrency-Control Mechanisms

Storage: all schemes (can be optimized to) use storage space proportional to the sum over all active transactions of the number of database elements the transaction accesses.

Performace:

Locking delays transactions but avoids rollbacks, even when interaction is high.
Timestamps and validation do not delay transactions, but can cause them to rollback.
If interference is low, then neither timestamps nor validation will cause many rollbacks, and may be preferable to locking because they generally have lower overhead than a locking scheduler.
When a rollback is necessary, timestamps catch some problems earlier than validation, which always lets a transaction do all its internal work before considering whether the transaction must rollback.

总结

同时执行多个事务时，需要保证每个事务的原子性，同时还必须保持一定的先后次序。

对 schedule 最严格的要求是串行性（serial），当然这并不能做到并发。退一步，我们不需要严格保证不同事务处理的时间不互相重叠，但需要保证最终的效果和串行执行一致，即“可串行化”（serializable schedule）。当然，这个条件覆盖的范围太大，很难判断 schedule 是否满足可串行化条件。因此，我们需要增加更严格的条件，使得我们可以有简单的方法判断。当然，这样一来，满足条件的 schedule 只是可串行化 schedule 的一个真子集。

第一大类办法是使用锁，并加上 2PL 条件，使得 schedule 满足“冲突可串行化”（confilict-serializable）。上锁有两个需要解决的问题：锁的类型及其兼容性，以及锁的粒度。

第二大类办法是“乐观的”（optimistic），即假设不会发生不可串行化的事件，仅当的确出现违反可串行化条件时采取措施。Optimistic 方法包括两种：by timestamp，即通过比较事务开始的时间与元素被读或写的时间，判断某个操作是否可以进行；by validation，即在验证阶段比较与之前事务的读写集合判断是否可以提交，验证成功后再写入数据库。

上锁的方法避免了重新执行，但事务会受到延迟，在冲突严重时较优；乐观方法由于可以进行一定操作，只在出现问题时取消或重新执行，因此延迟较低，但在冲突严重时会造成大量的重新执行而影响性能。

软件工程：The Missing Semester

liang2kl@outlook.com (Liang Yesheng) — Tue, 22 Mar 2022 23:01:03 +0800

要是让我总结一个“在清华体验不太好的课程列表”，软件工程一定位列其中。这并不意味着我不喜欢软工项目中的环境配置、CI/CD、单元测试、部署等等工作；相反，我在其中找到了很多乐趣——毕竟，我是一个爱折腾的人。

问题出在作用接近于 0 的文档上：对于很多依赖于详细的文档才能上手的工作，这门课几乎没有提供任何有用的文档。对于这些工作，课程组只提供了没有任何注释的“样例”让我们照猫画虎。虽然说面向 Google 是计算机专业最好的学习方式，但是将一堆东西扔给学生自学，还几乎不提供任何的引导，这是这门课最大的问题。虽然其中很多知识我以前都接触过，但是每当我站在没有开发经验的同学的角度上思考这些复杂的技术栈对于同学们来说意味着什么，就不禁感到愤怒。

在摸索了几天、踩了无数坑之后，我总算是把我们项目的代码部署到了软工提供的服务器上。在这里，我将把一些在软工平台上部署的经验写成文档，作为软工课程文档的补充。

By the way，“The Missing Semester”在这里有两个含义：一是致敬 CMU 的“The Missing Semester”课程，一是表达我对于软工试图仅用一学期就让我们成为全栈工程师的不满。在我看来，软工至少需要两个学期；在这两个学期中，教学团队的引导和同学们的开发应当是相辅相成的，而不能只是学生自己独自面对一个完整的、陌生的、无从下手的、令人恐惧的项目，即使可能有很多有开发经验的同学并不这么觉得。

感谢 @prnake 学长在 GitHub 上公开他们的项目 Quick-Red，下面的很多例子源于此项目。没有它，很多问题我根本无从下手。

创建项目

在软工平台上新建仓库

如果需要部署仓库内容到服务器上，必须要在软工平台（SECoder）上的 项目管理 - 仓库管理 中新建，否则之后无法使用 deployer 部署到提供的服务器上。

分支管理

仓库中应该有如下分支：

master（或 main）：主分支，用于部署生产环境
dev：开发分支，所有最新的改动合并到此分支，定期合并到 master 分支
其他开发分支（例如 feat/login）：开发某一新功能时新建的分支，开发完成后合并到 dev 分支

需要注意 master 和 dev 只能通过 merge request 由其他分支合并，不能直接 push。另外，新建开发分支时一定要从 dev 分支上新建，不能从其他开发分支上新建。

仓库配置

GitLab 中有几项设置对后续协作开发有不小的帮助，值得花点时间配置一下：

在 General - Merge request 中取消选择 Merge options 下的 Enable 'Delete source branch' option by default。课程需要保留开发过程中的分支，需要避免不小心删除分支的情况。
在 Repository - Default Branch 中将 Default Branch 设置为 dev，使得进行 merge request 时默认合并到 dev 分支。
在 Repository - Protected Branches 中添加 master 和 dev 都设置为受保护的分支，并禁止任何人直接 push 到这两个分支上。

增加 issue template 和 merge request template

在仓库目录下新建文件夹 .gitlab/issue_templates/，并在其中添加若干 Markdown 文件，这些文件将可用作新建 issue 时作为模版供选择。例如，针对 bug 的 issue：

<!-- Title 格式：[bug] Bug 描述 -->
## 复现过程

1.
2.

## 当前的行为
<!-- 当前版本存在的问题行为 -->

## 预期的行为
<!-- 正常应当有怎样的行为 -->

添加模版之后，在新建 issue 时可以选择其中之一作为模版，保证 issue 的规范和质量。

同理，可以为 merge request 添加模版，可以参考 Quick-Red 的模版。

CI/CD

CI/CD 简单来说就是在服务器上执行一系列命令，从而自动化地在每次提交代码之后完成测试、检查、构建等工作，并在需要时完成部署。

Stage 和 job

Stage 指的是 CI/CD 的不同阶段，用来完成不同阶段的工作，一般情况下顺序执行。你可以使用 GitLab 的 DAG 功能使得没有依赖关系的 stage 并行运行以加快速度，具体可以参考官方文档。

在软工项目中的 stage 通常包括：

pre：准备阶段，完成依赖库缓存的拉取和保存等
build：构建 Docker 镜像
test：单元测试、代码风格检查、上传代码质量报告（sonar）
deploy：将镜像部署到服务器上

在 .gitlab-ci.yml 开头声明 stage：

stages:
 - pre
 - build
 - test
 - deploy

需要注意的是，不同 stage 之间的环境是相互隔离的。比如，在前面的 stage 中如果安装了项目依赖（如 npm install），在后面的 stage 中仍然需要安装这些依赖。在后面将会介绍加快这一过程的方法。

Job 指的是 stage 内部的若干个任务单元，执行具体的命令，同一个 stage 的所有 jobs 是并行执行的，环境也是相互隔离的。

Job 一些常用的属性有：

stage：指定这个 job 所属的 stage；若不指定，默认为 test
script：这个 job 执行的命令行命令
before_script：在执行 script 之前执行的命令，一般用于环境配置
after_script：在执行 script 之后执行的指令，比如使用 sonar-scanner 上传在 script 中得到的覆盖率报告
only 和 except：用于指定运行此 job 的条件，比如生产环境的部署对应的 job 只在 master 分支上进行

具体的用法可以参考 GitLab 文档。

Hidden jobs 与继承

如果多个 job 有大量相同的配置，可以使用继承的方法避免重复编写相同配置。比如，我们对 Node.js 项目分别进行单元测试和代码风格检查，而它们都需要安装相同的依赖、都属于 test stage。

首先，定义一个以 . 开头的 job，这个 job 为 hidden job，不会被执行：

.test:
 stage: test
 before_script:
 - npm config set registry http://mirrors.cloud.tencent.com/npm/
 - npm install

第一条命令用于将 npm 使用的源设置为国内腾讯云镜像，这将大大加快加载速度。

然后，在真正的 job 中，使用 extends 继承此 job：

lint-test:
 extends: .test
 script:
 - npm run lint

unit-test:
 extends: .test
 script:
 - npm run test:ci

这两个 job 因此拥有了与 .test 相同的 stage 和 before_script 属性。

你还可以继承多个 hidden job，具体行为可以查阅有关文档。

加快速度：cache

对于使用如 Node.js 这样的需要安装大量依赖库的项目，如果在每个 stage 中、每次 CI/CD 都重新安装一次依赖，CI/CD 的效率将会非常低。对这个问题，我们可以使用 GitLab 的 cache 功能将这些依赖缓存起来供重复利用。

因为每个 job 的环境都是独立的，因此每个 job 都需要定义缓存。我们使用 hidden job 完成统一配置：

.cache:
 cache:
 key: ${CI_COMMIT_REF_SLUG}
 paths:
 - node_modules/
 - package-lock.json
 policy: pull

其中，key 使用分支名（${CI_COMMIT_REF_SLUG}），即不同的分支使用不同的缓存，而同一分支下的所有 job 共享这份缓存。paths 指定了缓存项的路径，这里我们将 Node.js 的依赖文件缓存起来。policy 设置为 pull 的目的是，每次只从服务器上拉取缓存，而不需要在结束之后将此缓存上传到服务器上。这很重要，因为我们不希望每个 job 都重复地上传相同的缓存。

我们在 pre 阶段中添加一个 job 用来更新缓存：

node-cache:
 stage: pre
 extends: .cache
 cache:
 policy: pull-push
 script:
 - npm config set registry http://mirrors.cloud.tencent.com/npm/
 - npm install

注意到，我们将 cache policy 更改为了 pull-push，这是因为我们需要将此缓存上传到服务器上供其他 job 和 pipeline 使用。

然后，在需要用到此缓存的 job 中，继承 .cache 即可：

build:
 stage: build
 extends: .cache
 script:
 - npm config set registry http://mirrors.cloud.tencent.com/npm/
 - npm install
 - ...

这个 job 将会从服务器上拉取最新的缓存，从而无需重新下载。

当然，以防万一，还是加上一句 npm install，虽然正常情况下这条命令并不会从网络上下载依赖，因为在 pre 阶段我们已经下载好了需要的依赖。

Sonar 与单元测试的配置

课程要求使用 Sonar 对源代码进行静态分析。既然是静态分析，那么 Sonar 需要测试工具执行测试生成测试报告，才能进行分析。因此，测试与报告的流程为：

测试工具执行测试，并输出测试结果
使用 sonar-scanner 对测试结果和源代码进行分析并上传分析结果

使用测试工具生成测试报告

Sonar 需要提供 xml 格式的测试报告，对于不同语言、框架的方法不同，可以到搜索引擎上搜索生成报告的方法。在这里分享一下我们项目使用的框架（Django、React（create-react-app）、Go）适用的方法。

Django

如果直接使用 pytest，可以参考 Quick-Red。

如果使用 Django 自带的测试框架 django.test：

需要安装以下依赖：

pytest
coverage
unittest-xml-reporting

在 settings.py 中，添加如下配置：

# 指定 test runner 为 xmlrunner
TEST_RUNNER = 'xmlrunner.extra.djangotestrunner.XMLTestRunner'
# 指定报告输出目录
TEST_OUTPUT_DIR = 'xunit-reports/'
# 指定报告文件名
TEST_OUTPUT_FILE_NAME = 'xunit-result.xml'

然后，运行

python -m coverage run --source path1,path2,...,pathn manage.py test
python -m coverage xml -o coverage-reports/coverage.xml

其中，path1、path2 等替换为包括在覆盖率报告中的文件/文件夹路径。

这样，分别生成了测试报告 xunit-reports/xunit-result.xml 和覆盖报告 coverage-reports/coverage.xml。

这些命令仅完成了最基本的测试报告的配置。关于可选的命令行参数，请参考官方文档。

React（create-react-app）

create-react-app 预置了 Jest，无需手动安装。

安装 jest-sonar：

npm install --save-dev jest-sonar

在 package.json 的 scripts 中添加：

"test:ci": "CI=true react-scripts test --coverage --reporters=jest-sonar --collectCoverageFrom=src/**/*.js"

然后，执行：

npm run test:ci

这样，在 coverage 目录下会生成测试报告。

这条命令仅完成了最基本的测试报告的配置。关于可选的命令行参数，请参考官方文档。

Golang

执行

go test -cover -race -v -coverprofile=coverage.out ./...

配置 sonar-project.properties 文件

我们通过项目根目录下的 sonar-project.properties 文件对 Sonar 进行配置。一些配置如下：

# 源代码所在目录
sonar.sources=src
# 包含测试文件的路径，sonar 将会寻找其中的所有测试文件
sonar.tests=src
# 包含在测试分析内的测试文件
sonar.test.inclusions=src/**/__tests__/*.test.js
# 排除在所有分析之外的路径
sonar.exclusions=node_modules/**,coverage/**
# 覆盖率分析时排除在外的路径
sonar.coverage.exclusions=src/utils/**/*.js

另外，还需要提供已经得到的测试报告的路径。对于 JavaScript：

sonar.javascript.lcov.reportPaths=coverage/lcov.info
sonar.testExecutionReportPaths=coverage/sonar-report.xml

对于使用 coverage 进行分析的 Python 代码：

sonar.python.coverage.reportPaths=coverage-reports/coverage.xml
sonar.python.xunit.reportPath=xunit-reports/xunit-result.xml

对于 Go：

sonar.go.coverage.reportPaths=coverage.out

这里路径需要改成上面一步所设置的覆盖报告和测试报告的路径。

设置 CI

在 CI 中，定义一个 job 用来执行测试和上传报告：

unit-test:
 ...
 script:
 # 执行测试的命令
 after_script:
 - SUFFIX=$RANDOM
 - curl "http://10.0.0.11/sonar-scanner.tar.gz" -s -o "/tmp/sonar-$SUFFIX.tar.gz"
 - tar -xf "/tmp/sonar-$SUFFIX.tar.gz" -C /opt
 - /opt/sonar-scanner/bin/sonar-scanner

Dockerfile

将代码部署在服务器上需要配置环境、编译应用、安装应用、开启服务等一系列操作，而 Docker 使得我们可以预先完成或指定这些操作，从而能够实现自动部署；Dockerfile 就是我们定义这些操作的地方。

在软工平台上使用 deployer 构建、上传 Docker 镜像，并使用此镜像进行部署。大概的逻辑是：

通过 Dockerfile 内的一系列语句预先配置好所需的环境并打包成镜像
将镜像上传到软工平台的镜像站上
部署时，拉取之前构建好的镜像，并在一个容器中运行，这样就完成了部署

这个过程在 .gitlab-ci.yml 中使用多个 job 完成：

# 构建 Docker 镜像
build:
 stage: build
 script:
 - export BUILD_IMAGE_NAME=$CI_REGISTRY_IMAGE
 - export BUILD_IMAGE_TAG=$CI_COMMIT_REF_SLUG
 - export BUILD_IMAGE_USERNAME=$CI_REGISTRY_USER
 - export BUILD_IMAGE_PASSWORD=$CI_REGISTRY_PASSWORD
 - deployer build

# 使用镜像部署
deploy:
 stage: deploy
 script:
 - deployer dyno replace $CI_PROJECT_NAME "$CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG" "$REGISTRY_USER" "$REGISTRY_PWD"

build 的多个 export 指定了上传时使用的镜像名、tag、使用的用户名和密码；deployer build 命令完成了 (1) 使用 docker build 根据 Dockerfile 进行镜像构建，(2) 将镜像上传到平台上；deploy 工作将 build 中上传的镜像部署到服务器上。这样就完成了整个部署过程。

所以，我们需要做的，就是在 Dockerfile 中描述配置容器的过程。

配置 Dockerfile

首先，指定一个“基础镜像”，即使用一个预先配置好的镜像，在这个镜像的基础上配置我们的镜像。比如，对于 Node.js 应用，我们使用官方的 node 镜像：

FROM node:latest

在这之后，我们就在一个配置好了 Node.js 的环境中了。

接下来，无非就是执行一系列语句来编译我们的应用，并将其拷贝到合适的位置。这部分内容可以参考软工课程给出的样例文件。

比如，编译 React 应用：

# 第一个阶段：使用 node 镜像编译 React 应用；将此阶段命名为 build
FROM node:latest as build

# 设置环境变量 HOME
ENV HOME=/opt/app

# 将工作目录设为 HOME，并拷贝当前目录（项目代码）到 HOME 中
WORKDIR $HOME
COPY . $HOME

# 安装依赖
RUN npm config set registry http://mirrors.cloud.tencent.com/npm/
RUN npm install
# 执行 React 的 build，获得网页文件
RUN npm run build

# 第二个阶段：配置使用 nginx 容器，使得可以通过 HTTP 访问
FROM nginx:1.19

# 从第一个阶段（build）拷贝文件
# 拷贝编译后的网页文件到 nginx 的目录下
COPY --from=build /opt/app/build /usr/share/nginx/html
# 拷贝 nginx 配置文件（储存在源代码中）
# 对于 nginx 的配置和使用，你可能需要查阅相关文档，也可以直接使用已有的样例
COPY --from=build /opt/app/nginx.conf /etc/nginx/nginx.conf

# 暴露容器的 80 端口
EXPOSE 80

# 这里定义了容器启动时执行的命令（开启 Nginx 服务），注意并不是在构建镜像时执行
CMD ["nginx", "-g", "daemon off;"]

有关 Dockerfile 的语句，可以参考 Docker - 从入门到实践（中文）或 Dockerfile 官方文档（英文）。

在 CI 中向 Dockerfile 传递环境变量

有时候，我们需要向 Dockerfile 中传递环境变量，比如使用不同的环境部署生产环境和开发环境的代码。但是，deployer 并不会向 docker build 传递环境变量，因此在 Dockerfile 中是无法获取到我们希望传递的环境变量的。

一种不太优雅的解决办法是：使用不同的 Dockerfile，直接在 Dockerfile 中用 ENV 语句设置环境变量。

比如，当前项目根目录下有两个文件：用于生产环境的 Dockerfile，以及用于开发环境的 Dockerfile-dev，它们的唯一区别是，Dockerfile-dev 设置了一个名为 REACT_APP_IS_DEV_SERVER 的环境变量，在我们的 React 应用中需要根据此环境变量判断所处的是否为生产环境：

ENV REACT_APP_IS_DEV_SERVER=true

但是，因为 deployer 无法指定构建镜像所使用的 Dockerfile 而只能使用文件名为 Dockerfile 的文件，我们需要将文件更名为 Dockerfile。在 CI 中，分别为生产环境和开发环境定义 build 的 job：

build:
 extends: .build
 only:
 - master

build-dev:
 extends: .build
 before_script:
 - rm Dockerfile
 - mv Dockerfile-dev Dockerfile
 except:
 - master

我们用 Dockerfile-dev 替代了 Dockerfile，实现了根据条件传递环境变量的目的。

数据库配置

对于需要使用 Client/Server 通信模式数据库的情况，需要部署一个独立的数据库服务器。下面以 MySQL 为例。

对于其他数据库，过程大同小异，只需要完成：

创建仓库并设置好 CI/CD
将持久卷挂载到数据库储存文件的位置
设置好数据库访问的用户名和密码、创建数据库、授予权限等初始化工作
在后端上配置好访问数据库的信息

建立仓库、配置持久卷和端口

在软工平台上创建数据库所用的仓库，并在软工平台 项目管理 - 部署管理 - 持久储存 中新建一个持久卷。

之后，在上方 容器 中打开数据库容器，在 挂载 一栏中选择此持久卷，挂载点设置为 /var/lib/mysql。这是因为 MySQL 所有的数据库文件均储存在此目录下，将持久卷挂载到此目录上可以保持数据库文件不因重新部署而丢失。

在容器的 端口 中添加 MySQL 使用的 3306 端口。

配置 CI/CD

.gitlab-ci.yml 和 Dockerfile 直接使用 Quick-Red 的配置即可。

初始化数据库

初次部署完成后，需要进入容器初始化 MySQL。在软工平台数据库容器下打开 管理 - 终端，进入容器。

然后，执行 mysql 命令进入 MySQL。

首先，设置数据库 root 用户的密码（<password_root> 设置为你想要设置的密码）：

ALTER USER 'root'@'localhost' IDENTIFIED BY '<password_root>';

接下来，创建供外部访问的账号（<password_remote> 设置为外部访问时使用的密码）：

CREATE USER 'django'@'%' IDENTIFIED BY '<password_remote>';

在这里，'django'@'%' 的意思是，创建一个从任意 IP 访问（%）、用户名为 django 的账户。django 可以设置为你想设置的用户名。注意用户名尽量不要使用 root，会产生冲突。然后，创建一个空的数据库（db_name 更改为你想要设置的名称）：

CREATE DATABASE db_name;

将此数据库的访问权限授予远程用户（注意修改 db_name 和 django）：

GRANT ALL PRIVILEGES ON db_name.* TO 'django'@'%';

最后，更新权限：

FLUSH PRIVILEGES;

这样，我们就可以在后端服务器上访问此数据库了。

配置 Django

这里以 Django 为例配置使用上面已经配置好的 MySQL 数据库。

在软工平台中，创建一个“配置”，并上传一个包含数据库访问信息的 JSON 文件：

{
 // 在 MySQL 中新建的数据库名
 "MYSQL_NAME": "db_name",
 // 配置数据库时设置的远程访问用户名
 "MYSQL_USER": "root",
 // 配置数据库时设置的远程访问密码
 "MYSQL_PASSWORD": "<password_remote>",
 // 数据库服务器的本地地址，在软工平台上可以找到
 "MYSQL_HOST": "example-app.secoder.local",
 // MySQL 端口
 "MYSQL_PORT": 3306
}

然后，在软工平台的后端容器中将此文件（配置）挂载到源代码所在的子目录下（这里你可能需要查看你的 Dockerfile 来获取容器中源代码所在的目录）。注意，这个操作会将此目录的所有内容替换为上面配置的内容，因此不要将其挂载到源代码根目录下，也不要将其挂载到任何一个原有的子目录下。

在 settings.py 中，读取配置文件（这里，我们把配置文件目录挂载到了代码目录/config，文件名为 ‌config.json）：

if os.path.isfile("config/config.json"):
 with open("config/config.json", "r") as file:
 env = json.load(file)

然后，将 DATABASES 更改为：

DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.mysql',
 'NAME': env["MYSQL_NAME"],
 'USER': env["MYSQL_USER"],
 'PASSWORD': env["MYSQL_PASSWORD"],
 'HOST': env["MYSQL_HOST"],
 'PORT': env["MYSQL_PORT"],
 'OPTIONS': {'charset': 'utf8mb4'},
 },
}

至此，Django 就可以使用 MySQL 服务器了。注意，你应该避免在开发环境中使用生产环境的 MySQL 服务器，这个问题可以通过挂载不同的配置文件解决。

Operating Systems: Three Easy Pieces 学习笔记（四）

liang2kl@outlook.com (Liang Yesheng) — Sun, 06 Mar 2022 17:24:23 +0800

13 The Abstraction: Address Spaces

13.3 The Address Space

The address space of a process contains all of the memory state of the running program (e.g. code, stack, heap…)

13.4 Goals

Goals of the design:

Transparency
Efficiency
Protection

14 Interlude: Memory API

15 Mechanism: Address Translation

15.3 Dynamic (Hardware-based) Relocation

When a program is loaded, the OS sets base and bounds registers.

physical address = virtual address + base

15.4 Hardware Support: A Summary

The required hardware support:

privileged mode
base/bounds registers
translate virtual address and check if within bounds
privileged instructions to update base/bounds registers
privileged instructions to register exception handlers
ability to raise exceptions

15.6 Summary

The problem: all the space between stack and heap is wasted (called internal fragmentation)

16 Segmentation

16.1 Segmentation: Generalized Base/Bounds

Segment: contiguous portion of the address space of a particular length.

Segmentation allows the OS to place segments in differnet parts of physical memory.

The hardware structure in the MMU: three base and bounds register pairs.

16.2 Which Segment Are We Referring To?

The explicit approach: chop up the address space into segments based on the top few bits of the virtual address.

The implicit approcah: the hardware determins the segment by noticing how the address was formed.

16.3 What About The Stack?

The difference: it grows backwords.

Use a bit in the hardware to indicate the sign of the offset.

16.5 Fine-grained vs. Coarse-grained Segmentation

16.6 OS Support

The operation to support segmentation:

On context switch: save and store segment registers
Support growing heap segment (sbrk())
Handle external fragmentation (physical memory quickly becomes full of little holes of free space, making it difficult to allocate new segments, or to grow existing ones)

17 Free-Space Management

17.1 Assumptions

Internal fragmentation: the allocator hands out chunks of memory bigger than that requested

17.2 Low-level Mechanisms

Splitting and Coalescing

Coalescing: coalesce spliited fragments when they are contiguous

Tracking The Size Of Allocated Regions

Most allocators store a little bit of extra information in a header block which is kept in memory to keep track of the size of the allocated region.

typedef struct {
 int size;
 int magic; /* for integrity checking */
} header_t;

Embedding A Free List

Growing The Heap

17.3 Basic Strategies

Unfortunately, because the stream of allocation and free requests can be arbitrary (after all, they are determined by the programmer), any particular strategy can do quite badly given the wrong set of inputs.

Best Fit

The best chunk: the smallest in candidates.

Cost: heavy performance overhead

Worst Fit

The opposite to the best fit strategy.

First Fit

Returns the first qualified block.

Problem: pollution at the beginning of the free list; approach: address-based ordering.

Advantage: speed.

Next Fit

Keep an eatra pointer to the last-searched location; the blocks are distributed more evenly than first-fit strategy.

17.4 Other Approaches

Segregated Lists

Keep a separate list just to manage objects of some popular sizes; all other requests are forwarded to a more general memory allocator.

Buddy Allocation

The binary buddy allocator: free memory is thought of as one big space of $2^N$; the search for free space recursively divides free space by two.

Suffers from internal fragmentation.

Free process: recursively coalescing blocks upwards.

Simple to determine the buddy of a particular block: each buddy pair (at the same level) only differs by a single bit.

18 Paging: Introduction

18.1 A Simple Example And Overview

Page table: a per-process data structure to store address translations.

18.3 What’s Actually In The Page Table?

Some bits:

valid bit (supporting a sparse address space; x86 doesn’t have it)
protection bit
present bit (whether a page has been swapped out)
dirty bit (whether a page has been modified)
refence bit (whether a page has been accessed)

Don’t worry: it deﬁnitely gets worse, because the mechanisms we are about to introduce only complicate this already complex machinery. Sorry!

19 Paging: Faster Translations (TLBs)

When we want to make things fast, the OS usually needs some help. And help often comes from the OS’s old friend: the hardware.

Translation-lookaside buffer (or TLB)

19.3 Who Handles The TLB Miss?

CISC: uses hardware-managed TLBs
RISC: uses software-managed TLBs

The software approach: more flexible and simple; need to avoid infinite chain of TLB misses.

19.4 TLB Contents: What’s In There?

The TLB typically has 32, 64 or 128 entries, and is fully associated (any given translation can be anywhere in the TLB).

19.5 TLB Issue: Context Switches

Some hardware systems provide an address space identifier (ASID) in the TLB to identify the associated process.

19.6 Issue: Replacement Policy

One common approach is to evict the least-recently-used or LRU entry.

Another typical approach is to use a random policy, which evicts a TLB mapping at random.

19.7 A Real TLB Entry

How to handle ‘ASID overflow’?

In MIPS, some TLB slots can be reserved for the OS.

20 Paging: Smaller Tables

Here, the problem should be clear: simple linear (array-based) page tables are too big.

20.2 Hybrid Approach: Paging and Segments

Whenever you have two reasonable but different approaches to something in life, you should always examine the combination of the two to see if you can obtain the best of both worlds.

Operating Systems: Three Easy Pieces 学习笔记（三）

liang2kl@outlook.com (Liang Yesheng) — Sat, 26 Feb 2022 13:26:41 +0800

4 The Abstraction: The Process

Process: a running program

4.2 Process API

create
destroy
wait
miscellaneous control
status

4.4 Process States

A process can be in one of three states:

running: executing instructions
ready: ready to run but the OS has chosen not to run at this moment
blocked: a process has performed some kind of operation that makes it not ready to run until some other event takes place

5 Interlude: Process API

5.4 Why? Motivating The API

The separation of fork() and exec() is essential in building a UNIX shell, because it lets the shell run code after the call to fork() but before the call to exec(); this code can alter the environment of the about-to-be-run program, and thus enables a variety of interesting features to be readily built.

5.5 Process Control And Users

The user, after entering a password to establish credentials, logs in to gain access to system resources (and as a result, can send signals to programs).

6 Mechanism: Limited Direct Execution

Use time sharing to achieve virtualization

Some challenges:

performance
control

6.1 Basic Technique: Limited Direct Execution

Direct execution: run the program directly on the CPU

6.2 Problem #1: Restricted Operations

The approach to restrict certain operations: introducing user mode (and kernel mode)

System calls allow the kernel to carefully expose certain key pieces of functionality to user programs, setting up a trap table for the hardware to jump to trap handlers

6.3 Problem #2: Switching Between Processes

The curx: how to regain control of the CPU?

A Cooperative Approach: Wait For System Calls

The OS regains control of the CPU by waiting for a system call or an illegal operation of some kind to take place.

A Non-Cooperative Approach: The OS Takes Control

A timer device can be programmed to raise an interrupt (timer interrupt) every so many milliseconds; when the interrupt is raised, the currently running process is halted, and a pre-configured interrupt handler in the OS runs.

Saving and Restoring Context

Two types of register saves/restores:

when timer interrupt occurs: the user registers are implicitly saved by the hardware to the kernel stack
when the OS decides to switch to another process: the kernel registers are explicitly saved by the software to the memory of the process structure (Still in the kernel mode so should kernel registers be saved/restored; the user registers are restored later during return-from-trap)

6.4 Worried About Concurrency?

OS might disable interrupts during interrupt processing (but can lead to lost of interrupts), and use locking to protect concurrent access to internal data structures.

7 Scheduling: Introduction

7.1 Workload Assumptions

Unrealistic assumptions:

each job runs for the same amount of time
all jobs arrive at the same time
once started, each job runs to completion
all jobs only use the CPU (i.e., they perform no I/O)
the run-time of each job is known (more unrealistic!)

7.2 Scheduling Metrics

Simplify with one single metric: turnaround time

$$ T_\mathrm{turnaround}=T_\mathrm{completion}-T_\mathrm{arrival} $$

In our case:

$$ T_\mathrm{turnaround}=T_\mathrm{completion} $$

7.3 First In, First Out (FIFO)

The First In, First Out scheduling, or First Come, First Served

Convoy effect: a number of relatively-short potential consumers of a resource get queued behind a heavyweight resource consumer.

7.4 Shortest Job First (SJF)

Shortest Job First: runs the shortest job first, then the next shortest, and so on; optimal.

Bad without assumption 2 (all jobs arrive at the same time)

7.5 Shortest Time-to-Completion First (STCF)

Relax assumption 3 (each job runs to completion)

The scheduler can preempt the current job; adding this to SJF, we get the Shortest Time-to-Completion First (STCF) or Preemptive Shortest Job First (PSJF) scheduler

7.6 A New Metric: Response Time

The response time:

$$ T_\mathrm{response}=T_\mathrm{firstrun}-T_\mathrm{arrival} $$

7.7 Round Robin

Round-Robin: instead of running jobs to completion, RR runs a job for a time slice (sometimes called a scheduling quantum) and then switches to the next job in the run queue

The length of the time slice is critical for RR; a trade-off between response time and the cost of context switching

The cost of context switch

When programs run, they build up a great deal of state in CPU caches, TLBs, branch predictors, and other on-chip hardware. Switching to another job causes this state to be flushed and new state relevant to the currently-running job to be brought in, which may exact a noticeable performance cost.

RR is pretty awful for turnaround time

More generally, any policy (such as RR) that is fair, i.e., that evenly divides the CPU among active processes on a small time scale, will perform poorly on metrics such as turnaround time.

7.8 Incorporating I/O

Relax assumption 4 (all jobs only use the CPU)

Overlap will occur if using STCF

7.9 No More Oracle

Relax our final assumption (the run-time of each job is known)

8 Scheduling: The Multi-Level Feedback Queue

The problem we try to address: given that we in general do not know anything about a process, how to

optimize turnaround time
minimize response time

8.1 MLFQ: Basic Rules

The MLFQ has a number of distinct queues, each assigned a different priority level. At any given time, a job that is ready to run is on a single queue.

A job with higher priority (i.e., a job on a higher queue) is chosen to run; use round-robin scheduling among jobs with the same priority.

rule 1: if Priority(A) > Priority(B), A runs (B doesn’t)
rule 2: if Priority(A) = Priority(B), A & B run in RR

To set the priority: MLFQ will try to learn about processes as they run, and thus use the history (long-running or interactive) of the job to predict its future behavior.

8.2 Attempt #1: How To Change Priority

rule 3: when a job enters the system, it is placed at the highest priority
rule 4
- a: if a job uses up an entire time slice while running, its priority is reduced
- b: if a job gives up the CPU before the time slice is up (therefore jobs with lower priority may have a chance to run), it stays at the same priority level

Example 1: A Single Long-Running Job

Example 2: Along Came A Short Job

The idea: first assumes a job to be short, otherwise move it down; this is an approximization of SJF

Example 3: What About I/O?

Problems With Our Current MLFQ

starvation: too many interactive jobs will consume all CPU time, thus long-running jobs will never receive any CPU time
can be attacked by first using most of the time and then perform an I/O
a program might change its behaviour

8.3 Attempt #2: The Priority Boost

rule 5: after some time period $S$, move all the jobs in the system to the topmost queue

If $S$ is set too high, long-running jobs could starve; too low, and interactive jobs may not get a proper share of the CPU.

8.4 Attempt #3: Better Accounting

rule 4: once a job uses up its time allotment (分配) at a given level (regardless of how many times it has given up the CPU), its priority is reduced (i.e., it moves down one queue)

8.5 Tuning MLFQ And Other Issues

The concept: instead of optimizing for turnaround or response time, a scheduler might instead try to guarantee that each job obtain a certain percentage of CPU time.

Tickets: the share of a resource that a process (or user or whatever) should receive.

The system picks a ticket (randomly) whose owner process can run at this point

If you are ever in need of a mechanism to represent a proportion of ownership, this concept just might be … (wait for it) … the ticket.

9.2 Ticket Mechanisms

ticket currency
ticket transfer
ticket inflation (通货膨胀)

9.3 Implementation

Best practice: order the list from the highest number of tickets to the lowest

9.4 An Example

Overall fairness is higher with higher job length

9.5 How To Assign Tickets?

Given a set of jobs, the “ticket-assignment problem” remains open.

9.6 Stride Scheduling

Stride: inverse in proportion to the number of tickets a job has

curr = remove_min(queue); // pick client with min pass
schedule(curr); // run for quantum
curr->pass += curr->stride; // update pass using stride
insert(queue, curr); // return curr to queue

Stride scheduling is a deterministic fair-share scheduler.

Lottery scheduling has no global state, so that new processes are easier to be incorporated

9.7 The Linux Completely Fair Scheduler (CFS)

Recent studies have shown that scheduler efficiency is surprisingly important; specifically, in a study of Google datacenters, Kanev et al. show that even after aggressive optimization, scheduling uses about 5% of overall datacenter CPU time.

Basic Operation

Goal: to fairly divide a CPU evenly among all competing processes

In the basic case, each process’s vruntime increases at the same rate, propotional to the physical time. Pick the process with the lowest vruntime to run next.

Divide sched_latency by process number to calculate the time slice; use min_granularity to constrain the minimum possible time slice.

Weighting (Niceness)

Use nice level to control the priority of a process. Positive nice values imply lower priority and negative values imply higher priority

When you’re too nice, you just don’t get as much (scheduling) attention, alas.

Calculation of the time slice:

$$ \texttt{time_slice}_k=\cfrac{\texttt{weight}_k}{\sum_{i=0}^{n-1}\texttt{weight}_i}\cdot\texttt{sched_latency} $$

Also adjusting the calculation of virtual runtime:

$$ \texttt{vruntime}_i=\texttt{vruntime}_i+\cfrac{\texttt{weight}_0}{\texttt{weight}_i}\cdot\texttt{runtime}_i $$

The table preserves CPU proportionality ratios when the difference in nice values is constant

Using Red-Black Trees

Use a red-black tree to maintain running (or runnable) processes; if a process goes to sleep (say, waiting fot an I/O to complete), it is removed.

Dealing With I/O And Sleeping Processes

A just-awaken process will monopolize the CPU; solution: set the vruntime of that job to the min value found in the tree (which only keeps track of running jobs!).

10 Multiprocessor Scheduling (Advanced)

10.1 Background: Multiprocessor Architecture

Two kinds of locality:

temporal locality
spatial locality

Problem with multi-code processors: cache coherence; the hardware uses bus snooping to update/invalidate outdated cache

10.2 Don’t Forget Synchronization

10.3 One Final Issue: Cache Affinity

A multiprocessor scheduler should consider cache affinity when making its scheduling decisions, perhaps preferring to keep a process on the same CPU if at all possible.

10.4 Single-Queue Scheduling

Singlequeue multiprocessor scheduling (or SQMS): take an existing policy that picks the best job to run next and adapt it to work on more than one CPU

Problems:

performance: the overhead of locking is high
cache affinity: each job ends up bouncing around from CPU to CPU

10.5 Multi-Queue Scheduling

Each CPU has a queue of tasks to be performed.

To solve load imbalance: using migration; a basic approach is to use work stealing

Operating Systems: Three Easy Pieces 学习笔记（二）

liang2kl@outlook.com (Liang Yesheng) — Wed, 23 Feb 2022 21:37:07 +0800

42 Crash Consistency: FSCK and Journaling

One major challenge faced by a file system is how to update persistent data structures despite the presence of a power loss or system crash.

Crash-consistency problem: On-disk state may only partially get updated on system crash or power loss

42.1 A Detailed Example

Crash Scenarios

Three possible outcomes if an error occured when a data block is allocated and written for a file (which should allocate a data block (and write data to it), update the data bitmap, and update the file inode):

only the data block is written: no problem at all (from the perspective of file-system crash consistency)
only the updated inode is written: garbage data will be read; file-system inconsistency: the allocated status of the data block is different in the bitmap and the inode
only the bitmap is written: space leak
only the inode and the bitmap are written: garbage data
only the inode and the data block: inconsistency between the inode and the bitmap
only the bitmap and the data block: space leak again

The Crash Consistency Problem

Crash-consistency problem (or consistent-update problem): the disk can only commit one write at a time, so that an update cannot be done atomically

42.2 Solution #1: The File System Checker

Early systems’ approach: fix inconsistencies later (when rebooting)

fsck’s phases:

check superblock
scans inodes, indirect blocks, etc. to make consistency between inodes and bitmaps (by trusting inodes)
check inodes for corruption and other problems
verify link count
check for duplicate pointers (two different inodes refer to the same block) (clear some inodes or make copies of the duplicate data)
check for bad block pointers (and remove them)
check directories

Fundamental problems of fsck: too slow

At a higher level, the basic premise of fsck seems just a tad irrational. Consider our example above, where just three blocks are written to the disk; it is incredibly expensive to scan the entire disk to fix problems that occurred during an update of just three blocks.

42.3 Solution #2: Journaling (or Write-Ahead Logging)

Write-ahead logging (or journaling): write logs before overwriting the structures to be able to recover from errors

Data Journaling

Journal write:

transaction begin block
blocks containing the exact contents of the updating blocks (physical logging) or some more compact forms (logical logging)
transaction end block

Checkpointing: override the old structures in the file system

Problems if a crach occurs during the write to the journal: if writing all the log blocks at once, as the disk might perform scheduling, they might not complete in order, and thus some blocks might not be correct (e.g. invalid data blocks within valid TxB and TxE blocks).

Solution: write all blocks except the TxE at once, and write TxE block after these writes. With atomicity guatantee!

Performance problem: the transaction-end block can only be written after previous blocks are written.

Optimizing log writes: using checksum

Three phases:

journal write (TxB, metadata and data)
journal commit (TxE)
checkpoint (write the contents to final on-disk locations)

Recovery

Replay the transactions that are commited to the disk (redo logging)

Batching Log Updates

Buffer all updates into a global transaction to avoid writing some same blocks many times.

Making The Log Finite

Journaling file systems treat the log as a circular data structure (the journal is referred to as circular log).

Mark the transaction free in the journal by updating the journal superblock some time after checkpoint.

Now the four phases:

journal write
journal commit
checkpoint
free

Metadata journaling

Ordered journaling (or metadata journaling): the user data is not written to the journal

One possible order (to avoid garbage data):

data write (1)
journal metadata write (2)
journal commit
checkpoint metadata
free

(1) and (2) can be written concurrently

43 Log-structured File Systems

The motivation

system memories are growing so that more data can be cached, and disk traffic increasingly consists of writes

a large gap between random and sequential I/O performace

exising file systems perform poorly on many common workloads

file systems are not RAID-aware

An ideal file system would thus focus on write performance, and try to make use of the sequential bandwidth of the disk. Further, it would perform well on common workloads that not only write out data but also update on-disk metadata structures frequently. Finally, it would work well on RAIDs as well as single disks.

43.1 Writing To Disk Sequentially

The basic idea: writing all updates (such as data blocks, inodes, etc.) to the disk sequentially

43.2 Writing Sequentially And Effectively

Sequential writes is not enough; to achieve good performance we must issue contiguous writes (or one large write)

Write buffering: keeps track of updates in memory, and write the buffered data at once when gets sufficient updates (called a segment)

43.3 How Much To Buffer?

$$ D=\cfrac{F}{1-F}\times R_\mathrm{peak}\times T_\mathrm{position} $$

43.4 Problem: Finding Inodes

43.5 Solution Through Indirection: The Inode Map

The inode map: takes an inode number as input and returns the disk address of the most recent version of the inode

LFS places chunks of the inode map right next to where it is writing all of the other new information.

Inode maps are compact enough to keep the active portions cached in main memory: inode map lookups rarely require disk accesses.

(From The Design and Implementation of a Log-Structured File System)

43.6 Completing The Solution: The Checkpoint Region

The checkpoint region (or CR) contains pointers to the latest pieces of the inode map; it is only updated periodically for performance

43.7 Reading A File From Disk: A Recap

The steps of reading a file (from start):

read the CR and cache it in memory
lookup the CR to find the address of a given inode
(the rest is pretty much the same as a typical FS)

43.8 What About Directories?

Steps:

look in the imap for the location of the inode of the directory
find inode number of the file in the inode of the directory
look in the imap for the location of the inode of the file

The imap also solves the recursive update problem through indirection.

43.9 A New Problem: Garbage Collection

The cleaner assures to preserve contiguous free regions by compacting existing segments to new, contiguous segments

43.10 Determining Block Liveness

Use segment summary block at the head of the segment to record the inode number and offset (which block of the file) for each data block

To determine whether a block is dead:

look in the segment summary block and find its inode number and offset
look in the imap to find and read the inode
look in the inode using the offset to compare the disk location

LFS can also use version number to determine this, avoiding extra reads.

43.11 A Policy Question: Which Blocks To Clean, And When?

The time to clean can be:

perioducally
during idle time
when the disk is full

43.12 Crash Recovery And The Log

Use two CRs containing update timestamps to recover from crash during CR updates

The last consistent snapshot of the file system may be quite old as LFS only writes the CR every 30 seconds or so; use roll forward to read through the next segments of the end of the log to see if there are any valid updates, and updates the file system accordingly.

44 Flash-based SSDs

Solid-state storage: random access, retains information on power loss

44.1 Storing a Single Bit

single-level cell (SLC) flash: a single bit per transistor
multi-level cell (MLC) flash: two bits per transistor (00, 01, 10, 11 represented by different levels of charge)
triple-level cell (TLC) flash: three bits per cell

SLC chips achieve higher performance and are more expensive.

44.2 From Bits to Banks/Planes

Flash chips are organized into banks or planes which consist of a large number of cells.

A bank is accessed in two different sized units:

block (or erase block): typically of size 128KB or 256KB
page: a few KB in size (e.g. 4KB)

44.3 Basic Flash Operations

Three low-level operations:

read (a page): random access; fast, 10s of $\mathrm{\mu s}$ or so
erase (a block): setting each bit to 1; quite expensive, takes a few ms; need to copy data of care somewhere else
program (a page): After a block is erased, change some of the 1’s within a page to 0’s; usually taking around $100\mathrm{\mu s}$

44.4 Flash Performance And Reliability

Wear out: erasing and programming accure a little bit of extra charge, 0 and 1 are increasingly difficult to be differentiated.

The typical lifetime:

MLC: 10,000 P/E (Program/Erase) cycles
SLC: 100,000 P/E cycles
actual lifetimes are much longer

Disturbance: some bits get flipped in neighboring pages when accessing (read/program) a particular page

44.5 From Raw Flash to Flash-Based SSDs

Flash translation layer (or FTL): translates read and write requests on logical blocks into low-level read, erase and program commands on underlying physical blocks and physical pages

The FTL should accomplish this task with the goal of delivering excellent performance and high reliability.

To achieve performance:

parallel
reduce write amplification

Write amplification: total write traffic issued to the flash chips (by the FTL) divided by the total write traffic issued to the SSD (by the client)

To achieve high reliability:

for wear out: wear leveling
for program disturbance: a sequential-programming approach

44.6 FTL Organization: A Bad Approach

Direct mapped organization: a read to a logical page is mapped directly to the physical page with the same page number

The problems with the direct-mapped FTL:

performance: each write needs to
- read in the entire block (costly)
- erase the entire block (quite costly)
- program the block (costly)
reliability: the same block can be erased and programmed over and over (e.g., file system metadata is overritten repeatedly)

The direct mapped approach simply gives too much control over wear out to the client workload; if the workload does not spread write load evenly across its logical blocks, the underlying physical blocks containing popular data will quickly wear out.

44.7 A Log-Structured FTL

Use a mapping table to map the logical block to the physical address

The log-based approach improves performance in:

erases being required once in a while
spread writes across pages (wear leveling)

Downsides:

garbage collection may drives up write amplification
in-memory mapping tables might be large

44.8 Garbage Collection

To reduce GC costs, overprovisioning can be performed: adding extra flash capacity and delay cleaning, which will be performed in background.

44.9 Mapping Table Size

Block-Based Mapping

Hybrid Mapping

Two types of mapping table:

log table (per-page mappings)
data table (per-block mappings)

To read:

first find in the log table
if not found, find in the data table

The key to the hybrid mapping strategy is keeping the number of log blocks small. To do that, the FTL has to periodically examine log blocks and switch them into blocks that can be pointed to by only a single block pointer.

Three types of merge:

switch merge: all pointers of a block in the log table can be switched into a pointer pointing to this block
partial merge
full merge

Page Mapping Plus Caching

44.10 Wear Leveling

One problem of the log-structured approach: blocks filled with long-lived data do not get overwritten; solution: periodically read and rewrite elsewhere

Operating Systems: Three Easy Pieces 学习笔记（一）

liang2kl@outlook.com (Liang Yesheng) — Thu, 13 Jan 2022 20:38:28 +0800

36 I/O Devices

36.1 System Architecture

Devices are connected to the system via:

memory bus (CPU - main memory)
general I/O bus: PCI (graphics, high performance devices)
peripheral bus: SCSI, SATA, USB (slow devices)

In modern systems:

PCIe Graphics
memory interconnect
DMI (Direct Media Interface)
PCIe
eSATA

36.2 A Canonical Device

A device has two important components:

interface
- status
- command
- data
internal structure

36.3 The Canonical Protocol

Programmed I/O (PIO): the main CPU is involved with the data movement

36.4 Lowering CPU Overhead With Interrupts

Utilize CPU:

interrupt
a two-phased approach: polls first, using interrupts if not yet finished
coalescing

36.5 More Efficient Data Movement With DMA

Direct Memory Access (DMA): transfer data between devices and main memory without much CPU intervention

36.6 Methods Of Device Interaction

explicit I/O instructions (on x86, the in and out instructions), usually privileged
memory-mapped I/O (no new instructions are needed)

36.7 Fitting Into The OS: The Device Driver

Read/write blocks:

file system
raw interface (support low-level storage management)

36.8 Case Study: A Simple IDE Disk Driver

Registers are available by reading or writing to specific “I/O addresses” using (on x86) the in and out I/O instructions.

wait for drive to be ready
write parameters to command registers
start the I/O: issuing read/write to command register
data transfer (for writes): write data to data port
handle interrupts

37 Hard Disk Drives

37.1 The Interface

The drive consists of a large number of sectors (512-byte blocks), each of which can be read or written

View the disk as an array of sectors (扇区)

multi-sector operations are possible
only guarantee a single 512-byte write is atomic

Efficiency:

access closer blocks are faster than farther ones
sequential read or write are faster than the random access manner

37.2 Basic Geometry

platter: 磁盘
surface: the 2 sides of a platter
spindle: 轴
track: 道, concentric circles of sectors
disk head
disk arm

37.3 A Simple Disk Drive

I/O time:

rotational delay
seek time
- acceleration
- coasting
- deceleration
- settling (significant)
transfer

Track skew: sequential reads can be properly serviced when crossing track boundaries

Multi-zoned disk drives:

a zone is a consecutive set of tracks on a surface
each zone has the same number of sectors per track
outer zones have more sectors

Cache (track buffer):

read: to read in all of the sectors on that track and cache them in its memory
write
- write back: acknowledge when puts into memory
- write through: acknowledge after actual writes

37.4 I/O Time: Doing The Math

The rate of I/O:

$$ T_\mathrm{I/O} = T_\mathrm{seek}+T_\mathrm{rotation}+T_\mathrm{transfer} $$

$$ R_\mathrm{I/O}=\cfrac{Size_\mathrm{transfer}}{T_\mathrm{I/O}} $$

a huge gap in drive performance between random and sequential workloads
a large difference in performance between high-end “performance” drives and low-end “capacity” drives

37.5 Disk Scheduling

Principle: shortest job first, SJF

Shortest-seek-time-first (SSTF, also shortest-seek-first or SSF): picking requests on nearest track to complete first

problems:

the drive geometry is not available to the OS (fix: nearest-block-first, NBF)
starvation: a steady stream to the closest track will block the access to other tracks

Elevator algorithm

SCAN: simply moves back and forth across the disks

F-SCAN: freezes the queue when doing a sweep (avoid starvation of far-away requests)

C-SCAN (Circular SCAN): only sweeps from outer-to-inner (more fair to the inner and outer tracks)

Prevent fights from taking place on elevators!

SCAN and SSTF does not adhere to SJF closly: they ignore rotation

SPTF: Shortest positioning time first

Also called shortest access time first, SATF

In engineering, it turns out “it depends” is almost always the answer, reflecting that trade-offs are part of the life of the engineer.

On modern drives both seek and rotation are roughly equivalent

SPTF is usually performed inside a drive

Other scheduling issues

Where to perform scheduling: The OS scheduler usually picks (what it thinks) some best few requests (say 16) and issues them all to disk; the disk then uses its internal knowledge to service said requests in the best possible (SPTF) order.

I/O merging: merge I/O requests by the OS

Non-work-conserving: waiting for some time for a possible better request

38 Redundant Arrays of Inexpensive Disks (RAIDs)

RAID: a technique to use multiple disks in concert to build a faster, bigger, and more reliable disk system

externally looks like a disk
internally consisting multiple disks, memory and processor(s)

38.1 Interface And RAID Internals

To perform a logical I/O:

calculate the actual disk(s)
perform one or more physical I/Os

38.2 Fault Model

RAIDs are designed to detect and recover from certain kinds of disk faults.

The fail-stop fault model: a not-working disk is assumed permanently lost

38.3 How To Evaluate A RAID

Characteristics:

capacity
reliability
performance

38.4 RAID Level 0: Striping

RAID level 0, or striping as it is better known, serves as an excellent upper-bound on performance and capacity.

Striping: no redundancy; spread the blocks of the array across the disks in a round-robin fashion to get the most parrallelism.

Simple striping:

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

Stripe: blocks in the same row (0, 1, 2, 3)

Striping with a bigger chunk size (8KB, 2 blocks, a stripe consists of 32KB of data):

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

Chunk sizes

small chunk size: on large files, positioning more on a single disk
large chunk size: less parallelism, but also less posisioning time

Thus, determining the “best” chunk size is hard to do, as it requires a great deal of knowledge about the workload presented to the disk system.

RAID-0 Analysis

capacity: perfect
reliability: any disk failure will lead to data loss
performance: all disks are utilized, often in parallel

Evaluating RAID Performances

Two performance metrics:

single-request latency
steady-state throughput (critical in high-perfromance environments)

Two types of workloads (considered here):

sequential: large contiguous chunks
- searching through a large file for a keyword
random: samll requests, to different random locations on disk
- transactional workloads on a database management system

Denote the sequential and random workload’s throughput as:

$S$ for sequential

$R$ for random

38.5 RAID Level 1: Mirroring

RAID-10 (or RAID 1+0, stripe of mirrors):

Disk 0	Disk 1	Disk 2	Disk 3
0	0	1	1
2	2	3	3
4	4	5	5
6	6	7	7

RAID-01

Disk 0 Disk 1 Disk 2 Disk 3

0 1 0 1

2 3 2 3

4 5 4 5

6 7 6 7

Disk 0	Disk 1	Disk 2	Disk 3
0	1	0	1
2	3	2	3
4	5	4	5
6	7	6	7

read: either copy
write: update both

Analysis

Consistent-update problem

untimely failures on write: inconsistent copies

solution: write-ahead log and recovery procedure

capacity: expensive, $N\cdot B/2$ for mirroring level = 2
reliability: tolerate failure on any disk, up to $N/2$ disks can fail
single request performance
- read: sames as on a single disk ($R$, writes to two blocks)
- write: slightly higher than writing to a single disk (worst-case seek and rotational delay)
steady-state throughput
- write: ($\frac{N}{2}\cdot S$, writes to $N$ blocks)
- read: same as write ($\frac{N}{2}\cdot S$, each disk receives a request for every other block)
random reads/writes
- read: $N\cdot R$
- write: $\frac{N}{2}\cdot R$

38.6 RAID Level 4: Saving Space With Parity

Parity-based approaches attempt to use less capacity and thus overcome the huge space penalty paid by mirrored systems. They do so at a cost, however: performance.

Disk 0	Disk 1	Disk 2	Disk 3	Disk 4
0	1	2	3	P0
4	5	6	7	P1
8	9	10	11	P2
12	13	14	15	P3

Simple function: XOR, which makes a row having even number of 1

Analysis

capacity: $(N-1)\cdot B$
reliability: tolerates 1 disk failure
performance
- steady-state: $(N-1)\cdot S$ (full-stripe write: calculate parity bits first then write all disks in parallel)
- random
  - read: $(N-1)\cdot R$
  - write: $R/2$ (the parity disk is the bottleneck)
    - additive parity: read in parallel, calculate XOR, and write in parallel (larger RAIDs require a high number of reads)
    - subtractive parity: $P_\mathrm{new}=(C_\mathrm{old}\oplus C_\mathrm{new})\oplus P_\mathrm{old}$ (Why not always better?– because it has to read the parity disk?)

Small-write problem: the parity disk is a bottleneck under small writes which prevents parallelism

38.7 RAID Level 5: Rotating Parity

Disk 0	Disk 1	Disk 2	Disk 3	Disk 4
0	1	2	3	P0
5	6	7	P1	4
10	11	P2	8	9
15	P3	12	13	14
P4	16	17	18	19

Analysis

random write: $\frac{N}{4}\cdot R$ (four I/O operations) (aren’t the reads/writes parallel?–the data disk itself serves as parity disk as well)

39 Interlude: Files and Directories

Thus, the OS must take extra care with such a device: this is where users keep data that they really care about.

39.1 Files And Directories

file: linear array of bytes
- low-level name (inode number)
directory
- low-level name (inode number)
- a list of (user-readable name, low-level name) pairs

39.3 Creating Files

Create a new file: call open() and pass O_CREAT flag:

int fd = open("foo", O_CREAT|O_WRONLY|O_TRUNC, S_IRUSR|S_IWUSR);

O_CREAT: create the file if it does not exist
O_WRONLY: read only
O_TRUNC: if exists already, truncates it to a size of zero bytes

39.5 Reading And Writing, But Not Sequentially

Reading some random offsets within the document:

off_t lseek(int fildes, off_t offset, int whence);

fildes: file descriptor
offset: the file offset to a particular location
whence
- SEEK_SET: the offset is set to offset bytes
- SEEK_CUR: the offset is set to its current location plus offset bytes
- SEEK_END: the offset is set to the size of the file plus offset bytes

Calling lseek() does not perform a disk seek

The “current offset” tracked by the OS:

implicitly updates when read or write
explicitly updates with lseek

The file structure:

struct file {
 int ref;
 char readable;
 char writable;
 struct inode * ip;
 uint off;
};

The open file table:

struct {
 struct spinlock lock;
 struct file file[NFILE];
} ftable;

39.6 Shared File Table Entries: `fork()` And `dup()`

The open file table entries are shared by 1. the parent and child processes created by fork(); 2. one file descriptor and its duplicates created by dup(), with the reference count incremented.

39.7 Writing Immediately With `fsync()`

Calls fsync() to force all dirty (not yet written) data to disk.

int rc = write(fd, buffer, size); assert(rc == size);

In some cases, it is also needed to fsync() the containing directory to ensure that the file is part of the directory.

Not surprisingly, this type of detail is often overlooked, leading to many application-level bugs.

mmap() and persistent memory

By combining the persistence of files with the access semantics of memory, file-backed memory mappings support a software abstraction called persistent memory.

39.8 Renaming Files

rename(char *old, char *new)

rename() call is usually implemented as an atomic call.

An example to use this kind of guarantee:

int fd = open("foo.txt.tmp", O_WRONLY|O_CREAT|O_TRUNC, S_IRUSR|S_IWUSR);
write(fd, buffer, size);
fsync(fd);
close(fd);
rename("foo.txt.tmp", "foo.txt");

39.9 Getting Information About Files

Use stat() or fstat() to access metadata of files or directories.

39.10 Removing Files

Use unlink() to remove files.

39.11 Making Directories

Use mkdir() to create a directory.

An empty directory has two entries:

refer to itself
refer to its parent

39.12 Reading Directories

Use opendir(), readdir() and closedir() to read contents of a directory.

DIR * dp = opendir(".");
assert(dp != NULL);
struct dirent * d;
while ((d = readdir(dp)) != NULL) {
 printf("%lu %s\n", (unsigned long) d->d_ino, d->d_name);
}
closedir(dp);

39.13 Deleting Directories

Call rmdir() to delete a directory.

39.14 Hard Links

Call link() to make an entry in the file system tree, simply creates another name in the directory and refers it to the same inode number.

ln file file2

When creating a file, two things happened:

making a structure (the inode) that tracks relevent information

linking a human-readable name to that file, and put that link into a directory

When the file system unlinks a file, it checks the reference count (link count) within the inode number, and only free the node and related data blocks when it reaches zero.

39.15 Symbolic Links

Call symlink() to make an symbolic link (soft link) to a file.

ln -s file file2

Differences from hard links:

symbolic links is actually a file itself of a different type
possibility for dangling reference

39.16 Permission Bits And Access Control Lists

Permission bits consist of three groupings:

owner
group
other (anyone)

The owner of the file can change the permissions.

But now you have learned an even more important lesson: there can be no secrets in a good marriage, even within the file system.

The Time Of Check To Time Of Use (TOCTTOU) problem

The problem is caused by the gap between the check and the update.

39.17 Making And Mounting A File System

And mkfs said, let there be a file system!

Mount: to take an existing directory as a target mount point and paste a new file system onto the directory tree at that point.

Mount unfies all file systems into one tree, making naming uniform and convenient.

40 File System Implementation

vsfs (the Very Simple File System)

The file system is pure software; unlike our development of CPU and memory virtualization, we will not be adding hardware features to make some aspect of the file system work better (though we will want to pay attention to device characteristics to make sure the file system works well).

40.2 Overall Organization

The disk is divided into:

data blocks: user data
inodes
allocation structures: to track whether inodes or data blocks are free or allocated
superblock: contains information about the fie system

40.3 File Organization: The Inode

Inode (index node): the data structure that holds the metadata of a given file

i-number (low-level name): the number that the inode is implicitly referred to; disk position can be calculated by the number

Calculation:

$$ block = (inumber\times sizeof(inode)) / blockSize $$

$$ sector = ((block\times blockSize) + inodeStartAddr) / sectorSize $$

Metadata in a inode:

type: directory or file (kept in the directory entry and thus is not found in the inode)
size
number of blocks
protection information
time
data block position on disk

The Multi-Level Index

Indirect pointer: points to a block that contains pointers which each points to user data

An inode may have some fixed number of direct pointers and a single indirect pointer.

If a file grows large enough, an indirect block is allocated (from the data block) and the inode’s indirect pointer is set to point to it.

Extent-based approaches: a disk pointer plus a length; allow for more than one extent

Linked-based approaches: use a linked list to keep track all blocks of a file

Double indirect pointer: refer to a block that contains indirect pointers

Most files are small: a small number of direct pointers is sufficient

40.4 Directory Organization

Deleting a file can leave an empty space in the middle of the directory; a new entry may reuse an old, bigger, deleted entry.

File systems often streat directories as a special type of file, and thus they have inodes in the inode table.

40.5 Free Space Management

To track free inode/data blocks:

use bitmap
use free list
use more soplisticated ds, e.g. B-tree

Pre-allocation policy: reserve a sequence of blocks for a newly-created file, to guarantee that a portion of the file is contiguous on the disk.

40.6 Access Paths: Reading and Writing

Reading A File From Disk

The timeline of reading a file /foo/bar:

open("/foo/bar", O_RDONLY)

read the root inode (/) (whose i-number is well known; 2 in most UNIX FSs)
read / data (to look for an entry for foo)
read foo inode
read foo data (to look for an entry for bar)
read bar inode

read(...)

read bar inode
read specific block of bar’s data
write bar inode for last access time

Yes, life can get pretty bad when reading a file; as you’re about to find out, writing out a file (and especially, creating a new one) is even worse.

Reads don’t access allocation structures (e.g. bitmaps); they are only accessed when allocation is needed. There is no need to make sure a block is allocated when the inode already points to it

Writing A File To Disk

Each write to a file logically generates 5 I/Os:

read file inode
read data bitmap
write data bitmap (to mark the newly-allocated block as used)
write file data
write file inode

For file creation:

read inode and inode data traversly to find the containing directory
read containing directory data
read inode bitmap (find a free inode)
write inode bitmap (to mark the inode allocated)
write directory data (link)
read/write directory inode
read/write inode of the new file (initialize)
additional I/O might be needed if the directory needs to grow

40.7 Caching and Buffering

Most file systems aggressively use system memory (DRAM) to cache important blocks.

Early file systems use a fixed-size cache to hold popular blocks; this static partitioning method can be wasteful.

Modern systems use a dynamic partitioning approach.

Static vs. dynamic partitioning

static: predictable performance

dynamic: better utilization; more complex to implement

Buffering: delay writes to reduce I/O

In this case, laziness (in writing blocks to disk) is a virtue.

41 Locality and The Fast File System

41.1 The Problem: Poor Performance

Main issue of the old UNIX file system: data was spread all over the place, thus had expensive positioning costs

Some problems:

the inode and the data block are often far away
the file system is getting more and more fragmented
the block size is too small, so that transferring data is inefficient

41.3 Organizing Structure: The Cylinder Group

Cylinder (柱面): a set of tracks on different surfaces that are the same distance from the center

FFS divides the disk into a number of cylinder groups.

As modern drives only export a logical address space of blocks, modern file systems instead organize the drive into block groups, each of which is a consecutive portion of the disk’s address space. By placing two files within the same group, FFS can ensure that accessing one after the other will not result in long seek time.

FFS needs to have the ability to place files and directories into a groups and track relevant information, thus all the structures that a file system is expected to have is included in each group.

The components of a single cylinder group:

a copy of the super block
a per-group inode bitmap and data bitmap
inode region
data block region

41.4 Policies: How To Allocate Files and Directories

The basic mantra is simple: keep related stuff together (and its corollary, keep unrelated stuff far apart).

A few placement heuristics:

directories: find the group
- with a low number of allocated directories (to balance directories across groups)
- with a high number of free inodes (to be able to allocate a bunch of files)
files:
- allocate the data blocks in the same group as its inode
- places all files that are in the same directory in the cylinder group of the directory they are in

41.6 The Large-File Exception

Filling an entire block group with large files will prevents related files from being placed within the same group.

FFS’ policy for large files: after some number of blocks are allocated into the first block group, it places the next large chunk of the file in another block group.

To address the performance problem: choosing chunk size carefully. By amotization, if the chunk size is large enough, the seek time will be relatively little.

FFS’s approach

the first 12 blocks are placed in the same group as the inode
each subsquent indirect block and the blocks it points to are placed in a different group

Note that the trend in disk drives is that transfer rate improves fairly rapidly, as disk manufacturers are good at cramming more bits into the same surface, but the mechanical aspects of drives related to seeks (disk arm speed and the rate of rotation) improve rather slowly.

41.7 A Few Other Things About FFS

Internal fragmentation: 4KB blocks are used by many 2KB files

Sub-blocks: 512-byte blocks can be allocated to files; copy to a 4KB block when the size grows beyond 4KB

To address the performance issue caused by copies: buffer writes, to avoid this in most cases.

A refined disk layout (parameterization): skipping a block when issuing a sequential read (e.g. 0 6 1 7 2 8 3 9 4 10 5 11); to issue the performance problem: using track buffer.

FFS also supports:

long file names
symbolic links

Certainly all modern systems account for the main lesson of FFS: treat the disk like it’s a disk.

2021 秋季学期总结

liang2kl@outlook.com (Liang Yesheng) — Sat, 08 Jan 2022 01:05:00 +0800

关于各课程

这个学期总共 17 学分，除了体育和信概，上了五门课：汇编、自动机、数据结构、网原、概统。

汇编的收获挺大。老师其实讲得很一般，但课程内容很有意思，计算机系统的知识对于之前只接触过上层软件的我来说是一个全新的世界。计算机系统各个部分、各个层次的运转和协调非常精妙，下学期应该有机会继续深入研究。

自动机属于个人感受先抑后扬的课程。前两节课上来就讲上下文无关文法无异于当头一棒，这部分内容过于抽象，而且老师并没有作很好的解释，体验极其不好。后来随着正规语言、DFA 这些更符合直觉的内容的引入，终于慢慢弄清楚了研究这些各种各样的语言有什么用，它们分别对应程序设计中的什么问题，也逐渐适应了其中的逻辑。老师非常温柔，也非常认真负责，但是讲课实在是有点无聊。

邓公的数据结构可以说是清华课程的天花板，上课时都是抱着“上一节少一节”的虔诚心态来享受的。PPT 的组织、老师的讲解、课堂的演示几乎都达到了完美，每堂课听完都有酣畅淋漓的感觉。当然，课讲得好，不代表学生上完课水平就高。上课感觉啥都会了，开始做 PA 还是一脸懵逼，最后的考试更是直接把“你并没有学懂”写在了试卷上。虽然但是，数据结构的确是一门深刻改变编程思想的课程，经过一个学期的学习，受益匪浅。

网原的学习体验并不好。我对网络还算挺感兴趣，计算机网络本身也很有意思，但是这课恨不得把每一层历经几十年发展积累的无论是过时的还是先进的技术都一股脑塞给你，知识过于繁杂，导致上课根本没有一个清晰的脉络。而且，自底向上的方法让人在前几章学数据通信、物理层和链路层时很难理解这些东西有什么用，这些协议这样设计的意义是什么。不过最后考试出的题目还挺有意思，这个出乎意料。

概统选的是胡家信老师的课，全程很水，特别是和之前上的唐宏岩的课相比，知识的广度和深度都差太多，统计竟然只讲到参数估计，连假设检验都没讲。老师上课讲得很详细，但是统计部分基本念 PPT，也没有什么原理性、启发性的解释。考试挺难的，有几道题不会做。

关于项目

这个学期做的项目最主要是一个静态网站生成器的博客插件，给 Mkdocs 增加了博客功能。维护用了不少时间，陆续加了不少功能，用的人也逐渐多了起来，感受还是挺不错的。不过用插件很难构建一个功能完善的博客，最后还是转向了 Hugo 来建博客。

另外，还写了一点 SwiftUI 教程，主要想对 SwiftUI 一些难懂的概念、原理作一下介绍，不过写了一半就停下来了（的确太花时间），写的效果也没有达到预期，可能寒假会继续写下去。

总结

前几天和 lqw 吃饭的时候聊到，感觉这个学期过得比以往任何一个学期都要快。前几个学期要么有繁忙的社工，要么在玩命写项目，要么在紧张准备转系，相比之下这个学期显得过于平淡了。

这个调子其实在开学前就定下了。我的 GPA 在机械还能勉强排到中上游，而在各路大神齐聚的贵系，这个分数对应的排名就变得非常难看，压力变得空前巨大。于是，暑假的时候我就先后退掉了宣中的社工、拒绝了一个创业团队的邀请。我给出的理由都是：成绩不好，之后只能专心学业。

结果就是，大多数日子里，我基本上都在宿舍-教室-食堂-图书馆的循环中度过，有时候想做一些好玩的东西，也的确写了几个玩具项目，但最终还是一次次地告诫自己：不要让这些事情干扰到学习。

现在回想，专心学习的确是有好处的。我在大一第一个学期之后第一次做到线下上课全勤，上课基本上都认真地听讲并做了笔记，每天课后也对内容做了回顾。这样坚持下来的最明显的好处是：我能够很清晰地掌握每个课程的脉络，清楚地知道自己在这些课程中学到了什么东西、这些课程的精髓在什么地方。之前的学习过于匆忙，没有回顾、思考的时间，囫囵吞枣，因此几乎没有对哪一门课有“学懂”了的感觉。这个学期，投入了更多的时间进行复习、思考，对知识的理解就有了深度。

但是，毕竟学习只是生活的一部分，阅读、游戏、游玩、写程序等等都不应该因此而荒废。以后应当提高学习效率，减少浪费在漫无目的的刷手机上的时间，把更多的时间放在这些有意思的事情上面。

总的来说，这个学期算是挺有收获。在贵系的第一个学期，（应该？但愿？）没有掉队，而且学习的内容都挺感兴趣，虽然学习的过程并不一直都那么顺利。下学期学习任务更重，希望到时候能够既保持课内学习的状态，同时在科研和其他方面有一定的发展吧。

更新

今天（1 月 21 日）不经意间看到机械班群里面赵导发的群公告，才知道出成绩了，来这里更新一下。

不得不说我的学习感觉和最终的成绩还是比较吻合的，几门比较用功并且学得比较透彻的专业课（汇编、自动机、网原）都得到了 4.0；花了比较多时间但并没有学得很透彻的数据结构，以及没怎么花时间的概统得了 3.6。

其实考试过程中和考完试之后一直挺担心一件事，就是我自认为学得很透彻的几门课可能由于我考试时经常犯的计算错误、审题错误、脑子短路等问题而不能够取得一个比较好的成绩；考完汇编和概统之后我悲观地认为这个学期，甚至以后的学期一个 4.0 都拿不到了。事实证明我还是多虑了，大多数的考试都是所学内容的子集，如果已经学得比较透彻，那已经超过（大部分的）考试要求了，也基本上不会出现上面这些所谓的问题。虽然这是一个高中就已经非常清楚的常识，但说实话，在没有什么自信的情况下（特别是在贵系中）是很难相信这一点，也很难相信“有付出就有回报”的。

这个学期的学习算是达到了预期，下学期继续努力吧。

2021 年终总结

liang2kl@outlook.com (Liang Yesheng) — Fri, 31 Dec 2021 20:46:58 +0800

终于到了 12 月 31 日，可以赶在 ddl 前的最后的三个小时里总结一下过去的一年了。

转系

今年最重要的事情，是从机械系降转到了计算机系。

转系的想法是在前一年转系结果出来的那段时间萌发的。当时从来没有编程经验的我经过一个学期的学习、开发后，在 App Store 上架了第一个 app。在这个过程中，我惊讶地发现，我短暂地到达了刚上高中时思考人生时所设想的那种理想中的状态：每时每刻都全身心投入在自己所感兴趣的事情上。

我的兴趣是什么？大学以来，我一直以一种回避的态度来面对这个问题。我之前的人生像是在应试教育的框条下的一条预设好的“最优道路”：上最好的小学，成绩拔尖；上最好的初中，成绩拔尖；上最好的高中，成绩拔尖。因此，当由于高考发挥不佳，只能通过领军进入清华而在有限的专业里面选择机械时，我也就理所应当地将其视为这条“预设”道路的一部分，是“最好的安排”。我一直回避与专业选择相关的问题，总是给自己灌输“继续学下去，就一定能找到兴趣”的观念。因为高中的时候对做生物实验挺感兴趣，又了解到机械系有生物 3D 打印的方向，于是在分流的时候，我还很笃定地（现在看来是一种自我安慰）认为我感兴趣的方向就是生物 3D 打印，并在分流小作文里表达了自己对“机械和生物结合”浓厚的兴趣。

这种想法在我接触编程后发生了改变。对于我来说，那是一种与之前的学习完全不同的感受：我愿意为与课内学习无关的知识付出时间，而不是之前“考试不考就没有动力学”；我不会因为越来越艰深的知识而感到枯燥、无聊，而是学得越多，越对更深入的知识产生更多的兴趣。原来这才是真正的兴趣，这才是我真正想做的事情。

在当年的转系结果出来以后，看到周围不少同学都找到了自己所认为的合适的专业，我第一次认真考虑了转系这一选项。我找到培养方案：一边是理论力学、材料力学、工程材料这些我看课程名就有点抗拒的课程，另一边是汇编、编译原理、网络原理这些在我之前写程序的过程中一直想要深入探究的、听上去就很有意思的东西。在这番比较之后，答案就很显然了：我要转系。

刚决定要转系的几天，也许是自己转系成功之前最紧张的几天。这种紧张并不是害怕转系失败，更多是一种站在十字路口上做选择的恐惧和迷茫。我从来没有自己做出对自己人生如此重大的决定，要是错了，怎么办？

在经过了做出决定之后的最初的挣扎之后，接下来的事情就非常自然了。我选了计算机的专业课，报了一个软院的 SRT，一直在写各种各样的程序，这些经历也成为了我面试时个人志趣的证明。当然，过了一年之后，当转系真正开始时，我还是有点紧张的，毕竟我的排名并不高，虽然已经坚定了学习计算机的信念，但要是不能通过，之后还是有点麻烦的。

非常幸运，最终转系成功。我第一次改变了自己的人生轨迹。

树洞

占据 2021 年故事的很大篇幅的另一个事情，是写树洞 app。寒假刚开始时，树洞在招募客户端开发者，我稍微犹豫了一会后加入了。犹豫是因为担心自己的能力不足以支持开发这样一个比较大的项目，但最终还是发邮件报了名。

在大家对新功能作一番论证、UI 设计师把设计稿画出来之后，就开始了漫长的开发过程。进行 iOS 客户端开发的有我和另外一个北大的同学，但只有我有过 iOS 开发经验，所以我承担了大部分的开发工作。开发过程中学到了不少东西：git 的一些高级用法、HTTP 请求、iOS 开发和 SwiftUI 的很多未接触过的知识……当然还走了不少弯路，要么是由于经验不足，要么是由于 SwiftUI 不成熟导致的问题。

写树洞 app 的投入程度比我之前写任何程序，包括 Whiz Reader，都要疯狂。除了正经坐在桌子前，在广州实践时住的酒店里、在高铁上、在春节回老家过年时、~~上 OOP 时~~，都留下了一条条 commit 记录，只要打开 Xcode，就感受不到任何的困倦。由于高强度的开发，虽然 iOS 客户端开发人手远少于安卓，但我们比安卓早了将近两个月完成开发。

这最终成为了我接触编程之后提升最大的一次项目经历。

告别

今年有两次告别让我猝不及防：一是梅西离开巴萨，一是树洞关闭。

这是我的两条朋友圈：

十几年前，看一个大哥哥打实况，我说这个人怎么跑得这么慢，他笑了笑，“他可是梅西，速度最快的”

接下来，在 CCTV5 的体育新闻里记下了，那个叫梅西的人是在一个叫巴塞罗那的俱乐部，队服是红蓝色的

2012 年，开始关注巴萨的比赛，那年欧冠半决赛输给了切尔西，梅西射丢了点球

2015 年，穿着梅西球衣看了欧冠决赛，那年 MSN 大杀四方，所向披靡

2017 年，6-1 逆转巴黎的欧冠看一次哭一次，至今还记得那天在教室电脑看到比分时的疯狂

2019 年，高考，几乎每场欧冠淘汰赛都看了，没看 3-0 利物浦，却看了 0-4 的那一场

2020 年，梅西要走，焦虑了大半个月，最后庆幸梅西还在巴萨

上个赛季，几乎每场球都看了，两点，三点，四点……梅西总能让伤身的熬夜显得那么值得

梅西在巴萨的最后一场比赛，看了直播，梅西进了一个头球，最后被逆转

没想到已成绝唱

青春真的结束了

……

为什么我们，包括其他开发者、设计人员和运营者都愿意牺牲自己的时间和精力投入在其中？

因为它对你我，对每个人都有独特的意义。这份意义，可以是更多的信息来源，可以是洞友们的善意带来的温暖，也可以是缓解压力的那些有趣的树洞。虽然树洞是一个存在很多争议和负面情绪的地方，但并不妨碍它存在于每个清华学生的美好回忆中。

今天下午花了几十分钟爬取树洞，爬着爬着到了每天8000个树洞的上限，只好作罢，不禁悲从中来，也许我们真的要跟树洞说再见了。

我之前并未经历多少离别，这两件事情对我来说是不小的打击。我逐渐意识到，再美好的事物都有逝去的一天。当它们真正离开的时候，我们几乎什么都做不了。

但是，美好事物的意义，不正在于它存在时在我们生活中留下的痕迹吗？

“Don’t be sad because it’s over. Smile because it happened.”

Goodbye, 2021. Hello, 2022.

Jinja 继承、函数和块

liang2kl@outlook.com (Liang Yesheng) — Fri, 24 Sep 2021 00:00:00 +0800

最近在为 mkdocs-blogging-plugin 添加自定义的功能，因为本来就是用 Jinja 的 HTML 模版来生成 HTML，所以也想用 Jinja 给用户提供自定义的接口。

大概的要求有：

提供自定义单个 post 而保留大体框架的方法
提供自定义 style sheet 的方法
提供整体重写的方法

这篇文章只会覆盖到部分。

继承：`extends`

Jinja 给我们提供了一种类似于继承的方法，可以在保留原来模版所有内容的情况下增加、重写部分内容的方法。

在“子模版”中，通过 extends 引用“父模版”：

{% extends "blog.html" %}

如果只有这一句，相当于将原来 blog.html 中所有内容原封不动地搬到新的模版中。至于增加和重写内容，稍后再谈。

函数：`macro`

在用户提供的覆写模版中，我们需要用户向父模版提供一个“函数”，用来生成单个博客的内容。

Jinja 中的“函数”叫做 macro，通过这样的方法定义：

{% macro render_blog(title, description, time, url) -%}
 {# content #}
{%- endmacro %}

以及，这样调用：

{% call render_blog(title, description, time, url) %}
 {# caller_content #}
{% endcall %}

在 call 调用 macro 后，将整个 call 块替换为 macro 块里面的所有内容 {# content #}，与 C 中的宏定义一致（这应该也是为什么叫做 macro 的原因）。

另外，macro 有一个隐含参数 caller，其作用是返回 call 块中间的内容 {# caller_content #}，如：

macro：

{% macro foo(name) -%}
 <div>{{ name + " says: " + caller() }}</div>
{%- endmacro %}

call：

{% call foo("liang2kl") %}
 Hello, World!
{% endcall %}

call 的结果为：

<div>liang2kl says: Hello, World!</div>

值得注意的是，如果不想传递 caller 中的内容，也需要在 macro 中调用 caller()，否则会报错：

TypeError: macro ‘foo’ was invoked with two values for the special caller argument. This is most likely a bug.

现在，我们只需要用户提供一个产生博客内容的 macro 给我们的父模版就可以了。

重写：`block`

Jinja 的继承机制允许我们在“子模版”中选择性地重写部分内容，而保持其他部分不变。实现的机制是 block。

在父模版中，我们用 block 块划出允许重写的部分。如：

{% block style %}
<style>
 ...
</style>
{% endblock %}

在子模版中，重写：

{% block style %}
 ...
{% endblock %}

即可将父模版中的 style 块替换为新的块。

另外，可以用 super() 保留原来内容：

{% block style %}
 {{ super() }}
 ...
{% endblock %}

放在一起

将上面几个功能放在一起，我们给用户提供这样的自定义方式：

{% macro render_blog(title, description, time, url) -%}
 <a href="{{ url }}"><h3>{{ title }}</h3></a>
 <div>{{ description }}</div>
 <div>{{ time }}</div>
 <hr/>
 {{ caller() }}
{%- endmacro %}

{% extends "blog.html" %}

{% block style %}
 .md-typeset .blog-post-title {
 color: blue;
 }
{% endblock %}

其作用：

在引入 blog.html 之前，定义 render_blog 的 macro，以便在 blog.html 中调用
引入 blog.html
通过 block 修改 blog.html 的 style 块

做一个 MkDocs 博客插件

liang2kl@outlook.com (Liang Yesheng) — Thu, 09 Sep 2021 00:00:00 +0800

MkDocs 是个好东西，非常适合用来写一些 tech 文章；而 MkDocs 的 Material 主题更是 geek 风格十足。第一次看到 Material for MkDocs，就一见钟情，马上搭了个博客网站。

但是，仔细一看 Material for MkDocs 的介绍，感觉不太对劲：

Technical documentation that just works

Create a branded static site from a set of Markdown files to host the documentation of your Open Source or commercial project…

MkDocs 本来就只是为了搭建项目文档网站设计的，很多功能和设计（如底部导航栏、侧边栏等）更适合文档，而非博客。这导致，MkDocs 并没有将所有文章列在一个地方的功能。没有博客界面，怎么能叫做一个博客呢……

但是，实在舍不得这么好看的界面，就琢磨着自己魔改一番。正好小学期学了 Python，可以用来练练手。

最终成果开源于 mkdocs-blogging-plugin

MkDocs 的插件是怎么工作的

仔细读了读开发者文档，MkDocs 插件的工作是在 MkDocs 处理文档的整个生命周期的不同阶段拦截当前结果，并返回处理后的结果。比如，对生成的 html 进行修改，是在插件类的 on_page_content 函数中实现的：

on_page_content

The page_content event is called after the Markdown text is rendered to HTML (but before being passed to a template) and can be used to alter the HTML body of the page.

Parameters:

html: HTML rendered from Markdown source as string

page: mkdocs.nav.Page instance

config: global configuration object

files: global files collection

Returns: HTML rendered from Markdown source as string

我们从函数参数中读取当前处理中的 html 字符串，在对其进行处理后，返回最终的 html 字符串，就完成了插件对页面内容的修改。

实现这些函数，我们就可以读取需要的信息，并更改某些页面内容。

设计与实现

首先，考虑把博客内容加入什么地方。考虑到用户可能需要在博客列表的前后加上其他的信息，直接生成一个页面不太可行。参考 mkdocs-git-revision-date-localized-plugin 的做法，让用户在需要添加博客内容的地方加上一个指定的占位符 {{ blog_content }}，然后在处理时用正则表达式替换即可。

然后，考虑博客的排序。我们选择使用 git log 来获取博文的创建和更新时间，然后向用户提供配置的选项（从新到旧 + 根据创建时间 / 从旧到新 + 根据修改时间等）。这部分代码可以直接抄 mkdocs-git-revision-date-localized-plugin 的实现，工作量–。

插件类与用户配置

根据文档，插件类需要继承 BasePlugin。在 BasePlugin 中，config_scheme 为插件的可配置选项。比如，我们需要用户设置一个名叫 foo 的参数，其类型为 str：

class BloggingPlugin(BasePlugin):
 config_scheme = (
 ("foo", config_options.Type(str, default=None)),
 )

这样，用户在 mkdocs.yml 中，可以这样配置 foo（假设我们的插件名为 blogging）：

plugins:
 - blogging:
 foo: bar

获取博客文件

我们需要给予用户自行设置哪些文件夹、哪些文件的途径。在 config_scheme 中，加上一项 dirs：

config_scheme = (
 ("dirs", config_options.Type(list, default=None)),
)

然后，在 on_page_content 函数中，如果 page 是在用户设置的 dirs 里面，就将其储存下来：

def on_post_page(self, output, page, config):
 for dir in self.docs_dirs:
 if page.file.src_path[:len(dir)] == dir:
 self.blog_pages.append(page)

另外，有些文章在 dirs 中，但可能并不希望被包括进博客中（如一些 index page）。对于这些文件，我们要求用户在 markdown 的 meta 中加入一项 exclude_from_blog：

---
exclude_from_blog: true
---

然后，修改一下上面的判断条件：

if page.file.src_path[:len(dir)] == dir \
 and (not "exclude_from_blog" in page.meta \
 or not page.meta["exclude_from_blog"]):

就可以实现页面的筛选。

页面生成

我们需要生成博客的列表界面，最简单的办法就是用 html 模版引擎来为我们动态地生成静态页面，这里使用 MkDocs 使用的 jinja2 来处理。

生成博客列表不是难事，写一个 for 循环就可以了：

{% for page in pages %}
 <div>...</div>
{% endfor %}

比较棘手的是分页的处理。根据我们的设计，我们最终在一个页面中插入博客内容，但是分页一般是多个页面。

最终采取了将所有博客信息塞入页面、使用 css 现实当前页面博客信息 / 隐藏其他页面的方法：

首先，在 pagination 中，将地址设置为 #page{{当前页面}}：

<a href="#page{{ page_idx + 1 }}">{{ page_idx + 1 }}</a>

在 css 中，id 与 # 后面字符相同的可以用 :target 选择器选中。比如，当前页面是 /blog/#page1，那么 :target 选中的就是 id = "page1" 的元素。我们只需要将 :target 设为显示，其他设为隐藏就可以了。

在 html 中：

<div class="pages">
 {% for page_idx in range(0, page_num) %}
 <div class="page" id="page{{ page_idx + 1 }}">
 <!-- 第 page_index + 1 页的内容 -->
 </div>
 {% endfor %}
</div>

在 css 中：

/* 将所有子元素隐藏 */
.pages > * {
 display: none;
}

/* 显示 :target */
.pages > :target {
 display: block;
}

由于 css 处于后面的声明会覆盖前面的声明，:target 可以显示，而其他页面的元素将被隐藏。这样就实现了分页。

另外，我们还需要 JavaScript 来处理 pagination 的高亮，在这里就不赘述了。

这种解决方法其实有个问题：当我们点击链接跳转到 #pageX 的时候，浏览器会自动跳转到 id = pageX 的元素处，非常影响体验。如今已经抛弃这种方法，改为在 JavaScript 中利用点击事件获取页面、更改 page 的 class 来实现页面的显示和隐藏。

页面插入

在插件的 on_post_page 函数中，将原来文件中的 {{ placeholder }} 替换为用 jinja 生成的 html 字符串：

def on_post_page(self, output, page, config):
 additional_html = self.template.render(pages=self.blog_pages, ...)

 output = re.sub(
 r"\{\{\s*blog_content\s*\}\}",
 additional_html,
 output,
 flags=re.IGNORECASE,
 )

 return output

就基本上完成了所有的工作。

总结

上面所述的仅仅是插件开发中一些枝干的问题，实际上，做一个工程，而不仅是自己用的小软件，要考虑的问题远不止于怎么实现功能，不仅要尽可能满足用户的需求，还要处理各种 corner cases（~~测试工程师进酒吧~~）。当然，造轮子虽然难，但是其中的快乐是无穷的。

用 Property Wrapper 包装网络请求参数

liang2kl@outlook.com (Liang Yesheng) — Sat, 28 Aug 2021 00:00:00 +0800

偶然看到 Java 语言 Retrofit 库的文档，对这种标注 HTTP 请求参数的方式十分感兴趣（其实我也没学过 Java）：

@FormUrlEncoded
@POST("user/edit")
Call<User> updateUser(@Field("first_name") String first, @Field("last_name") String last);

联想一下以前用 Swift 写的网络请求（参考协议 + 泛型：威力巨大的组合），都需要手动赋值参数，实在是不太优雅：

let headers: HTTPHeaders = [
 "TOKEN": self.configuration.token,
 "Accept": "application/json"
]

let parameters: [String : Encodable] = [
 "pid" : self.configuration.postId,
 "switch": self.configuration.switchToAttention ? 1 : 0,
]

Java 的这种语法与 Swift 的 Property Wrapper 很像（实践证明 Swift 这个语法局限性还是挺大的），~~而且逼格也非常高~~ ，恰好也一直想自己写个 Property Wrapper 玩一玩研究一下，于是就动手写一个包装网络请求参数的库。

理想效果

理想中，对参数的包装应该达到的效果有：

用 Property Wrapper 包装实际的参数值和对应的 key

struct SomeRequest: Request {
 @Header("TOKEN") var accessToken
 @Field("page") var page: Int
 @Field("foo") var bar: String
 ...
}

能够自动找到所有的参数，并将其放入 HTTP 请求中

目标有了，就开始写吧！

设计与实现

包装参数

我们的 Property Wrapper 中需要 key 和 value。尝试写一下 @Query：

@propertyWrapper
struct Query<Value: Encodable> {
 var key: String
 var wrappedValue: Value

 init(wrappedValue: Value, _ key: String) {
 self.key = key
 self.wrappedValue = wrappedValue
 }
}

@Query 接受 String 作为 key，和一个遵循 Encodable 协议的值作为 value。

可是，当我们尝试使用这个 Property Wrapper 的时候，却出现了问题：

@Query("foo") var bar: Int

这样写会出现编译错误：

Missing argument for parameter 'wrappedValue' in call

原因在于，@Query("foo") var bar: Int 的声明其实是在调用 Query<Int> 的 init(wrappedValue: Value, _ key: String)，而 Swift 不允许存在未初始化的成员变量，所以必须同时初始化 key 和 wrappedValue：

@Query("foo") var bar: Int = 1

但是，总不能要求调用者每种类型都给出个默认值……这样实在是太丑陋了，也不符合语义—— @Query("foo") 声明 key，value 应该是之后赋值的。而且也不现实，如果 wrappedValue 是一个自定义类型的话，提供默认值是一件匪夷所思的事情。

没办法，Property Wrapper 括号中的参数并不是严格意义上静态的 attribute，而是一个函数的参数，是一个变量，这本来就是和我们的需求相背的。

那么，退而求其次，既然不能要求提供默认值，那我们可以用一种不会产生歧义的、带有默认初始化方法的变量—— Optional：

@propertyWrapper
struct Query<Value: Encodable> {
 var key: String
 var wrappedValue: Value?

 init(wrappedValue: Value?, _ key: String) {
 self.key = key
 self.wrappedValue = wrappedValue
 }
}

这样一来，参数的声明就可以稍微合理一点了：

@Query("foo") var bar: Int? = nil

虽然我们还是要提供一个初始值，但是 nil 在这里刚好可以表达“未初始化”的意思，在以后解析所有参数的时候，如果这个值没有被设定，我们直接跳过这个请求参数就好了。

到这里，自然会想到在 init 中给 wrappedValue 设定 nil 的默认值，使得我们不需要手动写 = nil：

init(wrappedValue: Value? = nil, _ key: String)

这似乎解决了问题，我们可以这样写了：

@Query("foo") var bar: Int?

但是又多了一个问题：我们不能直接用 wrappedValue 初始化含有 @Query 变量的类型了，如：

struct Foo {
 @Query("foo") var bar: Int?
}

// let foo = Foo(bar: 1)
// Cannot convert value of type 'Int' to expected argument type 'Query<Int>'

用一个例子测试一下 Property Wrapper 初始化的原理：
struct A<Value: Encodable> {
 var key: String
 private var value: Value?
 public var wrappedValue: Value? {
 get { value }
 set { value = newValue; print(newValue) }
 }

 public init(wrappedValue: Value?, _ key: String) {
 self.key = key
 self.value = wrappedValue
 print("Initializing with wrappedValue \(wrappedValue), key \(key)")
 }
}

struct Test {
 @A("hello") var a: Int? = nil
}

let foo = Test()
let bar = Test(a: 1)
输出为：
Initializing with wrappedValue nil, key hello
Initializing with wrappedValue Optional(1), key hello
原来 @A 变量在 Test 的构造函数中无论是否赋值，都只会调用一次 @A 的 init。当我们不指定 a 的值的时候，使用我们提供的默认值 nil 进行初始化；当我们指定 a 的值的时候，使用我们指定的值。

所以，@Query("foo") var bar: Int? = nil 中 = nil 其实就相当于 init 的一个默认参数。这也解释了为何我们直接在 init 中设参数默认值使得无法用 wrappedValue 初始化。

所以，还是手动把 = nil 加上为妙。

获取信息

包装好了，怎么获取这些变量是另一个大问题。要知道，我们根本不知道传进来的对象是什么。例如，我们的 SomeRequest 中有这些参数：

struct SomeRequest {
 @Query("page") var page
 @Query("bar") var foo: Int? = nil
}

我们当然不知道 SomeRequest 中有 page 和 foo 两个成员。

幸好，我们有 Mirror ——利用对象的元数据，能够向我们提供对象成员变量的信息。¹

用 Mirror 尝试一下：

let mirror = Mirror(reflecting: request) // request is `SomeRequest`
for (_, property) in mirror.children {
 // property 是 request 的成员变量
}

我们可以通过这种方法访问 request 对象的所有成员变量。接下来的问题是，我们怎么识别是不是 @Query，以及怎么把 Query 里面的 key 和 wrappedValue 取出来。

一种很朴素，又很错误的想法是这样：

if let property = property as? Query {
 ...
}

这样当然通过不了编译，Query 只是个模版，不是具体的类。我们需要一种与 Query 模版参数无关的方法。

我们喜欢的 protocol 这时可以发挥作用了。我们不需要获取“property 具体的类型”这么强的信息，只需要这个 property 能够向我们提供我们需要的 URL 编码的 value 和 key 就行了。马上可以写一个协议：

protocol QueryProtocol {
 func urlEncodedKey() -> String
 func urlEncodedValue() -> String
}

我们给 Query 加上 QueryProtocol 的协议：

extension Query: QueryProtocol {
 func urlEncodedKey() -> String {
 return SomeURLStringEncoder().encode(key)
 }
 func urlEncodedValue() -> String {
 return SomeURLStringEncoder().encode(wrappedValue)
 }
}

这样，我们就可以用 Mirror 访问 key 和 value 了：

let mirror = Mirror(reflecting: request) // request is `SomeRequest`
for (_, property) in mirror.children {
 if let query = property as? QueryProtocol {
 let key = query.urlEncodedKey()
 let value = query.urlEncodedValue()

 // TODO: Add key, value to request URL.
 }
}

这样，最后一个障碍——读取参数信息也扫清了。我们可以获取到一个类里面所有的 @Query 参数了，将所有的 key 和 value 加到请求的 URL 即可。

实际上的处理要稍微复杂一点，因为 Value 可能是一个数组，这时候就不仅仅是一个 key 和 value 对了。

后续

根据相似的思路，我们可以为 Header、body 参数等定义类似的 Property Wrapper：

Property Wrapper	Description	Wrapped Value
`@Header`	HTTP Header	`String?`
`@HeaderDict`	An dictionary of headers	`[String : String]?`
`@Query`	Query parameters	`Encodable?`
`@QueryDict`	An dictionary of query parameters	`[String : String]?`
`@KeyQuery`	Query parameters with no value associated	`Bool`
`@JSON`	Body parameters with JSON encoding	`Encodable?`
`@Field`	Form URL Encoded parameters	`Encodable?`

我们可以在一个类声明中定义所有的请求参数了。最后的实现效果如下：

struct SetPushRequest: JSONDecodableRequest, RequestConfiguration {
 @Header("TOKEN") var accessToken = nil
 @Field("push_system_msg") var pushSystemMessage: Bool? = nil
 @Field("push_reply_me") var pushReplyMe: Bool? = nil
 @Field("push_favorited") var pushFavourite: Bool? = nil

 struct Response: Codable {
 var code: Int
 var msg: String?
 }

 let base: URL = URL(string: "https://dev-api.thuhole.com")!
 let path: String = "v3/config/set_push"
 let method: HTTPMethod = .post

 var configuration: Self { return self }
}

let request = SetPushRequest(accessToken: token, pushSystemMessage: true, pushReplyMe: true, pushFavourite: false)

request.perform { result in
 switch result {
 case .success(let response):
 print(response)
 case .failure(let error):
 print(error)
 }
}

SetPushRequest 的定义不计空行只用了 14 行。在原来树洞的代码中，完成上述功能写了 31 行（不包括上面代码不涉及的功能）。

项目源代码参见 liang2kl/APIKit（~~虽然还没写完~~）。

利用 Property Wrapper 包装参数，加上一些基本信息，就可以定义一个 HTTP 请求了。最重要的是，我们再也不需要手动设置 parameters 了。

Mirror | Apple Developer Documentation ↩︎

协议 + 泛型：威力巨大的组合

liang2kl@outlook.com (Liang Yesheng) — Thu, 26 Aug 2021 00:00:00 +0800

写树洞客户端时，和一个 PKU 的同学一起写，他负责写调用树洞 HTTP API 获取数据的部分。既然涉及到协作，就得先规定下接口了。

对于 Swift 来说，规定接口的最好的办法自然是 protocol ——规定并强制实现所有的接口。于是，我着手写这个协议的声明。

源代码参见 liang2kl/HollowCore。

协议的设计

目标

协议的设计有两个目标：

所有的请求均提供统一的接口，方便调用
尽可能方便不同的请求类复用代码

v1.0：最初尝试

接口无非是 输入 + 输出，对于网络请求，输入即是请求的参数，输出是得到的 response。很容易想到这样一个声明：

protocol Request {
 // 用网络请求参数初始化请求
 init(parameters: [String : String])
 // 开始请求
 func performRequest(completion: @escaping (String?, Error?) -> Void)
}

其中，init 接受一个字典作为输入，performRequest 接受一个回调函数，异步处理数据。

乍看之下，似乎没什么问题——调用者只需要将参数的字典传进去，然后接收 JSON 格式的 String 字符串就行了。不过，这个设计真的合理吗？

仔细分析，这个版本的协议存在这些问题：

调用者的输入 parameters: [String : String] 没有受到任何限制，导致：
- 调用者在每次调用时都需要查看文档以确定需要传哪些参数
- 被调用者需要繁琐地一一检查字典的 key 和 value 是否符合要求
直接返回原始的 JSON 字符串，每次调用后均需要解析

问题的根本在于，完成网络请求的类并不知道任何关于请求本身的具体信息。我们需要向类提供这些信息，使得类只接受符合规定的输入，并提供解析好的、符合规定的输出。而且，完成这个目标最好是依赖编译期进行静态的检查，避免可能出现的失误。朝着这个目标，我们来写 2.0 版本。

v2.0：添加请求信息

我们需要向 Request 协议内添加参数、输出的信息。

首先考虑传递参数的问题。一个朴素的想法是在 init 中分别列出参数，如：

init(token: String, page: Int, ...)

但是这就违背了我们**「提供一个统一的接口」**的宗旨。理想情况下，我们应该提供这样一个接口：

init(configuration: Configuration)

其中，Configuration 包装了所有需要的参数，这通常使用 struct 完成。

但是，不同请求的 Configuration 是不一样的，该怎么办？

幸运的是，protocol 支持“泛型”，我们只需要针对不同的请求定义不同的 Configuration 类就可以了。同理，每个请求应该有对应的 Response 类型。另外，为了方便处理错误，添加一个 Error 类型，其遵循 Swift 中 Error 协议，用来指定具体的错误。新的设计如下：

protocol Request {
 associatedtype Configuration
 associatedtype Response
 associatedtype Error: Swift.Error

 // 储存参数信息
 var configuration: Configuration { get set }

 init(configuration: Configuration)
 func performRequest(completion: @escaping (Response?, Error?) -> Void)
}

我们可以开始实现具体的请求了。比如，对于编辑收藏的请求：

struct EditAttentionRequest: Request {
 struct Configuration {
 var token: String
 var postId: Int
 var switchToAttention: Bool
 }

 struct Response {
 // 暂时省略
 ...
 }

 enum Error: Swift.Error {
 case tokenExpired,
 case ...
 }

 var configuration: Configuration

 init(configuration: Configuration) {
 self.configuration = configuration
 }

 func performRequest(completion: @escaping (Response?, Error?) -> Void) {
 let urlPath = "v3/edit/attention"
 ...
 }
}

这样，对于调用者来说就轻松很多了，不再需要翻文档来传参数，也不需要自己来解析 JSON 字符串，只需要根据 Configuration 的构造函数传递参数，并利用得到的 Response 即可：

let configuration = EditAttentionRequest.Configuration(...)
let request = EditAttentionRequest(configuration: configuration)

request.performRequest { response, error in
 ...
}

这个版本的 Request 基本上实现了我们设计一个统一接口的目标。

v2.1：Response 的界定

注意到上面的 EditAttentionRequest 中省略了 Response 的定义。我们需要明确 Response 是什么。

从调用者的角度，Response 应该是可以直接利用，而不需要再进行处理的数据；而从请求本身的角度，Response 指的是服务器返回的 JSON 字符串解析出来的对象。但是，这两个概念并不总是一样的：服务器返回的结果往往需要进一步处理，比如指示请求状态的 code，错误信息 msg 等。

于是，Response 的概念需要分成两部分：服务器返回的结果 Result，和处理后最终返回的可以直接使用的数据 ResultData：

protocol Request {
 associatedtype Configuration
 associatedtype Result
 associatedtype ResultData
 associatedtype Error: Swift.Error

 init(configuration: Configuration)
 func performRequest(completion: @escaping (ResultData?, Error?) -> Void)
}

相对应地，EditAttentionRequest 中 Result 和 ResultData 分别定义为：

struct Result: DefaultRequestResult {
 var code: Int
 var msg: String?
 var data: Post?
}

typealias ResultData = Post

在编辑完关注状态后，服务器会返回完整的树洞信息 Post，以及 code 和 msg。我们不需要 code 和 msg（错误已经在请求内部处理），于是 Post 作为 ResultData 就可以了。

定义 Result 类型是很有必要的：我们一般直接使用 JSONDecoder 将 JSON 反序列化为对象，这需要我们提供解析的模版，即 Result。

至此，我们的协议声明已经基本上完成了。所有遵循 Request 协议的类型都对外提供了统一的接口，并且利用泛型实现了对参数输入、服务器返回数据、最终输出和错误的严格规定。

代码复用与接口扩展

上面我们花了大力气来规定 Request 的各种类型，但除了统一了接口、约束输入输出外并没有什么特别的作用。实际上，协议 + 泛型的巨大威力体现在代码复用和接口扩展上。

代码复用

上面的 Request 只是规定了接口，我们还要逐一实现每个请求的 performRequest。如果分别独立写 HTTP 请求代码，将十分繁琐，而且会大量重复相同代码。为此，我们需要进行一些默认实现。

大多数请求满足两个共性：

从 JSON 反序列化为对象的要求很简单：Result 类型遵循 Decodable 即可。对于这些请求，由获得的 JSON 生成 Result 的方法是固定的。
返回包括 code 和 msg，用来传递查询结果和错误信息。因此，从 Result 生成 Error 的方法是固定的。而大多数的 Error 类型也是相同的。

利用这两点，我们可以在 Request 的基础上，针对这些请求进行 performRequest 的默认实现。对这些请求，我们定义一个新的协议 DefaultRequest，遵循 Request：

protocol DefaultRequest: Request
 where Error == DefaultRequestError, Result: DefaultRequestResult { }

Error 为 DefaultRequestError，是一个涵盖了所有错误类型的 enum：

enum DefaultRequestError: Swift.Error, LocalizedError {
 case decodeFailed
 case tokenExpiredError
 case fileTooLarge
 case unknown
 case noSuchPost
 case other(description: String)

 init(errorCode: Int, description: String?) {...}
}

Result 遵循 DefaultRequestResult，其定义如下：

protocol DefaultRequestResult: Codable {
 var code: Int { get }
 var msg: String? { get }
}

分别对应上述两个共同点。

于是，我们就可以进行 performRequest 的默认实现了。在 DefaultRequest 的 extension¹ 中：

extension DefaultRequest {
 func performRequest(
 urlRoot: String,
 urlPath: String,
 parameters: [String : Any]? = nil,
 headers: HTTPHeaders? = nil,
 method: HTTPMethod,
 transformer: @escaping (Result) -> ResultData?,
 completion: @escaping (ResultData?, Error?) -> Void
 ) {...}
}

在函数内，我们需要实现：

将网络请求得到的 JSON 反序列化为对象，由 DefaultRequestResult 遵循 Codable 满足

let jsonDecoder = JSONDecoder()
let result = try jsonDecoder.decode(Result.self, from: data)

将 Result 中包含的错误信息转化为 Error 返回，由 Error 类型已知以及 DefaultRequestResult 中要求 code 和 msg 满足
```
let error = DefaultRequestError(errorCode: result.code, description: result.msg)
```

将 Result 转化为 ResultData，由传入的参数 transformer 提供

if let data = transformer(result) {
 completion(data, nil)
}

我们在对 protocol 的泛型作了一定的约束后，获得了更多的信息，使得我们可以在不知道请求的具体类型的情况下进行默认实现。

完整代码如下：

func performRequest(
 urlRoot: String,
 urlPath: String,
 parameters: [String : Any]? = nil,
 headers: HTTPHeaders? = nil,
 method: HTTPMethod,
 transformer: @escaping (Result) -> ResultData?,
 completion: @escaping (ResultData?, Error?) -> Void
) {
 AF.request(
 urlRoot + urlPath,
 method: method,
 parameters: parameters,
 encoding: URLEncoding.default,
 headers: headers
 )
 .validate()
 .responseJSON { response in
 switch response.result {
 case .success:
 let jsonDecoder = JSONDecoder()
 jsonDecoder.keyDecodingStrategy = .convertFromSnakeCase
 do {
 guard let data = response.data else {
 completion(nil, .unknown)
 return
 }
 let result = try jsonDecoder.decode(Result.self, from: data)
 if result.code >= 0 {
 // result code >= 0 valid!
 if let data = transformer(result) {
 completion(data, nil)
 } else {
 completion(nil, .unknown)
 }
 } else {
 let error = DefaultRequestError(errorCode: result.code, description: result.msg)
 completion(nil, error)
 return
 }

 } catch {
 completion(nil, .decodeFailed)
 return
 }

 case let .failure(error):
 if let errorCode = error.responseCode, errorCode == 413 {
 completion(nil, .fileTooLarge)
 return
 } else {
 completion(nil, .other(description: error.localizedDescription))
 return
 }
 }
 }
}

现在，我们可以轻松实现具体类型的 performRequest 了，如 EditAttentionRequest：

func performRequest(completion: @escaping (ResultData?, Error?) -> Void) {
 let urlPath = "v3/edit/attention" + Constants.urlSuffix

 let headers: HTTPHeaders = [
 "TOKEN": self.configuration.token,
 "Accept": "application/json"
 ]

 let parameters: [String : Encodable] = [
 "pid" : self.configuration.postId,
 "switch": self.configuration.switchToAttention ? 1 : 0,
 ]

 performRequest(
 urlRoot: self.configuration.apiRoot,
 urlPath: urlPath,
 parameters: parameters,
 headers: headers,
 method: .post,
 transformer: { $0.data },
 completion: completion
 )
}

我们只需要将 Configuration 转换为字典就可以了。在实际项目中，几乎所有的请求都可以遵循 DefaultRequest，只需要写一次网络请求的代码，就可以实现所有的网络请求。这就是 protocol + 泛型 + 限制条件的魅力。

接口扩展

利用 protocol 的泛型，还有个好处在于扩展接口十分方便。例如，针对 Swift 5.5 的 async/await，我们很容易为 Request 添加异步接口：

extension Request {
 func result() async -> (ResultData?, Error?) {
 return await withCheckedContinuation { continuation in
 performRequest { result in
 continuation.resume(returning: result)
 }
 }
 }
}

几乎不需要写任何代码。

总结

Swift 的 protocol 相当于 C++ 的抽象类，不过相比 C++ 更加严谨、灵活。protocol 本身有规定接口的功能，再加上泛型，能够很好地实现多态，实现高效的代码复用，同时保持良好的可维护性和可扩展性。

Protocols — The Swift Programming Language (Swift 5.5) ↩︎

#travel #death-valley #national-park

DateTimeOriginal	2025:03:20 16:06:28
Make	SONY
Model	ILCE-6300
LensModel	E 55-210mm F4.5-6.3 OSS
FocalLength	55.0
ExposureTime	0.0025
FNumber	11.0
ISOSpeedRatings	100
Software	Adobe Photoshop Lightroom Classic 14.1.1 (Macintosh)

Gallery

liang2kl@outlook.com (Liang Yesheng) — Mon, 01 Jan 0001 00:00:00 +0000

< All Photos

Mesquite Flat Sand Dunes (Death Valley National Park)

#travel #death-valley #national-park

DateTimeOriginal	2025:03:20 18:24:41
Make	SONY
Model	ILCE-6300
LensModel	E 55-210mm F4.5-6.3 OSS
FocalLength	55.0
ExposureTime	0.00025
FNumber	8.0
ISOSpeedRatings	3200
Software	Adobe Photoshop Lightroom Classic 14.1.1 (Macintosh)

approximated

Gallery

liang2kl@outlook.com (Liang Yesheng) — Mon, 01 Jan 0001 00:00:00 +0000

< All Photos

Zabriskie Point (Death Valley National Park)

#travel #death-valley #national-park

DateTimeOriginal	2025:03:21 06:52:48
Make	SONY
Model	ILCE-6300
LensModel	E 55-210mm F4.5-6.3 OSS
FocalLength	55.0
ExposureTime	0.05
FNumber	4.5
ISOSpeedRatings	100
Software	Adobe Photoshop Lightroom Classic 14.1.1 (Macintosh)

approximated

Gallery

liang2kl@outlook.com (Liang Yesheng) — Mon, 01 Jan 0001 00:00:00 +0000

< All Photos

Tunnel View (Yosemite National Park)

#travel #yosemite #national-park #sierra

DateTimeOriginal	2025:06:15 07:48:50
Make	SONY
Model	ILCE-6300
LensModel	E PZ 16-50mm F3.5-5.6 OSS
FocalLength	26.0
ExposureTime	0.004
FNumber	8.0
ISOSpeedRatings	100
Software	Adobe Photoshop Lightroom Classic 14.1.1 (Macintosh)

approximated

Gallery

liang2kl@outlook.com (Liang Yesheng) — Mon, 01 Jan 0001 00:00:00 +0000

< All Photos

Point Imperial (Grand Canyon National Park)

#travel #grand-canyon #national-park

DateTimeOriginal	2025:06:18 07:49:36
Make	SONY
Model	ILCE-6300
LensModel	E PZ 16-50mm F3.5-5.6 OSS
FocalLength	50.0
ExposureTime	0.003125
FNumber	8.0
ISOSpeedRatings	100
Software	Adobe Photoshop Lightroom Classic 14.1.1 (Macintosh)

approximated

Gallery

liang2kl@outlook.com (Liang Yesheng) — Mon, 01 Jan 0001 00:00:00 +0000

< All Photos

Navajo Loop Trail (Bryce Canyon National Park)

#travel #bryce-canyon #national-park

DateTimeOriginal	2025:06:20 12:23:01
Make	SONY
Model	ILCE-6300
LensModel	E PZ 16-50mm F3.5-5.6 OSS
FocalLength	16.0
ExposureTime	0.004
FNumber	7.1
ISOSpeedRatings	100
Software	Adobe Photoshop Lightroom Classic 14.1.1 (Macintosh)

approximated

Gallery

liang2kl@outlook.com (Liang Yesheng) — Mon, 01 Jan 0001 00:00:00 +0000

< All Photos

Landscape Arch (Arches National Park)

#travel #arches #national-park

DateTimeOriginal	2025:06:21 08:37:01
Make	SONY
Model	ILCE-6300
LensModel	E PZ 16-50mm F3.5-5.6 OSS
FocalLength	16.0
ExposureTime	0.003125
FNumber	7.1
ISOSpeedRatings	100
Software	Adobe Photoshop Lightroom Classic 14.1.1 (Macintosh)

approximated

Gallery

liang2kl@outlook.com (Liang Yesheng) — Mon, 01 Jan 0001 00:00:00 +0000

< All Photos

Taggart Lake Loop Trail (Grand Teton National Park)

#travel #grand-teton #national-park

DateTimeOriginal	2025:06:25 07:17:17
Make	SONY
Model	ILCE-6300
LensModel	E PZ 16-50mm F3.5-5.6 OSS
FocalLength	50.0
ExposureTime	0.005
FNumber	5.6
ISOSpeedRatings	100
Software	Adobe Photoshop Lightroom Classic 14.1.1 (Macintosh)

approximated

Gallery

liang2kl@outlook.com (Liang Yesheng) — Mon, 01 Jan 0001 00:00:00 +0000

< All Photos

Taggart Lake (Grand Teton National Park)

#travel #grand-teton #national-park

DateTimeOriginal	2025:06:25 07:22:09
Make	SONY
Model	ILCE-6300
LensModel	E PZ 16-50mm F3.5-5.6 OSS
FocalLength	20.0
ExposureTime	0.01
FNumber	8.0
ISOSpeedRatings	100
Software	Adobe Photoshop Lightroom Classic 14.1.1 (Macintosh)

approximated

Gallery

liang2kl@outlook.com (Liang Yesheng) — Mon, 01 Jan 0001 00:00:00 +0000

< All Photos

Artist Point (Yellowstone National Park)

#travel #yellowstone #national-park

DateTimeOriginal	2025:06:27 17:12:35
Make	SONY
Model	ILCE-6300
LensModel	E 55-210mm F4.5-6.3 OSS
FocalLength	55.0
ExposureTime	0.005
FNumber	5.6
ISOSpeedRatings	100
Software	Adobe Photoshop Lightroom Classic 14.1.1 (Macintosh)

#arches #bayarea #bryce-canyon #death-valley#formula1#grand-canyon #grand-teton #hwy1 #london #national-park #polaroid #san-diego #sierra #singapore #travel #yellowstone #yosemite

Chinese GP 2024 Race - GS A
Shanghai, 2024/4/21

Chinese GP 2024 Sprint - GS A
Shanghai, 2024/4/20

Chinese GP 2024 Free Practice - GS H
Shanghai, 2024/4/19

Singapore GP Pit Lane
Singapore, 2023/9/14

Gallery

liang2kl@outlook.com (Liang Yesheng) — Mon, 01 Jan 0001 00:00:00 +0000

< All Photos

Taggart Lake Loop Trail
Grand Teton National Park, 2025/6/25

Landscape Arch
Arches National Park, 2025/6/21

Navajo Loop Trail
Bryce Canyon National Park, 2025/6/20

Point Imperial
Grand Canyon National Park, 2025/6/17

Tunnel View
Yosemite National Park, 2025/6/14

Zabriskie Point
Death Valley National Park, 2025/3/21

Mesquite Flat Sand Dunes
Death Valley National Park, 2025/3/20

Badwater Basin
Death Valley National Park, 2025/3/20

Artist's Palette
Death Valley National Park, 2025/3/20

Joshua Tree National Park
Twentynine Palms, 2025/1/15

Gallery

liang2kl@outlook.com (Liang Yesheng) — Mon, 01 Jan 0001 00:00:00 +0000

< All Photos

#polaroid

2025/3/20 - 2025/3/20

#arches #bayarea #bryce-canyon #death-valley #formula1 #grand-canyon #grand-teton #hwy1 #london #national-park#polaroid#san-diego #sierra #singapore #travel #yellowstone #yosemite

Mesquite Flat Sand Dunes
Death Valley National Park, 2025/3/20

Gallery

liang2kl@outlook.com (Liang Yesheng) — Mon, 01 Jan 0001 00:00:00 +0000

< All Photos

#san-diego

2024/12/10 - 2025/1/14

#arches #bayarea #bryce-canyon #death-valley #formula1 #grand-canyon #grand-teton #hwy1 #london #national-park #polaroid#san-diego#sierra #singapore #travel #yellowstone #yosemite

Sunset Cliff
San Diego, 2025/1/14

Torrey Pines State Reserve
San Diego, 2025/1/7

Torrey Pines State Reserve
San Diego, 2024/12/10

Gallery

liang2kl@outlook.com (Liang Yesheng) — Mon, 01 Jan 0001 00:00:00 +0000

< All Photos

#sierra

2025/6/14 - 2026/9/13

#arches #bayarea #bryce-canyon #death-valley #formula1 #grand-canyon #grand-teton #hwy1 #london #national-park #polaroid #san-diego#sierra#singapore #travel #yellowstone #yosemite

Convict Lake
Eastern Sierra, 2026/9/13

Tunnel View
Yosemite National Park, 2025/6/14

Gallery

liang2kl@outlook.com (Liang Yesheng) — Mon, 01 Jan 0001 00:00:00 +0000

< All Photos

#singapore

2023/7/30 - 2023/9/14

#arches #bayarea #bryce-canyon #death-valley #formula1 #grand-canyon #grand-teton #hwy1 #london #national-park #polaroid #san-diego #sierra#singapore#travel #yellowstone #yosemite

Singapore GP Pit Lane
Singapore, 2023/9/14

Merlion Park
Singapore, 2023/8/9

Gardens by the Bay
Singapore, 2023/7/30

Gallery

liang2kl@outlook.com (Liang Yesheng) — Mon, 01 Jan 0001 00:00:00 +0000

< All Photos

#travel

2023/7/30 - 2026/9/13

#arches #bayarea #bryce-canyon #death-valley #formula1 #grand-canyon #grand-teton #hwy1 #london #national-park #polaroid #san-diego #sierra #singapore#travel#yellowstone #yosemite

Convict Lake
Eastern Sierra, 2026/9/13

Niles Boulevard
Niles, 2026/5/24

Soberanes Point
Highway 1, 2026/5/20

McWay Falls
Highway 1, 2026/5/20

Big Ben
London, 2026/4/17

Artist Point
Yellowstone National Park, 2025/6/27

Taggart Lake
Grand Teton National Park, 2025/6/25

Taggart Lake Loop Trail
Grand Teton National Park, 2025/6/25

Landscape Arch
Arches National Park, 2025/6/21

Navajo Loop Trail
Bryce Canyon National Park, 2025/6/20

Point Imperial
Grand Canyon National Park, 2025/6/17

Tunnel View
Yosemite National Park, 2025/6/14

Zabriskie Point
Death Valley National Park, 2025/3/21

Mesquite Flat Sand Dunes
Death Valley National Park, 2025/3/20

Badwater Basin
Death Valley National Park, 2025/3/20

Artist's Palette
Death Valley National Park, 2025/3/20

Joshua Tree National Park
Twentynine Palms, 2025/1/15

Sunset Cliff
San Diego, 2025/1/14

Torrey Pines State Reserve
San Diego, 2025/1/7

Torrey Pines State Reserve
San Diego, 2024/12/10

Merlion Park
Singapore, 2023/8/9

Gardens by the Bay
Singapore, 2023/7/30

Gallery

liang2kl@outlook.com (Liang Yesheng) — Mon, 01 Jan 0001 00:00:00 +0000

< All Photos

#yellowstone

2025/6/27 - 2025/6/27

#arches #bayarea #bryce-canyon #death-valley #formula1 #grand-canyon #grand-teton #hwy1 #london #national-park #polaroid #san-diego #sierra #singapore #travel#yellowstone#yosemite

Artist Point
Yellowstone National Park, 2025/6/27

Gallery

liang2kl@outlook.com (Liang Yesheng) — Mon, 01 Jan 0001 00:00:00 +0000

< All Photos

#yosemite

2025/6/14 - 2025/6/14

#arches #bayarea #bryce-canyon #death-valley #formula1 #grand-canyon #grand-teton #hwy1 #london #national-park #polaroid #san-diego #sierra #singapore #travel #yellowstone#yosemite

Tunnel View
Yosemite National Park, 2025/6/14

Gallery

liang2kl@outlook.com (Liang Yesheng) — Mon, 01 Jan 0001 00:00:00 +0000

All Photos

Map >

#arches #bayarea #bryce-canyon #death-valley #formula1 #grand-canyon #grand-teton #hwy1 #london #national-park #polaroid #san-diego #sierra #singapore #travel #yellowstone #yosemite

Convict Lake
Eastern Sierra, 2026/9/13

Niles Boulevard
Niles, 2026/5/24

Soberanes Point
Highway 1, 2026/5/20

McWay Falls
Highway 1, 2026/5/20

Big Ben
London, 2026/4/17

Artist Point
Yellowstone National Park, 2025/6/27

Taggart Lake
Grand Teton National Park, 2025/6/25

Taggart Lake Loop Trail
Grand Teton National Park, 2025/6/25

Landscape Arch
Arches National Park, 2025/6/21

Navajo Loop Trail
Bryce Canyon National Park, 2025/6/20

Point Imperial
Grand Canyon National Park, 2025/6/17

Tunnel View
Yosemite National Park, 2025/6/14

Zabriskie Point
Death Valley National Park, 2025/3/21

Mesquite Flat Sand Dunes
Death Valley National Park, 2025/3/20

Badwater Basin
Death Valley National Park, 2025/3/20

Artist's Palette
Death Valley National Park, 2025/3/20

Joshua Tree National Park
Twentynine Palms, 2025/1/15

Sunset Cliff
San Diego, 2025/1/14

Torrey Pines State Reserve
San Diego, 2025/1/7

Torrey Pines State Reserve
San Diego, 2024/12/10

Chinese GP 2024 Race - GS A
Shanghai, 2024/4/21

Chinese GP 2024 Sprint - GS A
Shanghai, 2024/4/20

Chinese GP 2024 Free Practice - GS H
Shanghai, 2024/4/19

Singapore GP Pit Lane
Singapore, 2023/9/14

Merlion Park
Singapore, 2023/8/9

Gardens by the Bay
Singapore, 2023/7/30

关于

liang2kl@outlook.com (Liang Yesheng) — Mon, 01 Jan 0001 00:00:00 +0000

关于我

在这些地方读过书：

THU 计算机科学与技术，学士学位
UCSD Master in Computer Science and Engineering (in prgress)

喜欢：

iOS 开发、前后端、高性能计算、其他任何有意思的技术
看足球（巴萨）
看 F1（主要是看乐子）
玩游戏
听 Coldplay
皮克斯动画
一些美剧（如寻妈记、老友记、Severance）
一点点摄影
大多数 Apple 产品

编程语言：

非常熟练：
比较熟练：

项目

Whiz Reader

iOS App
闭源｜App Store 链接
2020.4 至今（其实很久没有维护了）

第一个项目，C++ 都还没学会的时候的产物。一个英文阅读器，支持点击查词、划词实时翻译等，本来想的是写来看生物原版教材，没想到最终让我来到了计算机系。用的人还不少，也赚了一点小钱。

libftm

Linux 程序
开源｜GitHub 链接
2020.12 - 2021.1

参加软院 SRT 时候写的程序，用 Wi-Fi 网卡进行测距/定位，花了不少时间。实现基本上是抄 iw 的。SRT 最后无疾而终，但是学会了不少 Linux 知识。

treehollow-v3-ios

iOS App
开源｜GitHub 链接
2021.1 - 2021.12

树洞 iOS 客户端。写过的规模最大、用户最多的的项目，可惜无法继续更新了。写的过程中学会了不少东西，算是很有收获。

wechat-avatar-frame

微信小程序
开源｜GitHub 链接
2021.4

给机械系学生节做的头像框小程序，1 天速成。后来人文学院和航院也用了。微信提供的接口还挺好用，就是文档写得一塌糊涂。

wqxuetang-downloader

Chrome 插件
开源｜GitHub 链接
2021.4

用来下载文泉学堂图片的 Chrome 插件。因为是直接操作浏览器，比一般的爬虫有效。

HollowCore

Swift Package
开源｜GitHub 链接
2021.6-2021.9

树洞网络请求库，目的是将网络请求代码和树洞客户端解耦。当时，为了用这个库，重构客户端花了不少时间。

Museum+

iOS App
闭源｜中文文档链接
2021.7 - 2021.8

苹果移动应用创新赛的参赛作品，利用 AR 增强博物馆游览体验，可以通过手机屏幕对艺术品实现精确、详细、可互动的讲解。没想明白为什么只拿了赛区二等奖。

Pasteboard

macOS App
开源｜GitHub 链接｜App Store 链接
2021.8

一个简单的记录剪贴板记录的状态栏程序，摆脱用备忘录临时记录的方法。起因是某同学在更新到 Windows 11 后很喜欢新的剪贴板功能，向我安利，然后我就想着给 macOS 写一个。实现很简陋，性能不太行，不过记录纯文本够用。

chess

Qt App
开源｜GitHub 链接
2021.8

小学期 Qt 大作业，支持双人联机对战的军棋游戏。纯代码实现，使用 MVVM 架构。

bilibili-crawler

Python + Django + React
开源｜GitHub 链接
2021.8

小学期爬虫 + 后端 + 前端大作业，爬取 B 站上的视频信息然后展示出来。超级大杂烩。

mkdocs-blogging-plugin

Mkdocs 插件
开源｜GitHub 链接
2021.9 至今

使用 Mkdocs 建博客的插件，支持自动生成博客页面、使用模版进行自定义等。目前为止在 GitHub 上 star 最多、issue 最多的项目。在 GitHub 上和外国友人/国内同胞交流还挺有意思的。

swiftui-tutorial

教程
在线｜网页链接
2022.1

为计算机系学生科协技能引导文档编写的 SwiftUI 入门教程。自我感觉写得还不错。

config-service

Go 服务器程序
开源｜GitHub 链接
2022.3 - 2022.5

字节提供的软件工程课程大作业项目，实现一个通过执行动态语言程序来动态返回应用配置的平台。

deploy-tool

Go 服务器程序
开源｜GitHub 链接
2022.5

软工最后一次组会之前软工平台不出所料地崩了，于是把我们的项目用 docker-compose 部署到了宿舍的电脑上，通过 ddns 访问（其实完全是想玩一下，因为我们当时已经写完代码，不需要再次部署在软工平台了）。想着每次 push 之后需要手动 git pull 和 docker-compose up 挺麻烦，于是写了个小后端来做这件事。

swiftui-wwdc22

SwiftUI 程序
开源｜GitHub 链接
2022.6

对 WWDC22 发布的 SwiftUI 新 API 的探索。

docker-tutorial

教程
在线｜网页链接
2022.7

在计算机系学生科协暑培上作为讲师介绍 Docker 的基本使用及原理。

simpledb

C++/Python 程序
开源｜GitHub 链接
2022.10 - 2023.1

数据库系统概论课程大作业，一个支持基础 SQL 的数据库管理系统（DBMS）。

riscv-lab

SystemVerilog
公开｜GitHub 链接
合作者｜王文琦田仁睿
2022.11 - 2022.12

计算机组成原理大作业，支持运行 uCore 操作系统的五级流水 RISC-V CPU。

minidecaf-compiler

C++ 程序
公开｜GitHub 链接
2022.9 - 2023.1

编译原理大作业，一个简单语言的简单编译器。

feiyue-database

Python 程序
开源｜GitHub 链接｜网页
2023.12 至今

把飞跃手册的案例结构化地存在数据库里，定期生成网页。这样的好处在于可以系统地整理申请情况，同时方便贡献。

juss-ticket

Python 脚本｜Go 后端｜React 前端
不公开｜不想被请喝茶
2024.3 - 2024.4

黄牛猖獗下，为了抢 F1 中国站的票写的抢票脚本，自己买到后加上了一个简单的后台系统和前端用来帮别人抢。抢票无法全流程自动化，因此和室友忙活了半个月。赚了一点小钱（至少相当于免费的三天 F1 票 + 住宿 + 交通）。

LaunchManager

macOS App
开源｜GitHub 链接
2024.12

一个方便管理 macOS 开机启动脚本的 GUI。

liang2kl's Blog

死亡谷国家公园自驾游记

准备

第一天：圣地亚哥到拉斯维加斯

第二天：游玩死亡谷

第三天：返程

2023 年终总结

照片中的 2023

感染新冠

九字班毕业

暑研 & 新加坡之旅

关于气候

到处玩玩

各种活动

朋友们

关于出国/暑研

关于游戏

关于音乐

总结的总结

2023 F1 新加坡大奖赛体验

周四：Pit Lane Experience

周六：三练，演唱会 & 排位赛

周日：正赛

记一次溜入 F1 新加坡大奖赛封闭区域的经历

起因

封闭的赛道

溜入封闭区域

赛道、维修区与围场

2022 年的一些记忆

编程

学习与科研

游戏

音乐

一些值得留念的瞬间

中国主流媒体视角与游戏产业发展的割裂——以《人民日报》游戏相关报道（1989-2021）为例

中国游戏产业发展的过程中，主流媒体的视角看向何处

什么造成了主流媒体与游戏产业发展的割裂

总结：如何看待主流媒体与游戏产业发展的割裂

2022 春季学期总结

WWDC22 Sessions 记录

Meet Swift Regex

Meet desktop class iPad

The SwiftUI cookbook for navigation

Hello Swift Charts

What’s new in SwiftUI

Window 和 Menu bar extras

Resizable sheets

其他

What’s new in UIKit

Compose custom layouts with SwiftUI

Grid

自定义布局

sizeThatFits

placeSubviews

传递额外信息

自适应布局

AnyLayout

Swift Charts: Raise the bar

Embrace Swift generics

Design protocol interfaces in Swift

Type erasure

Hide implementation details

关于 type(of:)

音乐剧 Come From Away 赏析

舞台设计

场景切换

道具

主题表现

其他

后记

协程上下文切换

上下文切换

调用栈结构

程序

例子 #1

例子 #2

汇编结果

Operating Systems: Three Easy Pieces 学习笔记（五）

26 Concurrency: An Introduction

26.1 Why Use Threads?

关于 `type(of:)`