Data processing method and apparatus, terminal, and storage medium

By detecting version information and build records during account switching, the problem of low data utilization in logged-out accounts was solved, enabling lossless synchronization and efficient migration of user data and improving the data support capabilities of map services.

CN115268957BActive Publication Date: 2026-06-26TENCENT TECHNOLOGY (SHENZHEN) CO LTD

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
TENCENT TECHNOLOGY (SHENZHEN) CO LTD
Filing Date
2021-04-29
Publication Date
2026-06-26

AI Technical Summary

Technical Problem

Low data utilization in unlogged accounts leads to data loss when uninstalling the client or changing terminals, affecting the user experience of map services. Furthermore, existing data synchronization methods suffer from network latency, data loss, and high development complexity.

Method used

When switching accounts, the version information of user data is detected, the first record is constructed, offline and online data are obtained, user data is synchronized, blockchain is used to ensure the authenticity and credibility of the data, avoids data dependence on separate synchronization of business scenarios, and adopts incremental update method for data migration.

Benefits of technology

It achieves lossless synchronization of user data when switching accounts, avoiding data loss and network latency, reducing development complexity, and improving data utilization and user experience.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN115268957B_ABST
    Figure CN115268957B_ABST
Patent Text Reader

Abstract

Embodiments of the present application provide a data processing method and device, a terminal and a storage medium, comprising: when switching between a first state account and a second state account, detecting version information of at least one user data corresponding to the first state account; obtaining first user data corresponding to the first state account as first target data, the first user data being user data without version information; constructing a first record based on second user data corresponding to the first state account, and obtaining second target data from the second user data according to the first record, the second user data being user data with version information; and synchronizing user data between the first state account and the second state account according to the first target data and the second target data. Embodiments of the present application solve the problem of low data utilization in the related art, thereby providing more comprehensive data support for more accurately providing map services such as preferences and recommendations.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a data processing method, apparatus, terminal, and storage medium. Background Technology

[0002] With the development of computer technology, various client applications that can run on terminals have emerged to meet users' diverse needs. For example, shopping clients meet users' shopping needs, audio and video clients enable audio-visual sharing services, and map clients facilitate users' travel.

[0003] Currently, some clients are positioned as tool-type clients. This can be understood as the main business scenario of tool-type clients being to assist users. For example, map clients can be regarded as tool-type clients, which can provide navigation services such as route planning to help users reach their destinations.

[0004] Since the account login rate of tool-type clients is generally less than 30%, the data generated by users using the client without logging in may be lost when the user uninstalls the client, or cannot be migrated when the user changes devices. This results in this part of the data not being able to provide data support for map services such as preferences and recommendations, thus affecting some user experiences of map services.

[0005] This shows that the utilization rate of data in unlogged accounts urgently needs to be improved. Summary of the Invention

[0006] This application provides a data processing method, apparatus, terminal, and storage medium, which can solve the problem of low data utilization in unlogged accounts in related technologies. The technical solution is as follows:

[0007] According to one aspect of the embodiments of this application, a data processing method includes: when switching between a first state account and a second state account, detecting version information of at least one user asset data corresponding to each business domain of the first state account; obtaining first user data corresponding to the first state account as first target data, wherein the first user data is user asset data without version information as offline data; constructing a first record based on second user asset data with version information corresponding to the first state account, and obtaining second target online data from the second user asset data with version information according to the first record, wherein the second user data is user data with version information; and synchronizing user asset data between the first state account and the second state account according to the obtained offline first user target data and second target online data.

[0008] According to one aspect of the embodiments of this application, a data processing apparatus includes: a version information detection module, configured to detect version information of at least one user data corresponding to the first state account when switching between a first state account and a second state account; a first target data acquisition module, configured to acquire first user data corresponding to the first state account as first target data, wherein the first user data is user data without version information; and a second target data acquisition module, configured to construct a first record based on second user data corresponding to the first state account, and acquire second target data from the second user data according to the first record, wherein the second user data is user data with version information; and a data synchronization module, configured to synchronize user data between the first state account and the second state account according to the first target data and the second target data.

[0009] According to one aspect of the embodiments of this application, a terminal includes: at least one processor, at least one memory, and at least one communication bus, wherein the memory stores a computer program, and the processor reads the computer program from the memory through the communication bus; when the computer program is executed by the processor, it implements the data processing method described above.

[0010] According to one aspect of the embodiments of this application, a storage medium stores a computer program thereon, which, when executed by a processor, implements the data processing method described above.

[0011] According to one aspect of the embodiments of this application, a computer program product includes a computer program stored in a storage medium, a processor of a computer device reads the computer program from the storage medium, and the processor executes the computer program, causing the computer device to implement the data processing method as described above when executed.

[0012] The beneficial effects of the technical solution provided in this application are:

[0013] In the above technical solution, when the client switches between a first-state account and a second-state account, it detects the version information of at least one user data corresponding to the first-state account, obtains the first user data without version information as the first target data, and constructs a first record based on the second user data with version information. Then, based on the first record, it obtains the second target data from the second user data with version information. Finally, based on the obtained second target data and the first target data, it synchronizes the user data between the first-state account and the second-state account. Thus, as at least one user data corresponding to the first-state account is synchronized to the second-state account, this part of the user data is closely associated with the second-state account. That is, when a user enters the second-state account, they can obtain this part of the user data accordingly. This data is not lost when the user uninstalls the client, nor is it affected by the user changing terminals. This is beneficial for providing data support for map services such as preferences and recommendations, and effectively solves the problem of low data utilization in unlogged-in accounts in related technologies. Attached Figure Description

[0014] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below.

[0015] Figure 1 This is a schematic diagram based on the implementation environment involved in this application;

[0016] Figure 2 This is a flowchart illustrating a data processing method according to an exemplary embodiment;

[0017] Figures 3 to 4 This is a schematic diagram illustrating different business scenarios in a map client according to an exemplary embodiment;

[0018] Figure 5 This is a flowchart illustrating the construction process of a first record according to an exemplary embodiment;

[0019] Figure 6 This is another flowchart illustrating the construction process of a first record according to an exemplary embodiment;

[0020] Figure 7 yes Figure 2 A flowchart of step 350 in one embodiment corresponds to the following example;

[0021] Figure 8 This is a flowchart illustrating another data processing method according to an exemplary embodiment;

[0022] Figure 9 This is a flowchart illustrating a synchronization process according to an exemplary embodiment;

[0023] Figure 10 This is a flowchart illustrating a pull process according to an exemplary embodiment;

[0024] Figure 11 This is a schematic diagram of a data processing system architecture in an application scenario;

[0025] Figure 12 This is a schematic diagram of the database base class provided for the business adapter in an application scenario;

[0026] Figure 13 This is a diagram illustrating the databases of logged-in and logged-out users in an application scenario.

[0027] Figures 14a to 14e This is a schematic diagram illustrating the specific implementation of a data processing method in an application scenario;

[0028] Figure 15 This is a structural block diagram of a data processing apparatus according to an exemplary embodiment;

[0029] Figure 16 This is a hardware structure diagram of a terminal according to an exemplary embodiment;

[0030] Figure 17 This is a structural block diagram of a terminal according to an exemplary embodiment. Detailed Implementation

[0031] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain this application, and should not be construed as limiting this application.

[0032] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in this application means the presence of the stated 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 groups thereof. It should be understood that when we say an element is “connected” or “coupled” to another element, it can be directly connected or coupled to the other element, or there may be intermediate elements. Furthermore, “connected” or “coupled” as used herein can include wireless connections or wireless coupling. The term “and / or” as used herein includes all or any units and all combinations of one or more associated listed items.

[0033] It is understood that in the specific implementation of this application, any user-related data, such as user data, user accounts, status accounts, version information of user data, records of each status account, whether the user account is logged in, and data generated by the user using the client, are involved. When the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0034] In other words, if any data related to users is involved in this application embodiment, such data must be obtained with the user's authorization and consent and in accordance with the relevant laws, regulations and standards of the country and region. If sensitive personal information is involved, the processing of sensitive personal information should obtain the individual's separate consent. If the personal information of minors is involved, the consent of the minor's parents or other guardians should also be obtained. If necessary, special personal information processing rules can also be formulated and implemented only with the authorization and consent of the relevant personnel.

