加载机制

通常情况下，我们使用的绝大部分是网络App，他的工作原理是这样的：

用户在客户端的界面上进行操作，客户端发送请求到服务器，服务器处理请求，返回数据给客户端，并显示给用户。

其中，客户端和服务器的交互过程，用户是感知不到的，而他确实会耗费时间，在不同的网络环境下耗费的时间也会有所差异，如何让用户在这段时间里有友好的体验呢？这时候“加载过程”起了作用。

加载过程的关键可以总结为：

1.让用户感知产品正在努力为他运作。

2.让用户有基本的心理预期需要等待的时间长短。

3.让用户在无聊的等待中获得更多乐趣。

进度条是一个针对加载过程很好的设计。

动态的加载进度表示产品正在工作，总进度和当前进度能让用户及时了解情况，让用户能根据这些信息预判时间，有了心理预期。

有趣的进度条设计or在加载过程中展示一些功能介绍提示（常用于游戏）能有效减少用户等待时的焦躁心理，也能有效地提高用户的容忍度。

进度条是web产品时代的产物，还有另外一种加载设计，就是加载图标。由于移动产品请求的数据量并不大，所以进度条往往会在一瞬间就完成了，在这种情境下，简化了加载的设计，很多移动产品转而使用加载图标来表示加载过程。

以上为两种比较常用的加载方式，下面将具体介绍他们与移动产品结合的用法：

页面加载机制

移动产品的信息都是通过页面来承载的，页面的加载方案设计是交互设计师面临的一个重要难题。

方案一：单页面整体加载

这种加载比较简单，一般运用在页面内容比较单一的情况下，所以直接一次性加载完所有数据后再显示内容。单页面加载失败的状态也比较好处理。

/

方案二：单页面分块加载

这种方案的特点是，能让用户逐步看到内容，在这个渐进的过程中降低用户的焦虑心理。其中又可以分为，模块间有关联性的，先加载父内容，再加载子内容，如优酷，先把栏目加载出来，再加载各栏目的内容。

模块间没有绝对关联性的，可独自加载各自模块内容，根据请求的速度不同分别显示。这样处理有一定几率让用户在没完全刷出数据的情况下就能找到自己需要的功能，如大众点评、淘宝客户端。

框架固定，内容更新的，可先把框架显示出来，再把各模块的数据各自加载显示，如各种iOS自带应用，云音乐。

这种分模块加载的需要特别注意加载失败的状态，毕竟每个模块都提示加载失败，点击重试是很挫的一件事，可以根据信息的优先级来决定哪些数据失败了采用默认状态，哪些数据采用失败提示。

方案三：跨页面加载

父页面&子页面 or 同一app内，页面间字段可以复用的，在加载子页面时不需要重新加载新数据。

/

方案四：预加载

这种加载方式的特点是，在加载一个页面内容的同时，预测用户的下一步行为，并为他下一步需要使用的页面加载内容，使得他在下一步的操作中能立刻获取信息而不需要加载等待。

预加载提供给用户无缝的产品使用体验，使得用户在使用产品的过程中更直接流畅，没有被打断的感觉。

具体的例子有：

在浏览图集的时候，当看到第一张的图片时，就自动后台加载第二第三第四张图片，用户浏览完第一张图片切换到第二张时就不会有加载等待的过程。

在浏览新闻列表时，就把每篇新闻的内容在后台进行预加载，用户选择看某篇新闻时，能立刻阅读到内容。

但是这种方案需要面临很多的问题，最直接的是流量问题，因为会自动跑掉很多用户可能根本用不上的数据流量，所以一般情况下可以设定在wifi环境才 采用这种加载模式。又或者设定加载规则，只把主要内容预加载，而部分次要内容可以在用户真的用到的时候才加载，例如预加载新闻正文的情况，可以只加载文本 信息，图片信息等到用户进入内页才加载。这种预加载与分块加载结合的方式也普遍运用在各个场景。

另外，预加载也需要时间的，他只是不在客户端显示给用户，默默在后台运作而已，需要特殊考虑未加载完用户就使用到那些信息的情况，所以在做预加载设计时需要同时考虑另一种适合该情况的普通加载方式。

预加载需要根据具体的场景来进行设计，设定好信息优先级，综合考虑各种类型信息的具体大小流量，整体考虑预加载的方式，这些都是需要经过精心分析思考的。随着网络环境的发展，预加载将成为以后产品普遍的加载方式，他提供给用户的无缝使用体验大大地提升了产品的可用性。

操作加载机制

除了页面的信息需要加载，页面内的操作也是需要通过给服务器发送请求记录的。

方案一：加载层

进行一个操作后，弹出模态的提示层，告知用户正在加载。

采用模态的提示主要是防止用户在该过程中进行其他操作，导致当前加载出错。由于采用模态的提示，并且有可能因为网络原因导致长时间处于加载状态，建议提供一个“关闭”的操作，中止本次加载，恢复App可用状态。加载失败时可在当前浮层变换为失败提示。模态提示层是最稳妥的方式，但他会使用户在使用过程中有打断的感觉。

方案二：控件自身加载状态

这种方式是把操作加载的状态与控件的样式结合起来了，对某个控件进行操作后，控件变换为加载状态，此时控件不能重复操作。

由于这种加载方式是控件的自身状态，不影响其他操作，所以用户也可以对页面进行其他操作，可能会导致同时有多个请求的情况，增加了加载失败的风险，这也算是这种方式的弊端，不过这种极端情况很少出现。请求失败后，可配合Toast提示告知用户失败的原因。

/

方案三：后台加载

用户在操作后，客户端立刻反馈操作成功，然后把请求放到后台与服务器交互，这一过程用户不需要了解，不需要等待，在正常情况下体验是非常棒的。

但是在极端情况下会出现一些莫名其妙的状况，由于是后台记录请求并与服务器交互，所以实际请求是否成功客户端是不说明的，全部以操作成功来显示，这 就会导致用户误以为操作成功了，但实际上下次来看发现没有成功。所以这种加载方式是需要根据具体使用场景来权衡使用的，对于一些重要的操作，建议还是使用 模态的方式加载，对于一些小操作，如点赞、订阅、关注，可采用后台加载的方式。