分类： 程序设计

从我开始研究ECS算起, 到现在已经将近20天了。

第一版ECS库终于实现完成了。先不论性能如何，基本功能都实现了。

在我的理解中，ECS中最复杂的地方是EC部分的管理和查询。而S部分的复杂度主要是依赖关系的问题，这会取决于具体的项目。

因此，在这个ECS库中主要解决EC的问题，关于S的部分并没有提供。这也是我称它为库而不是框架的原因。

在整个实现过程中，由于我还没能完全克服性能强迫症，导致我的心路历程非常坎坷（每次实现到一半，总会因为这样或那样的原因，让我推倒重来）。

最开始，我认为守望先锋的ECS之所以那么复杂，是因为他们使用了C++这种强类型语言。为了解决动态组合（动态添加和删除C）的问题，不得不在API上做出一些让步。

如果拿Lua来实现，语言本身就支持动态组合，那添加/删除Component的行为，可以退化为添加/删除“标签”功能。

每个System只需要过滤出含有特定“标签”组的Entity, 然后加以处理就行了。

很快我放弃了这一想法，主要原因是我认为作为一个合格的框架或库，它应该提供一些限制。可以让我们写出符合ECS原则，更易读的代码。

在上面的设计中，客户程序员很容易就违反了ECS原则，他完全可以只过滤某一个ComponentA, 然后去修改这个Entity中的ComponentB, 甚至删掉ComponentB但是并不会删除ComponentB的标签。这会导致一些很奇怪的Bug。而且从代码的易读性上来讲也没有好处。

在后续的设计中，我又陆续纠结了，Eid的分配问题， Component的存储问题，同一个Entity中的Component的关联问题。

在经过陆陆续续几次推倒重来之后，直到今天才实现完第一个版本。

在这不断的推倒重来中，我总是在是否“需要暴露Eid给客户程序”之间摇摆不定。最终，我认为是需要的。

我们总是需要在程序的某处去New出一个个的Entity。同样我们也总会需要在程序的某处，去修改某个特定Entity的某个Component数据。

在我看来，整个ECS的运行机制很像一个巨大的“粉碎机”。 我们总是在某一个入口投入足量的Entity, 然后ECS库或框架将这些Entity粉碎成各种Component，供System查询并操作。

因此在这一版的ECS库的实现中，我把Component作为主角来实现的。Entity的作用在这里，将一组Component进行关联，以方便Component查询和生命周期的管理。

先简单介绍一下API：

--创建一个名为Admin的world对象。使用相同名字多次调用ECS.fetch_world, 返回的是同一个world对象
local world = ECS.fetch_world("Admin")

--注册Component类型。 其中world.register的第二个参数是为了方便建立Component缓存池和Debug阶段检查一些Component的合法性（暂时还没有实现）。
world:register("vector2", {x = 0, y = 0})
world:register("vector3", {x = 0, y = 0, z = 0})

--创建一个Entity, 这个Entity只含有一个"vector2"的Component
local eid = world:new { vector2 = {x = 2, y = 2}}

--向eid所代表的Entity上添加一个"vector3"的Component
world:add(eid, "vector3", {x = 3, y = 3, z = 3})

--向eid所代表的Entity上删除一个"vector3"的Component
world:remove(eid, "vector3")

--查询world中的所有类型为"vector2"的Component
for v2 in world:match("all", "vector2") do
    w:touch(v2) --将Component v2置为脏标记
end

--查询world中所有被w:touch过的类型为"vector2"的Component
for v2 in world:match("dirty", "vector2") do
end

--查询world中所有已经死亡的类型为"vector2"的Component
for v2 in world:match("dead", "vector2") do

end

--删除Entity
world:del(eid)

--执行清理操作，每调一次为一个逻辑帧
world:update()

整个设计大概是这样的：

每个Component类型都有一个数字id称为tid。每个Component实例都有一个数字id称为cid。我们总是可以根据tid和cid来找到某一个具体的Component实例。

在相同的Component类型中，新创建的Component的cid总是比旧的Component的cid要大。在world:update时所有Component的cid会进行重排，但是依然满足这一约束。这会提供一个便利，在我们使用for遍历world:match时，依然可以不受限制的添加任何Compoent实例。

当某个Component实例被删除时，仅将其挂在“dead”链表上，并不做其他操作。如果已经在“dead”链表上，则不做任何处理。这会产生一个限制，刚对某个Entity删除了一个Component之后,不可以立马添加一个同类型的Component。

当某个Component实例被touch时，仅将其挂在“dirty”链表上。

当某个Entity被删除时，将此Entity下的所有Component标记为"dead", 然后将Entity挂在"dead"链表，不做任何处理。

在执行world:update时会产生以下行为：

1. 释放所有的Entity及其eid（以备后面复用)
2. 释放所有标记为“dead"的Component, 并整理存活的Component的cid
3. 清除"dead"链表
4. 清除"dirty"链表

总的来讲，所有的添加都是立即生效，所有的释放都会延迟到world:update中执行。

ps. 在这次纠结的过程中，在一定程度上治愈了我的性能强迫症。

大约在1个月前，游戏终于上线了，在这一个月以来，服务器竟然crash了5+次，还有几次严重Bug.

