2017年據說是找工作的寒冬，作為一個Android開發(fā)，下面的一些問題可能在面試的時候遇到哦：
1、java 內部類有哪些分類？都有什么特點
內部類可以分為四種：1、靜態(tài)內部類：最簡單的內部類形式，類定義時加上static關鍵字，不能和外部類有相同的名字，被編譯成一個完全獨立的.class文件，名稱為OuterClass$InnerClass.class的形式。只可以訪問外部類的靜態(tài)成員和靜態(tài)方法，包括了私有的靜態(tài)成員和方法。2：成員內部類：成員內部類也是定義在另一個類中，但是定義時不用static修飾，成員內部類和靜態(tài)內部類可以類比為非靜態(tài)的成員變量和靜態(tài)的成員變量。成員內部類就像一個實例變量。它可以訪問它的外部類的所有成員變量和方法，不管是靜態(tài)的還是非靜態(tài)的都可以。3：局部內部類：局部內部類定義在方法中，比方法的范圍還小。是內部類中最少用到的一種類型。像局部變量一樣，不能被public, protected, private和static修飾。只能訪問方法中定義的final類型的局部變量。局部內部類在方法中定義，所以只能在方法中使用，即只能在方法當中生成局部內部類的實例并且調用其方法。4：匿名內部類：匿名內部類就是沒有名字的局部內部類，不使用關鍵字class, extends, implements, 沒有構造方法。匿名內部類隱式地繼承了一個父類或者實現(xiàn)了一個接口。匿名內部類使用得比較多，通常是作為一個方法參數(shù)。
2、Json支持哪些數(shù)據類型？
Number ：雙精度浮點格式
String：字符型
Boolean：true 或 false
Array：值的有序序列
Value：它可以是一個字符串，一個數(shù)字，真的還是假（true/false），空(null?)等
Object：無序集合鍵值對
Whitespace：可以使用任何一對中的令牌
null：empty
3、volatile關鍵字？
用volatile修飾的變量，線程在每次使用變量的時候，都會讀取變量修改后的最的值。volatile修飾的變量不允許線程內部緩存和重排序，即直接修改內存。所以對其他線程是可見的。但是這里需要注意一個問題，volatile只能讓被他修飾內容具有可見性，但不能保證它具有原子性。比如 volatile int a = 0；之后有一個操作 a++；這個變量a具有可見性，但是a++ 依然是一個非原子操作，也就是這個操作同樣存在線程安全問題。當對非volatile變量進行讀寫的時候，每個線程先從內存拷貝變量到CPU緩存中。如果計算機有多個CPU，每個線程可能在不同的CPU上被處理，這意味著每個線程可以拷貝到不同的CPU cache中。而聲明變量是volatile的，JVM保證了每次讀變量都從內存中讀，跳過CPU cache這一步。
4、java中synchronized的用法？
當它用來修飾一個方法或者一個代碼塊的時候，能夠保證在同一時刻最多只有一個線程執(zhí)行該段代碼。
一、當兩個并發(fā)線程訪問同一個對象object中的這個synchronized(this)同步代碼塊時，一個時間內只能有一個線程得到執(zhí)行。另一個線程必須等待當前線程執(zhí)行完這個代碼塊以后才能執(zhí)行該代碼塊。
二、然而，當一個線程訪問object的一個synchronized(this)同步代碼塊時，另一個線程仍然可以訪問該object中的非synchronized(this)同步代碼塊。
三、尤其關鍵的是，當一個線程訪問object的一個synchronized(this)同步代碼塊時，其他線程對object中所有其它synchronized(this)同步代碼塊的訪問將被阻塞。
四、第三同樣適用其它同步代碼塊。也就是說，當一個線程訪問object的一個synchronized(this)同步代碼塊時，它就獲得了這個object的對象鎖。結果，其它線程對該object對象所有同步代碼部分的訪問都被暫時阻塞。
五、以上規(guī)則對其它對象鎖同樣適用.
5、簡述http協(xié)議？
http（超文本傳輸協(xié)議）是一個基于請求與響應模式的、無狀態(tài)的、應用層的協(xié)議，?；赥CP的連接方式，HTTP1.1版本中給出一種持續(xù)連接的機制，絕大多數(shù)的Web開發(fā)，都是構建在HTTP協(xié)議之上的Web應用。
HTTP協(xié)議的主要特點可概括如下：
a.支持客戶/服務器模式。
b.簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規(guī)定了客戶與服務器聯(lián)系的類型不同。由于HTTP協(xié)議簡單，使得HTTP服務器的程序規(guī)模小，因而通信速度很快。
c.靈活：HTTP允許傳輸任意類型的數(shù)據對象。正在傳輸?shù)念愋陀蒀ontent-Type加以標記。
d.無連接：無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求，并收到客戶的應答后，即斷開連接。采用這種方式可以節(jié)省傳輸時間。
e.無狀態(tài)：HTTP協(xié)議是無狀態(tài)協(xié)議。無狀態(tài)是指協(xié)議對于事務處理沒有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數(shù)據量增大。另一方面，在服務器不需要先前信息時它的應答就較快。
6、使用AlarmManage做倒計時或計數(shù)器？
AlarmManager的使用機制有的稱呼為全局定時器，有的稱呼為鬧鐘，其實它的作用和Timer有點相似。都有兩種相似的用法：（1）在指定時長后執(zhí)行某項操作（2）周期性的執(zhí)行某項操作 。AlarmManager對象配合Intent使用，可以定時的開啟一個Activity,發(fā)送一個BroadCast,或者開啟一個Service.
Intent intent=newIntent(xxxx.this, xxx.class);
intent.setAction("repeating");
PendingIntent sender=PendingIntent
.getBroadcast(xxx.this,0, intent,0);
//開始時間
longfirstime=SystemClock.elapsedRealtime();
AlarmManager am=(AlarmManager)getSystemService(ALARM_SERVICE);
//5秒一個周期，不停的發(fā)送廣播
am.setRepeating(AlarmManager.ELAPSED_REALTIME_WAKEUP
, firstime,5*1000, sender);
7、Android實現(xiàn)異步？
a:繼承Thread類 b:實現(xiàn)Runnable接口? c:AsyncTask d : Handler.
8、View的specMode？
EXACTLY：一般是設置了明確的值或者是MATCH_PARENT
AT_MOST：表示子布局限制在一個最大值內，一般為WARP_CONTENT
UNSPECIFIED：表示子布局想要多大就多大，很少使用
9、 activity在屏幕旋轉時的生命周期
答：不設置Activity的android:configChanges時，切屏會重新調用各個生命周期，切橫屏時會執(zhí)行一次，切豎屏時會執(zhí)行兩次；設置Activity的android:configChanges="orientation"時，切屏還是會重新調用各個生命周期，切橫、豎屏時只會執(zhí)行一次；設置Activity的android:configChanges="orientation|keyboardHidden"時，切屏不會重新調用各個生命周期，只會執(zhí)行onConfigurationChanged方法
10、 描述一下android的系統(tǒng)架構
android系統(tǒng)架構分從下往上為linux 內核層、運行庫、應用程序框架層、和應用程序層。
linuxkernel：負責硬件的驅動程序、網絡、電源、系統(tǒng)安全以及內存管理等功能。
libraries和 android runtime：libraries：即c/c++函數(shù)庫部分，大多數(shù)都是開放源代碼的函數(shù)庫，例如webkit（引擎），該函數(shù)庫負責 android網頁瀏覽器的運行，例如標準的c函數(shù)庫libc、openssl、sqlite等，當然也包括支持游戲開發(fā)2dsgl和 3dopengles，在多媒體方面有mediaframework框架來支持各種影音和圖形文件的播放與顯示，例如mpeg4、h.264、mp3、 aac、amr、jpg和png等眾多的多媒體文件格式。android的runtime負責解釋和執(zhí)行生成的dalvik格式的字節(jié)碼。
applicationframework（應用軟件架構），java應用程序開發(fā)人員主要是使用該層封裝好的api進行快速開發(fā)。
applications:該層是java的應用程序層，android內置的googlemaps、e-mail、即時通信工具、瀏覽器、mp3播放器等處于該層，java開發(fā)人員開發(fā)的程序也處于該層，而且和內置的應用程序具有平等的位置，可以調用內置的應用程序，也可以替換內置的應用程序。
上面的四個層次，下層為上層服務，上層需要下層的支持，調用下層的服務，這種嚴格分層的方式帶來的極大的穩(wěn)定性、靈活性和可擴展性，使得不同層的開發(fā)人員可以按照規(guī)范專心特定層的開發(fā)。
android應用程序使用框架的api并在框架下運行，這就帶來了程序開發(fā)的高度一致性，另一方面也告訴我們，要想寫出優(yōu)質高效的程序就必須對整個 applicationframework進行非常深入的理解。精通applicationframework，你就可以真正的理解android的設計和運行機制，也就更能夠駕馭整個應用層的開發(fā)。
11、一個".java"源文件中是否可以包括多個類（不是內部類）？有什么限制？
可以有多個類，但只能有一個public的類，并且public的類名必須與文件的主文件名相同。
包含多個類的Java源文件編譯之后會生成多個.class文件
12、Java如何跳出當前的多重嵌套循環(huán)？
在Java中，要想跳出多重循環(huán)，可以在外面的循環(huán)語句前定義一個標號，然后在里層循環(huán)體的代碼中使用帶有標號的break 語句，即可跳出外層循環(huán)。例如，
outer:
for(inti=0;i<10;i++)
{
for(intj=0;j<10;j++)
{
System.out.println(“i=”+ i + “,j=” + j);
if(j== 5) break ouer;
}
}
13、垃圾回收考慮幾種回收機制。
對于一個垃圾回收器的設計算法來說，大致有如下可供選擇的設計：
A．串行回收（Serial）和并行回收（Parallel）：串行回收就是不管系統(tǒng)有多少個CPU，始終只用一個CPU來執(zhí)行垃圾回收操作；而并行回收就是把整個回收工作拆分成多部分，每個部分由一個CPU負責，從而讓多個CPU并行回收，并行回收的執(zhí)行效率很高，但復雜度增加，另外也有其他一些副作用，比如內存碎片會增加。
B．并發(fā)執(zhí)行（Concurrent）和應用程序停止（Stop-the-world）：。Stop-the-world的垃圾回收方式在執(zhí)行垃圾回收的同時會導致應用程序的暫停。并發(fā)執(zhí)行的垃圾回收雖然不會導致應用程序的暫停，但由于并發(fā)執(zhí)行垃圾回收需要解決和應用程序的執(zhí)行沖突（應用程序可能會在垃圾回收的過稱中修改對象），因此并發(fā)執(zhí)行垃圾回收的系統(tǒng)開銷比Stop-the-world更好，而且執(zhí)行時也需要更多的堆內存。
C．壓縮（Compacting）和不壓縮（Non-compacting）和復制（Copying）：為了減少內存碎片，支持壓縮的垃圾回收器會把所有的活對象搬遷到一起，然后將之前占用的內存全部回收。不壓縮式的垃圾回收器只是回收內存，這樣回收回來的內存不可能是連續(xù)的，因此將會有較多的內存碎片。較之壓縮式的垃圾回收，不壓縮式的垃圾回收回收內存快了，而分配內存時就會更慢，而且無法解決內存碎片的問題。復制式的垃圾回收會將所有可達對象復制到另一塊相同的內存中，這種方式的優(yōu)點是垃圾及回收過程不會產生內存碎片，但缺點也很明顯，需要拷貝數(shù)據和額外的內存。
14、sleep() 和 wait() 有什么區(qū)別?
對于sleep()方法，我們首先要知道該方法是屬于Thread類中的。而wait()方法，則是屬于Object類中的。
sleep()方法導致了程序暫停執(zhí)行指定的時間，讓出cpu給其他線程，但是他的監(jiān)控狀態(tài)依然保持者，當指定的時間到了又會自動恢復運行狀態(tài)。
在調用sleep()方法的過程中，線程不會釋放對象鎖。
而當調用wait()方法的時候，線程會放棄對象鎖，進入等待此對象的等待鎖定池，只有針對此對象調用notify()方法后本線程才進入對象鎖定池準備
獲取對象鎖進入運行狀態(tài)
15、簡述synchronized和java.util.concurrent.locks.Lock的異同？
ReentrantLock 擁有Synchronized相同的并發(fā)性和內存語義，此外還多了 鎖投票，定時鎖等候和中斷鎖等候，線程A和B都要獲取對象O的鎖定，假設A獲取了對象O鎖，B將等待A釋放對O的鎖定，如果使用 synchronized ，如果A不釋放，B將一直等下去，不能被中斷如果 使用ReentrantLock，如果A不釋放，可以使B在等待了足夠長的時間以后，中斷等待，而干別的事情。
synchronized是在JVM層面上實現(xiàn)的，不但可以通過一些監(jiān)控工具監(jiān)控synchronized的鎖定，而且在代碼執(zhí)行時出現(xiàn)異常，JVM會自動釋放鎖定，但是使用Lock則不行，lock是通過代碼實現(xiàn)的，要保證鎖定一定會被釋放，就必須將unLock()放到finally{}中
在資源競爭不是很激烈的情況下，Synchronized的性能要優(yōu)于ReetrantLock，但是在資源競爭很激烈的情況下，Synchronized的性能會下降幾十倍，但是ReetrantLock的性能能維持常態(tài)
Atomic:和上面的類似，不激烈情況下，性能比synchronized略遜，而激烈的時候，也能維持常態(tài)。激烈的時候，Atomic的性能會優(yōu)于ReentrantLock一倍左右。但是其有一個缺點，就是只能同步一個值，一段代碼中只能出現(xiàn)一個Atomic的變量，多于一個同步無效。因為他不能在多個Atomic之間同步。
16、View, SurfaceView, GLSurfaceView有什么區(qū)別？
答：View是最基礎的，必須在UI主線程內更新畫面，速度較慢。
SurfaceView 是View的子類，使用了雙緩機制，在新的線程中更新畫面所以刷新界面速度比View快。
SurfaceView一般會與SurfaceHolder結合使用，調用SurfaceView的getHolder()方法即可獲取SurfaceView關聯(lián)的SurfaceHolder，SurfaceHolder用于向與之關聯(lián)的SurfaceView上繪圖，
SurfaceHolder提供了如下方法來獲取Canvas對象：
－ CanvaslockCanvas()：鎖定整個SurfaceView對象，獲取該Surface上的Canvas。
－ CanvaslockCanvas(Rect dirty)：鎖定SurfaceView上Rect劃分的區(qū)域，獲取該Surface上的Canvas。
當對同一個SurfaceView調用上面兩個方法時，兩個方法所返回的是同一個Canvas對象。但當程序調用第二個方法獲取指定區(qū)域的Canvas時，SurfaceView將只對Rect所“圈”出來的區(qū)域進行更新，通過這種方式可以提高畫面的更新速度。
當通過lockCanvas()獲取指定了SurfaceView上的Canvas之后，接下來程序就可調用Canvas進行繪圖了，Canvas繪圖完成后通過如下方法來釋放繪圖、提交所繪制的圖形：
－unlockCanvasAndPost(canvas);
GLSurfaceView 是SurfaceView的子類，OpenGL專用的。
17、Java 中的內存分配
靜態(tài)儲存區(qū)：編譯時就分配好，在程序整個運行期間都存在。它主要存放靜態(tài)數(shù)據和常量；
棧區(qū)：當方法執(zhí)行時，會在棧區(qū)內存中創(chuàng)建方法體內部的局部變量，方法結束后自動釋放內存；
堆區(qū)：通常存放 new 出來的對象。由 Java 垃圾回收器回收
18、Java中四種引用
強引用（StrongReference）：強引用就是指在程序代碼之中普遍存在的，只要某個對象有強引用與之關聯(lián)，JVM必定不會回收這個對象，即使在內存不足的情況下，JVM寧愿拋出OutOfMemory錯誤也不會回收這種對象
軟引用（SoftReference）：軟引用是用來描述一些有用但并不是必需的對象，在Java中用java.lang.ref.SoftReference類來表示。對于軟引用關聯(lián)著的對象，只有在內存不足的時候JVM才會回收該對象。因此，這一點可以很好地用來解決OOM的問題，并且這個特性很適合用來實現(xiàn)緩存：比如網頁緩存、圖片緩存等。
弱引用（WeakReference）：弱引用也是用來描述非必需對象的，當JVM進行垃圾回收時，無論內存是否充足，都會回收被弱引用關聯(lián)的對象。在java中，用java.lang.ref.WeakReference類來表示。
虛引用（PhantomReference）：虛引用和前面的軟引用、弱引用不同，它并不影響對象的生命周期。在java中java.lang.ref.PhantomReference類表示。如果一個對象與虛引用關聯(lián)，則跟沒有引用與之關聯(lián)一樣，在任何時候都可能被垃圾回收器回收。要注意的是，虛引用必須和引用隊列關聯(lián)使用，當垃圾回收器準備回收一個對象時，如果發(fā)現(xiàn)它還有虛引用，就會把這個虛引用加入到與之 關聯(lián)的引用隊列中。程序可以通過判斷引用隊列中是否已經加入了虛引用，來了解被引用的對象是否將要被垃圾回收。如果程序發(fā)現(xiàn)某個虛引用已經被加入到引用隊列，那么就可以在所引用的對象的內存被回收之前采取必要的行動。
對于強引用，我們平時在編寫代碼時經常會用到。而對于其他三種類型的引用，使用得最多的就是軟引用和弱引用，這2種既有相似之處又有區(qū)別。它們都是用來描述非必需對象的，但是被軟引用關聯(lián)的對象只有在內存不足時才會被回收，而被弱引用關聯(lián)的對象在JVM進行垃圾回收時總會被回收。針對上面的特性，軟引用適合用來進行緩存，當內存不夠時能讓JVM回收內存，弱引用能用來在回調函數(shù)中防止內存泄露。因為回調函數(shù)往往是匿名內部類，隱式保存有對外部類的引用，所以如果回調函數(shù)是在另一個線程里面被回調，而這時如果需要回收外部類，那么就會內存泄露，因為匿名內部類保存有對外部類的強引用。
19、activity的四種啟動模式
standard：默認模式，可以不用寫配置。在這個模式下，都會默認創(chuàng)建一個新的實例。因此，在這種模式下，可以有多個相同的實例，也允許多個相同Activity疊加
singleTop：可以有多個實例，但是不允許多個相同Activity疊加。即，如果Activity在棧頂?shù)臅r候，啟動相同的Activity，不會創(chuàng)建新的實例，而會調用其onNewIntent方法。
singleTask：只有一個實例。在同一個應用程序中啟動他的時候，若Activity不存在，則會在當前task創(chuàng)建一個新的實例，若存在，則會把task中在其之上的其它Activity destory掉并調用它的onNewIntent方法。如果是在別的應用程序中啟動它，則會新建一個task，并在該task中啟動這個Activity，singleTask允許別的Activity與其在一個task中共存，也就是說，如果我在這個singleTask的實例中再打開新的Activity，這個新的Activity還是會在singleTask的實例的task中。
singleInstance：只有一個實例，并且這個實例獨立運行在一個task中，這個task只有這個實例，不允許有別的Activity存在
20、java中String，StringBuilder, StringBuffer的區(qū)別
String類中使用字符數(shù)組保存字符串，因為有“final”修飾符，所以string對象是不可變的。StringBuilder與StringBuffer都繼承AbstractStringBuilder類，在AbstractStringBuilder中也是使用字符數(shù)組保存字符串，這兩種對象都是可變的。
String中的對象是不可變的，也就可以理解為常量，顯然線程安全；StringBuffer對方法加了同步鎖或者對調用的方法加了同步鎖，所以是線程安全的；
21：HashMap, LinkedHashMap, TreeMap，區(qū)別
Map主要用于存儲健值對，根據鍵得到值，因此不允許鍵重復(重復了覆蓋了),但允許值重復
Hashmap 是一個最常用的Map,它根據鍵的HashCode 值存儲數(shù)據,根據鍵可以直接獲取它的值，具有很快的訪問速度，遍歷時，取得數(shù)據的順序是完全隨機的。HashMap最多只允許一條記錄的鍵為Null;允許多條記錄的值為 Null;HashMap不支持線程的同步
Hashtable與 HashMap類似,它繼承自Dictionary類，不同的是:它不允許記錄的鍵或者值為空;它支持線程的同步，即任一時刻只有一個線程能寫Hashtable,因此也導致了 Hashtable在寫入時會比較慢。
LinkedHashMap保存了記錄的插入順序，在用Iterator遍歷LinkedHashMap時，先得到的記錄肯定是先插入的.也可以在構造時用帶參數(shù)，按照應用次數(shù)排序。在遍歷的時候會比HashMap慢，不過有種情況例外，當HashMap容量很大，實際數(shù)據較少時，遍歷起來可能會比LinkedHashMap慢，因為LinkedHashMap的遍歷速度只和實際數(shù)據有關，和容量無關，而HashMap的遍歷速度和他的容量有關
TreeMap實現(xiàn)SortMap接口，能夠把它保存的記錄根據鍵排序,默認是按鍵值的升序排序，也可以指定排序的比較器，當用Iterator 遍歷TreeMap時，得到的記錄是排過序的。
一般情況下，我們用的最多的是HashMap,HashMap里面存入的鍵值對在取出的時候是隨機的,它根據鍵的HashCode值存儲數(shù)據,根據鍵可以直接獲取它的值，具有很快的訪問速度。在Map 中插入、刪除和定位元素，HashMap 是最好的選擇。
TreeMap取出來的是排序后的鍵值對。但如果您要按自然順序或自定義順序遍歷鍵，那么TreeMap會更好。
LinkedHashMap 是HashMap的一個子類，如果需要輸出的順序和輸入的相同,那么用LinkedHashMap可以實現(xiàn),它還可以按讀取順序來排列，像連接池中可以應用。
22、TCP和UDP的區(qū)別
TCP/IP協(xié)議是一個協(xié)議簇。里面包括很多協(xié)議的。UDP只是其中的一個。之所以命名為TCP/IP協(xié)議，因為TCP,IP協(xié)議是兩個很重要的協(xié)議，就用他兩命名了。
一個TCP協(xié)議連接其實就是在物理線路上創(chuàng)建的一條“虛擬信道”。這條“虛擬信道”建立后，在TCP協(xié)議發(fā)出FIN包之前（兩個終端都會向對方發(fā)送一個FIN包），是不會釋放的。正因為這一點，TCP協(xié)議被稱為面向連接的協(xié)議！
UDP協(xié)議，一樣會在物理線路上創(chuàng)建一條“虛擬信道”，否則UDP協(xié)議無法傳輸數(shù)據！但是，當UDP協(xié)議傳完數(shù)據后，這條“虛擬信道”就被立即注銷了！因此，稱UDP是不面向連接的協(xié)議！
主要區(qū)別：
基于連接與無連接；
對系統(tǒng)資源的要求（TCP較多，UDP少）；
UDP程序結構較簡單；
流模式與數(shù)據報模式 ；
TCP保證數(shù)據正確性，UDP可能丟包，TCP保證數(shù)據順序，UDP不保證。
23、http session機制
http是無狀態(tài)的協(xié)議，客戶每次讀取web頁面時，服務器都打開新的會話，而且服務器也不會自動維護客戶的上下文信息，那么要怎么才能實現(xiàn)會話跟蹤呢？session就是一種保存上下文信息的機制，它是針對每一個用戶的，變量的值保存在服務器端，通過SessionID來區(qū)分不同的客戶,session是以cookie或URL重寫為基礎的，默認使用cookie來實現(xiàn)，系統(tǒng)會創(chuàng)造一個名為JSESSIONID的輸出返回給客戶端Cookie保存。
保存session id的幾種方式
A．保存session id的方式可以采用cookie，這樣在交互過程中瀏覽器可以自動的按照規(guī)則把這個標識發(fā)送給服務器。
B．由于cookie可以被人為的禁止，必須有其它的機制以便在cookie被禁止時仍然能夠把session id傳遞回服務器，經常采用的一種技術叫做URL重寫，就是把session id附加在URL路徑的后面，附加的方式也有兩種，一種是作為URL路徑的附加信息，另一種是作為查詢字符串附加在URL后面。網絡在整個交互過程中始終保持狀態(tài)，就必須在每個客戶端可能請求的路徑后面都包含這個session id。
C．另一種技術叫做表單隱藏字段。就是服務器會自動修改表單，添加一個隱藏字段，以便在表單提交時能夠把session id傳遞回服務器。
24、動態(tài)廣播訂閱和靜態(tài)廣播訂閱的區(qū)別
靜態(tài)訂閱廣播又叫：常駐型廣播，當你的應用程序關閉了，如果有廣播信息來，你寫的廣播接收器同樣的能接受到，他的注冊方式就是在你的應用程序中的AndroidManifast.xml進行訂閱的。
動態(tài)訂閱廣播又叫：非常駐型廣播，當應用程序結束了，廣播自然就沒有了，比如你在activity中的onCreate或者onResume中訂閱廣播，同時你必須在onDestory或者onPause中取消廣播訂閱。不然會報異常，這樣你的廣播接收器就一個非常駐型的了。
這里面還有一個細節(jié)那就是這兩種訂閱方式，在發(fā)送廣播的時候需要注意的是：動態(tài)注冊的時候使用的是隱式intent方式的，所以在發(fā)送廣播的時候需要使用隱式Intent去發(fā)送，不然是廣播接收者是接收不到廣播的，這一點要注意。但是靜態(tài)訂閱的時候，因為在AndroidMainfest.xml中訂閱的，所以在發(fā)送廣播的時候使用顯示Intent和隱式Intent都可以(當然這個只針對于我們自己定義的廣播接收者)，所以以防萬一，我們一般都采用隱式Intent去發(fā)送廣播
動態(tài)廣播比靜態(tài)廣播具有更高的優(yōu)先級
25、Android handler機制
基本流程：
首先Looper.prepare()在本線程中保存一個Looper實例，然后該實例中保存一個MessageQueue對象；因為Looper.prepare()在一個線程中只能調用一次，所以MessageQueue在一個線程中只會存在一個。
2、Looper.loop()會讓當前線程進入一個無限循環(huán)，不端從MessageQueue的實例中讀取消息，然后回調msg.target.dispatchMessage(msg)方法。因為這里采用的是無限循環(huán)，所以可能會有個疑問：該循環(huán)會不會特別消耗CPU資源？其實并不會，如果messageQueue有消息，自然是繼續(xù)取消息；如果已經沒有消息了，此時該線程便會阻塞在該next()方法的nativePollOnce()方法中，主線程便會釋放CPU資源進入休眠狀態(tài)，直到下個消息到達或者有事務發(fā)生時，才通過往pipe管道寫端寫入數(shù)據來喚醒主線程工作
3、Handler的構造方法，會首先得到當前線程中保存的Looper實例，進而與Looper實例中的MessageQueue想關聯(lián)。
4、Handler的sendMessage方法，會給msg的target賦值為handler自身，然后加入MessageQueue中。
5、在構造Handler實例時，我們會重寫handleMessage方法，也就是msg.target.dispatchMessage(msg)最終調用的方法。
在Activity中，我們并沒有顯示的調用Looper.prepare()和Looper.loop()方法，為啥Handler可以成功創(chuàng)建呢，這是因為在Activity的啟動代碼中，已經在當前UI線程調用了Looper.prepare()和Looper.loop()方法。
26、AIDL原理
AIDL (Android Interface Definition Language) 是一種IDL 語言，用于生成可以在Android設備上兩個進程之間進行進程間通信(interprocess communication, IPC)的代碼。如果在一個進程中（例如Activity）要調用另一個進程中（例如Service）對象的操作，就可以使用AIDL生成可序列化的參數(shù)。AIDL IPC機制是面向接口的，像COM或Corba一樣，但是更加輕量級。它是使用代理類在客戶端和實現(xiàn)端傳遞數(shù)據。
27、Android 下res和assert有什么區(qū)別
相同點：.兩者目錄下的文件在打包后會原封不動的保存在apk包中，不會被編譯成二進制。
不同點：res/raw中的文件會被映射到R.Java文件中，訪問的時候直接使用資源id即R.id.filename；assets文件夾下的文件不會被映射到R.java中，訪問的時候需要AssetManager類。
raw是Resources (res)的子目錄，Android會自動的為這目錄中的所有資源文件生成一個ID，這個ID會被存儲在R類當中，作為一個文件的引用。這意味著這個資源 文件可以很容易的被Android的類和方法訪問到，甚至在Android XML文件中你也可以@raw/的形式引用到它。在Android中，使用ID是訪問一個文件最快捷的方式。MP3和Ogg文件放在這個目錄下是比較合適 的
assets目錄更像一個附錄類型的目錄，Android不會為這個目錄中的文件生成ID并保存在R類當中，因此它與 Android中的一些類和方法兼容度更低。同時，由于你需要一個字符串路徑來獲取這個目錄下的文件描述符，訪問的速度會更慢。但是把一些文件放在這個目 錄下會使一些操作更加方便，比方說拷貝一個數(shù)據庫文件到系統(tǒng)內存中。要注意的是，你無法在Android XML文件中引用到assets目錄下的文件，只能通過AssetManager來訪問這些文件。數(shù)據庫文件和游戲數(shù)據等放在這個目錄下是比較合適的。
28、頁面卡頓原因分析及分析工具以及解決方法
界面卡頓影響的頁面 ：ListView、ScrollView、有動畫的頁面等
分析步驟：打開調試開發(fā)者選項，GPU呈現(xiàn)模式分析：如果藍色部分比較高，說明是UI線程性能問題；紅色部分比較高，應該是DrawList比較復雜，這部分可能跟藍色部分相關。目前還沒想到藍色部分不高，紅色部分搞的案例；黃色部分高，也許是GPU太忙，也許是CPU太忙。 GPU太忙，說明DrawList太多，CPU太忙，說明要么主線程性能有問題，要么GPU太忙，來不及通知主線程?？偟膩碚f，三部分是相關的。藍色部分的高，可以直接導致紅色和黃色部分的高，所以，重點還是分析藍色部分的高。
分析主線程性能：兩種類型的影響因素：全局級別的影響因素；比如CPU性能低、內存不足，頻繁GC。 頁面級別的影響因素；頁面的 measure比較耗時頁面的、 layout比較耗時、頁面的 draw比較耗時。
如果所有頁面都慢，判定是全局級別因素，如果只有某個頁面慢，判定是頁面級別的原因
頁面級別的影響因素一般原因：有自定義控件，measure, layout, draw效率比較低；View 結構比較復雜或者不合理，導致 measure, layout效率比較低；頁面結構設計復雜或者不合理，導致draw效率比較低，過度繪制
頁面級別影響因素的分析工具及方法：
自定義控件效率低下：用 method tracing可以發(fā)現(xiàn)，Android Studio:? Android Monitor-->start method tracing,結果用Exclusive Time排序
Android systrace? ? Method Profiling
29、Json數(shù)據的解析
android的json解析部分都在包org.json下，主要有以下幾個類：
JSONObject：可以看作是一個json對象,這是系統(tǒng)中有關JSON定義的基本單元，其包含一對(Key/Value)數(shù)值
JSONArray：它代表一組有序的數(shù)值
解析Json的例子：
/ 假設現(xiàn)在要創(chuàng)建這樣一個json文本
//??{
//??????"phone"?:?["12345678",?"87654321"],?//?數(shù)組
//??????"name"?:?"yuanzhifei89",?//?字符串
//??????"age"?:?100,?//?數(shù)值
//??????"address"?:?{?"country"?:?"china",?"province"?:?"jiangsu"?},?//?對象
//??????"married"?:?false?//?布爾值
//??}
try{
//?首先最外層是{}，是創(chuàng)建一個對象
JSONObject?person?=newJSONObject();
//?第一個鍵phone的值是數(shù)組，所以需要創(chuàng)建數(shù)組對象
JSONArray?phone?=newJSONArray();
phone.put("12345678").put("87654321");
person.put("phone",?phone);
person.put("name","yuanzhifei89");
person.put("age",100);
//?鍵address的值是對象，所以又要創(chuàng)建一個對象
JSONObject?address?=newJSONObject();
address.put("country","china");
address.put("province","jiangsu");
person.put("address",?address);
person.put("married",false);
}catch(JSONException?ex)?{
//?鍵為null或使用json不支持的數(shù)字格式(NaN,?infinities)
thrownewRuntimeException(ex);
}
30、怎么做出一個dialog樣式的activity
android自帶theme如下：
?android:theme="@android:style/Theme.Dialog"?? 將一個Activity顯示為對話框模式
?android:theme="@android:style/Theme.NoTitleBar"? 不顯示應用程序標題欄
?android:theme="@android:style/Theme.NoTitleBar.Fullscreen"? 不顯示應用程序標題欄，并全屏
?android:theme="Theme.Light"? 背景為白色
?android:theme="Theme.Light.NoTitleBar"? 白色背景并無標題欄
?android:theme="Theme.Light.NoTitleBar.Fullscreen"? 白色背景，無標題欄，全屏
?android:theme="Theme.Black"? 背景黑色
?android:theme="Theme.Black.NoTitleBar"? 黑色背景并無標題欄
?android:theme="Theme.Black.NoTitleBar.Fullscreen"??? 黑色背景，無標題欄，全屏
?android:theme="Theme.Wallpaper"? 用系統(tǒng)桌面為應用程序背景
?android:theme="Theme.Wallpaper.NoTitleBar"? 用系統(tǒng)桌面為應用程序背景，且無標題欄
?android:theme="Theme.Wallpaper.NoTitleBar.Fullscreen"? 用系統(tǒng)桌面為應用程序背景，無標題欄，全屏
?android:theme="Translucent"
?android:theme="Theme.Translucent.NoTitleBar"
?android:theme="Theme.Translucent.NoTitleBar.Fullscreen"
?android:theme="Theme.Panel"
?android:theme="Theme.Light.Panel"
其實，只要在manifest.xml文件中把中設置為android:theme = "@android:style/Theme.Dialog"即可
31、點擊短信里的鏈接進入APP
詳情請看：http://blog.csdn.net/books1958/article/details/49948555
32、POST和GET的區(qū)別
GET在瀏覽器回退時是無害的，而POST會再次提交請求。 GET產生的URL地址可以被Bookmark，而POST不可以。 GET請求會被瀏覽器主動cache，而POST不會，除非手動設置。 GET請求只能進行url編碼，而POST支持多種編碼方式。 GET請求參數(shù)會被完整保留在瀏覽器歷史記錄里，而POST中的參數(shù)不會被保留。 GET請求在URL中傳送的參數(shù)是有長度限制的，而POST么有。 對參數(shù)的數(shù)據類型，GET只接受ASCII字符，而POST沒有限制。 GET比POST更不安全，因為參數(shù)直接暴露在URL上，所以不能用來傳遞敏感信息。 GET參數(shù)通過URL傳遞，POST放在Request body中。
其實GET和POST本質上就是TCP鏈接，并無差別。但是由于HTTP的規(guī)定和瀏覽器/服務器的限制，導致他們在應用過程中體現(xiàn)出一些不同。
GET和POST還有一個重大區(qū)別，簡單的說：GET產生一個TCP數(shù)據包;POST產生兩個TCP數(shù)據包。
對于GET方式的請求，瀏覽器會把http header和data一并發(fā)送出去，服務器響應200(返回數(shù)據);
而對于POST，瀏覽器先發(fā)送header，服務器響應100 continue，瀏覽器再發(fā)送data，服務器響應200 ok(返回數(shù)據)。
也就是說，GET只需要汽車跑一趟就把貨送到了，而POST得跑兩趟，第一趟，先去和服務器打個招呼“嗨，我等下要送一批貨來，你們打開門迎接我”，然后再回頭把貨送過去。
并不是所有瀏覽器都會在POST中發(fā)送兩次包，F(xiàn)irefox就只發(fā)送一次。
33、Android中asserts目錄和raw目錄的區(qū)別
34、java的一些基礎面試題
未完待續(xù)~~~~~~
