字節(jié)-Android開發(fā)面經(jīng)（五）

Android的四大數(shù)據(jù)存儲(chǔ)方式之一“SharedPreference”，其他三個(gè)分別是SQLite、Content Provider 和 File

一般使用SharedPreference來(lái)存儲(chǔ)應(yīng)用程序的配置信息。它一般存儲(chǔ)在應(yīng)用程序的私有存儲(chǔ)區(qū),文件權(quán)限是私有的。也就是說(shuō)只能供寫入者讀取。它使用鍵/值（NVP機(jī)制）來(lái)存儲(chǔ)數(shù)據(jù)。支持的數(shù)據(jù)類型（boolean、int、float、long和String）。它存儲(chǔ)在應(yīng)用程序的私有目錄下(data/data/包名 /shared_prefs/)自定義的XML文件中。

1.創(chuàng)建SharedPreference

SharedPreference myPreference=getSharedPreferences("myPreference", Context.MODE_PRIVATE);

第一個(gè)參數(shù)：SharedPreference 的名稱

第二個(gè)參數(shù)：打開的方式，一般有兩個(gè)值（0和MODE_PRIVATE）我們一般用MODE_PRIVATE

2.寫入，更新SharedPreference

//獲取SharedPreferences對(duì)象

SharedPreference myPreference=getSharedPreferences("myPreference", Context.MODE_PRIVATE);

//像SharedPreference中寫入數(shù)據(jù)需要使用Editor

Editor editor = myPreference.edit();

//存入鍵值對(duì)數(shù)據(jù)，注意此處的put[type]("key",value);

editor.putString("STRING_KEY", "string");

editor.putInt("INT_KEY", 0);

editor.putBoolean("BOOLEAN_KEY", true);

//提交保存

//editor.apply();

editor.commit();

提示：

（1）apply和commit都是提交保存，區(qū)別在于apply是異步執(zhí)行的，不需要等待。不論刪除，修改，增加都必須調(diào)用apply或者commit提交保存。

（2）關(guān)于更新：如果已經(jīng)插入的key已經(jīng)存在。那么將更新原來(lái)的key。

（3）應(yīng)用程序一旦卸載，SharedPreference也會(huì)被刪除。

3.讀取

SharedPreference myPreference=getSharedPreferences("myPreference", Context.MODE_PRIVATE);

//讀取這里主要用到了get[type]("key",defaultvalue),第一個(gè)參數(shù)是要獲取的key，第二個(gè)參數(shù)是默認(rèn)值，是當(dāng)沒有為這個(gè)key保存值的時(shí)候使用。

String name=preferences.getString("name", "defaultname");

String age=preferences.getString("name", "暫無(wú)");

String age=preferences.getInt("age", 0);

String age=preferences.getBoolean("isRead", false);

4.檢索

SharedPreference myPreference=getSharedPreferences("myPreference", Context.MODE_PRIVATE);

//檢查當(dāng)前鍵是否存在

boolean isContains=myPreference.contains("key");

//使用getAll可以返回所有可用的鍵值

//Map<String,?> allMaps=myPreference.getAll();

  一. 介紹

HTTP/2是HTTP協(xié)議自1999年HTTP1.1發(fā)布后的首個(gè)更新，主要基于SPDY協(xié)議。

1.1 什么是SPDY協(xié)議

SPDY是Speedy的昵音，意為“更快”。它是Google開發(fā)的基于TCP協(xié)議的應(yīng)用層協(xié)議。目標(biāo)是優(yōu)化HTTP協(xié)議的性能，通過壓縮、多路復(fù)用和優(yōu)先級(jí)等技術(shù)，縮短網(wǎng)頁(yè)的加載時(shí)間并提高安全性。SPDY協(xié)議的核心思想是盡量減少TCP連接數(shù)。SPDY并不是一種用于替代HTTP的協(xié)議，而是對(duì)HTTP協(xié)議的增強(qiáng)。

1.2 HTTP1.X的缺點(diǎn)

