一、Java部分

1、java中=和equals和hashCode的區(qū)別

基本類型：=比較的是值，引用類型：=比較的是內(nèi)存地址

equals在沒有被覆藕的情況下比較的都是地址

hashCode比較的是集合，hashCode返回的是hash地址

2、int、char、long各占多少字節(jié)數(shù)

Byte:l個(gè)字節(jié)，boolean:至少一個(gè)字節(jié)，short:2個(gè)字節(jié),char:2個(gè)字節(jié),int:4個(gè)字節(jié),

float:4個(gè)字節(jié),long:8個(gè)字節(jié),double:8個(gè)字節(jié)

3、String-.StringBuffer-.StringBuilder區(qū)別

string對(duì)象不可變，后兩者是可變：string因?yàn)椴豢勺兯跃€程安全，StringBuffer對(duì)

方法加了同步鎖或者對(duì)調(diào)用的方法加了同步鎖，所以是線程安全的,StringBuilder并沒有

對(duì)方法進(jìn)行加同步鎖，所以是非線程安全的.如何程序不是多線程的，StringBuilder效

率高于StringBuffer。

4、什么是內(nèi)部類？內(nèi)部類的作用

在java語言中，可以把一個(gè)類定義到另外一個(gè)類的內(nèi)部，在類里面的這個(gè)類就叫內(nèi)部類，

外面的類就叫外部類.

作用：

1.隱藏你不想讓別人知道的操作，也即封裝性.

2.一個(gè)內(nèi)部類對(duì)象可以訪問創(chuàng)建它的外部類對(duì)象的內(nèi)容，甚至包括私有變量！

內(nèi)部類可以分為多種：主要以下4種:靜態(tài)內(nèi)部類，成員內(nèi)部類，局部內(nèi)部類，匿名內(nèi)部類

?態(tài)內(nèi)部類

靜態(tài)內(nèi)部類是指被聲明為static的內(nèi)部類，他可以不依賴內(nèi)部類而實(shí)例，而通常的內(nèi)

部類需要實(shí)例化外部類，從而實(shí)例化。靜態(tài)內(nèi)部類不可以有與外部類有相同的類名.不能

訪問外部類的普通成員變量，但是可以訪問價(jià)態(tài)成員變量和靜態(tài)方法（包括私有類型）

成員內(nèi)部類

一個(gè)冷態(tài)內(nèi)部類去掉static就是成員內(nèi)部類，他可以自由的引用外部類的屬性和方

法.無論是靜態(tài)還是非靜態(tài).但是不可以有靜態(tài)屬性和方法

局部內(nèi)部類

定義在一個(gè)代碼塊的內(nèi)類，他的作用范闈是所在代碼塊，是內(nèi)部類中最少使用的一類型.

局部內(nèi)部類跟局部變量一樣，不能被tected,private以及static修飾,只

能訪問方法中定義final類型的局部變量

匿名內(nèi)部類

匿名內(nèi)部類是一種沒有類名的內(nèi)部類，不使用class,extends,implements.沒有構(gòu)

造函數(shù)，他必須繼承其他類或?qū)崿F(xiàn)其他接口.匿名內(nèi)部類的好處是使代碼更加簡潔，緊湊,

但是帶來的問題是易讀性下降。

5、抽象類和接口區(qū)別

抽象類，

抽象方法必須用abstract關(guān)鍵字進(jìn)行修飾.如果一個(gè)類含有抽象方法，則稱這個(gè)類為抽象

類，抽象類必須在類前用abstract關(guān)鍵字修飾.

抽象類就是為了繼承而存在的

如果一個(gè)類繼承于一個(gè)抽象類，則子類必須實(shí)現(xiàn)父類的抽象方法.如果子類沒有實(shí)現(xiàn)父類

的抽象方法，則必須將子類也定義為為abstract類。

接口；

接口中的變量會(huì)被隱式地指定為publicstaticfinal變量（并且只能是publicstatic

final變量.用private修飾會(huì)報(bào)編譯錯(cuò)誤）.而方法會(huì)被隱式地指定為publicabstract

方法且只能是publicabstract方法（用其他關(guān)鍵字,比如

private,protected,static,final等修飾會(huì)報(bào)編譯錯(cuò)誤），并且接口中所仃的方法不

能有具體的實(shí)現(xiàn)，也就是說，接口中的方法必須都是抽象方法.

區(qū)別：

抽象類可以提供成G方法的實(shí)現(xiàn)細(xì)節(jié),而接口中只能存在publicabstract方法：

抽象類中的成員變量可以是各種類型的，血接口中的成員變量只能是publicstatic

final類型：

接口中不能含有常態(tài)代碼塊以及靜態(tài)方法,而抽象類可以有靜態(tài)代碼塊和靜態(tài)方法:

一個(gè)類只能繼承一個(gè)抽象類，而一個(gè)類卻可以實(shí)現(xiàn)多個(gè)接口.

6、算些情況下的對(duì)家會(huì)被垃圾回收機(jī)制處理掉？

1.沒有引用指向

2.只有弱引用指向并且不回收弱引用對(duì)象的話存儲(chǔ)區(qū)無空間

3.虛引用指向的對(duì)象

滿足以上任意條件則在gc時(shí)會(huì)回收

7、講一下常見編碼方式？

ASCII、ISO-8859-1?CB2312,CBK,UTF-8、UTF-16等

8、鼻態(tài)代理和動(dòng)態(tài)代理的區(qū)別，什么場景使用？

管態(tài)代理：由程序員創(chuàng)建或由特定工具力動(dòng)生成源代碼.再對(duì)其編譯.在程序運(yùn)行前，代

理類的.class文件就已經(jīng)存在了.

動(dòng)態(tài)代理；在程序運(yùn)行時(shí)，運(yùn)用反射機(jī)制動(dòng)態(tài)創(chuàng)建而成.

10、final,finally,finalize的區(qū)別

final:修飾類、成員變fit和成員方法.類不可被黎承，成員變量不可變，成員方法不可重

寫

finally:與try...catch...共同使用，確保無論是否出現(xiàn)異常都能被調(diào)用到

finalize:類的方法，坨圾回收之前會(huì)調(diào)用此方法,子類可以重寫finalize。方法實(shí)現(xiàn)對(duì)資

源的回收

11、Serializable和Parcelable的區(qū)別

Serializable:Java序列化接口在硬盤上讀寫讀寫過程中有大量臨時(shí)變量的生成，內(nèi)

部執(zhí)行大量的i/。操作，效率很低.

Parcelable:Android序列化接U效率高使用麻煩在內(nèi)存中讀寫（AS有相關(guān)插件一

健生成所需方法），對(duì)象不能保存到磁盤中

12、哪些情況下的對(duì)馥會(huì)被垃圾回收機(jī)制處理掉？

1.所有實(shí)例都沒有活動(dòng)線程訪問.

2.沒有被其他任何實(shí)例訪問的循環(huán)引用實(shí)例.

3.Java中有不同的引用類型.判斷實(shí)例是否符合垃圾收集的條件都依賴戶它的引用類型。

要判斷怎樣的對(duì)象是沒用的對(duì)象.這里有2種方法：

1.采用標(biāo)記計(jì)數(shù)的方法：

給內(nèi)存中的對(duì)象給打上標(biāo)記，對(duì)望被引用一次.計(jì)數(shù)就加L引用被群放了.計(jì)數(shù)就減一，

當(dāng)這個(gè)計(jì)數(shù)為0的時(shí)候,這個(gè)對(duì)象就可以被回收了.當(dāng)然，這也就引發(fā)了一個(gè)問題：循環(huán)

引用的對(duì)象是無法被識(shí)別出來并且被回收的.所以就有了第二種方法：

2.采用根搜索算法：

從一個(gè)根出發(fā)，搜索所有的可達(dá)對(duì)象.這樣剩F的那些對(duì)象就是需要被回收的

