Android-based simplified application layer device access and data processing intermediate layer service implementation

By designing intermediate layer services to isolate the display layer from the underlying hardware and optimizing communication protocols and instruction processing, the problems of complexity and high cost in Android display program development are solved, achieving low memory usage, high execution efficiency, and easy scalability.

CN119759610BActive Publication Date: 2025-12-19TBB POWER XIAMEN CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202411827111.X
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2024-12-12
Publication Date
2025-12-19
Estimated Expiration
2044-12-12

AI Technical Summary

Technical Problem

Existing Android display application development is complex and inflexible, making it difficult to adapt to the needs of complex industrial applications. Furthermore, development costs are high, and functional simplification leads to insufficient performance.

Method used

Design a middleware service that isolates the display layer from the underlying hardware by defining device tables and instruction queues, optimizes communication protocols and instruction processing, reduces memory usage, and improves execution efficiency.

Benefits of technology

It achieves low memory usage, high execution efficiency, adaptability to complex requirements, ease of expansion and debugging, and reduced development costs.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119759610B_ABST
    Figure CN119759610B_ABST
Patent Text Reader

Abstract

The application discloses an implementation mode of a middle layer service based on Android for simplifying application layer device access and data processing, which is a link connecting hardware and display programs, can reduce memory and storage occupation, improve execution efficiency, is easy to extend and debug, and meets various complex requirements. The implementation mode is developed based on a Java language, an interface method provided by hardware is called through JNI, and a hardware communication interaction process is realized; different device analysis classes are encapsulated according to different device types, so as to provide independent and flexible interaction processes among the device analysis classes; an efficient and simple data interface is provided for a display layer, various complex requirements can be compatible and extended; and SQLite databases are used to save and update data uploaded by hardware in a short period.
Need to check novelty before this filing date? Find Prior Art

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of Android program development, in particular to an intermediate layer service implementation method for simplifying application layer device access and data processing based on Android, which is part of the built-in display screen software program and also an intermediate adapter program connecting the Android display program and the Linux system bottom communication. BACKGROUND

[0002] For industrial application scenarios, Android program development is more complex than traditional single-chip microcomputer display screen program development, is more flexible and customizable, can make more complex interaction and effect, and also needs more time for maintenance and testing.

[0003] In the prior art, higher requirements are often proposed for hardware and technology itself, and lower requirements are proposed for software function and performance. In order to reduce development cost and development time, most of the programs of the Android display screen tend to be industrialized and original, and even in some products, in order to simplify the program on the Android display screen, some functions are incomplete or even missing. The programs for developing such industrialized Android display screens mostly tend to use the same simple technology to realize the most basic functions, and cannot be applied to the products with more and more complex display requirements. SUMMARY

[0004] The main purpose of the present application is to provide an intermediate layer service implementation method for simplifying application layer device access and data processing based on Android, to solve the problems in the prior art, to serve as a link between hardware and display program, to reduce memory and storage occupation, to improve execution efficiency, to be easy to extend and debug, and to meet various complex requirements.

[0005] In order to achieve the above purpose, the solution of the present application is as follows:

[0006] An intermediate layer service implementation method for simplifying application layer device access and data processing based on Android, which receives the instructions of the display layer from the upper intermediate layer and transmits the instructions of the bottom hardware to the lower intermediate layer;

[0007] For the bottom hardware:

[0008] In the logic of the bottom hardware, a table is defined, and each device in the table is configured with a plurality of addresses, and the device has a corresponding device ID and the address has a corresponding address ID;

[0009] The bottom layer hardware has a port communicating with the intermediate layer, and the port is preset with rules; the intermediate layer sends a sending instruction to the bottom layer hardware according to the rules, and receives a reply instruction of the bottom layer hardware, the type of the instruction including query, setting and burning; the program of the port establishes a corresponding instruction queue for each type of instruction; in the query instruction queue, a corresponding time interval is set according to the type of the query instruction, and the next query instruction will be triggered when the sending time of the query instruction reaches the corresponding time interval; and in the query instruction queue, after the execution of a query instruction, the intermediate layer reads the corresponding query reply from the port, and caches the data of the query reply into the analysis class of the corresponding device type according to the device type of the query instruction.

