Archiving method and apparatus for applications

Abstract

The application provides an archiving processing method and device of an application; the method comprises the following steps: in response to an archiving recovery request of a first application on a first device, determining a first device identifier of the first device, and querying first archiving data associated with the first device identifier from a database; when the first archiving data associated with the first device identifier is not queried, obtaining a target account logged in the first application, and querying at least one second device identifier associated with the target account from the database; determining a target device identifier from the at least one second device identifier, and querying second archiving data associated with the target device identifier from the database; loading the second archiving data to the first application, so that the first application continues to run from a state corresponding to the second archiving data. Through the application, direct archiving recovery without an account in a single-device scenario can be supported, and precise archiving migration based on an account in a cross-device scenario can be supported, so that the flexibility of application archiving is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to an application archiving method and apparatus. Background Technology

[0002] In the use of applications (especially games, document editing, and note-taking applications), the save function is a core requirement to ensure the continuity of user operations. Users want to be able to continue from the previous operation state (such as game progress or document editing content) after interruption, without having to start over.

[0003] In related technologies, user accounts are used as the sole link for archive storage and recovery: users must register and log in to their accounts, archive data is stored in the cloud and associated only with the account (usually stored in the cloud), which reduces the universality of application archives. Summary of the Invention

[0004] This application provides an application archiving method and apparatus that can support direct archive recovery without an account in a single-device scenario, and also support precise archive migration based on an account in a cross-device scenario, thereby improving the flexibility of application archiving.

[0005] The technical solution of this application embodiment is implemented as follows: This application provides an archiving method for an application, the method comprising: In response to an archive recovery request from a first application on a first device, a first device identifier of the first device is determined, and first archive data associated with the first device identifier is queried from the database; When no first archive data associated with the first device identifier is found, the target account for logging into the first application is obtained, and at least one second device identifier associated with the target account is queried from the database; Determine a target device identifier from the at least one second device identifier, and query second archived data associated with the target device identifier from the database; Load the second archived data into the first application so that the first application can continue running from the state corresponding to the second archived data.

[0006] This application provides an archiving processing apparatus, including: The first query module is used to respond to the archive recovery request of the first application on the first device, determine the first device identifier of the first device, and query the first archive data associated with the first device identifier from the database; The second query module is used to obtain the target account that logs into the first application when no first archive data associated with the first device identifier is found, and to query at least one second device identifier associated with the target account from the database. The third query module is used to determine the target device identifier from the at least one second device identifier, and to query the second archived data associated with the target device identifier from the database; An archive loading module is used to load the second archive data into the first application so that the first application can continue running from the state corresponding to the second archive data.

[0007] This application provides an electronic device, the electronic device comprising: Memory is used to store executable instructions or computer programs. The processor, when executing computer-executable instructions or computer programs stored in the memory, implements the archiving method of the application provided in the embodiments of this application.

[0008] This application provides a computer-readable storage medium storing a computer program or computer-executable instructions for use by a processor to implement the archiving method of the application provided in this application.

[0009] This application provides a computer program product, including a computer program or computer executable instructions. When the computer program or computer executable instructions are executed by a processor, they implement the archiving method of the application provided in this application.

[0010] The embodiments of this application have the following beneficial effects: On the one hand, the system prioritizes querying the first archive data from the database based on the first device identifier of the first device, allowing users to directly obtain archives previously stored on the first device without logging into an account, without relying on account binding. This lowers the barrier to entry for the archive function and improves the flexibility of the archive function. At the same time, archive recovery does not require additional steps such as account verification and cloud query, reducing data interaction steps and improving the efficiency of archive recovery.

[0011] On the other hand, when the first archive data associated with the first device identifier is not found, the target account is obtained and the second device identifier associated with the target account is queried. Then the target device identifier is determined and the corresponding second archive data is loaded, realizing cross-device archive recovery. This allows multiple device archives under the same account to be clearly distinguished by device identifiers, and the second archive data of the target device identifier can be accurately selected. This not only ensures the continuity of cross-device operations, but also improves the accuracy of recovery. Attached Figure Description

[0012] Figure 1 This is a schematic diagram of the architecture of the archiving system for the application provided in the embodiments of this application; Figure 2 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application; Figure 3 This is a flowchart illustrating the archiving method for the application provided in the embodiments of this application. Figure 1 ; Figure 4 This is a flowchart illustrating the archiving method for the application provided in the embodiments of this application. Figure 2 ; Figure 5 This is a flowchart illustrating the archiving method for the application provided in the embodiments of this application. Figure 3 ; Figure 6 This is a flowchart illustrating the archiving method for the application provided in the embodiments of this application. Figure 4 ; Figure 7 This is a flowchart illustrating the archiving method for the application provided in the embodiments of this application. Figure 5 . Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0014] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0015] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0016] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0017] Unless otherwise defined, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in the embodiments of this application is for the purpose of describing the embodiments of this application only and is not intended to limit this application.

[0018] In the implementation of this application, the collection and processing of relevant data should strictly comply with the requirements of relevant laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0019] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0020] 1) Responding to: used to indicate the conditions or states on which the operation is performed depends. When the conditions or states on which it depends are met, one or more operations can be performed in real time or with a set delay. Unless otherwise specified, there is no restriction on the order in which the multiple operations are performed.

[0021] 2) Archiving: This refers to the periodic storage of current runtime state data (such as game progress, document editing content, settings parameters, etc.) by an application based on user actions or application triggers during operation. The purpose of archiving is to restore the application to its saved state after the user interrupts use, ensuring the continuity of operation.

[0022] 3) Account: Refers to a unique identifier obtained by a user through registration in the application or authorization through a third-party authentication platform, used to associate user information and related permissions. In this embodiment, the account is associated with one or more device identifiers, supporting users to query and restore archived data across different devices by logging into the same account.

[0023] 4) Device Identifier: refers to the string or encoded information used to uniquely identify a device (such as a mobile phone, tablet, etc.), which has the characteristics of device uniqueness and stability.

[0024] In related technologies, mobile game save recovery solutions generally rely on users forcibly binding a third-party account. The process is as follows: First, the user must log in to their third-party platform account within the game. After successful login, the game client associates the user's account information with locally generated save data. Then, the save data associated with this account is uploaded to the game developer's server or a third-party cloud storage service. When the user changes devices or reinstalls the game, they need to log in to the same third-party platform account again, and retrieve and download the corresponding save data to the new device based on the account information of that third-party platform account.

[0025] The above solution has the following technical problems: (1) Some users are concerned about providing or binding third-party account information due to information security considerations, which makes them unwilling to use the save recovery function. (2) Complexity of operation process: The account login process (including inputting credentials, authorization, etc.) increases the complexity of user operation and reduces the ease of use of the save recovery function, especially for users with low operation proficiency or temporary use scenarios. (3) Security risks of account-related data: When a third-party account is associated with a save file containing high-value content (such as special virtual items, rare props and virtual currencies in game assets, accumulated usage results, etc.), the account itself becomes a tradable commodity. Any user who obtains the account can download and own the save file, which may lead to the unauthorized acquisition of this content, affecting the ecological balance within the application and the legitimate rights and interests of the developers.

