Android開發者面試總結

前言

今天去餓了麼面試，總體來說很失望，沒搞明白對方所問這些問題的重點在哪裡（當時腦袋一片空白），個人覺得面試官自己也描述不清楚，那麼下面是自己回去後總結的問題以及自己深思熟慮後想到的一些知識點。之前自己也面試過很多Android開發者，但與今天面試的可能不太一樣，關注點不一樣，以前換做是我的話，主要問一些功能實現。（PS：本人不善言談，其次並不是不懂，而是有些東西在心裡，但就是不知道如何用語言來表達，或許這也是我這次面試失敗的原因）

65K限制問題

65K限制問題說白了在日常開發中沒有碰到過，所屬部門不同擔任的責任也不盡相同，現在網上解決方案比較多，像multidex之類的，或者在Project.proterty中加“dex.force.jumbo=true”配置（2.3系統的機器上很容易出現INSTALL_FAILED_DEXOPT異常），為什麼會產出65K以及2.3系統的問題，我想底下的答案已經是很好的闡述了：

1、Android系統中，一個Dex文件中存儲方法id用的是short類型數據，所以導致你的dex中方法不能超過65k
2、在2.3系統之前，虛擬機內存只分配了5M

面對65K的問題單純從Android系統的結構上來看，只可遠觀，也就是無法從應用層去修改數據類型，拋開市面上的一些解決方案來說，怎樣盡量避免65K這個天花板呢？面對這個天花板我們只能這樣做：

1、去除無用的jar包，比如第三方的jar包，一些功能能自己拆分出來的，盡量不要使用完整的jar包。
2、可以將屬性設置成public，從而去掉get/set放。
注意：這些只是臨時解決方案，面對一些大公司並不適用。

通過上面的一些預防措施，最後這個天花板還是到來時，這時我們就要請出當前一些主流的解決方案

一種是微信代表的，也就是將功能做成插件，進行動態加載；還有一種就是facebook為代表的分包方案，將一個dex文件進行分割，最後進行動態的加載dex文件。
這兩種方案代表核心思想都是一樣的，但分包方案是將功能拆分成多個dex文件，那麼本身的應用體積並沒有什麼改變，但插件化方案不但能解決天花板問題，還能使應用體積減小。

HashMap

在很早以前使用HashMap，那時用的還給出了一個performance警告，今天被面試到這個HashMap時，不由的想到了之前碰到的這個警告，單從警告上看是建議你使用SparseArray，查看相關資料，SparseArray指的是稀疏數組，它是Android提供的一個工具類，為什麼叫稀疏數組，查看源碼其實和List一樣，只是內部做了矩陣壓縮，減少存儲空間，節約內存，值得指出的是它的查找算法采用的是二分法，從而提高了查找效率。

使用HashMap更占內存，除了使用上面的SparseArray之外，查閱網上資料，我們還可以使用ArrayMap,它內部使用兩個數組進行工作，其中一個數組記錄key hash過後的順序列表，另外一個數組按key的順序記錄Key-Value值，當獲取某個value的時候，ArrayMap會計算輸入key轉換過後的hash值，然後對hash數組使用二分查找法尋找到對應的index，然後我們可以通過這個index在另外一個數組中直接訪問到需要的鍵值對。如果在第二個數組鍵值對中的key和前面輸入的查詢key不一致，那麼就認為是發生了碰撞沖突。為了解決這個問題，我們會以該key為中心點，分別上下展開，逐個去對比查找，直到找到匹配的值，隨著數組中的對象越來越多，查找訪問單個對象的花費也會跟著增長，這是在內存占用與訪問時間之間做權衡交換。

ArrayMap的使用場景：

對象個數的數量級最好是千以內
數據組織形式包含Map結構

如何優化界面

當我聽到面試官問這個問題時，其實我內心是拒絕的，因為我壓根不明白面試官問的重心點在哪裡。

驗證一個界面是否卡頓，歸根到底還是采用了多層次重疊試圖，導致大量的性能問題，為此我們可以通過手機設置的開發者選項，打開Show GPU Overdraw的選項，觀察UI上的Overdraw情況。

