1、緩存機制緩存
一、爲何要加緩存？服務器
場景一：【等待】，在向服務器請求新的數據時。咱們讓用戶看到什麼？第一種是漂亮的等待加載頁面；第二種是緩存的內容。對於第二種，用戶能夠對頁面進行操做，等待新數據時能夠查看舊數據，更具備「可操做性」與「可用性」，從而減輕了從服務器獲取數據這一動做的大小和時間長短，加強了用戶體驗。另外一方面，若是內容更新的間隔較長或者用戶刷新的間隔較短，在沒有緩存的狀況下，不少數據咱們會屢次重複的向服務器獲取，增長了成本。微信
場景二：【結果】沒有聯網，或者在地鐵上網絡太差沒法加載數據時，若是留給用戶一個空白頁面，實在是感受有點不負責任啊。而且不少功能在沒有聯網的狀況下也有使用的可能性，好比：APP中的通信錄，查看一些聊天記錄，通知信息，文章列表等。由於用戶打開APP不必定是要看新信息，說不定是回顧老信息（或許老信息裏也有用戶以前沒看的），因此恰當的緩存能夠知足更多的用戶場景。網絡
場景三：【金錢】有一天，一個用戶發現本身裝了某個APP後流量用的特別快，Ta可能永遠將這個APP打入冷宮了，而增長緩存正是節省流量的一個方法。雖然節省的很少或者用戶也察覺不到，可是做爲一個有態度的產品經理，應該多作一些思考。app
二、什麼是緩存？框架
緩存可分爲以下幾類：工具
（1）app緩存。設計
（2）固定緩存。圖片
（3）可手動清理的緩存。支付寶
（4）不可手動清理的緩存。
（5）臨時緩存。
其中，臨時緩存經常使用於一個功能頁面內，保存各欄目的緩存。同一個功能裏會把子功能分爲多個欄目進行劃分，每一個標籤欄目下的內容在本次使用中均可保存爲臨時緩存，在該功能裏切換欄目，不須要從新加載數據，使用緩存顯示。
對於用戶來講，使用時達到了無縫切換瀏覽，對於服務器來講，在短期內數據不多會有更新，因此在通常狀況下能知足用戶的正常需求，並達到體驗優秀。
臨時緩存的清理機制是：退出該功能模塊就清除以前的緩存。也就是說下次進入該功能模塊，須要從新獲取一次數據。
不少時候咱們都會用到臨時緩存，由於那些信息真的不是那麼重要，並且不須要常常反覆查看，那對於那些咱們常用並且常常須要反覆查看的信息，馬海祥建議採起固定緩存，保存在本地，方便下次翻閱時不須要再一次向服務器請求數據了。
對於固定緩存又會細分爲可手動清理的緩存和不可手動清理的緩存。
第一種是咱們最多見的緩存，幾乎全部產品都採用這種緩存方式。平時用戶瀏覽文章、圖集加載的數據就以這種形式緩存在本地，下次看回這篇文章、圖集時就不須要加載了。用戶也能夠手動把這些緩存清理了，釋放空間。
而對於某些特殊場景，例如一些相對固定的數據，咱們不肯意一開始就打包進App裏，這樣會佔太大容量，形成產品包很大，也不肯意每次進入頁面都向服務器加載這些信息，那怎麼辦？建議的解決方法就是咱們能夠只加載一次就永遠存在本地了，這樣安裝包也不會大，之後也不用加載了。
三、如何清理緩存？
通常App都會在「設置」裏提供一個清理緩存的功能，一鍵把空間釋放。除此以外，App最好要設計自動清理機制，能夠經過兩個維度來設計這個機制。
（1）、時間
經過設定一個固定的時間，或者根據用戶使用週期靈活設定時間來清理緩存。每一個產品的場景不一，用戶使用頻率不一，設定這個機制的時候就須要結合實際狀況考慮了。
（2）、容量
通常是設定一個容量上限，採用堆棧的設計原理進行緩存清理，溢出堆棧的舊數據將自動清除。
2、加載機制
一、頁面加載
方案1：單頁面總體加載
這種加載比較簡單，通常運用在頁面內容比較單一的狀況下，因此直接一次性加載完全部數據後再顯示內容。其單頁面加載失敗的狀態相對來講也比較好處理。
方案2：單頁面分塊加載
這種方案的特色是，能讓用戶逐步看到內容，在這個漸進的過程當中下降用戶的焦慮心理。
其中又能夠分爲，模塊間有關聯性的，先加載父內容，再加載子內容。如優酷，先把欄目加載出來，再加載各欄目的內容。
模塊間沒有絕對關聯性的，可獨自加載各自模塊內容，根據請求的速度不一樣分別顯示。這樣處理有必定概率讓用戶在沒徹底刷出數據的狀況下就能找到本身須要的功能，如大衆點評、淘寶客戶端等。
框架固定，內容更新的，可先把框架顯示出來，再把各模塊的數據各自加載顯示，如各類iOS自帶應用。
這種分模塊加載的須要特別注意加載失敗的狀態，畢竟每一個模塊都提示加載失敗，點擊重試是很挫的一件事，能夠根據信息的優先級來決定哪些數據失敗了採用默認狀態，哪些數據採用失敗提示。
方案3：跨頁面加載
父頁面&子頁面 or 同一app內，頁面間字段能夠複用的，在加載子頁面時不須要從新加載新數據。
方案4：預加載
這種加載方式的特色是，在加載一個頁面內容的同時，預測用戶的下一步行爲，併爲他下一步須要使用的頁面加載內容，使得他在下一步的操做中能馬上獲取信息而不須要加載等待。
預加載提供給用戶無縫的產品使用體驗，使得用戶在使用產品的過程當中更直接流暢，沒有被打斷的感受。
具體的例子有：
在瀏覽圖集的時候，當看到第一張的圖片時，就自動後臺加載第二第三第四張圖片，用戶瀏覽完第一張圖片切換到第二張時就不會有加載等待的過程。
在瀏覽新聞列表時，就把每篇新聞的內容在後臺進行預加載，用戶選擇看某篇新聞時，能馬上閱讀到內容。
可是這種方案也須要面臨不少的問題，馬海祥以爲最直接的就是流量問題，由於會自動跑掉不少用戶可能根本用不上的數據流量，因此，通常狀況下馬海祥建議能夠設定在wifi環境才採用這種加載模式。又或者設定加載規則，只把主要內容預加載，而部分次要內容能夠在用戶真的用到的時候才加載，例如預加載新聞正文的狀況，能夠只加載文本信息，圖片信息等到用戶進入內頁才加載。這種預加載與分塊加載結合的方式也廣泛運用在各個場景。
另外，預加載也須要時間的，他只是不在客戶端顯示給用戶，默默在後臺運做而已，須要特殊考慮未加載完用戶就使用到那些信息的狀況，因此在作預加載設計時須要同時考慮另外一種適合該狀況的普通加載方式。
預加載須要根據具體的場景來進行設計，設定好信息優先級，綜合考慮各類類型信息的具體大小流量，總體考慮預加載的方式，這些都是須要通過精心分析思考的。
隨着網絡環境的發展，預加載將成爲之後產品廣泛的加載方式，他提供給用戶的無縫使用體驗大大地提高了產品的可用性。
二、操做加載
除了頁面的信息須要加載，頁面內的操做也是須要經過給服務器發送請求記錄的。
方案1：加載層
進行一個操做後，彈出模態的提示層，告知用戶正在加載。採用模態的提示主要是防止用戶在該過程當中進行其餘操做，致使當前加載出錯。因爲採用模態的提示，而且有可能由於網絡緣由致使長時間處於加載狀態，建議提供一個「關閉」的操做，停止本次加載，恢復App可用狀態。加載失敗時可在當前浮層變換爲失敗提示。模態提示層是最穩妥的方式，但他會使用戶在使用過程當中有打斷的感受。
方案2：控件自身加載狀態
這種方式是把操做加載的狀態與控件的樣式結合起來了，對某個控件進行操做後，控件變換爲加載狀態，此時控件不能重複操做。因爲這種加載方式是控件的自身狀態，不影響其餘操做，因此用戶也能夠對頁面進行其餘操做，可能會致使同時有多個請求的狀況，增長了加載失敗的風險，這也算是這種方式的弊端，不過這種極端狀況不多出現。請求失敗後，可配合Toast提示告知用戶失敗的緣由。
方案3：後臺加載
用戶在操做後，客戶端馬上反饋操做成功，而後把請求放到後臺與服務器交互，這一過程用戶不須要了解，不須要等待，在正常狀況下體驗是很是棒的。
可是在極端狀況下會出現一些莫名其妙的情況，因爲是後臺記錄請求並與服務器交互，因此實際請求是否成功客戶端是不說明的，所有以操做成功來顯示，這就會致使用戶誤覺得操做成功了，但實際上下次來看發現沒有成功。
因此，這種加載方式是須要根據具體使用場景來權衡使用的，對於一些重要的操做，建議仍是使用模態的方式加載，對於一些小操做，如點贊、訂閱、關注，可採用後臺加載的方式。
三、下一頁加載仍是當前也加載
用戶進入首頁，正式邁出體驗的第一步，接下來迎接的就是基於用戶目標的界面間跳轉。完成界面的跳轉，會有各類加載策略，但不管形式如何，咱們均可以將其歸爲兩大類：「下一頁加載」、「當前頁加載」。
（1）「下一頁加載」知足了用戶提早窺視的需求
咱們把頁面當作「點」，頁面流是鏈接這些點的「線」，咱們以「用戶想買一條牛仔褲」這一場景做爲案例作了簡單的眼動研究，從應用啓動到商品瀏覽再到商品肯定最後進入下單頁，用戶所呈現的瞳孔梯次增大，即E>D>C>B>A，爲了解釋這一現象，經過與被試交流，咱們發現相比於各類瀏覽，用戶更期待看到他們想看到的東西。所以此時的」下一頁加載「正好，知足了用戶提早窺視的需求。
（2） Wait！I Need Think Think
咱們以一樣的方式又對「使用支付寶對手機充值」這一場景作了研究，從開始支付到二次確認支付，用戶所呈現的瞳孔都比較大，即A與B近似相等，經過訪談，咱們發現與「遞增體驗流」不一樣的是，當用戶遇到判斷邏輯的界面時，用戶並不是急於想看下一頁面到底包含怎樣的內容，而是非0即1的驗證心態，即個人操做效成功了嗎？所以在判斷邏輯界面中，用戶的內容窺視需求並不強，固然也沒什麼內容，要麼僅是一個小小的Toast，再大一點就是一個簡單的信息反饋界面（意味着「下一頁加載」在這裏就是個雞肋），用戶反而對非0即1的驗證需求較爲強烈，其中還伴隨着等待結果過程當中的緊張感、激動感，所以界面經過當前頁加載代表系統正在努力地處理用戶交代的指令迎合了用戶的緊張感、激動感，直到結果顯現——「處理成功」，完成了非0即1驗證的知足感。
四、先加載仍是先展現
當需加載的是功能時，能夠先展現再加載，當需加載的是內容時，則反過來。
淘寶
打開APP的第一個頁面是功能，因此先展現再加載的：
隨便點擊一個模塊（不要點菜單），下面要展現的將要是內容（商品），因此是先加載再展現的，沒有加載完都不展現：
京東
一樣的，功能模塊先展現後加載：
內容先加載，沒加載完不展現：
兩種方式各有利弊：
先展現，後加載：
優勢：給用戶0等待的錯覺
缺點：當前數據有多是錯的，並且得等用戶操做到最後一步纔會發現
先加載，後展現：
優勢：保證數據的質量和準確
缺點：網絡很差時，形成等待
顯然，功能模塊對於一個產品來講是既有固定的，在短期內幾乎不會更新，因此這種數據出現錯誤或與當前狀態不一樣的概率小得多，所以，可使用先展現後加載的方式。
另外一方面，內容（特別是商品數據）是最容易產生變更的，爲了保證每個消費者看到的數據都是最真實，最準確的，因此務必要先加載再展現。
3、刷新機制
一、空白頁面刷新失敗有提示
如今的應用都標榜之內容爲中心，因此都會極力避免空白頁面的出現。對於大部分的應用，最好的方法就是使用緩存，進入頁面以後，先顯示以前的緩存，而後再進行內容的刷新。其次，消滅空白頁面的第二種方法就是提供系統推薦項進行替代。可是對於一些頁面，頁面內容跟用戶的使用狀態關係密切，沒法避免會出現空白頁面，這時候會使用一些引導類的提示，使得頁面變得更加豐富，同時能夠促進用戶產生內容。
可是一些資訊類應用，好比讀讀日報，打開默認是空白頁面，而後再加載內容（我不是很明白這種設定）。其餘一些應用，好比：豆瓣一刻和MONO，天天第一次進入應用的時候也會出現空白頁面。我猜測第二類應用的展現方式的緣由是這樣的。他們的內容推送都是嚴格以天爲單位的，天天固定時段推送精選內容。他們會但願你天天只看而且看完當天的東西，因此一旦到了次日，昨天的內容就是累贅了。因此天天第一次進入應用的時候會出現空白頁面，象徵着天天都是重新開始。此時就會對應一個「空白刷新」邏輯。
空白刷新對應的場景是這樣子的：用戶想要刷新出內容，而且用戶知道這裏能夠刷出新內容，可是沒有刷新成功，這時候須要給用戶一個交待。因此須要提示用戶。同時，提示完用戶以後須要給用戶一個解決方法，這就是「點擊後重試」。
二、緩存頁面刷新失敗無提示
常見的應用好比知乎、網易新聞、好奇心日報、微信朋友圈等，這些應用都會採用緩存的形式，打開以後顯示的是緩存內容，而後系統會給服務器發送請求，若是有內容更新的話就會自動更新一次內容，更新以後的內容直接覆蓋當前的內容。更新失敗以後是沒有提示的。可是有一些應用，好比有道詞典、企鵝FM、網易雲音樂等，他們更新失敗以後是有提示的。
我以爲這兩種應用的區分點在於
-
應用的使用頻率；
-
內容的時間連續性；
-
界面之間的關係緊密度。
好比說網易新聞，做爲一個打發時間的工具，天天使用頻率就會比較高，因此用戶進來以後是想看看有沒有更新。其次，網易新聞的內容是接二連三更新的，因此用戶會知道當前顯示的內容是我看看過而且處理過的。最後，新聞列表頁面顯示的是摘要，用戶能夠經過摘要快速進行判斷是否要進入詳情頁，摘要有助於幫助用戶回憶上一次的使用場景。
因此這就對應着一個這樣的場景：用戶只是想看看有沒有更新，因此他們已經作好了「沒有新內容」的心理預期，因此即便是更新不了內容，用戶也不會想太多。反卻是，若是進行了錯誤提示，用戶可能會有一種挫敗感。由於他知道如今有內容，只是由於網絡的緣由而沒有更新，他要進行的任務受到了外界因素的阻礙，由此產生一種細微的挫敗感。
三、緩存頁面刷新失敗有提示
另外一類應用，使用頻率沒那麼高，或者內容不具有時間連續性的，又或者說當前界面沒法喚起用戶上一次的使用場景。那麼就有必要進行率先你失敗提示了。
好比說企鵝FM，音頻類的應用註定使用不會那麼頻繁，由於經過視覺接收的信息會比經過聽覺接收的信息更快更多，同時音頻類對環境的要求較高（好比用耳機時要求環境不那麼嘈雜，外放時要求在私人場所）。其次，此類應用都是實時推薦的，不存在時間連續性的問題，用戶沒法經過時間來判斷內容是否被閱讀過。再者，標題也沒法幫你快速作出判斷，你仍是要進去聽過才知道內容是什麼。最後若是不提醒，用戶進入到詳情頁再收到提醒，就會以爲應用浪費了用戶的時間。因此，對於此類內容，刷新失敗是有必要進行提醒的。