directory
- Why should memory management be monitored? ?
- Performance Tool usage process
- Memory problems
- The symptoms and nature of memory problems
- Criteria for defining memory problems
- Several ways to monitor memory
- Browser task manager
- Timeline Records the Timeline diagram
- Heap snapshot lookup for detached DOM (can watch for memory leaks)
- How many states does DOM exist in?
- The instance
- How do I split the DOM?
- Determine if there is frequent garbage collection (requires different tools)
- Why judge?
- How to use monitoring to judge?
If you are not familiar with memory management, garbage collection, and GC, please refer to JavaScript – Memory Management and garbage Collection
Why should memory management be monitored?
The purpose of GC is to achieve a virtuous cycle of memory space, the cornerstone of which is the rational use of memory space. Because HTML does not provide apis for memory operations, the Performance tool can be used to locate problems by constantly monitoring memory changes. Performance provides multiple monitoring methods to monitor memory.
Performance Tool usage process
- Open your browser and type in the target url
Chrome
- Go to the Developer tools panel and select Performance
Performance
- Enable the recording function and access the page
- Perform user action and stop recording after a certain period of time
- Get a report to analyze the memory information recorded on the interface
In the following screenshot, you can see that the line graph of Memory options shows the condition of Memory. If there are ups and downs, it is normal to work:
Memory problems
The symptoms and nature of memory problems
Limit the current network problem to normal conditions:
Emerging phenomenon | Existing problems |
---|---|
Pages load lazily or pause frequently | Memory problem withGC Frequent garbage collection operations are associated, and there must be a memory drain in the code |
The page continues to have poor performance | Memory expansion occurs. To achieve the optimal usage speed, the current interface requires a certain amount of memory space, which exceeds the upper limit. Procedure |
Page performance deteriorates over time | Accompanying memory leaks |
Criteria for defining memory problems
- Memory leak: Memory usage continues to rise
- Memory bloat: The current application itself needs a certain amount of memory to achieve the optimal effect, which may be related to the current device hardware does not support, resulting in performance differences, need to determine whether the program or the device problem. You need to do a lot of testing, and the fact that you have performance problems on most devices is a sign that there is something wrong with the program.
- Frequent garbage collection: Analyzed by memory variation graph
Several ways to monitor memory
Browser task manager
The memory changes during the execution of the program are numerically represented
In your browser -> Shift +Esc -> right click on [JavaScript memory]
- The memory in the first column is native memory
DOM
Memory occupied by a node], this increase indicates that a new one has been createdDOM
Node. - The last column
JavaScript
Memory is heap memory, the amount of memory being used by all reachable objects in the interface. This increment indicates that either a new object is being created or the object is growing.
Here is an example:
<! Create a large array -->
<body>
<button id="add">Add</button>
<script>
const add = document.getElementById('add')
add.onclick = function() {
let arrList = new Array(1000000)}</script>
</body>
Copy the code
Click on the button and you know it’s going to get bigger, because we’re creating a big array. Later scripts, you can use this to monitor.
Timeline Records the Timeline diagram
The above method can only say that we have a memory problem, but it can not be more precise to determine when it happened, and which code is related. You can use the Timeline chart to directly show the current application trends in the form of points in time.
Here is an example:
<body>
<button id="btn">Add</button>
<script>
const arrList = []
function test() {
for( let i = 0 ; i < 100000; i++) {
document.body.appendChild(document.createElement('p'))
}
arrList.push(new Array(1000000).join('x'))}document.getElementById('btn').addEventListener('click',test)
</script>
</body>
Copy the code
Enter the page, open Performance to record, and click the button three times to stop recording.
You can see that the memory is normal, up and down, and where down is the GC working. If it’s not healthy, it’s a problem.
Heap snapshot lookup for detached DOM (can watch for memory leaks)
The heap snapshot is a very specific way to look for any separate DOM in the current interface object, and the presence of separate DOM is a memory leak. So just to be clear, what is detached DOM? How many states does DOM exist in?
How many states does DOM exist in?
- Interface elements live in
DOM
The tree - Garbage object
DOM
Node –DOM
fromDOM
The tree is detached,js
There are no quotes in it. - Detached state
DOM
Node –DOM
fromDOM
The tree is detached,js
There are references in there, not visible on the interface, but in memory.
The instance
For example, ul and LI are created, which are not rendered on the page, but are referenced in the code. These are the detached DOM:
<! ---->
<body>
<button id="btn">Add</button>
<script>
var tmpEle
function fn() {
var ul = document.createElement('ul')
for (var i = 0; i < 10; i++) {
var li = document.createElement('li')
ul.appendChild(li)
}
tmpEle = ul
}
document.getElementById('btn').addEventListener('click',fn)
</script>
</body>
Copy the code
Open the browser -> Memory -> Profiles -> Heap snapshot -> Take Snapshot
Click the Add button -> Take snapshot -> to see the extra UL tag and LI tag, this is the separate DOM
How do I split the DOM?
Set temEle to null
var tmpEle
function fn() {
var ul = document.createElement('ul')
for (var i = 0; i < 10; i++) {
var li = document.createElement('li')
ul.appendChild(li)
}
tmpEle = ul
tmpEle = null
}
Copy the code
At this point the heap snapshot, the detached DOM is gone.
Determine if there is frequent garbage collection (requires different tools)
Why judge?
Because the application is stopped while GC is working, if the current GC is running frequently and for too long, it is not friendly to the Web application. It will lead to the application being suspended and the user will feel that the application is stalling during use.
How to use monitoring to judge?
- According to the timing diagram of Timeline, the memory trend in the current performance panel is monitored. If there are frequent ups and downs, there will be frequent garbage collection. This is the time to locate the code and see what is doing to cause the situation.
- It’s easier to use the browser task manager, which is mostly about numerical changes, frequent split-second increases and decreases in data, and frequent garbage collection.