Memory leak analysis method and system based on IVI log and electronic equipment

Abstract

The invention discloses a memory leak analysis method and system based on an IVI log, electronic equipment and a storage medium, and relates to the field of in-vehicle machine memory data analysis, the method comprises the following steps: receiving an input parameter, determining an IVI log type, an analysis index and target application information, and obtaining analysis log data; according to the input parameters, loading a corresponding log file and carrying out text analysis; processing the analyzed log data, extracting effective data, and transferring the effective data into a database; performing fitting processing on the effective data by adopting a polynomial regression algorithm, and converting discrete data into a continuous curve; performing slope trend analysis on the fitted continuous curve, including deriving a fitting function corresponding to the continuous curve; calculating slope values of the curve at the plurality of data points based on the derivative function; analyzing the overall change trend of the slope value, and judging that the corresponding program has a memory leak risk; outputting a program name list with the memory leak risk; and displaying the effective data in a graphical mode.

Description

TECHNICAL FIELD

[0001] The application relates to the field of in-vehicle infotainment (IVI) memory data analysis, in particular to an IVI log-based memory leakage analysis method and system, an electronic device and a storage medium. BACKGROUND

[0002] For an in-vehicle infotainment (IVI) system, there are various types of logs, and developers and maintenance personnel usually use multiple methods to analyze and process the logs to ensure the stability and performance of the application. Among them, the Traceview and Systrace tools and the Kernel log consume system resources and are generally not stored offline, and need to be connected to a computer and stored and analyzed using special tools; the event log is opened for offline storage according to the situation, and the offline storage is used to save the corresponding information when a problem occurs, so as to facilitate subsequent analysis. In actual operation, a log file is usually read by a person using a text editor or a simple IDE tool, and relevant problems are analyzed by searching for specific fields and filtering information of a specified module, but the efficiency is low and the analysis time is long. In particular, problems related to system performance need to be analyzed from multiple dimensions and directions, not just a module or a type of log, and multiple logs need to be comprehensively analyzed.

[0003] Among them, memory leakage is easy to occur during program running, and the allocated memory is not properly released or recycled. In computer programming, an application needs to use memory to store data and perform tasks. When a program requests memory, the operating system allocates a certain amount of memory space; when the program no longer needs these memories, the mechanism provided by the programming language (such as the delete or free operation) should be used to release this part of memory so that other programs can use it again. If some allocated memory in the program cannot be properly released, this part of memory will be "forgotten", and even if the program continues to run, these memory areas will not be accessed. Over time, especially in long-running applications, this unreleased memory accumulates and eventually consumes the system's available memory resources. This may cause the program to crash or the entire system to become unstable or even slow down. SUMMARY

[0004] The application aims to provide an IVI log-based memory leakage analysis method and system, an electronic device and a storage medium. The application can quickly locate the problem in a short time, narrow down the range of causes of the problem, improve analysis efficiency, and visually display the trend of relevant data changes, give intelligent judgments and conclusions, and free up manpower, so that non-professionals can also output analysis results.

[0005] This invention provides the following solution:

[0006] According to one aspect of the present invention, a memory leak analysis method based on IVI logs is provided, comprising the following steps:

[0007] The steps for input parameter parsing are: receive input parameters, parse input parameters, determine IVI log type, analysis metrics and target application information, and obtain and parse log data;

[0008] The steps for loading log data are as follows: Based on the input parameters, load the corresponding IVI log file and perform text parsing;

[0009] The steps for filtering log data are as follows: filter, clean, and transform the parsed log data to extract valid data, including program name, process ID (PID), and memory usage.

[0010] The steps for transferring log data are: transferring the valid data to the database;

[0011] The steps for fitting discrete data are as follows: Use a multinomial regression algorithm to fit the effective data and convert the discrete data into a continuous curve;

[0012] The steps for determining the slope trend of a data curve are as follows: Perform slope trend analysis on the fitted continuous curve, specifically including:

[0013] The derivative function is obtained by taking the derivative of the fitted function corresponding to the continuous curve;

[0014] Calculate the slope of the curve at multiple data points based on the derivative function;

[0015] Analyze the overall trend of the slope value. If the slope value is generally greater than zero, it is determined that the corresponding program has a risk of memory leak.

[0016] Steps for outputting data results: Output a list of program names that are at risk of memory leaks;

[0017] The steps for data visualization are: to display the effective data graphically, including bar charts and line charts.

[0018] Furthermore, including:

[0019] The input parameters in the parameter parsing process also include instructions on whether memory leak investigation is required, as well as the validity verification of the specified investigation indicators.

[0020] Furthermore, including:

[0021] In the steps of discrete data fitting, the polynomial equation norm expression is as follows:

[0022] ;

[0023] Where y(x,w) is the predicted value of the fitted curve, which is a function of the independent variable x and the parameter w;

