當(dāng)我們要去看一個陌生的項目的時候，經(jīng)常會遇到很多類魂毁，很煩惱席楚，感覺就像是一片又一片的森林走不到頭疚漆，然后就會產(chǎn)生煩躁的思想，但是我們都知道闻镶，跟著一條主線往下走铆农，我也是這個樣子但是還是經(jīng)常會把自己繞進(jìn)去狡耻。
看代碼，或者說學(xué)習(xí)別人的代碼岭皂，怎么才算完全懂了爷绘？
對于細(xì)讀代碼我覺的下面這些是必要的：
理清楚業(yè)務(wù)邏輯，不要只是一個方法名一個方法名的向下去追购对。那么這就要求我們看清楚的這個對象是在那里創(chuàng)建的陶因，這個方法是運行在哪個進(jìn)程的那個線程里面楷扬。關(guān)注這個對象是在什么地方new出來的毅否，這個方法的參數(shù)是在什么地方創(chuàng)建出來的。一定注意揣摩方法名和變量名的意思徘溢，不要圖快捆探，多去讀注釋，理解寫代碼的人想表達(dá)的意思曾雕。停下來對思考它這個地方為什么要這樣寫助被，如果是你你怎么寫揩环，去分析代碼的業(yè)務(wù)是怎樣的，都要處理那幾種情況顾犹，多給自己提出問題炫刷，從code中去思考答案郁妈，多回頭，記住閱讀前面的代碼遇到的問題顾彰，在閱讀完后面的代碼之后拘央，在從全局的角度去思考這個問題灰伟，考慮他為什么這樣寫儒旬。
我認(rèn)為呢栈源？ 首先，牢記我們的目的是什么茶鹃？理清楚一個方法闭翩，變量疗韵，功能還是什么的蕉汪。每一次深入都結(jié)合目的思考一下逞怨，這樣子不容易走丟骇钦。接下來我認(rèn)為的最重要的一點，看接口和抽象類窥翩，我認(rèn)為不管是多復(fù)雜的項目寇蚊，只要我們能，把它的繼承關(guān)系棍好，理清楚仗岸，看到哪里都不會丟允耿，我們知道好的項目他的代碼都會做好分層，做好解耦扒怖，也就是面向接口編程應(yīng)用的很好较锡，以前看設(shè)計模式，對面向?qū)ο?大原則盗痒，只是在能讀懂的階段蚂蕴，遠(yuǎn)沒有達(dá)到能在代碼設(shè)計階段就將他們體現(xiàn)的淋漓盡致，而好的項目源碼俯邓，他的架構(gòu)脈絡(luò)應(yīng)該是清晰的骡楼，也就是抽象類和接口，對于設(shè)計模式有很好的應(yīng)用稽鞭，我一直認(rèn)為，抽象的好的話，那么架構(gòu)就不會太差兑燥。
所以再看代碼的時候，我認(rèn)為還應(yīng)該看清接口的依賴，理清楚回調(diào)扔枫，一個項目差不多就能想看哪里看哪里了叹哭。
下面分享我對android downloadmanager學(xué)習(xí)糠排，
public long enqueue(Request request) {
ContentValues values = request.toContentValues(mPackageName);
Uri downloadUri = mResolver.insert(Downloads.Impl.CONTENT_URI, values);
long id = Long.parseLong(downloadUri.getLastPathSegment());
return id;
}
這個方法很簡單，也很重要落追，封裝一個請求宽菜，添加到數(shù)據(jù)庫，這里為什么要添加到數(shù)據(jù)庫呢，直接處理不行嗎挚赊？考慮業(yè)務(wù)場景蔑鹦，我們在“下載”這個應(yīng)用里面是不是可以看到自己的下載記錄，還可以管理哟忍，那這樣是不是就有存到數(shù)據(jù)庫的必要了凤跑。返回一個id鹏控，后面可以通過這個id來抖僵，簡單的維護(hù)一下我們的請求找筝，
那么問題又來了這里只是添加了數(shù)據(jù)庫，系統(tǒng)怎么知道我們要下載東西呢谤民？
熟悉contentprovider的同學(xué)都知道为牍，contentprovider可以把數(shù)據(jù)庫的改動通知給關(guān)注某個uri的應(yīng)用兼雄。
那么我們?nèi)绾稳フ艺嬲南螺d的code在哪呢?
我們注意看上買呢insert方法后面跟的那個靜態(tài)的uri，從這個uri我們就可以找到對應(yīng)的contentprovider是DownloadProvider囱井，觀察這個類我們發(fā)現(xiàn)它繼承自DocumentsProvider不知道有沒有同學(xué)用過這個東西呢住练？提醒以下這個東西在apiguide里面又講哦！
insertRequestHeaders(db, rowID, values);
notifyContentChanged(uri, match);
// Always start service to handle notifications and/or scanningfinal
Context context = getContext();
context.startService(new Intent(context, DownloadService.class));
ok在downloadProvider的insert方法的最下面我們發(fā)現(xiàn)了這樣的代碼,很明顯這里會通知，而且還啟動了接受通知的服務(wù)，從注釋也能肯出來這一點。那么下來我們就來看一下這個服務(wù)藤滥。
/** * Initializes the service when it is first created */
@Override
public void onCreate() {
super.onCreate();
if (Constants.LOGVV) {
Log.v(Constants.TAG, "Service onCreate");
}
if (mSystemFacade == null) {
mSystemFacade = new RealSystemFacade(this);
}
//用到這個要做定時任務(wù)泳秀，猜想吕嘀？
mAlarmManager = (AlarmManager) getSystemService(Context.ALARM_SERVICE);
//推測這是網(wǎng)絡(luò)下載應(yīng)該是在這個線程里面進(jìn)行
mUpdateThread = new HandlerThread(TAG + "-UpdateThread");
mUpdateThread.start();
mUpdateHandler = new Handler(mUpdateThread.getLooper(), mUpdateCallback);
//掃描？
mScanner = new DownloadScanner(this);
//通知，這個應(yīng)該不會錯了
mNotifier = new DownloadNotifier(this);
mNotifier.cancelAll();
//觀察者，觀察數(shù)據(jù)庫的變化叨橱，從那個uri也可以看出
mObserver = new DownloadManagerContentObserver();
getContentResolver().registerContentObserver(Downloads.Impl.ALL_DOWNLOADS_CONTENT_URI, true, mObserver);
//不知道有沒有小伙伴用過這個。
JobScheduler js = (JobScheduler) getSystemService(Context.JOB_SCHEDULER_SERVICE); if (needToScheduleCleanup(js)) { final JobInfo job = new JobInfo.Builder(CLEANUP_JOB_ID, sCleanupServiceName) .setPeriodic(CLEANUP_JOB_PERIOD) .setRequiresCharging(true) .setRequiresDeviceIdle(true) .build(); js.schedule(job);
}}
ok以上就是DownService的oncreate方法了淑倾，看完也能猜測一部分代碼吧治力。
以為這是一個服務(wù)嘛，所以呢我們繼續(xù)去看剩余的生命周期方法，在onstartcommand調(diào)用了這個方法我們繼續(xù)看废亭。
public void enqueueUpdate() {
if (mUpdateHandler != null) {
mUpdateHandler.removeMessages(MSG_UPDATE);
mUpdateHandler.obtainMessage(MSG_UPDATE, mLastStartId, -1).sendToTarget();
}}
我們繼續(xù)去讀那個handler，
果然 DownloadService有這麼個觀察者粗恢，downloaservice這個類我們只看他的下載流程，現(xiàn)在不要在意細(xì)節(jié)坐榆，在oncreate里初始化handler 职员，而上面觀察到數(shù)據(jù)變化，會發(fā)送消息荔仁，然后會掉updateLocked（）這個方法來查詢數(shù)據(jù)庫次洼，拿出請求封裝成了一個downloadinfo ，在這類里面有這個方法info.startDownloadIfReady(mExecutor); 見名知意。進(jìn)去看我們發(fā)現(xiàn)他們?nèi)蝿?wù)都扔到線程池里面去處理了模暗，當(dāng)然還有DownloadThread這個類瓷产，處理之前是先把請求封裝成這個線程的再登。
ok這就是大概的一個流程炎疆，寫的有點亂七嫌，在這個基礎(chǔ)上再來看download的細(xì)節(jié)就會很輕松了。
