Application installation method based on cloud phone, cloud platform system and related equipment

Abstract

The present application provides a cloud phone-based application installation method, cloud platform system, and related equipment. The method includes the following steps: the cloud platform system provides a cloud phone configuration interface to the user, configures a template cloud phone according to the user's first input, and then provides a network shared file configuration interface to the user. According to the user's second input, the directory of the template cloud phone is stored in a first network shared file. Then, according to the user's third input, at least one cloud phone to be configured is configured to mount the first network shared file to complete the installation of multiple applications. This eliminates the need for the cloud platform system to be installed in advance for each cloud phone. The cloud phone can install, update, and uninstall applications by mounting network shared files, reducing the storage space occupied by the cloud phone and the operating and maintenance costs of the cloud phone. At the same time, it increases the startup, operation, and update speed of applications, thereby improving the user experience.

Description

Technical Field

[0001] The present application relates to the field of cloud computing, and in particular to a cloud phone-based application installation method, a cloud platform system, and related equipment. Background Art

[0002] A cloud phone is a cloud server with an operating system and virtual phone functionality. It significantly extends and expands the capabilities of physical phones, enabling applications such as cloud gaming and mobile office. In these scenarios, applications (apps) are installed on the cloud phone. App users can remotely connect to the cloud phone through their personal devices. The cloud phone streams the rendered audio and video from the app to the device, which then displays the stream on its screen. This allows app users to use hardware-intensive apps on devices with limited image processing and data processing capabilities, or even limited streaming capabilities.

[0003] Unlike physical phones, apps on cloud phones are generally managed by the user who purchased the cloud phone service. If a user purchases 1,000 cloud phones, each offering 100 apps, then each cloud phone will need to have 100 apps installed. If each app takes 1GB to install (and likely exceeds 1GB in reality), then one cloud phone will require 100GB of storage space, and 1,000 cloud phones will require 100TB of storage space. Updating any one app will also take up a significant amount of storage space, exorbitant operating and maintenance costs for game manufacturers. Furthermore, a cloud phone with 100 apps installed is more prone to lag during startup and app execution, diminishing the user experience. Summary of the Invention

[0004] This application provides a cloud phone-based application installation method, cloud platform system and related equipment, which are used to solve the problems of large storage space occupation, high operation and maintenance costs, and easy freezes during application operation when installing and updating applications on massive cloud phones.

[0005] In a first aspect, a cloud phone-based application installation method is provided, which includes the following steps: a cloud platform system (hereinafter referred to as the cloud platform) provides a cloud phone configuration interface to the user, configures a template cloud phone according to the user's first input, and then provides a network shared file configuration interface to the user, stores the directory of the above-mentioned template cloud phone to a first network shared file according to the user's second input, and then configures at least one cloud phone to be configured to mount the first network shared file according to the user's third input to complete the installation of multiple applications.

[0006] Among them, at least one cloud phone to be configured can be, for example, one cloud phone to be configured or multiple cloud phones to be configured. In actual applications, based on the hardware configuration of the physical server running the cloud phone, the embodiment of the present invention can support 1-1000 or more cloud phones to be configured to install multiple applications at the same time.

[0007] By implementing the method described in the first aspect, when the cloud platform installs and updates massive cloud applications, there is no need to install the applications in each cloud phone. The cloud phone to be configured can mount the installation information of various applications from the network shared file, thereby realizing the startup, operation and update of the application without installing the application in advance, thereby reducing the storage space occupied by the cloud phone and the operating and maintenance costs of the cloud phone. At the same time, the startup, operation and update speed of the App can be improved, thereby improving the user experience.

[0008] In a possible implementation of the first aspect, before providing the network shared file configuration interface, the cloud platform may also provide the user with an object storage interface, obtain the directory of the template cloud phone according to the user's fourth input and store the directory of the template cloud phone in the object storage device, and the cloud platform may also synchronize the directory storage of the template cloud phone stored in the object storage device to the first network shared file according to the user's second input through the network shared file configuration interface.

[0009] Optionally, before providing the network shared file configuration interface, the method may further include the following steps: providing a network shared file creation interface, where the network shared file creation interface is used to create a network shared file according to a sixth input of the user.

[0010] Optionally, before providing the object storage interface, the method may further include the following steps: providing an object storage creation interface, where the object storage creation interface is used to create an object storage according to a seventh input of the user.

[0011] When implementing the above-mentioned implementation method, the directory of the template cloud phone is first exported to the object storage device, and then the object storage device synchronizes the directory of the template cloud phone to the network shared file. Among them, the storage capacity of the object storage device is large, and the storage capacity of the network shared file is small. Therefore, multiple network shared files can be used to synchronize the installation information in the object storage device separately, thereby increasing the number of applications that users can install. In addition, the object storage device can also manage the installation information exported by the template cloud phone, such as recording the storage path, version information, corresponding user information, application name, type, etc. of the installation information, thereby further improving installation efficiency.

[0012] This application provides two ways to implement the mounting of network shared files on the cloud phone to be configured. The two implementation methods are explained below.

[0013] In a possible implementation of the first aspect, the mounting of network shared files can be achieved by configuring a first multi-layer file system in the cloud phone to be configured, specifically, the first network shared file includes a first installation directory and a second installation directory, wherein the second installation directory includes dynamic data of multiple applications, and the first installation directory includes static data of multiple applications; the cloud phone configuration interface is also used to configure at least one cloud phone to be configured to connect to the first installation directory in the first network shared file in a read-only manner according to a third input of the user; the cloud phone configuration interface is also used to configure a first multi-layer file system in at least one cloud phone to be configured according to the third input of the user, the first multi-layer file system is used for allowing at least one cloud phone to be configured to perform read and write operations on the second installation directory, wherein the first multi-layer file system includes an upper directory and a lower directory, the lower directory is used to connect to the second installation directory in a read-only mapping manner, the upper directory is used to store modified data generated during the operation of at least one application installed in the cloud phone to be configured, and the first multi-layer file system is used to superimpose the upper directory and the lower directory.

[0014] In a specific implementation, the above-mentioned first multi-layer file system can be implemented through an Overlay file system. The read-only mode can be to map the first installation directory in the network shared file to the cloud phone through a soft connection, so that when the cloud phone requests access to the first installation directory, it will jump to the first installation directory stored in the network shared file through the network, thereby realizing the installation information under the application installation directory mounted from the network shared file in a read-only manner.

[0015] By implementing the above-mentioned implementation method, the cloud phone to be configured mounts the network shared files through a combination of the first multi-layer file system and the read-only mode. This not only ensures the reading and writing of data during the operation of the application, and realizes the startup and operation of the application on the cloud phone to be configured, but also realizes the update of the application by remounting the new version installation information. In the scenario where a large number of cloud phones are configured with applications, the cloud platform does not need to install the application in each cloud phone to realize the installation, operation and update of the application, thereby reducing the storage space occupied by the cloud phone and reducing the operation and maintenance costs of the cloud phone.

[0016] In a possible implementation of the first aspect, the mounting of the network shared file by the cloud phone to be configured can be achieved by configuring a second multi-layer file system in the network shared file. Specifically, the cloud platform can configure the first network shared file to connect to the first installation directory in the first network shared file in a read-only manner according to the user's third input through the network shared file configuration interface, and then configure the second multi-layer file system in the first network shared file according to the user's third input through the network shared file configuration interface. The second multi-layer file system is used to receive and process data read and write requests sent by at least one cloud phone to be configured, wherein the second multi-layer file system includes an upper directory and a lower directory, the lower directory is used to connect to the second installation directory in a read-only mapping manner, the upper directory is used to store modified data generated during the operation of the application installed in the first network shared file, and the second multi-layer file system is used to superimpose the upper directory and the lower directory.

[0017] In a specific implementation, the above-mentioned second multi-layer file system can be implemented through the Overlay file system. The network shared file can first create a blank directory with the above-mentioned second multi-layer file system built in. The cloud phone to be configured is connected to the blank directory in read-only mode. Then the network shared file creates a copy directory. The copy directory template is a mirror image of the cloud phone directory. The blank directory with the Overlay file system deployed is mounted on the copy directory. The cloud phone to be configured is connected to the blank directory in read-only mode, thereby realizing the application installation of the cloud phone to be configured. The blank directory includes an upper directory and a lower directory. The lower directory is used to connect to the second installation directory in the copy directory in a read-only mapping manner. The upper directory is used to store the modified data generated during the operation of the application installed in the first network shared file. The second multi-layer file system is used to superimpose the upper directory and the lower directory. The cloud phone to be configured can read data from the blank directory 1 with the copied directory mounted on it, and write the generated modified data into the blank directory 1 through the second multi-layer file system of the blank directory 1, thereby realizing the installation of the application on the cloud phone to be configured.

[0018] The implementation of the above-mentioned method can not only ensure the reading and writing of data during the operation of the application, and realize the startup and operation of the application on the cloud phone to be configured, but also realize the update of the application by re-mounting the installation information of the new version. In the scenario where a large number of cloud phones are configured with applications, the cloud platform does not need to install the application in each cloud phone to realize the installation, operation and update of the application, thereby reducing the storage space occupied by the cloud phone and reducing the operation and maintenance costs of the cloud phone.

[0019] In one possible implementation of the first aspect, shared network files may include user data, which includes local business data and local habit data generated during the operation of the application. For example, if the application is a game application, the user data of the mobile game application may include the user's default account information, historical login zone information, etc., and the user data of a stand-alone game application may include game clearance records, game character data, etc.; if the application is an office application, such as a mailbox application, the user data may include the user's mailbox account binding information, mailbox business card settings, etc., and the user data of an office communication application may include the user's historical chat records, user historical account information, user historical file information, business data, etc. It should be understood that user data may also include private data generated by the user during the operation of other types of applications, which will not be explained one by one here.

[0020] When implementing the above implementation method, since the data generated during the operation of the application are all stored in the network shared file, when the application is updated, after the updated copy directory is generated according to the updated installation information, the above user data can still be retained in the blank directory of the network shared file, so that after the application is updated, the user data can still be retained, and the user does not need to re-set account information, re-download business data, etc., thereby improving the user experience.

[0021] In a possible implementation of the first aspect, the template cloud phone, at least one cloud phone to be configured, and the first network shared file are located in a first data center. When the first cloud phone to be configured in at least one cloud phone to be configured is migrated from the first data center to the second data center, the network shared file configuration interface is also used to create a second network shared file located in the second data center based on the user's fifth input, and the second network shared file is a mirror image of the first network shared file.

[0022] For example, suppose user A is working in Beijing (North China), and uses the cloud phone 1 and network shared file 1 of the North China Data Center to run an office application. Later, user A travels to Shenzhen to work (South China). At this time, the object storage device can send a request to the South China Data Center to create a network shared file 1', and then synchronize the installation information of the office application to the network shared file 1'. The network shared file 1 quickly synchronizes the user data generated by user A when working in Beijing to the network shared file 1', so that the cloud phone 1' mounted with the network shared file 1' can retain the user data while running the App. The user does not need to re-enter the account password, re-download business data, etc., thereby improving the user experience.

[0023] By implementing the above implementation method, since the application installation information and user data are stored in the network shared file, when the cloud phone to be configured is migrated across data centers, the application installation information and user data can still be retained, thereby avoiding the problem of application installation failure or slow application installation due to data incompatibility across regional data centers, and improving the user experience.

[0024] In one possible implementation of the first aspect, the network shared file configuration interface is further used to configure, based on a sixth input from the user, a first to-be-configured cloud phone migrated to the first data center to mount a second network shared file to complete the installation of multiple applications. For example, assuming that cloud phone 2 used by a user is migrated from server 1 to server 2, cloud phone 2 can be first stopped, the mount between cloud phone 2 and the network shared file can be canceled, and then cloud phone 2' can be created on server 2. The mount directory on the network shared file is provided to cloud phone 2', and cloud phone 2' can mount the network shared file through the mount directory to achieve resource migration of the cloud phone.

[0025] By implementing the above implementation method, since the application installation information and user data are stored in the network shared file, when the cloud phone to be configured is migrated between servers in the data center, the migrated cloud phone can re-mount the network shared file to achieve the application installation of the migrated cloud phone, which shortens the resource migration speed in the data center to seconds and improves the user experience.

[0026] In a possible implementation of the first aspect, a network shared file may be deployed with a server, and a cloud phone to be configured may be deployed with a client, wherein the client is used to aggregate the read and write IO requests generated by the cloud phone to be configured (such as a request to write modified data generated during the App running process to the second installation directory, a request to read the first installation directory, etc.) and send them to the server of the network shared file, and the server is used to receive the above-mentioned read and write IO requests sent by the client, and disassemble them and send them to the second multi-layer file system, and the second multi-layer file system implements the read and write operations of the installation information. In a specific implementation, the network shared file may cache the received IO requests in the memory first, and after receiving the IO request sent by the cloud phone to be configured, it may first update the data in the cache, and then generate an asynchronous IO request. Then, the IO requests of a large number of small files are aggregated into a single IO request, and the aggregated IO data is sent to the server at one time. The server may parse the received IO requests and then update them in batches to the storage medium.

[0027] By implementing the above implementation method, the IO requests in the cloud phone to be configured can be sent to the client, which aggregates the received IO requests and sends them to the server for processing, thereby reducing the number of IO requests received by network shared files, reducing the processing pressure of network shared files, and improving the efficiency of App startup, operation, update and uninstallation.

[0028] It is understandable that the cloud phone to be configured can also update the application through the application installation method based on the cloud phone. Specifically, the cloud platform can install the updated application to the template cloud phone and export it to the object storage device (or the user operates the template cloud phone to update the application, which is not specifically limited in this application). The object storage device synchronizes the new version installation information to the network shared file. The network shared file can provide a new mount directory to the cloud phone to be configured (of course, the mount directory can also be kept unchanged, and only the installation information under the mount directory is updated). The cloud phone to be configured can re-mount the new version installation information in the network shared file according to the above new mount directory to achieve the update of the App.

[0029] Similarly, after deleting the installation information of an application in the object storage device and network shared files, the application can be uninstalled. Users do not need to operate each cloud phone to uninstall, which improves the user experience.

[0030] Optionally, the template cloud phone and the cloud phone to be configured include a virtual machine, a container, and a bare metal server.

[0031] Optionally, the applications include game applications, work applications, educational applications, video applications, social applications, and virtual reality applications.

[0032] Optionally, users can purchase a template cloud phone through the console or API, operate the template cloud phone to install the required applications, and then the cloud platform creates network shared files and object storage devices, and configures the network shared files, object storage devices and the cloud phone to be configured, so that the cloud phone to be configured mounts the network shared files to install the applications.

[0033] Alternatively, users can purchase a template cloud phone through a console or API, operate the template cloud phone to install the required applications, and then use various interfaces provided by the cloud platform to create and configure network shared files, object storage devices, and the cloud phone to be configured, so that the cloud phone to be configured can mount the network shared files to install the applications. This interface can be an API interface, a web page, an application, or other form of console, and this application does not specifically limit it.

[0034] Optionally, users can also upload a list of applications to be installed and the number x of cloud phones to be configured through the console or API. The cloud platform will create a template cloud phone, a network shared file, and an object storage device based on the number of applications and the application list uploaded by the user, and install the applications in the above application list on the template cloud phone. The directory of the template cloud phone will then be exported to the object storage device, and the network shared file will synchronize the installation information in the object storage device. x cloud phones will be configured to be mounted on the network shared file, thereby achieving the purpose of installing the applications in the application list on the x cloud phones required by the user. The user's operation during the entire cloud phone application installation is very convenient, which improves the user experience.

[0035] In a second aspect, a cloud platform is provided, including: providing a cloud phone configuration interface unit for providing a cloud phone configuration interface, the cloud phone configuration interface is used to configure a template cloud phone according to a first input of a user, the template cloud phone is provided with multiple applications, and the directory of the template cloud phone records the installation information of multiple applications; providing a network shared file configuration interface unit for providing a network shared file configuration interface, the network shared file configuration interface is used to store the directory of the template cloud phone to a first network shared file according to a second input of the user; wherein the cloud phone configuration interface is also used to configure at least one cloud phone to be configured to mount the first network shared file according to a third input of the user to complete the installation of multiple applications.

[0036] The second aspect or any implementation of the second aspect is an implementation of the device corresponding to the first aspect or any implementation of the first aspect. The description in the second aspect or any implementation of the second aspect is applicable to the first aspect or any implementation of the first aspect and will not be repeated here.

[0037] In a third aspect, a computer-readable storage medium is provided, comprising instructions, which, when executed on a computing device, cause the computing device to execute the method as described in the first aspect.

[0038] In a fourth aspect, a computing device is provided, comprising a processor and a memory, wherein when the processor executes the code in the memory, the computing device implements the method described in the first aspect.

[0039] In a fifth aspect, a computer program product is provided, which, when read and executed by a computing device, implements the method described in the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art.

[0041] Figure 1 It is an architectural diagram of a public cloud system;

[0042] Figure 2 This is a schematic diagram of the structure of a cloud phone-based application installation system provided by this application;

[0043] Figure 3 This is a flowchart of the steps of a cloud phone-based application installation method provided by this application;

[0044] Figure 4A-4B This is a schematic diagram of the structure of a cloud phone to be configured to mount network shared files provided by this application;

[0045] Figure 5A~Figure 5B This is a schematic diagram of another structure of a cloud phone to be configured to mount network shared files provided by this application;

[0046] Figure 6 This is a flow chart of a cross-data center migration process for a cloud phone to be configured, provided by this application;

[0047] Figure 7 This is a flow chart of migration within a cloud phone data center to be configured, provided by this application;

[0048] Figure 8 This is a flowchart of the steps of a cloud phone-based application installation method provided by this application;

[0049] Figure 9 This is a schematic diagram of a console interface provided by this application;

[0050] Figure 10 This is another console interface diagram provided by this application;

[0051] Figure 11 This is a schematic diagram of the structure of a cloud platform provided by this application;

[0052] Figure 12 This is a structural diagram of a computing device provided by this application. DETAILED DESCRIPTION

[0053] The following will describe the technical solutions in the embodiments of this application in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0054] In order to facilitate understanding of the embodiments of the present application, first, some of the terms involved in the present application are explained.

[0055] Container: A container is a group of processes that are subject to resource constraints and isolated from each other.

[0056] Cloud phone: A container, virtual machine or bare metal server with a mobile phone operating system and virtual mobile phone functions that is virtualized in a physical server. Its essence is to transfer the applications on the mobile phone to the container, virtual machine or bare metal server on the public cloud for operation. Different cloud phones are isolated from each other and do not interfere with each other. Cloud phones can install local mobile phone applications, which run in the cloud phone. The audio and video streams generated during the operation can be sent to the user's local terminal device for display and playback. The control commands generated by the user's local terminal device based on the displayed and played audio and video streams can also be sent to the cloud phone. The cloud phone controls the running status of the application according to the control commands, thereby transferring the local mobile phone applications to the cloud phone for operation. The user's local terminal device does not need to install a large number of applications that consume hardware resources, which can achieve lightweight applications.

[0057] Public cloud: The core attribute of public cloud is shared resource service. It refers to the cloud infrastructure and services provided by cloud providers to users (also known as tenants) that can be used through public networks (such as the Internet). The cloud infrastructure and services are set up in the cloud provider's data center. Users pay the cloud provider to obtain the right to use the cloud infrastructure and services, so that they can use the cloud infrastructure and services remotely.

[0058] Object Storage Service (OBS): An object-based, mass storage service in the public cloud that provides customers with massive, secure, highly reliable, and low-cost data storage capabilities. OBS is an internet-accessible service, providing a web service interface based on HTTP / HTTPS protocols. Users can access and manage data stored in OBS anytime, anywhere, using the OBS management console or various OBS tools, from any internet-connected computer.

[0059] Scalable File Service (SFS): A public cloud service that provides a high-performance, scalable file system. SFS provides shared access to multiple Elastic Cloud Servers (ECS), containers, and Bare Metal Servers (BMS) on the public cloud. Typically, after creating a file system, users can mount it on a cloud server, allowing multiple cloud servers to share the file system.

[0060] Mounting: The process by which the operating system makes files and directories on a storage device (such as a hard disk or shared resource) accessible to users through the file system of the device. For example, when a user accesses file A on a storage device, if file A is mounted to directory B, the user can access file A on the storage device by accessing directory B. Directory B is also called a mount point. The mount point can be on the user's device, on a storage device, or in a virtual disk or virtual folder.

[0061] Secondly, a brief description of the "public cloud" application scenarios involved in this application is given.

[0062] With the rapid development of cloud computing technology and various network infrastructures, traditional Internet technology (IT) business architectures are gradually migrating to the public cloud, and an increasing number of business applications are being redesigned and used based on this architecture. Within this public cloud architecture, applications on a user's phone are installed on a cloud phone. The cloud phone can stream the audio and video rendered during the application's execution to terminal device 110. Terminal device 110 simply displays the received audio and video streams on its screen, making applications truly download-free and installation-free, allowing users to use them instantly.

[0063] Figure 1 This is a schematic diagram of the architecture of a public cloud system. Figure 1 As shown, the system includes a terminal device 110, a public cloud data center 130, and an application service node 140, and the terminal device 110, the public cloud data center 130, and the application service node 140 are connected via a network 120. The network 120 can be a public network, such as the Internet.

[0064] The terminal device 110 can be a smart phone, a handheld processing device, a tablet computer, a mobile notebook, a virtual reality device, a wearable device, an integrated handheld device, or any other electronic device with streaming media playback capability. Figure 1 The terminal device 110 is taken as an example of a smart phone, but this application does not make any specific limitation to this.

[0065] The application service node 140 is used to provide various application services to users. The application service node 140 may include a game service node, an education application service node, a video application service node, a social application service node, a virtual reality application service node, etc., which is not specifically limited in this application.

