Middle layer service implementation mode for simplifying application layer equipment access and data processing based on Android

Abstract

The invention discloses a middle layer service implementation mode for simplifying application layer equipment access and data processing based on Android, which is used as a link for connecting hardware and displaying a program, can reduce memory and storage occupation and improve execution efficiency, is easy to expand and debug, and meets various complex requirements. The implementation mode is based on Java language development, and an interface method provided by hardware is called through JNI, so that the process of communication interaction with the hardware is realized; packaging different equipment analysis classes according to different equipment types so as to provide an independent and flexible interaction process among the multiple equipment analysis classes; an efficient and simple data interface is provided for the display layer, and various complex requirements can be compatible and expanded; an SQLite database is used for storing and updating data uploaded by hardware in a short period.

Description

Technical Field

[0001] The present invention belongs to the technical field of Android program development, and in particular refers to an intermediate layer service implementation method based on Android to simplify application layer device access and data processing. The present invention is a part of a built-in display screen software program, and is also an intermediate switching program connecting the Android display program and the underlying communication of the Linux system. Background Art

[0002] For industrial application scenarios, Android program development is more complex, more flexible, and more customizable than traditional single-chip display program development. It can produce more complex interactions and effects, but also requires more time for maintenance and testing.

[0003] In the existing technology, higher requirements are often put forward for the hardware and process itself, while the requirements for software functions and performance are relatively low. In order to reduce development costs and development time, most Android display programs tend to be industrialized and primitive. In some products, in order to simplify the programs on the Android display, some functions can be allowed to be incomplete or even missing. However, most of the programs used to develop such industrialized Android displays tend to use the same simple technology to achieve the most basic functions, which cannot be applied to current products with increasingly complex display requirements. Summary of the invention

[0004] The main purpose of the present invention is to provide an intermediate layer service implementation method based on Android to simplify application layer device access and data processing, solve the problems existing in the prior art, and as a link connecting hardware and display programs, it can reduce memory and storage occupancy, improve execution efficiency, and is easy to expand and debug to meet various complex needs.

[0005] In order to achieve the above object, the solution of the present invention is: An implementation method of middle-layer services based on Android to simplify device access and data processing at the application layer, where the middle layer receives instructions from the display layer upwards and connects to instructions from the underlying hardware downwards; For the underlying hardware: In the logic of the underlying hardware, a table is defined, in which a number of addresses are configured for each device, and the device has a corresponding device ID and the address has a corresponding address ID; The bottom layer hardware has a port for communicating with the middle layer, and the port is preset with rules; the middle layer sends a sending instruction to the bottom layer hardware according to the rules, and receives a reply instruction from the bottom layer hardware, and the types of instructions include query, setting and burning; the port program establishes a corresponding instruction queue for each instruction; in the query instruction queue, a corresponding time interval is set according to the type of query instruction, and when the issuance time of the query instruction reaches the corresponding time interval, the issuance of the next query instruction will be triggered; and in the query instruction queue, after a query instruction is executed, the middle layer reads the corresponding query reply from the port, and caches the query reply data into the analysis class of the corresponding device type according to the device type of the query instruction; For display layers: When the display layer calls the middle layer, it creates a main service and initializes all related resources, including port opening and analysis class creation initialization; the main service receives the instructions sent by the display layer and makes corresponding replies; after the port is opened, it starts to execute the instruction queue in an infinite loop; The display layer sends a sending instruction to the middle layer and receives a reply instruction from the middle layer. The types of instructions include sending data, receiving data and initiating burning.

[0006] In the command queue established by the program of the port, the priorities are burning, setting and querying.

[0007] When the main service receives an instruction from the display layer, it sends it to the corresponding device analysis class for execution based on the device type and instruction type of the instruction. After the analysis class is executed, the result is returned to the main service, and then the main service returns it to the display layer.

[0008] When the main service is created, the startService method is called in the Application or Activity of the Android project to start the MainService; after the startService is successfully bound, the setCallback method of the MainService is called and the Response interface is passed in; the Response includes two interface methods: pushResponse (byte[] data) and void pushStatus (byte[] data).

[0009] Preferably, after completing initialization, the display layer configures parameters setWhiteListPush, startWatchDogTask and setDeviceConfig to MainService.

[0010] Preferably, when the instruction is to send data, the cmdSend(byte[]) method of MainService is called, including data query instructions, setting instructions, record query instructions, database query instructions and database deletion instructions; when the instruction is to receive data, the data transmitted by the pushResponse and pushStatus methods are received from the Callback interface of MainService, pushResponse replies with data content related to the instruction, and pushStatus calls back the whitelist address configured during initialization.

