我有台老款丐版 Mac Mini，硬盘只有 256GB，勉强凑合了好几年。日常只用来上下网，但时不时冒出的“磁盘空间不足”警告，着实让人头疼。每次空间告急，我都要去清一波数据，从文档到下载，上次甚至连 Xcode 和 Office 都删了，这电脑也称得上一句家徒四壁了。

昨天，我想下载个软件更新包，可试了好几次都下载失败。排除了网络问题后，我发现硬盘空间居然又满了！打开设置里的“储存空间”一看，好家伙，可用空间只剩不到 200MB，而“系统数据”竟然变本加厉占了整整 180GB！我实在是删无可删，无处可苟了。

幕后黑手

“系统数据”在家目录下主要是 ~/Library，一番排查后，我发现两个大头：

• ~/Library/Caches：缓存，随便删。
• ~/Library/Containers：macOS 应用的沙盒环境，这个不能直接删。

其中，~/Library/Containers 下面的 com.apple.mediaanalysisd 更是触目惊心，独占 130G，顶得上我电脑硬盘的半壁江山了。

研究了一番，我了解到这个目录主要是 macOS 在后台进行人脸识别、物体分类和 Spotlight 索引等工作时产生的缓存。照片图库越大，它的体积就越恐怖。虽然可以临时删除，但是它会随时间慢慢重建回来，治标不治本。鉴于它的体积，我只有把它挪走，这台电脑才能继续苟下去。

软链接

一开始，我的想法很简单：把这个目录挪到外置 SSD 上，然后在原地做一个软链接。但现实很骨感，~/Library/Containers 属于 macOS 的沙盒保护区域。为了防止恶意应用通过软链接访问敏感文件，系统对其做了严格的权限控制。因此，这个方法行不通。

挂载

问了下 ChatGPT，它提供了一个挂载的方案：将外置 SSD 上的一个分区直接挂载到 com.apple.mediaanalysisd 目录的位置，让系统以为它还在内置硬盘里。

1. 准备外置 SSD：用磁盘工具新建了一个 APFS 卷，命名为 MediaAnalysisVol。这是专门用来存储这个大缓存的。

2. 迁移数据：（可选，因为之后会重建）为了确保数据完整，先在终端里用 killall mediaanalysisd 关掉相关进程，然后用 rsync 命令行把 com.apple.mediaanalysisd 里的所有数据完整地复制到新卷里。rsync 是个好东西，它可以完整地保留文件权限、扩展属性等信息。

   rsync -aEHX --xattrs --protect-args ~/Library/Containers/com.apple.mediaanalysisd/ /Volumes/MediaAnalysisVol/
   

3. 清空原目录：将内置硬盘上的原目录内容删除，只保留一个空目录。

4. 挂载新卷：先用 diskutil list 找到新卷的设备名（例如 /dev/disk7s2），然后把其挂载到目标路径。

   sudo diskutil enableOwnership /dev/disk7s2
   sudo mount_apfs /dev/disk7s2 ~/Library/Containers/com.apple.mediaanalysisd
   

5. 开机自动挂载：为了避免每次开机都手动挂载，我们可以配置 /etc/fstab 文件。先用 diskutil info 找到新卷的 UUID，然后把挂载命令加到 fstab 里。

   UUID=12345678-ABCD-1234-ABCD-1234567890AB /Users/ahahaha/Library/Containers/com.apple.mediaanalysisd apfs rw 0 0
   

后续

现状良好，又可以苟一段时间了！

安装开关涉及强电，请务必注意人身安全并遵守当地法律法规！！！

楔子

去年搬家后，在新家里发现有三个前房主留下的智能开关，可以连WiFi的那种，样子平平，在墙上倒是不显突兀。拆下来发现是一个叫Gosund的牌子，正好当时正准备把家里的开关换成智能开关，也看了不少其他牌子，最后兜兜转转，还是去Temu上买了一些一样的。Amazon上其实也有，不过不知为何，名字已经换成了Ghome。

关于智能家居，我的目的很简单，就是能躺在床上用手机开关灯。由于我在家里已经部署了Home Assistant，这里只记录一下我是怎么把这些开关集成进来，并且导入Apple Home和Amazon Alexa里面的，关于Home Assistant的其他使用经验以后有机会可以继续分享。

基本思路

1. 把所有开关集成到Home Assistant里。
2. 选择一些实体（比如开关或灯）接入智能家居。
   1. Apple Home：由于家里人基本都是用的iPhone，我有一台Apple TV当家居中枢，Home Assistant里的设备可以用HomeKit Bridge集成接入过来，以供家里的苹果设备控制。
   2. Alexa：家里还有一些Echo Dot，关于如何接入Alexa，具体可以参考官方Amazon Alexa文档。我选用的是Emulated Hue集成，可以很方便的做到用Alexa语音控制开关灯。

集成到Home Assistant

说起类似的WiFi智能开关，不得不提一家叫涂鸦智能的公司，我猜他提供了一整套智能家居解决方案，厂商只需要集成他们的芯片并使用背后的涂鸦云，就可以很方便的把自己的设备变「智能」，并接入Alexa或者Google Home之类的智能家居平台。这种开关一搜一大把，本文内容也部分适用。

我第一次发现这个还是几年前用Costco买的一些Feit的智能灯泡，一开始一直使用Feit的官方App，后来偶然从Reddit上看到用一个叫「Tuya Smart」的App也可以控制这些设备，试用后发现界面都是一模一样的。再之后才得知这家叫「涂鸦」的公司。

闲话休提，言归正传。

Home Assistant官方的Tuya集成

如果想把这些开关集成到Home Assistant里，最简单的方法是使用官方的Tuya集成。

这部分Home Assistant的文档已经十分详细，不再赘述。

但是这种方式依然依赖涂鸦的服务器，从按下按钮到开关接通把灯点亮中间经过了网络请求，能明显感受到延迟。万一涂鸦的服务器挂了，我也不知具体会有什么后果。猜测

localtuya

秉持「本地优先」的原则，社区有很多优秀的集成可以跳过服务器直接和设备通信，我使用的是localtuya。主要区别是配置要复杂一些，需要注册涂鸦的账号并且获取设备密钥与ID，这部分文档也十分详细，同样不再赘述。

ESPHome

如果想彻底不依赖涂鸦的服务器，可以给这些设备刷自定义固件。涂鸦设备里面的芯片前几年主要是ESP8266，最近好多都换成了Beken的。ESP芯片可以刷ESPHome或者Tasmota，Beken的芯片同样有LibreTiny和OpenBeken，ESPHome在版本2023.9.0后也支持了LibreTiny。这些芯片都有留出UART引脚支持烧录程序。

