au加載預設的輸入和輸出裝置失敗_網絡異常，加載走查

你如果已經在做設計，肯定會遇到這種情況：在開設計評審會的時候，開發或者QA總能找到設計方案中遺漏的點。出現這種問題的原因并不是因為缺少知識，而是因為有時候要考慮的情況太多，難免會遇到遺漏的情況。而建立一個适合自身産品的互動走查表，會盡可能的減少遺漏的情況。

經過前面幾篇“特殊情況下的APP設計”相關文章的介紹，已經把在APP設計中，和主業務不太相關的特殊情況下的APP設計點介紹的差不多，還沒看過的小夥伴，可以系統地看一遍，希望能對你有用。今天，就用互動走查表的形式，對這個系列的文章進行一個總結。

互動走查表

1. 網絡異常

頁面有緩存資料時

頁面有緩存資料時要考慮兩種情況：

1. 網絡環境切換時（從WIFI到蜂窩資料；從蜂窩資料到WIFI），解決方案是“暫停播放并dialog提示”。
2. 網絡異常時，解決方案有兩種，一是Toast提示；二是常駐list提示。

頁面無緩存資料時

這種情況下，要有點選頁面重新加載的功能，有些APP是提供重新加載的button，有些是點選空白頁面任意區域都會觸發重新加載，另外，還有很多APP會提供前往設定WIFI的入口。

2. 預設頁面

有頁面架構時

顯示頁面架構+占位符；

無頁面架構時

盡量采用情感化設計，同時可以引導使用者去看推薦内容。

3. 加載重新整理

頁面有緩存資料時

（1）設計加載loading；

（2）考慮加載失敗的情況，加載失敗可分為網絡原因和其他原因。一般會采用Toast提示。

頁面無緩存資料時

（1）設計加載loading；

（2）考慮加載失敗的情況，加載失敗可分為網絡原因和其他原因。一般會進行情感化設計。

下拉重新整理

設計下拉重新整理動畫，每次重新整理可以給予Toast回報，例如豆瓣首頁，每次重新整理都會提示更新了多少條；如果目前内容已經是最新，可以提示使用者已經是最新内容。

分段加載

因為用戶端不可能一次性加載全部内容，得進行分段加載，規定每次加載多少條，像今日頭條APP，我沒記錯的話應該是每次會加載60條資料。

分布加載

考慮分布加載，先加載文字，後加載圖檔，如果頁面有架構，會最先出現頁面架構，再顯示文字和圖檔。由于加載圖檔時間稍長，是以在加載圖檔過程中會用一個預設的占位符來填充圖檔位置。

異步加載

為了減少使用者等待時間，可以考慮需不需要采用異步加載。

智能加載

根據産品自身的特性，考慮是否分網絡環境來加載不同内容。例如知乎APP，在設定中可以選擇蜂窩環境下隻加載文字不加載圖檔，幫助使用者節約流量。

4. 其他情況

1. 是否支援遊客模式
2. APP啟動頁面的設計
3. token失效時
4. 伺服器異常時

不同産品根據自身的特點，需要走查的點是不一樣的，例如：涉及多媒體播放和下載下傳的産品，才需要考慮網絡環境切換時的情況；必須強制登入的産品就不需要考慮遊客模式的設計，等等。

《清單革命》這本書将人類所犯的錯分為兩類，一類是無知之錯；另一類是無能之錯。無知之錯是因為缺少相關的知識所犯的錯誤，而無能之錯并非因為沒有掌握正确的知識，而是因為沒有正确的使用這些知識。而互動走查表（清單）的建立，會減少我們犯無能之錯的機率。