CN118819689A - Data collection method, device, electronic device and storage medium - Google Patents

Abstract

The present embodiment discloses a data acquisition method, device, electronic device and storage medium, the method comprising: a main program acquires a data acquisition instruction; calls a task subprogram and at least two instruction subprograms, passes instruction parameters of the data acquisition instruction to each instruction subprogram, and enables each instruction subprogram to pass instruction parameters to the task subprogram; the main program and the task subprogram are in different application environments; the main program creates at least two anonymous pipes, receives the acquisition data output by the process of the task subprogram through the first anonymous pipe of at least two anonymous pipes, and receives response information for the instruction parameters sent by the process of each instruction subprogram through the second anonymous pipe of at least two anonymous pipes; performs a first interaction with the task subprogram based on at least a channel between the first instruction subprogram and the task subprogram, and performs a second interaction with the task subprogram based on a channel between the second instruction subprogram and the task subprogram.

Description

Data collection method, device, electronic device and storage medium

Technical Field

The present application belongs to the field of computers, and in particular, relates to a data acquisition method, device, electronic device and storage medium.

Background Art

In the related art, the main program can call a sub-process for data collection, and the collection of computer resources and other data can be realized by executing the sub-process; the communication between the main program and the sub-process can be realized through anonymous pipes. The condition for using anonymous pipes to realize multiple interactions between the main program and the sub-process is that the main program and the sub-process need to be in the same application environment. When the main program and the sub-process are not in the same application environment, after calling the sub-process to obtain the collected data, the main program cannot interact with the sub-process again, which is not conducive to collecting data according to real-time data collection needs.

Summary of the invention

Embodiments of the present application provide a data collection method, device, electronic device, and storage medium.

The present application provides a data collection method, the method comprising:

The main program obtains data acquisition instructions;

The main program calls the task subprogram and at least two instruction subprograms, and passes the instruction parameters of the data acquisition instruction to each of the at least two instruction subprograms, so that each instruction subprogram passes the instruction parameters to the task subprogram; the main program and the task subprogram are in different application program environments;

The main program creates at least two anonymous pipes, receives the collected data output by the process of the task subroutine through the first anonymous pipe of the at least two anonymous pipes, and receives the response information for the instruction parameters sent by the process of each instruction subroutine through the second anonymous pipe of the at least two anonymous pipes; performs a first interaction with the task subroutine based on at least a channel between the first instruction subroutine and the task subroutine, and performs a second interaction with the task subroutine based on a channel between the second instruction subroutine and the task subroutine; the collected data is the data collected by the task subroutine according to the instruction parameters, and the first instruction subroutine and the second instruction subroutine are two instruction subroutines among the at least two instruction subroutines.

In some embodiments, after calling the task subroutine, the method further includes: redirecting the standard output of the task subroutine to the channel in the first anonymous pipe through which the main program receives data; after calling the first instruction subroutine, the method further includes: redirecting the standard output of each instruction subroutine to the channel in the second anonymous pipe through which the main program receives data.

It can be seen that by redirecting the standard output of the task subroutine to the channel for the main program to receive data in the first anonymous pipe, and redirecting the standard output of each instruction subroutine to the channel for the main program to receive data in the second anonymous pipe, the corresponding instruction subroutine and task subroutine can transmit data to the main program through a standard output method, which has the characteristic of simple implementation.

In some embodiments, the calling of at least two instruction subroutines includes: calling the at least two instruction subroutines by calling the exec function family; passing the instruction parameters of the data acquisition instruction to each instruction subroutine of the at least two instruction subroutines includes: passing the instruction parameters to each instruction subroutine by calling the exec function family.

It can be seen that the embodiments of the present application can implement the calling of the instruction subroutine and the passing of parameters to the instruction subroutine relatively simply and easily by calling the exec function family.

In some embodiments, after passing the instruction parameters of the data acquisition instruction to each of the instruction subprograms, the method further includes: when the response information sent by the process of any one of the at least two instruction subprograms is not received within a first time length, or when it is determined that the running time of the process of any one of the instruction subprograms is greater than or equal to a second time length, controlling the process of the corresponding instruction subprogram to terminate running.

It can be seen that if the main program does not receive a response message sent by the process of the corresponding instruction subroutine within the first time period after passing the instruction parameters to any instruction subroutine, or if it is determined that the running time of the process of any instruction subroutine is greater than or equal to the second time period, it can be considered that the process of the corresponding instruction subroutine has failed to run normally. By controlling the process of the corresponding instruction subroutine to terminate its operation, it is beneficial to save system resources.

In some embodiments, the collected data is data obtained by the task subroutine through executing the task to be executed, and the task to be executed is determined by the task subroutine according to the parsing result after parsing the instruction parameters and obtaining the parsing result.

It can be seen that through the interaction between the instruction subroutine and the task subroutine, the task subroutine can obtain instruction parameters, and then the task subroutine can more accurately determine the tasks to be executed by the task subroutine by parsing the instruction parameters.

In some embodiments, the instruction parameters include at least one of the identifier of the resource to be collected and the task feature setting parameter. In this way, the task subroutine can obtain the parsing result according to the identifier of the resource to be collected and the task feature setting parameter, so that the task to be executed can be determined more accurately according to the parsing result to realize resource collection as required.

