場景1:等待，同時從服務器請求新數據。我們向用戶展示什麽？第壹個是等待加載的漂亮頁面；第二個是緩存的內容。對於第二種，用戶可以壹邊操作頁面，壹邊查看舊數據，等待新數據，更具“可操作性”和“可用性”，從而減少從服務器獲取數據的大小和時間，提升用戶體驗。另壹方面，如果內容更新的間隔時間長，或者用戶刷新的間隔時間短，我們會從服務器重復獲取大量數據而不緩存，增加了成本。
場景二:結果是沒有互聯網連接，或者地鐵上網絡太差無法加載數據的時候，給用戶留壹個空白頁真的很不負責任。而且很多功能在不聯網的情況下也是可以使用的，比如:APP裏的通訊錄，查看壹些聊天記錄，通知信息，文章列表等等。因為用戶打開APP不用看新信息，可能會回頭看舊信息(可能有壹些舊信息用戶沒看過)，所以適當的緩存可以滿足更多的用戶場景。
場景三:錢有壹天，壹個用戶發現自己安裝了壹個APP，流量用的非常快。Ta可能會把這個APP永遠打入冷宮，增加緩存是節省流量的壹種方式。雖然節省的不多或者用戶沒有意識到，但是作為壹個有態度的產品經理，妳要多做思考。
2.什麽是緩存？
緩存可以分為以下幾類:
(1)應用緩存。
(2)固定緩存。
(3)可以手動清理的緩存。
(4)無法手動清理的緩存。
(5)臨時緩存。
其中，在壹個功能頁中經常使用臨時緩存來保存各列的緩存。在同壹個函數中，子函數會被分成多列，在這次使用中每個tab列下的內容都可以保存為臨時緩存。在這個函數中，在不重新加載數據的情況下切換列，並使用緩存顯示。
對於用戶來說，瀏覽可以在使用過程中無縫切換，而對於服務器來說，數據很少在短時間內更新，所以總體上可以滿足用戶的正常需求，實現優秀的體驗。
臨時緩存的清理機制是在退出本功能模塊後，清除之前的緩存。也就是說，下次進入這個功能模塊，需要重新獲取數據。
我們經常使用臨時緩存，因為信息真的沒有那麽重要，不需要反復檢查。對於我們經常用到的，需要反復檢查的信息，馬建議我們取壹個固定的緩存，保存在本地，下次瀏覽的時候就不需要再向服務器請求數據了。
對於固定緩存，將細分為手動可清理緩存和手動不可清理緩存。
第壹種是我們最常見的緩存，幾乎所有產品都采用。通常用戶瀏覽文章和圖集加載的數據都是以這種形式緩存在本地，下次回看這篇文章和圖集時就不需要加載了。用戶也可以手動清除這些緩存以釋放空間。
對於壹些特殊的場景，比如壹些相對固定的數據，我們不想壹開始就把它打包到App裏，那樣會占用太多的容量，造成產品包很大，也不想每次進入頁面都把這些信息加載到服務器上。我們做什麽呢建議的解決方案是，我們可以加載壹次，永久保存在本地，這樣安裝包就不會很大，以後就不需要加載了。
3.如何清理緩存？
壹般壹個App都會在設置裏提供清除緩存的功能，壹鍵釋放空間。另外，App最好設計壹個自動清理機制，可以通過兩個維度來設計。
(1)，時間
通過設置固定時間或者根據用戶的使用周期靈活設置時間來清空緩存。每個產品的場景不壹樣，用戶的使用頻率也不壹樣。在設置這個機制的時候，需要結合實際情況來考慮。
(2)容量
壹般設置壹個容量限制，采用堆棧的設計原理來清空緩存，溢出堆棧的舊數據會自動清除。
1，頁面加載
方案1:單頁整體加載
這種加載比較簡單，壹般用在頁面內容比較簡單的情況下，直接壹次加載完所有數據後再顯示內容。單頁加載失敗的狀態相對容易處理。
方案2:單頁塊加載
這種方案的特點是可以讓用戶壹步步看到內容，在這個漸進的過程中減少自己的焦慮。
其中，可以分為:如果模塊之間有關聯，先加載父內容，再加載子內容。如優酷，先加載欄目，再加載各欄目內容。
如果模塊之間沒有絕對的相關性，那麽每個模塊的內容都可以獨立加載，並根據請求速度的不同分別顯示。這個過程有壹定幾率讓用戶在不完全刷出數據的情況下找到自己需要的功能，比如大眾點評、淘寶客戶端。
如果框架是固定的，內容是更新的，可以先顯示框架，再分別加載顯示各個模塊的數據，比如各種iOS apps。
這種模塊加載需要特別註意加載失敗狀態。畢竟每個模塊都提示加載失敗，點擊重試是壹件很沮喪的事情。可以根據信息的優先級決定哪些數據失敗采用默認狀態，哪些數據采用失敗提示。
場景3:跨頁加載
父頁面&；子頁面或者同壹個app內，頁面之間的字段可以重用，加載子頁面時不需要重新加載新數據。
方案4:預壓
這種加載方式的特點是在加載壹個頁面內容的同時，預測用戶的下壹步行為，為他下壹步需要使用的頁面加載內容，讓他在下壹次操作中就能立即獲取信息，而不需要等待加載。
預裝為用戶提供了無縫的產品體驗，讓用戶在使用產品的過程中更加直接流暢，沒有被打斷的感覺。
具體例子有:
瀏覽圖集時，看到第壹張圖片，後臺會自動加載第二張、第三張、第四張圖片，用戶在瀏覽完第壹張圖片後切換到第二張圖片時，不會有等待的過程。
瀏覽新聞列表時，每條新聞的內容都是在後臺預加載的。當用戶選擇觀看新聞時，他們可以立即閱讀內容。
但是，這個方案也需要面對很多問題。馬向海認為最直接的問題是流量，因為它會自動跑走很多用戶可能根本用不到的數據流量。所以壹般來說，馬建議可以在wifi環境下設置這種加載模式。或者設置加載規則，只有主要內容可以預加載，壹些次要內容只有在用戶真正使用的時候才能加載。比如在預加載新聞文字的情況下，只能加載文字信息，只有用戶進入內頁才能加載圖片信息。這種預加載和塊加載的組合也廣泛應用於各種場景。
此外，預加載需要時間。只是不在客戶端展現給用戶，而是在後臺默默操作。當用戶使用加載前的信息時需要特別考慮，所以在設計預加載時需要同時考慮另壹種適合這種情況的常用加載方式。
預加載需要根據具體場景進行設計，設置信息優先級，綜合考慮各類信息的具體大小和流量，整體考慮預加載的方式，這些都需要仔細分析和思考。
隨著網絡環境的發展，預加載將成為未來產品加載的常用方式，其為用戶提供的無縫體驗大大提高了產品的可用性。
2.操作負載
除了需要加載頁面的信息之外，還需要通過向服務器發送請求來記錄頁面中的操作。
方案1:荷載層
壹次操作後，彈出模態提示層，通知用戶正在加載。模態提示主要用於防止用戶在過程中做其他操作，導致當前加載錯誤。由於模態提示以及由於網絡原因可能長時間處於加載狀態，建議提供“關閉”操作來暫停本次加載，恢復App可用狀態。當加載失敗時，可以在當前浮動層上轉化為失敗提示。模態提示層是最安全的方式，但是會讓用戶在使用過程中有被打斷的感覺。
場景2:控件本身的加載狀態
這種方法結合了操作加載的狀態和控制的風格。操作控件後，控件會更改為已加載狀態，此時控件無法重復該操作。由於這種加載方式是控件自身的狀態，不影響其他操作，所以用戶也可以在頁面上執行其他操作，這可能會導致同時出現多個請求，增加加載失敗的風險。這也是這種模式的壹個缺點，但是這種極端情況很少出現。請求失敗後，可以用Toast提示通知用戶失敗的原因。
方案3:後臺加載
用戶操作後，客戶端立即反饋操作成功，然後將請求放在後臺與服務器交互。這個過程不需要用戶理解，也不需要等待。壹般情況下，驗證是很好的。
但是在極端情況下，會出現壹些莫名其妙的情況。因為請求是在後臺記錄的，是和服務器交互的，實際請求是否成功，客戶端沒有說明，全部顯示為操作成功，會導致用戶誤以為操作成功，其實下次並不成功。
所以這種加載方式需要根據具體的使用場景來權衡。對於壹些重要的操作，建議使用模態加載。對於壹些小操作，比如點贊、訂閱、關註，可以使用後臺加載。
3.加載下壹頁或當前加載。
用戶進入首頁，正式邁出體驗的第壹步。下壹步是根據用戶的目標在界面之間跳轉。完成界面跳轉的加載策略有很多種，但不管是什麽形式，我們都可以把它們分為“下壹頁加載”和“當前頁加載”兩類。
(1)“下壹頁加載”滿足用戶提前窺視的需求。
我們把頁面看成壹個“點”，頁面流量就是連接這些點的壹條“線”。我們在“用戶想買壹條牛仔褲”的場景下做壹個簡單的眼動研究。從應用啟動到商品瀏覽，再到商品確認最後進入下壹頁，用戶呈現的瞳孔階梯是遞增的，即E & gtD & gtC & gtB& gt；a、為了解釋這種現象，通過與被試的交流，我們發現用戶更期待看到自己想看的東西，而不是瀏覽。所以此時的“下壹頁加載”恰到好處，滿足了用戶提前窺視的需求。
(2)等等！我需要思考思考
同理，我們也研究了“用支付寶給手機充值”的場景。從初次支付到第二次確認支付，用戶呈現的瞳孔比較大，即A和B大致相等。通過訪談發現，與“增量體驗流”不同的是，當用戶遇到判斷邏輯的界面時，用戶並不急於看到下壹頁包含什麽，而是不為0，即1的驗證心態。所以在判斷邏輯界面中，用戶對內容偷窺的需求並不強烈，當然也沒有內容，要麽只是壹個小小的吐司，要麽就是壹個簡單的信息反饋界面(這裏的意思是“下壹頁加載”是雞肋)。相反，用戶對非0即1的驗證需求強烈，在等待結果的過程中伴隨著緊張和興奮。所以通過當前頁面加載界面，說明系統在嘗試處理用戶給出的指令，讓用戶感到緊張和興奮，直到出現結果——“處理成功”，完成非0的滿足，即1驗證。
4.先加載還是先顯示
需要加載功能時，可以在加載前顯示，需要加載內容時，則相反。
淘寶網
打開APP的第壹頁是函數，所以先展示再加載:
只需點擊壹個模塊(不要點擊菜單)，下面會顯示內容(商品)，所以先加載後顯示，加載後才顯示:
京東
類似地，加載前會顯示功能模塊:
先加載內容，完成後再展示:
這兩種方法各有優缺點:
首先顯示，然後加載:
優點:給用戶等待0的錯覺。
缺點:目前的數據可能是錯誤的，直到用戶操作的最後壹步才會發現。
首先加載，然後顯示:
優點:保證數據的質量和準確性。
缺點:網絡不好的時候會造成等待。
很明顯，功能模塊對於壹個產品來說是固定的，短時間內幾乎不會更新，所以這個數據出錯或者與當前狀態不同的概率要小很多。所以可以采用先秀後裝的方式。
另壹方面，內容(尤其是商品數據)是最容易發生變化的。為了保證每壹個消費者看到的數據都是最真實最準確的，在展示之前必須加載。
1，空白頁刷新失敗，有提示。
現在的應用都標榜以內容為中心，所以會盡量避免空白頁。對於大多數應用程序，最好的方法是使用緩存。進入頁面後，先顯示之前的緩存，再刷新內容。其次，消除空白頁的第二種方法是提供系統推薦來替換它們。但對於某些頁面來說，頁面內容與用戶的使用狀態息息相關，出現空白頁在所難免。這時候就會用壹些導課的小技巧來豐富頁面，促進用戶產生內容。
但是有些資訊類應用，比如看日報，默認打開壹個空白頁然後加載內容(這個設置我不太懂)。其他應用，如豆瓣時刻、MONO，每天剛進入應用時也會有空白頁。我猜第二類應用的呈現原因是這樣的。他們的內容* *嚴格以天為單位，每天固定時間選取內容。他們會希望妳每天只看當天的東西，所以壹旦第二天，昨天的內容就繁瑣了。所以每天第壹次進入應用的時候，都會有壹個空白頁，象征著每天都是壹個全新的開始。此時會出現“空白刷新”邏輯。
空白刷新對應的場景是這樣的:用戶想刷新內容，用戶知道這裏可以刷新新的內容，但是刷新不成功。這時候就需要給用戶壹個交代了。所以妳需要提示用戶。同時，在提示用戶之後，我們需要給用戶壹個解決方案，就是“點擊再試”。
2.在沒有提示的情況下，緩存頁面刷新失敗。
常見的應用，如知乎、網易新聞、好奇心日報、微信朋友圈等。，都采取緩存的形式。打開後會顯示緩存的內容，然後系統會向服務器發送請求。如果有內容更新，內容會自動更新壹次，更新的內容會直接覆蓋當前內容。更新失敗後沒有提示。不過也有壹些應用，比如有道詞典，企鵝FM，網易雲音樂等。，更新失敗後會有提示。
我認為這兩個應用程序的區別在於
應用頻率；
內容的時間連續性；
接口之間的緊密性。
比如網易新聞，作為消磨時間的工具，每天都會被頻繁使用，所以用戶進來後想看看有沒有更新。其次，網易新聞的內容是持續更新的，所以用戶會知道當前顯示的內容是我看過並處理過的。最後，新聞列表頁面顯示壹個摘要，用戶可以通過摘要快速判斷是否進入詳情頁，幫助用戶回憶上壹次的使用場景。
所以這對應了壹個場景:用戶只是想看看有沒有更新，所以已經做好了“沒有新內容”的心理預期，所以即使更新不了內容，用戶也不會想太多。相反，如果給出錯誤提示，用戶可能會感到沮喪。因為他知道現在有內容了，但是因為網絡的原因沒有更新，他想進行的任務受到了外界因素的阻礙，產生了壹種微妙的挫敗感。
3.提示緩存頁面刷新失敗。
另壹類應用，使用頻率沒那麽高，或者內容不具備時間連續性，或者當前界面無法喚起用戶最後的使用場景。那麽就有必要給出妳失敗的第壹個暗示。
比如企鵝FM，註定使用頻率較低，因為通過視覺接收的信息會比通過聽覺接收的更快、更多，同時音頻類對環境的要求更高(比如使用耳機時環境沒有那麽嘈雜，在外面玩要求在私密的地方)。其次，這類應用是實時推薦的，不存在時間連續性的問題，用戶無法判斷內容是否已經按時間閱讀。而且題目也不能幫妳快速判斷，還是要進去聽，才知道內容是什麽。最後，如果不提醒用戶，當妳進入詳情頁收到提醒時，妳會覺得應用浪費了用戶的時間。所以對於這類內容，需要提醒妳刷新失敗。