WangJie's blog

Arc 初体验

Sat, 16 Jul 2022 15:16:48 GMT

Arc 是 the browser company 推出的浏览器。很早之前就有过宣传，号称是划时代的新型浏览器。而在六月底，终于开放了测试。我在收到邮件后第一时间下载测试。并且重度使用至今，已经两个多礼拜了。感觉真的很棒很炫酷。这里写一下评价和使用感受。

it's called Arc pic.twitter.com/1dl2H2Ca4e
— The Browser Company (@browsercompany) April 19, 2022

做出的改变

标签页 & 书签

Arc 最大的特点就是对于传统浏览器标签页 (tab) 的改变。传统浏览器会将标签页平铺。很容易导致打开一大堆标签页无法管理的情况。虽然 Chrome 和 Firefox 都相继支持了分组和固定的功能。但是对于标签页的管理仍然困难重重。因此也有诸多浏览器扩展试图弥补这一点。但是终究有所局限。

而 Arc 将标签页和书签的管理相互结合。最明显的就是左上方只有 icon 的 favorite 列表。对于很多常用的基于浏览器的应用，比如邮箱、IM 之类的应用，常驻一个标签页使得切换起来非常方便。我此前的主力浏览器一直是 Chrome，在使用 Chrome 的过程中我也经常会把 Gmail、telegram 这些始终会开一个的应用 pin 在最前面。可是 Chrome 在 pin 了之后的标签页非常小，点起来很不方便。而且每次因为重启关闭浏览器之后再打开，标签页也不会保留。而 Arc 直接将其固定，可以说是完美解决了这一问题。不过 favorite 列表目前也被限制为了最多 8 个。

另外就是标签页就等于书签。其实在日常使用过程中就有这样的感受。每次使用过程中，在一段时间内频繁打开的始终就那些页面。可是一直开着又会很占资源，关了之后再打开又很麻烦。而 Arc 直接将书签和标签页组合。会有一根线将标签页进行区分。下面的页面在关闭后，tab 也会直接消失。而上面的则关闭后 tab 还会保留。需要时就只要点一下，就像没有关闭一样，切换起来非常自然。而下面的临时标签页也可以很方便的一键关闭。可以通过这种方式很快的清理资源，整理思绪。

这是我的 Chrome 浏览器的画风：一大堆常用的书签。我每次想要使用都要点一下打开一个新的页面，要不然就是从一大堆打开的标签页中寻找。相比 Arc 使用起来很麻烦。

Space & Folder

Arc 将标签管理作为核心能力，提供了 space 功能。这也是当你打开 Arc 时非常明显告诉你的一个功能。浏览器作为目前最为重要，不可或缺的软件。不管是在工作、学习还是娱乐都会用到。而在通常的浏览器当中。对于此类状态的切换十分不顺畅。虽然大部分浏览器也可以多窗口（window）。而且近些年，也提供了直接「重新打开关闭的窗口内的所有标签页」之类的功能。但是问题在于每次重新打开的过程都会非常的卡顿。而且也不是每次都需要打开所有的标签页。如果所有窗口的所有页面都保持打开，那么会非常吃资源。而不一直打开，需要切换时又会非常麻烦。

而 Arc 除了直接将标签页和书签结合之外，同时提供了 space 的功能。你可以通过点击图标或者快捷键快速切换。而因为书签就是标签页。你也不需要一次性打开所有相关的页面，只要直接点击标签页切换就行了。而因为标签页就是书签。你也不需要为了区分各种状态，去费力的分类或是整理自己的书签。

这点真的是非常好用，也非常实用。

地址栏 = command bar

现在很多重大的产品都提供了聚合众多功能的 command bar。诸如 Mac 系统自带的 Spotlight，最为著名的 Alfred，以及最近大伙的 Raycast。然后 GitHub、Vercel 等等很多知名的网站。毋庸置疑这确实是非常高效易用的方案。传统浏览器在这方面也有很多尝试：有非常多类似 Alfred 的浏览器扩展，Chrome 的地址栏也一直可供扩展使用，并且也逐渐内建支持了搜索以外诸如标签页切换之类的功能。

而 Arc 则直接将浏览器最主要的地址栏缩小到左上角的一块，并且只显示域名部分。而主力推荐使用 Command + T 快捷键唤起地址栏，这也是传统浏览器打开新标签页的快捷键。其实就在传统浏览器当中，在需要访问的各种站点越来越多的时候，当要打开一个页面通常也是在地址栏直接搜索或者输域名，而不是在书签栏里寻找。Arc 对此做成的结合和改变无疑在现代使用中非常方便快捷。

Note & Easel

这应该算是比较无关紧要的功能了。但是也是 Arc 精心设计和大力宣传的一点。我这两个功能使用的不多。因为我已经有稳定信息汇聚和整理工作流了。但是这里也简单介绍一下。

Arc 的 Note 类似 Notion，是一个基于 Block 的富文本编辑功能。而 Easel 类似 Figma 新出的 FigJam 功能。区别在于 Arc 提供的功能较少，但是因为基于原生实现。有着非常好的性能。并且和 Arc 自带的网页元素截图功能，标签页功能结合的非常密切。如果整体作为一个工作流，使用起来会非常方便。

其他一些锦上添花的功能

Little Arc

开启这个功能之后在其他所有软件中点击链接都会在当前桌面（Desktop）开启一个单独的窗口显示。相比传统浏览器有了两点极大的改善：

首先在以往浏览器会直接在浏览器打开，如果浏览器不在同一个桌面，那么会感觉工作流程被突然打断，会很不爽。而 Little Arc 直接在当前桌面大概，非常平滑自然，感觉就像所有软件都有了链接预览功能一样。非常舒服。

其次，他的窗口和传统浏览器的窗口不一样，传统浏览器有两种窗口，一种是正常的 window，另一种是没有书签栏之类其他功能的 frame。前者会切换桌面，性能很差，而后者则窗口默认很小，切无法切换成正常 window 里的 tab。相反，Arc 的独立窗口性能非常好，而且可以一键切换成正常的 tab。在其他软件和浏览器结合的工作场景中非常流畅自然，体验非常好。

Previews

Arc 为个别常用网站定制了预览功能。比如 Gmail、Figma 等。这些网站只要鼠标移动到标签页上，就可以弹出一个小窗，以定制的原生 UI 显示网站的内容。因为是原生实现，而且是定制的 UI，并非是原本网页的缩小预览，性能和体验都会非常好。然而这个纯粹是锦上添花，支持的网站非常少，而且也无法满足所有人的偏好，开发起来成本也会比较高。

如果之后能将这个能力提供给第三方开发者来开发可能会有所作为。目前真的纯粹是锦上添花。

Library

Arc 在左下角隐藏了一个 Library 功能，可以浏览电脑里的文件，在拖拽到网页的场景时会非常方便。但是 mac 本身就可以将 folder 固定在 dock。并且交互已经挺好了。所以这个功能也是纯粹的锦上添花。

但是值得一提的是，在 Arc 中，文件、包括下载的文件，都可以放在 tab 栏中，也就是说你可以把文件，比如 PDF 之类的，也和书签之类的放在一起管理。在经常需要把下载的 PDF 和网页一起管理的场景来说是非常方便了。

总结

其他可能还有一些功能，这里就不完全介绍了。以上说的都是一些比较重要，核心的改变和功能。其他的如果想了解更多可以看官方的 Notion Page：Arc Resources。

个人感受和看法

上面主要是对于 Arc 功能的介绍，也包含了我感觉比较好的一些感受。这里在整体介绍一些和功能无关的。