[0035] The following is an introduction and explanation of several terms used in this application:

[0036] The first-state account refers to a user account that is not logged in. Correspondingly, the first state means the unlogged-in state. The first-state account is usually entered by default when the client is running on the terminal. Of course, there is also a possibility that the user did not log out after logging into the second-state account last time. In this case, the user will default to the second-state account when the client is running on the terminal. In this case, the first-state account can be switched from the second-state account. Alternatively, it can be considered that when the user logs out of the second-state account, the user will default to the first-state account.

[0037] A second-state account refers to a logged-in user account. Correspondingly, the second state refers to the login state. A second-state account can be accessed by switching from a first-state account, or by switching between different second-state accounts.

[0038] A business scenario, also known as a business domain, is used to implement at least one function provided by the client to the user. In other words, different business scenarios implement different functions. In the user interface provided by the client, these are typically displayed to the user in the form of controls (buttons, drop-down menus, text boxes, etc.). For example, in a map client, the business scenario "track recording" stores routes planned for the user based on the user's input start and end points; the business scenario "my favorites" stores addresses or POIs (Points of Interest) saved by the user. Similarly, in a shopping client, the business scenario "footprints" stores products viewed by the user; the business scenario "followed stores" stores stores saved by the user.

[0039] User data belongs to different business scenarios for accounts in different statuses, and can also be understood as non-financial account data. User data is generated during the user's use of the client, including but not limited to data actively entered, selected, searched, and recorded by the user. Taking a map client as an example, when a user adds a new POI or deletes a saved POI in the "My Favorites" section of the map, the added or deleted POI is considered user data in the "My Favorites" business scenario.

[0040] As mentioned earlier, the account login rate of tool-type clients is generally less than 30%, which means that the data generated by users using the client without logging in is not utilized effectively.

[0041] For example, this data may be lost if the user uninstalls the client, or it may not be able to be migrated if the user changes their device. As a result, this data may not be able to provide data support for map services such as preferences and recommendations, thus affecting some user experiences of map services.

[0042] To improve the utilization of data in unlogged-in accounts, a data synchronization scheme has been proposed, which synchronizes the data in unlogged-in accounts with the cloud, for example, uploading the data in unlogged-in accounts to the cloud.

[0043] However, during the aforementioned data synchronization process, on the one hand, poor network signal can cause delays in data interaction and cloud synchronization updates, and even data loss. Inevitably, when users interact with related data, they will perceive the impact of data changes on the client, such as delayed data display, leading to a poor user experience. On the other hand, data synchronization between the cloud and the client typically uses a full update method, resulting in excessive data consumption for users, which also contributes to a negative user experience.

[0044] Furthermore, data synchronization is typically business-oriented, meaning that each business scenario requires separate data synchronization. As the number of business scenarios increases, the development complexity and cost will increase exponentially. Moreover, data synchronization will become overly dependent on business scenarios, which is not conducive to the access and use of other business scenarios on the client side.

[0045] Therefore, even if data synchronization is used to improve the utilization rate of data in unlogged accounts, there is still a deficiency in the ability to migrate data, resulting in very limited improvement in the utilization rate of data in unlogged accounts.

[0046] In view of this, the data processing method, apparatus, terminal and storage medium provided in this application are intended to solve the above-mentioned technical problems in the related art.

[0047] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0048] Figure 1 This is a schematic diagram of an implementation environment involved in a data processing method. The implementation environment includes a terminal 100 and a server 200.

[0049] Specifically, the terminal 100 can be run on a client device, such as a desktop computer, laptop computer, tablet computer, smartphone, smart voice interaction device, smart home appliance, vehicle terminal, or other electronic device, without any limitation.

[0050] The client, also known as a tool-type client, such as a map client, audio / video client, shopping client, etc., can be in the form of an application or a webpage. Correspondingly, the user interface of the client can be in the form of a program window or a webpage, without any limitation here.

[0051] Server 200, also known as the cloud server, can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. For example, in this implementation environment, server 200 provides cloud storage services for relevant data to terminal 100.

[0052] The server 200 and the terminal 100 establish a communication connection in advance via wired or wireless means, and data transmission between the server 200 and the terminal 100 is achieved through this communication connection. For example, the transmitted data may be user data in various business scenarios of the first-state account, user data in various business scenarios of the second-state account, or version information of the aforementioned user data.

[0053] As the client runs on terminal 100, the user can use the client through the default first-state account, thereby generating and storing user data in at least one business scenario for the first-state account.

[0054] When switching between a first-state account and a second-state account, user data from at least one business scenario in the previously generated first-state account will be synchronized to the second-state account.

[0055] Furthermore, users can use the client by switching to a second-state account, thereby generating and storing user data for at least one business scenario in the second-state account.

[0056] Through the interaction between terminal 100 and server 200, user data in at least one business scenario for either the first-state account or the second-state account will be synchronized with server 200. It is worth mentioning that during the synchronization process between terminal 100 and server 200 for user data in at least one business scenario for either the first-state account or the second-state account, the user data can be stored on a blockchain. This leverages the immutability of data on the blockchain to fully guarantee the authenticity and reliability of the synchronization process.

[0057] In the above process, without hindering user use, that is, when users operate on user data, they do not need to be aware of the impact of the changes in this user data on the client. User data in each account and business scenario of the client can be completely stored in the cloud, thereby providing more comprehensive data support for more accurate map services such as preferences and recommendations, so as to fully improve the utilization rate of user data in the first state account.

[0058] Please see Figure 2 This application provides a data processing method, which is applicable to... Figure 1 The terminal 100 in the implementation environment is shown.

[0059] In the following method embodiments, for ease of description, the execution subject of each step is described as a client running in the terminal, but this does not constitute a specific limitation.

[0060] like Figure 2 As shown, the method may include the following steps:

[0061] Step 310: When switching between the first state account and the second state account, detect the version information of at least one user data corresponding to the first state account.

[0062] First, it should be noted that the first state account refers to a user account that is not logged in, and the second state account refers to a user account that is logged in. Correspondingly, the first state refers to the state of not being logged in, and the second state refers to the state of being logged in.

[0063] As mentioned earlier, when the client is running on the terminal, it usually defaults to the first state account. Of course, another possibility is that the user did not log out after logging into the second state account last time. In this case, when the client is running on the terminal, it defaults to the second state account from the previous login. In this case, the first state account can be switched to from the second state account. Alternatively, it can be considered that when the user logs out of the second state account, it defaults to the first state account.

[0064] Therefore, in this embodiment, the client switching between the first state account and the second state account means that the client switches from the first state account to the second state account.

[0065] Upon accessing a first-state account, a user can use the client through that first-state account, thereby generating at least one set of user data corresponding to that first-state account. In one possible implementation, the at least one set of user data corresponding to the first-state account includes user data from at least one business scenario for that first-state account.

[0066] Specifically, the process of generating this user data may include the following steps: detecting write operations for at least one business scenario of the first state account; if a write operation is detected, then processing the user data in at least one business scenario of the first state account based on the write operation.

[0067] Write operations include, but are not limited to, adding, modifying, and deleting operations. Correspondingly, related processing includes, but is not limited to, adding user data, modifying user data, and deleting user data.

[0068] Taking a map client as an example, Figures 3 to 4 The illustration shows a diagram illustrating different business scenarios in a map client. For example, such as... Figure 3 As shown, the client displays the business scenario "My Favorites". If the user selects "Edit", the terminal can detect the modification operation for "My Favorites" in that business scenario and thus modify the user data (e.g., "Home") within "My Favorites". For example, in... Figure 4 In the client, the business scenario "Trajectory Records" is displayed. If the user selects "Clear", the terminal can detect the deletion operation for the business scenario "Trajectory Records" and delete all user data in the business scenario "Trajectory Records".

[0069] It should be noted that the writing operation method will vary depending on the input component configured on the terminal. For example, on a smartphone with touch screen input, the writing operation can be performed using gestures such as clicking and swiping. Alternatively, on a laptop equipped with a mouse, the writing operation can be performed using mechanical operations such as dragging, clicking, and double-clicking.

