以下面試題來自於百度、小米、樂視、美團、58、獵豹、360、新浪、搜狐內部題庫

熟悉本文中列出的知識點會大大增加通過前兩輪技術面試的機率。

一、java基礎

1.介面的意義（百度）

規範、擴充套件、回撥

2.抽象類的意義（樂視）

為其子類提供一個公共的型別 封裝子類中得重複內容 定義抽象方法，子類雖然有不同的實現 但是定義是一致的

3.內部類的作用(百度，樂視)

1. 內部類可以用多個例項，每個例項都有自己的狀態資訊，並且與其他外圍物件的資訊相互獨立。
2. 在單個外圍類中，可以讓多個內部類以不同的方式實現同一個介面，或者繼承同一個類。
3. 建立內部類物件的時刻並不依賴於外圍類物件的建立。
4. 內部類並沒有令人迷惑的“is-a”關係，他就是一個獨立的實體。
5. 內部類提供了更好的封裝，除了該外圍類，其他類都不能訪問

4.父類的靜態方法能否被子類重寫，為什麼？（獵豹）

不能

子類繼承父類後，用相同的靜態方法和非靜態方法，這時非靜態方法覆蓋父類中的方法（即方法重寫），父類的該靜態方法被隱藏（如果物件是父類則呼叫該隱藏的方法），另外子類可繼承父類的靜態與非靜態方法，至於方法過載我覺得它其中一要素就是在同一類中，不能說父類中的什麼方法與子類裡的什麼方法是方法過載的體現

5.舉1-2個排序演算法，並使用java程式碼實現（美團）

http://blog.csdn.net/qy1387/article/details/7752973

6.列舉java的集合和繼承關係（百度、美團）

7.java虛擬機器的特性（百度、樂視）

Java語言的一個非常重要的特點就是與平臺的無關性。而使用Java虛擬機器是實現這一特點的關鍵。一般的高階語言如果要在不同的平臺上執行，至少需要編譯成不同的目的碼。而引入Java語言虛擬機器後，Java語言在不同平臺上執行時不需要重新編譯。Java語言使用模式Java虛擬機器遮蔽了與具體平臺相關的資訊，使得Java語言編譯程式只需生成在Java虛擬機器上執行的目的碼（位元組碼），就可以在多種平臺上不加修改地執行。Java虛擬機器在執行位元組碼時，把位元組碼解釋成具體平臺上的機器指令執行。

8.哪些情況下的物件會被垃圾回收機制處理掉（樂視、美團、小米）

Java 垃圾回收機制最基本的做法是分代回收。記憶體中的區域被劃分成不同的世代，物件根據其存活的時間被儲存在對應世代的區域中。一般的實現是劃分成3個世代：年輕、年老和永久。記憶體的分配是發生在年輕世代中的。當一個物件存活時間足夠長的時候，它就會被複制到年老世代中。對於不同的世代可以使用不同的垃圾回收演算法。進行世代劃分的出發點是對應用中物件存活時間進行研究之後得出的統計規律。一般來說，一個應用中的大部分物件的存活時間都很短。比如區域性變數的存活時間就只在方法的執行過程中。基於這一點，對於年輕世代的垃圾回收演算法就可以很有針對性。

9.程序和執行緒的區別（獵豹）

簡而言之,一個程式至少有一個程序,一個程序至少有一個執行緒。

執行緒的劃分尺度小於程序，使得多執行緒程式的併發性高。

另外，程序在執行過程中擁有獨立的記憶體單元，而多個執行緒共享記憶體，從而極大地提高了程式的執行效率。

執行緒在執行過程中與程序還是有區別的。每個獨立的執行緒有一個程式執行的入口、順序執行序列和程式的出口。但是執行緒不能夠獨立執行，必須依存在應用程式中，由應用程式提供多個執行緒執行控制。

從邏輯角度來看，多執行緒的意義在於一個應用程式中，有多個執行部分可以同時執行。但作業系統並沒有將多個執行緒看做多個獨立的應用，來實現程序的排程和管理以及資源分配。這就是程序和執行緒的重要區別。

程序是具有一定獨立功能的程式關於某個資料集合上的一次執行活動,程序是系統進行資源分配和排程的一個獨立單位.

執行緒是程序的一個實體,是CPU排程和分派的基本單位,它是比程序更小的能獨立執行的基本單位.執行緒自己基本上不擁有系統資源,只擁有一點在執行中必不可少的資源(如程式計數器,一組暫存器和棧),但是它可與同屬一個程序的其他的執行緒共享程序所擁有的全部資源.

一個執行緒可以建立和撤銷另一個執行緒;同一個程序中的多個執行緒之間可以併發執行.

程序和執行緒的主要差別在於它們是不同的作業系統資源管理方式。程序有獨立的地址空間，一個程序崩潰後，在保護模式下不會對其它程序產生影響，而執行緒只是一個程序中的不同執行路徑。執行緒有自己的堆疊和區域性變數，但執行緒之間沒有單獨的地址空間，一個執行緒死掉就等於整個程序死掉，所以多程序的程式要比多執行緒的程式健壯，但在程序切換時，耗費資源較大，效率要差一些。但對於一些要求同時進行並且又要共享某些變數的併發操作，只能用執行緒，不能用程序。如果有興趣深入的話，我建議你們看看《現代作業系統》或者《作業系統的設計與實現》。對就個問題說得比較清楚。

10.Java中==和equals的區別，equals和hashCode的區別（樂視）

http://blog.csdn.net/tiantiandjava/article/details/46988461

11.常見的排序演算法時間複雜度（小米）

12.HashMap的實現原理（美團）

