绝大部分的基础数据结构都是定长的，很容易针对优化它们的内存管理。但字符串是一个例外。内存管理和其它资源管理有明显的不同。管理内存有点像切蛋糕，从整块蛋糕上切下需要的那块，但归还的时候却因为支离破碎难以合并起来满足后续用途。举个极端的例子：如果内存堆有 2G 大小，如果碰巧在正中间分配了几个字节而从未释放，这个堆就被永久的分成了两个不足 1G 的分片。之后再无可能从这个 2G 大小的堆中分配出 1G 的内存块。改进内存分配算法或许可以减轻内存碎片的危害，但即使是在此方面做了相当多努力的 jemalloc ，其表现也大大低于一般用户的预期。以我的经验，一个 16G 的内存堆，对于长期运行，需要大量反复分配释放内存的程序，通常能做到 10G 左右的峰值有效内存占用就不错了。这里说的有效内存使用，指你调用 malloc 传入的字节数之和。根据应用程序使用内存的方式不同，这个数字会有很大的不同。60% 的内存使用率其实已经很好了，但还是会有很多人问，我的内存都去哪了？尽可能的规范数据结构的大小，并针对它特别管理内存，提高内存使用有效率的方法之一。这相当于分层管理资源，而不是不问青红皂白全部放在一个全局堆中。等长的数据结构在回收之后可以直接再利用，这可以消除大部分的外部内存碎片。btw, 定长的数据结构对持久化也更友好。这篇 blog 想探讨的字符串类型， 指的是一串不变的、连续的、用以表达某 ...继续阅读 (86)

最近半个月，因为广州防疫政策，我一直居家办公。找了点时间，给 skynet 做了一年一度的 release 。这次的 1.6.0 版，相比去年的 1.5.0 版，没有太大的变化。主要是平时积累的一些 bugfix 。它所依赖的第三方库，例如 Lua , jemalloc 我都更新到了最新的版本。值得一提的是，mongo 的 driver 也更新了。因为 mongo 在最新的版本中已经淘汰了旧的 wire protocol ，如果再不更新，就无法连接新版 mongo server 了。具体讨论可以参看PR #1649。因为 mongo 自己的设计原因，我们无法给出一个同时兼容新老版本协议的方案。从这点来看，我个人认为 redis 的底层协议设计就稳定的多。 这么多年更迭基本不需要修改。这些年，我一直在追踪 Lua 的更迭。我认为 Lua 的源代码是最值得一读的开源代码。作者的编码风格相当严谨，几乎每处细节都严格准循标准，而不仅仅只保证在现有环境下正确。这份严谨也并非从一开始就固有的，是这二十多年来逐步形成的。我的硬盘上留有几乎所有 Lua 发行版的源代码，经常对比阅读。自从 Lua 在 github 上镜像了开发仓库后，我就习惯阅读它的每一个 commit ，经常能学到一些东西。比如最近的这个：把 stack 的扩展从 free / copy / alloc 改成了 realloc ...继续阅读 (502)

这几年我一直被干眼症和结膜炎困扰。疫情之前，每次洗澡后就双眼通红。但似乎并无其他影响，也没怎么在意。后来慢慢的，眼睛就容易发干，经常疲劳。严重的时候眼睛几乎睁不开。最受影响是在开车的时候，因为无法休息眼睛，特别难受。到晚上环境光线不足的时候，感觉远处看不清楚。然后，视力突然断崖式下降。三年时间，每年体检，从 1.2 直落 0.7 左右。而我在 35 岁之前一直是双眼 1.5 的视力。本来 2020 年就想约眼科医生看看的，因为疫情去看五官科不方便就一直拖着，直到 2021 年底才去看了医生。初步诊断结果是结膜炎、干眼症、视疲劳。另外，验光结果表明我有 150 度近视加 50 度散光。因为并不影响日常生活，便没有配眼镜。而且，我的视力是时好时坏。从办公室眺望珠江对面的楼顶招牌时，有时那些字清晰可见，有时则是重影。我感觉如果以后能解决干眼症和结膜炎的话，视力能稳定一些。在医院开的眼药水用完后，我便自己在网上网购一些进口的眼药水。尝试了好几种，最后觉得德国产的海露（Hylo Gel）最舒服，几乎不刺激眼睛；只要隔两个小时滴一次，便可以缓解视疲劳。所以就在家中和办公室各常备一瓶。不过，结膜炎似乎今年更严重了。现在每天早上起来眼镜都充满血丝。而且视线略模糊。需要滴过眼药水，休息大约半小时才能恢复正常。前两个月又尝试了日本参天的一种据说消除红血丝的眼药水（金色包装的 Sante FX V+）。 ...继续阅读 (79)