In some embodiments, the main program obtains the data collection instruction, including: the main program receives the data collection instruction from the service platform; after the main program receives the collected data output by the process of the task subprogram through the first anonymous pipe of the at least two anonymous pipes, the method further includes: sending the collected data to the service platform. In this way, the service platform can obtain the collected data corresponding to the data collection instruction through interaction with the main program, and the data collection instruction can be determined according to actual needs. Therefore, the service platform can realize data collection according to actual needs.

In some embodiments, after the main program calls the task subroutine, the method further includes: the main program receives heartbeat messages sent by the process of the task subroutine multiple times, and when the duration between the last time the heartbeat message was received and the current time is greater than the set duration, the main program closes the process of the task subroutine and calls the task subroutine again.

Here, the task subroutine can periodically send heartbeat messages to the main program through the first anonymous pipe. The main program monitors the heartbeat information. When the duration between the last time the heartbeat message was received and the current time is greater than the set duration, it can be considered that the process of the task subroutine is abnormal, thereby forcibly closing and recreating the task subroutine to ensure the continuous and stable operation of the task subroutine.

The present application also provides a data acquisition device, the device comprising:

An acquisition module, used for acquiring data acquisition instructions;

A first processing module is used to call a task subroutine and at least two instruction subroutines, and pass instruction parameters of the data acquisition instruction to each instruction subroutine of the at least two instruction subroutines, so that each instruction subroutine passes the instruction parameters to the task subroutine; the main program and the task subroutine are in different application program environments;

The second processing module is used to create at least two anonymous pipes, receive the collected data output by the process of the task subroutine through the first anonymous pipe of the at least two anonymous pipes, and receive the response information for the instruction parameters sent by the process of each instruction subroutine through the second anonymous pipe of the at least two anonymous pipes; perform a first interaction with the task subroutine based on at least a channel between the first instruction subroutine and the task subroutine, and perform a second interaction with the task subroutine based on a channel between the second instruction subroutine and the task subroutine; the collected data is the data collected by the task subroutine according to the instruction parameters, and the first instruction subroutine and the second instruction subroutine are two instruction subroutines among the at least two instruction subroutines.

An embodiment of the present application also provides an electronic device, including a processor and a memory for storing a computer program that can be run on the processor; wherein the processor is used to run the computer program to execute any one of the above-mentioned data acquisition methods.

An embodiment of the present application further provides a computer storage medium on which a computer program is stored. When the computer program is executed by a processor, any one of the above-mentioned data collection methods is implemented.

It can be seen that in the scenario where the main program needs to interact with the task subprocess multiple times, first, the main program can call the instruction subroutine. After the instruction subroutine passes the instruction parameters to the task subroutine, the task subroutine can determine the task to be executed based on the parsing results of the instruction parameters. Therefore, when the main program and the task subroutine are two different applications, the main program can also call at least two instruction subroutines to pass instruction parameters to each of the at least two instruction subroutines, so that through the interaction of at least two different instruction subroutines with the task subroutine, the main program can pass multiple parameters to the task subroutine. That is, the main program can also interact with the task subprocess multiple times by calling at least two instruction subroutines, which is beneficial for the task subprogram to collect data according to real-time data collection requirements.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 is a schematic diagram of the interaction flow between the main program and the interface application program in the related art;

FIG2 is a flow chart of a data collection method according to an embodiment of the present application;

FIG3 is a flow chart of the interaction between the main program and the interface application provided in an embodiment of the present application;

FIG4 is an exemplary framework structure diagram for implementing data collection provided in an embodiment of the present application;

FIG5 is an interactive flow chart for implementing data collection provided in an embodiment of the present application;

FIG6 is a schematic diagram of the structure of a data acquisition device according to an embodiment of the present application;

FIG. 7 is a schematic diagram of the structure of an electronic device according to an embodiment of the present application.

DETAILED DESCRIPTION

In software engineering projects of related technologies, the software for collecting data (such as IoT device information) can be deployed in IoT devices through a middleware software development kit (SDK), and the relevant information of the device is obtained by calling different hardware device resource interfaces, and reported to a unified platform through the middleware SDK. In the process of collecting hardware-related resource interface information, the application layer software, as well as the middleware SDK and its underlying functions or devices need to have information interaction and communication capabilities.

In the related art, data collection can be achieved by calling an application program interface. An application program interface generally refers to an application programming interface (API). The main purpose of an API is to provide a way for applications and developers to call programs in the same way as defined functions and parameters. The software that provides the functions defined by the API is called the implementation of the API. The API can be regarded as an abstract interface. API is usually part of a software development kit (SDK); in the case of closed source code, the API can implement interface functions by providing a dynamic library or a static library.

Since the API is relatively complex, detailed definition of interface specifications is required. There is a lot of definition content such as structure definition, function parameters, return value, etc., which are difficult to describe and understand in the document. There will be problems such as insufficient experience of development technicians and high labor costs.

The characteristic of API is that it can only be called within the process and cannot be called through the process of another application. In this case, the API call cannot be implemented through cross-process communication, and there will be problems of mutual interference within the process. When the code is implemented through the interface, there will be memory leaks, the process memory usage is getting higher and higher, or there are code quality problems, which will cause the probe program to crash and terminate its operation, which will affect the normal functional operation of the application, and the quality requirements for the interface implementation are very high.