1. HashMap概述： HashMap是基於雜湊表的Map介面的非同步實現。此實現提供所有可選的對映操作，並允許使用null值和null鍵。此類不保證對映的順序，特別是它不保證該順序恆久不變。
2. HashMap的資料結構： 在java程式語言中，最基本的結構就是兩種，一個是陣列，另外一個是模擬指標（引用），所有的資料結構都可以用這兩個基本結構來構造的，HashMap也不例外。HashMap實際上是一個“連結串列雜湊”的資料結構，即陣列和連結串列的結合體。

從上圖中可以看出，HashMap底層就是一個數組結構，陣列中的每一項又是一個連結串列。當新建一個HashMap的時候，就會初始化一個數組。

13.java 狀態機

http://www.jdon.com/designpatterns/designpattern_State.htm

14.java中int char long各佔多少位元組數

byte 位數 8 位元組數 1

short 16 2

int 32 4

long 64 8

float 32 4

double 64 8

char 16 2

15.java int與integer的區別

http://www.cnblogs.com/shenliang123/archive/2011/10/27/2226903.html

16.string stringbuffer stringbuilder 區別（小米、樂視、百度）

String 字串常量

StringBuffer 字串變數（執行緒安全）

StringBuilder 字串變數（非執行緒安全）

簡要的說， String 型別和 StringBuffer 型別的主要效能區別其實在於 String 是不可變的物件, 因此在每次對 String 型別進行改變的時候其實都等同於生成了一個新的 String 物件，然後將指標指向新的 String 物件，所以經常改變內容的字串最好不要用String ，因為每次生成物件都會對系統性能產生影響，特別當記憶體中無引用物件多了以後,JVM 的 GC 就會開始工作，那速度是一定會相當慢的。

而如果是使用 StringBuffer 類則結果就不一樣了，每次結果都會對 StringBuffer 物件本身進行操作，而不是生成新的物件，再改變物件引用。所以在一般情況下我們推薦使用 StringBuffer ，特別是字串物件經常改變的情況下。而在某些特別情況下， String 物件的字串拼接其實是被 JVM 解釋成了 StringBuffer 物件的拼接，所以這些時候 String 物件的速度並不會比 StringBuffer 物件慢，而特別是以下的字串物件生成中， String 效率是遠要比 StringBuffer 快的：

String S1 = “This is only a” + “ simple” + “ test”;

StringBuffer Sb = new StringBuilder(“This is only a”).append(“ simple”).append(“ test”); 你會很驚訝的發現，生成 String S1 物件的速度簡直太快了，而這個時候 StringBuffer 居然速度上根本一點都不佔優勢。其實這是 JVM 的一個把戲，在 JVM 眼裡，這個 String S1 = “This is only a” + “ simple” + “test”; 其實就是： String S1 = “This is only a simple test”; 所以當然不需要太多的時間了。但大家這裡要注意的是，如果你的字串是來自另外的 String 物件的話，速度就沒那麼快了，譬如： String S2 = “This is only a”; String S3 = “ simple”; String S4 = “ test”; String S1 = S2 +S3 + S4; 這時候 JVM 會規規矩矩的按照原來的方式去做

在大部分情況下 StringBuffer > String

StringBuffer

Java.lang.StringBuffer執行緒安全的可變字元序列。一個類似於 String 的字串緩衝區，但不能修改。雖然在任意時間點上它都包含某種特定的字元序列，但通過某些方法呼叫可以改變該序列的長度和內容。

可將字串緩衝區安全地用於多個執行緒。可以在必要時對這些方法進行同步，因此任意特定例項上的所有操作就好像是以序列順序發生的，該順序與所涉及的每個執行緒進行的方法呼叫順序一致。

StringBuffer 上的主要操作是 append 和 insert 方法，可過載這些方法，以接受任意型別的資料。每個方法都能有效地將給定的資料轉換成字串，然後將該字串的字元追加或插入到字串緩衝區中。append 方法始終將這些字元新增到緩衝區的末端；而 insert 方法則在指定的點新增字元。

例如，如果 z 引用一個當前內容是“start”的字串緩衝區物件，則此方法呼叫 z.append("le") 會使字串緩衝區包含“startle”，而 z.insert(4, "le") 將更改字串緩衝區，使之包含“starlet”。

在大部分情況下 StringBuilder > StringBuffer

java.lang.StringBuilder

java.lang.StringBuilder一個可變的字元序列是5.0新增的。此類提供一個與 StringBuffer 相容的 API，但不保證同步。該類被設計用作 StringBuffer 的一個簡易替換，用在字串緩衝區被單個執行緒使用的時候（這種情況很普遍）。如果可能，建議優先採用該類，因為在大多數實現中，它比 StringBuffer 要快。兩者的方法基本相同

17.Java多型（樂視）

Java多型性理解

Java中多型性的實現

什麼是多型

面向物件的三大特性：封裝、繼承、多型。從一定角度來看，封裝和繼承幾乎都是為多型而準備的。這是我們最後一個概念，也是最重要的知識點。

多型的定義：指允許不同類的物件對同一訊息做出響應。即同一訊息可以根據傳送物件的不同而採用多種不同的行為方式。（傳送訊息就是函式呼叫）

實現多型的技術稱為：動態繫結（dynamic binding），是指在執行期間判斷所引用物件的實 際型別，根據其實際的型別呼叫其相應的方法。

多型的作用：消除型別之間的耦合關係。

現實中，關於多型的例子不勝列舉。比方說按下 F1 鍵這個動作，如果當前在 Flash 介面下彈出的就是 AS 3 的幫助文件；如果當前在 Word 下彈出的就是 Word 幫助；在 Windows 下彈出的就是 Windows 幫助和支援。同一個事件發生在不同的物件上會產生不同的結果。 下面是多型存在的三個必要條件，要求大家做夢時都能背出來！

