海量之道系列文章之弱联网优化 （七）

接海量之道系列文章

《 海量之道系列文章之弱联网优化 （一）》

《 海量之道系列文章之弱联网优化 （二）》

《 海量之道系列文章之弱联网优化 （三）》

《 海量之道系列文章之弱联网优化 （四）》

《 海量之道系列文章之弱联网优化 （五）》

《 海量之道系列文章之弱联网优化 （六）》

3.4. 多异步

经过前面不懈的努力，初步打造了一个比较好的技术根基，好马配好鞍，好车配风帆，怎么就把领先优势拱手送与特斯拉了。

用户欲壑难平，资源供不应求，靠“术”并无法优雅的解决。跳出来从产品角度去观察，还有些什么能够触动我们思考的深度呢。根据不同的需求和使用场景，用有损服务的价值观去权衡取舍，用完美的精神追求不完美，此乃道的层面。

所谓大道至简，完美之道，不在无可添加，而在无可删减。通过多异步和各类缓存机制，提供区分网络、区分业务场景下的差异化服务，是我们孜孜以求的大“道”。

下面通过一些实践案例的总结，来探索简洁优雅的弱联网体验改善之道（开始肆无忌惮的吹嘘了）。

①　【网络交互可否延后】

微博客户端某个版本启动时，从闪屏加载到timeline界面需要6秒+。这样的体验是无法接受的，与用户2秒以内的等待容忍度是背道而驰的。从技术角度去分析，很容易发现问题，诸如我们在启动时有10+个并发的网络请求（因为是HTTP短链接，意味着10+个并发的网络链接）、闪屏加载、主UI创建、本地配置加载、本地持久化数据加载至Cache等等程序行为，优化的目标很自然就集中在网络请求和本地配置、持久化数据加载上。

梳理并发网络请求，可以从以下三个方面考察：

1) 哪些请求是要求实时拉取的，比如timeline & 提及 & 私信的数字、身份校验；

2) 哪些请求是可以异步拉取的，比如timeline、用户Profile、云端配置、双向收听列表、闪屏配置、timeline分组列表、相册tag列表等；

3) 哪些请求是可以精简或合并的，比如timeline & 提及 & 私信的数字与身份校验合并；

此时，取舍就非常简单和清晰了，启动时1~2个网络请求足够应对。所做的仅仅是把一些请求延后发起，这是一种异步机制。

在移动APP里面还有大量类似的场景，比如用户更新了APP的某个设置项或者自己Profile的某个字段，是停在界面上转菊花等网络交互返回后再提示结果，亦或是把界面交互马上还给用户，延后异步向服务器提交用户请求，这里面的价值取向不同，“快”感也便不同。

②　【网络内容可否预先加载】

微博客户端在timeline刷新时，用户向上快速滑屏，到达一个逻辑分页（比如30条微博消息）时，有两个取舍，一是提前预加载下个分页内容并自动拼接，给用户无缝滑动的体验；二是等到用户滑动到达分页临界点时现场转菊花，卡不卡看当时的网络状况。实践中选择了方案一。用户在滑动浏览第一个逻辑分页时，APP就利用这个时间窗主动预先拉取下一个逻辑分页的内容，使得用户能享受一个顺畅的“刷”的体验。

所做的仅仅是把一个请求提前发起了，这也是一种异步机制。思考的要点是：

1) 预先加载的内容是用户预期的吗，预先加载和自动下载之间，失之毫厘谬以千里；

2) 预先加载的内容对用户移动设备的资源（比如流量、电量等）和后端服务器的资源（比如带宽、存储、CPU等）消耗要做好估算和判断，体贴和恶意之间，也就一步之遥；

3) 预先加载区分轻重数据，轻数据可以不区分网络状况，重数据考虑仅限优质网络下执行，最好这些策略云端可以控制；

4) 预先通过网络拉取加载或存储的过程中，不要打搅用户的正常使用；

在移动APP中，预加载有大量的实践，比较典型的就是升级提醒，大家都采用了先下载好升级包，再提示用户有新版本的策略，让你顺畅到底。

③　【用户体验可否降级】

微博客户端在中国香港公共WIFI下刷新timeline总是失败，通过后台用户接入请求和响应日志分析，判断是中国香港IDC到中国香港公共WIFI的汇接口带宽窄、时延大，此时该如何应对。

