緩存刷新方式是什麼

『壹』 瀏覽器緩存及刷新

1、伺服器開啟Cache-Control緩存控制（優先順序更高）
（相對時間，在這個時間之前不會和伺服器通信，本地拿過來直接用）
Cache-Control:max-age=3600，這里是3600秒過期，過期前不會和伺服器通信，直接用本地緩存
Cache-Control:no-cache，不使用本地緩存
2、伺服器開啟Expires（過期時間，絕對時間）
Expires:Thu,21 Jan 2017 23:39:02 GMT

1、Last-Modified（伺服器返回此文件最後修改時間）
If-Modified-Since（客戶端第二次請求該資源帶著上次伺服器返回的此文件最後修改時間，比對是否相同）
2、Etag（優先順序更高）（第一次請求資源伺服器返回一個Etag值）
If-None-Match（第二次請求資源客戶端帶著之前的Etag值給伺服器進行比對）

如果多個參數同事存在時：
強緩存優先順序更高，而在強緩存中，Cache-Control比Expires優先順序高
協商緩存中，Etag比Last-Modified優先順序高

1、正常操作：地址欄輸入url，跳轉鏈接，前進後退等
2、手動刷新：F5，點擊刷新按鈕，右鍵菜單刷新
3、強制刷新：ctrl+F5

1、正常操作：強制緩存有效，協商緩存有效
2、手動刷新：強制緩存失效，協商緩存有效
3、強制刷新：強制緩存失效，協商緩存失效

『貳』 iPhone6怎麼刷新DNS緩存 iOS8清除DNS緩存方法

iPhone刷新DNS緩存方法
這里為大家介紹幾種可行的解決辦法，由簡單到復雜，大家可以試試。
方法1.重啟iPhone
有時候遇到某些網站自己iPhone打不開，但其他用戶可以打開，那麼不妨刷新DNS緩存試試，最簡答的嘗試方法是，關閉iPhone所有網路，然後重啟iPhone，之後再試試是不是可以打開了。
方法2.重新設置iPhone的DNS
首先進入iPhone【設置】，然後進入【無線區域網】設置，然後點擊已經連接上的Wifi網路名稱後面的【i】圖標，如下圖所示。

然後會進入已連接網路的高級設置，在【DHCP】下方可以找到DNS設置，這里我們將默認的改成其他的，比如改成全球通用的【8.8.8.8】或者【114.114.114.114】（最多可以設置2個，設置2個，中間用逗號隔開），最佳建議大家設置成【網路DNS】【阿里DNS】，如下圖所示。

修改DNS後，再打開瀏覽器訪問需要打開的網站，之後就可以發現已經成功打開了，如下圖所示。

網站終於可以打開了
以上就是iPhone刷新DNS緩存方法，對於安卓手機用戶，也可以嘗試重啟手機或者更改DNS方法來解決。此外，大家今後遇到部分網站打不開，但其他手機或者電腦可以正常訪問，也可能是DNS緩存導致的，可以試試以上方法解決哦。

『叄』 如何刷新電腦的DNS緩存及修改hosts文件

一、刷新DNS緩存

1、首先點擊電腦左下角的開始按鈕，打開「命令提示符」；

『肆』 APP中緩存、載入與刷新機制設計【轉載】

1、為什麼要加緩存？

場景一：【等待】，在向伺服器請求新的數據時。我們讓用戶看到什麼？第一種是漂亮的等待載入頁面；第二種是緩存的內容。對於第二種，用戶可以對頁面進行操作，等待新數據時可以查看舊數據，更具有「可操作性」與「可用性」，從而減輕了從伺服器獲取數據這一動作的大小和時間長短，增強了用戶體驗。另一方面，如果內容更新的間隔較長或者用戶刷新的間隔較短，在沒有緩存的情況下，很多數據我們會多次重復的向伺服器獲取，增加了成本。

場景二：【結果】沒有聯網，或者在地鐵上網路太差無法載入數據時，如果留給用戶一個空白頁面，實在是感覺有點不負責任啊。並且很多功能在沒有聯網的情況下也有使用的可能性，比如：APP中的通訊錄，查看一些聊天記錄，通知信息，文章列表等。因為用戶打開APP不一定是要看新信息，說不定是回顧老信息（或許老信息里也有用戶之前沒看的），所以恰當的緩存可以滿足更多的用戶場景。

場景三：【金錢】有一天，一個用戶發現自己裝了某個APP後流量用的特別快，Ta可能永遠將這個APP打入冷宮了，而增加緩存正是節省流量的一個方法。雖然節省的不多或者用戶也察覺不到，但是作為一個有態度的產品經理，應該多做一些思考。

2、什麼是緩存？

緩存可分為如下幾類：

（1）app緩存。

（2）固定緩存。

