1、最新更新通知 加ixuexi66資料整理不易個(gè)人學(xué)習(xí)倒賣 Android開發(fā)高手課首頁|優(yōu)化（上）：常見的數(shù)據(jù)方法有哪些？12 |2019-01-08講述：時(shí)長(zhǎng) 15:21大小 14.07M通過專欄前面我講的 I/O 優(yōu)化基礎(chǔ)知識(shí)，相信你肯定了解了文件系統(tǒng)和磁盤的一些機(jī)制，以及不同 I/O 方式的使用場(chǎng)景以及優(yōu)缺點(diǎn)，并且可以掌握如何上I/O 操作。萬丈高樓平地起，在理解并掌握這些基礎(chǔ)知識(shí)的同時(shí)，你肯定還想知道如何利用這些知識(shí)指導(dǎo)我們寫出更好的代碼。今天我來結(jié)合 Android 系統(tǒng)的一些特性，講講開發(fā)過程中常見以幫你在日常工作中如何做出更好的選擇。方法的優(yōu)缺點(diǎn)，希望可Android 的基礎(chǔ)在講

2、具體的方法之前，我們應(yīng)該對(duì) Android 系統(tǒng)相關(guān)的一些基礎(chǔ)知識(shí)有所了解。1. Android 分區(qū)I/O 優(yōu)化中講到的大部分知識(shí)更側(cè)重 Linux 系統(tǒng)，對(duì)于 Android 來說，我們首先應(yīng)該對(duì)Android 分區(qū)的架構(gòu)和作用有所了解。在我們熟悉的 Windows 世界中，我們一般都把系統(tǒng)安裝在 C 盤，然后還會(huì)有幾個(gè)用來存放應(yīng)用程序和數(shù)據(jù)的分區(qū)。Android 系統(tǒng)可以通過 /proc/partitions 或者 df 命令來查看的各個(gè)分區(qū)情況，下圖是Nexus 6 中 df 命令的運(yùn)行結(jié)果。什么是分區(qū)呢？分區(qū)簡(jiǎn)單來說就是將設(shè)備中的劃分為一些互不重疊的部分，每個(gè)部分都可以單獨(dú)格式化，用

3、作不同的目的。這樣系統(tǒng)就可以靈活的單獨(dú)分區(qū)做不同的操作，例如在系統(tǒng)還原（recovery）過程，我們不希望會(huì)影響到用戶的數(shù)據(jù)。從上面的表中你可以看到，每個(gè)分區(qū)非常其中比較重要的有：，不同的分區(qū)可以使用的不同的文件系統(tǒng)。/system 分區(qū)：它是存放所有提供的 Android 組件的地方。這個(gè)分區(qū)只能以只讀方式 mount。這樣主要基于穩(wěn)定性和安全性考慮，即使發(fā)生用戶突然斷電的情況，也依然需要保證 /system 分區(qū)的內(nèi)容受到破壞和篡改。/data 分區(qū)：它是所有用戶數(shù)據(jù)存放的地方。主要為了實(shí)現(xiàn)數(shù)據(jù)，即系統(tǒng)升級(jí)和恢復(fù)的時(shí)候會(huì)擦除整個(gè) /system 分區(qū)，但是卻置，只會(huì)擦除 /data 的數(shù)據(jù)

4、。影響 /data 的用戶數(shù)據(jù)。而恢復(fù)出廠設(shè)最新更新通知 加ixuexi66資料整理不易個(gè)人學(xué)習(xí)倒賣/vendor 分區(qū)：它是存放廠商特殊系統(tǒng)修改的地方。特別是在 Android 8.0 以后，隆重推出了“Treble”項(xiàng)目。廠商 OTA 時(shí)可以只更新的 /vendor 分區(qū)即可，讓廠商能夠以更低的成本，更輕松、更快速地將設(shè)備更新到新版 Android 系統(tǒng)。2. Android安全除了數(shù)據(jù)的分區(qū)，安全也是 Android 系統(tǒng)非常重要的一部分，安全首先考慮的是權(quán)限。第一，權(quán)限Android 的每個(gè)應(yīng)用都在的應(yīng)用沙盒內(nèi)運(yùn)行，在 Android 4.3 之前的版本中，這些沙盒使用了標(biāo)準(zhǔn) Linu

