在测试我们的 iPhone 应用程序的新版本时，我们偶尔会看到应用程序窗口在 applicationWillEnterForeground 之后的某个时间恢复应用程序时完全变黑。使应用程序再次运行的唯一方法是完全关闭它，然后重新启动应用程序。我们无法确定持续重现的步骤。这个问题似乎是随机发生的，但只有在将其置于后台后返回应用程序时才会发生。有时它会在几秒钟后发生，有时它不会发生超过一周。
以下是正常操作期间主视图中的线程：
这是发生此问题时的线程，我暂停调试器：
我尝试过的事情
应用程序恢复时记录所有内容
应用程序恢复时似乎没有任何问题。此外，在applicationDidBecomeActive按下主页按钮之前，我的任何代码都不会执行。
2013-05-15 22:22:23 AppDelegate::applicationDidBecomeActive
2013-05-15 22:22:23 self.window = <UIWindow: 0x1dd6ee80; frame = (0 0; 320 480); opaque = NO; autoresize = RM+BM; layer = <UIWindowLayer: 0x1dd6ef80>>
2013-05-15 22:22:23 self.window.subviews.count = 7
2013-05-15 22:22:23 self.navigationController = <UINavigationController: 0x1dd87190>
2013-05-15 22:22:23 self.navigationController.visibleViewController = <MyViewController: 0x1dd7ffe0>
2013-05-15 22:22:23 self.navigationController.view = <UILayoutContainerView: 0x1dd876e0; frame = (0 0; 320 480); autoresize = W+H; layer = <CALayer: 0x1dd877a0>>
2013-05-15 22:22:23 self.navigationController.viewControllers.count = 1
2013-05-15 22:22:23 TestFlight: App Token is recognized
2013-05-15 22:22:24 AppDelegate::applicationWillResignActive
2013-05-15 22:22:24 TestFlight: End of Session
日志中有几项一开始我很关心，但我在正常操作期间观察到了它们，所以我不再认为它们相关。以防万一，它们是：
紧跟 ApplicationWillEnterForeground：
installd[54] <Error>: 0x2ff8d000 filter_attributes: Info.plist keys requested via MobileInstallationLookup/Browse in client Xcode (via mobile_installation_proxy) were not found in MobileInstallation's cache. Please file a bug requesting that these keys be added: <CFBasicHash 0x1cd86080 [0x3c44d100]>{type = mutable set, count = 18,
entries =>
0 : <CFString 0x3c4399f4 [0x3c44d100]>{contents = "CFBundlePackageType"}
1 : <CFString 0x1cebf1e0 [0x3c44d100]>{contents = "BuildMachineOSBuild"}
2 : <CFString 0x3c43aa44 [0x3c44d100]>{contents = "CFBundleResourceSpecification"}
3 : <CFString 0x1ce90cf0 [0x3c44d100]>{contents = "DTPlatformBuild"}
4 : <CFString 0x3c437794 [0x3c44d100]>{contents = "DTCompiler"}
5 : <CFString 0x3c439564 [0x3c44d100]>{contents = "CFBundleSignature"}
6 : <CFString 0x3c43a224 [0x3c44d100]>{contents = "DTSDKName"}
7 : <CFString 0x1cebe5f0 [0x3c44d100]>{contents = "NSBundleResolvedPath"}
8 : <CFString 0x3c436eb4 [0x3c44d100]>{contents = "UISupportedInterfaceOrientations"}
10 : <CFString 0x3c43ee84 [0x3c44d100]>{contents = "DTXcode"}
13 : <CFString 0x3c43eeb4 [0x3c44d100]>{contents = "CFBundleInfoDictionaryVersion"}
16 : <CFString 0x3c43c304 [0x3c44d100]>{contents = "CFBundleSupportedPlatforms"}
17 : <CFString 0x1ceabd10 [0x3c44d100]>{contents = "DTXcodeBuild"}
18 : <CFString 0x1cebb610 [0x3c44d100]>{contents = "UIStatusBarTintParameters"}
19 : <CFString 0x3c43ae54 [0x3c44d100]>{contents = "DTPlatformVersion"}
20 : <CFString 0x3c43dbf4 [0x3c44d100]>{contents = "DTPlatformName"}
21 : <CFString 0x3c43ec84 [0x3c44d100]>{contents = "CFBundleDevelopmentRegion"}
22 : <CFString 0x1ceb9ae0 [0x3c44d100]>{contents = "DTSDKBuild"}
}
不久之后：
lockdownd[45] <Notice>: 2ff24000 special_case_get: MGCopyAnswer(kMGQReleaseType) returned NULL
删除 TestFlight
这是一个通过 TestFlight 分发的构建，我们已经成功地用于之前的几个版本。我在 Xcode 部署的构建中也观察到了这种行为，因此至少在部署方面，排除了 TestFlight 作为潜在的违规者。此外，我已经从代码中删除了 TestFlight 调用并测试了应用程序。几天后，我观察到了这个问题，所以我知道它与 TestFlight 无关。
验证所有 NSURLConnections 都是异步执行的
验证 UI 的所有更新都是在主线程上执行的
在这一点上，我真正拥有的唯一信息是 main 和 UIApplicationMain 不再在堆栈上。怎么会这样？
此外，这个应用程序使用 SDWebImage 并且当这个问题发生时显示视图中有 UIImageViews，所以可能存在问题，但我真的怀疑这样一个高度使用的库会有如此明显的缺陷。