Ioseasy causes a referenced scene

Scene One: Nstimer

Timer is an object that can run the method we specify at some point in the future from now on, or periodically.

Nstimer Runnecessary: The runloop of the corresponding thread should be turned on, mode should be

Here is a circular reference to the timer:

, we write this class, and when we initialize this class there will be a timer open. Then when we go to release the current class, it is not going to go to the Dealloc function, because the timer will be on the current class count +1, and then the timer holding self,self holding the timer will cause a dead loop. Cause a memory leak. And the way to break the circular reference is invalidate.

Scenario Two:[self performselector: @selector (method:) withobject:self afterdelay: 5] ;

When the method is not running, return to the parent view when the current view is released. The Count of self is not lowered to 0, and the Dealloc method cannot be called , and a memory leak occurs

How to resolve:

1.[nsobject cancelpreviousperformrequestswithtarget:self]

2.[nsobjectcancelpreviousperformrequestswithtarget:self selector: @selector (method1:) Object:nil]

Scenario Three:addobserver

Q&a:

1. after addobserver to the nsnotificationcenter , there no reference count is made to this object Plus 1 operation?

2. In an already released nsobject viewcontroller What will the results be?

3.  [[ nsnotificationcenter Span style= "font-family:arial" >  defaultcenter ]  removeobserver :  name :   object:nil ;  

and the .

[[nsnotificationcenter defaultcenter ] Removeobserver:] How to choose

We first solve question 2nd. 。 In an already released nsobject viewcontroller class notice  nsobject will crash. An address error is prompted. Note that the notification simply remembers his address pointer, technology does not add 1, while the viewcontroller Crash does not occur when the class sends a notification. Why is that?

that is: viewcontroller will call Dealloc when    [[ nsnotificationcenter   defaultcenter    removeobserver :self  ;

and how do we verify it. That's to give nsnotificationcenter plus a category, overriding removeObserver :self method. will be very easy to find, you will also send the Dealloc now will remove the system notification, in fact, Apple is doing so.

last question: So how to make a choice? is to not call removeobserver :self in places other than Dealloc   Instead, use a single-removal method [[ nsnotificationcenter   defaultcenter ]  removeobserver :  name :   object:nil  

Scene Four:

Try be at risk. Catch requires caution

@try {

// code that may throw an exception

}

@catch (NSException *exception) {

// handling Exceptions

}

@finally {

//finally code block is optional

//But suppose written finallyblock, whether there is no abnormality, The code inside the block will be run

}

Then we will be able to play the following:

@try {

// code that may throw an exception

testtryctch*object = [[Testtryctch alloc] init];

[Object dosmmaythrowexception];//Exception function

[Object release];

}

@catch (NSException *exception) {

// handling Exceptions

NSLog (@ "Throw an exception:%@", Exception.reason);

}

@finally {

NSLog (@ "finally execution");

}

Will the above code have an exception???

Yes, it will. ，[Object dosmmaythrowexception];//] The exception function directly skips the object release. Generate memory leaks

Scenario Five: dead Loops

Catransition*transition = [catransition animation];

Transition.duration= 0.5;

Tansition.repeatcount= Huge_vall;

[self.view.layeraddAnimation:transition forkey: "Myanimation"]

, suppose Huge_vall is a memory leak resolution for a very large number :

-(void) Viewwilldisappear: (BOOL) animated{

[Self.view.layer removeallanimations];

}

Ioseasy causes a referenced scene