在iOS上,什么时候是Platform.Ready被解雇了? [英] On iOS, When is Platform.Ready fired vs. Resume?

查看:127
本文介绍了在iOS上,什么时候是Platform.Ready被解雇了?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我知道在加载应用程序时,platform.ready会触发,暂停后应用程序打开时会触发platform.resume。



但是,是有一段时间的应用程序没有被使用的应用程序将加载而不是恢复?如果是这样,iOS和Android的时间是多少?



似乎无法找到任何相关信息,并希望了解这一点,谢谢!

解决方案

TLDR:通常我们会收到一个简历事件,如果一个应用程序来从背景。



如果操作系统内存不足,可能会完全清除应用程序,我们将收到 deviceready 事件。我不知道应用程序被操作系统终止后有任何时间限制,这应该只会发生,如果操作系统内存不足,重新启动或者用户手动终止应用程序。






通过查看



所以放在后台的应用程序将被置于后台模式,其描述如下:


app在后台并执行代码。大多数应用程序暂停进入这个
状态暂停。但是,
请求额外执行时间的应用程序可能会在此状态下保留
时间。 ...


假设我们的应用程序没有在后台/请求中运行,额外的执行时间将仅暂停在此模式下,然后被置于进入暂停模式。



暂停模式描述如下(重点是我的):


该应用程序在后台但未执行代码。系统
会自动将应用程序移动到此状态,并且在
之前不会通知它们。暂停时,应用程序仍保留在内存中,但不会执行任何代码



当内存不足时,系统可能会清除暂停状态
应用程序,恕不另行通知
为前台应用程序腾出更多空间。







几乎同样适用于Android。 Android活动的生命周期稍微复杂一些,您可以在开发人员上查找详细信息.android.com 。底线与iOS相同(来源) :


系统在需要释放RAM时终止进程


因此,如果操作系统内存不足,可能会完全清除我们的应用程序,我们的生命周期将从 deviceready 事件开始。我不知道应用程序被操作系统终止后有任何时间限制,这应该只会发生,如果操作系统内存不足,重新启动或者用户手动终止应用程序。


I know that platform.ready will fire when an app is loaded, and platform.resume will fire when the app is opened after being paused.

But, is there a certain amount of time of the app not being in use where the app will load instead of resume? If so, what is that amount of time for iOS and Android?

Can't seem to find any information on this and would love to understand this, thanks!

解决方案

TLDR: Typically we will receive a resume event, if an app comes from the background.

If the OS is running out of memory it might completely purge an app and we will receive the deviceready event. I'm not aware that there is any time limit after an app gets terminated by the OS, this should only happen, if the OS is running out of memory, is being restarted or the app is terminated manually by the user.


Okay let's see the typical lifecycle of a Cordova app by looking at the event docs:

  1. The user starts an app and the deviceready event is fired once Cordova is fully loaded
  2. If the user switches to another app, the native platform puts the application into the background and the pause event fires.
  3. If the user comes back to our app, the app will be put in the foreground by the native platform again. That's the moment when the resume event fires.


To answer your actual question, we will have to look at the implementation per native platform. First of iOS.

iOS apps have following execution states (Source: developer.apple.com):

So an app that is put in background will be put to in Background mode, which is described like this:

The app is in the background and executing code. Most apps enter this state briefly on their way to being suspended. However, an app that requests extra execution time may remain in this state for a period of time. ...

Assuming our app does not run in background/request extra execution time will only stay in this mode briefly and then be put into Suspended mode.

The Suspended mode is described like this (emphasis is mine):

The app is in the background but is not executing code. The system moves apps to this state automatically and does not notify them before doing so. While suspended, an app remains in memory but does not execute any code.

When a low-memory condition occurs, the system may purge suspended apps without notice to make more space for the foreground app.


Pretty much the same applies to Android. The lifecycle of Android activities is little more complex, you can look up the details on developer.android.com. The bottom line is the same as for iOS (Source):

The system kills processes when it needs to free up RAM

So if the OS is running out of memory it might completely purge our app and our lifecycle will start from the beginning with the deviceready event. I'm not aware that there is any time limit after an app gets terminated by the OS, this should only happen, if the OS is running out of memory, is being restarted or the app is terminated manually by the user.

这篇关于在iOS上,什么时候是Platform.Ready被解雇了?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