其实前几年看到 the browser company 的宣传，对他们号称的「未来的」浏览器，我的期望非常高，而我第一次打开 Arc，除了开屏动画，感觉并没有非常的惊艳。之前从宣传的视频或者媒体的信息来看，可能是一种全新的浏览器工作方式。比如所有网页都在一个类似锤子的无限屏的无限扩展空间内展示。然而现在还是基于传统的标签页的方式。但是目前的 Arc，可以说在创意、设计、未来，这些点之间达成了一个目前最佳的平衡。目前的 Arc 应该不只是这家公司最终的愿景。但是也带来了足够的革新。

目前来说，没有必要，也没有可能，完全从零开发一款浏览器。Arc 完全是基于 Chromium 开发的。而 Arc 相比其他的一些新兴浏览器产品体验要更好。

基于 Chromium，确保了下限

其他的很多浏览器也是在 Chromium 之上包壳制作的，但是很多浏览器会把 chromium 作为一个 fork，在其之上大作修改。砍掉很多 chromium 自带的功能，然后有加入一些鸡肋的功能。定制一套和原本类似的 UI。强行按上一个自己的品牌。甚至很多年前国内的一些浏览器还会愚蠢的占很大一个空间展示一个自己的 LOGO。我不知道那样的意义何在。而且过多的修改导致没法跟随上游的更新。其实就是一个垃圾的 fork。并没有任何意义。

而 Arc 基于 Chromium 之上对他来说则是确保了这款浏览器的下限。Arc 是一个功能上完全没有阉割的 Chromium。所有内置的页面都有（可以通过 chrome://chrome-urls/ 查看并打开）。这就决定了用户从 Chrome 或是 Chromium 切换过来没有任何的体验下降。我之前尝试很多各种各样的产品，又最终放弃，很大程度都是因为那些产品做了一部分额外的功能，但是又丢失了原有的一些功能。而 Arc 则对 Chrome 所有的功能都有。我从 Chrome 切换到 Arc 的过程非常平滑和自然。

在初次打开时，可以直接登录 Google 账号，之前的所有浏览记录和扩展都会被同步过来。我此前在 Chrome 会有一大堆扩展，完全无法离开。而即使切换到 Arc 也不会丧失这些能力。

但是另一个视角来看，这也可以说是 Arc 的妥协。如果没有这些能力，可能我在切换的过程会很痛苦。以至于我最终无法完全切换过来。不过还是更启动更多更高程度的创新。我相信足够的创新可以重新定义使用习惯和交互。

极高的性能和额外的优化

Arc 最大的特点就是他优秀的 UI 和交互。而在这样炫酷的 UI 和交互之上，他的体验和流畅程度相比 Chrome 完全没有下降，反而还有所提升。除了他完全原生的 UI。而且正是因为他把标签和书签结合的设计。他可以更方便自然的优化闲置标签页。从而带来比 Chrome 更好的性能体验。

性能是我刚切换来时最大的顾虑，因为我在使用 Chrome 的过程饱受糟糕的性能和侵占大量电脑资源的困扰。而切换到 Arc 在性能方面反而更好，这点是着实惊艳到我的。光是这点就给我足够一直使用 Arc 的理由。

总结

Arc 目前还在积极的开发当中。甚至我后来在和朋友的推荐中才知道这次开放下载还不是完全可供所有人使用。现在似乎还得先在官网加入 wait list。不过我这些天对 Arc 的尝试着实久违地收到来自这样优秀和创新的产品的触动。

SPA 应用切换页面如何保留滚动位置及可能遇到的问题

Wed, 10 Nov 2021 22:53:49 GMT

在应用中通常会有在页面切换时保留滚动位置的需求。一种方式是自行控制滚动状态。但是其实浏览器很早之前就可以自动保存页面的滚动位置。

可以参考 History API: Scroll Restoration

浏览器的滚动位置保存在 history 中。在使用 history API 手动控制 url 时也可以保留滚动的位置。

但是如果在 SPA 应用中，页面切换时，如果首屏渲染的页面高度不够原本的滚动位置，就会出现滚动位置不对的问题。

示例

下面以 React + React Router 为例，演示一下这个问题。

export default function BasicExample() {
  return (
    <Router>
      <Switch>
        <Route exact path="/">
          <ItemList />
        </Route>
        <Route path="/item/:id">
          <Item />
        </Route>
      </Switch>
    </Router>
  );
}

有两个页面，分别是一个 item list 和 item 的 detail 页。

function ItemList() {
  const list = useMemo(() => {
    return Array.from({ length: 50 }, (_, i) => {
      return (
        <Link to={`/item/${i}`} key={i}>
          <div
            style={{
              width: 200,
              height: 100
            }}
          >
            {i}
          </div>
        </Link>
      );
    });
  }, []);

  return (
    <div>
      <h2>ItemList</h2>
      {list}
    </div>
  );
}

function Item() {
  const history = useHistory();

  return (
    <div>
      <h2>Item</h2>
      <button onClick={() => history.goBack()}>back</button>
    </div>
  );
}

Item Detail 页有按钮可以返回列表页。也可以直接用浏览器的返回按钮。

可用代码的完整内容可以在 CodeSandbox 查看。（但是在 iframe 的预览框里没法保留位置，需要在新页面中打开预览地址）

无法保留滚动位置的情况

但是一些开发的时候，可以会默认进行一个 loading 的操作。


function ItemList() {
  const list = useMemo(() => {
    return Array.from({ length: 50 }, (_, i) => {
      return (
        <Link to="/about">
          <div
            style={{
              width: 200,
              height: 100
            }}
          >
            {i}
          </div>
        </Link>
      );
    });
  }, []);

  const [loading, setLoading] = useState(true);

  useEffect(() => {
    setLoading(false);
  }, []);

  return (
    <div>
      <h2>ItemList</h2>
      {loading ? "loading" : list}
    </div>
  );
}

这时在第一次 render 时。页面上只有 loading，而没有渲染整个列表（虽然这个列表之前被渲染过了。他的数据可以被缓存下来）。

如何排查这样的问题

如果代码比较复杂的时候很难确定是在什么地方导致列表没有渲染。这种情况如果要排查的话可以用到 React Devtool 的 Profiler 功能。

先从列表页进入内容详情页。然后点 profiler 页的 Record 按钮。

然后返回列表页。然后 Stop Profiling。

之后就可以看到这期间的页面 rerender 的过程。

这里可以看到在第二个 frame 中页面切换到了列表页。但是这时并没有渲染列表。

在第三个 frame 中列表元素才渲染出来。

所以就可以知道没有渲染列表元素的组件层级。然后就可以比较好的缩小排查范围了。

（但是很蛋疼的是组件全是 Anonymous。又可以写一篇这方面的最佳实践了_(:з」∠)_

Git 工作流程的演化

Sat, 30 Oct 2021 00:00:00 GMT

很多人协作的 git 仓库经常会变的非常混乱。但是在有一定规范的情况下还是很好避免的。

抖音有一个 pack item 服务。负责包装视频对象上的信息，过滤视频等。每个业务线都可能在视频上加一些自己业务用的字段。这个结构体包含几百个字段。这个服务会有几十个业务线 & 数百个研发提交代码。并且这个服务有上万个实例，滚动升级一次需要几个小时。升级需要排队。这个服务几乎无时无刻不在升级。而这样的服务在抖音还有很多。

这篇文章会介绍一下 git 工作流程的演化过程。以及我们如何避免团队开发中的 git 工作流程的混乱。

背景

这是一个混乱的 git 仓库的 log graph。很难追溯历史。甚至我都不知道该从哪个分支切新的分支。

