Web simulation or real memory analysis applications and automation solutions

js comes with a GC (garbage collection) mechanism, so the vast majority of web developers do not consider memory conditions in daily development (including myself). In most business scenarios, this may not be a problem, but in some core web application scenarios (For example, when a page is placed under a first-level tab, the WebView will basically not be destroyed, or applications such as applets and PhoneGap / Electron that currently focus on WebView rendering) will cause some white screen crashes. Unexpected bugs affect user experience.

(*Note: Most of the third-party links in this article need to be accessed through the firewall)

Effects of memory leaks

For users, generally memory leak scenarios are not noticeable at all, but once the memory leak is serious, the user’s intuitive feeling is that the page/computer starts to operate laggy, until it is completely stuck at a certain moment or the page/application crashes and crashes. In this case, users will lose trust in your product.

  • PC Browser: Browser freezes or even crashes
  • iOS: In the early days, UIWebView shared memory space with the app, which would easily cause the app/browser to freeze, have a white screen, or even crash. Even inputting a large image/file would directly crash if it was not handled properly. Later, although WKWebView optimized the WebView memory and Management, but there are still many bugs. In addition, the iPhone itself has a small memory space, which is still prone to lags, white screens, and even crashes;
  • Android: Compared with the iPhone, Android devices usually have larger memory space, and the memory allocation of WebView is more sufficient, which provides some help for the stability of WebView. However, due to the ecological chaos of Android and the problems of js support in the engine, it will This leads to many weird problems and makes memory leaks more likely. It is prone to freezing, white screen, and even crash problems;

Compared with the PC side, the hardware conditions of the mobile terminal are often relatively backward, and the WebView environment and memory limitations are also more stringent. In addition, due to system limitations, the mobile terminal is not as convenient as the PC terminal for browser updates/switching, so it is more difficult to optimize WebView management through environmental improvement. Therefore, the memory problem on the mobile terminal will be more serious and needs sufficient attention.

Usually the PC side reduces memory problems through code or guided browser updates/switches. PC applications can also update the kernel to optimize the environment, and the overall cost is smaller. The mainstream optimization method on the mobile side is to optimize the kernel/memory management. Those who have the ability/real needs will often develop their own kernels to reduce memory problems. For example, many Android applications will be modified based on QQX5. These costs are often high and there are hosts. environmental restrictions. This article will not elaborate on memory optimization and management.

SPA pages need more attention

In SPA pages, the memory is not automatically cleared every time the navigation is switched, which is more likely to cause memory leaks than in MPA. Therefore, event monitoring, DOM operations, network requests, timers, etc. in SPA require more attention.


Real machine memory detection

The most common detection method——Chrome DevTool

1. “任务管理器”——Look at the overall situation

The entrance is the upper right corner of Chrome 设置 - 更多工具 - 任务管理器( Setting - More Tools - Task Manager).

p-chrome-1

And we can select the fields that need to be displayed through the right-click menu:

p-chrome-2

Field descriptions:

  • Task:Task
  • personal information:Profile
  • Memory footprint:Memory Footprint
  • CPU
  • network:Network
  • Process ID:Process ID
  • Image cache:Image Cache
  • Script cache:Script Cache
  • CSS caching:CSS Cache
  • GPU cache:GPU Memory
  • Memory used by SQLite:SQLite Memory
  • NaCI debug port:NaCI Debug Port
  • Memory used by JavaScript:JavaScript Memory
  • Wake up from idle state:Idle Wake Ups
  • File descriptor:File Descriptors
  • Process priority:Process Priority
  • Number of activities using the extension:Keepalive Count

2. Performance——View js Heapmemory changes on the timeline

Performance will be used relatively often. As long as we check it, Memorywe can increase the memory change statistics.

p-chrome-3

*Recorder, records combined with user events

Chrome 97 starts to support (about 2021.10), which can be used as the plus version of Performance. It adds event records related to user operations to better locate specific operation scenarios:

p-chrome-7

p-chrome-8

Official website usage introduction: "Chrome Developers——Record, replay and measure user flows"

3. Memory——View the specific snapshot information of a certain period/moment of memory

If you really want to locate memory problems, this is an indispensable tool, and its use is relatively simple.

p-chrome-4

Select mode:

  • Heap snapshot: Heap snapshot, used to print heap snapshot. The heap snapshot file displays the memory allocation between the js object of the page and the related DOM node;
  • Allocation instrumentation on timeline: Record memory information on the timeline, and record memory information as time changes;
  • Allocation sampling: Memory information sampling, using sampling method to record memory allocation. This profile type has minimal performance overhead and can be used for long-running operations. It provides a good approximation of the stack breakdown performed by js.
filter

