Service生命周期

1、service 啟動方式有兩種奉瘤，一種是通過startService()方式進行啟動亲族，另一種是通過bindService()方式進行啟動种呐。

startService()這種方式啟動的service狠半，生命周期是這樣：調用startService() --> onCreate()--> onStartConmon()--> onDestroy()噩死。這種方式啟動的話，第一：通過startService被調用以后神年，多次在調用startService(),onCreate()方法也只會被調用一次已维，而onStartConmon()會被多次調用當我們調用stopService()的時候，onDestroy()就會被調用已日，從而銷毀服務垛耳。

bindService()方式進行綁定，這種方式綁定service，生命周期走法：bindService-->onCreate()-->onBind()-->unBind()-->onDestroy()? bindservice 這種方式進行啟動service好處是更加便利activity中操作service堂鲜，在activity獲取ServiceConnection對象栈雳，通過ServiceConnection來獲取service中內部類的類對象，然后通過這個類對象就可以操作泡嘴。

2甫恩、Broadcast注冊方式與區(qū)別

第一種是靜態(tài)注冊逆济，也可成為常駐型廣播酌予，這種廣播需要在Androidmanifest.xml中進行注冊，這中方式注冊的廣播奖慌，不受頁面生命周期的影響抛虫，即使退出了頁面，也可以收到廣播這種廣播一般用于想開機自啟動啊等等简僧，由于這種注冊的方式的廣播是常駐型廣播建椰，所以會占用CPU的資源。

第二種是動態(tài)注冊岛马，而動態(tài)注冊的話棉姐，是在代碼中注冊的，這種注冊方式也叫非常駐型廣播啦逆，收到生命周期的影響伞矩，退出頁面后，就不會收到廣播夏志，我們通常運用在更新UI方面乃坤。這種注冊方式優(yōu)先級較高。最后需要解綁沟蔑，否則會內存泄露湿诊。

3、HttpClient與HttpUrlConnection的區(qū)別

首先HttpClient和HttpUrlConnection 這兩種方式都支持Https協(xié)議瘦材，都是以流的形式進行上傳或者下載數(shù)據(jù)等功能厅须。HttpClient這個擁有非常多的API，很難進行兼容擴展食棕，而HttpUrlConnection相對來說就是比較輕量級了朗和，API比較少，容易擴展宣蠕；

Java虛擬機：

1例隆、java虛擬機基于棧。

2抢蚀、java虛擬機運行的是java字節(jié)碼镀层。（java類會被編譯成一個或多個字節(jié)碼.class文件）

Dalvik虛擬機：

1、dalvik虛擬機是基于寄存器的

2、Dalvik運行的是自定義的.dex字節(jié)碼格式唱逢。（java類被編譯成.class文件后吴侦，會通過一個dx工具將所有的.class文件轉換成一個.dex文件，然后dalvik虛擬機會從其中讀取指令和數(shù)據(jù)

5坞古、進程北溉停活（不死進程）

當前業(yè)界的Android進程保活手段主要分為** 黑痪枫、白织堂、灰 **三種，其大致的實現(xiàn)思路如下：

黑色蹦坛拢活：不同的app進程易阳，用廣播相互喚醒（包括利用系統(tǒng)提供的廣播進行喚醒）{利用不同的app進程使用廣播來進行相互喚醒：開機廣播、三方sdk}

白色背粤＃活：調用系統(tǒng)api啟動一個前臺的Service進程潦俺，這樣會在系統(tǒng)的通知欄生成一個Notification

灰色保活：利用系統(tǒng)的漏洞啟動前臺Service徐勃，它不會在系統(tǒng)通知欄處出現(xiàn)一個Notification事示，看起來就如同運行著一個后臺Service進程一樣，大致的實現(xiàn)思路如下：

1 API < 18僻肖，啟動前臺Service時直接傳入new Notification()肖爵；

2 API >= 18，同時啟動兩個id相同的前臺Service檐涝，然后再將后啟動的Service做stop處理

