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