Transaction positioning acquisition method, transaction method and electronic equipment

Abstract

The invention discloses a transaction positioning acquisition method, a transaction method and electronic equipment. Creating a main thread, wherein the main thread is used for executing a transaction process; the main thread is utilized to create a sub-thread, the sub-thread is parallel to the main thread, and the sub-thread is used for obtaining positioning information of the transaction terminal and storing the positioning information in a cache; and in the process of executing the transaction process by the main thread, when a positioning data demand is triggered, obtaining positioning information from the cache. In the process of acquiring the positioning information by the sub-thread, the main thread can normally execute the transaction process without suspending a result waiting for the acquisition of the positioning information, so that the execution process is accelerated, and the sub-thread directly stores the positioning information in the cache for the main thread to acquire after acquiring the positioning information. According to the technical scheme, the main thread can obtain the positioning information from the cache when the positioning data requirement is triggered, if the positioning data meet the use condition, the sub-thread cannot be triggered again to obtain the positioning information, and consumption of positioning resources is reduced.

Description

Technical Field

[0001] The present invention relates to the field of terminal technology, and in particular to a transaction positioning acquisition method, a transaction method and an electronic device. Background Art

[0002] As transaction security requirements increase, obtaining location information during transactions to assist in security judgment has become a common technical means. However, in related technologies, the location acquisition process is usually directly embedded in the transaction execution process, which increases the time consumption and may also fail. At the same time, after successful positioning, positioning resources will be consumed, increasing the execution cost. Summary of the invention

[0003] The technical problem to be solved by the present invention is to provide a transaction positioning acquisition method, a transaction method and an electronic device, so as to improve the efficiency of acquiring positioning data during the transaction process and save costs.

[0004] In order to solve the above technical problems, a technical solution adopted by the present invention is: A transaction location acquisition method, used in a transaction terminal, comprising: Create a main thread, which is used to execute the transaction process; Using the main thread to create a sub-thread, the sub-thread is parallel to the main thread, and the sub-thread is used to obtain the location information of the transaction terminal and store it in a cache; During the process of executing the transaction process by the main thread, when a positioning data demand is triggered, the positioning information is obtained from the cache.

[0005] In order to solve the above technical problems, another technical solution adopted by the present invention is: A transaction method, used in a transaction terminal, comprising: when executing a transaction step through a main thread, obtaining positioning data in parallel using a transaction positioning method as described above; When sending a transaction message through the main thread, the positioning data is obtained, and the positioning data and the transaction message are sent together.

[0006] In order to solve the above technical problems, another technical solution adopted by the present invention is: An electronic device comprises a memory, a processor and a computer program stored in the memory and running on the processor, wherein the processor implements each step of the above-mentioned transaction location acquisition method when executing the computer program.

[0007] The beneficial effects of the present invention are as follows: the present application creates a main thread for executing a transaction process; uses the main thread to create a child thread parallel to the main thread to obtain positioning information. During the process of the child thread obtaining the positioning information, the main thread can normally execute the transaction process without suspending to wait for the result of the positioning information acquisition, thereby speeding up the execution process and improving the efficiency of obtaining positioning data; and after obtaining the positioning information, the child thread directly stores it in the cache for the main thread to obtain. After obtaining the positioning information, the child thread does not need the main thread to verify it immediately. The main thread can obtain the positioning information from the cache when the positioning data demand is triggered. If the positioning data meets the use conditions, the child thread will not be triggered again to obtain the positioning information, thereby reducing the consumption of positioning resources and saving costs. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1 A flowchart of a transaction location acquisition method provided by an embodiment of the present invention; Figure 2 A flow chart of the steps of the main thread in a transaction location acquisition method provided by an embodiment of the present invention; Figure 3 A flowchart of the steps of a sub-thread in a transaction location acquisition method provided by an embodiment of the present invention; Figure 4 An architecture diagram for implementing a transaction process in OpenHarmony provided in an embodiment of the present invention; Figure 5 An architecture diagram of a transaction location acquisition method implemented in OpenHarmony provided in an embodiment of the present invention; Figure 6 A timing diagram of a transaction location acquisition method implemented in OpenHarmony provided by an embodiment of the present invention; Figure 7 A flow chart of the steps of a transaction method in the prior art; Figure 8 A flowchart of a transaction method provided by an embodiment of the present invention; Fig. 9 A schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0009] In order to make the technical problems, technical solutions and beneficial effects to be solved by the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0010] In the following description, specific details such as specific system structures, technologies, etc. are provided for the purpose of illustration rather than limitation, so as to provide a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application may also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to prevent unnecessary details from obstructing the description of the present application.