从前面探讨的TCP/IP网络知识，可以知道，在一个窄带宽高时延网络中，吞吐量BDP必然很小，也就是说单位大小的数据传输所需的时间会很长。如果按照通常一次下发一个逻辑分页timeline数据的策略，那么从服务器到客户端传输，整个数据需要拆分成多个TCP数据报文，在缓慢的传输过程中，可能一个数据报文还未传输完成，客户端的链路就已经超时了。

如果在弱网络（需要在应用层有测速机制，类似TCP/IP的RTT机制，测速时机可以是拉取微博消息数字时）下，把逻辑分页的微博消息数由30调整为5会如何，如果方案成立，用户刷微博的体验是不是会下降，因为滑动一屏就要做一次网络交互，即便是配合预加载，也可能因为网络太慢，操控太快而又见菊花。外团在中国香港实测了这个版本，感叹，终于可以刷了。

在饥渴难耐和美酒佳肴之间，似乎还有很多不同层级的体验。聊胜于无，这个词很精准的表述了服务分层，降级取舍的重要性。思考的要点是：

1) 产品的核心体验是什么，即用户最在乎的是什么，在做宏观分层设计时要充分保障核心体验；

2) 每个产品交互界面中，什么数据是无法容忍短时间不一致的，即什么是用户不能容忍的错误，在做微观分层设计时要充分考虑正确性；

3) 在宏观和微观分层的基础上，开始设想在什么条件下，可以有什么样的降级取舍，来保障可用，保障爽快的体验；

4) 分层不宜太多太细，大部分产品和场景，3层足矣；

在移动弱网络条件下，处处可见降级取舍的案例。比如网络条件不佳时，降低拉取缩略图的规格，甚至干脆不自动拉取缩略图等等，分层由心，降级有意。

④　【端和云孰轻孰重】

移动APP时代，绝对的轻端重云或者轻云重端都是不可取的，只有端云有机的配合，才能在一个受限的网络通道上做出更好的用户体验。正所谓东家之子，胖瘦有致。

比如移动网游APP，如取向选择轻端重云，那么玩家的战斗计算就会大量的通过网络递交给服务器处理并返回，卡顿家常便饭，操控感尽失。

比如微博客户端，如果取向选择重端轻云，微博timeline所有的消息都拉取元数据（比如微博正文包括文字、各类URL、话题、标签、@、消息的父子关系、消息中用户profile、关系链等等），由客户端实时计算拼装，不但客户端用户需要消耗大量流量计算量，而且给后端服务器带来巨大的带宽成本和计算压力，如果过程中网络状况不佳，还会非常卡顿。

通过实践总结，端和云孰轻孰重，取舍的关键是在数据计算规模可控和数据安全有保障的前提下：

1) 减少网络往复，要快；

2) 减少网络流量，要轻；

端云有机结合，可以很好的演绎机制与策略分离的设计思想，从而使系统具备足够的柔韧性。

不得不再次特别提到的一点是，缓存技术是异步化的基础，它渗透在性能和体验提升的方方面面，从持久化的DB、文件，到短周期的内存数据结构，从业务逻辑数据，到TCP/IP协议栈，它无所不在。缓存涉及到数据结构组织和算法效能（耗时、命中率、内存使用率等）、持久化和启动加载、更新、淘汰、清理方案等，有机会我们可以展开做专题的介绍。牢记一个字，缓存是让用户爽到极致的利器，但千万别留下垃圾。

提倡多异步，实际上是要求团队认真审视产品的核心能力是什么，深入思考和发现什么是用户最关心的核心体验，把有限的资源聚焦在它们身上。通过考察用户使用产品时的心理模型，体验和还原用户使用场景，用追求完美的精神探索不完美之道。

互联网服务核心价值观之一“不要我等”，在移动互联网时代仍应奉为圭臬，如何面对新的挑战，需要更多的学习、思考、实践和总结，这篇文章即是对过去实践的总结，亦作为面对未来挑战的思考基点。

老子曰过：上士闻道，勤而行之；中士闻道，若存若亡；下士闻道，大笑之。不笑不足以为道。求求你了，笑一个。

知易行难，故知行合一似（jiu）为扯蛋，那么我们就且扯且珍惜吧。