强行杀死Android服务后重启的时间

时间：2012-05-10 13:24:51

标签： android

当我使用诸如＆＃34; Go Power Master＆＃34;等应用程序时强行杀死在我的Android手机上运行的服务，并非所有服务都以相同的延迟重新启动。为什么会这样，以及如何减少我的服务重新启动所需的时间？

Facebook服务就是一个很好的例子。下面是它的LogCat输出，连续3次被杀。注意重启时间以粗体显示：14992ms，5000ms，14963ms。

我的服务不是那么好对待。下面是它的LogCat输出，连续3次被杀。请注意以粗体显示更大的重启时间：23358ms，93432ms，373728ms。

此项目的完整源代码在GitHub上。 https://github.com/ccoffey/NUIMWiFi

Facebook LogCat

05-10 14：09：33.381：I / ActivityManager（192）：杀死proc 7280：com.facebook.katana / 10077：kill background 05-10 14：09：33.381：W / ActivityManager（192）：在 14992ms 中调度崩溃服务com.facebook.katana / .service.MediaUploadService的重启 05-10 14：09：48.412：I / ActivityManager（192）：启动proc com.facebook.katana以获取服务com.facebook.katana / .service.MediaUploadService：pid = 7847 uid = 10077 gids = {3003,1006,1015 } 05-10 14：09：48.568：I / ActivityThread（7847）：Pub com.facebook.katana.provider.LoggingProvider：com.facebook.katana.provider.LoggingProvider 05-10 14：09：48.592：I / ActivityThread（7847）：Pub com.facebook.katana.provider.KeyValueProvider：com.facebook.katana.provider.KeyValueProvider 05-10 14：09：48.592：I / ActivityThread（7847）：Pub com.facebook.katana.provider.CacheProvider：com.facebook.katana.provider.CacheProvider 05-10 14：09：48.592：I / ActivityThread（7847）：Pub com.facebook.katana.provider.MailboxProvider：com.facebook.katana.provider.MailboxProvider 05-10 14：09：48.599：I / ActivityThread（7847）：Pub com.facebook.katana.provider.UserStatusesProvider：com.facebook.katana.provider.UserStatusesProvider 05-10 14：09：48.599：I / ActivityThread（7847）：Pub com.facebook.katana.provider.EventsProvider：com.facebook.katana.provider.EventsProvider 05-10 14：09：48.607：I / ActivityThread（7847）：Pub com.facebook.katana.provider.NotificationsProvider：com.facebook.katana.provider.NotificationsProvider 05-10 14：09：48.607：I / ActivityThread（7847）：Pub com.facebook.katana.provider.UserValuesProvider：com.facebook.katana.provider.UserValuesProvider 05-10 14：09：48.607：I / ActivityThread（7847）：Pub com.facebook.katana.provider.PagesProvider：com.facebook.katana.provider.PagesProvider 05-10 14：09：48.607：I / ActivityThread（7847）：Pub com.facebook.katana.provider.MobileEventLogProvider：com.facebook.katana.provider.MobileEventLogProvider 05-10 14：09：48.607：I / ActivityThread（7847）：Pub com.facebook.katana.provider.PushNotificationsProvider：com.facebook.katana.provider.PushNotificationsProvider 05-10 14：09：48.615：I / ActivityThread（7847）：Pub com.facebook.katana.provider.PhotosProvider：com.facebook.katana.provider.PhotosProvider 05-10 14：09：48.615：I / ActivityThread（7847）：Pub com.facebook.katana.provider.ConnectionsProvider：com.facebook.katana.provider.ConnectionsProvider 05-10 14：09：48.623：I / ActivityThread（7847）：Pub com.facebook.orca.notify.FbandroidMessagesForegroundProvider：com.facebook.orca.notify.FbandroidMessagesForegroundProvider 05-10 14：09：48.639：D / ACRA（7847）：ACRA已启用com.facebook.katana，初始化... 05-10 14：09：48.654：D / ACRA（7847）：在/data/data/com.facebook.katana/app_acra-reports中查找错误文件 05-10 14：09：48.701：W / nalizableReferenceQueue（7847）：at com.facebook.orca.inject.binder.AnnotatedBindingBuilderImpl.a（AnnotatedBindingBuilderImpl.java:22） 05-10 14：09：48.701：W / nalizableReferenceQueue（7847）：at com.facebook.orca.app.FbBaseModule.a（FbBaseModule.java:73） 05-10 14：09：48.701：W / nalizableReferenceQueue（7847）：at com.facebook.orca.inject.AbstractModule.a（AbstractModule.java:19） 05-10 14：09：48.701：W / nalizableReferenceQueue（7847）：at com.facebook.orca.inject.FbInjectorImpl.a（FbInjectorImpl.java:61） 05-10 14：09：48.701：W / nalizableReferenceQueue（7847）：at com.facebook.orca.inject.FbInjectorImpl。（FbInjectorImpl.java:41） 05-10 14：09：48.701：W / nalizableReferenceQueue（7847）：at com.facebook.orca.inject.FbInjector.a（FbInjector.java:40） 05-10 14：09：48.701：W / nalizableReferenceQueue（7847）：at com.facebook.katana.FacebookApplication.onCreate（FacebookApplication.java:75） 05-10 14：09：48.928：I / SqliteDatabaseCpp（7847）：sqlite返回：错误代码= 21，msg =误用于[8609a15dfa]的第105099行，db = / data / data / com.facebook.katana / databases / prefs_db 05-10 14：09：53.810：I / ActivityManager（192）：杀死proc 7847：com.facebook.katana / 10077：kill background 05-10 14：09：53.810：W / ActivityManager（192）：在 5000ms 中调度崩溃服务com.facebook.katana / .service.MediaUploadService的重启 05-10 14：09：58.842：I / ActivityManager（192）：为服务com.facebook.katana / .service.MediaUploadService启动proc com.facebook.katana：pid = 7890 uid = 10077 gids = {3003,1006,1015 } 05-10 14：09：59.053：I / ActivityThread（7890）：Pub com.facebook.katana.provider.LoggingProvider：com.facebook.katana.provider.LoggingProvider 05-10 14：09：59.060：I / ActivityThread（7890）：Pub com.facebook.katana.provider.KeyValueProvider：com.facebook.katana.provider.KeyValueProvider 05-10 14：09：59.060：I / ActivityThread（7890）：Pub com.facebook.katana.provider.CacheProvider：com.facebook.katana.provider.CacheProvider 05-10 14：09：59.076：I / ActivityThread（7890）：Pub com.facebook.katana.provider.MailboxProvider：com.facebook.katana.provider.MailboxProvider 05-10 14：09：59.076：I / ActivityThread（7890）：Pub com.facebook.katana.provider.UserStatusesProvider：com.facebook.katana.provider.UserStatusesProvider 05-10 14：09：59.076：I / ActivityThread（7890）：Pub com.facebook.katana.provider.EventsProvider：com.facebook.katana.provider.EventsProvider 05-10 14：09：59.076：I / ActivityThread（7890）：Pub com.facebook.katana.provider.NotificationsProvider：com.facebook.katana.provider.NotificationsProvider 05-10 14：09：59.076：I / ActivityThread（7890）：Pub com.facebook.katana.provider.UserValuesProvider：com.facebook.katana.provider.UserValuesProvider 05-10 14：09：59.076：I / ActivityThread（7890）：Pub com.facebook.katana.provider.PagesProvider：com.facebook.katana.provider.PagesProvider 05-10 14：09：59.084：I / ActivityThread（7890）：Pub com.facebook.katana.provider.MobileEventLogProvider：com.facebook.katana.provider.MobileEventLogProvider 05-10 14：09：59.084：I / ActivityThread（7890）：Pub com.facebook.katana.provider.PushNotificationsProvider：com.facebook.katana.provider.PushNotificationsProvider 05-10 14：09：59.084：I / ActivityThread（7890）：Pub com.facebook.katana.provider.PhotosProvider：com.facebook.katana.provider.PhotosProvider 05-10 14：09：59.084：I / ActivityThread（7890）：Pub com.facebook.katana.provider.ConnectionsProvider：com.facebook.katana.provider.ConnectionsProvider 05-10 14：09：59.092：I / ActivityThread（7890）：Pub com.facebook.orca.notify.FbandroidMessagesForegroundProvider：com.facebook.orca.notify.FbandroidMessagesForegroundProvider 05-10 14：09：59.154：D / ACRA（7890）：ACRA已启用com.facebook.katana，初始化... 05-10 14：09：59.185：D / ACRA（7890）：在/data/data/com.facebook.katana/app_acra-reports中查找错误文件 05-10 14：09：59.232：W / nalizableReferenceQueue（7890）：at com.facebook.orca.inject.binder.AnnotatedBindingBuilderImpl.a（AnnotatedBindingBuilderImpl.java:22） 05-10 14：09：59.232：W / nalizableReferenceQueue（7890）：at com.facebook.orca.app.FbBaseModule.a（FbBaseModule.java:73） 05-10 14：09：59.232：W / nalizableReferenceQueue（7890）：at com.facebook.orca.inject.AbstractModule.a（AbstractModule.java:19） 05-10 14：09：59.232：W / nalizableReferenceQueue（7890）：at com.facebook.orca.inject.FbInjectorImpl.a（FbInjectorImpl.java:61） 05-10 14：09：59.232：W / nalizableReferenceQueue（7890）：at com.facebook.orca.inject.FbInjectorImpl。（FbInjectorImpl.java:41） 05-10 14：09：59.232：W / nalizableReferenceQueue（7890）：at com.facebook.orca.inject.FbInjector.a（FbInjector.java:40） 05-10 14：09：59.232：W / nalizableReferenceQueue（7890）：at com.facebook.katana.FacebookApplication.onCreate（FacebookApplication.java:75） 05-10 14：10：44.826：I / ActivityManager（192）：杀死proc 7890：com.facebook.katana / 10077：kill background 05-10 14：10：44.826：W / ActivityManager（192）：在 14963ms

中调度崩溃服务com.facebook.katana / .service.MediaUploadService的重启

MyService LogCat

I / ActivityManager（192）：杀死proc 8556：ie.cathalcoffey.android/10033：kill background I / ActivityManager（192）：杀死proc 8606：ie.cathalcoffey.android：remote / 10033：kill background W / ActivityManager（192）：在 23358ms 中安排重启崩溃服务ie.cathalcoffey.android/.MyService I / ActivityManager（192）：启动proc ie.cathalcoffey.android:remote for service ie.cathalcoffey.android/.MyService:pid = 8726 uid = 10033 gids = {3003} I / ActivityManager（192）：杀死proc 8726：ie.cathalcoffey.android：remote / 10033：kill background W / ActivityManager（192）：在 93432ms 中调度崩溃服务ie.cathalcoffey.android/.MyService的重新启动 I / ActivityManager（192）：启动proc ie.cathalcoffey.android:remote for service ie.cathalcoffey.android/.MyService:pid = 9063 uid = 10033 gids = {3003} I / ActivityManager（192）：杀死proc 9063：ie.cathalcoffey.android：remote / 10033：kill background W / ActivityManager（192）：在 373728ms

中安排重启崩溃服务ie.cathalcoffey.android/.MyService

3 个答案:

答案 0 :(得分：3)

