dealloc

Memory leak with UIWebView

由 好久不见. 提交于 2019-12-05 04:57:30
My project is a hybrid static lib for showing a UIWebView with some JS to control the logic. When I use 64bit and run demo on iOS 8/iPhone 6, the memory keeps going to 30M or more! When I use generation in instrument, the increased memory usage is almost all from webcore; does it means there are leaks in JS code? I can't find a leak when I use Safari to run similar JS directly. When I release the UIWebView, the memory is still not freed; I tested with instrument allocation. There are some webcore and (non - object) still in memory, what can I do to release them? 0JavaScriptCore WTF::MallocHook

Invalidating an NSTimer in dealloc

由 匆匆过客 提交于 2019-12-05 02:58:44
问题 Following this question, and more specifically, this comment: because retain (aka strong reference) cycles in the common case where the timer's target is also its owner I am wondering why dealloc isn't a good place to invalidate an NSTimer . I remember profiling my app without auto-repeating NSTimer invalidation and then with invalidation in dealloc , and the memory correctly freed. Is dealloc working differently in the latest iOS? Isn't in fact your overridden dealloc called prior to any

Suicide: Objective-C objects calling their own -dealloc methods on themselves

由 元气小坏坏 提交于 2019-12-04 19:11:57
Is it good practice for an object in Objective-C to commit suicide? That is, for an object to declare [self dealloc] where -dealloc permits an orderly wind down as usual? What are the principal risks? As it happens I have a specific example, a custom timer object that extends NSObject and comprises an NSTimer instance and an NSUInteger which is set to limit the number of times the timer fires. When time is up the object tells the timer to -invalidate and then commits suicide by calling its -dealloc method. As this is automatic we have no worries about having to track the object or crucially

View controller dealloc not called when using NSNotificationCenter code block method with ARC

由 强颜欢笑 提交于 2019-12-04 04:58:30
When I use -addObserverForName: object: queue: usingBlock: for NSNotificationCenter in the -viewDidLoad: method of my view controller, the -dealloc method ends up not being called. (When I remove -addObserverForName: object: queue: usingBlock: , -dealloc is called again.) Using -addObserver: selector: name: object: doesn't seem to have this problem. What am I doing wrong? (My project is using ARC.) Below is an example of my implementation, in case I'm doing something wrong here: [[NSNotificationCenter defaultCenter] addObserverForName:@"Update result" object:nil queue:nil usingBlock:^

Correct [super dealloc]

由 …衆ロ難τιáo~ 提交于 2019-12-03 17:21:19
问题 Does the order of statements in the dealloc method matter? Does the [super dealloc] need to be at the top of the method? Does it matter? Also in e.g. viewDidLoad . Should [super viewDidLoad] be at the top of the method? 回答1: It ABSOLUTELY matters. What you do depends on whether you're using Automatic Reference Counting (ARC) or manual reference counting. Using Manual Release-Retain Manual Release-Retain (MRR) is default memory management for all versions of Mac OS X, and the only way to

Invalidating an NSTimer in dealloc

由 非 Y 不嫁゛ 提交于 2019-12-03 17:17:02
Following this question , and more specifically, this comment : because retain (aka strong reference) cycles in the common case where the timer's target is also its owner I am wondering why dealloc isn't a good place to invalidate an NSTimer . I remember profiling my app without auto-repeating NSTimer invalidation and then with invalidation in dealloc , and the memory correctly freed. Is dealloc working differently in the latest iOS? Isn't in fact your overridden dealloc called prior to any NSObject deallocation? What is dealloc even used for, then? If not manually deallocating the respective

If a function returns an UnsafeMutablePointer is it our responsibility to destroy and dealloc?

由 耗尽温柔 提交于 2019-12-03 15:41:27
问题 For example if I were to write this code: var t = time_t() time(&t) let x = localtime(&t) // returns UnsafeMutablePointer<tm> println("\(x.memory.tm_hour): \(x.memory.tm_min): \(x.memory.tm_sec)") ...would it also be necessary to also do the following? x.destroy() x.dealloc(1) Or did we not allocate the memory and so therefore don't need to dismiss it? Update #1: If we imagine a function that returns an UnsafeMutablePointer : func point() -> UnsafeMutablePointer<String> { let a =

Who calls the dealloc method and when in Objective C?

由 拜拜、爱过 提交于 2019-12-03 11:39:52
问题 When a custom class is created in Objective C, when and how is the dealloc method called? Is it something that I have to implement somehow in my class? 回答1: You never send a dealloc message directly. Instead, an object’s dealloc method is invoked indirectly through the release NSObject protocol method (if the release message results in the receiver's retain count becoming 0). See Memory Management Programming Guide for more details on the use of these methods. Subclasses must implement their

UIPopoverController dealloc getting called—ARC environment

由 拈花ヽ惹草 提交于 2019-12-03 09:59:07
While displaying a popover controller for a second time (after dismissing it and then re-displaying it), I get the following error: Terminating app due to uncaught exception 'NSGenericException', reason: '-[UIPopoverController dealloc] reached while popover is still visible.' The stack trace is only a bunch of hex and the SIGABRT happens at UIApplicationMain every time. Here's the code that the button triggers: - (IBAction)createNewScore:(id)sender { if (self.pc) if (self.pc.popoverVisible) return; else // Breakpoint is hit here—crashes after this line [self.pc presentPopoverFromBarButtonItem:

Adding and removing observers to NSNotificationCenter in a UIViewController

由 天涯浪子 提交于 2019-12-03 07:58:47
问题 Looking at various Apple examples (for example Add Music) in which I see they add observers to the default NSNotificationCenter in viewDidLoad , then remove them in dealloc . This seems dangerous as viewDidLoad can be called multiple times without dealloc being called. This would then add the same observer multiple times, causing the handler to be called multiple times. A solution to this would be to also remove observers in viewDidUnload , but this would then mean the same observer could be
订阅 dealloc