Go Xcode Overview: Debugging Applications

Original URL: blog.csdn.net/fhbystudy/article/details/12856261

This article is translated by Cocoachina translation Group member Creolophus (GitHub homepage ) from the official Apple document Xcode overview:debug Your App, proofread the babble, please errata.

When you click the Run button in the workspace toolbar and your app compiles successfully, Xcode runs your application and turns on debugging. You can use graphical tools to debug your app directly in the source editor, such as using data tips and quick look to see variable values.

The debug area and Debug Navigator (Debug Navigator) allow you to check the status of the running app and control its execution.

To create a high-quality application, minimize the impact of the application on the user's system. Use the debug meter (debug gauges) in the Debug Navigator (Debug Navigator) to gain insight into the resource consumption of your app, and when you find a problem, use instruments to confirm and analyze the performance of your app.

If you are developing an iOS app, you can use the iOS emulator to identify problems during the design and early testing phases.

You can configure Xcode to help you focus on debugging tasks. For example, when the code runs to a breakpoint, you can have Xcode automatically play a warning and create a window named Debug tag, where Xcode can show the debug area, Debug Navigator (Debug Navigator), and the code at the breakpoint.

Control execution and observe status information (control execution and view state information)

Xcode allows you to step through your code one line at a time to see the status of the app in a particular execution phase. Use the Debug region (debug area) to control the execution of the code, observe the variables and registers of the program, observe the output of the console, and interact with the debugger. You can also use the debug area to navigate OpenGL calls to render frames and view rendering status information for a particular call.

Show the debug area by clicking the middle button () on the view selector on the Workspace window toolbar.

Click the pause button (toggle between pause and Continue) on the Debug Area toolbar to pause the app's execution. To set breakpoints, simply open the source code file and click on the Benlie (gutter) of the line where you want to pause the execution of the code. A blue arrow () in the Edge column identifies the breakpoint. If you want to learn more about breakpoints, including how to set breakpoint behavior and different types of breakpoints, see breakpoint Navigator Help.

When the app is paused, the line of code that is currently executing is highlighted in green. You can step through the execution of the code by using step Over (), step Into (), step Out () three buttons on the top bar of the debug area. Step over executes the line of code for the current line, including any method. If the current line of code calls a method, step into starts executing the current line of code and then stops when the first row of the called method is reached. Step out executes the remaining part of the current method or function.

When execution is paused, the Debug navigator opens and displays a stack trace. Select one of the items to view information about the item in the edit area and in the debug area. When you debug, you can expand or close the thread to show or hide the stack frame.

Hover the pointer over any variable in the source editor to view a data hint that shows the value of the variable. Click the Inspector icon () next to the variable to print the object's objective-c description to the debug area console and show it in an additional pop-up view.

Click the Quick Look icon () to see a graphical display of the variable contents. You can implement a custom quick look for your own objects. For more information, see Quick Look for Custom Types in the Xcode Debugger.

When you build and run an OpenGL ES app on your device, the Debug Area toolbar contains a Frame Capture button (). Click the button to capture a frame. You can use OpenGL ES frame capture to do the following things:

· Check OpenGL ES status information

· Introspect OpenGL ES objects, such as view textures and shaders.

· Step through the state call before each draw call, and then observe the changes for each call.

· Step through the draw call to see exactly how the image is built.

· See which objects each draw call uses in the secondary editor.

· Edit the shader to see the effect on the application.

The following shows the components of the rendered frame. The left-side debug navigator shows part of the render tree, and the main debugger displays the color and depth resources of the rendered frame and shows some other picture resources.

To learn more about debugging OpenGL ES, check out the debug Navigator Help and debugarea.

Check your app's view hierarchy at run time (examine Your app ' s view Hierarchy at runtime)

Click the Debug View Hierarchy button () in the top bar of the debug area to check the 3D rendered view hierarchy for the currently paused app. You can:

· Rotate the perspective by tapping and dragging in the canvas.

· Use the lower left slider to increase or decrease the spacing between the view layers.

· Use the slider bar on the lower right to change the extent of the visible view. Slide the left slider to change the bottom-most visible view and slide the right slider to change the top-most visible view

· Press the Show Cut Content button () to display the trimmed content in the selected view.

· Press the Show constraint button () to display any auto layout constraints for the selected view.

· Use the zoom in (+) button and the Zoom Out (-) button to increase or decrease the magnification of the perspective view.

For more information about debugging views, see Debugging views