[0024] x represents the independent variable (the input independent variable);

[0025] w j Represented as: the regression coefficient (weight) of the j-th order term, j=0,1,…,M;

[0026] M represents the highest order of the polynomial;

[0027] j is represented as: the index variable for summation, iterating through integers from 0 to M.

[0028] Furthermore, including:

[0029] The steps for judging the slope trend of the data curve also include calculating the second derivative of the fitted function. The second derivative is used to judge the concavity and convexity of the curve. If the second derivative is greater than zero, it indicates that the slope is increasing.

[0030] Furthermore, including:

[0031] In the process of transferring log data, the database is used to store valid data as historical reference data.

[0032] Furthermore, including:

[0033] In the data visualization step, the line chart is used to show the trend of the target program's memory data as the number of log collections changes, and the bar chart is used to show the top N programs in terms of memory usage and their average memory usage, where N is a positive integer.

[0034] Furthermore, including:

[0035] In the step of determining the slope trend of the data curve, multiple data points are evenly distributed throughout the entire data range.

[0036] According to a second aspect of the present invention, a memory leak analysis system based on IVI logs is provided, the system comprising:

[0037] The input parameter parsing module is used to receive and parse input parameters, determine the IVI log type, analysis indicators, and target application information, and obtain and parse log data; at the same time, it verifies the validity of parameters and identifies memory leak troubleshooting commands.

[0038] The log data loading module is used to connect to the input parameter parsing module, load the corresponding IVI log file according to the parameters, and perform text parsing and preliminary processing.

[0039] The data filtering module is used to connect to the log data loading module to filter, clean, and transform the parsed data, and extract the program name, PID, and memory usage.

[0040] The data transfer module is used to connect to the data filtering module and transfer valid data to the database to form historical reference data.

[0041] The data fitting module connects to the data transfer module and uses a multinomial regression algorithm to fit the effective data and generate a continuous curve. The slope trend judgment module connects to the data fitting module and performs slope analysis on the fitted curve.

[0042] The results output module is used to connect to the slope trend judgment module and output a list of program names with memory leak risk.

[0043] The graphical display module connects the data transfer module and the result output module to generate visual results.

[0044] According to three aspects of the present invention, an electronic device is provided, comprising: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0045] The memory stores a computer program, and when the computer program is executed by the processor, it causes the processor to perform a series of steps in a memory leak analysis method based on IVI logs.

[0046] According to four aspects of the present invention, a computer-readable storage medium is provided that stores a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of a memory leak analysis method based on IVI logs.

[0047] Compared with the prior art, the present invention has the following advantages:

[0048] This application uses Python software to analyze the logs generated during the operation of IVI, extract information from massive amounts of logs, output which modules may be at risk of memory leaks, and display the memory data changes of the corresponding modules through a graphical interface, providing a solution for quickly discovering and locating problems for system performance optimization.

[0049] This application is implemented using the Python language and can be installed and deployed across platforms, running easily on Windows, Linux, and macOS. It does not require high-performance hardware or cloud-based big data and large-scale model computing power; it can run on ordinary PCs or laptops, making it suitable for portable debugging and analysis during research and development.

[0050] This application can output relevant information by inputting relevant parameters: the analysis results are textual descriptions, indicating which programs have memory leaks, and the data is displayed graphically so that even people without technical knowledge can understand the problem. It is easy to operate.

[0051] This application uses data fitting algorithms and curve slope trend judgment algorithms to provide trend judgments, output the names of modules with memory leaks, and put the analysis conclusions into a file. This allows development personnel to quickly find which modules have memory leaks, improves troubleshooting efficiency, and ensures system stability. Attached Figure Description

[0052] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0053] Figure 1 This is a flowchart of a memory leak analysis method based on IVI logs provided by one or more embodiments of the present invention.

[0054] Figure 2 This is a structural diagram of a memory leak analysis system based on IVI logs provided by one or more embodiments of the present invention.

[0055] Figure 3 This is a flowchart of an IVI log analysis method according to a specific embodiment of the prior art of the present invention.

[0056] Figure 4 This is a flowchart of an intelligent IVI log analysis method according to a specific embodiment of the present invention.

[0057] Figure 5 This is a flowchart of the intelligent analysis program processing according to a specific embodiment of the present invention.

[0058] Figure 6 This is a flowchart of the input parameter parsing module in a specific embodiment of the present invention.

[0059] Figure 7 This is a data cleaning flowchart in a specific embodiment of the present invention.

[0060] Figure 8 This is a memory trend chart displayed graphically in a specific embodiment of the present invention.

[0061] Figure 9 This is a bar chart showing the memory usage of a specific embodiment of the present invention.

[0062] Figure 10 This is a polynomial data fitting curve diagram of a specific embodiment of the present invention.