用C編寫守護進程(即子進程) :?Android系統(tǒng)中當前進程fork出來的子進程遏匆，被系統(tǒng)認為是兩個不同的進程。當父進程被殺死的時候谁榜，子進程仍然可以存活幅聘。

5、講解一下Context

Context是一個抽象基類窃植。翻譯為上下文帝蒿，是提供一些程序的運行環(huán)境基礎信息。Context下有兩個子類巷怜，ContextWrapper是上下文功能的封裝類葛超，而ContextImpl則是上下文功能的實現(xiàn)類。? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ContextWrapper又有三個直接的子類延塑， ContextThemeWrapper绣张、Service和Application。其中关带，ContextThemeWrapper是一個帶主題的封裝類侥涵，而它有一個直接子類就是Activity， Context一共有三種類型，Application芜飘、Activity和Service务豺。它們都屬于Context的一種，而它們具體的功能則是由ContextImpl類去實現(xiàn)的嗦明，因此在絕大多數(shù)場景下笼沥，Activity、Service和Application這三種類型的Context都是可以通用的娶牌，特殊場景只能使用Activity類型的Context奔浅。

6、四種LaunchMode及其使用場景

standard 模式

這是默認模式裙戏，每次激活Activity時都會創(chuàng)建Activity實例乘凸，并放入任務棧中。使用場景：大多數(shù)Activity累榜。

singleTop 模式

如果在任務的棧頂正好存在該Activity的實例，就重用該實例灵嫌，否則就會創(chuàng)建新的實例并放入棧頂壹罚，即使棧中已經(jīng)存在該Activity的實例，只要不在棧頂寿羞，都會創(chuàng)建新的實例猖凛。

singleTask 模式

如果在棧中已經(jīng)有該Activity的實例，會讓該實例回到棧頂绪穆，因此在它上面的實例將會被移出棧辨泳。如果棧中不存在該實例，將會創(chuàng)建新的實例放入棧中玖院。

singleInstance

這種啟動模式比較特殊菠红，因為它會啟用一個新的棧結構，將Acitvity放置于這個新的棧結構中难菌，并保證不再有其他Activity實例進入

7试溯、Android中的幾種動畫

幀動畫：指通過指定每一幀的圖片和播放時間，有序的進行播放而形成動畫效果郊酒，比如想聽的律動條遇绞。

補間動畫：指通過指定View的初始狀態(tài)、變化時間燎窘、方式摹闽，通過一系列的算法去進行圖形變換，從而形成動畫效果褐健，主要有Alpha付鹿、Scale、Translate、Rotate四種效果倘屹。注意：只是在視圖層實現(xiàn)了動畫效果银亲，并沒有真正改變View的屬性，比如滑動列表纽匙，改變標題欄的透明度务蝠。

屬性動畫：在Android3.0的時候才支持，通過不斷的改變View的屬性烛缔，不斷的重繪而形成動畫效果馏段。相比于視圖動畫，View的屬性是真正改變了践瓷。比如view的旋轉院喜，放大，縮小晕翠。

8喷舀、Binder機制原理

在Android系統(tǒng)的Binder機制中，是有Client,Service,ServiceManager,Binder驅動程序組成的淋肾，其中Client硫麻，service，Service Manager運行在用戶空間樊卓，Binder驅動程序是運行在內核空間的拿愧。而Binder就是把這4種組件粘合在一塊的粘合劑，其中核心的組件就是Binder驅動程序碌尔，Service Manager提供輔助管理的功能浇辜，而Client和Service正是在Binder驅動程序和Service Manager提供的基礎設施上實現(xiàn)C/S 之間的通信。其中Binder驅動程序提供設備文件/dev/binder與用戶控件進行交互唾戚，Client柳洋、Service，Service Manager通過open和ioctl文件操作相應的方法與Binder驅動程序進行通信颈走。而Client和Service之間的進程間通信是通過Binder驅動程序間接實現(xiàn)的膳灶。而Binder Manager是一個守護進程，用來管理Service立由，并向Client提供查詢Service接口的能力轧钓。