除了觉得测试力度不够之外，我也在想到底有那些环节是我能做而没做好的。

仔细思考下来，出Bug的原因大概有两种典型情况。

写代码时，逻辑思维不严谨，并且函数之间耦合性过强，导致随便一个很平常的改动，都会产生新的Bug, 甚至是crash. 比如我经常写出类似下面这种函数之间耦合性过强代码。

struct foo {
    bool isfinish;
    time_t rsttime;
    //...
};
static viod try_reset(struct foo *f) {
    if (f->rsttime < time(NULL)) {
        //reset foo fields
    }
}
static int bar(struct foo *f) {
    if (f->isfinish)
        return -1;
    try_reset(f);
    //....do more things
}

这上面这个代码里，bar和try_reset耦合性实在是太强了，强到甚至我调换一下try_reset的调用顺序，都会导致整个逻辑出错。这次出的Bug中有好几个都是这种原因，原始逻辑是1年前写的，上线前调整了一下，结果没测到，然后就出问题了。

我仔细回忆了一下，这种强耦合的实现方式，是我最近两年才开始出现的情况。

之所以会出现这种情况，一方面是因为代码估算做多了之后，我对一条两条指令的开销同样很敏感，以至于很多时候把控不住优化的尺度，把设计弄糟。另一方面，我一直坚持设计正确，不需额外检查这一原则。对于上面的代码，本来设计try_reset就是需要调用方保证，一定在foo.finish为false时才调用，所以try_reset没有理由去检查foo.finish字段。

事实上，这并不是我第一次发现这个问题，以前也发生过几次这种问题。每次发生之后，总是自嘲一句“过早的优化是万恶之源”，然后改正了事。

但是连续几次的Bug, 让我头脑清醒了很多，我觉得我有必要重新审视一下这个问题，这应该不仅仅是过早优化的问题。

这段代码相关的需求大概是这样：如果foo在开始之后，需要完成若干操作，如果在开始之后的规定时间段内没有完成，则重置完成进度，重新完成。

为了“削峰填谷”，我并没有为每一个foo设置一个定时器（即使是固定时间轮），只是在每次获取foo结构时，尝试重置foo的进度。

经过重新审视了整个需求发现，其实“try_reset"的前置条件有两个：一个是没有完成，一个是过期时间。

但是在实现过程中， 把条件1放在了调用方，条件2放在了被调用方（也就是try_reset)。这样try_reset执行结果是否正确，竟然需要调用方来保证。以致于所有调用try_reset的函数，都会与try_reset有强耦合。这其实很像是“契约式编程”，但是除非有语言层面支持，不然只是靠人脑来保证契约前置条件是不靠谱的，所以我个人其实也不是很相信“契约式编程”。

将try_reset函数更改如下，其实可以避免很多Bug, 尤其是多年之后需要修改更时如此：

static viod try_reset(struct foo *f) {
    if (f->isfinish == false && f->rsttime < time(NULL)) {
        //reset foo fields
    }
}

那么上面问题的答案来了，是“过早优化么”？不是。“设计正确不需要检查”这个原则正确么，我依然认为是正确的。因为这种类型的Bug，其根本原因是没有设计好。

根据历史的设计经验，我一般都会有意识的将class/module设计为自成闭环。但是在一个class/module内部函数级实现时，几乎没有仔细思考抽象过，都是实现调用方函数的过程中做的，顺手提取出一个子函数供调用方调用，因此大部分情况下，内部函数和调用方之间都有很强的耦合性。当一个模块过大时，这种耦合性会呈几何倍数增加。

现在回过头来看，其实每一个函数在提取时，都值得仔细抽象来和调用方解偶，即使现在它只有一个调用方。据我过去的经验，你最开始抽象出来的函数，往往会随着业务逻辑的衍变，产生多个调用方。

上面的问题，大部分情况下只是会产生逻辑bug, 一般不太会诱发crash.

据最近几次crash的经验来看，主要原因就是在对于个unordered_map在for循环时，删除了其中的一些元素。比如下面代码：

struct st {
    int id;
    int progress;
    //other fields
};
std::unordered_map<int, struct st> DB;

bool bar(struct st &x)
{
    ++x.progress;
    if (x.progress >= MAX_PROCESS) {
        database_delete_by_id(x.id);
        DB.erase(x.id);
        return false;
    }
    //process x
    return true;
}

void foo(std::vector<int> &l)
{
    l.reserve(DB.size())
    for (auto &iter:DB) {
        auto &x = iter.second;
        if (bar(x)) {
            l.emplace_back(x.f1);
        }
    }
}

这种Bug最为讨厌，只要bar函数删除一个元素，就会导致整个迭代器失效，并且不是必崩的。所以这种Bug即使在测试足够的情况下，也很容易逃逸到线上。一般我都会将代码改成如下：

struct st {
    int id;
    int progress;
    //other fields
};
std::unordered_map<int, struct st> DB;

static std::unordered_map<int, struct st>::iterator
check(std::unordered_map<int, struct st>::iterator iter, bool &clear)
{
    auto &x = iter->second;
    if (x.progress >= MAX_PROCESS) {
        database_delete_by_id(x.id);
        clear = true;
        return DB.erase(iter);
    } 
    clear = false;
    return ++iter;
}