多型存在的三個必要條件 一、要有繼承； 二、要有重寫； 三、父類引用指向子類物件。

多型的好處：

1.可替換性（substitutability）。多型對已存在程式碼具有可替換性。例如，多型對圓Circle類工作，對其他任何圓形幾何體，如圓環，也同樣工作。

2.可擴充性（extensibility）。多型對程式碼具有可擴充性。增加新的子類不影響已存在類的多型性、繼承性，以及其他特性的執行和操作。實際上新加子類更容易獲得多型功能。例如，在實現了圓錐、半圓錐以及半球體的多型基礎上，很容易增添球體類的多型性。

3.介面性（interface-ability）。多型是超類通過方法簽名，向子類提供了一個共同介面，由子類來完善或者覆蓋它而實現的。如圖8.3 所示。圖中超類Shape規定了兩個實現多型的介面方法，computeArea()以及computeVolume()。子類，如Circle和Sphere為了實現多型，完善或者覆蓋這兩個介面方法。

4.靈活性（flexibility）。它在應用中體現了靈活多樣的操作，提高了使用效率。

5.簡化性（simplicity）。多型簡化對應用軟體的程式碼編寫和修改過程，尤其在處理大量物件的運算和操作時，這個特點尤為突出和重要。

Java中多型的實現方式：介面實現，繼承父類進行方法重寫，同一個類中進行方法過載。

18.什麼導致執行緒阻塞（58、美團）

執行緒的阻塞

為了解決對共享儲存區的訪問衝突，Java 引入了同步機制，現在讓我們來考察多個執行緒對共享資源的訪問，顯然同步機制已經不夠了，因為在任意時刻所要求的資源不一定已經準備好了被訪問，反過來，同一時刻準備好了的資源也可能不止一個。為了解決這種情況下的訪問控制問題，Java 引入了對阻塞機制的支援.

阻塞指的是暫停一個執行緒的執行以等待某個條件發生（如某資源就緒），學過作業系統的同學對它一定已經很熟悉了。Java 提供了大量方法來支援阻塞，下面讓我們逐一分析。

1. sleep() 方法：sleep() 允許 指定以毫秒為單位的一段時間作為引數，它使得執行緒在指定的時間內進入阻塞狀態，不能得到CPU 時間，指定的時間一過，執行緒重新進入可執行狀態。 典型地，sleep() 被用在等待某個資源就緒的情形：測試發現條件不滿足後，讓執行緒阻塞一段時間後重新測試，直到條件滿足為止。
2. suspend() 和 resume() 方法：兩個方法配套使用，suspend()使得執行緒進入阻塞狀態，並且不會自動恢復，必須其對應的resume() 被呼叫，才能使得執行緒重新進入可執行狀態。典型地，suspend() 和 resume() 被用在等待另一個執行緒產生的結果的情形：測試發現結果還沒有產生後，讓執行緒阻塞，另一個執行緒產生了結果後，呼叫 resume() 使其恢復。
3. yield() 方法：yield() 使得執行緒放棄當前分得的 CPU 時間，但是不使執行緒阻塞，即執行緒仍處於可執行狀態，隨時可能再次分得 CPU 時間。呼叫 yield() 的效果等價於排程程式認為該執行緒已執行了足夠的時間從而轉到另一個執行緒.
4. wait() 和 notify() 方法：兩個方法配套使用，wait() 使得執行緒進入阻塞狀態，它有兩種形式，一種允許 指定以毫秒為單位的一段時間作為引數，另一種沒有引數，前者當對應的 notify() 被呼叫或者超出指定時間時執行緒重新進入可執行狀態，後者則必須對應的 notify() 被呼叫.

初看起來它們與 suspend() 和 resume() 方法對沒有什麼分別，但是事實上它們是截然不同的。區別的核心在於，前面敘述的所有方法，阻塞時都不會釋放佔用的鎖（如果佔用了的話），而這一對方法則相反。

上述的核心區別導致了一系列的細節上的區別。

首先，前面敘述的所有方法都隸屬於 Thread 類，但是這一對卻直接隸屬於 Object 類，也就是說，所有物件都擁有這一對方法。初看起來這十分不可思議，但是實際上卻是很自然的，因為這一對方法阻塞時要釋放佔用的鎖，而鎖是任何物件都具有的，呼叫任意物件的 wait() 方法導致執行緒阻塞，並且該物件上的鎖被釋放。而呼叫 任意物件的notify()方法則導致因呼叫該物件的 wait() 方法而阻塞的執行緒中隨機選擇的一個解除阻塞（但要等到獲得鎖後才真正可執行）。

其次，前面敘述的所有方法都可在任何位置呼叫，但是這一對方法卻必須在 synchronized 方法或塊中呼叫，理由也很簡單，只有在synchronized 方法或塊中當前執行緒才佔有鎖，才有鎖可以釋放。同樣的道理，呼叫這一對方法的物件上的鎖必須為當前執行緒所擁有，這樣才有鎖可以釋放。因此，這一對方法呼叫必須放置在這樣的 synchronized 方法或塊中，該方法或塊的上鎖物件就是呼叫這一對方法的物件。若不滿足這一條件，則程式雖然仍能編譯，但在執行時會出現IllegalMonitorStateException 異常。