[0070] Similarly, when switching from a first-state account to a second-state account, the user can use the client through the second-state account, thereby generating user data in at least one business scenario for the second-state account.

[0071] As the aforementioned user data is generated, it can be stored in different designated storage areas to avoid data synchronization relying on business logic when switching accounts, thereby facilitating access and use in different business scenarios.

[0072] For example, if the specified storage area includes a database of unlogged-in users (DB) and a database of logged-in users, then the user data for each business scenario of the first-state account is stored in the database of unlogged-in users, and the user data for each business scenario of the second-state account is stored in the database of logged-in users.

[0073] Secondly, version information indicates the synchronization time of user data in the cloud. It can be understood that the later the user data is synchronized in the cloud, the more recent the version information.

[0074] In one possible implementation, the version information includes at least a version number. The version number uniquely corresponds to the user data; in other words, the version number of user data for different accounts in the same business scenario is different, and the version number of user data for the same account in different business scenarios is also different.

[0075] In one possible implementation, the method for obtaining the version number may include the following steps: synchronizing user data with the cloud for each business scenario of the first-state account / second-state account; and receiving the version number of the synchronized user data returned by the cloud. In other words, from the cloud's perspective, a version number will be assigned to the user data of the first-state account / second-state account synchronized to the cloud for each business scenario.

[0076] In one possible implementation, the generation of the version number may include the following steps: The cloud determines the timestamp corresponding to the write operation that generated the user data for which synchronization is requested; the timestamp is encrypted using an encryption algorithm (e.g., a hash function) to obtain the version number of the user data. It should be noted that the user data for which synchronization is requested can be user data from various business scenarios of a first-state account, or user data from various business scenarios of a second-state account.

[0077] In one possible implementation, the later the user data is synchronized in the cloud, the larger the version number assigned to that user data by the cloud.

[0078] Step 330: Obtain the first user data corresponding to the first state account as the first target data.

[0079] The first user data is user data for which there is no version information.

[0080] As mentioned earlier, during data synchronization, poor network signal may cause delays in data interaction and cloud synchronization updates, or even loss of synchronized data.

[0081] Therefore, in this embodiment, data synchronization first involves storing user data in a designated storage area, and then, when the network signal is good, synchronizing the user data in the designated storage area with the cloud at a set time.

[0082] In one possible implementation, the timing can refer to the client starting up and running on the terminal, or it can be every 5 minutes while the client is running on the terminal. Of course, the interval is not limited to 5 minutes and can be flexibly adjusted according to the actual needs of the application scenario; this is not intended to constitute a specific limitation.

[0083] As shown above, user data is synchronized to the cloud only when the network signal is strong, and the cloud assigns a version number accordingly. Conversely, when the network signal is weak, user data is stored in a designated storage area and is not synchronized with the cloud. Consequently, the user data cannot obtain a version number assigned by the cloud.

[0084] In this scenario, the user data that needs to be synchronized with the second-state account includes the first target data. The first target data refers to the first user data in each business scenario of the first-state account that does not yet have a version number. Alternatively, it can be understood as the user data in each business scenario of the first-state account that has not yet been synchronized with the cloud.

[0085] Taking a map client as an example, when a user is driving, they plan and navigate using a map client running on their smartphone without logging into their account. When the network signal is strong, the user data generated by the map client for business scenario A without logging into their account (first-state account) includes A1, A2, and A3. This user data will be synchronized to the cloud and assigned corresponding version numbers 11, 12, and 13 by the cloud.

[0086] As a vehicle moves, such as entering an underground parking lot, network signal may be weak. During this time, user data related to business scenario A, including A4, may be generated. Because user data A4 cannot be synchronized with the cloud, it cannot obtain the version number assigned by the cloud. As the user moves, such as entering a shopping mall, network signal may be restored, and user data related to business scenario A, such as A5, may be generated.

[0087] As the network signal improves, both user data A4 and A5 need to be synchronized with the cloud to obtain a version number assigned by the cloud, with user data A4 taking priority over user data A5 in version number assignment. At this point, if the user logs in, both user data A4 and A5 will be used as the primary target data for data synchronization with the logged-in user account (the second-state account).

[0088] Step 350: Construct a first record based on the second user data corresponding to the first state account, and obtain the second target data from the second user data according to the first record.

[0089] The second target data is user data with version information.

[0090] It should be understood that as users spend more time in their first-state accounts, the user data across different business scenarios within those accounts may also be updated. For example, a user might be added, modified, or deleted. When network signal is good, this updated user data will be synchronized to the cloud, receiving a version number assigned by the cloud. In other words, there may be multiple sets of user data with version numbers across different business scenarios within a first-state account; these different version numbers indicate the synchronization time of the corresponding user data in the cloud.

[0091] Therefore, in this embodiment, the first record is used to represent the latest version information of user data in at least one business scenario of the first state account. In one possible implementation, the first record is used to represent the maximum version number of user data in at least one business scenario of the first state account.

[0092] Specifically, such as Figure 5 As shown, the process of constructing the first record may include the following steps:

[0093] Step 351: Obtain the account identifier of the first-state account.

[0094] The account identifier is used to uniquely identify the first-state account. It should be noted that the account identifier of the first-state account is also considered to be the account identifier of the user account that is not logged in. After the client is installed on the terminal, it is created when the client is first launched and run on the terminal, and remains unchanged until the client is uninstalled by the user. Therefore, the account identifier of the first-state account remains unchanged from the time the client is installed to the time it is uninstalled.

[0095] Step 352: Obtain the maximum version number of user data in each business scenario of the first state account.

[0096] Step 353: Generate the first record based on the account identifier and maximum version number of the first state account.

[0097] For example, suppose the first-state account includes business scenario A and business scenario B.

[0098] For business scenario A, user data A1 has version number 11, user data A2 has version number 12, user data A3 has version number 13, and user data A4 has no version number.

[0099] For business scenario B, the version number of user data B1 is 21, the version number of user data B2 is 22, and the version number of user data B3 is 23.

[0100] For each business scenario, the larger the version number, the newer the version information of the user data. Therefore, the first record can be represented as: the account identifier uid of the first state account - business scenario A: 13 - business scenario B: 23.

[0101] Therefore, by introducing the first record, the latest user data synchronized to the cloud in each business scenario of the first state account can be determined, such as user data A3 and user data B3 in the example above.

[0102] After identifying the first record, the second target data can be further obtained from the second user data containing version information. The second target data refers to the user data of the first-state account that has version numbers in various business scenarios and needs to be synchronized.

[0103] In one possible implementation, second target data is obtained based on second user data with version information existing in various business scenarios of the first-state account stored locally, thereby achieving a simple and efficient physical copy of user data. In another possible implementation, second target data is obtained based on second user data with version information existing in various business scenarios of the first-state account synchronized in the cloud, thereby saving local storage resources, reducing user device costs, and ultimately improving the user experience.

[0104] Using the example above, assuming that user data A1 and A2 in business scenario A have been synchronized to the second state account, then based on the first record, it can be determined that the second target data includes: user data A3 with a version number in business scenario A; and user data B1, B2, and B3 with version numbers in business scenario B.

[0105] It should be noted that the execution order of steps 330 and 350 is not limited to this. In other embodiments, step 350 may be executed first and then step 330 may be executed, or steps 330 and 350 may be executed simultaneously. This embodiment does not constitute a specific limitation in this regard.

[0106] Step 370: Synchronize user data between the first state account and the second state account based on the first target data and the second target data.

[0107] In this embodiment, the user data for synchronizing from the first state account to the second state account includes the first target data and / or the second target data.

[0108] Specifically, if the first target data is obtained, the first target data is synchronized from the first state account to the second state account; if the second target data is obtained, the second target data is synchronized from the first state account to the second state account.

[0109] Through the above process, users can access user data from various business scenarios in the first-state account after entering the second-state account. This data will not be lost due to the user uninstalling the client or being affected by the user changing terminals. This will help provide data support for map services such as preferences and recommendations, and effectively solve the problem of low data utilization in unlogged accounts in related technologies.