任何事物的更新都是為了彌補(bǔ)或修復(fù)上個(gè)版本的某些問題，那么我們來(lái)看看HTTP1.x都有哪些缺點(diǎn)以至于我們要使用HTTP2.0。

HTTP1.x有以下幾個(gè)主要缺點(diǎn)：

HTTP/1.0一次只允許在一個(gè)TCP連接上發(fā)起一個(gè)請(qǐng)求，HTTP/1.1使用的流水線技術(shù)也只能部分處理請(qǐng)求并發(fā)，仍然會(huì)存在隊(duì)列頭阻塞問題，因此客戶端在需要發(fā)起多次請(qǐng)求時(shí)，通常會(huì)采用建立多連接來(lái)減少延遲。

單向請(qǐng)求，只能由客戶端發(fā)起。

請(qǐng)求報(bào)文與響應(yīng)報(bào)文首部信息冗余量大。

數(shù)據(jù)未壓縮，導(dǎo)致數(shù)據(jù)的傳輸量大

我們可以通過一個(gè)鏈接來(lái)對(duì)比一下HTTP2.0到底比HTTP1.x快了多少。鏈接地址

二. 二進(jìn)制分幀

在不改變HTTP1.x的語(yǔ)義、方法、狀態(tài)碼、URL以及首部字段的情況下，HTTP2.0是怎樣突破HTTP1.1的性能限制，改進(jìn)傳輸性能，實(shí)現(xiàn)低延遲高吞吐量的呢？關(guān)鍵之一就是在應(yīng)用層（HTTP）和傳輸層（TCP）之間增加一個(gè)二進(jìn)制分幀層。

在整理二進(jìn)制分幀及其作用的時(shí)候我們先來(lái)鋪墊一點(diǎn)關(guān)于幀的知識(shí)：

幀：HTTP2.0通信的最小單位，所有幀都共享一個(gè)8字節(jié)的首部，其中包含幀的長(zhǎng)度、類型、標(biāo)志、還有一個(gè)保留位，并且至少有標(biāo)識(shí)出當(dāng)前幀所屬的流的標(biāo)識(shí)符，幀承載著特定類型的數(shù)據(jù)，如HTTP首部、負(fù)荷、等等。

消息：比幀大的通訊單位，是指邏輯上的HTTP消息，比如請(qǐng)求、響應(yīng)等。由一個(gè)或多個(gè)幀組成

流：比消息大的通訊單位。是TCP連接中的一個(gè)虛擬通道，可以承載雙向的消息。每個(gè)流都有一個(gè)唯一的整數(shù)標(biāo)識(shí)符

HTTP2.0中所有加強(qiáng)性能的核心是二進(jìn)制傳輸，在HTTP1.x中，我們是通過文本的方式傳輸數(shù)據(jù)。基于文本的方式傳輸數(shù)據(jù)存在很多缺陷，文本的表現(xiàn)形式有多樣性，因此要做到健壯性考慮的場(chǎng)景必然有很多，但是二進(jìn)制則不同，只有0和1的組合，因此選擇了二進(jìn)制傳輸，實(shí)現(xiàn)方便且健壯。

在HTTP2.0中引入了新的編碼機(jī)制，所有傳輸?shù)臄?shù)據(jù)都會(huì)被分割，并采用二進(jìn)制格式編碼。

為了保證HTTP不受影響，那就需要在應(yīng)用層（HTTP2.0）和傳輸層（TCP or UDP）之間增加一個(gè)二進(jìn)制分幀層。在二進(jìn)制分幀層上，HTTP2.0會(huì)將所有傳輸?shù)男畔⒎譃楦〉南⒑蛶⒉捎枚M(jìn)制格式編碼，其中HTTP1.x的首部信息會(huì)被封裝到Headers幀，而Request Body則封裝到Data幀。

三. 首部壓縮

HTTP1.1并不支持HTTP首部壓縮，為此SPDY和HTTP2.0出現(xiàn)了。SPDY是用的是DEFLATE算法，而HTTP2.0則使用了專門為首部壓縮設(shè)計(jì)的HPACK算法。

HTTP每次通訊（請(qǐng)求或響應(yīng)）都會(huì)攜帶首部信息用于描述資源屬性。

在HTTP1.0中，我們使用文本的形式傳輸header，在header中攜帶cookie的話，每次都需要重復(fù)傳輸幾百到幾千的字節(jié)，這著實(shí)是一筆不小的開銷。

在HTTP2.0中，我們使用了HPACK（HTTP2頭部壓縮算法）壓縮格式對(duì)傳輸?shù)膆eader進(jìn)行編碼，減少了header的大小。并在兩端維護(hù)了索引表，用于記錄出現(xiàn)過的header，后面在傳輸過程中就可以傳輸已經(jīng)記錄過的header的鍵名，對(duì)端收到數(shù)據(jù)后就可以通過鍵名找到對(duì)應(yīng)的值。

四. 多路復(fù)用

在HTTP1.x中，我們經(jīng)常會(huì)使用到雪碧圖、使用多個(gè)域名等方式來(lái)進(jìn)行優(yōu)化，都是因?yàn)闉g覽器限制了同一個(gè)域名下的請(qǐng)求數(shù)量，當(dāng)頁(yè)面需要請(qǐng)求很多資源的時(shí)候，隊(duì)頭阻塞（Head of line blocking）會(huì)導(dǎo)致在達(dá)到最大請(qǐng)求時(shí)，資源需要等待其他資源請(qǐng)求完成后才能繼續(xù)發(fā)送。

HTTP2.0中,基于二進(jìn)制分幀層，HTTP2.0可以在共享TCP連接的基礎(chǔ)上同時(shí)發(fā)送請(qǐng)求和響應(yīng)。HTTP消息被分解為獨(dú)立的幀，而不破壞消息本身的語(yǔ)義，交錯(cuò)發(fā)出去，在另一端根據(jù)流標(biāo)識(shí)符和首部將他們重新組裝起來(lái)。通過該技術(shù)，可以避免HTTP舊版本的隊(duì)頭阻塞問題，極大提高傳輸性能。

五. 請(qǐng)求優(yōu)先級(jí)

把HTTP消息分為很多獨(dú)立幀之后，就可以通過優(yōu)化這些幀的交錯(cuò)和傳輸順序進(jìn)一步優(yōu)化性能。

六. 服務(wù)器推送

HTTP2.0新增的一個(gè)強(qiáng)大的新功能，就是服務(wù)器可以對(duì)一個(gè)客戶端請(qǐng)求發(fā)送多個(gè)響應(yīng)。服務(wù)器向客戶端推送資源無(wú)需客戶端明確的請(qǐng)求。

服務(wù)端根據(jù)客戶端的請(qǐng)求，提前返回多個(gè)響應(yīng)，推送額外的資源給客戶端。如下圖，客戶端請(qǐng)求stream 1(/page.html)。服務(wù)端在返回stream 1的消息的同時(shí)推送了stream 2(/script.js)和stream 4(/style.css)

服務(wù)端推送是一種在客戶端請(qǐng)求之前發(fā)送數(shù)據(jù)的機(jī)制。在HTTP2.0中，服務(wù)器可以對(duì)一個(gè)客戶端的請(qǐng)求發(fā)送多個(gè)響應(yīng)。如果一個(gè)請(qǐng)求是由你的主頁(yè)發(fā)送的，服務(wù)器可能會(huì)響應(yīng)主頁(yè)內(nèi)容、logo以及樣式表，因?yàn)樗揽蛻舳藭?huì)用到這些東西。這樣不但減輕了數(shù)據(jù)傳送冗余步驟，也加快了頁(yè)面響應(yīng)的速度，提高了用戶體驗(yàn)。

推送的缺點(diǎn)：所有推送的資源都必須遵守同源策略。換句話說(shuō)，服務(wù)器不能隨便將第三方資源推送給客戶端，而必須是經(jīng)過雙方的確認(rèn)才行。