static std::unordered_map<int, struct st>::iterator
bar(std::unordered_map<int, struct st>::iterator iter, bool &clear)
{
    bool clear;
    auto &x = iter->second;
    ++x.progress;
    iter = check(iter, clear);
    if (clear == false) {
        //process x
    }
    return iter;
}

void foo(std::vector<int> &l)
{
    bool clear;
    l.reserve(DB.size())
    for (auto iter = DB.begin(); iter != DB.end(); ) {
        bar(iter, clear);
        if (clear == false) {
            l.emplace_back(x.f1);
        }
    }
}

事实上，我个人很不喜欢这种改动，一股bad taste扑面而来。我也很不喜欢unordered_map的这个限制，他会让for循环方和被调用方强耦合在一起。

for循环方必须保证被调用方不会删除unordered_map中的元素才可以调用。即使是第二种写法，也有一种浓浓的耦合味道。

最近重新审视这种代码时，我发现也许我们可以使用“变换式编程（《程序员修炼之道(第二版)》P149)来解决这种问题。

struct st {
    int id;
    int progress;
    //other fields
};

std::unordered_map<int, struct st> DB;

static std::unordered_map<int, struct st>::iterator
check(std::unordered_map<int, struct st>::iterator iter)
{
    auto &x = iter->second;
    if (x.progress >= MAX_PROCESS) {
        database_delete_by_id(x.id);
        return DB.erase(iter);
    } else {
        return ++iter;
    }
}

static void
batch_check()
{
    auto iter = DB.begin();
    while (iter != DB.end()) {
        iter = check(iter);
    }
}

static void
batch_process()
{
    for (auto &iter:DB)
        ++iter->second.progress;
}

void foo(std::vector<int> &l)
{
    bool clear;
    l.reserve(DB.size())
    batch_process();
    batch_check();
    for (auto &iter:DB) {
        l.emplace_back(iter.second.f1);
    }
}

当然这样的改动会增加一点点性能开销，但是我认为这点开销不会成为热点的致因。

在研究上述问题的同时，我也在想，除了良好的抽象之外，我还能为代码的可靠性做些什么。

是的，答案只有一个，为代码写测试代码。

我查了很多关于单元测试理论性的书籍，他们都告诉我，单元测试就是要把被测试的类通过mock类隔离掉，转而只测试这一个类。

但是游戏服务器的业务太复杂了，以至于会有少量循环引用的情况。这样我实现的mock类到最后，除了可以设置假数据之外，几乎和真实的类的功能一模一样了。

而且我看到书上的很多例子，为了可测试性，会对被测试类的接口加以修改。这种侵入式的测试，我很难适应。

而且游戏服务器还有三大不可控因素: 时间,配表,数据库。

时间 – 在业务逻辑中，有大量时间相关的逻辑，比如多久回复多少资源, 执行一次操作后有多久的CD。与此相对的是，测试代码需要尽可能快的跑完。

配表 – 在业务逻辑中，有大量逻辑是根据配置来，因此测试代码并不能写死，需要根据配置自适应。而且升级配表之后，很难保证测试代码的正确性。

数据库 – 在业务逻辑中，玩家所有的操作造成的影响都会被存入数据库，因此测试不具有可重复性。

其实我很早以前就想为我写过的业务逻辑编写测试代码，但是基于以上种种原因，尝试了几次均以失败而告终。

由于最近出Bug的概率太高了，我下定决心想去解决游戏服务器的单元测式。

即然书上的理论在我这里行不通，那么我去看一些开源项目对单元测试是如何落地的。

我分别考察了Lua和Redis，发现他们都没有做大量侵入式的单元测试。而是通过他们“特有的方式”来触发相关的代码执行。

比如Lua是通过执行Lua代码来测试Lua虚拟机的各种角落，而Redis则是通过网络协议来测试。

我研究了一下这种方式，发现对游戏服务器同样可行。

其实我们根本不需要mock类。理论上我们可以通过网络协议来操作模块处理指定状态。然后再发协议操作某个特定模块，以验证这个模块的正确性。只要我们为服务器的每一个模块编写一个对应的测试操作模块，就可以大幅度减少测试代码, 大大提高了测试的可行性。

比如account操作模块提供一个account.eusure_create_role_whith_money(name, passwd, money)来保证创建一个名字为name, 密码为passwd, 初始金币为money的账号。

解决了mock类的问题之后，再来看看时间问题。

为了让测试代码尽可能快的运行，我们只有一种选择，那就是调时间。但是频繁去调开发机的时间，会造成一些很麻烦的后果，而且每个单元测试之后，都要把时间调回来。

好在，当时为了减少time()函数造成的系统调用，我封装了一个time.cpp静态类，所有的时间都是通过time::get()函数来获取的。我设计了一条GM指令，可以调整时间偏移量。为了避免测试相关的GM指令逃逸到线上去。我在本地Makefile加入了一个TEST宏，以确保只有test版本才会有这些指令。如此，时间的问题解决了。事实上不仅仅是调时间，我还加了少部分用于控制特殊逻辑的GM开关，以方便测试代码执行（就像Lua同样在源码里留了一些桩点用于测试使用)，这些控制逻辑同样是被TEST控制。