[0026] To address the problems existing in related technologies, this application provides an application archiving method and apparatus that supports direct archive recovery without an account in a single-device scenario, and precise archive migration based on an account in a cross-device scenario, thereby improving the flexibility of application archiving. The following describes exemplary applications of the application archiving device provided in this application embodiment. This application archiving device is an electronic device used to implement the application archiving method. The electronic device provided in this application embodiment can be implemented as various types of terminals such as laptops, tablets, desktop computers, set-top boxes, smartphones, smart speakers, smartwatches, smart TVs, and in-vehicle terminals, or it can be implemented as a server. The following will describe exemplary applications when the device is implemented as a terminal or server.

[0027] See Figure 1 , Figure 1This is a schematic diagram of the architecture of an application archiving system provided in this application embodiment. To perform application archiving operations, an application archiving application can be provided. The application archiving system 100 in this application embodiment includes at least a terminal 400, a network 300, and a server 200, wherein the server 200 is the server for the application archiving application. The server 200 can constitute the application archiving device of this application embodiment, that is, the application archiving method of this application embodiment is implemented through the server 200. The terminal 400 is connected to the server 200 through the network 300, which can be a wide area network (WAN), a local area network (LAN), or a combination of both.

[0028] Terminal 400 can be used to obtain the archive recovery request of the first application.

[0029] In some embodiments, a user performs an interactive operation on the client of a first application via a first device (terminal 400). This interactive operation may be, for example, triggering an archive recovery function. Upon receiving the user's interactive operation, the client generates an archive recovery request. In response to the request, it determines the first device identifier of the first device and queries the database for first archive data associated with that first device identifier. If the corresponding first archive data is found, the client loads it into the first application, allowing the first application to continue running from the state corresponding to the first archive data. If no first archive data associated with the first device identifier is found, the client obtains the target account used to log in to the first application and queries the database for at least one associated second device identifier based on that target account. The target device identifier is determined from the at least one second device identifier, and then the database is queried for second archive data associated with that target device identifier. Finally, the client loads the second archive data into the first application, allowing the first application to continue running from the state corresponding to the second archive data.

[0030] In some embodiments, a user can perform an interactive operation on the client of a first application via a first device (terminal 400). This interactive operation could be, for example, clicking a "Restore Archive" button to trigger the archive recovery function. Upon receiving the user's interactive operation, the client of terminal 400 generates an archive recovery request and sends it to server 200 via the network. In response to the archive recovery request from the first application on the first device, server 200 determines a first device identifier for the first device and queries the database for first archive data associated with the first device identifier. If no first archive data associated with the first device identifier is found, server 200 obtains the target account logged into the first application and queries the database for at least one second device identifier associated with the target account. Server 200 determines the target device identifier from the at least one second device identifier and queries the database for second archive data associated with the target device identifier. Server 200 sends the second archive data to terminal 400, and terminal 400 loads the second archive data into the first application, allowing the first application to continue running from the state corresponding to the second archive data.

[0031] The archiving method of the application in this application embodiment can be applied to various application scenarios, which will be described in detail below.

[0032] In some embodiments, in a gaming application scenario, a user opens the game (first application) on a new mobile terminal (e.g., a mobile phone) and clicks the "Restore Save" button. The client on the new mobile terminal generates a save restore request and sends it to the server. The server instructs the user to determine the first device identifier of the mobile terminal. After querying, it finds that the first device identifier has no associated first save data and obtains the user's target account for logging into the game. The server queries the second device identifiers of the old mobile terminal (second device) associated with the target account. The user selects one of the second device identifiers as the target device identifier. Based on the target device identifier, the server retrieves the game save data (such as level progress, item information, etc.) corresponding to the old mobile terminal and sends it to the new mobile terminal. The new mobile terminal loads the game save data, and the user can continue playing the game from the game progress on the old mobile terminal.

[0033] In some embodiments, in document editing application scenarios, a user uses a document editing application (first application) on a company computer (second device), logs in with a target account, and the document editing application automatically saves the document during the editing process. The user then opens the document editing application on a personal tablet (first device) and clicks "Restore Document." The tablet client sends an archive recovery request to the server. The server identifies the tablet as the first device identifier, queries for first archive data not associated with the first device identifier, obtains the target account the user logged into the document editing application, and obtains the company computer identifier (second device identifier) ​​associated with that target account. After confirming the company computer identifier as the target device identifier, the server queries the database for the document archive (second archive data) associated with the target device identifier. The tablet loads the document archive, allowing the user to continue editing the document that was not completed at the company.

[0034] In some embodiments, the electronic device may be Figure 1 Terminal 400, see [link / reference] Figure 2 , Figure 2 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Figure 2 The illustrated electronic device includes at least one processor 410, a memory 450, at least one network interface 420, and a user interface 430. The various components of the electronic device are coupled together via a bus system 440. It is understood that the bus system 440 is used to implement communication between these components. In addition to a data bus, the bus system 440 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in… Figure 2 The general labeled all buses as Bus System 440.

[0035] Processor 410 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among them, the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0036] User interface 430 includes one or more output devices 431 that enable the presentation of media content, including one or more speakers and / or one or more visual displays. User interface 430 also includes one or more input devices 432, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.

[0037] The memory 450 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The memory 450 may optionally include one or more storage devices physically located away from the processor 410.

[0038] The memory 450 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The memory 450 described in this application embodiment is intended to include any suitable type of memory.

[0039] In some embodiments, memory 450 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0040] Operating system 451 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, driver layer, etc., for implementing various basic business functions and handling hardware-based tasks; The network communication module 452 is used to reach other electronic devices via one or more (wired or wireless) network interfaces 420, exemplary network interfaces 420 including: Bluetooth, WiFi, and Universal Serial Bus (USB), etc. Presentation module 453 is configured to enable the presentation of information (e.g., a user interface for operating peripheral devices and displaying content and information) via one or more output devices 431 associated with user interface 430 (e.g., a display screen, a speaker, etc.). The input processing module 454 is used to detect and translate one or more user inputs or interactions from one or more input devices 432.

[0041] In some embodiments, the apparatus provided in this application can be implemented in software. Figure 2 An application archiving processing device 455 stored in memory 450 is shown. This device can be software in the form of programs and plug-ins, and includes the following software modules: a first query module 4551, a second query module 4552, a third query module 4553, and an archive loading module 4554. These modules are logically linked and can therefore be arbitrarily combined or further separated according to their implemented functions. The functions of each module will be described below.

[0042] In other embodiments, the apparatus provided in this application can be implemented in hardware. As an example, the apparatus provided in this application can be a processor in the form of a hardware decoding processor, which is programmed to execute the archiving processing method of the application provided in this application. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0043] The following describes the application archiving method provided in the embodiments of this application. As mentioned above, the electronic device implementing the application archiving method of the embodiments of this application can be a terminal, a server, or a combination of both. Therefore, the executing entity of each step will not be described again below.