Check the impact of your app on system resources (examine Your app ' s impact in system Resource)

The Debug Navigator (Debug Navigator) provides instrumentation that enables in-depth analysis of application performance. For example, the CPU meter meter shows the CPU usage of the app, which makes it easy for you to detect abnormal situations. Depending on the purpose and function of the application, the meter meter can tell you how the app affects memory, ICloud, OpenGL ES, power, and CPU.

If you want to see a detailed report, click one of the gauge meters in the debug area. If you want to do a deeper analysis of your application, please click the profile in Instruments button.

In the problem area, the battery report provides a preliminary diagnosis to tell you what may be seriously wasting your power consumption.

For more help, see Using Debug Gauges

Measure application Performance (Measure Your app ' s performance)

The instruments program in Xcode collects data from the running app and displays it on a graphical timeline. With instruments, you can collect performance data, such as your application's memory usage, disk activity, network activity, and graphics operations. By putting the data together, you can analyze the various aspects of your application's performance to identify potential performance improvements. You can also automate the testing of interface elements for iOS apps.

There are several ways to open instruments in Xcode, such as:

· Click the profile in Instruments button from the Meter Meter Detail report interface

· Select Product>profile

· Specify a instrument in the profile of a scheme

The instruments program uses a separate data acquisition module called instruments to collect data from a process at any time. The instruments program has a template library, each of which includes a series of instruments to get relevant information.

For more information, please see Performance Overview and Instruments User Guide

Early testing on the iOS emulator (Perform Early testing in iOS Simulator)

The iOS simulator can help you find major issues in the design and early testing phases. For example, the Debug menu of the iOS simulator provides you with a variety of tools to help you:

· Slow down an animation to find the problem.

· Triggers icloud sync.

· Identify the hybrid view layers that may be detrimental to your application's performance.

· Identify a picture of the source pixel that is not aligned to the target pixel

· See which content renders rendering outside the screen.

· Simulate a different location.

In any simulated environment of the iOS simulator, the home screen provides the ability to open iOS native apps (such as Safari,contacts,maps and Passbook). You can initially test your app's interactions with these apps in the iOS simulator. For example, if you are testing a game, you can use the iOS emulator to test whether the game is correctly called by Games Center.

The Accessibility viewer (accessibility Inspector) in the iOS simulator helps you to test the usability of your app without being personally constrained. Accessibility Inspector shows you the information for each element that your app can access and can simulate voiceover interacting with those elements. If you want to open accessibility Inspector, click the main screen button of the iOS emulator and click Settings > General > Accessibility. Open the Accessibility Inspector right slide button.

You can test your app's localization by changing the language in the iOS simulator. Settings > General > Language and Region >iphone language.

While you can test the basic functionality of your app in the iOS simulator, there are many limitations to the simulator as a test platform for many reasons. Like what:

· Because the iOS simulator runs on a Mac and uses the computer's memory, this is much larger than the memory on the real machine.

· The iOS emulator uses the CPU of the Mac to run instead of the iOS real computer.

· The iOS emulator does not run all the threads on the real machine.

· The iOS simulator cannot simulate hardware features like accelerometers, gyroscopes, cameras, or proximity sensors.

When developing an app, be sure to run and test on all iOS and iOS system versions you want to support.

For more details, please check out the testing and debugging in iOS Simulator section of iOS Simulator User Guide.

Customize your debug Workflow (Customize Your debugging Workflow)

Use Xcode behaviors to customize the behavior of Xcode. Choose xcode> Behaviors to customize what Xcode does when you build, run, and debug your app.

For example, Xcode can display the problem navigator when your code displays a debug area when a breakpoint is paused or when an application fails to build

Below are examples of some of the custom behaviors below that are shown in how the Xcode behavior is customized when contemporary code pauses.

· Play a beep every time you pause.

· Create a label named Debug in the work area form to show the Debug navigator.

· Both the variable view and the console view are displayed in the Debug tab.

· Hides the utilities area in the Debug tab.

When you set the behavior above, when the code in the project hits a breakpoint, Xcode creates a debug tag in the workspace window that shows the specific content.

You can customize the behavior of Xcode, which can be triggered by an option in the menu or by a bound shortcut key. Select Xcode > Preferences, select the Behaviors Preferences window, then click the Add (+) button at the bottom. Enter a custom name for the new behavior and press RETURN. Check the box on the right to tick what you want Xcode to do when you trigger this behavior. For example, create a behavior called unit testing to save a snapshot of your project and run your unit tests. When you create this behavior, it will appear in the Xcode> Behaviors menu.

To add a shortcut key to your custom behavior, select Xcode > Preferences and click Key Bindings. In the Key Bindings Preferences window, select the customized tab to find your custom behavior. In the text box, type the shortcut key and click outside the text box to complete the operation.

To learn more about the types of breakpoints and the role of breakpoints, view breakpoint Navigator Help

Go Xcode Overview: Debugging Applications