此问题的解决方案似乎如下。导致操作系统认为它已经杀死正在工作的服务。然后它似乎以较小的延迟重新启动该服务。

我现在编辑了我的服务以启动AsyncTask，它只是永远循环并调用Thread.sleep（100）

现在当我强行杀死我的服务时，我看到我为Facebook服务做的非常类似的重启时间：5000毫秒，24713毫秒，14997毫秒，54912毫秒，14988毫秒。

请证明我错了或是对的，但就目前而言，这似乎解决了我的问题。

答案 1 :(得分：1)

我认为这在很大程度上取决于被杀害过程的重要性。当您使用任务杀手杀死某个应用程序时，Android操作系统将以与系统内存不足相同的方式杀死它。由于它以相同的方式被杀死，因此Android操作系统将根据应用程序的“重要性”重新启动应用程序或服务。

要使服务更重要（因此可以更快地重新启动），您可以向服务添加通知。此通知将显示在通知栏中。由于该服务对用户可见，因此它将比应用程序或其他不可见的服务更快地重新启动。

此外，与活动绑定的服务将比无限制服务更重要。

有关详细信息，请查看此http://developer.android.com/guide/topics/fundamentals/processes-and-threads.html（流程生命周期部分）

EDIT 了解所有正在运行的流程。

List<RunningAppProcessInfo> procInfo = activityManager.getRunningAppProcesses();
for(int i = 0; i < procInfo.size(); i++){
    int importance = procInfo.get(i).importance;
    //Print importance and Package name to log
}

答案 2 :(得分：0)

        W/ActivityManager: Scheduling restart of crashed service com.faceopen.edgedevice/.service.FaceOpenRemoteService in 1000ms
        W/ActivityManager: Scheduling restart of crashed service com.faceopen.edgedevice/.service.FaceOpenRemoteService in 4000ms
        W/ActivityManager: Scheduling restart of crashed service com.faceopen.edgedevice/.service.FaceOpenRemoteService in 16000ms
        W/ActivityManager: Scheduling restart of crashed service com.faceopen.edgedevice/.service.FaceOpenRemoteService in 64000ms
        W/ActivityManager: Scheduling restart of crashed service com.faceopen.edgedevice/.service.FaceOpenRemoteService in 256000ms

在重新启动已终止的进程时，我在 Galaxy Tab 中遇到了类似的问题。上面的日志描述了 Android OS 内核分配的重启进程的时间段。当进程一重启就被反复杀死，上述情况下的调度周期呈指数增长。

然而，通过分析操作系统的进程调度模式，我们得出的结论是，在一段固定的时间后，操作系统停止对被杀死进程的调度进行优先级排序。

在我们的例子中，固定时间是 60000 毫秒（60 秒）。因此换句话说，如果我们在 60 秒后重新启动终止进程，它会在 1000 毫秒后启动。因此操作系统不会在此之后以指数方式调度进程。

相关问题
最新问题