iOS Child Threading Action UI issue check

In iOS development, because most of the functions are not thread-safe, it is very dangerous to manipulate the UI in a UI sub-thread, but sometimes because the developer is inexperienced, doesn't know that the UI is not in the child thread, or knows but does not notice when writing the code, Or do not know those functions to manipulate the UI (such as the UITableView reload function), causing this problem often occurs, hard to prevent, and iOS is not like Android, once the sub-thread operation UI directly crashes, iOS operating UI is only possible to collapse, causing problems often not reproduce, And often the stack is chaotic, can not find the place where the error, very headache.

I wrote a simple thread to check the UI operation of the library, when the child threads manipulate the UI, depending on the macro definition CRASH (view_op_inspect_crash) or the print stack (view_op_inspect_log_stack (not conflicting), the rationale is to replace most of the UIView's API with the runtime's Class_replacemethod (Given the performance issue, the get operation has no replace), Then check in the function of replace to see if the current thread is the main one.

GitHub address is https://github.com/pualxiao/PXViewOpInspect (just written out of a library, constantly perfected in, tap. Welcome comments and suggestions, and participate in the completion of the code)

The use of the method is very simple, put PXViewOpInspect.h and PXVIEWOPINSPECT.M in the project can be, if defined View_op_inspect_crash and View_op_inspect_log_ A macro in the stack will replace the UIView API, and no one will.

For performance issues, it is recommended that you use this library in debug mode, with no view_op_inspect_crash and View_op_inspect_log_stack defined under release.

　　

iOS Child Threading Action UI issue check