以下做法純屬個人習慣，歡迎討論:D

initView()與updateView()

通常，我會添加一個initView()方法來初始化所有的View對象，在這個方法的具體實現中，可能會有兩種不同的細微差別。第一種是僅僅做findViewById()就好了，也就是僅僅是去找到每一個View對象，而不去給它們設置屬性，比如setText()之類的。另一種則是在findViewById()后，順便給它們設置初始值。

我更傾向于第一種做法，因為如果你在initView()方法中給View設置一些屬性，那么當一些數據變更時，你可能也需要去變更View的一些屬性，你必然會有一個updateView()這樣的方法。updateView()方法中，需要根據當前頁面的狀態和數據去給View設值，問題就在于，當需求發生變化的時候，你可能需要改兩個地方，initView()和updateView()。考慮到這一點。最佳的做法就是你需要一個initView()方法和一個updateView()方法。

initView()方法只做初始化操作，也就是僅僅只會發生一次的操作，比如findViewById()，setListener()之類的。而updateView()方法中，則是去做一些根據某些成員變量，flag，boolean值之類的去變更View的屬性，會被反復調用的操作。

關于updateView()方法，我又有兩種不同的思路，在此之前，先具體的說明一下updateView()中要干的工作。比如我們有一些成員變量dataA，dataB，有一些會隨之變化的View，ViewA1，ViewA2，ViewB1，ViewB2……然后當數據dataA改變時，我們需要更改ViewA1，ViewA2的屬性，當數據dataB改變時，我們要更改ViewB*的屬性，于是，我們通常寫的updateView()方法是這樣的。

private void updateView() { ... viewA1.setText(dataA.getContent()); viewA2.setTextColor(dataA.getTextColor());viewB1.setImage(dataB.getImage()); viewB2.setText(dataB.getTitle()); ...}

在我們的Activity/Fragment比較簡單的時候，這樣寫應該沒有什么問題，但是當頁面的邏輯因需求的變更而變得越來越復雜，我們可能需要維持很多很多的成員變量（數據）和View。那么updateView()方法可能里面做了很多很多的工作，這樣調用一次必然是效率低下的。因此，我認為另一種比較好的方式是將數據A所關聯的Views都封裝成一個方法，數據B所關聯的Views都封裝成另一個方法，像這樣。

private void updateAViews() { viewA1.setText(dataA.getContent()); viewA2.setTextColor(dataA.getTextColor()); ...}private void updateBViews() { viewB1.setImage(dataB.getImage()); viewB2.setText(dataB.getTitle()); ...}private void updateAllViews() { updateAViews(); updateBViews(); ...}

顯然，第二種方式是效率最好的一種方式，也是維護起來最麻煩的一種方式，但我個人還是比較傾向于第二種寫法。因為有一些View它的onDraw()方法本身真的會消耗比較長的時間，如果簡單粗暴的更新所有的View，可能會讓UI的流暢度大打折扣。

使用boolean值來避免updateView()中的空指針異常

當我們使用initView()和updateView()兩個方法來變更View的時候，要注意空指針的情況，因為調用updateView的時機不是自己能控制的，updateView可能是在網絡數據返回時調用，那么如果onCreate的時候先請求數據，數據馬上返回了并調用updateView方法，這個時候，initView還沒有執行，那么updateView中對View的操作就會報空指針異常。

我們可以使用一個boolean值來解決這個問題。

提前考慮Activity和Fragment的復用

當我們寫Activity或Fragment的時候需要考慮到這個頁面可能會從哪些地方調過來。比如說，我們要完成一個需求，這個需求是顯示一個列表，列表里面有特定的數據，這個頁面必須要自己全新寫一個Activity或Fragment來完成，入口也只有一個，那么我們幾乎是可以“為所欲為”的實現這個頁面，想怎么寫就怎么寫。

但是當需求發生了變化，比如其他地方也可以點擊進入你這個頁面，并且還顯示了不一樣的數據，考慮到頁面復用這一點，我們應該通過傳入不同的參數，來改變這個頁面的行為（應該顯示怎么樣的數據，或者UI上有哪些其他的變化）。

所以，在我們全新寫這個頁面的時候，就應該有所收斂，要主動思考一下，因為這個頁面如果是被復用的，那么一般來說，是這個頁面的樣式，行為會被復用。不一樣的地方往往是數據，頁面的復用，就要考慮到在onCreate的時候可以傳入不同的參數，完成不同的要求和顯示。

我們應該在Activity或Fragment中添加幾個成員變量，用來標記狀態，比如：

public class DataListActivity extends Activity { public static final int DATA_TYPE_ALL = 1; public static final int DATA_TYPE_PART = 2; private int mDataType = DATA_TYPE_ALL;...}

