【发布时间】：2013-05-23 09:20:23
【问题描述】：
在测试我们的 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，所以可能存在问题，但我真的怀疑这样一个高度使用的库会有如此明显的缺陷。
【问题讨论】：
-
您可以在文档文件夹中创建一个日志文件，并记录在进入后台然后返回时发生的各种事件。从 iCloud 或 iTunes 中提取日志。对此进行迭代可能会导致您遇到问题。
-
@DavidH，感谢您的建议。你能详细说明一下这个过程吗？它与您可以通过 Xcode 管理器访问的普通控制台日志记录相比有何优势？
-
因为这只是为了调试使用appDelegate。它会在 Documentation 目录中打开一个文件，实质上您将 ASCII 消息输出到该文件，然后在每条消息之后同步该文件。我个人发现 iOS 控制台不那么可靠，但您可以先尝试一下。线程 1 看起来很糟糕，但不知道这是怎么发生的。您需要在起床时记录所有内容。
-
您是否曾经解决过这个问题和/或找到黑屏的根源？我遇到了类似的问题，希望有任何见解！
-
@BenchtopCreative 不幸的是，没有。此后，我们对 iOS 7 的 UI 进行了重大重写，我们不再看到问题，但从未确定原因。
标签： iphone ios testflight sdwebimage