[0066] The public cloud data center 130 can provide users with shared resource services, which may include OBS services, SFS services, cloud phone services, content delivery network services (CDN), cloud backup and recovery services (CBR), data management services (DAS), etc. This application does not limit the types of shared resource services that the public cloud data center 130 can provide. In specific implementations, individual users can rent the cloud infrastructure and services owned by the public cloud data center 130 through the network 120, and use the application services provided by the application service node 130 through the rented shared resources. For example, renting a public cloud virtual machine to experience high-quality stand-alone games, renting a public cloud phone to experience high-definition mobile games, etc. Enterprise users can purchase cloud services for their own use based on their needs, such as renting virtual machines from a public cloud as their servers. They can also make these services available to other users. For example, a game manufacturer can purchase multiple cloud phones or virtual machines to operate a cloud gaming platform. When launching a game, the manufacturer's game users can remotely connect to the cloud phones or virtual machines purchased by the game manufacturer through their own terminal devices. This allows game users to use applications with relatively limited image processing and data computing capabilities, or even terminal devices with only streaming media playback capabilities, to use applications that require high hardware resources. It should be understood that the above examples are for illustrative purposes only and do not constitute specific limitations.

[0067] For example, the data center 130 of the public cloud may include a cloud platform 131 and a hardware resource pool 132. It should be understood that Figure 1 The division method shown is for illustration only. The public cloud data center 130 may also be divided using other methods. This application does not limit the division method of the public cloud data center 130.

[0068] Among them, the cloud platform 131 can be implemented by a general physical server, such as an ARM server or an X86 server, or a virtual machine (VM) implemented in combination with network functions virtualization (NFV) technology. The cloud platform 131 can also be a virtual machine or physical server in the hardware resource pool 132, which is not specifically limited in this application.