[0011] After adopting the above technical solution, the present invention has the following technical effects: The present invention can run on the Android screen as an intermediate link connecting the underlying hardware and the display layer, isolating the display layer from the underlying hardware, avoiding confusion in code function logic, and facilitating development and debugging. It occupies low memory resources and storage, and only occupies about 10 to 20M of memory for a long time of independent operation; the instruction queue execution efficiency is high, and on the basis of being limited by the performance of the Android hardware device, 100 query instructions only take 0.2 to 0.3 seconds; compared with traditional industrialized Android screen projects, it is easier to expand and debug. The present invention has been actually applied to 5 projects for simultaneous development and debugging, expanding various complex needs. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 It is a flowchart of a specific embodiment of the present invention; Figure 2 It is a schematic diagram of instructions according to a specific embodiment of the present invention. DETAILED DESCRIPTION

[0013] In order to further explain the technical solution of the present invention, the present invention is described in detail below through specific embodiments.

[0014] refer to Figure 1 As shown, the present invention discloses an implementation method of middle-layer service based on Android to simplify application layer device access and data processing. It is a part of the Android program of the Android display screen, developed in Java language, responsible for communicating with the underlying hardware, and connecting the display program to realize data display or command issuance. In actual products, the program on the Android display screen is divided into two parts: one part is responsible for querying data, displaying data and human-computer interaction, called the display layer; the other part is responsible for communicating with the hardware, executing the instructions of the display layer and forwarding them to the hardware, called the middle layer. The present invention mainly focuses on the function of the middle layer. The middle layer needs to accept the instructions of the display screen upward and connect the instructions of the underlying hardware downward, playing a role of connecting the upper and lower parts.

[0015] Specifically, the present invention includes the following two parts: (1) For the underlying hardware Protocol: There are two main concepts in the communication process between the middle layer and the underlying hardware and display layer: device and address. In the logic of the underlying hardware, a table is defined, in which each device is configured with several addresses. At the same time, the device has a corresponding device ID and the address has a corresponding address ID.

[0016] In most cases, the ID is expressed in hexadecimal. For example, a device ID is 0x006D07, where 0x006D represents the device type and 07 represents the 8th device starting from 0. This device corresponds to an address of 0x1003, which is used to represent grid power. In general, the two are combined and 0x006D071003 is used as the unique identifier of an address, that is, the unique identifier of the business represented by this address. The development process also relies on this device ID and address ID to implement specific logic.

[0017] Command: The information transmitted by the middle layer and the underlying hardware is called instructions, which are divided into sending instructions sent by the middle layer to the underlying hardware and reply instructions sent by the underlying hardware to the middle layer. There are many types of sending instructions, including query, setting, and burning, and the reply instructions of the underlying hardware also have corresponding query replies, setting replies, and burning replies. The specific form of instructions is a byte array (byteArray). In addition to the fixed header and tail and CRC (Cyclic Redundancy Check) verification data, the byte array of each instruction is the actual interaction data, that is, it contains device ID, send and receive flags, single address multi-address flags, read and write flags, addresses, and data. Among them, the device ID is the device ID that this instruction wants to query or set; the send and receive flag means that the instructions sent by the middle layer will be 0, and the instructions replied by the bottom hardware will be 1; because the length of each instruction is fixed, it can carry a maximum of 12 bytes of data, but setting some data requires more than 12 bytes, it will be defined as a multi-address setting. When setting multiple addresses, an instruction containing only the CRC value will be sent first, and then the actual data will be sent, so there will be at least two instructions for multi-address setting; the address is the address that this instruction wants to query or set. Several addresses will be configured under each device ID according to actual needs.

[0018] See also Figure 2,During the communication process: the middle layer builds different byte arrays according to the different types, devices, and addresses of instructions, and follows the above rules, and then sends them to the underlying hardware; after receiving the instructions, the underlying hardware will reply to the middle layer according to the same rules to complete a communication.

[0019] Port: The communication process between the middle layer and the underlying hardware relies on an interface program that interacts with the underlying hardware. Its functions are only the most basic functions of opening, closing, writing and reading, which is called a port. The middle layer needs to communicate with the underlying hardware according to the rules of the port. In the port program, a command queue is established for each command to process the instructions sent by the middle layer, among which burning has the highest priority, followed by setting, and querying last. The port will cyclically read and execute the instructions in these queues to control the writing and reading process. As long as there is an instruction in the queue, it will be taken out and executed. After execution, this instruction will be destroyed, and then the next instruction will be executed. The query instruction is created in an infinite loop, which is equivalent to having a query instruction executed all the time, but the setting and burning instructions are created on demand. Because the operation initiated by the user from the display layer is not certain, but the content to be displayed needs to know the real-time changes of the data as much as possible, so an infinite loop query is required.