这在人多的项目比较常见。但是有一定规范的情况下还是挺好避免的。

理想情况

最理想清晰的 git log graph 是下面这样，一个 feature 接一个 feature，非常清晰。

理想的 git log graph

实际情况

通常情况

但通常因为协同开发会产生分支之间重合的情况。

更糟的情况

更糟的情况下分支都来自非常久之前的版本。这样后面的 PR 很容易和之前的代码产生冲突。

一种解决方式是在 feature 分支上合并一下主干。

但是这种情况下之前分支的代码就会被悄无声息的修改。因为通常来说这个 merge 主干产生的 commit 是一个大而杂的 commit。很难注意到其中包含了一些因为解决冲突带来的问题。

（类似这样）

并且可能一段时间之后，之前代码的作者发现自己的代码被人改了。但是很难从 log 里找出是谁改的。

通常来说可以用 git blame 很容易找到一行代码最后是被谁修改的。但是因为 merge 操作仍然会保留之前的 commit message，但是主干上的代码经过多次 merge 之后就指不定显示 author 是谁了。。

并且会导致 log graph 很乱。不知道这个改动是从什么时候开始的。

同步上游的推荐方式

另一种比较好的方式是通过 rebase 上游。让这个分支看起来像是刚刚 checkout 出来的一样。这样 git graph 就不会和其他的交叉。可以很清晰的看出这次 PR 包含了哪些 commit。并且如果在 rebase 期间解决了冲突，那么这部分变更会明显的显示出他的作者。

但是如果之前分支上就包括了多个 commit，那么在解决冲突时可能会发生多次冲突，可能需要解决多次冲突。这时可以先在原本分支 squash 一下。把多个 commit 合成一个 commit。这样只需要解决一次冲突了。

并且很多情况下一次 commit 并不是一个完整的 feature，那么最好也在合并到主干之前先 squash 一下。

GitLab 可以设置自动 fast-forward 到目标分支，这样可以自动让 log graph 不会交叉。但是 GitHub 没这个功能。所以只能靠大家手动做这件事情

开发分支

通常来说在 reviewer 比 developer 少很多的情况下会出现开头的情况。因为 PR 到很迟才会被 review。这样也很容易造成 PR 之间冲突。而且如果一个 PR 被放了很久然后又要回过头来解决冲突挺麻烦的。

这种时候会有个中间的开发分支。这个分支合并的需求比较低（可能没有完整的 review 或者测试，但通常也经过自测并且通过 CI 可以编译）。而一段时间之后再从 dev 尝试合并到主干。这时 review 和测试就会比较完全。

Release 分支

这个和上面的 git graph 是完全一致的。但是会直接合并到主干。类似目前的情况。

而通常来说 release 分支只有一个（在 git flow 中）。多个版本的情况其实应该非目前版本的代码就暂时不合并。而一个版本确定后也不会再变，所以一般会用 tag 来保证不变（不然任何一个 release 版本都可以 fast forward 到下一个 release。这个带版本号的 release 分支就很鸡肋了。）

Review

理想情况下每个 PR 都应该及时经过 review 并尽快合并。避免迟迟不合并造成和上游冲突导致的风险和开销。最好情况下每个 PR 都由项目的 PO (primary owner) review，如果没有 PO 则由相关代码的原作者 review，如果是新 feature 则由这部分的 BP (backup person, or business partner) review。

从字节跳动离职啦

Sat, 29 May 2021 11:28:34 GMT

昨天离职了，又可以写一篇阶段总结了。现在博客好像只剩下个人总结了。不过之后应该可以多一点时间写文了。

从 19 年开始在字节跳动实习，到现在也快两年了。之前是在基础架构做内部 CI 平台，然后今年一月转岗到抖音做 POI。尽量客观的说一下自己的感受吧。

字节的优点

整体上还是蛮挺喜欢字节的。毕竟从那么多家公司中选择了字节。之前有老哥问。总结了一下我感觉字节的优点：

内部轮子多
基础设施总体来说大部分建设的还是比较好的
相对比较扁平开放
工资和工作环境还可以

内部轮子多

好处是很多事情不用重复去做，基本上所有能力都有人做了封装。同时每个人也都可以把自己想到的功能封装成库或者 CLI 给别人使用。因为公司规模大到了一定程度，内部就像一个社区一样。

基础设施

公司内几乎所有能想到的能力都做成了 web 服务。从面向研发的计算存储能力，到面向各种职能的各种能力，都有对应的平台。而且还都有很多选择。

物理机，虚拟机，应用引擎，流式处理，对象存储，CDN，负载均衡等等。

存储包括：关系存储、文档存储、KV 存储、列式存储、图存储、ES、HDFS、HBase、HTAP 等。

并且每个存储还提供很多种方案：分库分表、主从模式、分布式。

消息队列也提供很多种：Kafka、RabbitMQ、RocketMQ 等。

每一个都做了很好的封装，而且提供了对应的 WEB 平台，各种语言的 SDK。

上面列的这些都不光包含把开源软件做成服务，还包括了各种自研的解决方案，而且做了良好的封装，而且通过 proxy 或者 shim 等方式对开源产品的 API 进行了兼容。可以隔离研发的理解和学习成本，但是又对于性能和容量上限进行了极大的提示，同时还拥有更低的经济成本。

然后用户行为分析，内容管理，运营平台，低代码建站，Serverless，工单系统，自动化工具，CI/CD，用户反馈平台等等。基本上能想到的能力都有对应的平台。而且很多都有不止一个，基本上适应所有使用场景。

而且这些所有都几乎不限量使用。所有东西都可以随便用，随便玩。然后如果有实际场景和业务需要，又可以在合理范围内无限扩容。这爽快的感觉不言而喻。这些有些有专门的部门和团队在做，有专门的产品经理和设计师，也有一些是个人自发做的。但只要做的好就可以获得更多资源做的更大。很多产品基本上随便拿一个都可以商业化。

这其中的既包括自上而下的也包括自下而上的。几乎每个人，不管是底层的研发，还是每个部门或者业务线的 leader。都可以自发做自己想做的平台、产品和功能。并且可以在公司内自由的推广。公司内就像市场一样，每个人都有各种机会，而且还没有经济成本。

相对比较扁平开放

除了上面提到的可以自发做很多自己想做的事情之外。在制度上每个人也都有很多的机会去做出推动和变革。比如之前组的一个老哥，一来就对于我萌做的平台的 A11Y，还有代码工程质量做了很大推动。这些没有上级会要求你做，也不会限制你做。只要可以做得好，带来收益，每个人都可以做任何想做的事情。并且还有机会获得上级和同事的支持。

即使是抖音一线业务这样卷的地方，也都有很多机会去做自己想做的。比如部门里就有一个老哥从一个人推动单测的建设，到获得部门老大的支持，大范围的推广。

但是这些也都需要有额外的付出，需要真切解决一些实际的问题才可以。不是任何一个人光扯嘴皮就可以的。当然，如果作为 leader 或者负责人确实可以有更大的权力。但是因为相对比较开放的沟通和评价机制，即使是作为老大的角色通常也是可以听取意见并作出改善的。

工资和工作环境还可以

工资就不说了。在能有还可以的工资之外还可以有不错的工作环境。包括各种可有可无的小恩小惠，可以白嫖零食饮料、办公用品、外设、设备、耗材。这些虽然对于不同人需求不一样。但是字节可以不会因为工资给的多点就克扣这些东西。相比国内公司福利做的还可以，相比国外公司工资还可以。

（当然也只能说是还可以了。实际上每天还是会对公司里的各种东西各种吐槽。但是这种算是在哪都会有的。不存在做到让每个人都觉得完美的。）