使用Tasmota或者OpenBeken接入Home Assistant需要自己配置相应的MQTT节点，而ESPHome可以直接集成到Home Assistant里面，我直接刷的ESPHome固件。

准备工具

1. 烧录过程中需要往串口读写数据，最简单的方法是准备一个USB转TTL转换器，很便宜。
2. 把转换器引脚连到PCB板引脚上，烙铁使得好的可以自己焊，我电焊技术不行，用的跳线，BDM支架和探针，我要刷十几个开关，这样也比较方便。

设置好后大概是这个样子：

接线

首先拆开开关，找到烧录口。我买到的这些Gosund开关的型号是SW5-A-V2.1，芯片是Beken的BK7231N。开关背后使用4根螺丝固定，很容易拆开，具体拆解可以参考Elektroda的这个帖子，除了芯片是BK7231T，其余部分都是一样的。

按照LibreTiny文档，一般而言，BK7231芯片接线是这样的：

然后是供电，这个开关有一个好处是提供了一个5V的供电串口，用这个不仅可以给芯片供电，继电器也可以用，刷完固件可以立马验证结果，同时这根供电线可以接一个开关，对后续烧录时重启比较方便。按照下图接好线：

烧录过程

烧录工具我选择的是LibreTiny推荐的ltchiptool。ltchiptool是python写的，自带一个wxPython写的GUI程序，看文档感觉在Windows/Linux上应该很稳定，我在macOS上会经常崩溃，所以用的是命令行。

烧录过程：

1. 首先断电，从命令行执行烧录程序
2. 立马打开供电，芯片会进入烧录模式，我有时候要多试几次才能成功开始烧录

首先备份原厂固件，万一有用呢：

ltchiptool -v flash read -d /dev/cu.usbserial-B0010WQ0 -b 921600 bk7231n stock-dump.bin

/dev/cu.usbserial-B0010WQ0是USB转TTL转换器在电脑上显示的串口设备，最后备份的固件大概有2.1M。

ltchiptool还有一个插件可以分析原厂固件，自动生成ESPHome配置文件，但是这个设备的固件我试了分析不成功，我们需要自己配置。

这个开关提供了4个引脚可以控制：

• P7: LED指示灯，很亮的绿色，原厂固件是接通灯泡时会点亮
• P8: 按钮按下或者松开的状态
• P14: 继电器
• P16: 另外一个没那么亮的红色LED

以下是一份示范配置：

esphome:
  name: example-switch
  friendly_name: Example Switch

bk72xx:
  board: generic-bk7231n-qfn32-tuya

logger:

web_server:

captive_portal:

mdns:

api:

ota:

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  # 设备连不上WiFi时会启动这个热点，默认的热点名就是上面的friendly_name，我们可以连上去更新WiFi信息
  ap:
    password: "T4hIwT0aCesq"

# 重启按钮
button:
  - platform: restart
    name: Restart
    id: restart_button

debug:
  update_interval: 30s

text_sensor:
  - platform: debug
    reset_reason:
      name: Reset Reason
  - platform: libretiny
    version:
      name: LibreTiny Version

sensor:
  - platform: uptime
    name: Uptime
  - platform: wifi_signal
    name: "WiFi Signal"
    update_interval: 60s

uart:
  rx_pin: RX1
  tx_pin: TX1
  baud_rate: 9600

# Register the Tuya MCU connection
# tuya:

# Pins:
# - P7: LED指示灯，很亮的绿色，原厂固件是接通灯泡时会点亮
# - P8: 按钮按下或者松开的状态
# - P14: 继电器
# - P16: 另外一个没那么亮的红色LED

# 继电器开关
switch:
  - platform: gpio
    name: "Relay"
    id: relay
    pin: P14
    # 同步LED指示灯状态
    on_turn_on:
      - light.turn_on: led_indicator
    on_turn_off:
      - light.turn_off: led_indicator
    restore_mode: RESTORE_DEFAULT_OFF

# 使用红LED灯当ESPHome的状态
status_led:
  pin:
    number: 16
    inverted: true # 这个开关的状态是反的

# LED指示灯
light:
  - platform: binary
    name: "LED Indicator"
    id: led_indicator
    output: led_output
    restore_mode: RESTORE_DEFAULT_OFF

output:
  - id: led_output
    platform: gpio
    pin:
      number: 7
      inverted: true

# 按钮状态
binary_sensor:
  - platform: gpio
    name: "Button"
    pin:
      number: 8
      inverted: true
    # 短按接通电路
    on_click:
    - min_length: 50ms
      max_length: 350ms
      then:
        - switch.toggle: relay
    # 长按重启
    - min_length: 5000ms
      max_length: 10000ms
      then:
        - button.press: restart_button

在ESPHome里编译好uf2文件后，使用下面的命令行程序烧录到芯片里：

ltchiptool -v flash write -d /dev/cu.usbserial-B0010WQ0 -b 921600 example-switch.uf2

烧录好后等一会儿，开关就会连上WiFi，然后Home Assistant应该就能自动找到这个新的开关了。

生活

尘尘出生后，大部分时间是围着他转。过去一年依然如此，尘尘已经从年初蹒跚学步长到可以翻箱倒柜了，语言能力最近也终于突飞猛进，昨晚还在床上唱「一闪一闪亮晶晶」。

年初尘尘做了个切除Dermoid Cyst的小手术，当时看着他额角头发下3cm长的缝针口好心疼，还好尘尘就是别人口中的“天使尘尘”，手术完很快就不哭了，之后依然能吃能睡，恢复得还不错。

去年也开始给尘尘讲睡前故事，每天和苏苏轮流讲半个多小时，希望他早日养成自己鸡自己的好习惯。现在的小朋友好幸福啊，有各种各样的绘本，有些书我们都能津津有味看好久，最近尘尘最喜欢的是 Rotraut Susanne Berner 的 All Around Bustletown 系列，这套书细节十分丰富，可以翻来覆去给尘尘讲好多遍。

非常感谢岳父在前年7月我们鸡飞狗跳的时候来帮我们一把，当时边境还没开，他一个从没出远门的人，经由新加坡洗白，三番转机来西雅图，舟车劳顿，中途还进了两次海关小黑屋，牺牲特别大。他在这里一直帮忙到了3月，只可惜大部分时间是这里的雨季，没有带他多出去看看。尘尘和爷爷关系特别好，甚至爱屋及乌对其他小朋友的爷爷都更加亲近 🤣。

