Runloop, time slice, and runloop time slice

Runloop, time slice, and runloop time slice
In the previous article <white screen problems caused by synchronous call of postNotificationName> "when a notification is thrown in mediaView, It is thrown in an asynchronous thread. Thread switching is used to avoid reloadData during reloadData ". why can this problem be solved?
When the HWCHAT_VIEW_NEED_RELOAD notification is thrown in the asynchronous thread (assuming thread10), The reloadChatCollectionViewData is synchronously called in thread10. Because the thread switching is performed in reloadChatCollectionViewData: yoho_dispatch_execute_in_main_queue, it is switched back to the main thread to execute reloadData. In this way, why does the reloadData execution avoid reloadData? The following describes the runloop issue.
Log: 10: 44: 40: 168 demo [2957: 807] Debug | [HWChatManager. m 175]: _ 45-[HWChatManager reloadChatCollectionViewData] _ block_invoke throwing notification HWCHAT_VIEW_NEED_RELOAD2015-03-25 10: 44: 40: 168 demo [2957: 807] Debug | [HWChatViewController. m 162]:-[HWChatViewController reloadChatCollectionViewData] 111111 ********** 2015-03-25 10: 44: 40: 169 demo [2957: 807] Debug | [HWChatViewController. m 164]: _ 52-[HWChatViewController reloadChatCollectionViewData] _ block_invoke 22222 ========== 10: 44: 40: 206 demo [2957: 807] Debug | [HWPhotoMediaItem. m 41]: _ 29-[HWPhotoMediaItem mediaView] _ block_invoke_2 throwing notification HWCHAT_VIEW_NEED_RELOAD2015-03-25 10: 52: 59: 275 demo [2957: 807] Debug | [HWChatViewController. m 162]:-[HWChatViewController reloadChatCollectionViewData] 111111 ********** 2015-03-25 10: 52: 59: 275 demo [2957: 807] Debug | [HWChatViewController. m 164]: _ 52-[HWChatViewController reloadChatCollectionViewData] _ block_invoke 22222 ========== 10: 52: 59: 277 demo [2957: 807] Debug | [HWChatViewController. m 167]: _ 52-[HWChatViewController reloadChatCollectionViewData] _ block_invoke 33333 ++
807 is the id of the main thread. When the main thread calls [HWChatViewController reloadChatCollectionViewData] And reloadData, [HWPhotoMediaItem mediaView] throws a notification to HWCHAT_VIEW_NEED_RELOAD in the main thread, [HWChatViewController reloadChatCollectionViewData] As the selector of the observer, reloadData is executed again, resulting in a white screen. These actions are executed in a pass (loop traversal, temporarily named passA) of the main thread's runloop.
In the main thread, when a notification is thrown in mediaView, It is throttled in an asynchronous thread. Then, the process must wait for the thread to switch to the asynchronous thread thread10.
The process gets the time slice and switches to the thread 10. thread10. Throw the notification HWCHAT_VIEW_NEED_RELOAD, and [HWChatViewController reloadChatCollectionViewData] as the observer's selector. Execute in thread10:

-(void)reloadChatCollectionViewData {    HWLog(@"111111*********");    yoho_dispatch_execute_in_main_queue(^{        HWLog(@"22222==========");        [_collectionView reloadData];        [_collectionView layoutIfNeeded];        HWLog(@"33333+++++++++++");        [_collectionView scrollToBottomAnimated:YES];    });}

Then, in reloadChatCollectionViewData, yoho_dispatch_execute_in_main_queue is switched back to the main thread. These actions are executed in a pass (assuming passB) of the runloop of thread10.

Then, the process must wait for the thread to switch to the main thread to execute reloadData. The process obtains the time slice for thread switching, and then enters the main thread to execute passC. At this time, passA has already completed the execution, that is, the previous reloadData has been completed. The execution of reloadData in passC is of course irrelevant to the previous reloadData, avoiding "reloadData again in the reloadData process ". If no problem occurs, the log is as follows: 11: 50: 52: 145 demo [10982: 807] Warn | [HWRecentTableViewController. m 214]:-[HWRecentTableViewController reloadQLMessage] Reload list 11: 50: 52: 748 demo [10982: ce17] Debug | [HWPhotoMediaItem. m 41]: _ 29-[HWPhotoMediaItem mediaView] _ block_invoke_2 throwing notification HWCHAT_VIEW_NEED_RELOAD2015-03-25 11: 50: 52: 748 demo [10982: 2507] Debug | [HWPhotoMediaItem. m 41]: _ 29-[HWPhotoMediaItem mediaView] _ block_invoke_2 throwing notification HWCHAT_VIEW_NEED_RELOAD2015-03-25 11: 50: 52: 748 demo [10982: ce17] Debug | [HWChatViewController. m 164]:-[HWChatViewController reloadChatCollectionViewData] 111111 *********** 11: 50: 52: 748 demo [10982: 2507] Debug | [HWChatViewController. m 164]:-[HWChatViewController reloadChatCollectionViewData] 111111 *********** 11: 50: 52: 750 demo [10982: 807] Debug | [HWChatViewController. m 166]: _ 52-[HWChatViewController reloadChatCollectionViewData] _ block_invoke 22222 ========== 11: 50: 52: 777 demo [10982: 807] Debug | [HWChatViewController. m 169]: _ 52-[HWChatViewController reloadChatCollectionViewData] _ block_invoke 33333 ++ 11: 50: 52: 777 demo [10982: 807] Debug | [HWChatViewController. m 166]: _ 52-[HWChatViewController reloadChatCollectionViewData] _ block_invoke 22222 ========== 11: 50: 52: 804 demo [10982: 807] Debug | [HWChatViewController. m 169]: _ 52-[HWChatViewController reloadChatCollectionViewData] _ block_invoke 33333 ++

Finally, we will describe the runloop. For better explanation, we will take a single cpu as an example. The program can continuously process user clicks or network events because of the runloop driver. Otherwise, shouldn't the cpu exit the program immediately after executing the command? Runloop can be understood as a loop that keeps your arm in the water, driving the rotation of the water (program execution ). Your arm draws a complete circle, which is a pass mentioned above.
Runloop can also be combined with cpu time slice. After the process obtains the cpu time slice, it is executed in a pass of A runloop of a thread. If the cpu is transferred due to network requests, disk io, or other reasons, this pass ends. When the subsequent process obtains the cpu time slice for running, it is executed in the next pass.