摘要
“基礎 Android 知識掌握的不錯，學習能力也不錯。但是基礎知識部分比較薄弱，有些概念和邏輯掌握不清。” 感謝春林的這句話。
- MVC，MVP 和 MVVM
- 架構的定義
- Volley相關
- 推送心跳包是TCP包還是UDP包或者HTTP包
- ARGB_8888佔用記憶體大小
- Activity中類似onCreate、onStart運用了哪種設計模式，優點是什麼
- HashMap的底層實現
- Atomic、volatile、synchronized區別
- 其他
MVC，MVP 和 MVVM
- MVC 通訊方式，環形方式：
1、View 傳送指令到 Controller
2、Controller 起到不同層面間的組織作用，用於控制應用程式的流程。它處理事件並作出響應。“事件”包括使用者的行為和資料 Model 上的改變。
3、Model 將新的資料傳送到 View，使用者得到反饋
所有通訊都是單向的。
- MVP 通訊方式：
1、各部分之間的通訊，都是雙向的。
2、View 與 Model 不發生聯絡，都通過 Presenter 傳遞。
3、View 非常薄，不部署任何業務邏輯，稱為”被動檢視”（Passive View），即沒有任何主動性，而 Presenter非常厚，所有邏輯都部署在那裡。
- MVVM 模式是 MVP 的升級：
基本上與 MVP 模式完全一致。唯一的區別是，它採用雙向繫結：View的變動，自動反映在 ViewModel，反之亦然。
(以上內容取自：http://www.ruanyifeng.com/blog/2015/02/mvcmvp_mvvm.html)
我們針對業務模型，建立的資料結構和相關的類，就可以理解為AndroidApp 的 Model，Model 是與 View 無關，而與業務相關的，例如資料庫讀取資料，應該是屬於model層的事情。（感謝@Xander的講解）
我的猜想：
至於為什麼我們通常直接去在 Activity 中去寫資料庫資料讀取，我的猜想是因為簡單。試想，如果是為了規範，首先定義一個getDataFromDB()的介面，再寫個類實現getDataFromDB()方法，以後如果改了請求資料所用的方法，直接改寫實現類，聽起來確實不錯，可是僅僅是為了從資料庫讀點資料，額外新增了至少兩個類檔案真的有意義嗎。
當然網路請求，是屬於業務邏輯層C層。
MVP中 Presenter 真正需要處理的並非業務邏輯，而應該是檢視邏輯。業務邏輯應該是檢視無關的，可以是單獨的一個類中，也可以是在P中。
P與V是一對多關係
EventBus應該作用於P層，在P層傳送，在P層接收。
MVVM中，M層改變並不是直接改變V層，而是通過VM層去改變V層。M與V依舊是不直接操作的。
相關介紹：http://www.tianmaying.com/tutorial/AndroidMVC
架構的定義
有關軟體整體結構與元件的抽象描述，用於指導大型軟體系統各個方面的設計。
總結一下，就是一整個軟體工程專案中的骨架，是一種巨集觀的規劃。
Volley相關
Volley的磁碟快取
在面試的時候，聊到 Volley 請求到網路的資料快取。當時說到是 Volley 會將每次通過網路請求到的資料，採用FileOutputStream，寫入到本地的檔案中。
那麼問題來了：這個快取檔案，是宣告在一個SD卡資料夾中的(也可以是getCacheFile())。如果不停的請求網路資料，這個快取資料夾將無限制的增大，最終達到SD卡容量時，會發生無法寫入的異常(因為儲存空間滿了)。
這個問題的確以前沒有想到，當時也沒說出怎麼回事。回家了趕緊又看了看程式碼才知道，原來 Volley 考慮過這個問題(汗!想想也是)
翻看程式碼DiskBasedCache#pruneIfNeeded()
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
private void pruneIfNeeded(int neededSpace) { if ((mTotalSize + neededSpace) mMaxCacheSizeInBytes) { return; } long before = mTotalSize; int prunedFiles = 0; long startTime = SystemClock.elapsedRealtime(); IteratorMap.EntryString, CacheHeader>> iterator = mEntries.entrySet().iterator(); while (iterator.hasNext()) { Map.EntryString, CacheHeader> entry = iterator.next(); CacheHeader e = entry.getValue(); boolean deleted = getFileForKey(e.key).delete(); if (deleted) { mTotalSize -= e.size; } else { //print log } iterator.remove(); prunedFiles++; if ((mTotalSize + neededSpace) mMaxCacheSizeInBytes * HYSTERESIS_FACTOR) { break; } } } |
其中mMaxCacheSizeInBytes是構造方法傳入的一個快取資料夾的大小，如果不傳預設是5M的大小。
通過這個方法可以發現，每當被呼叫時會傳入一個neededSpace，也就是需要申請的磁碟大小(即要新快取的那個檔案所需大小)。首先會判斷如果這個neededSpace申請成功以後是否會超過最大可用容量，如果會超過，則通過遍歷本地已經儲存的快取檔案的header(header中包含了快取檔案的快取有效期、佔用大小等資訊)去刪除檔案，直到可用容量不大於宣告的快取資料夾的大小。
其中HYSTERESIS_FACTOR是一個值為0.9的常量，應該是為了防止誤差的存在吧(我猜的)。
Volley快取命中率的優化
如果讓你去設計Volley的快取功能，你要如何增大它的命中率。可惜了，如果上面的快取功能是昨天看的，今天的面試這個問題就能說出來了。
還是上面的程式碼，在快取內容可能超過快取資料夾的大小時，刪除的邏輯是直接遍歷header刪除。這個時候刪除的檔案有可能是我們上一次請求時剛剛儲存下來的，屁股都還沒坐穩呢，現在立即刪掉，有點捨不得啊。
如果遍歷的時候，判斷一下，首先刪除超過快取有效期的(過期快取)，其次按照LRU演算法，刪除最久未使用的，豈不是更合適？
Volley快取檔名的計算
這個是我一直沒弄懂的問題。
如下程式碼：
|
1 2 3 4 5 6 |
private String getFilenameForKey(String key) { int firstHalfLength = key.length() / 2; String localFilename = String.valueOf(key.substring(0, firstHalfLength).hashCode()); localFilename += String.valueOf(key.substring(firstHalfLength).hashCode()); return localFilename; } |
為什麼會要把一個key分成兩部分，分別求hashCode，最後又做拼接。
這個問題之前在stackoverflow上問過 #連結
原諒我，別人的回答我最初並沒有看懂。直到最近被問到，如果讓你設計一個HashMap，如何避免value被覆蓋，我才想到原因。
先來看一下 String#hashCode() 的實現：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
@Override public int hashCode() { int hash = hashCode; if (hash == 0) { if (count == 0) { return 0; } final int end = count + offset; final char[] chars = value; for (int i = offset; i end; ++i) { hash = 31*hash + chars[i]; } hashCode = hash; } return hash; } |
從上面的實現可以看到，String的hashcode是根據字元陣列中每個位置的字母的int值再加上上次hash值乘以31，這種演算法求出來的，至於為什麼是31，我也不清楚。
但是可以肯定一點，hashcode並不是唯一的。不信你執行下面這兩個輸出：
|
1 2 |
System.out.print("======" + "vFrKiaNHfF7t[9::E[XsX?L7xPp3DZSteIZvdRT8CX:w6d;v.hashCode()); System.out.print("======" + "hI4pFxGOfS@suhVUd:mTo_begImJPB@Fl[6WJ?ai=RXfIx^=Aix@9M;;?Vdj_Zsi".hashCode()); |
這兩個字串是根據hashcode的演算法逆向出來的，他們的hashcode都是12345。逆向演算法請見這裡
再回到我們的問題，為什麼會要把一個key分成兩部分。現在可以肯定的答出，目的是為了儘可能避免hashcode重複造成的檔名重複(求兩次hash兩次都與另一個url重複的概率總要比一次重複的概率小吧)。
順帶再提一點，就像上面說的，概率小並不代表不存在。但是Java計算hashcode的速度是很快的，應該是在效率和安全性上取捨的結果吧。
推送心跳包是TCP包還是UDP包或者HTTP包
其實聊起這個問題是因為最近看到 @睡不著起不來的萬宵 同學寫的一篇文章《Android推送技術研究》結果就產生了這個沒回答出來的問題(媽蛋，自己給自己挖坑 – -)
最後看了這篇文章(好像是轉的，沒找到原地址)android 心跳的分析
原來心跳包的實現是呼叫了socket.sendUrgentData(0xFF)這句程式碼實現的，所以，當然是TCP包。
ARGB_8888佔用記憶體大小
首先說說本題的答案，是4byte，即ARGB各佔用8個位元來描述。當時回答錯了，詳細解答看這裡你的 Bitmap 究竟佔多大記憶體
但是——
這個問題引出了一個大大的鬧劇，請聽我慢慢道來。
不知道怎麼就聊到 Bitmap 壓縮上了，他說他們的Bitmap居然都是不壓縮的
還是直接甩程式碼吧。。。。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
public static Bitmap create(byte[] bytes, int maxWidth, int maxHeight) { //上面的省略了 option.inJustDecodeBounds = true; BitmapFactory.decodeByteArray(bytes, 0, bytes.length, option); int actualWidth = option.outWidth; int actualHeight = option.outHeight; // 計算出圖片應該顯示的寬高 int desiredWidth = getResizedDimension(maxWidth, maxHeight, actualWidth, actualHeight); int desiredHeight = getResizedDimension(maxHeight, maxWidth, actualHeight, actualWidth); option.inJustDecodeBounds = false; option.inSampleSize = findBestSampleSize(actualWidth, actualHeight, desiredWidth, desiredHeight); Bitmap tempBitmap = BitmapFactory.decodeByteArray(bytes, 0, bytes.length, option); // 做縮放 if (tempBitmap != null & (tempBitmap.getWidth() > desiredWidth || tempBitmap .getHeight() > desiredHeight)) { bitmap = Bitmap.createScaledBitmap(tempBitmap, desiredWidth, desiredHeight, true); tempBitmap.recycle(); } else { bitmap = tempBitmap; } } return bitmap; } |
你這麼做，decodeByteArray兩次不是更佔記憶體嗎？第一次設定inJustDecodeBounds = true 時候是不佔記憶體的，因為返回的是null
一臉不相信我的說：噢，這地方我下去再看看。嚇得我回來了以後趕緊又看了看，還好沒有記錯，見原始碼註釋
|
1 2 3 4 5 6 |
/** * If set to true, the decoder will return null (no bitmap), but * the out... fields will still be set, allowing the caller to query * the bitmap without having to allocate the memory for its pixels. */ public boolean inJustDecodeBounds; |
Activity中類似onCreate、onStart運用了哪種設計模式，優點是什麼
這個回答的太多了，我當時說的是代理模式，因為AppCompatActivity中的確是使用的代理模式。這一點還要感謝@程式碼家 當時說讓我看看AppCompatDelegate類的設計。其主要目的就是通過使用組合來替代繼承，降低了耦合。
不過回家後再想一想，對方想聽到的應該是模板方法模式吧。在父類中實現一個演算法不變的部分，並將可變的行為留給子類來實現。生命週期方法原本就是在基類中做出了Activity不同狀態時回撥的一系列方法，而這些方法具體需要做的可變部分交給子類去完成。
HashMap的底層實現
HashMap內部是通過陣列實現的，誒，大學時候資料結構有講過啊，都忘記了。根據hash演算法，求出當前key應該存放在陣列的那個index處，如果有值了，則存在相鄰的下一個位置。
根據如果自己實現HashMap如何防止value覆蓋。同上面 Volley 中講到的。
Atomic、volatile、synchronized區別
面Java基礎的時候遇上了這個問題，說如果只有一個i++;的時候，volatile和synchronized能否互換。當時也不知道，感覺volatile作為修飾變數的時候，變數自加會出現加到一半發生執行緒排程。再看看當時蒙對了。
volatile 可以保證在一個執行緒的工作記憶體中修改了該變數的值，該變數的值立即能回顯到主記憶體中，從而保證所有的執行緒看到這個變數的值是一致的。但是有個前提，因為它不具有操作的原子性，也就是它不適合在對該變數的寫操作依賴於變數本身自己。就比如i++、i+=1;這種。但是可以改為num=i+1;如果i是一個 volatile 型別，那麼num就是安全的，總之就是不能作用於自身。
synchronized是基於程式碼塊的，只要包含在synchronized塊中，就是執行緒安全的。
既然都說了執行緒安全，就多瞭解幾個：
AtomicInteger，一個輕量級的synchronized。使用的並不是同步程式碼塊，而是Lock-Free演算法(我也不懂，看程式碼就是一個死迴圈呼叫了底層的比較方法直到相同後才退出迴圈)。最終的結果就是在高併發的時候，或者說競爭激烈的時候效率比synchronized高一些。
ThreadLocal，執行緒中私有資料。主要用於執行緒改變內部的資料時不影響其他執行緒，使用時需要注意static。詳細分析見這篇文章 。
再補一個，才學到的。利用clone()方法，如果是一個類的多個物件想共用物件內部的一個變數，而又不想這個變數static，可以使用淺複製方式。(檢視設計模式原型模式)
其他
做內部庫設計時，最重要的考慮是jar的成本，方法數、體積。
設計模式不應該是去記憶，而應該是用的時候自然而然的用上。
3月11日更新
面試真的是有夠煩的，因為題目是隨機的，而知識是無窮的。直到被很多答案都是沒有標準的。就好像上面提到的 MV* ，也許到現在上面的理解依舊有問題，但是我覺得架構是死的，而最合適的才是最好的。
但是有一點，面試也是一種學習，至少它能讓你知道你的薄弱點在哪。