岳父回国后，尘尘就按计划去了离家不远的daycare。之前听说尘尘去daycare首先要生一个月病同步病毒库，一开始我们不以为然，以为尘尘长得结实，应该能免俗，然而现实好好教我们做了回人，他第一个月都在陆陆续续发烧，咳嗽，现在家中还常备几瓶泰诺，布洛芬。这也让我们更加深刻认识到尘尘是个普通人。尘尘刚开始去也不适应，每天哭得稀里哗啦，我们留了好多视频，印象最深刻的一个是尘尘一个人嘟着嘴站在窗户边落寞地看向外面，每次看起来都十分心疼，但是我们一直认为这是尘尘必须要跨出的一步，去daycare对尘尘发展也更好。现在好了，尘尘呆得很开心，每天daycare的报告上不是“happy today”就是“cheerful today”，早上去送的时候偶尔还会哭着要抱抱，基本上我们一出教室门就好了。

前房主不怎么管草坪，后面院子几乎快秃了，这个夏天心血来潮，把后面的草坪推了，买了车土铺上，重新种了新草。由于后院地势高，卡车上不去，土是用小推车一小车一小车推上去的，累得半死，但是看到新草慢慢发芽，渐渐长成绿油油的草坪（在收到水费账单之前）心情别提多欣慰。

夏天把后院前房主留下的烤炉清理出来了，其实也就冲了一下，几乎是新的。约朋友搞了好几次烧烤，大家一起在绿油油的新草坪旁串肉，烤肉，赶被烤肉吸引来的马蜂，夕阳西下，炊烟袅袅，十分安逸。顺手整理了一份菜谱，明年还可以继续。

除去烧烤，周末经常带着尘尘约各种小朋友在各种playground，公园，家里，海边，湖边，农场play date，尘尘年纪轻轻就有了好多小玩伴，不禁想起「郎骑竹马来，绕床弄青梅。同居长干里，两小无嫌猜。」这一年见证了尘尘第一次在海边泥巴里面挖贝壳，第一次在湖里划小船，第一次在回家山路上看夕阳，还有好多好多的第一次。

年底发现机票价格还行，帮妈妈买了机票来这边看看。5年没见了，印象中妈妈好像没那么唠叨 🤣。

旅游

经常和单身的朋友说，一定要趁着没有娃多出去旅游。去年只去了两次温哥华，一次波特兰。

第一次去温哥华是我们带尘尘单独去的，他超级兴奋，晚上也不好好睡，出去吃饭也到处跑，我和苏苏只能趁机吃几口，完全失去了众所周知去温哥华的最大乐趣——美食，第二天我们就电量耗尽草草回来了。第二次是和朋友家宝宝一起去的，小朋友互相消耗，我们倒是多逛了几个地方，还收获了一家叫「渔人」的好餐厅。

工作

过去一年工作上最大的变化是换了个工作，从后端回到了客户端方向。

入职不久经历了人生第一次出差，去自由女神像🗽打了个卡。只是不巧，尘尘在我刚到纽约就开始发烧了，宝宝一发烧就很闹，辛苦苏苏了，我回来的晚上两人都已经快断绝母子关系了 🤣。

受经济大环境影响，在经过两年找工市场的疯狂后，年中各个公司开始冻结招聘，到年底我见证了一波前所未见的裁员潮，团队里两个朋友也受了影响，这是我毕业以后第一次如此近距离接触经济衰退。明天经济大概率还会继续下行，希望大家苟住。

个人

宝宝出生之后，就几乎没有整段的时间，电影电视几乎不看了，游戏机也吃灰好久了。

今年看的电影，印象最深的有：

• 粤剧电影『白蛇传·情』，场景是真维美，戏曲是中国传统文化美学精神的集大成者，但是在现代文娱产品冲击下苟活不易，希望以后能有更好的发展。
• 纯沪语文艺片『爱情神话』，再也不是小清新的年纪了，这种烟火气十足的中年人爱情片更能看进去。
• 旧电影『剑雨』，特别喜欢的一部武侠片，居然是2010年的片子了。富含诗意的武打场景，一部充满了细碎生活场景的，非常不“武侠”的武侠片。

书也看得少，除了给宝宝读的童话书绘本，就读完了这几本：

• 『1984』：终于看完了这部书，背脊发凉。曾经听说过一个说法，未来的世界，要么是『1984』的，要么是『美丽新世界』的。感觉人类到不了星辰大海就被把自己搞死。
• 『筚路维艰』：现在读新中国初期的各种运动，气息十分熟悉。国家机器下，人就是螺丝钉，之后到改革开放，国退民进，让利于民后，情况才好一些。
• 『长安的荔枝』：非常马亲王的小说，从小人物视角看历史，有趣。

不过不好意思的说，今年消费得最多的文化产品是玄幻爽文。准备换工作的那段时间，压力比较大，经常开着喜马拉雅听书当背景音，垃圾网文听了好多本，听起来真解压，就是每本都听不长，听几章就腻了，各种套路，三观感人。那天看到有一个研究是研究网文主角性格与经济环境的关系，文艺作品真的是时代的剪影。

展望

一个字，苟。希望家人都安好，希望国内的亲戚朋友挺过这一轮疫情。希望经济奇迹出现。

多看看书，定个小目标6本吧。

多运动。

和家人一起出去旅个游。

以防停產，記錄一下撒料個配料：辣椒粉，芝麻，紫蘇，孜然，花生，味精，鹽，黃豆粉，洋蔥粉，白砂糖。

蝦

1. 簽子穿好，擦乾水
2. 烤乾，刷油，撒調料
3. 小火慢烤至不透明

烤魚

1. 魚從背部切開，改刀
2. 蔥一根，薑一小塊，花椒2g，八角2個，鹽25g，生抽15g，水800g，魚隔夜浸泡醃製
3. 烤魚夾子夾好
4. 小火慢烤至表皮酥脆

羊排

1. costco羊排切開
2. 肉重12%的洋蔥，3%的撒料，冰箱隔夜醃製
3. 小火慢烤至內部溫度到63度

牛肉串

1. 牛肉切成粒
2. 肉重10%的洋蔥，3%的撒料，1%的糖，1%的胡椒粉，1%的生抽，1%的鹽，16%的水，打成糊，冰箱隔夜醃製
3. 甜椒切塊與牛肉同串
4. 小火慢烤至內部溫度到63度

金針菇粉絲

1. 粉絲泡發，與金針菇，蒜茸置錫紙上烤熟

五花肉，年糕

1. 五花肉切片置於錫紙上慢火烤至金黃
2. 五花肉取出放鹽和撒料
3. 錫紙上放年糕烤至酥脆

雞翅

1. 奧爾良雞翅醃料說明醃製
2. 小火慢烤至內部溫度到74度

烤鱿鱼

1. 撒料加油配成酱料
2. 鱿鱼切块/整条剪好，刷酱
3. 烤箱200度烤五分钟
4. 拿出来翻面刷酱，再烤5分钟
5. 拿出来翻面刷酱，再烤3分钟
6. 拿出来翻面刷酱，再烤3分钟