[0010] For the display layer:

[0011] When the display layer calls the intermediate layer, a main service is created, and all related resources are initialized, including port opening and analysis class creation and initialization; the main service receives the instruction sent by the display layer and makes a corresponding reply; after the port is opened, the instruction queue is executed in an infinite loop;

[0012] The display layer sends a sending instruction to the intermediate layer, and receives a reply instruction of the intermediate layer, the type of the instruction including sending data, receiving data and initiating burning.

[0013] In the instruction queue established by the program of the port, the priority is burning, setting and query in turn.

[0014] When the main service receives the instruction sent by the display layer, the instruction is sent to the corresponding device analysis class for execution according to the device type and the type of the instruction, and the result is replied to the main service after the execution of the analysis class, and then the main service replies to the display layer.

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

[0016] Preferably, after the display layer is initialized, the MainService is configured with parameters setWhiteListPush, startWatchDogTask and setDeviceConfig.

[0017] Preferably, the instruction is to send data, the cmdSend (byte[]) method of MainService is called, including query data instruction, setting instruction, query record instruction, query database instruction and delete database instruction; the instruction is to receive data, the data transmitted by two methods of pushResponse and pushStatus in the Callback interface of MainService is received, pushResponse replies the data content related to the instruction, and pushStatus calls the white list address configured in initialization.

[0018] After the above technical scheme is adopted, the application has the following technical effects:

[0019] The application can be operated in the Android screen as the intermediate link connecting the bottom hardware and the display layer, isolates the display layer from the bottom hardware, avoids the code function logic confusion, is convenient for development and debugging, has low memory resource occupation and storage, and only occupies about 10 to 20M memory for long time independent operation; the instruction queue has high execution efficiency, on the basis of being limited by the performance of the Android hardware device, 100 query instructions only consume 0.2~0.3 seconds; compared with the traditional industrialized Android screen project, the application is more easy to extend and debug, the application has been actually applied to 5 project simultaneous development and debugging, and various complex requirements are extended. BRIEF DESCRIPTION OF DRAWINGS

[0020] Figure 1 The flow chart of the embodiment of the application is shown in the figure.

[0021] Figure 2 The instruction schematic diagram of the embodiment of the application is shown in the figure. DETAILED DESCRIPTION

[0022] In order to further explain the technical scheme of the application, the application is described in detail by specific embodiments.

[0023] REFERENCE Figure 1As shown, the application discloses a kind of intermediate layer service implementation mode based on Android simplification application layer device access, data processing, it is part of Android display screen Android program, developed with Java language, responsible for communication with bottom hardware, and connect display program, realize data display or instruction issue.In actual product, the program on Android display screen is divided into two parts: one part is responsible for querying data, display data and man-machine interaction part, called display layer;Another part is responsible for communication with hardware, execute the instruction of display layer and forward it to hardware, called intermediate layer.The application is mainly the function of this part of intermediate layer, intermediate layer needs to accept the instruction of display screen upwards, and needs to connect the instruction of bottom hardware downwards, play the role of upper and lower.

[0024] Specifically, the application includes the following two parts:

[0025] (1) for bottom hardware

[0026] Protocol (Protocol):

[0027] In the communication process of intermediate layer and bottom hardware, display layer, there are mainly two concepts, one is called device (Device), one is called address (address).In the logic of bottom hardware, define a table, and configure several addresses for each device in the table, while the device has corresponding device ID, and the address has corresponding address ID.

[0028] Most of the time, ID will be expressed as hexadecimal, for example: a device ID is 0x006D07, wherein 0x006D represents the device type, and 07 represents the 8th device from 0;This device corresponds to an address of 0x1003, such as the address is agreed to represent power grid power;Generally, the two will be combined to combine 0x006D071003 as a unique identifier of the address, that is, as a unique identifier of the business represented by the address, and the device ID and address ID will also be relied on in the development process to realize specific logic.

[0029] Command (Command):

[0030] The information communicated between the intermediate layer and the bottom layer hardware is called instruction, and is divided into sending instruction sent by the intermediate layer to the bottom layer hardware and reply instruction sent by the bottom layer hardware to the intermediate layer. The sending instruction has multiple types, including query, setting and burning, etc., and the reply instruction of the bottom layer hardware also has corresponding query reply, setting reply and burning reply, etc. The specific form of the instruction is byte array, and the byte array of each instruction is the actual interaction data, i.e. device ID, sending and receiving flag, single address and multi-address flag, read and write flag, address and data, in addition to fixed header, tail and CRC (Cyclic Redundancy Check) check data. Among them, the device ID is the device ID to be queried or set by the instruction; the sending and receiving flag is that the instruction sent by the intermediate layer is 0, and the instruction replied by the bottom layer hardware is 1; because the length of each instruction is fixed, it can bear up to 12 bytes of data, but setting some data needs more than 12 bytes, which will be defined as multi-address setting, and multi-address setting will send a instruction containing only CRC value first, and then send the actual data, so multi-address setting will have at least two instructions; the address is the address to be queried or set by the instruction, and according to the actual needs, a number of addresses will be configured under each device ID.

[0031] Referring to Figure 2 , in the communication process: the intermediate layer constructs different byte arrays according to the different types of instructions, different devices and different addresses, and in accordance with the rules in the above, and then sends them to the bottom layer hardware; the bottom layer hardware will reply to the intermediate layer according to the same rules after receiving the instruction, and complete a communication.

[0032] Port (Port):

[0033] The communication process between the intermediate layer and the bottom layer hardware relies on an interface program interacting with the bottom layer hardware, which has only the basic functions of opening, closing, writing and reading, and is called port. The intermediate layer needs to communicate with the bottom layer hardware according to the rules of the port. In the port program, an instruction queue is established for each type of instruction to process the sending instructions of the intermediate layer, in which the priority of burning is the highest, the priority of setting is the second, and the priority of query is the last. The port will read and execute these instructions in the queue in a loop, and the process of writing and reading will be controlled as long as there is an instruction in the queue, which will be taken out and executed, and after execution, the 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 executing at all times, but the setting and burning instructions are created on demand. Because the operation initiated by the display layer user is not determined, but the content to be displayed needs to know the real-time change of data as much as possible, so the query needs to be in an infinite loop.

[0034] Query queue (Queue):

[0035] There can be one-to-one or one-to-many relationship between the query instruction and the reply query instruction. The communication performance of the underlying hardware is relatively lower and unstable compared to the Android display screen, and the instability is reflected in the uncertain interval time of each read query reply. For example, in the middle layer, a query instruction of 9 addresses is sent to the underlying hardware at time A. Since each instruction can store 3 address values, 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 quantity of queries, the greater the volatility. When querying 1 address, the reply is obtained in about 2-4 milliseconds, when querying 10 addresses, the reply is obtained in about 10-15 milliseconds, and when querying 100 addresses, all replies are obtained in about 80-100 milliseconds. When there are many query instructions, the interval between multiple query instructions needs to be considered, and the case of no reply or missing reply of the instruction also needs to be considered. In this case, different strategies are used to deal with it. The most basic one is to ensure that each query instruction corresponds to the corresponding query reply to ensure data correctness, and also to ensure that the quantity of query instructions is not too much or too little, which cannot be less than the actual demand of the display program (address data concerned by the query interface), and cannot be too much, avoiding slow data update due to too large query instruction. In simple terms, it is necessary to ensure that the data to be queried is completed in the shortest possible time, and this period of time is temporarily named M. To solve the above problems, there are two strategies as follows:

[0036] The first strategy is to trigger the next query instruction by the end of the reply of a query instruction, for example: the Nth query instruction A is sent at T time, 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, and it is judged that the Nth query instruction has been replied; then, the N+1th query instruction B is triggered 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, and then the N+2th query instruction C is triggered at T+30……and so on. In the first strategy, the instability of hardware communication is ignored, and the automatic trigger logic of sending-receiving-sending-receiving is completely relied on to shorten the query cycle M to the shortest, and the advantage is that, in the normal communication, M completely depends on the hardware performance, and there is no redundant waiting and delay (through tests, the time of each query of 1000 instructions can be controlled within 600 milliseconds under the first strategy); and the disadvantage of the strategy is that when the reply of a query instruction is slow, the subsequent query instruction will be delayed, and even the cycle of the query queue will be interrupted. Although some delay waiting strategies can be added, such as setting a maximum timeout time for each query, but in actual situation, the time is not easy to determine uniformly, and the effect in the worst case is that each instruction is timed out, which will also lead to a slow whole.

[0037] The second strategy is to let each query instruction have a time interval to constrain the start of the next query instruction, and no matter whether the query instruction has been replied, the next query instruction will be triggered when the time interval is reached. For example: the interval time of each instruction relative to the next instruction is defined as G, the Nth query instruction A is sent at T time, 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; the N+1th query instruction B is sent at T+30, the G of B is 60 milliseconds, query reply B1 is obtained at T+34, and query reply B2 is obtained at T+37; the N+2th query instruction C is sent at T+90……and so on. In the second strategy, an algorithm close to the actual instruction delay needs to be found to calculate the G value of each instruction, which needs to be as small as possible under the condition of being greater than or equal to the actual delay, so as to ensure that M is the smallest. The advantage of the second strategy is that multiple queries do not affect each other, and the local response being slow will not cause the whole to be slow; and the disadvantage is that there will be a little useless waiting time in the middle.

[0038] At present, the second strategy is adopted in the middle layer, because the global stability is ensured at the cost of part of the time. According to the actual test results below, the relationship between the number of queries e and the delay d can be roughly calculated as d=3.3c, which is sufficient to cover most query scenarios and reduce the waiting gap as much as possible.

[0039]

[0040] Analyse:

[0041] In actual scenarios, multiple device types need to be defined to achieve different functional requirements. For example, the middle layer needs to query information 1 of A-class devices, so a query instruction for querying information 1 of A-class devices is added to the query queue, or the third setting item of B devices needs to be set, so a query instruction for setting the third setting item of B devices is added. In actual scenarios, there are about ten device types, and each device type has several to several hundred different information or setting items. When the application is started, according to the configured device types and device quantities, a module for processing the business of the corresponding device type is established, which is called an analysis class. Each analysis class defines the information to be queried by the device, and when it needs to be added to the instruction queue of the port program, it also defines the allowed setting items. Each analysis class has the same function of receiving and displaying layer query requests and replying to the requests. In the query instruction queue, after a query instruction is executed, the corresponding query reply is read from the port, and the data is cached to the analysis class of the corresponding device type according to the device type of the instruction.

[0042] (2) For the display layer

[0043] MainService:

[0044] The display layer calls the function of the middle layer, and needs to create a core built-in in the middle layer, which is called the main service. When the main service is created, it will initialize all related resources, including port opening, analysis class creation and initialization, etc. The main service will receive the instructions sent by the display layer, and will reply to the display layer with the corresponding reply instructions; after the port is opened, it will start to execute the instruction queue in an infinite loop.

[0045] When the display layer sends an instruction, it will send the instruction to the corresponding device analysis class for execution according to the device type and instruction type of the instruction; the analysis class will reply the result to the main service after execution, and then the main service will reply to the display layer, completing the entire process.

