IOS Programmer Level 6 Exam (answer and explanation)

IOS Programmer Level 6 Exam (answer and explanation) I'm the preface.

1. What does the following code output?

@implementationson: father -(id) init { Span class= "line" > self = [super init]; if (self) {

Answer: All output "Son"
Explanation: OBJC super is a compiler identifier, not the same as self an object, encountered in the super method of the postback will be translated into objc_msgSendSuper(...) , and the parameters of the object or self , so from the parent class along the inheritance chain - class to find this method, and finally in the NSObject (if no Override) is found, [self class] and [Super class] is now equivalent.

2. The following code error? Warning? or the normal output of what?

Father *father = [Father new]; BOOL B1 = [father Responsetoselector:@selector (responsetoselector:)]; BOOL b2 = [Father responsetoselector:@selector (responsetoselector:)]; NSLog (@ "%d,%d", B1, B2);

Answer: Both output "1" (YES)
Explanation: In OBJC:

• An object of type ID, whether it is an instance object or class (class is also an object)
• The instance object's Isa points to its class (store all minus methods), and the class object's Isa points to the Meta class (store all the plus methods)
• When you send a message to an object (ID type), you look for a method from the class that the object's isa pointer is pointing to

Back to the topic, when Father an instance method ( - responseToSelector ) message is sent like a class:

1. Will look for it, that is, the isa Father meta-class object, because the method in the meta-class is a class method, so naturally cannot find
2. So along the inheritance chain to look for the parent class NSObject Meta class, still no
3. Since OBJC's design of this block is that the parent class of NSObject's meta class is the NSObject class (that is, we are familiar with the NSObject Class), which has all the instance methods, so we find the- responseToSelector

Add: All instance methods in the NSObject class 很可能 implement a class method (which can be seen at least from open source code), such as + resonseToSelector , but not the public API, and if so, this method can be found in step 2nd above.
Add: The non-nsobject selector does not work.

3. The request will be completed soon, but the Completionblock will be set up after a long time, can it be executed?

... Currently in the main thread The background thread is called asynchronously and is called Completionblock on the main thread when completed Sleep (///Sleep main thread, so that the following code can be executed after the background thread completes [Request setcompletionblock:^{ NSLog (@ "Can I am printed?"); }]; ...

Answer: Yes (conditional)
Explanation: For convenience of explanation, we consider it as gcd a two linear queue : main queue and back queue

When the code executes sleep(100) , the order in which the two queues are executed looks like this:

• Main: *-sleep ————————-> | -setcompletionblock->
• Back: *-network-->

The network request comes back soon, and the callback function is typically executed as follows:

Back to main thread execution callback Dispatch_async (Dispatch_get_main_queue (), ^{ if (Self.completionblock) Self.completionblock (); });

And so it became:

• Main: *--sleep--> | -setcompletionblock-> | -invoke completionblock-->
• Back: *

So, when sleep finishes, the main thread keeps the call order:

• Main: *-setcompletionblock-> | -invoke completionblock-->

At this point, completionBlock the execution is in setCompletionBlock , after, so the callback can be normal.

Note: This explanation has a restrictive condition, and if you use the following callback method, the situation will be different:

Back to main thread execution callback if (self.completionblock) { Dispatch_async (Dispatch_get_main_queue (), ^{ Self.completionblock (); });

4. Is there a problem with this when you do not use IB?

-(void) Viewdidload { [Super Viewdidload]; CGRectMake (0.5); UIView *view = [[UIView alloc] initwithframe:frame]; [Self.view Addsubview:view]; }

Explanation: When you do not use IB to create Viewcontroller manually, the viewDidLoad location is not initialized in, the original encountered many times this small pit, when the external creation of this VC:

Testviewcontroller *VC = [[Testviewcontroller alloc] init]; CGRectMake (100); //...

We know that ViewController the approximate process of view initialization is:

-(UIView *) View { if (!_view) { [Selfloadview]; [//Edit: This sentence moves into parentheses, thanks to @change2hao's reminder } }

Therefore, when the external execution of vc.view.frame = CGRectMake(0, 0, 100, 100); this sentence, before the assignment operation, has been viewDidLoad called, so in the viewDidLoad value of the view frame is the default value (window size), not the set value.

Note: When using IB loading, this can happen as well, but generally there is a default value in IB.

5. What does the following code output?

-(void) Viewdidload { [Super Viewdidload]; NSLog (@ "1"); Dispatch_sync (Dispatch_get_main_queue (), ^{ NSLog (@ "2"); }); NSLog (@ "3"); }

Answer: Program deadlock after output 1
Explanation: dispatch_sync the document mentions:

Calls to Dispatch_sync () targeting the current queue would result in Dead-lock. Use of Dispatch_sync () was also subject to the same multi-party dead-lock problems, which may result from the use of a mutex. Use of Dispatch_async () is preferred.

The block of sync to the current thread will cause a deadlock, so the main thread will enter the deadlock state and will not continue execution until the log is out.
The reason, but also depends on what dispatch_sync do, it inserts a block into the queue, which is no different from async, the difference is that sync will wait until the block execution is complete before returning to the call point to continue execution, The execution of this block also relies on the end of the Dispatch_sync call in the Viewdidload, so the loop waits, causing a deadlock.

Follow-up topics continue to be supplemented

IOS Programmer Level 6 Exam (answer and explanation)