參考

1. 賴皮猴愛美食 https://youtu.be/u8fBaEHkLy4

   肉部分：肥瘦相间牛肉500g 、羊排或羊腿肉500g。

   牛肉腌料部分：洋葱丝50g、孜然粉5g、十三香1g、白糖4g、白胡椒粉5g、 蒜粉5g、生抽5g、盐6g、鸡精4g、小苏打0.5g、黄豆粉20g、水80g

   羊肉腌料部分： 洋葱丝60g、一个蛋清、蚝油10g、盐6g

   肉串撒料部份：半颗粒然50g、芝麻10g、秘制鲜香小料10g

   秘制鲜香料部分： 鸡精100g、 味精30g、陈有香肉香粉5g、四宝浓缩鲜香粉5g、 十三香1g

2. 小高姐 烤魚 https://youtu.be/3GeG8wzJXdU

看完之後仔細想來，家鄉的方言作爲弱勢方言，語音正在受漢語拼音的侵噬，其實每個方言都是如此。於是心裏有了一個小小的願望，制定爲自己的方言定一套拼音方案，並且爲方言正字正音，算是爲家鄉文化做一點微小的工作。 詹橋地處湖南湖北江西三省交界處，屬於贛語到湘語的過渡區，這裏屬於所謂的“濁音走廊”，在當今大部分方言的濁音都已經清化的大背景下，詹橋話裏廣泛存在着濁音聲母。下面是筆者所定的詹橋話拼音方案，由於漢語拼音方案廣爲人知，這套方案大體與漢語拼音方案類似。

聲母部分

聲母大部分采用與漢語拼音相同的字母，而不用國際音標寫法，以方便對漢語拼音方案的朋友們學習，但是具體發音不太相同。下文中均用方括號[]標註國際音標。

比如雙唇塞音，漢語拼音裡有兩個，分別是b/p，對應的國際音標為[p]/[pʰ]，而詹橋話裡沒有送氣清音，只有清音和濁音，對應的國際音標為[p]/[b]，由於清音[p]與漢語拼音發音相同，故本方案沿用漢語拼音b表示清音，而使用p表示濁音。同理，齒齦塞音d/t，齒齦塞擦音z/c，齦顎塞擦音j/q，軟顎塞音g/k等類似，都是前者爲清音，後者爲濁音，而不是讀漢語拼音里讀送氣音。

邊音[l]的洪音字與鼻音[n]在詹橋話里已合流，邊音[l]的細音字已派入濁齒齦塞音[d]，故本方案都拼做n，不設單獨的l。此外詹橋話裏沒有捲舌音zh、ch、sh、r，相比與漢語拼音，多了齦顎鼻音nj [ȵ]以及軟顎鼻音ng [ŋ]。

聲母表

此外有零聲母y/w。

韻母部分

韻母和漢語拼音有些許重合，撮口呼ü不好輸入，所以本方案寫作yu。

詹橋話保留了漢語的入聲，但是中古的-p、-k、-t入聲韻尾都退化成了喉塞音韻尾[ʔ]，本方案拼做-q。詹橋話裏有三個輔音可自成音節m、n、ng。

舌尖前不圓唇元音[ɿ]在漢語拼音中拼z、c、s，寫作i，如子、詞、思。爲作區分，本方案寫作r。

齊齒呼的韻母在沒有聲母的時候，遵從漢語拼音的習慣，寫作yi、ya、ye、yao、you、yan、yin、yang、yong、ying、yiq、yaq、yoq、yeq、youq。

合口呼的韻母在沒有聲母的時候，遵從漢語拼音的習慣，寫作wu、wa、we、wai、wei、wan、won、wen、wong、weng、wuq、waq、woq、weq、weiq。

撮口呼的韻母跟j、q、x、nj拼的時候，遵從漢語拼音的習慣，拼做ju、qu、xu、nju、njui，省略y。

iou、uei、uen、iouq、ueiq前面加聲母的時候，遵從漢語拼音的習慣，寫作iu、ui、un、iuq、uiq。例如tiu 流、gui 歸、gun 滾等。

yuei可簡寫成yui。

ieng可簡寫成ing。

韻母表

聲調部分

詹橋話有6個聲調，此方案用1~6標識調類，由於入聲韻有q結尾，可以省略調類6。

例子

由於漢語拼音沒有入聲，用詹橋話拼音讀有些古詩，尤其是入聲韻的古詩，會十分押韻。比如：

jiong1 xieq6
江雪
tiou3 zeng1 yuan2
柳宗元

qian1 san1 njiao3 fei1 qieq6
千山鸟飞绝
wan5 jin4 njin2 zeng1 meq6
万径人踪灭
gu1 zou1 soq6 tiq6 eng1
孤舟蓑笠翁
touq6 diao4 hon2 jiong1 xieq6
独钓寒江雪

漂泊經年，每每想起老家，就想起門對面山上的雞子石。

雞子石是一塊略顯光禿的石頭，從老家門口望去，圓鼓鼓的，像極了寫禿的鉛筆頭。小時候一直以為它背面也是這般模樣，直到有一次坐摩托車去山那邊的大姑媽家，才發現背面的雞子石坍塌了一塊，整個雞子石從側面看去居然是尖尖的。石頂上遠看倒有些植被，高中的時候和好友爬山，上去看過一次，上面是一人多高的灌木叢，密密麻麻的卻沒甚葉子，估計是被常年的山風吹的吧。

前段時間偶爾發現一本乾隆年間的《岳州府志》，心血來潮翻閱了一會兒，終於讓我在山川志的部分發現了雞子石的記載：“大雲山在縣東北一百二十里，盤旋七十餘峯，上有龍湫，又有石廟祀真武神并宋通判石光像，旁有雞子石，可容千人，明末郡人避亂於此，張李二賊環攻經年不破，半隸臨湘界”。第一次在歷史文獻中看到它的記載，當即在微信上分享給了爸媽。

從小學起，為了就近上個好學校，爸媽就帶我住在二姑媽家。此後輾轉各地上學，除了初中在老家山下中學讀的那半年，再不曾在老家長住。高中畢業後北上去了北京，老家在記憶中再也沒有了初春三月的梅雨和金燦燦的稻田。大學畢業後飛到地球另外一邊求職，山高海遠再加上簽證身份問題，回家更是成了一種奢望。希望以後能多回家看看，留此文聊慰鄉情。

搬运自 https://zhuanlan.zhihu.com/p/40663395

最近在微博上看到一个关于 block 的问题，有这么一段代码：

#include <stdio.h>