5、x 的保護(hù)機(jī)制，通過為每個(gè)應(yīng)用創(chuàng)建獨(dú)一無二的 Linux UID 來定義。簡(jiǎn)單來說，我們需要保證統(tǒng)的一些保護(hù)文件。不能淘寶的數(shù)據(jù)，并且在沒限的情況下也不能系在 Android 4.3 引入了SELinux（Security Enhanced Linux）機(jī)制進(jìn)一步定義 Android應(yīng)用沙盒的邊界。那它有什么特別的呢？它的作用是即使我們進(jìn)程有 root 權(quán)限也不能為所欲為，如果想在 SELinux 系統(tǒng)中干任何事情，都必須先在專門的安全策略配置文件中賦予權(quán)限。第二，數(shù)據(jù)加密除了權(quán)限的，用戶還會(huì)擔(dān)心在丟失或者導(dǎo)致個(gè)人隱私數(shù)據(jù)泄露。加密或許是一個(gè)不錯(cuò)的選擇，它可以保護(hù)丟失或設(shè)備上的數(shù)據(jù)。Andro

6、id 有兩種設(shè)備加密方法：全盤加密和文件級(jí)加密。全盤加密是在 Android 4.4 中引入的，并在 Android 5.0 中默認(rèn)打開。它會(huì)將 /data 分區(qū)的用戶數(shù)據(jù)操作加密 /，對(duì)性能會(huì)有一定的影響，但是新版本的都會(huì)在硬件中提供直接支持。我們知道，基于文件系統(tǒng)的加密，如果設(shè)備被了，加密也就沒有用了。所以 Android7.0 增加了基于文件的加密。在這種加密模式下，將會(huì)給每個(gè)文件都分配一個(gè)必須用用戶的 passcode 推導(dǎo)出來的密鑰。特定的文件被屏幕鎖屏之后，直到用戶下一次屏幕期間都不能。可能有些同學(xué)會(huì)問了，Android 的這兩種設(shè)備加密方法跟應(yīng)用的加密有什么不同，我們?cè)趹?yīng)用 還需

7、要單獨(dú)的給敏感文件加密嗎？說的是，設(shè)備加密方法對(duì)應(yīng)用程序來說是透明的，它保證我們 到的是 后的數(shù)據(jù)。對(duì)于應(yīng)用程序特別敏感的數(shù)據(jù)，我們也需要采用 RSA、AES、chacha20 等常用方式做進(jìn)一步的 加密。常見的數(shù)據(jù) 方法Android 為我們提供了很多種持久化 的方案，在具體 它們之前，你需要先問一下，什么是 ？每個(gè)人可能都會(huì)有 的 ，在我看來， 就是把特定的數(shù)據(jù)結(jié)構(gòu)轉(zhuǎn)化成可以被和還原的格式，這個(gè)數(shù)據(jù)格式可以是二進(jìn)制的，也可以是 XML、JSON、Protocol Buffer 這些格式。對(duì)于閃存來說，一切歸根到底還是二進(jìn)制的，XML、JSON 它們只是提供了一套通用的二進(jìn)制編 格式規(guī)范。既

8、然有那么多 的方案，那我們?cè)谶x擇數(shù)據(jù) 方法時(shí)，一般需要考慮哪些關(guān)鍵要素呢？1. 關(guān)鍵要素在選擇數(shù)據(jù) 方法時(shí)，我一般會(huì)想到下面這幾點(diǎn)，我把它們總結(jié)給你。最新 更新通知 加 ixuexi66資料整理不易 個(gè)人學(xué)習(xí) 倒賣那上面這些要素哪個(gè)最重要呢？數(shù)據(jù) 方法不能脫離場(chǎng)景來考慮，我們不可能把這六個(gè)要素都做成最完美。我來解釋一下這句話。如果首要考慮的是正確性，那我們可能需要采用冗余、雙寫等方案，那就要 對(duì)時(shí)間開銷產(chǎn)生的額外影響。同樣如果非常在意安全，加 環(huán)節(jié)的開銷也必不可小。如果想 啟動(dòng)場(chǎng)景，我們希望選擇在初始化時(shí)間和 時(shí)間更有優(yōu)勢(shì)的方案。2. 選項(xiàng)總的來說，我們需要結(jié)合應(yīng)用場(chǎng)景選擇合適的數(shù)據(jù) 方法。那