字节的缺点

这可能是大公司的通病。因为公司的规模非常大，所以即便有着各种管理方式，还是会存在很多低效的事情和很多重复的劳动。我个人的感觉就像是一股缓慢前进的钢铁洪流，很多人就是里面的工具人，甚至是开倒车。虽然上面提到有很多机会。但是机会是哪里都有的，有能力的人在哪里都可以做的很好。而对于大部分人来说就感觉自己做的是无关紧要的破事。会感觉很空虚。

然后因为内部竞争和整个行业乃至整个市场的环境。每个部门都在疯狂招人。招人的门槛无限降低，什么乱七八糟的人都往里招。所以会感觉水平低的和有问题的人特别多。虽然每天也能接触很多大牛，和很多很强很有想法的合作。但也很难避免被一些傻逼折磨。像我这样心态不好的人就很容易受影响。

以上的优点和缺点我尽量说的比较客观，因为不管在哪家公司，不同部门之间都会有很大的差距。如果是部门或者因为个别人的感受特别好或者特别差我就不说了。

我为什么离职

老实说，我做很多事情都没啥特别的理由和特别明确的规划。要不然我应该过得比现在好很多。根本原因是自己不喜欢一成不变，适应了一个环境就想换个环境体验一下。这也是之前从架构转到抖音的根本原因。而且还有着天真的自己做产品的理想以及为了圆一个创业的梦想。

直接原因主要是抖音这边确实是要卷一点。从我之前一个闲的蛋疼的部门到抖音来还是有点不适应。之前是做内部产品，而且作为前端岗位，通常是一个辅助的角色。工作的内容基本上很轻松就能搞定。然后还搞搞自己想做的事情。然后到了抖音做了 server。很多东西需要自己 owner。而且需要和各种角色和团队对接。加上有业务需求 push。研发相比产品人又少。所以比之前忙了太多。但是因为组里又有很多大牛（比如我的 mentor 和我 mentor 的 mentor）。所以组里的氛围又比较卷。所以还是选择先溜了。

关于转岗

字节内部活水的情况非常普遍，因为上面提到的疯狂招人，内部也是各种挖人。因为几乎每个部门都巴不得有人能进去干活。所以想转岗是非常容易的。而且内部转岗要比通过外部招聘进入要更加透明。你可以直接找任何一个组的 leader 和成员聊，而且因为在公司内部，除了保密项目之外，每个组在做什么做的咋样也都能直接看到。

所以如果想换一个环境还是非常容易的，即使是像我这样的前端岗位转到后端岗位也是大有人在。但是这也意味着要放弃一些之前的成果和积累。而且转岗和职级薪资都没有关系。所以不像跳槽可以直接有经济收益。

之后做什么

离职之后很多朋友问这个，其实就像我为什么离职一样，之后做啥也不特别明确。因为我没有买房和定居的计划，在字节搬砖一年收入也还可以，所以也没啥经济压力。就是想体验一下自由职业者的生活。先去旅行一下。然后重拾一下自媒体，然后做一下自己之前一直做但没时间做的产品。然后看一下收入情况，如果能够生活可能就一直这么下去了。如果不够开销就再回去上班。

2020 年终总结

Sat, 02 Jan 2021 02:59:52 GMT

今年真的经历了很多。年初的疫情其实对我的影响并不大。毕业虽然经历了些困难，但是也有惊无险的过去了。年中一直风平浪静。甚至可以每天和好兄弟们悠哉悠哉地去游泳。可到了十月份，好兄弟们一个个都离开了。兄弟们的离开更加坚定了我的离开。国庆和小刘玩完回来就开始找机会了，还借机去了北京一趟。起初先聊了几个部门。除了两个明确要求工作年限的部门之外，其他每个部门的 leader 一听我有意向都是特别希望能过去。本来觉得聊得都挺不错的。尤其是抖音那边一个全栈的部门。认识了一个在那边的一个很强的学妹。本来很想去那边了，但是到最后准备做决定的时候，还是觉得应该找一个专门的后端岗位。于是想到了 robin 那边。找他介绍了一下。确实看起来那边做的事情更吸引我一些。主要还是内部系统做多了，还是想尝试一下 toC 的。这样对之后单干也有利一点。

这一波就到十一月了。但是这个月是我这年最黯淡的一个月。已经住了两年的蛋壳公寓突然暴雷。第三年我也是年付的。这波等于损失了 2w+的房租。弄得心情很烦躁。为了减少一点无谓沟通的精力浪费。和乔老哥一起又租了一套房子。在租了之后人还没住过去的时候，为了先把 Aurora 和 Lambda 接过去，一天晚上约了魁少帮忙。结果停车的时候被一个神经病滋事。结果还弄到派出所折腾了半天。

整个十一月都一直在折腾这些突如其来的破事。就像我在派出所的时候那些民警说的：遇到这样的事情，只能算你倒霉。事情到了十二月初才算到头。最终也是破财消灾。自己也受了不少苦。但是人生真的大起大落。十二月十一日晚，和小刘老师确立了关系。

失去了一些也才更懂得珍惜。今年领悟的最深的一个道理就是「知足常乐」。确实应该珍惜当下。就像我之前一直盼着人生能突然有一个转机。但是也许转机已经来了。只是你还没有发现。

十二月十四号，终于转正满半年。虽然最后又被现在的 leader 恶心了一下。但是最后还是顺利发起了转岗流程。并且也赶在元旦前得到了面试通过的消息。至此，2020 年终于落幕了。

这一年里，对我来说真的是艰难。但是还好有身边的好兄弟们。尤其感谢乔老哥能在我人生至暗的时候帮我一把。感谢这一年来每一个帮助过我的人。21 年，我会更加的珍惜。

最后用今晚这份红酒配拌面来结束这篇文章吧。生活有时就是这么离奇。

JavaScript 的现状

Wed, 02 Oct 2019 04:06:48 GMT

有些事情我必须要吐槽一下了。

JavaScript 此前一直是我比较喜欢的编程语言。类 c 的语法和动态弱类型的特点让他非常容易上手。对于编程的初学者来说非常容易编写。怎么写不容易报错。

并且它是一个真正意义上的完全跨平台语言。因为它是浏览器环境唯一的编程语言。而在其他几乎任何环境都有 JS 的运行环境。还有著名的 Atwood's law：

“Any application that can be written in JavaScript, will eventually be written in JavaScript.” — Jeff Atwood, Author, Entrepreneur, Cofounder of StackOverflow

不知道大家有没有想过为什么是 JS。而不是其他什么语言？~~我这篇文章是黑 JS 的。之后可能会写一篇写 JS 优点的~~

基础问题：为什么要有那么多的编程语言？

不同的编程语言有什么区别？有什么是某个语言做的不到的吗？

理论上来说所有编程语言都是图灵完备的。只要一个语言的运行环境实现了对应功能的接口。那么他就可以做到任何事情。

但是这就够了吗？显然不啊！图灵完备的要求非常低，甚至不需要有条件分支结构。比如被曾被广泛使用的 Fortran。可为什么 Fortran 后来要加入条件分支结构？为什么一直用 Fortran？显然这是个基础功能啊。相对的。随着现代编程语言和软件工程的发展。越来越多的功能为开发者所需要。

比如模式匹配（pattern matching）：

很多现代编程语言都有了的功能。

比如通过模式匹配实现一个阶乘：

factorial 0 = 1
factorial n = n * factorial (n-1)

而 JS 的实现方式：

const fact = N => N > 0
  ? N * fact(N-1)
  : 1