13、說說你對(duì)Java反射的理解

JAVA反射機(jī)制是在運(yùn)行狀態(tài)中，對(duì)于任意一個(gè)類，都能夠知道這個(gè)類的所有屬性和方法：

對(duì)沖任意一個(gè)對(duì)象，都能夠調(diào)用它的任意一個(gè)方法和屬性.從對(duì)象出發(fā)，通過反射

（Class類）可以取得取得類的完整信息（類名Class類型，所在包、具有的所有方法

Method口類型、某個(gè)方法的完整信息（包括修飾符、返回值類型、異常、參數(shù)類型）、所

有屬性Field口、某個(gè)屬性的完整信息、構(gòu)造器Constructors）,調(diào)用類的屬性或方法自

己的總結(jié)：在運(yùn)行過程中獲得類、對(duì)象、方法的所有信息。

14、String為什么要設(shè)計(jì)成不可變的？

1、字符串池的需求

字符串池是方法區(qū)（MethodArea）中的一塊特殊的存儲(chǔ)區(qū)域.當(dāng)一個(gè)字符串已經(jīng)被創(chuàng)建并

且該字符串在池中，該字符串的引用會(huì)立即返回給變量,而不是重新創(chuàng)建一個(gè)字符串再將

引用返回給變量.如果字符串不是不可變的,那么改變一個(gè)引用（如：string2）的字符串

將會(huì)導(dǎo)致另一個(gè)引用（如：stringl）出現(xiàn)臟數(shù)據(jù)。

2、允許字符串級(jí)存哈希碼

在java中常常會(huì)用到字符串的哈希碼,例如：HashMap.String的不變性保證哈希碼始

終一，因此，他可以不用擔(dān)心變化的出現(xiàn)。這種方法意味著不必每次使用時(shí)都重新計(jì)算一

次哈希碼一這樣，效率會(huì)高很多.

3、貽

String廣泛的用于java類中的參數(shù),如：網(wǎng)絡(luò)連接（Networkconnetion）,打開文件

（openingfiles）等等。如果String不是不可變的，網(wǎng)絡(luò)連接、文件將會(huì)被改變——這

將會(huì)導(dǎo)致一系列的安全威脅.操作的方法本以為連接上了一臺(tái)機(jī)器,但實(shí)際上卻不是.由

F反射中的參數(shù)都是字符串，同樣,也會(huì)引起一系列的安全問題.

15、List,Set,Map的區(qū)別

Set,是最簡單的一種集合。集合中的對(duì)望不按特定的方式排序，并且沒有重復(fù)對(duì)象。Set

接口主要實(shí)現(xiàn)了兩個(gè)實(shí)現(xiàn)類：HashSet：HashSet類按照哈希算法來存取集合中的對(duì)象.

存取速度比較快

TreeSet,TreeSet類實(shí)現(xiàn)了SoriedSet接口，能夠?qū)现械膶?duì)象進(jìn)行排序.

List的特征是其元素以線性方式存儲(chǔ)，集合中可以存放重旦對(duì)象。

ArrayListO：代表長度可以改變得數(shù)組。可以對(duì)元素進(jìn)行隨機(jī)的訪問，向ArrayListO

中插入與刪除元素的速度慢.

LinkedListO：在實(shí)現(xiàn)中采用鏈表數(shù)據(jù)結(jié)構(gòu).插入和射除速度快,訪問速度慢.

Map：是一種把維對(duì)象和值對(duì)象映射的集合.它的每一個(gè)元素都包含一對(duì)健對(duì)象和值對(duì)象.

Map沒有繼承于Collection接口從Map集合中檢索元素時(shí),只要給出鍵對(duì)象，就會(huì)返回

對(duì)應(yīng)的值對(duì)象.

HashMap,Map基于散列表的實(shí)現(xiàn).插入和查詢“鍵值對(duì)”的開銷是固定的.可以通過構(gòu)造

器設(shè)置容量capacity和負(fù)載因子loadfactor,以調(diào)整容器的性能.

LinkedHashMap：類似于HashMap,但是迭代遍歷它時(shí)，取得“鍵值對(duì)”的順序是其插入次

序,或者是最近/少使用(LRI)的次序。只比HashMap慢一點(diǎn).而在迭代訪問時(shí)發(fā)問更快.

因?yàn)樗褂面湵砭S護(hù)內(nèi)部次序.

TreeMapt基于紅黑樹數(shù)據(jù)結(jié)構(gòu)的實(shí)現(xiàn).查看“鍵”或“鍵值對(duì)”時(shí)，它們會(huì)被排序(次序

由Comparabel或Comparator決定).TreeMap的特點(diǎn)在于，你得到的結(jié)果是經(jīng)過排序的.

TreeMap是唯一的帶有subMap()方法的Map,它可以返回一個(gè)子樹.

VeakHasbMao：弱鍵(weakkey)Map,Vap中使用的對(duì)象也被允許新放：這是為解決將殊問

題設(shè)計(jì)的.如果沒有map之外的引用指向某個(gè)“鍵”.則此“鍵”可以被境圾收集器回收.

16、ArrayList和LinkedList的區(qū)別，以及應(yīng)用場景

ArrayList；是基廣數(shù)組實(shí)現(xiàn)的，ArrayList線程不安全.

LinkedList.是基于雙鏈表實(shí)現(xiàn)的：

使用場都

(1)如果應(yīng)用程序?qū)Ω鱾€(gè)索引位置的元素進(jìn)行大量的存取或刪除操作，ArrayList對(duì)象要

遠(yuǎn)優(yōu)于LinkedList對(duì)象：

(2)如果應(yīng)用程序主要是對(duì)列表進(jìn)行循環(huán),并且循環(huán)時(shí)候進(jìn)行插入或者刪除操作，

LinkedList對(duì)象要遠(yuǎn)優(yōu)于ArrayList對(duì)較；

17、數(shù)組和健表的區(qū)別

數(shù)組：是將兀素在內(nèi)存中連續(xù)存儲(chǔ)的：它的優(yōu)點(diǎn)：因?yàn)閿?shù)據(jù)是連續(xù)存儲(chǔ)的，內(nèi)存地址連續(xù)，

所以在查找數(shù)據(jù)的時(shí)候效率比較高：它的缺點(diǎn)：在存儲(chǔ)之前，我們需要申請(qǐng)一塊連續(xù)的內(nèi)

存空間,并且在編譯的時(shí)候就必須確定好它的空間的大小.在運(yùn)行的時(shí)候空間的大小是無

法隨著你的需要進(jìn)行增加和減少而改變的.當(dāng)數(shù)據(jù)兩比較大的時(shí)候，仃可能會(huì)出現(xiàn)越界的

情況,數(shù)據(jù)比較小的時(shí)候，又有可能會(huì)浪費(fèi)掉內(nèi)存空間。在改變數(shù)據(jù)個(gè)數(shù)時(shí)，增加、插入、

刪除數(shù)據(jù)效率比較低.

健表：是動(dòng)態(tài)申請(qǐng)內(nèi)存空間，不需要像數(shù)組需要提前申請(qǐng)好內(nèi)存的大小.鏈表只需在用的

時(shí)候申請(qǐng)就可以,根據(jù)需要來動(dòng)態(tài)申請(qǐng)或者刪除內(nèi)存空間,對(duì)于數(shù)據(jù)增加和刪除以及插入

比數(shù)組織活.還有就是鏈表中數(shù)據(jù)在內(nèi)存中可以在任意的位置，通過應(yīng)用來關(guān)聯(lián)數(shù)據(jù)(就

是通過存在元素的指針來聯(lián)系)

18、run()和start。方法區(qū)別

這個(gè)問題經(jīng)常被問到，但還是能從此區(qū)分出面試者對(duì)Java線程模型的理解程度.start0

