D.A：我们都知道，无论是网页还是手机应用，响应速度都是最重要的体验指标之一，而手机应用的网络环境不稳定，速度经验似乎特别重要。事实上，速度优化不仅仅是程序员的事情，设计也可以让应用程序更快。1.后台执行这是一种很常见也很容易理解的方法。用户不会愿意盯着进度条傻等，除了“取消”别无选择。当系统在处理一些网络任务时，完全可以让用户做其他事情。各大平台发微博均在后台执行。云阅读的离线下载也是在后台进行的。而微博的长图（或视频）就是一个反例。网络不强的时候，要么等1分钟图片加载完毕，要么放弃看图。为什么在加载图片时用户无法查看其他微博？2.加载前显示内容客户端和web的一个区别，客户端显示的内容包括两部分：本地数据和网络数据。在设计界面的时候，把更多的信息放在本地，在没有加载网络数据的时候显示本地的数据，这样用户会有一种“加载了一半”的错觉，即使最终耗时一样，心理感受它也会更快。当然，在本地写太多数据会牺牲一些灵活性，这个需要根据具体情况来考虑。具体可以参考twitter、facebook、vine等优秀产品的启动画面，虽然还是静态图片，但没有使用LOGO，而是假装加载了“导航栏”和“标题栏”，让人有种“点击即启动”的感觉。再比如AppStore的详情页。在加载详细信息之前，首先显示现有信息。3.充分利用缓存。缓存可以将网络数据保存在本地，下次打开时无需再次请求网络，减少流量和等待时间。设计时，可以先展示缓存的内容，同时在后台从网络拉取新的内容。如果有新内容，将立即或在下次访问时更换。但是缓存的使用也要讲究“度”。过大的缓存文件会占用过多的系统空间，导致用户一气之下卸载应用。云阅读的“书城”、“微博找朋友”等界面都采用了缓存机制来提高页面打开速度。4.界面在前，网络交互在后。对于一些数据量小、失败概率低的网络交互，用户不需要清楚地知道是App在做这些事情，就可以流畅地使用App。那么我们就应该“把一些事实掩盖起来”，即界面乖乖地快速完成任务（心智模型），程序继续在后台默默地执行任务（实现模型）。最常用的就是QQ、微信、易信等聊天界面。点击发送后，消息立马“飞”到聊天上下文中，但对方还没有收到。但是这样的设计让通信过程更加顺畅，没有了“发送-发送成功”的各种过程的干扰。用户收藏文章、关注好友等数据量小的时候，可以优先使用接口。在用户继续浏览文章的同时，系统会为该文章添加书签。另一种类似这种思路的方法也经常被使用：在没有网络的时候，用户进行操作（比如写评论，写笔记等），将用户输入的内容保存到本地，有网络的时候再上传。让用户有连贯的体验。5.预测用户行为，提前启动任务。不知道大家有没有这样的淘宝习惯。在搜索结果列表中，将所有你感兴趣的结果作为新标签打开，然后一一查看。如果您不感兴趣，请关闭它们。这样做的好处是，我在浏览商品详情页的时候，每一页都是满载的，不然我点开一个看一个，每一个都要等加载完成，会大大降低效率。那么能否设计成满足类似的使用场景呢？应该是可以的，也就是预测用户的行为，提前开始任务。策略类似这样：当用户停留在某个界面时，预测他下一步可能会做ABC的三个任务，系统提前完成这些任务。当用户做出A等选择时，界面可以快速响应，同时从内存中清除BC的两个任务，节省资源。（当然，这一招也有局限性：1.只适用于免费网络。2.预加载不会影响系统性能。）我们再回到淘宝的iPad客户端。它有这样一个设计，在查看某个详情页时，向右滑动可以查看下一个商品，也许这是一个很好的设计，但它并没有帮我预加载下一个界面，我还得傻傻地等待页面加载.然后让我们看看其他一些设计。在网易云阅读，我们认为用户进入信息源的首要原因之一可能是刷新以查看新内容。所以即使没有开启自动刷新选项，源列表也会在后台自动加载新的内容，刷新按钮上会显示“NEW”。这时，当用户再次刷新时，内容会立即呈现出来。安装包自动下载后安卓更新提醒提示，让用户不再需要等待下载过程。再比如云阅的大图查看，自动加载下一张；TableView在快到底部时自动加载等，Chrome在下载前询问是否保存，在用户决定之前下载已经开始，节省了大量时间。如果用户放弃，下载的内容将自动删??除。所以，使用这个想法。微博插入照片后，是否可以不等用户点击“发送”再上传，自动上传？浏览微博时定位到某个微博，是不是应该自动加载大图或视频？当音乐app快要播放完当前歌曲时，是否应该下载下一首歌曲，以免切歌时卡住一会？6.使用动态效果覆盖加载过程。出色的动态设计使产品更加实用和引人注目。事实上，运动效果还有另一个大用途。吸引了用户的眼球，将枯燥的等待加载过程变成了享受的欣赏过程。以下例子来自网络。原文链接：http://uedc.163.com/11291.html
