Android中必須學(xué)習(xí)的七大開源項目本文原創(chuàng)，轉(zhuǎn)載請以鏈接形式注明地址：
http://blog.csdn.net/xiaole0313/article/details/51778103
“基礎(chǔ) Android 知識掌握的不錯，學(xué)習(xí)能力也不錯。但是基礎(chǔ)知識部分比較薄弱，有些概念和邏輯掌握不清。” 感謝春林的這句話。

MVC，MVP 和 MVVM##

MVC 通信方式，環(huán)形方式：
1、View 傳送指令到 Controller
2、Controller 起到不同層面間的組織作用，用于控制應(yīng)用程序的流程。它處理事件并作出響應(yīng)。“事件”包括用戶的行為和數(shù)據(jù) Model 上的改變。

我們針對業(yè)務(wù)模型，建立的數(shù)據(jù)結(jié)構(gòu)和相關(guān)的類，就可以理解為AndroidApp 的 Model，Model 是與 View 無關(guān)，而與業(yè)務(wù)相關(guān)的，例如數(shù)據(jù)庫讀取數(shù)據(jù)，應(yīng)該是屬于model層的事情。（感謝@Xander的講解）我的猜想：
至于為什么我們通常直接去在 Activity 中去寫數(shù)據(jù)庫數(shù)據(jù)讀取，我的猜想是因為簡單。試想，如果是為了規(guī)范，首先定義一個getDataFromDB()的接口，再寫個類實現(xiàn)getDataFromDB()方法，以后如果改了請求數(shù)據(jù)所用的方法，直接改寫實現(xiàn)類，聽起來確實不錯，可是僅僅是為了從數(shù)據(jù)庫讀點數(shù)據(jù)，額外添加了至少兩個類文件真的有意義嗎。當(dāng)然網(wǎng)絡(luò)請求，是屬于業(yè)務(wù)邏輯層C層。

MVP中 Presenter 真正需要處理的并非業(yè)務(wù)邏輯，而應(yīng)該是視圖邏輯。業(yè)務(wù)邏輯應(yīng)該是視圖無關(guān)的，可以是單獨的一個類中，也可以是在P中。P與V是一對多關(guān)系EventBus應(yīng)該作用于P層，在P層發(fā)送，在P層接收。
MVVM中，M層改變并不是直接改變V層，而是通過VM層去改變V層。M與V依舊是不直接操作的。

架構(gòu)的定義##

有關(guān)軟件整體結(jié)構(gòu)與組件的抽象描述，用于指導(dǎo)大型軟件系統(tǒng)各個方面的設(shè)計。總結(jié)一下，就是一整個軟件工程項目中的骨架，是一種宏觀的規(guī)劃。

Volley相關(guān)##

Volley的磁盤緩存##

在面試的時候，聊到 Volley 請求到網(wǎng)絡(luò)的數(shù)據(jù)緩存。當(dāng)時說到是 Volley 會將每次通過網(wǎng)絡(luò)請求到的數(shù)據(jù)，采用FileOutputStream
，寫入到本地的文件中。那么問題來了：這個緩存文件，是聲明在一個SD卡文件夾中的(也可以是getCacheFile())。如果不停的請求網(wǎng)絡(luò)數(shù)據(jù)，這個緩存文件夾將無限制的增大，最終達到SD卡容量時，會發(fā)生無法寫入的異常(因為存儲空間滿了)。這個問題的確以前沒有想到，當(dāng)時也沒說出怎么回事。回家了趕緊又看了看代碼才知道，原來 Volley 考慮過這個問題(汗!想想也是)

翻看代碼DiskBasedCache#pruneIfNeeded()###

