深入理解Android組件間通信機(jī)制對面向?qū)ο筇匦缘挠绊懺斀?/h1>
更新時(shí)間：2013年05月21日 11:34:59 投稿：jingxian
本篇文章是對Android組件間通信機(jī)制對面向?qū)ο筇匦缘挠绊戇M(jìn)行了詳細(xì)的分析介紹，需要的朋友參考下
組件的特點(diǎn)
對于Android的四大組件Activity, Service, ContentProvider和Service，不能有Setter和Getter，也不能給組件添加接口。原因是組件都是給系統(tǒng)框架調(diào)用的，開發(fā)者只能實(shí)現(xiàn)其規(guī)定的回調(diào)接口，組件的創(chuàng)建與銷毀都是由系統(tǒng)框架控制的，開發(fā)者不能強(qiáng)行干預(yù)，更沒有辦法獲取組件的對象。比如Activity，Service，BroadcastReceiver，你沒有辦法去創(chuàng)建一個(gè)Activity，Service或BroadcastReceiver，然后像使用其他類那樣的調(diào)用其上的接口與其通信，用Setters和Getters改變屬性等等。這也決定了，組件之間通信只能用系統(tǒng)支持的Intent。而Intent只能傳遞基本數(shù)據(jù)類型和Uri等一些常見的數(shù)據(jù)類型。Intent只支持傳遞內(nèi)置類型和一些限制類型，這就導(dǎo)致了組件之間的數(shù)據(jù)傳遞必須都是基本類型，所以枚舉類型無法使用。
多態(tài)無法實(shí)現(xiàn)
比如你有一個(gè)Service用于在后臺執(zhí)行UI中發(fā)來的請求，這些請求有些是做數(shù)據(jù)請求，有些是做數(shù)據(jù)分析，等等。這里可以用多態(tài)，定義一個(gè)統(tǒng)一的Transaction類，然后再為每種特定的Transaction類型，Transaction中統(tǒng)一接口process()用于實(shí)際的處理，理想的情況是，Service接收一個(gè)Transaction對象，然后調(diào)用其process()，沒有必要知道具體的類型，UI創(chuàng)建具體的一個(gè)類型對象然后交由Service來處理。但是這在Android當(dāng)中是無法實(shí)現(xiàn)的，因?yàn)镮ntent通信機(jī)制所限，因?yàn)樗荒苤苯觽鬟fTransaction對象。所以，Service必須要知道具體的類型。原生應(yīng)用Mms中就有如此的現(xiàn)象，在transaction包中TransactionService是處理服務(wù)，UI發(fā)送到Service的只是區(qū)別不同Transaction的Id（一個(gè)整數(shù)），Service查看不同的Id創(chuàng)建不同的Transaction對象，然后調(diào)用process()對其處理。
建議：自己實(shí)現(xiàn)一個(gè)類似Service的服務(wù)類，在其內(nèi)用Handler，Thread和Looper讓其長時(shí)間運(yùn)行。這樣就沒有組件間通信的限制，你可以像正常使用Java對象那樣來使用這個(gè)服務(wù)類，向其傳遞自定義的處理請求:
復(fù)制代碼 代碼如下:
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中就可以創(chuàng)建此Server的對象，然后使用它：
復(fù)制代碼 代碼如下:
TransactionServer server = new TransactionServer();
Transaction updateRequest = new UpdateTransaction();
server.execute(updateRequest);
另外，用AIDL與Service通信，雖可以獲取Service的對象引用，可以直接調(diào)用Service的方法，但這個(gè)也有限制，對于AIDL的接口，所有的參數(shù)和返回類型都必須是基本數(shù)據(jù)
據(jù)類型，不能有對象。原因也好理解，因?yàn)锳IDL也是要通過IPC的，即便Service與Activity在同一個(gè)進(jìn)程內(nèi)，所以本質(zhì)上它與Intent通信機(jī)制無區(qū)別。
組件間的通信機(jī)制決定了Android的封裝性，先來看一些實(shí)例：
復(fù)制代碼 代碼如下:
Intent i = new Intent(Intent.ACTION_VIEW);
i.setDataAndType(uri, "text/html");
startActivity(i);
這在Android當(dāng)中是再常見不過的了。
為你必須把字串，參數(shù)等直接寫入到Intent或IntentFilter當(dāng)中。例如：
復(fù)制代碼 代碼如下:
Intent i = new Intent("android.contacts.action.MULTIPLECONTACTSLISTS");
i.setExtra("request_type", 3);
<intent-filter>
<action android:name="android.contacts.action.MULTIPLECONTACTSLISTS" />
</intent-filter>
當(dāng)然，可以再好一點(diǎn)，就是：
Intent i = new Intent(Contacts.ACTION_GET_CONTACTS);
但是在AndroidManifest中的IntentFilter還是要寫字串常量（Literal Strings），這樣就有一個(gè)問題，就是即使你寫錯(cuò)了，編譯器不會提醒你，直到你運(yùn)行的時(shí)候才會發(fā)現(xiàn)程序不正常工作，你調(diào)試啊，調(diào)試，最終發(fā)現(xiàn)是字串寫錯(cuò)了?；蛘?，activity的name寫錯(cuò)了，編譯器同樣不會提醒你，但你運(yùn)行時(shí)卻因找不到類而報(bào)出RuntimeException。
建議：盡可能在所有作用域內(nèi)定義常量，以讓組件間接口保持一致性，特別是對于字串常量，一定要在二個(gè)組件都可見的作用域內(nèi)定義常量，否則將會有維護(hù)的麻煩。
例子：intent.putExtra("request_type", 3); --> intent.putExtra(TargetActivity.REQUEST_TYPE, TargetActivity.NO_BACKGROUND);否則，特別是當(dāng)目標(biāo)組件不在同一個(gè)包內(nèi)，或距離很遠(yuǎn)時(shí)，如果另一方改了，編譯時(shí)不會有錯(cuò)，但程序不會正常工作，從而引發(fā)難以發(fā)覺的Bug。
無法在組件間傳遞自定義的數(shù)據(jù)結(jié)構(gòu)
如前面所述，因?yàn)闊o法獲取組件的對象的引用，所以你無法向其設(shè)置數(shù)據(jù)，當(dāng)然，可以用靜態(tài)方法，但是不優(yōu)雅且難以維護(hù)（對于Service倒是可以通過AIDL方式獲取Service對象的引用，然后調(diào)用其方法來添加數(shù)據(jù)）。又因?yàn)镮ntent只能攜帶基本的數(shù)據(jù)類型，所以對于自定義的數(shù)據(jù)結(jié)構(gòu)想要在組件間傳遞就特別的麻煩。當(dāng)然你可以以讓數(shù)據(jù)結(jié)構(gòu)實(shí)現(xiàn)Parcleable接口，但是用起來也相當(dāng)?shù)穆闊?br />建議：
1. 盡可能的避免使用自定義數(shù)據(jù)結(jié)構(gòu)，特別是除了Setters和Getters以外不具有其他行為的數(shù)據(jù)結(jié)構(gòu)
對于結(jié)構(gòu)化的數(shù)據(jù)，為其定義ContentProvider，把數(shù)據(jù)寫入SQLite數(shù)據(jù)庫，這樣數(shù)據(jù)庫表中的每行數(shù)據(jù)都相當(dāng)于是一個(gè)數(shù)據(jù)對象，每一列都是其屬性。因?yàn)锳ndroid的組件與SQLite數(shù)據(jù)庫的粘性很大，每個(gè)組件都可以很方便的從數(shù)據(jù)庫中獲取數(shù)據(jù)，再通過Cursor等工具來操作數(shù)據(jù)。最最重要的是這很方便在組件間傳遞數(shù)據(jù)，因數(shù)ContentProvider的訪問都是通過Uri來實(shí)現(xiàn)的，而Uri又可以與Intent無縫接合，Uri可以方便的放入和從Intent中取出，每個(gè)組件又都可以直接訪問ContentProvider用Uri讀取數(shù)據(jù)，從而就可以實(shí)現(xiàn)組件間的無縫數(shù)據(jù)傳遞。
2. 盡可能的不要在組件之間傳遞數(shù)據(jù)
不要用太多的Activity，Service也能免則免，Activity＋線程可能解決大部分問題，當(dāng)然了，線程也不是那么好用的，特別是在Android里面。
3. 避免在組件之間傳遞自定義數(shù)據(jù)結(jié)構(gòu)
如前所述，組件之間最好直接傳遞基本數(shù)據(jù)和Intent支持的數(shù)據(jù)類型。對于自定義的數(shù)據(jù)結(jié)構(gòu)，要么不定義數(shù)據(jù)結(jié)構(gòu)，要么不要在組件間傳遞，否則會很麻煩，雖然可能以實(shí)現(xiàn)Parcelable接口，但是效率和操作的方便性上都會大打折扣。
關(guān)于枚舉和整數(shù)集
先前一篇<Android開發(fā)筆記之:用Enum(枚舉類型)取代整數(shù)集的應(yīng)用詳解>曾說要盡量使用枚舉(enum)代替整數(shù)集(ints)，而且很多編程書籍(Effective Java)也建議用枚舉代替整數(shù)集，這其中的好處就是降低出錯(cuò)率，把運(yùn)行時(shí)的檢查可以放到編譯時(shí)，因?yàn)檎麛?shù)的范圍較大，你可傳遞任意的整數(shù)，直到運(yùn)行時(shí)才會檢測或產(chǎn)生問題，但是枚舉會在編譯時(shí)檢查類型，如果不是合法的枚舉，編譯器會報(bào)怨。
但是我們可以看到，在Android中的情況卻很差，Android中大量的使用了整數(shù)集，系統(tǒng)定義了大量的整數(shù)集，很多參數(shù)也都是整數(shù)，雖然正確的方法都是向這些API傳遞其所定義的整數(shù)常量，但是你如果傳個(gè)Integer.MAX_VALUE或Integer.MIN_VALUE，起碼在編譯時(shí)不會出問題。
既然這不是一個(gè)好的編程規(guī)范，為什么Android中還要大量的使用整數(shù)集呢？原因就在于組件間通信，組件之間要傳遞參數(shù)，但是Intent又只能放入基本數(shù)據(jù)類型，也就是說如果使用枚舉，那么將無法用Intent傳遞給其他的組件，因?yàn)槊杜e轉(zhuǎn)為整數(shù)很容易，但反過來整數(shù)轉(zhuǎn)成枚舉就不是那么容易了。
所以，如果你的常量不需要在組件間來回的傳遞，那么最好定義成為枚舉，否則，只能用整數(shù)集了。
關(guān)于組件一般的設(shè)計(jì)原則
1. 不要用組件實(shí)現(xiàn)某些接口，比如點(diǎn)擊接口，等等
因?yàn)榻M件是一個(gè)開銷非常巨大的對象，組件的繼承層次也非常的深，用組件實(shí)現(xiàn)接口，傳遞給調(diào)用者，就相當(dāng)于用一個(gè)火車去運(yùn)送一個(gè)小老鼠一樣，給了別人一個(gè)相當(dāng)大的對象，但是僅有一個(gè)或二個(gè)方法是別人需要的。特別是對于Activity，不要去實(shí)現(xiàn)一些公共的接口比如View.OnClickListener，除了前面的原因以外，另外一個(gè)就是你的onClick必須用條件來區(qū)分點(diǎn)擊的是哪個(gè)UI元素，這很難維護(hù)，還有一個(gè)原因就是Activity的對象不是很穩(wěn)定，因?yàn)橄到y(tǒng)的某些事件如轉(zhuǎn)屏，語言切換等等會把Activity終止并重新創(chuàng)建一個(gè)實(shí)例，所以有可能會引發(fā)問題，雖然看起來Activity還在，但是并不同一個(gè)實(shí)例，如果某些東西與具體實(shí)例相關(guān)，就會引發(fā)問題，要么程序不正常工作，要么有RuntimeException。還有可能引發(fā)內(nèi)存泄漏，因?yàn)樗徒o使用者的接口對象都是Activity的實(shí)例引用，一旦某個(gè)引用超過Activity的生命周期，就會造成內(nèi)存泄漏。
推薦的做法是用匿名內(nèi)部類來實(shí)現(xiàn)接口，如果其他地方需要對此接口對象的操作，可以聲明一個(gè)成員變量或者一個(gè)內(nèi)部類，這樣也方便Activity來控制，以保證所有東西都生存在Activity的生存周期之內(nèi)。
2. 少用Service
組件Service并沒有傳說中的好用，而且它還會讓你的程序退出頁面后仍然在后臺跑，占系統(tǒng)資源不說，還會被罵（看看這些文章吧），因?yàn)镾ervice的生命周期是由系統(tǒng)來控制，我們無法干預(yù)，即使你確切的知道某些時(shí)候你已經(jīng)完全不用它了。用Activity和線程就可以完成絕大多數(shù)操作，而且你還能做到讓所有線程都在Activity的控制之內(nèi)，讓它們都活在Activity的生命周期之內(nèi)。另外的原因就是，因?yàn)榫€程都屬于自建的類，或者普通的Java類，可以應(yīng)用面向?qū)ο?，因?yàn)闆]有了組件通信的限制。
3. 利用ContentProvider來做復(fù)雜數(shù)據(jù)結(jié)構(gòu)的通信工具
ContentProvider和SQLiteDatabase存儲的就是結(jié)構(gòu)化數(shù)據(jù)，相當(dāng)于一個(gè)數(shù)據(jù)結(jié)構(gòu)，它的引用就是它的Uri，任何組件通過Uri就可獲得此數(shù)據(jù)結(jié)構(gòu)。它有如下優(yōu)點(diǎn)：
1. 可以方便的在組件間傳遞
因?yàn)閿?shù)據(jù)實(shí)際是在數(shù)據(jù)庫中，你在組件間僅傳遞其地址Uri即可，任何組件或任何持有Context的類都可以方便的獲取它，無論從實(shí)用性還是從效率上講，這比用Intent傳，或者實(shí)際傳送數(shù)據(jù)結(jié)構(gòu)對象來得快。
2. ContentProvider組件有自己的進(jìn)程和線程，不會有線程同步問題
外部都是通過ContentResolver來訪問ContentProvider，因此ContentProvider對外界來講是一樣的，訪問方式相同，自然就不會有線程同步之類的問題。
3. ContentProvider可以進(jìn)行封裝，從而使數(shù)據(jù)操作更加方便
因?yàn)镃ontentProvier提供統(tǒng)一的接口，你可以利用數(shù)據(jù)自身的特點(diǎn)，在實(shí)現(xiàn)這些接口時(shí)進(jìn)行一些封裝，比如添加默認(rèn)值等等。
4. ContentProvider可以用作隊(duì)列或堆棧
因?yàn)槊恳恍卸际且粋€(gè)結(jié)構(gòu)化數(shù)據(jù)，每一行的數(shù)據(jù)的順序又是按先后順序，所以這完全可以當(dāng)做一個(gè)隊(duì)列，或一個(gè)堆棧。
可以參考原生Mms中信息的發(fā)送流程，信息從用戶點(diǎn)擊發(fā)送就寫入數(shù)據(jù)庫，然后一路把其Uri在各個(gè)組件間中傳遞，每個(gè)組件更新信息的狀態(tài)，直到最后發(fā)送。還有DownloadProvider，Android中默認(rèn)的下載，應(yīng)用程序通過DownloadManager提交一個(gè)Request，但實(shí)際做下載的是DownloadService，而DownloadServer是在packages/provider/DownloadProvider中，是一個(gè)完全的進(jìn)程。DownloadManager僅是把一個(gè)Request寫入DownloadProvider中，這個(gè)Request包含下載一個(gè)東西的相關(guān)信息如URL等。DownloadService僅是DownloadProvider的變化，一旦有新數(shù)據(jù)，就創(chuàng)建線程讀出此Request，然后開始下載。下載的同時(shí)，也是把數(shù)據(jù)直接更新到DownloadProvider中，這樣UI就可以顯示進(jìn)度等信息。這一過程涉及二個(gè)進(jìn)程，至少三個(gè)組件：提交Request的用戶進(jìn)程和DownloadProvider進(jìn)程，DownloadManager（是一個(gè)公共API），DownloadService（單獨(dú)進(jìn)程，私有的package）和DownloadList(在DownloadProvider包內(nèi)部，用于顯示下載進(jìn)度的UI），這些組件之間沒有直接的通信，它們都是圍繞著ContentProvider。同時(shí)這里的ContentProvider也被用做下載請求的隊(duì)列，DownloadManager可以不斷的向其中加入請求，DownloadService會其變化從其中取出數(shù)據(jù)然后做下載。
別說Android開發(fā)很簡單
雖然Android上手很容易，但是要想寫出優(yōu)質(zhì)的代碼并不簡單，現(xiàn)象碎片化，系統(tǒng)架構(gòu)等等都給很多事情加大了難度?？梢钥匆幌略鷳?yīng)用中的主要的Activity代碼量都在5000行以上，它們的界面比較復(fù)雜，是主要核心業(yè)務(wù)邏輯所在，這些Activity控制的東西比較多，所以很臃腫。當(dāng)然這里的主要原因，還是未能進(jìn)行良好的設(shè)計(jì)和重構(gòu)。比如ICS中的Browser就做的好一些，它的BrowserActivity只有幾百行的代碼，但以前的代碼卻是6000多行，現(xiàn)在它把各種業(yè)務(wù)邏輯分別拆開，Activity只負(fù)責(zé)接收Frameworks層的回調(diào)，所有的業(yè)務(wù)邏輯控制交由Controller來完成，而Controller只負(fù)責(zé)Tab的管理，菜單等的管理。具體的菜單和布局分辨率相關(guān)的東西又交由PhoneUi來處理。下載的處理由DownloadHandler來處理，等等。原來這些所有的事情都放在了BrowserActivity中的，可以想像原來它里面的邏輯會是多么的亂，維護(hù)起來會是多么的痛苦。當(dāng)然，現(xiàn)在的設(shè)計(jì)也還有待提高，因?yàn)轭愔g的耦合依然很大，比如Controller中持有PhoneUi對象，但是PhoneUi對象又持有Controller，等等現(xiàn)象。很多時(shí)候會出現(xiàn)相互調(diào)用的情況，這是相當(dāng)難以維護(hù)的，相當(dāng)多的設(shè)計(jì)原則。
總之，凡是程序，如果要想寫的好，都需要投稿額外的精力，平臺雖然有優(yōu)劣但更重要的是對代碼投入的精力。但現(xiàn)在可悲的是，Android平臺贏利不理想，加之碎片化和浮躁的心理，使得很多應(yīng)用都在一二個(gè)月內(nèi)做出來，所以整個(gè)Android生態(tài)系統(tǒng)中的應(yīng)用質(zhì)量都不高，更為嚴(yán)重的是反編譯和克隆，很多人都是把應(yīng)用抓下來，反編譯然后改了改就是一個(gè)新的應(yīng)用，越是如此不關(guān)注質(zhì)量，用戶就越不買帳，開發(fā)者無法贏利，就越難投入精力做好應(yīng)用，如此進(jìn)入了一個(gè)惡性循環(huán)。
相關(guān)文章
-
Android Glide圖片加載(加載監(jiān)聽、加載動(dòng)畫)
這篇文章主要為大家詳細(xì)介紹了Android Glide圖片加載的具體實(shí)現(xiàn)方法，包括加載監(jiān)聽、加載動(dòng)畫,具有一定的參考價(jià)值，感興趣的小伙伴們可以參考一下 2016-11-11
-
Android開發(fā)之App widget用法實(shí)例分析
這篇文章主要介紹了Android開發(fā)之App widget用法,結(jié)合實(shí)例形式詳細(xì)分析了Android開發(fā)中使用App widget組件的具體步驟與相關(guān)技巧,具有一定參考借鑒價(jià)值,需要的朋友可以參考下 2016-06-06
-
Android中自定義ContentProvider實(shí)例
應(yīng)用A(TestBaidu)調(diào)用另外一個(gè)應(yīng)用(TestContentProvider)中的自定義ContentProvider，具體實(shí)現(xiàn)如下，感興趣的朋友可以參考下哈 2013-06-06
-
這篇文章主要為大家介紹了FFmpeg?音頻可視化解碼流程詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步，早日升職加薪 2022-10-10
-
這篇文章主要為大家介紹了Android開發(fā)input問題解決分析，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步，早日升職加薪 2022-11-11
-
基于Android AppWidgetProvider的使用介紹
本篇文章小編為大家介紹，基于Android AppWidgetProvider的使用。需要的朋友參考下 2013-04-04
-
Flutter使用sqflite處理數(shù)據(jù)表變更的方法詳解
了解過數(shù)據(jù)庫的同學(xué)應(yīng)該會知道，數(shù)據(jù)表結(jié)構(gòu)是可能發(fā)生改變的。所以本文為大家介紹了Flutter?使用?sqflite?處理數(shù)據(jù)表變更的版本升級處理方法，感興趣的可以了解一下 2023-04-04
-
Android ActivityManagerService啟動(dòng)流程詳解
這篇文章主要介紹了Android ActivityManagerService啟動(dòng)流程，AMS，即ActivityManagerService，是安卓java framework的一個(gè)服務(wù)，運(yùn)行在system_server進(jìn)程。此服務(wù)十分重要，因?yàn)樗芾碇沧康乃拇蠼M件，是安卓APP開發(fā)者最常接觸到的一個(gè)服務(wù) 2023-02-02
-
本文主要介紹 Android 中的注解，這里整理詳細(xì)的資料來說明Android注解是如何使用，提高編程效率，有興趣的小伙伴可以參考下 2016-08-08
-
這篇文章主要為大家介紹了Android?View的事件體系教程詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步早日升職加薪 2022-03-03
最新評論
組件的特點(diǎn)
對于Android的四大組件Activity, Service, ContentProvider和Service，不能有Setter和Getter，也不能給組件添加接口。原因是組件都是給系統(tǒng)框架調(diào)用的，開發(fā)者只能實(shí)現(xiàn)其規(guī)定的回調(diào)接口，組件的創(chuàng)建與銷毀都是由系統(tǒng)框架控制的，開發(fā)者不能強(qiáng)行干預(yù)，更沒有辦法獲取組件的對象。比如Activity，Service，BroadcastReceiver，你沒有辦法去創(chuàng)建一個(gè)Activity，Service或BroadcastReceiver，然后像使用其他類那樣的調(diào)用其上的接口與其通信，用Setters和Getters改變屬性等等。這也決定了，組件之間通信只能用系統(tǒng)支持的Intent。而Intent只能傳遞基本數(shù)據(jù)類型和Uri等一些常見的數(shù)據(jù)類型。Intent只支持傳遞內(nèi)置類型和一些限制類型，這就導(dǎo)致了組件之間的數(shù)據(jù)傳遞必須都是基本類型，所以枚舉類型無法使用。
多態(tài)無法實(shí)現(xiàn)
比如你有一個(gè)Service用于在后臺執(zhí)行UI中發(fā)來的請求，這些請求有些是做數(shù)據(jù)請求，有些是做數(shù)據(jù)分析，等等。這里可以用多態(tài)，定義一個(gè)統(tǒng)一的Transaction類，然后再為每種特定的Transaction類型，Transaction中統(tǒng)一接口process()用于實(shí)際的處理，理想的情況是，Service接收一個(gè)Transaction對象，然后調(diào)用其process()，沒有必要知道具體的類型，UI創(chuàng)建具體的一個(gè)類型對象然后交由Service來處理。但是這在Android當(dāng)中是無法實(shí)現(xiàn)的，因?yàn)镮ntent通信機(jī)制所限，因?yàn)樗荒苤苯觽鬟fTransaction對象。所以，Service必須要知道具體的類型。原生應(yīng)用Mms中就有如此的現(xiàn)象，在transaction包中TransactionService是處理服務(wù)，UI發(fā)送到Service的只是區(qū)別不同Transaction的Id（一個(gè)整數(shù)），Service查看不同的Id創(chuàng)建不同的Transaction對象，然后調(diào)用process()對其處理。
建議：自己實(shí)現(xiàn)一個(gè)類似Service的服務(wù)類，在其內(nèi)用Handler，Thread和Looper讓其長時(shí)間運(yùn)行。這樣就沒有組件間通信的限制，你可以像正常使用Java對象那樣來使用這個(gè)服務(wù)類，向其傳遞自定義的處理請求:
復(fù)制代碼 代碼如下:
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中就可以創(chuàng)建此Server的對象，然后使用它：
復(fù)制代碼 代碼如下:
TransactionServer server = new TransactionServer();
Transaction updateRequest = new UpdateTransaction();
server.execute(updateRequest);
另外，用AIDL與Service通信，雖可以獲取Service的對象引用，可以直接調(diào)用Service的方法，但這個(gè)也有限制，對于AIDL的接口，所有的參數(shù)和返回類型都必須是基本數(shù)據(jù)
據(jù)類型，不能有對象。原因也好理解，因?yàn)锳IDL也是要通過IPC的，即便Service與Activity在同一個(gè)進(jìn)程內(nèi)，所以本質(zhì)上它與Intent通信機(jī)制無區(qū)別。
組件間的通信機(jī)制決定了Android的封裝性，先來看一些實(shí)例：
復(fù)制代碼 代碼如下:
Intent i = new Intent(Intent.ACTION_VIEW);
i.setDataAndType(uri, "text/html");
startActivity(i);
這在Android當(dāng)中是再常見不過的了。
為你必須把字串，參數(shù)等直接寫入到Intent或IntentFilter當(dāng)中。例如：
復(fù)制代碼 代碼如下:
Intent i = new Intent("android.contacts.action.MULTIPLECONTACTSLISTS");
i.setExtra("request_type", 3);
<intent-filter>
<action android:name="android.contacts.action.MULTIPLECONTACTSLISTS" />
</intent-filter>
當(dāng)然，可以再好一點(diǎn)，就是：
Intent i = new Intent(Contacts.ACTION_GET_CONTACTS);
但是在AndroidManifest中的IntentFilter還是要寫字串常量（Literal Strings），這樣就有一個(gè)問題，就是即使你寫錯(cuò)了，編譯器不會提醒你，直到你運(yùn)行的時(shí)候才會發(fā)現(xiàn)程序不正常工作，你調(diào)試啊，調(diào)試，最終發(fā)現(xiàn)是字串寫錯(cuò)了?；蛘?，activity的name寫錯(cuò)了，編譯器同樣不會提醒你，但你運(yùn)行時(shí)卻因找不到類而報(bào)出RuntimeException。
建議：盡可能在所有作用域內(nèi)定義常量，以讓組件間接口保持一致性，特別是對于字串常量，一定要在二個(gè)組件都可見的作用域內(nèi)定義常量，否則將會有維護(hù)的麻煩。
例子：intent.putExtra("request_type", 3); --> intent.putExtra(TargetActivity.REQUEST_TYPE, TargetActivity.NO_BACKGROUND);否則，特別是當(dāng)目標(biāo)組件不在同一個(gè)包內(nèi)，或距離很遠(yuǎn)時(shí)，如果另一方改了，編譯時(shí)不會有錯(cuò)，但程序不會正常工作，從而引發(fā)難以發(fā)覺的Bug。
無法在組件間傳遞自定義的數(shù)據(jù)結(jié)構(gòu)
如前面所述，因?yàn)闊o法獲取組件的對象的引用，所以你無法向其設(shè)置數(shù)據(jù)，當(dāng)然，可以用靜態(tài)方法，但是不優(yōu)雅且難以維護(hù)（對于Service倒是可以通過AIDL方式獲取Service對象的引用，然后調(diào)用其方法來添加數(shù)據(jù)）。又因?yàn)镮ntent只能攜帶基本的數(shù)據(jù)類型，所以對于自定義的數(shù)據(jù)結(jié)構(gòu)想要在組件間傳遞就特別的麻煩。當(dāng)然你可以以讓數(shù)據(jù)結(jié)構(gòu)實(shí)現(xiàn)Parcleable接口，但是用起來也相當(dāng)?shù)穆闊?br />建議：
1. 盡可能的避免使用自定義數(shù)據(jù)結(jié)構(gòu)，特別是除了Setters和Getters以外不具有其他行為的數(shù)據(jù)結(jié)構(gòu)
對于結(jié)構(gòu)化的數(shù)據(jù)，為其定義ContentProvider，把數(shù)據(jù)寫入SQLite數(shù)據(jù)庫，這樣數(shù)據(jù)庫表中的每行數(shù)據(jù)都相當(dāng)于是一個(gè)數(shù)據(jù)對象，每一列都是其屬性。因?yàn)锳ndroid的組件與SQLite數(shù)據(jù)庫的粘性很大，每個(gè)組件都可以很方便的從數(shù)據(jù)庫中獲取數(shù)據(jù)，再通過Cursor等工具來操作數(shù)據(jù)。最最重要的是這很方便在組件間傳遞數(shù)據(jù)，因數(shù)ContentProvider的訪問都是通過Uri來實(shí)現(xiàn)的，而Uri又可以與Intent無縫接合，Uri可以方便的放入和從Intent中取出，每個(gè)組件又都可以直接訪問ContentProvider用Uri讀取數(shù)據(jù)，從而就可以實(shí)現(xiàn)組件間的無縫數(shù)據(jù)傳遞。
2. 盡可能的不要在組件之間傳遞數(shù)據(jù)
不要用太多的Activity，Service也能免則免，Activity＋線程可能解決大部分問題，當(dāng)然了，線程也不是那么好用的，特別是在Android里面。
3. 避免在組件之間傳遞自定義數(shù)據(jù)結(jié)構(gòu)
如前所述，組件之間最好直接傳遞基本數(shù)據(jù)和Intent支持的數(shù)據(jù)類型。對于自定義的數(shù)據(jù)結(jié)構(gòu)，要么不定義數(shù)據(jù)結(jié)構(gòu)，要么不要在組件間傳遞，否則會很麻煩，雖然可能以實(shí)現(xiàn)Parcelable接口，但是效率和操作的方便性上都會大打折扣。
關(guān)于枚舉和整數(shù)集
先前一篇<Android開發(fā)筆記之:用Enum(枚舉類型)取代整數(shù)集的應(yīng)用詳解>曾說要盡量使用枚舉(enum)代替整數(shù)集(ints)，而且很多編程書籍(Effective Java)也建議用枚舉代替整數(shù)集，這其中的好處就是降低出錯(cuò)率，把運(yùn)行時(shí)的檢查可以放到編譯時(shí)，因?yàn)檎麛?shù)的范圍較大，你可傳遞任意的整數(shù)，直到運(yùn)行時(shí)才會檢測或產(chǎn)生問題，但是枚舉會在編譯時(shí)檢查類型，如果不是合法的枚舉，編譯器會報(bào)怨。
但是我們可以看到，在Android中的情況卻很差，Android中大量的使用了整數(shù)集，系統(tǒng)定義了大量的整數(shù)集，很多參數(shù)也都是整數(shù)，雖然正確的方法都是向這些API傳遞其所定義的整數(shù)常量，但是你如果傳個(gè)Integer.MAX_VALUE或Integer.MIN_VALUE，起碼在編譯時(shí)不會出問題。
既然這不是一個(gè)好的編程規(guī)范，為什么Android中還要大量的使用整數(shù)集呢？原因就在于組件間通信，組件之間要傳遞參數(shù)，但是Intent又只能放入基本數(shù)據(jù)類型，也就是說如果使用枚舉，那么將無法用Intent傳遞給其他的組件，因?yàn)槊杜e轉(zhuǎn)為整數(shù)很容易，但反過來整數(shù)轉(zhuǎn)成枚舉就不是那么容易了。
所以，如果你的常量不需要在組件間來回的傳遞，那么最好定義成為枚舉，否則，只能用整數(shù)集了。
關(guān)于組件一般的設(shè)計(jì)原則
1. 不要用組件實(shí)現(xiàn)某些接口，比如點(diǎn)擊接口，等等
因?yàn)榻M件是一個(gè)開銷非常巨大的對象，組件的繼承層次也非常的深，用組件實(shí)現(xiàn)接口，傳遞給調(diào)用者，就相當(dāng)于用一個(gè)火車去運(yùn)送一個(gè)小老鼠一樣，給了別人一個(gè)相當(dāng)大的對象，但是僅有一個(gè)或二個(gè)方法是別人需要的。特別是對于Activity，不要去實(shí)現(xiàn)一些公共的接口比如View.OnClickListener，除了前面的原因以外，另外一個(gè)就是你的onClick必須用條件來區(qū)分點(diǎn)擊的是哪個(gè)UI元素，這很難維護(hù)，還有一個(gè)原因就是Activity的對象不是很穩(wěn)定，因?yàn)橄到y(tǒng)的某些事件如轉(zhuǎn)屏，語言切換等等會把Activity終止并重新創(chuàng)建一個(gè)實(shí)例，所以有可能會引發(fā)問題，雖然看起來Activity還在，但是并不同一個(gè)實(shí)例，如果某些東西與具體實(shí)例相關(guān)，就會引發(fā)問題，要么程序不正常工作，要么有RuntimeException。還有可能引發(fā)內(nèi)存泄漏，因?yàn)樗徒o使用者的接口對象都是Activity的實(shí)例引用，一旦某個(gè)引用超過Activity的生命周期，就會造成內(nèi)存泄漏。
推薦的做法是用匿名內(nèi)部類來實(shí)現(xiàn)接口，如果其他地方需要對此接口對象的操作，可以聲明一個(gè)成員變量或者一個(gè)內(nèi)部類，這樣也方便Activity來控制，以保證所有東西都生存在Activity的生存周期之內(nèi)。
2. 少用Service
組件Service并沒有傳說中的好用，而且它還會讓你的程序退出頁面后仍然在后臺跑，占系統(tǒng)資源不說，還會被罵（看看這些文章吧），因?yàn)镾ervice的生命周期是由系統(tǒng)來控制，我們無法干預(yù)，即使你確切的知道某些時(shí)候你已經(jīng)完全不用它了。用Activity和線程就可以完成絕大多數(shù)操作，而且你還能做到讓所有線程都在Activity的控制之內(nèi)，讓它們都活在Activity的生命周期之內(nèi)。另外的原因就是，因?yàn)榫€程都屬于自建的類，或者普通的Java類，可以應(yīng)用面向?qū)ο?，因?yàn)闆]有了組件通信的限制。
3. 利用ContentProvider來做復(fù)雜數(shù)據(jù)結(jié)構(gòu)的通信工具
ContentProvider和SQLiteDatabase存儲的就是結(jié)構(gòu)化數(shù)據(jù)，相當(dāng)于一個(gè)數(shù)據(jù)結(jié)構(gòu)，它的引用就是它的Uri，任何組件通過Uri就可獲得此數(shù)據(jù)結(jié)構(gòu)。它有如下優(yōu)點(diǎn)：
1. 可以方便的在組件間傳遞
因?yàn)閿?shù)據(jù)實(shí)際是在數(shù)據(jù)庫中，你在組件間僅傳遞其地址Uri即可，任何組件或任何持有Context的類都可以方便的獲取它，無論從實(shí)用性還是從效率上講，這比用Intent傳，或者實(shí)際傳送數(shù)據(jù)結(jié)構(gòu)對象來得快。
2. ContentProvider組件有自己的進(jìn)程和線程，不會有線程同步問題
外部都是通過ContentResolver來訪問ContentProvider，因此ContentProvider對外界來講是一樣的，訪問方式相同，自然就不會有線程同步之類的問題。
3. ContentProvider可以進(jìn)行封裝，從而使數(shù)據(jù)操作更加方便
因?yàn)镃ontentProvier提供統(tǒng)一的接口，你可以利用數(shù)據(jù)自身的特點(diǎn)，在實(shí)現(xiàn)這些接口時(shí)進(jìn)行一些封裝，比如添加默認(rèn)值等等。
4. ContentProvider可以用作隊(duì)列或堆棧
因?yàn)槊恳恍卸际且粋€(gè)結(jié)構(gòu)化數(shù)據(jù)，每一行的數(shù)據(jù)的順序又是按先后順序，所以這完全可以當(dāng)做一個(gè)隊(duì)列，或一個(gè)堆棧。
可以參考原生Mms中信息的發(fā)送流程，信息從用戶點(diǎn)擊發(fā)送就寫入數(shù)據(jù)庫，然后一路把其Uri在各個(gè)組件間中傳遞，每個(gè)組件更新信息的狀態(tài)，直到最后發(fā)送。還有DownloadProvider，Android中默認(rèn)的下載，應(yīng)用程序通過DownloadManager提交一個(gè)Request，但實(shí)際做下載的是DownloadService，而DownloadServer是在packages/provider/DownloadProvider中，是一個(gè)完全的進(jìn)程。DownloadManager僅是把一個(gè)Request寫入DownloadProvider中，這個(gè)Request包含下載一個(gè)東西的相關(guān)信息如URL等。DownloadService僅是DownloadProvider的變化，一旦有新數(shù)據(jù)，就創(chuàng)建線程讀出此Request，然后開始下載。下載的同時(shí)，也是把數(shù)據(jù)直接更新到DownloadProvider中，這樣UI就可以顯示進(jìn)度等信息。這一過程涉及二個(gè)進(jìn)程，至少三個(gè)組件：提交Request的用戶進(jìn)程和DownloadProvider進(jìn)程，DownloadManager（是一個(gè)公共API），DownloadService（單獨(dú)進(jìn)程，私有的package）和DownloadList(在DownloadProvider包內(nèi)部，用于顯示下載進(jìn)度的UI），這些組件之間沒有直接的通信，它們都是圍繞著ContentProvider。同時(shí)這里的ContentProvider也被用做下載請求的隊(duì)列，DownloadManager可以不斷的向其中加入請求，DownloadService會其變化從其中取出數(shù)據(jù)然后做下載。
別說Android開發(fā)很簡單
雖然Android上手很容易，但是要想寫出優(yōu)質(zhì)的代碼并不簡單，現(xiàn)象碎片化，系統(tǒng)架構(gòu)等等都給很多事情加大了難度?？梢钥匆幌略鷳?yīng)用中的主要的Activity代碼量都在5000行以上，它們的界面比較復(fù)雜，是主要核心業(yè)務(wù)邏輯所在，這些Activity控制的東西比較多，所以很臃腫。當(dāng)然這里的主要原因，還是未能進(jìn)行良好的設(shè)計(jì)和重構(gòu)。比如ICS中的Browser就做的好一些，它的BrowserActivity只有幾百行的代碼，但以前的代碼卻是6000多行，現(xiàn)在它把各種業(yè)務(wù)邏輯分別拆開，Activity只負(fù)責(zé)接收Frameworks層的回調(diào)，所有的業(yè)務(wù)邏輯控制交由Controller來完成，而Controller只負(fù)責(zé)Tab的管理，菜單等的管理。具體的菜單和布局分辨率相關(guān)的東西又交由PhoneUi來處理。下載的處理由DownloadHandler來處理，等等。原來這些所有的事情都放在了BrowserActivity中的，可以想像原來它里面的邏輯會是多么的亂，維護(hù)起來會是多么的痛苦。當(dāng)然，現(xiàn)在的設(shè)計(jì)也還有待提高，因?yàn)轭愔g的耦合依然很大，比如Controller中持有PhoneUi對象，但是PhoneUi對象又持有Controller，等等現(xiàn)象。很多時(shí)候會出現(xiàn)相互調(diào)用的情況，這是相當(dāng)難以維護(hù)的，相當(dāng)多的設(shè)計(jì)原則。
總之，凡是程序，如果要想寫的好，都需要投稿額外的精力，平臺雖然有優(yōu)劣但更重要的是對代碼投入的精力。但現(xiàn)在可悲的是，Android平臺贏利不理想，加之碎片化和浮躁的心理，使得很多應(yīng)用都在一二個(gè)月內(nèi)做出來，所以整個(gè)Android生態(tài)系統(tǒng)中的應(yīng)用質(zhì)量都不高，更為嚴(yán)重的是反編譯和克隆，很多人都是把應(yīng)用抓下來，反編譯然后改了改就是一個(gè)新的應(yīng)用，越是如此不關(guān)注質(zhì)量，用戶就越不買帳，開發(fā)者無法贏利，就越難投入精力做好應(yīng)用，如此進(jìn)入了一個(gè)惡性循環(huán)。
相關(guān)文章
-
Android Glide圖片加載(加載監(jiān)聽、加載動(dòng)畫)
這篇文章主要為大家詳細(xì)介紹了Android Glide圖片加載的具體實(shí)現(xiàn)方法，包括加載監(jiān)聽、加載動(dòng)畫,具有一定的參考價(jià)值，感興趣的小伙伴們可以參考一下2016-11-11 -
Android開發(fā)之App widget用法實(shí)例分析
這篇文章主要介紹了Android開發(fā)之App widget用法,結(jié)合實(shí)例形式詳細(xì)分析了Android開發(fā)中使用App widget組件的具體步驟與相關(guān)技巧,具有一定參考借鑒價(jià)值,需要的朋友可以參考下2016-06-06 -
Android中自定義ContentProvider實(shí)例
應(yīng)用A(TestBaidu)調(diào)用另外一個(gè)應(yīng)用(TestContentProvider)中的自定義ContentProvider，具體實(shí)現(xiàn)如下，感興趣的朋友可以參考下哈2013-06-06 - 這篇文章主要為大家介紹了FFmpeg?音頻可視化解碼流程詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步，早日升職加薪2022-10-10
- 這篇文章主要為大家介紹了Android開發(fā)input問題解決分析，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步，早日升職加薪2022-11-11
-
基于Android AppWidgetProvider的使用介紹
本篇文章小編為大家介紹，基于Android AppWidgetProvider的使用。需要的朋友參考下2013-04-04 -
Flutter使用sqflite處理數(shù)據(jù)表變更的方法詳解
了解過數(shù)據(jù)庫的同學(xué)應(yīng)該會知道，數(shù)據(jù)表結(jié)構(gòu)是可能發(fā)生改變的。所以本文為大家介紹了Flutter?使用?sqflite?處理數(shù)據(jù)表變更的版本升級處理方法，感興趣的可以了解一下2023-04-04 -
Android ActivityManagerService啟動(dòng)流程詳解
這篇文章主要介紹了Android ActivityManagerService啟動(dòng)流程，AMS，即ActivityManagerService，是安卓java framework的一個(gè)服務(wù)，運(yùn)行在system_server進(jìn)程。此服務(wù)十分重要，因?yàn)樗芾碇沧康乃拇蠼M件，是安卓APP開發(fā)者最常接觸到的一個(gè)服務(wù)2023-02-02 - 本文主要介紹 Android 中的注解，這里整理詳細(xì)的資料來說明Android注解是如何使用，提高編程效率，有興趣的小伙伴可以參考下2016-08-08
- 這篇文章主要為大家介紹了Android?View的事件體系教程詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步早日升職加薪2022-03-03