该问题适用于熟悉活动生命周期的Android开发人员。
我正在开发一个执行面部检测和面部标志识别的应用程序。
根据相应的机器学习模型需要很长时间才能从SD存储器中进行解析并将其加载到内存中。在目前平均水平的Android设备上，它最多可能需要20秒。顺便说一下，所有这些面部分析工作和模型加载都是在C ++本地代码中完成的，该代码使用Android NDK + JNI集成。
由于模型加载需要很长时间，因此实际的解析和加载是通过AsyncTasks在后台提前安排的，因此用户不会注意到巨大的延迟。
在执行实际的面部分析之前，用户可以通过MediaStore.ACTION_IMAGE_CAPTURE进行自拍。这将调用设备上安装的单独的相机应用程序，并通过onActivityResult接收图片。
现在问题开始了：当用户在单独的相机“活动/应用”中时，几乎整个应用过程都会被杀死。多数情况似乎是在从“相机”应用返回之前（时间似乎很奇怪）。我进行了另一项测试，以确认在相机应用程序中按下“捕获”按钮时会发生这种情况。那时，我的应用程序被杀死了。当按下“接受图像”按钮时，将重新创建该应用程序。 ActivityManager在logcat中给出的用于进程终止的原因是“ prev LAST”（关于此含义，我在Google上一无所获，但是我看到许多其他应用也由于该原因而被终止，因此似乎发生了经常）。
因此，我的应用程序的所有活动都需要由Android重新创建（我可以调整，因为它发生得很快），，而且面部分析模型也必须从头开始重新加载，用户会注意到他的自拍照无法处理之前有很大的延迟。
我的问题是：是否有可能告诉Android，Activity / App有合法的理由不被暂时隐藏在后台以获取相机图片而被杀死？ ActivityManager做出错误的决定以终止该应用程序。必须如此频繁地重新加载模型会占用大量CPU和内存资源。
这似乎是对Android生命周期体系结构的疏忽。我知道很少有应用程序具有我的应用程序的特定要求，但是看起来仍然很愚蠢。我能想到的“解决”此问题的唯一方法是在应用程序内实现自己的相机Activity，但这与Android的最佳做法背道而驰。
还有一些“ android：persistent”标记，您可以通过AndroidManifest.xml坚持执行“活动”，但是文档对此尚不清楚。 See the docs on this.
顺便说一句：当应用程序进程被杀死时，不会调用onDestroy。我读过某个地方，无法保证会调用onDestroy，这实际上对我来说不是问题。尽管我不知道为什么Android文档没有对此进行明确说明。
答案 0 :(得分：3)
当用户在单独的摄像机“活动/应用”中时，几乎所有应用过程都会被杀死
这并不奇怪。相机应用程序可能会消耗大量内存，因此Android需要通过终止后台应用程序的进程来释放内存。
毕竟，ActivityManager做出了杀死该应用的错误决定
鉴于可能的替代方案是操作系统崩溃，我怀疑用户会同意操作系统决定终止您的进程。
必须如此频繁地重新加载模型，这会占用大量CPU和内存资源。
那么也许您不应该从您的应用中启动另一个应用。自己拍张照片。直接使用相机API，或将Fotoapparat和CameraKit-Android之类的库用作这些API的更简单包装器。
我想想“解决”这个问题的唯一方法是在应用程序内部实现自己的相机Activity，但这与Android的最佳做法背道而驰。
根据这种说法，任何设备都不会拥有相机应用程序，因为编写任何相机应用程序都“违反了Android自身的最佳做法”。
任何需要摄像机的应用程序必须使用摄像机API（直接或间接）以可靠的方式进行拍摄。您假设成千上万的相机应用程序均已正确编写，并将正确地兑现您的ACTION_IMAGE_CAPTURE Intent（例如，将结果放在您用EXTRA_OUTPUT指定的位置）。 Many camera apps have buggy ACTION_IMAGE_CAPTURE implementations。 ACTION_IMAGE_CAPTURE对于您和用户无需照相就可以生活的情况（例如具有“附加照片”功能的记事本应用程序）并不是没有道理的，但是对于您的应用。