vcqxzai5/dfUtqjS5VZpZXfKsdbY0MJvbkRyYXe3vbeoLEFuZHJvaWTPtc2zzt63qLzssuLU2m9uRHJhd8Dvw+a+38zlu+HWtNDQyrLDtLLZ1/ejrM+1zbPO3reovOC/2LKi19S2r9PFu6+jrM7Sw8e/ydLUzai5/WNhbnZhcy5jbGlwUmVjdCgpwLSw79b6z7XNs8q2sfDEx9Cpv8m8+7XEx/jT8qGjzazKsWNsaXBSZWN0t723qLu5v8nS1LDv1vq92tS8Q1BV0+tHUFXXytS0o6zU2mNsaXBSZWN0x/jT8tauzeK1xLvm1sbWuMHutryyu7vhsbvWtNDQo6zEx9Cpsr+31sTayN3U2r7Y0M7H+NPyxNq1xNfpvP6jrMjUyLu74bXDtb275tbGoaM8L3A+DQo8cD6z/cHLY2xpcFJlY3S3vbeo1q7N4qOsztLDx7u5v8nS1Mq508NjYW52YXMucXVpY2tyZWplY3QoKcC0xdC2z8rHt/HDu7rNxLO49r7Y0M7P4L27o6y007b4zPi5/cTH0Km3x77Y0M7H+NPyxNq1xLvm1say2df3oaM8L3A+DQo8cD7Su9Cp0NTE3MnPtcTTxbuvv8nS1LLOv7TS1M/CzsTVwqO6PC9wPg0KPHA+PGEgaHJlZj0="http://hukai.me/android-performance-render/">Android性能優化之渲染篇

對於布局嵌套優化，可以使用include標簽重用layout、使用ViewStub實現View的延遲加載。

Volley與okhttp區別

關於這個問題，先來個總體的介紹。

OkHttp：

OkHttp是一個現代，快速，高效的Http client，支持HTTP/2以及SPDY，它為你做了很多的事情。縱觀一眼OkHttp為你實現的諸多技術如連接池，gziping，緩存等就知道網絡相關的操作是多麼復雜了。OkHttp扮演著傳輸層的角色。
OkHttp使用Okio來大大簡化數據的訪問與存儲，Okio是一個增強 java.io 和 java.nio的庫 。
OkHttp和Okio都是Square團隊開發的。
OkHttp是一個現代，快速，高效的Http client，支持HTTP/2以及SPDY，扮演著傳輸層的角色。

Volley：

Volley是一個簡化網絡任務的庫。他負責處理請求，加載，緩存，線程，同步等問題。它可以處理JSON，圖片，緩存，文本源，支持一定程度的自定義。
Volley是為RPC網絡操作而設計的，適用於短時操作。
Volley默認在Froyo上使用Apache Http stack作為其傳輸層，在Gingerbread及之後的版本上使用HttpURLConnection stack作為傳輸層。原因是在不同的安卓版本中這兩種http stack各自存在一些問題。
Volley可以輕松設置OkHttp作為其傳輸層。
Volley是谷歌開發的。

MVC、MVP、MVVM

面試過程被問到分層處理，常用的是MVC，MVP與MVVM沒用到過，抱著對MVP與MVVM敬畏的心，查閱相關資料，自己也通過案例演示了一遍。

先看看常用的MVC：

采用MVC模式的好處是便於UI界面部分的顯示和業務邏輯，數據處理分開。M層：適合做一些業務邏輯處理，比如數據庫存取操作，網絡操作，復雜的算法，耗時的任務等都在model層處理。 V層：應用層中處理數據顯示的部分，XML布局可以視為V層，顯示Model層的數據結果。 C層：在Android中，Activity處理用戶交互問題，因此可以認為Activity是控制器，Activity讀取V視圖層的數據，控制用戶輸入，並向Model發送數據請求（發起網絡請求等）。

PS：上面所提到的Volley網絡請求框架其實也是遵循著MVC框架的。

為什麼會推出MVP框架，使用MVC導致了Activity承擔的任務和邏輯處理太多，職責不清晰。

MVP：

MPV 是從經典的MVC模式演變過來的，其基本思路都是相通的。其中M是model模型，提供業務數據；P和MVC中的C擔當的角色相似，是Presenter控制者，進行邏輯處理。V是View視圖，顯示數據。MVP與MVC有著一個重大的區別：在MVP中View並不直接使用Model，它們之間的通信是通過Presenter (MVC中的Controller)來進行的，所有的交互都發生在Presenter內部，而在MVC中View會從直接Model中讀取數據而不是通過 Controller。

以下是MVC的框架圖：

以下是MVP的框架圖：

從上面的框架圖可以看出MVC和MVP最大的區別就是 Model和View之間的關系。在MVC框架中，View是可以直接讀取Model模型中的數據的，Model模型數據發生改變是會通知View數據顯示發生相應的改變。而在MVP中Model和View之間的沒有任何聯系，是兩個完全獨立的模塊，當Model模型發生數據改變時，通過Presenter通知View視圖發生相應的UI改變。因此，個人覺得：MVP才是正真的視圖和模型完全分離，也就是Model模型進行業務數據處理和View視圖顯示沒有任何關聯。

MVVM：

目前流行的第三方框架RoboAndroid可以支持MVVM模型。這個各位看官請自行查找相關說明。

寫在最後的話

我自認為自己不是高手，所以我每天不停的查閱資料，學習各方面知識。個人覺得自己屬於創業型開發者，獨自開發一款產品，抗壓比較強，Android這條路還長，面對這條充滿荊棘的路，唯有抱著對編程的熱愛堅持下去。