所謂,君子性非異也,善假于物也！~
那么，本文意在給大家提供快速、全面、高效的面試解決方案；
為大家節(jié)約尋找面試、筆試答案的時間；
讓閱讀本文或收藏本文的開發(fā)者成為Android面試場上的最強王者；
更是為開發(fā)者量身定制立志成為面試官的夢魘而奮斗！
現(xiàn)筆者將自己親身實戰(zhàn)的面試題及收到的面試題總結(jié)并分享答案出來。歡迎各位Developer斧正和指點，也希望看到本文的小伙伴積極提供面試題以供分享，內(nèi)容分為Java和Android兩大篇。
(介于篇幅較長,且長期更新,希望各位開發(fā)者多多支持多多收藏和點贊)
JAVA:
volatitle關(guān)鍵字及其原理?
Volatile是輕量級的synchronized，它在多線程開發(fā)中保證了共享變量的“可見性”。可見性的意思是當(dāng)一個線程修改一個共享變量時，另外一個線程能讀到這個修改的值。它在某些情況下比synchronized的開銷更小，如果一個字段被聲明成volatile，java線程內(nèi)存模型確保所有線程看到這個變量的值是一致的(比較常用的就是單例模式中,對字段的聲明,加上這個關(guān)鍵字)。
Volatile原理:
處理器為了提高處理速度，不直接和內(nèi)存進(jìn)行通訊，而是先將系統(tǒng)內(nèi)存的數(shù)據(jù)讀到內(nèi)部緩存（L1,L2或其他）后再進(jìn)行操作，但操作完之后不知道何時會寫到內(nèi)存，如果對聲明了Volatile變量進(jìn)行寫操作，JVM就會向處理器發(fā)送一條Lock前綴的指令，將這個變量所在緩存行的數(shù)據(jù)寫回到系統(tǒng)內(nèi)存。但是就算寫回到內(nèi)存，如果其他處理器緩存的值還是舊的，再執(zhí)行計算操作就會有問題，所以在多處理器下，為了保證各個處理器的緩存是一致的，就會實現(xiàn)緩存一致性協(xié)議，每個處理器通過嗅探在總線上傳播的數(shù)據(jù)來檢查自己緩存的值是不是過期了，當(dāng)處理器發(fā)現(xiàn)自己緩存行對應(yīng)的內(nèi)存地址被修改，就會將當(dāng)前處理器的緩存行設(shè)置成無效狀態(tài)，當(dāng)處理器要對這個數(shù)據(jù)進(jìn)行修改操作的時候，會強制重新從系統(tǒng)內(nèi)存里把數(shù)據(jù)讀到處理器緩存里。
原理總結(jié) (重點):先將當(dāng)前處理器緩存行的數(shù)據(jù)會寫回到系統(tǒng)內(nèi)存\,其次,這個寫回內(nèi)存的操作會引起在其他CPU里緩存了該內(nèi)存地址的數(shù)據(jù)無效。最后,當(dāng)處理器要對這個數(shù)據(jù)進(jìn)行修改操作的時候，會強制重新從系統(tǒng)內(nèi)存里把數(shù)據(jù)讀到處理器緩存里。如此循環(huán)反復(fù)保證共享變量的值是一致的
synchronize的理解及原理
A: 每個對象有一個監(jiān)視器鎖（monitor）。當(dāng)monitor被占用時就會處于鎖定狀態(tài)，線程執(zhí)行monitorenter指令時嘗試獲取monitor的所有權(quán)，過程如下：
1、如果monitor的進(jìn)入數(shù)為0，則該線程進(jìn)入monitor，然后將進(jìn)入數(shù)設(shè)置為1，該線程即為monitor的所有者。
2、如果線程已經(jīng)占有該monitor，只是重新進(jìn)入，則進(jìn)入monitor的進(jìn)入數(shù)加1.
3.如果其他線程已經(jīng)占用了monitor，則該線程進(jìn)入阻塞狀態(tài)，直到monitor的進(jìn)入數(shù)為0，再重新嘗試獲取monitor的所有權(quán)。
B:執(zhí)行monitorexit的線程必須是objectref所對應(yīng)的monitor的所有者。
指令執(zhí)行時，monitor的進(jìn)入數(shù)減1，如果減1后進(jìn)入數(shù)為0，那線程退出monitor，不再是這個monitor的所有者。其他被這個monitor阻塞的線程可以嘗試去獲取這個 monitor 的所有權(quán)。
可能你看暈了,沒事,附上鏈接:synchronize原理探索
簡述多態(tài)?
? ? ? 多態(tài)就是指程序中定義的引用變量所指向的具體類型和通過該引用變量發(fā)出的方法調(diào)用在編程時并不確定，而是在程序運行期間才確定，即一個引用變量倒底會指向哪個類的實例對象，該引用變量發(fā)出的方法調(diào)用到底是哪個類中實現(xiàn)的方法，必須在由程序運行期間才能決定。簡稱:父類引用指向子類對象
? ? 由多態(tài)引申的概念:向上轉(zhuǎn)型?
? ? 它只能訪問父類中擁有的方法和屬性，而對于子類中存在而父類中不存在的方法，該引用是不能使用的，盡管是重載該方法。若子類重寫了父類中的某些方法，在調(diào)用該些方法的時候，必定是使用子類中定義的這些方法（動態(tài)連接、動態(tài)調(diào)用）。
? ? Java實現(xiàn)多態(tài)有三個必要條件：繼承、重寫、向上轉(zhuǎn)型。
? ? 更詳細(xì)的說明和補充可以點擊這里了解多態(tài)
對Java的理解?
? ? ?可以從面向?qū)ο蟆?a target="_blank">分布式、健壯性、安全性、平臺獨立與可移植性、多線程、動態(tài)性等特點。Java可以編寫桌面應(yīng)用程序、Web應(yīng)用程序、分布式系統(tǒng)和嵌入式系統(tǒng)應(yīng)用程序,Android開發(fā)等等回答.
抽象類與接口的聯(lián)系與區(qū)別?
相同點:
都不能直接實例化,
接口的實現(xiàn)類或抽象類的子類都只有實現(xiàn)了接口或抽象類中的方法后才能被實例化
區(qū)別:
1、抽象類變量必須指向?qū)崿F(xiàn)所有抽象方法的子類對象，接口變量必須指向?qū)崿F(xiàn)所有接口方法的類對象。
2、抽象類要被子類繼承，接口要被類實現(xiàn)。
3、接口只能做方法申明，抽象類中可以做方法申明，也可以做方法實現(xiàn)
4、接口里定義的變量只能是公共的靜態(tài)的常量，抽象類中的變量是普通變量。
5、抽象類里的抽象方法必須全部被子類所實現(xiàn)，如果子類不能全部實現(xiàn)父類抽象方法，那么該子類只能是抽象類。同樣，一個實現(xiàn)接口的時候，如不能全部實現(xiàn)接口方法，那么該類也只能為抽象類。
6、抽象方法只能申明，不能實現(xiàn)。abstract void abc();不能寫成abstract void abc(){}。
7、抽象類里可以沒有抽象方法
8、如果一個類里有抽象方法，那么這個類只能是抽象類
9、抽象方法要被實現(xiàn)，所以不能是靜態(tài)的，也不能是私有的。
10、接口可繼承接口，并可多繼承接口，但類只能單根繼承。
綜述 : 特別是對于公用的實現(xiàn)代碼，抽象類有它的優(yōu)點。抽象類能夠保證實現(xiàn)的層次關(guān)系，避免代碼重復(fù)。然而，即使在使用抽 象類的場合，也不要忽視通過接口定義行為模型的原則。從實踐的角度來看，如果依賴于抽象類來定義行為，往往導(dǎo)致過于復(fù)雜的繼承關(guān)系，而通過接口定義行為能 夠更有效地分離行為與實現(xiàn)，為代碼的維護(hù)和修改帶來方便。
float f=2.3;是否正確?
不正確。2.3是雙精度數(shù)，將雙精度型(double)賦值給浮點型(float)屬于下轉(zhuǎn)型(down-casting，也稱為窄化)會造成精度損失，因此需要強制類型轉(zhuǎn)換float f =(float)2.3; 或者寫成float f =2.3F;。
short s1 = 1; s1 = s1 + 1;有錯嗎?short s1 = 1; s1 += 1;有錯嗎?
對于short s1 = 1; s1 = s1 + 1;由于1是int類型，因此s1+1運算結(jié)果也是int 型，需要強制轉(zhuǎn)換類型才能賦值給short型。而short s1 = 1; s1 += 1;可以正確編譯，因為s1+= 1;相當(dāng)于s1 = (short)(s1 + 1);其中有隱含的強制類型轉(zhuǎn)換。
當(dāng)一個對象被當(dāng)作參數(shù)傳遞到一個方法后，此方法可改變這個對象的屬性，并可返回變化后的結(jié)果，那么這里到底是值傳遞還是引用傳遞?
值傳遞。Java語言的方法調(diào)用只支持參數(shù)的值傳遞。當(dāng)一個對象實例作為一個參數(shù)被傳遞到方法中時，參數(shù)的值就是對該對象的引用。對象的屬性可以在被調(diào)用過程中被改變，但對對象引用的改變是不會影響到調(diào)用者的。
如何保證線程安全?
簡單來說，線程安全就是：在多線程環(huán)境中，能永遠(yuǎn)保證程序的正確性。因此,只有存在共享數(shù)據(jù)時才需要考慮線程安全問題。
解決方案1:Java多線程支持引入同步監(jiān)視器來解決這個問題,使用同步監(jiān)視器的通用方法就是同步代碼塊,使用synchronize(obj)代碼塊,(目的:任何時刻只能有一個線程可以獲得對同步監(jiān)視器的鎖定,當(dāng)同步代碼塊執(zhí)行完成后,該線程會釋放對該同步監(jiān)視器的鎖定) 推薦使用可能被并發(fā)訪問的共享資源充當(dāng)同步監(jiān)視器,邏輯大概就是 ? 加鎖-->修改-->釋放鎖?
解決方案2:通過顯示定義同步鎖對象實現(xiàn)同步,在這種機制下,同步鎖用Lock對象充當(dāng),Lock允許實現(xiàn)更靈活的結(jié)構(gòu),有差別很大的屬性,使用Lock對象來進(jìn)行同步,加鎖和釋放鎖出現(xiàn)在不同的作用范圍內(nèi),通常建議使用finally塊來確保在必要時候釋放鎖
簡述Java中為什么會出現(xiàn)死鎖?
當(dāng)兩個線程相互等待對方釋放同步監(jiān)視器時就會發(fā)生死鎖,Java虛擬機沒有監(jiān)測也沒有采取措施來處理死鎖情況,所以多線程編程時應(yīng)該采取措施避免死鎖出現(xiàn).一旦出現(xiàn)死鎖,整個程序既不會發(fā)生任何異常,也不會給出任何提示,只是所有線程處于阻塞狀態(tài),無法繼續(xù).
簡述Java中的四種引用?
1) 強引用（StrongReference）
強引用是使用最普遍的引用。比如new 對象等等,如果一個對象具有強引用，那垃圾回收器絕不會回收它。當(dāng)內(nèi)存空間不足，Java虛擬機寧愿拋出OutOfMemoryError錯誤，使程序異常終止，也不會靠隨意回收具有強引用的對象來解決內(nèi)存不足的問題。
2) 軟引用（SoftReference）
如果一個對象只具有軟引用，則內(nèi)存空間足夠，垃圾回收器就不會回收它；如果內(nèi)存空間不足了，就會回收這些對象的內(nèi)存。軟引用可用來實現(xiàn)內(nèi)存敏感的高速緩存。
3) 弱引用（WeakReference）
在java中，用java.lang.ref.WeakReference類來表示弱引用. ?與軟引用的區(qū)別在于：弱引用的對象擁有更短暫的生命周期。在垃圾回收器線程掃描它所管轄的內(nèi)存區(qū)域的過程中，一旦發(fā)現(xiàn)了只具有弱引用的對象，不管當(dāng)前內(nèi)存空間足夠與否，都會回收它的內(nèi)存。不過，由于垃圾回收器是一個優(yōu)先級很低的線程，因此不一定會很快發(fā)現(xiàn)那些只具有弱引用的對象。
4)虛引用（PhantomReference）
“虛引用”顧名思義，就是形同虛設(shè)，與其他幾種引用都不同，虛引用并不會決定對象的生命周期。在java中用java.lang.ref.PhantomReference類表示。
強引用置為null,會不會被回收?
只要是強引用就證明這個內(nèi)存是在的，但是置為null,因此回收器在適當(dāng)?shù)臅r候回收,什么是適當(dāng)時候，大體是使用內(nèi)存占申請內(nèi)存75%的時候，就啟動回收線程。（關(guān)于申請內(nèi)存75% 這個結(jié)論，筆者是查了一些資料）
如何保證多線程讀寫文件的安全?
加鎖,可以參考上面的線程安全
單例模式的常見寫法和優(yōu)缺點分析?
懶漢式：
第一次獲取單例類的實例時創(chuàng)建。(優(yōu)點:寫法簡單，且不存在多線程同步問題，避免了synchronized所造成的性能問題；缺點是：初始化類的時候就需要構(gòu)造實例，（即便你還沒有用到這個實例），因此在某些特定條件下會耗費內(nèi)存。)
餓漢式：
在類被加載的時候創(chuàng)建單例類的對象，類加載器負(fù)責(zé)加載類，并會保證只有一個線程在實例化單例類， (優(yōu)點：這種寫法比較簡單，就是在類裝載的時候就完成實例化。避免了線程同步問題。缺點：在類裝載的時候就完成實例化，沒有達(dá)到Lazy Loading的效果。如果從始至終從未使用過這個實例，則會造成內(nèi)存的浪費。)
單例模式個人覺得最經(jīng)典在項目里經(jīng)常使用的寫法（也稱雙重鎖機制）：
更多細(xì)節(jié)可以參考單例模式的8種寫法
單例模式的拓展？
1：使用靜態(tài)內(nèi)部類 實現(xiàn)單例模式
第一次加載Singleton類時并不會初始化sInstance，只有第一次調(diào)用getInstance方法時虛擬機加載SingletonHolder 并初始化sInstance ，這樣不僅能確保線程安全也能保證Singleton類的唯一性，在《java并發(fā)編程實踐》一書中推薦使用靜態(tài)內(nèi)部類單例模式。當(dāng)然，可以根據(jù)個人偏好去使用
2：使用容器 實現(xiàn)單例模式
用SingletonManager 將多種的單例類統(tǒng)一管理，在使用時根據(jù)key獲取對象對應(yīng)類型的對象，代碼可讀性強。這種方式使得我們可以管理多種類型的單例，并且在使用時可以通過統(tǒng)一的接口進(jìn)行獲取操作，降低了用戶的使用成本，也對用戶隱藏了具體實現(xiàn)，降低了耦合度。
StringBuffer和StringBuilder的區(qū)別?
StringBuilder：線程非安全的,但是效率高
StringBuffer：線程安全的,效率相對較低
.單線程操作字符串緩沖區(qū)下操作大量數(shù)據(jù)推薦使用:StringBuilder
?多線程操作字符串緩沖區(qū)下操作大量數(shù)據(jù)推薦使用:StringBuffer
數(shù)組和鏈表的區(qū)別？
答：二者都屬于一種數(shù)據(jù)結(jié)構(gòu)
從邏輯結(jié)構(gòu)來看
1. 數(shù)組必須事先定義固定的長度（元素個數(shù)），不能適應(yīng)數(shù)據(jù)動態(tài)地增減的情況。當(dāng)數(shù)據(jù)增加時，可能超出原先定義的元素個數(shù)；當(dāng)數(shù)據(jù)減少時，造成內(nèi)存浪費；數(shù)組可以根據(jù)下標(biāo)直接存取。
2. 鏈表動態(tài)地進(jìn)行存儲分配，可以適應(yīng)數(shù)據(jù)動態(tài)地增減的情況，且可以方便地插入、刪除數(shù)據(jù)項。（數(shù)組中插入、刪除數(shù)據(jù)項時，需要移動其它數(shù)據(jù)項，非常繁瑣）鏈表必須根據(jù)next指針找到下一個元素
從內(nèi)存存儲來看
1. (靜態(tài))數(shù)組從棧中分配空間, 對于程序員方便快速,但是自由度小
2. 鏈表從堆中分配空間, 自由度大但是申請管理比較麻煩
從上面的比較可以看出，如果需要快速訪問數(shù)據(jù)，很少或不插入和刪除元素，就應(yīng)該用數(shù)組；相反， 如果需要經(jīng)常插入和刪除元素就需要用鏈表數(shù)據(jù)結(jié)構(gòu)了。
HashMap?
TreeMap
LinkedHashMap
HashMap中的元素是沒有順序的 基于hash表實現(xiàn) ;使用HashMap定義了hashcode() 和equals()方法
TreeMap中所有的元素有某一固定順序 基于紅黑樹實現(xiàn) 要改變其排序可以自己寫一個Comparator（比較器）
HashMap TreeMap都不是線程安全的
LinkedHashMap有序，繼承HashMap LinkedHashMap也是線程不安全的
HashMap 內(nèi)部的 Node 數(shù)組默認(rèn)的大小是16 ，loadFactor 為0.75；當(dāng) HashMap 中的元素超過16\0.75=12時，會把數(shù)組大小擴展為2*16=32
HashMap為什么不安全？
1：多個線程同時使用put方法添加元素，這兩個 key 會添加到數(shù)組的同一個位置，
這樣最終就會發(fā)生其中一個線程的 put 的數(shù)據(jù)被覆蓋
2：HashMap 在并發(fā)執(zhí)行 put 操作時會引起死循環(huán)，導(dǎo)致 CPU 利用率接近100%。
ConcurrentHashMap、Hashtable 是線程安全的
線程和進(jìn)程的區(qū)別?
進(jìn)程有獨立的地址空間，一個進(jìn)程崩潰后，在保護(hù)模式下不會對其它進(jìn)程產(chǎn)生影響，
而線程只是一個進(jìn)程中的不同執(zhí)行路徑。線程有自己的堆棧和局部變量，但線程之間沒有單獨的地址空間，一個線程死掉就等于整個進(jìn)程死掉，所以多進(jìn)程的程序要比多線程的程序健壯，但在進(jìn)程切換時，耗費資源較大，效率要差一些。但對于一些要求同時進(jìn)行并且又要共享某些變量的并發(fā)操作，只能用線程，不能用進(jìn)程。
1) 簡而言之,一個程序至少有一個進(jìn)程,一個進(jìn)程至少有一個線程.
2) 線程的劃分尺度小于進(jìn)程，使得多線程程序的并發(fā)性高。
3) 另外，進(jìn)程在執(zhí)行過程中擁有獨立的內(nèi)存單元，而多個線程共享內(nèi)存，從而極大地提高了程序的運行效率。
4) 線程在執(zhí)行過程中與進(jìn)程還是有區(qū)別的。每個獨立的線程有一個程序運行的入口、順序執(zhí)行序列和程序的出口。但是線程不能夠獨立執(zhí)行，必須依存在應(yīng)用程序中，由應(yīng)用程序提供多個線程執(zhí)行控制。
5) 從邏輯角度來看，多線程的意義在于一個應(yīng)用程序中，有多個執(zhí)行部分可以同時執(zhí)行。但操作系統(tǒng)并沒有將多個線程看做多個獨立的應(yīng)用，來實現(xiàn)進(jìn)程的調(diào)度和管理以及資源分配。這就是進(jìn)程和線程的重要區(qū)別。
線程池的概念以及應(yīng)用場景?
多線程編程下如果并發(fā)的線程數(shù)量很多，并且每個線程都是執(zhí)行一個時間很短的任務(wù)就結(jié)束了，這樣頻繁創(chuàng)建線程就會大大降低系統(tǒng)的效率，因為頻繁創(chuàng)建線程和銷毀線程需要時間。那么有沒有一種辦法使得線程可以復(fù)用，就是執(zhí)行完一個任務(wù)，并不被銷毀，而是可以繼續(xù)執(zhí)行其他的任務(wù),線程池技術(shù)的出現(xiàn)就很好的解決了上面問題,可以更好的提供性能,并有效控制系統(tǒng)中并發(fā)線程的數(shù)量(線程池的最大線程數(shù)參數(shù)可以控制系統(tǒng)中并發(fā)線程數(shù)不超過此數(shù))
關(guān)鍵字:ThreadPoolExecutor
Session 、Cookie?、Token相關(guān)?
Cookie:? 它是保存在本地終端的數(shù)據(jù)。cookie由服務(wù)器生成，發(fā)送給瀏覽器，瀏覽器把cookie以key - Value 形式保存到某個目錄下的文本文件內(nèi)，下一次請求同一網(wǎng)站時會把該cookie發(fā)送給服務(wù)器。由于cookie是存在客戶端上的，所以瀏覽器加入了一些限制確保cookie不會被惡意使用，同時不會占據(jù)太多磁盤空間，所以每個域的cookie數(shù)量是有限的.(Cookie的作用是為了解決HTTP協(xié)議無狀態(tài)的缺陷所作的努力)
cookie的內(nèi)容主要包括：名字、值、過期時間、路徑和域。
路徑與域一起構(gòu)成cookie的作用范圍。
若不設(shè)置過期時間，則表示這個cookie的生命期為瀏覽器會話期間，關(guān)閉瀏覽器窗口，cookie就消失。這種生命期為瀏覽器會話期的cookie被稱為會話cookie.會話cookie一般不存儲在硬盤上而是保存在內(nèi)存里，當(dāng)然這種行為 并不是規(guī)范規(guī)定的。
若設(shè)置了過期時間，瀏覽器就會把cookie保存在硬盤上，關(guān)閉后再次打開瀏覽器，這些cookie仍然有效直到超過設(shè)定的過期時間。存儲在硬盤上的cookie可以在不同的瀏覽器進(jìn)程間共享，比如兩個IE窗口。而對于保存在內(nèi)存里cookie，不同的瀏覽器有不同的處理方式。
Session :? session的中文翻譯是“會話”，當(dāng)用戶打開某個web應(yīng)用時，便與web服務(wù)器產(chǎn)生一次session。
簡單的理解就是 : 服務(wù)器要知道當(dāng)前發(fā)請求給自己的是誰。為了做這種區(qū)分，服務(wù)器就要給每個客戶端分配不同的“身份標(biāo)識”，然后客戶端每次向服務(wù)器發(fā)請求的時候，都帶上這個“身份標(biāo)識”，服務(wù)器就知道這個請求來自于誰了。
?服務(wù)器使用session把用戶的信息臨時保存在了服務(wù)器上，用戶離開網(wǎng)站后session會被銷毀。這種用戶信息存儲方式相對Cookie來說更安全 . 但是session有一個缺陷：如果web服務(wù)器做了負(fù)載均衡，那么下一個操作請求到了另一臺服務(wù)器的時候session會丟失。
Token: (英譯漢 : 象征; 記號; 代幣;)
token是用戶身份的驗證方式，最簡單的token組成:uid(用戶唯一的身份標(biāo)識)、time(當(dāng)前時間的時間戳)、sign(簽名，由token的前幾位+鹽以哈希算法壓縮成一定長的十六進(jìn)制字符串，可以防止惡意第三方拼接token請求服務(wù)器)。還可以把不變的參數(shù)也放進(jìn)token，避免多次查庫
Cookie和Session的區(qū)別
1、cookie數(shù)據(jù)存放在客戶的瀏覽器上，session數(shù)據(jù)放在服務(wù)器上。
2、cookie不是很安全，別人可以分析存放在本地的cookie并進(jìn)行cookie欺騙,考慮到安全應(yīng)當(dāng)使用session。
3、session會在一定時間內(nèi)保存在服務(wù)器上。當(dāng)訪問增多，會比較占用你服務(wù)器的性能,考慮到減輕服務(wù)器性能方面，應(yīng)當(dāng)使用cookie。
4、單個cookie保存的數(shù)據(jù)不能超過4K，很多瀏覽器都限制一個站點最多保存20個cookie。
5、所以個人建議：
將登陸信息等重要信息存放為session
其他信息如果需要保留，可以放在cookie中
Token 和 Session 的區(qū)別
session和 token并不矛盾，作為身份認(rèn)證token安全性比session好，因為每個請求都有簽名還能防止監(jiān)聽以及重放攻擊，而session就必須靠鏈路層來保障通訊安全了。如上所說，如果你需要實現(xiàn)有狀態(tài)的會話，仍然可以增加session來在服務(wù)器端保存一些狀態(tài)
App通常用restful api跟server打交道。Rest是stateless的，也就是app不需要像browser那樣用cookie來保存session,因此用session token來標(biāo)示自己就夠了，session/state由api server的邏輯處理。如果你的后端不是stateless的rest api,那么你可能需要在app里保存session.可以在app里嵌入webkit,用一個隱藏的browser來管理cookie session.
Session是一種HTTP存儲機制，目的是為無狀態(tài)的HTTP提供的持久機制。所謂Session認(rèn)證只是簡單的把User信息存儲到Session里，因為SID的不可預(yù)測性，暫且認(rèn)為是安全的。這是一種認(rèn)證手段。而Token，如果指的是OAuth Token或類似的機制的話，提供的是 認(rèn)證 和 授權(quán) ，認(rèn)證是針對用戶，授權(quán)是針對App。其目的是讓 某App有權(quán)利訪問 某用戶 的信息。這里的Token是唯一的。不可以轉(zhuǎn)移到其它App上，也不可以轉(zhuǎn)到其它 用戶 上。轉(zhuǎn)過來說Session。Session只提供一種簡單的認(rèn)證，即有此SID，即認(rèn)為有此User的全部權(quán)利。是需要嚴(yán)格保密的，這個數(shù)據(jù)應(yīng)該只保存在站方，不應(yīng)該共享給其它網(wǎng)站或者第三方App。所以簡單來說，如果你的用戶數(shù)據(jù)可能需要和第三方共享，或者允許第三方調(diào)用API接口，用Token。如果永遠(yuǎn)只是自己的網(wǎng)站，自己的App，用什么就無所謂了。
token就是令牌，比如你授權(quán)（登錄）一個程序時，他就是個依據(jù)，判斷你是否已經(jīng)授權(quán)該軟件；cookie就是寫在客戶端的一個txt文件，里面包括你登錄信息之類的，這樣你下次在登錄某個網(wǎng)站，就會自動調(diào)用cookie自動登錄用戶名；session和cookie差不多，只是session是寫在服務(wù)器端的文件，也需要在客戶端寫入cookie文件，但是文件里是你的瀏覽器編號.Session的狀態(tài)是存儲在服務(wù)器端，客戶端只有session id；而Token的狀態(tài)是存儲在客戶端。
Http,Https相關(guān)?
Http:?(HTTP-Hypertext transfer protocol)又稱:超文本傳輸協(xié)議 , 是一種詳細(xì)規(guī)定了瀏覽器和萬維網(wǎng)服務(wù)器之間互相通信的規(guī)則，通過因特網(wǎng)傳送萬維網(wǎng)文檔的數(shù)據(jù)傳送協(xié)議。
Https:（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全為目標(biāo)的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎(chǔ)是SSL，因此加密的詳細(xì)內(nèi)容就需要SSL。Https情況下,電腦與服務(wù)器之間收發(fā)的信息傳輸將更加安全。
HTTP協(xié)議的主要特點可概括如下：
1.支持客戶/服務(wù)器模式。
2.簡單快速：客戶向服務(wù)器請求服務(wù)時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規(guī)定了客戶與服務(wù)器聯(lián)系的類型不同。由于HTTP協(xié)議簡單，使得HTTP服務(wù)器的程序規(guī)模小，因而通信速度很快。
3.靈活：HTTP允許傳輸任意類型的數(shù)據(jù)對象。正在傳輸?shù)念愋陀蒀ontent-Type加以標(biāo)記。
4.無連接：無連接的含義是限制每次連接只處理一個請求。服務(wù)器處理完客戶的請求，并收到客戶的應(yīng)答后，即斷開連接。采用這種方式可以節(jié)省傳輸時間。
5.無狀態(tài)：HTTP協(xié)議是無狀態(tài)協(xié)議。無狀態(tài)是指協(xié)議對于事務(wù)處理沒有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。另一方面，在服務(wù)器不需要先前信息時它的應(yīng)答就較快。
加密相關(guān):
對稱加密:
采用單鑰密碼系統(tǒng)的加密方法，同一個密鑰可以同時用作信息的加密和解密(注意:是同一個密鑰)，這種加密方法稱為對稱加密，也稱為單密鑰加密。所謂對稱，就是采用這種加密方法的雙方使用方式用同樣的密鑰進(jìn)行加密和解密。密鑰是控制加密及解密過程的指令。算法是一組規(guī)則，規(guī)定如何進(jìn)行加密和解密。因此,加密的安全性不僅取決于加密算法本身，密鑰管理的安全性更是重要。因為加密和解密都使用同一個密鑰，如何把密鑰安全地傳遞到解密者手上就成了必須要解決的問題。在對稱加密中，數(shù)據(jù)發(fā)送方將明文（原始數(shù)據(jù)）和加密密鑰一起經(jīng)過特殊加密算法處理后，使其變成復(fù)雜的加密密文發(fā)送出去。接收方收到密文后，若想解讀原文，則需要使用加密密鑰及相同算法的逆算法對密文進(jìn)行解密，才能使其恢復(fù)成可讀明文。在對稱加密算法中，使用的密鑰只有一個，發(fā)收信雙方都使用這個密鑰對數(shù)據(jù)進(jìn)行加密和解密。
對稱加密算法的優(yōu)點 ? ?: ? ?算法公開、計算量小、加密速度快、加密效率高。
對稱加密算法的缺點 ? ?: ? ?在數(shù)據(jù)傳送前，發(fā)送方和接收方必須商定好秘鑰，然后使雙方都能保存好秘鑰。其次如果一方的秘鑰被泄露，那么加密信息也就不安全了。另外，每對用戶每次使用對稱加密算法時，都需要使用其他人不知道的唯一秘鑰，這會使得收、發(fā)雙方所擁有的鑰匙數(shù)量巨大，密鑰管理成為雙方的負(fù)擔(dān)。
對稱加密算法中常用的算法有：DES、3DES、TDEA、Blowfish、RC2、RC4、RC5、IDEA、SKIPJACK、AES等
非對稱加密:
對稱加密算法在加密和解密時使用的是同一個秘鑰；
這兩個秘鑰是公開密鑰（public key，簡稱公鑰）和私有密鑰（private key，簡稱私鑰）。
公開密鑰與私有密鑰是一對，如果用公開密鑰對數(shù)據(jù)進(jìn)行加密，只有用對應(yīng)的私有密鑰才能解密；如果用私有密鑰對數(shù)據(jù)進(jìn)行加密，那么只有用對應(yīng)的公開密鑰才能解密。因為加密和解密使用的是兩個不同的密鑰，所以這種算法叫作非對稱加密算法。
非對稱加密與對稱加密相比，其安全性更好：對稱加密的通信雙方使用相同的秘鑰，如果一方的秘鑰遭泄露，那么整個通信就會被破解。而非對稱加密使用一對秘鑰，一個用來加密，一個用來解密，而且公鑰是公開的，秘鑰是自己保存的，不需要像對稱加密那樣在通信之前要先同步秘鑰。
非對稱加密的缺點是加密和解密花費時間長、速度慢，只適合對少量數(shù)據(jù)進(jìn)行加密。
在非對稱加密中使用的主要算法有：RSA、Elgamal、背包算法、Rabin、D-H、ECC（橢圓曲線加密算法）等。
MD5:?
MD5是一種信息摘要算法, 消息摘要是一種與消息認(rèn)證碼結(jié)合使用以確保消息完整性的技術(shù)。主要使用單向散列函數(shù)算法，可用于檢驗消息的完整性，和通過散列密碼直接以文本形式保存等，目前廣泛使用的算法有MD4、MD5、SHA-1。
ANR相關(guān)?
ANR全名Application Not Responding, 也就是"應(yīng)用無響應(yīng)". 當(dāng)操作在一段時間內(nèi)系統(tǒng)無法處理時, 系統(tǒng)層面會彈出上圖那樣的ANR對話框.
在Android里, App的響應(yīng)能力是由Activity Manager和Window Manager系統(tǒng)服務(wù)來監(jiān)控的. 通常在如下兩種情況下會彈出ANR對話框:
A) 5s內(nèi)無法響應(yīng)用戶輸入事件(例如鍵盤輸入, 觸摸屏幕等).
B) BroadcastReceiver在10s內(nèi)無法結(jié)束.
造成以上兩種情況的首要原因就是在主線程(UI線程)里面做了太多的阻塞耗時操作, 例如文件讀寫, 數(shù)據(jù)庫讀寫, 網(wǎng)絡(luò)查詢等等.
(持續(xù)更新.......)
Android:
今日頭條屏幕適配的原理？
1：首先計算出?density，計算公式：
當(dāng)前設(shè)備屏幕總寬度（單位為像素）/ 設(shè)計圖總寬度（單位為 dp) = density
density?的意思就是?1 dp?占當(dāng)前設(shè)備多少像素
計算density?的原因：在布局文件中填寫的是什么單位，最后都會被轉(zhuǎn)化為?px，系統(tǒng)就是通過上面的方法，將你在項目中任何地方填寫的單位都轉(zhuǎn)換為?px?
但是，今日頭條適配方案默認(rèn)項目中只能以高或?qū)捴械囊粋€作為基準(zhǔn)，來進(jìn)行適配
簡述Android中的加固和使用平臺?
加固:防止代碼反編譯,提高代碼安全性
加固三方平臺,梆梆安全,360加固,愛加密等
區(qū)別:梆梆安全,360加固看不到項目中的類,愛加密看的到Java類,單看不到里面的方法實現(xiàn)體,效果比前面差一點點
加固的底層原理:第三方加固的應(yīng)用會生成一個Apk,然后把你的APK讀取出來,在封裝到這個第三方應(yīng)用的APK里面.
如何對APK瘦身?
1)使用混淆,
2)開啟shrinkResourse(shrink-收縮),會將沒有用到的圖片變成一個像素點
3)刪除無用的語言資源(刪除國際化文件)
4)對于非透明的大圖,使用JPG(沒有透明度信息),代替PNG格式
5)使用tinypng進(jìn)行圖片壓縮
6)使用webp圖片格式,進(jìn)一步壓縮圖片資源
7)使用第三方包時把用到的代碼加到項目中來,避免引用整一個第三方庫
簡述多渠道打包及原理和常用操作?
針對每一個渠道(應(yīng)用市場)都生成一個帶有渠道標(biāo)識的apk文件
原理:用戶下載啟動應(yīng)用,獲取渠道標(biāo)識,和設(shè)備的唯一標(biāo)識,并上傳到服務(wù)器里面,服務(wù)器這里就 會根據(jù)獲取的記錄,根據(jù)渠道號然后判斷是否存在該服務(wù)器的表里面.(打標(biāo)記,取標(biāo)記,上傳標(biāo)記)
1)友盟多渠道打包:在清單文件中定義一個占位符,在gradle腳本中替換占位符(會使用到Python)
2)美團打包,在meta-data中創(chuàng)建一個空的文件,以文件名標(biāo)識渠道,做一個解壓與壓縮的操作,速度會比較快
3)新一代多渠道打包,將渠道標(biāo)識添加到.apk文件的末尾,并不會對源文件損壞
Android下的數(shù)據(jù)存儲方式有那些?
1)內(nèi)部存儲,直接存儲在內(nèi)部文件中
2)外部存儲,首先要判斷外部存儲條件是否可用,然后進(jìn)行存儲
3)SP存儲,底層是Xml實現(xiàn)的,以鍵值對形式存儲內(nèi)部的數(shù)據(jù),適宜于輕量級的存儲,存儲的數(shù)據(jù)類型有,boolean,String,int
4)數(shù)據(jù)庫存儲,SQlite存儲,輕量級的數(shù)據(jù)庫,強大的增刪改查功能
5)內(nèi)容提供者,ContentProvider,將自己愿意暴露的一部分?jǐn)?shù)據(jù)供外部使用操作
6)網(wǎng)絡(luò)存儲,等等
Sharepreference 線程安全問題？
官方文檔明確指出，SharedPreferences不支持多線程，進(jìn)程也是不安全的
如果想要實現(xiàn)線程安全需重新實現(xiàn)其接口，如下
假設(shè)在多進(jìn)程訪問SharePreferences的情況下，該如何保證進(jìn)程安全和共享數(shù)據(jù)?
解決辦法就是：將需要共享數(shù)據(jù)的字段提出來統(tǒng)一存儲到一個文件中。
Android開發(fā)下如何有效進(jìn)行屏幕適配?
1:機型適配，去一些統(tǒng)計網(wǎng)站諸如友盟,現(xiàn)在叫友盟+去看一下市場上最流行的Android機型,有針對性的切圖
2:屏幕適配，適配主流xhdpi屏幕尺寸，使用relativelayout，linerlayout等布局，多使用matchparent，wrapcontent，及配合weight,權(quán)重處理，
3:還有就是在代碼中，設(shè)計到具體尺寸的要使用dp2px的轉(zhuǎn)換，
4:圖片使用可拉伸.9圖片，imageview使用scaletype縮放；
5:使用權(quán)重,等比例,百分比布局等等
對象序列化：
為什么要序列化？
1）永久性保存對象，保存對象的字節(jié)序列到本地文件中；
2）通過序列化對象在網(wǎng)絡(luò)中傳遞對象；
3）通過序列化在進(jìn)程間傳遞對象。
在Android中實現(xiàn)序列化有兩個選擇：一是實現(xiàn)Serializable接口（是JavaSE本身就支持的），一是實現(xiàn)Parcelable接口（是Android特有功能，效率比實現(xiàn)Serializable接口高效，可用于Intent數(shù)據(jù)傳遞，也可以用于進(jìn)程間通信（IPC））。實現(xiàn)Serializable接口非常簡單，聲明一下就可以了，而實現(xiàn)Parcelable接口稍微復(fù)雜一些，但效率更高，推薦用這種方法提高性能。兩種實現(xiàn)方式依舊是貼url，方便大家快速查詢
既然Google推薦Parcelable這種序列化，在這里，推薦一鍵生成序列化的插件，
在Android Studio里面搜索插件，如下圖，寫起序列化（根本不用你寫）那就是一個美滋滋吶~
OkHttp相關(guān)?
OkHttp支持同步和異步數(shù)據(jù)請求，但異步請求是在子線程 (因為原生OkHttp的使用時回調(diào)方法是在子線程進(jìn)行的，要刷新界面還需要用Handler作處理，可以使用第三方的okhttp-utils,Okgo等等)；
OkHttp里面封裝了線程池、數(shù)據(jù)轉(zhuǎn)換、GZIP壓縮（減少流量的傳輸）、HTTP協(xié)議緩存等,
OKHttp優(yōu)點---使用GZip壓縮減少傳輸?shù)臄?shù)據(jù)量,緩存(減少重復(fù)請求);
失敗重試(如果你的服務(wù)有多個IP地址,如果第一次連接失敗,OKHttp將使用備用地址)
OKhttp是對http協(xié)議的封裝,比較底層,因此拓展性強,便于封裝;
OKhttp基于NIO(JDK1.5,非阻塞式IO)效率更高
ButterKnife相關(guān)?
簡介：
一款快速高效的注入框架，節(jié)約開發(fā)時間減少代碼量（依靠插件動態(tài)生成View,點擊事件等等）
優(yōu)點：
1.強大的View綁定和Click事件處理功能，簡化代碼，提升開發(fā)效率
2.方便的處理Adapter里的ViewHolder綁定問題
3.運行時不會影響APP效率，使用配置方便
4.代碼清晰，可讀性強
使用經(jīng)驗：
1.Activity ButterKnife.bind(this);必須在setContentView();之后，且父類bind綁定后，子類不需要再bind
2.Fragment ButterKnife.bind(this, mRootView);
3.屬性布局不能用private or static 修飾，否則會報錯，（注意權(quán)限）
4.setContentView()不能通過注解實現(xiàn)。（其他的有些注解框架可以）
原理：利用注解和反射去獲取綁定ViewID,
關(guān)于原理詳情可參考筆者的這一篇:Android-定制專屬ButterKnife框架,該文詳細(xì)介紹了ButterKnife框架并模仿了一個注解綁定View的框架
Rxjava概念,常用操作符及拓展?
簡介：
一款優(yōu)雅的異步框架,代替之前的AsyncTask / Handler / XXX / ...?
其強大的操作符和鏈?zhǔn)綄懛?線程切換等有助于提高開發(fā)效率和快速定位Bug
與Retrofit搭配使用更是有意想不到的效果，
底層原理：觀察者模式
如何使用：Rxjava涉及的內(nèi)容太多太多,只能說推薦引導(dǎo)大家看下這篇?Rxjava2相關(guān)?等一些相應(yīng)的博客
缺點：
1：操作符太多會增加學(xué)習(xí)成本時間
2：使用不好，容易導(dǎo)致內(nèi)存泄露(解決方式，推薦Rxlifecycle結(jié)合Rxjava，規(guī)避內(nèi)存泄漏風(fēng)險)
(持續(xù)更新.......)
ANR相關(guān)?
ANR全名Application Not Responding, 也就是"應(yīng)用無響應(yīng)". 當(dāng)操作在一段時間內(nèi)系統(tǒng)無法處理時, 系統(tǒng)層面會彈出上圖那樣的ANR對話框.
在Android里, App的響應(yīng)能力是由Activity Manager和Window Manager系統(tǒng)服務(wù)來監(jiān)控的. 通常在如下兩種情況下會彈出ANR對話框:
A) 5s內(nèi)無法響應(yīng)用戶輸入事件(例如鍵盤輸入, 觸摸屏幕等).
B) BroadcastReceiver在10s內(nèi)無法結(jié)束.
造成以上兩種情況的首要原因就是在主線程(UI線程)里面做了太多的阻塞耗時操作, 例如文件讀寫, 數(shù)據(jù)庫讀寫, 網(wǎng)絡(luò)查詢等等.
如何分析ANR?
ANR產(chǎn)生時, 系統(tǒng)會生成一個traces.txt的文件放在/data/anr/下. 開發(fā)人員可通過adb命令將其導(dǎo)出到本地 ($adb pull data/anr/traces.txt .)通過分析,我們可以根據(jù)具體的日志查看Anr原因( 如: 普通阻塞,CPU滿負(fù)荷,內(nèi)存泄露 )
更多Anr細(xì)節(jié)可參考 ?Anr詳解 ,這位筆者非常詳細(xì)的介紹了Anr相關(guān)內(nèi)容
Android中那些場景是執(zhí)行在主線程的?
1)Activity生命周期回調(diào)都是執(zhí)行在主線程的.
2)Service默認(rèn)是執(zhí)行在主線程的.
3)BroadcastReceiver的onReceive回調(diào)是執(zhí)行在主線程的.
4)沒有使用子線程的looper的Handler的handleMessage, post(Runnable)是執(zhí)行在主線程的.
5)AsyncTask的回調(diào)中除了doInBackground, 其他都是執(zhí)行在主線程的.
6)View的post(Runnable)是執(zhí)行在主線程的.等等
三級緩存:
當(dāng)我們第一次打開應(yīng)用獲取圖片或其它資源時，首先到網(wǎng)絡(luò)去下載，然后依次存入內(nèi)存緩存，磁盤緩存，
當(dāng)我們再一次需要用到剛才下載的這張圖片時，就不需要再重復(fù)的到網(wǎng)絡(luò)上去下載，直接可以從內(nèi)存緩存和磁盤緩存中找，由于內(nèi)存緩存速度較快，我們優(yōu)先到內(nèi)存緩存中尋找該圖片，如果找到則運用，
如果沒有找到（內(nèi)存緩存大小有限），那么我們再到磁盤緩存中去找。
只要我們合理的去協(xié)調(diào)這三層緩存運用，便可以提升應(yīng)用性能,給用戶更好的體驗
三級緩存指的是：內(nèi)存緩存、本地緩存、網(wǎng)絡(luò)緩存。其各自的特點是內(nèi)存緩存速度快, 優(yōu)先讀取，本地緩存速度其次, 內(nèi)存沒有該資源信息就去讀取本地內(nèi)存，網(wǎng)絡(luò)緩存速度較慢(比較對象是內(nèi)存緩存和本地緩存),假設(shè)本地內(nèi)存也沒有,才請求網(wǎng)絡(luò)獲取。
內(nèi)存泄漏:
當(dāng)應(yīng)用內(nèi)部不再需要某個實例后，但是這個對象卻仍然被引用，這個情況就叫做內(nèi)存泄露(Memory Leak)。安卓虛擬機為每一個應(yīng)用分配一定的內(nèi)存空間，當(dāng)內(nèi)存泄露到達(dá)一定的程度就會造成內(nèi)存溢出。
導(dǎo)致內(nèi)存泄露常見原因:
1)靜態(tài)變量直接或者間接地引用了Activity對象就會造成內(nèi)存泄露
2)Activity使用了靜態(tài)的View(View會持有Activity的對象的引用)
3)Activity定義了靜態(tài)View變量???
4)ImageSpan引用了Activity Context
5)單例中引用了Activity的Context(需要使用Application的Context)
6)對于使用了BraodcastReceiver，ContentObserver，F(xiàn)ile，Cursor，Stream，Bitmap等資源，應(yīng)該在Activity銷毀時及時關(guān)閉或者注銷，否則這些資源將不會被回收，從而造成內(nèi)存泄漏。
7)靜態(tài)集合保存的對象沒有及時消除(不使用的時候置為null)
8)在Java中,非靜態(tài)(匿名)內(nèi)部類會引用外部類對象,而靜態(tài)內(nèi)部類不會引用外部類對象
9)在Activity中,創(chuàng)建了非靜態(tài)內(nèi)部類(內(nèi)部類直接或者間接引用了Activity)的靜態(tài)成員變量
10)線程包括AsyncTask的使用,Activity退出后線程還在運行(線程在死循環(huán)),并且在線程中使用了Activity或view對象(解決方法:不要直接寫死循環(huán),可以設(shè)置一個布爾類型的TAG,當(dāng)activity推出的時候,設(shè)置TAG為False)
11)Handler對象的使用,Activity退出后Handler還是有消息需要處理(解決方法:在退出activity之后,移除消息)
12)WebView造成的內(nèi)存泄漏(在onDestory中銷毀)
如何進(jìn)行內(nèi)存泄露分析?
A: 通過Android Studio 窗口進(jìn)行分析,查看內(nèi)存分配情況,如果操作應(yīng)用是內(nèi)存一直往上漲說明存在內(nèi)存泄露
B: 定位內(nèi)存泄露分析的工具---MAT(Memory Analyzer tool)
C: 使用開源庫LeakCanary快速定位內(nèi)存泄露
Android中的四大組件相關(guān)?
Activity:
Activity是一個應(yīng)用程序組件，提供一個屏幕(狹義的理解就是當(dāng)前APP的界面)，用戶可以用來交互為了完成某項任務(wù)。(點擊,登錄,跳轉(zhuǎn)頁面)
Activity中所有操作都與用戶密切相關(guān)，是一個負(fù)責(zé)與用戶交互的組件，可以通過setContentView(View)來顯示指定控件(設(shè)置布局文件)。
在一個android應(yīng)用中，一個Activity通常就是一個單獨的屏幕，它上面可以顯示一些控件也可以監(jiān)聽并處理用戶的事件做出響應(yīng)。
Activity四種啟動模式?
Activity的啟動模式指,可以根據(jù)實際開發(fā)需求為Activity設(shè)置對應(yīng)的啟動模式，從而可以避免創(chuàng)建大量重復(fù)的Activity等問題。
1)standard
standard為Activity的默認(rèn)啟動模式，可以不用寫配置。在這個模式下，都會默認(rèn)創(chuàng)建一個新的實例。因此，在這種模式下，可以有多個相同的實例，也允許多個相同Activity疊加。(點back鍵會依照棧順序依次退出)
2)singleTop
singleTop模式下,Activity可以有多個實例，但是不允許多個相同Activity疊加。即，如果Activity在棧頂?shù)臅r候，啟動相同的Activity，不會創(chuàng)建新的實例，而會調(diào)用其onNewIntent方法。
3)singleTask
singleTask表示只有一個實例。在同一個應(yīng)用程序中啟動他的時候，若Activity不存在，則會在當(dāng)前task創(chuàng)建一個新的實例，若存在，則會把task中在其之上的其它Activity destory掉并調(diào)用它的onNewIntent方法。如果是在別的應(yīng)用程序中啟動它，則會新建一個task，并在該task中啟動這個Activity，singleTask允許別的Activity與其在一個task中共存，也就是說，如果我在這個singleTask的實例中再打開新的Activity，這個新的Activity還是會在singleTask的實例的task中。
4)singleInstance
只有一個實例，并且這個實例獨立運行在一個task中，這個task只有這個實例，不允許有別的Activity存在。
BraodcastReceiver:（待補充）
使用了設(shè)計模式中的觀察者模式：基于消息的發(fā)布/訂閱事件模型。
注冊的方式分為兩種：靜態(tài)注冊、動態(tài)注冊
ContentProvider:(待補充)
外界可以通過ContentResolver接口來訪問ContentProvider(內(nèi)容提供者)中的數(shù)據(jù)。Uri 通用資源標(biāo)志符（Universal Resource Identifier）Uri代表要操作的數(shù)據(jù)，Android中可用的每種資源 - 圖像、視頻片段等都可以用Uri來表示。
ContentProvider共享數(shù)據(jù)是通過定義一個對外開放的統(tǒng)一的接口來實現(xiàn)的。然而，應(yīng)用程序并不直接調(diào)用這些方法，而是使用一個 ContentResolver 對象，調(diào)用它的方法作為替代。ContentResolver可以與任意內(nèi)容提供者進(jìn)行會話，與其合作來對所有相關(guān)交互通訊進(jìn)行管理。當(dāng)外部應(yīng)用需要對ContentProvider中的數(shù)據(jù)進(jìn)行添加、刪除、修改和查詢操作時，可以使用ContentResolver類來完成，要獲取ContentResolver對象，可以使用Context提供的getContentResolver()方法。
IntentService：
IntentService是Service的子類，比普通的Service增加了額外的功能。IntentService會創(chuàng)建獨立的worker線程來處理所有的Intent請求；會創(chuàng)建獨立的worker線程來處理onHandleIntent()方法實現(xiàn)的代碼，無需處理多線程的問題；所有請求處理完成后，IntentService會自動停止，開發(fā)者無需手動調(diào)用stopSelf()方法停止Service；
簡述System.exit(0) 、onDestory()、Activity.finish()三者的區(qū)別
1)System.exit(0)?是你正常結(jié)束程序,kill?掉當(dāng)前進(jìn)程,針對的是整個Application
2)onDestory()方法是Activity生命周期的最后一步，資源空間等就被回收了。當(dāng)重新進(jìn)入此Activity的時候，必須重新創(chuàng)建，執(zhí)行onCreate()方法.
3)Activity.finish()當(dāng)你調(diào)用此方法的時候，系統(tǒng)只是將最上面的Activity移出了棧，并沒有及時的調(diào)用onDestory（）方法，也就是占用的資源沒有被及時釋放。
圖片優(yōu)化，以及圖片加載框架的使用，如Picasso、 Fresco、Glide等？
1)盡量使用小的圖片,對圖片進(jìn)行壓縮，bitmapfactory.options圖片配置類，insimplesize進(jìn)行縮放，設(shè)置圖片的編碼方式；對圖片使用軟引用，內(nèi)存不夠時即時釋圖片內(nèi)存；對圖片的復(fù)用，三級緩存的使用；
即時回收不再使用的bitmap對象；
2)Picasso,不支持gif，緩存的是Argb8888的原圖，占用內(nèi)存較大,圖片的框架使用了OkHttp緩存機制,使用Http協(xié)議緩存,也是異步加載.
3)Fresco,框架是FaceBook公司推出的,適合批量加載圖片,底層是通過三級緩存(2級內(nèi)存,1級磁盤)
加載成功后自動替換成目標(biāo)圖片
4)glide,Google公司14年推出來的,可以加載GIF圖,也可以根據(jù)指定圖片清晰度,底層的原理:為Bitmap維護(hù)一個對象池,對象池的目的是通過減少對象的分配,以重用來提高性能.對象池也可以幫助提高滾動的性能。API簡潔易調(diào)用
Handle相關(guān):
Handler 工作流程基本包括 Handler、Looper、Message、MessageQueue 四個部分。但我們在日常開發(fā)中，經(jīng)常都只會用到 Handler 和 Message 兩個類。Message 負(fù)責(zé)消息的搭載，里面有個target用于標(biāo)記消息，obj用于存放內(nèi)容，Handler 負(fù)責(zé)消息的分發(fā)和處理。
一般在開發(fā)中是怎么使用 Handler 的？
官方不允許在子線程中更新 UI，所以我們經(jīng)常會把需要更新 UI 的消息直接發(fā)給處理器 Handler，通過重寫 Handler 的handleMessage()方法進(jìn)行 UI 的相關(guān)操作。
Handle使用中就沒什么需要注意的嗎？
有，Handler 如果設(shè)置為私有變量的話，Android Studio 會報警告，提示可能會造成內(nèi)存泄漏，這種情況可以通過設(shè)置為靜態(tài)內(nèi)部類 + 弱引用，或者在onDestroy()方法中調(diào)用Handler.removeCallbacksAndMessages(null)即可避免
Handler 整體工作流程淺析分為以下四個步驟：
異步通信準(zhǔn)備 => 消息入隊 => 消息循環(huán) => 消息處理
A：異步通信準(zhǔn)備
I：假定是在主線程創(chuàng)建 Handler，則會直接在主線程中創(chuàng)建處理器對象Looper、消息隊列對象MessageQueue和 Handler 對象。
需要注意的是，Looper和MessageQueue均是屬于其創(chuàng)建線程的。
II：Looper對象的創(chuàng)建一般通過Looper.prepareMainLooper()和Looper.prepare()兩個方法，而創(chuàng)建Looper對象的同時，將會自動創(chuàng)建MessageQueue。
III：創(chuàng)建好MessageQueue后，Looper將自動進(jìn)入消息循環(huán)。此時，Handler自動綁定了主線程的Looper和MessageQueue。
B：消息入隊
工作線程通過Handler發(fā)送消息Message到消息隊列MessageQueue中，消息內(nèi)容一般是 UI 操作。發(fā)送消息一般都是通過Handler.sendMessage(Message msg)和Handler.post(Runnabe r)兩個方法來進(jìn)行的。而入隊一般是通過MessageQueue.enqueueeMessage(Message msg,long when)來處理。
C：消息循環(huán)
主要分為「消息出隊」和「消息分發(fā)」兩個步驟，Looper會通過循環(huán)取出消息隊列MessageQueue里面的消息Message，并分發(fā)到創(chuàng)建該消息的處理者Handler。如果消息循環(huán)過程中，消息隊列MessageQueue為空隊列的話，則線程阻塞。
D：消息處理
Handler接收到Looper發(fā)來的消息，開始進(jìn)行處理。
LRU全稱為Least Recently Used，即最近最少使用原則
1）當(dāng)緩存空間滿了的時候，將最近最少使用的數(shù)據(jù)從緩存空間中刪除，以增加可用的緩存空間來緩存新數(shù)據(jù)
2）這個算法內(nèi)部有一個緩存列表，每當(dāng)一個緩存數(shù)據(jù)被訪問的時候，這個數(shù)據(jù)就會被提到列表尾部，每次都這樣的話，列表的頭部數(shù)據(jù)就是最近最不常使用的了，當(dāng)緩存空間不足時，就會刪除列表頭部的緩存數(shù)據(jù)
3）內(nèi)部使用了 LinkedHashMap 進(jìn)行存儲，總緩存大小一般為可用內(nèi)存的 1/8
拓展
先簡單介紹下你自己？
分析：除了向面試官做簡單的基本自我介紹之外，還需向面試官展現(xiàn)自身對該職業(yè)所必須具備的一些自身特質(zhì)，
比如，面試程序員職業(yè)需要間接的向面試官表示自己思維嚴(yán)謹(jǐn)，對細(xì)節(jié)的處理，理性思維，假設(shè)論證等等；面試產(chǎn)品等職業(yè)，需要向面試官通過自己的一些故事間接展現(xiàn)對產(chǎn)品的看法以及獨特的思維個性等等
切入點：自身特質(zhì)能否符合該職位的預(yù)期需求
自己的興趣愛好特長有那些？
在企業(yè)和面試官看來，如果求職者的愛好和應(yīng)聘的崗位在某些方面恰恰有正向關(guān)聯(lián)，就會有興趣。面試官也會通過應(yīng)聘者的興趣愛好來判斷其價值觀是否與企業(yè)文化契合，能否很好地融入工作團隊。求職者的回答將有可能為面試加分。
下列興趣愛好所反映出的一些性格和職業(yè)方向可供參考：
1．籃球，足球，排球：團隊精神，適用大多數(shù)崗位。
2．圍棋，國際象棋：戰(zhàn)略意識，適合市場類或高端職位。
3．閱讀，古典音樂：高雅，適合文職類的職位。
4．旅游：適應(yīng)不同環(huán)境的能力，快速學(xué)習(xí)的能力，適合銷售業(yè)務(wù)類職位。
5．舞蹈：外向，易溝通，適合公關(guān)、市場類的職位。
對自己的期望和規(guī)劃？
分析：職業(yè)發(fā)展規(guī)劃表面上看是在考察你（求職者）、職位、公司三者之間長期的契合程度，但實際上，這么大的一個問題完全不是三眼兩語間能夠表達(dá)清楚的。面試官（無論HR還是專業(yè)部門的）主要是看你回答問題時的思路是否清晰，回答中表現(xiàn)出的工作態(tài)度如何，順便看看你是否對公司和職位有足夠的了解。所以不管答案如何，最關(guān)鍵的就是不能茫然。
切入點：依舊自身特點，對未來期望和規(guī)劃需表述清晰，思維敏捷
談?wù)勛约旱膬?yōu)點和缺點？
先談缺點：
技術(shù)行業(yè)面試基本是由該崗位未來同事和上司進(jìn)行。這種面試技術(shù)性強，行為問題主要考察就是你是否真心想做這個工作（而不是當(dāng)跳板或者聽說高薪體面而來）和你性格與文化是否相符。所有答案都應(yīng)該圍繞這兩點組織（即每個經(jīng)歷都應(yīng)回歸到你通過這個經(jīng)歷學(xué)到什么，該職位所需關(guān)鍵技巧，這些經(jīng)歷為何讓你想做這個工作，和該經(jīng)歷體現(xiàn)出你什么樣的個人風(fēng)格）。對這個問題因為好的回答而留下好印象很難，
關(guān)鍵是避免留下壞印象。
要點以下：
1）避免避重就輕，不要談一個算不得缺點的缺點。比如熬夜會困，或者（待人接物）太客氣等等。
2）避免談非職業(yè)缺點，比如有感情潔癖，挑食，不擅長陪女友逛街，做飯經(jīng)常不懂會煮糊。
3）避免談到無法改善的弱點，比如我算數(shù)必須用計算器，我腦子不好用看書不理解。
4）避免談到致命弱點，比如脾氣怪異,不喜歡合作,遲到早退等。
那談什么最好呢？我認(rèn)為要點有三：
1）談已經(jīng)在改正的缺點／有明確計劃來改正的缺點。尤其是你能夠充分論證在近期就可以解決的缺點。
2）談一個利用你的優(yōu)點改正的缺點，順便帶出一個優(yōu)點。（這是較高效的溝通技巧）
相對較好的回答：
1）喜歡追求細(xì)節(jié)導(dǎo)致項目／作業(yè)未能按期完成。通過時間管理能力改變工作方式，先完成框架再改善細(xì)節(jié)得以解決；
2）不知如何拒絕，同事要求幫忙一概攬下，影響自身工作進(jìn)度。通過多任務(wù)處理能力設(shè)定優(yōu)先順序，以該優(yōu)先順序表向求助同事展示自己手上工作，并給其一個自己在何時可以給予幫助的時間估計，讓求助人自行決定是否求助，問題解決
3）對處理同一問題的解決辦法上，由于組員自己的技術(shù)偏好和技術(shù)構(gòu)成不一樣容易造成溝通障礙及影響項目計劃，所以,應(yīng)學(xué)會高效和有效溝通方式及工作技巧
End:
本文意在分享面試題目,因是筆者自己整理的一些面試答案,如有不足,也希望大家多多指正(碼字不易,且行且珍惜望收藏望點贊),
感謝文章中動態(tài)鏈接的作者,忠于開源,樂于分享,我想，這才是Android開發(fā)的本質(zhì)及靈魂吧
千里之行，始于足下,希望能和大家一起學(xué)習(xí)成長,加油！
如果這篇文章對您有開發(fā)or學(xué)習(xí)上的些許幫助，希望各位看官留下寶貴的star，謝謝。
Ps:著作權(quán)歸作者所有,轉(zhuǎn)載請注明作者, 商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請注明出處(開頭或結(jié)尾請?zhí)砑愚D(zhuǎn)載出處，添加原文url地址),文章請勿濫用,也希望大家尊重筆者的勞動成果,謝謝。
最后,祝愿大家通過自己的努力早日拿到心儀的Offer !
