Android Service概述 我們知道,如果系統資源變得緊張,Android Activity可以被啟動、停止、銷毀甚至可能被重新創建。而Service被設計成擁有更長的生命週期。Service在Android中可以從Activity、廣播接收器(Broadcast receiver)或者由其他Service中啟動。 必須注意到的是,使用Service不會自動創建新的線程。所以,如果我們要在Service中實現一個簡單的邏輯並且那不需要長時間處理,我們不必在一個單獨的線程中運行它。但是,如果需要去實現一個複雜的邏輯並且會耗費長時間的處理,我們在創建新線程時必須小心,要不然由於Service運行在主線程可能引起ANR問題(應用程序無響應)。 在Android中Service主要使用的場景如下: 實現多任務(multi-task) 進程間通信(IPC) 第一種情況的典型例子是,應用需要從遠程服務端下載數據。在這種情況下,可以使用與用戶交互的Activity,並在用戶使用應用時啟動Service,在後台運行完成工作。還有一種場景,當Service完成了任務發送信息給用戶。 在第二種情況下,我們想要“分享”一些通常的功能,這樣不同的應用可以重用他們。例如,可以假設我們有一個可以發送郵件的Service,我們想要在幾個應用分享這個服務,這樣就不必重寫新相同的代碼。在這種情況下,我們可以使用IPC這樣Service,暴露一個可以被其他應用調用的“遠程”接口。 Service基礎 現在我們對Service有了更多的了解,我們來創建它。在Android中創建一個Service我們需要繼承Service類。
OnStartCommand方法是最重要的方法,因為它在我們需要啟動Service的時候被調用。在這個方法中,我們擁有在運行Service時傳遞進來的Intent,這樣就可以與Service交換一些信息。在這個方法中,我們實現自己的邏輯:如果不是耗時的操作可以直接在這個方法中執行,否則可以創建一個線程。正如你看到的那樣,這個方法需要返回一個整型值。這個整型代表系統應該怎麼樣處理這個Service: START_STICKY:使用這個返回值,如果系統殺死我們的Service將會重新創建。但是,發送給Service的Intent不會再投遞。這樣Service是一直運行的。 START_NOT_STICKY:如果系統殺死了Service,不會重新創建,除非客戶端顯式地調用了onStart命令。 START_REDELIVER_INTENT:功能與START_STICKY類似。另外,在這種情況下Intent會重新傳遞給Service。 OnDestory是在Service將被銷毀時系統調用的方法。 一旦有了自定義的Service類,就要在Manifest.xml中聲明,這樣我們就可以使用了。
正如我們知道的,一個Service會被啟動、最後會被停止,這樣就可以完成它的任務了。假設我們從一個Activity中啟動它,可以使用Intent傳遞給Service一些信息。假設我們的Activity有兩個按鈕,一個來啟動,一個來停止Service:
![]() 在開始按鈕上點擊,得到下面的Log: 可以注意到onCreate方法被調用了。因為這是我們第一次啟動這個Service,如果我們在開始按鈕上再次點擊,系統不會調用onCreate方法。當我們在停止按鈕上點擊時,系統銷毀這個Service。 IntentService 正如我們以前提到的,Service運行在主線程中。所以,我們在Service中實現邏輯時要非常小心。要考慮如果這個邏輯是一個阻塞操作,或者需要很長時間才能結束,可能會引發ANR問題。在這種情況下,我們要將邏輯移到獨立的線程中。這就意味著,要在onStartCommand方法中創建一個線程,然後運行它。 從Service派生的另一個IntentService類可以簡化我們的開發。當不需要在同一時間去處理多個請求時,這個類比較好用。這個類創建了一個工作線程來處理不同的請求。執行的操作如下: 創建一個單獨的線程來處理請求。 創建一個請求隊列並偶爾傳遞一個Intent。 創建一個默認的onStartCommand實現。 在所有的請求執行完畢後結束Service。 如果我們想要創建一個IntentService,需要繼承IntentService類而不是Service類:
自動啟動Service 很多時候我們想要自動啟動我們的服務,例如在開機時自動啟動。我們知道需要一個組件來啟動Service。那麼,怎麼樣做到自動啟動呢?我們可以使用一個廣播接收器來啟動服務。例如,如果我們想要在智能手機開機時候啟動它,可以先創建一個廣播接收器監聽這個事件(開機),然後啟動Service。
|
Powered by Discuz! X3.5
© 2001-2025 Discuz! Team.