Shulou(Shulou.com)06/03 Report--

This article mainly explains "how to understand the main thread and the main Runloop". The content in the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "how to understand the main thread and the main Runloop".

Pre

MacOS:Catalina 10.15.7

Xcode:12.3

Objc4:objc4-787.1

Basic Concepts CFRunloop

The CFRunLoop object monitors the input source of the task and dispatches control when they are ready for processing.

Running a loop can monitor three types of objects: CFRunLoopSource, CFRunLoopTimer, and CFRunLoopObserver.

Each source, timer, and observer added to the run loop must be associated with one or more run loop modes.

Core Foundation defines a special pseudo pattern called common modes, which allows you to associate multiple patterns with a given source, timer, or observer.

There is only one running loop per thread. You neither create nor destroy the thread's running loop. Core Foundation will automatically create it for you as needed.

The run loop can be run recursively. You can call CFRunLoopRun or CFRunLoopRunInMode in any run loop call and create a nested run loop activation on the call stack of the current thread.

Cocoa applications are built on top of CFRunLoop and implement their own advanced event loops. When writing applications, you can add source code, timers, and observers to their running loop objects and patterns. Your object is then monitored as part of a regular application event loop. The corresponding CFRunLoopRef type can be obtained using the gettcfrunloop method of NSRunLoop.

NSRunloop

NSRunLoop is the encapsulation of CFRunloop in Core Fundation

The NSRunLoop object handles input from sources such as mouse and keyboard events, NSPort objects, and NSConnection objects in the window system. The NSRunLoop object also handles the NSTimer event.

Your application neither creates nor explicitly manages NSRunLoop objects. Each NSThread object, including the main thread of the application, has a NSRunLoop object that is automatically created as needed. If you need to access the running loop of the current thread, you can use the class method currentRunLoop to do so.

Note that from NSRunLoop's point of view, NSTimer objects are not "inputs"-- they are a special type, which means that when they are triggered, they do not cause a running loop to return.

The NSRunLoop class is generally considered thread-unsafe and its methods should only be called in the context of the current thread. Never try to call a method of a NSRunLoop object running in a different thread, as doing so can lead to unexpected results.

Thread & Runloop first look at the conclusion! Draw the point!

Both Cocoa and Core Foundation provide run loop objects (NSRunloop and CFRunloop) to help configure and manage threads' running loops.

The application does not need to create these objects explicitly; each thread (including the main thread) has an associated Runloop object.

As part of the application startup process, the application framework automatically sets up and runs the loop on the main thread. Child threads need to explicitly run their running loops.

Relationship summary: after App starts, Apple creates its associated Runloop in the main thread and registers two Observer in that Runloop

The first event: BeforeWaiting (ready to go to sleep). In the callback, _ objc_autoreleasePoolPop () is called to release the old pool and _ objc_autoreleasePoolPush () is called to create a new pool.

The second event: Exit (about to exit Loop). _ objc_autoreleasePoolPop () will be called in the callback to destroy the automatic release pool.

The first event monitored by Observer (highest priority): Entry (about to enter Loop). _ objc_autoreleasePoolPush () will be called in the callback to create an automatic release pool.

The second Observer (lowest priority) monitors two events:

Relationship analysis

From the call stack, we can see that when the UIApplicationMain () method is called, the system automatically creates an associated Runloop for it.

By getting the main thread and the main runloop in the first line of the main () function, you can see that the runloop of the main thread already exists. We can infer that the corresponding runloop will be created after the main thread is created, that is, the main runloop will be created by default as soon as the program starts. However, relevant observers have not been added to the main runloop at this time, and so on.

When the code starts execution from main (), the runloop is still an empty structure

Check the call stack before entering applicationDidLaunchingWithOptions:

You can see that relevant information such as Source will be added to the main Runloop at this time.

When you enter the applicationDidLaunchingWithOptions, you can get the main Runloop information at this time through po CFRunloopGetMain (), and you can see that the observer, source, and so on have been added.

/ / intercept part current mode = kCFRunLoopDefaultMode,common modes = {type = mutable set, count = 2jigsaw = > 0: {contents = "UITrackingRunLoopMode"} 2: {contents = "kCFRunLoopDefaultMode"}} Thank you for reading. This is the content of "how to understand the main thread and the main Runloop". After studying this article, I believe you have a deeper understanding of how to understand the main thread and the main Runloop. The specific use situation still needs to be verified by practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.