[0011] It should be understood that when used in the present specification and the appended claims, the term "comprising" indicates the presence of described features, integers, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or combinations thereof.

[0012] References to "one embodiment" or "some embodiments" etc. described in the specification of this application mean that one or more embodiments of the present application include specific features, structures or characteristics described in conjunction with the embodiment. Therefore, the statements "in one embodiment", "in some embodiments", "in some other embodiments", "in some other embodiments", etc. that appear in different places in this specification do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in other ways. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized in other ways.

[0013] In the related art, it is necessary to obtain location information during the transaction to further confirm the security of the transaction, and in the related standards, there are also mandatory regulations that the geographical location of the financial payment terminal needs to be obtained during the transaction. In the related art, usually after the transaction process is executed, a separate process for obtaining the location is constructed, and the location is added to the transaction message. In this way, it is necessary to wait for the location to be obtained after the transaction process is executed, which prolongs the time to process the transaction process. And the additional step of obtaining the location may also fail to execute, thereby further increasing the retry time. In addition, successful positioning will consume positioning resources. If positioning data is required for each transaction in the related art, each transaction will consume positioning resources, increasing costs.

[0014] Furthermore, for terminals that use the Stage model in OpenHarmony, the callbacks of the application code, including event processing and lifecycle management, all run in the main thread. Therefore, if the process of obtaining the terminal's geographic location is directly introduced in the transaction steps, the entire process will also be executed in the main thread in the set order. In addition, the terminal's geographic location positioning is time-consuming in most cases and there is a probability of failure. After failure, it is necessary to retry the step of obtaining the geographic location positioning, which increases the time required to complete the overall transaction process.

[0015] Moreover, in transaction scenarios, payments are usually made through special financial payment terminals in indoor scenarios, such as through POS machines or cash registers. However, it is usually impossible to locate indoors through signals from satellite positioning systems such as GPS, so it is necessary to use network positioning to obtain the current location of the terminal, that is, to collect relevant data such as the current wireless network and base station information around the terminal and send it to the positioning service provider through the network. The positioning service provider calculates the terminal location based on the data and returns it. The mainstream market for this positioning interface charges according to the number of times, so each successful acquisition of the terminal's geographic location in the above-mentioned modified transaction process means consuming positioning resources once, increasing transaction costs.

[0016] The terms used in this application are explained as follows: The OpenHarmony system provides two application models for developers to use: 1. FA (Feature Ability) model: a model supported by API 7.

[0017] 2. Stage model: A new model added in API 9. In this model, since classes such as AbilityStage (when the basic unit of application installation HAP is first loaded into the process, a one-to-one AbilityStage instance is created) and WindowStage (which plays the role of a window manager within the application process and contains a main window) are provided as the "stage" for application components and Window windows, this application model is called the Stage model.

[0018] Main thread: There are three main types of threads under the Stage model: main thread, TaskPool Worker thread, and Worker thread. The main thread is mainly responsible for executing UI drawing and processing callbacks of application code, including event processing and life cycle management. TaskPool Worker thread and Worker thread are created in the main thread and are independent of the main thread. The multi-threaded operating environment of the two is different, namely TaskPool and Worker. Further explanations have been disclosed in detail in the official documentation and will not be repeated here.

[0019] Ability application components: Application components are the basic units of applications. The Stage model provides two types of components: UIAbility and ExtensionAbility. The UIAbility component is an application component that contains a UI and is mainly used to interact with users. The ExtensionAbility component is an application component provided based on specific scenarios (such as service cards, input methods, etc.) to meet more usage scenarios. MainAbility is the startup page of the program, and OuterAbility is the output page of the program. You can choose whether to configure it based on the actual situation.

[0020] Module: An application contains one or more modules. Module is the basic functional unit of an application / service, and includes source code, resource files, third-party libraries, and application / service configuration files. Modules are divided into two types: "Ability" and "Library". "Ability" type modules correspond to compiled HAP (Harmony AbilityPackage); "Library" type modules correspond to HAR (Harmony Archive). HAR can be used to share related codes among multiple modules or multiple projects. Unlike HAP, HAR cannot be installed and run independently on a device and can only be referenced as a dependency of an application module.

[0021] ServiceExtensionAbility: ServiceExtensionAbility is an ExtensionAbility application component provided by OpenHarmony. It provides background service capabilities and can be started or connected by other components. It can process related transactions in the background according to the caller's request information. The connect / disconnect operation can only be performed in the main thread, and cannot be performed in child threads such as Worker and TaskPool.

[0022] In order to solve the above problems, the present application provides a transaction location acquisition method, a transaction method and an electronic device. The following specifically introduces a transaction location acquisition method of the present application.

[0023] The transaction location acquisition method in the present application can be used in various payment terminals using the OpenHarmony system, such as POS machines, cash registers and other devices.

[0024] The transaction location acquisition method of the present invention is described in detail below, including steps S110-S130.

[0025] S110. Create a main thread, which is used to execute the transaction process.

[0026] S120: Use the main thread to create a sub-thread, the sub-thread is parallel to the main thread, and the sub-thread is used to obtain the location information of the transaction terminal and store it in the cache.

[0027] In one embodiment of the present application, step S120 includes steps S121 and S122: S121. Send a positioning request to the child thread through the main thread and record the current time as the request time.

[0028] In one embodiment of the present application, the execution of step S121 of the present application may have a prerequisite, that is, during the execution of the transaction process by the main thread, a forced real-time positioning flag is obtained, and if the forced real-time positioning flag indicates that it is turned on, S121 is executed. If the forced real-time positioning flag is turned on (true) here, it means that before sending the transaction message, this transaction requires real-time positioning, that is, the positioning time corresponding to the positioning data must be after the start time of the transaction process. In this way, if the forced real-time positioning flag is turned on in the transaction process during the execution of the transaction process by the main thread, it means that the transaction has a high timeliness requirement for the positioning data. At this time, a positioning request is sent to the child thread, that is, the positioning data is obtained in real time during the execution of the transaction process, meeting the high timeliness requirement. At the same time, in the scenario where the positioning timeliness requirement is high, the child thread is triggered separately to obtain positioning information for the transaction process during the execution of the transaction process, avoiding invalid triggering of the child thread and thus avoiding the waste of positioning resources and computing resources.

[0029] In one embodiment of the present application, before step S121, it also includes receiving a configuration request, and setting the state of the mandatory real-time positioning flag to on or off according to the configuration request. In this way, the user can configure the mandatory real-time positioning flag to be on or off according to different timeliness requirements, for example, in the transaction process of the main thread, so as to adapt to different transaction scenarios.

[0030] S122. When the child thread obtains the positioning request, it obtains the positioning data of the transaction terminal and records the positioning time, and associates the positioning data and the positioning time as positioning information and stores them in the cache.

[0031] In one embodiment of the present application, step S122 includes step 1221: Step 1221: Record the current time as the positioning time and associate the positioning time and positioning data as positioning information and store them in the cache. In this way, the child thread starts to obtain positioning data only after obtaining the positioning request, which reduces the number of times to obtain positioning data, thereby reducing the consumption of positioning resources; and while obtaining positioning data, record the current time as the positioning time corresponding to the positioning data, because if the positioning time is too long from the request time, the terminal may be moved and needs to obtain the positioning data again; therefore, recording the positioning time corresponding to the positioning data facilitates the judgment of the timeliness of the positioning data.

[0032] In an optional implementation, after obtaining the positioning data and the corresponding positioning time in step 1221, it is determined whether a stop positioning request sent by the main thread is received, and if so, the process in the child thread is terminated. In this way, the main thread needs to determine whether the positioning information in the current cache can be used before sending the transaction message. If the child thread updates the cache during the determination process, it will affect the determination result. Therefore, the main thread sends a stop positioning request to the child thread before making a determination. The child thread first determines whether a stop positioning request is obtained before storing the obtained positioning information in the cache. If so, the positioning information is not stored in the cache, so as to avoid affecting the determination result of the main thread.

[0033] Through the steps in S121-S122, when the main thread sends a positioning request to the child thread, the current time is recorded as the request time. When the positioning data is sent subsequently, it can be determined whether the positioning data is obtained in this transaction process based on the request time and the positioning time corresponding to the positioning data, so that the execution process can be adjusted according to different requirements for the time limit of the positioning data.

[0034] S130. When the positioning data requirement is triggered during the execution of the transaction process by the main thread, the positioning information is obtained from the cache.

[0035] In S130, when the positioning data demand is triggered, obtaining the positioning information from the cache includes: when sending a transaction message through the main thread, obtaining the positioning time of the positioning information in the cache, judging whether the positioning data in the positioning information is valid according to the positioning time and the request time, and if valid, obtaining the positioning data from the cache and writing it into the transaction message, otherwise, re-obtaining the positioning data. In this way, when sending a transaction message, verifying the positioning time in the positioning information and the previously obtained request time, it is possible to match different rules for judging whether the positioning data is valid according to different time limit requirements, and realize customized verification of the timeliness of the positioning data.

[0036] In one embodiment of the present application, the method for determining whether the positioning data in the positioning information is valid according to the positioning time and the request time in step S130 includes steps S131-S133: S131. If the forced real-time positioning flag is turned on, determine whether the positioning time is after the request time. If so, the positioning data is valid, otherwise, the positioning data is invalid.

[0037] S132: If the forced real-time positioning flag indicates closed, the process further includes obtaining the effective duration in the cache and then executing S133.

[0038] S133. Calculate the difference between the current time and the positioning time. If the difference does not exceed the valid time, the positioning data is valid; otherwise, the positioning data is invalid.

[0039] Through the steps in S131-S133, different methods of determining whether the positioning data is valid are used for different states of the mandatory real-time positioning flag. If the mandatory real-time positioning flag indicates that it is turned on, it means that the transaction process has high requirements for the timeliness of the positioning data. At this time, the positioning time in the positioning information is compared to see if it is after the request time. If it is after the request time, it means that the positioning data is synchronously obtained during the execution of this transaction process, and the high timeliness requirement is met; if the positioning time is not after the request time, it means that the positioning data is not obtained during the execution of this transaction process, and the high timeliness requirement is not met, and the positioning data is invalid. If the forced real-time positioning flag indicates off, it means that the transaction process has low requirements on the timeliness of the positioning data. At this time, the difference between the positioning time and the current time in the positioning information is compared. That is, as long as the difference between the positioning time and the current time does not exceed the effective duration, there is no mandatory restriction that the positioning data must be obtained during the execution of this transaction process. Therefore, when the timeliness requirement is low, there is no need to obtain the positioning data once during each transaction process execution. As long as the difference between the positioning time in the cached positioning information and the current time does not exceed the effective duration, the positioning data in the positioning information can be used, which reduces the number of times the positioning data is obtained, thereby reducing the cost and waiting time.

[0040] In one embodiment of the present application, re-acquiring the positioning data in S130 includes requesting to obtain the positioning data through the main thread. In this way, if the positioning data is invalid, the positioning data is requested to be obtained through the main thread. At this time, the transaction process in the main thread has been completed, and only the positioning data needs to be waited for to send the transaction message. If the positioning data is obtained again through the child thread, the communication time between the main thread and the child thread is increased. Therefore, if the positioning data in the cache is invalid, the positioning data is directly obtained through the main thread to speed up the process.

[0041] In one embodiment of the present application, S130 further includes: when sending a transaction message through the main thread, sending a stop positioning request to the child thread through the main thread. In this way, if the main thread has sent a transaction message, it means that the required positioning data has been obtained during the execution of this transaction process, and the child thread does not need to continue to request positioning data. Therefore, when sending a transaction message, a stop positioning request is sent to the child thread, thereby avoiding the situation of repeatedly obtaining positioning data and wasting positioning resources.