注意到了吗，不能用模式匹配的话必须判断参数来走向不同的逻辑。

再举一个实用场景的例子。我萌可能经常需要根据一个“符号”来走向不同的逻辑。比如我萌做一个 rogue 游戏。根据键盘事件来改变人物的坐标，我萌可能会写出这样的代码：

// 返回一个 tuple，分别表示 X 坐标和 Y 坐标的变化量
const onKeyPress = keycode => {
  if (keycode === 'up') return [0, 1]
  if (keycode === 'down') return [0, -1]
  if (keycode === 'left') return [-1, 0]
  if (keycode === 'right') return [1, 0]
  // ？？这里该干嘛？？
}

而使用模式匹配的话：

onKeyPress "up" = (0, 1)
onKeyPress "down" = (0, -1)
onKeyPress "left" = (-1, 0)
onKeyPress "right" = (1, 0)

非常清晰。并且可以保证函数的返回值。而试图传入不期望的参数？这个函数的签名压根就不存在。函数的参数会包括在函数的签名中。这样不管多少逻辑分支。时间复杂度都是 O(1)。而如果像 JS 代码那样提前返回的方式。每一次都是 O(n)。如果判断就包括复杂的逻辑，那么耗时将会更久。

我萌不妨实现一个上面的函数的反函数：

const genKeyCode = pos => {
  if (pos[0] === 0 && pos[1] === 1) return 'up'
  if (pos[0] === 0 && pos[1] === -1) return 'down'
  if (pos[0] === -1 && pos[1] === 0) return 'left'
  if (pos[0] === 1 && pos[1] === 0) return 'right'
}

使用模式匹配：

genKeyCode (0, 1) = "up"
genKeyCode (0, -1) = "down"
genKeyCode (-1, 0) = "left"
genKeyCode (1, 0) = "right"

很显然，模式匹配是个很好用的功能。所以当然会有人提议给 JS 加入模式匹配的功能 ECMAScript Pattern Matching。但是这个提案从 tc39 成立之初就有。却至今未被加入 JS 中。这是为啥？这个暂且不说。我萌先来看看前人为 JS 做出的贡献。

Lodash

Lodash 是 JS 的一个非常实用的工具库。他从 15 年开始加入了 enum#cond 方法。

使用他我萌可以简化上面的 genKeyCode 方法：

const genKeyCode = _.cond([
  [_.matches([0, 1]), () => 'up'],
  [_.matches([0, -1]), () => 'down'],
  [_.matches([-1, 0]), () => 'left'],
  [_.matches([1, 0]), () => 'right'],
])

可以看到。他的作用很简单。就是通过封装。来简化一些常用的逻辑。虽然他无法改变语言本身的实现。但是可以通过封装成函数这种方式来完成这种程序编写的方式。

这里必须插一句。编程的发展就是从链接到封装再到库。一个程序员的基本素质就是复用现有的实现以及编写可复用的代码。而不断写重复代码就是及其可耻的开倒车行为。

之前在 review 代码的时候有个场景。编写了大量奇怪的代码来实现用 Lodash 很容易实现的功能。这感觉就和写 C++ 却不用 STL 一样。这样的为啥还要写 ES6 再编译成 ES5？你咋不直接写 ES5？很多人就是这样的自相矛盾体。当时看到这个回复我是倒吸一口凉气。

TypeScript

TS 是个很流行的东西。~~很多人对 TS 一知半解就对着 TS 一通狂吹~~

他能流行起来的一个原因可能就是因为 vscode 了。编辑器的原生支持让 TS 具有最好的工具链和生态。让很多人得以有机会尝试 TS 并从 TS 中收益。但是 TS 这个语言还是有很多槽点：

TS 已经具备了函数重载的能力。但为什么只允许声明重载而不允许实现重载？

很多人觉得 TS 只是 JavaScript with type？那为啥不直接用 Flow ？

TS 一点也没改变吗？不。TS 加入了 enum，是一个全新的东西，而并非单纯语法层面上的改动。

TS 其实作为一门全新的语言。他完全可以做的更多，做的更好。他已经有能力引领 JS 的发展。可是在 TS 得势之后。他就变得小心翼翼。可能是生怕走错一步就失去现在的口碑和声誉。

另一个在 TC39 成立之初就有的提案是 Optional Chaining。早在 TS 的初期，就有人提议为 TS 加入该功能。TS 的第 16 个 issue 就是对此功能的建议。可是迟迟没有被加入。而开发者的答复是什么？「害怕和 TC39 的最终定义不一致」。看起来很荒唐。TypeScript 为什么要和 ES 一致？TS 哪里和 ES 相关了？你 TS 的代码能直接被 ES 的解释器处理？你最后还不是要编译成 JS？那你现在和他一不一致又有什么关系？

CoffeeScript 👍

CoffeeScript 就是很棒一个语言。他很自然的对 JS 的易用性做出了改善。加入了很多实用的功能便于它的开发者编写优雅的代码。早在实现之初就实现了 Optional Chaining 的功能：The Existential Operator

使用 CoffeeScript 能写出非常美观、简化的代码。它拥有一大批的受众。为 Atom 编辑器原生支持。在 JS 的发展历程中迈出了重要的一步。对开发者来说他是 ES6 之前的一个很好的跨越。

ECMA-262

JS 近些年似乎看起来比较火热。其实他在很长一段时间里都止步不前。

看看 JS 的历史吧：

Edition	Date published	Name
1	June 1997
2	June 1998
3	December 1999
4	Abandoned
5	December 2009
5.1	June 2011
6	June 2015	ECMAScript 2015 (ES2015)
7	June 2016	ECMAScript 2016 (ES2016)
8	June 2017	ECMAScript 2017 (ES2017)

1997 年发布了第一版。1999 年发布了第三版。到 2009 年才发布第五版：也就是 ES5。而到 2015 年才发布 ES6。在这中间。很长一段时间都是空白。只有广大的开发者不断贡献自己的热情，ES 却没有任何动静。直到 2015 年 ECMA 才想起来 ES。成立 tc39 来发展 ES。

开发者们的热情高涨。很多一直以来的诉求都被撰写为正式的提案，并且为他实现 babel plugin，让开发者可以首先就体验到新特性的益处。但 tc39 却不知道在干什么。很多重要特性或者基础功能迟迟没有得到推进。而却有一些争议提案却即将被正式纳入规范。proposal-class-fields 就是极大的争议。

这也是我写这篇文章的一个契机。9 月 5 号的时候我看到一条推。提到 9 月 8 日将在上海举办一场关于 class fileds 提案的讨论会。这才对这个提案有了细致的了解。同时也意识到其中的弊端。

但让人啼笑皆非的是。TS 却很早就支持了在 class 中申明和定义属性。因为他很符合主流面向对象语言的形式。能写出很像 Java 的类的代码。而现在在 class fields 提案饱受争议的时候，甚至会有人考虑是否应该兼容一下已被广泛使用的 TS。此时的我已经是一头的问号？？？

总结

JavaScript 真辣鸡

References

今天听到一期 podcast 感触良多

Sat, 01 Jun 2019 02:01:43 GMT

今天听到了一期让我感触良多的 Podcast，我和讲述者的一些经历和观念都很相似，可是现在的自己远没有讲述者那么理想。

Google Podcasts - UX Coffee 设计咖 - #70：我有一双隐形的翅膀（周楷雯 · 独立开发者）

