SBNotificationHub仅在从Testflight Beta构建发行版中的registerTemplateWithDeviceToken返回时崩溃

Question

如果我禁用该应用的通知，我不会同步，该应用程序运行正常。 如果启用了它们，并且代码注意到并尝试同步-它就会崩溃。

应用程序几周来一直在100％正常运行，而无需更改代码。 想知道在相同的测试设备上相同构建的方案之间的切换是否正在进行。

使用从Xcode到设备的相同的非调试/生产方案，可以正常运行。 但是通过官方存档构建的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

Answer 1

编辑 ：我一直跟踪到这一行代码 ，由于模板名称为nil ，我认为该代码已落空 。 在我的服务器代码（也与集线器进行交互）中，我没有传递template name因此它被淘汰了。 但是，仅此一项并不会导致崩溃。 随着设备ID的更改或类似原因，我还没有发现一个场景。 当我弄清楚什么时，我会更新。

编辑2 ：对于少数经历过这种情况的用户，Azure中数据的共同特征（如上面的代码所示）是缺少TemplateName 。 可以通过将nil名称传递给：来手动强制崩溃：

[hub registerTemplateWithDeviceToken:deviceToken 
                                name:nil 
                    jsonBodyTemplate:alertTemplate 
                      expiryTemplate:@"0" 
                                tags:[NSSet setWithArray:tags] 
                          completion:^(NSError* error) {

我不知道Azure发生了什么，使得有效字符串名称的调用没有更新Azure数据并返回有效值，但我的直觉是Azure端存在竞争条件和错误。

现在，我们将在Azure中抓取已注册的用户数据，并修复nil模板名称，我们已验证该模板名称为在此悲伤周期中陷入困境的用户解决了此问题。

更新 -这确实是修复。 自纠正错误的用户模板数据以来没有崩溃。

原始答案 ：不是一个非常令人满意的解决方案，但我禁用了应用程序的通知（通过操作系统设置），使用该应用程序取消订阅我订阅的所有标签（批量）。 然后重新启用通知，并且崩溃不再发生。

现在，我的生产Xcode方案和测试航班安装都会产生相同的设备ID。 这似乎不是问题的根源，但谁知道。 知道SDK在它崩溃的地方试图保持什么是非常有趣的 - 这将是弄清楚发生了什么的最可靠的方法。