[0063] Figure 11 This is a geometrical coordinate diagram of the slope of a curve according to a specific embodiment of the present invention.

[0064] Figure 12 This is a memory trend chart of the ltd.qisi.sds module in a specific embodiment of the present invention.

[0065] Figure 13 This is a memory trend chart of the ltd.qisi.accountapp module in a specific embodiment of the present invention.

[0066] Figure 14 This is a memory trend chart of the com.hsae.someipservice module in a specific embodiment of the present invention.

[0067] Figure 15 This is a memory trend chart of the ltd.qisi.ximalayaservice module in a specific embodiment of the present invention.

[0068] Figure 16 This is a memory trend chart of the ltd.qisi.media.service module in a specific embodiment of the present invention.

[0069] Figure 17 This is a memory trend chart of the ltd.qisi.carmedia module in a specific embodiment of the present invention.

[0070] Figure 18 This is a memory trend chart of the ltd.qisi.filemanager module in a specific embodiment of the present invention.

[0071] Figure 19 This is a memory trend chart of the ltd.qisi.inputmethod module in a specific embodiment of the present invention.

[0072] Figure 20 This is a block diagram of an electronic device structure that provides a memory leak analysis method based on IVI logs according to one or more embodiments of the present invention. Detailed Implementation

[0073] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0074] Figure 1 This is a flowchart of a memory leak analysis method based on IVI logs provided by one or more embodiments of the present invention.

[0075] like Figure 1 The methods shown include:

[0076] Step S1, Input Parameter Parsing Steps: Receive input parameters, parse input parameters, determine IVI log type, analysis metrics and target application information, and obtain parsed log data;

[0077] Step S2, the log data loading steps: Based on the input parameters, load the corresponding IVI log file and perform text parsing;

[0078] Step S3, the steps for filtering log data: Filter, clean and transform the parsed log data to extract valid data, including program name, process ID (PID) and memory usage;

[0079] Step S4, the log data transfer step: Transfer the valid data to the database;

[0080] Step S5, the steps for fitting discrete data: Use a multinomial regression algorithm to fit the effective data and convert the discrete data into a continuous curve;

[0081] Step S6, the steps for judging the slope trend of the data curve: Perform slope trend analysis on the fitted continuous curve, specifically including:

[0082] The derivative function is obtained by taking the derivative of the fitted function corresponding to the continuous curve;

[0083] Calculate the slope of the curve at multiple data points based on the derivative function;

[0084] Analyze the overall trend of the slope value. If the slope value is generally greater than zero, it is determined that the corresponding program has a risk of memory leak.

[0085] Step S7, the data result output step: Output a list of program names that have a risk of memory leak;

[0086] Step S8, the step of data graphical display: Display the effective data in a graphical way, including bar charts and line charts.

[0087] Specifically,

[0088] The steps of input parameter parsing include: supporting different input parameters, analyzing different types of log files, analyzing different information in the logs, such as system memory usage, CPU usage, the status of a specific application, or a ranking of programs with the highest memory usage, etc., to provide the program with human classification ideas through parameter descriptions. Based on the parameter configuration, the program provides corresponding analysis conclusions, such as... Figure 6 As shown.

[0089] The steps for loading log data include: reading different log files and performing text parsing and preliminary processing.

[0090] The steps for filtering log data include: filtering, cleaning, and transforming the loaded data according to the input parameters, and then using it as source data for subsequent data analysis. At this point, the amount of data is much smaller than the original amount of data. It is a valid data set that has been processed by the software, including all program names, PIDs, memory usage, etc.

[0091] The steps for transferring log data include: transferring the processed, valid data set to the database for subsequent module analysis and processing, and also for backup storage as a historical reference data set. These steps—log loading, data filtering, and data transfer—can be categorized as a data cleaning process. Figure 7 The diagram shown is a data cleaning flowchart of one embodiment.

[0092] The steps for fitting discrete data include: since the effective data set selected from the logs is discrete data, it is necessary to use a fitting algorithm to curve the discrete data and use it as input for subsequent modules.

[0093] The steps for determining the slope trend of the data curve include: using the curve trend algorithm to determine the fitted curve data, providing the trend judgment, outputting the names of modules with memory leaks, and storing the analysis conclusions in a file. Developers can then use this file to understand which modules have memory leaks.

[0094] Memory leaks typically manifest as a gradual increase in program memory usage over a period of time. For example, a program might initially use only 20MB of memory, but after 10 minutes it might use 30MB, and after an hour it might use 100MB. In such cases, we consider the program to be at risk of a memory leak. The entire process is a gradual increase, but there are fluctuations in the data. Overall, it's an upward trend, and the slope of the curve is generally greater than 0. Figure 11As shown. The geometric meaning of slope: The slope indicates the degree of inclination of the curve at a certain point. If the slope is positive, it means that as x increases, y also increases, and the curve slopes upward; if the slope is negative, it means that as x increases, y decreases, and the curve slopes downward; if the slope is zero, it means that the curve is horizontal at that point, that is, y does not change with x. Therefore, we calculate whether the overall trend of the slope change of the fitted curve is >0. We use this indicator to determine whether the program has a memory leak. In this way, we can also copy the algorithm logic to the status of all programs in the system and check and analyze them one by one. This method is much faster and more accurate than manually reading logs.

[0095] The slope trend determination algorithm can be summarized in the following steps:

[0096] Differentiate:

[0097] The fitting function from the previous step is f(x) provided by the existing multinomial regression algorithm. For a given model function f(x), its reciprocal f'(x) is calculated. The value of the derivative f'(x) at a point x is the slope at that point.

[0098] Calculate the slope:

[0099] Using the derivative f′(x), the slope can be calculated at a series of points of interest. These points can be selected according to your needs, such as points uniformly distributed across the entire data range, or specific regions of interest.

[0100] Analyze the slope trend:

[0101] By analyzing the calculated slope values, you can observe the trend of the slope's change. You can plot the slope as a function of x to visually observe how the slope changes. For example, an increase in slope may indicate that the curve is becoming steeper, while a decrease in slope may indicate that the curve is becoming flatter.

[0102] Determine the trend:

[0103] If the slope gradually increases, it means that the curve becomes steeper and steeper within that interval.

[0104] If the slope gradually decreases, it means that the curve becomes increasingly flat within that interval.

[0105] If the slope changes from a positive value to a negative value (or vice versa), it indicates that the curve has undergone a directional change, which may be an extreme point.

[0106] Using the second derivative:

[0107] For a more in-depth analysis, you can further calculate the second derivative f′′(x), which provides the rate of change of the slope. If f′′(x) > 0, it means the slope is increasing; if f′′(x) < 0, it means the slope is decreasing. This can help you determine the concavity or convexity of the curve.

[0108] This method is implemented in Python and can be installed and deployed across platforms, including Windows, Linux, and macOS.

[0109] It does not require high-performance hardware or cloud-based big data and large-scale model computing power support. It can run on ordinary PCs or laptops, making it suitable for portable debugging and analysis in R&D.

[0110] Simply input the relevant parameters to get the output: the analysis results are presented in textual description, indicating which programs have memory leaks, and the data is displayed graphically so that even people without technical knowledge can understand the problem. It is easy to operate.

[0111] The steps for data visualization include: displaying the processed and valid data set graphically, providing different types of image display methods, such as bar charts, line charts, etc. Figure 8 and Figure 9 As shown.

[0112] Furthermore, the input parameters in the parameter parsing step also include instructions on whether memory leak investigation is required, as well as the validity verification of the specified investigation indicators.

[0113] Specifically, the input parameters need to include an instruction on "whether to perform memory leak investigation" to clarify whether the system triggers the memory leak analysis process and enhance the system's responsiveness.

[0114] By validating the user-specified screening indicators, the system ensures that the input parameters are within the range that the system can process, avoiding analysis errors caused by invalid parameters and improving the stability and reliability of the system.

[0115] Furthermore, including:

[0116] In the steps of discrete data fitting, the polynomial equation norm expression is as follows:

[0117] ;

[0118] Where y(x,w) is the predicted value of the fitted curve, which is a function of the independent variable x and the parameter w;

[0119] x represents the independent variable (the input independent variable);

[0120] w jRepresented as: the regression coefficient (weight) of the j-th order term, j=0,1,…,M;

[0121] M represents the highest order of the polynomial;

[0122] j is represented as: the index variable for summation, iterating through integers from 0 to M.

[0123] Specifically, discrete memory data in the IVI log is fitted using a polynomial form to transform it into a continuous curve, providing a basis for subsequent judgment of memory leaks based on slope trends.

[0124] The data fitting module uses a multinomial regression algorithm, such as... Figure 10 As shown, a series of discrete data can be fitted into a curve that conforms to the patterns in the data using mathematical formulas and algorithms. Multinomial regression is an extension of linear regression that fits the data by adding higher-order terms to the feature variables. Simply put, if a standard linear regression model only contains first-order terms (e.g., y = a + bx), then multinomial regression will include quadratic, cubic, and so on (e.g., y = a + b1x + b2x2 + b3x3) terms for the features. These additional terms help the model better capture the nonlinear relationships in the data.

[0125] Advantages of the algorithm:

[0126] Multinomial regression can capture non-linear relationships in data.

[0127] Compared to other nonlinear regression techniques, the calculation is relatively simple.

[0128] Disadvantages of the algorithm:

[0129] If the chosen polynomial order is too high, the model may overfit, meaning it follows the noise in the training data too closely, resulting in poor performance on new data.

[0130] The explanatory power of polynomial regression decreases as the order of the polynomial increases.