9、 Android 為應(yīng)用開發(fā)者提供了哪些 數(shù)據(jù)的方法呢？你可以參考 選項(xiàng)，綜合來看，有下面幾種方法。SharedPreferences ContentProvider文件 數(shù)據(jù)庫(kù)今天我先來講 SharedPreferences 和 ContentProvider 這兩個(gè) 方法，文件和數(shù)據(jù)庫(kù)將放到“ 優(yōu)化”后面兩期來講。第一，SharedPreferences 的使用。SharedPreferences是 Android 中比較常用的 方法，它可以用來 一些比較小的鍵值對(duì)集合。雖然 SharedPreferences 使用非常簡(jiǎn)便，但也是我們?cè)嵅”容^多的 方法。它的性能問題比較多，我可以輕松地說

10、出它的“ ”。跨進(jìn)程不安全。由于沒有使用跨進(jìn)程的鎖，就算使用MODE_MULTI_PROCESS， SharedPreferences 在跨進(jìn)程頻繁讀寫有可能導(dǎo)致數(shù)據(jù)全部丟失。根據(jù)線上統(tǒng)計(jì)，SP 大 有萬分之一的損壞率。加載緩慢。SharedPreferences 文件的加載使用了異步線程，而且加載線程并沒有設(shè)置線程優(yōu)先級(jí)，如果這個(gè)時(shí)候主線程 數(shù)據(jù)就需要等待文件加載線程的結(jié)束。這就導(dǎo)致出現(xiàn)主線程等待低優(yōu)先級(jí)線程鎖的問題，比如一個(gè) 100KB 的 SP 文件 等待時(shí)間大約需要 50100ms，我建議提前用異步線程預(yù)加載啟動(dòng)過程用到的 SP 文件。寫入。無論是調(diào)用 commit() 還是 appl

11、y()，即使我們只改動(dòng)其中的一個(gè)條目，都會(huì)把整個(gè)內(nèi)容全部寫到文件。而且即使我們多次寫入同一個(gè)文件，SP 也沒有將多次修改合并為一次，這也是性能差的重要 之一。由于提供了異步落盤的 apply 機(jī)制，在 或者其他一些異常情況可能會(huì)導(dǎo)致數(shù)據(jù)丟失。所以當(dāng)應(yīng)用收到系統(tǒng)廣播，或者被調(diào)用 onPause 等一些時(shí)機(jī)，系統(tǒng)會(huì)強(qiáng)制把所 有的 SharedPreferences 對(duì)象數(shù)據(jù)落地到磁盤。如果沒有落地完成，這時(shí)候主線 被一直阻塞。這樣非常容易造成 ，甚至是 ANR，從線上數(shù)據(jù)來看 SP 占比一般會(huì)超過 5%。講到這里，如果你對(duì) SharedPreferences 機(jī)制還不熟悉的話，可以參考徹底搞懂Sh

12、aredPreferences。最新一手資源 更新通知 加微信 ixuexi66資料整理不易 僅供個(gè)人學(xué)習(xí) 請(qǐng)勿倒賣坦白來講，系統(tǒng)提供的 SharedPreferences 的應(yīng)用場(chǎng)景是用來存儲(chǔ)一些非常簡(jiǎn)單、輕量 的數(shù)據(jù)。我們不要使用它來存儲(chǔ)過于復(fù)雜的數(shù)據(jù)，例如 HTML、JSON 等。而且SharedPreference 的文件存儲(chǔ)性能與文件大小相關(guān)，每個(gè) SP 文件不能過大，我們不要將毫無關(guān)聯(lián)的配置項(xiàng)保存在同一個(gè)文件中，同時(shí)考慮將頻繁修改的條目單獨(dú)隔離出來。我們也可以替換通過復(fù)寫 Application 的 getSharedPreferences 方法替換系統(tǒng)默認(rèn)實(shí)現(xiàn)，比如優(yōu)化卡頓、合并

13、多次 apply 操作、支持跨進(jìn)程操作等。具體如何替換呢？在今天的 Sample 中我也提供了一個(gè)簡(jiǎn)單替換實(shí)現(xiàn)。復(fù)制代碼1 public class MyApplication extends Application 2 Override3 public SharedPreferences getSharedPreferences(String name, int mode)4 5 return SharedPreferencesImpl.getSharedPreferences(name, mode);6 7 對(duì)系統(tǒng)提供的 SharedPreferences 的小修小補(bǔ)雖然性能有所提升，但是