wait() 和 notify() 方法的上述特性決定了它們經常和synchronized 方法或塊一起使用，將它們和作業系統的程序間通訊機制作一個比較就會發現它們的相似性：synchronized方法或塊提供了類似於作業系統原語的功能，它們的執行不會受到多執行緒機制的干擾，而這一對方法則相當於 block 和wakeup 原語（這一對方法均宣告為 synchronized）。它們的結合使得我們可以實現作業系統上一系列精妙的程序間通訊的演算法（如訊號量演算法），並用於解決各種複雜的執行緒間通訊問題。

關於 wait() 和 notify() 方法最後再說明兩點：

第一：呼叫 notify() 方法導致解除阻塞的執行緒是從因呼叫該物件的 wait() 方法而阻塞的執行緒中隨機選取的，我們無法預料哪一個執行緒將會被選擇，所以程式設計時要特別小心，避免因這種不確定性而產生問題。

第二：除了 notify()，還有一個方法 notifyAll() 也可起到類似作用，唯一的區別在於，呼叫 notifyAll() 方法將把因呼叫該物件的 wait() 方法而阻塞的所有執行緒一次性全部解除阻塞。當然，只有獲得鎖的那一個執行緒才能進入可執行狀態。

談到阻塞，就不能不談一談死鎖，略一分析就能發現，suspend() 方法和不指定超時期限的 wait() 方法的呼叫都可能產生死鎖。遺憾的是，Java 並不在語言級別上支援死鎖的避免，我們在程式設計中必須小心地避免死鎖。

以上我們對 Java 中實現執行緒阻塞的各種方法作了一番分析，我們重點分析了 wait() 和 notify() 方法，因為它們的功能最強大，使用也最靈活，但是這也導致了它們的效率較低，較容易出錯。實際使用中我們應該靈活使用各種方法，以便更好地達到我們的目的。

19.抽象類介面區別（360）

1. 預設的方法實現 抽象類可以有預設的方法實現完全是抽象的。介面根本不存在方法的實現

2. 實現 子類使用extends關鍵字來繼承抽象類。如果子類不是抽象類的話，它需要提供抽象類中所有宣告的方法的實現。
   子類使用關鍵字implements來實現介面。它需要提供介面中所有宣告的方法的實現

3. 構造器
   抽象類可以有構造器
   介面不能有構造器

4. 與正常Java類的區別
   除了你不能例項化抽象類之外，它和普通Java類沒有任何區 介面是完全不同的型別

5. 訪問修飾符
   抽象方法可以有public、protected和default這些修飾符 介面方法預設修飾符是public。你不可以使用其它修飾符。

6. main方法
   抽象方法可以有main方法並且我們可以執行它
   介面沒有main方法，因此我們不能執行它。

7. 多繼承
   抽象類在java語言中所表示的是一種繼承關係，一個子類只能存在一個父類，但是可以存在多個介面。

8. 速度
   它比介面速度要快
   介面是稍微有點慢的，因為它需要時間去尋找在類中實現的方法。

9. 新增新方法
   如果你往抽象類中新增新的方法，你可以給它提供預設的實現。因此你不需要改變你現在的程式碼。 如果你往介面中新增方法，那麼你必須改變實現該介面的類。

20.容器類之間的區別（樂視、美團）

http://www.cnblogs.com/yuanermen/archive/2009/08/05/1539917.html http://alexyyek.github.io/2015/04/06/Collection/ http://tianmaying.com/tutorial/java_collection

21.java 內部類（小米）

http://www.cnblogs.com/chenssy/p/3388487.html

22.Java中hashmap和hashtable的區別（樂視、小米）

http://www.233.com/ncre2/JAVA/jichu/20100717/084230917.html

23.ArrayMap VS HashMap

http://lvable.com/?p=217

二、android基礎

1.資料庫的操作型別有哪些，如何匯入外部資料庫？

把原資料庫包括在專案原始碼的 res/raw

android系統下資料庫應該存放在 /data/data/com..（package name）/ 目錄下，所以我們需要做的是把已有的資料庫傳入那個目錄下.操作方法是用FileInputStream讀取原資料庫，再用FileOutputStream把讀取到的東西寫入到那個目錄.

2.是否使用過本地廣播，和全域性廣播有什麼差別？

因廣播資料在本應用範圍內傳播，不用擔心隱私資料洩露的問題。 不用擔心別的應用偽造廣播，造成安全隱患。 相比在系統內傳送全域性廣播，它更高效。

3.是否使用過intentServer，作用是什麼，AIDL解決了什麼問題？(小米)

<code class="language-none">生成一個預設的且與主執行緒互相獨立的工作者執行緒來執行所有傳送至 onStartCommand() 方法的Intetnt。
生成一個工作佇列來傳送Intent物件給你的onHandleIntent()方法，同一時刻只傳送一個Intent物件，這樣一來，你就不必擔心多執行緒的問題。
在所有的請求(Intent)都被執行完以後會自動停止服務，所以，你不需要自己去呼叫stopSelf()方法來停止該服務
提供了一個onBind()方法的預設實現，它返回null
提供了一個onStartCommand()方法的預設實現，它將Intent先傳送至工作佇列，然後從工作佇列中每次取出一個傳送至onHandleIntent()方法，在該方法中對Intent對相應的處理。</code>

AIDL (Android Interface Definition Language) 是一種IDL 語言，用於生成可以在Android裝置上兩個程序之間進行程序間通訊(interprocess communication, IPC)的程式碼。如果在一個程序中（例如Activity）要呼叫另一個程序中（例如Service）物件的操作，就可以使用AIDL生成可序列化的引數。 AIDL IPC機制是面向介面的，像COM或Corba一樣，但是更加輕量級。它是使用代理類在客戶端和實現端傳遞資料。

4.Activity、Window、View三者的差別，fragment的特點？（360）

