项目本身——那个叫《莉吉内塔的冒险》的小东西，磨磨蹭蹭总算是跑起来了。但真正让我头疼的，不是代码，而是怎么让别人能拿到手，并且保证后续更新不麻烦。我以前老是依赖各种大平台，被卡脖子的滋味不好受，所以这回我下定决心，要自己从头到尾搭一套能用的分发和更新系统。
从零开始：搞定下载这破事
一开始我想得简单，随便找个网盘扔上去不就得了？结果发现不行。网盘那速度，那广告，用户体验简直是喂狗。而且每次我小修小补一个Bug，我都要手动上传一整个新包，几百兆的东西，我累死了，用户也累死了。
我决定自己动手搭一套。第一步，解决文件的储存和下载地址的问题。我琢磨了一圈，租了个便宜的云服务器，专门用来放安装包和补丁文件。这个过程我反复折腾，调整了N次权限，确保文件能公开访问，但又不能被随便乱搞。
光是配置那个CORS（跨域），我就抓秃了半边头，查了三天三夜的社区帖子，因为客户端程序要读取服务器上的版本信息文件，浏览器安全策略老是拦着。我不得不学习了一堆关于HTTP头和MIME类型的基础知识，才把那个下载地址固定下来，确保任何客户端都能顺畅访问。
我动手写了一个小小的后端脚本，它的唯一任务就是根据用户请求，提供最新版本安装包的裸链接。这个脚本用起来很简单，但它内部做了一层简单的流量控制和日志记录，让我能知道到底有多少人在下载，也方便我后续审计，防止有人恶意盗用流量。这部分虽然耗费精力，但帮我完全掌握了初始下载的入口权。
真正的难点：更新机制的实践
下载地址固定下来就好办了，一个固定的链接就行。但更新地址才是个大麻烦。我可不想用户每次都重新下载几十个G的文件，那太浪费资源，也太慢了。我必须实现增量更新。
我采取了最笨也最实用的办法：版本控制文件。我的思路是这样的：
- 第一步：制作清单。我写了一个自动化脚本，每次我编译完新的《莉吉内塔的冒险》，脚本就会跑一遍，把所有文件都扫描一遍，计算出每个文件的MD5值和文件大小，生成一个叫`*`的最新版本号清单。
- 第二步：客户端比对。我修改了启动器程序，让它在用户启动游戏前，先去服务器拉这个最新的`*`。然后，它会对比用户本地的旧清单（上一次更新时保存的）和服务器上的新清单。
- 第三步：生成差异包。对比发现哪个文件变了，哪个文件是新增的，一目了然。对于“修改”的文件，我不再整个下载，而是学习了老前辈们搞补丁包的思路，用了一个叫bsdiff的工具（我用了个国产替代品，原理差不多），只打包差异部分。
为了生成这些差异包，我得在我的开发机上跑一套复杂的脚本，专门用来对比当前版本和上个版本的二进制文件，然后压缩成一个tiny的补丁包。这个过程一开始经常出错，因为有时候文件路径大小写不对，对比就会产生巨大的错误差异，导致补丁包体积反而比整个文件还大。我硬是花了好几个通宵，把文件名和路径的规范化流程锁死了，才解决了这个乌龙。
这套流程跑下来，一个原来要下载500MB的更新，现在只需要几MB的补丁，用户那边下载速度快得飞起，我的服务器带宽压力也小多了。实践证明，自己动手搞一套增量更新，虽然麻烦，但效果立竿见影。
实践教训：为什么非得自己折腾
我折腾这套流程花了整整两个月。这比做游戏本身还让人心力交瘁。为啥非要搞得这么复杂？因为我之前在老东家吃过大亏，那个痛我到现在还记得。
那时候公司有个项目，所有更新渠道都依赖一家第三方平台。平台说变脸就变脸，说停服务就停服务，把我们卡得死死的。我记得清清楚楚，那是一个周五晚上，我正准备下班，突然收到平台通知说要调整接口费率，直接涨了三倍。老板差点把键盘砸了，但我们毫无办法。
当时我们连夜赶工，试图把渠道切换到另一家，结果因为技术架构和各种API耦合得太紧，根本动不了。那段时间，我几乎天天睡在公司，处理各种因为平台政策变动导致的崩溃反馈。我老婆都快不认识我了，问我到底是嫁给了程序员还是嫁给了服务器。
从那以后我就明白了，核心的分发权一定要抓在自己手里。宁可自己多费点劲搭个土平台，也不能把命运交给别人。这回做《莉吉内塔的冒险》，我就死活坚持，所有的下载和更新逻辑必须自己写，必须是裸链接，不受任何第三方平台的约束。更新地址和下载地址，完全在我掌控之中，想什么时候发，发什么内容，都是我说了算，这个感觉，太踏实了。