[0042] In summary, the present application introduces a sub-thread, obtains positioning data through the sub-thread, and the sub-thread is parallel to the main thread. After the sub-thread obtains the positioning data, it stores the positioning data in the cache; thereby avoiding the problem of inserting the positioning steps serially into the transaction process and being executed sequentially by the main thread, increasing the execution steps of the main thread, and increasing the execution time of the steps; and introduces the positioning time corresponding to the positioning data, the positioning time and effective duration of the main thread sending the positioning request to the sub-thread; and cooperates with the forced real-time positioning flag. If forced real-time positioning is required, the positioning data is obtained during the execution of this transaction process. If forced real-time positioning is not required, the positioning data in the cache is directly obtained, and the positioning data is judged whether it is expired according to the positioning time and effective duration. If it is not expired, it is directly used, thereby reducing the number of times the positioning data is obtained, effectively saving positioning resources, and improving the execution speed of the transaction business. The transformation is easy and has little impact on the original business process of the acquiring program. High flexibility, the validity of the positioning data and the time judgment strategy can be dynamically adjusted. Take into account the real-time nature and positioning speed of the positioning data.

[0043] The following is a detailed description of the application embodiments of the present application. The present application can apply the above solution to scenarios where devices developed based on OpenHarmony need to obtain positioning data during transactions. Figure 2 , including steps (1)-(8) (1) Start the trading program in the main thread; at the same time, start the child thread through the main thread. That is, after the trading program is started, the main thread will create a worker child thread to run.

[0044] (2) When executing the preset transaction step 1, obtain whether the forced real-time positioning flag forceRealLocate is turned on (true). If so, it means that real-time positioning is required, and execute (3). Otherwise, continue to execute subsequent transaction steps. Among them, if sufficient time is required for the step of obtaining positioning data in the child thread, the forced real-time positioning flag can be obtained when executing the first transaction step.

[0045] Among them, the forced real-time positioning flag forceRealLocate is a flag pre-set outside the business process, that is, outside the transaction step. When this flag is true (true), the transaction process must perform the terminal geographic location positioning (real-time) step. Otherwise, it is decided whether to re-acquire the positioning data in this transaction process based on the positioning time and validity period of the positioning data cached in the last transaction.

[0046] (3) The main thread records the current time as the request time startTime, and the main thread notifies the child thread to perform positioning. For example, the main thread can send a positioning request to the child thread to notify the child thread to perform positioning.

[0047] Please refer to Figure 3 , after (3) includes steps ad executed by the child thread: a. After receiving the request message data, determine whether the request type is a positioning request. If so, set the positioning data acquisition flag isLocating to true and execute step b. Otherwise, set the positioning data acquisition flag isLocating to false and stop executing.

[0048] b. Determine whether isLocating is true. If so, execute step c, otherwise stop executing.

[0049] c. Get the positioning data data and positioning time as positioning information, and determine whether the main thread stops positioning. If so, end the process, otherwise execute step d; d. Store the positioning information in the cache. The positioning information can also be further persisted in the database to facilitate recording the positioning data of the terminal. The current time when the positioning data is obtained is used as the positioning time ITime.

[0050] Among them, the positioning data is the address location information of the terminal, including longitude and latitude and other data that can indicate the location of the terminal; the positioning time corresponds to the meaning of the positioning data, indicating the time when the positioning data is obtained.

[0051] (4) After executing the last transaction step, notify the child thread to stop positioning.

[0052] Positioning requests are usually time-consuming asynchronous actions. Before sending a transaction message, since the main thread does not know whether the positioning of the child thread is successful, the main thread will notify the child thread to stop positioning to avoid changes in the positioning results of the child thread during the logical judgment of the main thread on the positioning results, which will affect the subsequent logical judgment of the main thread on the positioning data. After the positioning request is completed, the child thread needs to first determine whether the main thread has stopped positioning. If it has stopped positioning, the process ends. Otherwise, the acquired positioning data and time are stored (i.e. step d).

[0053] (5) Obtain the valid time expireTime and positioning information in the cache. The positioning information includes positioning data data and the positioning time ITime corresponding to the positioning data.

[0054] Among them, the effective time can be pre-set by the user or the default value can be pre-configured in the program, which indicates the validity period of the positioning data, that is, the maximum time difference between the current time and the positioning time. If the time difference is exceeded, it means that the corresponding positioning data has expired and the positioning data needs to be obtained again.

[0055] (6) Check again whether the forced real-time positioning forceRealLocate is on (true). If so, execute (7); otherwise, execute (8).

[0056] (7) Obtain the positioning time ITime and the request time startTime, and determine whether ITime>startTime. If so, it means that the positioning time is after the request time. Add the positioning data to the transaction message and send the transaction message. Otherwise, perform positioning through the main thread.