方法被用來啟動(dòng)新創(chuàng)建的線程，而且start。內(nèi)部調(diào)用了run。方法，這和直接調(diào)用run。

方法的效果不一樣.當(dāng)你調(diào)用run()方法的時(shí)候，只會(huì)是在原來的線程中調(diào)用，沒有新的

線程啟動(dòng).start。方法才會(huì)自動(dòng)新線程.

19、如何控制某個(gè)方法允許并發(fā)訪問線程的個(gè)數(shù)？

semaphore,acquire0請(qǐng)求一個(gè)信號(hào)量,這時(shí)候的信號(hào)量個(gè)數(shù)T(一旦沒有可使用的信號(hào)

S.也即信號(hào)量個(gè)數(shù)變?yōu)樨?fù)數(shù)時(shí),再次請(qǐng)求的時(shí)候就會(huì)陽塞,直到其他線程釋放了信號(hào)量)

semaphore,release()郛放一個(gè)信號(hào)量,此時(shí)信號(hào)量個(gè)數(shù)+1

20、在Java中wait和seelp方法的不同

Java程序中wait和sleep都會(huì)造成某種形式的暫停，它們可以滿足不同的需要.waitO

方法用于線程間通信，如果等待條件為真且其它線程被喚醒時(shí)它會(huì)彈放鎖,而sleep。方

法僅僅稈放CPU資源或者讓當(dāng)前線程停止執(zhí)行一段時(shí)間,但不會(huì)群放鎖.

21、談?wù)剋ait/notify關(guān)健字的理解

等待對(duì)象的同步鎖,需要獲得該對(duì)象的同步鎖才可以調(diào)用這個(gè)方法,否則編譯可以通過，但

運(yùn)行時(shí)會(huì)收到一個(gè)異常：11legalMonitorStateException.

調(diào)用任意對(duì)象的waitO方法導(dǎo)致該線程阻塞,該線程不可繼續(xù)執(zhí)行，并且該對(duì)象上的鎖

被擇放.

喚醒在等待該對(duì)象同步鎖的線程(只喚醒一個(gè),如果有多個(gè)在等待)，注意的是在調(diào)用此方法

的時(shí)候，并不能確切的喚醒某一個(gè)等待狀態(tài)的線程,而是由JVM確定喚醒哪個(gè)線程，而且

不是按優(yōu)先級(jí).

調(diào)用任意對(duì)象的notify。方法則導(dǎo)致因調(diào)用該對(duì)象的wait。方法而阻塞的線程中隨機(jī)選

擇的一個(gè)解除阻塞（但要等到獲得鎖后才真正可執(zhí)行）。

22、什么導(dǎo)致線程阻塞？線程如何關(guān)閉？

阻塞式方法是指程序會(huì)一直等待該方法完成期間不做其他事情，ServerSocket的accept0

方法就是一直等待客戶端連接.這里的阻塞是指調(diào)用結(jié)果返回之前,當(dāng)前線程會(huì)被掛起.

直到得到結(jié)果之后才會(huì)返回.此外,還有異步和非陰塞式方法在任務(wù)完成前就返回.

一種是調(diào)用它里面的stop。方法

另一種就是你自己設(shè)重一個(gè)停止線程的標(biāo)記（推薦這種）

23、如何保證線程安全？

1.synchronized；

2.Object方法中的wait,notify：

3.ThreadLocal機(jī)制來實(shí)現(xiàn)的.

24、如何實(shí)現(xiàn)線程同步？

1、synchronized關(guān)鍵字修改的方法。

2、synchronized關(guān)鍵字修飾的語旬塊

3、使用特殊域變量（volatile）實(shí)現(xiàn)線程同步

25、淡淡對(duì)Synchronized關(guān)健字，類鎖，方法鎖，重入鎖的理解

java的對(duì)象鎖和類鎮(zhèn),java的時(shí)象鎖和類鎖在鎖的概念上基本上和內(nèi)置鎖是一致的，但是,

兩個(gè)鎖實(shí)際是有很大的區(qū)別的,對(duì)象鎖是用于對(duì)象實(shí)例方法，或者一個(gè)對(duì)象實(shí)例上的，類

鎖是用尸類的靜態(tài)方法或者一個(gè)類的class對(duì)象上的.我們知道，類的對(duì)轂實(shí)例可以有很

多個(gè)，但是每個(gè)類只有一個(gè)class對(duì)望,所以不同對(duì)象實(shí)例的對(duì)象鎖是互不干擾的，但是

每個(gè)類只有一個(gè)類鎖.但是有一點(diǎn)必須注意的是,其實(shí)類鎖只是一個(gè)概念上的東西，并不

是真實(shí)存在的，它只是用來幫助我們理解鎖定實(shí)例方法和靜態(tài)方法的區(qū)別的

26、synchronized和volatile關(guān)健字的區(qū)別

1.volatile本質(zhì)是在告訴jvm當(dāng)前變量在寄存器（工作內(nèi)存）中的值是不確定的,需要從

主存中讀?。簊ynchronized則是鎖定當(dāng)前變量，只有當(dāng)前線程可以訪問該變量.其他線程

被阻塞住.

2.volatile僅能使用在變量級(jí)別：synchronized則可以使用在變量、方法、和類級(jí)別的

3.volatile僅能實(shí)現(xiàn)變量的修改可見性，不能保證原子性：而synchronized則可以保證

變量的修改可見性和原子性

4.volatile不會(huì)造成線程的阻塞：synchronized可能會(huì)造成線程的陰塞.

5.volatile標(biāo)記的變量不會(huì)被編譯器優(yōu)化：synchronized標(biāo)記的變量可以被編譯器優(yōu)化

27、ReentrantLock、synchronized和volatile比較

ava在過去很長一段時(shí)間只能通過synchronized關(guān)鍵字來實(shí)現(xiàn)互斥，它有一些缺點(diǎn).比如

你不能擴(kuò)展鎖之外的方法或者塊邊界,嘗試獲取鎖時(shí)不能中途取消等.Java5通過Lock

接口提供了更復(fù)雜的控制來解決這些問題.ReentrantLock類實(shí)現(xiàn)了Lock,它擁有與

synchronized相同的并發(fā)性和內(nèi)存語義且它還具有可擴(kuò)展性.

28、死做的四個(gè)必要條件？

死鎮(zhèn)產(chǎn)生的原因

1.系統(tǒng)費(fèi)源的競爭

系統(tǒng)資源的競爭導(dǎo)致系統(tǒng)資源不足,以及資源分配不當(dāng),導(dǎo)致死鎖.

2.艇運(yùn)行不神

互斥條件，一個(gè)資源每次只能被一個(gè)進(jìn)程使用，即在一段時(shí)間內(nèi)某資源僅為一個(gè)進(jìn)程所占

有.此時(shí)若有其他進(jìn)程請(qǐng)求該資源,則請(qǐng)求進(jìn)程只能等待.

請(qǐng)求與保持條件：進(jìn)程已經(jīng)保持了至少一個(gè)資源.但乂提出了新的資源請(qǐng)求，而該資源已

被其他進(jìn)程占有，此時(shí)請(qǐng)求進(jìn)程被阻塞，但對(duì)白己已獲得的資源保持不放.

不可剝奪條件：進(jìn)程所獲得的資源在未使用完畢之前,不能被其他進(jìn)程強(qiáng)行奪走，即只能

由獲得該資源的進(jìn)程1*1己來絳放（只能是主動(dòng)糅放）.

循環(huán)等待條件：若干進(jìn)程間形成首尾相接循環(huán)等待資源的關(guān)系

這四個(gè)條件是死鎖的必要條件，只要系統(tǒng)發(fā)生死鎖.這些條件必然成立，而只要上述條件

之一不滿足,就不會(huì)發(fā)生死鎖。

死健的重兔與預(yù)防，

死依雉克的基本思想：