In the related art, the decoupling of different program interface functions can be achieved by means of inter-process communication. In one example, a scheme for inter-process communication is: by setting a set of programming interfaces, programmers can coordinate different processes so that they can run simultaneously in an operating system and transmit and exchange information with each other. In another example, the scheme for implementing inter-process communication may include an inter-process communication scheme based on a socket, an inter-process communication scheme based on a shared memory, an inter-process communication scheme based on a Linux pipe, an inter-process communication scheme based on a named pipe, or other schemes, where the named pipe is also called a First Input First Output (FIFO) queue.

The characteristic of Linux anonymous pipe is half-duplex communication mode. In the related art, the relationship between two processes using Linux anonymous pipe communication is a parent-child process relationship; in actual implementation, the process in the main program is the parent process, and the child process can be created by the parent process. The parent process and the child process jointly establish a Linux pipe and communicate through the pipe descriptor (handle) passed. In the scenario of implementing interface function decoupling in a cross-process manner, it is necessary to implement two processes belonging to different applications to communicate. At this time, the Linux anonymous pipe feature will be more restricted. In some embodiments, the child process is a process in the interface application; referring to Figure 1, when the main program 101 and the interface application 102 are two different applications, the main program 101 can only carry running parameters when the process is called, and pass the running parameters to the interface application 102; after the process of the interface application 102 outputs data to the main program 101, the main program 101 cannot interact with the interface application 102 again. At this time, only one-way communication from the interface application 102 to the main program 101 can be realized, so that the main program 101 and the interface application 102 cannot realize real-time interaction.

In the related art, the condition for realizing multiple interactions between the main program 101 and the interface application 102 based on Linux anonymous pipes is that the main program 101 and the interface application 102 need the same program code space. However, when the parent process of the main program 101 and the child process of the interface application 102 belong to two different applications, the code of the parent process of the main program 101 and the code of the child process of the interface application 102 are separated. In this case, multiple interactions between the main program 101 and the interface application 102 cannot be realized.

In the related art, compared with the inter-process communication scheme based on Linux pipes, the interface definition complexity of other inter-process communication schemes is relatively high, and there are problems such as difficulty in development and maintenance. For example, the main program 101 is the main program A, and the interface application 102 is the interface program B. The inter-process communication scheme based on Socket or the inter-process communication scheme based on shared memory can realize the communication between the main program A and the interface program B. Here, the process of the main program A and the process of the interface program B are two processes belonging to different applications. When the program abnormality of the interface program B causes the business to fail to operate normally, since the main program A and the interface program B have no process management relationship, they cannot make management and control actions, thereby increasing the operation and maintenance costs of abnormal situations.

In summary, the inter-process communication solution based on Linux pipes cannot realize real-time interaction between two processes and does not meet the real-time communication requirements between two processes; the inter-process communication solution based on Linux pipes is not conducive to the wide application of interface definition and interface specifications. Other inter-process communication solutions in the related art cannot realize the operation management and control capabilities of the main program 101 over the interface application 102. Therefore, the inter-process communication solutions in the related art cannot meet the actual needs for inter-process communication.

In order to solve the above technical problems, a technical solution of the embodiment of the present application is proposed.

The following is a further detailed description of the embodiments of the present application in conjunction with the accompanying drawings and examples. It should be understood that the embodiments provided herein are only used to explain the embodiments of the present application and are not intended to limit the embodiments of the present application. In addition, the embodiments provided below are partial embodiments for implementing the present application, rather than providing all embodiments for implementing the present application. In the absence of conflict, the technical solutions recorded in the embodiments of the present application can be implemented in any combination.

It should be noted that, in the embodiments of the present application, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a method or device including a series of elements includes not only the elements explicitly recorded, but also includes other elements not explicitly listed, or also includes elements inherent to the implementation of the method or device. In the absence of further restrictions, an element defined by the sentence "includes a ..." does not exclude the presence of other related elements (such as steps in a method or units in a device, for example, a unit may be a part of a circuit, a part of a processor, a part of a program or software, etc.) in the method or device including the element.

The embodiment of the present application provides a data collection method. The data collection method provided by the embodiment of the present application includes a series of steps, but the data collection method provided by the embodiment of the present application is not limited to the recorded steps. Similarly, the data collection device provided by the embodiment of the present application includes a series of modules, but the device provided by the embodiment of the present application is not limited to including the modules explicitly recorded, and can also include modules required to obtain relevant information or perform processing based on information.

The data collection method provided in the embodiment of the present application can be applied to an Internet of Things device or other devices. FIG. 2 is a flow chart of the data collection method in the embodiment of the present application. As shown in FIG. 2 , the process may include:

Step 201: The main program obtains data acquisition instructions.

In some embodiments, the main program can receive data collection instructions from the service platform; the data collection instructions can be instructions for collecting resources of the Internet of Things device or other devices. For example, the resources of the Internet of Things device or other devices can be device status information such as memory occupancy rate and central processing unit (CPU) occupancy rate, or can be basic device information such as device serial number and CPU mode, or can be information such as International Mobile Equipment Identity (IMEI) or International Mobile Subscriber Identity (IMSI).

Here, after obtaining the data acquisition instruction, the main program can obtain the instruction parameters in the data acquisition instruction.

Step 202: The main program calls the task subprogram and at least two instruction subprograms, and passes instruction parameters of the data acquisition instruction to each of the at least two instruction subprograms, so that each instruction subprogram passes instruction parameters to the task subprogram; the main program and the task subprogram are in different application environments.