1. 從IPC角度來說，Binder是Android中的一種跨進程通信方式锐膜，Binder還可以理解為一種虛擬的物理設備毕箍，它的設備驅動是/dev/binder，該通信方式在linux中沒有

2. 從Android Framework角度來說道盏，Binder是ServiceManager連接各種Manager（ActivityManager而柑、WindowManager文捶，etc）和相應ManagerService的橋梁

3. 從Android應用層來說，Binder是客戶端和服務端進行通信的媒介媒咳，當你bindService的時候粹排，服務端會返回一個包含了服務端業(yè)務調用的Binder對象，通過這個Binder對象涩澡，客戶端就可以獲取服務端提供的服務或者數(shù)據(jù)顽耳，這里的服務包括普通服務和基于AIDL的服務

1、同進程中Activity和Service進行通訊時候妙同，用到binder,在Activity中對Servrice進行操作

2射富、不同進程可以用AIDL讓系統(tǒng)創(chuàng)建一個Binder,然后Activity對遠端的service進行操作。

9粥帚、AIDL理解

AIDL: 每一個進程都有自己的Dalvik VM實例胰耗，都有自己的一塊獨立的內存，都在自己的內存上存儲自己的數(shù)據(jù)芒涡，執(zhí)行著自己的操作柴灯，都在自己的那片狹小的空間里過完自己的一生。而aidl就類似與兩個進程之間的橋梁拖陆，使得兩個進程之間可以進行數(shù)據(jù)的傳輸弛槐，跨進程通信有多種選擇，比如 BroadcastReceiver , Messenger 等依啰，但是 BroadcastReceiver 占用的系統(tǒng)資源比較多，如果是頻繁的跨進程通信的話顯然是不可取的店枣；Messenger 進行跨進程通信時請求隊列是同步進行的速警，無法并發(fā)執(zhí)行。

10鸯两、熱修復的原理

Tinker熱修復 ：是微信官方發(fā)布的 Android 熱補丁解決方案闷旧，它支持動態(tài)下發(fā)代碼、So庫以及資源钧唐，讓應用能夠在不需要重新安裝的情況下實現(xiàn)更新忙灼；

原理：Tinker都利用了Android 的類加載機制，Android中有兩個主要的Classloader钝侠，PathClassLoader和DexClassLoader该园，它們都繼承自BaseDexClassLoader，Android系統(tǒng)通過PathClassLoader來加載系統(tǒng)類和主dex中的類帅韧。而DexClassLoader則可用于加載指定路徑的apk里初、jar或dex文件。BaseDexClassLoader 中調用findClass忽舟，這個方法中會遍歷dexpathlist中的dexElements數(shù)組双妨，然后初始化DexFile淮阐。ClassLoader在加載到正確的類之后就會停止加載此類,因此我們將包含正確的類的Dex文件中插入在dexElements數(shù)組前面就可以完成對問題類的修復

流程：啟動應用-》有無fix_classes.dex文件-》下載補丁 patch.dex-》開啟TinkerPathService 和舊dex文件合并生成全量dex-》重新啟動把這個全量dex elements前面 –》完成修復

11、Android UI適配

字體使用sp,使用dp刁品，多使用match_parent泣特，wrap_content，weight

圖片資源挑随，不同圖片的的分辨率状您，放在相應的文件夾下可使用百分比代替。

12镀裤、JAVA GC原理

垃圾收集算法的核心思想是：對虛擬機可用內存空間竞阐，即堆空間中的對象進行識別，如果對象正在被引用暑劝，那么稱其為存活對象

骆莹，反之，如果對象不再被引用担猛，則為垃圾對象幕垦，可以回收其占據(jù)的空間，用于再分配傅联。垃圾收集算法的選擇和垃圾收集系統(tǒng)參數(shù)的合理調節(jié)直接影響著系統(tǒng)性能先改。

13、ANR

ANR全名Application Not Responding, 也就是"應用無響應". 安卓應用程序是由活動管理器和窗口管理器來監(jiān)聽的

產生原因：

