Android Studio Learning----Debugging---breakpoint debugging

Android Studio debugging is also very convenient, general problems directly through as the DDMS Logcat can be done. As supports all features of DDMS like Eclipse. Here to say is the debugging of difficult problems, that is, breakpoint debugging.

First compile the program you want to debug.

Click Set breakpoint at line number as shown in 2. Then click to open the debugging session as shown in 1.

As shown, the Debug view appears below the IDE, and 1 points to the line of code where the debugger is currently stuck, and the 2 area is the program's method call stack area. In this area shows the method used by the program to execute to the breakpoint, the more the following method is called earlier. In this order presumably some Android in-depth understanding of a little Android system startup process know how these methods, how to the activity of the oncreate. Haha, speaking of the system. It's not a rip. 3 is a number of debugging buttons, shortcut keys placed directly on the above will be displayed. 4 and 5 are some variable observation areas.

In

Click the 1 point button, the program executes a line down, if the current line has a method call, this method will be executed to return, and then to the next line.

Click the 2 point button and the program executes one line down. If the row has a custom method, it runs into a custom method (a method that does not enter the official class library).

Click on the 3 button to enter any method when debugging.

Click 4 the role is if you enter a method (such as Debugfunc) when debugging, and feel that the method is not a problem, you can use 4 to jump out of the method, return to the method is used to the next line of the statement. It is worth noting that the method has been executed.

When you click the 5-point button, you will return to the current method's call to execute again, and the value of all context variables will return to that time. You can jump to any of these methods as long as there is a parent method in the call chain.