系統(tǒng)對(duì)進(jìn)程發(fā)出每一個(gè)系統(tǒng)能夠滿足的資源申請(qǐng)進(jìn)行動(dòng)態(tài)檢查，并根據(jù)檢查結(jié)果決定是否分

配資源,如果分配后系統(tǒng)可能發(fā)生死鎖,則不予分配,否則予以分配.這是一種保證系統(tǒng)不進(jìn)

入死鎖狀態(tài)的動(dòng)態(tài)策略。理解了死鎖的原因，尤其是產(chǎn)生死鎖的四個(gè)必要條件，就可以最

大可能地避免、預(yù)防和解除死鎖.所以.在系統(tǒng)設(shè)計(jì)、進(jìn)程調(diào)度等方面注意如何讓這四個(gè)

必要條件不成立，如何確定資源的合理分配算法，避免進(jìn)程永久占據(jù)系統(tǒng)資源.此外，也

要防止進(jìn)程在處于等待狀態(tài)的情況下占用資源.因此.時(shí)資源的分配要給予合理的規(guī)劃.

死鎖重兔和死《（預(yù)防的區(qū)別：

死鎖預(yù)防是設(shè)法至少破壞產(chǎn)生死鎖的四個(gè)必要條件之一,嚴(yán)格的防止死鎖的出現(xiàn),而死鎖避

免則不那么嚴(yán)格的限制產(chǎn)生死鎖的必要條件的存在，因?yàn)榧词顾梨i的必要條件存在,也不一

定發(fā)生死鎖.死鎖避免是在系統(tǒng)運(yùn)行過程中注意避免死鎖的最終發(fā)生.

29、什么是線程池，如何使用？

創(chuàng)建線程要花費(fèi)昂貴的資源和時(shí)間.如果任務(wù)來了才創(chuàng)建線程那么響應(yīng)時(shí)間會(huì)變長，而且

一個(gè)進(jìn)程能創(chuàng)建的線程數(shù)有限。為了避免這些問題.在程J節(jié)啟動(dòng)的時(shí)候就創(chuàng)建若干線程來

響應(yīng)處理,它們被稱為線程池，里面的線程叫工作線程.從JDK1.5開始，JavaAPI提供

了Executor框架讓你可以創(chuàng)建不同的線程池.比如單線程池，每次處理一個(gè)任務(wù)：數(shù)目固

定的線程池或者是緩存線程池（一個(gè)適合很多生存期短的任務(wù)的程序的可擴(kuò)展線程池）。

30、Java中堆和棧有什么不同？

為什么把這個(gè)問題歸類在多線程和并發(fā)面試題里？因?yàn)闂Ｊ且粔K和線程緊密相關(guān)的內(nèi)存區(qū)

域。每個(gè)線程都有力己的棧內(nèi)存,用于存儲(chǔ)本地變量,方法參數(shù)和棧調(diào)用，一個(gè)線程中存

儲(chǔ)的變量對(duì)其它線程是不可見的?而堆是所有線程共享的一片公用內(nèi)存區(qū)域.對(duì)象都在堆

里創(chuàng)建,為了提升效率線程會(huì)從堆中弄一個(gè)緩存到力己的棧，如果多個(gè)線程使用該變量就

可能引發(fā)問題，這時(shí)volatile變量就可以發(fā)揮作用了，它要求線程從主存中讀取變量的

值.

31、有三個(gè)線程TLT2,T3,怎么確保它們按順序執(zhí)行？

在多線程中有多種方法讓線程按特定順序執(zhí)行,你可以用線程類的join。方法在一個(gè)線程

中扇動(dòng)另一個(gè)線程,另外一個(gè)線程完成該線程繼續(xù)執(zhí)行.為了確保三個(gè)線程的順序你應(yīng)該

先啟動(dòng)最后一個(gè)（T3調(diào)用T2,T2調(diào)用T1）.這樣TI就會(huì)先完成而T3最后完成.

線程間通信

我們知道線程是CPU調(diào)度的最小單位。在Android中主線程是不能夠做耗時(shí)操作的.子線

程是不能夠更新UI的.而線程同通信的方式有很多，比如廣播.Eventbus,接口回掉，在

Android中主要是使用handler。handler通過調(diào)用sendmessage方法，將保存消息的

Message發(fā)送到Messagequeue中，而looper對(duì)象不斷的調(diào)用loop方法，從messageueue

中取出message,交給handler處理，從而完成線程間通信。

32、說下你對(duì)Collection這個(gè)類的理解.

Collection是集合框架的頂層接U,是存儲(chǔ)對(duì)象的容器,Colloction定義了接口的公用方

法如addremoveclear等等，它的子接口有兩個(gè).List和Set,List的特點(diǎn)有元素有序，

元素可以重復(fù)，元素都有索引（角標(biāo)），典型的有

Vector:內(nèi)部是數(shù)組數(shù)據(jù)結(jié)構(gòu)，是同步的（線程安全的）.增刪查詢都很慢.

ArrayList:內(nèi)部是數(shù)組數(shù)據(jù)結(jié)構(gòu)，是不同步的（線程不安全的）.替代了Vector.查詢速

度快，增刪比較慢.

LinkedList:內(nèi)部是鏈表數(shù)據(jù)結(jié)構(gòu)，是不同步的（線程不安全的）.增刪元素速度快。

血Set的是特點(diǎn)元素?zé)o序,元素不可以重復(fù)

HashSet：內(nèi)部數(shù)據(jù)結(jié)構(gòu)是哈希表.是不同步的.

Set集合中元素都必須是唯一的,HashSet作為其子類也需保證元素的唯一性.

判斷元素唯一性的方式：

通過存儲(chǔ)對(duì)象（兀素）的hashCode和equals方法來完成對(duì)象唯一性的.

如果對(duì)象的hashCode值不同，那么不用調(diào)用equals方法就會(huì)將對(duì)象直接存儲(chǔ)到集合中：

如果對(duì)象的hashCode值相同，那么需調(diào)用equals方法判斷返回值是否為true.

若為false,則視為不同元素，就會(huì)直接存儲(chǔ)：

若為true.則視為相同元素，不會(huì)存儲(chǔ).

如果要使用HashSet集合存儲(chǔ)元素,該元素的類必須覆蓋hashCode方法和equals方法.

一般情況下，如果定義的類會(huì)產(chǎn)生很多對(duì)象.通常都需要覆蠱equals.hashCode方法.建

立對(duì)象判斷是否相同的依據(jù).

TreeSet：保證元素唯一性的同時(shí)可以對(duì)內(nèi)部元素進(jìn)行排序，是不同步的.

判斷元素唯一性的方式：

根據(jù)比較方法的返回結(jié)果是否為0,如果為0視為相同元素，不存：如果非0視為不同元

素，則存.

TreeSet對(duì)元素的排序有兩種方式：

方式一：使元素（對(duì)象）對(duì)應(yīng)的類實(shí)現(xiàn)Comparable接口，覆蠱compareTo方法.這樣元素

門身具有比較功能。

方式二：使TreeSet集合白身具有比較功能.定義一個(gè)比較器Comparator,將該類對(duì)象作

為參數(shù)傳遞給TreeSet集合的構(gòu)造函數(shù)

2、Android部分

1、Activity各種情況下的生命周期

Situationl：

正常啟動(dòng)：onCreateOonStart()—onResume0:

返回健退出：onPauseOonStopO-onDestory():

Situation2:

正常自動(dòng)：onCreateO-*onStart-*0onResume();

按home健：onPauseO—onStopO;

正常啟動(dòng)：onRestart0-onStart()-*onResume();

Situations：

正常啟動(dòng)：onCreateO—onStart()-*onResume();

橫豎屏切換：onPauseO-*onStopO—onDestoryO—onCreateO-

onStart()-onResume0;

Situation4:

