我們都知道不管網頁還是移動應用，響應速度都是最重要的體驗指標之一，並且移動應用的網路環境不穩定，速度的體驗顯得尤為重要。其實速度優化不僅是程式設計師的事，設計，也能夠讓APP變得更快。

1.後臺執行
這是一條很通用，也容易理解的方法。使用者不會願意盯著進度條傻傻地等待，除了“取消”沒有其他選擇。在系統處理一些網路任務的時候，完全可以允許使用者做一些其他的事情。各大平臺的發微博，都採用了後臺執行。雲閱讀的離線下載也採用後臺執行。
 
而微博的看長圖(或視訊)，是個反例。網路不給力時，要麼等待1分鐘讓圖載入完，要不就只好放棄看圖。為什麼不能讓圖載入的同時，使用者可以看其他微博呢？
2.在載入前顯示內容
客戶端與web的一個不同點，客戶端的顯示內容包括本地資料和網路資料兩部分。在設計介面時，將更多的資訊放在本地，在網路資料未載入時即顯示本地資料，讓使用者產生一種“已經載入一半了”的錯覺，即使最終的耗時一樣，心理感受也會更快。當然把資料過多地寫在本地，會犧牲一些靈活性，需要根據具體情況考慮。
具體請看twitter、Facebook、Vine等優秀產品的啟動畫面，雖然同是靜態圖片，但它們不使用LOGO而假裝已經載入了“導航欄”和“標題欄”，讓人感覺“點選後立即就啟動了”。
再如App Store的詳情頁，在詳細資訊載入前，已有資訊先顯示。
3.充分利用好快取
快取可以把網路資料儲存在本地，下次開啟時無需要再次向網路請求，減少流量並減少等待時間。在設計時，可以先顯示快取內容，同時後臺到網路上拉取新內容，若有新內容立即替換或下次訪問時替換。但快取使用也要注意“度”，過大的快取檔案佔用太多的系統空間，會讓使用者一怒之下解除安裝APP。
雲閱讀的“書城”和“通過微博找好友”等介面，都使用了快取機制，提高開啟頁面的速度。
4.介面先行，網路互動隨後
對於一些資料量很小，且失敗可能性較小的網路互動，使用者並不需要明確知道APP在幹這些事情，也能夠順暢地使用APP，那麼我們就應該“把一些事實掩蓋起來”，即介面上聽話地、迅速地完成任務(心智模型)，程式後臺默默地繼續執行任務(實現模型)。
最常用的比如QQ、微信、易信等聊天介面。點選傳送後，訊息立即”飛”到聊天上下文中，其實對方還沒收到。但這樣的設計讓溝通的過程更順暢，沒有“正在傳送 – 傳送成功”各種過程的干擾。
使用者在收藏文章，關注好友等操作時，資料量很小，可以介面先行。使用者在繼續瀏覽文章的同時，系統會把文章收藏好。
與此思路相仿的另一種方法也常被用到：在無網路條件下，使用者進行操作(比如寫評論，寫備註等)，把使用者的輸入內容儲存在本地，等到有網路時再上傳。讓使用者有連貫的體驗。
5.預測使用者行為，提前開始任務
不知道大家使用淘寶有沒有這樣的習慣，在搜尋結果列表，將所有感興趣的結果都開啟為新標籤頁，然後一個個地看，沒興趣的就關閉。這樣做的好處是，在我瀏覽商品詳情頁的時候，每個頁面都是載入完全了，否則我點開一個看一個，每個都要等待載入完，就會大大降低效率。
那麼能否通過設計，來滿足類似使用場景呢？應該是可以的，那就是預測使用者的行為，提前開始任務。
策略類似這樣：
使用者在某個介面停留的時候，預測下一步可能做ABC三個任務，系統於是把這些任務都提前做完。當使用者做出選擇比如A時，介面可以迅速響應，並且同時把BC兩個任務從記憶體中清空掉以節省資源。(當然這招也有限制：1，只適用於免費的網路。2，預載入不能影響系統的效能)
我們就回來看淘寶的iPad客戶端。它有這樣的設計，在某詳情頁檢視時，向右一劃可以檢視下一個商品，也許這是一個好設計，但是卻沒有幫我預載入下一個介面，我還是不得不傻傻地等頁面載入完。
那我們看一些其他的設計
在網易雲閱讀，我們認為使用者進入一個資訊源的一個最大可能就是重新整理檢視新內容。所以即使沒有開啟自動重新整理選項時，進行源列表，後臺自動載入新內容，並在重新整理按鈕上顯示“NEW”，此時當使用者再重新整理，內容立即呈現。
 Android更新提醒在安裝包自動下載完成之後提示，讓使用者不再需要等待下載過程。
再比如雲閱讀的檢視大圖，自動載入下一張;TableView在將要達到底部時自動載入等。
Chrome在下載前詢問是否儲存，在使用者決定之就已經開始下載，節省了不少時間。如果使用者放棄，已下載內容會自動刪除。
那麼，用這個思路
寫微博插入照片後，能否自動上傳，而不必等使用者點選了“傳送”才上傳？
看微博時定位到某條微博，是否應該自動載入大圖或視訊？
音樂應用在當前歌曲快播放完時，是否應該下載下一首歌，以免切歌的時候會卡一會兒？
6.使用動效來掩護載入過程
優秀的動效設計，讓產品更好用且讓人眼前一亮。其實，動效還有另一大用處，吸引使用者的注意，讓本來枯燥的等待載入的過程，變成愉悅欣賞的過程。
以下兩個例子來源於網路
自：網易uedc