14、依然不能徹底解決問題。基本每個(gè)大公司都會(huì)自研一套替代的存儲(chǔ)方案，比如微信最近就開源了MMKV。下面是 MMKV 對(duì)于 SharedPreferences 的“六要素”對(duì)比。你可以參考 MMKV 的實(shí)現(xiàn)原理和性能測(cè)試報(bào)告，里面有一些非常不錯(cuò)的思路。例如利用 文件鎖保證跨進(jìn)程的安全、使用 mmap 保證數(shù)據(jù) 丟失、選用性能和 空間更好的Protocol Buffer 代替 XML、支持增量更新等。根據(jù) I/O 優(yōu)化的分析，對(duì)于頻繁修改的配置使用 mmap 的確非常合適，使用者不用去理解 apply() 和 commit() 的差別，也不用擔(dān)心數(shù)據(jù)的丟失。同時(shí)，我們也不需要每次交整個(gè)文件，整體性能會(huì)

15、有很大提升。第二，ContentProvider 的使用。為什么 Android 系統(tǒng)不把 SharedPreferences 設(shè)計(jì)成跨進(jìn)程安全的呢？那是因?yàn)锳ndroid 系統(tǒng)更希望我們?cè)谶@個(gè)場(chǎng)景選擇使用 ContentProvider 作為 方式。ContentProvider 作為 Android 四大組件中的一種，為我們提供了不同進(jìn)程甚至是不同應(yīng)用程序之間共享數(shù)據(jù)的機(jī)制。 最新 更新通知 加 ixuexi66 資料整理不易 個(gè)人學(xué)習(xí) 倒賣Android 系統(tǒng)中比如相冊(cè)、日歷、音頻、 、 等模塊 供了 ContentProvider 的 支持。它的使用十分簡(jiǎn)單，你可以參考 文檔。當(dāng)然，在

16、使用過程也有下面幾點(diǎn)需要注意。啟動(dòng)性能ContentProvider 的生命周期默認(rèn)在 Application onCreate() 之前，而且都是在主線建的。我們自定義的 ContentProvider 類的構(gòu)造函數(shù)、靜態(tài)代碼塊、onCreate 函數(shù)都盡量不要做耗時(shí)的操作，會(huì)拖慢啟動(dòng)速度。可能很多同學(xué)都不知道 ContentProvider 還有一個(gè)多進(jìn)程模式，它可以和AndroidManifest 中的 multiprocess 屬性結(jié)合使用。這樣調(diào)用進(jìn) 直接在 進(jìn)程里創(chuàng)建一個(gè) push 進(jìn)程的 Provider 實(shí)例，就不需要跨進(jìn)程調(diào)用了。需要注意的是，這樣也會(huì)帶來 Provider

17、的多實(shí)例問題。穩(wěn)定性ContentProvider 在進(jìn)行跨進(jìn)程數(shù)據(jù)傳遞時(shí)，利用了 Android 的 Binder 和 共享內(nèi)存機(jī)制。簡(jiǎn)單來說，就是通過 Binder 傳遞 CursorWindow 對(duì)象內(nèi)部的 共享內(nèi)存的文件描述符。這樣在跨進(jìn)程傳輸中，結(jié)果數(shù)據(jù)并不需要跨進(jìn)程傳輸，而是在不同進(jìn)程中通過傳 輸?shù)?共享內(nèi)存文件描述符來操作同一塊 內(nèi)存，這樣來實(shí)現(xiàn)不同進(jìn)程 相同數(shù)據(jù)的目的。正如我前面 I/O 優(yōu)化所講的，基于 mmap 的 共享內(nèi)存機(jī)制也是有代價(jià)的。當(dāng)傳輸?shù)臄?shù)據(jù)量非常小的時(shí)候，可能不一定劃算。所以 ContentProvider 提供了一種 call 函數(shù)，它會(huì)直接通過 Binde