[0131] Higher-order terms may increase computational complexity.

[0132] Furthermore, including:

[0133] The steps for judging the slope trend of the data curve also include calculating the second derivative of the fitted function. The second derivative is used to judge the concavity and convexity of the curve. If the second derivative is greater than zero, it indicates that the slope is increasing.

[0134] Specifically, in addition to using the first derivative to calculate the curve slope to determine if memory is increasing (slope > 0 indicates potential leak), the calculation of the second derivative is added. The second derivative reflects the rate of change of the slope:

[0135] If the second derivative is greater than 0, it means that the slope of the curve is "continuously increasing" (i.e., the memory growth rate is accelerating).

[0136] This addition can more accurately depict the "worsening trend" of memory leaks, help locate modules with more severe leaks, and improve the granularity of the analysis.

[0137] Furthermore, including:

[0138] In the process of transferring log data, the database is used to store valid data as historical reference data.

[0139] Furthermore, including:

[0140] In the data visualization step, the line chart is used to show the trend of the target program's memory data as the number of log collections changes, and the bar chart is used to show the top N programs in terms of memory usage and their average memory usage, where N is a positive integer.

[0141] Specifically, through graphical display, the line chart focuses on the "target program" and uses "number of log collections" as the horizontal axis to intuitively present the dynamic trend of its memory data as the collection process progresses, making it easy to observe whether memory continues to grow (leakage characteristics).

[0142] Bar chart: Focuses on comparing multiple programs, showing the "top N programs in terms of memory usage" and their "average memory usage", which can quickly locate potential risk modules with high memory consumption. The value of N can be flexibly adapted to different analysis needs.

[0143] This limitation makes the graphical display more specific, enhancing the feasibility of the method and the readability of the results.

[0144] Furthermore, including:

[0145] In the step of determining the slope trend of the data curve, multiple data points are evenly distributed throughout the entire data range.

[0146] Specifically, this method uses a computer program implemented in Python to classify and process the massive log files output by IVI, filter and analyze specific indicators, provide graphical displays, and output corresponding analysis conclusions. Through algorithmic processing of log data, it automatically analyzes which modules in the system are at risk of memory leaks and outputs a list of corresponding module names.

[0147] During the R&D process, human involvement is always required for problem analysis and workflow. However, this method liberates labor by allowing computer software to replace manual analysis, resulting in high efficiency and speed. It eliminates the need for large-scale manual screening and comparison of all logs, saving labor costs, improving analysis and work efficiency, and offering high accuracy. It transforms massive amounts of text information into simple graphical representations, making it easier for humans to understand. This improves the efficiency of problem analysis and workflow during R&D, and the method of problem description is improved. Instead of using excessive text to describe a problem, it uses data extracted from logs and graphical information to describe the problem. This helps downstream problem solvers better understand the root causes of their module's issues, promoting iterative optimization and improvement of software modules.

[0148] According to another preferred embodiment, specifically: there are modules in the project with obvious memory leaks.

[0149] This includes the fact that the corresponding module ran normally throughout Monkey's operation without interruption, and the memory usage continued to increase, as shown in the corresponding memory data trend chart.

[0150] ltd.qisi.sds is the module responsible for data storage management and device status interaction in the vehicle system. Its memory data trend chart is shown below. Figure 12 As shown, possible causes of memory leaks include: failure to close the cursor and file stream in a timely manner when frequently reading and writing to local databases (such as SQLite) or files, resulting in resource handles continuously occupying memory;

[0151] When caching device status data (such as real-time sensor data), a static collection (such as HashMap) is used for storage, but no expiration and cleanup mechanism is set, and the data accumulates indefinitely over time.

[0152] Registered device status listeners (such as Bluetooth and USB connection status) are not deregistered after the service lifecycle ends, causing the context or data objects held by the listeners to be unable to be garbage collected.

[0153] ltd.qisi.accountapp is a module that explicitly points to the account application and is responsible for user login, identity authentication, and account information synchronization services. Its memory data trend chart is as follows: Figure 13 As shown, possible causes of memory leaks include: During the login process, asynchronous tasks (such as AsyncTask) or callbacks used for network requests (such as Token acquisition and information verification) are not bound to the Activity / Fragment lifecycle. After the task is completed, references to destroyed components are still held, resulting in memory not being released.

[0154] When caching user information (such as avatars and profiles), Bitmap objects are not compressed or reused, and are not actively recycled when memory is insufficient. Large objects are repeatedly created as user operations (such as switching accounts or refreshing information) occur.

[0155] Static variables hold account context (such as AccountManager instances), causing the entire account module's object tree to reside in memory for a long time and not be garbage collected.