(1)app5s內無法響應用戶輸入事件(例如鍵盤輸入, 觸摸屏幕等).

(2)BroadcastReceiver在10s內無法結束

(3)Service 20s內無法結束（低概率）

解決方式：

(1)不要在主線程中做耗時的操作蒸走，而應放在子線程中來實現(xiàn)仇奶。如onCreate()和onResume()里盡可能少的去做創(chuàng)建操作。

(2)應用程序應該避免在BroadcastReceiver里做耗時的操作或計算比驻。

(3)避免在Intent Receiver里啟動一個Activity该溯，因為它會創(chuàng)建一個新的畫面，并從當前用戶正在運行的程序上搶奪焦點别惦。

(4)service是運行在主線程的狈茉，所以在service中做耗時操作，必須要放在子線程中掸掸。

14氯庆、RecyclerView和ListView的區(qū)別

RecyclerView可以完成ListView,GridView的效果，還可以完成瀑布流的效果及列表的滾動方向（垂直或者水平）扰付；RecyclerView提供了API來實現(xiàn)item的動畫效果堤撵；RecyclerView還可以組合展示不同類型的view。

在性能上：

如果需要頻繁的刷新數(shù)據(jù)悯周，需要添加動畫粒督，則RecyclerView有較大的優(yōu)勢。

如果只是作為列表展示禽翼，則兩者區(qū)別并不是很大屠橄。

15族跛、static

1、static變量：對于靜態(tài)變量在內存中只有一個拷貝（節(jié)省內存）锐墙，JVM只為靜態(tài)分配一次內存礁哄，

在加載類的過程中完成靜態(tài)變量的內存分配于样，可用類名直接訪問（方便）亚脆，當然也可以通過對象來訪問（但是這是不推薦的）。

2芙代、static代碼塊

static代碼塊是類加載時之拨，初始化自動執(zhí)行的茉继。

3、static方法

static方法可以直接通過類名調用蚀乔，任何的實例也都可以調用烁竭，因此static方法中不能用this和super關鍵字，

不能直接訪問所屬類的實例變量和實例方法(就是不帶static的成員變量和成員成員方法)吉挣，只能訪問所屬類的靜態(tài)成員變量和成員方法派撕。

16、String,StringBuffer,StringBuilder區(qū)別

1睬魂、三者在執(zhí)行速度上：StringBuilder > StringBuffer > String (由于String是常量终吼，不可改變，拼接時會重新創(chuàng)建新的對象)氯哮。

2际跪、StringBuffer是線程安全的，StringBuilder是線程不安全的喉钢。（由于StringBuffer有緩沖區(qū)）

Java中重載和重寫的區(qū)別：

1垫卤、重載：一個類中可以有多個相同方法名的，但是參數(shù)類型和個數(shù)都不一樣出牧。這是重載。

2歇盼、重寫：子類繼承父類舔痕，則子類可以通過實現(xiàn)父類中的方法，從而新的方法把父類舊的方法覆蓋豹缀。

17伯复、網(wǎng)絡 Http https區(qū)別

1、https協(xié)議需要到ca申請證書邢笙，一般免費證書較少啸如，因而需要一定費用。

2氮惯、http是超文本傳輸協(xié)議叮雳，信息是明文傳輸想暗，https則是具有安全性的ssl加密傳輸協(xié)議。

3帘不、http和https端口不一樣说莫，前者是80，后者是443寞焙。

7储狭、Http位于TCP/IP模型中的第幾層？為什么說Http是可靠的數(shù)據(jù)傳輸協(xié)議捣郊？

tcp/ip的五層模型：

從下到上：物理層->數(shù)據(jù)鏈路層->網(wǎng)絡層->傳輸層->應用層

其中tcp/ip位于模型中的網(wǎng)絡層辽狈，處于同一層的還有ICMP（網(wǎng)絡控制信息協(xié)議）。http位于模型中的應用層（先有ip在tcp）

由于tcp/ip是面向連接的可靠協(xié)議呛牲，而http是在傳輸層基于tcp/ip協(xié)議的刮萌，所以說http是可靠的數(shù)據(jù)傳輸協(xié)議。

