21.數據的存儲方式
- File 存儲
- SharedPreference 存儲
- ContentProvider 存儲
- SQLiteDataBase 存儲
- 網絡存儲
22.數據的加密方式
1.MD5(這種方法不推薦使用了,網上都能直接找到相應的明文)
MD5英文全稱“Message-Digest Algorithm 5”，翻譯過來是“消息摘要算法5”，由MD2、MD3、MD4演變過來的，是一種單向加密算法，是不可逆的一種的加密方式。
具體可參考:Android數據加密之MD5加密
2.Android數據加密之Base64編碼算法
平時開發(fā)中遇見的各種數據加密方式，最終都會對加密后的二進制數據進行Base64編碼，起到一種二次加密的效果，其實呢Base64從嚴格意義上來說的話不是一種加密算法，而是一種編碼算法，為何要使用Base64編碼呢？
Base64是網絡上最常見的用于傳輸8Bit字節(jié)代碼的編碼方式之一，Base64并不是安全領域的加密算法，其實Base64只能算是一個編碼算法，對數據內容進行編碼來適合傳輸。標準Base64編碼解碼無需額外信息即完全可逆，即使你自己自定義字符集設計一種類Base64的編碼方式用于數據加密，在多數場景下也較容易破解。Base64編碼本質上是一種將二進制數據轉成文本數據的方案。對于非二進制數據，是先將其轉換成二進制形式，然后每連續(xù)6比特（2的6次方=64）計算其十進制值，根據該值在A--Z,a--z,0--9,+,/ 這64個字符中找到對應的字符，最終得到一個文本字符串。基本規(guī)則如下幾點：
標準Base64只有64個字符（英文大小寫、數字和+、/）以及用作后綴等號；
Base64是把3個字節(jié)變成4個可打印字符，所以Base64編碼后的字符串一定能被4整除（不算用作后綴的等號）；
等號一定用作后綴，且數目一定是0個、1個或2個。這是因為如果原文長度不能被3整除，Base64要在后面添加\0湊齊3n位。為了正確還原，添加了幾個\0就加上幾個等號。顯然添加等號的數目只能是0、1或2；
嚴格來說Base64不能算是一種加密，只能說是編碼轉換。
具體可參考:Android數據加密之Base64編碼算法
3.異或加密
異或運算中，如果某個字符（或數值）x 與 一個數值m 進行異或運算得到y(tǒng)，則再用y 與 m 進行異或運算就可以還原為 x ，因此應用這個原理可以實現數據的加密解密功能。
具體可參考:Android數據加密之異或加密算法
4.DES
DES是一種對稱加密算法，所謂對稱加密算法即：加密和解密使用相同密鑰的算法。DES加密算法出自IBM的研究，
后來被美國政府正式采用，之后開始廣泛流傳，但是近些年使用越來越少，因為DES使用56位密鑰，以現代計算能力，
24小時內即可被破解。
具體可參考:Android數據加密之Des加密
5.AES
高級加密標準（英語：Advanced Encryption Standard，縮寫：AES），在密碼學中又稱Rijndael加密法，是美國聯邦政府采用的一種區(qū)塊加密標準。這個標準用來替代原先的DES，已經被多方分析且廣為全世界所使用。
具體可參考:Android數據加密之Aes加密
6.RSA
RSA算法是最流行的公鑰密碼算法，使用長度可以變化的密鑰。RSA是第一個既能用于數據加密也能用于數字簽名的算法。
RSA算法原理如下：
1.隨機選擇兩個大質數p和q，p不等于q，計算N=pq；
2.選擇一個大于1小于N的自然數e，e必須與(p-1)(q-1)互素。
3.用公式計算出d：d×e = 1 (mod (p-1)(q-1)) 。
4.銷毀p和q。
最終得到的N和e就是“公鑰”，d就是“私鑰”，發(fā)送方使用N去加密數據，接收方只有使用d才能解開數據內容。
RSA的安全性依賴于大數分解，小于1024位的N已經被證明是不安全的，而且由于RSA算法進行的都是大數計算，使得RSA最快的情況也比DES慢上倍，這是RSA最大的缺陷，因此通常只能用于加密少量數據或者加密密鑰，但RSA仍然不失為一種高強度的算法。
具體可參考:Android數據加密之Des加密
7.so文件加密
將一些重要信息代碼放到native層，主要因為native層的逆向分析的難度更大，而且代碼執(zhí)行效率高，對性能影響小。
23.Xml和Json
XML
XML的優(yōu)點
A.格式統(tǒng)一，符合標準；
B.容易與其他系統(tǒng)進行遠程交互，數據共享比較方便。
XML的缺點
A.XML文件龐大，文件格式復雜，傳輸占帶寬；
B.服務器端和客戶端都需要花費大量代碼來解析XML，導致服務器端和客戶端代碼變得異常復雜且不易維護；
C.客戶端不同瀏覽器之間解析XML的方式不一致，需要重復編寫很多代碼；
D.服務器端和客戶端解析XML花費較多的資源和時間。
解析方式:
A.DOM解析器
B.SAX解析器
C.PULL解析器
PULL解析器小巧輕便，解析速度快，簡單易用，非常適合在Android移動設備中使用，Android系統(tǒng)內部在解析各種XML時也是用PULL解析器。主要使用XmlPullParser這個類.
Json
JSON的優(yōu)點：
A.數據格式比較簡單，易于讀寫，格式都是壓縮的，占用帶寬小；
B.易于解析，客戶端JavaScript可以簡單的通過eval()進行JSON數據的讀取；
C.支持多種語言，包括ActionScript, C, C#, ColdFusion, Java, JavaScript, Perl, PHP, Python, Ruby等服務器端語言，便于服務器端的解析；
D.在PHP世界，已經有PHP-JSON和JSON-PHP出現了，偏于PHP序列化后的程序直接調用，PHP服務器端的對象、數組等能直接生成JSON格式，便于客戶端的訪問提取；
E.因為JSON格式能直接為服務器端代碼使用，大大簡化了服務器端和客戶端的代碼開發(fā)量，且完成任務不變，并且易于維護。
JSON的缺點
A.沒有XML格式這么推廣的深入人心和喜用廣泛，沒有XML那么通用性；
B.JSON格式目前在Web Service中推廣還屬于初級階段。
解析方式:
A.傳統(tǒng)的使用JSONObject進行解析
B.Gson
C.FastJson
XML和JSON的優(yōu)缺點對比
(1).可讀性方面。
JSON和XML的數據可讀性基本相同，JSON和XML的可讀性可謂不相上下，一邊是建議的語法，一邊是規(guī)范的標簽形式，XML可讀性較好些。
(2).可擴展性方面。
XML天生有很好的擴展性，JSON當然也有，沒有什么是XML能擴展，JSON不能的。
(3).編碼難度方面。
XML有豐富的編碼工具，比如Dom4j、JDom等，JSON也有json.org提供的工具，但是JSON的編碼明顯比XML容易許多，即使不借助工具也能寫出JSON的代碼，可是要寫好XML就不太容易了。
(4).解碼難度方面。
XML的解析得考慮子節(jié)點父節(jié)點，讓人頭昏眼花，而JSON的解析難度幾乎為0。這一點XML輸的真是沒話說。
(5).流行度方面。
XML已經被業(yè)界廣泛的使用，而JSON才剛剛開始，但是在Ajax這個特定的領域，未來的發(fā)展一定是XML讓位于JSON。到時Ajax應該變成Ajaj(Asynchronous Javascript and JSON)了。
(6).解析手段方面。
JSON和XML同樣擁有豐富的解析手段。
(7).數據體積方面。
JSON相對于XML來講，數據的體積小，傳遞的速度更快些。
(8).數據交互方面。
JSON與JavaScript的交互更加方便，更容易解析處理，更好的數據交互。
(9).數據描述方面。
JSON對數據的描述性比XML較差。
(10).傳輸速度方面。
JSON的速度要遠遠快于XML。
24.網絡請求
25.MVC、MVP
26.Android屏幕適配方案
27.界面卡頓的原因
Android系統(tǒng)每隔16ms會發(fā)出信號重繪我們的界面(Activity).
為什么是16ms, 因為Android設定的刷新率是60FPS(Frame Per Second), 也就是每秒60幀的刷新率, 約合16ms刷新一次.
例如, 假設我們更新屏幕的背景圖片, 需要24ms來做這次運算. 當系統(tǒng)在第一個16ms時刷新界面, 然而我們的運算還沒有結束, 無法繪出圖片. 當系統(tǒng)隔16ms再發(fā)一次VSYNC信息重繪界面時, 用戶才會看到更新后的圖片. 也就是說用戶是32ms后看到了這次刷新(注意, 并不是24ms). 這就是傳說中的丟幀(dropped frame),丟幀給用戶的感覺就是卡頓, 而且如果運算過于復雜, 丟幀會更多, 導致界面常常處于停滯狀態(tài), 卡到爆.
原因:
1.過于復雜的布局(UI布局層次太深,即布局嵌套太多了, 或是自定義控件的onDraw中有復雜運算)
2.過度繪制(Overdraw)
繪制了多重背景.
繪制了不可見的UI元素.
3.UI線程的復雜運算
4.頻繁的GC
執(zhí)行GC操作的時候，任何線程的任何操作都會需要暫停，等待GC操作完成之后，其他操作才能夠繼續(xù)運行, 故而如果程序頻繁GC, 自然會導致界面卡頓.
28.JVM的內存分布及垃圾回收機制
29.哪些情況會導致OOM？
30.ANR發(fā)生的情況及如何避免
ANR全名Application Not Responding, 也就是"應用無響應". 當操作在一段時間內系統(tǒng)無法處理時, 系統(tǒng)層面會彈出ANR對話框.
原因:
1.5s內無法響應用戶輸入事件(例如鍵盤輸入, 觸摸屏幕等).
2.BroadcastReceiver在10s內無法結束.
造成以上兩種情況的首要原因就是在主線程(UI線程)里面做了太多的阻塞耗時操作, 例如文件讀寫, 數據庫讀寫, 網絡查詢等等.所以解決方法就是不要在主線程(UI線程)里面做繁重的操作.
具體可參考:Android App優(yōu)化之ANR詳解
31.內存泄漏
32.第三方框架
1.Volley
2.Glide的源碼
3.Okhttp的源碼
4.Retrofit的源碼
5.Rxjava的源碼
33.熱更新
1.AndFix
Github上提交不活躍了,不過阿里百川HotFix提供了更為簡便方案,具體請點以下網站:
2.Tinker
3.Robust
新一代熱更新系統(tǒng)Robust，對Android版本無差別兼容。無需發(fā)版就可以做到隨時修改線上bug，快速對重大線上問題作出反應，補丁修補成功率高達99.9%。
優(yōu)勢
支持Android2.3-7.X版本
高兼容性、高穩(wěn)定性，修復成功率高達三個九
補丁下發(fā)立即生效，不需要重新啟動
支持方法級別的修復，包括靜態(tài)方法
支持增加方法和類
支持ProGuard的混淆、內聯、優(yōu)化等操作
4.Amigo
5.Aceso
關于熱更新的對比可參考以下文章:
Android 熱修復專題：支付寶、淘寶、微信、QQ空間、餓了么、美麗說蘑菇街、美團大眾點評方案集合
34.Http、Https相關知識
35.談談對Socket的理解
兩類傳輸協議：TCP、UDP
TCP是Tranfer Control Protocol的 簡稱，是一種面向連接的保證可靠傳輸的協議。通過TCP協議傳輸，得到的是一個順序的無差錯的數據流。發(fā)送方和接收方的成對的兩個socket之間必須建 立連接，以便在TCP協議的基礎上進行通信，當一個socket（通常都是server socket）等待建立連接時，另一個socket可以要求進行連接，一旦這兩個socket連接起來，它們就可以進行雙向數據傳輸，雙方都可以進行發(fā)送 或接收操作。
UDP是User Datagram Protocol的簡稱，是一種無連接的協議，每個數據報都是一個獨立的信息，包括完整的源地址或目的地址，它在網絡上以任何可能的路徑傳往目的地，因此能否到達目的地，到達目的地的時間以及內容的正確性都是不能被保證的。
比較：
UDP：
1.每個數據報中都給出了完整的地址信息，因此無需要建立發(fā)送方和接收方的連接。
2.UDP傳輸數據時是有大小限制的，每個被傳輸的數據報必須限定在64KB之內。
3.UDP是一個不可靠的協議，發(fā)送方所發(fā)送的數據報并不一定以相同的次序到達接收方
TCP：
1.面向連接的協議，在socket之間進行數據傳輸之前必然要建立連接，所以在TCP中需要連接時間。
2.TCP傳輸數據大小限制，一旦連接建立起來，雙方的socket就可以按統(tǒng)一的格式傳輸大的數據。
3.TCP是一個可靠的協議，它確保接收方完全正確地獲取發(fā)送方所發(fā)送的全部數據。
應用：
1.TCP在網絡通信上有極強的生命力，例如遠程連接（Telnet）和文件傳輸（FTP）都需要不定長度的數據被可靠地傳輸。但是可靠的傳輸是要付出代價的，對數據內容正確性的檢驗必然占用計算機的處理時間和網絡的帶寬，因此TCP傳輸的效率不如UDP高。
2.UDP操作簡單，而且僅需要較少的監(jiān)護，因此通常用于局域網高可靠性的分散系統(tǒng)中client/server應用程序。例如視頻會議系統(tǒng)，并不要求音頻視頻數據絕對的正確，只要保證連貫性就可以了，這種情況下顯然使用UDP會更合理一些。
什么是Socket
網絡上的兩個程序通過一個雙向的通訊連接實現數據的交換，這個雙向鏈路的一端稱為一個Socket。Socket通常用來實現客戶方和服務方的連接。Socket是TCP/IP協議的一個十分流行的編程界面，一個Socket由一個IP地址和一個端口號唯一確定。
但是，Socket所支持的協議種類也不光TCP/IP一種，因此兩者之間是沒有必然聯系的。在Java環(huán)境下，Socket編程主要是指基于TCP/IP協議的網絡編程。
Socket通訊的過程
Server端Listen(監(jiān)聽)某個端口是否有連接請求，Client端向Server 端發(fā)出Connect(連接)請求，Server端向Client端發(fā)回Accept（接受）消息。一個連接就建立起來了。Server端和Client 端都可以通過Send，Write等方法與對方通信。
對于一個功能齊全的Socket，都要包含以下基本結構，其工作過程包含以下四個基本的步驟：
1） 創(chuàng)建Socket；
2） 打開連接到Socket的輸入/出流；
3） 按照一定的協議對Socket進行讀/寫操作；
4） 關閉Socket.（在實際應用中，并未使用到顯示的close，雖然很多文章都推薦如此，不過在我的程序中，可能因為程序本身比較簡單，要求不高，所以并未造成什么影響。）
具體使用可參考:
讀懂Java中的Socket編程
36.設計模式
1.單例模式
2.工廠模式
3.觀察者模式
37.版本控制SVN、Git
本文還未整理完成,會繼續(xù)整理
