facebook android app如何防止自己被杀死

Question

我注意到facebook android应用程序非常有弹性，无法关闭。即使我已经强制停止应用程序并杀死其所有相关服务，但它在某种程度上可以在一段时间后神奇地重启。

这引出了我的问题：

1）如何在不卸载应用程序和所有Facebook服务的情况下实际停止它。

2）该应用程序应用什么方法来防止自己被杀死（即如何在android中编写类似的东西）？

Answer 1

  

1）如何在不使用的情况下实际停止应用程序和所有Facebook服务   卸载它。

只要Android需要更多资源来处理更高优先级的其他进程的逻辑，就会执行进程终止。 它如何应用于Android的Service？

服务返回onStartCommand()中的特定代码：

START_STICKY - 简而言之，一旦通过返回此常量来杀死应用程序的进程，我们会要求操作系统在出现可用资源时恢复应用程序的Service。因此，重新创建应用程序的过程。

START_NOT_STICKY - 一旦通过返回此常量来杀死应用程序的进程，我们就告诉操作系统不要打扰我们的服务娱乐。

START_REDELIVER_INTENT - 与START_STICKY相同，但有细微的区别。每当我们的Service恢复时，我们都要求onStartCommand()与我们在终止前最后一次交付的Intent相同。

您的观察结果可能是Facebook使用上述常量将服务重新投入使用。

  

2）该应用程序适用于防止自身获取的方法   杀死（即如何在android中编写类似的东西）？

每当我们想阻止我们的申请成为第一个被终止的候选人时，很少有值得记住的事情：

1. 依赖Activity.onLowMemory()或Application.onLowMemory()方法 - 如果我们将应用程序隐藏到后台或放弃它，则会调用此方法。在这种情况下，值得释放资源，包括：

   • 缓存或缓存条目（例如LruCache），

   • 昂贵的对象（位图，临时POJO等）

   • 取消注册动态BroadcastReceivers

2. Unregistering statically declared broadcast receivers每当我们不需要它们时。

3. Preventing application from having memory leaks - 泄露内存的大多数进程无可争议地是系统终止的第一个进程。

4. 防止对象创建并将我们的代码设计为不可变的（book）（link）

5. 批量组织我们的HTTP请求（link）（link）（link）（link），而不是按需执行。

希望有所帮助。