徒步路线：法喜寺 - 三分岔 - 龙井村 - 九溪十八涧
看完后有所感触，其实毒品是一个极端的案例，但生活中，无处不在的有一些不健康的沉迷事物。比如我看网络小说，大学被同学推荐后，我就迷上了这种网络小说，后来一发不可收拾，大量时间都花在网络小说上，断断续续挣扎地看了很多年。
现在我周末有时候会看一些动漫或者电视剧，或者玩游戏，我都是尽量对一些容易沉迷的事物有所戒心。目前已知有两种方式是最容易脱离沉迷的：
如果是开始计划，我把这个看完就不看了，其实 90% 的情况是没办法真的不看的，因为你闭环了一个圈后，还想再闭环一次。平时吃东西吃到饱后会有反馈吃饱了不想吃的链路，但大脑看这些东西的时候，其实负反馈很少，或者需要看足够久才会有负反馈，比如看腻了，身体疲惫，或者其它一些负反馈，不然就会一直看。
抛开哪些能让人沉迷，实践中发现有几个情况能缓解沉迷一件事情的方法：
运动能极大的抛开你沉迷的东西，以前人类狩猎，如果没有抓到猎物，大脑还是会给奖励内啡肽的，不然就没有动力进行下一次的狩猎（有据可查，需要找资料）。所以前一个正反馈循环，和运动这个正反馈循环，这两个循环的对抗确实有一定的概率能增强对沉迷并且自责的事物进行抵抗。
有时候确实很难靠自律走出沉迷的漩涡，这个时候需要有人拉一把，把当前的事物换一个环境，这样能很好的避免沉迷，比如上面那个吸毒的案例，只要还进没有那种让你沉迷的条件，就能客观的戒掉沉迷。
当你认为一个事情有毒，并且熬过来后，大脑和身体就会产生抵抗。但身体和大脑本身又有一些来者不拒的情况。所以就像前面说的，当你意识到前面是悬崖的时候，你对未来可能发生沉迷的事情，只要多想几步，就能避免陷进去几个小时，甚至一天。比如刷短视频，或者玩游戏一天。要做到这一点，具备这几个点效果会比较好：
让你沉迷的，总是那种回路短，正反馈强烈且快速的情况容易让身体大脑记住。日常的事情其实很少有这种沉迷的情况，就算有也是频率极低的，一般都是链路长、反馈少甚至失败的情况。链路长的事情本身就很难坚持，但只要找到里面的正反馈，不管今天，还是明天，总会有契机，走到环上去的。
]]>支持 Markdown 格式写作，内容可自动发布到 Bitcron 关联网站，且允许自定义域名。
由于未参与平台运营决策，无法对维护团队的选择做绝对评判。后续了解到这个团队转向课程变现业务，对博客服务的投入相应减少。从技术架构来看，Bitcron 持续维护成本较高，但对之前的用户而言，省时省力尝试一下也还可以，但如果要完全自定义曲线就会陡然增高。
早年曾尝试 Jekyll + Github 的博客方案，因国内访问受限放弃，但认可 “仅维护 Markdown 文章” 的静态生成模式。恰逢 Serverless 技术兴起，且本人熟悉相关技术栈，遂启动该方案搭建。
从语雀拉取内容并转换为 Markdown 格式，通过自主开发的 Serverless Hexo 博客生成器处理后，生成 HTML 等静态文件，最终发布到 OSS（对象存储服务）。
该方案以自用为核心，初期围绕 Serverless 生态进行适配改造。后期因维护成本高、精力有限，博客更新停滞，项目搁置 3 年。
针对上一版方案维护成本高的问题，核心原因在于架构复杂，但仍倾向于 Serverless 的技术特性，花费两个周末的部分时间进行重构，计划将 Hexo 生成代码封装为 Library 简化架构，然后按需调用。
虽然按照上面的重构，但还有比较多问题，核心还是 Serverless 调试不方便，本质还是 沙箱不是很适合本地调试，远程调试非常依赖基础设施，但明显现在云的基础设施并不怎么样。最终避免费更多精力，走到不应以技术为核心导向的地步，应该需优先匹配实际需求。
复盘前期方案，明确核心优化目标是降低维护成本、解决线上调试难的问题。结合 Hexo 原生适配本地运行的特性，引入 Github Action 构建新架构。
生成速度仍有优化空间，最快需 50 秒左右完成生成流程，不过速度在静态站点生成（SSG）场景下基本可满足使用需求。
当前采用的 Hexo + Github Action + OSS 方案，与最初的 Bitcron 方案相比，虽未实现一体化整合的高效性，但通过整合各平台优势，成为小众场景下维护成本较低的可行方案。实际使用中，当朋友反馈博客主题或配置问题时，通过 Cursor Remote Agent 在手机端完成 PR 提交、合并及重新发布操作还是非常适应当前的时代发展🤣。其实很好地反应了根据具体的需求做定制化的设计是很重要的。
]]>徒步路线：法喜寺 - 三分岔 - 龙井村 - 九溪十八涧
核心的架构思路是分层,实现数据 \ 代码和渲染分离：
生产流程走 GitHub Action， 调试执行记录也方便查看。特别是在当前 AI Coding 的环境下，直接使用 Cursor Remote Agent 就可以在手机上直接修改博客代码，自动提交 PR 并重新发布。画图使用画板或者其它脑图等都很方便,在博客生成时会自动转为图片。博客文章也可以在手机语雀上写完自动发布。整体的生态已经相对成熟。
另外善于利用这些成熟的工具，稳定性有很大的保证，语雀放数据/代码放 Github/博客放 OSS，利用了所有擅长的产品。
]]>1 | nH |
1 | nL |
1 | zz |
1 | zo 展开一层，zO 递归展开 |
1 | c3w, 而不是 dws， vws |
- <font style="color:rgb(51, 51, 51);">实现删除当前单词 daw 或者 diw，如果删除后要插入，就 ciw，或者 caw，不过为了均衡手指的点击，建议用 diw 和 ciw</font>- <font style="color:rgb(51, 51, 51);">比如 w 是快速移动一个单词，W 是快速移动一个“字”，那什么才是字呢？ 空格隔开的算啥？ "';: 这些符号隔开的算啥？我的经验是，这些都不必去记，如果一个操作你需要思考的话，速度就已经慢下来了，还影响你的思路。你的脑子应该用在考虑代码逻辑上，而不是用在怎么把代码打出来。拿刚刚这个例子来说吧，就简单的理解成“W 是更快的 w ”就好啦！</font>1 | goto 21490 |
- goto 指定位置（命令行）1 | vim +21490 script.py |
+{command} 或者 -c {command}
{command} will be executed after the first file has been read. {command} is interpreted as an Ex command. If the {command} contains spaces it must be enclosed in double quotes (this depends on the shell that is used).
1 | !sort -t, -k3 |
1 | d11d |
1 | :sort |
选择 text object
1 | /var<cr> |
选中并修改
1 | cgn |
- 接着一直按`.`就可以了- 如果 2. 这种，就可以隔两个继续 redoMultiple cursors plugin https://github.com/mg979/vim-visual-multi
快速编辑函数
1 | cw |
1 | cc |
1 | f(lct, |
1 | f)dF, |
1 | ci{ |
ya{ 复制括号所有的内容，所以以此类推 yi{ 是复制不包括花括号的内容，总结为 abc 公式
1 | a 可选：c、d、y、v |
或者：
1 | a 可选：d |
(需要转义1 | :%s/\(.\{4\}\)/0x\1 /g |
1 | :g/^/m |
1 | ^s*(?=r?$)\n |
1 | vim -c 'noau e foo.xlsx' |
1 | noremap <Leader>y "*y |
1 | set fenc=cp936 |
文章在点击发布或者更新后，会自动发布到中，如果出现异常，可以通过访问下面的链接手动生成：
http://hexo.vastiny.com/generate/vastiny-com
可以通过每篇文章最前面添加下面的 front matter，自定义当前文章的标题、创建日期、隐私状态、多语言等。
1 | title: 文章标题 |
具体在一个文章里面就是这样：
当前 leedom 以及 leedom2 已经适配好了多语言，自己通过添加导航 xxx/en/ 就可以访问，比如 https://vastiny.com/en/ 一定要加后面的 /才能访问。如果要写一篇英文文章， 不会出现在中文页面，需要定制英文文章的元信息：
1 | lang:en |
然后要配置好网站元信息（完整的信息示例在下面）：
1 | { |
之后，网站就会在 /en/ 的路径下展示英文文章。
使用 Hexo 的 _config.yml 转为 语雀的 json 网站配置：
配置示例：
1 | { |
com.apple.HIToolbox.plist 文件，让输入法 Rime 保留为唯一的输入法。这里最新的系统 macOS Ventura 13 在升级输入法后发现设置失效了，这里重新记录一下成功的案例。1 | cp ~/Library/Preferences/com.apple.HIToolbox.plist{,_1} |
会拷贝 ~/Library/Preferences/com.apple.HIToolbox.plist 文件到同目录下的 ~/Library/Preferences/com.apple.HIToolbox.plist_1。
1 | plutil -convert xml1 ~/Library/Preferences/com.apple.HIToolbox.plist |
因为 plist 有两种格式，一种是二进制的，直接用编辑器打开是乱码，所以需要用工具转为 xml 格式，方便编辑。
用编辑器打开 com.apple.HIToolbox.plist，删除掉 AppleEnabledInputSources 键下不需要的输入法 dict。我这里删除后只剩下这些。可以不用拷贝，直接编辑系统上的文件到类似的内容即可。然后保存文件
1 |
|
保存文件后，其它都不要操作，直接重启 Mac 系统。启动后就会发现菜单栏只剩下一个输入法了。
]]>工作目标自己也要知道高峰区才是最理想的，过多就会倦怠的情况。
会因为一些小事，点爆火药桶。本来可以一笑了之的事情，会因为可能会升级矛盾，导致恶性循环。
公墓里面，有那种夫妻一起，活着的没有染色的字碑，去世的是有染色的墓碑。讲师亲自去数了一下，是 7:3。讲到一个可能就是男性承受的倦怠或者压力常常在内憋着，女生可以有更多的手段去释放出来，比如说更多的话。
如果碰到压力太大或者倦怠的情况，脱离当前的环境，去外面走走。但有些人可能连这个自由都没有，那就是 13~18 岁的学生，因为他们没有意识到能出去，每节课都说，要集中注意力。
早上吃饭，水喝多了一点，过一会儿有小便的想法，但在路上，是膀胱受到了刺激，外周神经给你的中枢神经传导了一个信号。但中枢通过处理又给外周下了指令，不行，憋住。然后这样过多的利用中枢去控制外周，就会疲劳。工作中也有很多不能随心所欲的东西，过多的控制就会疲劳倦怠。
讲师讲述别人工作中的疲劳解决方法：
讲师提到自己用的方法：
晚上疲惫的时候，走到操场，放听不懂的音乐，避免音乐印象情绪，只听节奏就好，比如西班牙语很多的歌节奏挺好的。按照节奏开始快步走，配速配到六公里每小时。然后不要和任何人说话，把手机收好不看手机，持续时间四十分钟以上。频率每周两三次，保持几周时间，就会发现很不一样。
然后讲师终于切入正题，正念是如何缓解倦怠的，这里面就包括了前面提到的正念行走，保持关注行走本身。下面是常见的一些正念探索分类。
关于正念饮食，就是吃饭的时候，只关注吃饭本身，不要说话，也不要看手机，只要关注到菜的味道，和自己。讲师还讲了一个自己的关于吃的事情。自己是江苏人，喜欢吃爆鳝面。怎么找到好吃的爆鳝面，得先找到鳝鱼。所以把车开到余杭平遥。就看哪个农民在那里抓鳝鱼，抓了后就跟着他他那个的小三轮车，观察他把鳝鱼送到哪家面馆就进哪家面馆。
这个例子感觉很棒，因为这种我一直认为，建立联接，才是你觉得这个菜好吃的原因。好吃不支持口味，也包含菜品背后的故事。比如前几周清明节，同事送了青团给我们吃，我当时觉得这个也一般（至少比盒马的好吃），为什么还会流传至今。后来深思了一下，文化传统，在这样的节日下吃这样的食物，是相当惬意的。当你知道你吃菜的来龙去买，你才会知道，下一次吃这个菜的缘起了。
另外城市生活中，有一类人（比如我）吃健康餐，是因为好吃吗？不一定，是因为健康。因为吃的是健康的食物，所以感到心情愉悦。所以吃东西，好吃只是日常吃东西的一个原因，也有文化、健康等因素。
讲师提到自己观鸟的爱好，大概一半的时间都是在讲自己观鸟的经历。因为观鸟，要去到各个地方，也是他了解到的正念旅行。讲到早睡早起有两个原因，也挺有意思的：
城市老人每天一睁眼，就会想着我要去那，今天要干什么，城市老人晚年都是吃药去世在 ICU。而乡村老人一般都是鸡鸣而起，然后就忙各种农活或者到处都是朋友，这种场景会更容易一些，所以一般都是自然死亡。所以早睡早起也是这种充实的一个环节，能让自己一天很充实。
有时候我也认为，不是因为早睡早起好，就要这样，而是因为自己的爱好，自己的其它活动让自己早睡早起。
下面是一些我听讲座总结和结合自己的观点，总结的几个可以操作的地方：
避免浮躁就是减少碎片化的时间，这个是我在生活中的一个实践。比如下班回来后，我一般情况不会去看短视频，这种碎片的内容，一般都是把 B 站的长视频，或者干脆就看电视剧，这样一个小时就能让自己好一些。而不是看短视频后啥都没有的事后感。
所以看出来了吧，最核心的还是，找到自己沉浸式的爱好，然后你在爱好中，不再去思考其它，专注当下。讲师的观鸟就是，他因此会早起早睡，因此会去世界各地去旅行，同样也能缓解自己的倦怠。
]]>| 原地址 | 新路径 |
|---|---|
| /post/tech/strace | 查阅系统调用 strace 和 instruments |
| /post/tech/electron-lifecycle | Electron 生命周期事件 |
| /post/tech/electron-asar | asar 解析 |
| /post/tech/electron-screenshot | Electron 截屏方案分析 |
| /post/tech/electron-remote | 分析并实现一个简单 Electron 的 remote obj |
| /post/tech/vscode-nodejs-deasync | 分析异步转同步库 deasync |
| /post/tech/vscode-nodejs-addon | VSCode 配置 NodeJS C/C++ Addon Debug 环境 |
| /post/tech/fs-lockfile | 应用内文件锁 |
| /post/tech/word-count | 字数统计 |
| /post/tech/ubuntu-screen-sharing | Ubuntu Screen Sharing |
| /post/tech/electron-protocol | Electron 的 Protocol 实例解析 |
| /post/tech/mac-do-not-distrib | 隐藏所有通知 ── 快捷的开关勿扰模式 |
| /post/tech/fix-zip | ZIP 文件常用结构分析和修复 |
| /post/tech/spell-intro | 使用 Spell 实践深度学习，几乎零配置开始使用 |
| /post/fork-for-mac-and-windows-git-client | Fork for Mac and Windows（Git 客户端） |
| /post/remote-control | 怎样简单的用浏览器控制电脑 |
| /post/tech/macos-wkwebview | macOS 的 WKWebView 基本使用 |
| /post/tech/aws-error | AWS 更新导致的一次错误 |
| /post/tech/reset-microphone | Mojave 的隐私设置和重置权限方法 |
| /post/tech/ubuntu-xfce | 在 Ubuntu Server 上安装简洁版 Xfce Desktop |
| /post/tech/hammerspoon_part2_launcher_and_switcher | Hammerspoon Part 2: Launcher and Switcher / 启动器 |
| /post/tech/hammerspoon_part1_window_manager | Hammerspoon Part 1: Window Manager / 窗口管理 |
| /post/tech/recover_safari_history | 导出 Safari 历史记录 |
| /post/tech/shared_docker_container_and_auto_build | Docker 容器互联和自动构建 |
| /post/tech/nginx_webdav | 用 Nginx 建立 WebDAV 盘 |
| /post/tech/fake-gps | Fake GPS for iOS / 在 iOS 伪造 GPS |
| /post/tech/frontend-library | jQuery 、 Zepto 、 Bootstrap、PureCSS 模块定制大小比较 |
| /post/tech/an-zhuang-centos-i3wm-zhuo-mian-huan-jing | 安装 CentOS + i3wm 桌面环境 |
| /post/tech/nc | nc and socat |
| /post/tech/emacs | Emacs Guide |
1 | { |
文档支持 Front-matter
可以直接输入 date: 后面有详细的日期，然后输入 ---<回车>，变成下面这样，在保存后，站点的文章就会是这个日期
status 设置为 private 将不会发布文章内容
1 | ## status: private |
在 Linux 世界，进程不能直接访问硬件设备，当进程需要访问硬件设备(比如读取磁盘文件，接收网络数据等等)时，必须由用户态模式切换至内核态模式，通过系统调用访问硬件设备。strace 可以跟踪到一个进程产生的系统调用,包括参数，返回值，执行消耗的时间。
strace 常用来跟踪进程执行时的系统调用和所接收的信号，当然 strace 对于代码里的死循环是解决不了的。比如你发现一个进程 CPU 100% 了，strace 恐怕是解决不了的。因为 strace 是看系统调用，一般都是 IO 类操作，既然是 IO 密集，那 CPU 一定不可能是 100%。
strace php abc.phpstrace node abc.jsuptime 会读取 /proc/uptime 和 /proc/loadavg 获取详细信息，怎么去判断的呢？
1 | $ strace uptime 2>&1 | grep open |
也可以使用strace -e open uptime 获得更加简便的，也可以通过 strace -e trace=file -f uptime获取结果相对复杂。
macOS 也有类似
安全问题：sudo dtruss [dtruss_options] -f sudo -u $USER myprogram [program_options]
man -k dtrace1 | dtrace: error on enabled probe ID 1712 (ID 564: syscall::sysctl:return): invalid user access in action #5 at DIF offset 0 |
所以使用 XCode 提供的 instruments 才是更好的方案:
使用 instruments 来查看调用：
就可以看到对应的底层调用
这个是用来替换 instruments 的，用法先看看 man xctrace 吧，功能跟 instruments 类似。
ready close closed 这些事件，但 electron 的事件也非常的多，如果想要更加深入的了解 electron 整个生命周期的流程，需要对应用里面的生命周期，窗口的生命周期以及页面内的生命周期的时机有一个清晰的理解。一图胜千言：
这里把这些事件分成三部分，App 事件、BrowserWindow 事件以及 Renderer 进程中的 Web 事件：
on('will-finish-launching', (event: Event) => {})on('ready', (event: Event, launchInfo: Record<string, any>) => {})on('open-file', (event: Event, path: string) => {}) 【macOS】应该在 ready 之前对 open-file 进行监听。如果想要自己接管文件的打开，应该 event.preventDefault()
触发条件：
Windows 电脑中，需要通过主进程的 process.argv 进行解析
on('open-url', (event: Event, url: string) => {})【macOS】事件 open-url 是处理通过系统通过 electron 应用打开 url 时触发，如果想要自己接管打开 url，应该 event.preventDefault() 。并且要在 info.plist 中定义 url scheme，原话是这么说的：Your application’s Info.plist file must define the URL scheme within the CFBundleURLTypes key, and set NSPrincipalClass to AtomApplication.
on('activate', (event: Event, hasVisibleWindows: boolean) => {}) 【macOS】事件 activate 只会在【首次启动应用程序】、【尝试在应用程序已运行时】或【单击应用程序的坞站或任务栏图标时】重新激活它。
on('did-become-active', (event: Event) => {}) 【macOS】事件 did-become-active 则会在切换到这个应用的时候触发，比如没有窗口的应用或者程序第一次启动。
on('session-created', (session: Session) => {})on('web-contents-created', (event: Event, window: BrowserWindow) => {})on('browser-window-created', (event: Event, window: BrowserWindow) => {})创建一个窗口，都是依次以 session-created , web-contents-created , browser-window-created 创建。但不知道为什么在 app ready 事件后，又触发了事件 web-contents-created 。
on('browser-window-focus', (event: Event, window: BrowserWindow) => {})on('second-instance', (event: Event, argv: string[], workingDirectory: string) => {})on('window-all-closed', ()=>{})这个事件只有一个窗口一个窗口的关闭后，才会触发，其它情况，比如 app.quit 、 cmd+q 或者菜单的退出，或者任何其它方式的退出软件都不会触发。
on('before-quit', (event: Event) => {})如果应用关闭是被 autoUpdater.quitAndInstall() 发起的，那么在所有窗口触发 close 之后 才会触发 before-quit 并关闭所有窗口。
on('quit', (event: Event, exitCode: number) => {})在 Windows 系统中，如果应用程序因系统关机/重启或用户注销而关闭，那么 before-quit 和 quit 事件不会被触发。
on('close', (event: Event) =>{})on('closed', () => {})on('ready-to-show', () => {}) 还没有显示的时候就发起window.onunloadwindow.onbeforeunload 返回非 undefined 就会中断 主进程 close 事件document.addEventListener('DOMContentLoaded')document.addEventListener('visibilitychange')Cmd+q 或者菜单中的退出按钮。app.quit()autoupdater.quitAndInstall()app.reluanch()比如常见的在主进程调用 process.crash() 。
我们常见的命令行退出软件的方式有 ctrl+c ，命令行给进程发送了 SIGKILL 信号，其实还有其它常见关闭进程的方式，可以通过 kill 对进程发送信号，比如 kill -s KILL 24567 或者 kill -9 24567 ：
1 | 1 HUP (hang up) |
Cmd+q 退出1 | ==> app-event: will-finish-launching <=== |
==> window-event: closed <=== 这个事件最后才发送是因为 closed 完全是异步的，closed 不会因为没有执行完就阻塞，应用会把所有异步执行完后才退出进程。
可以通过流程图更加清晰的表达：
【流程图】
ctrl+c 退出1 | ... |
启动后，所有事件正常，但退出通过 ctrl+c 中断应用， electron 就只发出了 before-quit 事件。试试其它方法：
SIGHUP 和正常的退出流程一致SIGINT 效果同上，也是 ctrl+c 发出的信号SIGQUIT 会导致整个应用完全没有任何反应就退出SIGABRT 效果同上SIGKILL 效果同上SIGSEGV 效果同上，也是 process.crash() 发出的信号SIGTERM 和正常的退出流程大概一致，也是 app.quit() 的退出方式app.quit() 退出，这里发现通过这种方式退出，有一些不太一样的地方：1 | ... |
这里多了一个 unload 事件，也可以看出，其实整个应用通过 app.quit 退出才是正常的退出流程， cmd+q 也会导致部分流程会被忽略退出。然后使用 app.reluanch() 也是和 cmd+q 类似，不会触发 unload 事件。
通过 beforeunload 中调用 event.returnValue = false 中断应用的退出和窗口的关闭：
1 | window.onbeforeunload = (event: Event) => { |
通过 cmd+q 会重复调用下面三个事件：
1 | ==> app-event: before-quit <=== |
如果是直接关闭窗口：
1 | ==> window-event: close <=== |
close 事件中断，就只会触发 close 事件：1 | ==> window-event: close <=== |
BrowserWindow
closed事件是没有 event 的。
before-quit 中断，直接按 cmd+q 是不会关闭窗口。1 | ==> app-event: before-quit <=== |
通过
ctrl+c或者上面的一些 SIG 信号关闭，是会忽视这个中断关闭的操作。
will-quit 中断，直接按 cmd+q 会关闭所有窗口，但程序还是激活状态。1 | ==> app-event: before-quit <=== |
通过
ctrl+c或者上面的一些 SIG 信号关闭，是会忽视这个中断关闭的操作。
软件常见的启动有很多，比如通过 open 或者 Windows 的 start 启动，或者通过 url scheme 然后系统启动，或者拖动文档到 dock 或者 tray 启动。下面来说说启动软件后，软件参数和环境的路径。
一般双击软件启动，会经过 will-finish-launching 和 ready ，然后正常进入应用界面。
在应用启动的时候，检测 app.requestSingleInstanceLock() 是否是单例模式，如果是就退出，并且发送一个事件给 second-instance ，从这里再获取退出的应用的 argv 和 cwd。
其实这里检测是否是单例模式的方法是，看看
app.getPath('userData')下是否有 lock 文件。
命令行执行 /path/to/app --arg1 value1 --arg2 value2 document/path ，会在应用启动的时候，通过 process.argv 和 process.cwd
通过 app.setAsDefaultProtocolClient('electron-test') 注册 url scheme，然后在 app 事件 open-url 的 url 参数获取 url 信息：
1 | ==> app-event: did-become-active <=== |
通过 dock 拖拽启动，需要在 info.plist 中声明支持的文件类型，比如 electronBuilder 可以通过 extendInfo 字段中，声明 CFBundleDocumentTypes 注册支持的类型。
触发的是事件 open-file 。
下面是一个 asar 文件头的 json 文件信息，通过这种格式信息，能完整的分析出有哪些文件和文件的目录结构:
1 | { |
下面来分析一个如何从 asar 中读取一个文件。
做出一个类似这样的文件结构：
1 | └── project |
然后执行，就会产生一个 project.asar 的包
1 | npm install asar -g |
可以通过一个 nodejs 脚本代码来获取文件信息：
1 | const fs = require("fs"); |
最后就会生成跟上面一样的文件结构：
1 | { |
下面来试试读取其中的 index.js 文件，先指定一个路径 child-dir/index.js。定位到文件大小 27bytes，偏移量为 0。
1 | const fileInfo = { |
看来可以读取到文件内容了。
其实可以直接通过编辑器打开 project.asar 文件，里面基本就是没有压缩的文件，是一个很简单的单文件档案。
文件中的代码都是改编自 asar 原来的代码，有兴趣也可以看看：
]]>这种技术有一个非常有名的库：html2canvas，可以支持相对比较简单的 DOM 截图
目前一直是处于实验状态（very experimental state）,如果理解这个库的限制，那么是一个还不错的选择
原理是使用 BoundCurves 对 DOM 进行 path 绘制。例如下面一段选自 html2canvas 库中的代码：
1 | this.topLeftPaddingBox = |
计算每一个 DOM 的形状，再把这些数据，比如 topLeftPaddingBox 放到 Stack 中，最后放在队列中，一个一个的绘制。
优势
劣势
如下简单的例子，可以把 DOM 通过 svg 的 foreignObject 放到 canvas 中，就可以截图了。
1 | // 这段代码出自它处 |
做得好的是 rasterizeHTML.js，同时可以支持直接填写 url，然后获取后自己截图。
rasterizeHTML.js 和 html2canvas 的区别
之前是 rasterizeHTML.js 使用 foreignObject，而 html2canvas 自己从最基础的开始。
推荐直接使用 foreignObject 更加安全，目前 html2canvas 和 rasterizeHTML 都兼容使用 foreignObject (html2canvas 看源代码里面已经支持了）。
1 | const captureStream = await navigator.mediaDevices.getDisplayMedia({ |
比如在 Chrome 中执行，会弹出下面的窗口，然后开启屏幕分享：
这种可以实现录制整个屏幕，或者某个 Tab，从而分享画面，不过录音这个功能会碰到一些阻碍。
优势
劣势
Electron 内置了一个截取网页内的接口 webContents.capturePage ，如下：
1 | const remote = require("electron").remote; |
优势
劣势
DesktopCapturer 模块里面可以通过设置录屏的 video，然后通过 canvas 获取录制屏幕数据。前面的 getDisplayMedia 也可以通过这个方式获取到截屏图片。
例如下面的代码：
1 | const { desktopCapturer } = require("electron"); |
之前看到有个地方，用 Thumbnail 拿来做屏幕截图 :P
1 | const { desktopCapturer } = require('electron') |
优势
劣势
这种就不细讲了，每端都适配复杂的原生接口，这样就已经迷失方向了。
如果用上面的任何一种方法，在高分屏里面截图(window.devicePixelRatio === 2)，最后得到的图片还是图片宽高放大一倍，但像素还是低一倍。
后来发现其实是图片头中有记录 meta 信息。里面就有关于 dpi 的信息。找到包 changedpi 可以修改 canvas 和 DataUrl 拿到的图片 dpi。
1 | // 创建一个标准的 72 dpi |
canvas 一般情况下，最高只能获得 72 dpi 分辨率的图片。
每个点都没有太详细的讲，但已经可以通过这些选择最终的方案了。最后当然推荐使用的是 webContents.capturePage 的方法。简单易用，在功能上能做到最好。
实现的一个示例 demo: https://github.com/yantze/demo-electron-remote 。
默认的 ipc 协议是可以传送可以结构化的数据。remote 需要完成的事情是，对不能结构化的数据，用元信息(meta) 记录，然后 remote 需要被调用的时候，发起 ipc 请求到主进程或者 server 进程，远程调用方法。这里是实现一个简单的 remote 调用机制的流程，方便了解 remote 的整个调用流程。
下面分析从一个简单的结构开始，逐渐到复杂结构体，来实现跨进程的传送。
1 | // server.js |
这里实现一个相当简单的进程间传送数据的例子，当 server 进程 fork 一个 child 进程后，child 发送一个请求，然后 server 接受数据后，发送给 child 一个自身的对象，然后 child 就接受到了这个数据对象。
但一旦这个 remoteObj 对象中包含了一个方法，或者 Promise 这些不可结构化的数据，那么对应的数据就会丢失。
其实实现的方式也还好，就是判断这里面是否有 function, 如果有，就使用元信息包裹一下这个 function，记录方法名。因为当 client 进程调用对应的方法的时候，需要向 server 进程发起请求，server 接到请求后，需要找到对应的 remoteObj, 并且定位到方法名，就可以 remoteObj[functionName]() 实现远程方法调用了。
既然需要记录方法名等额外数据，就需要 meta 去包裹方法，这里 server 需要需要一个新的方法 valueToMeta，而 client 需要一个解释 meta 的方法， metaToValue。
1 | // server.js |
这里可以看到，判断为 function 后，valueToMeta 会把将 function 解析后变成 4 个数据字段返回，id 和 members 可以可以暂时不管，因为暂时不考虑 class 类。然后 client 进程就能通过 metaToValue 解析并且还原 remoteObj 的结构。
这个时候，就要开始复杂的嵌套分析和解析了。其实也是在上一小节里面，再加上一个嵌套，就是如果分析到一个新的对象，那就把这个子对象存起来，当子对象的方法需要被调用的时候，就需要通过 id 找到子对象，并且通过方法名调用子对象的方法。
这时需要用到上面代码中出现的 parseMembers 方法了，这个方法能解析 object 中的所有自有对象，并且把子对象再次放进 valueToMeta 中，做递归循环。
1 | function parseMembers(value) { |
不过这里会忽略一些属性，在 IGNORE_FUNCTION_MEMBERS 中有声明，比如 arguments 这个 function 的自有属性。之所以把 type 改为了 method ，是因为这个一个对象的方法，需要使用 id 去寻找方法的上层对象。
其实通过上面的介绍，已经基本清楚整个 remote 的调用流程了，如果不明白可以直接访问我新建的一个 demo 仓库，里面可以完整地运行一个简单的 remote 调用。
chrome://inspect./client.jsconst obj = await require('./client.js').getRemoteObj()试试，应该还挺好玩的 :P。
1 | clientProcess = cp.spawn("node", ["--inspect=9230", "./client.js"], { |
这里的 ipc 参数，能让 nodejs 在 spawn 子进程的时候，加上一个 ipc socket 隧道，默认是没有加的，那样将不能使用 process.send 方法。之所以 child_process.fork 方法可以使用 ipc，是因为 fork 其实是 spawn 的一个封装方法，里面有加上 ipc 这个参数。
./electron/lib/browser/remote/server.ts 和 ./electron/lib/renderer/api/remote.js这个库的源码在这里 deasync。最好是看了我上一篇的介绍 NodeJS debug C++ 的那篇文章，同样的内容我就不注释了。
这其实是一个 NodeJS 的 C++ 的插件。核心代码只有下面的一些：
1 |
|
这里面用的是 N-API 的接口，但这个库里面的代码不能正常的编译出 Debug 模块，所以把这核心代码拿出来又写了一个新的库，然后重新编译即可。
直接看代码：
1 |
|
uv_run 显式的运行一次 EventLoop, 并且暴露 run 方法，然后用在下面的 js 代码中：
1 | const deasyncAddon = require("./build/Debug/hello.node"); |
先不管 process._tickCallback()，看起来就像是写了一个阻塞的循环代码，只有 pred() 或者 isEnd() 结束后才会中断：
1 | const wait = function (time) { |
但几乎完全不一样。pred 这个回调方法完成后，就会终止，而不像 wait 方法让整个线程都阻塞，干不了其它事情。
在 loopWhite 方法中， process._tickCallback() 的使用也很巧妙，在 NodeJS 源码中有说：
1 | process.nextTick = nextTick; |
在正常的代码中出现 _tickCallback()，则马上执行之前所有的 nextTicks 任务，接着执行同步任务。但我看 runNextTicks 源码的时候，发现其实是执行 runMicrotasks 😂。所以会把 Process.nextTick、Promise.then catch finally、MutationObserver 这些全部执行完毕后，才会进入下一步。
所以如果代码是这样的：
1 | setImmediate(() => { |
为什么会这样呢？因为 nextTicks 的名字有误，nodejs 网站上面有说， setImmediate 意思应该互换 nextTick。nextTick 才是在同一个阶段立即执行, 而 setImmediate 是在 EventLoop 接下来执行，或者在 tick 上触发。(文末参考链接)
首先 deasync 库把 loopWhile 封装成一个等待方法：
1 | function deasync(fn) { |
然后可以写一个简单的阻塞 sleep 方法：
1 | const sleep = deasync(function (timeout, done) { |
更多可以去看看 deasync 中的例子。
deasync 默认只处理带 callback 的方法。如果是想要处理 promise 的方法，需要包裹一层转化一下。
1 | const unPromisify = (fn) => { |
还有一个类似功能的库：node-fibers，不过它的实现原理不同，并且复杂得多。
node-gyp。这次介绍如何写一个简单的 hello 插件，并且能 debug C/C++ 代码。node-gyp 编译的项目1 | npm install -g node-gyp |
新建目录 hello, 并 npm init -y。
binding.gyp 文件，用来配置 node-gyp1 | // binding.gyp |
1 | // ./src/hello.cc |
例子来自： https://nodejs.org/api/addons.html#addons_hello_world
1 | node-gyp rebuild |
会生成 build/Release/hello.node 文件
在 package.json 的 “scripts” 字段中，添加：
1 | "scripts": { |
之后在 Visual Studio Code 中就可以直接执行 Task 了。
执行 Task 的方式是：通过快捷键 Command+P 在弹出的框中，输入
task build:dev就可以执行对应的命令了。
index.js 并在里面添加如下：1 | const helloAddon = require("./build/Release/hello.node"); |
这里的 helloAddon 就是编译的结果，等同于 js 代码 module.exports.hello = () => 'world'。
接着执行 node index.js 即会输出 output: world 结果。
node-gyp 编译出 Debug 版本的 hello.node1 | node-gyp rebuild --debug |
这样会重新编译 hello.cc ，并且生成 ./build/Debug/hello.node
ms-vscode.cpptoolsvadimcn.vscode-lldb<node.h> 是红线，因为没有找到对应的头文件Command+Shift+P 弹出的下拉框输入，C/C++ configuration (UI)添加头文件路径可以参考我的，这样代码里面的头文件 node.h 就不会影响
1 | "/Users/xxx/node-investigation/n1/node/src/**", |
接着把先前 index.js 的代码 Release 改成 Debug
1 | const helloAddon = require("./build/Debug/hello.node"); |
在项目中 Command+Shift+P 弹出的下拉框输入 open launch.json ，会显示这个打开 launch.json 的选项，然后添加：
1 | { |
这样下次开始 Start Debugging 的时候，会依据 launch.json 执行，当给 hello.cc 标记断点后，程序会在断点出断点。
注意：只有装了 lldb 插件后，才能使用 type: “lldb” 选项值。lldb 是 llvm 的一个类似 gdb 的实现。这个插件用来支持 llvm 编译器的。如果在 Windows 中，可以用 vscode 自带的
cppvsdbg。
就是先启动 NodeJS 调试后，接着启动 C/C++ 调试器，这样在深入 js 代码的过程中，还可以进入到 Addons 中去。有了上面介绍的基础，实现混合调试简单了很多。
在 launch.json 中的 configurations 数组中，继续添加如下配置：
1 | { |
这样，就可以在 Start Debugging 的时候，选择 JS Debug Build 可以调试断点 JS 代码了。
注意：调试 JS 代码，需要让 Debugger 面板切换到
JS Debug Build,如下图
继续在 launch.json 中添加如下配置：
1 | { |
把 Debug 面板的 Debugger 切换到 Attach C/C++ Addon， 接着再启动即可。这里的 request: “attach” 是让 lldb 链接到 nodejs 进程中去 Debug。所以下面的 pid 字段就是启动后，会弹出下拉框，然后选择要 链接的进程。一旦链接成功，就可以对 C/C++ 代码断点了。
如果没有成功可以参考我弄的一个 demo 仓库： https://github.com/yantze/demo-nodejs-addon-debug。
注意，里面的 c_cpp_properties.json 需要自己修改 include 路径。
如果还想弄 Node Addon API 的 NAPI 接口，配置算是类似的，就不再赘述了。不过，如果使用的是 NAPI 的代码，就不需要 node 和 v8 的头文件了，并且官方推荐的也是 N-API 实现插件。
]]>这样应用内的所有磁盘 IO 都被应用程序统一接管，如果需要做比如权限管理、Bookmark、文件缓存、虚拟文件系统等，这些都可以做一个中间层，也有一定的使用场景。
首先设计了六个方法，获取读锁、释放读锁、获取写锁、释放写锁、读文件、写文件。读文件里面封装了读锁的获取和释放，写文件里面封装了写锁的获取和释放。接口的方法如下：
展示一下 read 简单封装了 obtainReadLock ，并且在执行读文件操作后，调用 releaseReadLock 释放读锁。
1 | async function read(fp) { |
obtainReadLock
obtainWriteLock
注意：要先把新生成的写锁放在 writeQueue 中，因为其它方法可能会访问这个写队列
另外两个方法也是类似的，这样一个完整的应用层的锁就写好了。
是一个简单的 Promise 锁。构造一个方法，生成一个 Promise 实例，然后把里面的 resolve 方法引用到一个对象中，当需要释放锁的时候，调用 resolve 方法就能继续执行。如下面的例子:
1 | function generateLock() { |
这样的设计后，还是有两个扩展的问题
以及多线程操作的问题
多线程进程的解决方法也好处理：前文说了，read & write 封装是应对一般的需求，如果要做 ipc 通信，或者一些权限处理，或者缓存文件等，可以自行封装和完善。
这里是 npm package 的地址: fs-lockfile 。
]]>一般情况下，统计的时候，Emoji 是算成一个数，但 ES6 之前的 api 是会把这种字符算成多个。
String.prototype.length1 | "中文".length; // 2 |
最后一个 🙋♂️ 的长度有 5 个字符，中间有一个零宽字符 \u200D，能把两个 Emoji 合并成一个。 最后有一个 \uFE0F 是一个变体选择器。 可以看文末参考链接。
下面是一个黑色皮肤的举手 Emoji：
1 | console.log("\uD83D\uDE4B\uD83C\uDFFF\u200D\u2642\uFE0F"); // 🙋🏿♂️ |
这里面的 \uD83C\uDFFF 代表的是黑色皮肤，如果是 \uD83C\uDFFB 代表的是白色皮肤，可以看参考文末链接。
Array.from1 | Array.from("中文").length; // 2 |
这里会把 🙋♂️ 分拆成四个部分 ["\uD83D\uDE4B", "\u200D", "\u2642", "\uFE0F"]
1 | console.log("\uD83D\uDE4B"); // 🙋 |
所以使用 Array.from 也不是一个比较好的统计字数的方法。
ES6 之后给 REGEX FLAGS 添加了 u 标识位，对 Unicode 更加友好的支持。比如：
1 | '𠮷'.match(/\S/g).length // 2 |
但在处理组合的 Emoji 的时候，还是没有比较好的处理：
1 | '🙋♂️'.match(/\S/gu).length // 4 |
后来发现一个字数统计的正则：
1 | const ASTRAL_REGEX = |
写了一个脚本分别测试原生 length、Array.from、/\S/gu、REGEX_UNICODE_CHARACTER 测试判断的长度时间：
1 | const UNICODE_WORD_REGEX = /[\u00ff-\uffff]|\S+/g; |
通过测试 190 个字，循环 100000 遍，得到执行结果如下，使用 UNICODE_CHARACTER2_REGEX 是一个折衷方案中最好的方法。
1 | 使用方法 | 计算长度 | 耗费时间(ms) |
UNICODE_CHARACTER2_REGEX 统计出的 19000000 才是正确的。
这里的 FITZ-(1~5) 就是不同的五种肤色，从 \u1F3FB – \u1F3FF 共五个。
常见的有: