深入理解Android組件間通訊機制對物件導向特性的影響詳解

組件的特點
對於Android的四大組件Activity, Service, ContentProvider和Service，不能有Setter和Getter，也不能給組件添加介面。原因是組件都是給系統架構調用的，開發人員只能實現其規定的回調介面，組件的建立與銷毀都是由系統架構控制的，開發人員不能強行幹預，更沒有辦法擷取組件的對象。比如Activity，Service，BroadcastReceiver，你沒有辦法去建立一個Activity，Service或BroadcastReceiver，然後像使用其他類那樣的調用其上的介面與其通訊，用Setters和Getters改變屬性等等。這也決定了，組件之間通訊只能用系統支援的Intent。而Intent只能傳遞基礎資料型別 (Elementary Data Type)和Uri等一些常見的資料類型。Intent只支援傳遞內建類型和一些限制類型，這就導致了組件之間的資料傳遞必須都是基本類型，所以枚舉類型無法使用。
多態無法實現
比如你有一個Service用於在後台執行UI中發來的請求，這些請求有些是做資料請求，有些是做資料分析，等等。這裡可以用多態，定義一個統一的Transaction類，然後再為每種特定的Transaction類型，Transaction中統一介面process()用於實際的處理，理想的情況是，Service接收一個Transaction對象，然後調用其process()，沒有必要知道具體的類型，UI建立具體的一個類型對象然後交由Service來處理。但是這在Android當中是無法實現的，因為Intent通訊機制所限，因為它不能直接傳遞Transaction對象。所以，Service必須要知道具體的類型。原生應用Mms中就有如此的現象，在transaction包中TransactionService是處理服務，UI發送到Service的只是區別不同Transaction的Id（一個整數），Service查看不同的Id建立不同的Transaction對象，然後調用process()對其處理。
建議：自己實現一個類似Service的服務類，在其內用Handler，Thread和Looper讓其長時間運行。這樣就沒有組件間通訊的限制，你可以像正常使用Java對象那樣來使用這個服務類，向其傳遞自訂的處理請求:

複製代碼 代碼如下:public class TransactionServer extends HandlerThread {
public TransactionServer() {
start();
}
public void onLooperPrepared() {
mHandler = new Handler(getLooper(), new Handler.Callback() {
@Override
public void handleMessage(Message msg) {
Transaction request = (Transaction) msg.obj;
request.process();
}
}
}

public void execute(Transaction request) {
if (mHandler == null) {
return;
}
Message msg = Message.obtain();
msg.obj = request;
mHandler.sendMessage(msg);
}
}

在Activity中就可以建立此Server的對象，然後使用它：複製代碼 代碼如下:TransactionServer server = new TransactionServer();
Transaction updateRequest = new UpdateTransaction();
server.execute(updateRequest);

另外，用AIDL與Service通訊，雖可以擷取Service的對象引用，可以直接調用Service的方法，但這個也有限制，對於AIDL的介面，所有的參數和傳回型別都必須是基本資料
據類型，不能有對象。原因也好理解，因為AIDL也是要通過IPC的，即便Service與Activity在同一個進程內，所以本質上它與Intent通訊機制無區別。
封裝性被破壞
組件間的通訊機制決定了Android的封裝性，先來看一些執行個體：複製代碼 代碼如下:Intent i = new Intent(Intent.ACTION_VIEW);
i.setDataAndType(uri, "text/html");
startActivity(i);

這在Android當中是再常見不過的了。
Intent和IntentFilter的使用讓封裝性受到大大的破壞，因為你必須把字串，參數等直接寫入到Intent或IntentFilter當中。例如：複製代碼 代碼如下:Intent i = new Intent("android.contacts.action.MULTIPLECONTACTSLISTS");
i.setExtra("request_type", 3);
<intent-filter>
<action android:name="android.contacts.action.MULTIPLECONTACTSLISTS" />
</intent-filter>

當然，可以再好一點，就是：
Intent i = new Intent(Contacts.ACTION_GET_CONTACTS);
但是在AndroidManifest中的IntentFilter還是要寫字串常量（Literal Strings），這樣就有一個問題，就是即使你寫錯了，編譯器不會提醒你，直到你啟動並執行時候才會發現程式不正常工作，你調試啊，調試，最終發現是字串寫錯了。或者，activity的name寫錯了，編譯器同樣不會提醒你，但你運行時卻因找不到類而報出RuntimeException。
建議：儘可能在所有範圍內定義常量，以讓組件間介面保持一致性，特別是對於字串常量，一定要在二個組件都可見的範圍內定義常量，否則將會有維護的麻煩。
例子：intent.putExtra("request_type", 3); --> intent.putExtra(TargetActivity.REQUEST_TYPE, TargetActivity.NO_BACKGROUND);否則，特別是當目標組件不在同一個包內，或距離很遠時，如果另一方改了，編譯時間不會有錯，但程式不會正常工作，從而引發難以發覺的Bug。
無法在組件間傳遞自訂的資料結構
如前面所述，因為無法擷取組件的對象的引用，所以你無法向其設定資料，當然，可以用靜態方法，但是不優雅且難以維護（對於Service倒是可以通過AIDL方式擷取Service對象的引用，然後調用其方法來添加資料）。又因為Intent只能攜帶基本的資料類型，所以對於自訂的資料結構想要在組件間傳遞就特別的麻煩。當然你可以以讓資料結構實現Parcleable介面，但是用起來也相當的麻煩。
建議：
1. 儘可能的避免使用自訂資料結構，特別是除了Setters和Getters以外不具有其他行為的資料結構
對於結構化的資料，為其定義ContentProvider，把資料寫入SQLite資料庫，這樣資料庫表中的每行資料都相當於是一個資料對象，每一列都是其屬性。因為Android的組件與SQLite資料庫的粘性很大，每個組件都可以很方便的從資料庫中擷取資料，再通過Cursor等工具來操作資料。最最重要的是這很方便在組件間傳遞資料，因數ContentProvider的訪問都是通過Uri來實現的，而Uri又可以與Intent無縫接合，Uri可以方便的放入和從Intent中取出，每個組件又都可以直接存取ContentProvider用Uri讀取資料，從而就可以實現組件間的無縫資料傳遞。
2. 儘可能的不要在組件之間傳遞資料
不要用太多的Activity，Service也能免則免，Activity＋線程可能解決大部分問題，當然了，線程也不是那麼好用的，特別是在Android裡面。
3. 避免在組件之間傳遞自訂資料結構
如前所述，組件之間最好直接傳遞基本資料和Intent支援的資料類型。對於自訂的資料結構，要麼不定義資料結構，要麼不要在組件間傳遞，否則會很麻煩，雖然可能以實現Parcelable介面，但是效率和操作的方便性上都會大打折扣。
關於枚舉和整數集
先前一篇<Android開發筆記之:用Enum(枚舉類型)取代整數集的應用詳解>曾說要盡量使用枚舉(enum)代替整數集(ints)，而且很多編程書籍(Effective Java)也建議用枚舉代替整數集，這其中的好處就是降低出錯率，把運行時的檢查可以放到編譯時間，因為整數的範圍較大，你可傳遞任意的整數，直到運行時才會檢測或產生問題，但是枚舉會在編譯時間檢查類型，如果不是合法的枚舉，編譯器會報怨。
但是我們可以看到，在Android中的情況卻很差，Android中大量的使用了整數集，系統定義了大量的整數集，很多參數也都是整數，雖然正確的方法都是向這些API傳遞其所定義的整數常量，但是你如果傳個Integer.MAX_VALUE或Integer.MIN_VALUE，起碼在編譯時間不會出問題。
既然這不是一個好的編程規範，為什麼Android中還要大量的使用整數集呢？原因就在於組件間通訊，組件之間要傳遞參數，但是Intent又只能放入基礎資料型別 (Elementary Data Type)，也就是說如果使用枚舉，那麼將無法用Intent傳遞給其他的組件，因為枚舉轉為整數很容易，但反過來整數轉成枚舉就不是那麼容易了。
所以，如果你的常量不需要在組件間來回的傳遞，那麼最好定義成為枚舉，否則，只能用整數集了。
關於組件一般的設計原則
1. 不要用組件實現某些介面，比如點擊介面，等等
因為組件是一個開銷非常巨大的對象，組件的繼承層次也非常的深，用組件實現介面，傳遞給調用者，就相當於用一個火車去運送一個小老鼠一樣，給了別人一個相當大的對象，但是僅有一個或二個方法是別人需要的。特別是對於Activity，不要去實現一些公用的介面比如View.OnClickListener，除了前面的原因以外，另外一個就是你的onClick必須用條件來區分點擊的是哪個UI元素，這很難維護，還有一個原因就是Activity的對象不是很穩定，因為系統的某些事件如轉屏，語言切換等等會把Activity殺死並重新建立一個執行個體，所以有可能會引發問題，雖然看起來Activity還在，但是並不同一個執行個體，如果某些東西與具體執行個體相關，就會引發問題，要麼程式不正常工作，要麼有RuntimeException。還有可能引發記憶體流失，因為送給使用者的介面對象都是Activity的執行個體引用，一旦某個引用超過Activity的生命週期，就會造成記憶體流失。
推薦的做法是用匿名內部類來實現介面，如果其他地方需要對此介面對象的操作，可以聲明一個成員變數或者一個內部類，這樣也方便Activity來控制，以保證所有東西都生存在Activity的生存周期之內。
2. 少用Service
組件Service並沒有傳說中的好用，而且它還會讓你的程式退出頁面後仍然在後台跑，占系統資源不說，還會被罵（看看這些文章吧），因為Service的生命週期是由系統來控制，我們無法幹預，即使你確切的知道某些時候你已經完全不用它了。用Activity和線程就可以完成絕大多數操作，而且你還能做到讓所有線程都在Activity的控制之內，讓它們都活在Activity的生命週期之內。另外的原因就是，因為線程都屬於自建的類，或者普通的Java類，可以應用物件導向，因為沒有了組件通訊的限制。
3. 利用ContentProvider來做複雜資料結構的通訊工具
ContentProvider和SQLiteDatabase儲存的就是結構化資料，相當於一個資料結構，它的引用就是它的Uri，任何組件通過Uri就可獲得此資料結構。它有如下優點：
1. 可以方便的在組件間傳遞
因為資料實際是在資料庫中，你在組件間僅傳遞其地址Uri即可，任何組件或任何持有Context的類都可以方便的擷取它，無論從實用性還是從效率上講，這比用Intent傳，或者實際傳送資料結構對象來得快。
2. ContentProvider組件有自己的進程和線程，不會有線程同步問題
外部都是通過ContentResolver來訪問ContentProvider，因此ContentProvider對外界來講是一樣的，訪問方式相同，自然就不會有線程同步之類的問題。
3. ContentProvider可以進行封裝，從而使資料操作更加方便
因為ContentProvier提供統一的介面，你可以利用資料自身的特點，在實現這些介面時進行一些封裝，比如添加預設值等等。
4. ContentProvider可以用作隊列或堆棧
因為每一行都是一個結構化資料，每一行的資料插入的順序又是按先後順序，所以這完全可以當做一個隊列，或一個堆棧。

可以參考原生Mms中資訊的發送流程，資訊從使用者點擊發送就寫入資料庫，然後一路把其Uri在各個組件間中傳遞，每個組件更新資訊的狀態，直到最後發送。還有DownloadProvider，Android中預設的下載，應用程式通過DownloadManager提交一個Request，但實際做下載的是DownloadService，而DownloadServer是在packages/provider/DownloadProvider中，是一個完全獨立的進程。DownloadManager僅是把一個Request寫入DownloadProvider中，這個Request包含下載一個東西的相關資訊如URL等。DownloadService僅是監聽DownloadProvider的變化，一旦有新資料插入，就建立線程讀出此Request，然後開始下載。下載的同時，也是把資料直接更新到DownloadProvider中，這樣UI就可以顯示進度等資訊。這一過程涉及二個進程，至少三個組件：提交Request的使用者進程和DownloadProvider進程，DownloadManager（是一個公用API），DownloadService（單獨進程，私人的package）和DownloadList(在DownloadProvider包內部，用於顯示下載進度的UI），這些組件之間沒有直接的通訊，它們都是圍繞著ContentProvider。同時這裡的ContentProvider也被用做下載請求的隊列，DownloadManager可以不斷的向其中加入請求，DownloadService會監聽其變化從其中取出資料然後做下載。
別說Android開發很簡單
雖然Android上手很容易，但是要想寫出優質的代碼並不簡單，分裂現象，片段化，系統架構等等都給很多事情加大了難度。可以看一下原生應用中的主要的Activity代碼量都在5000行以上，它們的介面比較複雜，是主要核心商務邏輯所在，這些Activity控制的東西比較多，所以很臃腫。當然這裡的主要原因，還是未能進行良好的設計和重構。比如ICS中的Browser就做的好一些，它的BrowserActivity只有幾百行的代碼，但以前的代碼卻是6000多行，現在它把各種商務邏輯分別拆開，Activity只負責接收Frameworks層的回調，所有的商務邏輯控制交由Controller來完成，而Controller只負責Tab的管理，菜單等的管理。具體的菜單和布局解析度相關的東西又交由PhoneUi來處理。下載的處理由DownloadHandler來處理，等等。原來這些所有的事情都放在了BrowserActivity中的，可以想像原來它裡面的邏輯會是多麼的亂，維護起來會是多麼的痛苦。當然，現在的設計也還有待提高，因為類之間的耦合依然很大，比如Controller中持有PhoneUi對象，但是PhoneUi對象又持有Controller，等等現象。很多時候會出現相互調用的情況，這是相當難以維護的，也破壞了相當多的設計原則。

總之，凡是程式，如果要想寫的好，都需要投稿額外的精力，平台雖然有優劣但更重要的是對代碼投入的精力。但現在可悲的是，Android平台贏利不理想，加之片段化和浮躁的心理，使得很多應用都在一二個月內做出來，所以整個Android生態系統中的應用品質都不高，更為嚴重的是反編譯和複製，很多人都是把應用抓下來，反編譯然後改了改就是一個新的應用，越是如此不關注品質，使用者就越不買帳，開發人員無法贏利，就越難投入精力做好應用，如此進入了一個惡性迴圈。