用户在使用网页或 APP的过程中，大多会遇到加载场景。加载对用户来说是一种反馈，是用户触发、系统反应的过程。在一个产品中可能会涉及到多种形式的加载场景，例如进场加载、页面间的转场加载以及局部功能的加载等。
在这些场景下，加载设计需要让用户知道系统正在处理什么、哪些内容已经可用，以及等待失败后如何继续。
选择加载方式时，把等待前、等待中和失败后的页面一起放进在线原型设计工具中走查，才能看出哪些内容应保留、用户何时可以继续操作。
五种加载模式
网页的加载速度是评估网站质量一个重要指标。等待过长可能打断阅读或操作，因此需要同时关注实际耗时与等待反馈。下面讨论的是加载过程的交互呈现。它们可以帮助用户理解等待和继续操作，但不会自动降低接口耗时；真实性能问题仍需结合资源体积、请求和渲染测量来处理。
1. 全屏加载
全屏加载是在关键内容尚未就绪时，对当前主要区域展示等待反馈；不必先清空成白屏，也不一定使用进度条。例如列表页进入详情页、图片详情等。可以保留页面标题和必要的返回入口，让用户知道正在打开什么。动画应服务于状态表达，不应成为延迟展示已就绪内容的理由。
优点：能保证内容的整体性，关键内容就绪后统一展示，减少依赖数据不完整时的误操作。
缺点：有非常强烈的等待感，弱网或请求迟迟不结束时，单一转圈无法说明系统是否仍在工作，需要补充可理解的提示与重试入口。
2. 优先加载
如果一个页面有图片有文字，可以先把文字都加载出来，保证用户可以有内容可读，然后再加载比较费流量的图片。但是活动页千万不能把重要信息全部放在图片上，导致加载不出来。这种加载形式更加适用于内容阅读型的APP。
优点：可以帮助用户快速阅读内容，了解信息。
缺点：也许会丢失掉重要的关键信息，无法建立信息获取的闭环。
3. 整页加载
在当前页与下一页是整页切换的时候，可以考虑采用整页加载的形式，但是要保证每个页面的数据量不是特别的大。一般适用于宫格图片模式、全屏图片模式、网状详情页模式。
优点：能保证每个页面的完整性，体验比较整体。
缺点：不好保证整页的加载效率，且有可能影响浏览的流畅度。
4. 下拉刷新加载
页面首次载入后，还可能需要更新已有内容；在支持相应手势的移动页面中，下拉刷新是一种常见方式。下拉刷新已经在APP中被普遍应用，保证了用户既可以看到本地的内容，也可以选择主动下拉对当前内容进行更新。加载的样式也可以做出进一步的设计，例如运用产品形象作为刷新的样式，能加深用户对品牌的认知。
优点：保留现有内容并由用户主动更新，不必离开当前页面。下拉刷新更新已有列表，与滚动到底部继续加载下一批内容不是同一操作。
缺点：用户一定要在页面顶部下拉才有刷新效果，不然下拉手势通常会先触发当前内容区域的滚动。
5. 离线加载
当用户没网的时候，往往很多功能都不能用了，内容也无法加载出来，导致APP变得根本不可用，这时候就要考虑预加载离线缓存的设计了。首先在有网的时候把数据提前加载下来，缓存到本地，当没网的时候，直接加载已经缓存下来的内容。
一般会提供给用户选择，是否开启有WiFi的情况下预加载功能，或者是否开启WiFi下的离线缓存功能。这样便可在一定程度上减少地铁上信号时好时差而无法正常使用产品所带来的困扰了。但考虑到手机空间，要设计合适的离线机制，并配合一定的清理缓存的机制。这种加载方式适用于小说阅读、新闻阅读、视频类APP。
优点：让已缓存内容在无网时仍可访问，并减少重复下载；未缓存或需要联网确认的内容仍不可用。
缺点：占用本地存储空间，而且有时候预加载的内容根本没有用到。
先判断等什么，再选择如何展示
上面的五种模式并非互斥选项。一份阅读列表可以首次分批显示文字和封面，回到列表时保留缓存，再通过下拉刷新获取新内容。真正需要先确定的是：这次等待会阻断整个任务，还是只影响某个局部？有没有上一份仍可用的数据？后端能否提供可信的完成进度？
例如进入文章详情时，正文已就绪但插图仍在加载，应该先让人阅读正文，并为图片保留尺寸。若为了等一张非关键插图而继续遮住整个页面，就把局部等待扩大成了全屏阻塞。相反，用户提交预约后，确认结果尚未返回，则不能先显示“预约成功”来制造速度感。
能确定进度，才显示百分比
“已上传 3 个，共 5 个”和“正在验证文件”表达的是不同阶段。前者有明确总量，可以展示可信的阶段进度；后者若没有可测量的总工作量，就用状态文字说明正在处理。不要把定时增长到 99% 的动画当成真实进度，也不要在进度条到达终点后仍让用户无提示地等待下一阶段。
骨架屏、刷新提示和空结果需要区分
骨架屏适合内容结构大致已知、尚无数据可展示的首次进入状态；已有内容正在更新时，通常可以继续保留旧列表，并在局部显示刷新状态。接口成功返回零条结果，应结束加载并解释空结果；请求失败则要说明失败，不应把错误伪装成“暂无内容”。有关加载组件的使用边界，可参阅 Carbon 的 Loading 使用说明。
把阅读列表的等待和恢复连成完整路径
可以用一份“设计收藏”阅读列表演练：首次打开显示与卡片布局对应的占位；内容返回后进入正常列表；用户下拉时保留当前卡片并显示更新提示；更新失败时显示“暂时无法更新，已保留上次内容”，提供重试。离线打开时明确告知内容来自已下载数据，而不是让旧内容看起来像刚刚同步。
重试不应让人反复回到同一个无解释的等待状态。设计时为失败提示保留足够空间，说明重试针对哪一部分；如果用户已经离开这个页面，迟到的加载结果不应把他拉回原处。缓存内容还需要清理入口、占用说明和过期处理，不能把离线缓存当作永远准确的最新数据。
在 Pixso 中复制同一列表画板，分别设计首次载入、更新中、失败后保留旧内容和离线阅读四个状态，再用交互连线表达重试与返回。评审时逐一指出“哪些内容还能操作、哪里显示等待、失败后能做什么”，让研发拿到的不只是一张加载动画。
Pixso总结
在深入了解加载的状态和模式后，可以让我们在设计和交互中改善那些使用不合理的加载，从而提升产品的舒适度，也可以利用加载来做更多的交互设计，让加载变得更有趣味性，减少用户因等待产生的焦虑感，提升用户的体验感。
当然，要想做出好的加载设计，还需要参考大量优质的加载设计案例。建议你打开Pixso社区资源，里面有很多优质的APP加载设计案例，绝对能给你带来更多的加载设计灵感！