private void pruneIfNeeded(int neededSpace) { 
if ((mTotalSize + neededSpace) < mMaxCacheSizeInBytes) { 
return; 
} 
long before = mTotalSize; 
int prunedFiles = 0; 
long startTime = SystemClock.elapsedRealtime(); 
Iterator> iterator = mEntries.entrySet().iterator(); 
while (iterator.hasNext()) { 
Map.Entry 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
是構(gòu)造方法傳入的一個緩存文件夾的大小，如果不傳默認是5M的大小。通過這個方法可以發(fā)現(xiàn)，每當(dāng)被調(diào)用時會傳入一個neededSpace
，也就是需要申請的磁盤大小(即要新緩存的那個文件所需大小)。首先會判斷如果這個neededSpace
申請成功以后是否會超過最大可用容量，如果會超過，則通過遍歷本地已經(jīng)保存的緩存文件的header(header中包含了緩存文件的緩存有效期、占用大小等信息)去刪除文件，直到可用容量不大于聲明的緩存文件夾的大小。其中HYSTERESIS_FACTOR
是一個值為0.9的常量，應(yīng)該是為了防止誤差的存在吧(我猜的)。

Volley緩存命中率的優(yōu)化##

如果讓你去設(shè)計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上問過#鏈接原諒我，別人的回答我最初并沒有看懂。直到最近被問到，如果讓你設(shè)計一個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分成兩部分。現(xiàn)在可以肯定的答出，目的是為了盡可能避免hashcode重復(fù)造成的文件名重復(fù)(求兩次hash兩次都與另一個url重復(fù)的概率總要比一次重復(fù)的概率小吧)。順帶再提一點，就像上面說的，概率小并不代表不存在。但是Java計算hashcode的速度是很快的，應(yīng)該是在效率和安全性上取舍的結(jié)果吧。

推送心跳包是TCP包還是UDP包或者HTTP包##

其實聊起這個問題是因為最近看到@睡不著起不來的萬宵同學(xué)寫的一篇文章《Android推送技術(shù)研究》結(jié)果就產(chǎn)生了這個沒回答出來的問題(媽蛋，自己給自己挖坑 - -)最后看了這篇文章(好像是轉(zhuǎn)的，沒找到原地址)android 心跳的分析原來心跳包的實現(xiàn)是調(diào)用了socket.sendUrgentData(0xFF)
這句代碼實現(xiàn)的，所以，當(dāng)然是TCP包。

ARGB_8888占用內(nèi)存大小##

首先說說本題的答案，是4byte，即ARGB各占用8個比特來描述。當(dāng)時回答錯了，詳細解答看這里你的 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; 
// 計算出圖片應(yīng)該顯示的寬高 
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)存嗎？第一次設(shè)置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運用了哪種設(shè)計模式，優(yōu)點是什么##

這個回答的太多了，我當(dāng)時說的是代理模式，因為AppCompatActivity
中的確是使用的代理模式。這一點還要感謝@代碼家當(dāng)時說讓我看看AppCompatDelegate
類的設(shè)計。其主要目的就是通過使用組合來替代繼承，降低了耦合。不過回家后再想一想，對方想聽到的應(yīng)該是模板方法模式吧。在父類中實現(xiàn)一個算法不變的部分，并將可變的行為留給子類來實現(xiàn)。生命周期方法原本就是在基類中做出了Activity不同狀態(tài)時回調(diào)的一系列方法，而這些方法具體需要做的可變部分交給子類去完成。

HashMap的底層實現(xiàn)##

HashMap內(nèi)部是通過數(shù)組實現(xiàn)的，而數(shù)組的每一位都是Entry
的對象，這個Entry
實際上是一個鏈表的節(jié)點。誒，大學(xué)時候數(shù)據(jù)結(jié)構(gòu)有講過啊，都忘記了。根據(jù)hash算法，求出當(dāng)前key應(yīng)該存放在數(shù)組的那個index處，如果有值了，則存在index所在Entry
所在鏈表相鄰的下一個位置。根據(jù)如果自己實現(xiàn)HashMap如何防止value覆蓋。同上面 Volley 中講到的。

Atomic、volatile、synchronized區(qū)別##

面Java基礎(chǔ)的時候遇上了這個問題，說如果只有一個i++;的時候，volatile
和synchronized
能否互換。當(dāng)時也不知道，感覺volatile
作為修飾變量的時候，變量自加會出現(xiàn)加到一半發(fā)生線程調(diào)度。再看看當(dāng)時蒙對了。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))。最終的結(jié)果就是在高并發(fā)的時候，或者說競爭激烈的時候效率比synchronized
高一些。ThreadLocal
，線程中私有數(shù)據(jù)。主要用于線程改變內(nèi)部的數(shù)據(jù)時不影響其他線程，使用時需要注意static
。詳細分析見這篇文章。再補一個，才學(xué)到的。利用clone()
方法，如果是一個類的多個對象想共用對象內(nèi)部的一個變量，而又不想這個變量static，可以使用淺復(fù)制方式。(查看設(shè)計模式原型模式)

其他##

做內(nèi)部庫設(shè)計時，最重要的考慮是jar的成本，方法數(shù)、體積。設(shè)計模式不應(yīng)該是去記憶，而應(yīng)該是用的時候自然而然的用上。

3月11日更新面試真的是有夠煩的，因為題目是隨機的，而知識是無窮的。
直到被很多答案都是沒有標(biāo)準(zhǔn)的。就好像上面提到的 MV* ，
也許到現(xiàn)在上面的理解依舊有問題，但是我覺得架構(gòu)是死的，而最合適的才是最好的。
但是有一點，面試也是一種學(xué)習(xí)，至少它能讓你知道你的薄弱點在哪。

原文地址：http://blog.csdn.net/xiaole0313/article/details/51778103 轉(zhuǎn)載必須注明出處。
博 客：http://blog.csdn.net/xiaole0313GitHub：https://github.com/xiaole0310