8侈净、HTTP鏈接的特點

HTTP連接最顯著的特點是客戶端發(fā)送的每次請求都需要服務器回送響應尊勿，在請求結束后，會主動釋放連接畜侦。

從建立連接到關閉連接的過程稱為“一次連接”元扔。

9、TCP和UDP的區(qū)別

tcp是面向連接的旋膳，由于tcp連接需要三次握手澎语，所以能夠最低限度的降低風險，保證連接的可靠性验懊。

udp 不是面向連接的擅羞，udp不需要與對象建立連接，無論是發(fā)送還是接收义图，都沒有發(fā)送確認信號减俏。所以說udp是不可靠的。

由于udp不需要進行確認連接碱工，使得UDP的開銷更小娃承，傳輸速率更高，所以實時行更好怕篷。

10历筝、Socket建立網(wǎng)絡連接的步驟

建立Socket連接至少需要一對套接字，其中一個運行與客戶端--ClientSocket廊谓，一個運行于服務端--ServiceSocket

1梳猪、服務器監(jiān)聽：服務器端套接字并不定位具體的客戶端套接字，而是處于等待連接的狀態(tài)蒸痹，實時監(jiān)控網(wǎng)絡狀態(tài)春弥，等待客戶端的連接請求呛哟。

2、客戶端請求：指客戶端的套接字提出連接請求惕稻，要連接的目標是服務器端的套接字竖共。注意：客戶端的套接字必須描述他要連接的服務器的套接字，

指出服務器套接字的地址和端口號俺祠，然后就像服務器端套接字提出連接請求公给。

3、連接確認：當服務器端套接字監(jiān)聽到客戶端套接字的連接請求時蜘渣，就響應客戶端套接字的請求淌铐，建立一個新的線程，把服務器端套接字的描述

發(fā)給客戶端蔫缸，一旦客戶端確認了此描述腿准，雙方就正式建立連接。而服務端套接字則繼續(xù)處于監(jiān)聽狀態(tài)拾碌，繼續(xù)接收其他客戶端套接字的連接請求吐葱。

17、內存管理區(qū)域：

共享數(shù)據(jù)區(qū)：

? ? ? ? ? 方法區(qū)：存放類信息校翔、常量弟跑、靜態(tài)變量、編譯器編譯后的代碼等數(shù)據(jù)

? ? ? ? ? ? ? ? ? 堆：對象分配內存的區(qū)域

線程私有 ：

? ? ? 虛擬機棧：方法執(zhí)行的內存區(qū)防症，每個方法執(zhí)行時會在虛擬機棧中創(chuàng)建棧幀孟辑；

? 本地方法棧：虛擬機的Native方法執(zhí)行的內存區(qū)

? 程序計數(shù)器：記錄正在執(zhí)行的虛擬機字節(jié)碼的地址

18、JAVA中堆和棧的區(qū)別

基本數(shù)據(jù)類型變量和對象 的引用都是在棧中

堆內存用來存放由new創(chuàng)建的對象和數(shù)組

static修飾的變量蔫敲，程序在一加載的時候就在堆中為類變量分配內存饲嗽，堆中的內存地址存放在棧中

實例變量：當你使用java關鍵字new的時候，系統(tǒng)在堆中開辟間分配給變量

局部變量:由聲明在某方法奈嘿，或某代碼段里（比如for循環(huán)）貌虾，執(zhí)行到它的時候在棧中開辟內存，當局部變量一但脫離作用域裙犹，內存立即釋放

19酝惧、XML解析

解析XML的幾種方式的原理與特點：DOM、SAX伯诬、PULL

SAX和pull 基于事件驅動的流動解析，解析速度快巫财，占內存少

DOM消耗內存 盗似；先把xml文檔都讀到內存中，然后在訪問各個節(jié)點

20平项、Dalvik和ART的區(qū)別：

在Dalvik下赫舒，應用每次運行時都會執(zhí)行轉換機器碼操作悍及；