int main() {
    typedef int(^Block)(void);
    Block blocks[3];
    int i;
    for (i = 0; i < 3; ++i) {
        blocks[i] = ^{
            return i;
        };
    }
    for (i = 0; i < 3; ++i) {
        printf("%d\n", blocks[i]());
    }
}

这段代码在 ARC 和 MRC 模式下分别会输出什么？答案是：ARC 模式下面会输出 012，而 MRC 模式下会输出 222。

MRC 模式下的 block

我们先来讨论 MRC 模式下这段代码的行为，关于 block 的实现细节，可以参考这篇文章：Block Implementation Specification。从中我们可以看到编译器会生成一些描述这个 block 的 struct，由于我们引用了栈上的局部变量 i，这个 block 会存在于栈内存里（而不是全局内存里）。其实这 3 个 block 指针都指向栈上面同一片内存，每次循环唯一修改的只是这个 block 里面捕获的变量 i 的副本，循环完后，block 里面保存的副本值为 2，所以 MRC 模式下输出 3 个 2。

道理不难，我倒是很好奇编译器到底生成了什么样的代码，带着这个疑惑，我研究了一下上面代码对应的汇编代码，为了看懂这个汇编，我还临时抱佛脚，看了一篇汇编的介绍。

首先生成 MRC 模式下的汇编代码：

clang -fno-stack-protector -fno-objc-arc -S blocktest.m -o blocktest_mrc.s

因为主要区别在于 3 个 blocks[i] 赋值，我们重点看这一部分。这一段汇编代码结合上述 block 实现细节那篇文章的 Imported Variables 这一节看有奇效：

根据文章，我们的 block 大概会编译成：

struct __block_literal_tmp {
    void *isa;  // &__NSConcreteStackBlock
    int flags;  // 0xC0000000
    int reserved;  // 0 
    void (*invoke)(struct __block_literal_2 *);
    struct __block_descriptor_2 *descriptor;
    const int i;
};

我摘取了对应的汇编代码分享一下：

...
_main:
  pushq %rbp
  movq  %rsp, %rbp
  subq  $80, %rsp                       ## 栈上留出 80 bytes
  movl  $0, -4(%rbp)
  movl  $0, -36(%rbp)                   ## -36(%rbp) 存的是局部变量 i
LBB0_1:                                 ## 第一个循环
  cmpl  $3, -36(%rbp)
  jge LBB0_4                            ## i >= 3 则跳出循环

  leaq  -72(%rbp), %rax                 ## block 的地址
  leaq  ___block_descriptor_tmp(%rip), %rcx
  leaq  ___main_block_invoke(%rip), %rdx
  movq  __NSConcreteStackBlock@GOTPCREL(%rip), %rsi
  movq  %rsi, -72(%rbp)                              ## 初始化 isa
  movl  $-1073741824, -64(%rbp) ## imm = 0xC0000000  ## 初始化 flags
  movl  $0, -60(%rbp)                   ## 初始化 reserved 
  movq  %rdx, -56(%rbp)                 ## 初始化 invoke
  movq  %rcx, -48(%rbp)                 ## 初始化 descriptor
  movl  -36(%rbp), %edi                 ## 这两行把 i 的值复制给 block 里面的副本
  movl  %edi, -40(%rbp) 
  movslq  -36(%rbp), %rcx               ## %rcx = i
  movq  %rax, -32(%rbp,%rcx,8)          ## 赋值给 blocks[i]

  movl  -36(%rbp), %eax                 ## ++i
  addl  $1, %eax
  movl  %eax, -36(%rbp)
  jmp LBB0_1
LBB0_4:                                 ## 第二个循环
  movl  $0, -36(%rbp)
...

第一个循环结束之后栈内存大概长这个样子：

%rsp       -> |-------------------------------------------|
                                 ...
              |-------------------------------------------|
              |       block[2] = %rax = -72(%rbp)         |-----------------|
              |                                           |                 |
-16(%rsp)  -> |-------------------------------------------|                 |
              |       block[1] = %rax = -72(%rbp)         |-----------------|
              |                                           |                 |
-24(%rsp)  -> |-------------------------------------------|                 |
              |       block[0] = %rax = -72(%rbp)         |-----------------|
              |                                           |                 |
-32(%rsp)  -> |-------------------------------------------|                 |
              |       2 // local int i                    |                 |
-36(%rsp)  -> |-------------------------------------------| ----            |
              |       2 // block const int i              |    |            |
              |-------------------------------------------|    |            |
              |       &___block_descriptor_tmp            |    |            |
              |                                           |    |            |
              |-------------------------------------------|    |            |
              |       &___main_block_invoke               |    |            |
              |                                           |    |            |
              |-------------------------------------------| block_literal   |
              |       0 // reserved                       |    |            |
              |-------------------------------------------|    |            |
              |       0xC0000000 // flags                 |    |            |
              |-------------------------------------------|    |            |
              |       &__NSConcreteStackBlock             |    |            |
              |                                           |    |            |
-72(%rsp)  -> |-------------------------------------------| ----     <<<----|
                                 ...

看汇编代码就很清晰了，基本上 block 这块内存来回被初始化了 3 次，之后 block 里面的副本 i 变成了 2。

ARC 模式下的 block

我们继续看 ARC 模式下的 block，我们先拿到汇编代码：

clang -fno-stack-protector -fobjc-arc -S blocktest.m -o blocktest_arc.s

同样摘取第一个循环部分，重点看两边不同的地方：

...
_main:
  pushq %rbp
  movq  %rsp, %rbp

## >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
  ## 这里不同的地方在于 ARC 模式下会用 memset 清空 blocks 
  subq  $112, %rsp
  xorl  %esi, %esi
  movl  $24, %eax
  movl  %eax, %edx
  leaq  -32(%rbp), %rcx
  movl  $0, -4(%rbp)
  movq  %rcx, %rdi
  callq _memset
## <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

  movl  $0, -36(%rbp)                   ## -36(%rbp) 存的是局部变量 i
LBB0_1:                                 ## 第一个循环
  cmpl  $3, -36(%rbp)
  jge LBB0_4                            ## i >= 3 则跳出循环

  leaq  -72(%rbp), %rax                 ## block 的地址
  leaq  ___block_descriptor_tmp(%rip), %rcx
  leaq  ___main_block_invoke(%rip), %rdx
  movq  __NSConcreteStackBlock@GOTPCREL(%rip), %rsi
  movq  %rsi, -72(%rbp)                              ## 初始化 isa
  movl  $-1073741824, -64(%rbp) ## imm = 0xC0000000  ## 初始化 flags
  movl  $0, -60(%rbp)                   ## 初始化 reserved 
  movq  %rdx, -56(%rbp)                 ## 初始化 invoke
  movq  %rcx, -48(%rbp)                 ## 初始化 descriptor
  movl  -36(%rbp), %edi                 ## 这两行把 i 的值复制给 block 里面的副本

