下面對這段時間面試遇到的問題進行整理，分享給大家供大家參考，具體內(nèi)容如下
java基礎(chǔ)：
1、內(nèi)存泄露的原因
1)、資源對象沒關(guān)閉。
如cursor、file等資源。他們會在finalize中關(guān)閉，但這樣效率太低。容易造成內(nèi)存泄露。
sqlitecursor，當數(shù)據(jù)量大的時候容易泄露
2）、使用adapter時，沒有使用系統(tǒng)緩存的converview。
3）、即時調(diào)用recycle（）釋放不再使用的bitmap。
適當降低bitmap的采樣率，如：
|
1
2
3
|
bitmapfactory.options options = newbitmapfactory.options(); options.insamplesize = 2;//圖片寬高都為原來的二分之一，即圖片為原來的四分之一 bitmap bitmap =bitmapfactory.decodestream(cr.openinputstream(uri), null, options); preview.setimagebitmap(bitmap); |
4）、使用application的context來替代activity相關(guān)的context。
盡量避免activity的context在自己的范圍外被使用，這樣會導(dǎo)致activity無法釋放。
5）、注冊沒取消造成內(nèi)存泄露
如：廣播
6）、集合中的對象沒清理造成的內(nèi)存泄露我們通常把一些對象的引用加入到了集合中，當我們不需要該對象時，并沒有把它的引用從集合中清理掉，這樣這個集合就會越來越大。如果這個集合是static的話，那情況就更嚴重了。
7）、handler應(yīng)該申明為靜態(tài)對象， 并在其內(nèi)部類中保存一個對外部類的弱引用。如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
static class myhandler extends handler { weakreference<activity > mactivityreference; myhandler(activity activity) { mactivityreference= new weakreference<activity>(activity); } @override public void handlemessage(message msg) { final activity activity = mactivityreference.get(); if (activity != null) { mimageview.setimagebitmap(mbitmap); } }} |
2、arraylist和linkedlist的區(qū)別
- arraylist初試大小為10，大小不夠會調(diào)用grow擴容：length = length + (length >> 1)
- linkedlist中node first,last。分別指向頭尾
arraylist和linkedlist在性能上各 有優(yōu)缺點，都有各自所適用的地方，總的說來可以描述如下：
1）、對arraylist和linkedlist而言，在列表末尾增加一個元素所花的開銷都是固定的。對 arraylist而言，主要是在內(nèi)部數(shù)組中增加一項，指向所添加的元素，偶爾可能會導(dǎo)致對數(shù)組重新進行分配；而對linkedlist而言，這個開銷是 統(tǒng)一的，分配一個內(nèi)部entry對象。
2）、在arraylist的 中間插入或刪除一個元素意味著這個列表中剩余的元素都會被移動；而在linkedlist的中間插入或刪除一個元素的開銷是固定的。
3）、linkedlist不 支持高效的隨機元素訪問。
4）、arraylist的空 間浪費主要體現(xiàn)在在list列表的結(jié)尾預(yù)留一定的容量空間，而linkedlist的空間花費則體現(xiàn)在它的每一個元素都需要消耗相當?shù)目臻g。
可以這樣說：當操作是在一列 數(shù)據(jù)的后面添加數(shù)據(jù)而不是在前面或中間,并且需要隨機地訪問其中的元素時,使用arraylist會提供比較好的性能；當你的操作是在一列數(shù)據(jù)的前面或中 間添加或刪除數(shù)據(jù),并且按照順序訪問其中的元素時,就應(yīng)該使用linkedlist了。
3、hashmap和hashtable的不同
1）、繼承不同。
|
1
2
|
public class hashtable extends dictionary implements mappublic class hashmap extends abstractmap implements map |
2）、hashtable 中的方法是同步的，而hashmap中的方法在缺省情況下是非同步的。在多線程并發(fā)的環(huán)境下，可以直接使用hashtable，但是要使用hashmap的話就要自己增加同步處理了。
3）、hashtable中，key和value都不允許出現(xiàn)null值。
在hashmap中，null可以作為鍵，這樣的鍵只有一個；可以有一個或多個鍵所對應(yīng)的值為null。當get()方法返回null值時，即可以表示 hashmap中沒有該鍵，也可以表示該鍵所對應(yīng)的值為null。因此，在hashmap中不能由get()方法來判斷hashmap中是否存在某個鍵， 而應(yīng)該用containskey()方法來判斷。
4）、兩個遍歷方式的內(nèi)部實現(xiàn)上不同。
hashtable、hashmap都使用了 iterator。而由于歷史原因，hashtable還使用了enumeration的方式 。
5）、哈希值的使用不同，hashtable直接使用對象的hashcode。而hashmap重新計算hash值。
6.hashtable和hashmap它們兩個內(nèi)部實現(xiàn)方式的數(shù)組的初始大小和擴容的方式。hashtable中hash數(shù)組默認大小是11，增加的方式是 old*2+1。hashmap中hash數(shù)組的默認大小是16，而且一定是2的指數(shù)。
4、iterator和enumeration的不同
1）、函數(shù)接口不同
enumeration只有2個函數(shù)接口。通過enumeration，我們只能讀取集合的數(shù)據(jù)，而不能對數(shù)據(jù)進行修改。 iterator只有3個函數(shù)接口。iterator除了能讀取集合的數(shù)據(jù)之外，也能數(shù)據(jù)進行刪除操作。
2）、iterator支持fail-fast機制，而enumeration不支持。 enumeration 是jdk 1.0添加的接口。使用到它的函數(shù)包括vector、hashtable等類，這些類都是jdk 1.0中加入的，enumeration存在的目的就是為它們提供遍歷接口。enumeration本身并沒有支持同步，而在vector、hashtable實現(xiàn)enumeration時，添加了同步。而iterator 是jdk 1.2才添加的接口，它也是為了hashmap、arraylist等集合提供遍歷接口。iterator是支持fail-fast機制的：當多個線程對同一個集合的內(nèi)容進行操作時，就可能會產(chǎn)生fail-fast事件。
ail-fast 機制是java集合(collection)中的一種錯誤機制。當多個線程對同一個集合的內(nèi)容進行操作時，就可能會產(chǎn)生fail-fast事件。例如：當某一個線程a通過iterator去遍歷某集合的過程中，若該集合的內(nèi)容被其他線程所改變了；那么線程a訪問集合時，就會拋出concurrentmodificationexception異常，產(chǎn)生fail-fast事件。
5、接口的注意點
1）、接口中的字段全部默認為 public static類型。
2）、接口中的方法全部默認為 public類型。
3）、接口中可以申明內(nèi)部類，而默認為public static，正因為是static，只是命名空間屬于接口，代碼邏輯不屬于接口。所以不違法接口定義。
4）、接口本身可以申明為public或者缺省。
5）、抽象類繼承自某接口。如果在抽象類中實現(xiàn)了父類（接口）中的方法，在其子類可以不用實現(xiàn)，否則在子類必須實現(xiàn)。
6、final方法
將方法聲明為final那有兩個原因，第一就是說明你已經(jīng)知道這個方法提供的功能已經(jīng)滿足你要求，不需要進行擴展，并且也不允許任何從此類繼承的類來覆寫這個方法，但是繼承仍然可以繼承這個方法，也就是說可以直接使用。第二就是允許編譯器將所有對此方法的調(diào)用轉(zhuǎn)化為inline調(diào)用的機制，它會使你在調(diào)用final方法時，直接將方法主體插入到調(diào)用處，而不是進行例行的方法調(diào)用，例如保存斷點，壓棧等，這樣可能會使你的程序效率有所提高，然而當你的方法主體非常龐大時，或你在多處調(diào)用此方法，那么你的調(diào)用主體代碼便會迅速膨脹，可能反而會影響效率，所以你要慎用final進行方法定義。
android知識點
1、handler機制
1）、handler對activity finish影響。
在開發(fā)的過程中碰到一個棘手的問題，調(diào)用activity.finish函數(shù)acitivity沒有執(zhí)行生命周期的ondestory函數(shù)，后面查找半天是因為有一個handler成員，因為它有一個delay消息沒有處理，調(diào)用activity.finish，activity不會馬上destory，所以記得在ativity finish前清理一下handle中的未處理的消息，這樣activity才會順利的destory
2）、looper
通過調(diào)用looper.prepare()創(chuàng)建looper()對象并綁定到threadlocal變量中。
looper里面包含了messagequeue。
構(gòu)造器如下：
|
1
2
3
4
5
6
|
private looper(){ mqueue = new messagequeue(); mrun = true; mthread = thread.currentthread();} |
3）、loop()函數(shù)
1）從looper中取出messagequeue；
2）循環(huán)從messagequeue中取出message；
3）從message中取出target（handler對象）；
4）調(diào)用tartget的dispatchmessage分發(fā)消息。
4）、handler對象
重要成員變量：
|
1
2
3
|
final messagequeue mqueue;final looper mlooper;final callback mcallback; //用于回調(diào) |
handler對象在發(fā)送消息的時候，將msg的target變量設(shè)為自己。這樣在looper對象循環(huán)取出msg的時候就可以調(diào)用對應(yīng)handler的dispatchmessage()。此函數(shù)分發(fā)消息的優(yōu)先級如下：
message在創(chuàng)建的時候調(diào)用obtain設(shè)置了callback。
handler在創(chuàng)建的時候傳入了callback。
交給handler子類的handlemessage處理（通常的做法）。
2、android啟動模式
standard和singletop模式。
這兩種比較簡單。創(chuàng)建activity放入當前的任務(wù)棧中，若當前是singleinstace，則放入設(shè)置的任務(wù)棧中。其中如果activity在棧頂，則調(diào)用onnewintent。
singletask：棧內(nèi)復(fù)用模式。不是在當前任務(wù)棧中查找是否存在，實際過程如下：
1）、查找該activity所需的任務(wù)棧是否存在（由taskaffinity控制，或者默認為包名）。
2）、在任務(wù)棧當中查找該activity是否存在。
這里面存在任務(wù)棧的切換，也就是當開啟的singtask類型的activity不屬于當前任務(wù)棧時，則會切換到其任務(wù)棧。
singleinstance：單實例模式。
包含了singletask的所有特性，另外加上：設(shè)置為該模式的activity，只能單獨存在于一個任務(wù)棧中。當有兩個singleinstace的activity設(shè)置成同樣的任務(wù)棧時，會出現(xiàn)兩個同名的任務(wù)棧，分別用來存放同名的activity。
注：在任何跳轉(zhuǎn)的時候，首先調(diào)用本activity的onpause，然后跳轉(zhuǎn)。如果被跳轉(zhuǎn)的activity由于啟動方式而沒創(chuàng)建新的實例，則會先調(diào)用onnewintent，然后按照正常的生命周期調(diào)用。
如
1：a→b，a：onpause；b：oncreate，onstart，onresume。
2：a(singletop)→a，a：onpause；a：onsaveinstancestate；a：onresume。
以上是我遇到和搜集到的各類題目以及相應(yīng)的解答，接下來一段時間也會持續(xù)更新，希望大家繼續(xù)關(guān)注。
也祝愿大家可以找到自己喜歡的工作。