[0057] (8) Determine whether the current time - ITime > expireTime is established. If so, it means that the duration of the positioning time has exceeded the effective time and the corresponding positioning data is invalid. Then, positioning is performed through the main thread to re-acquire the positioning data. Otherwise, it means that the duration of the positioning time has not exceeded the effective time and the positioning data is still within the effective time. The positioning data is written into the transaction message and the transaction message is sent.

[0058] Furthermore, the following example illustrates a specific implementation of a transaction location acquisition method in the present application in OpenHarmony.

[0059] The official OpenHarmony system documentation (for example, version 3.2) contains the following important restrictions on the use of worker threads (child threads): 1. Ability type modules support the use of worker threads, while Library type modules do not support the use of worker threads.

[0060] 2. Creating a Worker does not support using Worker.ts files of other modules, that is, it does not support calling Worker threads across modules.

[0061] Combining the above two points, an application can only use the Worker thread created by the Module in the Ability type Module.

[0062] In one embodiment of the present application, the transaction business code that is not related to the view is encapsulated into a library type module, which can be used by a third party or use a third-party transaction module. Therefore, the transaction program module division based on this idea is as follows Figure 4 As shown in the architecture diagram; for different transaction procedures (for example, different transaction procedures correspond to different payment methods), there may be multiple abilities in the AbilityModule based on business needs, and each ability can call the Library to execute transactions.

[0063] Reference Figure 5 ,exist Figure 4 In the architecture, a Worker sub-thread is introduced to obtain positioning data, and the Worker is placed in an Ability type Module. At the same time, a ServiceExtenstionAbility is added to the Ability type Module, which holds a Worker sub-thread that implements the positioning function. In the Stage model, all UIAbilities and ServiceExtensionAbilities in the same application run on the same main thread. MainAbility or other UIAbilities can interact with ServiceExtensionAbility through thread communication solutions such as EventHub to achieve the ability to call the positioning Worker sub-thread. Figure 4 The architecture construction can be performed before step (1) above.

[0064] When the UIAbility that references the transaction service library to execute the transaction needs to call the Worker subthread for positioning, the interaction sequence diagram of each component in the process of executing a transaction positioning acquisition method in this application is as follows Figure 6 As shown, including steps 1 to 6: Step 1: After the program starts, MainAbility starts and sends a message to ServiceExtensionAbility; Step 2: ServiceExtensionAbility creates a Worker child thread to implement the positioning function. After the creation is successful, a creation success message is returned to ServiceExtensionAbility. Step 3: After receiving the message that the Worker child thread is successfully created, ServiceExtensionAbility registers the listener message locate in EventHub; Step 4: When the preset transaction step is executed in MainAbility, the locate message is triggered; Step 5: After the locate message is triggered, EventHub calls back ServiceExtensionAbility, triggering ServiceExtensionAbility to request the Worker child thread to locate.

[0065] Step 6: After the Worker child thread completes the positioning, it returns the positioning information to the ServiceExtensionAbility, and the ServiceExtensionAbility processes the positioning result.

[0066] It can be seen that when other UIAbilities need to perform transaction operations, they only need to Figure 6 Just like MainAbility in , you can trigger the locate event through EventHub.

[0067] In summary, in the introduction of Worker sub-threads, this application uses ServiceExtendAbility and EventHub, etc., to achieve the effect of each UIAbility calling the same positioning Worker in the transaction business code when the transaction module is an independent Library Module and multiple UIAbilities, without the need to build a Worker sub-thread separately for each UIAbility.

[0068] Please refer to Figure 7 , is a flowchart of a transaction method in the related art. It can be seen that in the related art, all transaction steps are executed by the main thread. If positioning is required, the positioning step is usually added directly to the main thread, for example, the positioning step is added before sending the transaction message. In this way, the main thread needs to wait for the execution result of the positioning step before sending the transaction message, which prolongs the execution time, and each transaction process needs to execute the positioning step once.

[0069] Please refer to Figure 8 The present invention also provides a transaction method, including steps S210-S220.

[0070] S210, when executing the transaction step through the main thread, the location data is obtained in parallel using the transaction location acquisition method as described above; S220. When sending a transaction message through the main thread, obtain positioning data, and send the positioning data together with the transaction message.