After selecting the mode to take a snapshot, you can filter by selecting the module in the upper right:

  • Snapshot viewing mode: DefaultSummary
    • Summary: Can display objects grouped by constructor name. Use this view to gain insight into objects (and their memory usage) based on type grouped by constructor name, useful for tracking DOM leaks.
    • Comparison: Can show the differences between two snapshots. Use this view to compare the differences between two (or more) memory snapshots before and after an operation. Examining the changes and reference counts of freed memory can confirm whether there is a memory leak and its cause.
    • Containment: This view provides an object structure view to analyze memory usage, with top-level objects as the entry point.
    • Statistic: Memory usage pie chart.
  • Filtering of object classification: Right Constructorfiltering
  • Object selection: DefaultAll objects
Display fields

Description of the fields displayed in the table:

  • Contructor: Represents all objects created using this constructor
  • Distance: Displays the distance from the root node using the node's shortest simple path
  • Shallow Size: Displays the sum of the shallow sizes of all objects created through a specific constructor. The shallow size refers to the memory size occupied by the object itself (generally speaking, the shallow size of arrays and strings is relatively large)
  • Retained Size: Displays the largest reserved size among objects in the same group. The amount of memory that can be freed after an object is deleted (its dependencies are no longer reachable) is called the reserved size.
  • New: (Comparison specific) New item
  • Deleted: (Comparison specific) Delete item
  • Delta: (Comparison-specific) increment
  • Alloc. Size: (Comparison-specific) memory allocation size
  • Freed Size: (Comparison-specific) Release size
  • Size Delta: (Comparison-specific) memory increment

Official website terminology explanation: "Chrome Developers——Memory terminology"

search

ctrl/command + FWake up search and filter based on keywords

p-chrome-5

4. Performance monitor——Easy View

p-chrome-6

Performance monitor is real-time, but there is no way to see detailed information.

There are many methods and scenarios for Chrome to troubleshoot memory, such as


Mobile terminal——Chrome/Safari

Compared with PC, real-machine debugging on mobile terminals has always been more troublesome. In particular, memory analysis is difficult to perform like style debugging, which can use some socket connection methods (Performance Memory is compatible with pull-across), so it is necessary to check the real memory usage of mobile terminal pages. Situation requires equipment/environmental assistance.

iOS——Safari

Wired, you need an iPhone, Mac and data cable.

step
  • 1. Confirm the phone settings ( 设置-> Safari-> 高级-> Web检查器is open);
  • 2. USB connection to real machine;
  • 3. Confirm device trust;
  • 4. Open Safari on both your phone and computer;
  • 5. In the Safari menu 开发- XXX 的 iPhone, click to start debugging.

Note that if you want to see the memory changes in the timeline, select "For" in the menu and 时间线select 内存the module for programming on the left, such as:

p-safari-1

Special reminder, if you want to check the memory status, it is best to select only 内存one indicator module. If there are multiple indicators selected, Safari will easily crash and crash.

*iOS can also be debugged using ios-webkit-debug-proxy and then using Chrome. The mechanism itself is to connect to Chrome by creating a proxy server. Please refer to this article: "How to debug remote iOS device using Chrome DevTools "

Android/Hongmeng——Chrome/Android Studio

Similar to iOS debugging, it is wired and requires an Android phone, Windows/Mac computer and data cable.

Chrome official description: "Chrome Developers——Remote debug Android devices"

step
  • 1. Confirm the phone settings ( 开发者模式Open-> USB调试Open status);

  • 2. USB connection to real machine;

  • 3. Confirm device trust;

  • 4. Open Chrome on both your phone and computer;

  • 5. PC Chrome access chrome://inspect: Confirm connection status
    p-dchrome-1

  • 6. Select 'inspect' of the corresponding page to access
    p-dchrome-2

The debugging mode of Android Studio is similar to Chrome and also relies on Chrome. For operations, please refer to "How to debug Android Chrome from Windows, Linux, or Mac—Install Android Debug Bridge (ADB)"

Special reminder: If 'inspect'you find that the debugging console is always blank or 404 when accessing, it is likely that the js files involved in the console have failed to load. Most of the js files need to be accessed over the wall, so you need to browse them at this time.

Is there any remote method without plugging in the wires?

Yes, but the device needs to be on the same network segment. Set up a web server and host a site on your development computer, then access the content from your Android device. For details, please view the documentation: "Chrome Developers—Access local servers"

In-app page

The general solution is to install the debug app, and then debug through the IDE or use Safari/Chrome. The main problem with this method is that it requires a debug package and environment;
or it needs to use a simulator developed by the client for troubleshooting. The main problem with this method is that it is a simulated environment, which is somewhat different from the real environment;
either the client provides a console and displays the memory information in the console, such as Didi's DoraemonKit , but it should be noted that iOS Apps now basically WKWebView will be used. In this case, the client cannot get the memory information of the page (WebView) (because the system shares the WebView virtual memory), so the memory module like DoraemonKit cannot observe the page memory situation. The solution at this time is to obtain The memory information of the entire device can be judged by observing changes in the device memory. The disadvantage is that it is difficult to ensure the impact on other applications and systems;

