问题标签 [ios-lifecycle]

首先，如果我的问题是假的，我想说声抱歉，我对 iOS 真的很陌生，并且要了解事情的进展情况。想象这样一种情况——用户点击主页按钮，应用程序开始崩溃，但在点击主页按钮后，用户立即点击了一些 UI 元素。所以，我想知道 iOS 将如何处理这个问题？我尝试使用断点进行一些测试，但由于它只是测试，我不能 100% 确定。似乎如果UI交互事件发生在系统调用之前，willResignActive那么该事件将被完全处理，如果系统willResignActive首先调用，那么偶数将被丢弃并且根本不会被处理。这是正确的，还是我错过了什么？谢谢

我想做一些涉及仅在应用程序状态为 InActive 或 Paused 时写入本地数据库的异步操作，但是如果异步操作在运行时突然关闭应用程序怎么办

该操作在完成任务之前是否仍然有效？

据我所知，在applicationDidEnterBackground返回后什么都不能调用，因为在那之后应用程序被暂停。我的应用程序是这样设计的——它从从服务器加载一些数据的初始控制器开始，一旦加载，它就会转到另一个控制器。我viewWill/DidAppear在我的第二个 vc 中设置了一个断点， applicationDidEnterBackground在 AppDelegate 中设置了另一个断点。我启动应用程序并立即将其最小化。令我大吃一惊applicationDidEnterBackground的不是我能够捕获的最后一个断点！有时我按此顺序捕获它们SecondVC.viewWillAppear -> applicationDidEnterBackground ->SecondVC.viewDidAppear 有时按此顺序 - applicationDidEnterBackground > SecondVC.viewWillAppear ->SecondVC.viewDidAppear ！这怎么可能 ？我能弄清楚的唯一充分的解释是，当应用程序附加到调试器生命周期时，工作方式略有不同，但我不确定这是否是原因。那么，有人可以解释为什么会发生这种情况吗？谢谢！

我对 Apple 官方生命周期图中显示的一个过渡有点困惑。这种Suspended -> Inactive转变在我看来很奇怪。我的意思是应用程序如何跳过Background状态。应用程序进入Suspended状态的唯一方法是通过Background. 因此，每当您返回应用程序时，它应该仍处于Background状态一段时间，直到它接收到applicationDidEnterForeground委托事件。那么，应用程序如何直接进入Inactive状态省略Background？Suspended <-> Background -> Inactive似乎是唯一有效的过渡。此转换涵盖所有情况，例如，当应用程序Background执行获取然后返回时的后台获取Suspended，以及应用程序从Suspended到Background然后到的应用程序的常规唤醒Inactive，但由于某种原因，存在这种提取转换。有人可以解释它为什么在这里吗？谢谢！

更新 1.也许这只是为了表明应用程序的定期唤醒而添加的？我的意思是没有后台获取和其他东西，应用程序直接在后台模式下被操作系统唤醒以执行一些操作。也许这只是显示用户正常返回应用程序时会发生什么的“缩短”方式？

我一直都知道那window?.makeKeyAndVisible()是在didFinishLaunching

但我也认为在应用程序被前台显示之前，不会调用根视图控制器的生命周期事件。想法不正确吗？

即通过调用makeKeyAndVisible- 即使应用程序仅在后台启动，我也看到它的viewDidLoad,viewWillAppear和viewDidAppear方法被调用。

这是预期的吗？！

我的任务是调试为什么某些用户在打开应用程序时有时会遇到黑屏。我是这个特定应用程序的新手，所以我不知道整个流程，但我可以看出该应用程序具有后台功能。有一些任务在夜间运行。

在后台模式方面，我很难理解 iOS 应用程序的整个生命周期。

当应用程序从终止状态在后台启动时，我假设它didFinishLaunchingWithOptions仍然会被调用。我看到我们在代码中有一个小检查，在这种情况下它省略了整个 UI 初始化：

我怀疑当应用程序当前或最近由“系统”在后台运行时（从最初终止的状态）手动打开时，此代码会导致应用程序不显示 UI。这个对吗？这意味着在某些极端情况下，人们会在没有调用“{ Start UI }”的情况下打开应用程序。