[0020] Query Queue: There may be a one-to-one or one-to-many relationship between query commands and reply query commands. The communication performance of the underlying hardware is lower and more unstable than that of the Android display. The instability is reflected in the uncertainty of the interval between each query reply. For example, at time A, the middle layer sends a command to query 9 addresses to the underlying hardware. Because each command can save the values ​​of 3 addresses, 3 query replies will be obtained under normal circumstances, such as the first query reply at A+10 milliseconds, the second query reply at A+15 milliseconds, and the third query reply at A+18 milliseconds. However, the time difference of 10, 15, and 18 is not fixed, and the greater the amount of queries, the greater the volatility. When querying 1 address, a reply will be obtained in about 2~4 milliseconds, when querying 10 addresses, a reply will be obtained in about 10~15 milliseconds, and when querying 100 addresses, all replies will be obtained in about 80~100 milliseconds. When there are many query commands, it is necessary to consider the interval between multiple query commands, and also consider the situation where there is no reply or lack of reply to the command. In this case, there are different strategies to deal with it. The most basic one is to ensure that each query instruction can correspond to the corresponding query reply to ensure the data is correct. It is also necessary to ensure that the number of query instructions is not too much or too little, not less than the actual needs of the display program (the address data that the query interface focuses on), and not too much, to avoid slow data updates due to excessive query instructions. In simple terms, it is necessary to ensure that the data to be queried is queried in the shortest possible time. This cycle time is temporarily named M. There are two strategies for the above problems: The first strategy is to trigger the next query instruction by relying on the completion of the reply of a query instruction. For example, the Nth query instruction A is issued at time T, and query reply A1 is obtained at T+5, query reply A2 is obtained at T+10, and query reply A3 is obtained at T+18, then it is judged that the Nth query instruction has been replied to; then, the N+1th query instruction B is triggered to be issued at T+18, query reply B1 is obtained at T+20, and query reply B2 is obtained at T+30, and it is judged that the N+1th query instruction B has been replied to, then the N+2th query instruction C is triggered to be issued at T+30... and so on. Under the first strategy, the instability of hardware communication will be ignored, and the automatic triggering logic of send-receive-send-receive will be completely relied upon to shorten the query cycle M to the shortest. The advantage is that under normal communication, M completely relies on hardware performance, without unnecessary waiting and delay (after testing, the time for each query of 1,000 items under the first strategy can be controlled within 600 milliseconds); the disadvantage of this strategy is that when the response to a query instruction is slow, the subsequent query instructions will be delayed, and even the query queue cycle will be interrupted. Although some delayed waiting strategies can also be added, such as setting a maximum timeout for each query, in actual situations, this time is not easy to determine uniformly. The effect after determination is that in the worst case, if each query times out, it will also cause the overall slowness.

[0021] The second strategy is to let each query instruction have a time interval to constrain the start of the next query instruction. Regardless of whether the query instruction has been replied during the period, the next query instruction will be triggered when the time interval is reached. For example: define the interval time between each instruction and the next instruction as G, issue the Nth query instruction A at time T, the G of A is 30 milliseconds, query reply A1 is obtained at T+5, query reply A2 is obtained at T+8, and query reply A3 is obtained at T+19; issue the N+1th query instruction B at T+30, the G of B is 60 milliseconds, query reply B1 is obtained at T+34, query reply B2 is obtained at T+37; issue the N+2th query instruction C at T+90... and so on. Under the second strategy, it is necessary to find an algorithm that is as close to the actual instruction delay as possible to calculate the G value of each instruction. This value needs to be as small as possible when it is greater than or equal to the actual delay to ensure that M is minimized. The advantage of the second strategy is that multiple queries do not affect each other, and a slow response locally will not cause all queries to slow down; its disadvantage is that there will be some useless waiting time in the middle.

[0022] At present, the middle layer adopts the second method, which sacrifices some time to ensure global stability. According to the actual test results below, we can roughly estimate that the relationship between the number of queries e and the delay d is d=3.3c, which is enough to cover most query scenarios and minimize waiting gaps.

[0023]