前提條件：Activity的AndroidManifest.xml中設(shè)置

android:configChanges=*orientation|keyboardllidden|screensize”

正常啟動(dòng)：onCreateO-*onStart0-onResume();

橫豎屏切換：onConfigurationChangedO：

結(jié)論，

設(shè)置Activity的android:configChanges=*orientation|keyboardHidden|screenSize*

時(shí)，切屏不會(huì)重新調(diào)用各個(gè)生命周期,只會(huì)執(zhí)行onConfigurationChanged方法：

自從Android3.2(API13),在設(shè)置Activity的android:configChanges=*orientation

|keyboardHidden"后，還是一樣會(huì)重新調(diào)用各個(gè)生命周期的.因?yàn)閟creensize也開始跟

著設(shè)備的橫輕切換而改變。所以，在AndroidManifest.xml里設(shè)置的MiniSdkVersion和

TargetSdkVersion屬性大于等于13的情況F，如果你想阻止程序在運(yùn)行時(shí)重新加載

Activity,除了設(shè)置"orientalion",你還必須設(shè)置"ScreenSize”。

2、橫豎屏切換的時(shí)候，Activity各種情況下的生命周期

分兩種情況：

1.不設(shè)置Activity的android:configChangesr或設(shè)置Activity的

android:configChanges=*orientation*.或設(shè)置Activity的

android:configChanges=*orientation|keyboardHidden*?切屏?xí)匦抡{(diào)用各個(gè)生命周期,

切橫屏?xí)r會(huì)執(zhí)行一次?切豎屏?xí)r會(huì)執(zhí)行一次。橫豎屏切換造成activity的生命周期

onPause()-onSaveInstanceState0-onStop()-onDestroy()-onCreat()-onStart()一

onRestoreInstanceState()-onResume()即會(huì)導(dǎo)致activity的銷毀和重建.

2.fid置android:configChanges=*orientation|keyboardHidden|screenSize*?才不會(huì)銷

毀activity,且只調(diào)用onConfiguraiionChanged方法。

onSaveInstanceState（）與onRestorelntanceStateO資源相關(guān)的系統(tǒng)配置發(fā)生改變或者

資源不足時(shí)（例如屏幕旋轉(zhuǎn)），當(dāng)前Activity會(huì)銷毀，并且在onSlop之前回調(diào)

onSavelnstanceState保存數(shù)據(jù)，在重新創(chuàng)建Activity的時(shí)候在onSlarl之后回調(diào)

onRestorelnstanceStateo其中Bundle數(shù)據(jù)會(huì)傳到onCreaie（不一定有數(shù)據(jù)）和

onRestoreInstanceState（一定有數(shù)據(jù)）.

用戶或者程序員主動(dòng)去銷毀一個(gè)Activity的時(shí)候不會(huì)回調(diào)（如代碼中finish（）或用戶

按卜.back,不會(huì)回調(diào)），其他情況都會(huì)調(diào)用，來保存界面信息.

3、Activity與Fragment之間生命周期比較

ActivityStateFragmentCallbacks

onAttach()

Created

onCreate()

onCreateView()

onActivityCreatedO

StartedonStart()

ResumedonResumeO

PausedonPauseQ

StoppedonStopf)

onDestroyVewQ

Destroyed

■

onDestroyO

onDetach()

4、兩個(gè)Activity之間跳轉(zhuǎn)時(shí)必然會(huì)執(zhí)行的是哪幾個(gè)方法?

一般情況下比如說有兩個(gè)activity,分別叫A,B.當(dāng)在A里面激活B組件的時(shí)候，A會(huì)調(diào)

用onPauseO方法，然后B調(diào)用onCreateO,onStart（）,onResume0.這個(gè)時(shí)候B漫蠱了

A的窗體,A會(huì)調(diào)用onSiopO方法.如果B是個(gè)透明的窗口，或者是對(duì)話框的樣式，就不會(huì)

調(diào)用A的onStopO方法.如果B已經(jīng)存在于Activity棧中，B就不會(huì)調(diào)用onCreateO方

法.

5、內(nèi)存泄漏的場景和解決辦法

1.非靜態(tài)內(nèi)部類的靜態(tài)實(shí)例

非靜態(tài)內(nèi)部類會(huì)持有外部類的引用，如果非靜態(tài)內(nèi)部類的實(shí)例是靜態(tài)的,就會(huì)長期的維持

著外部類的引用，組織被系統(tǒng)回收，解決辦法是使用靜態(tài)內(nèi)部類

2.多線程相關(guān)的匿名內(nèi)部類和非靜態(tài)內(nèi)部類

匿名內(nèi)部類同樣會(huì)持有外部類的引用，如果在線程中執(zhí)行耗時(shí)操作就有可能發(fā)生內(nèi)存泄漏，

導(dǎo)致外部類無法被回收，直到耗時(shí)任務(wù)結(jié)束,解決辦法是在頁面退出時(shí)結(jié)束線程中的任務(wù)

3.Handler內(nèi)存泄漏

Handler導(dǎo)致的內(nèi)存泄漏也可以被歸納為非靜態(tài)內(nèi)部類導(dǎo)致的.Handler內(nèi)部message是被

存儲(chǔ)在MessageQueue中的，有些message不能馬上被處理，存在的時(shí)間會(huì)很長，導(dǎo)致

handler無法被回收，如果handler是非靜態(tài)的，就會(huì)導(dǎo)致它的外部類無法被回收.解決

辦法是1.使用靜態(tài)handler,外部類引用使用弱引用處理2.在退出頁面時(shí)移除消息隊(duì)列中

的消息

4.Context導(dǎo)致內(nèi)存ift漏

根據(jù)場景確定使用Activity的Context還是Application的Context,因?yàn)槎呱芷?/p>

不同，對(duì)于不必須使用Activity的Context的場景（Dialog）,一律采用Application的

Context.單例模式是最常見的發(fā)生此泄漏的場景,比如傳入一個(gè)Activity的Context被靜

態(tài)類引用，導(dǎo)致無法回收

5.靜態(tài)View導(dǎo)致泄漏

使用靜態(tài)View可以避免每次扇動(dòng)Activity都去讀取并渲染View,但是靜態(tài)View會(huì)持有

Activity的引用，導(dǎo)致無法回收，解決辦法是在Activity銷毀的時(shí)候?qū)㈧o態(tài)View設(shè)置為

null（View一旦被加載到界面中將會(huì)持有一個(gè)Context對(duì)象的引用，在這個(gè)例子中,這個(gè)

context對(duì)象是我們的Activity,聲明一個(gè)靜態(tài)變量引用這個(gè)View,也就引用了

activity）

6.WebView導(dǎo)致的內(nèi)存泄漏

呢bView只要使用一次，內(nèi)存就不會(huì)被林放.所以WebVie*都存在內(nèi)存泄漏的問題，通常

的解決辦法是為WebYiew單開一個(gè)進(jìn)程,使用AIDL進(jìn)行通信，根據(jù)業(yè)務(wù)需求在合適的時(shí)機(jī)

料放掉

7.資源對(duì)象未關(guān)閉導(dǎo)致

如Cursor,File等，內(nèi)部往往都使用了緩沖,會(huì)造成內(nèi)存泄漏，一定要確保關(guān)閉它并將引

用置為null

8.集合中的對(duì)象未清理

集合用于保存對(duì)蒙,如果集合越來越大,不進(jìn)行合理的清理，尤其是入股集合是靜態(tài)的

9.Bitmap導(dǎo)致內(nèi)存泄漏

bitmap是比較占內(nèi)存的,所以一定要在不使用的時(shí)候及時(shí)進(jìn)行清理，避免靜態(tài)變量持有大

的bitmap對(duì)象

10.監(jiān)聽器未關(guān)閉

很多需要register和unregister的系統(tǒng)服務(wù)要在合適的時(shí)候進(jìn)行unregisier，下動(dòng)添加