今天我们请到的是独立开发者 Kevin 周楷雯，他是独立应用《50 音起源》的作者。接受我们采访的时候，周楷雯刚刚结束度假，回到自己在青岛的海边小屋，悠闲地享受着一个美好的下午。然而就在两三年前，周楷雯的生活正一片灰暗，那时候的他刚刚经历了公司并购，项目关停，好友离职等等一系列的变故。对周楷雯来说，他高考后的这十年时间，可谓是起起伏伏。这一路来的故事，可以一直追溯到他刚刚踏入大学校门的那个夏天。

提醒：这篇文章并没有任何干货

我开始的想法和 kevin 很像：对人生有着自己的规划；同样高考之前不去上课；同样上了大学也不去上课，每天写代码。

大一的时候是我学习效率最高的时候，也是做产品欲望最强烈的时候。那时候看了 12 Startups in 12 Months 以及一些创业公众号。我就特别想做产品。当时主动接触了很多人，谈论，请教，交流了很多想法和产品。

当时做了很多东西：

只花一个礼拜就做完了 toolkit.space （一个包括了数十个在线工具的网站，模仿 atool）；

只花一天就完成了 Village Game （一个模仿 Telegram 上村庄游戏的微信公众号，那是我第一次接触微信公众平台）；

一个早上就用 PHP 加 JQuery 再加 LAMP 一把梭写完并上线了 jsurl （一个短网址程序，现在的 i8e.net 所用的代码）

。

但是完全不知道怎么去宣传，所以很多东西最终也没有其他人用。也因此在制作时都只考虑了自己方便，也没有去更深入的打磨和优化。

关于宣传其实了解了很多。但是了解到的所有方式都觉得成本太高，感觉要花费太多时间精力，而且一分钱也不想花。

而且当时每个产品所涉及的都是对我来说全新的技术。当时才刚刚开始用 Node（中学时一直 PHP 一把梭。

但是从大二开始就怠惰了。

当时暑假和学长商量着做一个产品，后来觉得太扯了就弃了。可能是因为感觉商业化太难，全心投入代价太大，不敢又没有必要破釜沉舟，所以还是想着稳妥一点。因此做东西畏首畏尾考虑一大堆，最后很多想做的都没做。

当时花了太多时间在没意义的事情上面：参加了很多奇怪的比赛。

当时同时搞 CTF，大数据比赛，服务外包比赛，还同时给老师打工。除此之外还在同时干很多不正经的事情。撩学妹，参加社团活动，还得打游戏，期中期末还得学看高数。反正感觉真的是屁事很多，反正是少有时间安心的做自己想做的东西了。

当时可能是被迫花了太多时间干了太多自己感觉没意义的事情（确实也很没意义，比赛没有获奖，技术没有长进，钱也没挣到，成果也没有。

大二下学期其实还可以，参加了 GSOC，参加了 Hackathon，找到了一个还不错的暑期实习，玩了不少游戏。也学了很多想学的东西。还做了一个不少人用的浏览器扩展（但这也是个大坑，没什么回报，还占用了我很多时间去回邮件）

大三开始就非常堕落了。整个上学期身体，心态都不太好。

因为大一大二基本上每天都在实验室。在实验室反正就折腾，虽然效率不高但是从早到晚搞一天也能有点产出。但是后来一个因为不想给老师打工了，还有觉得实验室的研究生太傻逼了，就很少去实验室了，过了几个月到大三感觉算是被驱逐了（座位给了新来的研一的）所以就基本再也没去过实验室（我的显示器和一大堆书还在我桌子上我都不好意思去拿了，到现在也没拿回来）

后来就在寝室疯狂打游戏。室友天天打，自己也克制不住。唯一做了点事也就是考了个驾照（其实考驾照也没花多少时间，只是经常拿学车安慰自己不去努力

可能是当时大一刚来想尝试的东西都尝试的差不多了，简单的全都会了，难的花时间也没进展。当时心态问题很大，有种眼高手低的感觉。以至于就感觉完全折腾不动了。

缺乏积淀

反省一下自己一直以来都比较缺乏积淀。一直不太喜欢写博客，很大一个原因是绝大多数东西都是从网上有的东西学到的，总觉得没必要去重复。而且特别反感很多人的博客都是一些烂大街的东西。自己也很少有什么创新，所以一直以来博客都没什么产出。

经常看到一些前辈的个人 wiki，博客里很多原创文章就很羡慕。比如 felixonmars 的 wiki，对于类似的个人可控的知识的积累非常的喜欢。这里不得不提一个特别崇拜的前辈百合仙子依云，他的博客非常高产，都是原创文章，并且都包含干货和自己思考（其实想一想很多 dalao 的博客里也会有一些个人的想法和生活的记录，可是我一个是不太希望暴露自己的生活在网上，因为太颓了；还有除了技术文章我其实很讨厌看和写大段这种记录个人生活的文字。

花了太多时间完善工作流

一直以来都有对自己产生的数据有极强的控制欲，所有网络服务的数据都希望自己可以掌控结构化的数据，便于迁移，修改，整理和保存。所以花了太多时间去寻找和配置工具。

其实很多人一直用着现有的工具，随着时间也就有了一些产出和积累。（比如很多人可能就有着有道云笔记或者 OneNote 就够了）可是我总想找到一套完美的工具。笔记应用几乎把所有能找到的都试了一圈（包括 LeanNote，SimpleNote 等等很多小众的），RSS 应用也都试过一圈，自动化应用也都试过一圈。结果到最后也没能找到完美的，让自己满意的。很多应用没有接口，没法掌控所有数据，也就没有第三方客户端。现在的笔记应用感觉没有一个能让用户完全掌控数据的，所以到不如本地用 Markdown。（想写一篇文章谈谈对现在笔记产品的看法和感受）

而且因为松鼠症，收藏了太多太多东西，但是没有时间去整理，或是完整阅读。因为什么都想留存下来，RSS 订阅的几十个博客和社区，日常的所有通话记录和短信，手机使用记录，标星的邮件，还有打心的推特全部都会自动化的存到某个笔记应用里。那个笔记应用里可能存了几千条笔记了，但是并没有什么卵用。而且那个笔记应用很封闭。Google Keep 里也存了一大堆东西，本来只想当个 todo list 用，但是后来很多想法，收藏的东西都放里面了，可能也存了几百条，但是也很难迁移出来了。

（感觉想写一篇文章整理一下自己的工作流和工具了）

在尝试这些工具上花了太多时间，最后效率也没有什么提升，而且很多东西分散在了不同的地方。

本来还想谈谈自己的理想，关于出国，还有产品的创意。但是实在是不太想写非技术的文字。这篇就到这里吧，算是难得的对近期的总结

JavaScript 在浏览器环境中的多进程同步

Thu, 02 May 2019 17:24:44 GMT

这标题看起来有点蠢，因为 JS 是单线程的，多进程其实指的是多个 JS 实例。但是多个 JS 实例是可能并行访问相同的数据的，所以还是会碰到需要多进程同步的情况的。

在单一 JS 实例中的纯同步代码确实是不用担心这个问题的。虽然由于事件模型可能会由于用户操作产生并发，但是由于 JS 是单线程的，所有同步操作都可以看做是原子的。比如下面的代码：

var count = 0
button.addEventListener('click', () => {
  count = count + 1
})
for (var i = 0; i < 1000; i += 1)
  button.dispatchEvent(new Event('click'))
// expected count is 1000

在其他多线程程序中这种并发操作共享内存的情况就可能会出现异常的情况。下面用 Golang 举个俗套的栗子：

func test() {
  var a int64 = 0
  var wg sync.WaitGroup
  wg.Add(1000)
  for i := 0; i < 1000; i++ {
    go (func() {
      a = a + 1
      wg.Done()
    })()
  }
  wg.Wait()
  fmt.Println(a)
  // expected output less than 1000
}

