Android 一些面試問題收集

前言

因為最近換工作，所以需要面試，但是面試了3家只有一個offer，只是可能因為工資問題最終還是需要繼續面試，同時感覺每次面試都不做任何準備，不看面試題，不去溫習一下書本，感覺臨場表現可能的確不行吧，所以本文主要記錄在面試中被遇到的一些問題和一些我覺得的答案，以做記錄，不過通過三次面試感覺有時候面試多點也好，畢竟一般公司都會問你公司所在乎的問題（反正我之前面試別人就是這樣），所以很多時候吧面試的問題拿來學習，也是一種不錯的辦法，同時也請教一下，怎么樣才能增加面試機會啊，投了幾天簡歷了，才收到4個面試通知（其中2個直接郵件通知，因為預約的時間相同，所以只去了一家），在boss直聘上問也沒人回答，甚至看都不看，這是什么鬼？

正文

好了下面就是面試中遇到的一些問題了

1.網絡優化

問題：有沒有做過網絡優化，比如信號不好和手機網絡狀態頻繁變化的情況下做了什么優化 答案：

底層優化：

1、 IP訪問 通過IP和域名結合訪問方法，因為域名解析也需要一定的時間，所以直接通過IP訪問會比域名要更快，當然因為IP隨時可能會變，所以我們存儲的IP是一個動態IP，一旦IP發生改變請求失敗時，就通過解析域名獲取新的IP，通過新的IP來訪問

2、 鏈接復用 可以節省連接建立時間，如開啟 keep-alive，Http 1.1 默認啟動了 keep-alive，對于 Android 來說默認情況下 HttpURLConnection 和 HttpClient 都開啟了 keep-alive，檢查keep-alive是否開業也很簡單，直接用抓包軟件對請求抓包，如果請求頭是否有Connection: keep-alive，如果有則說明已經開啟了

3、 請求合并 簡單來說越少請求接口越好，如果一個接口能把相關必要的數據一起獲取下來，就不用別個數據去調用一個接口了，我之前是試過一個首頁調用了8個接口才把數據完全拿到，雖然這樣對于接口本身來說業務分離的比較好，但是對于客戶端來說這樣的設計明顯不合理，而且多次請求也會增加服務器壓力

4、 請求壓縮

a)對于 POST 請求，Body 和接口返回的數據可以做 Gzip 壓縮,當然開啟了Gzip可能需要服務器配合

b)請求頭壓縮，具體可以搜索SPDY ，因為我對這一塊也不是很了解

應用層優化

1、 請求失敗重復請求 簡單來說就是給定一個可以出錯的次數，如果在指定次數中都失敗了，那么則確定請求失敗，當然要注意的幾點就是一定要給定合理的鏈接超時限制，否則如果超時時間過短，網速慢的情況下在多次請求都到達不了，但是太長，網速慢的請求下就要等很久才能有結果反饋（主要是針對失敗的反饋）

2、 網絡請求失敗的處理 主要是針對網絡請求失敗做一些處理，比如顯示網絡請求失敗的界面，點擊可以重試

3、 緩存 對于及時性不是很高或者沒有網絡的情況下，可以使用緩存來減少網絡訪問次數和加快數據展示速度，當然值得注意的是，如果界面對數據實時性要求特別高，還是不建議用緩存，如支付等界面

4、 斷點 對于下載來說，處理好斷點下載是很必要的，畢竟移動網絡并不穩定，所以如果能斷點下載，對于流量和電量都是一個很好的優化，同時上傳也可以做斷點上傳，不過一定要確定好的就是被上傳的源文件未被修改，同時斷點上傳也需要服務器的支持

2.電量優化

首先分析APP真正耗電的地方：Android手機大量的電主要消耗在網絡、傳感器，當然如果是游戲程序還主要消耗在CPU和GPU上面，當然我們只是開發APP應用，所以一般來說CPU和GPU不會消耗過多電量，除非你用了需要很大計算量的自定義控件（我曾經寫了一個自定義控件，在OnGlobalLayoutListener中沒有異常監聽，而我的控件又放在ListView中，導致此監聽一直被執行，同時適配器也一直調用getItemCount的方法，雖然沒有調用getView，但是一直讓CPU處理計算狀態，感覺肯定會加大電量消耗），所以我們主要從這幾個方面來入手解決電量優化的問題

1、 網絡優化 這個可以直接參考上面的網絡優化，當然也有一個問題，那就是我們還需要在請求網絡的時候判斷網絡的狀態，如果網絡是不可用狀態，就不用再去發起網絡請求了