[0110] Furthermore, on the one hand, data synchronization combines online second target data and offline first target data, avoiding problems such as delays and high loss rates caused by network limitations, and achieving lossless data interaction to fully guarantee the smoothness of user operations; on the other hand, by introducing a first record for user data in each business scenario of the first state account, each business scenario no longer needs to perform data synchronization separately, avoiding problems such as excessive development costs and excessive development complexity caused by limitations of business scenarios, and thus improving the data migration capability between different accounts.

[0111] Please see Figure 6 This application embodiment provides a possible implementation method. The construction process of the first record in step 350 may further include the following steps:

[0112] Step 354: Obtain the first marker indicating whether the user agrees to upload user data to the cloud.

[0113] The first flag indicates whether the user agrees to upload user data from various business scenarios of the first-state account to the cloud.

[0114] It should be understood that data generated by users using the client without logging into their accounts may involve user privacy or other security issues. Therefore, the first tag can effectively protect the privacy and security of user data.

[0115] Step 355: Obtain whether the user data has been synchronized to the second tag of the second state account.

[0116] The second marker is used to indicate whether user data in each business scenario of the first state account has been synchronized to the second state account, thereby preventing duplicate copying of user data and improving data processing efficiency.

[0117] It should be noted that the execution order of steps 354 and 355 is not limited to this. In other embodiments, step 355 may be executed first and then step 354 may be executed, or steps 354 and 355 may be executed simultaneously. This embodiment does not constitute a specific limitation in this regard.

[0118] Step 356: Add the first tag and / or the second tag to the first record.

[0119] Continuing with the previous example, the first record can be represented as: the account identifier uid of the first state account - business scenario A:13 - business scenario B:23 - confirm=true - sync=false.

[0120] In the first-state account identified by uid, the maximum version number of user data in business scenario A is 13, and the maximum version number of user data in business scenario B is 23. The first flag "confirm" indicates that the user agrees to upload the user data in each business scenario of the first-state account to the cloud, and the second flag "sync" indicates that the user data in each business scenario of the first-state account needs to be synchronized to the second-state account.

[0121] Therefore, based on the first record, user data synchronization between the first state account and the second state account can be performed on the acquired second target data.

[0122] With the cooperation of the above embodiments, the addition of the first mark and / or the second mark to the first record is realized. This not only fully considers user privacy and other security issues to prevent user privacy leakage, but also effectively prevents duplicate copying of user data, which is conducive to improving data processing efficiency.

[0123] Please see Figure 7 This application provides a possible implementation method in which step 350, obtaining the second target data from the second user data based on the first record, may include the following steps:

[0124] Step 410: Obtain the second record stored in the second state account.

[0125] The second record is constructed based on the first user data, which contained version information from the previous account switch.

[0126] In other words, for the first-state account, the first record reflects the maximum version number of user data in each business scenario at the time of the current account switch, which is also the maximum version number of user data that has been synchronized to the cloud at the time of the current account switch; while the second record reflects the maximum version number of user data in each business scenario at the time of the previous account switch, which is also the maximum version number of user data that has been synchronized to the cloud at the time of the previous account switch.

[0127] Therefore, based on the version information in the first and second records, it is possible to determine the changes in user data synchronized to the cloud in various business scenarios of the first state account during the two account switching periods, and thus determine the user data with version numbers that need to be synchronized, namely the second target data.

[0128] The determination process is as follows:

[0129] Compare the version information in the first record and the second record to obtain the first comparison result.

[0130] Specifically, based on the version information in the first and second records, the various business scenarios of the first-state account are traversed.

[0131] The traversal methods include:

[0132] Step 431: Use the traversed business scenario as the current business scenario.

[0133] Compare the version information for the current business scenario in the first record and the second record to obtain the second comparison result for the current business scenario.

[0134] Step 4331: In the first record, determine the version number of the second user data in the current business scenario, and use it as the first version number.

[0135] Step 4333: In the second record, determine the version number of the second user data in the current business scenario, and use it as the second version number.

[0136] It should be noted that the execution order of steps 4331 and 4333 is not limited to this. In other embodiments, step 4333 may be executed first and then step 4331, or steps 4331 and 4333 may be executed simultaneously. This embodiment does not constitute a specific limitation in this regard.

[0137] Step 4335: Compare whether the first version number and the second version number match to obtain the second comparison result for the current business scenario.

[0138] Once the above traversal steps are completed for each business scenario of the first-state account, the second comparison results for each business scenario of the first-state account can be obtained respectively.

[0139] Step 450: Generate the first comparison result based on the second comparison results obtained from the traversal of each business scenario for the first state account.

[0140] Step 470: Based on the first comparison result, obtain the second target data from the second user data containing version information.

[0141] Using the previous example, suppose the first record is represented as: Account ID uid of the first state account - Business Scenario A: 13 - Business Scenario B: 23, and the second record is represented as: Account ID uid of the first state account - Business Scenario A: 12 - Business Scenario B: 0.

[0142] When the current business scenario is business scenario A, the version number 13 in the first record for business scenario A is the first version number, and the version number 12 in the second record for business scenario A is the second version number. Then, the second comparison result is obtained that the first version number 13 and the second version number 12 do not match in business scenario A.

[0143] When the current business scenario is business scenario B, the version number 23 for business scenario B in the first record is the first version number, and the version number 0 for business scenario B in the second record is the second version number. Then, the second comparison result of business scenario B is obtained regarding the mismatch between the first version number 23 and the second version number 0.

[0144] Therefore, the first comparison result = {the second comparison result of business scenario A, the second comparison result of business scenario B}.

[0145] Therefore, based on the first comparison result, it is determined that the version number of the user data that needs to be synchronized in business scenario A is greater than 12 and less than or equal to 13, and the version number of the user data that needs to be synchronized in business scenario B is greater than 0 and less than or equal to 23. That is to say, the second target data includes: user data A3 with version number 13 in business scenario A; and user data B1, B2, and B3 with version numbers 21, 22, and 23 respectively in business scenario B.

[0146] In one possible implementation, based on the second user data in each business scenario of the first state account stored locally, such as the second user data in the database of unlogged users, the second target data can be obtained from the database of unlogged users, namely, user data A3 with version number 13 in business scenario A; and user data B1, B2, and B3 with version numbers 21, 22, and 23 respectively in business scenario B.

[0147] In one possible implementation, based on the second user data in each business scenario of the first state account stored in the cloud, the version numbers of the second user data that need to be synchronized in each business scenario of the first state account are sent to the cloud, namely version numbers 13, 21, 22, and 23. Correspondingly, the cloud will return user data A3 with version number 13 in business scenario A, and user data B1, B2, and B3 with version numbers 21, 22, and 23 in business scenario B.

[0148] Under the above embodiments, based on the first record and the second record, the acquisition of the second target data is realized, providing a data basis for synchronizing user data between the first state account and the second state account in an incremental update manner. This helps to reduce the data traffic consumed by users during the data synchronization process and can effectively promote the improvement of user experience.

[0149] Please see Figure 8 In this embodiment of the application, a possible implementation is provided. Before step 370, the method described above may further include the following steps:

[0150] Step 361: Compare whether the first marker in the first record is consistent with the first marker in the second record.

[0151] If the first marker in the first record is inconsistent with the first marker in the second record, it indicates that it is uncertain whether the user agrees to upload user data to the cloud, and then proceed to step 363.

[0152] Conversely, if the first marker in the first record matches the first marker in the second record, it indicates that the user has agreed to upload user data to the cloud, and then step 365 is executed.

[0153] It should be noted that, in one possible implementation, if the first marker in the first record is consistent with the first marker in the second record, step 370 can also be performed to synchronize the acquired first target data and second target data from the first state account to the second state account. This embodiment does not constitute a specific limitation in this regard.

[0154] Step 363: A pop-up message is displayed.

[0155] The pop-up message is used to prompt users whether they agree to upload their user data to the cloud.

[0156] If a confirmation action is detected in response to the pop-up message, indicating that the user agrees to upload user data to the cloud, then proceed to step 365.

[0157] Conversely, if no confirmation action is detected for the pop-up message, it means that the user does not agree to upload user data to the cloud. In this case, the first and second target data obtained do not need to be synchronized to the second state account, and the user data synchronization between the accounts ends.

[0158] Step 365: Compare whether the second marker in the first record and the second record are consistent.

