1、 活動Activity的啟動模式
Standard（標準模式）
活動默認的啟動方式
singleTop（棧頂復用模式）
在啟動活動時如果發(fā)現(xiàn)返回棧的棧頂已經(jīng)是該活動，則認為可以直接使用它，不會再創(chuàng)建新的活動實例。
singleTask（棧內(nèi)復用模式）
每次啟動該活動時，系統(tǒng)首先會在返回棧中檢查是否存在該實例，如果發(fā)現(xiàn)已存在則直接使用該實例，并把這個活動之上的所有活動統(tǒng)統(tǒng)出棧，如果沒有發(fā)現(xiàn)就會創(chuàng)建一個新的活動實例。
singleInstance（單實例模式）
啟用一個新的返回棧管理這個活動，解決共享活動實例的問題。
2、 活動在其生命周期的四種狀態(tài)
一個活動在其存在，也就是生命周期中一共存在四種狀態(tài)：
運行：位于棧頂，系統(tǒng)最不愿意回收的活動。
暫停：不是棧頂?shù)奈恢?，但是在界面依舊可見，并不是每一個活動都占滿整個屏幕，當系統(tǒng)內(nèi)存比較低的時候會回收。
停止：不是棧頂?shù)奈恢?，完全不可見，仍然會存一些成員變量的內(nèi)容，當其他地方需要內(nèi)存的時候會回收。
銷毀：從返回棧中移除之后，系統(tǒng)最喜歡的就是回收這種活動。
3、 Activity的生命周期
管理活動聲明周期(Managing the activity lifecycle)：
onCreate():該回調(diào)在系統(tǒng)創(chuàng)建活動時觸發(fā)，必須實現(xiàn)此回調(diào)。必須在此處調(diào)用setContentView()以定義活動界面的布局當onCreate()完成后回調(diào)onStart()。
onStart():在onCreate()退出時，活動進入開始狀態(tài)，并且活性變得對用戶可見。
onResume():在活動開始與用戶交互前，系統(tǒng)將調(diào)用此回調(diào)。此時，活動位于活動對戰(zhàn)的頂部，并捕獲所有用戶輸入。該onResume()方法實現(xiàn)了應用程序的大多數(shù)核心功能onPause()回調(diào)始終遵循onResume()。
onPause():當活動失去焦點并進入暫停狀態(tài)時，系統(tǒng)將調(diào)用。不應該使用onPause()保存應用程序或用戶數(shù)據(jù)，進行網(wǎng)絡調(diào)用，或執(zhí)行數(shù)據(jù)庫事務。一旦onPause()執(zhí)行完畢，接下來的回調(diào)是onStop()或onResume()，根據(jù)活動進入暫停狀態(tài)以合會發(fā)生什么。
onStop():onStop()當用戶停止或銷毀該活動時，將調(diào)用。系統(tǒng)將調(diào)用的下一個回調(diào)是onReatart()，如果活動返回與用戶交互，或者是onDestory()該活動完全終止。
onRestart():當處于“已停止”狀態(tài)的活動即將重新啟動時，系統(tǒng)將調(diào)用此回調(diào)。onRestart()從活動停止時回復其狀態(tài)，之后回調(diào)是onStart()。
onDestory():在活動被銷毀之前，系統(tǒng)將調(diào)用此回調(diào)此回調(diào)是活動收到的最后一個回調(diào)。onDestroy()通常實現(xiàn)可以確保在銷毀活動或包含活動的流程時釋放活動的所有資源。
4、 TCP的三次握手與四次揮手
三次握手
? 第一次：客戶端發(fā)送請求到服務器，服務器知道客戶端發(fā)送，自己接收正常。SYN=1,seq=x
? 第二次：服務器發(fā)給客戶端，客戶端知道自己發(fā)送、接收正常，服務器接收、發(fā)送正常。ACK=1,ack=x+1,SYN=1,seq=y
? 第三次：客戶端發(fā)給服務器：服務器知道客戶端發(fā)送，接收正常，自己接收，發(fā)送也正常.seq=x+1,ACK=1,ack=y+1
四次揮手
? 第一次揮手：客戶端發(fā)出釋放FIN=1，自己序列號seq=u，進入FIN-WAIT-1狀態(tài)
? 第二次揮手：服務器收到客戶端的后，發(fā)出ACK=1確認標志和客戶端的確認號ack=u+1，自己的序列號seq=v，進入CLOSE-WAIT狀態(tài)
? 第三次揮手：客戶端收到服務器確認結果后，進入FIN-WAIT-2狀態(tài)。此時服務器發(fā)送釋放FIN=1信號，確認標志ACK=1，確認序號ack=u+1，自己序號seq=w，服務器進入LAST-ACK（最后確認態(tài)）
? 第四次揮手：客戶端收到回復后，發(fā)送確認ACK=1，ack=w+1，自己的seq=u+1，客戶端進入TIME-WAIT（時間等待）。客戶端經(jīng)過2個最長報文段壽命后，客戶端CLOSE；服務器收到確認后，立刻進入CLOSE狀態(tài)。
5、 OkHttp的優(yōu)點
①允許連接到同一個主機地址的所有請求,提高請求效率?
②共享Socket,減少對服務器的請求次數(shù)?
③通過連接池,減少了請求延遲
④緩存響應數(shù)據(jù)來減少重復的網(wǎng)絡請求
⑤減少了對數(shù)據(jù)流量的消耗?
⑥自動處理GZip壓縮
6、 http和https的區(qū)別
①HTTPS協(xié)議需要到 CA?（Certificate Authority，證書頒發(fā)機構）申請證書，一般免費證書較少，因而需要一定費用。
②HTTP是超文本傳輸協(xié)議，信息是明文傳輸，HTTPS 則是具有安全性的 SSL?加密傳輸協(xié)議。
③、HTTP和 HTTPS 使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。
④、HTTP的連接很簡單，是無狀態(tài)的。HTTPS?協(xié)議是由 SSL+HTTP?協(xié)議構建的可進行加密傳輸、身份認證的網(wǎng)絡協(xié)議，比 HTTP 協(xié)議安全。(無狀態(tài)的意思是其數(shù)據(jù)包的發(fā)送、傳輸和接收都是相互獨立的。無連接的意思是指通信雙方都不長久的維持對方的任何信息。)
7、 TCP與UDP的特點
TCP和UDP都是傳輸層的協(xié)議，它們起到的最基本功能都是將IP提供的主機-主機傳遞服務擴展到端-端的進程級，通俗來說，就是把數(shù)據(jù)段從一個電腦上面的一個應用傳遞到另一個電腦上面的一個應用上面。除此之外，它們還都有的功能是差錯檢測功能，注意，只是檢測功能，即都能發(fā)現(xiàn)錯誤，但是對于錯誤的處理就不相同了。
UDP協(xié)議：User Datagram Protocol，即用戶數(shù)據(jù)報協(xié)議。提供了不可靠的無連接傳輸服務。它使用IP傳輸報文，但增加了對給定主機上多個目標進行區(qū)別的能力。它的結構比較簡單，但是對于差錯的控制是不可靠的。
具體來說，UDP協(xié)議：①沒有確認機制。每當接收端接收到數(shù)據(jù)段之后，進行差錯校驗，不論是否有誤，都不會給發(fā)端進行反饋，如果有錯誤就丟棄。這樣發(fā)端就不知道這個數(shù)據(jù)段的傳輸情況，這對于提升效率是有好處的。②不對報文排序 即使數(shù)據(jù)段的順序是不對的，收端也不會返回錯誤或者進行排序? ③沒有反饋機制進行流量控制? 流量控制能夠有效避免接收端處理太慢從而造成緩沖區(qū)溢出的丟包事件，但是UDP沒有這方面的處理，丟了就是丟了，也不會給發(fā)送端報告錯誤。? ④沒有超時機制? ?丟包了也不會重發(fā)。
這些特點導致了報文的丟棄，重復和亂序。但是我們都知道我們希望數(shù)據(jù)的完整性和順序性，所以使用UDP的應用程序要承擔可靠性方面的全部工作。
UDP優(yōu)點
①它的報頭開銷小。UDP的頭只有8字節(jié)長，但是TCP的頭有20字節(jié)。報文頭短，結構簡單，提升了數(shù)據(jù)傳輸?shù)男省?/p>
②它是面向無連接的，不需要在傳輸之前建立連接。并且不用建立連接，就不需要維護連接狀態(tài)。這有什么用呢？UDP的非連接性讓它不需要給每一個數(shù)據(jù)報編號，和發(fā)送確認號。它的延遲就更少，實時性好。所以說，UDP更適于像視頻傳輸那種對于正確率要求并不是很高，但是要求延遲低的應用。
③應用程序可控制何時發(fā)送數(shù)據(jù)。UDP想發(fā)送數(shù)據(jù)，直接發(fā)送即可，但是TCP就需要收到確認之后才能發(fā)送（由于擁塞和流量控制決定的）。并且遇到網(wǎng)絡擁塞，TCP會使應用直接阻塞，無法發(fā)送。
TCP協(xié)議：Transmission Control Protocol 傳輸控制協(xié)議。提供了可靠的面向連接的字節(jié)流傳輸協(xié)議。那么和UDP協(xié)議的區(qū)別無非有兩點：可靠的，面向連接的。
面向連接，是指發(fā)送數(shù)據(jù)之前必須在兩端建立連接。建立連接的方法是“三次握手”，這樣能建立可靠的連接。建立連接，是為數(shù)據(jù)的可靠傳輸打下了基礎。所謂可靠傳輸，是TCP協(xié)議中規(guī)定了：①如何處理丟失或重復等差錯情況。②如何初始化一個數(shù)據(jù)流傳輸 ③如何協(xié)商結束數(shù)據(jù)流傳輸 ④流量控制和擁塞控制機制。解釋如下：
對于可靠傳輸，判斷丟包，重復靠的是TCP的段編號以及確認號。TCP在發(fā)送數(shù)據(jù)的時候，為每個字節(jié)編號，接收端收到數(shù)據(jù)之后，經(jīng)過校驗無誤，發(fā)回確認號，確認號為接收端等待接受的寫一個字節(jié)的序號。并且它會緩存到達的亂序數(shù)據(jù)，統(tǒng)一排序之后傳遞給上層。這樣就解決了丟包，重復和亂序的問題。
協(xié)商開始和結束數(shù)據(jù)傳輸：當協(xié)商開始數(shù)據(jù)傳輸?shù)臅r候要發(fā)送SYN信號，請求同步，并且告知將要發(fā)送的數(shù)據(jù)序號是多少，經(jīng)過三次握手兩端都知道對方已經(jīng)建立連接并且知道對方將要從那個序號開始發(fā)送；結束的時候一方發(fā)送FIN結束信號，另一方收到之后發(fā)送ACK確認信號，于是兩端都知道連接被釋放，數(shù)據(jù)傳輸就停止了。
流量控制和擁塞控制：TCP采用滑動窗口的方式進行流量控制，用擁塞窗口的速率調(diào)整算法（慢啟動算法）來進行擁塞控制。
這些功能都是UDP所不具備的，它們都是為了可靠數(shù)據(jù)傳輸所提供的，但是TCP相對也有缺點。比如說延遲大，實時性不好等等。缺點看看上文UDP的優(yōu)點就能對比出來了。
TCP和UDP各有優(yōu)缺點，最主要的區(qū)別就是可靠與不可靠，以及是否面向連接。兩者共同構成了傳輸層端對端數(shù)據(jù)傳輸?shù)幕A。
7、 有幾種布局方式？
線性布局、絕對布局（比較老舊的布局，基本不用）、相對布局、網(wǎng)格布局、表格布局、幀布局。
8、 layout_gravity與gravity的區(qū)別？
android:layout_gravity：設置控件本身相對于父控件的顯示位置。
android:gravity：設置的是控件自身上面的內(nèi)容位置。
9、 Activity的緩存方法是怎么樣的？
Activity的緩存方法主要有onSaveInstanceState(Bundle outState)、onRestoreInstanceState(Bundle saveInstanceState)、onCeate(Bundle saveInsanceState)，Android系統(tǒng)的回收機制會在未經(jīng)用戶主動操作的情況下銷毀Activity，而為了避免這種機制的系統(tǒng)回收Activity導致數(shù)據(jù)丟失，Android為我們提供了onSaveInstanceState（Bundle outState）和onRestoreInstanceState（Bundle saveInstanceState）、onCreate（Bundle saeInstanceState）用于保存和恢復數(shù)據(jù)。