[0069] The hardware resource pool 132 may include at least one physical server ( Figure 1The resource pool includes Server 1, Server 2, Server 3, and Server 4. The physical servers can be general-purpose physical servers, such as ARM servers or X86 servers, and this application does not impose specific limitations. The physical servers in hardware resource pool 132 and the cloud platform are connected via an internal network. Each physical server can communicate with other physical servers and cloud platform 131 via the internal network.

[0070] Each physical server can run at least one cloud phone, and the public cloud data center 130 can provide users with cloud phone rental services, such as charging according to the hardware specifications of the cloud phone required by the user. The user can install and use the required applications in the rented cloud phone. Alternatively, the public cloud data center 130 can also pre-install various applications in the cloud phone and provide users with rental services for the applications in the cloud phone, such as charging according to the usage time of the application. For example, Figure 1 As shown, assuming that a user needs to use application 111, the user can send a purchase request to the cloud platform 131 to rent a cloud phone. The cloud platform 131 can allocate a cloud phone 11 installed with application 111 to the user based on the resource usage in the hardware resource pool. It should be understood that whether renting a cloud phone or renting an application, the terminal device 110 can remotely control the application on the cloud phone after paying. The cloud phone can respond to the user's remote operation and send the resulting audio and video streams to the terminal device 110 for display and playback. This allows the user to use a terminal device 110 with relatively limited image processing and data computing capabilities, or even a terminal device 110 with only streaming media playback capabilities, to use applications that require high hardware resources.

[0071] In specific implementation, such as Figure 1 As shown, cloud phones can be Figure 1 Any one of the virtual machines (such as virtual machine 21), containers (such as container 11 and container 22), and bare metal servers (BMS) (such as server 3). If the cloud phone is implemented via a container, the cloud platform 131 can notify the cloud platform management agent node of the server to create a container based on the operating environment required by the application, and install application 111 on the cloud phone. If the cloud phone is implemented via a virtual machine, the cloud platform 131 can create a virtual machine through the virtual machine manager based on the operating environment required by the application, and install application 111 on the cloud phone. If the cloud phone is a BMS, the cloud platform 131 can select a suitable BMS based on the operating environment required by the application and install application 111 on it, thereby obtaining a cloud phone with application 111 installed. In this application, the cloud phone is a virtual resource on the public cloud data center 130, which runs a mobile phone operating system. This application does not limit the specific form of the cloud phone.

[0072] It should be understood that after the terminal device 110 stops remotely controlling the application 111 on the cloud phone, the cloud platform 131 can release the cloud phone (i.e., container 11), and the released resources can be used by other users. When the terminal device 110 requests remote control of the application 111 on the cloud phone again, the cloud platform 131 can once again create a cloud phone with the application 111 installed for the user to use.

[0073] In summary, under the public cloud architecture, the user's application will be installed in the cloud phone. The cloud phone can transmit the audio and video images rendered during the application operation to the terminal device in the form of audio and video streams. The terminal device only needs to display the received audio and video streams to the user, truly achieving the goal of no download or installation required for the application.

[0074] However, for corporate users who rent cloud phones to operate their businesses, after purchasing a large number of cloud phones, they need to deploy applications on the cloud phones in advance. For example, game manufacturers who rent cloud phones for game users need to install multiple games of the game manufacturer on each cloud phone in advance. If the game manufacturer operates 100 games and purchases 1,000 cloud phones, then each cloud phone needs to install 100 game apps. If the installation size of each game app is 1GB (it is likely to exceed 1GB in reality), then one cloud phone will require 100GB of storage space, and 1,000 cloud phones will require 100T of storage space. The update of any game app will also take up a lot of system resources, making the operation and maintenance costs of the game manufacturer too high. In addition, cloud phones with 100 apps installed are more likely to be stuck during startup and app operation, reducing the user experience.

[0075] In order to solve the problem that the above-mentioned cloud phones need to install applications in advance, which leads to high operating and maintenance costs for application manufacturers who purchase cloud phones, and cloud phones with a large number of applications installed are prone to lag when starting up and running applications, this application provides a cloud phone application installation system based on a cloud platform, such as Figure 2 As shown, the system can be deployed in Figure 1 In the embodiment, the public cloud data center 130 may include a cloud platform 131 and a hardware resource pool 132. The hardware resource pool 132 may include a template cloud phone 1324, at least one cloud phone to be configured 1321, and a network storage device 1325. Figure 2 Taking two cloud phones to be configured as an example, this application does not limit the number of cloud phones to be configured.

[0076] The template cloud phone 1324 and the cloud phone to be configured 1321 can be Figure 1For any of the containers, virtual machines and BMS in the embodiments, please refer to the description of the cloud phone in the above content, which will not be repeated here.

[0077] The network storage device 1325 is used to provide storage services, which can be Figure 1 Any one of the virtual machines and bare metal servers in the embodiment. Optionally, the network storage device 1325 may include an object storage device 1323 and a network shared file 1322. In a specific implementation, the object storage device 1323 may be a cloud storage service in a public cloud, such as an OBS service, which is created and obtained by the cloud platform 131 and can store any amount and form of unstructured data. The network shared file 1323 may be a network-based file system service in a public cloud, such as an SFS service, which is created and obtained by the cloud platform 131. Among them, the SFS service can provide shared access for multiple servers (specifically, one or more of the above-mentioned virtual machines, containers, and BMS). In a specific implementation, the file system created by the SFS service can be any network file system that supports the NFS protocol, or a network file system such as CIFS / SMB. This application does not limit the file system type of the network shared file 1323.

[0078] In an embodiment of the present application, the template cloud phone 1324 can install multiple applications required by the user, and after generating the installation information of multiple applications, the directory of the template cloud phone (including the installation information of the above-mentioned multiple applications) is stored in the object storage device. The cloud platform 131 can also store the directory of the template cloud phone in the object storage device 1323 according to the user's second input. The object storage device 1323 synchronizes the stored directory of the target cloud phone to the network shared file 1323. The network shared file 1323 can provide a mount directory to at least one cloud phone to be configured. When the App user uses the cloud phone to be configured, the cloud phone to be configured can access the installation information in the network shared file 1323 through the mount directory to start and run the application, thereby reducing the memory usage of the cloud phone, improving the user experience, and reducing the operating and maintenance costs of the application manufacturer.

[0079] In a specific implementation, the object storage 1323 can globally store and manage the installation information of multiple applications exported by the template cloud phone 1324, such as the classification management of the installation information of each application, version management, and the mapping management of each application and the network shared file 1322. Figure 2Take the example of a user installing 4 applications on a template cloud phone, a network shared file synchronizing the installation information of 2 applications, and a network shared file providing a mount directory for a cloud phone to be configured. In the specific implementation, the number of applications synchronized by each network shared file can be determined based on the storage capacity of the network shared file. This application does not limit the number of applications installed on the template cloud phone, the number of applications synchronized by the network shared file 1322, and the number of cloud phones to be configured that are mounted by the network shared file 1322.

[0080] It should be noted that due to the limited storage capacity of the file system, one object storage 1322 can connect to multiple network shared files 1323. For example, a game manufacturer owns 100 games, and the installation information of all 100 games is stored in object storage 1322. However, one network shared file can only store the installation directories and external storage directories of 50 games. In this case, the object storage can connect to two network shared files: network shared file A is responsible for mounting the directories of the first 50 games, and network shared file B is responsible for mounting the directories of the second 50 games. It should be understood that the above example is for illustrative purposes only, and this application does not limit the number of object storages 1322 and network shared files 1323.

[0081] Understandably, Figure 2 The network storage device shown can be divided into many types. Figure 1 It is only an exemplary division method, and each module can be a software module, a hardware module, or partly a software module and partly a hardware module, and this application does not limit it. For example, in some application scenarios, a network storage device may only include a network shared file 1322. It should be understood that if the types of applications that enterprise users need to install are relatively small, there is no need to globally manage the installation information of multiple applications. For example, a game manufacturer only needs to install one game to a cloud phone. Then the template cloud phone can export the installation information generated after the game is installed to the network shared file 1323, and the network shared file 1323 provides a mount point to the cloud phone to be configured for directory mounting. It should be understood that the above examples are for illustration only and this application does not limit this.

[0082] Similarly, when an App is updated, the updated application data can first be exported to the object storage 1323 and then synchronized to the network shared file 1322. The cloud phone can re-mount the updated installation information to achieve the application update. Therefore, using the application installation system provided by this application, if a game manufacturer operates 1,000 games and purchases 1,000 cloud phones, when a game A among the 1,000 games needs to be updated, the updated installation information can be exported to the object storage, and the object storage synchronizes the updated installation information to the network shared file. When the game user uses the cloud phone to start game A, the cloud phone can mount the above-mentioned updated installation information from the network shared file, so that the update of the App does not need to occupy a large amount of storage space and system resources of the cloud phone, which not only reduces the operating costs of enterprise users, but also reduces the lag that is easy to occur during the startup of the cloud phone and the startup and operation of the App, thereby improving the user experience.

[0083] In summary, the cloud phone-based application installation system provided by this application does not require the installation of applications in each cloud phone, but instead synchronizes the application installation information to a network shared file. Each time a user uses a cloud phone to use various applications, the cloud phone can mount the installation information of various applications from the network shared file, thereby enabling the startup, operation and update of applications without installing the applications in advance, thereby reducing the memory usage of the App in the cloud phone, greatly reducing the operating and maintenance costs of the application manufacturer, and at the same time improving the startup, operation and update speed of the App, thereby improving the user experience.

[0084] Below with reference to accompanying drawing, Figure 2 The specific steps of how to install applications in the cloud phone-based application installation system are introduced in detail.

[0085] like Figure 3 As shown, this application provides an application installation method based on cloud phone, which is applied to Figure 2 The application installation system shown in the figure can be described in the following way: Figure 1~Figure 2 The method comprises the following steps:

[0086] S310: The template cloud phone 1324 installs the App and generates installation information for the application.

[0087] In one embodiment, when an app is installed on template cloud phone 1324, the operating system of template cloud phone 1324 installs the data in the app installation package to a path set by template cloud phone 1324. The generated installation information typically includes a first installation directory and a second installation directory. The second installation directory includes dynamic data for multiple applications, while the first installation directory includes static data for multiple applications. Simply put, static data refers to data that does not change during the operation of the app on the cloud phone, while dynamic data refers to data that will change during the operation of the app. Taking the Android operating system as an example, the first installation directory can be the application installation directory, and the second installation directory is an external storage directory. The application installation directory stores application installation information such as the app's apk file, lib library, and oat file, and the path is / data / App / {App_package}. The data in this directory does not change during the operation of the app. The external storage directory stores application runtime files, such as equipment information and game versions involved in game applications, and the path is / data / media / 0 / Android / data / {App_package}. The data in this directory will change during the operation of the app. It should be understood that the specific files and paths stored in the above-mentioned first installation directory and second installation directory are used for illustration purposes only. The first installation directory and the second installation directory have different paths and store different installation information in different operating systems (such as the IOS operating system, the Hongmeng operating system, etc.). This application does not provide examples one by one.

[0088] S320: The template cloud phone 1324 exports the installation information to the object storage 1322. The object storage 1322 is an object storage 1322 corresponding to the enterprise user created by the cloud platform after the enterprise user purchases the cloud phone. The object storage 1322 can store and manage the installation information of the applications installed by the enterprise user on the template cloud phone.

[0089] Specifically, the template cloud phone can compress and package the installation information, such as compressing it into a file in tar.gz format, and then upload it to the object storage 1322. The object storage 1322 can decompress the received installation information and store it in a storage medium, such as the user's OBS data bucket. It should be understood that in the public cloud, each user will have a corresponding OBS data bucket, so storing the installation information in the user's OBS data bucket is very convenient and fast. The object storage 1322 does not need to re-apply for storage resources from the cloud platform, which can improve processing efficiency. Of course, the object storage 1322 can also store the installation information in other storage media, such as the OBS data bucket corresponding to the object storage 1322. This application does not limit this. Optionally, the object storage 1322 can also record the storage path, version information, corresponding user information, application name, type, etc. of the installation information. This application does not make specific limitations on the specific types of storage management of application files by the object storage 1322.

[0090] S330: The object storage 1322 synchronizes the installation information to the network shared file 1323.

[0091] In a specific implementation, when the object storage 1322 does not yet have a corresponding network shared file 1323 (i.e., when the user installs the application on the template cloud phone for the first time), or when the current object storage has insufficient remaining storage space, the object storage may first send a request to create the network shared file 1323 to the cloud platform 131. After the cloud platform 131 creates a network shared file 1323, the object storage sends the installation information to the network shared file 1323 and records the correspondence between the installation information and the network shared file 1323. In this way, when the object storage 1322 receives the updated version of the installation information, it can determine the network shared file 1323 corresponding to the installation information based on the correspondence, and then send the updated version of the above installation information to the corresponding network shared file 1323 to update the application installation information. It is worth noting that the directory structure of the installation information in the network shared file instance is consistent with the directory structure of the object storage 1322, and is also consistent with the directory structure of the installation information generated after the template cloud phone 1324 installs the App.

[0092] S340: To-be-configured cloud phone 1321 accesses the installation information by mounting the network shared file, enabling the startup, operation, and update of the application. The network shared file can provide a mount directory (mount point), such as / data / share_app_center, to to-be-configured cloud phone 1321. This mount directory allows the to-be-configured cloud phone to access the installation information in network shared file 1323, enabling the startup and operation of the application. This reduces the cloud phone's memory usage, improves the user experience, and reduces the operating and maintenance costs of the application manufacturer.

[0093] This application provides two methods for starting, running and updating the App by mounting the installation information in the network shared file 1323 on the cloud phone to be configured. The following are detailed explanations of these two methods.

[0094] 1. Mount files by deploying the first multi-layer file system in the cloud phone to be configured

[0095] In one embodiment, referring to the above content, it can be seen that the installation information generated after the App is installed on the mobile phone includes a first installation directory and a second installation directory. During the operation of the App, the first installation directory will not be modified, and the modified data generated during the operation will be written to the second installation directory. Therefore, the cloud phone 1321 to be configured can mount the first installation directory from the network shared file in a read-only manner, and then write the modified data to the second installation directory through the first multi-layer file system, thereby realizing the startup and operation of the App in the cloud phone 1321 to be configured.

[0096] Specifically, the first multi-layer file system may include at least an upper directory and a lower directory, wherein the lower directory is the second installation directory in the network shared file 1233, and the upper directory is used to store modified data. After the first multi-layer file system synthesizes the upload directory and the lower directory, during the running of the App, the operating system can access the first multi-layer file system to read and write the second installation directory, thereby enabling the running of the App in the cloud phone to be configured 1321. It should be understood that the above-mentioned modified data can be the login date recorded when the game is started, the game data generated during the running process, etc. The directory structure of the upper directory is a preset directory structure. The applicable preset directory structure can be determined according to the application scenario to store the modified data. This is not limited in this application.

[0097] For example, if Figure 4A As shown, assuming that the operating system of the cloud phone to be configured is the Android operating system, the installation information of an App has been synchronized from the object storage to the network shared file 1322. In the installation information of the App, the first installation directory is the application installation directory 1, and the second installation directory is the external storage directory 1. When the cloud phone to be configured 1321 runs the App, the operating system will access the application installation directory 1' or the external storage directory 1', wherein the application installation directory 1' mounts the application installation directory 1 in the network shared file 1322 in read-only mode, and the external storage directory 1' is a composite directory of the upper directory and the lower directory, wherein the lower directory can be realized by mounting the external storage directory 1, and the upper directory is a preset directory structure, and the stored data is the modified data generated during the operation of the App, thereby realizing the operation of the App in the cloud phone to be configured 1321.

[0098] Similarly, if Figure 4BAs shown, when there are multiple cloud phones to be configured ( Figure 4B Taking the installation of the same application on two cloud phones to be configured as an example), cloud phone 1 to be configured and cloud phone 2 to be configured can respectively mount the installation information in the network shared file 1322 to install the application. Specifically, cloud phone 1 to be configured and cloud phone 2 to be configured are both deployed with their own first multi-layer file systems, and are respectively connected to the application installation directory 1 in the network shared file in read-only mode, and then respectively read and write to the external storage directory 1 through their own first multi-layer file systems to complete the installation of the application, wherein the upper directory of the first multi-layer file system is used to store the modified data generated during the operation of each application, and the lower directory is connected to the application installation directory 1 in the network shared file in read-only mode. It should be understood that Figure 4B For content not described in Figure 4A The embodiments will not be repeated here, and the above examples are for illustration only. This application does not limit the number of cloud phones to be configured and the number of applications.

[0099] In a specific implementation, the above-mentioned first multi-layer file system can be implemented through an Overlay file system. The read-only mode can be to map the first installation directory in the network shared file to the cloud phone to be configured through a soft connection, so that when the cloud phone to be configured requests access to the first installation directory, it will jump to the first installation directory stored in the network shared file through the network, thereby realizing the installation information under the application installation directory mounted from the network shared file in a read-only manner.

[0100] It can be understood that the method of combining the first multi-layer file system and the read-only mode to mount the network shared file can not only ensure the reading and writing of data during the operation of the App, and realize the startup and operation of the App on the cloud phone to be configured, but also realize the update of the App by remounting the new version installation information. Specifically, after the new version installation information of Application A is installed on the template cloud phone and exported to the object storage device, the object storage device can synchronize the new version installation information to the corresponding network shared file 1322 according to the previously recorded correspondence. The network shared file 1322 can provide a new mount directory to the cloud phone to be configured 1321 (of course, the mount directory can also be kept unchanged, and only the installation information under the mount directory is updated). The cloud phone to be configured 1321 can remount the new version installation information in the network shared file 1322 according to the above new mount directory to realize the update of the App.

[0101] In a specific implementation, when the cloud phone 1321 to be configured remounts the new version installation information, it can remount the first installation directory in read-only mode to implement read operations on the first installation directory, access the updated first multi-layer file system to implement read and write operations on the second installation directory, thereby enabling the startup and operation of the updated App. Among them, the updated first multi-layer file system re-synthesizes the updated upper directory and the updated lower directory, the updated lower directory mounts the updated second installation directory in the network shared file 1322, and the updated upper directory uses a new preset directory (or still uses the previous preset directory but clears the modified data under the directory). The modified data generated when the updated App is running and started can be written to the updated upper directory, thereby enabling the startup and operation of the updated App.

[0102] Similarly, the method of mounting files by combining the first multi-layer file system and the read-only mode can not only realize the startup, operation and update of the App on the cloud phone to be configured, but also realize the rapid uninstallation of the App. Specifically, after the enterprise user initiates a request to uninstall the App, the object storage and network shared files can delete the installation information corresponding to the App, thereby realizing the uninstallation of the App. Using this method to uninstall the App, there is no need to perform the application uninstallation steps for each cloud phone, which reduces the resource scheduling pressure on enterprise users when managing cloud phones and improves the efficiency of App uninstallation on cloud phones.

[0103] It can be understood that by mounting the installation information in the network shared file as mentioned above, the App can be started, run and updated. Each cloud phone does not need to install the application in advance, which not only reduces the memory usage of the cloud phone and improves the efficiency of App startup and operation, but also reduces the resource scheduling pressure required for enterprise users to install, update and uninstall applications when managing cloud phones, thereby reducing operating costs.

[0104] 2. Mounting the installation information by deploying a second layer of file system in a network shared file

[0105] In one embodiment, the modified data generated by the cloud phone to be configured during the running of the App can be sent to a network shared file, and the network shared file performs read and write operations on the first installation directory and the second installation directory, concentrating the pressure of the read and write operations on the network shared file, reducing the processing pressure of the cloud phone to be configured during the running of the App, improving the efficiency of the running of the cloud phone to be configured App, and thus improving the user experience. Specifically, the above-mentioned second multi-layer file system can be deployed in a network shared file, and the second multi-layer file system can mount the installation information. The cloud phone to be configured can send the modified data generated during the running of the App to the network shared file, and the network shared file can perform read and write operations on the installation information through the second multi-layer file system. In a specific implementation, the above-mentioned second multi-layer file system can be implemented through the Overlay file system,

[0106] Still taking the above example, Figure 5A As shown, assuming that the operating system of the cloud phone to be configured is the Android operating system, the installation information of a certain App has been synchronized from the object storage to the network shared file 1322. In the installation information of the App, the first installation directory is the application installation directory 1, and the second installation directory is the external storage directory 1. Before the cloud phone to be configured starts the App, the network shared file 1322 can first create a blank directory 1 with the above-mentioned second multi-layer file system built in, and mount it to the cloud phone to be configured as the root directory of its data disk. Then, the network shared file 1322 creates a copy directory based on the installation information downloaded from the object storage. The directory structure and data in the copy directory are the same as the directory structure and data in the installation information, and the blank directory 1 is mounted in the copy directory. In this way, when the cloud phone to be configured runs the App, the cloud phone to be configured can read data from the blank directory 1 with the copy directory mounted, and write the generated modified data into the blank directory 1 through the second multi-layer file system of the blank directory 1. Similarly, when the App needs to be updated, the copy directory can be updated according to the updated installation information, and then the blank directory can be re-mounted on the updated copy directory. When the App needs to be uninstalled, the installation information and the copy directory can also be directly deleted. It should be understood that the data in the blank directory is empty when it is created. After being mounted on the copy directory, the data in the blank directory is no longer empty. Based on this, by deploying a second multi-layer file system in the network shared file to realize the mounting of installation information, each cloud phone can realize the startup, operation, update and uninstallation of the App without installing the application in advance. This not only reduces the memory usage of the cloud phone, and improves the efficiency of App startup and operation, but also reduces the resource scheduling pressure required for enterprise users to install, update and uninstall applications when managing cloud phones, thereby reducing operating costs.

[0107] Similarly, if Figure 5BAs shown, when there are multiple cloud phones to be configured ( Figure 5B Taking the installation of the same application on two cloud phones to be configured as an example), cloud phone 1 to be configured and cloud phone 2 to be configured can respectively mount the network shared file 1322 to install the application. Specifically, the network shared file 1322 has multiple second multi-layer file systems (i.e. Figure 5B The blank directory 1 and the blank directory 2 in the directory correspond to different cloud phones to be configured, that is, the cloud phone 1 to be configured is mounted in the blank directory 1, and the cloud phone 2 to be configured is mounted in the blank directory 2, thereby realizing the installation of the cloud phone 1 to be configured and the cloud phone 2 to be configured. It should be understood that Figure 5B For details on the contents not described, please refer to Figure 5A The embodiments will not be repeated here, and the above examples are for illustration only. This application does not limit the number of cloud phones to be configured and the number of applications.

[0108] In a specific implementation, a network shared file can be deployed with a server, and a cloud phone to be configured can be deployed with a client, wherein the client is used to send the read and write IO requests generated by the cloud phone to be configured (such as a request to write the modified data generated during the App running process to an external storage directory, a request to read the application installation directory, etc.) to the server of the network shared file, and the server is used to receive the above-mentioned read and write IO requests sent by the client, and send it to the second multi-layer file system, which implements the read and write operations of the installation information, and further realizes the remote mounting and installation information of the cloud phone to be configured, so that each cloud phone can realize the startup, operation, update and uninstallation of the App without installing the application in advance. This not only reduces the memory usage of the cloud phone, and improves the efficiency of App startup and operation, but also reduces the resource scheduling pressure required for enterprise users to install, update and uninstall applications when managing cloud phones, thereby reducing operating costs.

[0109] It should be understood that since a network shared file can be connected to multiple cloud phones to be configured, each cloud phone to be configured will send multiple read and write IO requests to the network shared file, which puts a lot of pressure on the network shared file. Therefore, the IO requests in the cloud phone to be configured can be sent to the client, and the client aggregates the received IO requests and sends them to the server for processing, thereby reducing the number of IO requests received by the network shared file, reducing the processing pressure of the network shared file, and improving the efficiency of App startup, operation, update and uninstallation. In a specific implementation, the network shared file can cache the received IO requests in the memory first. After receiving the IO request sent by the cloud phone to be configured, it first updates the data in the cache and then generates an asynchronous IO request. The IO requests of a large number of small files are then aggregated into a single IO request, and the aggregated IO data is sent to the server at one time. The server can parse the received IO requests and then update them in batches to the storage medium.

[0110] In one embodiment, user data is also generated during the operation of the App. Using the above method to manage the App can ensure that the user data can be retained after the application is updated, thereby improving the user experience. The user data can be personal business data and personal habit data generated locally during the operation of the App. For example, when the App is a game App, the user data of a mobile game App may include the user's default account information, historical login area information, etc., and the user data of a stand-alone game App may include game clearance records, game character data, etc.; when the App is an office App, the user data of a mailbox App may include the user's mailbox account binding information, mailbox business card settings, etc., and the user data of an office communication App may include the user's historical chat records, user's historical account information, user's historical file information, business data, etc. It should be understood that user data may also include private data generated by personal users of other types of Apps during operation, which are not given examples here.

[0111] It should be understood that since the data generated during the operation of the App are all stored in the network shared files, when the App is updated, after the updated copy directory is generated according to the updated installation information, the above user data can still be retained in the blank directory of the network shared file, so that after the App is updated, the user data can still be retained, and the user does not need to re-set account information, re-download business data, etc., thereby improving the user experience.

[0112] In one embodiment, due to physical latency, the cloud phone used by the user is a cloud phone on the public cloud in the user's geographic region. For example, if the user is currently in North China, the cloud phone and network shared files used by the user belong to the North China Data Center. If the user is currently in South China, the cloud phone and network shared files used by the user belong to the South China Data Center. Normally, data between data centers cannot be interoperable, or it costs a lot to achieve data interoperability. In this application scenario, the above method is used for App management. When the user's geographic location changes, user data can be quickly synchronized from historical network shared files to current network shared files, thereby avoiding user data loss due to changes in the user's geographic location, reducing maintenance costs, and improving the user experience.

[0113] For example, if Figure 6 As shown, assuming that user A is working in Beijing (North China), user A uses the cloud phone 1 and network shared file 1 of the North China Data Center to run an office app. Later, user A travels to Shenzhen to work (South China). At this time, the object storage device can send a request to the South China Data Center to create a network shared file 1', and then synchronize the installation information of the office app to the network shared file 1'. The network shared file 1 quickly synchronizes the user data generated by user A when working in Beijing to the network shared file 1', so that the cloud phone 1' mounted with the network shared file 1' can retain the user data while running the app. The user does not need to re-enter the account password, re-download business data, etc., thereby improving the user experience.

[0114] In one embodiment, due to various reasons, the cloud phone that the user is currently using often undergoes resource migration. Using the above method to manage apps can reduce the time required for cloud phone resource migration, while ensuring that user data will not be lost after the cloud phone resources are used, thereby improving the user experience. Among them, cloud phone resource migration refers to the migration of the cloud phone that the user is currently using from one server to another server. There are many reasons for resource migration. For example, the resource occupancy rate of the server where the cloud phone that the user is currently using is high. In order to avoid the cloud phone from freezing, the cloud phone that the user is currently using can be migrated to another server with a lower resource occupancy rate; or, during the process of using the cloud phone, the user's usage requirements have changed. For example, the user has only installed office apps before, and the configuration of the cloud phone is relatively low. If the user installs a game app with high configuration requirements, the cloud phone used by the user can also be migrated from one server to another server. It should be understood that the above reasons for resource migration are used for illustration purposes only and are not limited in this application. In this application scenario of cloud phone resource migration, the above method is used for App management. When resource migration occurs on the cloud phone used by the user, the cloud phone before migration can be stopped first, and the migrated cloud phone can be remounted to the network shared file, thereby quickly realizing the resource migration of the cloud phone. Since the entire migration process is based on mounting network shared files, there is no need to perform redundant steps such as application installation or data synchronization on the migrated cloud phone, which shortens the resource migration of the cloud phone to a few seconds, improving the user experience. At the same time, since the network shared files mounted on the migrated cloud phone are the same as those of the cloud phone before migration, the user data after the cloud phone resource migration can still be retained. The user does not need to re-enter the account password, re-download business data, etc., further improving the user experience.

[0115] For example, if Figure 7 As shown, assuming that the cloud phone 2 used by the user is migrated from server 1 to server 2, you can first stop running cloud phone 2, then cancel the mount between cloud phone 2 and the network shared file, and then create a cloud phone 2' on server 2, and provide the mount directory on the network shared file to cloud phone 2'. Cloud phone 2' mounts the network shared file through the mount directory, thereby quickly realizing the resource migration of the cloud phone and improving the user experience.

[0116] It should be understood that this application provides two methods for the cloud phone to be configured to realize application startup, operation, update and uninstallation by mounting network shared files, namely, mounting files by deploying a second multi-layer file system in the cloud phone to be configured, and mounting installation information by deploying a second multi-layer file system in a network shared file. The above two methods are used for illustration. In specific implementation, file mounting can also be achieved through other methods, which are not specifically limited in this application.

[0117] It should be noted that the application installation method provided by this application can be that after the user purchases the cloud phone service and installs the application in the template cloud phone, the cloud platform automatically executes steps S310 to S340 to implement the application installation of at least one cloud phone to be configured for the user. The cloud platform can also implement the solution provided by this application according to the configuration requirements input by the user. In the specific implementation, the user can manually set the object storage device, shared network files, and the cloud phone to be configured, etc. through the console or API, such as Figure 8 As shown, the following explains how the cloud platform implements the installation of applications to be configured on the cloud phone based on user input in the method provided by this application.

[0118] S410: The cloud platform 131 provides a cloud phone configuration interface to the user, where the cloud phone configuration interface is used to configure a template cloud phone according to the user's first input. The template cloud phone is provided with multiple applications, and the directory of the template cloud phone records installation information of the multiple applications.

[0119] Among them, the user's first input may include the App installation package, update package, performance configuration information of the template cloud phone, etc. that the user needs to install. The cloud phone configuration interface can be the console (console) or application program interface (API) of the cloud platform 131. The console can specifically be an application or web page for users to purchase cloud services and configure cloud services. For example, users can purchase a template cloud phone through the cloud platform's website and upload the application to be installed in the template cloud phone to complete the application update. It should be understood that the above examples are for illustration only and this application does not make specific limitations.

[0120] S420: The cloud platform 131 provides the user with a network shared file configuration interface, which is used to store the directory of the template cloud phone to the network shared file according to the user's second input.

[0121] In a specific implementation, before providing a network shared file configuration interface, the method further includes: providing an object storage interface, the object storage interface is used to obtain the directory of the template cloud phone according to the user's fourth input and store the directory of the template cloud phone in the object storage device, and the network shared file configuration interface is used to synchronize the directory storage of the template cloud phone stored in the object storage device to the network shared file according to the user's second input. Here, the user's fourth input can be an instruction to synchronize the network shared file with the object storage device. The cloud platform can receive the user's fourth input, obtain the directory of the template cloud phone and store the directory of the target cloud phone in the object storage device. The user's second input can be to associate the object storage device with the network shared file, such as Figure 2In this embodiment, the object storage device is associated with network shared file 1 and network shared file 2, where each network shared file stores installation information for two applications. It should be understood that the above examples are for illustrative purposes only and are not specifically limited in this application. Furthermore, the network shared file configuration interface and object storage interface can be the console or API described above, which is also not specifically limited in this application.

[0122] Optionally, before providing the object storage interface, the method further includes providing an object storage creation interface, the object storage creation interface being used to create an object storage device based on a seventh input from the user. The seventh input may be an instruction to create an object storage device and configuration information for the object storage device, such as the storage capacity of the object storage device, a storage directory of the object storage device, and the like.

[0123] For example, the cloud platform 131 provides the user with an object storage creation interface. Assuming that the interface is an API interface, the user can use the API instructions to create an object storage device. For example, the OBS data bucket in the cloud service is used as the object storage device to store the directory of the template cloud phone. Exemplarily, the API instruction for creating the object storage device (the user's fifth input) can be as follows:

[0124] POST / share-stores /

[0125] {“bucket_id”:”…”}

[0126] This creates the object storage device to be used, and then you can package and compress the template cloud phone directory (for example, compress it into tar.gz) and upload it to the above OBS data bucket.

[0127] Similarly, if the interface is a web page or application console, for example, Figure 9 As shown, the console can show the user some configuration options for creating an object storage device, such as selecting the data center where the object storage device is located as the North China Data Center, selecting the name of the created object storage device as Object Storage Device 1, selecting the storage category of the object storage device as Standard Storage, etc. Users can drag and drop local files to the "Upload Object" column to store them, or click the icon to add files and import the directory of the template cloud phone into the object storage device. Finally, click the Upload button to complete the creation of Object Storage Device 1 and the storage of the directory of the template cloud phone. Figure 9 The configuration content shown may be the fifth and seventh inputs of the user. It should be understood that Figure 9 The console interface shown is for illustration only and is not limited in this application.

[0128] Optionally, before providing the network shared file configuration interface, the method provided in this application further includes providing a network shared file creation interface, wherein the network shared file creation interface is used to create a network shared file based on a sixth input from the user. The sixth input may be an instruction to create a network shared file and configuration information for the network shared file, such as the storage capacity of the network shared file, the type of the file system, etc., which is not specifically limited in this application.

[0129] For example, the cloud platform 131 provides users with a network shared file creation interface. Assuming that the interface is an API interface, the user can use API instructions to create a network shared file, such as an instance of the SFS service in the cloud service, and then synchronize the directory of the template cloud phone in the above-mentioned OBS data bucket to the SFS instance. Exemplarily, the API instruction for creating a network shared file (the user's sixth input) can be as follows:

[0130] POST / share-stores / {share_store_id} / instances

[0131] { “available_zone”: “…”, “name”: “…”}

[0132] It should be understood that the SFS instance created using the above API can automatically synchronize the directory of the template cloud phone stored in the object storage device. The above API instructions are used for illustration and are not specifically limited in this application.

[0133] Similarly, if the interface is a web page or application console, for example, Figure 10 As shown, the console can show the user some configuration options for creating a network shared file, such as configuring the data center where the network shared file is located to be the North China data center, setting the name of the network shared file to be network shared file 1, configuring the protocol type to be NFS protocol, setting the capacity of network shared file 1 to 500GB, and synchronizing network shared file 1. Figure 9 The data in the object storage device 1 shown is the directory of the template cloud phone. Finally, click the Create button to complete the creation of the network shared file and the data synchronization of the object storage device. Figure 10 The configuration content shown may be the sixth input, the second input, and the fourth input of the user. It should be understood that Figure 10 The console interface shown is for illustration only and is not limited in this application.

[0134] In one embodiment, the cloud phone configuration interface is further used to configure at least one cloud phone to be configured to mount a network shared file based on a third user input to complete the installation of multiple applications. For example, assuming that the cloud phone configuration interface is an API interface, the user can use API instructions to configure the cloud phone to be configured and mount the cloud phone to the SFS instance created in the above example. For example, the above API instructions (the user's third input) can be as follows:

[0135] POST / share-stores / {share_store_id} / instances / {id} / action

[0136] { “mount”: { “target” : ” / data / share_app_center”}}

[0137] From a system perspective, users can also enter API commands to view mount information, which will be displayed similarly to the following:

[0138] # mount

[0139] {nfs export address}: / on / data / share_app_center type nfs (ro,vers=3,...)

[0140] It should be understood that the above API instructions are used for illustration purposes only and are not specifically limited in this application.

[0141] refer to Figure 2-Figure 7 As can be seen from the embodiments, this application provides two mounting methods to enable at least one cloud phone to be configured to mount network shared files to complete the installation of multiple applications. The two mounting methods are explained below.

[0142] In one embodiment, a first multi-layer file system can be deployed in the cloud phone to be configured, static data can be connected in a read-only manner, and dynamic data can be read and written using the multi-layer file system, thereby achieving the mounting of the template cloud phone directory and completing the installation, operation and startup of the application.

[0143] In a specific implementation, the cloud phone configuration interface is also used to configure at least one cloud phone to be configured to connect to the first installation directory in the first network shared file in a read-only manner according to the user's third input; the cloud phone configuration interface is also used to configure the first multi-layer file system in at least one cloud phone to be configured according to the user's third input, and the first multi-layer file system is used for at least one cloud phone to be configured to perform read and write operations on the second installation directory, wherein the first multi-layer file system includes an upper directory and a lower directory, the lower directory is used to connect to the second installation directory in a read-only mapping manner, the upper directory is used to store modified data generated during the operation of an application installed in at least one cloud phone to be configured, and the first multi-layer file system is used to superimpose the upper directory and the lower directory. Among them, the specific description of deploying the first multi-layer file system in the cloud phone to be configured to achieve mounting can be referred to the aforementioned Figure 4A-4B The embodiments are not repeated here.

[0144] It should be understood that in the method of deploying the first multi-layer file system in the cloud phone to realize application mounting, the above-mentioned third input may include an instruction to connect the cloud phone to be configured to the first installation directory in the first network shared file in a read-only manner, and may also include an instruction to set the first multi-layer file system in the cloud phone to be configured, and may also include an instruction to store modified data in the upper directory of the first multi-layer file system and soft-connect the lower directory with the first installation directory. For example, assuming that the cloud phone configuration interface is an API interface, the user can use the API instructions to configure the cloud phone to be configured and mount the cloud phone to be configured in the SFS instance created in the above example. For example, the API instruction to connect the cloud phone to be configured to the first installation directory in a read-only manner can be as follows:

[0145] # cd / data / app /

[0146] # ln -s / data / share_app_center / {app_id} / app / {app_package} / data / app / {app_package}

[0147] The user can execute ls to view the connection relationship between the cloud phone to be configured and the first installation directory, which should be displayed as follows:

[0148] # ls -l

[0149] drwxr-xr-x 1 system system 4096 2020-05-25 17:51 {app_package} -> / data / share_app_center / {app_id} / app / {app_package}

[0150] The first multi-layer file system is deployed in the cloud phone to be configured, wherein the upper directory of the first multi-layer file system stores the modified data, and the API instruction for soft linking the lower directory with the second installation directory can be as follows:

[0151] # mount -t overlay -o

[0152] lowerdir= / sfs_dir / {app_id} / sdcard / {app_package},upperdir= / overlay / {app_package} / diff / , workdir= / overlay / {app_package} / work / / overlay / {app_package} / merge /

[0153] # mount --bind / overlay / {app_package} / merge / / sdcard / Android / data / {app_package}

[0154] This command sets the second installation directory as the lower directory (i.e., "lowerdir" in the above command) to connect to the cloud phone to be configured in read-only mode. The upper directory (i.e., "upperdir" in the above command) is used to store the modified data. The first multi-layer file system overlays the upper and lower directories to complete the application installation on the cloud phone to be configured. It should be understood that the above API instructions are for illustrative purposes only and are not limited to this application.

[0155] Optionally, the user can also use an API command to register the mounted application with the operating system of the cloud phone to be configured. The application icon will be displayed in the cloud phone to be configured, and the user can click the icon to launch the application. The API command to register the application with the operating system of the cloud phone to be configured can be as follows: "# bash quick-reg.sh / data / app / {app_package}". It should be understood that the above API command is for illustrative purposes only and is not specifically limited in this application.

[0156] In one embodiment, when an application is updated, the cloud platform may receive instructions input by the user through the console or API to implement the application update. Specifically, the user may first update the application in the template cloud phone, generate an updated directory of the target cloud phone, and then compress and package it and upload it to the object storage device. The object storage device synchronizes the updated directory of the template cloud phone to a shared network file, and the to-be-configured cloud phone remounts the to-be-configured cloud phone to implement the application update. For example, the API for the to-be-configured cloud phone to remount the first installation directory in read-only mode may be as follows:

[0157] # rm / data / app / {app_package}

[0158] # cd / data / app /

[0159] # ln -s / data / share_app_center / {app_id} / {version} / app / {app_package} / data / app / {app_package}

[0160] The API for re-using the first multi-layer file system to mount the second installation directory on the cloud phone to be configured may be as follows:

[0161] # umount / sdcard / Android / data / {app_package}

[0162] # mount -t overlay -o lowerdir= / sfs_dir / {app_id} / {version} / sdcard / {app_package},upperdir = / overlay / {app_package} / diff / ,workdir= / overlay / {app_package} / work / / overlay / {app_package} / merge /

[0163] # mount --bind / overlay / {app_package} / merge / / sdcard / Android / data / {app_package}

[0164] This completes the application update. During the entire update process, the new version of the application only needs to be installed on the template cloud phone, without having to update the application on all cloud phones purchased by the user. This improves the application update efficiency and thus improves the user experience.

[0165] In one embodiment, a second multi-layer file system can be deployed in the network shared file, static data can be connected in a read-only manner, and dynamic data can be read and written using the multi-layer file system, thereby achieving the mounting of the template cloud phone directory and completing the installation, operation and startup of the application.

[0166] In a specific implementation, the network shared file configuration interface is also used to configure the first network shared file to connect to the first installation directory in the first network shared file in a read-only manner according to the user's third input; the network shared file configuration interface is also used to configure a second multi-layer file system in the first network shared file according to the user's third input, and the second multi-layer file system is used to receive and process data read and write requests sent by at least one cloud phone to be configured, wherein the second multi-layer file system includes an upper directory and a lower directory, the lower directory is used to connect to the second installation directory in a read-only mapping manner, the upper directory is used to store modified data generated during the operation of the application installed in the first network shared file, and the second multi-layer file system is used to superimpose the upper directory and the lower directory.

[0167] refer to Figure 5A~Figure 5B It can be seen from the embodiment that before the cloud phone to be configured starts the App, a blank directory 1 with the above-mentioned second multi-layer file system built in it can be created in the network shared file, and it can be mounted to the cloud phone to be configured as the root directory of its data disk. Then, based on the installation information downloaded from the object storage, a copy directory is created. The directory structure and data in the copy directory are the same as the directory structure and data in the installation information, and the blank directory 1 is mounted in the copy directory. In this way, when the cloud phone to be configured runs the App, the cloud phone to be configured can read data from the blank directory 1 with the copied directory mounted, and write the generated modified data to the blank directory 1 through the second multi-layer file system of the blank directory 1. For example, in the case where the network shared file configuration interface is an API interface, for example, assuming that the cloud phone to be configured is C1, the API for creating a blank directory as the root directory for the cloud phone to be configured can be as follows:

[0168] POST / share-stores / {share_store_id} / instances / {id} / action

[0169] { “create”: { “path” : ” / data_C1”}}

[0170] Mount a blank directory to the cloud phone C1 to be configured as the root directory of its data disk using the following API:

[0171] POST / share-stores / {share_store_id} / instances / {id} / action

[0172] { “mount”: { “path” : ” / data_C1”, “target”: “ / data”}}

[0173] You can enter the following API to view the mount information, which will be displayed similar to the following:

[0174] # mount

[0175] {cpsfs address}: / data_C1 on / data type cpsfs (rw,ver=1,...)

[0176] Create a copy directory in the network shared file and mount it to the root directory of the cloud phone C1 to be configured. The API can be as follows:

[0177] POST / share-stores / {share_store_id} / instances / {id} / action

[0178] { “copy_on_write”: { “src_path” : ” / App_A_share / sdcard / App_A”, “dest_path” : “ / data_C1 / sdcard / Android / data / App_A”}}

[0179] Based on this, the cloud phone C1 to be configured can be mounted to the network shared file to realize the installation, operation and update of the application. It should be understood that the above examples are for illustration only and this application does not make specific limitations. Moreover, the method of using the second multi-layer file system to realize application update by the network shared file is similar to the method of using the first multi-layer file system to realize application update by the above-mentioned cloud phone to be configured. The API for application update will not be repeated here.

[0180] In one embodiment, if resource migration occurs in the cloud phone to be configured, the template cloud phone, at least one cloud phone to be configured, and the first network shared file are located in the first data center, and in the case where the first cloud phone to be configured in at least one cloud phone to be configured is migrated from the first data center to the second data center, the network shared file configuration interface is also used to create a second network shared file located in the second data center based on the user's fifth input, and the second network shared file is a mirror image of the first network shared file. The network shared file configuration interface is also used to configure the first cloud phone to be configured that has been migrated to the first data center to mount the second network shared file to complete the installation of multiple applications based on the user's sixth input. Simply put, after the location changes, the user can create a second network shared file in the second data center through the API or console, and mount the migrated cloud phone to be configured to the above-mentioned second network shared file, so that when the user's geographic location changes, the user data will not be lost, thereby improving the user experience. For details of the above process, please refer to Figure 6 The embodiments are not repeated here.

[0181] In one embodiment, when the cloud phone to be configured is migrated from the first server of the first data center to the second server of the first data center, the network shared file configuration interface is used to configure the cloud phone to be configured on the second server to mount the network shared file to complete the installation of multiple applications, so that the migration time of the cloud phone to be configured in the same data center is shortened to seconds, thereby improving the user experience of the cloud phone. The above process can be specifically referred to Figure 7 The embodiments are not repeated here.

[0182] In one embodiment, the user can also upload a list of applications to be installed and the number x of cloud phones to be configured through the console or API. The cloud platform automatically creates a template cloud phone, a network shared file, and an object storage device based on the number of applications and the application list uploaded by the user, and installs the applications in the above application list on the template cloud phone. The directory of the template cloud phone is then exported to the object storage device, and the network shared file synchronizes the installation information in the object storage device. x-1 cloud phones are configured to mount on the network shared file, and the purpose of installing the applications in the application list on x-1 cloud phones is achieved. Including the template cloud phone, the purpose of installing the applications in the application list on x cloud phones is achieved. The user's operation during the entire cloud phone application installation is very convenient, which improves the user experience.

[0183] In summary, the cloud phone-based application installation method provided in this application does not require the installation of applications in each cloud phone, but instead synchronizes the application installation information to a network shared file. The cloud phone can mount the installation information of various applications from the network shared file, thereby realizing the startup, operation and update of the application without installing the application in advance, reducing the memory usage of the cloud phone, and reducing the operation and maintenance costs of the cloud phone. At the same time, the startup, operation and update speed of the App can be improved, thereby improving the user experience.

[0184] The above describes in detail the method of the embodiment of the present application. In order to facilitate better implementation of the above scheme of the embodiment of the present application, correspondingly, related equipment for cooperating in implementing the above scheme is also provided below.

[0185] like Figure 11 As shown, the present application provides a cloud platform 131, including a cloud phone configuration interface unit 1110, an object storage creation interface unit 1120, an object storage interface unit 1130, a network shared file creation interface unit 1140, and a network shared file configuration interface unit 1150.

[0186] A cloud phone configuration interface unit 1110 is provided for providing a cloud phone configuration interface, which is used to configure a template cloud phone according to a first input from a user, wherein the template cloud phone is provided with multiple applications, and the directory of the template cloud phone records the installation information of multiple applications; a network shared file configuration interface unit 1150 is provided for providing a network shared file configuration interface, which is used to store the directory of the template cloud phone to a first network shared file according to a second input from a user; wherein the cloud phone configuration interface is also used to configure at least one cloud phone to be configured to mount the first network shared file according to a third input from the user to complete the installation of multiple applications.

[0187] In one embodiment, an object storage interface unit 1130 is provided for providing an object storage interface, and the object storage interface is used to obtain the directory of the template cloud phone according to the user's fourth input and store the directory of the template cloud phone in the object storage device. A unit is provided for providing an object storage interface; a network shared file configuration interface is used to synchronize the directory storage of the template cloud phone stored in the object storage device to the first network shared file according to the user's second input.

[0188] In one embodiment, the first network shared file includes a first installation directory and a second installation directory, wherein the second installation directory includes dynamic data of multiple applications, and the first installation directory includes static data of multiple applications; the cloud phone configuration interface is also used to configure at least one cloud phone to be configured to connect to the first installation directory in the first network shared file in a read-only manner according to the user's third input; the cloud phone configuration interface is also used to configure a first multi-layer file system in at least one cloud phone to be configured according to the user's third input, and the first multi-layer file system is used for at least one cloud phone to be configured to perform read and write operations on the second installation directory, wherein the first multi-layer file system includes an upper directory and a lower directory, the lower directory is used to connect to the second installation directory in a read-only mapping manner, the upper directory is used to store modified data generated during the operation of an application installed in at least one cloud phone to be configured, and the first multi-layer file system is used to superimpose the upper directory and the lower directory.

[0189] In one embodiment, the network shared file includes a first installation directory and a second installation directory, wherein the second installation directory includes dynamic data of multiple applications, and the first installation directory includes static data of multiple applications; the network shared file configuration interface is also used to configure the first network shared file to connect to the first installation directory in the first network shared file in a read-only manner according to the user's third input; the network shared file configuration interface is also used to configure a second multi-layer file system in the first network shared file according to the user's third input, and the second multi-layer file system is used to receive and process data read and write requests sent by at least one cloud phone to be configured, wherein the second multi-layer file system includes an upper directory and a lower directory, the lower directory is used to connect to the second installation directory in a read-only mapping manner, the upper directory is used to store modified data generated during the operation of the application installed in the first network shared file, and the second multi-layer file system is used to superimpose the upper directory and the lower directory.

[0190] In one embodiment, the first network shared file is located in the first data center. When the cloud phone to be configured is located in the second data center, the network shared file configuration interface is also used to create a second network shared file located in the second data center based on the user's fifth input. The second network shared file is a mirror image of the first network shared file.

[0191] In one embodiment, when the cloud phone to be configured is migrated from the first server of the first data center to the second server of the first data center, the network shared file configuration interface is used to configure the cloud phone to be configured on the second server to mount the network shared file to complete the installation of multiple applications.

[0192] In one embodiment, a network shared file creation interface unit 1140 is provided for providing a network shared file creation interface, where the network shared file creation interface is used to create a network shared file according to a sixth input of the user.

[0193] In one embodiment, an object storage creation interface unit 1120 is provided for providing an object storage creation interface, where the object storage creation interface is used to create an object storage according to a seventh input of the user.

[0194] In summary, when the cloud platform provided by this application installs applications on cloud phones, there is no need to install applications in each cloud phone. Instead, the installation information of the applications is synchronized to a network shared file. The cloud phone can mount the installation information of various applications from the network shared file, thereby realizing the startup, operation and update of the applications without installing the applications in advance, thereby reducing the memory usage of the App in the cloud phone, greatly reducing the operating and maintenance costs of the cloud phone, and at the same time improving the startup, operation and update speed of the App, thereby improving the user experience.

[0195] Figure 12A schematic diagram of the structure of a computing device 1200 provided in an embodiment of the present application. The computing device 1200 may be Figures 1-11 The cloud platform 131 in the embodiment. Figure 12 As shown, the computing device 1200 includes: a processor 1210, a communication interface 1220 and a memory 1230. The processor 1210, the communication interface 1220 and the memory 1230 can be connected to each other through an internal bus 1240, or can communicate through other means such as wireless transmission. The embodiment of the present application takes the connection through the bus 1240 as an example. The bus 1240 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. The bus 1240 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 12 Only one thick line is used in the diagram, but this does not mean that there is only one bus or one type of bus.

[0196] The processor 1210 may be composed of at least one general-purpose processor, such as a central processing unit (CPU), or a combination of a CPU and a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The PLD may be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof. The processor 1210 executes various types of digitally stored instructions, such as software or firmware programs stored in the memory 1230, enabling the computing device 1200 to provide a wide variety of services.

[0197] The memory 1230 is used to store program codes and is controlled by the processor 1210 to execute the above Figure 2-Figure 10 The processing steps of the cloud phone management node 310 in any embodiment. The program code may include one or more software modules. The one or more software modules may be Figure 12The software modules provided in the illustrated embodiment, such as providing a cloud phone configuration interface unit, providing a network shared file configuration interface unit 1150, etc., wherein the cloud phone configuration interface unit is provided for providing a cloud phone configuration interface, and the cloud phone configuration interface is used to configure the template cloud phone according to the user's first input, and the template cloud phone is provided with multiple applications, and the directory of the template cloud phone records the installation information of multiple applications; the network shared file configuration interface unit is provided for providing a network shared file configuration interface, and the network shared file configuration interface is used to store the directory of the template cloud phone to the first network shared file according to the user's second input, which can be specifically used to execute steps S310 to S340, steps S410 to S440 and optional steps thereof of the aforementioned method, and can also be used to execute Figure 3-10 The other steps performed by the cloud platform 131 described in the embodiment will not be repeated here.

[0198] It should be noted that this embodiment can be implemented by a general physical server, for example, an ARM server or an X86 server, or it can be implemented by a virtual machine based on a general physical server combined with NFV technology. The virtual machine refers to a complete computer system with complete hardware system functions simulated by software and running in a completely isolated environment. This application does not make specific limitations.

[0199] The memory 1230 may include a volatile memory, such as a random access memory (RAM); the memory 1030 may also include a non-volatile memory, such as a read-only memory (ROM), a flash memory, a hard disk drive (HDD), or a solid-state drive (SSD); the memory 1230 may also include a combination of the above types. The memory 1230 may store program code, specifically including a program code for executing Figure 3-10 The program codes of other steps described in the embodiment will not be described in detail here.

[0200] The communication interface 1220 can be a wired interface (such as an Ethernet interface), an internal interface (such as a high-speed serial computer expansion bus (Peripheral Component Interconnect express, PCIe) bus interface), a wired interface (such as an Ethernet interface) or a wireless interface (such as a cellular network interface or a wireless local area network interface) for communicating with other devices or modules.

[0201] Need to explain, Figure 12 This is only one possible implementation of the embodiment of the present application. In actual applications, the computing device may also include more or fewer components, which is not limited here. Figure 3-10 The relevant explanations in the embodiments are not repeated here.

[0202] It should be understood that Figure 12 The computing device shown may also be a computer cluster consisting of at least one server, which is not specifically limited in this application.

[0203] The embodiment of the present application further provides a computer-readable storage medium, wherein the computer-readable storage medium stores instructions, which, when executed on a processor, Figure 3-10 The method flow shown is realized.

[0204] The present application also provides a computer program product. When the computer program product is run on a processor, Figure 3-10 The method flow shown is realized.

[0205] The above embodiments can be implemented in whole or in part via software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented in whole or in part in the form of a computer program product. The computer program product comprises at least one computer instruction. When loaded or executed on a computer, the computer program instruction fully or partially performs the processes or functions described in accordance with the embodiments of the present invention. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, optical fiber, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible by a computer or a data storage device, such as a server or data center, that contains at least one set of available media. The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a high-density digital video disc (DVD),) or a semiconductor medium. The semiconductor medium may be an SSD.

[0206] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and such modifications or substitutions are intended to be within the scope of protection of the present invention. Therefore, the scope of protection of the present invention shall be subject to the scope of protection of the claims.

Claims

1. A cloud phone application installation method based on a cloud platform system, characterized in that: include: Providing a cloud phone configuration interface, the cloud phone configuration interface is used to configure a template cloud phone according to a first input of a user, the template cloud phone being provided with a plurality of applications, and a directory of the template cloud phone recording installation information of the plurality of applications; Providing a network shared file configuration interface, the network shared file configuration interface being used to store the directory of the template cloud phone to a first network shared file according to the second input of the user, the first network shared file including a first installation directory and a second installation directory, wherein the first installation directory includes static data of the multiple applications during operation, and the second installation directory includes dynamic data of the multiple applications during operation; Among them, the cloud phone configuration interface is also used to configure at least one cloud phone to be configured to mount the first network shared file according to the user's third input, so as to realize the startup and operation of the multiple applications, wherein the cloud phone to be configured mounts the first installation directory from the first network shared file in a read-only manner, and the cloud phone to be configured mounts the second installation directory through a multi-layer file system, the multi-layer file system includes an upper directory and a lower directory, the lower directory is used to connect to the second installation directory in a read-only mapping manner, the upper directory is used to store the modified data generated during the operation of the multiple applications, the multi-layer file system is used to superimpose the upper directory and the lower directory, the multi-layer file system is deployed in the cloud phone to be configured, or the multi-layer file system is deployed in the network shared file.

2. The method according to claim 1, characterized in that Before providing the network shared file configuration interface, the method further includes: Provide an object storage interface, the object storage interface is used to obtain the directory of the template cloud phone according to the fourth input of the user and store the directory of the template cloud phone in the object storage device; then The network shared file configuration interface is specifically used to synchronize the directory storage of the template cloud phone stored in the object storage device to the first network shared file according to the second input of the user.

3. The method according to claim 1, characterized in that The cloud phone configuration interface is further configured to configure the at least one cloud phone to be configured to connect to the first installation directory in the first network shared file in a read-only manner according to the third input of the user; The cloud phone configuration interface is further used to configure a first multi-layer file system in the at least one cloud phone to be configured according to the user's third input, and the first multi-layer file system is used for the at least one cloud phone to be configured to perform read and write operations on the second installation directory, wherein the first multi-layer file system includes an upper directory and a lower directory, the lower directory is used to connect to the second installation directory in a read-only mapping manner, the upper directory is used to store modification data generated during the operation of an application installed in the at least one cloud phone to be configured, and the first multi-layer file system is used to superimpose the upper directory and the lower directory.

4. The method according to claim 1, wherein The network shared file configuration interface is further configured to configure the first network shared file to be connected to the first installation directory in the first network shared file in a read-only manner according to the third input of the user; The network shared file configuration interface is also used to configure a second multi-layer file system in the first network shared file according to the user's third input, and the second multi-layer file system is used to receive and process data read and write requests sent by at least one cloud phone to be configured, wherein the second multi-layer file system includes an upper directory and a lower directory, the lower directory is used to connect to the second installation directory in a read-only mapping manner, the upper directory is used to store modified data generated during the operation of the application installed in the first network shared file, and the second multi-layer file system is used to superimpose the upper directory and the lower directory.

5. The method according to claim 4, characterized in that The template cloud phone, the at least one cloud phone to be configured, and the first network shared file are located in a first data center. When the first cloud phone to be configured in the at least one cloud phone to be configured is migrated from the first data center to the second data center, The network shared file configuration interface is further used to create a second network shared file located in a second data center according to the fifth input of the user, where the second network shared file is a mirror image of the first network shared file.

6. The method according to claim 5, characterized in that The network shared file configuration interface is further used to configure the first to-be-configured cloud phone migrated to the first data center to mount the second network shared file to complete the installation of the multiple applications based on the user's sixth input.

7. The method according to claim 1, characterized in that Before providing the network shared file configuration interface, the method further includes: A network shared file creation interface is provided, where the network shared file creation interface is used to create the network shared file according to the sixth input of the user.

8. The method according to claim 2, characterized in that Before providing the object storage interface, the method further includes: An object storage creation interface is provided, where the object storage creation interface is used to create the object storage according to the seventh input of the user.

9. The method according to claim 3 or 4, characterized in that The multi-layer file system includes an overlay file system.

10. The method according to claim 1, characterized in that The template cloud phone and the cloud phone to be configured include virtual machines, containers and bare metal servers.

11. The method according to claim 1, characterized in that The network shared file includes user data, and the user data includes local business data and local habit data generated during the running of the application.

12. The method according to any one of claims 1 to 8, 10 and 11, characterized in that: The applications include gaming applications, work applications, educational applications, video applications, social applications, and virtual reality applications.

13. A cloud platform system, characterized in that: include: Providing a cloud phone configuration interface unit, for providing a cloud phone configuration interface, wherein the cloud phone configuration interface is used to configure a template cloud phone according to a first input of a user, wherein the template cloud phone is provided with a plurality of applications, and a directory of the template cloud phone records installation information of the plurality of applications; Providing a network shared file configuration interface unit, configured to provide a network shared file configuration interface, wherein the network shared file configuration interface is configured to store the directory of the template cloud phone to a first network shared file according to the second input of the user, wherein the first network shared file includes a first installation directory and a second installation directory, wherein the first installation directory includes static data of the multiple applications during operation, and the second installation directory includes dynamic data of the multiple applications during operation; Among them, the cloud phone configuration interface is also used to configure at least one cloud phone to be configured to mount the first network shared file according to the user's third input, so as to realize the startup and operation of the multiple applications, wherein the cloud phone to be configured mounts the first installation directory from the first network shared file in a read-only manner, and the cloud phone to be configured mounts the second installation directory through a multi-layer file system, the multi-layer file system includes an upper directory and a lower directory, the lower directory is used to connect to the second installation directory in a read-only mapping manner, the upper directory is used to store the modified data generated during the operation of the multiple applications, the multi-layer file system is used to superimpose the upper directory and the lower directory, the multi-layer file system is deployed in the cloud phone to be configured, or the multi-layer file system is deployed in the network shared file.

14. The cloud platform system according to claim 13, characterized in that: The cloud platform system also includes: providing an object storage interface unit, configured to provide an object storage interface, wherein the object storage interface is configured to obtain a directory of the template cloud phone according to the fourth input of the user and store the directory of the template cloud phone in an object storage device; The network shared file configuration interface is used to synchronize the directory storage of the template cloud phone stored in the object storage device to the first network shared file according to the second input of the user.

15. The cloud platform system according to claim 13, characterized in that: The cloud phone configuration interface is further configured to configure at least one cloud phone to be configured to connect to the first installation directory in the first network shared file in a read-only manner according to the third input of the user; The cloud phone configuration interface is further used to configure a first multi-layer file system in the at least one cloud phone to be configured according to the user's third input, and the first multi-layer file system is used for the at least one cloud phone to be configured to perform read and write operations on the second installation directory, wherein the first multi-layer file system includes an upper directory and a lower directory, the lower directory is used to connect to the second installation directory in a read-only mapping manner, the upper directory is used to store modification data generated during the operation of an application installed in the at least one cloud phone to be configured, and the first multi-layer file system is used to superimpose the upper directory and the lower directory.

16. The cloud platform system according to claim 14, characterized in that: The network shared file configuration interface is further configured to configure the first network shared file to be connected to the first installation directory in the first network shared file in a read-only manner according to the third input of the user; The network shared file configuration interface is also used to configure a second multi-layer file system in the first network shared file according to the user's third input, and the second multi-layer file system is used to receive and process data read and write requests sent by at least one cloud phone to be configured, wherein the second multi-layer file system includes an upper directory and a lower directory, the lower directory is used to connect to the second installation directory in a read-only mapping manner, the upper directory is used to store modified data generated during the operation of the application installed in the first network shared file, and the second multi-layer file system is used to superimpose the upper directory and the lower directory.

17. The cloud platform system according to claim 16, characterized in that: The template cloud phone, the at least one cloud phone to be configured, and the first network shared file are located in a first data center. When the first cloud phone to be configured in the at least one cloud phone to be configured is migrated from the first data center to the second data center, The network shared file configuration interface is further used to create a second network shared file located in a second data center according to the fifth input of the user, where the second network shared file is a mirror image of the first network shared file.

18. The cloud platform system according to claim 17, characterized in that: The network shared file configuration interface is further used to configure the first to-be-configured cloud phone migrated to the first data center to mount the second network shared file to complete the installation of the multiple applications based on the user's sixth input.

19. The cloud platform system according to any one of claims 13 to 18, characterized in that: The cloud platform system also includes: A network shared file creation interface unit is provided, which is used to provide a network shared file creation interface, and the network shared file creation interface is used to create the network shared file according to the sixth input of the user.

20. The cloud platform system according to claim 14, wherein: The cloud platform system also includes: An object storage creation interface unit is provided, which is used to provide an object storage creation interface, and the object storage creation interface is used to create the object storage according to the seventh input of the user.

21. A computer-readable storage medium, characterized in that The method comprises instructions, which, when executed on a computing device, cause the computing device to perform the method according to any one of claims 1 to 12.

22. A computing device, characterized in that The method comprises a processor and a memory, wherein the processor executes the code in the memory to perform the method according to any one of claims 1 to 12.

23. A computer program product, characterized in that The method comprises a computer program, which, when read and executed by a computing device, causes the computing device to perform the method according to any one of claims 1 to 12.

Images