2.0?API?level之后，實現(xiàn)onStart等同于重寫onStartCommand并返回START_STICKY??
@Override??
public?void?onStart(Intent?intent,?int?startId)?{??
handleCommand(intent);??
}??
//?2.0?API?level之后尸曼，onStart()方法被onStartCommand()取代了??
@Override??
public?int?onStartCommand(Intent?intent,?int?flags,?int?startId)?{??
handleCommand(intent);??
//?We?want?this?service?to?continue?running?until?it?is?explicitly??
//?stopped,?so?return?sticky.??
return?START_STICKY;??
}???
啟動服務(wù)時依次執(zhí)行onCreate，onStartCommand侠仇，onStart；如果在系統(tǒng)顯示調(diào)用stopService和stopSelf之前終止服務(wù)腹尖，service再次重啟狮荔，onStartCommand會被調(diào)用，重啟服務(wù)時依次執(zhí)行onStartCommand贫贝，onStart秉犹。無論何時，都會先調(diào)用onStartCommand()稚晚，在調(diào)用onStart()崇堵。??
onStartCommand返回值??
onStartComand使用時，返回的是一個(int)整形客燕。??
這個整形可以有四個返回值：START_STICKY鸳劳、START_NO_STUCKY、START_REDELIVER_INTENT也搓、START_STICKY_COMPATIBILITY棍辕。??
它們的含義分別是：??
1):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昔案。??
2):START_NOT_STICKY：“非粘性的”尿贫。使用這個返回值時，如果在執(zhí)行完onStartCommand后踏揣，服務(wù)被異常kill掉庆亡，系統(tǒng)不會自動重啟該服務(wù)??
3):START_REDELIVER_INTENT：重傳Intent。使用這個返回值時捞稿，如果在執(zhí)行完onStartCommand后又谋，服務(wù)被異常kill掉，系統(tǒng)會自動重啟該服務(wù)娱局，并將Intent的值傳入彰亥。???
4):START_STICKY_COMPATIBILITY：START_STICKY的兼容版本，但不保證服務(wù)被kill后一定能重啟衰齐。??
onStartComand參數(shù)flags含義??
flags表示啟動服務(wù)的方式：??
Additional?data?about?this?start?request.?Currently?either?0,?START_FLAG_REDELIVERY,?or?START_FLAG_RETRY.??
START_FLAG_REDELIVERY：如果你實現(xiàn)onStartCommand()來安排異步工作或者在另一個線程中工作,?那么你可能需要使用START_FLAG_REDELIVERY來讓系統(tǒng)重新發(fā)送一個intent任斋。這樣如果你的服務(wù)在處理它的時候被Kill掉,?Intent不會丟失.??
START_FLAG_RETRY：表示服務(wù)之前被設(shè)為START_STICKY，則會被傳入這個標記耻涛。