這樣，我們內部獲取數據的時候就根據這個mDataType來做具體的處理就好了。考慮到復用這一點，后面擴展的時候就會更游刃有余。并且這個mDataType也許會影響到UI上的一些表現，updateView系列方法可能也需要關心這個（些）變量的情況。

通過封裝好的靜態方法啟動Activity

初學的時候，我們總是是用下面類似的代碼啟動Activity。

Intent i = new Intent();i.setClass(context, TargetActivity.class);context.startActivity(i);

但是，根據上一個小主題上面所說的，往往我們需要告訴要啟動的Activity一些特定的信息，然后展示出不同的行為，一般有兩種常見的寫法。

方式A：

public class TargetActivity extends Activity { public static final String INTENT_KEY_DATA_TYPE = 'INTENT_KEY_DATA_TYPE';public static final int DATA_TYPE_ALL = 1; public static final int DATA_TYPE_PART = 2;public static void start(Context c, int dataType) {Intent i = new Intent();i.setClass(c, TargetActivity.class);i.putExtras(INTENT_KEY_DATA_TYPE, dataType);c.startActivity(i); }}//in other ActivityTargetActivity.start(context, TargetActivity.DATA_TYPE_ALL);

方式B：

public class TargetActivity extends Activity { public static final String INTENT_KEY_DATA_TYPE = 'INTENT_KEY_DATA_TYPE';public static final int DATA_TYPE_ALL = 1; public static final int DATA_TYPE_PART = 2;public static Intent obtainIntent(Context, int dataType) {Intent i = new Intent();i.setClass(c, TargetActivity.class);i.putExtras(INTENT_KEY_DATA_TYPE, dataType);return i; }}//in other Activity.startActivity(TargetActivity.obtainIntent(this, TargetActivity.DATA_TYPE_ALL));

方式A更簡潔，方式B更繁瑣一些，但是方式B更好，因為有時候我們需要啟動的Activity結束時返回一些東西，那么我們需要調用到startActivityForResult()方法來啟動，在當前的Activity調用這個方法，必須要獲取到Intent對象，所以，方式B的obtainIntent使用情況就更廣泛了。

但在編寫obtianIntent方法的時候，建議讓它帶上你需要傳遞的參數，當前的demo是只有一個int型的dataType，也許你還有很多其他的參數，但都請在obtainIntent方法中就給Intent填上，這樣外面（其他）的Activity就不需要去填寫這些額外的信息了，你的INTENT_KEY可以完全的定義在要用它的內部，這樣做真是又干凈又漂亮。

父類應該減輕子類的負擔，而不是給子類添加約束

上面幾個話題，我們講了幾個常見的套路做法，這樣可以使代碼更加清晰，更加易于維護。

但是我們習慣的套路中那些initView，updateView，obtainIntent等方法，并不適合移動到父類去，因為這不是邏輯，如果你挪到父類中寫成抽象方法，方法就是限定死了，所有的子類都要有這個initView方法，這樣是不合適的，不同的人也許有不同的代碼習慣，因此將多余的流程挪到父類，就會形成對子類的約束。子類中如果有重復的邏輯，才是應該移動到父類的。

監聽器，觀察者模式，回調

其實監聽器和觀察者模式，回調都是一樣的東西，表面上看，它們就是一群叫OnXxxxx的一群方法或者接口。

它們負責告訴你一些事件發生了，比如系統給你的onClick，onTouch，onSrcoll……還可以是在新的線程發起一個網絡請求，當請求結果返回時，告訴你，像onResult，onPush……這樣的形式。

總之，當你理解了這個東西，你就可以熟練的使用，當你想寫一個控件，這個控件要完成一個功能或者一些特性，你需要提供一些回調接口來供客戶程序員使用。比如我之前寫過一個底部有loading的控件，滾動到底部的時候，會出現一個loading（轉菊花），然后給你一個“時機”來讓你請求數據，然后讓adapter更新數據。這里有是具體的代碼： BottomLoadListView.java in github

通常，我們可以把這個回調接口都讓Activity或者Fragment來實現，像這樣：

public class MyActivity extends Activity implement OnClickListener, OnNetworkChangeListener, IOnRequestCallback{ ...}

這樣，這個Activity內部的一些對象需要回調接口的時候，直接給它this即可，就不需要那么多匿名內部類了，而這些回調方法都放在Activity中，當它們被調用的時候，也能很好的控制整個Activity的行為，是很方便的。

多個頁面共用數據與回調

