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

MVC，MVP 和 MVVM##

MVC 通信方式，環(huán)形方式：
1、View 傳送指令到 Controller
2、Controller 起到不同層面間的組織作用，用于控制應(yīng)用程序的流程。它處理事件并作出響應(yīng)?！笆录卑ㄓ脩舻男袨楹蛿?shù)據(jù) Model 上的改變。

我們針對(duì)業(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ù)讀取，我的猜想是因?yàn)楹?jiǎn)單。試想，如果是為了規(guī)范，首先定義一個(gè)getDataFromDB()的接口，再寫個(gè)類實(shí)現(xiàn)getDataFromDB()方法，以后如果改了請(qǐng)求數(shù)據(jù)所用的方法，直接改寫實(shí)現(xiàn)類，聽起來確實(shí)不錯(cuò)，可是僅僅是為了從數(shù)據(jù)庫讀點(diǎn)數(shù)據(jù)，額外添加了至少兩個(gè)類文件真的有意義嗎。當(dāng)然網(wǎng)絡(luò)請(qǐng)求，是屬于業(yè)務(wù)邏輯層C層。

MVP中 Presenter 真正需要處理的并非業(yè)務(wù)邏輯，而應(yīng)該是視圖邏輯。業(yè)務(wù)邏輯應(yīng)該是視圖無關(guān)的，可以是單獨(dú)的一個(gè)類中，也可以是在P中。P與V是一對(duì)多關(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)各個(gè)方面的設(shè)計(jì)?？偨Y(jié)一下，就是一整個(gè)軟件工程項(xiàng)目中的骨架，是一種宏觀的規(guī)劃。

Volley相關(guān)##

Volley的磁盤緩存##

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

翻看代碼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)造方法傳入的一個(gè)緩存文件夾的大小，如果不傳默認(rèn)是5M的大小。通過這個(gè)方法可以發(fā)現(xiàn)，每當(dāng)被調(diào)用時(shí)會(huì)傳入一個(gè)neededSpace
，也就是需要申請(qǐng)的磁盤大小(即要新緩存的那個(gè)文件所需大小)。首先會(huì)判斷如果這個(gè)neededSpace
申請(qǐng)成功以后是否會(huì)超過最大可用容量，如果會(huì)超過，則通過遍歷本地已經(jīng)保存的緩存文件的header(header中包含了緩存文件的緩存有效期、占用大小等信息)去刪除文件，直到可用容量不大于聲明的緩存文件夾的大小。其中HYSTERESIS_FACTOR
是一個(gè)值為0.9的常量，應(yīng)該是為了防止誤差的存在吧(我猜的)。

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

如果讓你去設(shè)計(jì)Volley的緩存功能，你要如何增大它的命中率?？上Я?，如果上面的緩存功能是昨天看的，今天的面試這個(gè)問題就能說出來了。還是上面的代碼，在緩存內(nèi)容可能超過緩存文件夾的大小時(shí)，刪除的邏輯是直接遍歷header刪除。這個(gè)時(shí)候刪除的文件有可能是我們上一次請(qǐng)求時(shí)剛剛保存下來的，屁股都還沒坐穩(wěn)呢，現(xiàn)在立即刪掉，有點(diǎn)舍不得啊。如果遍歷的時(shí)候，判斷一下，首先刪除超過緩存有效期的(過期緩存)，其次按照LRU算法，刪除最久未使用的，豈不是更合適？

Volley緩存文件名的計(jì)算##

這個(gè)是我一直沒弄懂的問題。如下代碼：

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;
}

為什么會(huì)要把一個(gè)key分成兩部分，分別求hashCode，最后又做拼接。這個(gè)問題之前在stackoverflow上問過#鏈接原諒我，別人的回答我最初并沒有看懂。直到最近被問到，如果讓你設(shè)計(jì)一個(gè)HashMap，如何避免value被覆蓋，我才想到原因。先來看一下String#hashCode()
的實(shí)現(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;
}