In some embodiments, the main program may call at least two instruction subroutines in sequence according to a predetermined calling order of at least two instruction subroutines. The instruction parameters passed to the at least two instruction subroutines may be the same instruction parameters or different instruction parameters; for example, when the instruction parameters passed by the main program to the at least two instruction subroutines are the same instruction parameters, and the instruction parameters are used to characterize the data collection method, the task subroutine may collect data multiple times according to the same data collection method based on the instruction parameters sent by the at least two task subroutines. When the instruction parameters passed by the main program to the at least two instruction subroutines are different instruction parameters, and the instruction parameters are used to characterize the data collection method, the task subroutine may collect data multiple times according to different data collection methods based on the instruction parameters sent by the at least two task subroutines.

In some embodiments, the process of each instruction subroutine can communicate with the process of the task subroutine through inter-process communication (IPC) or other communication methods; the task subroutine can determine the task to be executed by the task subroutine by parsing the instruction parameters.

In some embodiments, the task to be executed in the task subroutine is a task for continuous data collection.

Step 203: the main program creates at least two anonymous pipes, receives the collected data output by the process of the task subroutine through the first anonymous pipe of the at least two anonymous pipes, and receives the response information for the instruction parameters sent by the process of each instruction subroutine through the second anonymous pipe of the at least two anonymous pipes; performs a first interaction with the task subroutine based on at least a channel between the first instruction subroutine and the task subroutine, and performs a second interaction with the task subroutine based on a channel between the second instruction subroutine and the task subroutine; the collected data is the data collected by the task subroutine according to the instruction parameters, and the first instruction subroutine and the second instruction subroutine are two instruction subroutines of the at least two instruction subroutines.

In some embodiments, the anonymous pipe can be a Linux anonymous pipe. The main program can create a first anonymous pipe for receiving data sent by the process of the task subroutine, and can also create a second anonymous pipe for receiving data sent by the process of each instruction subroutine. The first anonymous pipe is the data transmission channel between the main program and the task subroutine, and the second anonymous pipe is the data transmission channel between the main program and the instruction subroutine.

In some embodiments, when the main program creates multiple different second anonymous pipes, data sent by a process of an instruction subroutine can be received through each of the multiple second anonymous pipes, that is, by creating at least two different second anonymous pipes, data from processes of at least two instruction subroutines can be received.

In some embodiments, after the main program calls the first instruction subroutine and the second instruction subroutine, instruction parameters can be passed to the first instruction subroutine, and based on the channel between the first instruction subroutine and the task subroutine, the first interaction between the main program and the task subroutine is realized; then, instruction parameters can be passed to the second instruction subroutine, and based on the channel between the second instruction subroutine and the task subroutine, the second interaction between the main program and the task subroutine is realized.

In some embodiments, the main program receives the collected data continuously output by the process of the task subroutine through the first anonymous pipe.

In some embodiments, the main program can receive data collection instructions from the service platform; after the main program receives the collected data output by the process of the task subprogram through the first anonymous pipe, the collected data can also be sent to the service platform. In this way, the service platform can obtain the collected data corresponding to the data collection instruction through interaction with the main program, and the data collection instruction can be determined according to actual needs. Therefore, the service platform can realize data collection according to actual needs.

In some embodiments, referring to FIG. 3 , the main program 101 may be a program for an information detection and collection application; the information detection and collection application may be deployed as a terminal application in an IoT device or a terminal device. In an IoT project, the main task of the information detection and collection application is to collect information of the device or terminal in a targeted manner.

When the information detection and collection application needs to collect a certain type of information, the information detection and collection application can interact with the platform through the network protocol in the northbound direction, and can use the technical solution of the embodiment of the present application to communicate with the interface application in the southbound direction to realize data collection and report the collected data to the service platform through the northbound network interface.

Referring to FIG3 , the task subroutine and each instruction subroutine are programs in the interface application 102. The program of the information detection and collection application is a program module responsible for creating and managing the interface application 102. The main program 101 can call each instruction subroutine to achieve the process creation of each instruction subroutine; the main program 101 can also pass instruction parameters to each instruction subroutine after calling each instruction subroutine. The main program 101 can also call the task subroutine to achieve the process creation of the task subroutine.

The interface application 102 can receive instructions from the main program 101 , and after implementing the data collection function according to the instructions, output the collected data to the main program 101 .

It can be seen that there are two data transmission processes between the main program and the interface application, and the transmission directions of these two data transmission processes are different. In the first data transmission process, data can be transmitted from the main program to the interface application, and the parameter transmission when the interface application is started can be realized. In the second data transmission process, the process of the interface application can transmit data to the main program. For example, the process of the task subroutine can transmit the collected data to the main program, and the process of the instruction subroutine can transmit the response information of the instruction parameter to the main program.

In some embodiments, the data output to the anonymous pipe by the process in the interface application 102 is a string output by a standard application, and the output string may contain multiple meaningful data information items, with commas or other symbols as data item separators in sequence, and "\n" (newline) as the current line end mark. Multiple lines of information output are allowed to represent multiple groups of different information.

Here, multiple groups of different information may refer to multiple groups of data determined based on fixed parameter information after the collected data is classified, and the multiple groups of data are represented in multiple rows. In some embodiments, the fixed parameters may represent the type of data to be collected, and the collection time corresponding to different rows of data may be different. For example, the fixed parameters may be CPU occupancy and memory occupancy, and the data in the first row and the data in the second row may represent the collected data corresponding to the fixed parameters in different time periods.