[0156] com.hsae.someipservice is a server or client module for the SOME / IP protocol, responsible for message routing, service discovery, data transmission, etc. Its memory data trend chart, such as... Figure 14 As shown, the cause of the memory leak is that when processing SOME / IP messages, message objects (such as request / response data packets) do not have an expiration cleanup mechanism. In high-frequency communication scenarios (such as real-time vehicle status reporting), a large number of unreleased objects accumulate in the message queue.

[0157] During service registration and discovery, if the network connection (Socket) or session created is not properly closed after disconnection, the connection handle and buffer data will continue to occupy memory.

[0158] If a subscribed remote service event (such as a vehicle status change) is not unsubscribed when it is no longer needed, the event callback will continue to hold a reference to the local service, forming a memory reference chain.

[0159] ltd.qisi.ximalayaservice is the backend service module for the Himalaya in-car version, responsible for audio playback, content caching, and download management (such as podcasts and music). Its memory data trend chart is shown below. Figure 15 As shown, the cause of the memory leak is: the audio caching mechanism is poorly designed, the total size of downloaded audio files (such as temporary cached fragments) is not limited, and they are not cleaned up after playback, causing the memory occupied by the cache directory (or disk-mapped memory) to grow indefinitely with the playback time.

[0160] Audio player instances (such as MediaPlayer, custom players) are repeatedly created without calling the release() method to release hardware decoding resources, resulting in a new, uncollected player object being created every time audio is switched.

[0161] Callbacks such as progress updates and playback status listeners (e.g., OnPlaybackListener) were not removed after the service stopped, causing the player and the service to hold references to each other, forming a memory leak chain.

[0162] ltd.qisi.media.service is a general media service responsible for the unified audio and video management module within the in-vehicle system. It handles local media library scanning, media file parsing from external devices (USB flash drives / mobile phones), playback control, etc. Its memory data trend chart, such as... Figure 16 As shown, the possible causes of the memory leak are: during the media library scanning process, MediaMetadata (media metadata, including cover art, duration, etc.) objects are frequently created, but temporary objects are not released after the scan is completed. This is especially true when scanning a large number of files (such as thousands of songs on a USB drive), where memory usage surges and does not decrease.

[0163] Hardware-related media resources (such as HDMI output and car audio interface) are not released correctly. Even if playback stops, they still hold references to the hardware devices, resulting in the inability to reclaim the associated memory areas.

[0164] When switching between multiple tasks (such as switching from music to video), the thread of the previous media task (such as the decoding thread) is not properly interrupted. The thread continues to run and holds the media data buffer, causing the memory to fail to be released.

[0165] All five modules are continuously running background services / applications (uninterrupted in Monkey testing). Their core commonality in memory leaks is that during long-term operation, objects are continuously created or resources are consumed without an effective release / cleanup mechanism, leading to linear or accelerated memory growth over time. Given the limited resources of in-vehicle IVI systems, such leaks could ultimately cause system lag, application crashes, or even restarts. Therefore, code auditing and tool detection (such as using LeakCanary or MAT to analyze memory snapshots) should be prioritized for the aforementioned suspected leak points.

[0166] These modules either exited or were killed during Monkey testing, resulting in a periodic increase in memory usage.

[0167] ltd.qisi.carmedia is the in-vehicle media module, responsible for integrating in-vehicle audio and video resources, managing playback control, and synchronizing media metadata. Its memory data trend chart is shown below. Figure 17 As shown.

[0168] In the Monkey test, a loop of "start → play → exit (or be killed by the system) → restart" may occur, and the memory baseline is higher after each loop than the previous one (i.e., "start once, memory increases significantly").

[0169] Suspected cause of leakage: Incomplete resource release: Each time the media library is loaded during startup (such as scanning USB music or reading online playlists), a large number of metadata objects (such as MediaInfo and cover Bitmap) are created. If the onDestroy callback is not triggered upon exit (such as being forcibly killed by the system), these objects may not be garbage collected, resulting in new objects overlapping old objects in residual memory during the next startup.

[0170] Cross-process reference remnants: If cross-process communication with hardware modules such as in-vehicle screens and audio systems is conducted via Binder, and the connection is not disconnected upon exit, the hardware service may still hold a reference to that module, resulting in some memory (such as the playback buffer) not being released;

[0171] Static cache not cleared: To optimize the user experience, modules may use static collections (such as LruCache) to cache frequently used media resources, but no maximum cache threshold is set or the cache is not actively cleared upon exit. After the process restarts, the static variables are not reset due to the process-level lifecycle, resulting in the accumulation of cached data.

[0172] ltd.qisi.filemanager is responsible for file management of the in-vehicle system, including browsing local storage / external USB flash drive files, copying / deleting / decompressing files, displaying file thumbnails (such as image and video previews), and calculating storage space. Its memory data trend chart, for example... Figure 18 As shown.

