优化|客户端加载耗时优化方案（上）加载|客户端|优化|耗时|方案

编辑导语：我们经常能碰到客户端加载耗时的情况，那么应该如何优化解决这种问题，提升用户体验感呢？本文作者总结了刷新加载loading的三个阶段，在本篇文章中，主要是针对第一阶段，为我们阐述了优化方案。

文章插图
任何一件事情的发生可能背后有很多种原因，要解决好一个问题，都要明确造成这个问题的原因是什么，然后针对这些原因进行优化。
在刷新加载loading的过程，经历了三个阶段：

客户端触发顶部刷新；
服务器收到请求后准备要下发的数据；
客户端收到服务器数据进行展示。

本文针对第一阶段:“客户端触发顶部刷新”聊一聊怎么减少耗时问题（下一篇文章会针对另外两个阶段阐述优化方案）。

文章插图
01交互层面：使用占位策略缓解用户焦虑app某个界面一直空白，或者界面一直在转loading，在这样的过程中，用户任何信息都获取不到，会让用户产生等待焦虑。
1）动画策略
动画策略是一个比较常用的策略，比如可以使用新颖的加载动画来代替老式的loading菊花样式，用户在看动画的过程中加载就已经结束了，以此降低用户预期的等待时长。
但新颖的动画不一定适用所有App，不恰当的使用新颖的加载动画甚至会加重某些用户的等待焦虑，造成用户流失。所以当你决定要采用动画策略时，不妨采用A/B Test的方式进行测试，看看新动画是否真的有降低等待焦虑的作用。
2）历史内容策略
历史内容占位是目前主流App最常用的策略，除了用户首次登陆App没有历史信息外，其余每次登陆都会先使用历史内容来进行占位，以此来减少页面空白加载给用户带来的焦虑。
02技术层面：预拉取预拉取的基本操作
预拉取，也即提前拉取，在用户真正触发向后台拉取内容的网络请求之前，就已经准备好数据，等到用户真正开始拉取时，直接把上次提前拉取好的数据返回给用户，这种操作甚至可以让用户体会到瞬间拉取的效果。

文章插图
图1- 常规拉取流程

文章插图
图2-预拉取流程
如上图所示，预拉取的最关键的问题在于：何时触发预拉取？
用户自然希望每次拉取时，客户端都把数据拉取好，这样每次都可以体会到瞬间拉取的效果。那么最直接的方法就是：在一切用户未进行网络请求的时刻，一直向后台请求最新的数据。
但从用户流量，服务器所能接受的并发请求上限来看，上面这种策略不仅会浪费用户流量，甚至在用户数量多的情况下会把服务器搞挂掉，这就得不偿失了。
我们不妨换个思路，如果我们是用户，我们在什么情况下对拉取内容耗时要求最高？
那自然是我们对内容最迫切的时候，比如：
下面我们针对”红点预拉取”和”首次预拉取”讨论下具体的产品方案。
03红点预拉取在介绍红点预拉取之前，我们先明确下红点本身的定位，红点大致可以被分为两种类型：

消息型红点：比如朋友圈和视频号的红点，会在你的朋友有输出型行为（点赞、发表、评论等）时给予你通知，这种红点强调实时性，需要具有过期和撤回的能力；
功能型红点：不强调实时性，一般在给用户介绍新功能时起引导的作用，只有当你手动点击时这种红点才会消失，这种红点基本不需要具备过期和撤回的能力。

因为我们需要通过预拉取来获取新的内容，遂下面讨论的主要是”消息型红点”。
红点在app中无处不在，以朋友圈举例，当我在发现页收到一个”同事A的头像+小红点”类型的红点，这时在我点进朋友圈之前，我内心的预期自然是想看同事A 点赞了什么内容。
在我点进朋友圈如果加载的loading时间过长，我的预期就没有被满足。
那么用红点预拉取怎么做呢？
当我收到”同事A的头像+小红点”类型的红点（红点中要带上”同事A刚发的那条内容背后的id”）时，客户端立马通过这个id去服务器请求内容数据，客户端收到内容数据中先存在缓存里。
当我真正点进朋友圈触发顶部刷新时，这时直接把我已经从服务器拉取到数据进行展示。这样的一个流程可以被称为”红点预拉取”。

文章插图
但是，红点预拉取就这么简单吗？非也非也。