[0044] See Figure 3 , Figure 3 This is a flowchart illustrating the archiving method for the application provided in the embodiments of this application. Figure 1 , will combine Figure 3 The steps shown are explained as follows: Figure 3 As shown, taking the server as the execution subject of the application's archiving processing method as an example, the method includes the following steps 101 to 104: In step 101, in response to the archive recovery request of the first application on the first device, the first device identifier of the first device is determined, and the first archive data associated with the first device identifier is queried from the database.

[0045] Here, the first device is the electronic device currently initiating the save / restore request, such as a mobile phone, tablet, or computer. The first application is the application running on the first device, such as a game or document editing software. The save / restore request is used to trigger the retrieval and loading of saved data, such as from a database. When a user opens the first application on the first device for the first time, the save / restore request can be automatically triggered. For example, if the first application is a game, when the user opens the game application for the first time on a different device, the game application will automatically pop up a prompt asking "Restore historical progress?" If the user confirms, the game application will automatically generate a save / restore request. Alternatively, the user can generate a save / restore request by interacting with the save / restore control in the first application; for example, the user can click the "Restore Save" button in the game application.

[0046] The first device identifier is an identifier used to uniquely identify the first device. The database is a storage system used to store device identifiers, accounts, archived data, and associated relationships; the database can be deployed locally on the terminal or on a cloud server. The first archived data is the archived data associated with the first device identifier, that is, the application status data of the first application uploaded or saved by the first device at historical moments.

[0047] In some embodiments, determining the first device identifier of the first device can be achieved by: determining the device type of the first device; when the device type is a first type, obtaining the first device identifier of the first device through the native identifier interface of the first device; when the device type is a second type, obtaining a pre-stored globally unique identifier from the keychain service of the first device, and determining the globally unique identifier as the first device identifier.

[0048] Here, the first type can be an Android system device. The native identification interface of the first device can be an interface provided by the Android system or application engine (such as the Unity engine) for obtaining the unique hardware identifier of the device (e.g., the SystemInfo.deviceUniqueIdentifier application programming interface (API)). For the first device of the first type, the first device identifier of this single device can be obtained directly through the native identification interface.

[0049] The second type can be an iOS system device. Keychain Service is a secure storage mechanism provided by the iOS system that persistently saves data and retains it even after the application is uninstalled (provided the device has not been factory reset). The pre-stored globally unique identifier (GUID) is an identifier generated when the first application runs on the first device. For the second type of first device, the globally unique identifier (GUID) can be directly obtained from Keychain Service as the first device identifier.

[0050] In this embodiment, when the device type of the first device is the second type, if the pre-stored globally unique identifier cannot be obtained from the keychain service of the first device, it indicates that the first application is running on the first device for the first time. At this time, in response to the first application running on the first device for the first time, a globally unique identifier for the first device is generated and stored in the keychain service of the first device. The access attribute of the keychain service is set to non-synchronizable, so that the globally unique identifier is only stored locally on the current first device and is not synchronized through the cloud.

[0051] For example, the first application is a game, and the first device is an iOS mobile terminal. When a user installs and opens the game on this first device for the first time, the game attempts to read a globally unique identifier from the Keychain Service. Since it's the first run, the Keychain Service doesn't store the corresponding globally unique identifier, so the game determines it's a first-run scenario and generates a unique string (e.g., f47ac10b-58cc-4372-a567-0e02b2c3d479) as the globally unique identifier using the System.Guid.NewGuid().ToString() method. This globally unique identifier is then written to the Keychain Service, with the access attribute (kSecAttrSynchronizable) configured to False (i.e., not synchronized) during the write process. This ensures that the globally unique identifier is only stored in the Keychain Service of the current first device and is not synchronized to other iOS devices of the user via cloud services. Subsequent times when the user opens the game again on this first device, the game can directly read this globally unique identifier from the Keychain Service as the first device identifier.

[0052] In some embodiments, in response to the first application running on the first device for the first time, a globally unique identifier may be generated based on at least one of the hardware information of the first device (e.g., serial number, hash value of physical (Media Access Control, MAC) address), timestamp, and random number.

[0053] In some embodiments, in response to the first application running on the first device for the first time, it may also request the server to allocate a unique identifier. The server stores the association between the unique identifier and the device information summary of the first device, and the first device subsequently uses the unique identifier as the first device identifier.

[0054] In some embodiments, in response to the first application running on the first device for the first time, the user's biometrics (e.g., fingerprints, facial features, etc.) can also be acquired, the biometrics can be encrypted, and a digest can be obtained. An association is established between the digest and a first device identifier of the first device, so that the associated first device identifier can be obtained by performing biometric identification on the user.

[0055] This application embodiment achieves accurate identification and secure binding of device identities across different operating systems (such as Android and iOS) by determining the first device identifier based on device type: For Android devices, the native interface is directly called to obtain the unique hardware identifier, ensuring efficiency and stability; for iOS devices, the Keychain Service is used to persistently store a globally unique identifier (GUID), which is generated and configured to be non-synchronizable upon first run, avoiding cross-device data confusion and ensuring user data isolation and privacy. Simultaneously, when no pre-stored identifier is found in the Keychain, it is automatically created and saved locally, supporting identifier generation in the first run scenario and enhancing identifier uniqueness and anti-counterfeiting capabilities through hash values, timestamps, random numbers, or server allocation. This achieves a highly reliable, highly secure, and traceable device identification mechanism across multiple devices and scenarios, significantly improving the accuracy of the archive recovery process and the consistency of user experience.

[0056] In some embodiments, when first archived data associated with a first device identifier is found, the first archived data is loaded into a first application so that the first application can continue to run from the state corresponding to the first archived data.

[0057] Here, the first archived data may include the state information of the first application at the first moment of runtime, such as user operation records, parameter configurations, progress nodes, etc. The first moment is the moment when the first archived data is saved. When there is only one first archived data, the retrieved first archived data can be transferred to the runtime memory of the first application, and through preset parsing logic, the first archived data is converted into a format that the first application can recognize. The interface display, functional status, user progress, etc. of the first application will be completely restored to the state at the first moment recorded by the first archived data.

[0058] For example, in a game, the game client transmits the retrieved first save data (including character level, current map location, acquired items, quest progress, and other historical status information) to the game's runtime memory. Through data parsing, the first save data is mapped to various game systems. For instance, "character level 30" is mapped to the character attribute panel, "located in the 'Misty Forest' map coordinates (X: 120, Y: 80)" is mapped to the map scene system, and "possessing the 'Flame Sword'" is mapped to the inventory system. After loading, the game screen directly reverts to the scene when the first save data was saved: the character stands at the corresponding coordinates in the "Misty Forest," the attribute panel displays level 30, the Flame Sword is displayed in the inventory, and the progress of "collecting 5 magic leaves" in the quest list is displayed as "completed 3 / 5." At this point, the user does not need to start over from the starting village and can directly control the character to continue exploring the Misty Forest to collect the remaining magic leaves or use items in the inventory to deal with encountered monsters.