[0159] If the second marker in the first record matches the second marker in the second record, it means that the user data has been synchronized to the second state account. In order to prevent duplicate copying of user data, the first target data and the second target data obtained do not need to be synchronized to the second state account. At this time, the user data synchronization between the accounts ends.

[0160] Conversely, if the second marker in the first record and the second record are inconsistent, it means that the user data has not been synchronized to the second state account. Then, step 370 is executed to synchronize the acquired first target data and second target data from the first state account to the second state account.

[0161] Therefore, before synchronizing user data between the first-state account and the second-state account, not only are user privacy and other security issues fully considered to prevent user privacy leaks, but also user data can be effectively prevented from being copied repeatedly, which in turn helps to improve data processing efficiency.

[0162] This application embodiment provides a possible implementation method. Before step 370, the method described above may further include the following steps:

[0163] Synchronize at least one user's data with the cloud for the second-state account.

[0164] Specifically, such as Figure 9 As shown, in one possible implementation, the synchronization process may include the following steps:

[0165] The system iterates through each business scenario in the second-state account, including the following methods:

[0166] Step 610: Use the traversed business scenario as the current business scenario.

[0167] Step 630: Based on the current business scenario, compare whether the version information of the user data stored locally matches that of the user data stored in the cloud.

[0168] Specifically, the maximum version number of user data stored locally is determined as the local version number, and the maximum version number of user data stored in the cloud is determined as the cloud version number; the local version number and the cloud version number are compared to see if they match.

[0169] If the local version number matches the cloud version number, proceed to step 650.

[0170] Conversely, if the local version number does not match the cloud version number, for example, if the local version number is less than the cloud version number, it means that the local and cloud versions have not yet been synchronized. In this case, step 670 is executed to make the local version number match the cloud version number.

[0171] Step 650: Check whether the user data stored locally is consistent with the user data stored in the cloud.

[0172] If the user data stored locally is consistent with the user data stored in the cloud, it means that the local and cloud have been synchronized, and the synchronization of user data with the cloud for the second-state account in various business scenarios ends.

[0173] Conversely, if the user data stored locally is inconsistent with the user data stored in the cloud, it means that the local and cloud data have not yet been synchronized, and then step 690 is executed.

[0174] Step 670: Retrieve user data from the cloud that matches the version information in the current business scenario.

[0175] Specifically, such as Figure 10 As shown, in one possible implementation, the pull process may include the following steps:

[0176] On the one hand, if the current business has user data that needs to be continued, the retrieval process is as follows:

[0177] Step 671: When it is detected that there is user data in the current business scenario that needs to be resumed, obtain the breakpoint resume information.

[0178] The breakpoint resume information includes at least one of the following: version information of the user data that needs to be resumed, version information of the user data stored in the cloud, and a third marker indicating whether there is still user data that needs to be resumed.

[0179] Step 673: Based on the breakpoint resume information, determine the version information of the user data that needs to be resumed.

[0180] Step 675: Compare the version information of the user data that needs to be continued with the version information of the user data stored in the cloud.

[0181] Specifically, based on the breakpoint resume information, the version number of the user data that needs to be resumed is determined, as well as the maximum version number of the user data stored in the cloud; the version number of the user data that needs to be resumed is compared with the maximum version number of the user data stored in the cloud to see if they match.

[0182] If the version number of the user data to be continued does not match the maximum version number of the user data stored in the cloud, proceed to step 677.

[0183] Conversely, if the version number of the user data that needs to be continuously transmitted matches the maximum version number of the user data stored in the cloud, then the process of retrieving user data from the cloud that matches the version information will end.

[0184] Step 677: Retrieve user data that needs to be continued in the current business scenario from the cloud.

[0185] After the user data that needs to be continued is retrieved, it can be further determined based on the aforementioned third marker whether there is still user data that needs to be continued. If it is determined that there is still user data that needs to be continued, the process returns to step 671 until the version information of the user data that needs to be continued matches the version information of the user data stored in the cloud, or there is no user data that needs to be continued.

[0186] On the other hand, if there is no user data that needs to be continued in the current business, the retrieval process is as follows: retrieve user data from the cloud that matches the local version number with the cloud version number in the current business scenario.

[0187] Step 690: For the current business scenario, replace the user data stored locally with the user data stored in the cloud.

[0188] Through the combination of the above embodiments, the synchronization process between user data and the cloud is realized for various business scenarios of the second-state account.

[0189] It should be noted that the synchronization process between user data and the cloud in various business scenarios for the first-state account is basically the same as the process described above, so it will not be repeated. The difference is that the synchronization of the first-state account is mainly to obtain the version number assigned by the cloud, while the synchronization of the second-state account is mainly to ensure that user data in various business scenarios of the client can be completely stored in the cloud, so as to provide more comprehensive data support for more accurate map services such as preferences and recommendations.

[0190] Figure 11 , Figure 12 , Figure 13 , Figures 14a to 14eThis is a schematic diagram illustrating a data processing method used in an application scenario. In this scenario, the client running on the terminal is a map client. The data processing method aims to synchronize user data across different accounts (e.g., logged-in and logged-out user accounts) and various business scenarios (e.g., POI favorites, search history, company and home information, home toolbar, driving trajectory, license plate number, frequently used addresses, etc.). The terminal can be a desktop computer, laptop, tablet, smartphone, smart voice interaction device, smart home appliance, or in-vehicle terminal, etc.

[0191] Figure 11 A schematic diagram of a data processing system architecture is shown as an example. Figure 11 The data processing system architecture includes: a map business layer, a basic service layer, a business interface layer, a data processing layer, and a data persistence layer.

[0192] Among them, the map business layer can deploy multiple business scenarios, such as company / home, POI collection, license plate, driving trajectory, etc., to provide user data in various accounts and business scenarios of the client.

[0193] The basic service layer includes API interfaces and business adapters. The API interfaces are responsible for encapsulating the general access logic for user data provided by the map business layer. For example, this encapsulation could involve converting user data belonging to different business scenarios into a unified binary stream. The business adapters facilitate access and use for different business scenarios through calls to database base classes, effectively improving the componentization capability of the data processing system architecture and eliminating the dependency of data synchronization on business scenarios. For example, database base classes implemented based on the Jetpack Room database include, but are not limited to, migration base classes, query base classes, entity base classes, etc. Figure 12 As shown;

[0194] The business interface layer includes at least a save module, a get module for retrieving local data, a page module for pagination, and an update module for asynchronous updates, providing external data access capabilities. For example, the map business layer can call the save module to store user data locally; the get module can read user data from local storage; the page module can fetch user data from cloud storage in pages, alleviating processing pressure on the cloud; and the update module can synchronize user data between the map business layer and the cloud for different business scenarios involving logged-in and logged-out user accounts.

[0195] The data persistence layer includes at least a local database, such as... Figure 13As shown, the local database further includes an unlogged-in user database db and a logged-in user database db, which are responsible for storing user data in various business scenarios (such as POI collection and driving trajectory) of the unlogged-in user account userId1 and the logged-in user account userId2, respectively. This not only helps to eliminate the dependence of data synchronization on business logic when switching accounts, but also allows for dynamic expansion as accounts change. Moreover, the implementation logic is simple and can effectively reduce development costs.

[0196] The data processing layer includes the pull component, the sync component, and the clone component. The pull component is responsible for pulling user data from the cloud storage. The pull can be performed when the client starts running, when the client switches from the background to the foreground, or when switching between logged-in and logged-out user accounts on the client side. The sync component is responsible for synchronizing user data with the cloud for various business scenarios for logged-out and logged-out user accounts. The upload timing is not limited to client startup; it can also be performed at a set interval after the client starts running on the terminal, for example, at an interval of 5 minutes. The clone component is responsible for synchronizing user data between logged-out and logged-out user accounts.

[0197] Figures 14a to 14e An exemplary diagram illustrates a specific implementation of the data processing method using the aforementioned components. For example... Figure 14a As shown, the pull component is used to implement the pull process in the data processing method. Figure 14b As shown, the upload component `sync` is used to implement the synchronous process in the data processing method. Figures 14c to 14d As shown, the cloning component is used to implement the cloning process in the data processing method. This cloning process further includes checking the cloning process and initiating the cloning process. Figure 14e As shown, the above three components are combined to achieve synchronization of user data between logged-in and logged-out accounts, as well as synchronization of user data between local and cloud environments. It is worth noting that a pull process can be introduced into either the synchronization or cloning process.

[0198] Combination Figures 14a to 14e The following examples illustrate the above processes:

[0199] Assume that the unlogged-in accounts include business scenario A and business scenario B.

[0200] When the network signal is good, the upload component `sync` is invoked. The client will synchronize data with the cloud for at least one user corresponding to an unlogged-in account, and receive the version number of the synchronized user data returned by the cloud, such as... Figure 14e As shown.

[0201] Assume that for business scenario A, user data A1 has version number 11, user data A2 has version number 12, user data A3 has version number 13, and user data A4 has no version number.

[0202] For business scenario B, the version number of user data B1 is 21, the version number of user data B2 is 22, and the version number of user data B3 is 23.

[0203] As users log in, user data will be synchronized between logged-in and unlogged-in accounts.

[0204] like Figure 14c As shown, by calling the clone component, the cloning process is initiated to check the offline data. The first target data is determined, which includes at least user data A4 in business scenario A.

[0205] Accordingly, the first record can be represented as: Account ID (uid) of the first-state account - Business Scenario A: 13 - Business Scenario B: 23 - confirm = true - sync = false. Here, in the first-state account with account ID uid, the maximum version number of user data in Business Scenario A is 13, and the maximum version number of user data in Business Scenario B is 23. The first flag, confirm, indicates that the user agrees to upload user data from each business scenario in the first-state account to the cloud, and the second flag, sync, indicates that user data from each business scenario in the first-state account needs to be synchronized to the second-state account.

[0206] Further assuming that user data A1 and A2 in business scenario A have been synchronized to the second-state account, the obtained second record can be represented as: Account identifier uid of the first-state account - Business scenario A: 12 - Business scenario B: 0 - confirm = true - sync = true. Here, in the second-state account with account identifier uid1, the maximum version number of user data in business scenario A is 13, and the maximum version number of user data in business scenario B is 23. The first flag "confirm" indicates that the user agrees to upload user data from each business scenario in the first-state account to the cloud, and the second flag "sync" indicates that user data from each business scenario in the first-state account does not need to be synchronized to the second-state account.

[0207] After determining the first and second records, a comparison is performed between them. Specifically: When the current business scenario is business scenario A, version number 13 in the first record for business scenario A is the first version number, and version number 12 in the second record for business scenario A is the second version number. Therefore, the second comparison result for business scenario A is that the first version number 13 and the second version number 12 do not match. When the current business scenario is business scenario B, version number 23 in the first record for business scenario B is the first version number, and version number 0 in the second record for business scenario B is the second version number. Therefore, the second comparison result for business scenario B is that the first version number 23 and the second version number 0 do not match. Thus, the first comparison result = {the second comparison result for business scenario A, the second comparison result for business scenario B}.

[0208] Based on the first comparison result, it is determined that the version number of the user data that needs to be synchronized in business scenario A is greater than 12 and less than or equal to 13, and the version number of the user data that needs to be synchronized in business scenario B is greater than 0 and less than or equal to 23. Therefore, the online data, i.e., the second target data, is determined to include at least: user data A3 with version number 13 in business scenario A; and user data B1, B2, and B3 with version numbers 21, 22, and 23 respectively in business scenario B.

[0209] After determining the offline and online data, the cloning process is initiated by calling the clone component, such as... Figure 14d As shown, user data A3 and A4 in business scenario A, and user data B1, B2, and B3 in business scenario B, are synchronized from accounts in an offline state to accounts in a logged-in state. In one possible implementation, synchronization refers to a physical copy, that is, copying offline user data A4 from the database of offline users to the database of logged-in users; in another possible implementation, synchronization refers to asynchronous retrieval, such as... Figure 14a As shown, under the premise that there is no interruption and resume, and the version number matches, user data A3, B1, B2, and B3 are obtained from the cloud and stored in the logged-in user database.

[0210] This completes the synchronization of user data between logged-in and logged-out accounts.

[0211] Furthermore, when the network signal is good, the client will also synchronize at least one user data corresponding to the logged-in account with the cloud through the call of the upload component sync.

[0212] like Figure 14b As shown, assume that the user data requested for synchronization includes at least: user data A4 from business scenario A. Correspondingly, the version number of the user data stored locally is 13.

[0213] The first scenario, for business scenario A, assumes the version number of user data stored in the cloud is 13, indicating that the user data in the cloud has not been updated. If both the user data with version number 13 in the cloud and the user data with version number 13 in local storage are A3, then user data A4 is uploaded to the cloud for storage, completing the synchronization between the client and the cloud regarding user data A4 for the logged-in account. Correspondingly, version number 14 is assigned to user data A4, thereby updating the version number of user data in both local and cloud storage to 14.

[0214] The second scenario, for business scenario A, assumes the version number of user data stored in the cloud is 13, indicating that the user data in the cloud has not been updated. If the user data with version number 13 in the cloud and the user data with version number 13 in local storage are inconsistent, then firstly, the user data with version number 13 in local storage is replaced with the user data with version number 13 in the cloud. Then, user data A4 is uploaded to the cloud for storage, completing the synchronization between the client and the cloud regarding user data A4 for the logged-in account. Correspondingly, version number 14 is assigned to user data A4, thus updating the version number of user data in both local and cloud storage to 14.

[0215] The third scenario is for business scenario A. Assume the version number of the user data stored in the cloud is 15 (where version number 14 is assigned to user data A5' and version number 15 is assigned to user data A6'). This indicates that the user data stored in the cloud has been updated (for example, the user performed a write operation on another client using the same login account), but the user data stored locally has not been updated. Then, as follows... Figure 14a As shown, the process first asynchronously retrieves user data from cloud storage via a pull component call until the version number of the locally stored user data is updated from 13 to 15. This means user data A5' and user data A6' are stored locally. Then, user data A4 is uploaded to the cloud for storage, completing the synchronization between the client and the cloud regarding user data A4 for the logged-in account. Correspondingly, version number 16 is assigned to user data A4, thus updating the version numbers of both locally and cloud-stored user data to 16.

[0216] This achieves the synchronization of user data between logged-in and logged-out accounts, as well as the synchronization of user data between local and cloud environments.

[0217] In this application scenario, for the map client, user data from each account and business scenario can be completely stored in the cloud. This not only enables comprehensive monitoring of data interactions and timely detection of problems, but also provides more comprehensive data support for more accurate map services such as preferences and recommendations. In addition, from the perspective of R&D benefits, labor costs are reduced by 50%, version iteration speed is increased by 30%, and as more and more different business scenarios are connected to the above data processing system architecture, the rate of benefit improvement becomes more and more obvious.

[0218] The following are embodiments of the apparatus described in this application, which can be used to execute the data processing method involved in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the method embodiments of the data processing method involved in this application.

[0219] Please see Figure 15 This application provides a data processing device 900, including but not limited to: a version information detection module 910, a first target data acquisition module 930, a second target data acquisition module 950, and a data synchronization module 970.

[0220] The version information detection module 910 is used to detect the version information of at least one user data corresponding to the first state account when switching between the first state account and the second state account.

[0221] The first target data acquisition module 930 is used to acquire the first user data corresponding to the first state account as the first target data, wherein the first user data is user data without version information.

[0222] The second target data acquisition module 950 is used to construct a first record based on the second user data corresponding to the first status account, and to acquire second target data from the second user data according to the first record, wherein the second user data is user data with version information.

[0223] The data synchronization module 970 is used to synchronize user data between the first status account and the second status account based on the first target data and the second target data.

[0224] In one possible implementation, the version information includes at least a version number; the device 900 uses a functional module to perform the following steps: synchronizing at least one user data corresponding to a first-state account with the cloud; and receiving a version number of the synchronized user data returned by the cloud.

[0225] In one possible implementation, the device 900 uses a functional module to perform the following steps: obtaining the account identifier of a first state account; obtaining the maximum version number of at least one user data corresponding to the first state account; and generating a first record based on the account identifier and the maximum version number of the first state account.

