網(wǎng)上有很多介紹?；畹奈恼拢€有一些極客利用Native?；顂ervice，確實很有想法~
我這個方案不算新鮮，不過確實解決了我的問題，達到了我想要的效果，我的業(yè)務(wù)是：APP啟動之后，在用戶無感知的情況下， 拉取用戶所有照片上傳到服務(wù)器(沒有惡意，僅僅是為了鍛煉技術(shù))

ok,現(xiàn)在步入正題，首先我想要?；畹氖荢ervice，但是普通的service是依賴于APP的，所以我將service設(shè)置了

android:process=":uploadImage"

你懂得，將service設(shè)為進程級別。

雖然我們的service目前不依賴APP，但是卻不能頑強的存活，經(jīng)不起手機衛(wèi)士來搞事情，所以我們需要在service中重寫onStartCommand方法，這個方法有四種返回值：

START_STICKY：如果service進程被kill掉，保留service的狀態(tài)為開始狀態(tài)，但不保留遞送的intent對象。隨后系統(tǒng)會嘗試重新創(chuàng)建service，由于服務(wù)狀態(tài)為開始狀態(tài)，所以創(chuàng)建服務(wù)后一定會調(diào)用onStartCommand(Intent,int,int)方法。如果在此期間沒有任何啟動命令被傳遞到service，那么參數(shù)Intent將為null。

START_NOT_STICKY：“非粘性的”。使用這個返回值時，如果在執(zhí)行完onStartCommand后，服務(wù)被異常kill掉，系統(tǒng)不會自動重啟該服務(wù)。

START_REDELIVER_INTENT：重傳Intent。使用這個返回值時，如果在執(zhí)行完onStartCommand后，服務(wù)被異常kill掉，系統(tǒng)會自動重啟該服務(wù)，并將Intent的值傳入。

START_STICKY_COMPATIBILITY：START_STICKY的兼容版本，但不保證服務(wù)被kill后一定能重啟。

ok,這里我使用的是START_STICKY，經(jīng)測試START_REDELIVER_INTENT的效果和START_STICKY，而且START_STICKY屬性使service的重啟速度更快。

現(xiàn)在的service算是比較頑強了，但是為了保險起見，我又注冊一個廣播，然后在service的onDestroy中發(fā)送廣播，在廣播中實現(xiàn)拉起：

class KeepAliveReceiver : BroadcastReceiver() {

    override fun onReceive(context: Context, intent: Intent) {
        context.startService(Intent(context, ImageHandleService::class.java))
    }
}

到此結(jié)束，現(xiàn)在的service還不算很安全，還可以做更安全的方案優(yōu)化，比如再開啟一個守護進程，實時監(jiān)聽。

要使自己的Service能夠一直運行,最簡單的方法就是重寫onStartCommand方法就好了.但是千萬不要做壞事,不要做被用戶鄙視的惡意程序

進程?；罘桨福篈larmManager + JobScheduler + service原生方法onStartCommand + 廣播保活 + 雙進程守護。

筆者能力有限，不足之處歡迎指出。