周末在家里折腾 BT 下载，发现 UPnP 无法工作，便去光猫那里看看是什么情况。我发现现在电信宽带默认已经是由光猫来拨号，家中的路由器是作为一个二级路由在使用，如果想让 UPnP 或 DMZ 工作起来，需要在光猫里设置。查看光猫设备上印的默认管理员密码登录上去，没有找到太多设置选项。在网上搜了一下，需要一个超级管理员身份才能看到全部设置菜单。一般的说法是打电话问一下装宽带的师傅，但天色已晚，不想麻烦人。转念一想，有这么多家宽带设备要管理，电信应该用的是统一密码，或是有一些简单手段可以拿到这个密码才对。否则建立一整套管理系统成本实在太高了。按 google 搜索结果，打开 192.168.1.1/cgi-bin/baseinfoSet.cgi 后，果然密码就写在这个 json 文件中。虽然不是明文，但和明文也差不多了。密码条目中写的数字就是 ascii 的变形。因为普通密码是已知的，很容易就能看出规则：偏小的数字就是 ascii 码，偏大的数字是 ascii 偏移 4 。用一行 lua 代码就能转换为密码的原文。拿到超级管理员密码进入管理界面后，便可以打开 DMZ 等端口映射功能。但是我发现现在电信已经不再给 ipv4 的公网地址了，即使做了端口映射也没啥用。按网上的说法，可以打电话给电信要求一个公网 IP ，一般都会爽快的给。但一是时间已晚，人工客户不在线；另外按最新的说法，最近 ...继续阅读 (95)

我们游戏引擎的 IO 模块其实一直在修改。最初的版本到现在有四年多了。一直没有定稿的一部分原因是因为我们给引擎设定了一个比较高的需求：引擎本身也是可以从网络自更新的。而更新引擎本身必然依赖 IO ，包括 IO 模块自身。而我们引擎又基于一个多线程版本的 Lua 框架ltask，ltask 本身也是需要依赖 IO 模块启动的。这些后续的设计要晚于最初 IO 模块的设计，反复重构也就是必然了。一开始我们为 IO 单独分配了一个线程，它负责和文件服务器通讯以及文件的读写。后来因为整合 ltask ，又花了许多功夫把它从独立线程变为 ltask 的一个服务。但这个服务又有点特殊：因为它还需要负责 ltask 自身的加载。所以它前生是一个 native os thread ，中途再转换为 ltask 的独占服务。最近，我反思整个模块的演化历程或许被引入了不必要的复杂度。重新考虑把所有的 IO 请求都放到一个单独的线程/服务 中是否是过度设计、似乎应该做一些退让，维护很少几个全局状态，似乎能简化很多的设计工作。这里需要解决的另一个难题是一些第三方库需要注册一个 IO 回调接口，再需要读写文件时调用框架提供的接口加载文件。这些第三方模块都是把文件操作看作是同步调用，而我们已经实现的 IO 模块本质上提供的是异步接口。如果一个模块本身是 Lua 实现的，那么同步接口和异步接口的差异很小；但如果回调 ...继续阅读 (77)

我们在制作一款类似 Factorio 以自动化为主题的游戏。在游戏开发中遇到了不少算法上的问题，解决过程都非常有趣。比如之前就写过一篇流体系统。和 Factorio 体验的最大不同在于，我们不使用传送带做主要物流手段，而是依靠公路网和货车。这种形式并不新，我在 20 多年前的凯撒3 （以及同系列的法老王、宙斯、龙之崛起等）中就玩到过。采用这种物流方式的游戏一直不曾间断，这几年我玩过放逐之城、缺氧、环世界、海狸浮生记也是这种。这类游戏的共性是需要靠城市资源供养一批工人，然后这些工人干活来供养城市，其中一个重要的工作就是物流。一般受资源产能影响，不会养太多工人，不然很难产生正循环。所以物流所占工作比例并不大。大部分工人的工作（在生产建筑中）从事生产。我们的游戏可能更贴近 Factorio 一些，不需要工人运作机器，物流更纯粹。供养货车的成本也不高，鼓励玩家尽可能多的增加货车，提高物流效率。和前面提到的系列游戏不同，我们的道路资源是有限的。车辆在道路上必须遵守交通规则，如果车辆太多会发生拥堵。所以限制物流效率的是道路而不是资源。我想给玩家的体验是：物流的运作会遵循一定的规则，玩家可以大概感知到规则的存在，并通过不同的布局和调整提高整体的效率。玩起来不如传送带规则那么明确，也不会像一个黑箱那样，无法精细控制。一开始我想设计成偏向铁路运输的逻辑，玩家自己规划路线，货车都严格跑在路线上，只接收 ...继续阅读 (81)

ltask是一个功能类似 skynet 的库。我主要将它用于客户端环境。由于比 skynet 后设计，所以我在它上面实验了许多新想法。最近碰到一个需求：我们的游戏引擎中嵌入的第三方 C/C++ 模块以 callback 形式提供了若干接口。在把这些模块嵌入 ltask 的服务中运行时，这些 callback 函数是难以使用全部 ltask 的特性。比如，我们的 IO 操作全部在一个独立服务中，引擎读取文件时，很可能是通过网络异步远程加载数据的。这些第三方模块通常没有考虑异步 IO 操作，都是以同步 IO 方式给出一个读文件的 callback 函数让使用者填写。那么，怎样才能在这个 C callback 中挂起当前任务，等待 IO 的异步完成呢？初看是不可能做到的。框架没有设计成支持异步机制，我们难以从 C 函数中 yield ，挂起当前任务。这样，同一个服务就不可能在 callback 结束前相应外部消息，也就无法利用 ltask 的调度器完成异步 IO 工作。Lua 虚拟机也并没有（也无必要）设计成多线程安全的，我们不能把这个 C 模块及其 Lua binding 的运行环境放在一个独立线程环境中。所以，callback 中阻塞调用 IO 请求，就意味着整个服务的阻塞。一个比较简单的解决方法是给 IO 服务额外开通一个 channel ，不走 ltask 内部的消息。在 C c ...继续阅读 (84)