[0071] This embodiment obtains positioning data through the transaction positioning method described above, and its corresponding beneficial effects have been described above and will not be repeated here. When sending a transaction message, the positioning data is sent together with the transaction message, and the time for waiting to obtain the positioning data is reduced by parallelizing the process of obtaining the positioning data and the process of executing the transaction steps.

[0072] Please refer to the figure, the present invention also provides an electronic device 300, including a memory 301 and a processor 302 and a computer program stored in the memory 301 and running on the processor 302, when the processor 302 executes the computer program, it implements the various steps in a transaction location acquisition method or a transaction method as described above.

[0073] The beneficial effects of the electronic device of the present invention are the same as those of the above method and will not be described in detail here.

[0074] The above are only embodiments of the present invention, and are not intended to limit the patent scope of the present invention. Any equivalent transformations made using the contents of the specification and drawings of the present invention, or directly or indirectly applied in related technical fields, are also included in the patent protection scope of the present invention.

Claims

1. A transaction location acquisition method, characterized in that: For a transaction terminal, the method comprises: Create a main thread, which is used to execute the transaction process; Using the main thread to create a sub-thread, the sub-thread is parallel to the main thread, and the sub-thread is used to obtain the location information of the transaction terminal and store it in a cache; During the process of executing the transaction process by the main thread, when a positioning data demand is triggered, the positioning information is obtained from the cache.

2. A transaction location acquisition method according to claim 1, characterized in that: After creating a child thread using the main thread, the method further includes: Sending a positioning request to the child thread through the main thread and recording the current time as the request time; When the child thread obtains the positioning request, it obtains the positioning data of the transaction terminal and records the positioning time, and associates the positioning data and the positioning time as positioning information and stores them in a cache; When the positioning data requirement is triggered, obtaining the positioning information from the sub-thread includes: When sending a transaction message through the main thread, the positioning time of the positioning information in the cache is obtained, and whether the positioning data in the positioning information is valid is judged according to the positioning time and the request time. If valid, the positioning data is obtained from the cache and written into the transaction message, otherwise, the positioning data is re-obtained.

3. A transaction location acquisition method according to claim 1 or 2, characterized in that: The positioning data and positioning time are associated as positioning information and stored in the cache, including: The current time is recorded as the positioning time and the positioning time and the positioning data are associated as positioning information and stored in a cache.

4. A transaction location acquisition method according to claim 2, characterized in that: After creating a child thread using the main thread, the method further includes: During the process of the main thread executing the transaction process, the forced real-time positioning flag is obtained. If the forced real-time positioning flag indicates that it is turned on, the step of sending a positioning request to the child thread through the main thread and recording the current time as the request time is executed.

5. A transaction location acquisition method according to claim 4, characterized in that: The determining whether the positioning data in the positioning information is valid according to the positioning time and the request time includes: If the mandatory real-time positioning flag indicates that it is on, then determining whether the positioning time is after the request time, if so, the positioning data is valid, otherwise, the positioning data is invalid; If the forced real-time positioning flag indicates off, the process also includes obtaining the effective time length in the cache; The difference between the current time and the positioning time is calculated. If the difference does not exceed the valid time, the positioning data is valid; otherwise, the positioning data is invalid.

6. A transaction location acquisition method according to claim 4, characterized in that: The method further comprises: A configuration request is received, and a state of the forced real-time positioning flag is set to on or off according to the configuration request.

7. A transaction location acquisition method according to claim 2, characterized in that: The reacquiring the positioning data comprises: The positioning data is obtained through the main thread request.

8. A transaction location acquisition method according to claim 2, characterized in that: When the positioning data requirement is triggered, obtaining the positioning information from the sub-thread includes: When sending a transaction message through the main thread, a stop positioning request is sent to the child thread through the main thread.

9. A trading method, characterized in that: For a transaction terminal, the method comprises: When executing the transaction step through the main thread, obtaining the positioning data in parallel using the method described in any one of claims 1 to 8; When sending a transaction message through the main thread, the positioning data is obtained, and the positioning data and the transaction message are sent together.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that: When the processor executes the computer program, the transaction location acquisition method described in any one of claims 1-8 is implemented.

Images