[0059] When there are multiple first-save data sets, the target save data can be selected from these multiple first-save data sets according to a preset strategy and loaded into the runtime memory of the first application. The preset strategy may include at least one of the following: timestamp priority strategy (selecting the latest first-save data set at the first moment to ensure that the user continues to use the application from the most recent state), user tag priority strategy (if the save data contains user-manually marked "default" or "frequently used" tags, the first-save data set corresponding to that tag is selected first to reflect personalized preferences), save type priority strategy (setting priority according to the save purpose (such as "auto-save", "manual save", "level completion save"), for example, prioritizing the restoration of manual saves to preserve user intent, etc.

[0060] This application embodiment uses a first device identifier as a unique index to directly locate and load the first archive data bound to that first device from the database, achieving precise archive recovery based on the device. It eliminates the need for user login, cloud accounts, or manual selection, automatically identifying device attributes (such as Android native ID or iOS keychain GUID) to ensure that each first device can only recover its own historical state, avoiding accidental recovery across devices or data confusion. This mechanism significantly improves the automation and security of archive recovery, making it particularly suitable for offline scenarios, multi-device switching, or applications without an account system.

[0061] In step 102, when no first archive data associated with the first device identifier is found, the target account for logging into the first application is obtained, and at least one second device identifier associated with the target account is queried from the database.

[0062] Here, when no first archive data associated with the first device identifier is found, it indicates that the first application is running for the first time on the first device, or that the first device has not yet stored valid archive data. For example, when a user uses the first application on the first device, saving is never triggered (e.g., no document is manually saved, or the game exits before reaching the auto-save node), resulting in no archive record associated with the first device identifier in the database. The target account is the unique account used by the user to log in to the first application and identify the user. The target account is an identity credential obtained by the user through registration or authorization (such as association with a third-party account) in the first application, used to associate the user's personal information, operation records, and cross-device data within the application.

[0063] For example, if the first application is a game, the target account can be the user's registered game account (such as "game_user123"), used to record the user's game character, game progress, etc.; if the first application is cloud document software, the target account can be the user's platform account (such as "doc@xxx.com"), used to associate the document records edited by the user on different devices.

[0064] In this embodiment, the database may include a target account, at least one second device identifier, and the association between the second device identifier and the target account. The second device identifier is a unique identifier of another device (not the first device) that is bound to the target account currently logged in by the user, that is, the device identifier of a device on which the user has previously logged in to the first application using the target account and generated archived data in the first application.

[0065] For example, suppose the user's target account is "game123", and the user has used this target account to log in to a game on an Android phone (device identifier "ID-Android-001") and a tablet (device identifier "ID-iOS-002"), and saved game saves on both devices. Then "ID-Android-001" and "ID-iOS-002" can be two second device identifiers associated with the target account "game123".

[0066] In some embodiments, obtaining the target account for logging into the first application in step 102 can be achieved by: detecting the login status of the first application; when the login status is logged in, reading the currently logged-in target account from the local cache of the first application; when the login status is not logged in, triggering the login interface of the first application, and responding to the login request initiated by the user through the login interface, obtaining the target account from the login request.

[0067] Here, the first application can determine whether an account is currently logged in by using locally stored login credentials (such as tokens, session information, etc.). For example, a game application can check if a valid login token is stored locally, and a document application can check if there are any remembered account login records. When the login status is "logged in," the application directly reads the currently logged-in account information from its local cache as the target account. For example, if the user previously logged in with the account "user_001" in the first application and has not logged out, the application can directly retrieve "user_001" from the cache as the target account without requiring the user to enter it again. When the login status is "not logged in," the application can automatically trigger a login interface (such as a pop-up account and password input box, a verification code login window, or a third-party authorization button) to prompt the user to log in. The user can complete the login operation through this interface (such as entering the account and password and submitting, authorizing a third-party account to log in) to initiate a login request. The application extracts the account information from the user's login request and identifies the account information as the target account.

[0068] This application embodiment detects the local login status of the first application and intelligently distinguishes between logged-in and logged-out scenarios, achieving automated identification and retrieval of the target account: when the first application is logged in, the current account is directly read from the local cache, avoiding repeated input and improving efficiency; when it is logged out, the login interface is actively triggered and the user operation is responded to, extracting account information from the login request as the target account. This mechanism not only simplifies the user operation process but also enhances the accuracy and security of account recovery. Combined with the device-identified archived data matching logic in the preceding steps, a dual authentication system of device unique identifier and currently logged-in account is formed, ensuring that archived data can be accurately attributed to the device and associated with the currently logged-in user. Thus, without requiring the user to manually select an account, seamless binding of archive recovery and user identity is achieved, significantly improving usability and user experience consistency in multi-device, multi-account scenarios.

[0069] In step 103, a target device identifier is determined from at least one second device identifier, and second archived data associated with the target device identifier is queried from the database.

[0070] Here, when the database returns a second device identifier associated with the target account, this second device identifier can be directly used as the target device identifier. When the database returns multiple second device identifiers associated with the target account, the target device identifier can be selected manually by the user, or the first application can automatically filter the target device identifier from the multiple second device identifiers according to preset rules. The preset rules can be similar to the preset strategy for filtering target archive data in the above embodiments, and will not be described further here.

[0071] In this embodiment, after determining the target device identifier, the client of the first application sends a query request to the database, carrying the target device identifier in the query request. The database may include the association between device identifiers and archived data, so the database returns the second archived data corresponding to the target device identifier. The second archived data may be historical state data of the first application stored on the target device corresponding to the target device identifier (such as game level progress, item list, document editing content, etc.).

[0072] In some embodiments, see Figure 4 , Figure 4 The determination of the target device identifier from at least one second device identifier in step 103 is shown to be achieved through steps 1031A to 1032A.

[0073] In step 1031A, the device selection interface of the first application is triggered, and at least one second device identifier is displayed in the device selection interface.

[0074] Here, when at least one second device identifier is retrieved from the database, the first application can proactively pop up a device selection interface to display at least one second device identifier that can currently be restored to archive. This embodiment does not limit the presentation format of the device selection interface; for example, it can be a pop-up window, a standalone page, etc. The device selection interface can also display the last time the archive was generated for the second device corresponding to each second device identifier.

[0075] For example, the device selection screen of a game application may display: Second device identifier: ID-Android-001, last save: xxxx-xx-xx; Second device identifier: ID-iOS-002, last save: xxxx-xx-xx.

[0076] In step 1032A, in response to the selection operation performed by the user in the device selection interface, the second device identifier associated with the selection operation is determined as the target device identifier.

[0077] Here, users can select a second device identifier by clicking, checking, long-pressing, swiping, or other interactive operations in the device selection interface. The first application can capture the selection operation and determine the second device identifier corresponding to the selection operation as the target device identifier.

[0078] This application introduces a device selection interface, which presents multiple second device identifiers to the user in a visual manner and responds to the user's explicit selection operation to accurately determine the target device identifier. This enables flexible control and clear matching of user intent in cross-device save data recovery scenarios, effectively solving the problems of unclear save data ownership and easy misselection during automatic recovery in multi-device environments. It allows users to actively select the device corresponding to the save data they wish to recover (such as restoring game progress from an old phone), avoiding data corruption caused by inconsistent device identifiers or default system logic. At the same time, this interaction method is intuitive and controllable, improving the user's sense of control and experience satisfaction in save data management. It is especially suitable for typical scenarios such as home shared devices and multi-device switching, providing a safe, transparent, and configurable technical path for device-level save data recovery.

[0079] In some embodiments, see Figure 5 , Figure 5 The determination of the target device identifier from at least one second device identifier in step 103 is shown to be achieved through steps 1031B to 1033B.

[0080] In step 1031B, the update time of the archived data of the first application on the second device is determined.

[0081] The second device corresponds one-to-one with the second device identifier.

[0082] Here, the second device refers to the device corresponding to the second device identifier, that is, other archived devices associated with the target account in the database besides the current first device. The update time of the archived data of the first application on the second device is the timestamp of the last time the first application saved the archived data on the second device, which is usually recorded in a standard time format.

[0083] In step 1032B, the time difference between the update time and the current time for each second device is determined.

[0084] For example, the database includes two second device identifiers associated with the target account: ID-Android-001 and ID-iOS-002. The second device identifier ID-Android-001 corresponds to the second device A, and the second device identifier ID-iOS-002 corresponds to the second device B. The update time corresponding to the second device A is t0, and the update time corresponding to the second device B is t1. The time difference between the update time t0 corresponding to the second device A and the current time is calculated to be 2 days, and the time difference between the update time t1 corresponding to the second device B and the current time is 5 days.

[0085] In step 1033B, the second device corresponding to the minimum time difference is determined as the target device, and the identifier of the second device corresponding to the target device is determined as the target device identifier.

[0086] For example, the time difference between the update time t0 corresponding to the second device A and the current time is 2 days, and the time difference between the update time t1 corresponding to the second device B and the current time is 5 days. Then the minimum time difference is 2 days, the target device is the second device A, and the second device identifier ID-Android-001 corresponding to the second device A is determined as the target device identifier.

[0087] This application's embodiments introduce an automated device selection mechanism based on time difference, achieving intelligent target device identification without user intervention: First, the update time of the archived data on each second device is obtained, and the time difference between it and the current time is calculated. Then, the second device with the smallest time difference is selected as the target device, and its corresponding second device identifier is set as the final target device identifier. This strategy ensures that the latest state of the archive is restored first, avoiding historical version restoration problems caused by user forgetting or misselection, significantly improving the accuracy and efficiency of cross-device archive restoration. At the same time, this mechanism is applicable to automatic restoration logic in multi-device scenarios when the user does not actively operate (such as first login, device change), truly realizing "data timeliness-driven restoration decision-making," enhancing the intelligence level of the archiving system and the consistency of user experience.

[0088] In some embodiments, determining the target device identifier from at least one second device identifier in step 103 can also be achieved by: first, determining the activity level of the second device corresponding to each second device identifier; then, determining the second device corresponding to the maximum activity level as the target device, and determining the second device identifier corresponding to the target device as the target device identifier.

[0089] Here, the activity level of the second device is used to characterize the frequency or intensity with which the second device is used to run the first application within a preset time period, and is used to measure whether the second device is the user's "primary device". For each second device corresponding to a second device identifier, the number of times the first application is run, the duration of each run, the number of save operations, and the interval between the most recent run of the first application and the current time can be obtained. The activity level of the second device is obtained by weighted summing of the number of runs, the duration, the number of save operations, and the interval. It should be noted that the preset time period is not limited in this embodiment and can be set according to actual needs, for example, within 30 days. After obtaining the activity level of the second device corresponding to each second device identifier, the maximum value is determined from multiple activity levels, and the second device identifier of the second device corresponding to the maximum value is determined as the target device identifier.

[0090] This application's embodiments introduce activity as a device screening criterion, extending the determination of target device identification from simply relying on timestamps to the level of user behavior habits. This achieves intelligent decision-making that is closer to the actual usage intent. Even if a device's save data is not the latest, as long as it is the device the user uses most often, the save data of that device will still be restored first, significantly improving the personalization and rationality of cross-device save data restoration. At the same time, this mechanism does not require manual selection by the user and avoids erroneous restoration caused by recent updates (such as when a user just ran a game on an old device but experienced a network failure, while the new device is the device that mainly runs the game), truly realizing a save data restoration logic centered on user behavior.

[0091] In step 104, the second archive data is loaded into the first application so that the first application can continue running from the state corresponding to the second archive data.

[0092] Here, the second archived data may include the state information of the first application during its runtime at the second moment, such as user operation records, parameter configurations, progress nodes, etc. The second moment is the time when the second archived data is saved. The second archived data is transferred to the runtime memory of the first application, and through preset parsing logic, the second archived data is converted into a format that the first application can recognize. The interface display, functional status, user progress, etc. of the first application will be completely restored to the state recorded in the second archived data at the second moment.

[0093] This application embodiment prioritizes querying first archive data from the database based on the first device identifier of the first device. This allows users to directly access archives previously stored on the first device without logging into an account, eliminating the need for account binding, thus lowering the barrier to entry for the archive function and improving its flexibility. Simultaneously, archive recovery eliminates the need for account verification and cloud queries, reducing data interaction steps and improving recovery efficiency. When the first archive data associated with the first device identifier is not found, the target account is obtained, and the second device identifier associated with that account is queried. The target device identifier is then determined, and the corresponding second archive data is loaded, enabling cross-device archive recovery. This allows multiple device archives under the same account to be clearly distinguished by device identifiers, enabling precise selection of the second archive data for the target device identifier. This ensures both the continuity of cross-device operations and improves recovery accuracy.

[0094] In some embodiments, see Figure 6 If the login status of the first application on the first device is not logged in, Figure 6 The archiving method for the application provided in the embodiments of this application may further include steps 201 to 203.

[0095] In step 201, in response to the archive saving request of the first application on the first device, third archive data of the first application on the first device is generated based on the current running status data of the first application.

[0096] Here, the save request is an instruction used to trigger the storage of the application's current running state. It can be triggered manually by the user (e.g., clicking the "Save Progress" button) or automatically by the application (e.g., reaching a preset save node, such as after completing a game level). The first application's current running state data can include user operation records (e.g., task completion status, level progress), function parameter configurations (e.g., volume, image quality, interface layout), game character attributes (level, equipment, gold coins, experience, etc.), content editing records (text, images, formats), and the application's internal state (e.g., current scene coordinates, unfinished task list), etc. The third save data is the save data generated based on the first application's current running state when the first device is not logged into an account, containing all the application's current state information.

[0097] In this embodiment of the application, after obtaining the current running status data of the first application, the current running status data of the first application is packaged according to a preset data format (such as encrypted JSON format) to generate third archive data.

[0098] In step 202, the association between the first device identifier and the third archived data is established.

[0099] Here, the first device identifier of the first device is determined, and the association between the first device identifier and the third archive data is established. For example, the first device identifier is used as the key, and the corresponding third archive data is used as the value, forming a one-to-one mapping relationship.

[0100] In step 203, the third archived data, the first device identifier, and the association relationship are stored in the database.

[0101] Here, the third archive data, the first device identifier, and the association between the third archive data and the first device identifier are uploaded and stored together in the database. The database can use the first device identifier as an index to save the corresponding third archive data, ensuring that the saved third archive data can be retrieved later using the first device identifier.

[0102] This application embodiment can still respond to save requests when the first application is not logged in. It generates third save data based on the current running status data and binds it to the first device identifier and stores it in the database. This realizes a flexible mechanism that allows saving without an account. It can persist local state without relying on user identity and ensure that the user's operation progress is not lost in scenarios where they are not logged in (such as trial play, temporary use, or offline environment). At the same time, it establishes a strong association between the save data and the device through the device identifier, providing a reliable basis for automatically matching the corresponding save data or restoring across devices when logging in later. This significantly improves the availability, fault tolerance and user experience consistency of the application in multiple scenarios.

[0103] In some embodiments, see Figure 7 If the login status of the first application on the first device is "logged in", Figure 7 The archiving method for the application provided in the embodiments of this application may further include steps 301 to 304.

[0104] In step 301, in response to the archive saving request of the first application on the first device, third archive data of the first application on the first device is generated based on the current running status data of the first application.

[0105] Here, the specific process of step 301 is the same as that of step 201, and will not be described again.

[0106] In step 302, the number of second device identifiers associated with the target account is determined.

[0107] Here, the database is queried to find all second device identifiers associated with the currently logged-in target account, and the number of all second device identifiers stored in the database is counted.

[0108] For example, in the database, the target account "user123" is currently associated with two secondary device identifiers, "ID-Android-001" and "ID-iOS-002", so the number is 2.

[0109] In step 303, when the quantity is less than a preset quantity threshold, an association is established between the target account, the first device identifier, and the third archived data.

[0110] Here, this application embodiment does not limit the preset quantity threshold, which can be set according to actual needs. For example, the preset quantity threshold is 3, which means that an account can be associated with a maximum of 3 devices. When the quantity is less than the preset quantity threshold, it means that the target account has not yet reached the device binding limit. At this time, it is allowed to establish an association between the first device identifier of the current first device and the target account, and to establish an association between the first device identifier and the third archived data. Alternatively, when the quantity is greater than or equal to the preset quantity threshold, the association between the target account and the first device identifier and the third archived data is not established, and a binding failure prompt message (e.g., "The number of devices bound to this account has reached the limit, and no new devices can be bound") can be displayed on the client interface of the first application.

[0111] In step 304, the third archived data, the first device identifier, the target account, and the associated relationships are stored in the database.

[0112] Here, the third archive data, the first device identifier, the target account, and the association relationships between the first device identifier and the target account, and between the first device identifier and the third archive data, are stored together in the database. The database records the association relationship between the target account and the first device identifier, and saves the third archive data using the first device identifier as an index, making it convenient to query the third archive data later by the target account or the first device identifier.

[0113] In this embodiment, when the first application is logged in, the system determines whether to establish a binding relationship between the account and device archives by judging whether the number of second device identifiers currently associated with the target account is less than a preset threshold (e.g., 3 devices). New bindings are only allowed when the number of devices has not reached the limit. This effectively prevents users from abusing their accounts by registering on a large number of devices, frequently creating new accounts, or forging device identifiers to siphon archives, tamper with data, or engage in account trading. This embodiment significantly limits the number of devices a single account can use to distribute archives. Potential account traders cannot bind high-value archives to a large number of devices for resale without restriction, significantly increasing the cost and difficulty of account trading (requiring continuous registration of new accounts with a low binding limit per account). This ensures the cross-device recovery capabilities of normal users while achieving a security boundary for account archive management through device number control, significantly improving the anti-attack capability and data credibility in multi-device scenarios.

[0114] The following will describe an exemplary application of the embodiments of this application in a real-world application scenario.

[0115] This application provides an application save file processing method, which addresses the problem of mobile game save file recovery mechanisms relying on forcibly binding users to third-party accounts. The proposed method offers a mobile game save file recovery method that eliminates the need for mandatory account binding. The technical problems solved by this application embodiment are described in detail below.

[0116] (1) Device-level unique identifier and persistent storage mechanism: This application embodiment solves the technical problem of generating, storing and reliably retrieving a unique and persistent device identifier (corresponding to the device identifier in the above embodiment) for mobile devices (especially the iOS platform where the native device identifier is limited) without requiring the user to actively log in to a third-party account. This UDID is independent of any user account and is used to uniquely associate the user's local game save (corresponding to the save data in the above embodiment) on the server side. Game save data is a digital record used to persistently record key information such as the player's game progress, status, assets, and achievements.

[0117] (2) Save file recovery mechanism: Based on the device identifier UDID, this application embodiment realizes a function that allows uploading and recovering game save data without binding an account. Users can recover game saves on the server side using the device itself without an account.

[0118] (3) Flexible mechanism for account binding and device association: When a user chooses to actively bind a third-party account (corresponding to the target account in the above embodiments), the user's account information can be associated with the device identifier UDID of the device and uploaded to the server. This mechanism allows users to restore archives by logging in to different bound devices.

[0119] (4) Device Binding Limit Policy: To prevent account abuse (such as large-scale account transactions), a maximum number of devices that a single third-party account can bind is set on the server side (e.g., 5 devices). This policy effectively protects the rights and interests of developers by limiting the number of devices that can be associated with an account for archiving.

[0120] The following describes in detail the implementation process of the application archiving method provided in the embodiments of this application.

[0121] (1) Acquisition and persistent storage of the unique device identifier UDID.

[0122] For the Android platform: Use the SystemInfo.deviceUniqueIdentifier API provided by the Unity engine to obtain the device's native identifier. This native identifier typically has good stability on Android devices and can be used as a UDID.

[0123] For the iOS platform: Due to iOS's restrictions on access to native device identifiers and their potential instability (such as changes due to resets or system updates), directly using `SystemInfo.deviceUniqueIdentifier` cannot guarantee the permanent uniqueness of the identifier. This application utilizes the Keychain service. Upon first running the game or detecting a lack of a valid UDID, the client locally generates a globally unique identifier (GUID), for example, using the C# `System.Guid.NewGuid().ToString()` method. The generated GUID is securely written to the device's local Keychain storage. Keychain is a secure and persistent data storage mechanism provided by iOS; even if the application is uninstalled, the data in Keychain is usually retained as long as the device has not been factory reset. When writing to Keychain, the access property `kSecAttrSynchronizable` is explicitly set to false, ensuring that the GUID is only stored locally on the current device and will not be synchronized to other devices owned by the user through their account ID. This avoids the confusion caused by the same identifier appearing on multiple devices due to cloud synchronization. Subsequent runtimes read this GUID from Keychain as the device's UDID. If the read operation fails, the data will be regenerated and written again.

[0124] (2) Uploading and restoring archives without account binding.

[0125] When the game client needs to save its progress (e.g., upon exiting, at a critical point, or manually saving), it uploads the device identifier (UDID) along with the current game save data to the game server. When a user needs to restore their save data on a new device or after reinstalling the game, the client automatically obtains (or generates) and stores the device identifier (UDID), and uses this UDID to initiate a save data query request to the server. The server retrieves the associated save data based on the received UDID. If a matching save data is found, it is downloaded to the client for restoration.

[0126] (3) Account binding and device association mechanism.

[0127] After a user successfully logs in to a third-party account, the client obtains the account identifier information (corresponding to the target account in the above embodiment) and uploads it to the server along with the device identifier UDID. The server then associates and binds the account identifier information with the device identifier UDID, establishing a mapping relationship between account ID and UDID. Simultaneously, the account identifier information is also associated with the archived data corresponding to the current UDID (if it exists). After this binding is complete, when a user logs in to the same third-party account on other devices: the server can retrieve all bound UDIDs associated with that account. The client can select one of the associated UDIDs to download and restore the archived data, enabling the transfer of archives between multiple devices under a user-bound account.

[0128] (4) Device binding quantity limit policy.

[0129] First, server-side verification: When a client requests to bind a third-party account ID to the current device's UDID: the server first queries the number of valid devices successfully bound to that account ID, x. If x < N (a preset threshold, e.g., N=5), the binding request is allowed, and a new account ID <-> UDID association record is created in the database. If x ≥ N, the binding request is rejected. Then, client feedback: the server notifies the client of the binding result (success / failure). If binding fails, the client displays a user-friendly message (e.g., "This account has reached its device binding limit and cannot bind any more devices"). This embodiment of the application significantly limits the number of devices a single account can be used to distribute archives. Potential account traders cannot bind high-value archives to a large number of devices for resale without restriction, significantly increasing the cost and difficulty of account trading (requiring continuous registration of new accounts with a low binding limit per account), thereby effectively curbing account trading and protecting the interests of developers.

[0130] This application embodiment greatly simplifies the save recovery process by eliminating the mandatory account binding step, reducing the user's operational burden. Respecting user choice, it allows users who are unwilling or inconvenient to bind third-party accounts to seamlessly and conveniently use the save recovery function, effectively improving user satisfaction and retention rates, enhancing user experience, and lowering the barrier to entry. This application embodiment provides a save recovery mechanism that does not rely on specific third-party authentication services, improving the availability and flexibility of application save processing. Even if third-party services are unavailable or users refuse authorization, the core save function remains available. This application embodiment sets a physical upper limit on account save distribution from a technical perspective through a mandatory device binding limit strategy (N≤5), significantly increasing the operational difficulty and economic cost of large-scale abnormal distribution of account saves or resource abuse (requiring more accounts), effectively protecting the virtual economic ecosystem within the game and the interests of developers (such as in-app purchase revenue), and maintaining a fair gaming environment. This application embodiment utilizes the iOS KeyChain service and combines it with the specific access control attribute kSecAttrSynchronizable=false to implement a reliable, persistent, device-unique, and non-cross-device synchronized identifier storage scheme on the iOS platform, laying a key technical foundation for the implementation of bind-free save recovery in the iOS ecosystem.

[0131] It should be noted that in this embodiment, a more complex local unique ID can also be generated based on the hash value of device hardware information (such as serial number, MAC address) or by combining timestamps and random numbers. When the game runs for the first time, the client can also request the server to assign a unique ID. The server stores this ID along with a certain "fingerprint" of the device (such as an anonymized device information digest). Subsequent clients use this server-assigned ID as their UDID. This scheme is suitable for scenarios with good network conditions but high requirements for local stability. It is necessary to properly handle fault tolerance issues caused by the initial lack of network connection and changes in device fingerprints. On devices that support biometric authentication, the encrypted digest or associated token of biometric features (fingerprint, face) can also be bound to the UDID as a higher-security recovery credential (recoverable only by the user, ensuring data security even if the device is lost).

[0132] In this embodiment, the server can also store multiple archive snapshots at different times for the same UDID or account ID, allowing users to choose to restore a specific historical version. When the same account generates archives on different devices, a mechanism can be designed to prompt the user to select or attempt to automatically merge conflicting data.

[0133] In this embodiment, the preset threshold N can be dynamically configurable, flexibly adjusted according to user account status (such as paid user level, activity level) or operational strategies, balancing convenience for ordinary users with flexibility for high-value users. A device binding validity period can also be introduced (e.g., automatic expiration after 90 days of inactivity), or users can be allowed to actively unbind infrequently used older devices to release binding quotas, improve resource utilization, and reduce the management burden caused by long-term invalid bindings. The server needs to record the binding timestamp and process the unbinding logic. When binding or restoring a device, the server can verify whether the hardware and software fingerprint information submitted by the device differs significantly from the information at the time of initial binding (e.g., sudden changes in CPU model or screen resolution) to identify possible device clones or emulators.

[0134] The application archiving method provided in this application embodiment is a scheme that combines local persistent unique identifiers, optional account binding, and binding quantity limits. It can be migrated and applied to other client-server application scenarios that require device identifier or user identifier association and have a limited number of followers, such as: cross-device personalized configuration / setting synchronization, activation and usage restrictions of subscription services on multiple devices, device authorization management in digital rights management, and applications that require anonymous user behavior detection and analysis.

[0135] The following description continues to illustrate the exemplary structure of the application archiving device 455 provided in the embodiments of this application as a software module. In some embodiments, such as Figure 2 As shown, the software modules stored in the application archiving processing device 455 in the memory 450 may include: The first query module 4551 is used to respond to the archive recovery request of the first application on the first device, determine the first device identifier of the first device, and query the first archive data associated with the first device identifier from the database; The second query module 4552 is used to obtain the target account for logging into the first application when no first archive data associated with the first device identifier is found, and to query at least one second device identifier associated with the target account from the database. The third query module 4553 is used to determine the target device identifier from at least one second device identifier and query the second archived data associated with the target device identifier from the database. The archive loading module 4554 is used to load the second archive data into the first application so that the first application can continue to run from the state corresponding to the second archive data.

[0136] In some embodiments, the first query module 4551 is further configured to determine the device type of the first device; when the device type is a first type, obtain the first device identifier of the first device through the native identifier interface of the first device; when the device type is a second type, obtain a pre-stored globally unique identifier from the keychain service of the first device, and determine the globally unique identifier as the first device identifier.

[0137] In some embodiments, the second query module 4552 is further configured to detect the login status of the first application; when the login status is logged in, read the target account currently logged in from the local cache of the first application; when the login status is not logged in, trigger the login interface of the first application, and respond to the login request initiated by the user through the login interface, obtain the target account from the login request.

[0138] In some embodiments, the third query module 4553 is further configured to trigger the device selection interface of the first application, display at least one second device identifier in the device selection interface, and determine the second device identifier associated with the selection operation as the target device identifier in response to the selection operation performed by the user in the device selection interface.

[0139] In some embodiments, the third query module 4553 is further configured to determine the update time of the archived data of the first application on the second device, wherein the second device corresponds one-to-one with the second device identifier; determine the time difference between the update time corresponding to each second device and the current time; determine the second device corresponding to the smallest time difference as the target device, and determine the second device identifier corresponding to the target device as the target device identifier.

[0140] In some embodiments, the third query module 4553 is further configured to determine the activity level of the second device corresponding to each second device identifier; determine the second device corresponding to the maximum activity level as the target device, and determine the second device identifier corresponding to the target device as the target device identifier.

[0141] In some embodiments, the archive loading module 4554 is further configured to load the first archive data into the first application when the first archive data associated with the first device identifier is found, so that the first application can continue to run from the state corresponding to the first archive data.

[0142] In some embodiments, the application's archiving processing device 455 further includes an archiving module, which, in response to an archiving request of the first application on the first device when the login status of the first application on the first device is not logged in, generates third archive data of the first application on the first device based on the current running status data of the first application; constructs an association between the first device identifier and the third archive data; and stores the third archive data, the first device identifier, and the association in a database.

[0143] In some embodiments, the archive saving module is further configured to, in response to an archive saving request of the first application on the first device, generate third archive data of the first application on the first device based on the current running status data of the first application when the login status of the first application on the first device is logged in; determine the number of second device identifiers associated with the target account; when the number is less than a preset number threshold, construct an association relationship between the target account, the first device identifier, and the third archive data; and store the third archive data, the first device identifier, the target account, and the association relationship in a database.

[0144] This application provides a computer program product comprising a computer program or computer-executable instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer-executable instructions from the computer-readable storage medium and executes the computer-executable instructions, causing the electronic device to perform the archiving processing method described above in this application embodiment.

[0145] This application provides a computer-readable storage medium storing computer-executable instructions or a computer program. When the computer-executable instructions or the computer program are executed by a processor, the processor will execute the archiving method of the application provided in this application embodiment, for example, such as... Figure 3 The application's archive processing method is shown.

[0146] In some embodiments, the computer-readable storage medium may be a memory such as RAM, ROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories.

[0147] In some embodiments, computer-executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0148] As an example, computer-executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., files that store one or more modules, subroutines, or code sections).