的listener也需要及時(shí)移除

6、如何避免00M?

1.使用更加輕量的數(shù)據(jù)結(jié)構(gòu)：如使用ArrayMap/SparseArray替代HashMap,HashMap更耗內(nèi)

存，因?yàn)樗枰~外的實(shí)例對(duì)象來記錄Mapping操作,SparseArray更加高效.因?yàn)樗?/p>

免了KeyValue的白動(dòng)裝箱，和裝箱后的解箱操作

2.便面枚舉的使用,可以用靜態(tài)常量或者注解@IniDef替代

3.Bitmap優(yōu)化:

a.尺寸壓縮：通過InSampleSize設(shè)置合適的縮放

b.顏色質(zhì)量：設(shè)置合適的format,ARGB_6666/RBG_545/ARGB_4444/ALPHA_6,存在很大差

異

c.inBitmap:使用inBitmap屬性可以告知Bitmap解碼器去嘗試使用已經(jīng)存在的內(nèi)存區(qū)域，

新解碼的Bitmap會(huì)嘗試去使用之前那張Bitmap在Heap中所占據(jù)的pixeldata內(nèi)存區(qū)域,

而不是去問內(nèi)存重新中清一塊區(qū)域來存放Bitmap.利用這種特性，即使是上千張的圖片.

也只會(huì)僅僅只需要占用屏幕所能夠顯示的圖片數(shù)量的內(nèi)存大小,但復(fù)用存在一些限制,具

體體現(xiàn)在：在Android4.4之前只能重用相同大小的Bitmap的內(nèi)存，而Android4.4及以

后版本則只要后來的Bitmap比之前的小即可。使用inBitmap參數(shù)前,每創(chuàng)建一個(gè)Bitmap

對(duì)象都會(huì)分配一塊內(nèi)存供其使用，而使用了inBitmap參數(shù)后，多個(gè)Bitmap可以復(fù)用一塊

內(nèi)存，這樣可以提高性能

4.StringBuilder替代String:在有些時(shí)候.代碼中會(huì)需要使用到大量的字符串拼接的操

作，這種時(shí)候有必要考慮使用String&iilder來替代頻繁的“+”

5.避免在類似onDraw這樣的方法中創(chuàng)建對(duì)象,因?yàn)樗鼤?huì)迅速占用大量內(nèi)存，引起頻繁的

GC甚至內(nèi)存抖動(dòng)

6.減少內(nèi)存泄漏也是一種避免00M的方法

7、ANR的原因

1.耗時(shí)的網(wǎng)絡(luò)訪問

2.大量的數(shù)據(jù)讀寫

3.數(shù)據(jù)庫操作

4.硬件操作（比如camera）

5.調(diào)用thread的join。方法、sleep。方法、wait。方法或者等待線程鎖的時(shí)候

6.servicebinder的數(shù)量達(dá)到上限

7.systemserver中發(fā)生WatchDogANR

8.service忙導(dǎo)致超時(shí)無響應(yīng)

9.其他線程持有鎖.導(dǎo)致主線程等待超時(shí)

10.其它線程終止或崩潰導(dǎo)致主線程一直等待

8、說下Activity的啟動(dòng)模式，生命周期，兩個(gè)Activity跳轉(zhuǎn)的生命周期，如

果一個(gè)Activity跳轉(zhuǎn)另一個(gè)Activity再按下Home健在回到Activity的生命

周期是什么樣的

啟動(dòng)模式

Standard模式:Activity可以有多個(gè)實(shí)例,每次啟動(dòng)Activity,無論任務(wù)棧中是否已經(jīng)有

這個(gè)Activity的實(shí)例，系統(tǒng)都會(huì)創(chuàng)建一個(gè)新的Activity實(shí)例

SingleTop模式：當(dāng)一個(gè)singleTop模式的Activity已盔位4■,任務(wù)棧的棧頂,再去啟動(dòng)它

時(shí)，不會(huì)再創(chuàng)建新的實(shí)例，如果不位于棧頂，就會(huì)創(chuàng)建新的實(shí)例

SingleTask模式：如果Activity已經(jīng)位于棧頂，系統(tǒng)不會(huì)創(chuàng)建新的Activity實(shí)例.和

singleTop模式一樣.但Activity已經(jīng)存在但不位于棧頂時(shí),系統(tǒng)就會(huì)把該Activity移

到棧頂，并把它上面的activity出棧

Singlelnstance模式：singlelnstance模式也是單例的，但和singleTask不同，

singleTask只是任務(wù)棧內(nèi)單例,系統(tǒng)里是可以有多個(gè)singleTaskActivity實(shí)例的.而

singlelnstanceActivity在整個(gè)系統(tǒng)里只有一個(gè)實(shí)例，啟動(dòng)一singlelnstanceActivity

時(shí)，系統(tǒng)會(huì)創(chuàng)建一個(gè)新的任務(wù)棧,并且這個(gè)任務(wù)棧只有他一個(gè)Activity

生命周期

onCreateonStartonResumeonPauseonStoponDestroy

兩個(gè)Activity跳轉(zhuǎn)的生命周期

1.啟動(dòng)A：onCreate-onStart-onResume

2.在A中啟動(dòng)B：ActivityAonPause->ActivityBonCreate->ActivityBonStart-

>ActivityBonResume->ActivityAonStop

3.從B中返回A(按物理硬件返回地)

ActivityBonPause->ActivityAonRestart->ActivityAonStart->ActivityA

onResume->ActivityBonStop->ActivityBonDestroy

4.繼續(xù)返回

ActivityAonPause->ActivityAonStop->ActivityAonDestroy

9、onRestart的調(diào)用場景

(1)按下home鍵之后，然后切換回來，會(huì)調(diào)用onRestart()。

(2)從本Activity跳轉(zhuǎn)到另一個(gè)Activity之后,按back鍵返回原來Activity,會(huì)調(diào)用

onRestart0；

(3)從本Activity切換到其他的應(yīng)用,然后再從其他應(yīng)用切換回來，會(huì)調(diào)用onRestart。：

說卜Activity的橫睡屏的切換的生命周期,用那個(gè)方法來保存數(shù)據(jù)，兩者的區(qū)別。觸發(fā)在

什么時(shí)候在那個(gè)方法里可以獲取數(shù)據(jù)等.

10、是否了解Surfaceview,它是什么？他的繼承方式是什么？他與View的區(qū)

別(從源碼角度，如加*,繪制等).

SurfaceVie*中采用了雙緩沖機(jī)制.保證了UI界面的流暢性，同時(shí)SurfaceView不在主線

程中繪制，而是另開辟一個(gè)線程去繪制,所以它不妨礙門線程：

SurfaceView繼承于View,他和View主要有以下三點(diǎn)區(qū)別：

(1)View底層沒有雙線沖機(jī)制,SurfaceView有：

(2)view主要適用于主動(dòng)更新,而SurfaceView適用與被動(dòng)的更新,如頻繁的刷新

(3)view會(huì)在主線程中去更新UL而SurfaceView則在子線程中刷新:

SurfaceView的內(nèi)容不在應(yīng)用窗口上，所以不能使用變換(平移、縮放、旋轉(zhuǎn)等)。也難

以放在ListView或者ScrollView中,不能使用LI控件的一些特性比如View.setAlphaO

View：顯示視圖,內(nèi)置通布,提供圖形繪制函數(shù)、觸屏事件、按鍵事件函數(shù)等：必須在UI

主線程內(nèi)更新畫面，速度較慢.

SurfaceView：基于view視圖進(jìn)行拓展的視圖類,更適合2D游戲的開發(fā)：是view的子類，

類似使用雙緩機(jī)制，在新的線程中更新畫面所以刷新界面速度比view快，Camera預(yù)覽界

面使用SurfaceView.