我们正在制作的游戏中，交通和物流是基于公路网的。公路网其实是以路口为顶点，路为边构成的（无向）图。因为我们有大量的车辆行驶在这个路网中，所以，我需要一个空间高效的方法储存这些车辆的路径。在大部分情况下，我们的车辆都选择唯一的最短路径，也就是说如果从 A 路口到 B 路口存在一条制定好的路径的话，所有的车都会走这条路。基于这一点，我们可以对多条路径合并储存。我选择用当前路口 id 和目的地路口 id 做 key ，把下一站路口 id 作为 value ，保存在一张 hash 表中。这样，先用 dijkstra 算法求出起点到终点的最短路线后，再把每一段路线用该结构保存下来即可。当车辆到达某个路口，只需要用当前路口和它自己的目的地就可以索引到应该往哪个方向开。这个结构很适合保存在 Lua table 中，用元表触发尚未计算过的路径。而且这样一个路径表只是一个 cache ，随时可以清理重建。如果路网已经稳定，那么还可以选择一个内存更紧凑的结构保存它们。对于每个路口，连接的路是有限的。在我们的游戏中，其实只有十字路口（ 4 叉）和 T 字路口（ 3 叉）两种。我们可以对路口连接的路编号为 1-4 。我们用 4 个数组就能储存下所有的路径信息。驶向同一编号出口的路径可以储存在一起。比如，如果从 42 号路口去向 100 号路口的车需要在 42 号路口的第 2 出口驶出，我们就把 (42,1 ...继续阅读 (92)

今天同事给我转了一个帖子，说的是 golang 在处理大量并发 json / protobuffer unmarshaling 事务时，可能产生大量的 (10GB) 临时内存，无法及时回收的问题。我的观点是：如果一个系统的某个模块有可能使用 10G 这个量级的内存，那么它必然是一个核心问题需要专门对待。核心问题应该有核心问题的考量方法，这不是 GC 之错，也并非手动管理内存一条解决之道。即使手工管理内存，也无非是把内存块之管理转嫁到一个你平常不太想关心的“堆”这个数据结构上，期待有人实现了一个通用方案尽可能的帮你解决好。如果随意使用，一样有类似内存碎片无法合并之类的问题，吃掉你额外的内存。如果它存在于你的核心模块，你一样需要谨慎考量。在这个具体问题上，我认为还是应该先简化数据结构，让核心数据结构变得易管理。显然、固定大小的数据结构是最容易被管理的。因为如果你的数据结构大小固定，就不再需要堆管理，而是一个固定数组滚动处理临时数据。json 这样的弹性数据结构看起来不太好用固定大小的数据结构去描述，但稍微想点办法也不难做到。C 在这方面的库不少，我就不一一列举。核心想法一般是：用一个固定数据结构去引用编码数据中的切片。解码后的结构只保留元素的类型以及在原始数据中的位置。如果你能大致知道需要解码的数据元素的数量级，那么就可以用一个固定大小的结构去承载解码结果，不需要任何动态的内存分配。只 ...继续阅读 (82)

去年设计luaecs时遗留了一个问题：如何引用特定 entity。一开始，我认为可以灵活使用 tag 系统来解决大部分问题；或者用户自己构建一个 64bit ID 的 component ，采用二分查找的方法来引用特定 Entity 。今年初，我发现我们的自己的使用者和外部使用者都无法避免引用特定 Entity ，所以增加了一个非侵入式的引用方案。最近又围绕它做了一些讨论，让我重新考虑内置一个 Entity 引用的方案。原本关联同一个 Entity 的不同 Components 使用了一个 32bits id ，在过去的代码中我称之为 entity id ，这可能造成了一些误解。它虽然是一直递增的，但 32bit ID 在长期运行的系统上无法避免回绕问题，也就是新的 entity 可能会复用已被删除的 id 。我用一个叫 rearrange 的机制来解决这个问题，当 id 超过 31bit 范围后，在update 环节会重新排列系统中所有的 id ，让它们重新变得足够的小。如果这个 id 并不暴露给上层使用，那么怎么变化它们都无所谓。但如果把 id 暴露出去充当 entity 的引用就会有问题。一个简单的解决方案是换成 64bit ID ，这样就不会再有回绕问题了。但是，每个 component 都会增加 32bit 的 payload ，查找它们的效率也会随之下降。我认为是不值当 ...继续阅读 (79)

我们的游戏引擎的 GameUI 使用的RmlUI。我的想法是用成熟的 CSS 来描述 UI 的呈现，借鉴 web 前端开发的方法来制作游戏的 UI 。但我不想嵌入太复杂的 Web 渲染引擎，而且游戏的需求也会有所不同，所以我选择了轻量的 RmlUI 。同时，为了和游戏的开发语言一致，我们使用 Lua 而不是 javascript 来控制 CSS 。在使用 RmlUI 的过程中，一开始我们尽量和上游保持一致，修复了不少 Bug ，并合并到了上游。后来发现我们有很多需求和上游不同，需要大刀阔斧的做一些改动，所以就 fork 了一个自己的分支。最重要的两个改动是：第一，完全实现了 Lua Binding ，因为原有的实现非常低效和复杂，很多接口设计不合理。做大规模的接口变化必须破坏向前兼容，这是我们 fork 分支的主要动机。第二，废弃了 RmlUI 自己实现的排版模块，换成了 Facebook 维护的Yoga。迁移到自己的分支上后，我们陆续对 RmlUI 的代码进行了不少重构。最近，发现了 RmlUI 原有的一个 Bug ，有时修改了一个 css 节点属性后，会影响另一个不相干的节点的属性。仔细研究后，判断这是它固有的设计失误造成的。我们知道，css 非常灵活，每个节点的属性都可以被很多数据源影响。如果我们不做任何优化，推导一个节点上的属性会是一个相当昂贵的操作。所以，必须对其做一些缓 ...继续阅读 (74)

我们引擎中使用的数学库已经修修补补很久了。期间积累了很多想法。最近在对引擎做性能优化，把一些找到的热点系统用 C/C++ 改写，顺便就重构了一下数学库，让它更好的兼顾 Lua API 和 C API 。上一次对数学库的改进是三年前的事情了。这三年的使用，我们发现，基于一个栈的 DSL 虽然可以减轻 Lua 和 C 之间的通讯成本，但是使用起来并不方便。大部分时候，我们还是倾向更传统的接口：一次数学运算调用一次函数。而高复杂度的数学运算完全可以放在独立的 C 模块中完成。结合 ECS 系统，我们可以在 C side 集中批量处理相同但数量巨大的数学运算。我们在很早以前就放弃了原来设计的 DSL ，只使用数学库的部分功能。趁这次重构，我打算把这些已经废弃的部分彻底删掉，并重新设计底层的数据结构，让它能更好的适应其核心特性。我认为我们的数学库最核心的特性是：所有的数学对象，包括矩阵、向量、四元数都是不可改写的值对象，有一致的外观。我将它表达为 64bit 的 id ，这样方便 Lua (或别的语言）binding 。做 Lua binding 时，数学对象 id 是一个 lightuserdata 而非传统库用的重量级的 userdata 。这样用起来的代价和普通的数字相比，并无明显的额外负担。即使不在 Lua 中使用，直接由 C/C++ 运用时，一个 64bit 的 id 也好过更大 ...继续阅读 (85)

我们的游戏场景是由若干场景节点构成的，每个场景节点是一个 Entity 的 Component 。而一个复杂的场景可以在编辑器中生成一个预制件 Prefab，像搭建乐高积木那样堆砌已经做好的部件。关于预制件的设计，之前有过两篇 blog 讨论。分别是：游戏引擎中预制件的设计和预制件和对象集的管理。就目前的使用经验来看，几乎所有游戏中的 Entity 都是从 Prefab 实例化得来的。一个 Prefab 会实例化出 n 个 Entity ，但这 n 个 Entity 的生命期管理却很麻烦。最自然的想法是：所有的 Entity 都必须是场景树上的节点（拥有场景组件），当我们删除一个场景节点时，它所有的子孙都一起移除。这个做法有两个问题：如果一个 Entity 被间接移除（祖先被删除），持有它的引用该如何处理？传统的方法是，只能对 Entity 保持弱引用。一般用 Entity ID 作弱引用。我们在对 Entity ID 解引用时，应检查引用是否有效。有些 Entity 未必是场景节点，但也需要合理的自动化生命期管理怎么办？传统的方法要么让所有的东西都必须是场景节点，要么把这个东西变成场景某个节点的一个组件附着在场景节点上。我不喜欢上面提到的传统解决方案。因为：生命期管理和场景管理其实是两件事。场景管理是按树结构组织的，而生命期管理更适合用集合这种结构。所有需要被管理的东西不应该都必 ...继续阅读 (70)

前段时间我们给引擎增加了对象分组的功能。做这个特性的动机是当整个游戏世界中的对象数量远超同时需要处理（显示）的对象数量时，有一个快速筛选出待处理代码集合的机制。在使用过程中，我陆续发现了这个特性的其它用途。过去的某个游戏项目中，曾经遇到这么一个需求：游戏中需要为玩家生成一个头像，这个头像是由很多部分构成的。有玩家的肖像、名字、等级、修饰用的图标等等。这个头像可能同时在屏幕的很多位置显示。如果场景是一个简单的树结构，那么，每个出现头像的地方，都是一个构成头像元素的子树。这样，场景中就可能出现完全一样的多份子树。固然我们可以用一个通用接口构造这个子树出来，但是，一旦这个玩家的属性发生变化，就需要针对所有场景中出现的同类子树进行修改。这需要为每个玩家额外维护一个列表，引用所有头像在场景树中出现的位置。这无疑增加了数据结构的复杂性。一个自然的想法是，场景不再是一颗树，而是一个有向无环图。玩家头像在场景中可以出现在多处，但子树只有一份。这颗子树的根节点可以有多个父亲。这样，需要修改时，我们只需要改动一处。在 Ejoy2D 中，我实现了这个机制。但总觉得有些别扭，因为底层的数据结构还是变得复杂了。目前我们正在用新引擎开发游戏，遇到了同样的问题。我们在做一个类似异星工厂的游戏，里面有许多小细节。在许多场景元素（工厂、机械爪、运输无人机等等）中会挂接一些小元件。玩家可以看到这些小东西在游戏中的流动 ...继续阅读 (77)

目前，我们用 ECS 管理游戏引擎中的对象。当游戏场景大到一定程度，就需要有一个机制来快速筛选出需要渲染的对象子集。换句话说，如果你创建了 100K 个 Entity ，但是只有 1K 个 Entity 需要同时渲染，虽然遍历所有可渲染对象的成本最小是 O(n) ，但这个 n 是 100K 这个数量级，还是 1K 这个数量级，区别还是很大的。我们的 ECS 系统已经支持了 tag 这个特性，可以利用 visible tag 做主 key 快速筛选可见对象。但当镜头移动时，需要重置这些 tag 又可能有性能问题。重置这些 visible tags 怎样才能避免在 100K 这个数量级的 O(n) 复杂度下工作？一个容易想到的方案是给 Entity 分组。比如在超大规模的场景下，我们可以按区块来分组。根据镜头所在的位置，可以快速的确定哪些 group 是关心的，哪些不必关心。我首先想到的是用多个 world 来描述整个场景。每个 world 是一个 group ，按地理位置存放 Entity 。但这有明显的问题：渲染的有些环节是唯一的，比如 PreZ 阶段生成 Z Buffer 、后处理阶段处理屏幕空间的效果，这些需要多个分组一起处理。所以，我还是倾向于给 Entity 加一个 group id 来区分它们。如果把 ECS 看成是一个内存数据库，那么，我们的需求是 where 字句的查 ...继续阅读 (72)

前段时间有同学抱怨说 skynet 下提供的 lua 模块都没有名字空间，平坦的命名，容易和自己项目开发的模块命名冲突。虽然自己项目开发的模块可以单独给一个名字空间，但混杂在一起使用还是不美观。我考虑了几天，决定在 skynet 1.1 版本中把大部分的模块都加上 skynet 前缀。调整的模块有：cluster : skynet.clustercrypt : skynet.cryptdatacenter : skynet.datacenterdns : skynet.dnsmemory : skynet.memorymongo :skynet.db.mongoredis : skynet.db.redismysql : skynet.db.mysqlmulticast : skynet.multicastnetpack : skynet.netpackprofile : skynet.profilesharedata : skynet.sharedatasharemap : skynet.sharemapstm : skynet.stmsnax : skynet.snaxsocket : skynet.socketsocketchannel : skynet.socketchannelsocketdriver : skynet.socketdriver因为一些模块引用的外部库，所 ...继续阅读 (73)

问题的起因是 skynet 上的一个issue，大概是说 socket 线程陷入了无限循环，有个 fd 不断的产生新的消息，由于这条消息既不是 EPOLLIN 也不是 EPOLLOUT ，导致了 socket 线程不断地调用epoll_wait占满了 cpu 。我在自己的机器上暂时无法重现问题，从分析上看，这个制造问题的 fd 是 0 ，也就是 stdin ，猜想和重定向有关系。skynet 当初并没有处理 EPOLLERR 的情况（在 kqueue 中似乎没有对应的东西），这个我今天的 patch 补上了，不过应该并不能彻底解决问题。我做了个简单的测试，如果强行 close fd 0 ，而在 close 前不把 fd 0 从 epoll 中移除，的确会造成一个不再存在的 fd (0) 不断地制造 EPOLLIN 消息（和 issue 中提到的不同，不是 EPOLLERR）。而且我也再也没有机会修复它。因为 fd 0 被关闭，所以无法在出现这种情况后从 epoll 移除，也无法读它（内核中的那个文件对象），消息也就不能停止。我对 epoll 了解的不多，google 了一下，搜到一篇有趣的 blog ，对这个问题有了更多的了解：Epoll is fundamentally broken他认为，epoll 的设计失误在于，接口设计上混淆了 "file descriptor" 和 "f ...继续阅读 (65)

最近同事碰到的一个需求：需要频繁把一组数据在 skynet 中跨网络传递，而这组数据实际变化并不频繁，所以做了大量重复的序列化和传输工作。更具体一点说，他在 skynet 中设计了一个网关节点，这个网关服务可以负责把一条消息广播给一组客户端，每个客户端由内部的一个 uuid 串识别，而每条消息都附带有客户端 uuid 列表。而实际上这些 uuid 列表组有大量的重复。每条广播消息都重复打包了列表组，且列表组有大量重复信息。一开始我想的方法是专门针对这个需求设计一组协议，给发送过的数据组编上 id ，然后在发送方和接收方都根据 id 压缩通讯数据。即，第一次发送时，发送全量信息，之后再根据数据变化发送差异；如果完全没有变化，则只需要发送 id 。之后我想，能不能设计一种较为通用的差异同步方法，可以在跨节点传递数据组的时候，避免将相同的数据重复传输，而采用差异同步的方法同步对象。晚饭后，我试着实现了一个这样一个简单的模块。https://github.com/cloudwu/syncobj我们可以先在通讯的两端建立对等的通道，构造数据的一端用 syncobj.source() 创建一个发送通道；而同步数据的另一端用 syncobj.clone() 创建一个接收通道。当我们在发送端需要构造一组数据的时候，利用 obj = source:new() 创建出一个依附在这个通道上的对象 obj ...继续阅读 (84)

前几天我们正在运营的一款产品发生了崩溃，我花了两天尝试用 gdb 分析了 coredump ，虽然最后还是没能找到 bug ，但还是觉得应该做一些总结。产品是基于 skynet 开发的，由于历史原因，它基于的是 skynet 1.0 之前 2015 年中的一个版本，由于这两年一直没出过什么问题，所以维护人员懈怠而没有更新。崩溃的时候，关于 Lua 部分的代码缺少调试符号信息，这加大了分析难度。现在的 skynet 在编译 lua 时，加入了 -g 选项，这应该可以帮助未来出现类似问题时更好的定位问题。导致代码崩溃的直接原因是 rip 指向了一个数据段的地址，准确的说，跳转到了当前工作线程拥有的 lua 虚拟机的主线程 L 那里。发现这条线索很容易，skynet 的其它部分是有调试符号的，可以在崩溃的调用栈上看到，服务的 callback 函数的 ud 和崩溃地址一致，而 lua 服务的 ud 正是 L 。用 gdb 的 p (lua_State*)地址 查看这个结构，也能观察到这个数据结构的内容正是一个lua_State。由于用 bt 查看的调用栈是不正常的，所以可以断定在函数调用链的过程中应该是发生了某种错误改写了 C 栈的内容。在这种情况下，gdb 多半靠猜测来重建调用链（就是用 bt 看到的那些）。现代编译器经过优化代码之后， C 栈上已经没有 stack frame 的基地 ...继续阅读 (74)

昨天和人闲扯，谈到了 MMORPG 客户端的网络消息应该基于怎样的模型。依稀记得很早写过我的观点，但是 blog 上却找不到。那么今天补上这么一篇吧。我认为，MMO 类游戏，服务器扮演的角色是虚拟的世界，一切的状态变化都是在游戏服务器仲裁和演化的。而客户端的角色本质上是一个状态呈现器，把玩家视角看到的虚拟世界的状态，通过网络消息呈现出来。所以、在设计客户端的网络消息分发框架时，应围绕这个职责来设计。客户端发起的请求分两种：一种是通知服务器，我扮演的角色状态发生了改变，请求服务器仲裁；另一种是，我期望获取服务器对象的最新状态。后一种有时以服务器主动推送来解决，也可以用主动请求，两者主要的区别在于流量控制。其实、对于客户端作为状态呈现这个角色而言，请求和回应之间的关系并没有什么紧密联系，并不适合使用基于 RPC 的网络模型。这个无关乎 RPC 的实现是用 callback 还是用 coroutine 。这是因为，当服务器的状态改变时，客户端关心的应该是这类事情发生时，我应该如何呈现；而不是具体到某个请求发出后，收到回应我应该怎么处理。RPC 把请求和回应紧密耦合在一起，让回应的处理流程强依赖请求时的上下文，这样容易引起不必要的状态管理。比如，我看到我们公司的一个项目中曾经出过这样的 bug ：UI 界面上点击一个按钮，用 callback 的形式发起了一次 RPC 调用；在回应的 ca ...继续阅读 (322)

我们公司有两个项目的客户端在使用 git 做项目管理，三个项目使用 svn 管理。程序员比较爱 git ，但是为什么 svn 还存在？主要是在做客户端开发时，策划和美术人员始终迈不那道坎。即使已经在用 git 的项目，策划们还是反应用起来比 svn 跟容易犯错误，遇到自己无法解决的问题也更多。我是非常想在公司全部推广使用 git 做项目管理的。所以需要仔细考察到底是什么东西阻止了策划（及美术）们掌握这个工具。思考一番后，我认为一套完整的培训机制还是得建立起来。完全靠自学和口口相传是不靠谱的。尤其是在有 svn 基础的时候，非程序开发人员接受 git 其实比程序开发人员要困难的多。如果你硬要把 svn 的概念全部适配到 git 上，其实就是在把 git 当 svn 在用，不仅获得不了好处，反而增加了很多困扰。而实用主义者，在没有外力的情况下，只会看到表面。不可能系统的从原理上系统理解 git 到底解决了什么问题、每步操作背后到底做了什么，如果出现了问题，问题是怎么引起的。我们知道，在用 git 的时候，由于分支和提交都比 svn 方便，分布式的结构也会更容易导致版本演化图变得异常复杂。当它乱成一团乱麻的时候，任何新的合并操作都会比之前遇到更多麻烦。如果使用者心里有清晰的概念，时刻保持演化关系简单，他遇到的问题自然会少。而你遇到问题乱解决一通，只满足于把现在的问题搞定，那么下次就会面临 ...继续阅读 (79)

我们公司的一个 MMORPG 项目最近在内存方面碰到了红线，昨天开会讨论了一下。我提出了一个改进方案，写篇 blog 记录一下。问题是这样的。在当下的手机及平板硬件设备条件下，操作系统留给应用的可用内存并不多，大约只有 500M 左右。和 PC 环境不同，手机上是交换分区的机制来对应一些临时突发性内存需求的。而手机必须保证一些系统服务（某些高优先级后台业务）的运行，所以在接电话、收取推送等等意外任务发生时，有可能多占用一些内存，导致操作系统杀掉前台任务让出资源。根据实际测试，游戏想跑在当前主流高端手机上必须把自己的内存占用峰值控制在 400M 内存以下，350 M 会是一个合理的值，而这个值是远远低于 10 年前的 PC 游戏标准的。而我们的项目却是一个写实类型的 拥有大场景的 MMORPG 。Unity3D 是在智能手机普及以前设计的，远没有料到会被广泛用于手机游戏的制作。它在设计之初并没有为低内存环境考虑。内存使用太粗犷，是在使用 Unity 开发 MMORPG 项目时最被吐槽的一点。为手机游戏定制游戏引擎，最特别的，和 PC 游戏不同的两点就是内存必须严格控制、能耗必须严格控制。比如在我们开发的 ejoy2d 中，会为资源数据中的项目引用定制短指针，即资源内部的相互引用使用 32bit 偏移量来代替 64bit 指针，每个指针节省出 4 字节内存；变换矩阵使用 6 个 32b ...继续阅读 (77)

skynet 在最初的设计里，希望做一个分布式系统，抹平 actor 放在本机和处于网络两端的差别。所以，设计了 master/slave 模式。利用 4 个字节表示 actor 的地址，其高 8 位是节点编号，低 24 位是进程（节点）内的 id 。这样，在同一个系统中，不管处于哪个进程下，每个 actor （在 skynet 中被成为服务）都有唯一的地址。在投递消息时，无需关心目的地是在同一个进程内，还是通过网络来投递消息。随后，我发现试图抹平网络和本地差异的想法不那么靠谱。想把一个分布式系统做得（和单一进程同样）可靠，无论如何都简单不了。而 skynet 的核心希望可以保持简单稳定。所以我打算把分布式的支持放在稍上一点的层次实现。先来说说同一进程下的服务通讯和跨网络的通讯到底有什么不同。进程内的内存是共享的，skynet 是用 lua 沙盒来隔离服务状态，但是可以通过 C 库来绕过沙盒直接沟通。如果一个服务生产了大量数据，想传给您一个服务消费，在同一进程下，是不必经过序列化过程，而只需要通过消息传递内存地址指针即可。这个优化存在 O(1) 和 O(n) 的性能差别，不可以无视。同一进程内的服务从底层角度来说，是同生共死的。Lua 的沙盒可以确保业务错误能够被正确捕获，而非常规代码不可控的错误，比如断电、网络中断，不会破坏掉系统的一部分而另一部分正常工作。所以，如果两个 act ...继续阅读 (69)

skynet 1.0 于 2016 年 8 月 1 日正式发布，到今天已经有 7 个多月了。这段时间积累了很多小修改，我想是时候发布 1.1 版了。很高兴这段时间 skynet 社区继续壮大，有更多的公司选择基于 skynet 开发。现打算在下个月已目前 github 仓库 master 分支为基础发布 1.1 正式版，这两周如果同学们还有什么问题请尽快提 issue 。下面是从 1.0 开始积累的更新：debug console : 可用户指定绑定 ip 。debug console : 增加 call 指令向服务发送消息。debug console : 反馈 inject code 的错误信息。debug console : 修改命令确认信息，方便自动化处理。sharedata : 增加 flush 。sharedata : 增加 deepcopy 。cluster : 增加 send 。cluster : 支持绕过配置文件直接传递配置表。skynet : 增加 state 指令查询服务的 cpu 开销。skynet : wakeup 保证次序。httpc : 支持 timeout 。mongo driver : sort 支持多个 key 。bson : 对 string 类型做 utf8 编码检查。daemon 模式 : 可正确输出错误信息。sproto : 支持定点数。 ...继续阅读 (97)

又一篇谈 Lua debugger 的 blog 了。但这次，并不是我的个人作品 :) 。去年底我写了如何优雅的实现一个 lua 调试器。正如我的 blog 中所写：“不过期待它短期内发展成为一个图形式的漂亮交互调试器可能有点不现实，除非做前端的朋友有兴趣来完善它。”ok 。这次，真的有人来完善它了。我公司的前端大神突然对实现一个 lua debugger 产生了兴趣。他觉得既然 chrome 可以用来调试 javascript ，那么魔改一下后，调试 lua 也完全没有问题。利用几个月的业余时间，他完成了这么个东西：http://mare.ejoy.com/ps. 不愧是做前端出身啊，开源项目的主页比 skynet 好看多了。 ...继续阅读 (80)

sproto是我设计的一个类 google protocol buffers 的东西。在很多年前，我在我经手的一些项目中使用 google protocol buffers 。用了好几年，经历了几个项目后，我感觉到它其实是为静态编译型语言设计的协议，其实并没有脱离语言的普适性。在动态语言中，大家都不太愿意使用它（json 更为流行）。一个很大的原因是，protobuffers 是基于代码生成工作的，如果你不使用代码生成，那么它自身的 bootstrap 就非常难实现。因为它的协议本身是用自身描述的，如果你要解析协议，必须先有解析自己的能力。这是个先有鸡还是先有蛋的矛盾。过去很多动态语言的 binding 都逃不掉引入负责的 C++ 库再加上一部分动态代码生成。我对这点很不爽，后来重头实现了pbc这个库。虽然它还有一些问题，并且我不再想维护它，这个库加上 lua 的 binding 依然是 lua 中使用 protobuffer 的首选。protobuffer 自身有很长的历史，历史带来了包袱，实际上在我放弃 protobuffer 后不久，google 也大刀阔斧的更新了 3.0 版，对之前 2.x 版做了很多必要的，不兼容的改进。我仿照 protobuffer 的基本理念设计了 sproto ，设计上的考虑在之前的 blog 中已经写了很多。sproto 的设计理念之一：保证基 ...继续阅读 (91)

今天试了一下一个想法：绕过 lua 提供的 C API 直接去访问 lua 的表结构，提供在性能及其重要的环境高效访问数据结构的方法。例如：我们需要在 lua 和 C 中共享一个 vector 3 结构，有两种实现方法：一、把 C struct 实现为 lua 中的 userdata ，然后给 userdata 加上 metatable 以供 lua 中访问内部数据；二、在 lua 中使用一个 table 实现这个 vector3 结构，类似 { x = 0.0 , y = 0.0, z = 0.0 } 这样；然后在 C 里通过 c api (lua_rawget/lua_gettable/lua_getfield) 来访问里面的数据。前一种方法会导致在 Lua 中访问成本加大、而后一种方法增加的是 C 中访问数据的成本。如果我们只在少数性能敏感的地方通过 C 去操作数据结构，那么第二种方法看起来更简单灵活一些。这样，不需要 C 介入的地方，是没有额外开销的。毕竟、通过 metamethod 索引 userdata 的成本比直接索引一个普通的 table 要重的多。但是、第二种方法会导致 C 访问数据的成本较大。我们采用 C 代码去处理 vector 数据结构，一定是考虑到性能热点，在语言边界上损失性能感觉不太划算。我觉得或许可以采取一个技巧来加快它。对于标准的 Lua 实现，构造 ...继续阅读 (90)

今天同事在公司群里调侃问 Windows 能管理多少个盘。当超过 24 个盘的时候，盘符似乎是以 24 进制的方式增加的，也就是 Z: 后面是 CC: 到 CZ: 然后是 DC: 到 DZ: 。当有 600 个盘以后，或许应该用 CCC: 了吧？这也提醒我们，用正则表达式匹配 Windows 下的文件路径时，不可默认盘符只有一个字符。为什么 Windows 会有盘符这个诡异的东西呢？按如非必要、勿增实体的原则，只用路径就够了呀。物理分区完全可以隐藏在文件系统之后，在 Unix 系的操作系统中，分区是用挂接点的方式挂接在虚拟文件系统中的。如果是为了方便记忆和保持用户习惯，完全可以把分区顺着挂接到 /c /d /e /f 下。如果你在 windows 下安装 mingw/msys 它就是这样处理 C 盘、D 盘 …… 的。答案要从历史中找。Windows 的前身是 微软的 Dos 系统。我见过的最古老的 MS Dos 是在我同学家的一台旧 IBM PC/XT 上。10M 的硬盘、只有 256K 内存，配置的系统是 PC(MS) Dos 2.0 。知道这个 2.0 版的 Dos 比它的前身最大的改进是什么吗？它比 MS DOS 1.0 多支持了硬盘，以及层级目录结构。同时期的主流电脑是 Apple ][ ，它的原生操作系统（Apple Dos）是不支持硬盘的，软盘上只有一个根目录。MS ...继续阅读 (72)

这两个月，我的主要工作是跟进公司内一个 MMORPG 项目，做一些代码审查提出改进意见的工作。在数月前，项目经理反应程序不太稳定，经常出一些错误，虽然马上就可以改好，但是随着开发工作推进，不断有新的 bug 产生。我在浏览了客户端的代码后，希望修改一下客户端的 UI 框架以及消息分发机制等，期望可以减少以后的 bug 出生概率。由于开发工作不可能停下来重构，所以这相当于给飞行中的飞机换引擎，做起来需要非常小心，逐步迭代。工作做了不少，其中一个小东西我觉得值得拿出来写写。我希望 UI 部分可以严格遵守 MVC 模式来实现。其实道理都明白，但实际操作的时候，大部分人又会把这块东西实现得不伦不类。撇开各种条条框框，纸上谈兵的各种模式，例如 MVC MVP MVVM 这些玩意，我认为核心问题不在于 M 和 V 大家分不清楚，而是 M 和 V 产生联系的时候，到底应该怎么办。联系它们的是 C 还是 P 或是 VM 都只为解决一个问题：把 M 和 V 解耦。我们的底层使用的是 Unity3D 及它的 UGUI ，UGUI 提供了 UI 需要的显示控件对象，我们开发的业务逻辑则是围绕这些对象开发的。由于在移动设备上内存有限，项目又做了一系列的对象管理工作，UI 控件并不一定常驻内存，会根据需要加载或删除。又由于这是一个网络游戏，UI 操作和反馈经常需要和服务器打交道，又许多异步操作。故而有一段时 ...继续阅读 (88)

昨天在 review 我公司一个正在开发的项目客户端代码时，发现了一些坏味道。客户端框架创建了一个简单的对象系统，用来组织客户端用到的对象。这些对象通常是有层级关系的，顶层对象放在一个全局集里，方便遍历。通常，每帧需要更新这些对象，处理事件等等。顶层每个对象下，还拥有一些不同类别的子对象，最终成为一个森林结构，森林里每个根对象都是一颗树。对象间有时有一些引用关系，比如，一个对象可以跟随另一个对象移动，这个跟随就不是拥有关系。这种设计方法或模式，是非常常见的。但是在实现手法上，我闻到了一丝坏味道。由于类别很多，所以代码中充斥着模仿静态语言如 C++/C# 般的大量构造和析构函数。我一直对同事说Lua 不是 C++大部分同事也认同我的观点，但落到实处，却逃不出过去的很多经验。比如在这次具体问题上，为什么要实现一套带构造和析构函数的类别系统呢？核心驱动力是因为大部分逻辑对象是和场景关联在一起的，并且引用了 U3D Engine 中的 C# 对象，依赖 lua 的 gc 系统去回收资源延迟太大。而往往大部分时候，我们都可以明确的知道一个对象从场景中移除，几乎没有别的地方在引用它，所以需要立刻释放资源。而临时对象很多，设计人员又想实现一套对象的 table 再利用的方案，让释放掉的对象在可能的情况下，能重新在新创建对象时再利用起来，减少 lua gc 的负担。为了做到这点，代码框架模仿了 C ...继续阅读 (234)