[0173] Each time I open the file manager to browse a large number of files (such as a folder containing hundreds of images) and then exit, the memory usage does not return to its initial level; when I open it again, the memory usage continues to increase from the "high baseline at the time of last exit".

[0174] Possible causes of suspected leak:

[0175] Uncontrolled thumbnail caching: To speed up browsing, image / video thumbnails (especially large preview images) are cached. If the cache size is not limited and is not cleared upon exit (e.g., only released when manually triggering "clear cache"), even if the process is killed, the cache may have been written to disk and mapped to memory, causing memory accumulation when reloaded on the next startup.

[0176] File handle not released: When operating on large files (such as decompressing zip files or reading log files), if the process is forcibly terminated midway (such as Monkey triggering the return key + system killing process), the opened file stream (FileInputStream) or input / output buffer is not closed, causing the kernel to still hold the file handle and occupy memory;

[0177] List data remnants: When displaying a list of files, the RecyclerView's adapter holds a large number of File object references. If the adapter is not unbound or the data source is not cleared when exiting, these objects may be marked as "unnecessary but not reclaimed" in the GC, accumulating memory usage.

[0178] ltd.qisi.inputmethod is a customized input method for in-vehicle use, supporting scenarios such as navigation address input, search box text input, and message reply. It may include modules for word association, handwriting recognition, and speech-to-text conversion. Its memory data trend chart is shown below. Figure 19 As shown.

[0179] Each time the input method is activated (such as by clicking the search box), memory usage increases; after the input method is closed (switched to other applications) or the process is killed, memory usage does not completely decrease; upon reactivation, memory usage continues to increase from a higher baseline (especially when frequently switching input scenarios).

[0180] Possible causes of suspected leak:

[0181] Lexicon / model resources not uninstalled: To improve input efficiency, local lexicons (such as place name lexicons, contact lexicons) or handwriting recognition models (larger machine learning models) may be preloaded. These resources are not released when the input method is hidden (rather than destroyed), and they still occupy memory even if the process is running in the background.

[0182] UI resource residency: The keyboard layout of the input method (especially custom skins) contains a large number of images and animation resources. If the View objects created each time they are displayed are not recycled when they are hidden (such as due to design flaws in the reuse mechanism), it will cause the View tree to accumulate and consume memory.

[0183] Improper context references: As a system service, the input method may hold a long-term reference to the Application context or the Activity of the currently active input box. If the reference is not broken after the Activity is destroyed, the Activity and its associated resources (such as input history) will not be garbage collected, forming a memory leak chain.

[0184] Figure 2 This is a structural diagram of a memory leak analysis system based on IVI logs provided by one or more embodiments of the present invention.

[0185] like Figure 2 The system shown includes:

[0186] The input parameter parsing module is used to receive and parse input parameters, determine the IVI log type, analysis indicators, and target application information, and obtain and parse log data; at the same time, it verifies the validity of parameters and identifies memory leak troubleshooting commands.

[0187] The log data loading module is used to connect to the input parameter parsing module, load the corresponding IVI log file according to the parameters, and perform text parsing and preliminary processing.

[0188] The data filtering module is used to connect to the log data loading module to filter, clean, and transform the parsed data, and extract the program name, PID, and memory usage.

[0189] The data transfer module is used to connect to the data filtering module and transfer valid data to the database to form historical reference data.

[0190] The data fitting module connects to the data transfer module and uses a multinomial regression algorithm to fit the effective data and generate a continuous curve. The slope trend judgment module connects to the data fitting module and performs slope analysis on the fitted curve.

[0191] The results output module is used to connect to the slope trend judgment module and output a list of program names with memory leak risk.

[0192] The graphical display module connects the data transfer module and the result output module to generate visual results.

[0193] It is worth noting that although this system only discloses the input parameter parsing module, log data loading module, data filtering module, data transfer module, data fitting module, result output module, and graphical display module, it does not mean that this system is limited to the above-mentioned basic functional modules. On the contrary, what this invention intends to express is that, based on the above-mentioned basic functional modules, those skilled in the art can add one or more functional modules in combination with existing technology to form an infinite number of embodiments or technical solutions. That is to say, this system is open rather than closed. It should not be assumed that the scope of protection of the claims of this invention is limited to the above-disclosed basic functional modules just because this embodiment only discloses a few basic functional modules.

[0194] Figure 3 This is a flowchart of an IVI log analysis method according to a specific embodiment of the prior art of the present invention.

[0195] like Figure 3 The methods shown include:

[0196] By intelligently analyzing IVI's offline logs, memory leaks are detected, improving analysis efficiency. This technical solution mainly consists of the following seven steps:

[0197] Input parameter analysis;

[0198] Log data loading;

[0199] Log data filtering;

[0200] Log data transfer;

[0201] Discrete data fitting;

[0202] Judging the trend of the slope of the data curve;

[0203] Data results output;

[0204] Data is displayed graphically;