[0149] As an example, computer-executable instructions can be deployed to execute on a single electronic device, or on multiple electronic devices located at one location, or on multiple electronic devices distributed across multiple locations and interconnected via a communication network.

[0150] In summary, the device identifier priority and account fallback archiving recovery mechanism of this application embodiment enables local archiving recovery without mandatory binding, supports cross-device archiving migration, and improves the availability and flexibility of archiving processing. Combined with the device binding quantity limit strategy, it effectively reduces the transaction risk of accounts, and innovatively utilizes keychain service to achieve unique, persistent, and non-cross-device synchronized identifier storage, solving the key technical problem of account-free archiving.

[0151] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. An application archiving method, characterized in that, The method includes: In response to an archive recovery request from a first application on a first device, the device type of the first device is determined; When the device type is the first type, the first device identifier of the first device is obtained through the native identifier interface of the first device. When the device type is the second type, a pre-stored globally unique identifier is obtained from the keychain service of the first device, and the globally unique identifier is determined as the identifier of the first device; If the globally unique identifier is not present in the keychain service, then in response to the first application running for the first time, a globally unique identifier for the first device is generated, the globally unique identifier is stored in the keychain service, and the access attribute of the keychain service is set to non-synchronizable, so that the globally unique identifier is only stored locally on the current first device and is not synchronized through the cloud. Retrieve the first archived data associated with the first device identifier from the database; When no first archive data associated with the first device identifier is found, the target account for logging into the first application is obtained, and at least one second device identifier associated with the target account is queried from the database; Determine a target device identifier from the at least one second device identifier, and query second archived data associated with the target device identifier from the database; Load the second archived data into the first application so that the first application can continue running from the state corresponding to the second archived data.