[0024] Analyse: In actual scenarios, multiple device types need to be defined to achieve different functional requirements. For example, if the middle layer needs to query the information 1 of the A-type device, it will add a command of "query the information 1 of the A-type device" to the query queue, or if it needs to set the third setting item of the B-type device, it will add a command of "set the setting item 3 of the B-type device". In actual scenarios, there will be about ten types of devices, and each type of device has several to hundreds of different information or setting items. When the application starts, according to the configured device type and number of devices, a module for processing the corresponding device type business is established, which is called an analysis class. Each analysis class will define the information to be queried by its own device, and when it needs to be added to the command queue of the port program, it will also define the settings that are allowed to be accepted. Each analysis class will have the same function of receiving query requests from the display layer and replying to the request. In the query command queue, after a query command is executed, the corresponding query reply will be read from the port, and the data will be cached in the analysis class of the corresponding device type according to the device type of this command.

[0025] (2) For the display layer MainService: The display layer calls the functions of the middle layer, and needs to create a core built into the middle layer, called the main service. When the main service is created, it will initialize all related resources, including port opening, analysis class creation initialization, etc. The main service will receive instructions from the display layer and reply to the corresponding reply instructions of the display layer; after the port is opened, it will start to execute the instruction queue in an infinite loop.

[0026] When the display layer sends an instruction, it will send the instruction to the corresponding device analysis class for execution based on the device type and instruction type of the instruction. After the analysis class executes, the result will be returned to the main service, and then the main service will return to the display layer to complete the whole process.

[0027] Initialization (init): To use this program, you need to call the startService method in the Application or Activity of the Android project to start the MainService. After the startService is successfully bound, call the setCallback method of the MainService and pass in a Response interface. There are two main interface methods in Response: one is pushResponse (byte[] data), which will call back the MainService to reply to the display layer; the other is void pushStatus (byte[] data), which can be used to tell the display layer about the data changes when there are data changes in the middle layer.

[0028] Configuration (config): After successful initialization, you need to configure the following parameters to MainService to tell the middle layer the current running requirements and provide more usage scenarios.

[0029] setWhiteListPush, whitelist - used to tell the middle layer which devices and which addresses need to be actively pushed to the display layer when their values ​​change.

[0030] startWatchDogTask, watchdog - start the watchdog thread of the middle layer; after the thread is started, the display layer needs to call the feedDog method once every 1 minute. This function is to ensure that when the display layer is unresponsive and the program function fails, the middle layer can sense it and restart to restore the program function.

[0031] setDeviceConfig, device tree - the middle layer needs to be configured with the type and number of devices that need to be started. Because this program is used in many different projects, the actual project needs to define the functions of the middle layer.

[0032] use: The main functions of using this program are sending data, receiving data, initiating burning, etc. The information transmitted by the display layer and the middle layer is called a command. The information transmitted by the display layer to the middle layer is called a send command, and the information transmitted by the middle layer to the display layer is called a reply command.

[0033] Sending data: The actual operation of sending a command is to call the method of sending data, that is, to call the cmdSend (byte[]) method of MainService. This method passes in a byte type array, which contains the information of this command. There are five types of sending commands sent by the display layer, query data command, setting command, query record command, query database command, and delete database command. All five commands need to call the cmdSend method to complete the sending. The format of the array of each command is different. The array is assembled according to the respective formats agreed by the middle layer.

[0034] The query command can query the values ​​of all addresses from address X to address Y of the device. For example, to query the values ​​of all addresses from 2715 to 2720 of the 006D01 device, the content sent is 05006D012715006D012720, including the start address and the end address.

[0035] The set command can set a specified value to a certain address. For example, if you want to set the address 1003 of 005F00 to 4, the content sent is 005F001003020004, which includes the value of the address to be set, the length of the value and the specific value.

[0036] The query record instruction can query the specified type and range of records. For example, to query the operation log of device 009100 and query 10 records starting from the 5th, the content sent is 030091000100050A, which includes the device type to be queried, log type, query start index, and query number.

[0037] The query database command can be used to query the value of a specified address of a device within a certain time period. The display layer is generally used to display charts. For example, to query the values ​​of 271A, 271B, and 271C of device 006D04 from timestamp 1730390400 to timestamp 1730476800, the content sent is 6723A9806724FB0001006D04271A006D04271B006D04271C, including the start time, end time, time accuracy, device ID, and address to be queried.

[0038] The delete database command can delete all the data in the database. It can only accept one type, and the sent format is 0001, which means deleting the entire database.

[0039] Receiving data: Receiving data refers to the process of receiving the pushResponse and pushStatus methods from the Callback interface of MainService. All the reply instructions of the previous send instructions will be called back from the pushResponse method. Each send instruction corresponds to a special reply instruction data format. For example, the data of the reply query instruction corresponding to the query instruction will contain the data content to be queried by the query instruction. The reply instruction corresponding to the setting instruction will contain the execution result of this setting instruction. The pushStatus method will call back the whitelist address configured during initialization. When the values ​​of these whitelist addresses in the middle layer change, the display layer will be notified by calling back the pushStatus method, so that the display layer can respond to data changes in real time.

