寫在前面
“基礎 Android 知識掌握的不錯，學習能力也不錯。但是基礎知識部分比較薄弱，有些概念和邏輯掌握不清。” 感謝春林的這句話。
MVC，MVP 和 MVVM
-
MVC 通信方式，環(huán)形方式：
1、View 傳送指令到 Controller
2、Controller 起到不同層面間的組織作用，用于控制應用程序的流程。它處理事件并作出響應?！笆录卑ㄓ脩舻男袨楹蛿?shù)據(jù) Model 上的改變。
3、Model 將新的數(shù)據(jù)發(fā)送到 View，用戶得到反饋
所有通信都是單向的。
1.png
-
MVP 通信方式：
1、各部分之間的通信，都是雙向的。
2、View 與 Model 不發(fā)生聯(lián)系，都通過 Presenter 傳遞。
3、View 非常薄，不部署任何業(yè)務邏輯，稱為"被動視圖"（Passive View），即沒有任何主動性，而 Presenter非常厚，所有邏輯都部署在那里。
2.png
-
MVVM 模式是 MVP 的升級：
基本上與 MVP 模式完全一致。唯一的區(qū)別是，它采用雙向綁定：View的變動，自動反映在 ViewModel，反之亦然。
3.png
(以上內(nèi)容取自：[http://www.ruanyifeng.com/blog/2015/02/mvcmvp_mvvm.html](http://www.ruanyifeng.com/blog/2015/02/mvcmvp_mvvm.html))
我們針對業(yè)務模型，建立的數(shù)據(jù)結構和相關的類，就可以理解為AndroidApp 的 Model，Model 是與 View 無關，而與業(yè)務相關的，例如數(shù)據(jù)庫讀取數(shù)據(jù)，應該是屬于model層的事情。（感謝@Xander的講解）
我的猜想：
至于為什么我們通常直接去在 Activity 中去寫數(shù)據(jù)庫數(shù)據(jù)讀取，我的猜想是因為簡單。試想，如果是為了規(guī)范，首先定義一個getDataFromDB()的接口，再寫個類實現(xiàn)getDataFromDB()方法，以后如果改了請求數(shù)據(jù)所用的方法，直接改寫實現(xiàn)類，聽起來確實不錯，可是僅僅是為了從數(shù)據(jù)庫讀點數(shù)據(jù)，額外添加了至少兩個類文件真的有意義嗎。
當然網(wǎng)絡請求，是屬于業(yè)務邏輯層C層。
MVP中 Presenter 真正需要處理的并非業(yè)務邏輯，而應該是視圖邏輯。業(yè)務邏輯應該是視圖無關的，可以是單獨的一個類中，也可以是在P中。
P與V是一對多關系
EventBus應該作用于P層，在P層發(fā)送，在P層接收。
MVVM中，M層改變并不是直接改變V層，而是通過VM層去改變V層。M與V依舊是不直接操作的。
相關介紹：http://www.tianmaying.com/tutorial/AndroidMVC
架構的定義
有關軟件整體結構與組件的抽象描述，用于指導大型軟件系統(tǒng)各個方面的設計。
總結一下，就是一整個軟件工程項目中的骨架，是一種宏觀的規(guī)劃。
Volley相關
Volley的磁盤緩存
在面試的時候，聊到 Volley 請求到網(wǎng)絡的數(shù)據(jù)緩存。當時說到是 Volley 會將每次通過網(wǎng)絡請求到的數(shù)據(jù)，采用FileOutputStream，寫入到本地的文件中。
那么問題來了：這個緩存文件，是聲明在一個SD卡文件夾中的(也可以是getCacheFile())。如果不停的請求網(wǎng)絡數(shù)據(jù)，這個緩存文件夾將無限制的增大，最終達到SD卡容量時，會發(fā)生無法寫入的異常(因為存儲空間滿了)。
這個問題的確以前沒有想到，當時也沒說出怎么回事?；丶伊粟s緊又看了看代碼才知道，原來 Volley 考慮過這個問題(汗!想想也是)
翻看代碼DiskBasedCache#pruneIfNeeded()
private void pruneIfNeeded(int neededSpace) {
if ((mTotalSize + neededSpace) < mMaxCacheSizeInBytes) {
return;
}
long before = mTotalSize;
int prunedFiles = 0;
long startTime = SystemClock.elapsedRealtime();
Iterator<Map.Entry<String, CacheHeader>> iterator = mEntries.entrySet().iterator();
while (iterator.hasNext()) {
Map.Entry<String, 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的大小。
通過這個方法可以發(fā)現(xiàn)，每當被調(diào)用時會傳入一個neededSpace，也就是需要申請的磁盤大小(即要新緩存的那個文件所需大小)。首先會判斷如果這個neededSpace申請成功以后是否會超過最大可用容量，如果會超過，則通過遍歷本地已經(jīng)保存的緩存文件的header(header中包含了緩存文件的緩存有效期、占用大小等信息)去刪除文件，直到可用容量不大于聲明的緩存文件夾的大小。
其中HYSTERESIS_FACTOR是一個值為0.9的常量，應該是為了防止誤差的存在吧(我猜的)。
Volley緩存命中率的優(yōu)化
如果讓你去設計Volley的緩存功能，你要如何增大它的命中率。
可惜了，如果上面的緩存功能是昨天看的，今天的面試這個問題就能說出來了。
還是上面的代碼，在緩存內(nèi)容可能超過緩存文件夾的大小時，刪除的邏輯是直接遍歷header刪除。這個時候刪除的文件有可能是我們上一次請求時剛剛保存下來的，屁股都還沒坐穩(wěn)呢，現(xiàn)在立即刪掉，有點舍不得啊。
如果遍歷的時候，判斷一下，首先刪除超過緩存有效期的(過期緩存)，其次按照LRU算法，刪除最久未使用的，豈不是更合適？
Volley緩存文件名的計算
這個是我一直沒弄懂的問題。
如下代碼：
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() 的實現(xiàn)：
@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;
}
從上面的實現(xiàn)可以看到，String的hashcode是根據(jù)字符數(shù)組中每個位置的字母的int值再加上上次hash值乘以31，這種算法求出來的，至于為什么是31，我也不清楚。
但是可以肯定一點，hashcode并不是唯一的。不信你運行下面這兩個輸出：
System.out.print("======" + "vFrKiaNHfF7t[9::E[XsX?L7xPp3DZSteIZvdRT8CX:w6d;v<_KZnhsM_^dqoppe".hashCode());
System.out.print("======" + "hI4pFxGOfS@suhVUd:mTo_begImJPB@Fl[6WJ?ai=RXfIx^=Aix@9M;;?Vdj_Zsi".hashCode());
這兩個字符串是根據(jù)hashcode的算法逆向出來的，他們的hashcode都是12345。逆向算法請見這里
再回到我們的問題，為什么會要把一個key分成兩部分?，F(xiàn)在可以肯定的答出，目的是為了盡可能避免hashcode重復造成的文件名重復(求兩次hash兩次都與另一個url重復的概率總要比一次重復的概率小吧)。
順帶再提一點，就像上面說的，概率小并不代表不存在。但是Java計算hashcode的速度是很快的，應該是在效率和安全性上取舍的結果吧。
推送心跳包是TCP包還是UDP包或者HTTP包
其實聊起這個問題是因為最近看到 @睡不著起不來的萬宵 同學寫的一篇文章《Android推送技術研究》結果就產(chǎn)生了這個沒回答出來的問題(媽蛋，自己給自己挖坑 - -)
最后看了這篇文章(好像是轉的，沒找到原地址)android 心跳的分析
原來心跳包的實現(xiàn)是調(diào)用了socket.sendUrgentData(0xFF)這句代碼實現(xiàn)的，所以，當然是TCP包。
ARGB_8888占用內(nèi)存大小
首先說說本題的答案，是4byte，即ARGB各占用8個比特來描述。當時回答錯了，詳細解答看這里你的 Bitmap 究竟占多大內(nèi)存
但是——
這個問題引出了一個大大的鬧劇，請聽我慢慢道來。??????
不知道怎么就聊到 Bitmap 壓縮上了，他說他們的Bitmap居然都是不壓縮的??????
還是直接甩代碼吧。。。。
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兩次不是更占內(nèi)存嗎？??????
第一次設置inJustDecodeBounds = true 時候是不占內(nèi)存的，因為返回的是null
一臉不相信我的說：噢，這地方我下去再看看。
嚇得我回來了以后趕緊又看了看，還好沒有記錯，見源碼注釋
/**
* 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運用了哪種設計模式，優(yōu)點是什么
這個回答的太多了，我當時說的是代理模式，因為AppCompatActivity中的確是使用的代理模式。這一點還要感謝@代碼家 當時說讓我看看AppCompatDelegate類的設計。其主要目的就是通過使用組合來替代繼承，降低了耦合。
不過回家后再想一想，對方想聽到的應該是模板方法模式吧。在父類中實現(xiàn)一個算法不變的部分，并將可變的行為留給子類來實現(xiàn)。生命周期方法原本就是在基類中做出了Activity不同狀態(tài)時回調(diào)的一系列方法，而這些方法具體需要做的可變部分交給子類去完成。
HashMap的底層實現(xiàn)
HashMap內(nèi)部是通過數(shù)組實現(xiàn)的，而數(shù)組的每一位都是Entry的對象，這個Entry實際上是一個鏈表的節(jié)點。誒，大學時候數(shù)據(jù)結構有講過啊，都忘記了。根據(jù)hash算法，求出當前key應該存放在數(shù)組的那個index處，如果有值了，則存在index所在Entry所在鏈表相鄰的下一個位置。
根據(jù)如果自己實現(xiàn)HashMap如何防止value覆蓋。同上面 Volley 中講到的。
Atomic、volatile、synchronized區(qū)別
面Java基礎的時候遇上了這個問題，說如果只有一個i++;的時候，volatile和synchronized能否互換。當時也不知道，感覺volatile作為修飾變量的時候，變量自加會出現(xiàn)加到一半發(fā)生線程調(diào)度。再看看當時蒙對了。
volatile 可以保證在一個線程的工作內(nèi)存中修改了該變量的值，該變量的值立即能回顯到主內(nèi)存中，從而保證所有的線程看到這個變量的值是一致的。但是有個前提，因為它不具有操作的原子性，也就是它不適合在對該變量的寫操作依賴于變量本身自己。就比如i++、i+=1;這種。但是可以改為num=i+1;如果i是一個 volatile 類型，那么num就是安全的，總之就是不能作用于自身。
synchronized是基于代碼塊的，只要包含在synchronized塊中，就是線程安全的。
既然都說了線程安全，就多了解幾個：
AtomicInteger，一個輕量級的synchronized。使用的并不是同步代碼塊，而是Lock-Free算法(我也不懂，看代碼就是一個死循環(huán)調(diào)用了底層的比較方法直到相同后才退出循環(huán))。最終的結果就是在高并發(fā)的時候，或者說競爭激烈的時候效率比synchronized高一些。
ThreadLocal，線程中私有數(shù)據(jù)。主要用于線程改變內(nèi)部的數(shù)據(jù)時不影響其他線程，使用時需要注意static。
詳細分析見這篇文章 。
再補一個，才學到的。利用clone()方法，如果是一個類的多個對象想共用對象內(nèi)部的一個變量，而又不想這個變量static，可以使用淺復制方式。(查看設計模式原型模式)
其他
做內(nèi)部庫設計時，最重要的考慮是jar的成本，方法數(shù)、體積。
設計模式不應該是去記憶，而應該是用的時候自然而然的用上。
面試真的是有夠煩的，因為題目是隨機的，而知識是無窮的。直到被很多答案都是沒有標準的。就好像上面提到的 MV* ，也許到現(xiàn)在上面的理解依舊有問題，但是我覺得架構是死的，而最合適的才是最好的。
但是有一點，面試也是一種學習，至少它能讓你知道你的薄弱點在哪。
小編給大家準備了安卓進階學習資料
加QQ群：4112676
