Welcome to our official account, we will share original articles every week. We focus on mobile development and share mobile development technologies, including iOS, Android, applets, mobile front end, React Native, WEEX, etc.

GitHub, a collection of knowledge

“I depend, how does this problem check, tried dozens of times, can’t reproduce?” “Oh my God, this question makes my head spin”… I hear this a lot, so TODAY I’m going to give you a brief introduction to some of Xcode’s great diagnostic tools to improve your productivity. (This article will not explain how to use it in detail, please Google or Baidu.)

Be kind to compile warning

Xcode already has plenty of compile warnings for us, and while they don’t lead to compilations, there’s certainly no gratuitous hate behind them. Treat Warnings as Errors. Treat Warnings as Errors is also a good choice. If you are absolutely confident about certain Warnings, you can remove them by modifying the Warnings option in Build Settings or adding diagnostic Ignore to the warning code. As Xcode is updated, you should also use the editor-validate Settings of the project file to optimize the project configuration options.

Don’t ignore Analyze

Xcode has long provided static detection tools that can detect a range of hard-to-find problems, such as memory leaks, logic errors, unused variables, and included libraries. For many projects, a complete run of Analyze can take a long time, and perhaps because of this, the tool is increasingly ignored by developers. You can change the Analyze During ‘Build’ in the Build Settings to perform the Analyze function immediately During normal development and debugging.

Runtime diagnostics

In addition to compiling warnings and Analyze, Apple also provides more dynamic debugging tools. They are scattered all over Xcode, and they are relevant to our daily development.

Debug Gauges

When the App starts debugging, the Navigator view on the left side of Xcode will automatically switch to the Debug Navigator. Here, by default, several key metrics are shown to give you an overview of the current state of your App. They give you an idea of what each thread is doing, memory requests, power usage, disk reads and writes, network operations, and more. If you are interested in more detailed diagnostic information, you can easily access Instruments for a diagnosis.

###Process Debug

Xcode provides us with four types of process debugging:

  • View Process by Thread: the call stack for a Thread. This is the default and the one we use most often. Add a breakpoint to view all current thread calls.

  • View Process by Queue: Similar to View Process by Thread, the current Queue name will replace the Thread name with a richer color.

  • View UI Hierarchy: You can switch to God View to View View Hierarchy and View properties.

  • View Memory Graph Hierarchy: can easily detect Memory leaks such as circular references, very practical.

Open the Diagnostics

In addition to Xcode’s early Guard Malloc and Zombie Objects, the recent introduction of Sanitizers and Main Thread Checker has further improved detection tools during development.

  • Address Sanitizer

For OC in MRC environment, operating on an object after it is released will trigger crash. In the ARC era, we care less and less about this problem. But when you use Core Foundation, or mix C++, this problem can become unpredictable. When an area of memory is freed, there is no problem accessing it before the area is reallocated, which adds a great deal of randomness. In addition, if you accidentally overstep the bounds when accessing memory using Pointers, the consequences are unpredictable. For these issues, Xcode provides Address Sanitizer for more robust detection.

  • Thread Sanitizer

Historically, problems with Data Race have been difficult to locate and troubleshoot because the problems it creates are often unexpected. Xcode detects each memory access by recording information such as the time of each memory access. You can optionally turn this tool on during routine debugging, but you should consider turning it on during unit testing. If your use case coverage is high, it will probably catch most multithreaded data contention problems for you.

  • Undefined Behavior Santizer

Undefined line detection, such as dividing by 0, loading memory to its pointer, unassociating a null pointer, etc. It may or may not crash, depending on the compiler, but it should be avoided.

  • Main Thread Checker

Check on child threads using AppKit, UIKit, and other apis. This check tool is enabled by default and does not need to be recompiled. The principle is that after the App is started, the API that can only be used in the main thread will be automatically replaced, and exceptions will be generated when such API is called.

It is worth noting that the implementation of Address Sanitizer, Guard Malloc, or Zombie Objects directly or indirectly affects the memory management of runtime Objects. Debug Evacuate Memory will now fail.

conclusion

Solving the warning and diagnosis App as soon as possible will greatly improve the stability of the App after its launch, and also improve our work efficiency. What are we waiting for? Let’s take action soon.