詳解Android Service 使用時的注意事項
最近有個項目剛好使用了Service,特別是AIDL遠程服務,經(jīng)過這次項目對Service有了更好的理解,在這里作個總結。
startService / bindService 混合使用
- 每一次調用 startService 都會回調onStartCommand,之后調用了stopService之后就會 destroy Service。即使有多個client啟動服務,那調用一次stopService 就能 destroy Service 。通過這種方式還有一個好處就是Service可以通過調用 stopSelf 主動退出。
- 第一次調用bindService 的時候才會回調 onBind,如果有多個client連接服務,在最后一個client調用unbindService時才會回調 onUnbind,并destroy Service。
如果startService / bindService 混合使用 那Service的生命同期會怎樣呢,其實只要記住以上的思路,這種問題很好理解。首先 startService 與 stopService 對應 ,沒有stopService 之前不會 destroy Service , bindService 與 unbindService對應 ,沒有 unbindService 前也不會destroy Service。
為服務添加權限
相信大家做的服務都是公共的,即所有應用都可以調用。但是如果我想我的服務只給特定的應用調用,應該如何設置呢?我們可以給服務添加權限。關于權限,Android系統(tǒng)給權限為了四個類別:
- 普通級: 這些權限并不能真正傷害到用戶(比如更換壁紙),當程序需要這些權限是,開發(fā)者不需要指定程序會自動賦予這些權限。
- 危險級: 這些權限可能會帶來真的傷害(比如打電話,打開網(wǎng)絡鏈接等),如果要使用它們需要開發(fā)者在AndroidManifest.xml中聲明對應的權限。
- 簽名級: 如果應用使用的是相同的簽名證書時,這些權限會自動授予給聲明或者創(chuàng)建這些權限的程序。設計這一層級權限的目的是方便組件間數(shù)據(jù)共享。
- 簽名/系統(tǒng)級: 和簽名級一樣,例外的是系統(tǒng)鏡像是自動獲取這些權限的,這一層級是專為設備制造商設計的。
<uses-permission android:name="android.permission.custom.XXX"/>
如果我們想讓自己開發(fā)的Service只能被特定的Client調用,那就可以添加自定義的權限。比如危險級,我們可以在AndroidManifest.xml中聲明對應的權限,只有應用也設置了這個權限,才能正常啟動服務。
關于AIDL遠程服務
所謂的AIDL遠程服務 就是運行在另一個進程的服務,平時我們調用的服務都運行在主線程。要使用AIDL服務就必須寫AIDL接口,向外暴露接口就可以與遠程服務進行交互了。對于AIDL有如下幾個值得注意的地方:
- AIDL接口的函數(shù)都不支持重載,即函數(shù)名不能一樣,即使函數(shù)參數(shù)個數(shù)不一樣。
- AIDL接口傳遞的參數(shù)只有是基本數(shù)據(jù)類型、String 和CharSequence、List 和 Map、實現(xiàn)android.os.Parcelable 接口的類。
- 既然AIDL是在另一個進程的服務,那客戶端調用的AIDL接口是否堵塞? 答案是肯定的。如果不加 oneway 修飾符,那客戶端調用的接口都是堵塞的,但是oneway修飾符也有限制,就是oneway接口下面的方法都必須是返回void類型,不能返回其他類型的數(shù)據(jù)。
AIDL的接口如何升級?
在做一個比較大型的項目,那項目會不斷迭代,那就有可能增加、修改AIDL接口,那如何保證AIDL接口和老的接口不會混亂呢,根據(jù)我的經(jīng)驗有如下總結:
- 對于增刪參數(shù)的接口:AIDL函數(shù)的訪問會檢測參數(shù),Client有參數(shù)的接口可以調用Service的接口(不管有無參數(shù)),反過來,Client的接口沒參數(shù)就只能調用Service沒有參數(shù)的接口。比如我們的新接口定義函數(shù)添加了參數(shù),那client必須同時或提前修改,不然我們發(fā)布了新接口的Service應用,Client就不能調用了,但是Client用新接口是可以去訪問老接口的服務的。
- 對于增刪函數(shù)的接口:服務端增加函數(shù)并不影響客戶端,相反客戶端增加服務端沒有的接口就會訪問無效果,如果客戶端增加接口有返回值就返回默認值。
Service管理多個客戶端
如果Service有多個客戶端,如何安全地與它們通信呢?如何給各個客戶端回調結果呢? 在這里我要說說我在最近項目出現(xiàn)的一個問題,我在項目中要做一個公共的服務,類似于指紋解鎖,其它應用通過調用我的服務來獲取結果,我設計了start(callback), stop()兩個接口,一開始我就用單回調的方式,即在代碼中定義一個callback的屬性,誰調用了start就把callback設置成誰,只有最后一個調用start的Client能夠獲得回調,代碼如下 :
private Callbak mCallback; public void start(Callback callback) { this.mCallback = callback; } public void stop() { this.mCallback = null; }
這種方式,在單個應用時是很有效的,在多個應用時,只要應用能按順序執(zhí)行start、stop 那這個接口的設計也沒什么問題。但是事情沒想象中那么簡單,如果Client1調用了start,跟著Client2也調用了start,這時Client1 要stop,那會怎樣,那整個服務都stop了。這個就是我設計的服務中出現(xiàn)的大問題,之后我想著為我的服務接口作一些改變,以適應這種多應用的不按順序的調用 。我第一個想法就是用register、unregister的方式,用一個list收集所有的callback ,回調時可以輪循,stop時也可以通過判斷l(xiāng)ist的個數(shù),如果是小于等于1,那就執(zhí)行stop :
private List<Callbak> mCallbacks; public void start(Callback callback) { mCallbacks.add(callback); } public void stop(Callback callback) { mCallbacks.remove(callback); if(list.size() >= 1) return; }
考慮到接口的升級,這個改動是最小的,只給stop添加了一個參數(shù)。但是這個方式也有毛病,我們服務對Callback的引用是強引用,如果Client異常退出了,那引用還在并且會越積越多,在回調的時候,也可能出現(xiàn)DeadObjectException的錯誤。通過網(wǎng)絡查找資料,我找到了RemoteCallbackList,RemoteCallbackList也是一個列表,保存的是回調接口,使用Link-To-Death回調 (在Sevice中接受到這個Binder對象,并且使用 binder.linkToDeath(),注冊一個DeathRecipient回調;實現(xiàn)DeathRecipient。當Client意外退出的時候,DeathRecipient.binderDied()將被回調,我們可以在這里釋放相關的資源。)。最終代碼如下:
private RemoteCallbackList<Callback> mCallbacks = new RemoteCallbackList<>(); public void start(Callback callback) { mCallbacks.register(callback); } public void stop(Callback callback) { mCallbacks.unregister(callback); if(mCallbacks.getBroadcastItem() >= 1) return; } private void notifyResult(String result) { final int len = mCallbacks.beginBroadcast(); for (int i = 0; i < len; i++) { try { mCallbacks.getBroadcastItem(i).onResult(result); } catch (RemoteException e) { e.printStackTrace(); } } mCallbacks.finishBroadcast(); }
使用Messenger 實現(xiàn) Servie與Client端通信
Messenger是基于Handler的,通過為Messenger添加Handler來傳遞處理數(shù)據(jù),之后Service與Client的通信都是通過傳遞的Handler來進行。用這種方式可以不需要定義AIDL接口,也就不出現(xiàn)因為修改AIDl接口所造成的接口版本不對應的麻煩。
Messenger的使用就是通過 Handler傳遞消息, 客戶端send方法發(fā)送的是一個Message,這個Message.replyTo指向的是一個Messenger,Messenger又持有客戶端的一個Binder對象(MessengerImpl),服務端正是利用這個Binder對象做的與客戶端的通信。
以上就是本文的全部內容,希望對大家的學習有所幫助,也希望大家多多支持腳本之家。
- Android Studio 導入開源項目的正確姿勢及注意事項
- Android Studio3.0升級后使用注意事項及解決方法
- Android 程序執(zhí)行Linux命令的解決方法及注意事項
- 將Eclipse工程轉Android Studio工程的步驟與注意事項
- AndroidStudio升級到3.0的新特性和注意事項小結
- Android 中ViewPager中使用WebView的注意事項
- Android TimerTask 的簡單應用及注意事項
- Android 如何使用log4j及注意事項
- Android集成百度地圖開發(fā)流程和注意事項
- Android onNewIntent()觸發(fā)機制及注意事項
- Android Studio添加第三方庫的注意事項
- Android 程序申請權限注意事項
- Android Service自啟動注意事項分析
- 關于Android WebView的loadData方法的注意事項分析
- Android NDK中socket的用法以及注意事項分析
- Android生存指南之:開發(fā)中的注意事項
- Android 編程下字庫的使用及注意事項
- 60條Android開發(fā)注意事項與經(jīng)驗總結
相關文章
Android Handler,Message,MessageQueue,Loper源碼解析詳解
這篇文章主要介紹了Android Handler,Message,MessageQueue,Loper源碼解析詳解,本篇文章通過簡要的案例,講解了該項技術的了解與使用,以下就是詳細內容,需要的朋友可以參考下2021-09-09Android使用ImageView實現(xiàn)支持手勢縮放效果
這篇文章主要介紹了Android使用ImageView實現(xiàn)支持手勢縮放效果,非常不錯,具有參考借鑒價值,需要的朋友可以參考下2016-09-09Intel HAXM為Android 模擬器加速解決模擬器運行慢的問題
Android 模擬器一直以運行速度慢著稱, 本文介紹使用 Intel HAXM 技術為 Android 模擬器加速, 使模擬器運行度媲美真機, 徹底解決模擬器運行慢的問題,感興趣的朋友可以了解下哦2013-01-01Android使用TabLayout+Fragment實現(xiàn)頂部選項卡
本文通過實例代碼給大家介紹了Android使用TabLayout+Fragment實現(xiàn)頂部選項卡功能,包括TabLyout的使用,感興趣的朋友參考下本文吧2017-05-05Android編程實現(xiàn)canvas繪制餅狀統(tǒng)計圖功能示例【自動適應條目數(shù)量與大小】
這篇文章主要介紹了Android編程實現(xiàn)canvas繪制餅狀統(tǒng)計圖功能,可實現(xiàn)自動適應條目數(shù)量與大小的功能,涉及Android基于canvas的圖形繪制相關操作技巧,需要的朋友可以參考下2017-01-01