2、 服務優化 很多程序會有一個服務定時去更新服務器數據，一般來說是用開啟一個線程無限循環的去更新，然后休眠線程，到時在去開啟，當然如果是每次間隔比較長，那么就可以通過使用AlarmManager來實現定時調用線程，因為AlarmManager是系統原生底層的東西，消耗是非常少的。不過如果本身間隔很短，比如10幾秒，那么就不用使用AlarmManager了，畢竟使用AlarmManager本身也會帶來一定消耗，就像你為了防止UI線程卡頓啟動另外一個線程來執行幾十毫秒的操作，可能你啟動線程的時候，這個操作就已經完成了，所以這個一定要根據自己的需求，來確定到底使用哪種辦法

3、 內存優化 這個就很簡單了，主要是針對一些大內存的優化，比如bitmap、文件流、游標這些用完就釋放掉

4、 傳感器優化 如果APP對定位要求不是特別高，那么則可以使用wifi和移動網絡cell定位即可，同時一般APP只需要簡單定位，定位完成就可以關閉掉定位了，其他傳感器也同理。

3.解決小米、魅族、華為等手機從系統層攔截推送

這個我還沒有想出什么好的答案。。。

3.屏幕適配

1、 使用百分比 使用百分比布局很多時候能解決一些簡單的布局適配

2、 layout文件夾 主要是建立layout文件夾，可以為平板和手機分別建立布局，也可以用來適配橫豎屏

3、 values文件夾 可以為不同尺寸和不同分辨率不同屏幕密度來建立文件夾，屏幕適配的主要方式

4、 9.png 可以拉伸的圖片文件

5、 自定義控件 有時候我們只能確定一個控件的寬度，但是高度卻是按照一定比例出來的，這時候可以考慮用自定義控件實現，通過比例計算出高度，因為如果在布局中寫死寬高還需要為每個屏幕來進行適配，而在代碼中獲取寬度來計算高度也有一定問題畢竟控件的寬高好繪制好了才能獲取，當獲取成功后再修改高度，會造成閃爍，所以通過自定義控件在onMeasure中計算并修改就不會有閃爍問題，而且性能會更好

6、 使用不同的圖片 針對不同的屏幕密度使用不同的圖標

4.Handler機制

handler機制的4個主要組件

1、 Looper 一個線程可以產生一個Looper對象，用它來管理此線程中的消息隊列(MessageQueue)，無限循環從消息隊列中獲取消息進行處理，如果沒有消息則進入等待狀態

2、 handler對象 與Looper進行溝通和處理消息的對象，可以把消息push進消息隊列，同時一旦消息的執行到了，Looper會從消息隊列中取出消息，先判斷消息是不是底層（ndk）消息，如果是就交給底層實現，如果不是則根據消息的屬性獲取發送的handler，調用handler的handlerMessage方法，處理消息

3、 MessageQueue 消息隊列，用來存放需要處理的消息，保存在ThreadLocal中，所以只有線程被銷毀時，才會釋放

4、 Thread 可以是UI線程，UI線程默認會初始化好MessageQueue，也可以是其他線程，除了HandlerThread已經實現好之外，其他線程需要手動調用Looper.prepare方法手動初始化好，然后調用Looper.loop循環獲取消息

5.布局優化

1、 include 把多個界面相同的布局抽離出來一個布局文件，使用include標簽導入要引用的界面布局中，這樣能加快很多開發速度， 注意 這里主要是針對開發速度有加快效果，對運行速度沒有什么卵用

2、 viewstub viewstub作用跟include差不多，都是引入一個布局，不同點在于viewstub主要導入一開始并不會顯示的布局，只會在特定情況下顯示的布局，比如網絡連接失敗，顯示的提示界面，所以一開始viewstub引入的布局是不會解析的，需要解析時在java中通過(ViewStub)findViewById(id)找到ViewStub，通過stub.inflate()展開ViewStub，然后得到子View

3、 merge 在使用了include后可能導致布局嵌套過多，多余不必要的layout節點，從而導致解析變慢，當被引用的布局能確定引用布局引用處的父布局，同時也沒有margin和padding等屬性時，可以使用merge減少一層布局嵌套

4、 減少嵌套層次 其實只要不怕麻煩，RelativeLayout可以減少很多布局嵌套，當然也要在RelativeLayout和LinearLayout做出取舍，有些簡單的布局，只有2層的話那么用RelativeLayout和LinearLayout的層次是一樣的，所以要根據具體情況做出取舍

5、 減少控件使用 據我所知，差不多的控件都是支持上下左右圖標的，所以如果出現左邊一個圖標中間文本右邊圖標的控件，可以使用一個TextView就能實現，而不用使用一個ViewGroup，然后再用2個圖標一個文本控件，一個控件也有劣勢，那就是適配，因為圖標的大小不好控制

6、 用SurfaceView或TextureView代替普通View 如果是有需要大量繪制的控件，可以使用SurfaceView和TextureView來代替，因為這2個控件是在非UI線程進行繪制的

 

來自：http://www.raye.wang/2016/09/13/android-yi-xie-mian-shi-wen-ti-shou-ji/