18、r 來傳輸數(shù)據(jù)。Android 的 Binder 傳輸是有大小限制的，一般來說限制是 12MB。ContentProvider 的接口調(diào)用參數(shù)和 call 函數(shù)調(diào)用并沒有使用 共享機(jī)制，比如要批量 很多數(shù)據(jù)，那 出現(xiàn)一個(gè) 數(shù)據(jù)的數(shù)組，如果這個(gè)數(shù)組太大了，那么這個(gè)操作就可能會(huì)出現(xiàn)數(shù)據(jù)超大異常。安全性雖然 ContentProvider 為應(yīng)用程序之間的數(shù)據(jù)共享提供了很好的安全機(jī)制，但是如果ContentProvider 是 exported，當(dāng)支持執(zhí)行 SQL 語句時(shí)就需要注意 SQL 注入的問題。另外如果我們傳入的參數(shù)是一個(gè)文件路徑，然后返回文件的內(nèi)容，這個(gè)時(shí)候也要校驗(yàn)合法 性，不然整個(gè)應(yīng)用的

19、私有數(shù)據(jù)都有可能被別人拿到，在 intent 傳遞參數(shù)的時(shí)候可能經(jīng)常會(huì)犯這個(gè)錯(cuò)誤。 最新 更新通知 加 ixuexi66 資料整理不易 個(gè)人學(xué)習(xí) 倒賣最后我給你總結(jié)一下 ContentProvider 的“六要素”優(yōu)缺點(diǎn)。總的來說，ContentProvider 這套方案實(shí)現(xiàn)相對(duì)比較笨重，適合傳輸大的數(shù)據(jù)。總結(jié)雖然 SharedPreferences 和 ContentProvider 都是我們?nèi)粘＝?jīng)常使用的 方法，但是里面的確會(huì)有大大小小的暗坑。所以我們需要充分了解它們的優(yōu)缺點(diǎn)，這樣在工作中可以更好地使用和優(yōu)化。如何在合適的場(chǎng)景選擇合適的 方法是 優(yōu)化的必修課，你應(yīng)該學(xué)會(huì)通過正確性、時(shí)間開銷

20、、空間開銷、安全、開發(fā)成本以及兼容性這六大關(guān)鍵要素來分解某個(gè) 方法。在設(shè)計(jì)某個(gè)方案的時(shí)候也是同樣的道理，我們無法同時(shí)把所有的要素都做得最好，因此要學(xué)會(huì)取舍和選擇，在的世界里不全局最優(yōu)解，我們要找的是局部的最優(yōu)解。這個(gè)時(shí)候更應(yīng)明確做到最好。的訴求，大膽犧牲部分關(guān)鍵點(diǎn)的指標(biāo)，將場(chǎng)景最關(guān)心的要素點(diǎn)課后作業(yè)下面是 MMKV 給出的性能測(cè)試報(bào)告，你可以看到跟系統(tǒng)的 SharedPreferences 相比，主要差距在于寫的速度。沒有實(shí)踐就沒有發(fā)言權(quán)，今天我們一起來嘗試測(cè)試對(duì)比 MMKVSharedPreferences 的性能差異。請(qǐng)將你的測(cè)試結(jié)果和分析體會(huì)，寫在留言享交流吧。同學(xué)們分今天的練習(xí)Samp

21、le是通過復(fù)寫 Application 的 getSharedPreferences 方法替換系統(tǒng)默認(rèn)實(shí)現(xiàn)，這種方式雖然不是最好的方法，不過它主要的優(yōu)點(diǎn)在于代碼的侵入性比較低，無需修改太多的代碼。歡迎你點(diǎn)擊“請(qǐng)朋友讀”，把今天的內(nèi)容給好友，邀請(qǐng)他一起學(xué)習(xí)。最后別忘了在評(píng)論區(qū)提交今天的作業(yè)，我也為認(rèn)真完成作業(yè)的同學(xué)準(zhǔn)備了豐厚的“學(xué)習(xí)加油禮包”，期待最新更新通知 加ixuexi66資料整理不易個(gè)人學(xué)習(xí)倒賣與你一起切磋進(jìn)步哦。歸科技所有，上一篇練習(xí)Sample跑起來 | 熱點(diǎn)問題答疑第3期13 |優(yōu)化（中）：如何優(yōu)化數(shù)據(jù)？下一篇精選留言 (5)寫 言102019-01-08您好!最近正打算利用MMKV替換Sh