（3）可手動清理的緩存。

（4）不可手動清理的緩存。

（5）臨時緩存。

其中，臨時緩存常用於一個功能頁面內，保存各欄目的緩存。同一個功能里會把子功能分為多個欄目進行劃分，每個標簽欄目下的內容在本次使用中都可保存為臨時緩存，在該功能里切換欄目，不需要重新載入數據，使用緩存顯示。

對於用戶來說，使用時達到了無縫切換瀏覽，對於伺服器來說，在短時間內數據很少會有更新，所以在一般情況下能滿足用戶的正常需求，並達到體驗優秀。

臨時緩存的清理機制是：退出該功能模塊就清除之前的緩存。也就是說下次進入該功能模塊，需要重新獲取一次數據。

很多時候我們都會用到臨時緩存，因為那些信息真的不是那麼重要，而且不需要經常反復查看，那對於那些我們經常使用而且經常需要反復查看的信息，馬海祥建議採取固定緩存，保存在本地，方便下次翻閱時不需要再一次向伺服器請求數據了。

對於固定緩存又會細分為可手動清理的緩存和不可手動清理的緩存。

第一種是我們最常見的緩存，幾乎所有產品都採用這種緩存方式。平時用戶瀏覽文章、圖集載入的數據就以這種形式緩存在本地，下次看回這篇文章、圖集時就不需要載入了。用戶也可以手動把這些緩存清理了，釋放空間。

而對於某些特殊場景，例如一些相對固定的數據，我們不願意一開始就打包進App里，這樣會占太大容量，造成產品包很大，也不願意每次進入頁面都向伺服器載入這些信息，那怎麼辦？建議的解決方法就是我們可以只載入一次就永遠存在本地了，這樣安裝包也不會大，以後也不用載入了。

3、如何清理緩存？

一般App都會在「設置」里提供一個清理緩存的功能，一鍵把空間釋放。除此之外，App最好要設計自動清理機制，可以通過兩個維度來設計這個機制。

（1）、時間

通過設定一個固定的時間，或者根據用戶使用周期靈活設定時間來清理緩存。每個產品的場景不一，用戶使用頻率不一，設定這個機制的時候就需要結合實際情況考慮了。

（2）、容量

一般是設定一個容量上限，採用堆棧的設計原理進行緩存清理，溢出堆棧的舊數據將自動清除。

1、頁面載入

方案1：單頁面整體載入

這種載入比較簡單，一般運用在頁面內容比較單一的情況下，所以直接一次性載入完所有數據後再顯示內容。其單頁面載入失敗的狀態相對來說也比較好處理。

方案2：單頁面分塊載入

這種方案的特點是，能讓用戶逐步看到內容，在這個漸進的過程中降低用戶的焦慮心理。

其中又可以分為，模塊間有關聯性的，先載入父內容，再載入子內容。如優酷，先把欄目載入出來，再載入各欄目的內容。

模塊間沒有絕對關聯性的，可獨自載入各自模塊內容，根據請求的速度不同分別顯示。這樣處理有一定幾率讓用戶在沒完全刷出數據的情況下就能找到自己需要的功能，如大眾點評、淘寶客戶端等。

框架固定，內容更新的，可先把框架顯示出來，再把各模塊的數據各自載入顯示，如各種iOS自帶應用。

這種分模塊載入的需要特別注意載入失敗的狀態，畢竟每個模塊都提示載入失敗，點擊重試是很挫的一件事，可以根據信息的優先順序來決定哪些數據失敗了採用默認狀態，哪些數據採用失敗提示。

方案3：跨頁面載入

父頁面&子頁面 or 同一app內，頁面間欄位可以復用的，在載入子頁面時不需要重新載入新數據。

方案4：預載入

這種載入方式的特點是，在載入一個頁面內容的同時，預測用戶的下一步行為，並為他下一步需要使用的頁面載入內容，使得他在下一步的操作中能立刻獲取信息而不需要載入等待。

預載入提供給用戶無縫的產品使用體驗，使得用戶在使用產品的過程中更直接流暢，沒有被打斷的感覺。

具體的例子有：

在瀏覽圖集的時候，當看到第一張的圖片時，就自動後台載入第二第三第四張圖片，用戶瀏覽完第一張圖片切換到第二張時就不會有載入等待的過程。

在瀏覽新聞列表時，就把每篇新聞的內容在後台進行預載入，用戶選擇看某篇新聞時，能立刻閱讀到內容。

但是這種方案也需要面臨很多的問題，馬海祥覺得最直接的就是流量問題，因為會自動跑掉很多用戶可能根本用不上的數據流量，所以，一般情況下馬海祥建議可以設定在wifi環境才採用這種載入模式。又或者設定載入規則，只把主要內容預載入，而部分次要內容可以在用戶真的用到的時候才載入，例如預載入新聞正文的情況，可以只載入文本信息，圖片信息等到用戶進入內頁才載入。這種預載入與分塊載入結合的方式也普遍運用在各個場景。