在ART下，應用在第一次安裝的時候接癌，字節(jié)碼就會預先轉換成機器碼

優(yōu)點：運行快缺點：1.機器碼占用的存儲空間更大 2.應用的安裝時間會變長

21心赶、JNI（Java Native Interface 本地接口語言）的操作步驟：

·編寫帶有native聲明的方法的java類

·使用javac命令編譯所編寫的java類

·使用javah 對java類生成擴展名為h的頭文件

·使用C/C++（或者其他編程想語言）實現(xiàn)本地方法

·將C/C++編寫的文件生成動態(tài)連接庫

21 、IntentService

IntentService缺猛，可以看做是Service和HandlerThread的結合處理耗時操作缨叫。當任務執(zhí)行完后，IntentService 會自動停止荔燎，不需要我們去手動結束耻姥。

22、多線程斷點下載? 實現(xiàn)過程

①有咨、首先使用HttpURLConnection.getContentLength()獲取下載文件的長度琐簇，然后設置本地文件的長度。

②座享、根據(jù)下載文件長度和線程數(shù)計算每條線程下載的數(shù)據(jù)長度和下載的位置婉商。

③、使用HTTP的請求頭字段Range指定每條線程從文件的什么位置開始下載渣叛，到什么位置下載結束丈秩。

④、保存文件诗箍。使用RandomAccessFile類指定每條線程從本地文件的什么位置開始寫入數(shù)據(jù)癣籽。

23、 線程池

1.避免線程頻繁創(chuàng)建消毀滤祖。多個線程頻繁地銷毀筷狼，會頻繁地調用GC機制，這會使性能降低匠童。

2.避免系統(tǒng)資源緊張埂材。多個線程頻繁的創(chuàng)建會占用大量的資源，缺乏統(tǒng)一的管理汤求，在資源競爭時容易出現(xiàn)問題造成界面卡頓俏险。

3.更好地管理線程。以下載功能為例扬绪，可以很好的控制下載任務：下載數(shù)竖独，下載順序隊列等。

newFixedThreadPool（固定數(shù)量線程池）：數(shù)量固定挤牛，適用于為了滿足資源管理的需求莹痢，而限制當前線程數(shù)，它適用于負載比較重的服務器。優(yōu)點：更快的響應外界請求

newCachedThreadPool：（緩存線程池）線程數(shù)非常大竞膳，任何任務都會被立即執(zhí)行航瞭，比較適合執(zhí)行大量的耗時較少的任務.

newSingleThreadExecutor（單利線程池）：保證順序地執(zhí)行各個任務；并且不會有多個線程活動坦辟，不需要處理線程同步的問題

newScheduledThreadPool：（定時線程池）主要在給定的延遲之后運行任務刊侯，或者定期執(zhí)行任務，例如定時輪詢數(shù)據(jù)庫中的表的數(shù)據(jù)

24锉走、java 基本設計模式

? 23種模式： 設計模式主要分三個類型:創(chuàng)建型滨彻、結構型和行為型。

其中創(chuàng)建型有：

? 1挠日、單例模式：單例模式確保某一個類只有一個實例疮绷，而且自行實例化并向整個系統(tǒng)提供這個實例單例模式；

? 2嚣潜、觀察者模式：觀察者模式屬于行為型模式冬骚，定義對象間的一種一對多的依賴關系，當一個對象的狀態(tài)發(fā)生改變時懂算，所有依賴于它的對象都得到通知并被自動更新只冻。

? 事件通知也是觀察者模式。

? 3计技、工廠模式：定義了一個創(chuàng)建對象的接口,讓子類來決定具體實例化哪一個類

?4喜德、適配器模式：ListView或GridView的Adapter 簡介：不同的數(shù)據(jù)提供者使用一個適配器來向一個相同的客戶提供服務。

?5垮媒、建造者模式：AlertDialog.Builder 簡介：可以分步地構造每一部分舍悯。

?6、命令模式：Handler.post后Handler.handleMessage 簡介：把請求封裝成一個對象發(fā)送出去睡雇，方便定制萌衬、排隊、取消它抱。