[0046] init:

[0047] Using this program, you need to call the startService method in the Application or Activity of the Android project to start MainService. After the startService binding is successful, call the setCallback method of MainService, passing in a Response interface. Response has two main interface methods: one is pushResponse (byte[] data), which will call MainService to reply to the data of the display layer; the other is void pushStatus (byte[] data), which can tell the display layer about the data changes when the middle layer has data changes.

[0048] Configuration (config):

[0049] After successful initialization, you need to configure MainService with parameters including but not limited to the following to tell the middle layer about the current running requirements, which can provide more use scenarios.

[0050] setWhiteListPush, white list - used to tell the middle layer which device and which address value change needs to be actively pushed to the display layer.

[0051] startWatchDogTask, watchdog - start the watchdog thread of the middle layer; after the thread is started, the display layer needs to call the feedDog method every 1 minute. This function is to ensure that when the display layer is unresponsive and causes program function failure, the middle layer can perceive and restart to recover program function.

[0052] setDeviceConfig, device tree - you need to configure the type and number of devices that need to be started in the middle layer. Because this program is used in multiple different projects, the actual use project needs to define the function of the middle layer.

[0053] Usage:

[0054] The main functions of using this program are sending data, receiving data, and initiating burning. The information communicated between the display layer and the middle layer is called instructions, and the display layer communicates to the middle layer is called sending instructions, and the middle layer communicates to the display layer is called reply instructions.

[0055] Send data:

[0056] The actual operation of sending the instruction is to call the method of sending data, that is, to call the cmdSend(byte[]) method of MainService. The method passes in a byte array, and the byte array contains the information of the instruction. The sending instruction sent by the display layer has five types: query data instruction, setting instruction, query record instruction, query database instruction, and delete database instruction. These five instructions all need to call the cmdSend method to complete the sending. The format of the array of each instruction is different, and the array is assembled according to the respective format agreed by the middle layer.

[0057] The query instruction can query the values of all addresses from X address to Y address 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, which contains the start address and the end address.

[0058] The setting instruction can set a specified value to a certain address. For example, to set the value of address 1003 of 005F00 to 4, the content sent is 005F001003020004, which contains the address to be set, the length of the value, and the specific value.

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

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

[0061] The delete database instruction can delete all data in the database, and can only accept one type, with the format 0001, representing deleting all the database.

[0062] Receiving data:

[0063] The receiving data refers to the process of receiving two methods of pushResponse and pushStatus from the Callback interface of MainService. All the reply instructions of the sending instructions are returned from the pushResponse method, and each sending instruction corresponds to a special data format of the reply instruction. For example, the data corresponding to the reply query instruction of the query instruction contains the data content to be queried by the query instruction. The reply instruction corresponding to the setting instruction contains the execution result of the setting instruction. The pushStatus method will call the white list address configured during initialization, and when the value of the white list address in the middle layer changes, the display layer will be notified through the callback pushStatus method to facilitate the display layer to respond to the data change in real time.

[0064] Through the above scheme, the key point of the present application is:

[0065] Because the program of the port is relatively simple, and the function to be realized is very complex, multi-layer encapsulation is realized, other port programs are also compatible, quick switching of projects, adding new projects, increasing expansion and debuggability can be realized; the present application creates an analysis class for each device type, and realizes the corresponding function in each analysis class; the present application isolates the display layer from the bottom layer hardware through the middle layer, avoids the confusion of code function logic, and is convenient for development and debugging. Because of the performance limitation of the bottom layer hardware, the delay of the transmitted data fluctuates, the actual delay rule is summarized, and a special algorithm is calculated to ensure that the query amount is unchanged and the delay is minimized.

[0066] Therefore, the present application can realize the following technical effects:

[0067] The present application can be used as an intermediate link between the bottom layer hardware and the display layer and run on the Android screen, and has low memory resource occupation and storage, and only occupies about 10 to 20M memory for a long time independent running; the instruction queue has high execution efficiency, and on the basis of being limited by the performance of the Android hardware device, 100 query instructions only take 0.2-0.3 seconds; compared with the traditional industrialized Android screen project, it is easier to expand and debug, and the present application has been actually applied to 5 project simultaneous development and debugging, and various complex requirements are expanded.

[0068] The above embodiments and drawings do not limit the product shape and style of the present application, and any appropriate changes or modifications made by those skilled in the art shall be considered as not departing from the patent scope of the present application.

Claims

1. An intermediate layer service implementation mode for simplifying application layer device access and data processing based on Android, characterized in that: the intermediate layer receives instructions from the display layer and sends instructions to the underlying hardware; for the underlying hardware: a table is defined in the logic of the underlying hardware, in which table, each device is configured with a plurality of addresses, and the device has a corresponding device ID, and the address has a corresponding address ID; the underlying hardware has a port for communicating with the intermediate layer, and the port is preconfigured with rules; the intermediate layer sends sending instructions to the underlying hardware according to the rules and receives reply instructions from the underlying hardware, and the types of instructions include query, setting and burning; the program of the port establishes a corresponding instruction queue for each type of instruction; in the query instruction queue, a corresponding time interval is set according to the type of the query instruction, and the next query instruction will be triggered when the sending time of the query instruction reaches the corresponding time interval; and in the query instruction queue, after the execution of a query instruction, the intermediate layer reads the corresponding query reply from the port and caches the data of the query reply in the analysis class corresponding to the device type according to the device type of the query instruction; for the display layer: when the display layer calls the intermediate layer, a main service is created, and all related resources are initialized, including port opening and analysis class creation and initialization; the main service receives instructions from the display layer and makes corresponding replies; after the port is opened, the instruction queue is executed in an infinite loop; the display layer sends sending instructions to the intermediate layer and receives reply instructions from the intermediate layer, and the types of instructions include sending data, receiving data and initiating burning.

2. The intermediate layer service implementation mode for simplifying application layer device access and data processing based on Android according to claim 1, characterized in that: in the instruction queue established by the program of the port, the priority is burning, setting and query in sequence.

3. The intermediate layer service implementation mode for simplifying application layer device access and data processing based on Android according to claim 1, characterized in that: when the main service receives instructions from the display layer, it sends the instructions to the corresponding device analysis class for execution according to the device type and instruction type of the instructions, and the analysis class returns the results to the main service after execution, and the main service returns the results to the display layer.

4. The intermediate layer service implementation mode for simplifying application layer device access and data processing based on Android according to claim 1, characterized in that: ​ ​ ​ ​ ​ ​ ​ The main service is created, the startService method is called in the Application or Activity of the Android project to start MainService; after the startService binding is successful, the setCallback method of MainService is called, and the Response interface is transmitted; the Response includes two interface method pushResponse (byte[] data) and void pushStatus (byte[] data).

5. The intermediate layer service implementation method for simplifying application layer device access and data processing based on Android according to claim 4, characterized in that: The display layer configures parameters setWhiteListPush, startWatchDogTask and setDeviceConfig to MainService after completing initialization.

6. The intermediate layer service implementation method for simplifying application layer device access and data processing based on Android according to claim 4, characterized in that: When the instruction is for sending data, the cmdSend (byte[]) method of MainService is called, including a query data instruction, a setting instruction, a query record instruction, a query database instruction and a delete database instruction; when the instruction is for receiving data, data transmitted by the two methods pushResponse and pushStatus in the Callback interface of MainService is received, pushResponse replies data content related to the instruction, and pushStatus calls the white list address configured during initialization.

Citation Information

Patent Citations

  • Universal serial device communication module based on Android system

    CN103353839A

  • Real-time EtherCAT master station implementation method of Window platform

    CN110620712A