SBNotificationHub仅在Testflight Beta版本发行版中从registerTemplateWithDeviceToken返回时崩溃
如果我禁用应用程序的通知，我不会同步，应用程序运行良好。 如果它们被启用，并且代码注意并尝试同步 – 则会崩溃。
应用程序一直工作100％罚款周没有代码的变化。 想知道是否在相同的testing设备上的相同的构buildscheme之间切换是在放置东西。
工作正常，从Xcode到设备运行相同的，非debugging/生产，scheme。 但通过官方存档构build的Testflight应用程序安装它崩溃。 很奇怪。
任何见解？
Thread : Fatal Exception: NSInvalidArgumentException 0 CoreFoundation 0x000000018714659c __exceptionPreprocess + 132 1 libobjc.A.dylib 0x00000001978980e4 objc_exception_throw + 60 2 CoreFoundation 0x00000001870311f8 -[__NSDictionaryM setObject:forKey:] + 972 3 0x0000000100522580 -[SBLocalStorage updateWithRegistrationName:registration:] (SBLocalStorage.m:89) 4 0x00000001005223fc -[SBLocalStorage updateWithRegistration:] (SBLocalStorage.m:59) 5 0x000000010051ceb4 __72-[SBNotificationHub retrieveAllRegistrationsWithDeviceToken:completion:]_block_invoke (SBNotificationHub.m:314) 6 0x000000010051b31c -[SBURLConnection connectionDidFinishLoading:] (SBURLConnection.m:115) 7 CFNetwork 0x0000000186beae70 __65-[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:]_block_invoke + 80 8 CFNetwork 0x0000000186beae00 -[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:] + 208 9 CFNetwork 0x0000000186beaf7c -[NSURLConnectionInternal _withActiveConnectionAndDelegate:] + 60 10 CFNetwork 0x0000000186abf8e4 ___ZN27URLConnectionClient_Classic26_delegate_didFinishLoadingEU13block_pointerFvvE_block_invoke + 104 11 CFNetwork 0x0000000186b88540 ___ZN27URLConnectionClient_Classic18_withDelegateAsyncEPKcU13block_pointerFvP16_CFURLConnectionPK33CFURLConnectionClientCurrent_VMaxE_block_invoke_2 + 104 12 CFNetwork 0x0000000186aabb54 RunloopBlockContext::_invoke_block(void const*, void*) + 76 13 CoreFoundation 0x0000000187028aac CFArrayApplyFunction + 68 14 CFNetwork 0x0000000186aaba00 RunloopBlockContext::perform() + 136 15 CFNetwork 0x0000000186aab8b4 MultiplexerSource::perform() + 312 16 CFNetwork 0x0000000186aab6e0 MultiplexerSource::_perform(void*) + 68 17 CoreFoundation 0x00000001870fe9ec __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 24 18 CoreFoundation 0x00000001870fdc90 __CFRunLoopDoSources0 + 264 19 CoreFoundation 0x00000001870fbd40 __CFRunLoopRun + 712 20 CoreFoundation 0x00000001870290a4 CFRunLoopRunSpecific + 396 21 GraphicsServices 0x00000001901c35a4 GSEventRunModal + 168 22 UIKit 0x000000018b95aaa4 UIApplicationMain + 1488 23 0x00000001000dabc0 main (main.m:14) 24 libdyld.dylib 0x0000000197f06a08 start + 4 这是Windows Messaging Azure SDK的1.2.4版本
编辑 ：另外v2.0
编辑 ：我跟踪到这一行的代码 ，我相信由于没有模板名称摔倒。 在我的服务器代码也与集线器进行交互，我没有传递template name所以它被淘汰出局。 但是，这本身并不会导致崩溃。 有一种情况我还没有发现设备ID改变，或类似的，这是表面。 当我弄清楚什么时我会更新。
编辑2 ：对于那些遇到这种情况的less数用户来说，他们在Azure中的数据的共同特征，以及上面代码暗示的是一个缺less的TemplateName 。 通过传递一个零的名字来手动强制崩溃是可能的：
[hub registerTemplateWithDeviceToken:deviceToken name:nil jsonBodyTemplate:alertTemplate expiryTemplate:@"0" tags:[NSSet setWithArray:tags] completion:^(NSError* error) {
我不知道Azure发生了什么事情，因此使用有效string名称的调用不会更新Azure数据并返回有效值，但是我的直觉是Azure方面存在竞争条件和错误。
现在，我们正在爬行Azure中的注册用户数据，并修复了我们已经validation的无模板名称，以便为陷入这种悲伤循环的用户解决问题。
更新 – 这确实是修复。 自更正不良用户模板数据以来没有发生崩溃。
原来的答案 ：不是一个非常充实的解决scheme，但我禁用了应用程序的通知（通过操作系统设置），使用应用程序来取消订阅我订阅的所有标签（大量）。 然后重新启用通知，崩溃不再发生。
现在我的生产Xcodescheme和testing飞行安装都会得到相同的设备ID。 这似乎不是问题的根源，但谁知道。 了解SDK在发生崩溃时试图坚持什么是非常有趣的，这将是确定发生的最可靠的方法。