25秕豫、Android 網(wǎng)絡通信機制?

Android平臺有三種網(wǎng)絡接口可以使用，他們分別是：java.net.*(標準Java接口)观蓄、Org.apache接口和Android.net.*(Android網(wǎng)絡接口)混移。

1，java.net.* (標準java接口) HttpURLConnection 獲取鏈接信息,

2侮穿，Apache接口 ：HttpClient歌径。它是一個開源項目，功能豐富.

3亲茅，Android網(wǎng)絡接口 : Socket 套接字通信

26沮脖、handler機制的原理

　　andriod提供了 Handler 和 Looper 來滿足線程間的通信.

　　1)Looper: 一個線程可以產生一個Looper對象金矛，由它來管理此線程里的Message Queue(消息隊列)。

　　2)Handler: Handler 先進先出原則,構造Handler對象來與Looper溝通勺届，以便push新消息到Message Queue里;或者接收Looper從Message Queue取出)所送來的消息。

　　3)Message Queue(消息隊列):用來存放線程放入的消息娶耍。

　　4)線程：UI thread 通常就是main thread免姿，而Android啟動程序時會替它建立一個Message Queue。

27榕酒、多渠道打包

美團的方案胚膊，直接解壓apk，解壓后的根目錄會有一個META-INF目錄想鹰，在目錄下添加不同渠道的空文件唯一標識紊婉，類似 channel_xxx 的空文件, 在Java代碼中解析這個文件名獲取市場xxx即可

28、SurfaceView和view的區(qū)別

SurfaceView中采用了雙緩沖機制辑舷，保證了UI界面的流暢性喻犁，同時SurfaceView不在主線程中繪制，而是另開辟一個線程去繪制何缓，所以它不妨礙UI線程肢础；

SurfaceView繼承于View，他和View主要有以下三點區(qū)別：

（1）SurfaceView底層采用雙緩沖機制碌廓，View沒有传轰；

（2）SurfaceView適用與被動的更新，如頻繁的刷新谷婆，view主要適用于主動更新

（3）SurfaceView在子線程中刷新UI慨蛙，view會在主線程中去更新；

29Serializable與Parcable的區(qū)別

為了保存對象的字節(jié)序列到本地文件里纪挎，在網(wǎng)絡中傳遞對象需要做序列化處理

Serializable Java 在硬盤上讀寫, 讀寫過程中有大量臨時變量的生成期贫，會頻繁GC，效率低廷区。

Parcelable Android 在內存中讀寫唯灵，效率高 ，對象不能保存到磁盤中

30隙轻、Devik 進程埠帕，linux 進程，線程的區(qū)別

Dalvik進程玖绿。每一個android app都會獨立占用一個dvm虛擬機敛瓷，運行在linux系統(tǒng)中。

所以dalvik進程和linux進程是可以理解為一個概念斑匪。一個進程可以包含多個線程運行呐籽。

31、Android 程序運行時權限與文件系統(tǒng)權限的區(qū)別

文件的系統(tǒng)權限是由linux系統(tǒng)規(guī)定的，只讀狡蝶，讀寫等庶橱。

運行時權限，是對于某個系統(tǒng)上的app的訪問權限贪惹，允許苏章，拒絕，詢問奏瞬。該功能可以防止非法的程序訪問敏感的信息枫绅。

?32、ArrayMap和HashMap的對比

1硼端、HashMap重新創(chuàng)建對象并淋，開銷很大。ArrayMap用的是copy數(shù)據(jù)珍昨，所以效率相對要高县耽。

2、ArrayMap提供了數(shù)組收縮的功能曼尊，在clear或remove后酬诀，會重新收縮數(shù)組，是否空間

?33骆撇、HashMap和HashTable的區(qū)別

HashMap不是線程安全的瞒御，效率高一點、方法不是Synchronize的要提供外同步神郊。

hashtable是肴裙，線程安全，不允許有null的鍵和值涌乳，效率稍低蜻懦，方法是是Synchronize的。/