Activity像一個工匠（控制單元），Window像窗戶（承載模型），View像窗花（顯示檢視） LayoutInflater像剪刀，Xml配置像窗花圖紙。

1. 在Activity中呼叫attach，建立了一個Window
2. 建立的window是其子類PhoneWindow，在attach中建立PhoneWindow
3. 在Activity中呼叫setContentView(R.layout.xxx)
4. 其中實際上是呼叫的getWindow().setContentView()
5. 呼叫PhoneWindow中的setContentView方法
6. 建立ParentView：
作為ViewGroup的子類，實際是建立的DecorView(作為FramLayout的子類）
7. 將指定的R.layout.xxx進行填充
通過佈局填充器進行填充【其中的parent指的就是DecorView】
8. 呼叫到ViewGroup
9. 呼叫ViewGroup的removeAllView()，先將所有的view移除掉
10. 新增新的view：addView()

fragment 特點

• Fragment可以作為Activity介面的一部分組成出現；
• 可以在一個Activity中同時出現多個Fragment，並且一個Fragment也可以在多個Activity中使用；
• 在Activity執行過程中，可以新增、移除或者替換Fragment；
• Fragment可以響應自己的輸入事件，並且有自己的生命週期，它們的生命週期會受宿主Activity的生命週期影響。

5.描述一次網路請求的流程（新浪）



6.Handler、Thread和HandlerThread的差別（小米）

http://blog.csdn.net/guolin_blog/article/details/9991569

http://droidyue.com/blog/2015/11/08/make-use-of-handlerthread/

從Android中Thread（java.lang.Thread -> java.lang.Object）描述可以看出，Android的Thread沒有對Java的Thread做任何封裝，但是Android提供了一個繼承自Thread的類HandlerThread（android.os.HandlerThread -> java.lang.Thread），這個類對Java的Thread做了很多便利Android系統的封裝。

android.os.Handler可以通過Looper物件例項化，並運行於另外的執行緒中，Android提供了讓Handler運行於其它執行緒的執行緒實現，也是就HandlerThread。HandlerThread物件start後可以獲得其Looper物件，並且使用這個Looper物件例項Handler。

7.低版本SDK實現高版本api（小米）

自己實現或@TargetApi annotation

8.編譯安卓系統（百度）

1.建立一個大小寫敏感的磁碟映象檔案 2.首先你要安裝的就是Xcode 3.從macports.org安裝MacPorts工具 4.從MacPorts安裝make,git, and GPG packages 5.修改檔案識別符號限制 6.建立~/bin/目錄 7.安裝repo 8.設定repo可執行許可權 9.修改~/bin/repo檔案將第五行 10.新建目錄gingerbread，並進入該目錄 11.執行repoinit 12. reposync 13.設定必要的編譯環境-編譯 14.利用Eclipse除錯程式碼

9.launch mode應用場景（百度、小米、樂視）

standard，建立一個新的Activity。

singleTop，棧頂不是該型別的Activity，建立一個新的Activity。否則，onNewIntent。

singleTask，回退棧中沒有該型別的Activity，建立Activity，否則，onNewIntent+ClearTop。

注意: 1.設定了"singleTask"啟動模式的Activity，它在啟動的時候，會先在系統中查詢屬性值affinity等於它的屬性值taskAffinity的Task存在； 如果存在這樣的Task，它就會在這個Task中啟動，否則就會在新的任務棧中啟動。因此， 如果我們想要設定了"singleTask"啟動模式的Activity在新的任務中啟動，就要為它設定一個獨立的taskAffinity屬性值。 2.如果設定了"singleTask"啟動模式的Activity不是在新的任務中啟動時，它會在已有的任務中檢視是否已經存在相應的Activity例項， 如果存在，就會把位於這個Activity例項上面的Activity全部結束掉，即最終這個Activity 例項會位於任務的Stack頂端中。 3.在一個任務棧中只有一個”singleTask”啟動模式的Activity存在。他的上面可以有其他的Activity。這點與singleInstance是有區別的。

singleInstance，回退棧中，只有這一個Activity，沒有其他Activity。

singleTop適合接收通知啟動的內容顯示頁面。 例如，某個新聞客戶端的新聞內容頁面，如果收到10個新聞推送，每次都開啟一個新聞內容頁面是很煩人的。 singleTask適合作為程式入口點。 例如瀏覽器的主介面。不管從多少個應用啟動瀏覽器，只會啟動主介面一次，其餘情況都會走onNewIntent，並且會清空主介面上面的其他頁面。 singleInstance應用場景：鬧鈴的響鈴介面。 你以前設定了一個鬧鈴：上午6點。在上午5點58分，你啟動了鬧鈴設定介面，並按 Home 鍵回桌面；在上午5點59分時，你在微信和朋友聊天； 在6點時，鬧鈴響了，並且彈出了一個對話方塊形式的 Activity(名為 AlarmAlertActivity) 提示你到6點了(這個 Activity 就是以 SingleInstance 載入模式開啟的)，你按返回鍵，回到的是微信的聊天介面，這是因為 AlarmAlertActivity 所在的 Task 的棧只有他一個元素， 因此退出之後這個 Task 的棧空了。如果是以 SingleTask 開啟 AlarmAlertActivity，那麼當鬧鈴響了的時候，按返回鍵應該進入鬧鈴設定介面。

10.touch 事件傳遞流程（小米）

http://hanhailong.com/2015/09/24/Android-%E4%B8%89%E5%BC%A0%E5%9B%BE%E6%90%9E%E5%AE%9ATouch%E4%BA%8B%E4%BB%B6%E4%BC%A0%E9%80%92%E6%9C%BA%E5%88%B6/

11.view繪製流程（百度）

http://www.codekk.com/blogs/detail/54cfab086c4761e5001b253f

12.多執行緒（360）

• Activity.runOnUiThread(Runnable)
• View.post(Runnable),View.postDelay(Runnable,long)
• Handler
• AsyncTask

13.執行緒同步（百度）

http://www.itzhai.com/java-based-notebook-thread-synchronization-problem-solving-synchronization-problems-synchronized-block-synchronized-methods.html#read-more

http://www.juwends.com/tech/android/android-inter-thread-comm.html

單例

<code class="language-none">public class Singleton{
private volatile static Singleton mSingleton;
private Singleton(){
}
public static Singleton getInstance(){
  if(mSingleton == null){\\A
    synchronized(Singleton.class){\\C
     if(mSingleton == null)
      mSingleton = new Singleton();\\B
      }
    }
    return mSingleton;
  }
}</code>

14.什麼情況導致記憶體洩漏（美團）

1.資源物件沒關閉造成的記憶體洩漏

描述： 資源性物件比如(Cursor，File檔案等)往往都用了一些緩衝，我們在不使用的時候，應該及時關閉它們，以便它們的緩衝及時回收記憶體。它們的緩衝不僅存在於 java虛擬機器內，還存在於java虛擬機器外。如果我們僅僅是把它的引用設定為null,而不關閉它們，往往會造成記憶體洩漏。因為有些資源性物件，比如 SQLiteCursor(在解構函式finalize(),如果我們沒有關閉它，它自己會調close()關閉)，如果我們沒有關閉它，系統在回收它時也會關閉它，但是這樣的效率太低了。因此對於資源性物件在不使用的時候，應該呼叫它的close()函式，將其關閉掉，然後才置為null.在我們的程式退出時一定要確保我們的資源性物件已經關閉。 程式中經常會進行查詢資料庫的操作，但是經常會有使用完畢Cursor後沒有關閉的情況。如果我們的查詢結果集比較小，對記憶體的消耗不容易被發現，只有在常時間大量操作的情況下才會復現記憶體問題，這樣就會給以後的測試和問題排查帶來困難和風險。

2.構造Adapter時，沒有使用快取的convertView

描述： 以構造ListView的BaseAdapter為例，在BaseAdapter中提供了方法： public View getView(int position, ViewconvertView, ViewGroup parent) 來向ListView提供每一個item所需要的view物件。初始時ListView會從BaseAdapter中根據當前的屏幕布局例項化一定數量的 view物件，同時ListView會將這些view物件快取起來。當向上滾動ListView時，原先位於最上面的list item的view物件會被回收，然後被用來構造新出現的最下面的list item。這個構造過程就是由getView()方法完成的，getView()的第二個形參View convertView就是被快取起來的list item的view物件(初始化時快取中沒有view物件則convertView是null)。由此可以看出，如果我們不去使用 convertView，而是每次都在getView()中重新例項化一個View物件的話，即浪費資源也浪費時間，也會使得記憶體佔用越來越大。 ListView回收list item的view物件的過程可以檢視: android.widget.AbsListView.java --> voidaddScrapView(View scrap) 方法。 示例程式碼：

<code class="language-none">public View getView(int position, ViewconvertView, ViewGroup parent) {
View view = new Xxx(...); 
... ... 
return view; 
} </code>

修正示例程式碼：

<code class="language-none">public View getView(int position, ViewconvertView, ViewGroup parent) {
View view = null; 
if (convertView != null) { 
view = convertView; 
populate(view, getItem(position)); 
... 
} else { 
view = new Xxx(...); 
... 
} 
return view; 
} </code>

3.Bitmap物件不在使用時呼叫recycle()釋放記憶體

描述： 有時我們會手工的操作Bitmap物件，如果一個Bitmap物件比較佔記憶體，當它不在被使用的時候，可以呼叫Bitmap.recycle()方法回收此物件的畫素所佔用的記憶體，但這不是必須的，視情況而定。可以看一下程式碼中的註釋：

/** •Free up the memory associated with thisbitmap's pixels, and mark the •bitmap as "dead", meaning itwill throw an exception if getPixels() or •setPixels() is called, and will drawnothing. This operation cannot be •reversed, so it should only be called ifyou are sure there are no •further uses for the bitmap. This is anadvanced call, and normally need •not be called, since the normal GCprocess will free up this memory when •there are no more references to thisbitmap. */

4.試著使用關於application的context來替代和activity相關的context

這是一個很隱晦的記憶體洩漏的情況。有一種簡單的方法來避免context相關的記憶體洩漏。最顯著地一個是避免context逃出他自己的範圍之外。使用Application context。這個context的生存週期和你的應用的生存週期一樣長，而不是取決於activity的生存週期。如果你想保持一個長期生存的物件，並且這個物件需要一個context,記得使用application物件。你可以通過呼叫 Context.getApplicationContext() or Activity.getApplication()來獲得。更多的請看這篇文章如何避免 Android記憶體洩漏。

5.註冊沒取消造成的記憶體洩漏

一些Android程式可能引用我們的Anroid程式的物件(比如註冊機制)。即使我們的Android程式已經結束了，但是別的引用程式仍然還有對我們的Android程式的某個物件的引用，洩漏的記憶體依然不能被垃圾回收。呼叫registerReceiver後未呼叫unregisterReceiver。 比如:假設我們希望在鎖屏介面(LockScreen)中，監聽系統中的電話服務以獲取一些資訊(如訊號強度等)，則可以在LockScreen中定義一個 PhoneStateListener的物件，同時將它註冊到TelephonyManager服務中。對於LockScreen物件，當需要顯示鎖屏介面的時候就會建立一個LockScreen物件，而當鎖屏介面消失的時候LockScreen物件就會被釋放掉。 但是如果在釋放 LockScreen物件的時候忘記取消我們之前註冊的PhoneStateListener物件，則會導致LockScreen無法被垃圾回收。如果不斷的使鎖屏介面顯示和消失，則最終會由於大量的LockScreen物件沒有辦法被回收而引起OutOfMemory,使得system_process 程序掛掉。 雖然有些系統程式，它本身好像是可以自動取消註冊的(當然不及時)，但是我們還是應該在我們的程式中明確的取消註冊，程式結束時應該把所有的註冊都取消掉。

6.集合中物件沒清理造成的記憶體洩漏

我們通常把一些物件的引用加入到了集合中，當我們不需要該物件時，並沒有把它的引用從集合中清理掉，這樣這個集合就會越來越大。如果這個集合是static的話，那情況就更嚴重了。

15.ANR定位和修正

如果開發機器上出現問題，我們可以通過檢視/data/anr/traces.txt即可，最新的ANR資訊在最開始部分。

• 主執行緒被IO操作（從4.0之後網路IO不允許在主執行緒中）阻塞。
• 主執行緒中存在耗時的計算
• 主執行緒中錯誤的操作，比如Thread.wait或者Thread.sleep等 Android系統會監控程式的響應狀況，一旦出現下面兩種情況，則彈出ANR對話方塊
• 應用在5秒內未響應使用者的輸入事件（如按鍵或者觸控）
• BroadcastReceiver未在10秒內完成相關的處理

• Service在特定的時間內無法處理完成 20秒

• 使用AsyncTask處理耗時IO操作。

• 使用Thread或者HandlerThread時，呼叫Process.setThreadPriority(Process.THREADPRIORITYBACKGROUND)設定優先順序，否則仍然會降低程式響應，因為預設Thread的優先順序和主執行緒相同。

• 使用Handler處理工作執行緒結果，而不是使用Thread.wait()或者Thread.sleep()來阻塞主執行緒。

• Activity的onCreate和onResume回撥中儘量避免耗時的程式碼

• BroadcastReceiver中onReceive程式碼也要儘量減少耗時，建議使用IntentService處理。

16.什麼情況導致oom（樂視、美團）

http://www.jcodecraeer.com/a/anzhuokaifa/androidkaifa/2015/0920/3478.html

1）使用更加輕量的資料結構 2）Android裡面使用Enum 3）Bitmap物件的記憶體佔用 4）更大的圖片 5）onDraw方法裡面執行物件的建立 6）StringBuilder

17.Android Service與Activity之間通訊的幾種方式

• 通過Binder物件
• 通過broadcast(廣播)的形式

18.Android各個版本API的區別

http://blog.csdn.net/lijun952048910/article/details/7980562

19. Android程式碼中實現WAP方式聯網（360）

http://blog.csdn.net/asce1885/article/details/7844159

20.如何保證service在後臺不被kill

一、onStartCommand方法，返回START_STICKY

1、START_STICKY 在執行onStartCommand後service程序被kill後，那將保留在開始狀態，但是不保留那些傳入的intent。不久後service就會再次嘗試重新建立，因為保留在開始狀態，在建立 service後將保證呼叫onstartCommand。如果沒有傳遞任何開始命令給service，那將獲取到null的intent。

2、STARTNOTSTICKY 在執行onStartCommand後service程序被kill後，並且沒有新的intent傳遞給它。Service將移出開始狀態，並且直到新的明顯的方法（startService）呼叫才重新建立。因為如果沒有傳遞任何未決定的intent那麼service是不會啟動，也就是期間onstartCommand不會接收到任何null的intent。

3、STARTREDELIVERINTENT 在執行onStartCommand後service程序被kill後，系統將會再次啟動service，並傳入最後一個intent給onstartCommand。直到呼叫stopSelf(int)才停止傳遞intent。如果在被kill後還有未處理好的intent，那被kill後服務還是會自動啟動。因此onstartCommand不會接收到任何null的intent。

二、提升service優先順序

在AndroidManifest.xml檔案中對於intent-filter可以通過android:priority = "1000"這個屬性設定最高優先順序，1000是最高值，如果數字越小則優先順序越低，同時適用於廣播。

三、提升service程序優先順序

Android中的程序是託管的，當系統程序空間緊張的時候，會依照優先順序自動進行程序的回收。Android將程序分為6個等級,它們按優先順序順序由高到低依次是: 1.前臺程序( FOREGROUNDAPP)
 2.可視程序(VISIBLEAPP )
 3. 次要服務程序(SECONDARYSERVER )
 4.後臺程序 (HIDDENAPP)
 5.內容供應節點(CONTENTPROVIDER)
 6.空程序(EMPTYAPP) 當service執行在低記憶體的環境時，將會kill掉一些存在的程序。因此程序的優先順序將會很重要，可以使用startForeground 將service放到前臺狀態。這樣在低記憶體時被kill的機率會低一些。

四、onDestroy方法裡重啟service

service +broadcast 方式，就是當service走ondestory的時候，傳送一個自定義的廣播，當收到廣播的時候，重新啟動service；

五、Application加上Persistent屬性

六、監聽系統廣播判斷Service狀態

通過系統的一些廣播，比如：手機重啟、介面喚醒、應用狀態改變等等監聽並捕獲到，然後判斷我們的Service是否還存活，別忘記加許可權啊。

21.Requestlayout，onlayout，onDraw，DrawChild區別與聯絡（獵豹）

requestLayout()方法 ：會導致呼叫measure()過程 和 layout()過程 。 說明：只是對View樹重新佈局layout過程包括measure()和layout()過程，不會呼叫draw()過程，但不會重新繪製 任何檢視包括該呼叫者本身。

onLayout()方法(如果該View是ViewGroup物件，需要實現該方法，對每個子檢視進行佈局)

呼叫onDraw()方法繪製檢視本身 (每個View都需要過載該方法，ViewGroup不需要實現該方法)

drawChild()去重新回撥每個子檢視的draw()方法

22.invalidate()和postInvalidate() 的區別及使用（百度）

http://blog.csdn.net/mars2639/article/details/6650876

23.Android動畫框架實現原理

Animation框架定義了透明度，旋轉，縮放和位移幾種常見的動畫，而且控制的是整個View，實現原理是每次繪製檢視時View所在的ViewGroup中的drawChild函式獲取該View的Animation的Transformation值，然後呼叫canvas.concat(transformToApply.getMatrix())，通過矩陣運算完成動畫幀，如果動畫沒有完成，繼續呼叫invalidate()函式，啟動下次繪製來驅動動畫，動畫過程中的幀之間間隙時間是繪製函式所消耗的時間，可能會導致動畫消耗比較多的CPU資源，最重要的是，動畫改變的只是顯示，並不能相應事件。

24.Android為每個應用程式分配的記憶體大小是多少？（美團）

android程式記憶體一般限制在16M，也有的是24M

25.Android View重新整理機制（百度、美團）

由ViewRoot物件的performTraversals()方法呼叫draw()方法發起繪製該View樹，值得注意的是每次發起繪圖時，並不會重新繪製每個View樹的檢視，而只會重新繪製那些“需要重繪”的檢視，View類內部變數包含了一個標誌位DRAWN，當該檢視需要重繪時，就會為該View新增該標誌位。

呼叫流程 ：

mView.draw()開始繪製，draw()方法實現的功能如下：

1. 繪製該View的背景
2. 為顯示漸變框做一些準備操作(見5，大多數情況下，不需要改漸變框)
   
3. 呼叫onDraw()方法繪製檢視本身 (每個View都需要過載該方法，ViewGroup不需要實現該方法)
4. 呼叫dispatchDraw ()方法繪製子檢視(如果該View型別不為ViewGroup，即不包含子檢視，不需要過載該方法)值得說明的是，ViewGroup類已經為我們重寫了dispatchDraw ()的功能實現，應用程式一般不需要重寫該方法，但可以過載父類函式實現具體的功能。

26.LinearLayout對比RelativeLayout（百度）

1.RelativeLayout會讓子View呼叫2次onMeasure，LinearLayout 在有weight時，也會呼叫子View2次onMeasure 2.RelativeLayout的子View如果高度和RelativeLayout不同，則會引發效率問題，當子View很複雜時，這個問題會更加嚴重。如果可以，儘量使用padding代替margin。 3.在不影響層級深度的情況下,使用LinearLayout和FrameLayout而不是RelativeLayout。 最後再思考一下文章開頭那個矛盾的問題，為什麼Google給開發者預設新建了個RelativeLayout，而自己卻在DecorView中用了個LinearLayout。因為DecorView的層級深度是已知而且固定的，上面一個標題欄，下面一個內容欄。採用RelativeLayout並不會降低層級深度，所以此時在根節點上用LinearLayout是效率最高的。而之所以給開發者預設新建了個RelativeLayout是希望開發者能採用儘量少的View層級來表達佈局以實現效能最優，因為複雜的View巢狀對效能的影響會更大一些。

27.優化自定義view（百度、樂視、小米）

為了加速你的view，對於頻繁呼叫的方法，需要儘量減少不必要的程式碼。先從onDraw開始，需要特別注意不應該在這裡做記憶體分配的事情，因為它會導致GC，從而導致卡頓。在初始化或者動畫間隙期間做分配記憶體的動作。不要在動畫正在執行的時候做記憶體分配的事情。

你還需要儘可能的減少onDraw被呼叫的次數，大多數時候導致onDraw都是因為呼叫了invalidate().因此請儘量減少呼叫invaildate()的次數。如果可能的話，儘量呼叫含有4個引數的invalidate()方法而不是沒有引數的invalidate()。沒有引數的invalidate會強制重繪整個view。

另外一個非常耗時的操作是請求layout。任何時候執行requestLayout()，會使得Android UI系統去遍歷整個View的層級來計算出每一個view的大小。如果找到有衝突的值，它會需要重新計算好幾次。另外需要儘量保持View的層級是扁平化的，這樣對提高效率很有幫助。

如果你有一個複雜的UI，你應該考慮寫一個自定義的ViewGroup來執行他的layout操作。與內建的view不同，自定義的view可以使得程式僅僅測量這一部分，這避免了遍歷整個view的層級結構來計算大小。這個PieChart 例子展示瞭如何繼承ViewGroup作為自定義view的一部分。PieChart 有子views，但是它從來不測量它們。而是根據他自身的layout法則，直接設定它們的大小。

28.ContentProvider（樂視）

http://blog.csdn.net/coder_pig/article/details/47858489

29.fragment生命週期

30.volley解析（美團、樂視）

http://a.codekk.com/detail/Android/grumoon/Volley%20%E6%BA%90%E7%A0%81%E8%A7%A3%E6%9E%90

31.Android Glide原始碼解析

http://www.lightskystreet.com/2015/10/12/glidesourceanalysis/ http://frodoking.github.io/2015/10/10/android-glide/

32.Android 設計模式

http://blog.csdn.net/bboyfeiyu/article/details/44563871

33.架構設計（搜狐）

相關推薦