In some embodiments, the main program 101 and the interface application 102 can set operating parameters according to actual interaction requirements. When the interface application 102 is created and started, it can receive a name parameter and the first to nth parameters, where n is an integer greater than or equal to 1; the interface application 102 can process the first to nth parameters, where the name parameter can represent the name of the interface application 102.

In practical applications, steps 201 to 203 can be implemented based on a processor of an electronic device, and the processor can be at least one of an application specific integrated circuit (ASIC), a digital signal processor (DSP), a digital signal processing device (DSPD), a programmable logic device (PLD), a field programmable gate array (FPGA), a central processing unit (CPU), a controller, a microcontroller, and a microprocessor.

It can be seen that in the scenario where the main program needs to interact with the task subprocess multiple times, first, the main program can call the instruction subroutine. After the instruction subroutine passes the instruction parameters to the task subroutine, the task subroutine can determine the task to be executed based on the parsing results of the instruction parameters. Therefore, when the main program and the task subroutine are two different applications, the main program can also call at least two instruction subroutines to pass instruction parameters to each of the at least two instruction subroutines, so that through the interaction of at least two different instruction subroutines with the task subroutine, the main program can pass multiple parameters to the task subroutine. That is, the main program can also interact with the task subprocess multiple times by calling at least two instruction subroutines, which is beneficial for the task subprogram to collect data according to real-time data collection requirements.

Furthermore, when the instruction subroutine and the task subroutine are programs in the interface application 102, based on the aforementioned records, it can be seen that the main program 101 runs the interface application 102 by creating a subprocess, which is beneficial to solving the real-time interaction problem between the main program 101 and the interface application 102 through the first anonymous pipe and the second anonymous pipe.

In some embodiments of the present application, after calling the task subroutine, the standard output of the task subroutine is redirected to the channel in the first anonymous pipe through which the main program receives data; after calling the first instruction subroutine, the standard output of each instruction subroutine is redirected to the channel in the second anonymous pipe through which the main program receives data.

It can be seen that by redirecting the standard output of the task subroutine to the channel for the main program to receive data in the first anonymous pipe, and redirecting the standard output of each instruction subroutine to the channel for the main program to receive data in the second anonymous pipe, the corresponding instruction subroutine and task subroutine can transmit data to the main program through a standard output method, which has the characteristic of simple implementation.

In some embodiments of the present application, the process of calling at least two instruction subroutines may include: calling at least two instruction subroutines by calling the exec function family; the process of passing instruction parameters to each instruction subroutine of the at least two instruction subroutines may include: passing instruction parameters to each instruction subroutine by calling the exec function family.

The exec function family provides a method to start another program execution in a process. It can find the executable file according to the specified file name or directory name, and use it to replace the data segment, code segment and stack segment of the original calling process. Exemplarily, the exec function family can be functions such as execl, execlp, execle, execv, execvp, execvpe, etc.

It can be seen that the embodiments of the present application can implement the calling of the instruction subroutine and the passing of parameters to the instruction subroutine relatively simply and easily by calling the exec function family.

In some embodiments of the present application, after receiving the instruction parameters, each instruction subroutine can pass the instruction parameters to the task subroutine; after receiving the reply information of the task subroutine for the instruction parameters, the response information for the instruction parameters can be sent to the main program 101 through the second anonymous pipe. After the process of the first instruction subroutine sends the response information to the main program 102 through the second anonymous pipe, the first instruction subroutine can be terminated immediately. In this way, while saving process resources, it is beneficial to improve the stability of the operation of the interface application by terminating the first instruction subroutine, and there is no additional requirement for the stability of the operation of the interface application; further, since the first instruction subroutine of the interface application will exit after the call is completed, this can release memory, and to a certain extent, the memory overflow problem of the interface application can be solved, so that the memory overflow problem will not affect the operation of the device where the interface application is located.

In some embodiments of the present application, after the instruction parameters of the data acquisition instruction are passed to each instruction subroutine, the following steps can also be performed: when the response information sent by the process of any one of the at least two instruction subprograms is not received within the first time length, or when it is determined that the running time of the process of any one of the instruction subprograms is greater than or equal to the second time length, the process of the corresponding instruction subprogram is controlled to terminate running.

In the embodiment of the present application, the first duration and the second duration can be preset according to actual needs. In some embodiments, the main program 101 can monitor the running state of the process of the instruction subprogram by means of a probe application, so as to determine the running time of the instruction subprogram.

It can be seen that if the main program does not receive a response message sent by the process of the corresponding instruction subroutine within the first time period after passing the instruction parameters to any instruction subroutine, or if it is determined that the running time of the process of any instruction subroutine is greater than or equal to the second time period, it can be considered that the process of the corresponding instruction subroutine has failed to run normally. By controlling the process of the corresponding instruction subroutine to terminate its operation, it is beneficial to save system resources.

In some embodiments of the present application, after the main program calls the task subroutine, the main program receives heartbeat messages sent by the process of the task subroutine multiple times. When the duration between the last time the heartbeat message was received and the current time is greater than the set duration, the main program closes the process of the task subroutine and calls the task subroutine again.

Here, the task subroutine can periodically send heartbeat messages to the main program through the first anonymous pipe. The main program monitors the heartbeat information. When the duration between the last time the heartbeat message was received and the current time is greater than the set duration, it can be considered that the process of the task subroutine is abnormal, thereby forcibly closing and recreating the task subroutine to ensure the continuous and stable operation of the task subroutine.

