我们都知道，无论是网页还是移动应用，响应速度都是最重要的体验指标之一，而移动应用的网络环境是不稳定的，所以速度体验尤为重要。其实速度优化不仅仅是程序员的事，还能让App更快。
一、软件的后台执行
这是一个非常常见且容易理解的方法。用户不想盯着进度条等，除了“取消”别无选择。当系统处理一些网络任务时，它可以允许用户做其他事情。各大平台的微博都是后台执行。云阅读的离线下载也是在后台进行的。
而微博的长图(或视频)就是反例。当网络较弱时，要么等待1分钟加载图形，要么放弃图形。为什么在加载图形的同时用户不能看其他微博？
其次，可以在加载之前显示内容
客户端和web的一个区别是客户端的显示内容包括本地数据和网络数据。在设计界面时，更多的信息放在本地，网络数据没有加载时显示本地数据，给用户的感觉是加载了一半。即使最后的时间一样，心理感受也会更快。当然，在本地写太多数据会牺牲一些灵活性，需要根据具体情况考虑。一些优秀产品的启动图片虽然是静态图片，但却假装没有使用LOGO就加载到了“导航条”和“标题栏”，让人感觉“点击后立即启动”。
第三，充分利用缓存
缓存可以将网络数据存储在本地，下次打开时不需要再次请求网络，减少了流量和等待时间。设计上可以先显示缓存内容，后台从网络拉新内容。如果有新的内容，可以立即更换或在下次访问时更换。但是在使用缓存的时候要注意“度”。太大的缓存文件占用太多系统空间，会让用户一怒之下卸载App。
第四，界面可以继续
对于一些数据量小、失败概率低的网络交互，用户不需要清楚地知道App在做什么，可以流畅地使用App，所以要“掩盖一些事实”，即在界面上乖乖地快速完成任务(心智模型)，在程序后台继续默默执行任务(实现模型)。最常用的聊天界面是QQ、微信、电子邮件。点击发送后，消息立即“飞入”聊天上下文，但对方尚未收到。但这种设计使得沟通过程更加顺畅，没有“发送——发送成功”各种流程的干扰。用户在收集文章、关注好友等操作时，数据量很小，界面可以进行下去。在用户继续浏览文章的同时，系统会很好的收集文章。经常使用的另一种类似于这种思路的方法是:在没有网络的情况下，用户进行操作(比如写评论和笔记等)。)，本地保存用户输入，有网络再上传。让用户有连贯的体验。
V .预测用户行为，提前开始任务
不知道你有没有使用淘宝的习惯。在搜索结果列表中，将所有感兴趣的结果作为新标签页打开，然后逐一查看，不感兴趣的关闭。这样做的好处是我在浏览产品详情页面的时候，每个页面都是完全加载的，否则我会点击一个页面看到一个，每个页面都要等待加载，效率会大大降低。那么可以设计成满足类似的使用场景吗？应该可以预测用户的行为，提前启动任务。
策略类似这样：用户在某个界面停留的时候，预测下一步可能做ABC三个任务，系统于是把这些任务都提前做完。当用户做出选择比如A时，界面可以迅速响应，并且同时把BC两个任务从内存中清空掉以节省资源。(当然这招也有限制：1，只适用于免费的网络。2，预加载不能影响系统的性能)我们就回来看淘宝的iPad客户端。它有这样的设计，在某详情页查看时，向右一划可以查看下一个商品，也许这是一个好设计，但是却没有帮我预加载下一个界面，我还是不得不傻傻地等页面加载完。
然后我们再来看一些其他的设计。比如网易云阅读，我们认为用户进入一个信息源最大的可能性之一就是刷新和查看新内容。因此，即使没有打开自动刷新选项，也会制作源列表，在后台自动加载新内容，并在刷新按钮上显示“新建”。此时，当用户再次刷新时，内容立即呈现。比如我们的Android更新提醒在安装包自动下载后提示，让用户不再需要等待下载过程。再比如查看云读大图，自动加载下一张；当到达底部时，TableView将自动加载，等等。如果下载前问是否保存，可以在用户决定的时候开始下载，节省了很多时间。如果用户放弃，下载的内容会自动删除。所以，用这个思路。插入微博后可以自动上传照片，而不是等用户点击“发送”吗？当你看一个微博，定位一个微博，应该自动加载大图还是大视频？音乐应用是否应该在当前歌曲快结束的时候下载下一首歌，这样在剪辑歌曲的时候就不会卡一会儿了？
VI .使用动态效果覆盖加载过程
优秀的动态设计，让产品更好用，让人眼前一亮。其实动态效果还有一个很大的用处，就是吸引用户的注意力，把等待载入的枯燥过程变成一个愉悦欣赏的过程。
2021-04-09 09:50:26分类：APP开发
阅读()