Relevant code for iOS development to obtain memory:

// 获取当前app消耗的内存,注意捕获不了WebView的内存消耗
+ (NSUInteger)useMemoryForApp {
  task_vm_info_data_t vmInfo;
  mach_msg_type_number_t count = TASK_VM_INFO_COUNT;
  kern_return_t kernelReturn = task_info(mach_task_self(), TASK_VM_INFO, (task_info_t) &vmInfo, &count);
  if (kernelReturn == KERN_SUCCESS) {
    int64_t memoryUsageInByte = (int64_t) vmInfo.phys_footprint;
	return memoryUsageInByte / 1024 / 1024;
  } else {
    return -1;
  }
}

// 获取整个设备的内存情况
+ (NSUInteger)totalMemoryForDevice {
  return [NSProcessInfo processInfo].physicalMemory / 1024 / 1024;
}
*js VM

Finally, there is another way to use Chrome and the server to build a js VM debugging ecosystem. The following small program developer tools are also in this mode. If you are interested, you can take a look at the Chrome DevTools Protocol: https://chromedevtools.github.io/devtools- protocol/

Mini Program - Developer Tools

Mini program developer tools such as WeChat/Alipay usually make better use of the js VM memory tool supported by Chrome 67 and later , so it is very convenient to conduct real-machine memory analysis remotely.

p-weapp-1


In addition, with the help of the headless browser Puppeteer , we can automate memory detection :

Quick method - FuiteJs

Github address: https://github.com/nolanlawson/fuite

Fuite is a cli tool written in js. It analyzes whether there are memory leaks on the page based on Puppeteer and is SPA-friendly.

Note: Fuite requires nodejs v14.14.0 and above environment (currently the stable version of nodejs is 16+)

Principle and mechanism

Fuite is relatively simple. It mainly determines whether there is a memory leak by monitoring route jumps:

  • 1. Use Puppeteer to open the parameter page;
  • 2. Find all routing pages on the page and open them;
  • 3. Simulate fallback (route return);
  • 4. Repeat (default is 7 times) to confirm whether there is a memory leak. This is the main logical processing of the entire library. Judgments based:
    • Objects:对象(Chrome heap snapshots)
    • Event listeners: event listening
    • DOM node
    • Arrays, Maps, Sets、普通Object

If Fuite detects a leak, it will display the information in the console or output file.

use

imperative

Installation and testing

npx fuite https://blog.michealwayne.cn

use:

fuite [options] <url>

parameter:

  url                        URL to load in the browser and analyze

Among them Options:

  -o, --output <file>        Write JSON output to a file
  -i, --iterations <number>  Number of iterations (default: 7)
  -s, --scenario <scenario>  Scenario file to run
  -S, --setup <setup>        Setup function to run
  -H, --heapsnapshot         Save heapsnapshot files
  -d, --debug                Run in debug mode
  -p, --progress             Show progress spinner (use --no-progress to disable)
  -b, --browser-arg <arg>    Arg(s) to pass when launching the browser
  -V, --version              output the version number
  -h, --help                 display help for command
quotation
import {
    
     findLeaks } from 'fuite';

const myScenario = {
    
    
  async setup(page) {
    
     /* ... */ },			// 默认无
  async createTests(page) {
    
     /* ... */ },	// 默认拿href
  async iteration(page, data) {
    
     /* ... */ }	// 默认为页面后退的往返
};

for await (const result of findLeaks('https://blog.michealwayne.cn', {
    
    
  scenario: myScenario,		// scenario参数可选,默认为defaultScenario
})) {
    
    
  console.log(result);
}

Interestingly, the author of Fuite used Fuite to test the homepages of 10 mainstream front-end frameworks and found that all of them had leakage problems (the author hid the specific names in the statistics, you can try it if you are interested):

p-auth-page1

extend

We can extend the functions and usage scenarios of Fuite to better serve business memory detection:

  • 1. Servitization: We can put Fuite on the server and perform regular checks through configuration, as well as corresponding abnormal alarms, etc., to turn memory detection into a service and platform;
  • 2. Cluster processing: Using Fuite usually takes a long time. If there are multiple addresses that need to be detected, it is recommended to set up a multi-process cluster for separate detection;
  • 3. Transformation: The Fuite logic is to obtain all routes in the page for detection. We can adjust the filtering control and optimize the MPA processing to improve detection efficiency and coverage.

at last

Not all memory leaks are problems that need to be solved. For example, v8's JIT can also cause memory growth, but as web developers, we are obliged to use tool methods to find out all memory leak scenarios in the business.

*My github: https://github.com/MichealWayne , blog address: https://blog.michealwayne.cn/


Related Links

Guess you like

Origin blog.csdn.net/qq_24357165/article/details/128461172