[0226] In one possible implementation, the device 900 uses a functional module to perform the following steps: obtaining a first tag indicating whether the user agrees to upload user data to the cloud; and / or obtaining a second tag indicating whether the user data has been synchronized to a second state account; and adding the first tag and / or the second tag to a first record.

[0227] In one possible implementation, the device 900 uses a functional module to perform the following steps: obtaining a second record stored in a second state account; comparing the version information in the first record and the second record to obtain a first comparison result; and obtaining second target data from the second user data based on the first comparison result.

[0228] In one possible implementation, the device 900 uses a functional module to perform the following steps: based on the version information in the first record and the second record, traversing each business scenario of the first state account, and generating a first comparison result according to the second comparison result obtained for each business scenario of the first state account, wherein the traversal method includes: taking the traversed business scenario as the current business scenario; comparing the version information for the current business scenario in the first record and the second record to obtain the second comparison result for the current business scenario.

[0229] In one possible implementation, the device 900 uses a functional module to perform the following steps: in a first record, determine the version number of the second user data in the current business scenario as a first version number; and in a second record, determine the version number of the second user data in the current business scenario as a second version number; compare whether the first version number and the second version number match to obtain a second comparison result for the current business scenario.

[0230] In one possible implementation, the device 900 uses a functional module to perform the following steps: comparing whether the first marker in the first record is consistent with the first marker in the second record; if they are inconsistent, displaying a pop-up message, so that when a confirmation operation is received for the pop-up message, the first target data and the second target data are synchronized from the first state account to the second state account; wherein, the pop-up message is used to prompt the user whether they agree to upload user data to the cloud.

[0231] In one possible implementation, the device 900 uses a functional module to perform the following steps: comparing whether the second mark in the first record and the second record are consistent, so that when the second mark in the first record and the second record are inconsistent, the first target data and the second target data are synchronized from the first state account to the second state account.

[0232] In one possible implementation, the device 900 uses a functional module to perform the following steps: synchronizing at least one user data corresponding to a second-state account with the cloud.

[0233] In one possible implementation, the device 900 uses a functional module to perform the following steps: traversing each business scenario in the second state account, the traversal method including: taking the traversed business scenario as the current business scenario; comparing the version information of the user data stored locally with that of the user data stored in the cloud based on the current business scenario; if they do not match, then pulling user data from the cloud that matches the version information in the current business scenario.

[0234] In one possible implementation, the device 900 uses a functional module to perform the following steps: when it detects that there is user data in the current business scenario that needs to be resumed, it obtains breakpoint resume information; based on the breakpoint resume information, it determines the version information of the user data that needs to be resumed; it compares whether the version information of the user data that needs to be resumed matches the version information of the user data stored in the cloud; if they do not match, it retrieves the user data that needs to be resumed in the current business scenario from the cloud until the version information of the user data that needs to be resumed matches the version information of the user data stored in the cloud.

[0235] In one possible implementation, the device 900 uses a functional module to perform the following steps: if the version information of the user data stored locally matches that of the user data stored in the cloud, then it detects whether the user data stored locally and the user data stored in the cloud are consistent; if they are inconsistent, then for the current business scenario, the user data stored in the cloud replaces the user data stored locally.

[0236] It should be noted that the data processing device provided in the above embodiments is only illustrated by the division of the above functional modules when performing data processing. In actual applications, the above functions can be assigned to different functional modules as needed. That is, the internal structure of the data processing device will be divided into different functional modules to complete all or part of the functions described above.

[0237] Furthermore, the data processing apparatus and data processing method embodiments provided in the above embodiments belong to the same concept, and the specific way in which each module performs operations has been described in detail in the method embodiments, and will not be repeated here.

[0238] Therefore, as user data from various business scenarios in the first-state account is synchronized to the second-state account, this part of user data is closely associated with the second-state account. That is, when a user enters the second-state account, they can obtain this part of user data accordingly. It will not be lost when the user uninstalls the client, nor will it be affected by the user changing the terminal. This is conducive to providing data support for map services such as preferences and recommendations, and can effectively solve the problem of low data utilization in unlogged-in accounts in related technologies.

[0239] Please see Figure 16 , Figure 16 This is a schematic diagram illustrating the structure of a terminal according to an exemplary embodiment. The terminal is suitable for… Figure 1 The terminal 100 in the implementation environment is shown.

[0240] It should be noted that this terminal is merely an example adapted to this application and should not be construed as providing any limitation on the scope of use of this application. Furthermore, this terminal should not be interpreted as requiring or depending on any specific feature. Figure 16 One or more components of the exemplary terminal 1100 shown.

[0241] like Figure 16 As shown, terminal 1100 includes memory 101, memory controller 103, and one or more ( Figure 16 (Only one is shown) Processor 105, peripheral interface 107, radio frequency module 109, positioning module 111, camera module 113, audio module 115, touch screen 117, and button module 119. These components communicate with each other through one or more communication buses / signal lines 121.

[0242] The memory 101 can be used to store computer programs and modules, such as the computer programs and modules corresponding to the data processing method and apparatus in the exemplary embodiments of this application. The processor 105 executes various functions and data processing by running the computer programs stored in the memory 101, that is, it completes the data processing method.

[0243] The memory 101, as a carrier for resource storage, can be random access memory, such as high-speed random access memory, non-volatile memory, such as one or more magnetic storage devices, flash memory, or other solid-state memory. The storage method can be temporary storage or permanent storage.

[0244] The peripheral interface 107 may include at least one wired or wireless network interface, at least one serial-to-parallel conversion interface, at least one input / output interface, and at least one USB interface, etc., for coupling various external input / output devices to the memory 101 and the processor 105 to realize communication with various external input / output devices.

[0245] The radio frequency module 109 is used to transmit and receive electromagnetic waves, realizing the mutual conversion between electromagnetic waves and electrical signals, thereby enabling communication with other devices through a communication network. The communication network includes cellular telephone networks, wireless local area networks, or metropolitan area networks, and these communication networks can use various communication standards, protocols, and technologies.

[0246] The positioning module 111 is used to obtain the current geographical location of the terminal 1100. Examples of positioning modules 111 include, but are not limited to, Global Positioning System (GPS), positioning technologies based on wireless local area networks or mobile communication networks.

[0247] The camera module 113 is part of the camera and is used to capture pictures or videos. The captured pictures or videos can be stored in the memory 101 or transmitted to the host computer via the radio frequency module 109.

[0248] The audio module 115 provides an audio interface to the user, which may include one or more microphone jacks, one or more speaker jacks, and one or more headphone jacks. Audio data is exchanged with other devices through the audio interface. Audio data can be stored in the memory 101 and can also be transmitted via the radio frequency module 109.

[0249] The touchscreen 117 provides an input / output interface between the terminal 1100 and the user. Specifically, the user can perform input operations through the touchscreen 117, such as clicking, touching, and swiping gestures, so that the terminal 1100 can respond to the input operations. The terminal 1100 then displays the output content, which can be text, images, or videos in any form or combination thereof, to the user through the touchscreen 117.

[0250] The button module 119 includes at least one button, providing an interface for users to input information into the terminal 1100. Users can press different buttons to enable the terminal 1100 to perform different functions. For example, the volume adjustment button allows users to adjust the volume of the sound played by the terminal 1100.

[0251] Understandable. Figure 16 The structure shown is for illustrative purposes only; terminal 1100 may also include components that are more advanced than those shown. Figure 16 The more or fewer components shown, or having the same Figure 16 The different components are shown. Figure 16 The components shown can be implemented using hardware, software, or a combination thereof.

[0252] Please see Figure 17 This application provides a terminal 4000, which may include: desktop computer, laptop computer, tablet computer, smartphone, smart voice interaction device, smart home appliance, vehicle terminal, etc.

[0253] exist Figure 17 In this terminal 4000, there are at least one processor 4001, at least one communication bus 4002, and at least one memory 4003.

[0254] The processor 4001 and memory 4003 are connected, for example, via a communication bus 4002. Optionally, the terminal 4000 may also include a transceiver 4004, which can be used for data interaction between the terminal and other terminals, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 4004 is not limited to one, and the structure of the terminal 4000 does not constitute a limitation on the embodiments of this application.

[0255] Processor 4001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 4001 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0256] The communication bus 4002 may include a path for transmitting information between the aforementioned components. The communication bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. The communication bus 4002 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 17 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0257] The memory 4003 may be ROM (Read Only Memory) or other types of static storage devices capable of storing static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices capable of storing information and instructions, or EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto.

