嘿，召唤师们
今天，在接下来六个月的时间里，我们会为《英雄联盟》客户端后端的基础架构
推出一系列新的改动与改进举措。
为了追踪我们的进展，针对两个主要的客户端性能数值：客户端完全启动时长(即启动所需时间)以及英雄选择锁定时间，我们会与大家分享一些具体的目标。
在过去的一段时间里，客户端曾出现过一些BUG、崩溃以及延迟方面的问题，我们在2019年经过了很长时间的监测分析与调整，虽然经过了一些改善，但我们认为依然还不够，我们想试试其他办法来让客户端整体的体验变的更好。简而言之，我们希望能让客户端有一些更明显的体验优化。
相比于介绍后续的相关计划，我们更想与大家分享的是接下来这六个月打算推出改动的具体性能目标以及明确的细节信息。
客户端数据
我们希望实现的是，即使是那些电脑速度较慢的玩家，完全启动所需的时间也不超过15秒，目前来看，有些玩家完全启动所需要的时间可能是这个数字的三倍甚至是四倍。
我们检测的一个比较重要的问题是“英雄选择锁定”时间。即在你点击按钮之后客户端记录你锁定该英雄需要的时间。在下方的图表当中，大家可以看到9.22版本(橙色)以及10.2版本中(蓝色)英雄锁定的平均响应时间。
上面的图表显示出不同的玩家之间英雄选择响应时间差异。当然，客户端的性能因你电脑的速度会有所不同。举例来说，如果你的锁定时间低于0.2秒，那你的电脑就可以排进前10%了，说明你的响应时间比90%的玩家都短。同样，如果你的响应时间超过了0.8秒，那你就是靠后的那10%了，就是说你客户端运行的速度要比90%的玩家慢。
大家可以看到，相比于9.22版本，10.2版本中玩家的锁定时间有了大幅改善。这次改善最大的原因在于，我们在9.23版本中更新了客户端运行所使用的Chromium引擎版本。这为我们带来了很大的帮助，但我们认为依然可以再实现一些提升。
为了让大家更容易理解，我们来看一组更详细的数据，就是特定群体玩家英雄锁定响应时间随日期的变化。
如大家所见，蓝色线代表第50百分位，也就是“中位”玩家的水平，图表上中位玩家锁定响应时间大幅降低确实很好，但目前来说，中位玩家英雄选择相应时间在0.3秒所有浮动，压力较大的服务器可能会更高一点，这虽然算不上可怕，但依然会有延迟感。
第70百分位的玩家(绿色线)体验近期也有大幅的改善，但是他们的英雄选择响应时间在0.45秒左右浮动。老实说就算是对于电脑配置一般的玩家，这也比我们期望的反应效率要慢一些。
最后， 看看第90百分位(橙色线)真的就非常明显了。毫无疑问，这些玩家的响应速度应该慢于大多数的玩家。0.8秒的数字相对来说会比较夸张，而这还是Chromium 引擎更新之后的情况呢。
如果说服务器压力很大(特别是同时并发时期)或者电脑性能较弱，响应的时间可能比上述数据还要高，这样的体验并不算好。
那么，就说说接下来我们打算怎么办吧!
我们接下来的重点
对于客户端的性能优化，我们会将两个具体的长期目标列为重中之重：
1)我们希望将完全启动时间降低到15秒以内，对于第90百分位的玩家们也是如此。这比之前启动较慢的机器来说，大概提升3~4倍的速度;
2)我们希望第90百分位的玩家英雄锁定响应时间能够降低到0.1秒左右，对于这部分玩家来说，相应效率提升8倍，实际体验上，即点击后基本感知不到延迟时间。
我们知道大家在想什么，因为遇到的问题不止这些，还需要去解决一些比如减少BUG、崩溃与内存泄漏等等的问题，并需要提升发现问题的处理效率。
我们为什么要优先这两方面呢?原因在于，在解决完全启动和英雄选择锁定时间的过程中，我们会对客户端架构的某些基础层面进行清理和重做。我们认为在解决这些关键目标的过程中，可以伺机处理这些BUG、内存泄漏以及崩溃等问题。
像是英雄选择中的“黑屏”BUG以及符文页没有正确保存等问题只是我们打算在此过程中一并解决的部分例子。但是我们想非常坦率地告诉大家，这是需要时间的。我们相信，这大约六个月的计划会帮助我们向这些目标取得长足的进展。但要实现我们的长期追求很可能要更多的时间。
这是我们的目标，但我们无法百分百保证在这个期间内一定能完全达成，我们现在把这些目标告诉大家是因为我们知道，我们会努力持续改善大家的体验，会更坦诚的去面对问题和交流问题。
那么大家可能还想问，我们到底会怎么做呢?
我们会怎么做
我们已经找到了导致启动速度变慢的两大架构问题(这真是一个漫长而又曲折的过程)。首先是我们的插件式架构，它让我们可以将客户端的代码分割成一些有用的大模块。但由于我们为客户端加入了很多的新功能，这个架构变得越发臃肿。其次，我们并没有非常有效合理的利用驱动我们用户界面的Javascript框架(称之为Ember)。
目前，客户端使用了太多的插件和Ember程序。实际上，在客户端完整启动的过程当中，会加载41项单独的插件以及16项程序。它们每项启动都需要0.1到0.8秒不等的时间，加起来可能就是一个不小的数字。
我们的计划是将这些插件和程序整合并大幅精简为少数几个(理论上效率也更高的)插件和程序。我们会先把重点放在启动过程中启用的那些，因为我们相信这将会为客户端的性能提升带来最大的收益。
第一阶段：完全启动
如今，有些玩家的完全启动时间较长的电脑整个启动过程可能会达到40秒的时间，如果你是这其中一员的话，会知道这种体验是多么的漫长难捱，假如非常不幸的再遇到崩溃问题，就更痛苦了。
客户端中有大量的内容，比如通知、好友列表以及收藏标签等都会受到启动时启用的那些插件及程序的影响。所以尽管我们说过长期的追求是将第90百分位玩家的完全启动时间降低到15秒，但我们认为在此过程中还要解决大量的BUG以及影响着整个客户端的低效内容。
主攻启动问题几个月之后，我们会评估一下距离目标还有多远，然后——可能是春天快结束的时候——我们会转向下一个重心专门处理英雄选择问题。
第二阶段：英雄选择
英雄选择引入了更多额外的插件和Ember程序。简单地说，你在英雄选择时所做的每件事几乎都会创建新的程序。交换英雄会生成两个。更换召唤师技能也是如此。
在单次的体验内，你玩《英雄联盟》的时间越久，就有越多这样的程序互相堆积在一起，体验可能会更卡，并且，你在选择英雄时的大多数大多数行动都要依赖与服务器的通讯，这可能会让交互的延迟进一步增加。
英雄选择中真正的根源问题是我们后端系统管理数据的方式，目前我们采用的英雄选择架构可以让我们通过系统传输大量有效的数据。例如，如果拳头决定在排位赛中禁用一个英雄，那几乎所有玩家的这个英雄都会立即被禁用，只要这次禁用被推送上线，就连正在英雄选择过程中的玩家也会无法继续选用此英雄。
这是一套极为强大的系统，但要让它运作起来需要非常强劲的马力。就目前的系统设置方式而言，这个过程中有大量不必要的入口和瓶颈。所以有时候，即使一个小的输入变化，也会有数不清的数据需要重新渲染，这会影响到大家在客户端内的体验。
为了解决这个问题，我们要从根本上改变英雄选择后端架构的工作方式。我们会将英雄选择时所有数据从服务器到客户端的传送方式进行重做，这需要一些时间。
我们还有其他一些雄心勃勃的长期追求，就是让英雄选择变得更高效一些，比如将整个客户端整合成为一个单独的Ember程序而完全不牵涉插件。但短期的话，我们希望推出足够的改动，让客户端按照我们上面所说的目标效率运行。
至于这六个月的阶段结束之后，我们距离“尽善尽美”有多远还是个未知数。但是等我们临近尾声的时候，我们认为我们可能已经取得了很大的进展，并对未来有了更加清晰明确的方向。
未来的方向
我们每隔数月都会通过开发者日志与大家分享我们的进展，其中会有满满的性能数据干货以及对项目时间表的调整的相关介绍。
祝我们顺利吧!感谢大家成为《英雄联盟》的一员，我们稍后再聊。