异步的情况

可是 JS 也可能会有异步的数据操作，这样的操作就不是原子的了。

var count = 0

var readData = () => new Promise(r => {
  setTimeout(() => r(count), 0)
})

var writeData = data => new Promise(r => {
  setTimeout(() => r(count = data), 0)
})

button.addEventListener('click', async () => {
  const data = await readData()
  await writeData(data + 1)
})
for (var i = 0; i < 1000; i += 1)
  button.dispatchEvent(new Event('click'))
// expected count is 1

但是浏览器环境中 localStorage 操作是同步的，所以不用担心这种情况。可是在使用 indexDB 或者 webSQL 这种的时候就不安全了，其实如果直接用 transaction api 或者用 SQL 操作还可以，但是用 localForage 这种的时候就可能会出现这种问题。

const t = async () => {
  const a = +await localforage.getItem('a')
  await localforage.setItem('a', a + 1)
}

for (let i = 0; i < 1000; i += 1) t()
// expected a = 1

早在很多年前就有文章阐述过这个问题。文章所说的是浏览器中同域名下的多页面同时访问 localStorage 的情况。但是现在 localStorage 是多线程安全的。

主要还是对于指提供了 set 和 get 两种操作的异步数据操作来说比较危险。而扩展中的 storage API 就是这样的，所以就必须进行访问控制了。

延迟操作

可以使用一个变量来标志是否正在进行读写操作，如果正在进行的话就延迟执行。

let processing = false
const t = async () => {
  if (processing) return setTimeout(t, 0)
  processing = true
  const a = +await localforage.getItem('a')
  await localforage.setItem('a', a + 1)
  processing = false
}
for (let i = 0; i < 1000; i += 1) t()

轮询阻塞

但是上面的方法就无法通过 await 进行流程控制了，不知道实际会在什么时候执行，所以最好可以阻塞到操作结束。下面的方式可以实现这样的效果。

let processing = false
const wait = () => new Promise(r => {
  const _wait = () => {
    setTimeout(() => {
      if (processing) _wait()
      else r()
    }, 0);
  }
  _wait()
})

const t = async () => {
  await wait()
  processing = true
  const a = +await localforage.getItem('a')
  await localforage.setItem('a', a + 1)
  processing = false
}
for (let i = 0; i < 1000; i += 1) await t()

使用 Promise

还有一种方式是 Promise，通过每次创建一个 Promise，在处理结束后将 Promise resolve，在创建时就等待当前的 Promise resolve。这样可以避免使用 setTimeout 造成的递归的代码。

let processing = Promise.resolve()
const start = () => {
  let end
  const start = new Promise(r => { end = r })
  const wait = processing.then(() => end) // 阻塞到当前执行完毕后将结束方法返回
  processing = processing.then(() => start) // 设置当前状态为进行中
  return wait
}
const t = async () => {
  const end = await start()
  const a = +await localforage.getItem('a')
  await localforage.setItem('a', a + 1)
  end()
}
for (let i = 0; i < 1000; i += 1) await t()

这些控制方式都依赖于 JS runtime 本身的调度方式。只适用于单进程的并发情况。

多进程同步

一个方法是通过进程间通讯将操作交由一个线程进行

const init = async () => {
  const c = new BroadcastChannel('tabs')
  const cbs = {}
  // 通过这种方式来实现可以响应的信息交互
  c.addEventListener('message', ({data: {id, msg}}) => {
    if (cbs[id]) {
      cbs[id](msg)
      delete cbs[id]
    }
    if (msg === 'init' && isMain) {
      c.postMessage({id, msg: 'hasMain'})
    }
  })

  // 实现发送消息的函数
  c.sendMessage = msg => new Promise(r => {
    const id = Math.random()
    c.postMessage({id, msg})
    setTimeout(() => r('timeout'), 1000)
    cbs[id] = r
  })

  const result = await c.sendMessage('init')
  c.isMain = result === 'timeout'
  return c
}

这种方式在浏览器扩展环境还是比较实用的，在浏览器环境中可以有一个一直运行的 background 进程，可以把页面中的交互操作发送给 background 进行执行。但是为了暴露相同的 API 同样需要一个初始化的过程，来判断当前环境是否是 background，如果是 background 直接执行，不是 background 则发送消息。

Web Locks API

这个是个比较新的 API，用法很简单，参考提案即可，但是目前并未在所有平台实现，兼容性可以参考 MDN。

const sleep = ms => new Promise(r => setTimeout(r, ms))
navigator.locks.request('test', async () => {
  console.time()
  await sleep(1000)
})
navigator.locks.request('test', async () => {
  await sleep(1000)
  console.timeEnd()
})
// expect output default: 2000ms

SharedArrayBuffer 和 Atomics

通过 SharedArrayBuffer 和 Atomics 实现锁操作可以参考 js-lock-and-condition 通过 haredWorker 共享 SharedArrayBuffer 大概是这么个流程

const initLock = async () => {
  const worker = new SharedWorker('worker.js')
  const buffer = await new Promise(resolve => {
    work.onmessage = buf => r(buf)
    setTimeout(() => {
      const buf = new SharedArrayBuffer(100)
      work.postMessage(buf)
      resolve(buf)
    }, 100)
  })
  return new Int32Array(buffer)
}

// worker.js
let locks
onconnect = e => {
  const [port] = e.ports
  if (locks) port.postMessage(locks)
  else port.onmessage = ({data}) => { locks = data }
}

通过 SharedArrayBuffer 和 Atomics 实现的共享内存，再在其之上实现的锁操作。这个就很麻烦了。要先通过 SharedWorker 共享 SABs，然后才能借此进行同步。并且 SABs API 之前还曾被禁用过，因此倒不如使用 localStorage API 实现：


const lock = (key, fn) => new Promise(resolve => {
  const K = key + '_LOCK'
  const _tryLock = () => {
    setTimeout(async () => {
      if (localStorage[K]) _tryLock()
      else {
        localStorage[K] = 1
        await fn()
        delete localStorage[K]
        resolve()
      }
    }, 50)
  }
  _tryLock()
})

const sleep = ms => new Promise(r => setTimeout(r, ms))

lock('t', async () => {
  console.time()
  await sleep(1000)
})
lock('t', async () => {
  await sleep(1000)
  console.timeEnd()
})
// expect output default: 2000ms

参考

关于离线优先应用的多端同步的思考和总结

Sun, 06 Jan 2019 06:51:02 GMT

因为做了一个扩展，很多用户反馈希望能加入多端同步数据的功能。所以前段时间研究了一下对于离线优先应用的多端同步的方式。上来先看来一些现有的应用的同步实现方式以及一些现有的解决方案。然后最终选择了一个比较简易的方案。

现有的一些应用的实现方式

印象笔记的同步方式可以参考官方的文档。以一个笔记为最小粒度，基本思路是通过一个标识 USN 来表示笔记的版本。每一次更新都使得 USN 加一。如果更新前的 USN 和远程的 USN 不同的话说明发生了冲突。而印象笔记处理冲突的方式是创建一个新的笔记，同时保留远程的和本地的版本。然后由用户来选择是否删除其中一个。如果不发生冲突的话可以上传对一个笔记的修改。

Chromium 对于用户数据的同步方式一直是我很好奇的。尤其是对于书签这种又包含多个属性和类型，又可以多层级，又有序的这种复杂的数据类型。像是历史记录这种不可变的，时序的数据同步起来非常简单，只要完全增量就可以了。而书签这种就比较复杂。Chromium 的文档中有对于同步服务的大体框架。这篇文章中提到对于 Chromium 来说希望开发者可以尽量避免涉及同步服务的细节。而通过一个统一的框架来进行同步服务的开发。

