邀请停止广告的同伴时，Multipeer Connectivity崩溃

问题描述

限时删除！！

我有以下情况：

• Peer A 正在等待自定义用户界面中的邀请（让我们看看）称之为 WaitingVC ）。应用程序启动时初始化 MCNearbyServiceAdvertiser 对象，当时，广告开始（ startAdvertisingPeer ）显示WaitingVC 。


• Peer B 已启动并运行 MCNearbyServiceBrowser ，也使用自定义UI（即不使用Apple提供的 MCBrowserViewController ）。


• Peer B 发现Peer A （浏览器：foundPeer：withDiscoveryInfo：被调用）。


• 同时Peer 选择关闭 WaitingVC 。广告已停止（ stopAdvertisingPeer ）。


• 在Peer B 发现之前，有几秒滞后，Peer A 丢失（即浏览器：lostPeer：被调用）。


• 如果在这几秒钟内，Peer B 选择邀请Peer A （他们似乎仍可用于Peer B ），Peer A 崩溃（是的，被邀请的人，通常会停止投放广告）。


• 对等 B 的邀请通常会超时，并且不会出现任何问题。

• Peer A is waiting for invitations in a custom UI (let's call it WaitingVC). The MCNearbyServiceAdvertiser object is initialized at application start, and the advertising starts (startAdvertisingPeer) when the WaitingVC is presented.
• Peer B has the MCNearbyServiceBrowser up and running, also with custom UI (that is, not using the Apple provided MCBrowserViewController).
• Peer B finds Peer A (browser:foundPeer:withDiscoveryInfo: is called).
• Meanwhile Peer A chooses to close the WaitingVC. Advertising is stopped (stopAdvertisingPeer).
• There is a few seconds lag, before Peer B finds out, that Peer A is lost (that is, browser:lostPeer: is called).
• If in these few seconds, Peer B chooses to invite Peer A (who still seems to be available for Peer B), Peer A crashes (yes, the invited one, who normally stopped advertising).
• Peer B's invite normally times out, and no problem arises.

崩溃发生在队列 com.apple.NSNetServices.tcplistener-queue 。发布时 dispatch_call_block_and_release 调用失败（ EXC_BREAKPOINT ）。

The crash happens in queue com.apple.NSNetServices.tcplistener-queue. A dispatch_call_block_and_release call fails at release (EXC_BREAKPOINT).

我真的很想知道，如果这是MC框架中的一个错误;或者我错过了一些清理程序？对等 A 仅执行以下操作：

I truly wonder, if this a bug in the MC framework; or am I missing some cleanup procedure? Peer A only does the following:

• 应用委托：创建 MCPeerID ，存储在强大的属性中，


• 应用代理：创建 MCNearbyServiceAdvertiser ，存储在强大的属性中，设置委托，


• 在 WaitingVC ：调用 startAdvertisingPeer ，然后调用 stopAdvertisingPeer 完成后。

• App delegate: Creating an MCPeerID, store in a strong property,
• App delegate: Creating an MCNearbyServiceAdvertiser, store in a strong property, setting delegate,
• In WaitingVC: calling startAdvertisingPeer, then calling stopAdvertisingPeer when done.

无论我做什么，崩溃似乎都会发生。如果 MCNearbyServiceAdvertiser 对象和 MCPeerID 对象保存在 WaitingVC 因此在 WaitingVC 关闭后销毁，崩溃仍然发生。

The crash seemingly occurs no matter what I do. If the MCNearbyServiceAdvertiser object and the MCPeerID object is being kept in WaitingVC and thus destroyed after the WaitingVC is closed, the crash still happens.

除此之外，一切正常罚款（邀请程序，连接，交换数据）;但这几秒钟的某些失败窗口并不是真的可以接受。保持广告客户一直运行解决了这个问题，但它只是处理symtpom（这个同步功能很少会在应用程序中使用，所以它也是一种矫枉过正的行为）。

Apart from this, everything works fine (invitation procedure, connecting, exchanging data); but this few seconds window for certain failure is not really acceptable. Keeping the advertiser running all the time solves this, but it's just treating the symtpom (and this "sync" feature would be used seldom in the applicaiton, so it's also an overkill).

更新：

使用 MCAdvertiserAssistant 时发生同样的崩溃，如果我在Peer A 上调用其停止方法，并快速连接Peer B 。此外，我测试了本教程中的场景： - 结果是一样的：崩溃。所以我有一个强烈的怀疑，这是苹果方面的一个错误......

The same crash happens when using MCAdvertiserAssistant, if I call its stop method on Peer A, and quickly connect on Peer B. Also, I tested the scenario on this tutorial: http://techmaster.vn/2013/09/multipeer-connectivity-quick-tutorial/ - and the result is the same: Crash. So I have a strong suspicion, this is a bug on Apple's side...

推荐答案

我一直在经历同样的崩溃并根据开发论坛中的这个主题，所以有其他人。已为其创建错误报告：

I've been experiencing the same crash and according to this thread in the Dev Forums so have other people. A bug report has been created for it:

这篇关于邀请停止广告的同伴时，Multipeer Connectivity崩溃的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！

1403页，肝出来的..