网络故障设计总结

本文原创自news.mkq.online
版权声明：本文为原创文章，版权牛站科技所有
转载请注明http://www.niuzhan.com/keji/

当你正在用微信跟朋友胡侃，在b站看纪录片，逛虎扑怼skr。这时网络突然断掉，我们应该给用户什么样的提示呢？最近因为自己也在梳理类似的场景，所以这篇文章就来跟大家分享交流一下在网络故障场景下如何给予用户合适的提示。

所有的报错提示/反馈都可以拆解为两个部分：报错现象和解决方案。因此网络发生故障时我们首先应该告诉用户您当前的网络状态异常，让用户感知到这个事实，然后再提供解决方案。

目前来说，常见的报错样式有toast、snackbar、对话框、通告栏、界面内嵌与空页面。最近看了一下自己之前的文章，发现都是基于组件来阐述适用场景。这种解构方式有个问题，那就是现实情况中，产品或者交互设计师都是基于场景去确定合适的组件。因此为了更方便大家理解，这里我不具体介绍每个组件的用法，而是以场景来定义来组件。

不提示

首先我们需要明确一个事实：不是每一种网络故障都需要提示用户。这里的“不提示”其实是一个相对的说法，并不是真的不给用户提示，而是只有用户执行了请求数据的操作才告知用户网络发生故障。支付宝就是一个典型的例子，即使断网了，用户基本也感知不到。只有用户请求了新数据，才会以toast通知用户网络异常。

支付宝这种高冷也是有底气的，因为其多数页面都有缓存机制，用户不用每次进入这个页面都要去服务端请求一遍数据。类似的还有QQ音乐、咕咚，对于这些产品来说断网并不会带来灾难性的影响。因为断网不影响我去听缓存或下载好的歌曲，也不会影响记录运动数据。所以对于此类应用来说，当网络报错的时候，只要用户没有触发请求数据的操作，没有必要提示用户。

当然我们需要给缓存数据设置一个有效期，如果过了那个有效期，网络还是没有恢复正常，应该及时提示用户网络故障。

无缓存

当然并不是每一个页面都有缓存，对于没有缓存数据的页面，我们有两种方案。一种是展示空页面，另一种是展示骨架屏（Skeleton Screen）。

骨架屏顾名思义就是展示页面的框架，当数据请求完成时再渲染页面。这种先占好位置再加载数据的模式也被称之为占位符，都是一个意思。

最后再说空页面，其实空页面的展示方案也可以分为两种：

1 提供“刷新页面”按钮；

2 提供“解决方案”按钮；

两种方案都有自己的道理，我个人更倾向于把两种方案进行融合。展示“刷新页面”的按钮，如果用户点击了还是没有办法请求到数据，这时以snackbar的形式提供解决方案。其实解决方案都是引导用户去系统设置里检查/开通网络权限。