- 相關(guān)推薦
android面試常見(jiàn)問(wèn)題
Android面試中HR常問(wèn)的問(wèn)題會(huì)有哪些呢?結(jié)合以往自己的經(jīng)歷,下面是小編為大家收集整理的android面試常見(jiàn)問(wèn)題，歡迎閱讀。
1，PendingIntent 和Intent的區(qū)別：
PendingIntent就是一個(gè)Intent的描述，我們可以把這個(gè)描述交給別的程序，別的程序根據(jù)這個(gè)描述在后面的別的時(shí)間做你安排做的事情
換種說(shuō)法Intent字面意思是意圖，即我們的目的，我們想要做的事情，在activity中，我們可以立即執(zhí)行它
PendingIntent 相當(dāng)于對(duì)intent執(zhí)行了包裝，我們不一定一定要馬上執(zhí)行它，我們將其包裝后，傳遞給其他activity或application
這時(shí)，獲取到PendingIntent的application 能夠根據(jù)里面的intent來(lái)得知發(fā)出者的意圖，選擇攔截或者繼續(xù)傳遞或者執(zhí)行。
Android的四個(gè)基本組件中：—— Activity，Service和Broadcast Receiver——都是通過(guò)Intent機(jī)制激活的，不同類型的組件有不同的傳遞Intent方式：
要激活一個(gè)新的Activity，或者讓一個(gè)現(xiàn)有的Activity做新的操作，可以通過(guò)調(diào)用Context.startActivity()或者Activity.startActivityForResult()方法。
要啟動(dòng)一個(gè)新的Service，或者向一個(gè)已有的Service傳遞新的指令，調(diào)用Context.startService()方法或者調(diào)用Context.bindService()方法將調(diào)用此方法的上下文對(duì)象與Service綁定。
Context.sendBroadcast()、Context.sendOrderBroadcast()、Context.sendStickBroadcast()這三個(gè)方法可以發(fā)送Broadcast Intent。發(fā)送之后，所有已注冊(cè)的并且擁有與之相匹配IntentFilter的BroadcastReceiver就會(huì)被激活。
2，Android中的尺寸，以及dp,px,sp的區(qū)別和聯(lián)系：
px:表示屏幕實(shí)際的像素。 320*480 :標(biāo)示：在橫向320個(gè)縱向480個(gè)像素。
pt:標(biāo)示一個(gè)點(diǎn)，時(shí)屏幕的物理尺寸，大小為1英寸的七十二分之一。
in：標(biāo)示英寸，時(shí)屏幕的物理尺寸，每英寸等于2.54厘米。例如，形容手機(jī)大小為3.2英寸，是說(shuō)屏幕對(duì)角線的大小。
dp與sp標(biāo)尺單位的又來(lái)及計(jì)算方法：
像素尺寸：240*320 320*240 320*480 480*800 480*854 640*960 720*1280，
屏幕物理尺寸：3.2、3.5、3.75、4.0、4.3、5.0、7、9.3、10.1
0.75 1.5 2xhdpi xxhdpi3 4 8
android 程序代碼部分 采用像素為單位
程序的布局所有的尺寸都是采用dp為單位。
公式 ：一個(gè)dp數(shù)值轉(zhuǎn)換為px的數(shù)字：
px = dp * (dpi/160)
例如：10dp --> 在mdpi dpi = 160 ;因此 10dp = 10px。
像素密度：dpi:每英寸像素?cái)?shù)： 如 手機(jī)為：240*320 像素分辨率，大小為：1.5*2 英寸。像素密度：240/1.5 = 320/2 =160dpi。
譬如1280x720物理分辨率，5英寸大小的屏幕，其dpi 的計(jì)算方法是：sqrt(1280*1280+720*720)/5 = 293.72 dpi
譬如1280x720物理分辨率，5英寸大小的屏幕上，54dp
這個(gè)高度如何轉(zhuǎn)換成 px 呢，計(jì)算方法是：54dp * 293.72/160+0.5f = 99.6305px，約為 100px。
dpi = 60
Ldpi = 120 3
mpdpi = 160 4
hdpi= 240 6
xHdpi = 320 8
[java] view plain copy
import android.content.Context;
public class DensityUtil {
/**
* 根據(jù)手機(jī)的分辨率從 dp 的單位 轉(zhuǎn)成為 px(像素)
*/
public static int dip2px(Context context, float dpValue) {
final float scale = context.getResources().getDisplayMetrics().density;
return (int) (dpValue * scale + 0.5f);
}
/**
* 根據(jù)手機(jī)的分辨率從 px(像素) 的單位 轉(zhuǎn)成為 dp
*/
public static int px2dip(Context context, float pxValue) {
final float scale = context.getResources().getDisplayMetrics().density;
return (int) (pxValue / scale + 0.5f);
}
}
dp,sp,px之間的區(qū)別和聯(lián)系：
dp也就是dip,這個(gè)和sp基本類似。
若是 設(shè)置長(zhǎng)度，高度等屬性時(shí)，可以使用dp,或者sp。但如果設(shè)置字體，需要使用sp。
dp是與密度無(wú)關(guān)，sp除了與密度無(wú)關(guān)外，還與scale無(wú)關(guān)。如果屏幕密度為160，這時(shí)dp和sp和px是一樣的。1dp = 1sp = 1px，但如果使用px作單位，如果屏幕大小不變（假設(shè)是3.2寸），而屏幕密度變?yōu)榱?20，那么原來(lái)的TextView的寬度設(shè)置成160px,在密度為320的3.2寸屏幕里看到要比在密度為160的3.2寸屏幕上看短了一半。但如果設(shè)置成160dp或者160sp的話。系統(tǒng)會(huì)自動(dòng)將width屬性值設(shè)置成320px的。也就是160*320/160。其中320/160可稱為密度比例因子。
如果使用dp和sp,系統(tǒng)會(huì)根據(jù)屏幕密度的變化自動(dòng)轉(zhuǎn)換。
3，關(guān)于scrool+ListView：
1，所有的容器在顯示內(nèi)容之前，都需要進(jìn)行排版，排版的時(shí)候，都需要獲取內(nèi)部子控件或子容器的尺寸，通過(guò)尺寸才可以進(jìn)行排版。
2，所有的View內(nèi)部都有一個(gè)回調(diào)的方法，onMeasure這個(gè)方法，
3, ScroolView內(nèi)部控件 進(jìn)行尺寸計(jì)算 onMeasure()的時(shí)候，
參數(shù)模式 是 UNSPECIFIED.
ListView的onMeasure :方法，檢測(cè)模式 如果是 UNSPECINIED,listView則永遠(yuǎn)只有一行。
4，Http請(qǐng)求數(shù)據(jù)，get,Post的區(qū)別：
在HTTP請(qǐng)求消息中，請(qǐng)求方式有GET、POST、HEAD、OPTIONS、DELETE、TRACE、PUT和CONNECT八種。而在以后們最常用的有兩種請(qǐng)求方式：POST請(qǐng)求、GET請(qǐng)求。
get和post區(qū)別：
GET:從指定的服務(wù)器中獲取數(shù)據(jù)，POST-提交數(shù)據(jù)給指定的服務(wù)器處理。
1，使用GET方法時(shí)，查詢字符串會(huì)以鍵值對(duì)的形式附加在action所指向的url的后面一起發(fā)送到服務(wù)器。
2，使用POST方法時(shí)，查詢字符串在POST信息中單獨(dú)存在，和HTTP請(qǐng)求一起發(fā)送到服務(wù)器。
3,get是從服務(wù)器上獲取數(shù)據(jù)，post是用來(lái)向服務(wù)器上傳遞數(shù)據(jù)。
特點(diǎn)：
get:
get請(qǐng)求 能 夠被緩存下來(lái)。
get請(qǐng)求 會(huì) 保存在瀏覽器的 瀏覽記錄中。
以GET 請(qǐng)求的URL能夠保存為 瀏覽器書簽。
GET請(qǐng)求的URL能夠 保存為瀏覽器書簽。
GET請(qǐng)求 有長(zhǎng)度限制。
GET請(qǐng)求 主要用以獲取數(shù)據(jù)。
post:
數(shù)據(jù)量大小為128k.
HTTP協(xié)議規(guī)范也沒(méi)有對(duì)URL長(zhǎng)度進(jìn)行限制。這個(gè)限制是特定的瀏覽器及服務(wù)器對(duì)它的限制。IE對(duì)URL長(zhǎng)度的限制是2083字節(jié)(2K+35)。對(duì)于其他瀏覽器，如Netscape、FireFox等，理論上沒(méi)有長(zhǎng)度限制，其限制取決于操作系統(tǒng)的支持。
http和https的區(qū)別：
https 是以安全為目標(biāo)的HTTP通道，簡(jiǎn)單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎(chǔ)是SSL，因此加密的詳細(xì)內(nèi)容就需
要SSL。它是一個(gè)URI scheme（抽象標(biāo)識(shí)符體系）。句法類同http:體系。用于安全的HTTP數(shù)據(jù)傳輸。
https：url表明它使用了HTTP,但HTTPS存在不同于HTTP的默認(rèn)端口及一個(gè)加密/身份驗(yàn)證與加密通訊方法。 被廣泛應(yīng)用于萬(wàn)維網(wǎng)上安全敏感的通訊，例如交易支付方面。
5，Handler的介紹：
android提供了Handler和Looper來(lái)滿足線程間的通信，Handler先進(jìn)先出原則，Looper類來(lái)管理特定線程內(nèi)對(duì)象之間的消息轉(zhuǎn)換。
1，Looper:一個(gè)線程可以產(chǎn)生一個(gè)Looper對(duì)象，由他來(lái)管理此線程里的MessageQueue(消息隊(duì)列);
2，Handler:用于push新消息到MessageQueue里，或者接受Looper從MessageQueue送來(lái)的消息。
3，MessageQueue:用來(lái)存放線程放入的消息。
4，Message對(duì)象:handler用于傳遞的數(shù)據(jù)信息。
handler創(chuàng)建消息：
handler消息機(jī)制中引入了消息池，Handler創(chuàng)建消息時(shí)首先查詢消息池中是否有消息存在。如果有直接從消息池中取得，如果沒(méi)有則重新初始化一個(gè)消息實(shí)例。消息不被使用時(shí)，并不作為垃圾回收，而是放入消息池�？晒┫麓蜨andler創(chuàng)建消息時(shí)使用。
Handler持有對(duì)UI主線程消息隊(duì)列MessageQueue和循環(huán)Looper的引用。子線程可以通過(guò)Handler將消息發(fā)送到UI線程的消息隊(duì)列MessageQueue中。
Handler處理消息：
UI主線程通過(guò)Looper循環(huán)查詢消息隊(duì)列的UI_MQ,當(dāng)發(fā)現(xiàn)有消息存在時(shí)會(huì)將消息從隊(duì)列中取出。首先分析消息，通過(guò)消息的參數(shù)判斷該消息對(duì)應(yīng)的Handler,然后將消息分發(fā)到指定的Handler進(jìn)行處理。
handler message messageQueue
每一個(gè)消息發(fā)送到主線程的MessageQueue中，MessageQueue遵循先進(jìn)先出原則，發(fā)送消息不會(huì)阻塞線程，而接收線程會(huì)阻塞線程。Handler允許發(fā)送并處理Message消息，Message對(duì)象通過(guò)主線程的MessageQueue消息隊(duì)列相關(guān)聯(lián)的Message和Runnable對(duì)象進(jìn)行存取。每個(gè)Handler實(shí)例對(duì)Message消息發(fā)送和接收與對(duì)應(yīng)主線程和主線程的消息隊(duì)列有關(guān)。當(dāng)創(chuàng)建一個(gè)新的Handler時(shí)，Handler就屬于當(dāng)前主線程，主線程MessageQueue消息隊(duì)列也同步創(chuàng)建，即Handler會(huì)綁定到創(chuàng)建該Handler的主線程/消息隊(duì)列上。然后，Handler就可以通過(guò)主線程的消息隊(duì)列發(fā)送和接收Message消息對(duì)象了。
6，java的內(nèi)存機(jī)制：
內(nèi)存:
寄存器,方法區(qū),棧,堆,本地方法區(qū)。
方法區(qū):存類的信息,常量池,靜態(tài)方法區(qū).
棧(值類型):存放調(diào)用方法的局部變量,
存儲(chǔ)在棧中的變量,作用域結(jié)束立即消失.
堆(引用類型):存數(shù)組或者引用對(duì)象.
特點(diǎn):
1,分配內(nèi)存首地址。
2,有默認(rèn)值。
3,有g(shù)c(垃圾回收機(jī)制)。
本地方法區(qū):實(shí)現(xiàn)類庫(kù)的調(diào)用.
注意:常量池中,Java默認(rèn)創(chuàng)建-128~127之間的常量對(duì)象. 對(duì)于字符串常量會(huì)首先去常量池中查找,如果不存在就創(chuàng)建字符串常量.字符串常量對(duì)像保存在字符串常量池中.
7，raw和assert中的資源有什么區(qū)別：
raw和asserts文件夾的相同點(diǎn)：
1,兩者目錄下的文件在打包后會(huì)原封不動(dòng)的保存在apk包中。不會(huì)被編譯成二進(jìn)制。
不同點(diǎn)：
1,raw文件夾中的文件會(huì)被映射到R.java文件中。訪問(wèn)的時(shí)候直接使用資源id即R.id.fileName;assert不會(huì)被映射到R.java中。訪問(wèn)的時(shí)候需要AssertManager類。
2，raw不可以有目錄結(jié)構(gòu)，而assert則可以有目錄結(jié)構(gòu)，也就是assert下可以再建立文件夾。
讀取文件資源:
inputStream is = getResources().openRawResource(R.id.filename);
讀取assert下的文件資源，通過(guò)以下方式獲取輸入流來(lái)進(jìn)行寫操作。
AssertManager am = null; am = getAssert(); InputStream is = am.open("fileName");
8，fileInputStream 與dataInputStream區(qū)別
FileInputStream是實(shí)體流，也就是真實(shí)做事情的流，用來(lái)讀文件的。使用該類創(chuàng)建對(duì)象時(shí)，系統(tǒng)會(huì)自動(dòng)將需要讀的文件轉(zhuǎn)換成該類的流對(duì)象，你可以直接讀取。DataInputStream是裝飾流，必須建立在其他實(shí)體流的基礎(chǔ)之上。如果用軟件來(lái)類比流的話，那么操作系統(tǒng)就是實(shí)體流，而一般的應(yīng)用軟件則是裝飾流。因?yàn)閼?yīng)用軟件以操作系統(tǒng)軟件為基礎(chǔ)
9,LayoutInfalter 的參數(shù) 兩個(gè)和三個(gè)參數(shù)的區(qū)別？
View inflate(int resource, ViewGroup root)
View inflate(int resource , ViewGroup root, boolean attachToRoot)
第二個(gè)參數(shù) 是指 實(shí)例的布局所要放入的根視圖。一般我們?cè)诓恍枰獙⒃摬季址湃敫晥D的時(shí)候都會(huì)把第二個(gè)數(shù)傳為null。
第三個(gè) 參數(shù)為 是否將 第二個(gè)視圖引用到第一個(gè)資源文件上。。
10,Linux進(jìn)程 和線程：
進(jìn)程是程序執(zhí)行時(shí)的一個(gè)實(shí)例，即它是程序已經(jīng)執(zhí)行到各種程度的數(shù)據(jù)結(jié)構(gòu)的匯集。從內(nèi)核的觀點(diǎn)看，進(jìn)程的目的就是擔(dān)當(dāng)分配系統(tǒng)資源（CPU時(shí)間、內(nèi)存等）的基本單位。
線程是進(jìn)程的一個(gè)執(zhí)行流，是CPU調(diào)度和分派的基本單位，它是比進(jìn)程更小的能獨(dú)立運(yùn)行的基本單位。一個(gè)進(jìn)程由幾個(gè)線程組成（擁有很多相對(duì)獨(dú)立的執(zhí)行流的用戶程序共享應(yīng)用程序的大部分?jǐn)?shù)據(jù)結(jié)構(gòu)），線程與同屬一個(gè)進(jìn)程的其他的線程共享進(jìn)程所擁有的全部資源。
11,android是什么：
是基于Linux內(nèi)核的軟件平臺(tái)和操作系統(tǒng)，早期由Google開(kāi)發(fā)
Android平臺(tái)手機(jī)5大優(yōu)勢(shì)：
一、開(kāi)放性.
二、掙脫運(yùn)營(yíng)商的束縛.
三、豐富的硬件選擇.
四、不受任何限制的開(kāi)發(fā)商
五、無(wú)縫結(jié)合的Google應(yīng)用
12,Intent的七大屬性：
data（Data屬性 通常用于向Action屬性提供操作的數(shù)據(jù)。Data屬性的值是個(gè)Uri對(duì)象）
extras（提供操作的額外數(shù)據(jù)，可以為各種對(duì)象）
category (類別)
flags（為Intent添加控制標(biāo)記，同activity，LaunchMode）
action
intentFalter (意圖過(guò)濾器，通過(guò)action查找該intent。)
type（Type屬性用于指定Data所指定的Uri對(duì)應(yīng)的MIME類型).
13,fragment和activity的生命周期
fragment生命周期
onAttach(); onCreate(); onCreateView(); onActivityCreated(); onStart(); onResume();
onPause(); onStop(); onDestoryView(); onDestory(); onDetach();
activity的生命周期：
onCreated()，onStart()，onRestart()，onResume()，onPaused()，onStoped()，onDestroyed（）
14，事件分發(fā)機(jī)制：
TouchEvent事件發(fā)生時(shí)Activity的dispatchTouchEvent（MotionEvent ev）會(huì)以隧道方式從根元素依次往下傳遞直到內(nèi)層子元素或在中間元素由于某一條件停止傳遞。
dispatchTouchEvent事件的分發(fā)邏輯：
1，返回true，進(jìn)行處理，事件分發(fā)給當(dāng)前view的dispatchTouchEvent方法進(jìn)行消費(fèi)，同時(shí)事件會(huì)停止向下傳遞。
2，返回false，事件向下分發(fā)，此時(shí)事件分發(fā)分為兩種：如果當(dāng)前view獲取的事件來(lái)自Activity，則會(huì)將事件返回給父View的Activity的onTouchEvent進(jìn)行消費(fèi)。如果當(dāng)前View獲取的事件來(lái)自父外層控件，則會(huì)將事件返回給父View的onTouchEvent進(jìn)行消費(fèi)。
3，如果返回系統(tǒng)默認(rèn)的super.dispatchTouchEvent(ev),事件會(huì)自動(dòng)的分發(fā)給當(dāng)前View的onInterceptTouchEvent方法。
事件攔截方法：onInterceptTouchEvent(MotionEvent ev)
1，在外層的View的dispatchTouchEvent(MotionEvent ev) 方法返回系統(tǒng)默認(rèn)的super.dispatchTouchEvent(ev)情況下，事件會(huì)自動(dòng)的分發(fā)給當(dāng)前View的onInterceptTouch
Event方法，onInterceptTouchEvent方法，onInterceptTouchEvent的事件攔截邏輯如下：
1，如果onInterceptTouchEvent返回true 標(biāo)示事件將進(jìn)行攔截，并將攔截到的事件交由當(dāng)前view的onTouchEvent進(jìn)行處理。
2，如果onInterceptTouchEvent返回false,則表示將事件放行，不進(jìn)行攔截，當(dāng)前view上的事件會(huì)被傳遞到子View上，再由子view的dispatchTouchEvent來(lái)開(kāi)始這個(gè)事件的分發(fā)。
3，如果返回super，則默認(rèn)攔截并將攔截到的事件交由當(dāng)前的View的onTouchEvent進(jìn)行處理。
事件響應(yīng)：onTouchEvent（MotionEvent ev）
1，在dispatchTouchEvent返回super的情況下, 并且onInterceptTouchEvent返回false或者返回super的情況下onTouchEvent會(huì)被調(diào)用。onTouchEvent的事件相應(yīng)邏輯如下：
1，如果事件傳遞到當(dāng)前View的onTouchEvent方法，而該方法返回了false，那么這個(gè)事件會(huì)從當(dāng)前View向上傳遞，并且都是由上一層View的onTouchEvent來(lái)接受，如果傳遞到上面的onTouchEvent也返回false,這個(gè)事件就會(huì)消失，而且接受不到下一次事件。
2,如果改事件rue 則會(huì)接受消費(fèi)該事件。
3，如果返回super默認(rèn)處理事件的邏輯和返回false相同。
15，IntentReceiver作用：
當(dāng)你希望你的應(yīng)用能夠?qū)σ粋�(gè)外部的事件(如當(dāng)電話呼入時(shí)，或者數(shù)據(jù)網(wǎng)絡(luò)可用時(shí)，或者到了晚上時(shí))做出響應(yīng)，你可以使用一個(gè)IntentReceiver。雖然IntentReceiver 在感興趣的事件發(fā)生時(shí)，會(huì)使用NotificationManager通知用戶，但它并不能生成一個(gè)UI。IntentReceiver 在AndroidManifest.xml 中注冊(cè)，但也可以在代碼中使用Context.registerReceiver()進(jìn)行注冊(cè)。當(dāng)一個(gè)intentreceiver 被觸發(fā)時(shí)，你的應(yīng)用不必對(duì)請(qǐng)求調(diào)用intentreceiver，系統(tǒng)會(huì)在需要的時(shí)候啟動(dòng)你的應(yīng)用。各種應(yīng)用還可以通過(guò)使用Context.broadcastIntent()將它們自己的intentreceiver 廣播給其它應(yīng)用程序。
16，UDP和TCP,三次握手和四次揮手：:
UDP（）：半雙工。傳輸快，不安全。信息量要求速度的適用。
TCP:(請(qǐng)求響應(yīng)方式)
三次握手：
第一次握手：建立連接時(shí)，客戶端發(fā)送syn包（syn=j）到服務(wù)器，并進(jìn)入SYN_SEND狀態(tài)，等待服務(wù)器確認(rèn)；SYN:同步序列編號(hào)（Synchronize Sequence Numbers）。
第二次握手：服務(wù)器收到syn包，必須確認(rèn)客戶的SYN（ack=j+1），同時(shí)自己也發(fā)送一個(gè)SYN包（syn=k），即SYN+ACK包，此時(shí)服務(wù)器進(jìn)入SYN_RECV狀態(tài)；
第三次握手：客戶端收到服務(wù)器的SYN + ACK包，向服務(wù)器發(fā)送確認(rèn)包ACK(ack=k+1），此包發(fā)送完畢，客戶端和服務(wù)器進(jìn)入ESTABLISHED（TCP連接成功）狀態(tài)，完成三次握手。
連接終止協(xié)議（四次揮手）：
由于TCP連接是全雙工的，因此每個(gè)方向都必須單獨(dú)進(jìn)行關(guān)閉。這原則是當(dāng)一方完成它的數(shù)據(jù)發(fā)送任務(wù)后就能發(fā)送一個(gè)FIN來(lái)終止這個(gè)方向的連接。收到一個(gè) FIN只意味著這一方向上沒(méi)有數(shù)據(jù)流動(dòng)，一個(gè)TCP連接在收到一個(gè)FIN后仍能發(fā)送數(shù)據(jù)。首先進(jìn)行關(guān)閉的一方將執(zhí)行主動(dòng)關(guān)閉，而另一方執(zhí)行被動(dòng)關(guān)閉。
�。�1） TCP客戶端發(fā)送一個(gè)FIN，用來(lái)關(guān)閉客戶到服務(wù)器的數(shù)據(jù)傳送（報(bào)文段4）。
�。�2） 服務(wù)器收到這個(gè)FIN，它發(fā)回一個(gè)ACK，確認(rèn)序號(hào)為收到的序號(hào)加1（報(bào)文段5）。和SYN一樣，一個(gè)FIN將占用一個(gè)序號(hào)。
�。�3） 服務(wù)器關(guān)閉客戶端的連接，發(fā)送一個(gè)FIN給客戶端（報(bào)文段6）。
（4） 客戶段發(fā)回ACK報(bào)文確認(rèn)，并將確認(rèn)序號(hào)設(shè)置為收到序號(hào)加1（報(bào)文段7）。
17，http1.1訪問(wèn)網(wǎng)絡(luò)的八種方式：
http協(xié)議請(qǐng)求由三部分組成，分別是：請(qǐng)求行、消息報(bào)頭、請(qǐng)求正文。
請(qǐng)求行以一個(gè)方法符號(hào)開(kāi)頭，以空格分開(kāi)，后面跟著請(qǐng)求的URI和協(xié)議的版本，格式如下：
Method Request-URI HTTP-Version CRLF
1，HTTP/1.0協(xié)議使用非持久連接,即在非持久連接下,一個(gè)tcp連接只傳輸一個(gè)Web對(duì)象,；
2，HTTP/1.1默認(rèn)使用持久連接(然而,HTTP/1.1協(xié)議的客戶機(jī)和服務(wù)器可以配置成使用非持久連接)。
OPTIONS：返回服務(wù)器針對(duì)特定資源所支持的HTTP請(qǐng)求方法。也可以利用向Web服務(wù)器發(fā)送'*'的請(qǐng)求來(lái)測(cè)試服務(wù)器的功能性。
HEAD：向服務(wù)器索要與GET請(qǐng)求相一致的響應(yīng)，只不過(guò)響應(yīng)體將不會(huì)被返回。這一方法可以在不必傳輸整個(gè)響應(yīng)內(nèi)容的情況下，就可以獲取包含在響應(yīng)消息頭中的元信息。
GET：向特定的資源發(fā)出請(qǐng)求。注意：GET方法不應(yīng)當(dāng)被用于產(chǎn)生“副作用”的操作中。
POST：向指定資源提交數(shù)據(jù)進(jìn)行處理請(qǐng)求（例如提交表單或者上傳文件）。數(shù)據(jù)被包含在請(qǐng)求體中。POST請(qǐng)求可能會(huì)導(dǎo)致新的資源的建立和/或已有資源的修改。
PUT：向指定資源位置上傳其最新內(nèi)容。
DELETE：請(qǐng)求服務(wù)器刪除Request-URI所標(biāo)識(shí)的資源。
TRACE：回顯服務(wù)器收到的請(qǐng)求，主要用于測(cè)試或診斷。
CONNECT：HTTP/1.1協(xié)議中預(yù)留給能夠?qū)⑦B接改為管道方式的代理服務(wù)器
18，F(xiàn)ragment的優(yōu)化：
hide 和 add
正確的切換方式是add()，切換時(shí)hide()，add()另一個(gè)Fragment；再次切換時(shí)，只需hide()當(dāng)前，show()另一個(gè)。
/**
* 切換頁(yè)面的重載，優(yōu)化了fragment的切換
*
* @param f
* @param descString
*/
public void switchFragment(Fragment from, Fragment to) {
if (from == null || to == null)
return;
FragmentTransaction transaction = getSupportFragmentManager()
.beginTransaction().setCustomAnimations(R.anim.tran_pre_in,
R.anim.tran_pre_out);
if (!to.isAdded()) {
// 隱藏 當(dāng)前的fragment，add下一個(gè)到Activity中
transaction.hide(from).add(R.id.fl_main, to).commit();
} else {
// 隱藏當(dāng)前的fragment，顯示下一個(gè)
transaction.hide(from).show(to).commit();
}
// 讓menu回去
menu.toggle();
}
19：aidl線程間通信介紹：
android系統(tǒng)中的進(jìn)程之間不能共享內(nèi)存，因此，需要提供一些機(jī)制在不同進(jìn)程之間進(jìn)行數(shù)據(jù)通信。
aidl是一種接口定義語(yǔ)言，用與兩個(gè)進(jìn)程間的通訊規(guī)則，共編譯器生成代碼。實(shí)現(xiàn)android設(shè)備上的兩個(gè)進(jìn)程間通信。
定義步驟：
1，在項(xiàng)目中創(chuàng)建一個(gè)擴(kuò)展名為aidl的文件，該文件的語(yǔ)法類似于java代碼。
2，如果aidl文件的內(nèi)容是正確的，工具會(huì)自動(dòng)生成一個(gè)java接口文件。
3，建立一個(gè)服務(wù)類（service的子類）。
4，實(shí)現(xiàn)由aidl文件生成的java接口。
5，在注冊(cè)文件中配置AIDL服務(wù)，標(biāo)簽中的android：name的屬性就是客戶端要引用該服務(wù)的ID。也就是intent的參數(shù)值。
在Android 中，AiDL是一種接口定義語(yǔ)言，編譯器通過(guò)*.aidl文件的描述信息生成符合通信協(xié)議的java代碼，我們無(wú)需自己去寫這段繁雜的代碼，只需要在需要的時(shí)候調(diào)用即可。通過(guò)這種方式我們就可以完成進(jìn)程間的通信工作。
20，單元測(cè)試的步驟和方法：
第一步：
在安卓注冊(cè)文件的應(yīng)用程序application代碼塊中添加代碼：
在application外部添加代碼：
<instrumentation android:name="android.test.InstrumentionTestRunner"
android:targetPackage = "xx.xx.x.x" android:label = "Tests for My App"/>
第二部 ：
新建普通類繼承 AndroidTestCase類。編寫測(cè)試方法：必須以public void開(kāi)頭，盡量拋出異常。在該方法中調(diào)用需要測(cè)試的方法或代碼。
第三步：將鼠標(biāo)放在測(cè)試代碼的測(cè)試方法上，點(diǎn)擊run as方法運(yùn)行測(cè)試。
---集成測(cè)試：
主要是在單元測(cè)試的基礎(chǔ)上測(cè)試接口訪問(wèn)或者異步任務(wù)是否正確。
21，數(shù)字簽名的作用：
1，目的是保證軟件包的完整性包含軟件發(fā)布者的證書信息。
2，作用：
1，確保軟件包沒(méi)有被修改，
2，android系統(tǒng)根據(jù)相同軟件id來(lái)區(qū)分軟件，如果相同的id，只要證書不同，那么不允許安裝，除非卸
載原有程序，保護(hù)數(shù)據(jù)。
3，證書可以包含有效期，如果一個(gè)軟件證書的有效期過(guò)期了，android不允許程序再運(yùn)行了。
1，Key Store:用于 保存公鑰和私鑰，公鑰包含證書信息；開(kāi)發(fā)工具使用keystore文件來(lái)進(jìn)行數(shù)字簽名。
2，團(tuán)隊(duì)中應(yīng)該使用相同的keystore文件，進(jìn)行代碼的調(diào)試和打包，主要針對(duì)百度地圖這種，需要證書信息的，
3，如公司已經(jīng)提供keystore，那么直接復(fù)制出來(lái)，放到自己的電腦上。
4，若沒(méi)有提供，需要?jiǎng)?chuàng)建一個(gè) 放到工程中。
keyStore文件的生成：
1，推薦 在工程中創(chuàng)建keyStore文件，團(tuán)隊(duì)就可以協(xié)同工作了。
2，名詞：key alias別名：在創(chuàng)建的時(shí)候，可以給每一個(gè)秘鑰對(duì)私鑰，指定一個(gè)名稱。
這樣就。
22,Android內(nèi)存的優(yōu)化：
android優(yōu)化：內(nèi)存控制，循環(huán)使用。圖片的優(yōu)化（二次采樣）。
內(nèi)存優(yōu)化：
1，減少內(nèi)存占有。
2，及時(shí)的緩存。
3，把不適用的內(nèi)存置空
4，圖片比較大的 進(jìn)行二次采樣。
android 代碼優(yōu)化的核心原則：
1、字符串頻繁操作時(shí)，多用StringBuffer而少用String
2、盡量使用本地變量，即反復(fù)使用的變量要先保存成臨時(shí)或局部變量，尤其是循環(huán)中使用的變量
3、String方法中Substring和indexOf都是native方法可以大量的使用。
4、如果函數(shù)返回String類型，而且返回后的使用就是要加入到StringBuffer此時(shí)可以直接傳入StringBuffer
5、用兩個(gè)一維數(shù)組代替二維數(shù)組 int[][]=====int[] int[]
6、如果返回直接類型足夠了，就不應(yīng)返回接口類型如假如返回Hashmap就足夠了，請(qǐng)不要返回Map
7、如果一個(gè)方法不訪問(wèn)（不修改）成員變量，請(qǐng)用static方法
8、盡量不用getters和setters，如果你非要用的話請(qǐng)加上final關(guān)鍵字，編譯器會(huì)把它當(dāng)成內(nèi)聯(lián)函數(shù)
9、永遠(yuǎn)不要在for循環(huán)第二個(gè)參數(shù)中使用方法調(diào)用
10、不修改的static變量請(qǐng)用static final常量代替
11、foreach可以用來(lái)處理數(shù)組和arraylist，如果處理其他對(duì)象相當(dāng)于Iterator
12、避免使用枚舉，請(qǐng)使用常量代替。
13、慎用浮點(diǎn)數(shù) float尤其是大量的數(shù)學(xué)運(yùn)算
14、不使用的引用變量要手動(dòng)置null，提高內(nèi)存被回收的幾率
15、慎用圖片操作，使用后要立即釋放資源。
23，fresco:第三方圖片加載庫(kù)介紹：
DraweeView 是Fresco的三大組件（Hierarchy、Controller、View) 之一，作為MVC模式中的 View，主要負(fù)責(zé)顯示由 Hierarchy 提供的數(shù)據(jù)，Controller 作為幕后，負(fù)責(zé)獲取數(shù)據(jù)。
fresco是通過(guò)控件來(lái)實(shí)現(xiàn)它內(nèi)部的優(yōu)化緩存處理的。
Fresco源碼解析，fresco源碼：Fresco是一個(gè)MVC模型，由三大組件構(gòu)成，
它們的對(duì)應(yīng)關(guān)系如下所示：
M -＞DraweeHierarchy
V -＞ DraweView
C -> DraweeController。
M 所對(duì)應(yīng)的 DraweeHierarchy 是一個(gè)有層次結(jié)構(gòu)的數(shù)據(jù)結(jié)構(gòu)，DraweeView 用來(lái)顯示位于 DraweeHierarchy 最頂層的圖像（top level drawable），DraweeController則用來(lái)控制DraweeHierarchy的頂層圖像是哪一個(gè)。
三者的互動(dòng)關(guān)系很簡(jiǎn)單，DraweeView 把獲得的 Event 轉(zhuǎn)發(fā)給 Controller，然后 Controller 根據(jù) Event 來(lái)決定是否需要顯示和隱藏 （包括動(dòng)畫）圖像，而這些圖像都存儲(chǔ)在 Hierarchy 中，最后 DraweeView 繪制時(shí)直接通過(guò) getTopLevelDrawable 就可以獲取需要顯示的圖像。
24，垃圾回收內(nèi)部運(yùn)行機(jī)制：
java中 垃圾回收機(jī)制的原理：
1，gc垃圾回收機(jī)制的工作原理：
1，gc的工作原理：引用計(jì)數(shù)，標(biāo)記復(fù)制。引用計(jì)數(shù)其實(shí)是一種簡(jiǎn)單但速度很慢的垃圾回收技術(shù)，所有對(duì)象都需要有一個(gè)引用計(jì)數(shù)器，當(dāng)有引用連接時(shí)計(jì)數(shù)器加1。當(dāng)引用離開(kāi)作用域時(shí)或者被置為null時(shí)，計(jì)數(shù)器-1.垃圾回收器會(huì)在所有包含對(duì)象引用的列表上進(jìn)行遍歷，當(dāng)發(fā)現(xiàn)某個(gè)對(duì)象的引用計(jì)數(shù)為0時(shí)，就釋放占用的空間。
2，“標(biāo)記復(fù)制”的運(yùn)行機(jī)制，垃圾回收器遍歷包含所引用的列表，當(dāng)發(fā)現(xiàn)存活的對(duì)象引用時(shí)做上標(biāo)記，這樣當(dāng)遍歷完 所有對(duì)象引用并做上標(biāo)記的時(shí)候，執(zhí)行垃圾回收，將沒(méi)有標(biāo)記的 對(duì)象 堆空間釋放。
3，垃圾回收機(jī)制的特點(diǎn)：java的垃圾回收機(jī)制使得java程序員不用擔(dān)心內(nèi)存空間的分配，減少了內(nèi)存溢出。但同時(shí)也犧牲了一定的性能。
實(shí)現(xiàn)gc的算法：
引用計(jì)數(shù)法，tracing算法，compacting算法，copying算法，generation算法，adaptive算法，
25，設(shè)計(jì)模式：
根據(jù)模式的目的劃分為三類：
1，創(chuàng)建型模型：與對(duì)象的創(chuàng)建有關(guān)。2， 結(jié)構(gòu)性模型：處理類與對(duì)象的組合。3，行為型模型：對(duì)類或?qū)ο笤鯓咏换ズ驮鯓臃峙渎氊?zé)進(jìn)行描述。
1.創(chuàng)建型模式：
(1).工廠方法模式 (2).抽象工廠模式 (3).創(chuàng)建者模式 (4).原型模式 (5).單例模式
2.結(jié)構(gòu)型模式：
(6).適配器模式 (7).橋模式 (8).組合模式 (9).裝飾模式 (10).外觀模式 (11).享元模式 (12).代理模式
3.行為型模式
(13).解釋器模式 (14).模板方法模式 (15).職責(zé)鏈模式 (16).命令模式 (17).迭代器模式 (18).中介者模式 (19).備忘錄模式 (20).觀察者模式 (21).狀態(tài)模式 (22).策略模式 -----:官方告訴大家我這里有一個(gè)排序的接口ISort的sort()方法,然后民間各盡其能，實(shí)現(xiàn)這個(gè)排序的方法：冒泡，快速，堆等等。這些方法就是“不同的策略”。 (23).訪問(wèn)者模式
MVC不是一種設(shè)計(jì)模式：
Trygve Reenskaug最初提出MVC的目的是為了把數(shù)據(jù)（Model）和視圖（View）分離開(kāi)來(lái)，然后用控制器（Controller）作膠水來(lái)粘合M和V之間的關(guān)系。目的是為了實(shí)現(xiàn)注意點(diǎn)分離這樣一個(gè)更高層次的設(shè)計(jì)理念，也就是讓專業(yè)的對(duì)象做專業(yè)的事情，View就只負(fù)責(zé)視圖相關(guān)的東西，Model就只負(fù)責(zé)描述數(shù)據(jù)模型，Controller負(fù)責(zé)總控，各自協(xié)作。
它其實(shí)是其它三個(gè)經(jīng)典的設(shè)計(jì)模式的演變：觀察者模式(Observer)(Pub/Sub), 策略模式(Strategy)和組合模式(Composite)。
26，ViewStub介紹:
解決動(dòng)態(tài)根據(jù)條件顯示哪個(gè)View或某個(gè)布局：
android.view.ViewStub。
viewStub是一個(gè)輕量級(jí)的View。他是一個(gè)看不見(jiàn)的，不占布局的位置。占用資源非常小的控件，可以為ViewStub制定一個(gè)布局，在inflate布局的時(shí)候，只有ViewStub會(huì)被初始化。然后當(dāng)ViewStub被設(shè)置為可見(jiàn)的時(shí)候，或是調(diào)用了ViewStub.inflate()的時(shí)候，ViewStub所向的布局就會(huì)被inflate和實(shí)例化。然后ViewStub的布局屬性都會(huì)傳給它所指向的布局。這樣，就可以使用ViewStub來(lái)方便的在運(yùn)行時(shí)，要還是不要顯示某個(gè)布局。
viewStub只能實(shí)例化一次，之后ViewStub對(duì)象會(huì)被置為null。
27，軟件測(cè)試的基本步驟:
軟件首先在開(kāi)發(fā)中進(jìn)行單元測(cè)試。
開(kāi)發(fā)完成后進(jìn)行 集成測(cè)試（設(shè)計(jì)規(guī)格說(shuō)明）-------》功能測(cè)試（系統(tǒng)功能需求）-----》性能
測(cè)試（其他軟件需求）-----》驗(yàn)收測(cè)試（用戶需求規(guī)格說(shuō)明書）-----》安裝測(cè)試（用戶環(huán)境）。
28,加密算法：
數(shù)據(jù)加密：
計(jì)算機(jī)的加密解密是由秘鑰控制實(shí)現(xiàn)的。秘鑰使用戶按照一種密碼制隨機(jī)選取。通常是一隨機(jī)字符串。是控制明文和秘文變化的隨機(jī)參數(shù)。
密碼技術(shù)除了提供信息的加解密外，還提供對(duì)信息來(lái)源的鑒別，保證信息的完整和不可否認(rèn)等功能，而這三種功能都是通過(guò)數(shù)字簽名實(shí)現(xiàn)。數(shù)字簽名時(shí)涉及信息和簽名人私鑰的計(jì)算結(jié)果。首先簽名人的軟件對(duì)發(fā)送的信息進(jìn)行散列函數(shù)運(yùn)算后。生成信息摘要。
加密體制:
根據(jù)秘鑰類型不同將現(xiàn)代密碼及技術(shù)分為兩類：對(duì)稱加密（秘鑰加密）系統(tǒng)，非對(duì)稱加密（公開(kāi)秘鑰加密）。
對(duì)稱加密：
加密和解密均采用一把秘密鑰匙，而且通信算法必須足夠強(qiáng)大。適合于大規(guī)模生產(chǎn)。
非對(duì)稱加密（公鑰加密）：
指加密和解密使用不同秘鑰的加密算法。也稱為公私鑰加密，假設(shè)兩個(gè)用戶要加密交換。
MD5:消息摘要（信息摘要算法），Message-Digest Algorithm 5 散列函數(shù)。
將數(shù)據(jù)（如漢字）運(yùn)算為另一固定長(zhǎng)度的值。是緊湊算法的基礎(chǔ)原理。
它只是將數(shù)據(jù)按照指定算法壓縮成長(zhǎng)度固定的摘要信息。
摘要算法 就好比將一本書的每一頁(yè)第一個(gè)字的筆畫數(shù)計(jì)算出來(lái)，并拼接在一起，組成了一個(gè)很長(zhǎng)的數(shù)字串。不論何時(shí)，按相同的算法計(jì)算這本書的摘要，都是完全一樣的。但通過(guò)這個(gè)數(shù)字串，無(wú)法還原出書中的數(shù)據(jù)，即過(guò)程不可逆。md5算法類似于這種計(jì)算摘要的思想，只是具體實(shí)現(xiàn)要復(fù)雜很多。
MD5特點(diǎn)：
1，壓縮性：任意長(zhǎng)度的數(shù)據(jù)，算出的MD5的值都是固定的。
2，容易計(jì)算：從元數(shù)據(jù)計(jì)算出MD5的值很容易。
3，抗修改性：對(duì)原數(shù)據(jù)進(jìn)行任何修改，哪怕只修改一個(gè)字節(jié)，所得到的MD5值都有很大區(qū)別。
4，強(qiáng)抗碰撞：已知原數(shù)據(jù)MD5值，想找到一個(gè)具有相同MD5值的數(shù)據(jù)（即偽造數(shù)據(jù)）是非常困難的。
原理：
1，對(duì)MD5算法簡(jiǎn)要的敘述可以為：MD5以512位分組來(lái)處理輸入的信息，且每一分組又被劃分為16個(gè)32位子分組。經(jīng)過(guò)了一系列的處理后，
算法的輸出有四個(gè)32位組成，將這四個(gè)32位分組級(jí)聯(lián)后生成一個(gè)128位散列值。
2，例如字符串： 計(jì)算數(shù)據(jù)的長(zhǎng)度，對(duì)數(shù)據(jù)進(jìn)行填充到512位（64個(gè)字節(jié)）。然后將數(shù)據(jù)分成16個(gè)小組（16個(gè)數(shù)）。經(jīng)過(guò)數(shù)據(jù)分組處理后，按照內(nèi)存順序輸出即為最終結(jié)果。
RSA:非對(duì)稱加密原理：
用到素?cái)?shù)，互質(zhì)數(shù)(公因數(shù)只有1的兩個(gè)數(shù))，指數(shù)運(yùn)算，模運(yùn)算（模運(yùn)算即求余運(yùn)算）等幾個(gè)簡(jiǎn)單的數(shù)學(xué)知識(shí)。
密鑰產(chǎn)生方法：yh
隨機(jī)產(chǎn)生兩個(gè)不相等的質(zhì)數(shù)計(jì)算乘機(jī)n轉(zhuǎn)為二進(jìn)制，二進(jìn)制的位數(shù)就是密鑰的位數(shù)。實(shí)際應(yīng)用中RSA密鑰一般為1024位，重要場(chǎng)合為2048位。
計(jì)算出n的歐拉函數(shù)，隨機(jī)選擇一個(gè)整數(shù)e(實(shí)際應(yīng)用中，常常選擇65537)，條件是1< e < φ(n)，且e與φ(n) 互質(zhì)。
計(jì)算e對(duì)于φ(n)的 模反元素d。所謂"模反元素"就是指有一個(gè)整數(shù)d，可以使得ed被φ(n)除的余數(shù)為1。
將n和e封裝成公鑰，n和d封裝成私鑰。
RSA缺點(diǎn)：
產(chǎn)生密鑰很麻煩，受到產(chǎn)生素?cái)?shù)技術(shù)的限制。
分組長(zhǎng)度太大，為保證安全性，n至少也要600bit以上。使運(yùn)算代價(jià)很高，尤其是速度較慢。
DES算法的入口參數(shù)有三個(gè)：Key、Data、Mode。其中Key為8個(gè)字節(jié)共64位，是DES算法的工作密鑰；Data也為8個(gè)字節(jié)64位，是要被加密或被解密的數(shù)據(jù)；Mode為DES的工作方式，有兩種：加密或解密。
DES算法是這樣工作的：如Mode為加密，則用Key 去把數(shù)據(jù)Data進(jìn)行加密， 生成Data的密碼形式（64位）作為DES的輸出結(jié)果；
如Mode為解密，則用Key去把密碼形式的數(shù)據(jù)Data解密，還原為Data明碼形式（64位）作為DES的輸出結(jié)果。 在通信網(wǎng)絡(luò)的兩端，雙方約定一致的Key，在通信的源點(diǎn)用Key對(duì)核心數(shù)據(jù)進(jìn)行DES加密，然后以密碼形式在公共通信網(wǎng)（如電話網(wǎng)）中傳輸?shù)酵ㄐ啪W(wǎng)絡(luò)的終點(diǎn)， 數(shù)據(jù)到達(dá)目的地后，用同樣的Key對(duì)密碼數(shù)據(jù)進(jìn)行解密，便再現(xiàn)了明碼形式的核心數(shù)據(jù)。這樣，便保證了核心數(shù)據(jù)（如PIN、MAC等）在公共通信網(wǎng)中傳輸?shù)陌踩院涂煽啃浴?/p>
29，activity的啟動(dòng)模式：
standard(標(biāo)準(zhǔn)模式) singleTop(棧頂) singleTask() singleInstance()
標(biāo)準(zhǔn)模式：每次都會(huì)創(chuàng)建一個(gè)新的Activity，不在任務(wù)棧中作任何存在性檢查。（對(duì)系統(tǒng)消耗過(guò)大，每次都會(huì)創(chuàng)建一個(gè)activity的實(shí)例）。
singleTop(棧頂模式):只對(duì)棧頂作存在性檢查，當(dāng)啟動(dòng)的activity已經(jīng)位于棧頂時(shí)，只對(duì)棧頂作存在性檢查，直接使用。若沒(méi)有位于棧頂則直接創(chuàng)建。
singleTask（檢查棧中所有）：系統(tǒng)會(huì)檢查棧中是否存在該活動(dòng)的實(shí)例，如存在則直接使用該實(shí)例。
singleInstance：在開(kāi)發(fā)程序中如果需要activity在整個(gè)體系中都只有一個(gè)實(shí)例則使用單實(shí)例模式。指定為singleInstance模式的activity會(huì)啟動(dòng)一個(gè)新的任務(wù)棧來(lái)管理這個(gè)activity。
30，ListView 的優(yōu)化：
1，利用ListView自身的緩存機(jī)制，他會(huì)緩存一個(gè)條目的item，當(dāng)listView第一屏顯示完成之后。就會(huì)出現(xiàn)一個(gè)緩存條目，其實(shí)就是BaseAdapter里面的public View getView(int position,View convertView,ViewGroup parent)。
2,減少findViewById（）的次數(shù)，findViewById是一個(gè)相對(duì)比較耗性能的操作，因?yàn)檫@個(gè)操作每次都需要到布局中查找文件。把item里面的控件封裝成一個(gè)javaBean，當(dāng)item條目被加載的時(shí)候就去找相應(yīng)的控件。
3，利用時(shí)間去換取時(shí)間，比如開(kāi)機(jī)優(yōu)化，把一些重要的程序先啟動(dòng)了，啟動(dòng)系統(tǒng)完成之后再啟動(dòng)其他程序。
4，利用空間去換取時(shí)間，把要獲取的數(shù)據(jù)現(xiàn)價(jià)在到內(nèi)存里面，在處理數(shù)據(jù)的時(shí)候，直接從內(nèi)存中獲取。減少數(shù)據(jù)庫(kù)的頻繁打開(kāi)和關(guān)閉和減少查詢的次數(shù)。
31，Thread和Runnable區(qū)別：
如果一個(gè)類繼承Thread，則不適合資源共享，但是如果實(shí)現(xiàn)了Runnable接口的話，則很容易的實(shí)現(xiàn)資源共享。
在程序開(kāi)發(fā)中只要是多線程肯定以Runnable接口為主，因?yàn)閷?shí)現(xiàn)Runnable接口相比繼承Thread類有如下好處：
避免點(diǎn)繼承的局限性，一個(gè)類可以繼承多個(gè)接口。
適合于資源的共享。
32，surfaceView view GLSurfaceView： 區(qū)別：
View：顯示視圖，內(nèi)置畫布，提供圖形繪制函數(shù)、觸屏事件、按鍵事件函數(shù)等；必須在UI主線程內(nèi)更新畫面，速度較慢。
SurfaceView：基于view視圖進(jìn)行拓展的視圖類，更適合2D游戲的開(kāi)發(fā)；是view的子類，類似使用雙緩機(jī)制，在新的線程中更新畫面所以刷新界面速度比view快。
GLSurfaceView：基于SurfaceView視圖再次進(jìn)行拓展的視圖類，專用于3D游戲開(kāi)發(fā)的視圖；是SurfaceView的子類，openGL專用。
33，android系統(tǒng)中具備6個(gè)啟動(dòng)模式：
1，normal mode:一般啟動(dòng)模式的功能是正常啟動(dòng)方式，方法為關(guān)機(jī)狀態(tài)下按電源鍵啟動(dòng)。
2，safe mode:此模式和正常啟動(dòng)一樣，但沒(méi)有登記Google,所以不能訪問(wèn)Market或使用你的Google賬號(hào)，操做方法為按住“menu”鍵，按電源鍵啟動(dòng)手機(jī)，直至手機(jī)啟動(dòng)完成松開(kāi)“menu”鍵。
3，恢復(fù)模式（recovery mode）：可打開(kāi)命令解釋程序（shell），刷新映像文件，執(zhí)行備份等，。當(dāng)然這一切取決于你手機(jī)上的recovery image版本。使用方法很簡(jiǎn)單。就是home鍵和電源鍵一起按。
4，引導(dǎo)模式的功能，是從sd卡上安裝新的系統(tǒng)映像，只需再按一次電源鍵。值得一提為android手機(jī)獲取root權(quán)限。就是使用這個(gè)模式，操做方法為照相鍵和電源鍵一起按。
5，fastboot模式主要是在電腦上使用fastboot命令刷新映像文件。使用方法為按住返回鍵，按電源鍵啟動(dòng)手機(jī)，直至屏幕出現(xiàn)FASTBOOT字樣松開(kāi)后返回鍵。
6，診斷模式（diagnostic mode）是為了測(cè)試手機(jī)各項(xiàng)功能的模式，刻意通過(guò)軌跡球中心鍵和電源鍵打開(kāi)。
34，Permission 的ProtectionLevel的屬性值：
normal:低風(fēng)險(xiǎn)權(quán)限，只要申請(qǐng)了就可以使用(在AndroidMainFest.xml中添加），安裝時(shí)不需要用戶確認(rèn)。
danerous:高風(fēng)險(xiǎn)權(quán)限，安裝時(shí)需要用戶的確認(rèn)才可使用。
signature：只有當(dāng)申請(qǐng)權(quán)限的應(yīng)用程序的數(shù)字簽名與聲明此權(quán)限的應(yīng)用程序的數(shù)字簽名相同時(shí)，才能將權(quán)限授給他。
signatureOrSystem:簽名相同，或者申請(qǐng)權(quán)限的應(yīng)用為系統(tǒng)應(yīng)用（在system image中）。
35，內(nèi)存溢出和內(nèi)存泄露的區(qū)別：
內(nèi)存溢出out of memory,是指程序在申請(qǐng)內(nèi)存時(shí)，沒(méi)有足夠的內(nèi)存空間供其使用，出現(xiàn)out of memory；比如申請(qǐng)了一個(gè)integer,但給他存了long才能存下的數(shù)。
比如棧：棧滿時(shí)，進(jìn)行進(jìn)棧，內(nèi)存溢出。�？諘r(shí)，進(jìn)行出棧，內(nèi)存也會(huì)溢出。分配內(nèi)存不足以放下數(shù)據(jù)項(xiàng)序列，稱為內(nèi)存溢出。
內(nèi)存泄露memory leak,是指程序在申請(qǐng)內(nèi)存后，無(wú)法釋放已申請(qǐng)的內(nèi)存空間，一次內(nèi)存泄露危害可以忽略，但內(nèi)存泄露堆積后果很嚴(yán)重，無(wú)論多少內(nèi)存遲早會(huì)被占光。 是指向系統(tǒng)中申請(qǐng)分配內(nèi)存進(jìn)行使用（new），但使用完后，卻沒(méi)有歸還。申請(qǐng)到的內(nèi)存自己也不能再訪問(wèn)，而系統(tǒng)也不能再次將它分配給需要的程序。
內(nèi)存泄露會(huì)導(dǎo)致內(nèi)存溢出。
36，java中有四種類型的引用：及區(qū)別：
1，強(qiáng)引用（Strong Reference）：只要某個(gè)對(duì)象有強(qiáng)引用與之關(guān)聯(lián)，JVM必定不會(huì)回收這個(gè)對(duì)象，即使在內(nèi)存不足的情況下，JVM寧愿拋出OutOfMemory錯(cuò)誤也不會(huì)回收這種對(duì)象。
2，弱引用（Weak Refrence）：如果一個(gè)對(duì)象只有弱引用指向它，垃圾回收器會(huì)立即回收該對(duì)象。
3，軟引用（SoftRefrence）：只有在內(nèi)存不足的時(shí)候JVM才會(huì)回收該對(duì)象。并且這個(gè)特性很適合用來(lái)實(shí)現(xiàn)緩存：比如網(wǎng)頁(yè)緩存、圖片緩存等。
4，虛引用（PhantomReference）：如果一個(gè)對(duì)象與虛引用關(guān)聯(lián)，則跟沒(méi)有引用與之關(guān)聯(lián)一樣，在任何時(shí)候都可能被垃圾回收器回收。
37，怎么解決橫豎屏切換導(dǎo)致的 數(shù)據(jù)丟失？
activity橫豎屏切換時(shí)，當(dāng)前的Activity會(huì)被銷毀，然后Activity上面的數(shù)據(jù)將全部丟失。
如ListView扇面的每個(gè)item的checkbox,橫豎屏切換時(shí)，復(fù)選框就丟失所有選中的信息。
實(shí)現(xiàn)：
1，在注冊(cè)文件中，activity 標(biāo)簽中，使用android：configChanges = "orientation|keyboardHidden"標(biāo)簽。
2，強(qiáng)制activity在 支持橫屏或者豎屏。landscape標(biāo)識(shí)橫屏，portrait標(biāo)識(shí)豎屏。
3，在activity中：通過(guò)復(fù)寫 onConfigurationChanged(Configuratiion newConfig)方法。實(shí)現(xiàn)在不同屏幕下的處理方式。
[java] view plain copy
@Override
public void onConfigurationChanged(Configuration newConfig) {
// TODO Auto-generated method stub
super.onConfigurationChanged(newConfig);
/*
* 橫豎屏檢測(cè)
*/
if (this.getResources().getConfiguration().orientation == Configuration.ORIENTATION_LANDSCAPE) {
// 當(dāng)前為橫屏
//實(shí)現(xiàn)代碼
}
else if (this.getResources().getConfiguration().orientation == Configuration.ORIENTATION_PORTRAIT) {
// 當(dāng)前為豎屏
//實(shí)現(xiàn)代碼
}
/*
* 實(shí)體鍵盤狀態(tài)檢測(cè)
*/
if (newConfig.hardKeyboardHidden == Configuration.HARDKEYBOARDHIDDEN_NO) {
// 實(shí)體鍵盤處于推出狀態(tài)
//實(shí)現(xiàn)代碼
}
else if (newConfig.hardKeyboardHidden == onfiguration.HARDKEYBOARDHIDDEN_YES) {
// 實(shí)體鍵盤處于合上狀態(tài)
//實(shí)現(xiàn)代碼
}
}
38，Volley請(qǐng)求和xUtils請(qǐng)求的區(qū)別：
Volley谷歌的：支持小數(shù)據(jù)大頻繁請(qǐng)求。
xUtils中國(guó)人開(kāi)發(fā)的。
相同點(diǎn)：
1，采用了網(wǎng)絡(luò)數(shù)據(jù)緩存機(jī)制。
2，通過(guò)handler機(jī)制進(jìn)行線程通信。
不同點(diǎn)：
1,Volley請(qǐng)求在android2.3版本之前是通過(guò)HttpClient，在之后的版本是URLHTTPConnextion.xUtils都是通過(guò)HttpClient請(qǐng)求數(shù)據(jù)信息的(bitmap模塊圖片是通過(guò)URLHTTPConnection)。URLHttpConnection默認(rèn)支持GZIP壓縮。api操作簡(jiǎn)單。
2，Volley將Http請(qǐng)求數(shù)據(jù)先緩存進(jìn)Byte[],然后是分配給不同的請(qǐng)求轉(zhuǎn)化為需要的格式。 xUtils是直接轉(zhuǎn)換為需要的格式。 Volley的擴(kuò)展性很好，但是不能存在大數(shù)據(jù)的請(qǐng)求，否則就報(bào)OOM。 XUtils不會(huì)緩存如byte[]支持大數(shù)據(jù)的請(qǐng)求，速度要比Volley稍快。但擴(kuò)展性低。
3，Volley訪問(wèn)網(wǎng)絡(luò)數(shù)據(jù)時(shí)直接開(kāi)啟固定個(gè)數(shù)的線程訪問(wèn)網(wǎng)絡(luò)數(shù)據(jù)，在run方法中執(zhí)行死循環(huán)。阻塞等待請(qǐng)求隊(duì)列等。 XUtils是開(kāi)啟線程池來(lái)管理線程。緩存失效策略。volley的所有網(wǎng)絡(luò)數(shù)據(jù)支持從http相應(yīng)頭控制是否緩存和讀取緩存失效時(shí)間，每個(gè)請(qǐng)求可以控制是否緩存和緩存失效時(shí)間。 xUtils網(wǎng)絡(luò)數(shù)據(jù)請(qǐng)求是統(tǒng)一自定義緩存失效時(shí)間。
39，android5.0的新特性：
1、Face unlock(面部解鎖)：在Lollipop系統(tǒng)中，Google花費(fèi)大力氣優(yōu)化了面部解鎖功能。當(dāng)用戶拿起手機(jī)處理鎖屏界面上的消息通知時(shí)，面部解鎖功能便自動(dòng)被激活。隨意瀏覽幾條消息之后，手機(jī)已經(jīng)默默地完成了面部識(shí)別，解鎖就是這么簡(jiǎn)單!
2，Lock screen notifications(鎖屏通知中心)
Android Lollipop中加入了全新風(fēng)格的通知系統(tǒng)，改進(jìn)后的通知系統(tǒng)會(huì)優(yōu)先顯示由用戶設(shè)定的重要的信息，而將不太緊急的內(nèi)容隱藏起來(lái)。用戶只需要向下滑動(dòng)就可以查看全部的通知內(nèi)容，如果是短信、微信，就可以再通知欄里直接進(jìn)行回復(fù)，非常人性化。
3，Pin Apps(多任務(wù)視窗)
Lollipop在系統(tǒng)設(shè)置中提供了一項(xiàng)全新的功能——在多任務(wù)視窗中，給app應(yīng)用窗口添加pin鎖定代碼。正如名字講的那樣，像是用別針鎖定app應(yīng)用，只用當(dāng)輸入正確的密碼才能退出該app界面。雖然說(shuō)與iOS系統(tǒng)的Guided Access功能也很像，但Guest Mode使用時(shí)好像更加簡(jiǎn)單快捷。
4，Material Design
Google重新設(shè)計(jì)了更加趨于扁平化的Lollipop系統(tǒng)UI，稱為Material Design。在今年6月26日舉辦的I/O 2014開(kāi)發(fā)者大會(huì)上，許多人就已經(jīng)提前領(lǐng)略到Material Design出色的功能了。到現(xiàn)在，它得到了更多的優(yōu)化，例如給通訊錄聯(lián)系人添加不同的顏色優(yōu)先等級(jí)。新的UI設(shè)計(jì)，在基本元素的處理上，借鑒了傳統(tǒng)的印刷設(shè)計(jì)，從字體版式、網(wǎng)格系統(tǒng)，到空間、比例、配色、圖像等方面，都驚醒了大膽的平面化的創(chuàng)新。這一舉措，無(wú)疑是加大了國(guó)產(chǎn)UI設(shè)計(jì)的難度與門檻。
5，Android 5.0還支持新的電池模式、多賬戶登陸、訪客模式以及通過(guò)藍(lán)牙設(shè)備解鎖等新功能。
Material Design新控件：
支持的八個(gè)新控件：
TextInputLayout:對(duì)EditText進(jìn)行封裝，帶有提示信息的輸入框。一個(gè)TextInputLayout只能嵌套一個(gè)EditText,內(nèi)容過(guò)多會(huì)水平滾動(dòng)進(jìn)行查看
FloatingActionButton:一個(gè)負(fù)責(zé)顯示界面基本操作的懸浮圓形按鈕。繼承自ImageView，你可以使用android：src(更改圓形按鈕中間的圖片)或者ImageView的任意方法。懸浮按鈕的背景使用colorAccent屬性更改。
Snackbar:一個(gè)介于Toast和AlertDialog之間的輕量級(jí)控件。他可以很方便的提供消息的提示和動(dòng)作反饋。
TabLayout標(biāo)簽布局位置隨意，只能進(jìn)行文字導(dǎo)航，既實(shí)現(xiàn)了固定的選項(xiàng)卡（View的寬度平均分配），也實(shí)現(xiàn)了可滾動(dòng)的選項(xiàng)卡（View寬度不固定同時(shí)可以橫向滾動(dòng)）
NavigationView：
CoorDinatorLayout: 效果1:滾動(dòng)效果，例子如：讓浮動(dòng)操作按鈕(FloatingActionButton)上下滑動(dòng)，為Snackbar留出空間，實(shí)現(xiàn)方式：使用CoordinatorLayout作為基本布局放在FloatingActionButton布局外層，會(huì)自動(dòng)實(shí)現(xiàn)上移下移的動(dòng)畫.
AppBarLayout:可把容器類的組件全部作為AppBar,例如把Toolbar和TabLayout放到了AppBarLayout中，讓他們當(dāng)做一個(gè)整體作為AppBar.
TooBayLayout:CollapsingToolbarLayout作用是提供了一個(gè)可以折疊的Toolbar，它繼承至FrameLayout，給它設(shè)置layout_scrollFlags，它可以控制包含在CollapsingToolbarLayout中的控件(如：ImageView、Toolbar)在響應(yīng)layout_behavior事件時(shí)作出相應(yīng)的scrollFlags滾動(dòng)事件(移除屏幕或固定在屏幕頂端)。