## >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
  ## 这里不同的地方是我们初始化 block 之后，会调用 _bojc_retainBlock 把 block 复制到 heap 离去
  ## blocks[i] 保存的 heap 里面的 block
  movq  %rax, %rdi                      ## _objc_retainBlock(__block_literal)
  callq _objc_retainBlock
  movslq  -36(%rbp), %rcx
  movq  -32(%rbp,%rcx,8), %rdx          ## %rdx = blocks[i]
  movq  %rax, -32(%rbp,%rcx,8)          ## blocks[i] = _objc_retainBlock(__block_literal)
  movq  %rdx, %rdi                      ## _objc_release(%rdx)
  callq _objc_release
## <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

  movl  -36(%rbp), %eax                 ## ++i
  addl  $1, %eax
  movl  %eax, -36(%rbp)
  jmp LBB0_1
LBB0_4:                                 ## 第二个循环
  movl  $0, -36(%rbp)
...

到这里这个问题就算破案了，欲知后事如何，请听下回分解！

微软大法好

VSCode 是个好编辑器，虽然插件挫了点，但是跑得比 Atom 快，调试功能特别赞，对 JavaScript 和 Go 的代码提示简直不能再好，将来插件生态再好一点，这就是一个全能的 IDE 了。

VSCode 在很早就开放了插件系统， 这里主要介绍一下语法高亮插件的部分。

VSCode 的语法高亮配置和 Atom 一样，使用的是 textmate 的配置语法。

例子

来看一个例子：

{
    "scopeName": "source.untitled",
    "fileTypes": [],
    "foldingStartMarker": "\{\s*$",
    "foldingStopMarker": "^\s*\}'",
    "patterns": [
        {
            "name": "keyword.control.untitled",
            "match": "\b(if|while|for|return)\b"
        },
        {
            "name": "string.quoted.double.untitled",
            "begin": "\"",
            "end": "\"",
            "patterns": [
                {
                    "name": "constant.character.escape.untitled",
                    "match": "\\."
                }
            ]
        }
    ]
}

主要配置有几部分：

• scopeName: 这个是用来标识语言的，必须独一无二，一般使用 . 分割成两个部分， 前半部分一般是 text / source，后面是具体的语言名字
• fileTypes: 这个用来指定配置适用的文件扩展名
• foldingStartMarker / foldingStopMarker: 用来控制折叠
• patterns: 这才是真正用来识别高亮的规则

另外还有两个不在例子里面的配置：

• firstLineMatch: 如果匹配了文档第一行，这个文档就适用这个高亮规则，比如 ^#!/.*\bruby\b
• repository: 这是一堆键值对形式的规则，可以在文档中使用 include 引用这些规则

规则

规则使用键值对形式，键可以是：

• name: 指定规则的名字，是用来高亮的依据，需要遵循一定的命名规则来让编辑器知道该高亮成什么类型
• match: 匹配文本的正则表达式
• begin, end: 匹配多行文本的规则，和 match 不能共存，begin 是匹配开头的正则， end 是匹配结尾的正则，begin 里面 capture 到内容可以在 end 里面引用，比如匹配 heredoc 的时候：

    {
        "name": "string.unquoted.here-doc",
        "begin": "<<(\w+)",
        "end": "^\1$"
    }
  

• contentName: 类似 name，但是是设置 begin 和 end 中间文本的类型的
• captures, beginCaptures, endCaptures: 设置正则匹配到的部分的类型，用来高亮，只能包含 name
• include: 引用其他语言的高亮规则或者引用 repository 里面的东西

命名规则

为了让主题文件可以通用，name 设置要遵循一定的规则，这样编辑器就知道这块地方是注释，那块是关键字， 从而为不同的部分设置不同的颜色，高亮就是这么来的。名字各部分之间使用 . 连接起来，比如 comment.line.number-sign：

• comment 设置注释
  • line 单行注释，一般使用的有
    • double-slash //
    • double-dash –
    • number-sign #
    • percentage — %
    • character 其他类型的单行注释
  • block 多行注释，比如 /* … */，<!-- … -->
    • documentation
• constant 常量
  • numeric 数字
  • character 字符，比如<，\e，\031
    • escape 转义字符
  • language 语言支持的常量，true / false / nil 等等
  • other 比如 css 里面的颜色
• entity 各种实体，类名，方法名等
  • name
    • function 方法名
    • type 类型名
    • tag 标签名
    • section 区块名
  • other 其他实体
    • inherited-class 继承的类名
    • attribute-name 属性名
• invalid 表示非法内容
  • illegal
  • deprecated
• keyword 关键字
  • control 流程控制类 if / while 之类
  • operator 运算符，比如 or
  • other 其他
• markup 为标记语言使用的，顾名思义即可
  • underline
  • bold
  • heading
  • italic
  • quote
  • raw 比如代码块，无格式
  • other
• meta 表示不同的部分，比如 meta.class，meta.method 目的是更好的组织这些规则
• storage 与数据存储相关的
  • type 类型 class / function / int / var 等
  • modifier 修饰符 static / const / final 啥的
• string 字符串
  • quoted
    • single 单引号引用的
    • double 双引号引用的
    • triple 三个引号引用的 比如 """Python"""
    • other 另类的，比如 $'shell'，%{ruby}
  • unquoted here-doc
    • interpolated 要解析的字符串：`date`, $(pwd)
    • regexp 正则表达式
    • other 其他类型的字符串
• support 框架或者库提供的功能
  • function 比如 C 里面的 printf
  • class 比如 C++ 里面的 vector
  • type
  • constant
  • variable
  • other
• variable
  • parameter 函数参数
  • language 语言预定于的变量，比如 this / super / self
  • other

实战

有了这些东西就可以开始为一个语言写高亮配置文件了，这里选用一个简单的语言 Cool， Cool (Classroom Object Oriented Language) 是 Stanford 编译器课程的教学语言，语法比较简单

具体语法可以查看 http://theory.stanford.edu/~aiken/software/cool/cool.html

具体例子可参考 https://github.com/maogm12/language-cool

在 VSCode 中安装的命令 ext install cool

