Data processing method and device, terminal equipment and computer readable storage medium
By combining plugin identifiers and context function encapsulation classes, the problem of plugin data isolation in Android pluginization projects is solved, ensuring independent access and security of plugin data.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SHENZHEN TCL NEW-TECH CO LTD
- Filing Date
- 2026-01-14
- Publication Date
- 2026-05-12
AI Technical Summary
In Android plugin-based projects, plugins share the same running process and data storage space, lacking an effective isolation mechanism, which leads to the risk of plugins deleting other files in the same directory.
The target access path is determined by the plugin identifier, and the context function encapsulation class is used to realize independent access to plugin data, ensuring the isolation of plugin data from other plugins and host application data.
Independent access to plugin data has been achieved, avoiding mutual data interference and out-of-bounds access, thus improving the security and stability of plugin data operations.
Smart Images
Figure CN122019014A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of software engineering technology, specifically to a data processing method, apparatus, terminal device, and computer-readable storage medium. Background Technology
[0002] With the rapid development of the Android system, plug-in architecture has become the mainstream trend in the development of large-scale mobile applications. Plug-in technology can effectively support the dynamic loading and upgrading of application components, improving development and maintenance efficiency. In current Android plug-in projects, plug-ins typically perform local data operations such as file creation and database storage. However, in actual projects, plug-ins often share the same running process and data storage space, and the storage directories (such as cache, files, database, etc.) lack effective isolation mechanisms. This can lead to the risk of a plug-in deleting other files in the same directory. Summary of the Invention
[0003] This application provides a data processing method, apparatus, terminal device, and computer-readable storage medium that can find the independent access path of each plugin based on the plugin name, distinguish the data of different plugins, and ensure that modifying the data of a plugin will not affect the data of other plugins or the data of the host application, thereby achieving data isolation of each plugin.
[0004] The technical solution adopted by this invention to solve the problem is as follows: On the one hand, this application provides a data processing method, including: Receive plugin data access requests for the target plugin; In response to a plugin data access request, determine the target access path marked with the plugin identifier of the target plugin; Access the plugin data of the target plugin based on the target access path.
[0005] In some embodiments of this application, in response to a plugin data access request, a target access path marked with a plugin identifier is determined, including: Determine the plugin identifier corresponding to the plugin data access request; Based on the plugin identifier, determine the target context function encapsulation class corresponding to the target plugin; The target access path is determined by encapsulating the target context functionality in the class.
[0006] In some implementation schemes of this application, the target context function encapsulation class corresponding to the target plugin is determined based on the plugin identifier, including: Check if a context function wrapper class that matches the plugin identifier exists; If a context function wrapper class that matches the plugin identifier exists, the context function wrapper class that matches the plugin identifier will be identified as the target context function wrapper class. If no context function wrapper class matches the plugin identifier, a new context function wrapper class is created and bound to the plugin identifier to obtain the target context function wrapper class.
[0007] In some implementations of this application, the target access path is determined through a target context function encapsulation class, including: Determine the data access method corresponding to the plugin data access request based on the data access type of the plugin data access request. The target access path is obtained by calling the data access method through the target context function encapsulation class.
[0008] In some implementations of this application, the target access path is obtained by calling the data access method through the target context function encapsulation class, including: By calling the data access method through the target context function encapsulation class, the plugin identifier is inserted into the original access path to obtain the target access path. The target access path is isolated from the path that stores plugin data of other plugins.
[0009] In some embodiments of this application, before receiving a plugin data access request for the target plugin, the following is included: Write the plugin identifier into the target plugin's base file so that the plugin identifier in the base file can be automatically read and inserted into the currently called method.
[0010] In some embodiments of this application, before receiving a plugin data access request for the target plugin, the following is also included: Detect whether there is any abnormal code in the running code of the target plugin. The abnormal code includes at least one of the following: code used to obtain data from the application's global path, and code used to obtain plugin data through means other than the context utility class. If there is abnormal code in the target plugin's runtime code, an exception message will be generated. The exception message is used to indicate that there is unisolated data in the target plugin's data.
[0011] Secondly, embodiments of the present invention also provide a data processing apparatus, comprising: The receiving module is used to receive plugin data access requests for the target plugin; The determination module is used to determine the target access path marked with the plugin identifier in response to the plugin data access request; The access module is used to access the plugin data of the target plugin based on the target access path.
[0012] Thirdly, this application also provides a terminal device, which includes: One or more processors; Memory; and One or more applications, wherein the applications are stored in memory and configured to be executed by a processor to implement the data processing method of any of the first aspects.
[0013] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, the computer program being loaded by a processor to perform the steps of the data processing method of any of the first aspects.
[0014] The beneficial effects of this invention are as follows: After receiving a plugin data access request for a target plugin, the target access path marked with the plugin identifier of the target plugin is first determined, and then the plugin data of the target plugin is accessed based on the target plugin's own target access path. The independent access path of each plugin can be found based on the plugin name, which can distinguish the data of different plugins. When the plugin data is modified, it will not affect the data of other plugins or the data of the host application, thus achieving data isolation of each plugin. Attached Figure Description
[0015] To more clearly illustrate the technical solutions in the embodiments of the present invention 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 recorded in the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0016] Figure 1 This is a schematic diagram of a data processing system provided in an embodiment of the present invention; Figure 2 This is a flowchart illustrating one embodiment of the data processing method provided in this invention. Figure 3 This is a schematic diagram of the software architecture provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the Lint detection process provided in an embodiment of the present invention; Figure 5 This is a schematic block diagram of the data processing device provided in the embodiments of the present invention; Figure 6 This is a schematic diagram of an embodiment of the terminal device provided in this invention. Detailed Implementation
[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0018] In the description of this application, the terms "first," "second," "third," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with "first," "second," "third," etc., may explicitly or implicitly include one or more of the stated features.
[0019] In this application, the term "exemplary" is used to mean "used as an example, illustration, or description." Any embodiment described as "exemplary" in this application is not necessarily to be construed as being more preferred or advantageous than other embodiments. The following description is provided to enable any person skilled in the art to make and use this application. Details are set forth in the following description for purposes of explanation. It should be understood that those skilled in the art will recognize that this application can be made without using these specific details. In other instances, well-known structures and processes are not described in detail to avoid obscuring the description of this application with unnecessary detail. Therefore, this application is not intended to be limited to the embodiments shown, but is consistent with the broadest scope of the principles and features disclosed in this application.
[0020] It should be noted that since the method in this application embodiment is executed in a terminal device, the processing objects of each terminal device exist in the form of data or information, such as time, which is essentially time information. It can be understood that if size, quantity, position, etc. are mentioned in subsequent embodiments, they are all corresponding data that exist so that the terminal device can process them. Specific details will not be elaborated here.
[0021] This application provides a data processing method, apparatus, terminal device, and computer-readable storage medium, which will be described in detail below.
[0022] Please see Figure 1 , Figure 1 This is a schematic diagram of a data processing system provided in an embodiment of this application. The data processing system may include a terminal device 100, which integrates a data processing unit, such as... Figure 1 Terminal devices in the process.
[0023] In this embodiment, the terminal device 100 is mainly used to receive plugin data access requests for a target plugin; in response to the plugin data access request, determine the target access path marked with the plugin identifier of the target plugin; and access the plugin data of the target plugin based on the target access path. It can find the independent access path of each plugin based on the plugin name, distinguish the data of different plugins, and when the plugin data is modified, it will not affect the data of other plugins or the data of the host application, thereby achieving data isolation of each plugin.
[0024] In this embodiment, the terminal device 100 can be an independent server, a server network, or a server cluster. For example, the terminal device 100 described in this embodiment includes, but is not limited to, a computer, a network host, a single network server, a set of multiple network servers, or a cloud server composed of multiple servers. The cloud server is composed of a large number of computers or network servers based on cloud computing.
[0025] It is understood that the terminal device 100 used in the embodiments of this application can be a device that includes both receiving and transmitting hardware, that is, a device having receiving and transmitting hardware capable of performing bidirectional communication on a bidirectional communication link. Such a device may include: cellular or other communication devices having a single-line display, a multi-line display, or a cellular or other communication device without a multi-line display. Specifically, the terminal device 100 may be a desktop terminal or a mobile terminal, and the terminal device 100 may also be one of a mobile phone, tablet computer, laptop computer, etc.
[0026] Those skilled in the art will understand that Figure 1 The application environment shown is merely one application scenario of the solution in this application and does not constitute a limitation on the application scenario of the solution in this application. Other application environments may include those that are more specific to this application. Figure 1 The number of more or fewer terminal devices shown, for example Figure 1 Only one terminal device is shown in the diagram. It is understood that the data processing system may also include one or more other services, which are not specified here.
[0027] In addition, such as Figure 1 As shown, the data processing system may also include a memory 200 for storing data, such as plug-in identifiers and plug-in data.
[0028] It should be noted that, Figure 1The schematic diagram of the data processing system shown is merely an example. The data processing system and scenario described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of data processing systems and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.
[0029] First, this application provides a data processing method, the execution subject of which is a data processing device, which is applied to a terminal device. The data processing method includes: receiving a plugin data access request for a target plugin; responding to the plugin data access request, determining a target access path marked with a plugin identifier of the target plugin; and accessing the plugin data of the target plugin based on the target access path.
[0030] like Figure 2 The diagram shown is a flowchart of an embodiment of the data processing method in this application. The data processing method may include the following steps S201 to S203, as detailed below: Step S201: Receive a plugin data access request for the target plugin.
[0031] The execution entity in this step can be either application software on the terminal device or a general context utility class called ContextUtils within the application software. Application software is an independent software program that provides specific functions or services to the user, while plugins are modular components that depend on the host program to run, extending functionality by conforming to the interface specifications defined by the host program. ContextUtils is a utility class in the Android framework used to manage object context information, providing support to the application during its runtime. ContextUtils can also be called by plugins, enabling them to obtain plugin data based on the data processing methods provided in this application and provide it to the plugin.
[0032] In this embodiment, the target plugin can be any plugin within the host application, and the plugin data access request can be a request to access the plugin data of the target plugin. The object initiating the plugin data access request can be the plugin itself; that is, when a plugin needs to operate on its own data, it can call ContextUtils to retrieve its own data from its independent path. Alternatively, the host application can also initiate the plugin data access request. For example, the host application can call ContextUtils to retrieve plugin data from the plugin's independent path based on management or data sharing needs. Furthermore, users or other plugins can also initiate plugin data access requests and retrieve plugin data by calling ContextUtils. In other words, regardless of who initiates the plugin data access request, as long as plugin data of a certain plugin needs to be retrieved, it can be achieved by calling ContextUtils.
[0033] Step S202: In response to the plugin data access request, determine the target access path marked with the plugin identifier of the target plugin.
[0034] In this embodiment, the target access path is a path marked with a plugin identifier that can locate the plugin data storage location. The plugin identifier is a unique identity marker for each plugin, used to uniquely identify the plugin in the application.
[0035] In one specific embodiment, when ContextUtils receives a plugin data access request, it locates the storage location of the target plugin's plugin data based on the target plugin's plugin identifier, i.e., it finds the target access path. It should be noted that this access path is marked with the target plugin's plugin identifier and is a dedicated storage path corresponding to the target plugin. This path only stores the target plugin's plugin data; the data of other plugins are stored in separate paths distinguished by their own plugin identifiers, thereby achieving complete isolation between plugin data at the physical level.
[0036] Step S203: Access the plugin data of the target plugin based on the target access path.
[0037] In one specific embodiment, plugin data stored in the target access path can be directly accessed and manipulated based on that path.
[0038] It should be noted that the method provided in this application is not only applicable to triggering execution when a data access request for the target plugin is received, but can also be enabled when a data processing request involving the target plugin (including but not limited to data modification and data deletion) is received; regardless of the type of request, the method determines the target access path marked with the plugin identifier of the target plugin, locates and operates the isolated data that belongs only to the plugin, thereby ensuring that subsequent data access or processing is accurately completed within its exclusive data space.
[0039] Using the data processing method provided in this application, when accessing the data of a specific plugin, a path marked with the plugin's identifier is first determined. The storage address pointed to by this path belongs exclusively to that plugin and is isolated from other plugins. Therefore, the relevant data of the plugin can be found at the storage address pointed to by this path, and operations such as modification and deletion of the data can be performed without worrying about affecting the data of the host application or other plugins.
[0040] In one specific embodiment, in response to a plugin data access request, determining the target access path marked with a plugin identifier of the target plugin includes: determining the plugin identifier corresponding to the plugin data access request; determining the target context function encapsulation class corresponding to the target plugin based on the plugin identifier; and determining the target access path through the target context function encapsulation class.
[0041] In this embodiment, the context function encapsulation class is a ContextWrapper derived object implemented on the host application side, which rewrites the functionality and isolates the path of the system's native Context. It is used to generate exclusive files, caches, and database access environments that belong only to the plugin based on the plugin identifier.
[0042] In actual execution, when ContextUtils is called to fulfill a data access or data processing request (such as reading, writing, modifying, or deleting local files and database data) from a target plugin, it first parses which plugin the request originates from, thereby obtaining the corresponding plugin identifier. Subsequently, ContextUtils can find or construct a target context function wrapper class instance bound to the target plugin based on the plugin identifier. This target context function wrapper class has automatically appended the plugin identifier to the data directory by overriding path-related interfaces, ensuring that all data reads and writes are forcibly restricted to a private path named after the plugin identifier. Therefore, the target access path can be determined through the target context function wrapper class, ultimately ensuring that data operations only occur in the plugin's dedicated directory, preventing accidental or unauthorized access to other plugins' data.
[0043] In one specific embodiment, determining the target context function encapsulation class corresponding to the target plugin based on the plugin identifier includes: detecting whether there is a context function encapsulation class that matches the plugin identifier; if there is a context function encapsulation class that matches the plugin identifier, determining the context function encapsulation class that matches the plugin identifier as the target context function encapsulation class; if there is no context function encapsulation class that matches the plugin identifier, creating a new context function encapsulation class, and binding the new context function encapsulation class to the plugin identifier to obtain the target context function encapsulation class.
[0044] In this embodiment, the system first determines whether a context function wrapper class instance bound to the plugin identifier already exists based on the plugin identifier. Here, "matching" means that the wrapper class is an isolated ContextWrapper previously created and cached for the same plugin, containing the plugin's identifier information and corresponding to the plugin's dedicated storage directory. If the instance already exists, it is directly returned as the target context function wrapper class, ensuring that the same plugin receives a completely consistent isolated data environment when called by different modules at different times, thus ensuring stable and reusable path mapping.
[0045] If a wrapper class corresponding to the plugin identifier does not yet exist, a new context-based wrapper class instance can be created. The new instance is built based on the host's native application context and writes the plugin identifier internally during initialization, automatically generating isolated directories with that plugin identifier in all path-related methods. Subsequently, the newly created wrapper class can be bound to the plugin identifier and cached so that all subsequent accesses to the plugin still use the same object.
[0046] In one specific embodiment, determining the target access path through the target context function encapsulation class includes: determining the data access method corresponding to the plugin data access request based on the data access type corresponding to the plugin data access request; and obtaining the target access path by calling the data access method through the target context function encapsulation class.
[0047] In this embodiment, the data access type refers to the data category of the plugin's requested operation, such as reading from the cache, accessing a private file directory, writing to an external storage directory, or opening a database file. The corresponding data access methods are specific path retrieval interfaces in ContextWrapper, such as getCacheDir(), getFilesDir(), getExternalFilesDir(), and getDatabasePath(). Each method returns a local storage path for a specific category. Specifically, getCacheDir() retrieves the path to the local cache folder, getFilesDir() retrieves the path to the private file storage folder, getExternalFilesDir() retrieves the path to the external storage file directory, and getDatabasePath() retrieves the path to the database file.
[0048] After determining the context function wrapper class corresponding to the target plugin, the system further parses the plugin's request to determine the type of data the request seeks to manipulate. For example, if the request is to read or write a cached file, the corresponding data access type is local cache file, and the system will identify `getCacheDir()` as the corresponding data access method; if the request is to access the plugin's private file, the data access type is private file storage, and the corresponding method is `getFilesDir()`; if external storage is involved, `getExternalFilesDir()` is called; if a database file is to be accessed, `getDatabasePath()` is called. Based on the mapping relationship between data types and methods, the correct method is selected and called through the target context function wrapper class. Because the target context function wrapper class has internally overridden the relevant methods and automatically appended the plugin identifier, the path returned by each method call naturally corresponds to the plugin's dedicated isolated directory.
[0049] In one specific embodiment, obtaining the target access path by calling the data access method through the target context function encapsulation class includes: inserting the plugin identifier into the original access path by calling the data access method through the target context function encapsulation class to obtain the target access path, wherein the target access path is isolated from the path where plugin data of other plugins is stored.
[0050] In this embodiment, the original access path refers to the storage path generated by the Android system by default when no plugin isolation is performed, such as the general cache directory returned by getCacheDir() or the private file directory returned by getFilesDir(). Inserting the plugin identifier into the original access path means that when the context function wrapper class overrides these methods, it will add the plugin name (i.e., pluginA) as an additional directory level to the system's default path, i.e., the original access path, to generate the target access path. For example, it expands the system's / data / data / host / cache / to / data / data / host / cache / pluginA / . This path expansion logic is automatically handled internally by the target context function wrapper class, requiring no intervention from the plugin developer.
[0051] The path generated after calling the data access method through the target context function wrapper class is the target access path of the target plugin. This path is inherently unique and isolated because it contains the plugin identifier, completely distinguishing it from the data paths of other plugins. In other words, even if different plugins call the same method, due to the difference in the context wrapper class, their returned paths will never overlap, fundamentally eliminating the risk of data out-of-bounds errors, misuse, or mutual overwriting.
[0052] In one specific embodiment, before receiving a plugin data access request for the target plugin, the method includes: writing the plugin identifier into the base file of the target plugin, so as to automatically read the plugin identifier in the base file and insert it into the currently called method.
[0053] In this embodiment, the base file is a configuration class file automatically generated during the plugin build phase of the compilation process, such as BuildConfig.java. This file is a standard artifact in the compilation process and is used to store compile-time constants. Writing the plugin identifier into the base file means that during the plugin build process, the unique name of the current plugin is automatically written into BuildConfig.java as a constant, so that it can be quickly and accurately read by the system at runtime and used as the basis for subsequent isolation logic. Through this compile-time writing method, plugin developers do not need to manually specify or maintain their own plugin names, and the stability of the isolation logic will not be affected by configuration omissions or errors.
[0054] When a plugin calls ContextUtils to obtain the isolation context during runtime, it can automatically read the plugin identifier from the base file and dynamically insert the identifier into the currently called method, thereby generating a unique access path for that plugin. Plugin developers do not need to pass the plugin name in the code, nor do they need to understand the internal structure of the isolation logic; all path identification processing is handled automatically by the system.
[0055] In one specific embodiment, before receiving a plugin data access request for the target plugin, the method further includes: detecting whether there is abnormal code in the runtime code of the target plugin, wherein the abnormal code includes at least one of the following: code for obtaining data from the application's global path, and code for obtaining plugin data through a means other than a context utility class; if there is abnormal code in the runtime code of the target plugin, generating an exception message, wherein the exception message is used to indicate that there is unisolated data in the data of the target plugin.
[0056] In this embodiment, all code of the target plugin and / or the host application can be inspected at compile time to ensure that the plugin's data access behavior is completely controlled by the unified entry point of the isolation system (i.e., obtaining the plugin's data by calling ContextUtils), and will not bypass the context utility class (i.e., ContextUtils) or the isolation context function wrapper class (i.e., ContextWrapper) to directly access the host application's global directory. Abnormal code refers to code patterns that may cause the plugin to access non-isolated paths, cross plugin boundaries, or directly operate the system's global directory. Examples include directly using native File, Paths, or Context.getFilesDir() methods to access the host application's default paths, or attempting to obtain the original Context without going through ContextUtils before performing storage operations. If such abnormal behavior is not constrained, it will compromise the integrity of the entire plugin data isolation system; therefore, it needs to be detected in advance through static analysis or Lint detection.
[0057] In practice, the Lint tool can be used to scan and analyze the target plugin's runtime code, identifying the presence of the aforementioned abnormal code through custom Lint rules. If the plugin is detected attempting to retrieve data from the application's global path or trying to bypass the context utility class to directly access the storage path, the Lint tool will generate an "exception warning," pointing out to developers that the plugin contains access logic that violates the isolation specification. It will explicitly state that this data is not protected by the plugin's path isolation mechanism and is considered "unisolated data," potentially leading to data privilege escalation, data corruption, or security vulnerabilities. This proactive exception warning mechanism allows developers to correct problems during the compilation or development phase, without waiting for actual data access conflicts to occur at runtime.
[0058] In a specific implementation, such as Figure 3As shown, the host application can provide the ContextUtils utility class to multiple plugins, enabling each plugin to access plugin data isolated from other plugins. It also allows the Lint detection tool to perform code checks on plugins at compile time. Plugins can obtain their own plugin data through ContextUtils. ContextUtils locates the corresponding target context function wrapper class ContextWrapper by parsing the plugin identifier in the request. ContextWrapper automatically inserts the plugin identifier when returning the path by overriding data path retrieval methods (such as getCacheDir and getFilesDir), thus ensuring that each plugin's data is stored in physically isolated directories and avoiding data cross-contamination. Figure 4 As shown, the Lint inspection tool can inspect code during the plugin development coding phase. By integrating with the development environment (such as IDE / Gradle), it identifies abnormal code that attempts to access data through the application's global path or bypasses context utility classes for storage operations. Once such non-compliant behavior is detected, the Lint inspection tool generates an exception message to remind developers of unisolated data operations in the plugin, thus ensuring the standardization of data access behavior at the source. After the code is uploaded to continuous integration / code repository, the Lint inspection tool performs automatic checks again and generates an inspection report, forming a dual quality assurance mechanism during the coding and integration phases. Therefore, by combining context isolation technology with the automated Lint inspection process, both data security isolation between plugins and code standardization and stability are achieved, effectively improving the reliability and development efficiency of the plugin architecture.
[0059] To better implement the data processing method in the embodiments of this application, based on the data processing method, the embodiments of this application also provide a data processing apparatus, such as... Figure 5 As shown, the data processing apparatus 500 includes: The receiving module 510 is used to receive plugin data access requests for the target plugin; The determination module 520 is used to determine the target access path marked with the plugin identifier in response to the plugin data access request; Access module 530 is used to access the plugin data of the target plugin based on the target access path.
[0060] In this embodiment of the application, after receiving a plugin data access request for a target plugin, the target access path marked with the plugin identifier of the target plugin is first determined, and then the plugin data of the target plugin is accessed based on the target plugin's own target access path. The independent access path of each plugin can be found based on the plugin name, which can distinguish the data of different plugins. When the plugin data is modified, it will not affect the data of other plugins or the data of the host application, thus achieving data isolation of each plugin.
[0061] In some embodiments of this application, the determining module 520, in response to a plugin data access request, determines a target access path marked with a plugin identifier of the target plugin, including: Determine the plugin identifier corresponding to the plugin data access request; Based on the plugin identifier, determine the target context function encapsulation class corresponding to the target plugin; The target access path is determined by encapsulating the target context functionality in the class.
[0062] In some embodiments of this application, the determining module 520 determines the target context function encapsulation class corresponding to the target plugin based on the plugin identifier, including: Check if a context function wrapper class that matches the plugin identifier exists; If a context function wrapper class that matches the plugin identifier exists, the context function wrapper class that matches the plugin identifier will be identified as the target context function wrapper class. If no context function wrapper class matches the plugin identifier, a new context function wrapper class is created and bound to the plugin identifier to obtain the target context function wrapper class.
[0063] In some embodiments of this application, the determining module 520 determines the target access path through the target context function encapsulation class, including: Determine the data access method corresponding to the plugin data access request based on the data access type of the plugin data access request. The target access path is obtained by calling the data access method through the target context function encapsulation class.
[0064] In some embodiments of this application, the determining module 520 obtains the target access path by calling a data access method through the target context function encapsulation class, including: By calling the data access method through the target context function encapsulation class, the plugin identifier is inserted into the original access path to obtain the target access path. The target access path is isolated from the path that stores plugin data of other plugins.
[0065] In some embodiments of this application, the receiving module 510 includes the following features before receiving a plugin data access request for a target plugin: Write the plugin identifier into the target plugin's base file so that the plugin identifier in the base file can be automatically read and inserted into the currently called method.
[0066] In some embodiments of this application, before receiving a plugin data access request for a target plugin, the receiving module 510 further includes: Detect whether there is any abnormal code in the running code of the target plugin. The abnormal code includes at least one of the following: code used to obtain data from the application's global path, and code used to obtain plugin data through means other than the context utility class. If there is abnormal code in the target plugin's runtime code, an exception message will be generated. The exception message is used to indicate that there is unisolated data in the target plugin's data.
[0067] This application also provides a terminal device that integrates any of the data processing devices provided in this application. The terminal device includes: One or more processors; Memory; and One or more applications, wherein the applications are stored in memory and configured to be executed by a processor from the steps of the data processing method in any of the embodiments described above.
[0068] This application also provides a terminal device that integrates any of the data processing devices provided in this application. For example... Figure 6 As shown, it illustrates a structural schematic diagram of the terminal device involved in the embodiments of this application. Specifically: The terminal device may include components such as a processor 601 with one or more processing cores, a memory 602 with one or more computer-readable storage media, a power supply 603, and an input unit 604. Those skilled in the art will understand that... Figure 6 The terminal device structure shown does not constitute a limitation on the terminal device and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein: The processor 601 is the control center of the terminal device. It connects various parts of the terminal device via various interfaces and lines. By running or executing software programs and / or modules stored in the memory 602, and by calling data stored in the memory 602, it performs various functions and processes data of the terminal device, thereby providing overall monitoring of the terminal device. Optionally, the processor 601 may include one or more processing cores; preferably, the processor 601 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 601.
[0069] The memory 602 can be used to store software programs and modules. The processor 601 executes various functional applications and data processing by running the software programs and modules stored in the memory 602. The memory 602 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the terminal device, etc. In addition, the memory 602 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 602 may also include a memory controller to provide the processor 601 with access to the memory 602.
[0070] The terminal device also includes a power supply 603 that supplies power to the various components. Preferably, the power supply 603 can be logically connected to the processor 601 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 603 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.
[0071] The terminal device may also include an input unit 604, which can be used to receive input digital or character information, and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.
[0072] Although not shown, the terminal device may also include a display unit, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 601 in the terminal device loads the executable files corresponding to the processes of one or more applications into the memory 602 according to the following instructions, and the processor 601 runs the applications stored in the memory 602 to realize various functions, as follows: Receive plugin data access requests for the target plugin; In response to a plugin data access request, determine the target access path marked with the plugin identifier of the target plugin; Access the plugin data of the target plugin based on the target access path.
[0073] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.
[0074] Therefore, embodiments of this application provide a computer-readable storage medium, which may include: read-only memory (ROM), random access memory (RAM), a magnetic disk, or an optical disk, etc. A computer program is stored thereon, and the computer program is loaded by a processor to execute the steps in any of the data processing methods provided in embodiments of this application. For example, the computer program loaded by the processor can execute the following steps: Receive plugin data access requests for the target plugin; In response to a plugin data access request, determine the target access path marked with the plugin identifier of the target plugin; Access the plugin data of the target plugin based on the target access path.
[0075] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the detailed descriptions of other embodiments above, which will not be repeated here.
[0076] In practice, each of the above units or structures can be implemented as an independent entity or can be arbitrarily combined to be implemented as the same or several entities. For the specific implementation of each of the above units or structures, please refer to the previous method embodiments, which will not be repeated here.
[0077] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.
[0078] The data processing method, apparatus, terminal device, and computer-readable storage medium provided in the embodiments of this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.
Claims
1. A data processing method, characterized in that, include: Receive plugin data access requests for the target plugin; In response to the plugin data access request, determine the target access path marked with the plugin identifier of the target plugin; Based on the target access path, access the plugin data of the target plugin.
2. The data processing method according to claim 1, characterized in that, The step of determining the target access path marked with the plugin identifier in response to the plugin data access request includes: Determine the plugin identifier corresponding to the plugin data access request; Based on the plugin identifier, determine the target context function encapsulation class corresponding to the target plugin; The target access path is determined by the target context function encapsulation class.
3. The data processing method according to claim 2, characterized in that, The step of determining the target context function encapsulation class corresponding to the target plugin based on the plugin identifier includes: Detect whether a context function encapsulation class matching the plugin identifier exists; If a context function encapsulation class that matches the plugin identifier exists, the context function encapsulation class that matches the plugin identifier will be determined as the target context function encapsulation class. If no context function encapsulation class matches the plugin identifier, a new context function encapsulation class is created, and the new context function encapsulation class is bound to the plugin identifier to obtain the target context function encapsulation class.
4. The data processing method according to claim 2, characterized in that, The step of determining the target access path through the target context function encapsulation class includes: Based on the data access type corresponding to the plugin data access request, determine the data access method corresponding to the plugin data access request; The target access path is obtained by calling the data access method through the target context function encapsulation class.
5. The data processing method according to claim 4, characterized in that, The target access path is obtained by calling the data access method through the target context function encapsulation class, including: The target access path is obtained by calling the data access method through the target context function encapsulation class to insert the plugin identifier into the original access path, wherein the target access path is isolated from the path that stores plugin data of other plugins.
6. The data processing method according to claim 5, characterized in that, Before receiving the plugin data access request for the target plugin, the process includes: The plugin identifier is written into the base file of the target plugin so that the plugin identifier in the base file is automatically read and inserted into the currently called method.
7. The data processing method according to claim 1, characterized in that, Before receiving the plugin data access request for the target plugin, the method further includes: Detect whether there is any abnormal code in the running code of the target plugin, wherein the abnormal code includes at least one of the following: code for obtaining data from the application's global path, and code for obtaining the plugin data through a means other than the context utility class; If the abnormal code exists in the running code of the target plugin, an exception message is generated, wherein the exception message is used to indicate that there is unisolated data in the data of the target plugin.
8. A data processing apparatus, characterized in that, include: The receiving module is used to receive plugin data access requests for the target plugin; The determination module is used to determine the target access path marked with the plugin identifier in response to the plugin data access request; The access module is used to access the plugin data of the target plugin based on the target access path.
9. A terminal device, characterized in that, The terminal device includes: one or more processors, a memory, and one or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the processor to implement the data processing method of any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, It stores a computer program, which is loaded by a processor to perform the steps of the data processing method according to any one of claims 1 to 7.