If you set multiple breakpoints, turn on debugging. To move across a breakpoint to the next breakpoint, click a 1 arrow, and the program will run a breakpoint between the next breakpoint and the code that needs to be executed. If the following code does not have a breakpoint, tapping the button again will run the program. Click on the arrow 2 to point to the button, you can see the breakpoint you have set and can set some properties of the breakpoint, as shown in. After debugging begins, in the variables area you can assign a value to the specified variable (the left mouse button selects the variable, the right-click popup menu selects the SetValue ... ）。 This feature allows you to detect your conditional statements and loop statements more quickly. You can view the value of the trace variable by tapping the arrow 3 plus or by right-clicking on the debug code variable to add watcher.

Arrow 1 points to the breakpoint you have set, and arrow 2 can set a conditional breakpoint (when a condition is met, pause the execution of the program, such as Index==5). After you finish debugging, you should delete the breakpoint you set at arrow 1 (after selecting the breakpoint you want to delete, click the red minus sign above).

These are some of the debugging techniques used by AS.

Reprinted from: http://www.cnblogs.com/firstcsharp/p/4333264.html

Compile the program you want to debug first.

1. Set breakpoints

Select the line of code where you want to set the breakpoint, and click the left mouse button after the area of the row number.

2. Turn on the debug session

Click on the red arrow pointing to the Bug and start debugging.

The debug view appears below the IDE, and the red Arrow points to the line of code that is now stuck in the debugger, in method F2 (), line 11th of the program. The red arrow hovers over the area of the program's method call stack. In this area shows the method used by the program to execute to the breakpoint, the more the following method is called earlier.

3. Single Step commissioning 3.1 step Over

Click on the button pointing to the red Arrow, the program executes a line down (if the current line has a method call, this method will be executed to return, and then to the next line)

3.2 Step Into

Click the button pointing to the red Arrow and the program executes one line down. If the row has a custom method, it runs into a custom method (a method that does not enter the official class library). The steps are as follows:

Set breakpoints at Custom method send F1 (), perform debugging

Click

3.3 Force Step Into

This button can enter any method when debugging.

3.4 Step Out

If you enter a method (such as F2 ()) while debugging, and feel that the method is not a problem, you can use StepOut to jump out of the method and return to the next line of statements where the method is being used. It is worth noting that the method has been executed.

3.5 Drop Frame

When you click the button, you will return to the current method's call (for example, the program will return to Main ()) and the value of all context variables will return to that time. You can jump to any of these methods as long as there is a parent method in the call chain.

4. Advanced Debugging 4.1 cross-Breakpoint debugging

Set multiple breakpoints to turn on debugging.

To move to the next breakpoint, click for example:

The program runs a breakpoint to the next breakpoint between the code that needs to be executed. If the following code does not have a breakpoint, tapping the button again will run the program.

4.2 Viewing breakpoints

Click the arrow Point button to view the breakpoints you have set and to set some properties of the breakpoint.

Arrow 1 points to the breakpoint you have set, and arrow 2 can set a conditional breakpoint (when a condition is met, pause the execution of the program, such as C==97). After you finish debugging, you should delete the breakpoint you set at arrow 1 (after selecting the breakpoint you want to delete, click the red minus sign above).

4.3 Setting variable values

After debugging starts, the red arrow points to the area can assign a value to the specified variable (left mouse button to select the variable, right-click Pop-up menu select SetValue ... ）。 This feature allows you to detect your conditional statements and loop statements more quickly.

alt+f8 debug时选中查看值 f8相当于eclipse的f6跳到下一步 shift+f8相当于eclipse的f8跳到下一个断点，也相当于eclipse的f7跳出函数 f7相当于eclipse的f5就是进入到代码 alt+shift+f7这个是强制进入代码 ctrl+shift+f9 debug运行java类 ctrl+shift+f10正常运行java类 command+f2停止运行Reprinted from: Http://www.tuicool.com/articles/UJRj6nvEvaluate Expression

This is a useful feature that allows you to enter an evaluation environment directly at a breakpoint where you can perform any expression you are interested in:

For example, there is an object at the breakpoint, and object if you want to view one of its properties it is simple to see it in the Debug window, but what if you want to execute one of its methods to see what the result is? With this can be achieved. Of course, its function is far more than this, the equivalent of directly into an REPL environment, very practical. Forgot to say, shortcut key Alt + F8 :P

Conditional breakpoint

Suppose your breakpoint is in the loop of a list, but you are only interested in one of the elements of the list, and only want to break it when you encounter this element; Do you always have human flesh F9 until you meet the conditions? A conditional breakpoint is a breakpoint that satisfies this requirement, as the name implies, under certain conditions. It is also very simple to use, the mouse on your breakpoint will appear a small window, write the conditions can be.

Log Breakpoint

Many times when we debug more is the print log to locate the exception code, reduce the scope after the use of breakpoints to solve the problem, so often do is to add log information in the code, output function parameters, return information, output the variable information we are interested in.

But the problem with this is that we have added the log code that needs to be recompiled, Instant Run and it is very painful to do so in the dark Ages, with less than dozens of seconds per compilation and a few minutes, so meaningless waiting is simply torture; in fact, in addition to the hot deployment tool, We can also use a log breakpoint to solve this problem.

First we place the next breakpoint where we want to export the information, and then right-click the breakpoint and set the breakpoint's property in the box that appears, which is suspend False called a "breakpoint", but it does not really break down; then we fill in the log message log information we want to output. such as (note the red position):

In this way, every time the code executes to the breakpoint's location, this lovely breakpoint does not stop our program, but instead outputs the log information we tell it, and then it is very convenient to do so.

Method Breakpoint

The traditional way of debugging is in the behavior unit, the so-called single-step debugging; But most of the time we care about the parameters of a function, the return value; (Recall that the most information we print when we use the log is not the parameter and the return value of the function?) Using a method breakpoint, we can debug at the function level, and this type of breakpoint is useful if you frequently jump out of a function or are only interested in the parameters of a function. There are two ways to use it, and the simplest is to put a breakpoint on the line of the method you're interested in, and you'll find that the breakpoint icon is a little different, which is the method breakpoint, like this:

Another way is through the Breakpoint Setup window , which is described later.

Exception Breakpoint

In some cases, we are only interested in certain exceptions, or we are only interested in exceptions, and we hope that as long as the program is abnormal the program will be able to break down; this is like saving the scene, as long as the occurrence of a homicide (abnormal), the first time to save the scene, so what fingerprints and other clues will be much clearer, Bad guys are chachinanfei even if they want to escape.

Android Studio has given us this ability! That's the exception breakpoint ! You can break the entire program directly when a particular exception occurs, and if you are interested in all the anomalies, just go straight to it Throwable .

To do this, enter Run -> View BreakPoints or use the shortcut key to open the Breakpoint Settings window, such as:

Click on the top left: heavy_plus_sign: A selection box will appear, Exception Breakpoint and a dialog box will appear to select the exception you are interested in:

Field Watchpoint

When we add the exception breakpoint above, when we click on the plus sign, there are four options; The first is the second method that we said before, the third one is the exception breakpoint, then the second Field watchpoint is what?

Is there a scenario where you find that a value is somehow unknown and who is responsible for the change? Although Java is a value pass, but the reference can also be a value, the object is all stored on the heap, and the heap is shared by all threads, so in a very complex scenario, you have no idea who modified the shared variables, it is very dangerous; in a multithreaded environment, invariance is a very important feature, We see high concurrency in languages such Erlang as Scala a degree of support for this invariance.

Well, pull it off, so how do we find the troublemaker who modified our values? That is the function of the field Watchpoint ; we can break the program when a field is accessed or modified, and solve the problem perfectly.

There are two ways to place breakpoints in the same way as method breakpoints, and the first is to place a breakpoint directly at the declaration of a field, when the breakpoint icon changes, such as:

Right-click this breakpoint we can make some settings, such as the default is modified by the time of the break down, you can also change every time you access this field to break down.

Another way is to Run -> View BreakPoint open the setting, similar to an exception breakpoint.

Far more than that.

There are a lot of details on the above-mentioned functions. Open the Breakpoint Settings window (Run, View breakpoint '):

Android Studio Learning----Debugging---breakpoint debugging