花了几天时间对“网络游戏”有了些许概念性的了解后，就还是开始攻克前端这个真正摆在眼前的问题了。

插句题外话，前些日子脂评版石头记看完后，这些日子公车途中在看汪曾祺先生的散文。特别是偶得一本说吃的合集，特长，特爽。心得有二。其一，终于意识到散文是什么了，从小一直说散文散文啊，都没想通到底什么是散文，原来这种便是；其二，我真是妄称热爱文学，博客都写得烂如这般，文字洗练还是要下功夫。一名作家，看小说会让你喜欢上他，于是想了解他。故此，散文便是最好的途径了。如汪老一般写到这般“信手拈来无不是”的境界，也就“字如其人”了（搜狗给我打了个信手拈来无不适……我很震惊自己一直理解错了吗？一查发现用“是”是对的，而且这句还真出自脂批）。

前两天状态很不错，一直有点担心是不是打折能量饮料喝多了，后面就“萎了”。至少现在看来并不是。我也不完全信是褪黑素的功劳，但是解决了“贪睡”这个老大难问题，还是挺好的，印证了一句老话：办法总比困难多。

正题

回到前端的问题上。

升了 Unity 2017.2，一是新项目用最新版的习惯（长痛不如短痛），二是有些新功能（比如原生的Tile Map）想试试看情况。

改了下.gitignore。排除了/.vs、Resharper相关路径，还有AssetBundles的导出路径

重新整理了一下Directory，从之前几个项目中，把混乱的“Framework”（自己写的框架，仗着重构namespace方便就先乱起了个名字）切出来，导入插件。

框架和插件选择这两点，等以后稳定下来，肯定需要专门系统的写几篇说明。

然后就是解决了几个问题。首先是AssetBundle，AssetBundle Manager这个插件本身没问题，不过2015年之后在Asset Store上就没更新了。按照我对Unity的理解，这么重要的东西肯定还是在做的，不说别的，就看这几年光官方就出了那么多AssetBundle插件就可能看出官方还是挺重视的，而AssetBundle Manager在这一堆插件中还算是很不错的了。于是Google一下就发现BitBucket上官方有个项目叫AssetBundleDemo，点进去一看果然最近还在更新。Clone下来导入项目一款，嗯不错，Asset Store版本中注释掉的Inspector面板，这个版本是实现了的，应该就是同一个项目的演化版本无疑了，就用它了！

某次还看到了Asset Bundle Browser Tools，Asset Store就有，也是官方出品，看上去比较靠谱，也是果断Github之（比较新），果然，很好用。

接下里的问题就花了几个通宵了，AssetBundle Manager有一些bug和一些兼容性问题，这个好修，修好以后想给提个Pull Request。随后没提真不是我懒，是我一看，好家伙，已经一堆人提过了，官方目前还没管呢。然后呢，这接口是异步的，按照Node.js的经验，异步接口无外乎写成回调和Task（或者Promise，这个我还没完全了解一堆这种名字到底是不是同一个概念的东西，哪天得好好研究研究），对于Task形式的接口，我希望是可以写成

var task = new Task<TResult>(DoSomeJob());
yield return task;
var result = task.Result;

其中，DoSomeJob函数返回值应该是个IEnumerator。

一开始我可犯了难，yield return 一个对象。 这是什么东西？这时才发现原来其实Unity用迭代器实现的这个协程自己理解的还不是那么透彻的。憋了很久算是憋出来了，结果发现嗨，不是和AssetBundle Manager原生接口返回的东西基本一样嘛。那么这个实际上就只是个适配器而已了，充其量可以打两个Log。在使用var的情况下，两种方式的代码甚至可以做到基本无差别。于是……这代码就被我怒删了。

当然……现在后悔了，因为发现其实后续一些框架接口也是要写成异步形式，所以这个类还是有用的，用到了再补回来，知道怎么写了就快了，代码很短，就是个IEnumerator的实现而已。代码后续补上。

研究了AssetBundle Manager与AssetBundle Browser的搭配工作流程，在Editor下和手机上都跑通了，我也困得不行，就拿衣服边上先睡了。

应该淘宝一床被子放公司里。

第二天一早精神依然挺好，继续整框架，发现一个新需求，我必须要让所有逻辑代码在框架启动完毕之后启动。

插播一下，现在框架启动已经是通过[RuntimeInitializeOnLoadMethod]了，真的爽飞。

于是开始改写之前临时写的GameLogic类，开始很顺利，后面发现自己想错了一大堆东西，其实并不可能写成自己想象中优雅的方式，结果还是大改特改，目前算是能跑了，先用着，在自己使用中越来越完善嘛。

这种方式，让服务启动也是使用协程顺序启动成为可能，也算给服务启动时异步加载提供了可行方案（不然脚本肯定比服务先启动的），这个根据需求后期修改。

具体实现依然等稳定了再慢慢写说明……

然后看了新的TileMap，这个很难说，因为我至今还没搞清楚怎么用，所以还是不说了吧，继续研究研究……

所以就去了。