GLSurfaceView：基于SurfaceView視圖再次進(jìn)行拓展的視圖類，專用于3D游戲開發(fā)的視

圖：是SurfaceView的子類，openGL專用.

11、如何實(shí)現(xiàn)進(jìn)程?；?/p>

a:Service設(shè)置成START_STICKYkill后會(huì)被重啟（等待5秒左右）,重傳Intent.保持

與重啟前一樣

b:通過startForeground將進(jìn)程設(shè)置為前臺(tái)進(jìn)程，做前臺(tái)服務(wù)，優(yōu)先級(jí)和前臺(tái)應(yīng)用一個(gè)

級(jí)別，除非在系統(tǒng)內(nèi)存非常缺,否則此進(jìn)程不會(huì)被kill

c:雙進(jìn)程Service：讓2個(gè)進(jìn)程互相保護(hù)對(duì)方，其中一個(gè)Service被清理后，另外沒被

清理的進(jìn)程可以立即重后進(jìn)程

d:用C編寫守護(hù)進(jìn)程（即子進(jìn)程）：Android系統(tǒng)中當(dāng)前進(jìn)程（Process）fork出來的子進(jìn)程，

被系統(tǒng)認(rèn)為是兩個(gè)不同的進(jìn)程.當(dāng)父進(jìn)程被殺死的時(shí)候.子進(jìn)程仍然可以存活，并不受影

響（Android5.0以上的版本不可行）聯(lián)系廠商，加入白名單

e.鎖屏狀態(tài)下，開啟一個(gè)一像素Activity

12、說下冷啟動(dòng)與熱啟動(dòng)是什么，區(qū)別，如何優(yōu)化，使用場景等.

app冷后動(dòng)：當(dāng)應(yīng)用行動(dòng)時(shí),后臺(tái)沒有該應(yīng)用的進(jìn)程,這時(shí)系統(tǒng)會(huì)重新創(chuàng)建一個(gè)新的進(jìn)程

分配給該應(yīng)用，這個(gè)啟動(dòng)方式就叫做冷后動(dòng)（后臺(tái)不存在該應(yīng)用進(jìn)程）。冷啟動(dòng)因?yàn)橄到y(tǒng)

會(huì)重新創(chuàng)建一個(gè)新的進(jìn)程分配給它.所以會(huì)先創(chuàng)建和初始化Application類，再創(chuàng)建和初

始化MainActivity類（包括一系列的測量、布局、繪制），最后顯小在界面上.

app熱啟動(dòng)：當(dāng)應(yīng)用已經(jīng)被打開，但是被按下返回鍵、Home屣等按鍵時(shí)回到臬面或者是

其他程序的時(shí)候,再重新打開該app時(shí)，這個(gè)方式叫做熱啟動(dòng)（后臺(tái)已經(jīng)存在該應(yīng)用進(jìn)程）

.熱啟動(dòng)因?yàn)闀?huì)從已有的進(jìn)程中來舊動(dòng)，所以熱啟動(dòng)就不會(huì)走Application這步了,而是

直接走M(jìn)ainActivity（包括一系列的測殳、布局、繪制），所以熱啟動(dòng)的過程只需要?jiǎng)?chuàng)建

和初始化一個(gè)MainActivity就行了，而不必創(chuàng)建和初始化Application

冷出動(dòng)的流程

當(dāng)點(diǎn)擊app的后動(dòng)圖標(biāo)時(shí)，安卓系統(tǒng)會(huì)從Zygote進(jìn)程中fork創(chuàng)建出一個(gè)新的進(jìn)程分配給

該應(yīng)用，之后會(huì)依次創(chuàng)建和初始化Application類、創(chuàng)建MainActivity類、加載主題樣式

Theme中的windowBackground等屬性設(shè)置給MainActivity以及配置Activity層級(jí)上的一

些屬性、再inflate布局、當(dāng)onCreate/onStart/onResume方法都走完了后最后才進(jìn)行

contentView的measure/1ayout/draw顯示在界面上

冷自動(dòng)的生命周期簡要流程：

Application構(gòu)造方法->attachBaseContextO-〉onCreate->Activity構(gòu)造方法-〉

onCreateO->fid置主體中的背景等操作->onStart（）->onResume（）->測量、布

局、繪制顯示

冷啟動(dòng)的優(yōu)化主要是視覺上的優(yōu)化,解決白屏問題，提高用戶體驗(yàn),所以通過上面冷啟動(dòng)

的過程。能做的優(yōu)化如下：

減少onCreateO方法的工作量

不要讓Application參與業(yè)務(wù)的操作

不要在Application進(jìn)行耗時(shí)操作

不要以靜態(tài)變量的方式在Application保存數(shù)據(jù)

減少布局的復(fù)雜度和層級(jí)

減少主線程耗時(shí)

13、為什么冷啟動(dòng)會(huì)有白屏黑屏問題?

原因在于加載主題樣式Theme中的windowBackground等屬性設(shè)置給MainActivity發(fā)生在

inflate布局當(dāng)onCreate/onStari/onResume方法之前，而windowBackground背景被設(shè)置

成了白色或者黑色，所以我們進(jìn)入app的第一個(gè)界面的時(shí)候會(huì)造成先白屏或黑屏一卜再進(jìn)

入界面.解決思路如下

1.給他設(shè)置windowBackground背景跟啟動(dòng)頁的背景相同，如果你的扇動(dòng)頁是張圖片那么可

以直接給windowBackground這個(gè)屬性設(shè)置該圖片那么就不會(huì)有一閃的效果了

<stylename='\"Splash_Theme"'"parent=?android:style/Theme.NoTitleBar*">'