配置表的问题，咋一看很麻烦，但是静下心来想想，其实我们的代码依赖的并不是表中的内容。而是表结构。所以在写完测试代码之后，除非功能有变化，不然根本没有理由去更改表的内容。惟一麻烦的是，有时候我们需要通过改表来隔绝其他模块造成的干扰。这种情况下，我们就需要为这引单元测试代码定制一份配置表出来。这也意味着我们的单元测试框架需要有，能为不同单元测试代码指定不同配置的能力。

数据库的问题，其实在我们编写测试操作模块时就已经解决了。我们只需要像Redis一样，在执行每个单元测试之前，把所有测试进程杀死，并且清空数据库即可。每个单元测试自己负责构造自己所需要的数据。由于我们的测试操作模块提供的都是很上层的操作。因此创建数据部分，并不会花费太多代码。

基于以上事实，我实现了一个简易的单元测试框架，并配合valgrindt和GCC的ASan，可以同时进行逻辑测试和内存问题测试。

这个框架有部分项目相关性，而且代码并不算太多，因此并没有开源。

ps. 在编辑测试框架过程中，发现一个有意思的问题。当可执行程序在运行过程中，替换其所依赖的so文件会造成进程崩溃。研究了一下发现，这是因为so文件的代码部分是通过mmap到进程内存空间直接执行的。而mmap的特性就是，对映射内存的修改，直接反映到文件，对文件的修改直接反应到mmap的进程内存地址。而cp命的执行步骤一般是，将文件大小截断为0，然后再写入新文件内容。当文件大小截断为0这个步骤，一下子就把so的代码部分破块了，崩溃也就成了必然。

在日常开发中，伪随机函数几乎是必不可少的一个函数。

大部分我们在使用这个函数时，就自然而然拿来用了，很少去思考用的对不对，反正他是随机的，并且也很难去验证（需要各种大量数据统计)。

所以即使概率看起来不太对，也可以安慰自己说，其实是统计的数据量不够。但有时候真的是因为我们误用了随机函数。

在《计算机程序设计艺术》卷2中，详细介绍了线性同余序列的生成算法。
下面就以线性同余算法为例，来分析一下，为什么随机函数还有可能被误用，他原本不就是随机的么？

在游戏开发中，一般都会设计有开宝箱环节，假设每个宝箱每次开出A的概率是30%，开出B的概率是70%，宝箱可以重复开。

我们的代码可能会这么写

    int open_box(box *b)
    {
        int n = rand() % 1000;

        return  n < 300 ? b->a : b->b;
    }

是的,这段代码就是开宝箱存在“垫刀”的根本原因。

我们来看一下线性同余(LCG)伪随机算法的定义：

Nj+1 = (A*Nj + B) (mod M)(j, j+1为下标)

其中A,B,M为线性同余序列生成常数。

LCG周期为M，A,B,M的关系限定如下：

1. B,M互质
2. M的所有质因子都能整除A-1
3. 若M是4的倍数，则A-1 也是
4. A, B, N0都比M小
5. A,B是正整数

通俗点来讲就是，线性同余生成的[0,M)个数在统计学意义上，是等概率出现的。也就是说在足够多次随机以后，他们出现的次数是相同的。

咋一看，感觉上面的代码好像没啥问题。因为[0,M)是等概率出现的，因此rand()%1000之后的值，也是等概率出现的。

但是！我们忽略了一个事实，这段代码意味着。所有人的所有宝箱（甚至还有其他系统）共用了一个伪随机序列。

假设rand()%1000的伪随机序列是这样的：

900，1，300， 500， 299， 785， 556 …

我们来模拟一下多个宝箱交替打开的行为：

开宝箱1，rand()%1000返回的是900， 因此开出来的是B

开宝箱2，rand()%1000返回的是1， 因此开出来的是A

开宝箱1，rand()%1000返回的是300， 因此开出来的是B

开宝箱1，rand()%1000返回的是500, 因此开出来的是B

开宝箱2， rand()%1000返回的是299， 因此开出来的是A

如果宝箱1和宝箱2一直在以类似的顺序交替打开。即使开再多次，你也很难拍着胸脯说，宝箱1和宝箱2开出来的A，B概率分布是符合预期的。

毕竟你亲口告诉玩家，每个宝箱都有30%的概率开出来的是A，但是宝箱1却从来开不出A。

事情之所以会演变成这样。根本原因是，除了有一个伪随机序列之外，还有一个真随机事件，即玩家开宝箱的时机选择。

用软件工程的话来说，宝箱1和宝箱2通过一个全局变量（同一个线性同余序列）耦合在一起了，他们不是正交的。因此，开一个宝箱势必会影响另一个，所以它必然是错的。

还有很多类似的情况，比如一个技能的触发概率。我们本来告诉玩家的是每个技能以某种特定的概率触发，但是我们很可能做成了，以某种概率释放了某个技能。

在我们用随机函数之前，一定要先问问自己，所有使用rand()函数的地方其实是共用了同一个伪随机序列，这样真的没问题么？

2021/11/16补充:

经过这一年多来的观察, 除了"垫刀"的问题之外, 我们还习惯使用如1000, 10000之类的数字来代替100%的概率. 这就会产生一个现象, 就是1000或10000很可能和LCG公式中的M是有公约数的, 这会导致LCG的周期缩短, 其影响远大于"垫刀"产生的不良影响。在我们将接近1000或10000的质数作为100%概率的代表时，随机数的分布有明显改善。

最近在用Lua实现Websocket协议时，碰到了一个直击我的思维惯性的弱点的Bug。代码大约如下(实际实现较为复杂，比如还支持wss协议，因此定位到问题也着实花费了一些功夫，毕竟GC的执行是异步的.)：

--websocket.lua
local M = {}
local mt = {
__index = M,
__gc = function(sock)
    close_via_c_layer(sock[1])
end}
function M:connect(url)
    local ip,port = parse from url
    local fd = connect_via_c_layer(ip,port);
    local sock = setmetatable({fd}, mt)
    return sock
end
....
return M
--foo.lua
local ws = require "websocket"
local sock = ws:connect("ws://127.0.0.1")
print(sock)

--main.lua
require "foo"
while true do
    collectgarbage("step", 1024)
    sleep for a while
end

起初，我发现foo.lua中建立的链接会被莫名关闭，各种排查websocket的实现。最后才发现竟然是sock对象的__gc函数被触发了。

查到的问题后，我足足想了有5分钟才明白过来为什么sock会被GC掉。

因为潜意识中，foo.lua类似于下面C代码，其中sock变量是与整个C代码的生命周期一致的。而在C语言中，代码是不会被回收的。因此sock是作用域有限的全局变量。

#include "websocket"
static websocket sock;
void exec()
{
    sock = websocket::connect("ws://127.0.0.1:8001");
    print(sock);
}

那为什么在Lua中sock变量会被GC掉，就要从Lua的基本规则说起：

在Lua中，一共有8种基本类型: nil、boolean、number、string、function、userdata、 thread 和 table。

其中’string,function,userdata,thread,table’等需要额外分配内存的数据类型均受Lua中的GC管理。

而require "foo" 的本质工作（如果你没有修改packaeg.preload的话）是在合适的路径找到foo.lua，并将其编译为一个chunk（一个拥有不定参数的匿名函数），然后执行这个chunk来获取返回值，并将返回值赋给package.loaded["foo"]。

在这个chunk被执行之后，整个LuaVM再无一处引用着此chunk. 因而此chunk可以被GC掉，而顺带着，被chunk引用的sock变量也一并被GC掉（因为sock变量仅被此chunk引用）。

一切都是这么的自然和谐，惟一不和谐的就是，我犯了这个错误。

以往在研究GC时，就单纯的研究GC，在一张图上经过若干步骤进行mark,再进行若干步骤进行sweep。

在编写Lua代码时，却往往根据以往的c/c++经验来判断变量的生命周期, 毕竟就算在如java,C#这些带GC的面向对象语言中，这些经验依然适用。

也因此，在我面向对象编程范式（也许叫‘基于对象’更合适，毕竟我极少使用继承）的思维惯性下，潜意识竟然将这两个紧密相关的部分，强行割裂开来。

以往写Lua代码时，我一直以为Lua是“原型对象”编程范式，然而这个“大跟头”让我发现，原来Lua的底层基石竟然是“函数式编程”范式（非纯函数式编程语言，Lua中的函数有副作用）。

在我们写代码之初，就被人谆谆教导：“程序＝算法+数据结构”。

过一段时间（也许很久），我们又被教导各种编程范式，如：“面向对象编程范式，函数式编程范式”。

接着你就会问：“什么是函数式编程，什么是面向对象编程？”

会有很多人告诉你：“在函数式编程语言中，函数是一等公民。在面向对象编程中，万物皆对象”。

然后你（主要是我自己）就开始似懂非懂的用这些概念去“忽悠”其他人。

却从来没在意过，整个编程范式中，数据的生命周期是以何种方式被管理着，以及数据在以何种方式进行转换和通信。

借着这个Bug的契机，我从数据的视角来重新审视了一下这些话，有了一些意想不到的发现。这次终于打破了以往的范式惯性（上次学Lua时，我也是自信满满的认为我懂了函数式编程，结果摔了个大跟头）。

先来大致看看面向对象的哲学。

在纯面向对象编程语言中(C++显然不算)，所有的逻辑交互均是在对象之间产生的，不允许变量产生在对象之外。

即使他们在努力的模仿函数式编程，比如所谓的委托，匿名函数。然而这些函数背后却总是逃不开this指针的影子。比如下面代码：

using System;
using System.IO;
namespace test {
class TestClass {
    public string a;
    public delegate int foo_t();
    public int bar() {
        foo_t func = ()=>{Console.Write(a + "\n"); return 0;};
        func();
        return 1;
    }
};
class Program {
    static void Main(string[] args)
    {
        TestClass tc = new  TestClass();
        tc.a = "foo";
        TestClass.foo_t cb = tc.bar;
        cb();
    }
}}

再来看看函数式编程范式中一等公民的定义："如果一个语言支持将函数作为参数传入其他函数，将其作为值从其他函数中返回，并且将它们向变量赋值或将他们存储在数据结构中，就在这门语言中，函数是一等公民。

