Android中必須學(xué)習(xí)的七大開源項(xiàng)目本文原創(chuàng)，轉(zhuǎn)載請以鏈接形式注明地址：
http://blog.csdn.net/xiaole0313/article/details/51778103
“基礎(chǔ) Android 知識掌握的不錯(cuò)，學(xué)習(xí)能力也不錯(cuò)捅位。但是基礎(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ù)讀取苦掘，我的猜想是因?yàn)楹唵巍Ｔ囅胄ㄈ溃绻菫榱艘?guī)范鹤啡，首先定義一個(gè)getDataFromDB()的接口，再寫個(gè)類實(shí)現(xiàn)getDataFromDB()方法蹲嚣，以后如果改了請求數(shù)據(jù)所用的方法递瑰，直接改寫實(shí)現(xiàn)類，聽起來確實(shí)不錯(cuò)端铛，可是僅僅是為了從數(shù)據(jù)庫讀點(diǎn)數(shù)據(jù)泣矛，額外添加了至少兩個(gè)類文件真的有意義嗎。當(dāng)然網(wǎng)絡(luò)請求禾蚕，是屬于業(yè)務(wù)邏輯層C層您朽。

MVP中 Presenter 真正需要處理的并非業(yè)務(wù)邏輯，而應(yīng)該是視圖邏輯换淆。業(yè)務(wù)邏輯應(yīng)該是視圖無關(guān)的哗总，可以是單獨(dú)的一個(gè)類中，也可以是在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)各個(gè)方面的設(shè)計(jì)±春颍總結(jié)一下跷叉，就是一整個(gè)軟件工程項(xiàng)目中的骨架，是一種宏觀的規(guī)劃营搅。

Volley相關(guān)##

Volley的磁盤緩存##

在面試的時(shí)候云挟，聊到 Volley 請求到網(wǎng)絡(luò)的數(shù)據(jù)緩存。當(dāng)時(shí)說到是 Volley 會(huì)將每次通過網(wǎng)絡(luò)請求到的數(shù)據(jù)转质，采用FileOutputStream
园欣，寫入到本地的文件中。那么問題來了：這個(gè)緩存文件峭拘，是聲明在一個(gè)SD卡文件夾中的(也可以是getCacheFile())俊庇。如果不停的請求網(wǎng)絡(luò)數(shù)據(jù)，這個(gè)緩存文件夾將無限制的增大鸡挠，最終達(dá)到SD卡容量時(shí)辉饱，會(huì)發(fā)生無法寫入的異常(因?yàn)榇鎯?chǔ)空間滿了)。這個(gè)問題的確以前沒有想到拣展，當(dāng)時(shí)也沒說出怎么回事彭沼。回家了趕緊又看了看代碼才知道备埃，原來 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
于毙，也就是需要申請的磁盤大小(即要新緩存的那個(gè)文件所需大小)。首先會(huì)判斷如果這個(gè)neededSpace
申請成功以后是否會(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í)候刪除的文件有可能是我們上一次請求時(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。逆向算法請見這里再回到我們的問題梨水，為什么會(huì)要把一個(gè)key分成兩部分∈没纾現(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è)大大的鬧劇，請聽我慢慢道來辟汰。不知道怎么就聊到 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ì)歼疮。其主要目的就是通過使用組合來替代繼承杂抽，降低了耦合。不過回家后再想一想韩脏，對方想聽到的應(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
的對象弧械，這個(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í)蒙對了。volatile
可以保證在一個(gè)線程的工作內(nèi)存中修改了該變量的值逐工，該變量的值立即能回顯到主內(nèi)存中铡溪，從而保證所有的線程看到這個(gè)變量的值是一致的。但是有個(gè)前提泪喊，因?yàn)樗痪哂胁僮鞯脑有宰亓颍簿褪撬贿m合在對該變量的寫操作依賴于變量本身自己。就比如i++袒啼、i+=1;這種哈扮。但是可以改為num=i+1;如果i是一個(gè)volatile
類型，那么num就是安全的蚓再，總之就是不能作用于自身滑肉。synchronized
是基于代碼塊的，只要包含在synchronized
塊中摘仅，就是線程安全的靶庙。既然都說了線程安全，就多了解幾個(gè)：AtomicInteger
实檀，一個(gè)輕量級的synchronized
惶洲。使用的并不是同步代碼塊按声，而是Lock-Free算法(我也不懂，看代碼就是一個(gè)死循環(huán)調(diào)用了底層的比較方法直到相同后才退出循環(huán))恬吕。最終的結(jié)果就是在高并發(fā)的時(shí)候签则，或者說競爭激烈的時(shí)候效率比synchronized
高一些。ThreadLocal
铐料，線程中私有數(shù)據(jù)渐裂。主要用于線程改變內(nèi)部的數(shù)據(jù)時(shí)不影響其他線程，使用時(shí)需要注意static
钠惩。詳細(xì)分析見這篇文章柒凉。再補(bǔ)一個(gè)，才學(xué)到的篓跛。利用clone()
方法膝捞，如果是一個(gè)類的多個(gè)對象想共用對象內(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ī)的究孕，而知識是無窮的啥酱。
直到被很多答案都是沒有標(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