1G 的话实际也推不上去（得用 LFS （然后问题就很复杂了））
不考虑这个问题的话，其他人可以通过记录第一次推送时的 commit hash 来强行获取旧的文件（在 github gc 之前都能存在）

@asanelder 打包之后被压缩了啊，然后就需要边解压边读取，zip 压缩也不是固定输出大小的压缩，解压的时候也很难预测要读多少内容才能得到 1024 ，通常的思路就是读固定大小，然后解出多少就提供多少（

你把 framework 从设备里提取出来反编译一下试试？

类似的问题多了去了
https://github.com/cblp/yaml-sucks

(这一系列函数中，只有 memmove 是保证重叠的时候正确的）

什么时候改文件内容会修改文件夹修改时间了？？
Linux 下能更新怕不是因为包管理器更新时先 unlink 了原文件再创建回去造成的。。

不如一步到位直接起个数据库（划掉）
如果可以序列化成数据库的话，同一台机器上可以使用 SQLite3 ，启用 WAL 模式后读写互不干扰，可以同时进行，性能大概比每次序列化强，但是单独访问的话就不一定比 OrderedDict 快（
但是最主要的是不用自己解决复杂的线程同步问题了，而这个可是经常处理出错误的（

@1sm23 也不是不可以在安卓子系统上弄）
我记得是全局生效的

协程就是一种代码的组织结构，你当然可以全部使用手写状态机来做，事实上早期开发大部分都是这个模型。。。
作为一种结构，它可以大幅度简化某些场景的代码复杂度，这就是它最初的意义。
即使传统磁盘 IO 没办法使用 poll 的模型（因为总是 ready ），为了代码上的统一，做成线程池支撑，上层逻辑用协程描述也无可厚非（虽然现在新的 io 模型已经支持提交大量磁盘请求然后等一起完成了）
至于性能方面的提升，那有也只是副作用，即降低了编码复杂度导致可以从更高抽象角度优化业务逻辑，而不是拘泥于底层状态机的实现细节。
这里和同步 /异步，阻塞 /非阻塞其实关系不大，即使是一个纯算法，也可以使用协程来描述，generator 的模式和协程其实就差不多同构（可以互相转换），与其在需要数据时耦合上获取数据的代码，不如做一个 generator 将数据获取的过程抽象出来，generator 可以让你使用传统控制流结构来描述逻辑，同时内部状态就直接用 generator 中的局部变量表示。

Swift: ?

(先看看是不是真的要特权才能跑。。。
执行前设置一个 __COMPAT_LAYER=RunAsInvoker 环境变量试试功能会不会异常

@yangyaofei 考虑下内网有没有别的服务（
比如数据库

还有就是即使啥权限没有，也能挖矿

@feather12315 win 阵营也抄了个 Io Rings （
https://docs.microsoft.com/en-us/windows/win32/api/ioringapi/

考虑到还有原生对象，精确的复制大概是不现实的（
加上还可以 proxy

Windows 容器可以 hyperv 也可以用进程隔离，但是后者只在 server 版提供（
反正两种都不支持运行图形应用

原因是被编译（ ES6->ES5 ）成
var _this = this
... map(function (question) {
eval('this.xxx' + xxx)
});
这样了。。。
显而易见编译不可能处理 eval 里面的东西（

api 30 明明是倒退
无需任何权限就可以在标准目录里创建文件夹，然后也能读取文件列表，那么只需要把跟踪信息编码到文件名里就好了

(我就记得 chrome 的菜单按钮可以支持这个操作的
启动器不支持我觉得是故意的，因为这和拖动重新排序的手势冲突了，而后者是出现了很久的，不可能说改就改