In some embodiments of the present application, after each instruction subroutine passes the instruction parameters of the data acquisition instruction to the task subroutine, the task subroutine parses the instruction parameters to obtain the parsing results; determines the task to be executed according to the parsing results; and obtains the collected data by executing the task to be executed.

It can be seen that through the interaction between the instruction subroutine and the task subroutine, the task subroutine can obtain instruction parameters, and then the task subroutine can more accurately determine the tasks to be executed by the task subroutine by parsing the instruction parameters.

In some embodiments of the present application, the instruction parameters may include at least one of the identifier of the resource to be collected and the task feature setting parameter. For example, the task feature setting parameter is a relevant parameter set for the task to be executed of the task subroutine, and the task feature setting parameter may be a period for sending data to the main program, etc. It can be seen that the task subroutine can obtain the parsing result based on the identifier of the resource to be collected and at least one of the task feature setting parameters, so that according to the parsing result, the task to be executed can be determined more accurately to realize resource collection as required.

In some embodiments, the identification of the resource to be collected is the identity identification number (Identity Document, ID) of the resource or other identification. When the main program is an Internet of Things information collection application program, the ID of the resource to be collected can be displayed in Table 1.

In Table 1, when the resource ID is 001, the data items include IMEI; when the resource ID is 002, the data items include IMSI; when the resource ID is 100, the data items include DeviceSN, DeviceModel, CpuModel, HardwareVer, SoftwareVer, RamSize, and FlashSize, where DeviceSN represents the device serial number, DeviceModel represents the device model, CpuModel represents the CPU model, HardwareVer represents the hardware version number, SoftwareVer represents the software version number, and RamSize represents the random access memory (Random Access When the resource ID is 101, the data items include SystemTime, BootTime, RunTime, CpuUsage, RamUsage, FlashUsage and Temperature, where SystemTime indicates system time, BootTime indicates device boot time, RunTime indicates the running time after the device is powered on, CpuUsage indicates CPU usage, RamUsage indicates RAM usage, FlashUsage indicates FLASH memory usage, and Temperature indicates temperature.

Table 1

The instruction subroutine is used to receive resource ID information and pass it to the task subroutine. The task subroutine can collect resources according to the resource ID. According to the agreed data item content, the data output of the task subroutine to the main program can be completed through the standard output operation of the system print function. It should be noted that the data type of the resource ID can be the numeric type shown in Table 1, or it can be other character types.

The data collection method of the embodiment of the present application is further described below with reference to the accompanying drawings.

FIG4 is an exemplary framework structure diagram for implementing data collection provided in an embodiment of the present application. As shown in FIG4 , the main program 101 may include a task subprocess management module, a task subprocess data analysis module, and an instruction subprocess management module.

Among them, the task subprocess management module is used to implement the operation and management functions of the task subprogram process. In some embodiments, the task subprocess management module can control the task subprogram process to be in a continuous running state; in some embodiments, the task subprocess management module can monitor the task subprogram process through a probe application, and process the task subprogram process when the task subprogram process is unresponsive and the process exits abnormally. For example, when the task subprogram process is unresponsive, the task subprogram process can be controlled to exit, and then the task subprogram process can be recreated. When the task subprogram process exits abnormally, the task subprogram process can be recreated.

The data analysis module of the task subprocess may analyze the collected data output by the task subprogram, and may send the analysis result to the service platform 401 .

The instruction subprocess management module is a subprocess created and called by the main program according to the instruction configuration requirements. In some embodiments, the instruction subprocess management module is used to implement the calling and forced exit of the instruction subprogram process. In some embodiments, the instruction subprocess management module can determine the first to nth parameters recorded above as instruction parameters.

It can be seen that the embodiment of the present application can handle the abnormal situations of the process of the instruction subroutine and the process of the task subroutine in the interface application without affecting the next call of the interface application.

Referring to Figure 4, the task subroutine may include an interface module, an instruction parsing module, a task scheduling module and a task function module; wherein the interface module receives data sent by the instruction subroutine; the instruction parsing module may parse the data received by the interface module, and the task scheduling module determines the task to be executed according to the parsing result output by the instruction parsing module, thereby allocating and scheduling different task function modules. The task function module implements the code according to the actual function of the task, is mainly responsible for the specific data collection function, and outputs the data to the main program through an anonymous pipe according to the protocol content output by the task.

FIG5 is an interactive flow chart for implementing data collection provided in an embodiment of the present application. Referring to FIG5 , the service platform is a remote platform, and instruction subprocess 1 and instruction subprocess 2 are processes of two different instruction subroutines.

After the main program initiates service registration with the service platform, the service platform can send data collection instructions to the main program. The main program can create a task subprogram and at least two instruction subprograms, and send instruction parameters to the instruction subprograms.

The main program receives the command message collected by the service platform, can create a subprocess to call the command subprogram, and pass the command parameter information, wait for the process of its command subprogram to feedback the command response information and monitor whether the process of the command subprogram exits normally.

The command subprogram can send a configuration transmission instruction to the task subprogram, and the configuration transmission instruction carries the above instruction parameter information; after receiving the configuration transmission instruction, the task subprogram can reply a configuration confirmation message to the command subprogram. After the command subprogram receives the configuration confirmation message, the process of the command subprogram can reply a response message to the main program, and after the process of the command subprogram replies a response message to the main program, the command subprogram can be exited immediately to release system resources.

After receiving the collected data sent by the process of the task subroutine, the main program can package the collected data and send the packaged data to the service platform.

In summary, the embodiment of the present application proposes a communication method based on anonymous pipes, which solves the real-time interaction capability between the interface application and the main program, while also solving the main program's process management and control capabilities of the interface application, and the code implementation requirements for the interface application are also simpler.

Those skilled in the art will appreciate that, in the above method of specific implementation, the order in which the steps are written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of the steps should be determined by their functions and possible internal logic.

Based on the data acquisition method proposed in the above-mentioned embodiment, the embodiment of the present application further proposes a data acquisition device, which is applied in the main program.

FIG6 is a schematic diagram of the structure of a data acquisition device according to an embodiment of the present application. As shown in FIG6 , the device may include:

An acquisition module 601 is used to acquire a data acquisition instruction;

The first processing module 602 is used to call the task subroutine and at least two instruction subroutines, and pass the instruction parameters of the data acquisition instruction to each instruction subroutine of the at least two instruction subroutines, so that each instruction subroutine passes the instruction parameters to the task subroutine; the main program and the task subroutine are in different application program environments;

The second processing module 603 is used to create at least two anonymous pipes, receive the collected data output by the process of the task subroutine through the first anonymous pipe of the at least two anonymous pipes, and receive the response information for the instruction parameters sent by the process of each instruction subroutine through the second anonymous pipe of the at least two anonymous pipes; perform a first interaction with the task subroutine based on at least a channel between the first instruction subroutine and the task subroutine, and perform a second interaction with the task subroutine based on a channel between the second instruction subroutine and the task subroutine; the collected data is the data collected by the task subroutine according to the instruction parameters, and the first instruction subroutine and the second instruction subroutine are two instruction subroutines among the at least two instruction subroutines.

In some embodiments, the first processing module 602 is further used to redirect the standard output of the task subprogram to the channel for receiving data of the main program in the first anonymous pipe after calling the task subprogram;

The first processing module 602 is further configured to redirect the standard output of each instruction subprogram to the channel for receiving data of the main program in the second anonymous pipe after calling the first instruction subprogram.

In some embodiments, the first processing module 602 is used to call at least two instruction subroutines, including: calling the at least two instruction subroutines by calling the exec function family;

The first processing module 602 is used to transfer the instruction parameters of the data acquisition instruction to each instruction subroutine of at least two instruction subroutines, including: transferring the instruction parameters to each instruction subroutine by calling the exec function family.

In some embodiments, the first processing module 602 is also used to control the process of the corresponding instruction subroutine to terminate its operation when the response information sent by the process of any one of the at least two instruction subroutines is not received within a first time period after the instruction parameters of the data acquisition instruction are passed to each instruction subroutine, or when it is determined that the running time of the process of any one of the instruction subroutines is greater than or equal to a second time period.

In some embodiments, the collected data is data obtained by the task subroutine through executing the task to be executed, and the task to be executed is determined by the task subroutine according to the parsing result after parsing the instruction parameters and obtaining the parsing result.

In some embodiments, the instruction parameters include at least one of an identification of a resource to be collected and a task feature setting parameter.

In some embodiments, the acquisition module 601 is used to acquire data acquisition instructions, including: the main program receives the data acquisition instructions from the service platform;

The second processing module 603 is further configured to send the collected data to the service platform after receiving the collected data output by the process of the task subroutine through the first anonymous pipe of the at least two anonymous pipes.

In some embodiments, the first processing module 602 is also used to receive heartbeat messages sent by the process of the task subroutine multiple times after calling the task subroutine, and when the duration between the last time the heartbeat message was received and the current time is greater than the set duration, close the process of the task subroutine and call the task subroutine again.

In practical applications, the acquisition module 601, the first processing module 602 and the second processing module 603 can all be implemented based on a processor of an electronic device.

It should be noted that the description of the above device embodiment is similar to the description of the above method embodiment, and has similar beneficial effects as the method embodiment. For technical details not disclosed in the device embodiment of the present application, please refer to the description of the method embodiment of the present application for understanding.

It should be noted that in the embodiments of the present application, if the above method is implemented in the form of a software function module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a storage medium, including a number of instructions to enable a computer device (which can be a terminal, a server, etc.) to execute all or part of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a U disk, a mobile hard disk, a read-only memory (ROM), a disk or an optical disk. In this way, the embodiments of the present application are not limited to any specific combination of hardware and software.

Correspondingly, an embodiment of the present application further provides a computer program product, which includes computer executable instructions, and the computer executable instructions are used to implement any data collection method provided in the embodiment of the present application.

Accordingly, an embodiment of the present application further provides a computer storage medium, on which computer executable instructions are stored, and the computer executable instructions are used to implement any one of the data collection methods provided in the above embodiments.

The embodiment of the present application further provides an electronic device. FIG. 7 is a schematic diagram of the composition structure of the electronic device provided in the embodiment of the present application. As shown in FIG. 7 , the electronic device 70 may include:

Memory 701, used to store executable instructions;

The processor 702 is used to implement any of the above-mentioned data collection methods when executing the executable instructions stored in the memory 701.

The processor 702 may be at least one of an ASIC, a DSP, a DSPD, a PLD, a FPGA, a CPU, a controller, a microcontroller, and a microprocessor.

The above-mentioned computer-readable storage medium/memory can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic random access memory (FRAM), a flash memory (Flash Memory), a magnetic surface memory, an optical disk, or a compact disc read-only memory (CD-ROM) and the like; it can also be various terminals including one or any combination of the above-mentioned memories, such as mobile phones, computers, tablet devices, personal digital assistants, etc.

In some embodiments, the functions or modules included in the device provided in the embodiments of the present application can be used to execute the method described in the above method embodiments. The specific implementation can refer to the description of the above method embodiments. For the sake of brevity, it will not be repeated here.

The above description of various embodiments tends to emphasize the differences between the various embodiments. The same or similar aspects can be referenced to each other, and for the sake of brevity, they will not be repeated herein.

The methods disclosed in the various method embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments.

The features disclosed in the various product embodiments provided in this application can be arbitrarily combined without conflict to obtain new product embodiments.

The features disclosed in the various method or device embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments or device embodiments.

Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM/RAM, a magnetic disk, or an optical disk), and includes a number of instructions for a terminal (which can be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) to execute the methods described in each embodiment of the present application.