[0258] The memory 4003 stores a computer program, and the processor 4001 reads the computer program stored in the memory 4003 through the communication bus 4002.

[0259] When the computer program is executed by the processor 4001, it implements the data processing methods in the above embodiments.

[0260] Therefore, without hindering user access—that is, when users manipulate user data, they do not need to be aware of the impact of changes in this user data on the client—user data from each account and business scenario on the client can be completely stored in the cloud. This not only enables comprehensive detection of data interactions and timely discovery of problems, but also provides more comprehensive data support for more accurate map services such as preferences and recommendations, thereby fully improving the utilization rate of user data in the first-state account.

[0261] Furthermore, this application provides a storage medium storing a computer program, which, when executed by a processor, implements the data processing methods described in the above embodiments.

[0262] This application provides a computer program product comprising a computer program stored in a storage medium. A processor of a computer device reads the computer program from the storage medium and executes the computer program, causing the computer device to perform the data processing methods described in the above embodiments.

[0263] Compared with related technologies, when users enter the second-state account, they can obtain user data from various business scenarios in the first-state account. This data will not be lost when the user uninstalls the client or is affected by the user changing the terminal. This is beneficial for providing data support for map services such as preferences and recommendations, and can effectively solve the problem of low data utilization in unlogged accounts in related technologies.

[0264] Furthermore, on the one hand, data synchronization combines online second target data and offline first target data, avoiding problems such as delays and high loss rates caused by network limitations, and achieving lossless data interaction to fully guarantee the smoothness of user operations; on the other hand, by introducing a first record for user data in each business scenario of the first state account, each business scenario no longer needs to perform data synchronization separately, avoiding problems such as excessive development costs and excessive development complexity caused by limitations of business scenarios, and thus improving the data migration capability between different accounts.

[0265] It should be understood that although the steps in the flowcharts of the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0266] The above description is only a partial embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A data processing method, characterized in that, The method includes: When switching between a first-state account and a second-state account, the version information of at least one user data corresponding to the first-state account is detected; the first-state account is an unlogged-in user account, and the second-state account is a logged-in user account. Obtain the first user data corresponding to the first state account as the first target data, wherein the first user data is user data without version information; and A first record is constructed based on the second user data corresponding to the first status account, and second target data is obtained from the second user data according to the first record, wherein the second user data is user data with version information; Based on the first target data and the second target data, perform user data synchronization between the first status account and the second status account; The step of obtaining the second target data from the second user data based on the first record includes: Retrieve the second record stored in the account in the second state; Compare the version information of the first record with that of the second record to obtain a first comparison result; Based on the first comparison result, the second target data is obtained from the second user data.

2. The method as described in claim 1, characterized in that, The version information includes at least a version number; Before detecting the version information of at least one user data corresponding to the first state account, the method further includes: Synchronize at least one user data corresponding to the account in the first state with the cloud; Receive the version number of the synchronized user data returned by the cloud.

3. The method as described in claim 1, characterized in that, The construction of the first record based on the second user data corresponding to the first status account includes: Obtain the account identifier of the account in the first state; and Obtain the maximum version number of at least one user data corresponding to the first state account; The first record is generated based on the account identifier of the first state account and the maximum version number.

4. The method as described in claim 3, characterized in that, The step of constructing the first record based on the second user data corresponding to the first status account further includes: Obtain a first flag indicating whether the user agrees to upload user data to the cloud; and / or, obtain a second flag indicating whether the user data has been synchronized to the second-state account; Add the first tag and / or the second tag to the first record.

5. The method as described in claim 1, characterized in that, The user data corresponding to the first state account includes user data in at least one business scenario of the first state account; The step of comparing the version information in the first record and the second record to obtain a first comparison result includes: Based on the version information in the first record and the second record, the business scenarios of the first state account are traversed, and the first comparison result is generated according to the second comparison result obtained for the traversal of the business scenarios of the first state account. The traversal methods include: The business scenario that has been traversed is taken as the current business scenario; By comparing the version information for the current business scenario in the first record and the second record, a second comparison result for the current business scenario is obtained.

6. The method as described in claim 5, characterized in that, The step of comparing the version information for the current business scenario in the first record and the second record to obtain a second comparison result for the current business scenario includes: In the first record, the version number of the second user data in the current business scenario is determined as the first version number; and In the second record, the version number of the second user data in the current business scenario is determined and used as the second version number; The first version number is compared with the second version number to obtain the second comparison result of the current business scenario.

7. The method as described in claim 1, characterized in that, Before synchronizing user data between the first status account and the second status account based on the first target data and the second target data, the method further includes: Compare whether the first marker in the first record is consistent with the first marker in the second record; If there is a discrepancy, a pop-up message is displayed so that, upon receiving a confirmation operation for the pop-up message, the first target data and the second target data are synchronized from the first status account to the second status account. The pop-up message is used to prompt the user whether they agree to upload their user data to the cloud.

8. The method as described in claim 1, characterized in that, Before synchronizing user data between the first status account and the second status account based on the first target data and the second target data, the method further includes: The first record is compared with the second record to see if the second mark is consistent. If the first record and the second record are inconsistent, the first target data and the second target data are synchronized from the first state account to the second state account.

9. The method according to any one of claims 1 to 8, characterized in that, After synchronizing user data between the first status account and the second status account based on the first target data and the second target data, the method further includes: Synchronize at least one user data corresponding to the second-state account with the cloud.

10. The method as described in claim 9, characterized in that, At least one user data corresponding to the second status account includes user data in at least one business scenario of the second status account; The synchronization of at least one user data corresponding to the second-state account with the cloud includes: The process involves iterating through each of the aforementioned business scenarios in the second-state account, and the iteration method includes: The business scenario that has been traversed is taken as the current business scenario; Based on the current business scenario, compare whether the version information of the user data stored locally matches that of the user data stored in the cloud. If there is no match, then retrieve user data from the cloud that matches the version information in the current business scenario.

11. The method as described in claim 10, characterized in that, The step of retrieving user data from the cloud that matches the version information in the current business scenario includes: When it is detected that there is user data in the current business scenario that needs to be resumed, obtain the breakpoint resume information; Based on the breakpoint resume information, determine the version information of the user data that needs to be resumed; Compare whether the version information of the user data that needs to be re-uploaded matches that of the user data stored in the cloud. If they do not match, the user data that needs to be continued in the current business scenario is retrieved from the cloud until the version information of the user data that needs to be continued matches the version information of the user data stored in the cloud.

12. The method as described in claim 10, characterized in that, The synchronization of at least one user data corresponding to the second-state account with the cloud also includes: If the version information of the user data stored locally matches that of the user data stored in the cloud, then it is checked whether the user data stored locally is consistent with the user data stored in the cloud. If there is a discrepancy, then for the current business scenario, the user data stored locally will be replaced by the user data stored in the cloud.

13. A data processing apparatus, characterized in that, The device includes: The version information detection module is used to detect the version information of at least one user data corresponding to the first state account when switching between a first state account and a second state account; the first state account is an unlogged user account and the second state account is a logged-in user account. The first target data acquisition module is used to acquire first user data corresponding to the first state account as first target data, wherein the first user data is user data without version information; and The second target data acquisition module is used to construct a first record based on the second user data corresponding to the first status account, and to acquire second target data from the second user data according to the first record, wherein the second user data is user data with version information; The data synchronization module is used to synchronize user data between the first status account and the second status account based on the first target data and the second target data. The step of obtaining the second target data from the second user data based on the first record includes: Retrieve the second record stored in the account in the second state; Compare the version information of the first record with that of the second record to obtain a first comparison result; Based on the first comparison result, the second target data is obtained from the second user data.

14. A terminal, characterized in that, include: At least one processor, at least one memory, and at least one communication bus, wherein, The memory stores a computer program, and the processor reads the computer program from the memory via the communication bus; When the computer program is executed by the processor, it implements the data processing method according to any one of claims 1 to 12.