另外，預載入也需要時間的，他只是不在客戶端顯示給用戶，默默在後台運作而已，需要特殊考慮未載入完用戶就使用到那些信息的情況，所以在做預載入設計時需要同時考慮另一種適合該情況的普通載入方式。

預載入需要根據具體的場景來進行設計，設定好信息優先順序，綜合考慮各種類型信息的具體大小流量，整體考慮預載入的方式，這些都是需要經過精心分析思考的。

隨著網路環境的發展，預載入將成為以後產品普遍的載入方式，他提供給用戶的無縫使用體驗**地提升了產品的可用性。

2、操作載入

除了頁面的信息需要載入，頁面內的操作也是需要通過給伺服器發送請求記錄的。

方案1：載入層

進行一個操作後，彈出模態的提示層，告知用戶正在載入。採用模態的提示主要是防止用戶在該過程中進行其他操作，導致當前載入出錯。由於採用模態的提示，並且有可能因為網路原因導致長時間處於載入狀態，建議提供一個「關閉」的操作，中止本次載入，恢復App可用狀態。載入失敗時可在當前浮層變換為失敗提示。模態提示層是最穩妥的方式，但他會使用戶在使用過程中有打斷的感覺。

方案2：控制項自身載入狀態

這種方式是把操作載入的狀態與控制項的樣式結合起來了，對某個控制項進行操作後，控制項變換為載入狀態，此時控制項不能重復操作。由於這種載入方式是控制項的自身狀態，不影響其他操作，所以用戶也可以對頁面進行其他操作，可能會導致同時有多個請求的情況，增加了載入失敗的風險，這也算是這種方式的弊端，不過這種極端情況很少出現。請求失敗後，可配合Toast提示告知用戶失敗的原因。

方案3：後台載入

用戶在操作後，客戶端立刻反饋操作成功，然後把請求放到後台與伺服器交互，這一過程用戶不需要了解，不需要等待，在正常情況**驗是非常棒的。

但是在極端情況下會出現一些莫名其妙的狀況，由於是後台記錄請求並與伺服器交互，所以實際請求是否成功客戶端是不說明的，全部以操作成功來顯示，這就會導致用戶誤以為操作成功了，但實際上下次來看發現沒有成功。

所以，這種載入方式是需要根據具體使用場景來權衡使用的，對於一些重要的操作，建議還是使用模態的方式載入，對於一些小操作，如點贊、訂閱、關注，可採用後台載入的方式。

3、下一頁載入還是當前也載入

用戶進入首頁，正式邁出體驗的第一步，接下來迎接的就是基於用戶目標的界面間跳轉。完成界面的跳轉，會有各種載入策略，但無論形式如何，我們都可以將其歸為兩大類：「下一頁載入」、「當前頁載入」。

（1）「下一頁載入」滿足了用戶提前窺視的需求

我們把頁面看成「點」，頁面流是連接這些點的「線」，我們以「用戶想買一條牛仔褲」這一場景作為案例做了簡單的眼動研究，從應用啟動到商品瀏覽再到商品確定最後進入下單頁，用戶所呈現的瞳孔梯次增大，即E>D>C>B>A，為了解釋這一現象，通過與被試交流，我們發現相比於各種瀏覽，用戶更期待看到他們想看到的東西。因此此時的」下一頁載入「正好，滿足了用戶提前窺視的需求。

（2） Wait！I Need Think Think

我們以同樣的方式又對「使用支付寶對手機充值」這一場景做了研究，從開始支付到二次確認支付，用戶所呈現的瞳孔都比較大，即A與B近似相等，通過訪談，我們發現與「遞增體驗流」不同的是，當用戶遇到判斷邏輯的界面時，用戶並非急於想看下一頁面到底包含怎樣的內容，而是非0即1的驗證心態，即我的操作效成功了嗎？因此在判斷邏輯界面中，用戶的內容窺視需求並不強，當然也沒什麼內容，要麼僅是一個小小的Toast，再大一點就是一個簡單的信息反饋界面（意味著「下一頁載入」在這里就是個雞肋），用戶反而對非0即1的驗證需求較為強烈，其中還伴隨著等待結果過程中的緊張感、激動感，因此界面通過 當前頁載入 表明系統正在努力地處理用戶交代的指令**了用戶的緊張感、激動感，直到結果顯現——「處理成功」，完成了非0即1驗證的滿足感。

4、先載入還是先展示

當需載入的是功能時，可以先展示再載入，當需載入的是內容時，則反過來。

淘寶

打開APP的第一個頁面是功能，所以先展示再載入的：