(itemname='""androidrwindowBackground'"'>?drawable/splash_bg</item>"

<itemname='"androidiwindowNoTitle*''>'true\</item></style>

2.采用世面的處理方法，設(shè)置背景是透明的.給人一種延遲啟動(dòng)的感覺.，將背景顏色設(shè)置

為透明色,這樣當(dāng)用戶點(diǎn)擊桌面APP圖片的時(shí)候.并不會(huì)"立即"進(jìn)入APP,而且在桌面上停

留一會(huì)，其實(shí)這時(shí)候APP已經(jīng)是啟動(dòng)的了，只是我們心機(jī)的把Theme里的

windowBackground的顏色設(shè)置成透明的,強(qiáng)行把鍋甩給了手機(jī)應(yīng)用廠商(手機(jī)反應(yīng)太慢了

啦)

<stylename="""Splash_Theme"，parent="'"6android:style/Theme.NoTitleBar*'">'

<itemname=""android:windowlsTranslucent">>,true'</item>"

〈itemname="'*，android:windowNoTitle<，"'>'"true'-</item>'</style>"

3.以上兩種方法是在視覺上顯得更快,但其實(shí)只是一種表象,讓應(yīng)用啟動(dòng)的更快,有一種

思路，耨Application中的不必要的初始化動(dòng)作實(shí)現(xiàn)懶加載，比如，在SpashActivity顯

示后再發(fā)送消息到Application,去初始化,這樣可以將初始化的動(dòng)作放在后邊,縮短應(yīng)

用啟動(dòng)到用戶看到界面的時(shí)間

14、四大組件的生命周期和筒單用法

Activity：

onCreate()->onStart()->onResume0->onPause()->onStop()->onDestory0onCreateO：

為Activity設(shè)置布局，此時(shí)界面還不可見：onStartO:Activity可見但還不能與用戶

交互，不能獲得焦點(diǎn)onReslartO：重新啟動(dòng)Activity時(shí)被回調(diào)。onResumeO:

Activity可見且可與用戶進(jìn)行交互

onPauseO:當(dāng)前Activity暫停，不可與用戶交互，但還可見。在新Activity自動(dòng)前被

系統(tǒng)調(diào)

用保存現(xiàn)有的Activity中的持久數(shù)據(jù)、停止動(dòng)畫等.onStopO:當(dāng)Activity被新的

Activity覆蓋不可見時(shí)被系統(tǒng)調(diào)用.onDestoryO:當(dāng)Activity被系統(tǒng)銷毀殺掉或是由

于內(nèi)存不足時(shí)調(diào)用

Service

a)onBind方式綁定的：onCreate->onBind->onUnBind->onDeslory(不管調(diào)用

bindService兒

次，onCreate只會(huì)調(diào)用一次，onSlarl不會(huì)被調(diào)用.建立連接后，service會(huì)一直運(yùn)行，

直到

調(diào)用unBindService或是之前調(diào)用的bindService的Context不存在了，系統(tǒng)會(huì)自動(dòng)停

止

Service,時(shí)應(yīng)的onDestory會(huì)被調(diào)用)

b)startService后動(dòng)的：onCreHie->onStartCommand->onDeslory(start多次，

onCreate只會(huì)被

調(diào)用一次，onStart會(huì)調(diào)用多次.該service會(huì)在后臺(tái)運(yùn)行，直至被調(diào)用stopService

或是

stopSelf）

c）又被啟動(dòng)又被綁定的服務(wù)，不管如何調(diào)用onCreateO只被調(diào)用一次，startService調(diào)

用多

少次，onStart就會(huì)被調(diào)用多少次，而unbindService不會(huì)停止服務(wù)，必須調(diào)用

stopService

或是stopSelf來停止服務(wù).必須unbindService和stopService（stopSelf）同時(shí)都調(diào)

用了才會(huì)停止服務(wù).

BroadcastReceiver

a）動(dòng)態(tài)注冊(cè)：存活周期是在Context.registerReceiver和

Context.unregisterReceiver之間，

BroadcastReceiver每次收到廣播都是使用注冊(cè)傳入的對(duì)象處理的.

b）靜態(tài)注冊(cè)：進(jìn)程在的情況下,receiver會(huì)正常收到廣播,調(diào)用onReceive方法：生命

周

期只存活在onReceive函數(shù)中.此方法結(jié)束.BroadcastReceiver就銷毀了.onReceive。只

有

十幾秒存活時(shí)間，在onReceive。內(nèi)操作超過10S,就會(huì)報(bào)ANR.

進(jìn)程不存在的情況，廣播相應(yīng)的進(jìn)程會(huì)被拉活,Application.onCreate會(huì)被調(diào)用,再調(diào)用

onReceive.

ContentProvider?

應(yīng)該和應(yīng)用的生命周期一樣,它屬于系統(tǒng)應(yīng)用.應(yīng)用啟動(dòng)時(shí),它會(huì)跟

著初始化，應(yīng)用關(guān)閉或被殺.它會(huì)跟著結(jié)束。

15、Activity之間的通信方式

1）通過Intent方式傳遞參數(shù)跳轉(zhuǎn)

2）通過廣播方式

3）通過接口回調(diào)方式

4）借助類的靜態(tài)變量或全局變量

5）借助SharedPreference或是外部存儲(chǔ).如數(shù)據(jù)庫或本地文件

16、Activity狀態(tài)保存于恢復(fù)

Activity被主動(dòng)回收時(shí)，如按下Back鍵.系統(tǒng)不會(huì)保存它的狀態(tài)，只有被動(dòng)回收時(shí)，雖

然

這個(gè)Activity實(shí)例已被銷毀，但系統(tǒng)在新建一個(gè)Activity實(shí)例時(shí)，會(huì)帶上先前被回收

Activity的信息.在當(dāng)前Activity被銷毀前調(diào)用onSaveInstanceState（onPause和

onStop之間保存）.

重新創(chuàng)建Activity后會(huì)在onCreate后調(diào)用onRestorelnstanceState（onStart和

onResume之

間被調(diào)用），它們的參數(shù)Bundle用來數(shù)據(jù)保存和讀取的.保存View狀態(tài)有兩個(gè)前提：

View的子類必須實(shí)現(xiàn)了onSaveInstanceState：必須要設(shè)定Id,這個(gè)ID作為Bundle

的Key

17、Fragment狀態(tài)保存onSavelnstanceState是哪個(gè)類的方法，在什么情況

下使用？

在對(duì)應(yīng)的FragmentActivity.onSavelnstanceState方法會(huì)調(diào)用

Fragmentcontroller.saveAHState.其中會(huì)對(duì)mActive中各個(gè)Fragmeni的實(shí)例狀態(tài)和

View狀態(tài)分別進(jìn)行保存.當(dāng)Activity在做狀態(tài)保存和恢復(fù)的時(shí)候，在它其中的fragment

ri然也需要做狀態(tài)保存和恢復(fù).

18、Fragment.startActivityForResult是和FragmentActivity的

startActivityForResult?

如果希望在Fragment的onAclivilyResult接收數(shù)據(jù)，就要調(diào)用

Fragment,startActivityForResu11,ifij不是Fragment.getActivity0.

startActivityForResulto

Fragment.startActivityForResult-

>FragmentActivitymHost.HostCa11backs.onStartActivityFromFragment-

>FragmentActivity.startActivityFromFragment?如果request=-l則直接調(diào)用

FragmentActivity.startActivityForResult?它會(huì)重新計(jì)算requestCode,使其大于

0xfffffo

19、如何實(shí)現(xiàn)Fragment的滑動(dòng)？

ViewPager+FragmentPagerAdapter+List<Fragment>

20、fragment之間傳遞數(shù)據(jù)的方式？

1）在相應(yīng)的fragment中編寫方法，在需要回調(diào)的fragment里獲取對(duì)應(yīng)的Fragment實(shí)

例，

調(diào)用相應(yīng)的方法：

2）采用接口回調(diào)的方式進(jìn)行數(shù)據(jù)傳遞：

a）在Fragment1中創(chuàng)建一個(gè)接口及接口對(duì)應(yīng)的set方法：b）在Fragment1中調(diào)用接口

的方

法：c）在Fragment2中實(shí)現(xiàn)該接口：

3）利用第三方開源框架EventBus

21、service和activity怎么進(jìn)行數(shù)據(jù)交互？

1)通過bindService啟動(dòng)服務(wù).可以在ServiceConnection的onServiceConnec1ed中

獲取到

Service的實(shí)例，這樣就可以調(diào)用service的方法,如果service想調(diào)用activity的

方法，可以

在service中定義接口類及相應(yīng)的set方法,在activity中實(shí)現(xiàn)相應(yīng)的接口,這樣

service就可以回調(diào)接口言法：

2)通過廣播方式

22、說說Contentprovider-,ContentResolver>Contentobserver之間的關(guān)系

ContentProvider實(shí)現(xiàn)各個(gè)應(yīng)用程序間數(shù)據(jù)共享,用來提供內(nèi)容給別的應(yīng)用操作。如聯(lián)系

人

應(yīng)用中就使用了ContentProvider,可以在門己應(yīng)用中讀取和修改聯(lián)系人信息，不過需要

獲

取相應(yīng)的權(quán)限.它也只是一個(gè)中間件,真正的數(shù)據(jù)源是文件或SQLite等.

ContentResolver內(nèi)容解析者，用于獲取內(nèi)容提供者提供的數(shù)據(jù)，通過

ContentResolver.notifyChange(uri)發(fā)出消息Contentobserver內(nèi)容監(jiān)聽者，可以監(jiān)聽

數(shù)據(jù)的改變狀態(tài)，觀察特定Iri引起的數(shù)據(jù)庫變化.維而做一些相應(yīng)的處理，類似于數(shù)

據(jù)庫中的觸發(fā)器，當(dāng)Contentobserver所觀察的Uri發(fā)生變化時(shí)，便會(huì)觸發(fā)它。

23、請(qǐng)描述一下廣播BroadcastReceiver的理解

Broadcas