[0205] This solution can support different types of log file input (top logs, meminfo type logs).

[0206] Figure 5 This is a block diagram of an electronic device structure for a multi-vehicle testing application method provided by one or more embodiments of the present invention.

[0207] like Figure 5 As shown, this application provides an electronic device, including: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0208] The memory stores a computer program, which, when executed by the processor, causes the processor to perform steps of a method for adapting to multi-vehicle testing applications.

[0209] This application also provides a computer-readable storage medium storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of a method for adapting to multi-vehicle testing applications.

[0210] For the sake of simplicity, the method embodiments are described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0211] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0212] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A memory leak analysis method based on IVI logs, characterized in that, Includes the following steps: The steps of input parameter parsing are: receiving input parameters, parsing the input parameters, determining the IVI log type, analysis indicators and target application information, and obtaining and parsing log data; The steps for loading log data are as follows: Based on the input parameters, load the corresponding IVI log file and perform text parsing; The steps for filtering log data are as follows: the parsed log data is filtered, cleaned, and transformed to extract valid data, which includes program name, process ID (PID), and memory usage. The steps for transferring log data are as follows: Transfer the valid data to the database; The steps for fitting discrete data are as follows: use a multinomial regression algorithm to fit the effective data and convert the discrete data into a continuous curve; The steps for determining the slope trend of a data curve are as follows: Perform slope trend analysis on the fitted continuous curve, specifically including: The derivative function is obtained by differentiating the fitting function corresponding to the continuous curve; The slope of the curve at multiple data points is calculated based on the derivative function. Analyze the overall trend of the slope value. If the slope value is generally greater than zero, it is determined that the corresponding program has a risk of memory leak. Steps for outputting data results: Output a list of program names that are at risk of memory leaks; The steps for data graphical display are as follows: The effective data is displayed graphically, including bar charts and line charts.

2. The memory leak analysis method based on IVI logs according to claim 1, characterized in that, In the step of parsing the input parameters, the input parameters also include instructions on whether memory leak investigation is required, as well as the validity verification of the specified investigation indicators.

3. The memory leak analysis method based on IVI logs according to claim 1, characterized in that, In the discrete data fitting step, the polynomial equation norm expression is as follows: ； Where y(x,w) is the predicted value of the fitted curve, which is a function of the independent variable x and the parameter w; x represents the independent variable (the input independent variable); w j Represented as: the regression coefficient (weight) of the j-th order term, j=0,1,…,M; M represents the highest order of the polynomial; j is represented as: the index variable for summation, iterating through integers from 0 to M.

4. The memory leak analysis method based on IVI logs according to claim 1, characterized in that, The step of judging the slope trend of the data curve also includes calculating the second derivative of the fitting function, and judging the concavity of the curve by the second derivative. If the second derivative is greater than 0, it indicates that the slope is increasing.

5. The memory leak analysis method based on IVI logs according to claim 1, characterized in that, In the step of transferring log data, the database is used to store valid data as historical reference data.

6. The memory leak analysis method based on IVI logs according to claim 1, characterized in that, In the step of data graphical display, the line graph is used to show the trend of memory data of the target program as the number of log collections changes, and the bar graph is used to show the top N programs in terms of memory usage and their average memory usage, where N is a positive integer.

7. The memory leak analysis method based on IVI logs according to claim 1, characterized in that, In the step of determining the slope trend of the data curve, the multiple data points are evenly distributed throughout the entire data range.

8. A memory leak analysis system based on IVI logs, characterized in that, include: The input parameter parsing module is used to receive input parameters, parse the input parameters, determine the IVI log type, analysis indicators and target application information, and obtain parsed log data; at the same time, it verifies the legality of the parameters and identifies memory leak investigation commands. The log data loading module is used to connect to the input parameter parsing module, load the corresponding IVI log file according to the parameters, and perform text parsing and preliminary processing. The data filtering module is used to connect to the log data loading module to filter, clean, and transform the parsed data, and extract the program name, PID, and memory usage. The data transfer module is used to connect to the data filtering module and transfer valid data to the database to form historical reference data; The data fitting module is used to connect to the data transfer module, and uses a multinomial regression algorithm to fit the effective data and generate a continuous curve. Slope trend judgment module: Connects to the data fitting module and performs slope analysis on the fitted curve; The results output module is used to connect to the slope trend judgment module and output a list of program names at risk of memory leaks. The graphical display module connects the data transfer module and the result output module to generate visual results.

9. An electronic device, characterized in that, include: The processor, communication interface, memory, and communication bus are connected, with the processor, communication interface, and memory communicating with each other via the communication bus. The memory stores a computer program that, when executed by the processor, causes the processor to perform the steps of the memory leak analysis method based on IVI logs as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, It stores a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of a memory leak analysis method based on IVI logs as described in any one of claims 1-7.

Images