strong-references

How can identify strong reference cycles in Swift?

匆匆过客 提交于 2021-02-05 12:48:10
问题 Is there a tool or method to locate strong references cycles in my SWIFT code? A strong reference cycle is when two instances of classes reference each other without the proper safeties ( weak / unowned ) hence preventing the garbage collector from disposing of them once all the variables I created stopped referencing those objects. 回答1: The method for finding strong reference cycles is the same in Swift as it is in Objective-C. You'd run the app from Xcode, exercise the app sufficiently to

Swift Weak Reference Much Slower than Strong Reference

淺唱寂寞╮ 提交于 2020-07-03 03:43:31
问题 I'm building a physics engine in Swift. After making some recent additions to the engine and running the benchmarking tests I noticed the performance was drastically slower. For example, in the screenshots below you can see how the FPS dropped from 60 to 3 FPS (FPS is in the bottom-right corner). Eventually, I traced the problem down to just a single line of code: final class Shape { ... weak var body: Body! // This guy ... } At some point in my additions I added a weak reference from the

Does Xcode Memory graph offer any smart visual indicators for strong references that aren't memory cycles?

风格不统一 提交于 2019-12-17 21:17:58
问题 As a follow up to my previous How can I create a reference cycle using dispatchQueues?: For the strong references (that create leaks, but aren't reference cycles) e.g. Timer , DispatchSourceTimer , DispatchWorkItem , the memory graph doesn't create a purple icon, I suspect it's simply because it doesn't find two objects pointing back to each other strongly. I know I can go back and forth and observe that a specific class is just not leaving the memory, but wondering if Xcode is providing

How is a strong retain cycle possible with async or static calls?

杀马特。学长 韩版系。学妹 提交于 2019-12-13 05:14:20
问题 I am trying to grasp how I can recognize when a strong retain cycle is possible and requires me to use [weak/unowned self] . I've been burned by unnecessarily using [weak/unowned self] and the self was deallocated immediately before giving me a chance to use it. For example, below is an async network call that refers to self in the closure. Can a memory leak happen here since the network call is made without storing the call it self into a variable? NSURLSession.sharedSession()

add __strong ivar at runtime under ARC

北城余情 提交于 2019-12-11 08:59:38
问题 A normal ivar declared in @interface is __strong default. @interface XLPerson : NSObject { NSString *name; // __strong default } @end Now, I create above class at runtime: Class XLPerson = objc_allocateClassPair([NSObject class], "XLPerson", 0); size_t size = sizeof(NSString*); class_addIvar(XLPerson, "name", size, log2(align), @encode(NSString*))); objc_registerClass(XLPerson); However, the ivar named "name" isn't a __strong ivar. While I using object_setIvar() , the Ivar can't hold the

Objective-C: Weak attritube don't work as expected [duplicate]

牧云@^-^@ 提交于 2019-12-09 15:14:00
问题 This question already has answers here : Closed 6 years ago . Possible Duplicate: Why do weak NSString properties not get released in iOS? I'm a newbie to Objective C and I've got some questions that I cannot answer myself. I have a block of code for testing __weak variable (I'm using ARC, of course): NSString *myString = [[NSString alloc] initWithFormat:@"John"]; NSString * __weak weakString = myString; myString = nil; //<-- release the NSString object NSLog(@"string: %@", weakString); The

How do weak and strong references look like in objective-c?

醉酒当歌 提交于 2019-11-30 03:38:31
Wikipedia states "In computer programming, a weak reference is a reference that does not protect the referenced object from collection by a garbage collector". How do those two types of references look like in code? Does a weak reference is a reference made by an autoreleased message? The following answer is for the case when there is no garbage collection (such as on iOS). In the case of garbage collection, there is actually a keyword ( __weak ) to create a weak reference. A "weak" reference is a reference that you do not retain. You need to use these weak references to break up cycles. A

Does Xcode Memory graph offer any smart visual indicators for strong references that aren't memory cycles?

不想你离开。 提交于 2019-11-29 16:23:10
As a follow up to my previous How can I create a reference cycle using dispatchQueues? : For the strong references (that create leaks, but aren't reference cycles) e.g. Timer , DispatchSourceTimer , DispatchWorkItem , the memory graph doesn't create a purple icon, I suspect it's simply because it doesn't find two objects pointing back to each other strongly. I know I can go back and forth and observe that a specific class is just not leaving the memory, but wondering if Xcode is providing anything more. Is there any other indicator? I know Xcode visually shows the number of instances of a type

What is difference between self.timer = nil vs [self.timer invalidate] in iOS?

生来就可爱ヽ(ⅴ<●) 提交于 2019-11-29 09:49:39
Can anyone explain me self.timer=nil vs [self.timer invalidate] ? What exactly happens at the memory location of self.timer ? In my code self.timer=nil doesn't stops the timer but [self.timer invalidate] stops the timer. If you require my code I will update that too. Once you have no need to run timer, invalidate timer object, after that no need to nullify its reference. This is what Apple documentation says: NSTimer Once scheduled on a run loop, the timer fires at the specified interval until it is invalidated. A non-repeating timer invalidates itself immediately after it fires. However, for

NSTimer memory management

牧云@^-^@ 提交于 2019-11-29 02:42:02
问题 When I execute this code: [NSTimer scheduledTimerWithTimeInterval:0.5 target:self selector:@selector(showButtons) userInfo:nil repeats:NO]; do I need to nil it or release it, ot whatever for memory management? I am using ARC 回答1: Yes, NSTimer will maintain a strong reference to the target , which can cause (especially in repeating timers) strong reference cycles (a.k.a. retain cycles). In your example, though, the timer does not repeat, and is delayed only 0.5, so worst case scenario, you