2

当我使用诸如“Go Power Master”之类的应用程序强行终止在我的 Android 手机上运行的服务时，并非所有服务都以相同的延迟重新启动。为什么会这样？如何减少服务重启所需的时间？

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

我的服务没有得到很好的对待。下面是它的 LogCat 输出，它被连续杀死了 3 次。请注意以粗体显示的更大的重启时间：23358ms、93432ms、373728ms。

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

脸书日志猫

05-10 14:09:33.381: I/ActivityManager(192): Killing proc 7280:com.facebook.katana/10077: kill background 05-10 14:09:33.381: W/ActivityManager(192): 计划重启崩溃服务 com.facebook.katana/.service.MediaUploadService 在14992 毫秒 05-10 14:09:48.412: I/ActivityManager(192): 为服务 com.facebook.katana/.service.MediaUploadService 启动 proc com.facebook.katana: 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)：为 com.facebook.katana 启用 ACRA，正在初始化... 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): 在 com.facebook.orca.app.FbBaseModule.a(FbBaseModule.java:73) 05-10 14:09:48.701: W/nalizableReferenceQueue( 7847): 在 com.facebook.orca.inject.AbstractModule.a(AbstractModule.java:19) 05-10 14:09:48.701: W/nalizableReferenceQueue(7847): 在 com.facebook.orca.inject.FbInjectorImpl.a (FbInjectorImpl.java:61) 05-10 14:09:48.701: W/nalizableReferenceQueue(7847): 在 com.facebook.orca.inject.FbInjectorImpl.(FbInjectorImpl.java:41) 05-10 14:09:48.701: W/nalizableReferenceQueue(7847): 在 com.facebook.orca.inject.FbInjector.a(FbInjector.java:40) 05-10 14:09:48.701: W/nalizableReferenceQueue(7847): 在 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): Killing proc 7847:com.facebook .katana/10077：杀死背景 05-10 14:09:53.810：W/ActivityManager(192)：计划重启崩溃的服务 com.facebook.katana/.service.MediaUploadService5000毫秒 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)：为 com.facebook.katana 启用 ACRA，正在初始化... 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): 在 com.facebook.orca.app.FbBaseModule.a(FbBaseModule.java:73) 05-10 14:09:59.232: W/nalizableReferenceQueue( 7890): 在 com.facebook.orca.inject.AbstractModule.a(AbstractModule.java:19) 05-10 14:09:59.232: W/nalizableReferenceQueue(7890): 在 com.facebook.orca.inject.FbInjectorImpl.a (FbInjectorImpl.java:61) 05-10 14:09:59.232: W/nalizableReferenceQueue(7890): 在 com.facebook.orca.inject.FbInjectorImpl.(FbInjectorImpl.java:41) 05-10 14:09:59.232: W/nalizableReferenceQueue(7890): 在 com.facebook.orca.inject.FbInjector.a(FbInjector.java:40) 05-10 14:09:59.232: W/nalizableReferenceQueue(7890): 在 com.facebook.katana.FacebookApplication .onCreate(FacebookApplication.java:75) 05-10 14:10:44.826: I/ActivityManager(192): Killing proc 7890:com.facebook.katana/10077:杀死背景 05-10 14:10:44.826：W/ActivityManager(192)：计划重启崩溃的服务 com.facebook.katana/.service.MediaUploadService14963毫秒

我的服务日志猫

I/ActivityManager（192）：杀死 proc 8556：ie.cathalcoffey.android/10033：杀死背景 I/ActivityManager（192）：杀死 proc 8606：ie.cathalcoffey.android：remote/10033：杀死背景 W/ActivityManager（192） : 计​​划在 23358 毫秒内重新启动崩溃的服务 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): Killing 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): Killing proc 9063:ie .cathalcoffey.android:remote/10033：杀死后台W/ActivityManager（192）：计划在373728ms内重新启动崩溃的服务ie.cathalcoffey.android/.MyService

4

3 回答 3

3

这个问题的解决方案似乎如下。使操作系统相信它已经杀死了正在工作的服务。然后似乎以较小的延迟重新启动该服务。

我现在已经编辑了我的服务以启动一个 AsyncTask，它只是永远循环并调用 Thread.sleep(100)

现在，当我强行终止我的服务时，我看到与 Facebook 服务非常相似的重启时间：5000 毫秒、24713 毫秒、14997 毫秒、54912 毫秒、14988 毫秒。

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

于 2012-05-12T22:34:10.740 回答
1

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

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

此外，绑定到 Activity 的服务将比无边界服务更重要。

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

编辑获取所有正在运行的进程的重要性。

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
}
于 2012-05-10T13:35:01.153 回答
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 秒后重新启动 kill 进程，它会在 1000 毫秒后启动。因此操作系统不会在那之后以指数方式调度该过程。

于 2021-02-05T14:37:09.003 回答