The embodiments of the present application are described above in conjunction with the accompanying drawings, but the present application is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the guidance of the present application, ordinary technicians in this field can also make many forms without departing from the purpose of the present application and the scope of protection of the claims, all of which are within the protection of the present application.

Claims (11)

1. A data collection method, characterized in that the method comprises: The main program obtains data acquisition instructions; The main program calls the task subprogram and at least two instruction subprograms, and passes the instruction parameters of the data acquisition instruction to each of the at least two instruction subprograms, so that each instruction subprogram passes the instruction parameters to the task subprogram; the main program and the task subprogram are in different application program environments; The main program creates at least two anonymous pipes, receives the collected data output by the process of the task subroutine through the first anonymous pipe of the at least two anonymous pipes, and receives the response information for the instruction parameters sent by the process of each instruction subroutine through the second anonymous pipe of the at least two anonymous pipes; performs a first interaction with the task subroutine based on at least a channel between the first instruction subroutine and the task subroutine, and performs a second interaction with the task subroutine based on a channel between the second instruction subroutine and the task subroutine; the collected data is the data collected by the task subroutine according to the instruction parameters, and the first instruction subroutine and the second instruction subroutine are two instruction subroutines among the at least two instruction subroutines. 2. The method according to claim 1, characterized in that after calling the task subroutine, the method further comprises: redirecting the standard output of the task subroutine to the channel in the first anonymous pipe through which the main program receives data; After calling the first instruction subprogram, the method further includes: redirecting the standard output of each instruction subprogram to the channel for the main program to receive data in the second anonymous pipe. 3. The method according to claim 1, characterized in that the calling of at least two instruction subroutines comprises: Calling the at least two instruction subroutines by calling the exec function family; The step of transmitting the instruction parameter of the data acquisition instruction to each instruction subroutine of at least two instruction subroutines comprises: By calling the exec function family, the instruction parameters are passed to each instruction subroutine. 4. The method according to any one of claims 1 to 3, characterized in that after the instruction parameters of the data acquisition instruction are transmitted to each instruction subroutine, the method further comprises: When the response information sent by the process of any one of the at least two instruction subprograms is not received within the first time period, or when it is determined that the running time of the process of any one of the instruction subprograms is greater than or equal to the second time period, the process of the corresponding instruction subprogram is controlled to terminate running. 5. The method according to any one of claims 1 to 3 is characterized in that the collected data is data obtained by the task subroutine through executing the task to be executed, and the task to be executed is determined by the task subroutine after parsing the instruction parameters and obtaining the parsing result based on the parsing result. 6 . The method according to claim 5 , wherein the instruction parameters include at least one of an identification of resources to be collected and a task feature setting parameter. 7. The method according to any one of claims 1 to 3, characterized in that the main program obtains the data collection instruction, comprising: the main program receives the data collection instruction from the service platform; After the main program receives the collected data output by the process of the task subprogram through the first anonymous pipe of the at least two anonymous pipes, the method further includes: sending the collected data to the service platform. 8. The method according to any one of claims 1 to 3, characterized in that after the main program calls the task subroutine, the method further comprises: The main program receives heartbeat messages sent by the process of the task subprogram multiple times. When the time between the last time the heartbeat message was received and the current time is greater than the set time, the main program closes the process of the task subprogram and calls the task subprogram again. 9. A data acquisition device, characterized in that it is applied to a main program, and comprises: An acquisition module, used for acquiring data collection instructions; A first processing module is used to call a task subroutine and at least two instruction subroutines, and pass instruction parameters of the data acquisition instruction to each instruction subroutine of the at least two instruction subroutines, so that each instruction subroutine passes the instruction parameters to the task subroutine; the main program and the task subroutine are in different application program environments; The second processing module is used to create at least two anonymous pipes, receive the collected data output by the process of the task subroutine through the first anonymous pipe of the at least two anonymous pipes, and receive the response information for the instruction parameters sent by the process of each instruction subroutine through the second anonymous pipe of the at least two anonymous pipes; perform a first interaction with the task subroutine based on at least a channel between the first instruction subroutine and the task subroutine, and perform a second interaction with the task subroutine based on a channel between the second instruction subroutine and the task subroutine; the collected data is the data collected by the task subroutine according to the instruction parameters, and the first instruction subroutine and the second instruction subroutine are two instruction subroutines among the at least two instruction subroutines. 10. An electronic device, comprising a processor and a memory for storing a computer program that can be run on the processor; wherein: The processor is used to run the computer program to execute the data collection method according to any one of claims 1 to 8. 11. A computer storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the data acquisition method according to any one of claims 1 to 8.