简体   繁体   English

应用程序卡在 iOS 9 上的启动画面中,没有错误

[英]App stuck in splash screen on iOS 9 with no error

My app gets stuck on splash screen in iOS 9 both on iPhone and simulator.我的应用程序在 iPhone 和模拟器上的 iOS 9 启动画面上都卡住了。 I can run it on iOS 8 or lower on device and simulator with no problem.我可以在 iOS 8 或更低版本的设备和模拟器上运行它,没有问题。 My colleague working on the same app has exactly the same problem.我在同一个应用程序上工作的同事遇到了完全相同的问题。

There is no error or anything, just hangs on splash screen.没有错误或任何东西,只是挂在启动画面上。 If I stop it on xcode and try to run it from the phone or simulator directly, it would run without any problem.如果我在 xcode 上停止它并尝试直接从手机或模拟器运行它,它会毫无问题地运行。

By the way, I don't see didFinishLaunchingWithOptions or willFinishLaunchingWithOptions getting called!顺便说一句,我没有看到didFinishLaunchingWithOptionswillFinishLaunchingWithOptions被调用!

在此处输入图片说明

In your "answer" you include the code:在您的“答案”中,您包含以下代码:

+(void)initialize
{

   titles = @[NSLocalizedString(@"CODE", nil), NSLocalizedString(@"ERROR", nil), NSLocalizedString(@"TROUBLESHOOTING", nil)];
}

This is indeed the source of your issue.这确实是您问题的根源。 It's wise to be very careful when implementing +load or +initialize .在实现+load+initialize时非常小心是明智的。 @bbum has a great article on exactly that topic. @bbum 有一篇关于该主题的精彩文章

+initialize is invoked the first time the class (or category) is touched - when the class is initialized +initialize is called by the class loading mechanism. +initialize在第一次接触类(或类别)时被调用 - 当类被初始化时+initialize被类加载机制调用。 There is no guarantee of when in the class loading process this may happen, which is part of your problem.无法保证在类加载过程中何时会发生这种情况,这是您的问题的一部分。

In your case you are using NSLocalizedString - which under the hood can be fairly heavy.在您的情况下,您使用的是NSLocalizedString - 它在引擎盖下可能相当沉重。 It has dependancies on several other classes ( NSString , etc) and can potentially access the file system.它依赖于其他几个类( NSString等)并且可以潜在地访问文件系统。 As @bbum points out in his article, that can lead to serious trouble.正如@bbum 在他的文章中指出的那样,这可能会导致严重的麻烦。 In your case, this may be a nasty deadlock.在您的情况下,这可能是一个令人讨厌的僵局。

Move your titles = @[NSLocalizedString... line to a more appropriate place in your object, like an initializer, awakeAfterUsingCoder:, etc. and your immediate problem should be solved.将您的titles = @[NSLocalizedString...行移动到对象中更合适的位置,例如初始化程序、awakeAfterUsingCoder: 等,您的当前问题应该得到解决。 After doing so you should check your entire codebase for instances where +initialize and +load are implemented and audit them to make sure those uses are in line with @bbum 's recommendations.这样做之后,您应该检查您的整个代码库中实现+initialize+load实例,并审核它们以确保这些使用符合@bbum 的建议。

OK I found the problem.好的,我发现了问题。 It sounds ridiculous though!!虽然听起来很可笑!!

I am using UITabBarController and inside the first controller I have a UITableViewController with a customised datasource class which would initiate a hard code table header and these headers are localised!!我正在使用UITabBarController并且在第一个控制器中我有一个带有自定义数据源类的UITableViewController它将启动一个硬代码表头,并且这些头是本地化的!!

+ (void)initialize {
    titles = @[NSLocalizedString(@"CODE", nil), NSLocalizedString(@"ERROR", nil), NSLocalizedString(@"TROUBLESHOOTING", nil)];
}

After I traced the stacks, I realised the process gets stuck right there with no trace and error!在我跟踪堆栈之后,我意识到这个过程卡在那里,没有任何跟踪和错误! I still don't know why!我还是不知道为什么!

So I came up with a workaround:所以我想出了一个解决方法:

+ (void)initialize {
    titles = @[@"Code",@"Error",@"Troubleshooting"];
}

And only retrieve the localised value when returning the text:并且仅在返回文本时检索本地化值:

- (NSString *)titleAt:(NSInteger)index {
    return NSLocalizedString(titles[index],nil);
}

Ok, I think I found the answer.好的,我想我找到了答案。

You have to specify arm64 in all "Valid Architectures".您必须在所有“有效架构”中指定 arm64。 If you don't specify arm64 or forget one the app won't start and stays on the splashscreen.如果您没有指定 arm64 或忘记了一个应用程序将不会启动并停留在启动画面上。

Just verified this.刚刚验证了这一点。

Is this an Xcode 7 bug?这是 Xcode 7 的错误吗?

我将调试和发布都设置为 NO 您确定“任何 SDK”也有 arm64?

我有同样的问题通过pod update更新了我的pod update ,它对我有用

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM