菜单
  

    You are likely already familiar with basic breakpoints, either from using JS developer tools or a previous language.
    It is one of the most useful tools in a developer’s toolkit. While in code view (sources tab in Chrome) you can add a
    breakpoint by clicking the line count, which leaves a marker (the breakpoint). As I explained earlier, this default type
    of breakpoint pauses the JavaScript and allows you to see the current state, including the values of the variables. There
    are a few other types of breakpoints and not all debuggers can deal with all types of breakpoints, which can be useful
    in different situations.
    • DOM breakpoints: These let you pause the code for changes such as modification of an
    attribute or removal of an element. In Chrome this can be found by right-clicking a DOM none
    and selecting one of the options listed under Break on….
    • Exceptions: Quite often you will have code that is set up to throw an exception but rather
    than handling it in the code, you will want to debug it properly and figure out what caused the
    exception. Instead of having breakpoints on every exception, which soon gets annoying, you
    can set the debugger to pause on either all exceptions or just uncaught exceptions. In Chrome
    this is accessed by clicking the pause button that has a hexagonal background. The color
    changes dependent on which mode it is set to.
    • Events: Breakpoints can be set for when an event gets triggered, such as click or mousemove,
    which can be very useful for making sure events are triggered where they should be and that
    they do as expected. In Chrome, these are available from the sources panel under the Event
    Listener Breakpoints heading.
    • Conditional breakpoints: These are the same as the default breakpoint except that you
    can set conditions on which the breakpoint pauses, which work the same way as if you
    put a breakpoint within an if statement. These are, in my opinion, the most useful kind of
    breakpoint because you can use them to only pause the code when the results are not what
    you would expect them to be. To place a conditional breakpoint, right-click the line count and
    Timeline
    So far we have discussed functionality in debuggers that allow you to fix code and make sure it is working as you
    would expect it to. Sometimes however, getting the code to work is the easy bit—making it fast is often far harder. We
    are still on the subject of debuggers but now rather than inspecting to make sure each part of the code is working, we
    instead need to record the entire process so that we can spot patterns in performance (looking at the overall running
    of the code rather than each inpidual function/line). This is a subject that could easily fill an entire book, so I will
    go over the basics and it should give you a good starting point for figuring out how to understand and improve the
    performance.
    In Chrome, the tool that we use to measure performance of the code is the timeline. I should note that the
    network pane is also related, as it lets us see which resources are causing a delay. But I’m going to focus on the
    running of the code rather than the resources, because it is more likely that you have experience with resources
    (on a normal website) than with performance testing of the code (crucial for the more creative of web apps).
    To start using the timeline, you need to record the running of the code by clicking the circle button. As soon as it
    starts recording you will notice that some graphs are created. There are (at the time of writing) three aspects that are
    recorded: Events, Frames, and Memory; all these are recorded simultaneously but can only be viewed separately by
    selecting them. At the basic level, these features give you a good way to test the speed of parts of your code because it
    breaks down the code like a stack, showing you each function call. This is a fairly easy way to find bottlenecks, but it
  1. 上一篇:ASP.NET技术英文文献和中文翻译
  2. 下一篇:MVC设计模式和Spring,Struts框架英文文献和中文翻译
  1. 汽车乘员舱的声振耦合英文文献和中文翻译

  2. 立体光照成型的注塑模具...

  3. 低频振动的铁路车轴的状...

  4. 接头的形状对沥青塞接头...

  5. 电-气动驱动的垂直计算机...

  6. 开口端纺纱系统中的锥形...

  7. 木质填料聚丙烯复合材料...

  8. java+mysql车辆管理系统的设计+源代码

  9. 河岸冲刷和泥沙淤积的监测国内外研究现状

  10. 当代大学生慈善意识研究+文献综述

  11. 杂拟谷盗体内共生菌沃尔...

  12. 大众媒体对公共政策制定的影响

  13. 十二层带中心支撑钢结构...

  14. 中考体育项目与体育教学合理结合的研究

  15. 酸性水汽提装置总汽提塔设计+CAD图纸

  16. 乳业同业并购式全产业链...

  17. 电站锅炉暖风器设计任务书

  

About

751论文网手机版...

主页:http://www.751com.cn

关闭返回