我在Xcode 4.6中有一个与Facebook连接的应用程序。我注意到,当应用程序进入后台并返回到前台时,每隔一段时间,应用程序中的不同点偶尔会发生崩溃。由于不一致,崩溃很难分析,所以我尝试使用仪器来识别内存泄漏。我对iOS很陌生,虽然我能够成功确定我确实有内存泄漏,我甚至可以看到哪些方法触发了它们,但我发现自己在想,“现在好吗?”换句话说,我看到问题所在,但我无法识别它。我希望如果我突出一个例子,有人可以解释一下。
**以下是我在仪器中看到的内容:
查看列表中第一个泄露的对象:
泄露的对象=“FB会话”
负责任的框架=
+[FBSession openActiveSessionWithPermissions:allowLoginUI:allowSystemAccount:isRead:defaultAudience:completionHandler:]
我将此解释为意味着此方法中存在一些泄漏的对象。那是对的吗?实现的方法存在于我的App Delegate中,如下所示:
- (BOOL)openSessionWithAllowLoginUI:(BOOL)allowLoginUI {
NSArray *permissions = [[NSArray alloc] initWithObjects:
@"user_about_me",
@"read_friendlists",
nil];
//IMPLEMENTED METHOD
return [FBSession openActiveSessionWithReadPermissions:permissions
allowLoginUI:allowLoginUI
completionHandler:^(FBSession *session,
FBSessionState state,
NSError *error) {
[self sessionStateChanged:session
state:state
error:error];
}];
}
此时,我不确定我需要做什么,或者这种方法甚至可能导致泄漏。我看过内存泄漏教程,但他们只是让我找到问题的定位,但没有帮助我弄清楚如何解决它。任何帮助表示赞赏。
答案 0 :(得分:1)
通常,您不应将self
传递给阻止,因为阻止了它。似乎FBSession也保留了completionHandler
,因此它变成了保留周期。
为了打破它,请使用以下结构之一:
__weak FBSession *zelf = self; // OK for iOS 5 only
__unsafe_unretained FBSession *zelf = self; // OK for iOS 4.x and up
__block FBSession *zelf = self; // OK if you aren't using ARC
然后
return [FBSession openActiveSessionWithReadPermissions:permissions
allowLoginUI:allowLoginUI
completionHandler:^(FBSession *session,
FBSessionState state,
NSError *error) {
[**zelf** sessionStateChanged:session
state:state
error:error];
}];
有关保留周期的详细说明,请参阅this post。