我们还applicationDidBecomeActive实现了，我认为应该使用它来确保在这种情况下呈现 UI。但是，现在这里只有一些可达性的东西：

我发现的大多数在线资源都没有具体显示应用程序是如何在后台启动的，例如这个在所有情况下总是过渡到的图表。didBecomeActive

所以问题1；评估状态的最佳实践方法是didFinishLaunchingWithOptions什么？当前的实现是否在.background最佳情况下省略了 UI？如果是这样，我是否应该执行检查以查看 UI 是否正在运行didBecomeActive，如果不是则启动 UI？

引出问题2；如果我们应该在其中加载 UI didBecomeActive，我们是否也应该在其中卸载或取消分配任何活动的 UI didEnterBackground？

额外的问题：是否有可能用调试器实际重现这个？每次我用调试器启动应用程序时，它显然不在后台。如何调试从后台到前台的生命周期？

或者我可能在这里完全偏离目标，为什么有时某些用户没有 UI 可能有不同的原因？

我有一个 MvvmCross 应用程序，我正在使用 MvvmCross ViewModel Lifecycle 函数来实现视图出现、移至后台和移至前台时的某些操作：

• 公共覆盖异步无效ViewAppeared（）
• 公共覆盖异步无效ViewAppearing（）
• 公共覆盖无效 ViewDisappearing()
• 公共覆盖无效 ViewDisappeared()
• 公共覆盖无效 ViewDestroy(bool viewFinishing)

这些功能在我的 Android 设备上运行良好。但是对于 iOS，当应用程序移动到后台或前台时它们不会被触发（尽管除了 ViewDestroy，它们在 iOS 应用程序的屏幕之间导航时会触发）

1）这是预期的行为，还是我遗漏了什么？

2）如果是这样，我们必须遵循什么方法，当应用程序移动到前台/后台时我们需要执行一些操作（如停止计时器）？我们是否应该有两种实现，一种用于 android，一种用于 ios？我还尝试了 MvxBaseViewController 中的 ViewDidDisappear 方法，当应用程序移动到后台时它仍然没有被激活。Xamarin/MvvmCross 中有一种方法可以连接到本机 ios applicationDidEnterBackground？

编辑：我试过 Ranjit 的回答，但订阅该消息似乎是个问题。这是我的测试代码：

AppDelegate.cs：

基类：

视图模型：

消息在 AppDelegate.cs 中发布，但视图模型中的 OnLocationMessage 方法永远不会执行。

另外我想知道如何正确取消订阅该消息。ViewDestroy 似乎是最自然的地方，但如前所述，它从未在 iOS 上调用

I'm updating a Firebase database variable in sceneWillEnterForeground, and for some reason it the update gets triggered not only when the app goes to foreground, but also when I quit the app, It doesn't get triggered when I go to background. How is this possible?

I'm 100% sure it's sceneWillEnterForeground that's causing the Firebase database to update, I'm not calling the update from anywhere else in the code.

我想进行一些颤振函数调用，以在应用程序崩溃或进入后台时离开或关闭颤振应用程序获取的资源。

这些生命周期方法在 SceneDelegate.swift 和 AppDelegate.swift 中可用。

这些是当应用程序崩溃在中间关闭时处理生命周期的一些可用方法。

我想从这些函数中调用颤振函数。

但是，任何替代方案都会更好，因此我可以在应用程序进入后台或崩溃或突然关闭之前执行一些功能。

我试图了解 SpriteKit 场景的帧周期何时在主 iOS 运行循环中运行。具体来说，我很关心 AppDelegate 的applicationDidBecomeActive(_:)方法。我一直认为该方法是在应用程序激活后调用的，但在您呈现的场景的帧周期运行之前。

这对我正在构建的项目很重要，因为我使用该applicationDidBecomeActive(_:)方法来执行一些时间敏感的任务，例如检查时间戳、设置标志、启动计时器等。所以我需要可靠地预测在帧周期内何时调用此方法（让我们称之为“游戏循环”）。

我做了一些测试，这表明游戏循环在与applicationDidBecomeActive(_:)方法相关的不同时间运行，具体取决于应用程序运行的 iOS 版本。这是一个问题，因为这意味着我不能依赖此方法的单个实现来在正确的时间执行我需要的任务。

我想确切地知道何时applicationDidBecomeActive(_:)调用与 SpriteKit 游戏循环相关的时间。这似乎是任何编写 SpriteKit 游戏的人都需要了解的基本知识。我很震惊地看到它似乎因操作系统版本而异。我可能在测试和假设中犯了错误。但我会报告我在这里发现的内容，看看是否有其他人注意到这一点，以及是否有人可以解释这种奇怪的行为。

在我当前的项目中，我一直在运行 iOS 12.4 的物理 iPhone 上进行测试，有时还使用运行 iOS 13 的 iPhone 的模拟器。通过 usingprint语句，我观察到AppDelegate'applicationDidBecomeActive(_:)方法和SKScene'update(_:)方法在不同的顺序，具体取决于使用的 iOS 版本。

请注意，我的项目使用UIViewController'viewDidLoad()方法来呈现场景。我尝试viewWillLayoutSubviews()改用，希望事情可以以这种方式更可靠地工作。但事实证明这更不可靠，所以我不会在这里讨论。

方法调用顺序（iOS 12.4）：

方法调用顺序（iOS 13）：

您可以看到两个版本的操作系统都先调用了AppDelegate方法application(_:didFinishLaunchingWithOptions:)，然后才加载视图。在viewDidLoad()，我打电话让视图呈现我的SKScene。正如预期的那样，didMove(to:)在视图呈现场景之后调用场景的方法。但接下来发生的是奇怪的部分。

在 iOS 12.4 中，update(_:)调用了场景的方法，这表明场景执行了其游戏循环的单次运行。然后AppDelegate调用它的方法applicationDidBecomeActive(_:)。接下来，该update(_:)方法再次运行。然后update(_:)，正如预期的那样，随着场景的游戏循环每秒触发 60 次，不断地被调用。

在 iOS 13 中，该update(_:)方法不会在被调用后立即didMove(to:)被调用。相反，applicationDidBecomeActive(_:)在 之后调用didMove(to:)。只有这样，该update(_:)方法才会运行（然后按预期继续运行）。

所以基本上，这里的问题是，在 iOS 12.4 中，游戏循环似乎在它出现后立即运行一次，beforeapplicationDidBecomeActive(_:)被调用。但在 iOS 13 中，这不会发生。

iOS 12.4 中的游戏循环在调用之前多运行一次是一个问题applicationDidBecomeActive(_:)。这使得游戏的生命周期在不同版本的操作系统之间不一致，这意味着我将不得不编写不同的代码来处理不同操作系统版本的情况。要么，要么我必须重新设计依赖于applicationDidBecomeActive(_:)找到更一致的处理方式的应用程序部分。这也让我想知道游戏循环的额外运行是否是 iOS 12 中的一个错误。

我一直认为应用程序的生命周期在操作系统版本之间是一致的（至少关于 和 的方法调用顺序AppDelegate）SKScene。但这一发现使所有这些都受到质疑。我还没有测试过其他版本的 iOS，因为即使这是所有操作系统版本之间的唯一差异，它仍然意味着您的代码必须根据操作系统版本以不同方式处理事情。

为了给这个分析增加一个皱纹......

我还制作了一个新的 SpriteKit 模板项目并执行了相同的测试。我发现了同样的差异，但有一个额外的特点：在 iOS 12.4 中，该update(_:)方法在被调用之后立即被调用两次didMove(to:)，在applicationDidBecomeActive(_:)被调用之前。在 iOS 13 中，行为与上述相同。

我不确定为什么update(_:)会像在我的其他项目中那样触发两次而不是一次。这似乎很奇怪。但是这个“干净”模板项目中的测试表明这是一个真正的问题，而不是我自己的代码中的一些错误。

重申我的问题......
我想知道是否有其他人注意到这一点。也许我的结论是错误的。如果这是一个真正的问题，我想知道是否有任何“修复”可以使游戏循环在所有操作系统版本中以一致的方式工作。如果没有，任何人都可以提出一个好的解决方法，以便您的代码在applicationDidBecomeActive(_:)游戏循环首次触发之前始终运行？我已经有了一些想法。但首先，我想确认这是 iOS 的实际问题，还是我自己的代码中的错误。