34夕晓、HashMap與HashSet的區(qū)別

hashMap:HashMap實現(xiàn)了Map接口,HashMap儲存鍵值對,使用put()方法將元素放入map中,HashSet實現(xiàn)了Set接口宛乃，HashSet僅僅存儲對象，使用add()方法將元素放入set中,HashSet較HashMap來說比較慢

35蒸辆、ArrayList和LinkedList的區(qū)別

ArrayList是線程不安全征炼，基于數(shù)組實現(xiàn)的

LinkedList是基于雙鏈表實現(xiàn)的;

（1）如果應用程序對各個索引位置的元素進行大量的存取或刪除操作，ArrayList對象要遠優(yōu)于LinkedList對象躬贡；

?( 2 ) 如果應用程序主要是對列表進行循環(huán)谆奥，并且循環(huán)時候進行插入或者刪除操作，LinkedList對象要遠優(yōu)于ArrayList對象拂玻；

36酸些、數(shù)組和鏈表的區(qū)別

數(shù)組：將元素在內存中連續(xù)存儲,隨機訪問性強,查找速度快,數(shù)組大小固定,不能動態(tài)拓展,插入和刪除效率低

鏈表:是動態(tài)申請內存空間,大小沒有固定宰译，拓展很靈活,插入刪除速度快,不能隨機查找，必須遍歷魄懂，查找效率低

?37沿侈、Rxjava:響應式編程主要采用觀察者模式進行開發(fā)，即觀察者訂閱可觀察的市栗±呒幔可觀察的（Observable）通過調用觀察者的方法來發(fā)射事件給它的所有觀察者（observer）

?38、自定義View的基本流程

①.自定義View的屬性 編寫attr.xml文件

②.在layout布局文件中引用肃廓，同時引用命名空間

③.在View的構造方法中獲得我們自定義的屬性 ，在自定義控件中進行讀然迕凇（構造方法拿到attr.xml文件值）

④.重寫onMesure

⑥.重寫onDraw

39盲赊、如何優(yōu)化ListView

①Item布局，層級越少越好敷扫，使用hierarchyview工具查看優(yōu)化哀蘑。

②復用convertView

③使用ViewHolder

④item中有圖片時，異步加載

⑤快速滑動時葵第，不加載圖片

⑥item中有圖片時绘迁，應對圖片進行適當壓縮

40、設備橫豎屏切換的時候卒密，生面周期的變化

不設置Activity的android:configChanges時缀台，切屏會重新調用各個生命周期，切橫屏時會執(zhí)行一次哮奇，切豎屏時會執(zhí)行兩次

設置Activity的android:configChanges=”orientation”時膛腐，切屏還是會重新調用各個生命周期，切橫鼎俘、豎屏時只會執(zhí)行一次

設置Activity的android:configChanges=”orientation|keyboardHidden”時哲身，切屏不會重新調用各個生命周期，只會執(zhí)行onConfigurationChanged方法

41贸伐、沉浸式實現(xiàn)：

?Android4.4（API 19）實現(xiàn)方式為: 通過FLAG_TRANSLUCENT_STATUS設置狀態(tài)欄為透明并且為全屏模式勘天， 然后通過添加一個與StatusBar 一樣大小的View，將View 的 background 設置為我們想要的顏色捉邢，從而來實現(xiàn)沉浸式脯丝。

Android 5.0（API 21）以上版本： 在Android 5.0的時候，加入了一個重要的屬性和方法 android:statusBarColor （對應方法為 setStatusBarColor）歌逢，直接繪制狀態(tài)欄的背景巾钉。

?Android 6.0是改變狀態(tài)欄字體顏色： 獲取DecorView 包含狀態(tài)欄和布局的contentView因此對獲取 decorView 設置一些沉浸式模式的UI Flag View decorView=getWindow().getDecorView(); intoption=View.SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN|View.SYSTEM_UI_FLAG_LAYOUT_STABLE; decorView.setSystemUiVisibility(option); getWindow().setStatusBarColor(Color.TRANSPARENT)