GCM iOS示例中连接/断开连接的不对称性

Question

在GCM client guide for iOS中，它会显示您在[[GCMService sharedInstance] connectWithHandler:...]中呼叫-applicationDidBecomeActive:，之后它会显示您在[[GCMService sharedInstance] disconnect];中呼叫-applicationDidEnterBackground:。

连接和断开的位置对我来说似乎是不对称的。它是否有这样做的原因？我觉得它应该是

• 在-applicationDidBecomeActive:中加入并在-applicationWillResignActive:或
中断开连接
• 在-applicationWillEnterForeground:中加入并在-applicationDidEnterBackground:
中断开连接

Answer 1

如果您查看Apple的iOS应用编程指南中的Execution States for Apps，请说明：

applicationWillResignActive： - 让您知道您的应用正在转变为前台应用。使用此方法可将您的应用置于静止状态。

与

比较

applicationDidEnterBackground： - 让您知道您的应用现在正在后台运行，并且可能随时被暂停。

例如，如果您按设备的主页按钮两次，则会立即调用applicationWillResignActive方法，您的应用现在处于transitioning状态。请参阅下面的图片（您的应用程序离开前景，但尚未在后台）：

如果您选择其他应用，则系统会调用您应用的applicationDidEnterBackground，并且您的应用会进入后台。因此，与GCMService.sharedInstance().disconnect()州相比，当您的应用实际处于background状态时，最好拨打transitioning。

同样，applicationWillEnterForeground vs applicationDidBecomeActive。

如果您现在在其他应用中，并且切换回自己的应用，则会立即调用applicationWillEnterForeground，但您的应用可能仍处于处于非活动状态（目前尚未接收）事件）即可。

它可能只持续不到半秒，applicationDidBecomeActive会立即调用。因为applicationWillEnterForeground更像transitioning州。因此，当您的应用实际处于处于活动状态（应用程序在前台运行并且正在接收事件）时，最好拨打GCMService.sharedInstance().connectWithHandler() 。

您可能认为applicationDidBecomeActive和applicationDidEnterBackground是不对称的，但这两种方法都有一个单词Did。但另外两种方法有Will，意思是transitioning状态。

您还可以从this StackOverflow answer看到生命周期图片。

@ user102008评论后编辑：

如果您使用applicationWillEnterForeground方法进行连接，则首次启动应用时不会调用connect方法。此外，GCM文档说Call disconnect when the client app is in the background or when it needs to stop exponential background connection retry，所以我认为最好在应用程序处于后台时调用断开连接，而不是在电话呼叫到来时？我认为您可以使用包含3个不同状态{1}，connecting和not connected的枚举，当调用connected方法时，您可以检查它是否不是applicationDidBecomeActive或connected，然后再次调用connect方法。