從上面的實(shí)現(xiàn)可以看到，String的hashcode是根據(jù)字符數(shù)組中每個(gè)位置的字母的int值再加上上次hash值乘以31，這種算法求出來的，至于為什么是31，我也不清楚。但是可以肯定一點(diǎn)，hashcode并不是唯一的。不信你運(yùn)行下面這兩個(gè)輸出：

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());

這兩個(gè)字符串是根據(jù)hashcode的算法逆向出來的，他們的hashcode都是12345。逆向算法請(qǐng)見這里再回到我們的問題，為什么會(huì)要把一個(gè)key分成兩部分?，F(xiàn)在可以肯定的答出，目的是為了盡可能避免hashcode重復(fù)造成的文件名重復(fù)(求兩次hash兩次都與另一個(gè)url重復(fù)的概率總要比一次重復(fù)的概率小吧)。順帶再提一點(diǎn)，就像上面說的，概率小并不代表不存在。但是Java計(jì)算hashcode的速度是很快的，應(yīng)該是在效率和安全性上取舍的結(jié)果吧。

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

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

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

首先說說本題的答案，是4byte，即ARGB各占用8個(gè)比特來描述。當(dāng)時(shí)回答錯(cuò)了，詳細(xì)解答看這里你的 Bitmap 究竟占多大內(nèi)存但是——這個(gè)問題引出了一個(gè)大大的鬧劇，請(qǐng)聽我慢慢道來。不知道怎么就聊到 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; 
// 計(jì)算出圖片應(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 時(shí)候是不占內(nèi)存的，因?yàn)榉祷氐氖莕ull一臉不相信我的說：噢，這地方我下去再看看。嚇得我回來了以后趕緊又看了看，還好沒有記錯(cuò)，見源碼注釋

/** * 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ùn)用了哪種設(shè)計(jì)模式，優(yōu)點(diǎn)是什么##

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

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

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

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

面Java基礎(chǔ)的時(shí)候遇上了這個(gè)問題，說如果只有一個(gè)i++;的時(shí)候，volatile
和synchronized
能否互換。當(dāng)時(shí)也不知道，感覺volatile
作為修飾變量的時(shí)候，變量自加會(huì)出現(xiàn)加到一半發(fā)生線程調(diào)度。再看看當(dāng)時(shí)蒙對(duì)了。volatile
可以保證在一個(gè)線程的工作內(nèi)存中修改了該變量的值，該變量的值立即能回顯到主內(nèi)存中，從而保證所有的線程看到這個(gè)變量的值是一致的。但是有個(gè)前提，因?yàn)樗痪哂胁僮鞯脑有?，也就是它不適合在對(duì)該變量的寫操作依賴于變量本身自己。就比如i++、i+=1;這種。但是可以改為num=i+1;如果i是一個(gè)volatile
類型，那么num就是安全的，總之就是不能作用于自身。synchronized
是基于代碼塊的，只要包含在synchronized
塊中，就是線程安全的。既然都說了線程安全，就多了解幾個(gè)：AtomicInteger
，一個(gè)輕量級(jí)的synchronized
。使用的并不是同步代碼塊，而是Lock-Free算法(我也不懂，看代碼就是一個(gè)死循環(huán)調(diào)用了底層的比較方法直到相同后才退出循環(huán))。最終的結(jié)果就是在高并發(fā)的時(shí)候，或者說競(jìng)爭(zhēng)激烈的時(shí)候效率比synchronized
高一些。ThreadLocal
，線程中私有數(shù)據(jù)。主要用于線程改變內(nèi)部的數(shù)據(jù)時(shí)不影響其他線程，使用時(shí)需要注意static
。詳細(xì)分析見這篇文章。再補(bǔ)一個(gè)，才學(xué)到的。利用clone()
方法，如果是一個(gè)類的多個(gè)對(duì)象想共用對(duì)象內(nèi)部的一個(gè)變量，而又不想這個(gè)變量static，可以使用淺復(fù)制方式。(查看設(shè)計(jì)模式原型模式)

其他##

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

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

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