读后总结（第7篇 - 加载问题）
加载是以一种合适的方式告诉用户正在发生什么，将会发生什么，减少用户的等待感。
用户输入信息，信息要从客户端先到服务器（这里的加载特指页面中没有缓存数据，完全从服务器加载内容），一系列计算完成以后，才会从服务器返回到客户端，在屏幕上做出更新，所以用户的许多动作都会发生加载的状态，而不同场景下加载的样式也不相同，下面来举例说明。
------------------------------------------------------
1.开屏加载
2.内容页加载
3.界面内加载
4.不同网络环境下的自适应加载
5.指示器
------------------------------------------------------
1.开屏加载
启动页的出现就是为了给用户营造一个好的第一印象，其次产品启动需要一个过程，而“启动页加载”可以实现这一过程的一个过渡，在给予用户一个响应的同时预加载部分首页内容，使得用户不至于看到空白的页面，体验上更趋流畅。
2.内容页加载
2.1）如列表页进入详情页，图片详情等。如果页面内容单一，采取全页面加载，页面会处于空白，这个时候需要一个加载动画来显示状态，让用户保持耐心。
2.2）如列表页进入详情页，图片详情等。如果页面元素比较多，但框架比较固定，可以采取分块加载的方式，先把框架先加载出来，再加载文字，默认图片，图片以减弱用户的等待感。
facebook的灰色占位图就是一个很好的例子。他在加载内容时使用模板元素并且使用户对于内容将要加载出来的全局架构更加熟悉。
注意：数据是先加载还是先展示？
当用户打开你的app，你希望把数据展示给他，还任由他在上面操作，还是等数据加载好了，再给他呢？
两种方式各有利弊：
先展示，后加载：
优点：给用户0等待的错觉
缺点：当前数据有可能是错的，而内容（特别是商品数据）是最容易产生变动的，为了保证每一个消费者看到的数据都是最真实，最准确的，所以务必要先加载再展示。
先加载，后展示：
优点：保证数据的质量和准确
缺点：网络不好时，造成等待
什么时候先加载，什么时候先展示，来看看淘宝是怎么处理的。
功能模块对于一个产品来说是既有固定的，在短时间内几乎不会更新，所以这种数据出现错误或与当前状态不同的几率小得多，因此，可以使用先展示后加载的方式。
内容（特别是商品数据）是最容易产生变动的，为了保证每一个消费者看到的数据都是最真实（毕竟，比起等待，用户更讨厌被骗），最准确的，所以务必要先加载再展示。
2.3）预先加载，这种在新闻列表页面比较常见的一种加载方法，预判用户会点击的列表项，在用户点击前就加载页面内容；或者在一些功能使用流程中（如阅读中的预先加载下一页），预判用户操作流程提前一步。
优点：这种加载方式给予用户无缝的使用体验，使得用户在使用产品过程中更直接流程，没有被打断的感觉。
缺点：这种加载方式容易消耗不必要的流量。
要结合网络情况和加载内容进行综合考虑，可以只加载文字信息或关键信息。
3.界面内加载
3.1）模态提示层，app在触发后加载，出现模态提示层，防止用户在加载过程中进行其他操作，导致当前加载出错。如果采用模态加载，肯会因为网络原因或内容过多导致长时间处于加载状态，建议提供一个“取消”的操作，同时在安卓中的后退按钮能关闭模态提示。（有些APP可以点击标题栏的返回，相当于“取消”提交的加载内容）
模态提示层加载缺点：使用户处在被动等待中。所以慎用，常常用于像支付之类的比较重要的场景。其他情况可考虑“控件自身加载”。
3.2）控件自身加载，把操作加载的状态与控件的样式结合起来，对某个控件进行操作后，控件变为加载状态，此时控件不能重复操作，当加载完毕后，控件再作为显示加载结果的状态。通过按钮状态的变化直接呈现加载进度，是对操作状态的延续，避免了浮层带来的干扰和阻断感。比如说appstore软件的更新/获取/下载/打开按钮，登录按钮，音频软件中常见的下载按钮。这种加载方式是控件的自身状态，不影响其他操作，所以用户也可以对页面进行操作，因此也会导致同时有多个请求的情况，增加了加载失败的风险，请求失败后可配合提示告知用户失败的原因。
控件自身加载的优点：用户不用像“模态加载”那样再去看霸占整个屏幕的进度条或其他无关信息，使得操作体验更简洁流畅。
3.3）标题栏加载，这个在微信里面比较常见，以标题栏的形式展现加载状态，如刚进入的连接中，对方正在输入等。将导航栏标题临时变为加载信息，在用户与产品互动过程中提供实时反馈。
3.4）后台加载，用户在操作后，app立即反馈操作成功，然后把加载过程放到后台，用户不需要了解也不需要等待，例如微信里面的点赞。但因为后台操作，可能有时候明明显示成功，但其实失败，所以一些比较重要的操作不太适合用这种方式来呈现。
另一个后台加载的例子：
3.5）界面内刷新，下拉刷新，上拉加载更多已经为广大用户所接受。
看看微信逆天下之大不违把小视频放在聊天窗口的下拉里，导致网上骂声一片，最近在最新的版本里有偷偷改掉。有些用户习惯，可以被挑战，有些不能~
最好别挑战习惯，除非你的设计根本改变了问题 ！
4.不同网络环境下的自适应加载
4.1）根据网络环境自适应加载。在不同的网络情况下（wifi或使用数据流量），智能判断是否下载图片，图片质量等，并且在网络情况发生变化时提醒用户变化情况。
4.2）根据移动网络自适应加载。从4G到E，为了避免用户过长的等待，我们可以采用分布加载策略，“E状态”先加载占用网络资源少的内容，例如框架、文字、默认图案，再通过手动触发，加载占用网络资源多的内容，这样可以让用户更快速地看到界面框架内容。虽然体验上较4G模式会大打折扣，但我们至少维系了E状态下的可用性。
4.3）离线访问（也叫缓存），移动场景带来的网络情况的多样性，有时候用户没有网络（网络覆盖），或者关闭网络（流量限制）。可以缓存一部分数据来进行离线访问，这样在断网情况下也能使用，并能访问已有的数据。缓存的优点：
减少访问时间：在向服务器请求新的数据时。我们让用户看到什么？第一种是漂亮的等待加载页面；第二种是缓存的内容。对于第二种，用户可以对页面进行操作，等待新数据时可以查看旧数据，更具有“可操作性”与“可用性”，从而减轻了从服务器获取数据这一动作的大小和时间长短，增强了用户体验。另一方面，如果内容更新的间隔较长或者用户刷新的间隔较短，在没有缓存的情况下，很多数据我们会多次重复的向服务器获取，增加了成本。
展示更多内容：没有联网，或者在地铁上网络太差无法加载数据时，如果留给用户一个空白页面，实在是感觉有点不负责任。并且很多功能在没有联网的情况下也有使用的可能性，比如：APP中的通讯录，查看一些聊天记录，通知信息，文章列表等。因为用户打开APP不一定是要看新信息，说不定是回顾老信息，所以恰当的缓存可以满足更多的用户场景。
减少流量的消耗：有一天，一个用户发现自己装了某个APP后流量用的特别快，Ta可能永远将这个APP打入冷宫了，而增加缓存正是节省流量的一个方法。虽然节省的不多或者用户也察觉不到，但是作为一个有态度的产品经理，应该多做一些思考。
注意：考虑到手机空间，要设计合适的离线机制，并配合一定的清理缓存的机制。
5.指示器
5.1）无限循环指示器
如果正在执行的处理影响范围较大，可以使用模态的无限循环指示器。
如果只是界面的一部分，可以采用小尺寸的提示信息。
如果显示时间较长，建议改用进度条来提示用户当前的执行进度以及还需要等待多少时间，这样能减少用户的焦躁感。同时让用户可以取消这个状态，或执行其他操作。
ios和安卓默认加载指示器如下。
5.2）进度条
浏览器的进度条是一种较为常见的进度告知设计，通过这个进度告知，让用户有了更加明确的知情权，也能更好的预期到加载完成的时间。但即便是小小的进度条，也有很多的设计技巧在里面。
一个非常经典的体验设问，同样是3s的加载时间，匀速的进度条、先慢后快的进度条、先快后慢的进度条，哪个让用户感觉上最快?经过科学的实验证实，先慢后快的进度条是让用户心理感受上最快的设计。这是因为用户最容易记住最后一瞬间的感觉，如果最后一瞬间，感知到了快，就觉得顺畅了。
5.3）自定义动画
界面的每一个加载都会涉及到等待，有时受到网络的限制，可能需要等待更久，但是用户等不起，普通用户能够忍受的最长的加载页面时间一般为8秒，如果加载时间超过8秒，除非用户必须在这个页面获得一些信息，一般用户会关闭页面或转到其他页面。面对着千篇一律直接采用系统提供的旋转式loading，等待会显得更加焦躁。我们可以通过自己的专业将“情感化”融入加载设计中，自定义动画现在是比较常见的指示器方式，加入与品牌相关的元素，增加趣味性，使用户不再感到无聊，时间也会感觉过得快一点。
参考原文链接：APP加载框架，关于数据：先加载还是先展示？