我认为对于有C/C++背景的人来讲，这不足以解释函数式编程的特点。

因为在C/C++语言中，函数指针同样可以做到上述所有的事情。

惟一的区别就是函数式编程语言中的函数其实是闭包（所需要的上下文+指令码（也许是CPU指令，也许是VM的OPCODE）），而C语言中的函数就真的是一段CPU指令。这两种函数有着本质上的区别。

类比面向对象是万物皆对象，函数式编程就应该是万物皆函数。

而实现万物皆函数，闭包是函数式编程必不可少的条件（这里不讨论纯函数式编程范式，连LISP都不是纯函数式编程语言）。

在函数式编程范式中，所有的逻辑交互均是以函数（闭包）为主体来运行。

每一个函数会携带自身所需的环境变量，以便在任何需要执行的地方执行。

自身的GC机制会保证，在函数（闭包）没有被回收前，其携带的环境变量永远有效。

在Lua的require和chunk的机制中我摔的跟头充分验证了这一点。

最后让我绞尽脑汁举一个不太恰当的例子来收尾吧（毕竟我也是刚刚(自以为)重新认识了函数式编程）：

local function travel(tbl, process)
    return function()
        for k, v in pairs(tbl) do
            process(k,v)
        end
    end
end

local function printx(title)
    return function(x, y)
        print(title, x, '=>', y)
    end
end
local tbl = {"foo", "bar"}
local func = travel(tbl, printx("index:"))
tbl = {"newfoo", "newbar"}
----other logic
func()

终于又甩掉了一个包袱, 这是我重构完第一句想说的话。

从我入职开始, 就因为这套登录逻辑的复杂性而略为不满, 其间还坑过我一次，但是因为一直勉强能用，所以也没有理由对它动手。

这一次终于因为不能够满足新需求，而让我有理由可以重构这段代码了。

旧的登录流程大致如下：

    $UST=(uid,session,token)
    Client-------------AuthServer---------------------GameServer-----------DBProxy
     *--"账号密码认证" ---> * 
                     检查账号密码,
                     生成session和token
                          *----------发送$UST----------->*
                                                     记录$UST
                          *<----------成功--------------*
    *<------$UST----------*
    *-------使用$UST登陆-------------------------------->*
                                                     校验$UST是否匹配
                                                        *------请求加载------->*
                                                                      加载玩家数据
                                                        *<---返回玩家数据------*
    *<---------------------------返回登陆成功------------*

每一个认证流程都会生成一个惟一session,类似tcp连接. 甚至加载玩家数据也会带着同样的session请求。如果此次数据加载与当前登陆session不符，则拒绝使用，直接抛弃。

session的存在使的整个“认证－登陆”流程可以做到精确无比。

然而，这种精确会带来其他问题，例如客户端出于某种bug多发了一次认证，就会导致整个登陆流程失败，并且会导致重复加载玩家数据（事实上我真的被这个问题坑过，查了好久才发现问题）。

经过这次重构后，我去掉了session机制，并将GameServer的整个登陆流程切分成三块相对独立的逻辑，即“认证逻辑”，“加载逻辑”，“登陆逻辑”。

1. 当AuthServer检查账号密码正确后，即颁发token, 将uid，token发往GameServer。
2. 当GameServer的“认证逻辑”到消息uid,token之后，记下token并随即调用“加载逻辑”进行数据加载。
3. 当GameServer的“登陆逻辑”收到协议后会检查uid,token是否匹配，如果匹配则等待数据加载完成，然后向客户端返回登陆成功。

“认证逻辑”在收到AuthServer的消息后，仅简单的记录每一个要登陆的uid对应的最新的token,并踢掉当前在线的链接。

“加载逻辑”则需要对加载请求进行过滤，防止重复加载。当收到加载请求后，如果数据已经加载途中或已经加载完成，则直接扔掉加载请求。为了防止DBProxy挂掉，而造成加载卡死。每一个玩家会有一个30秒的加载超时时间（即超过30s后即使DBProxy还没有返回数据，下次收到加载数据请求，依然会再次向DBProxy请求）。

加载数据返回后，总是检查当前内存中是否已经有加载成功的数据，如果没有才使用当前DBProxy返回的玩家数据，如果已经有数据，则直接抛弃。

之所以这样做，是为了数据一致性问题。来看一下如下操作序列。

GameServer视角：加载数据请求A—〉等待30秒—>加载数据请求B—->加载数据请求A返回—>玩家开始操作，修改玩家数据—>向DBProxy更新数据—>另载数据请求B返回。

DBProxy视角: 加载数据A->返回加载数据A->加载数据B->返回加载数据B->修改数据

如果此时应用数据B，则在A返回和B返回对玩家数据的修改则全部会丢失。而旧的登陆逻辑，之所以在加载数据时依然带着session,应该也是为了防止数据一致性问题，但是我们玩家数据都是采用Write-Through方式来将一个玩家的所有数据都cache内存之后才进行修改的。因此我认为只取第一份成功加载的数据就可以解决一致性问题。