通常，我們某一個頁面（Activity/Fragment）需要顯示一些數據，這些數據的引用都是讓Activity自己持有的，如果僅僅是一個頁面需要這些數據，這么做沒有什么問題，當我們有兩個頁面需要對同一份數據進行操作的時候，這樣做就不太方便了。通常可以寫一個名為XxxxEngine的東西，xxx具體是什么跟所關聯的業務邏輯有關，比如說是消息列表，那么就叫MessageEngine好了。

這個Engine一般會寫成單例模式，然后讓它來持有數據的引用，而兩個或多個頁面需要對這份消息列表（message list）進行操作的時候，就通過這個Engine來獲取就行了。

使用Engine還有另一個場景，就是兩個頁面都需要監聽某一個網絡push，比如說在多終端的情況下，我們有一個個人信息頁面，個人信息是可以在別的終端被修改的，那么我們的頁面就會收到一個通知，有時候，通知回調是不帶數據的，我們需要手動去拉去數據，就算帶上了數據，如果兩個頁面都監聽這個網絡回調，也會有問題，因為這樣就有兩份數據，或者說有兩個地方會對數據進行操作。我用來代碼來演示。

public class ProfileActivity extends Activity implement OnProfileChangedListener, OnResultForProfileRequest {private Profile mProfile = null;//當別的終端更新了個人信息后調用這里 @override public void onProfileChanged() {ProfileManager.getInstance().requestProfile(this); //傳入OnResultForProfileRequest接口 }//當requestProfile()請求結果返回時調用 @override public void onResult(Profile profile) {mProfile = profile;updateView(); }}

上面代碼展示了一個頁面收到數據變更的通知以及請求數據的情況，那么當我們有兩個頁面都需要關心數據發生變化的時候，如果兩個頁面都像上面這樣寫，那么我們就有兩處來請求數據，這樣是不好的，因為兩個地方用的是同一份數據，這樣根據上面說的，我們需要一個ProfileEngine來維持這份數據的引用，另一方面，我們可以把profile changed的監聽，放在ProfileEngine上，這樣就只有它一個地方收到變化的通知，一個地方來拉取最新數據，更新好了之后，再通知兩個（多個）頁面通過單例來獲取最新的數據。這種情形下，我們需要定義一個本地的接口。

public class ProfileEngine implement OnRemoteProfileChangedListener, OnResultForProfileRequest {public interface OnLocalProfileChangedListener { void onLocalProfileChanged(Profile newProfile); }private Profile mProfile = null;//監聽列表 private ArrayList<OnLocalProfileChangedListener> mListeners = new ArrayList<>();//當別的終端更新了個人信息后調用這里 @override public void onProfileChanged() {ProfileManager.getInstance().requestProfile(this); //傳入OnResultForProfileRequest接口 }//當requestProfile()請求結果返回時調用 @override public void onResult(Profile profile) {mProfile = profile; }//通知所有的頁面，profile發生了變更，并且已經取好了最新的數據了，拿過去更新UI就好了 private void notifyListener() {for (OnLocalProfileChangedListener l : mListeners) { l.onLocalProfileChanged(mProfile);} }}

這個套路感覺真的很簡潔干練，但我們需要注意一個問題就是本地的監聽的注冊與反注冊。

單例一旦被創建就不會被銷毀了，除非進程被干掉，或者我們主動置空（null）并且GC。也就是說，這個單例通常情況下會一直在內存中的，也會一直監聽remote的profile變化，并且會去拉去最新的數據，請注意這里的mListeners，里面存放的兩個頁面（Activity/Fragment），如果我們沒有在頁面銷毀（onDestory）的時候將自己從監聽列表中移除，那么mListeners就會一直持有Activity的引用，但是頁面卻已經是消失了，這樣就造成了內存泄露。因此一定要嚴格的在onCreate和onDestory中調用注冊與反注冊方法。

一種網絡請求套路

這種網絡請求套路也是最近才學習到的，感覺非常的簡單巧妙。

//發起一個請求檢查一下數據是否有變更，如果有變更，會通過通知onChanged()告訴客戶端，無參數無返回值void check();//通知，告知客戶端數據有變更，要拉取最新數據需要另一個接口，無參數，無返回值void onChanged();//通過網絡拉取數據，無返回值，傳入回調接口，因為是異步返回數據void request(onRequestResult);//請求數據的回調接口，參數中是最新的數據void onRequestResult(Data)//通過網絡更新數據，無返回值，通過參數傳入新數據和回調接口void set(Data, OnSetResult);//更新數據的回調接口，參數表示有沒有成功，以及最新的數據，同時也會調用onChanged()方法void onSetResult(int, Data);

可以發現，數據變化的時候，總是會調用onChanged()方法，而這僅僅是通知，獲取數據需要自己手動去拉取一次。這樣我們有統一的時機可以獲取最新的數據。

以上做法純屬個人習慣，歡迎討論:D