隨便點擊一個模塊（不要點菜單），下面要展示的將要是內容（商品），所以是先載入再展示的，沒有載入完都不展示：

京東

同樣的，功能模塊先展示後載入：

內容先載入，沒載入完不展示：

兩種方式各有利弊：

先展示，後載入：

優點：給用戶0等待的錯覺

缺點：當前數據有可能是錯的，而且得等用戶操作到最後一步才會發現

先載入，後展示：

優點：保證數據的質量和准確

缺點：網路不好時，造成等待

顯然，功能模塊對於一個產品來說是既有固定的，在短時間內幾乎不會更新，所以這種數據出現錯誤或與當前狀態不同的幾率小得多，因此，可以使用先展示後載入的方式。

另一方面，內容（特別是商品數據）是最容易產生變動的，為了保證每一個消費者看到的數據都是最真實，最准確的，所以務必要先載入再展示。

1、空白頁面刷新失敗有提示

現在的應用都標榜以內容為中心，所以都會極力避免空白頁面的出現。對於大部分的應用，最好的方法就是使用緩存，進入頁面之後，先顯示之前的緩存，然後再進行內容的刷新。其次，消滅空白頁面的第二種方法就是提供系統推薦項進行替代。但是對於一些頁面，頁面內容跟用戶的使用狀態關系密切，無法避免會出現空白頁面，這時候會使用一些引導類的提示，使得頁面變得更加豐富，同時可以促進用戶產生內容。

但是一些資訊類應用，比如讀讀日報，打開默認是空白頁面，然後再載入內容（我不是很明白這種設定）。其他一些應用，比如：豆瓣一刻和MONO，每天第一次進入應用的時候也會出現空白頁面。我猜想第二類應用的展示方式的原因是這樣的。他們的內容**都是嚴格以天為單位的，每天固定時段**精選內容。他們會希望你每天只看並且看完當天的東西，所以一旦到了第二天，昨天的內容就是累贅了。所以每天第一次進入應用的時候會出現空白頁面，象徵著每天都是從新開始。此時就會對應一個「空白刷新」邏輯。

空白刷新對應的場景是這樣子的：用戶想要刷新出內容，並且用戶知道這里可以刷出新內容，但是沒有刷新成功，這時候需要給用戶一個交待。所以需要提示用戶。同時，提示完用戶之後需要給用戶一個解決方法，這就是「點擊後重試」。

2、緩存頁面刷新失敗無提示

常見的應用比如知乎、網易新聞、好奇心日報、微信朋友圈等，這些應用都會採用緩存的形式，打開之後顯示的是緩存內容，然後系統會給伺服器發送請求，如果有內容更新的話就會自動更新一次內容，更新之後的內容直接覆蓋當前的內容。更新失敗之後是沒有提示的。但是有一些應用，比如有道詞典、企鵝FM、網易雲音樂等，他們更新失敗之後是有提示的。

我覺得這兩種應用的區分點在於

應用的使用頻率；

內容的時間連續性；

界面之間的關系緊密度。

比如說網易新聞，作為一個打發時間的工具，每天使用頻率就會比較高，所以用戶進來之後是想看看有沒有更新。其次，網易新聞的內容是連續不斷更新的，所以用戶會知道當前顯示的內容是我看看過並且處理過的。最後，新聞列表頁面顯示的是摘要，用戶可以通過摘要快速進行判斷是否要進入詳情頁，摘要有助於幫助用戶回憶上一次的使用場景。

所以這就對應著一個這樣的場景：用戶只是想看看有沒有更新，所以他們已經做好了「沒有新內容」的心理預期，所以即使是更新不了內容，用戶也不會想太多。反倒是，如果進行了錯誤提示，用戶可能會有一種挫敗感。因為他知道現在有內容，只是因為網路的原因而沒有更新，他要進行的任務受到了外界因素的阻礙，由此產生一種細微的挫敗感。

3、緩存頁面刷新失敗有提示

另一類應用，使用頻率沒那麼高，或者內容不具備時間連續性的，又或者說當前界面無法喚起用戶上一次的使用場景。那麼就有必要進行率先你失敗提示了。

比如說企鵝FM，音頻類的應用註定使用不會那麼頻繁，因為通過視覺接收的信息會比通過聽覺接收的信息更快更多，同時音頻類對環境的要求較高（比如用耳機時要求環境不那麼嘈雜，外放時要求在私人場所）。其次，此類應用都是實時推薦的，不存在時間連續性的問題，用戶無法通過時間來判斷內容是否被閱讀過。再者，標題也無法幫你快速做出判斷，你還是要進去聽過才知道內容是什麼。最後如果不提醒，用戶進入到詳情頁再收到提醒，就會覺得應用浪費了用戶的時間。所以，對於此類內容，刷新失敗是有必要進行提醒的。