重构之后的登陆流程大概如下：

    $UT=(uid,token)
    Client-------------AuthServer---------------------GameServer-----------DBProxy
     *--"账号密码认证" ---> * 
                     检查账号密码,
                     生成session和token
                          *----------发送$UT----------->*
                                                     记录$UT
                          *<----------成功--------------*--------请求加载----->*
    *<------$UT----------*                                         加载玩家数据
                                                         | <-----返回玩家数据--*
    *-------使用$UST登陆--------------------------------> |
                                                         |
    *<------返回登陆成功----------------------------------* 

本来“加载逻辑”还要负责登陆超时的淘汰操作，即数据加载之后，客户端迟迟不向GameServer发送登陆请求，这时需要将加载出来的数据从GameServer淘汰掉。

但是由于我们专为手游实现了半弱联网机制。在socket断掉之后，N分钟以内会保留玩家数据。这可以保证在地铁或电梯等信号不好处链接断掉后，可以在信号良好时快速登陆。

因此“加载逻辑”将数据加载完成之后，直接交给原本的数据淘汰逻辑即可。

除了登陆流程以外，这次重构我还修改了"登陆"的语义。

重构前, 对AuthServer发起认证时，会先尝试对账号进行注册，再发送登陆协议。虽然这样可以避免在新号时连着发送三条认证相关的协议。但总感觉有点bad taste。

重构后，我将"登陆"定义为"如果账号不存在则先执行注册， 然后执行登陆逻辑"。

重构前,对GameServer发起登陆时,如果uid还没有对应的游戏数据,同样会返回错误。然后客户端根据错误码去发初始化消息进行初始化， 在初始化的过程中，如果由于某种原因连续多发，同样会出现问题。

重构后，当GameServer收到$UT准备加载数据前，会先检查uid是否被初始化过数据，如果没有，则直接向DBProxy请求创建。DBProxy创建玩家数据与DBProxy加载玩家数据具有相同的返回。

这样整个"认证-登陆"逻辑相关的协议，由4条（"注册","认证","创建","登陆")降为2条("认证","登陆")。

这里会有一个问题，刚开服时，可能有很多玩家只注册完就卸载走人了。这样会浪费我们的服务器资源。因为他只要发一条"认证"，我们就帮他把数据创建好了。

幸运的是，我们新实现里， 恰好提前实现了删号功能。即一个低级玩家多久没登陆过之后，过一段时间会自动被清理。

ps.重构之后，个人觉得对于整个流程，服务端和客户端都各种更内聚了，因为整个登陆流程的判断都被挪到了服务端。

上次增加资源半自动释放机制之后，根据log显示已经有30%~40%的资源被释放掉了（大部分为UI资源)。然而内存问题，并没有明显改善。

我们的资源管理是通过一个叫做ABM的模块进行管理的，ABM采用标准的引用计数方案来管理资源和AssetBundle的生命周期。

当使用ABM.load_asset时会首先检查这个资源的引用计数是否为0，如果为0则会触发加载相应AssetBundle操作。

加载AssetBundle时会首先检查AssetBundle的引用计数是否为0，如果不为0则直接将引用计数加1.并将结果返回即可。

如果AssetBundle的引用计数为0，则除了要对引用计数加1之外，还需要递归加载其所依赖的其它AssetBundle。

如果所需要加载的AssetBundle有依赖于其他AssetBundle，则先递归加载所有依赖的AssetBundle，最后再加载自身。

当卸载一个资源时，首先将其引用计数减1，然后检查其引用计数是否为0. 如果引用计数为0，则触发AssetBundle卸载操作。

卸载AssetBundle时，同样将其引用计数减1，如果引用计数为0，则调用Unity接口AssetBundle.Unload(true)真正释放AssetBundle. 同时递归卸载依赖的所有AssetBundle。

由于担心资源泄漏不可控，所以我们并没有使用AssetBundle.Unload(false)来进行AssetBundle释放。

在整个流程，只有AssetBundle的引用计数为0时，才会被调用Unity接口进行释放。而仅在AssetBundle被释放时，其内部被加载过的资源才会被释放。

换句话说，假如一个AssetBundle有10个资源，如果先加载其中9个，再加载任意2个，最后再将上次加载的9个资源进行释放。这10个资源就会同时存在于内存之中。

因此一个AssetBundle的利用率（即AssetBundle中同时引用计数大于0的资源数量除以AssetBundle中的资源数量）越低，这个AssetBundle中的资源同时出现数量就会越少，相邻两次同时存在内中的资源集合的交集就可能会越小，资源内存泄漏的概率就越大。

当然事情并不是绝对的，如上面的例子，如果先卸载9个资源，并且此AssetBundle没有被其他AssetBundle所依赖，就会产生一次AssetBundle.Unload(true)，此时再加载此AssetBundle中的2个资源时，这个AssetBundle会被重新加载，并从AssetBundle加再次加载所需的2个资源。这样就不会有内存泄漏。

但是实际的AssetBundle依赖关系及资源加载顺序都比较复杂，很难保证上述良好的情况及顺序。因此我认为AssetBundle的利率用还是有很大的参考价值的。

为此，我写了一个AssetBundle Profiler，通过折线图来实时显示当前所有AssetBundle的平均利用率。

当选中某个采样点时，可以详细看到此时每个AssetBundle的利用率，并可以查看任意一个AssetBundle中所有资源的引用计数情况，及所在的图集（如果是图片的话)。

