Android会杀死一个进程,如果它在后台,而操作系统决定它需要资源(RAM, CPU等)。我需要能够在测试期间模拟这种行为,以便确保我的应用程序行为正确。我希望能够以自动的方式执行此操作,以便无论何时发生此操作,我都可以测试应用程序的行为是否正确,这意味着我必须在每个活动中测试它,等等。

我知道如何终止我的进程。这不是问题所在。问题是当我杀死我的进程(使用DDMS, adb shell kill, process . killprocess()等)时,Android不会像Android操作系统杀死它一样重新启动它。

如果Android OS杀死了进程(由于资源需求),当用户返回到应用程序时,Android将重新创建进程,然后重新创建活动堆栈上的顶部活动(调用onCreate())。

另一方面,如果我杀死进程,Android假设活动堆栈顶部的活动表现不佳,因此它自动重新创建进程,然后从活动堆栈中删除顶部活动,并重新创建顶部活动下面的活动(调用onCreate() ')。这不是我想要的行为。我想要与Android终止进程时相同的行为。

简单地解释一下,如果我的activity栈是这样的:

    ActivityA -> ActivityB -> ActivityC -> ActivityD

如果Android终止了该进程,用户返回到应用程序,Android将重新创建该进程并创建ActivityD。

如果我杀死了进程,Android会重新创建进程并创建ActivityC。


当前回答

我不确定这就是你想要的答案,这更像是一种逻辑思考。

我不认为你可以做一个完全自动化的测试,模拟它的唯一方法是重新创建它,也就是有太多的活动,Android会杀死你的应用程序。

所以我的想法或建议是制作另一个小应用程序,它会不断弹出新的活动,直到Android耗尽内存并开始在后台杀死进程。

行内的东西:

如果应用程序在列表中,则增加i并重新启动循环,但不关闭当前活动,否则->减少i并关闭当前活动,返回上一个并重新检查…

其他回答

当应用程序进程终止时,Android会遍历活动记录(这些记录代表历史堆栈中的活动),并决定哪些活动保留在历史记录中,哪些活动从历史记录中删除。

这里的关键点之一是名为haveState的ActivityRecord字段,Android框架工程师将其描述为“我们是否获得了最后的活动状态?”

默认情况下,Android认为活动有一个状态。当应用程序向活动任务管理器服务报告活动已恢复时,活动变为无状态,并且在应用程序通知框架活动已进入停止状态之前,此状态一直有效。简单地说,根据应用程序的目标版本,onResume()被调用和onStop()或onSaveInstanceState()被调用之间的haveState值为false。

如果我杀死了进程,Android会重新创建进程并创建ActivityC。

在这种情况下,ActivityD在应用程序清单中没有android:stateNotNeeded="true"属性,它目前正在前台运行,所以android从历史记录中删除它,因为系统还没有得到它的最后一个状态。

如何模拟Android杀死我的进程

正如前面多次提到的,你可以简单地将应用程序移到后台,这样activity back堆栈中的顶部活动就会保存它的状态,之后你可以通过Android Debug Bridge, Android Studio或使用Developer Options中的后台进程限制属性来终止应用程序进程。之后,您最近的活动将成功重新创建。

尽管如此,还有另一种简单的方法来测试应用程序进程死亡场景。知道了上面描述的所有内容和事实,如果你从当前运行的ActivityD开始新的ActivityE,那么ActivityD onStop()回调只在ActivityE onResume()方法之后被调用,你可以做下面的技巧。

class TerminatorActivity : Activity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        val isPrePie = applicationInfo.targetSdkVersion < Build.VERSION_CODES.P
        val callbacks = TerminatorLifecycleCallbacks(isPrePie)
        (applicationContext as Application).registerActivityLifecycleCallbacks(callbacks)
    }

    private class TerminatorLifecycleCallbacks(
        // Before P onSaveInstanceState() was called before onStop(), starting with P it's
        // called after
        // Used to schedule the death as app reports server that activity has stopped
        // after the latest of these was invoked
        private val isPrePie: Boolean
    ) : ActivityLifecycleCallbacksDefault {

        private val handler = Handler(Looper.getMainLooper())

        override fun onActivityPostStopped(activity: Activity) {
            if (isPrePie) {
                terminate()
            }
        }

        override fun onActivityPostSaveInstanceState(activity: Activity, outState: Bundle) {
            if (!isPrePie) {
                terminate()
            }
        }

        fun terminate() {
            handler.postDelayed(
                {
                    Process.killProcess(Process.myPid()) // This is the end... 
                },
                LAST_MILLIS
            )
        }

        companion object {
            // Let's wait for a while, so app can report and server can handle the update
            const val LAST_MILLIS = 100L
        }

    }

    private interface ActivityLifecycleCallbacksDefault : Application.ActivityLifecycleCallbacks {
        override fun onActivityCreated(activity: Activity, savedInstanceState: Bundle?) {}
        override fun onActivityStarted(activity: Activity) {}
        override fun onActivityResumed(activity: Activity) {}
        override fun onActivityPaused(activity: Activity) {}
        override fun onActivityStopped(activity: Activity) {}
        override fun onActivitySaveInstanceState(activity: Activity, outState: Bundle) {}
        override fun onActivityDestroyed(activity: Activity) {}
    }
}

然后,当您想要终止应用程序时,只需启动TerminatorActivity。

最后还有一个轻量级工具,它简化了应用程序进程死亡的测试,称为Venom。

你也可以用adb shell从终端连接到你的设备/模拟器,然后用ps | grep <your_package_name获取你进程的PID,然后执行kill -9 < PID >。然后从最近的应用程序选择器中打开最小化的应用程序,它将重新启动最后一个活动

以编程的方式在应用程序后台运行,然后发出ADB命令:

adb shell am kill <PACKAGE_NAME>

请注意,这与Wajahat Karim的一篇优秀文章中描述的adb shell kill命令不同:https://wajahatkarim.com/2020/03/defending-your-app/

请注意,这与adb shell kill命令不同。该命令杀死你的应用程序的整个进程,如终止应用程序按钮,而adb shell am kill只杀死安全的进程,以重新分配资源,如内存,CPU等。

另一个方法,可能是可脚本化的,因为它不需要DDMS:

一次性设置:转到开发人员选项,选择后台进程限制设置,将值从“标准限制”更改为“无后台进程”。

当需要重新启动进程时,请按home键。进程将被杀死(你可以在logcat/Android Monitor studio中验证—进程将被标记为[DEAD])。然后使用任务切换器切换回应用程序。

对我来说,最好的测试方法是这样的:

在应用程序中打开ActivityD 按Home键 在Android Studio的Logcat窗口中按下终止应用程序(这会杀死应用程序进程,确保你在Logcat顶部的下拉菜单中选择了你的设备和进程) 长按Home键返回应用程序或打开的应用程序(取决于设备) 应用程序将在重新创建的ActivityD中启动(ActivityA, ActivityB, ActivityC已死,当您返回时将重新创建它们)

在一些设备上,你也可以回到应用程序(ActivityD)与应用程序->你的启动器图标,但在其他设备上,它将启动ActivityA代替。

Android文档是这么说的:

通常,在某些情况下,当用户从主屏幕重新选择该任务时,系统会清除该任务(从根活动之上的堆栈中删除所有活动)。通常,如果用户在一定时间内(比如30分钟)没有访问该任务,就会执行此操作。