[0040] Through the above scheme, the key points of the present invention are: Because the port program is relatively simple, but the functions to be implemented are very complex, multi-layer encapsulation is implemented, and there is also compatibility processing for other port programs, which can realize fast switching of projects, add new projects, and increase scalability and debuggability; the present invention creates an analysis class for each device type, and each analysis class implements the corresponding function; the present invention isolates the display layer from the underlying hardware through an intermediate layer to avoid confusion in the logic of code functions and facilitate development and debugging. Due to the performance limitations of the underlying hardware, the delay of the outgoing data fluctuates. The actual delay rules are summarized and a special algorithm is calculated to ensure the lowest delay when the query volume remains unchanged.

[0041] Therefore, the present invention can achieve the following technical effects: The present invention can run on the Android screen as an intermediate link connecting the underlying hardware and the display layer. It occupies low memory resources and storage, and only occupies about 10 to 20M of memory for a long time of independent operation; the instruction queue execution efficiency is high. Based on the limitation of the performance of the Android hardware device, 100 query instructions only take 0.2 to 0.3 seconds; compared with traditional industrialized Android screen projects, it is easier to expand and debug. The present invention has been actually applied to 5 projects for simultaneous development and debugging, and expanded to various complex needs.

[0042] The above embodiments and drawings do not limit the product form and style of the present invention. Any appropriate changes or modifications made by ordinary technicians in the relevant technical field should be deemed to be within the patent scope of the present invention.

Claims

1. An implementation method of an intermediate layer service based on Android to simplify application layer device access and data processing, characterized in that: The middle layer receives instructions from the display layer and connects to the instructions from the underlying hardware. For the underlying hardware: In the logic of the underlying hardware, a table is defined, in which a number of addresses are configured for each device, and the device has a corresponding device ID and the address has a corresponding address ID; The bottom layer hardware has a port for communicating with the middle layer, and the port is preset with rules; the middle layer sends a sending instruction to the bottom layer hardware according to the rules, and receives a reply instruction from the bottom layer hardware, and the types of instructions include query, setting and burning; the port program establishes a corresponding instruction queue for each instruction; in the query instruction queue, a corresponding time interval is set according to the type of query instruction, and when the issuance time of the query instruction reaches the corresponding time interval, the issuance of the next query instruction will be triggered; and in the query instruction queue, after a query instruction is executed, the middle layer reads the corresponding query reply from the port, and caches the query reply data into the analysis class of the corresponding device type according to the device type of the query instruction; For display layers: When the display layer calls the middle layer, it creates a main service and initializes all related resources, including port opening and analysis class creation initialization; the main service receives the instructions sent by the display layer and makes corresponding replies; after the port is opened, it starts to execute the instruction queue in an infinite loop; The display layer sends a sending instruction to the middle layer and receives a reply instruction from the middle layer. The types of instructions include sending data, receiving data and initiating burning.

2. The middle layer service implementation method for simplifying application layer device access and data processing based on Android as claimed in claim 1, characterized in that: In the command queue established by the program of the port, the priorities are burning, setting and querying.

3. The middle layer service implementation method for simplifying application layer device access and data processing based on Android as claimed in claim 1, characterized in that: When the main service receives an instruction from the display layer, it sends it to the corresponding device analysis class for execution based on the device type and instruction type of the instruction. After the analysis class is executed, the result is returned to the main service, and then the main service returns it to the display layer.

4. The middle layer service implementation method for simplifying application layer device access and data processing based on Android as claimed in claim 1, characterized in that: When the main service is created, the startService method is called in the Application or Activity of the Android project to start the MainService; after the startService is successfully bound, the setCallback method of the MainService is called and the Response interface is passed in; the Response includes two interface methods: pushResponse (byte[] data) and void pushStatus (byte[] data).

5. The middle layer service implementation method for simplifying application layer device access and data processing based on Android as claimed in claim 4 is characterized in that: After completing the initialization, the display layer configures parameters setWhiteListPush, startWatchDogTask and setDeviceConfig to MainService.

6. The middle layer service implementation method for simplifying application layer device access and data processing based on Android as claimed in claim 4 is characterized by: When the instruction is to send data, the cmdSend(byte[]) method of MainService is called, including data query instructions, setting instructions, record query instructions, database query instructions and database deletion instructions; when the instruction is to receive data, the data transmitted by the pushResponse and pushStatus methods are received from the Callback interface of MainService, pushResponse replies with data content related to the instruction, and pushStatus callbacks the whitelist address configured during initialization.

Images