Android ndk 在所有全局变量为零的情况下启动应用程序

Android ndk 在所有全局变量为零的情况下启动应用程序,android-ndk,Android Ndk,我正在编写一个Android NDK应用程序,它由一个大型的独立于平台的C内核和几行基于Android.app.NativeActivity类的Java粘合代码组成。除了一件让我头疼的事之外,这真的很好用 问题是,Android应用程序在调用ANativeActivity\u finish()时并没有真正退出,而是进入某种空闲状态,而且只有在Android需要资源时才会真正停止 Android的这种特性对我来说是一个巨大的问题,因为我的C内核使用了很多全局变量,当我的C内核运行其关闭代码时,它们

我正在编写一个Android NDK应用程序,它由一个大型的独立于平台的C内核和几行基于
Android.app.NativeActivity
类的Java粘合代码组成。除了一件让我头疼的事之外,这真的很好用

问题是,Android应用程序在调用
ANativeActivity\u finish()
时并没有真正退出,而是进入某种空闲状态,而且只有在Android需要资源时才会真正停止

Android的这种特性对我来说是一个巨大的问题,因为我的C内核使用了很多全局变量,当我的C内核运行其关闭代码时,它们不会重置为0。因此,当Android在我的应用关闭后启动它时,所有全局变量都包含上次运行我的应用时的一些随机状态,而不是0

在我的程序(Win32、Mac OS、Linux)支持的所有桌面系统上,这根本不是问题,因为在这些系统上,程序可以真正退出。但在Android上,这是根本不同的。是的,我知道全局变量是不好的,我应该在使用完它们后将它们重置为0,但我们谈论的是一个非常大的C内核,它已经开发了近20年,所以需要付出巨大的努力来清理这一切

这就是为什么我想问,是否有什么方法可以迫使Android总是像第一次启动应用程序时那样将我所有的全局变量归零


我已经做了一些研究,AFAIC唯一的方法就是使用
android.os.Process.killProcess()
真正杀死我的应用程序,但这看起来像是一种暴力方法。启动我的应用程序时,是否有其他方法可以始终获取零全局值

初始归零由操作系统执行——变量存储占用新映射的页面。没有“将需要归零的内容归零”的内部函数可以调用

您有两种基本方法:

  • 让Android应用程序像在其他平台上一样工作,并手动关闭应用程序以强制重新加载
  • 让你的应用程序像Android一样工作,不要表现得好像它暂停时完全关闭了一样。换句话说,永远不要运行关闭代码。当应用程序暂停时,你仍然需要释放大量的资源,但这应该比把所有东西都拆下来的负担要小
  • 方法2的可行性取决于代码的性质

    是的,我知道全局变量不好,我应该在使用完它们后将它们重置为0,但是


    如果您绝对必须使用globals,请创建一个单一的全局结构并将所有内容堆积到其中,因此如果您需要重置它或在调试器中转储所有状态,则很容易找到所有内容。这并不理想,但比寻找分散的全球用户和(天方夜谭)静态本地用户要容易得多。

    谢谢,关于如何“正确”手动关闭应用程序,有明确的答案吗?我做了一些研究,似乎有很多不同的建议,例如
    System.exit()
    android.os.Process.killProcess()
    ,新的API 21
    finishAndRemoveTask()
    finishafinity()
    ,但到目前为止,我还没有找到如何手动杀死应用程序的确切答案。我尝试过System.exit(),但这会导致LogCat上出现一些警告消息(“消费者关闭输入通道或发生错误”),有时还会出现“赢-死”警告,这似乎不是一个很好的解决方案……记住,你不需要终止应用程序,你需要终止它正在运行的进程,因为您需要系统加载器来有效地重置全局变量。如果有其他应用程序在同一进程中运行,你将别无选择,只能将它们也杀掉。考虑到这一点,
    killProcess()
    方法(发送SIGKILL,与低内存killer相同)是合适的。
    System.exit()
    的优点是,它将执行任何已注册的“退出时”处理程序,但这在Android上通常不相关,因为不希望应用程序退出。好的,谢谢。虽然在退出时,我有时会收到LogCat消息,说明JavaBinder或使用者关闭的输入通道中的BINDER事务失败,或者发生错误,或者试图从InputDispatcher中注销已注销的输入通道。我想这只是因为我的应用程序突然消失了,因为killProcess()是Android所没有预料到的?很可能。该系统旨在应对崩溃的应用程序,因此在恢复时不会出现问题。如果进程被某个濒死活动回调(如
    onDestroy()
    )终止,您可能会收到较少的投诉。