摘要：一方法，返回在運行后進程被后，那將保留在開始狀態，但是不保留那些傳入的。不久后就會再次嘗試重新創建，因為保留在開始狀態，在創建后將保證調用。因此進程的優先級將會很重要，可以使用將放到前臺狀態。六將安裝到，變身系統級應用更多加速啟動切換動畫

　　在運行onStartCommand后service進程被kill后，那將保留在開始狀態，但是不保留那些傳入的intent。不久后service就會再次嘗試重新創建，因為保留在開始狀態，在創建 service后將保證調用onstartCommand。如果沒有傳遞任何開始命令給service，那將獲取到null的intent。

　　　【結論】 手動返回START_STICKY，親測當service因內存不足被kill，當內存又有的時候，service又被重新創建，比較不錯，但是不能保證任何情況下都被重建，比如進程被干掉了….　

　　在AndroidManifest.xml文件中對于intent-filter可以通過android:priority = “1000”這個屬性設置最高優先級，1000是最高值，如果數字越小則優先級越低，同時適用于廣播。

　　Android中的進程是托管的，當系統進程空間緊張的時候，會依照優先級自動進行進程的回收。Android將進程分為6個等級,它們按優先級順序由高到低依次是:
1.前臺進程( FOREGROUND_APP)
2.可視進程(VISIBLE_APP )

次要服務進程(SECONDARY_SERVER )
4.后臺進程 (HIDDEN_APP)
5.內容供應節點(CONTENT_PROVIDER)
6.空進程(EMPTY_APP)
當service運行在低內存的環境時，將會kill掉一些存在的進程。因此進程的優先級將會很重要，可以使用startForeground 將service放到前臺狀態。這樣在低內存時被kill的幾率會低一些。
在onStartCommand方法內添加如下代碼：

Notification notification = new Notification(R.drawable.ic_launcher,

     getString(R.string.app_name), System.currentTimeMillis());
     PendingIntent pendingintent = PendingIntent.getActivity(this, 0,
     new Intent(this, AppMain.class), 0);
     notification.setLatestEventInfo(this, "uploadservice", "請保持程序在后臺運行",
     pendingintent);
     startForeground(0x111, notification);

注意在onDestroy里還需要stopForeground(true)，運行時在下拉列表會看到自己的APP在：
【結論】如果在極度極度低內存的壓力下，該service還是會被kill掉，并且不一定會restart

　　直接在onDestroy（）里startService　
　　或
　　service +broadcast 方式，就是當service走ondestory的時候，發送一個自定義的廣播，當收到廣播的時候，重新啟動service；

【結論】當使用類似口口管家等第三方應用或是在setting里-應用-強制停止時，APP進程可能就直接被干掉了，onDestroy方法都進不來，所以還是無法保證~.~

　　通過系統的一些廣播，比如：手機重啟、界面喚醒、應用狀態改變等等監聽并捕獲到，然后判斷我們的Service是否還存活，別忘記加權限啊。

更多:

android加速啟動activity

activity切換動畫