{
  "scopeName": "source.cool",
  "name": "COOL",
  "fileTypes": [
    "cl"
  ],
  "patterns": [
    {
      "include": "#code"
    }
  ],
  "repository": {
    "block": {
      "patterns": [
        {
          "begin": "{",
          "end": "}",
          "name": "meta.block.cool",
          "patterns": [
            {
              "include": "#code"
            }
          ]
        }
      ]
    },
    "builtins": {
      "patterns": [
        {
          "match": "(Int|String|Bool|IO|Object)",
          "name": "support.class.cool"
        },
        {
          "match": "(abort|type_name|copy|out_string|out_int|in_string|in_int|length|concat|substr)",
          "name": "support.function.cool"
        },
        {
          "match": "(self|SELF_TYPE)",
          "name": "variable.language.cool"
        }
      ]
    },
    "class": {
      "begin": "((?i:class))\\s+([A-Z][A-Za-z0-9_]*)(\\s+((?i:inherits))\\s+([A-Z][A-Za-z0-9_]*))?\\b",
      "beginCaptures": {
        "1": {
          "name": "storage.type.cool"
        },
        "2": {
          "name": "entity.name.type.class.cool"
        },
        "4": {
          "name": "keyword.operator.cool"
        },
        "5": {
          "name": "entity.name.type.class.cool"
        }
      },
      "end": "}",
      "name": "meta.class.cool",
      "patterns": [
        {
          "begin": "{",
          "end": "(?=})",
          "name": "meta.class.body.cs",
          "patterns": [
            {
              "include": "#method"
            },
            {
              "include": "#code"
            }
          ]
        }
      ]
    },
    "code": {
      "patterns": [
        {
          "include": "#block"
        },
        {
          "include": "#builtins"
        },
        {
          "include": "#class"
        },
        {
          "include": "#comments"
        },
        {
          "include": "#constants"
        },
        {
          "include": "#keywords"
        },
        {
          "include": "#method"
        }
      ]
    },
    "line_comment": {
      "begin": "--",
      "end": "$\\n?",
      "name": "comment.line.double-dash.cool"
    },
    "block_comment": {
      "begin": "\\(\\*",
      "end": "\\*\\)\\n?",
      "name": "comment.block.documentation.cool",
      "patterns": [
        {
          "include": "#block_comment"
        }
      ]
    },
    "comments": {
      "patterns": [
        {
          "include": "#line_comment"
        },
        {
          "include": "#block_comment"
        }
      ]
    },
    "constants": {
      "patterns": [
        {
          "match": "\\b(true|false)\\b",
          "name": "constant.language.cool"
        },
        {
          "match": "\\b([1-9][0-9]*)\\b",
          "name": "constant.numeric.cool"
        },
        {
          "begin": "(?<!\\\\)\"",
          "end": "(?<!\\\\)\"",
          "name": "string.quoted.double.cool",
          "patterns": [
            {
              "match": "\\\\(n|t)",
              "name": "constant.character.escape.cool"
            }
          ]
        }
      ]
    },
    "keywords": {
      "patterns": [
        {
          "match": "\\b(if|then|else|fi|while|loop|pool|case|esac)\\b",
          "name": "keyword.control.cool"
        },
        {
          "match": "\\b(in|inherits|isvoid|let|new|of|new|not)\\b",
          "name": "keyword.operator.cool"
        }
      ]
    },
    "method": {
      "patterns": [
        {
          "match": "\\b([a-z][A-Za-z0-9_]*)\\s*\\(\\s*(?:([a-z][A-Za-z0-9_]*)\\s*:\\s*([A-Z][A-Za-z0-9_]*))?(?:\\s*,\\s*([a-z][A-Za-z0-9_]*)\\s*:\\s*([A-Z][A-Za-z0-9_]*))*\\s*\\)\\s*:\\s*([A-Z][A-Za-z0-9_]*)\\b",
          "name": "meta.method.cool",
          "captures": {
            "1": {
              "name": "entity.name.function.cool"
            },
            "2": {
              "name": "variable.parameter.cool"
            },
            "3": {
              "name": "storage.type.cool"
            },
            "4": {
              "name": "variable.parameter.cool"
            },
            "5": {
              "name": "storage.type.cool"
            },
            "6": {
              "name": "storage.type.cool"
            }
          }
        }
      ]
    }
  }
}

效果如下：

整个界面看起来很像 Sublime Text，是一个很良心的编辑器，唯一的缺点就是有点慢。

编辑器的灵魂在于插件，Sublime Text 这么受欢迎与那一大堆优秀的插件们是离不开， VSCode 要加油啊。

最近写 Ruby 的项目，由于 RubyMine 太过于臃肿，转而还用了 Atom 做主力编辑器。 Atom 配置完成之后，写起代码来体验还是很棒的，现在比以前的版本也快多了。

作为工具党，插件我没少装，于是时时冒出自己学一下写插件的想法。Atom 底层是 NodeJs， 我也还能写一写。

正好在写单元测试的时候，测试大整数时，Rubocop 提示我 Ruby 中大整数应该使用 _ 隔开， 类似 123_456_789，这样提高代码可读性。

那就写个轮子吧！！！

Atom 文档中有插件开发指南: http://flight-manual.atom.io/hacking-atom/sections/package-modifying-text/

我的插件功能就是获取当前光标下的数字，然后把他们替换成下划线分割的格式。

使用 Atom 自带的包生成工具，可以很方便的生成插件的开发包，具体请参考官方文档。 由于不涉及到 View 的操作，我们的插件很简单，生成完之后，删除掉 View 操作的代码后，结构如下：

.
├── CHANGELOG.md
├── LICENSE.md
├── README.md
├── lib
│   └── seperate-number.js
├── package.json

测试代码容我后续再补哈。。。

库里面关键是操作数字，实现两个功能：

1. 添加分隔符
2. 取消分隔符

看代码，添加主要是三个一分三个一分，取消分隔符更简单，将分隔符都替换成空即可：

class NumberSeperator {
    constructor(seperator) {
        this.seperator = seperator || '_';
    }

    toggleNumber(number) {
        var pos = number.indexOf(this.seperator);
        if (pos == -1) { // no seperator
            return this.seperateNumber(number, this.seperator);
        } else if (pos > 0 && pos <= 3) {
            var newPos = number.indexOf(this.seperator, pos + 1);
            while (newPos == pos + 3 + this.seperator.length) {
                pos = newPos;
                newPos = number.indexOf(this.seperator, pos + 1);
            }
            if (newPos == -1 && pos == number.length - 3 - this.seperator.length) {
                return this.unSeperateNumber(number, this.seperator);
            }
        }

        return number;
    }

    seperateNumber(number) {
        if (typeof number === 'string') {
            var length = number.length;
            if (length <= 3) {
                return number;
            }
            var start = length % 3;
            var result = start > 0 ? number.substring(0, start) : '';
            for (var i = start; i < length; i += 3) {
                if (i > 0) {
                    result += this.seperator;
                }
                result += number.substring(i, i + 3);
            }
            return result;
        }
        return '';
    }