相信通过连续观察某一个AssetBundle的资源的详细加载情况，可以为我们如果优化拆分AssetBundle有不错的帮助。比如，我们可以通过资源的使用频次，根据频次的多少来做成树状态倚赖的AssetBundle关系，或者将逻辑上互斥的资源拆分成多个AssetBundle, 即使这些资源只属于同一个模块使用。

然而,上面的方法只能一定程度上改善内存泄漏问题，并不能真正解决问题。因为我们真的很难保证AssetBundle中的所有资源一起加载一起释放。

最好的办法就是，在一个资源的引用计数为0触发卸载AssetBundle之前，先调用Resources.UnloadAsset，将这个资源进行释放。

上述ABM的实现中，没有执行此操作的原因在于，当被加载的资源是一个Prefab时，他可以引用各种其他资源，这些资源会被AssetBundle.LoadAsset(Async)时, 会被Unity底层进行加载。

如果这个Prefab所依赖的资源在其他AssetBundle中，Unity就会通过AssetBundle的依赖关系告诉我们，需要加载这个被依赖AssetBundle。 至于Prefab所用的资源则由Unity底层自动加载，上层的ABM是感知不到的。

换句话说，ABM中的资源的引用计数是不准确的，它的精度仅能够正确指示AssetBundle的生命周期，而不能正确指示其自身的生命周期。

如果要想使资源的引用计数准确指示出资源的生命周期，就必须在加载Prefab这类引用其他资源的资源时，修正所有被Prefab依赖的资源的引用计数。

如果要这么做，就必须要做好两件事。

1. 如何运行时获取资源之间的倚赖关系

2. 如何时处理资源与AssetBundle的引用问题

对于第一件事，Unity并没有提供运行时获取资源之间的依赖关系。幸运的是，AssetDatabase.GetDependencies提供了一个非运行时接口。因此我们可以在生成AssetBundle时，通过生成一个文件来存储资源间的依赖关系并在运行时解出。

如果一个资源被“引用”之后引用计数为1，则递归对它所依赖的所有资源引用计数加1。同样如果一个资源被卸载后，如果引用计数为0，则递归对他所依赖的资源引用计数减1。

由于Unity底层会自动加载被依赖的资源。为了避免无谓的开销，在操作引用计数时，我们仅仅去修正资源的引用计数而并不实际去加载资源，同样也不需要去加载相应的AssetBundle（也不去操作其引用计数）。

这对我们做好第二次事，造成了困扰。因为此时资源的引用计数与AssetBundle的引用计数完全割裂了。我们需要重新找到一个判断何时加载AssetBundle的依据。

最开始我认为应该将资源间依赖产生的引用计数单独记录，可以叫depend_ref, 而原先的引用计数ref含义及触发的操作保持不变。

如此，我们就可以在产生资源依赖时修正depend_ref，而在资源释放时，如果ref和depend_ref同时为0，则调用Resources.UnloadAsset。

这样做一定是对的，因为其实depend_ref与AssetBundle之间的依赖关系其实是重合的，所以就算ref的值为0而触发AssetBundle卸载操作，只要depend_ref不为0，这个AssetBundle的引用计数一定大于1，从而不可能被真正释放。

经过观察发现，而在释放时，depend_ref+ref一起产生作用，在加载时，ref单独产生作用，在处理依赖关系时depend_ref单独产生作用。

而ref产生的惟一作用就是当它为0时，进行加载和卸载AssetBundle。

前面说过就算ref等于0只要depend_ref大于0，AssetBundle是不可能被卸载的，因为depend_ref本质是反应的是AssetBundle之间的依赖关系，同时因为depend_ref大于0，说明依赖他的资源还在内存中，因此资源不能释放，他所在的AssetBundle也不能释放。因此depend_ref和ref逻辑是统一的，可以进行合并。

而在加载时，ref的作用仅仅是在等于0时进行AssetBundle加载。这是一个2值变量，就是说要么是true, 要么是false。恰好我们有一个相似的变量可以使用，每个被加载成功且没有卸载资源，ABM必须要保留其引用，以避免重复加载。当我们卸载此资源后，为了避免被误为，一般会将资源引用置为null。终于，ref可以和depend_ref进行合并了，我们的抽象更完美了一些。

修改后ABM流程如下。

当加载一个资源时先通过资源间的依赖关系修正相关资源的引用计数，以正确表明资源的生命周期。

判断需要通过ABM加载的资源的引用是否为null,如果不为null则直接返回。如果为null则加载相应的AssetBundle(处理AssetBundle及其依赖的引用计数逻辑不变)。

当卸载一个资源时同样根据资源间的依赖关系修正相关资源的引用计数，如果引用计数为0，且ABM持有的资源引用不为null,则调用Resources.UnloadAsset同时触发AssetBundle的卸载操作。然后将资源引用置为null。

ps. "释放"指通过AssetBundle.Unload(true)，而"卸载"指处理AssetBundle的引用计数，如果为0，则真正"释放"

pps. 如果多张图片在一张图集里，只要图集中任意一张图片没有Resources.UnloadAsset，整张图集也不可能被卸载。