这个图大体描述了一个同步的流程：上传变更，下载变更并进行合并，之后将变更应用于本地数据。对于每种数据来说，需要实现一个 processor 用于应用更改；一个 merger 用于合并更改就可以了。具体如何合并和应用更改还是可以客户端决定的。而服务器还是会保留所有客户端上传的更改。

对于书签来说，比如本地进行了对一个书签的改名操作，然后下载变更后有另一个对这个书签的改名操作。这时遇到冲突的情况，Chromium 就可能会创建一个新的书签。导致书签的重复。而 Chromium 除此之外也会储存书签的很多其他的元数据。比如创建时间，修改时间和最后访问时间。对于最后访问时间。如果发生的冲突。那么直接保留一个值最大的修改操作就可以了。然而对于书签来说还有很多种不同的操作，比如重排序，移动到其他文件夹等。都可能有不同的策略。对于书签的同步的具体实现可以看 ./components/sync_bookmarks 这个目录的代码。

然后除了同步的流程之外，还需要有很多逻辑来控制何时下载，何时上传等状态，这个文件编写了各种操作变更同步状态的逻辑。所以对于 Chromium 来说同步服务异常的复杂。除此之外还有 UI 层和数据层直接的同步。毕竟 UI 不能每一次操作都完整读写整个储存。所以可以 UI 和数据层共用相同的 processor 这种方式，UI 和数据层直接也只需要传送修改操作就行了。

并且也有很多策略来验证一致性，简化传输的数据等。chrome://sync-internals/ 可以查看 Chromium 所有同步所储存的数据，状态，发送的消息等信息。

一些现有的解决方案

shareDB

这个是为了一个 Node.js 多端同步应用开发框架 derbyjs 实现的一个同步数据库。基于 WebSocket 在多终端之间同步。Demo 中的效果还是很好的。但是这个库并不是离线优先，在离线时的操作都会被丢弃。

但是这个库有一定的参考价值，它的数据保存和传送使用了对于 JSON 的 Operational Transformation (OT)。并且作者自己实现了一套 OT 的标准和库：ottypes。主要作用是通过约定好的格式来简化传输时的数据大小。并且可以对多个操作进行撤销，交换顺序等。

PouchDB | CouchDB

根据官网的介绍写着来自 Apache CouchDB。后来发现这个 PouchDB 其实就是 CouchDB 接口的一个 JS 的实现。所以就直接研究这个 CouchDB 了。

这个 CouchDB 其实还是挺有意思的。官网首页就号称大数据和稳定性：

Seamless multi-master sync, that scales from Big Data to Mobile, with an Intuitive HTTP/JSON API and designed for Reliability.

看了一下文档发现是 erlang 实现的。主要同步原理是通过储存所有变动，保留所有冲突。所以才有了号称的稳定性。然后每次查询都可以看到所有冲突的版本。然后可以将所有版本展现给用户，由用户来决定保留哪个版本。

这样确实做到了离线优先和多端同步。但是过于重量级了。使用他需要额外的数据库实例，并且只是把冲突问题交给了用户来解决，和 evernote 的方式差不多了。而且客户端也需要保留很多冗余的数据。之后可以写一篇关于 CouchDB 的文章来专门介绍一下。之后的应用如果有需要也可以采用这个。但是这个项目还是想轻量一点。所以也就没有采用 PouchDB。

总结

很重要的一点就是最小数据粒度。对于最小粒度的数据，只需要一个记录了最后更新时间的时间戳就可以确定正确的状态了。如果远程的数据更新了，在客户端没有获取到远程更新的状态时如果客户端对该数据进行了更改，那么上传时远程只要直接更新到该客户端修改后的状态即可。因为客户端的修改也是来自用户。如果只有用户可以触发修改那么该状态也是经由用户确认的正确的状态。

最终的采用的方案

现在的方案是以一个列表为最小粒度。以最后修改时间为标识。保留最后修改时间最大的修改。当获取完整数据时先获取每个列表的 ID 和最后修改时间。如果最后修改时间大于本地的修改时间则下载完整列表数据进行替换。并且每次进行更新时，确保最后修改时间小于当前时间且大于上一个版本的时间。

参考

Offline Storage for Progressive Web Apps

Vue transition-group 组件实现类似 Google Keep 的延迟动画

Thu, 25 Oct 2018 21:18:44 GMT

最近在重构某项目，前端想模仿 Google Keep 来做。非常喜欢点搜索框之后卡片滑动进入的动画效果。

昨天研究了一晚才搞定。因为这次实在是没找到相关的文章，所以在这记录一下。

关于 transition 和 transition-group 组件的基本用法可以参考官方文档，写了很多特殊情况的用法。但是没有这种延迟的动画效果。

首先写一下动画各个阶段的样式。

.slide-enter-active {
  transition: all ease-out .22s; // 进入时为 0.22s 的滑入动画
}
.slide-leave-active  {
  transition: all 0; // 离开时直接消失
}
.slide-enter-to {
  opacity: 1;
}
.slide-enter {
  transform: translateY(100px);
  opacity: 0.3;
}

何时应用哪个类在文档中写的非常清晰。尤其是这个图一看就非常明了。

然后是模板部分。这里用两个单独的元素来举例子。省略了不重要的部分。

<transition-group
  tag="v-layout"
  name="slide"
  @after-leave="afterLeave"
>
  <v-flex key="date" v-if="card > 0">
    ...
  </v-flex>
  <v-flex key="color" v-if="card > 1">
    ...
  </v-flex>
</transition-group>

如果用v-for的话就是下面这样。

<div v-for="i in 10" key="i" v-if="card > i - 1"></div>

然后重点就在这里啦。其实就是通过延时来增加计数器。使得元素一个一个渲染啦。

export default {
  data() {
    return {
      card: 0,
    }
  },
  activated() {
    this.slideCard()
  },
  deactivated() {
    this.card = 0
  },
  methods: {
    slideCard() {
      if (this.card === 2) return
      this.toBeHide = this.card += 1
      setTimeout(this.slideCard, 200)
    },
  },
}

然后这样就可以保证组件激活的时候出现延迟进入的动画效果啦。如果组件没有keep-alive的话直接在created里调用slideCard就行了。

虽然这样就足够实现我萌想要的效果了。但是可以稍微引申一点点。我们想要重置动画的话，比如等所以卡片隐藏之后再重新来一遍。如果想知道卡片全部移除的话需要用一个计数器。因为事件里只有一个after-leave，并没有全部移除的事件。所以需要在after-leave事件里修改计数器来达到这个效果。

export default {
  data() {
    return {
      card: 0,
      toBeHide: 0,
    }
  },
  activated() {
    this.loadListColors()
    if (this.card === 0) this.slideCard()
    else this.card = 0
  },
  methods: {
    slideCard() {
      if (this.card === 2) return
      this.toBeHide = this.card += 1
      setTimeout(this.slideCard, 200)
    },
    afterLeave() {
      this.toBeHide -= 1
      if (this.toBeHide === 0) {
        this.slideCard()
      }
    },
  },
}

这就是最终的效果啦。

碎碎念：

我一个后端开发怎么搞 vue 来了呢 (⊙o⊙)? 这个项目的同步服务正在进行一个复杂的重构，等完全弄好了整理一下发个文章吧。

为什么 Google Keep 说改版就改版了。底色变的全白了好刺眼啊，还有各种难看的圆角。还是原来的好。

参考

https://cn.vuejs.org/v2/api/#transition-group https://codepen.io/dizzyluo/pen/yJLwWm