Toast message call detection method and device, terminal and medium
By dynamically tracking function scope in static code analysis and using a boolean flag mechanism, the problem of low detection accuracy of Toast message calls is solved, achieving accurate detection in nested function scenarios and improving the accuracy and reliability of detection results.
Patent Information
- Application Number
- CN202511049878.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-07-29
- Publication Date
- 2025-10-31
AI Technical Summary
Existing static code analysis techniques suffer from low detection accuracy when detecting Toast message calls in the Android system, especially in nested function scenarios where missed or false detections are common.
By dynamically tracking the entry and exit states of function scopes while scanning code files, and combining Boolean flags and regular expressions, the system accurately identifies the location of Toast message function fields and extracts parameters, ensuring that the detection is performed within the correct function scope.
It achieves accurate detection in multi-level nested function scenarios, avoiding false detections and missed detections, and improving the accuracy and reliability of static code analysis.
Smart Images
Figure CN120872783A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of program analysis and debugging tools, and in particular to a method, device, terminal and medium for detecting Toast message calls. Background Technology
[0002] Toast is a lightweight UI notification component in the Android system. It features flexible display position and automatic timeout disappearance, and is often used to indicate the result of an operation (such as "Saved successfully" or "Network connection failed").
[0003] Static code analysis technology discovers potential problems by statically scanning the syntax, structure, and logic of source code without executing the program. It has been widely used in code quality inspection, vulnerability identification, and other fields. However, when detecting Toast message calls, existing static code analysis technologies still use the traditional regular expression and large codebase scanning detection mode. This detection mode cannot effectively handle nested functions or dynamic code logic, and is prone to missed or false detections. It also has the technical problem of insufficient detection accuracy in nested function scenarios. Summary of the Invention
[0004] This application provides a method, apparatus, terminal, and medium for detecting Toast message calls, which addresses the technical problem of low detection accuracy in existing static code analysis techniques when detecting Toast message calls.
[0005] To address the aforementioned technical problems, the first aspect of this application provides a method for detecting Toast message invocation, including:
[0006] Obtain the code file to be tested;
[0007] The code file is scanned based on the function definition information in the code file. When any target function is scanned, a preset first Boolean flag is activated, wherein the first Boolean flag is used to indicate that the current scan position has entered the scope of the target function.
[0008] The scope of the target function is scanned for Toast message function fields. When a Toast message function field is scanned and the first boolean flag is active, the position of the Toast message function field is recorded and the parameters corresponding to the Toast message function field are extracted.
[0009] When the function end marker of the target function is detected, the first Boolean flag is reset;
[0010] After the code file scan is complete, the Toast message call detection result of the code file is output.
[0011] Preferably, the step of recording the position of the Toast message function field and extracting the parameters corresponding to the Toast message function field when the Toast message function field is scanned and the first boolean flag is active includes:
[0012] When the Toast message function field is scanned, a preset second Boolean flag is activated, which is used to indicate that the target function has been detected to call the Toast message function;
[0013] When both the first Boolean flag and the second Boolean flag are active, record the position of the Toast message function field and extract the parameters corresponding to the Toast message function field.
[0014] Preferably, after extracting the parameters corresponding to the Toast message function field, the process includes:
[0015] Once the parameters corresponding to the Toast message function field have been extracted, the second Boolean flag is reset.
[0016] Preferably, the step of scanning the scope of the target function using the Toast message function field includes:
[0017] The Toast message function field within the scope of the target function is matched using regular expressions.
[0018] Preferably, after obtaining the code file to be detected, the process further includes:
[0019] Based on preset file extension filtering information, when the file extension of the code file matches the file extension filtering information, the code file is filtered.
[0020] Meanwhile, a second aspect of this application provides a Toast message invocation detection device, comprising:
[0021] The code file acquisition unit is used to acquire the code file to be inspected.
[0022] The function scanning unit is used to scan the code file according to the function definition information in the code file. When any target function is scanned, a preset first Boolean flag is activated, wherein the first Boolean flag is used to indicate that the current scanning position has entered the scope of the target function.
[0023] The Toast message scanning unit is used to scan the scope of the target function for Toast message function fields. When a Toast message function field is scanned and the first Boolean flag is active, the position of the Toast message function field is recorded and the parameters corresponding to the Toast message function field are extracted.
[0024] The first flag reset unit is used to reset the first Boolean flag when the function end identifier of the target function is detected.
[0025] The detection result output unit is used to output the detection result of the code file by calling a Toast message after the code file scan is completed.
[0026] Preferably, the Toast message scanning unit is specifically used for:
[0027] The scope of the target function is scanned for Toast message function fields. When a Toast message function field is scanned and the first Boolean flag is active, the position of the Toast message function field is recorded, and the parameters corresponding to the Toast message function field are extracted.
[0028] Preferably, it further includes:
[0029] The second flag reset unit is used to reset the second boolean flag after the parameters corresponding to the Toast message function field have been extracted.
[0030] A third aspect of this application provides a Toast message invocation detection terminal, comprising: a memory and a processor;
[0031] The memory is used to store program code, which is used to implement a Toast message call detection method as provided in the first aspect of this application;
[0032] The processor is used to read and execute the program code.
[0033] The fourth aspect of this application provides a computer-readable storage medium storing program code, which is read and executed by a processor to implement a Toast message call detection method as provided in the first aspect of this application.
[0034] As can be seen from the above technical solutions, this application has the following advantages:
[0035] The solution provided in this application is based on the code file to be detected. It scans the code file according to the function definition information, activating a first Boolean flag when the target function is detected. Within the target function's scope, it scans the Toast message function field; when a Toast message field is detected and the first Boolean flag is activated, the position is recorded and parameters are extracted. When a function end marker is detected, the first Boolean flag is reset. Finally, the detection result is output. This solution accurately marks the function scope using the first Boolean flag, dynamically tracks the entry and exit states of the function scope, and combines this with a specific field matching mechanism to achieve more accurate detection, solving the technical problem of low detection accuracy in multi-layered nested function scenarios. Attached Figure Description
[0036] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0037] Figure 1 This is a flowchart illustrating an embodiment of a Toast message invocation detection method provided in this application.
[0038] Figure 2 This is an overall flowchart of an embodiment of a Toast message invocation detection method provided in this application.
[0039] Figure 3 This is a schematic diagram of an embodiment of a Toast message invocation detection device provided in this application.
[0040] Figure 4 This is a schematic diagram of the structure of an embodiment of a Toast message invocation detection terminal provided in this application. Detailed Implementation
[0041] In existing technologies, Toast is a lightweight UI notification component in the Android system, commonly used to indicate operation results. Static code analysis techniques discover potential problems by statically scanning source code. However, existing technologies, when detecting Toast message calls, employ traditional regular expressions and large codebase scanning methods, which cannot effectively handle nested functions or dynamic code logic, leading to frequent missed or false detections. For example, in scenarios with multiple levels of nested functions, traditional tools are prone to failing to accurately identify the actual call location of the Toast message due to scope confusion. To address these issues, those skilled in the art have noted the limitations of existing detection methods in identifying function scope. Analysis revealed that while regular expressions can quickly match code patterns, they cannot trace the logical hierarchy within functions.
[0042] In view of this, embodiments of this application provide a method, apparatus, terminal, and medium for detecting Toast message calls. This scheme dynamically tracks the entry and exit states of function scopes during the scanning process, and combined with a matching mechanism for specific fields, more accurate detection can be achieved. This approach breaks through the fixed pattern of traditional static analysis, combining scope state management with code feature recognition to solve the technical problem of low detection accuracy in existing static code analysis techniques when detecting Toast message calls.
[0043] To make the inventive objectives, features, and advantages of this application more apparent and understandable, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the embodiments described below are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0044] First, a detailed description of an embodiment of a Toast message invocation detection method provided in this application is as follows:
[0045] Please see Figure 1 and Figure 2 The Toast message invocation detection method provided in this application includes:
[0046] Step 101: Obtain the code file to be detected;
[0047] Step 102: Scan the code file according to the function definition information in the code file. When any target function is detected, activate the preset first Boolean flag.
[0048] Step 103: Scan the scope of the target function for the Toast message function field. When the Toast message function field is scanned and the first boolean flag is active, record the position of the Toast message function field and extract the parameters corresponding to the Toast message function field.
[0049] Step 104: When the function end marker of the target function is detected, reset the first Boolean flag;
[0050] Step 105: After the code file scan is complete, output the Toast message call detection results of the code file.
[0051] The function definition information refers to the syntactic features used to identify the function structure. This can be achieved by parsing the `function` keyword, arrow function symbols, or class method declarations in the code, and its purpose is to accurately define the starting position of the function body. The first Boolean flag is a state variable used to mark whether the current scan position is within the function scope; it can be named "infunction" and can be a Boolean variable storing the true or false state. The activation and reset of this flag strictly correspond to the start and end positions of the function body. The Toast message function field refers to the method identifier that calls the Toast function, specifically represented by fixed syntax structures such as `.showToast()`. Its identification relies on predefined regular expression matching rules. The function end marker is a syntactic symbol that marks the end of the function body, such as a closing curly brace `}` or a specific code indentation format, used to trigger the reset operation of the first Boolean flag.
[0052] Specifically, this method first iterates through each line of code in the file. When a function definition statement is detected, a first boolean flag is activated, indicating that subsequent code is within the scope of that function. During the scope scanning phase, the system continuously monitors for calls to Toast message function fields, and parameter extraction is only performed when the first boolean flag is active. For example, when `function saveData(){...}` is scanned, the flag is activated. If `.showToast('Save successful')` is detected in a subsequent line of code, the line number of that statement is recorded and the prompt text parameter is extracted. When a function terminator `}` is scanned, the flag is immediately reset to ensure that the detection of subsequent function calls is not affected by preceding functions.
[0053] This solution effectively addresses the mismatch issue in multi-level nested function scenarios by dynamically managing function scope states. Furthermore, it accurately associates calling statements with their respective function bodies. Through this technical approach, precise location of Toast message calls in nested function scenarios is achieved, avoiding false positives or false negatives caused by scope confusion. This method can accurately identify message prompt statements within each function body and correctly extract the corresponding text parameters, providing a reliable basis for code review.
[0054] Based on the above basic embodiments, this application further proposes to activate a preset second Boolean flag when the Toast message function field is scanned, wherein the second Boolean flag is used to indicate that the target function has called the Toast message function; when both the first Boolean flag and the second Boolean flag are active, the position of the Toast message function field is recorded and the parameters corresponding to the Toast message function field are extracted.
[0055] The second Boolean flag is a status marker used to dynamically track whether a Toast message function call exists within the target function. It can be implemented using a Boolean variable, named `isShowToast`, which is initially inactive and is activated when a Toast message function field is detected. The activation state is a logical condition triggered by the recognition of specific syntactic structures during code scanning. This can be achieved by matching function call identifiers such as ".showToast" using regular expressions. When this field is matched, the state of the second Boolean flag changes.
[0056] Specifically, during code file scanning, when a function definition boundary is detected, a first boolean flag is activated to mark the current state as being within the target function's scope. Within this scope, if a Toast message function field is further scanned, a second boolean flag is simultaneously activated, forming a dual-state verification mechanism. The Toast message function's location recording and parameter extraction operations are performed only when both boolean flags are active simultaneously. For example, in multi-level nested function scenarios, this method leverages the local scope characteristic of the second boolean flag to ensure that only Toast calls within the current target function are detected, avoiding misjudgments caused by residual state from outer functions. After parameter extraction is complete, the second boolean flag is immediately reset to release state occupation.
[0057] This solution constructs a dual verification mechanism for scope and function call through the synergistic effect of dual state flags. When a Toast call is detected, it forces verification to confirm whether the current function scope is valid, thereby eliminating the risk of false detection across scopes. Through the above technical solution, the problem of false judgment in Toast message call detection in nested function scenarios can be solved, ensuring that parameter extraction operations are triggered only in the correct function scope, avoiding detection result deviations caused by scope boundary confusion, and improving the accuracy and reliability of static code analysis.
[0058] Based on the previous embodiment, this application further proposes resetting the second Boolean flag after extracting the parameters corresponding to the Toast message function field.
[0059] The second Boolean flag is activated when a Toast message function field is detected, working in conjunction with the first Boolean flag to confirm that the current scope is correct. Resetting the second Boolean flag means restoring it to its initial state after parameter extraction is complete, to prevent subsequent code within the same function or other code in nested functions from being incorrectly associated.
[0060] Specifically, when a Toast message function field is detected during code scanning, a second boolean flag is activated to indicate a valid call. After parameter extraction is complete, the second boolean flag is immediately reset to an inactive state by identifying the end of the field or the statement termination symbol (such as a semicolon or closing brackets of a code block). This operation ensures that subsequent scans of other code within the function scope will not lead to misjudgments due to the residual state of the second boolean flag. For example, in multi-level nested functions, failure to reset this flag in a timely manner may cause subsequent code in the outer function to be incorrectly identified as containing a Toast call, leading to confusion in parameter extraction.
[0061] This solution effectively isolates the detection states between different functions or code blocks by introducing independent control and precise reset of a second Boolean flag, avoiding cross-scope interference. Through this technical solution, the detection scope of Toast message function calls can be precisely limited, preventing false detections or parameter extraction errors caused by residual flag states. It is particularly suitable for code scenarios containing nested functions, conditional branches, or loop structures, significantly improving the reliability and accuracy of detection results.
[0062] This application further proposes to scan the scope of the target function for Toast message function fields, including matching Toast message function fields within the scope of the target function using regular expressions.
[0063] The regular expression refers to a pattern used to match character combinations in a string. It can be implemented using predefined syntax rules, such as constructing a pattern string containing a specific method name and parameter structure. This feature is used to quickly locate Toast message functions that match a specific call format in the code text, avoiding the inefficiency of manual line-by-line checking. The Toast message function field refers to the method call statement that triggers the UI prompt function. This can be implemented using code snippets containing fixed method names, such as function calls ending with ".showToast". This feature is used to accurately identify the code location that actually performs the Toast display operation, avoiding misjudging non-functional code or comments as valid calls.
[0064] Specifically, during the detection process, once the target function's scope is entered, the system will initiate a regular expression matching mechanism for each line of code within that scope. For example, when processing JavaScript code, a regular expression pattern such as " / .showToast\s*( / )" can be pre-set, which can precisely match lines of code containing the .showToast() call. By limiting the matching scope to the function scope marked by the activated boolean flag, interference from methods with the same name in other scopes is effectively eliminated, such as excluding commented-out code segments or text content in string constants.
[0065] This solution restricts regular expression matching operations to the confirmed function scope, thus preserving the efficient matching characteristics of regular expressions while significantly reducing the false detection rate through the scope isolation mechanism. Through the above technical solution, the Toast call position in nested function structures can be accurately identified, solving the problem of detection failure caused by scope confusion in traditional static analysis tools in complex code logic scenarios, while avoiding misjudgments caused by global regular expression matching.
[0066] Furthermore, this application also proposes that after obtaining the code file to be detected, the code file is filtered when the file extension of the code file matches the file extension filtering information according to preset file extension filtering information.
[0067] The file extension filtering information refers to a pre-defined set of file extension matching rules, which can be stored as a list of strings, such as lists containing ".js" and ".jsx", to quickly identify the type of code files that need to be processed. Filtering code files means skipping the scanning process for files that do not meet the extension criteria. This can be achieved by checking whether the file extension exists in the filter list when traversing the file system, thus avoiding invalid scanning of non-target files.
[0068] Specifically, during the code file acquisition phase, when the system traverses all files in the specified directory, it extracts the file extensions one by one and compares them with a preset filter list. For example, if the filter list contains ".js", all files with the extensions ".jsx" or ".ts" will be automatically excluded. For files that match successfully, the system only retains their path information and does not perform subsequent scanning operations, thereby reducing the total number of files that need to be processed. This process can be combined with a recursive directory traversal mechanism to initiate the detection process only for files that meet the extension requirements in a multi-level folder structure.
[0069] This solution effectively excludes file types irrelevant to the detection target through a suffix matching mechanism, avoiding resource waste. Furthermore, this technical approach significantly reduces the resource consumption of static code analysis and minimizes computational overhead from processing non-target files. Simultaneously, this mechanism prevents the misidentification of non-code file content as function definitions, thereby improving the accuracy of detection results. This is particularly beneficial when handling large projects containing mixed file types, enabling rapid focus on the actual code files requiring detection.
[0070] The above is a detailed description of an embodiment of a Toast message invocation detection method provided by this application. The following is a detailed description of an embodiment of a Toast message invocation detection device provided by this application:
[0071] Please see Figure 3This application provides a Toast message invocation detection device, comprising:
[0072] Code file acquisition unit 201 is used to acquire the code file to be detected;
[0073] The function scanning unit 202 is used to scan the code file according to the function definition information in the code file. When any target function is scanned, a preset first Boolean flag is activated, wherein the first Boolean flag is used to indicate that the current scanning position has entered the scope of the target function.
[0074] Toast message scanning unit 203 is used to scan the scope of the target function for Toast message function fields. When a Toast message function field is scanned and the first Boolean flag is active, the position of the Toast message function field is recorded and the parameters corresponding to the Toast message function field are extracted.
[0075] The first flag reset unit 204 is used to reset the first Boolean flag when the function end identifier of the target function is scanned;
[0076] The detection result output unit 205 is used to output a Toast message to the code file to call the detection result after the code file scan is completed.
[0077] Furthermore, the Toast message scanning unit is specifically used for:
[0078] Scan the scope of the objective function for the Toast message function field. When the Toast message function field is scanned and the first boolean flag is active, record the position of the Toast message function field and extract the parameters corresponding to the Toast message function field.
[0079] Furthermore, the apparatus provided in this embodiment may further include:
[0080] The second flag reset unit 2040 is used to reset the second boolean flag after the parameters corresponding to the Toast message function field have been extracted.
[0081] In addition, this application also provides a detailed description of an embodiment of a Toast message invocation detection terminal and a computer-readable storage medium.
[0082] Please see Figure 4 The present application provides a Toast message call detection terminal, which includes a memory 33 and a processor 31, and the memory 33 and the processor 31 can be connected through a communication bus 34.
[0083] The memory 33 is used to store program code, which is used to implement a Toast message call detection method as provided in the above embodiment;
[0084] Processor 31 is used to read and execute program code.
[0085] The types of terminals mentioned in this embodiment include, but are not limited to, personal computers, servers, and embedded electronic devices.
[0086] Among them, memory 33 refers to the hardware module used for persistent storage of program code. Specifically, it can be implemented using ROM, flash memory or solid-state drive. Its function is to provide a stable storage medium for the detection logic and ensure the complete preservation of code parsing rules and flag state management strategies.
[0087] Among them, processor 31 refers to the arithmetic control unit that executes program instructions. Specifically, it can be implemented using a multi-core CPU, microcontroller, or application-specific integrated circuit. Its function is to achieve coordinated control of function scope boundary recognition and Toast message call detection by parsing the code file line by line, dynamically switching the Boolean flag state, and performing regular expression matching operations.
[0088] Specifically, the program code stored in memory includes a function definition identification module, a scope marking module, and a message field scanning module. During runtime, the processor first traverses the code file directory, filtering non-target files based on preset suffixes. Next, it identifies function start symbols using regular expressions, activating the first Boolean flag to mark entry into the function scope. Then, it scans line by line within the scope. When a Toast message function field is detected, after confirming the first Boolean flag is active, it triggers parameter extraction and records the code position. When a function end symbol is encountered, the processor automatically resets the first Boolean flag to prepare for the next function scan. For nested function scenarios, the processor uses a stack-based management of scope markings to ensure that multi-level function boundary identification is not confused.
[0089] Through the above technical solution, this application can accurately identify the location of Toast message calls within nested functions, avoiding false detections across scopes. Simultaneously, through the coordinated operation of the processor and memory, it achieves stable parsing of dynamic code logic, improving the reliability of the detection results. For code files containing multi-level callback functions or closure structures, the terminal can completely record the message call parameters within each scope, ensuring consistency between the detection report and the actual execution logic of the code.
[0090] This application provides a computer-readable storage medium containing program code, which is read and executed by a processor to implement a Toast message call detection method as provided in the above embodiments.
[0091] Computer-readable storage media refers to physical carriers that can persistently store program code. Specifically, they can be solid-state drives, hard disk drives, or flash memory chips. Their function is to provide repeatedly readable code storage space for the execution of detection methods.
[0092] Among them, program code refers to a set of instructions written according to preset logic. Specifically, it can be implemented using JavaScript, Python, or Java. Its function is to parse and execute instructions through the processor to complete the scanning of code files, flag control, and output of detection results.
[0093] The processor refers to the computing unit that can execute program code. Specifically, it can be implemented using a central processing unit or a graphics processing unit. Its function is to automate the Toast message call detection process by reading program code line by line and executing the corresponding operations.
[0094] Specifically, after the program code is read by the processor, it first obtains the code file to be detected, and then scans it based on the function definition information. When a target function is detected, a first boolean flag is activated to mark entry into the function scope; within the scope, the scanning of Toast message function fields continues. If the field is detected simultaneously and the first boolean flag is active, the field position is recorded and the parameters are extracted; when the function end marker is detected, the first boolean flag is reset. After the code file scan is complete, the detection results are output. This scheme controls the state switching of the boolean flag through program code, ensuring accurate identification of Toast message calls in multi-level nested functions and avoiding detection failures caused by scope confusion.
[0095] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the terminals, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.
[0096] In the several embodiments provided in this application, it should be understood that the disclosed terminals, devices, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.
[0097] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the application described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0098] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.
[0099] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0100] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.
[0101] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0102] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application 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 of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.
Claims
1. A method for detecting Toast message invocation, characterized in that, include: Obtain the code file to be tested; The code file is scanned based on the function definition information in the code file. When any target function is scanned, a preset first Boolean flag is activated, wherein the first Boolean flag is used to indicate that the current scan position has entered the scope of the target function. The scope of the target function is scanned for Toast message function fields. When a Toast message function field is scanned and the first boolean flag is active, the position of the Toast message function field is recorded and the parameters corresponding to the Toast message function field are extracted. When the function end marker of the target function is detected, the first Boolean flag is reset; After the code file scan is complete, the Toast message call detection result of the code file is output.
2. The Toast message invocation detection method according to claim 1, characterized in that, When a Toast message function field is detected and the first boolean flag is active, recording the position of the Toast message function field and extracting the parameters corresponding to the Toast message function field includes: When the Toast message function field is scanned, a preset second Boolean flag is activated, which is used to indicate that the target function has been detected to call the Toast message function; When both the first Boolean flag and the second Boolean flag are active, record the position of the Toast message function field and extract the parameters corresponding to the Toast message function field.
3. The Toast message invocation detection method according to claim 2, characterized in that, After extracting the parameters corresponding to the Toast message function fields, the following are included: Once the parameters corresponding to the Toast message function field have been extracted, the second Boolean flag is reset.
4. The Toast message invocation detection method according to claim 1, characterized in that, The step of scanning the scope of the target function for Toast message function fields includes: The Toast message function field within the scope of the target function is matched using regular expressions.
5. The Toast message invocation detection method according to claim 1, characterized in that, After obtaining the code file to be detected, the following is also included: Based on preset file extension filtering information, when the file extension of the code file matches the file extension filtering information, the code file is filtered.
6. A Toast message invocation detection device, characterized in that, include: The code file acquisition unit is used to acquire the code file to be inspected. The function scanning unit is used to scan the code file according to the function definition information in the code file. When any target function is scanned, a preset first Boolean flag is activated, wherein the first Boolean flag is used to indicate that the current scanning position has entered the scope of the target function. The Toast message scanning unit is used to scan the scope of the target function for Toast message function fields. When a Toast message function field is scanned and the first Boolean flag is active, the position of the Toast message function field is recorded and the parameters corresponding to the Toast message function field are extracted. The first flag reset unit is used to reset the first Boolean flag when the function end identifier of the target function is detected. The detection result output unit is used to output the detection result of the code file by calling a Toast message after the code file scan is completed.
7. A Toast message invocation detection device according to claim 6, characterized in that, The Toast message scanning unit is specifically used for: The scope of the target function is scanned for Toast message function fields. When a Toast message function field is scanned and the first Boolean flag is active, the position of the Toast message function field is recorded, and the parameters corresponding to the Toast message function field are extracted.
8. A Toast message invocation detection device according to claim 7, characterized in that, Also includes: The second flag reset unit is used to reset the second boolean flag after the parameters corresponding to the Toast message function field have been extracted.
9. A Toast message invocation detection terminal, characterized in that, include: Memory and processor; The memory is used to store program code, which is used to implement a Toast message call detection method as described in any one of claims 1 to 5; The processor is used to read and execute the program code.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium contains program code that is read and executed by a processor to implement a Toast message call detection method as described in any one of claims 1 to 5.