網(wǎng)上有很多介紹被遥活的文章，還有一些極客利用Native鼻城龋活service纽谒，確實(shí)很有想法~
我這個(gè)方案不算新鮮，不過確實(shí)解決了我的問題如输，達(dá)到了我想要的效果鼓黔，我的業(yè)務(wù)是：APP啟動之后，在用戶無感知的情況下不见， 拉取用戶所有照片上傳到服務(wù)器(沒有惡意澳化，僅僅是為了鍛煉技術(shù))
ok,現(xiàn)在步入正題，首先我想要蔽人保活的是Service缎谷，但是普通的service是依賴于APP的，所以我將service設(shè)置了
android:process=":uploadImage"
你懂得灶似，將service設(shè)為進(jìn)程級別列林。
雖然我們的service目前不依賴APP，但是卻不能頑強(qiáng)的存活酪惭，經(jīng)不起手機(jī)衛(wèi)士來搞事情希痴，所以我們需要在service中重寫onStartCommand方法，這個(gè)方法有四種返回值：
START_STICKY：如果service進(jìn)程被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：“非粘性的”。使用這個(gè)返回值時(shí)谦秧，如果在執(zhí)行完onStartCommand后竟纳，服務(wù)被異常kill掉，系統(tǒng)不會自動重啟該服務(wù)疚鲤。
START_REDELIVER_INTENT：重傳Intent锥累。使用這個(gè)返回值時(shí)，如果在執(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算是比較頑強(qiáng)了纺荧，但是為了保險(xiǎn)起見旭愧，我又注冊一個(gè)廣播，然后在service的onDestroy中發(fā)送廣播宙暇，在廣播中實(shí)現(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)化占贫，比如再開啟一個(gè)守護(hù)進(jìn)程桃熄，實(shí)時(shí)監(jiān)聽。
要使自己的Service能夠一直運(yùn)行,最簡單的方法就是重寫onStartCommand方法就好了.但是千萬不要做壞事,不要做被用戶鄙視的惡意程序
進(jìn)程卑薪＃活方案：AlarmManager + JobScheduler + service原生方法onStartCommand + 廣播彬卟Γ活 + 雙進(jìn)程守護(hù)。
筆者能力有限桩引，不足之處歡迎指出缎讼。