2. The method according to claim 1, characterized in that, The step of obtaining the target account for logging into the first application includes: Detect the login status of the first application; When the login status is logged in, the target account currently logged in is read from the local cache of the first application; When the login status is not logged in, the login interface of the first application is triggered, and in response to the login request initiated by the user through the login interface, the target account is obtained from the login request.

3. The method according to claim 1, characterized in that, Determining the target device identifier from the at least one second device identifier includes: Trigger the device selection interface of the first application, and display the at least one second device identifier in the device selection interface; In response to a selection operation performed by the user in the device selection interface, the second device identifier associated with the selection operation is determined as the target device identifier.

4. The method according to claim 1, characterized in that, Determining the target device identifier from the at least one second device identifier includes: Determine the update time of the archived data of the first application on the second device, wherein the second device corresponds one-to-one with the second device identifier; Determine the time difference between the update time and the current time for each of the second devices; The second device corresponding to the smallest time difference is determined as the target device, and the identifier of the second device corresponding to the target device is determined as the target device identifier.

5. The method according to claim 1, characterized in that, Determining the target device identifier from the at least one second device identifier includes: Determine the activity level of the second device corresponding to each second device identifier; The second device corresponding to the highest activity level is identified as the target device, and the second device identifier corresponding to the target device is identified as the target device identifier.

6. The method according to claim 1, characterized in that, The method further includes: When the first archived data associated with the first device identifier is found, the first archived data is loaded into the first application so that the first application can continue to run from the state corresponding to the first archived data.

7. The method according to any one of claims 1 to 6, characterized in that, When the login status of the first application on the first device is not logged in, the method further includes: In response to the first application's archive saving request on the first device, third archive data of the first application on the first device is generated based on the current running status data of the first application; Establish the association between the first device identifier and the third archived data; The third archived data, the first device identifier, and the association relationship are stored in the database.

8. The method according to any one of claims 1 to 6, characterized in that, When the login status of the first application on the first device is logged in, the method further includes: In response to the first application's archive saving request on the first device, third archive data of the first application on the first device is generated based on the current running status data of the first application; Determine the number of second device identifiers associated with the target account; When the quantity is less than a preset quantity threshold, an association is established between the target account, the first device identifier, and the third archived data; The third archived data, the first device identifier, the target account, and the association relationship are stored in the database.

9. An application archiving processing device, characterized in that, The device includes: The first query module is used to respond to an archive recovery request from a first application on a first device, determine the device type of the first device; when the device type is a first type, obtain the first device identifier of the first device through the native identifier interface of the first device; when the device type is a second type, obtain a pre-stored globally unique identifier from the keychain service of the first device, and determine the globally unique identifier as the first device identifier; if the globally unique identifier is not in the keychain service, generate the globally unique identifier of the first device in response to the first application's first run, store the globally unique identifier in the keychain service, and set the access attribute of the keychain service to non-synchronization, so that the globally unique identifier is only stored locally on the current first device and is not synchronized through the cloud; query the first archive data associated with the first device identifier from the database; The second query module is used to obtain the target account that logs into the first application when no first archive data associated with the first device identifier is found, and to query at least one second device identifier associated with the target account from the database. The third query module is used to determine the target device identifier from the at least one second device identifier, and to query the second archived data associated with the target device identifier from the database; An archive loading module is used to load the second archive data into the first application so that the first application can continue running from the state corresponding to the second archive data.

Images