    unSeperateNumber = function(number_with_seperator) {
        return number_with_seperator.split(this.seperator).join('');
    }
}

面向对象，搞个类先。

toggleNumber 主要是判断数字的格式，如果是没有分隔符的，我们就加上，如果有分隔符， 并且是正确的使用分割符的，我们就把分隔符去掉。

具体到插件的生命周期，每一个插件在 Atom 启动的时候都会调用 active 方法， 我们在这个方法里面注册我们的命令 seperate-number:toggle。

activate() {
    this.subscriptions = new CompositeDisposable();

    // Register command that toggles this view
    this.subscriptions.add(atom.commands.add('atom-workspace', {
        'seperate-number:toggle': () => this.toggle()
    }));
}

然后在 toggle 方法里面主要是选中当前光标下的单词，然后选出其中的数字部分进行操作。

toggle() {
    if (editor = atom.workspace.getActiveTextEditor()) {
        if (editor.getSelectedText() === '') {
            editor.selectWordsContainingCursors();
        }

        const worker = new NumberSeperator();
        var word = editor.getSelectedText();
        var numbers = word.match(/\d[_\d]+/g);
        var newNumber;
        numbers.forEach(function(number) {
            word = word.replace(number, worker.toggleNumber(number));
        });
        editor.insertText(word);
    }
}

看看效果吧，基本满足需求哈！

项目在这里：https://github.com/maogm12/separate-number

TODO：

• Atom 多选的时候有问题
• 扔 Atom 的插件库里面去

It’s OK for the code to use but a little unintuitive for us human beings to understand the tree, for simple ones we can draw that on paper checking row by row, while for complicated trees, it will cause us ton of time to just visualize the tree.

And why not make a tool for drawing that tree :D

Overall

For decoupling, the tool is made up of 2 parts: the backend and the front-end. Then the font-end can only do the rendering and is replaceable by any other font-end.

Backend

I plan to not involve detailed logic of the backend and only define the interface for the front-end to fetch data.

And a sample response from the backend is like:

{
  "id": 1,
  "name": "root",
  "description": "description",
  "children": [
    {
      "id": 2,
      "name": "level1",
      "description": "description",
      "children": [
        {
          "id": 4,
          "name": "level22222",
          "description": "This is level2"
        },
        {
          "id": 5,
          "name": "level222",
          "description": "This is level2",
          "children": [
            {
              "id": 10,
              "name": "level333",
              "description": "Here are a few key resources to get you started with building mobile apps quickly",
              "children": [
                {
                  "id": 11,
                  "name": "level444444",
                  "description": "Introduces Android development. Covers the tool chain, Xamarin.Android projects, and Android fundamentals."
                },
                {
                  "id": 12,
                  "name": "level 4444",
                  "description": "This guide walks through the installation steps and configuration details required to install Xamarin.Android on Windows."
                }
              ]
            }
          ]
        }
      ]
    },
    {
      "id": 3,
      "name": "level1111",
      "description": "description",
      "children": [
        {
          "id": 6,
          "name": "level2222222",
          "description": "Never know this level: level2, 233333"
        }
      ]
    },
    {
      "id": 3,
      "name": "level111111111",
      "description": "description",
      "children": [
        {
          "id": 7,
          "name": "level22222222222",
          "description": "blahblahblah"
        },
        {
          "id": 8,
          "name": "level222",
          "description": "The AppDelegate.cs file contains our AppDelegate class"
        },
        {
          "id": 9,
          "name": "level two",
          "description": "which is responsible for creating our window and listening to OS events"
        }
      ]
    }
  ]
}

It’s JSON formatted with the children representing the relationship.

Front-end

This time I try to implement the front-end on Mac using Xamarin.Mac.

Xamarin is a nice tool for cross-platform development using C#. And Xamarin.Mac is for developing Mac native app.

Our result is like:

Just create a new solution for our TreeViewer. The IDE - Xamarin Studio takes the advantage of the Xcode to editing storyboard files.

We use a horizon SplitView for the main structure. The we draw a text field for entering root ID, and a draw button the draw the tree.

We should custom a view to draw the actual tree. Let’s make it TreeView.

The TreeView is subclass of the NSControl on Cocoa framework.

The key point is calculating the tree size and positions of each nodes/links.

Here, we use json.NET to parsing the JSON response and using a generic object to representing the tree, because the backend may response extra info in node, so there is no a fixed node class.

The width／height calculation is as follows:

private int calcTreeWidth(JObject root) {
    if (root == null) {
        return 0;
    }

    // no children, the leaf node
    if (root ["children"] == null) {
        root.Add (NODE_WIDTH_TAG, NodeWidth);
        return NodeWidth;
    }

    int childrenWidth = 0;
    foreach (var child in root["children"]) {
        childrenWidth += calcTreeWidth (child.Value<JObject>());
    }
    root.Add(NODE_WIDTH_TAG, Math.Max (childrenWidth, NodeWidth));
    return Math.Max (childrenWidth, NodeWidth);
}

private int calcTreeHeight(JObject root) {
	if (root == null) {
		return 0;
	}

	// leaf
	if (root ["children"] == null) {
		root.Add(NODE_HEIGHT_TAG, NodeHeight);
		return NodeHeight;
	}

	int childrenHeight = 0;
	foreach (var child in root["children"]) {
		int height = calcTreeHeight (child.Value<JObject>());
		childrenHeight = Math.Max (height, childrenHeight);
	}
	root.Add (NODE_HEIGHT_TAG, NodeHeight + childrenHeight);
	return NodeHeight + childrenHeight;
}

The sum of children’s width is the root’s width and the height is simply the depth of the tree.

Along the way, we can store the whole size of the subtree, and we can calculate the positions of each node later on.

private CGPoint calcTreePos (JObject root, CGPoint origin) {
	if (root == null) {
		return origin;
	}

	int width = (int)root [NODE_WIDTH_TAG];
	int height = (int)root [NODE_HEIGHT_TAG];

	// root
	CGPoint rootPos = new CGPoint(origin.X + width / 2, origin.Y + NodeHeight / 2);
	_nodes.Add (rootPos);
	if (root ["children"] != null) {
		var curX = origin.X;
		var curY = origin.Y + NodeHeight;
		foreach (var child in root["children"]) {
			JObject childObj = child.Value<JObject> ();
			CGPoint childPos = calcTreePos(childObj, new CGPoint(curX, curY));
			// add path
			_paths.Add(new Tuple<CGPoint, CGPoint>(rootPos, childPos));
			int childWidth = (int)childObj [NODE_WIDTH_TAG];
			curX += childWidth;
		}
	}

	return rootPos;
}

At last

OK, the tree is very ugly now, more should be done the make it better.