WO2022033090A1 - 基于云手机的应用安装方法、云平台及相关设备 - Google Patents

基于云手机的应用安装方法、云平台及相关设备 Download PDF

Info

Publication number
WO2022033090A1
WO2022033090A1 PCT/CN2021/092955 CN2021092955W WO2022033090A1 WO 2022033090 A1 WO2022033090 A1 WO 2022033090A1 CN 2021092955 W CN2021092955 W CN 2021092955W WO 2022033090 A1 WO2022033090 A1 WO 2022033090A1
Authority
WO
WIPO (PCT)
Prior art keywords
cloud
directory
network shared
shared file
phone
Prior art date
Application number
PCT/CN2021/092955
Other languages
English (en)
French (fr)
Inventor
陈佳敦
明亮
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from CN202011395057.8A external-priority patent/CN114115912A/zh
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to EP21855146.3A priority Critical patent/EP4191401A4/en
Publication of WO2022033090A1 publication Critical patent/WO2022033090A1/zh
Priority to US18/167,587 priority patent/US20230185556A1/en

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/61Installation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003Arrangements for executing specific machine instructions
    • G06F9/3004Arrangements for executing specific machine instructions to perform operations on memory
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/65Updates

Definitions

  • the present invention relates to the technical field of cloud computing, and in particular, to a method for issuing resources for cloud services and related equipment.
  • a cloud phone is a cloud server with an operating system and a virtual phone function.
  • Cloud mobile phones play a very good role in extending and expanding physical mobile phones, and can be used in scenarios such as cloud mobile games and mobile office.
  • the application Application, App
  • the App user can remotely connect to the cloud mobile phone through a personal terminal device, and the cloud mobile phone will render the audio and video images rendered during the application running process through the audio and video stream.
  • the terminal device displays the received audio and video streams on the screen, so that App users can use terminal devices with relatively limited image processing and data computing capabilities, or even only streaming media playback capabilities to use hardware resources. App with higher requirements.
  • apps in cloud mobile phones are generally managed by users who have purchased cloud mobile phone services. If a user buys 1000 cloud phones, each cloud phone can provide 100 kinds of apps, then each cloud phone needs to install 100 kinds of apps, if the installation size of each app is 1GB (actually it is likely to exceed 1GB), then One cloud phone needs 100GB of storage space, and 1,000 cloud phones need 100T of storage space. Any App update will also take up a lot of storage space, making the operation and maintenance costs of game manufacturers too high. Cloud mobile phones with 100 kinds of apps are more likely to be stuck during startup and app running, reducing the user's cloud mobile phone experience.
  • the present application provides an application installation method, cloud platform and related equipment based on cloud mobile phones, which are used to solve the problem that when installing and updating applications on massive cloud mobile phones, a large amount of storage space is occupied, the operation and maintenance costs are high, and the card is prone to appear during the operation of the application. ton's question.
  • a first aspect provides an application installation method based on a cloud phone, and the method includes the following steps: a cloud platform provides a user with a cloud phone configuration interface, configures a template cloud phone according to the user's first input, and the cloud platform provides the user with a network
  • the shared file configuration interface according to the user's second input, stores the directory of the template cloud phone in the first network shared file, and then configures at least one cloud phone to be configured according to the user's third input to mount the first network shared file to complete multiple installation of an application.
  • the at least one cloud phone to be configured may be, for example, one cloud phone to be configured or multiple cloud phones to be configured.
  • the embodiment of the present invention can support 1-1000 More than one cloud phone to be configured installs multiple applications at the same time.
  • the cloud platform does not need to install applications in each cloud mobile phone when installing and updating massive cloud applications, and the cloud mobile phone to be configured can mount the installation information of various applications from the network shared file, In this way, the startup, operation and update of the application can be realized without installing the application in advance, thereby reducing the storage space occupation of the cloud mobile phone and the operation and maintenance cost of the cloud mobile phone. user experience.
  • the cloud platform may further provide the user with an object storage interface, obtain the directory of the template cloud phone according to the fourth input of the user, and store the template cloud phone's directory
  • the directory is stored in the object storage device, and the cloud platform can 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 second input of the user through 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 the network shared file according to the sixth input of the user.
  • the method may further include the following steps: providing 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.
  • 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, wherein the object storage device has a larger storage capacity, and the network shared file has a larger storage capacity.
  • the storage capacity is small, so multiple network shared files can be used to synchronize the installation information in the object storage device, thereby increasing the number of applications that users can install.
  • the object storage device can also manage the installation information exported from the template cloud phone. For example, the storage path, version information, corresponding user information, application name, type, etc. of the installation information are recorded, so as to further improve the installation efficiency.
  • the present application provides two ways to implement the cloud phone to be configured to mount the network shared file, and the two implementation ways are explained below respectively.
  • the network shared file can be mounted by configuring the first multi-layer file system in the cloud phone to be configured.
  • the first network shared file includes the 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 The cloud mobile phone to be configured is connected to the first installation directory in the first network shared file in a read-only manner;
  • the cloud mobile phone configuration interface is also used to configure the first multi-layer file system on at least one cloud mobile phone to be configured according to the third input of the user,
  • 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-level directory and a lower-level directory, and the lower-level directory is used for read-only mapping.
  • the second installation directory is connected, the upper-level directory is used to store modified data generated during the running of at least one application installed in the
  • the above-mentioned first multi-layer file system can be realized by the overlay file system, and the read-only mode can be through a soft connection.
  • the first installation directory in the network shared file is mapped to the cloud mobile phone, so that the cloud mobile phone requests access
  • the first installation directory it will jump to the first installation directory stored in the network shared file through the network, so that the installation information in the application installation directory can be obtained by mounting from the network shared file in a read-only manner.
  • the cloud mobile phone to be configured mounts the network shared file through the combination of the first multi-layer file system and the read-only mode, which not only ensures the reading and writing of data during the running process of the application, but also realizes the application in the cloud to be configured.
  • the startup and operation on the mobile phone can also realize the application update by re-mounting the installation information of the new version, so that in the scenario of massive cloud mobile phone configuration applications, the cloud platform can realize the application without installing the application in each cloud mobile phone.
  • the installation, operation and update of the cloud mobile phone can reduce the occupation of the storage space of the cloud mobile phone and reduce the operation and maintenance cost of the cloud mobile phone.
  • the cloud phone to be configured may mount the network shared file by configuring the second multi-layer file system in the network shared file.
  • 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 through the network shared file configuration interface according to the third input of the user, and then configure the interface through the network shared file
  • the second multi-layer file system is configured on the first network to share the file according to the third input of the user, and the second multi-layer file system is used to receive and process the data read and write request sent by at least one cloud phone to be configured, wherein the second multi-layer file system
  • the file system includes an upper-level directory and a lower-level directory.
  • the lower-level directory is used to connect the second installation directory in a read-only mapping manner
  • the upper-level directory is used to store the modified data generated during the running of the application installed in the first network shared file.
  • Layer file systems are used to overlay upper and lower directories.
  • the above-mentioned second multi-layer file system can be implemented by the Overlay file system, and a network shared file can first create a blank directory with the above-mentioned second multi-layer file system built in, and the cloud mobile phone to be configured is linked in a read-only mode with the blank directory Make a connection, and then create a copy directory for the network shared file.
  • the copy directory is a mirror image of the cloud phone directory.
  • the blank directory with the overlay file system deployed is mounted in the copy directory.
  • the cloud phone to be configured is read-only and connected to the blank directory.
  • the blank directory includes an upper-level directory and a lower-level directory
  • the lower-level directory is used to connect the second installation directory in the copy directory in a read-only mapping manner
  • the upper-level directory is used to store the first network.
  • the modified data generated during the running of the application installed in the shared file, and the second multi-layer file system is used to superimpose the upper-level directory and the lower-level directory.
  • the cloud phone to be configured can read data from the blank directory 1 where the copy directory is mounted, and write the generated modified data into the blank directory 1 through the second multi-layer file system of the blank directory 1, so as to realize the application in the cloud to be configured. installation on the phone.
  • Implementing the above implementation method can not only ensure the reading and writing of data during the running process of the application, and realize the startup and operation of the application on the cloud mobile phone to be configured, but also realize the update of the application by re-mounting the installation information of the new version, so that the application can be updated.
  • the cloud platform can install, run and update applications without installing applications in each cloud phone, reducing the storage space occupied by the cloud phone and reducing the operation and maintenance cost of the cloud phone.
  • the shared network file may include user data, and the user data includes local service data and local habit data generated during the running of the application.
  • the user data of the mobile game application may include the user's default account information, historical login area server information, etc.
  • the user data of the stand-alone game application may include game clearance records, game character data, etc.
  • the user data of the mailbox application may include user mailbox account binding information, mailbox card settings, etc.
  • the user data of the office communication application may include user history chat records, user history account information, and user history files.
  • Information, business data, etc. it should be understood that the user data may also include private data generated by the user during the running of other types of applications, which will not be illustrated here.
  • 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, and the first cloud phone to be configured in the at least one cloud phone to be configured
  • the network sharing file configuration interface is also used to create a second network sharing file located in the second data center according to the fifth input of the user, and the second network sharing file is a mirror of the first network share file.
  • the object storage device can send a request to create a network shared file 1' to the South China data center, and then synchronize the installation information of the office application to the network shared file 1'.
  • the cloud phone 1' mounted on the network shared file 1' can keep the user data while the app is running, and the user does not need to re-enter the account password, re-download business data, etc., Improve user experience.
  • the network shared file configuration interface is further configured to, according to the sixth input of the user, configure the first cloud phone to be configured migrated to the first data center to mount the second network shared file to Complete the installation of multiple applications. For example, if the cloud phone 2 used by the user is migrated from server 1 to server 2, the cloud phone 2 can be stopped first, and then the mount between the cloud phone 2 and the network shared file can be cancelled, and then a cloud phone can be created on server 2. 2', and provide the mounting directory on the network shared file to the cloud phone 2', and the cloud phone 2' mounts the network shared file through the mounting directory to realize the resource migration of the cloud phone.
  • the migrated cloud phone can be implemented by re-mounting the network shared file
  • the application installation of the migrated cloud phone shortens the resource migration speed in the data center to the second level, improving the user experience.
  • the network shared file may be deployed with a server, and the cloud phone to be configured may be deployed with a client, wherein the client is used to read and write IO requests generated by the cloud phone to be configured (for example, the request to write the modified data generated by the running process of the App into the second installation directory, the request to read the first installation directory, etc.) are aggregated and sent to the server of the network shared file, and the server is used to receive the data sent by the client.
  • the above read and write IO request is disassembled and sent to the second multi-layer file system, and the second multi-layer file system realizes the read and write operations of the installation information.
  • the network shared file can first cache the received IO request in the memory.
  • the data in the cache is updated first, and then the asynchronous IO request is generated. . Then aggregate the IO requests of a large number of small files into a single IO request, and send the aggregated IO data to the server at one time.
  • the server can parse the received IO requests and then update them to the storage medium in batches.
  • the IO requests in the cloud mobile phone to be configured can be sent to the client. After the client aggregates the received IO requests, it is sent to the server for processing, thereby reducing the number of IO requests received by network shared files. It reduces the processing pressure of network shared files and improves the efficiency of App startup, operation, update and uninstallation.
  • the cloud phone to be configured can also be updated by the application installation method based on the cloud phone.
  • the cloud platform can install the updated application to the template cloud phone and export it to the object storage device (or operated by the user.
  • the template cloud phone performs application update, which is not specifically limited in this application), the object storage device synchronizes the installation information of the new version to the network shared file, and the network shared file can provide a new mount directory to the cloud phone to be configured (of course, it can also be kept The mount directory remains unchanged, but the installation information in the mount directory is updated).
  • the cloud phone to be configured can re-mount the new version of the installation information in the network shared file according to the above-mentioned new mount directory to update the App.
  • the uninstallation of the application can be completed, and the user does not need to operate each cloud phone to perform the uninstallation operation, which improves the user experience.
  • the template cloud phone and the cloud phone to be configured include virtual machines, containers, and bare metal servers.
  • the applications include gaming applications, work applications, educational applications, video applications, social applications, and virtual reality applications.
  • the user can purchase the 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 provides network shared files, object storage devices and to-be-shared files. Configure the cloud phone for configuration, so that the cloud phone to be configured mounts the network shared file to implement the application installation.
  • users can purchase a template cloud phone through the console or API, operate the template cloud phone to install the required applications, and then create and configure network shared files, object storage devices, and cloud phones to be configured through various interfaces provided by the cloud platform. , so that the cloud mobile phone to be configured mounts the network shared file to implement the application installation.
  • the interface may be an API interface, or a web page, an application program, or a console in other forms, which is not specifically limited in this application.
  • the user can also upload the list of applications to be installed and the number of cloud phones to be configured x through the console or API, and the cloud platform creates template cloud phones, network shared files and object storage according to the number of applications and the list of applications uploaded by the user.
  • the cloud platform creates template cloud phones, network shared files and object storage according to the number of applications and the list of applications uploaded by the user.
  • device and install the applications in the above application list on the template cloud phone, then export the directory of the template cloud phone to the object storage device, synchronize the installation information in the object storage device with the network shared file, and configure x cloud phones to be mounted on the object storage device.
  • the network shared file realizes the application purpose of the x number of cloud mobile phone installation application lists required by the user, and the user's operation in the entire cloud mobile phone application installation is very convenient and improves the user's use experience.
  • a cloud platform including: a cloud phone configuration interface unit for providing a cloud phone configuration interface, the cloud phone configuration interface for configuring a template cloud phone according to a user's first input, and the template cloud phone is provided with For multiple applications, the directory of the template cloud phone records the installation information of multiple applications; a network shared file configuration interface unit is provided, which is used to provide a network shared file configuration interface, and the network shared file configuration interface is used to configure the template according to the second input of the user.
  • the directory of the cloud phone is stored in the first network shared file; wherein, the cloud phone configuration interface is further configured to configure at least one cloud phone to be configured to mount the first network shared file according to the third input of the user to complete the installation of multiple applications.
  • the second aspect or any implementation manner of the second aspect is implemented by a device corresponding to the first aspect or any implementation manner of the first aspect, and the descriptions in the second aspect or any implementation manner of the second aspect are applicable to the first aspect Or any implementation manner of the first aspect, which is not repeated here.
  • a computer-readable storage medium comprising instructions that, when executed on a computing device, cause the computing device to perform the method as described in the first aspect.
  • a computing device including a processor and a memory, and when the processor executes codes in the memory, the computing device implements the method described in the first aspect.
  • a fifth aspect provides a computer program product that, when read and executed by a computing device, implements the method as described in the first aspect.
  • Figure 1 is a schematic diagram of the architecture of a public cloud system
  • FIG. 2 is a schematic structural diagram of a cloud-based mobile phone-based application installation system provided by the present application
  • FIG. 3 is a schematic flowchart of steps of a cloud-based mobile phone-based application installation method provided by the present application
  • 4A to 4B are schematic structural diagrams of a cloud mobile phone to be configured to mount a network shared file provided by the present application;
  • 5A-5B are another schematic structural diagram of a cloud mobile phone to be configured to mount a network shared file provided by the present application;
  • FIG. 6 is a schematic flowchart of cross-data center migration of a cloud mobile phone to be configured provided by the present application
  • FIG. 7 is a schematic flowchart of migration in a cloud mobile phone data center to be configured provided by the present application.
  • FIG. 8 is a schematic flowchart of steps of a cloud-based mobile phone-based application installation method provided by the present application.
  • FIG. 9 is a schematic diagram of a console interface provided by the application.
  • Fig. 10 is another kind of console interface schematic diagram provided by this application.
  • FIG. 11 is a schematic structural diagram of a cloud platform provided by the present application.
  • FIG. 12 is a schematic structural diagram of a computing device provided by the present application.
  • a container is a set of resource-constrained processes that are isolated from each other.
  • Cloud mobile phone a container, virtual machine or bare metal server with a mobile phone operating system virtualized in a physical server and a virtual mobile phone function. Its essence is to transfer the applications on the mobile phone to the container and virtual machine on the public cloud. Or bare metal server to run, different cloud mobile phones are isolated from each other and do not interfere with each other, cloud mobile phones can install applications of local mobile phones, these applications run in cloud mobile phones, and the audio and video streams generated during the running process can be sent to users.
  • the local terminal device performs display and playback, and the control commands generated by the user’s local terminal device according to the displayed and played audio and video streams can also be sent to the cloud mobile phone.
  • the application is transferred to the cloud mobile phone to run, and the user's local terminal device does not need to install a large number of applications that consume hardware resources, which can realize the lightweight of the application.
  • Public cloud The core attribute of public cloud is shared resource service, which refers to cloud infrastructure and services provided by cloud providers for 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, and users can use the cloud infrastructure and services remotely by paying the cloud provider to use the cloud infrastructure and services.
  • OBS Object Storage Service
  • OBS An object-based mass storage service in the public cloud, which can provide customers with massive, secure, highly reliable, and low-cost data storage capabilities.
  • OBS is an internet-oriented service that provides a web service interface based on the HTTP/HTTPS protocol. Users can connect to computers on the internet anytime, anywhere, and access and manage the data stored in OBS through the OBS management console or various OBS tools. data.
  • Elastic file service SFS: a service in the public cloud that provides a high-performance file system that can be expanded on demand.
  • SFS can be used for multiple elastic cloud servers (ECS), containers on the public cloud.
  • ECS elastic cloud servers
  • BMS Bare Metal Server
  • a cloud server can be used to mount the file system, so as to realize the purpose of sharing and using the file system by multiple cloud servers.
  • Mounting A process in which the operating system makes files and directories on a storage device (such as a hard disk or a shared resource) available to the user through the file system of the held device.
  • a storage device such as a hard disk or a shared resource
  • the user can access file A in the storage device by accessing directory B.
  • the directory B is also called the mount point, and the mount point can be located in the storage device.
  • the mount point can be located in the storage device.
  • On the device held by the user it can also be on the storage device, and it can also be on a virtual disk or a virtual folder.
  • the traditional Internet Technology (IT) business architecture is gradually migrating to the public cloud, and more and more business applications are redesigned and redesigned based on the public cloud architecture. use.
  • the application on the user's mobile phone will be installed in the cloud mobile phone, and the cloud mobile phone can transmit the audio and video images rendered during the running of the application to the terminal device 110 in the form of audio and video streams.
  • the terminal device 110 only needs to The received audio and video streams are displayed on the screen, and the application is truly free of download, installation, and click-to-use.
  • FIG. 1 is a schematic diagram of the architecture of a public cloud system.
  • 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 through a network 120 .
  • the network 120 may be a public network, such as the Internet.
  • the terminal device 110 may be an electronic device with streaming media playback capability, such as a smart phone, a handheld processing device, a tablet computer, a mobile notebook, a virtual reality device, a wearable device, an integrated handheld computer, etc.
  • the terminal device 110 is a smart phone.
  • An example is used for description, but this application does not specifically limit it.
  • the application service node 140 is used to provide various application services to the user, and the application service node 140 may include game service nodes, educational application service nodes, video application service nodes, social application service nodes, virtual reality application service nodes, etc., which are not specified in this application. limited.
  • the data center 130 of the public cloud may provide users with shared resource services, and the shared resource services may include OBS services, SFS services, cloud phone services, content delivery network services (CDN), and cloud backup services (cloud backup services). backup and recovery, CBR), data management service (data admin service, DAS), etc.
  • This application does not limit the types of shared resource services that the data center 130 of the public cloud can provide.
  • individual users can rent cloud infrastructure and services owned by the data center 130 of the public cloud through the network 120, and use the application services provided by the application service node 130 through the rented shared resources. High-quality stand-alone games, rental public cloud cloud mobile phones to experience high-definition mobile games, etc. Enterprise users can purchase cloud services for their own use according to their needs.
  • 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 the division method shown in FIG. 1 is used for illustration, and the data center 130 of the public cloud may also be divided in other manners. This application does not limit the way of dividing the data center 130 of the public cloud.
  • the cloud platform 131 may be implemented by a general-purpose physical server, for example, an ARM server or an X86 server, or may be a virtual machine (VM) implemented in combination with network functions virtualization (NFV) technology.
  • the platform 131 may also be a virtual machine or a physical server in the hardware resource pool 132, which is not specifically limited in this application.
  • the hardware resource pool 132 may include at least one physical server (FIG. 1 takes the resource pool including server 1, server 2, server 3 and server 4 as an example for illustration), wherein the physical server may be a general physical server, such as an ARM server Or an X86 server, which is not specifically limited in this application.
  • the physical server may be a general physical server, such as an ARM server Or an X86 server, which is not specifically limited in this application.
  • each physical server can run at least one cloud phone
  • the data center 130 of the public cloud 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 data center 130 of the public cloud can also install various applications in the cloud mobile phone in advance, and provide the user with the service of renting the application in the cloud mobile phone, such as charging according to the usage time of the application.
  • the user can send a purchase request to the cloud platform 131 to rent a cloud mobile phone, and the cloud platform 131 can allocate an installed mobile phone according to the resource usage in the hardware resource pool.
  • the cloud phone 11 of the application 111 is used by the user.
  • the terminal device 110 can remotely operate the application on the cloud mobile phone after paying for it, and the cloud mobile phone can respond to the user's remote operation and send the resulting audio and video streams to the terminal.
  • the device 110 performs display and playback, so that the user can use the terminal device 110 with relatively limited image processing and data computing capabilities, or even the terminal device 110 with only streaming media playback capabilities, to use applications that require high hardware resources.
  • the cloud phone may be a virtual machine (such as virtual machine 21 ), a container (such as container 11 and container 22 ), and a bare metal server (BMS) (such as a server) in FIG. 1 3) any of the above.
  • a virtual machine such as virtual machine 21
  • a container such as container 11 and container 22
  • BMS bare metal server
  • the cloud platform 131 can notify the cloud platform management agent node of the server to create a container according to the operating environment required by the application, and install the application 111 on the cloud phone; if the cloud phone is implemented by a virtual machine, the cloud The platform 131 can create a virtual machine through the virtual machine manager according to the running environment required by the application, and install the application 111 on the cloud mobile phone; if the cloud mobile phone is a BMS, the cloud platform 131 can select a suitable one according to the running environment required by the application. The BMS installs the application 111 on it, thereby obtaining the cloud mobile phone with the application 111 installed.
  • the cloud mobile phone is a virtual resource on the data center 130 of the public cloud, and the virtual resource runs a mobile phone operating system. The specific form of the cloud phone is limited.
  • the cloud platform 131 can release the cloud phone (ie, the container 11 ), and the released resources can be used by other users.
  • the terminal device 110 requests to remotely manipulate the cloud again
  • the application 111 is installed on the mobile phone
  • the cloud platform 131 can again create a cloud mobile phone with the application 111 installed for the user to use.
  • the user's application will be installed on the cloud phone, and the cloud phone can transmit the audio and video images rendered during the running of the application to the terminal device in the form of audio and video streams.
  • the user displays the received audio and video streams, and the application is truly free of download and installation.
  • the present application provides a system based on The cloud mobile phone application installation system of the cloud platform, as shown in FIG. 2 , the system can be deployed in the data center 130 of the public cloud in the embodiment of FIG. 1 , wherein the system can include a cloud platform 131 and a hardware resource pool 132 , wherein, 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 illustrates two cloud phones to be configured, and this application does not limit the number of cloud phones to be configured.
  • the template cloud phone 1324 and the to-be-configured cloud phone 1321 may be any of the container, virtual machine and BMS in the embodiment of FIG.
  • the network storage device 1325 is used to provide storage services, and may specifically be any of the virtual machine and the bare metal server in the embodiment of FIG. 1 .
  • the network storage device 1325 may include an object storage device 1323 and a network shared file 1322 .
  • 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 unstructured data in any quantity and form.
  • the network shared file 1323 may be a network-based file system service in a public cloud, such as an SFS service, created and obtained by the cloud platform 131 .
  • the SFS service may provide shared access for multiple servers (specifically, one or more of the foregoing virtual machines, containers, and BMSs).
  • the file system created by the SFS service may be any network file system that supports the NFS protocol, or may be a network file system such as CIFS/SMB. This application does not limit the file system type of the network shared file 1323 .
  • the template cloud phone 1324 can install multiple applications required by the user, and after generating the installation information of the 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 in the device.
  • the cloud platform 131 can also store the directory of the template cloud mobile phone in the object storage device 1323 according to the second input of the user, and the object storage device 1323 synchronizes the stored directory storage of the target cloud mobile phone to the network shared file 1323, and the network shared file 1323
  • a mount directory can be provided to at least one cloud phone to be configured, and 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 realize the startup and operation of the application, In this way, the memory occupation of cloud mobile phones is reduced, the user experience is improved, and the operation and maintenance costs of application manufacturers are reduced.
  • 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, version management, and network sharing of each application's installation information. Mapping management of file 1322, etc.
  • Fig. 2 takes the user to install 4 applications on the template cloud mobile phone, one network shared file synchronizes the installation information of 2 applications, and one network shared file provides a mount directory for a cloud mobile phone to be configured as an example to illustrate,
  • the number of applications synchronized by each network shared file can be determined according to the storage capacity of the network shared file. This application does not provide mounts for the number of applications installed on the template cloud mobile phone, the number of applications synchronized by the network shared file 1322, and the network shared file 1322. The number of cloud phones to be configured is limited.
  • one object storage 1322 can connect to multiple network shared files 1322.
  • a game manufacturer owns 100 games, and the installation information of the 100 games is all stored in the object storage 1322.
  • a network shared file can only store the installation directory and external storage directory of 50 games, then the object storage can be connected with two network shared files.
  • Network shared file A is responsible for the directory mounting of the first 50 games
  • the network shared file File B is responsible for the directory mounting of the last 50 games.
  • the network storage device shown in FIG. 2 can be divided into multiple types, and FIG. 1 is only an exemplary division method, and each module can be a software module, a hardware module, or a part of a software module. Some are hardware modules, which are not limited in this application. For example, in some application scenarios, the network storage device may only include network shared files 1322. It should be understood that if there are only a few types of applications that enterprise users need to install, there is no need to globally manage the installation information of multiple applications, such as a game.
  • 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 the cloud phone to be configured with a mount point for cataloging mount. It should be understood that the above examples are for illustration, and are not limited in the present application.
  • the updated application data can be exported to the object storage 1323 first, and then synchronized to the network shared file 1322, and the cloud phone can re-mount the updated installation information, thereby realizing the application update. Therefore, using the application installation system provided in this application, if a game manufacturer operates 1,000 games and purchases 1,000 cloud mobile phones, when one of the 1,000 games needs to be updated, the updated installation information can be exported to Object storage. Object storage synchronizes the updated installation information to the network shared file.
  • the cloud mobile phone can mount the above-mentioned updated installation information from the network shared file, so that the app's The update does not need to occupy a large amount of storage space and system resources of the cloud mobile phone, which not only reduces the operating cost of enterprise users, but also reduces the lag that is prone to occur during the startup and operation of the cloud mobile phone and the app, and improves the user experience.
  • the application installation system based on the cloud mobile phone provided by this application does not need to install the application in each cloud mobile phone, but synchronizes the installation information of the application to the network shared file, and each time the user uses the cloud mobile phone to use various applications.
  • the cloud mobile phone can mount the installation information of various applications from the network shared file, so as to realize the startup, operation and update of the application without installing the application in advance, so that the memory occupation of the app in the cloud mobile phone is reduced, which can be greatly reduced.
  • the operation and maintenance costs of application manufacturers are increased, and the startup, operation and update speed of apps are improved, and the user experience is improved.
  • the present application provides an application installation method based on a cloud mobile phone.
  • the method is applied to the application installation system shown in FIG. 2 .
  • the method includes the following steps:
  • S310 The template cloud phone 1324 installs an App, and generates installation information of the app.
  • the operating system of the template cloud mobile phone 1324 will install the data in the App installation package in the path set by the template cloud mobile phone 1324, and the generated installation information can usually include: The first installation directory and the second installation directory, where the second installation directory includes dynamic data of multiple applications, and the first installation directory includes static data of multiple applications.
  • static data refers to the running process of the App on the cloud phone
  • dynamic data refers to the data that will be modified during the running of the app.
  • the first installation directory may be an application installation directory
  • the second installation directory may be an external storage directory
  • the application installation directory stores the installation of applications such as the apk file, lib library, and oat file of the App Information
  • the path is /data/App/ ⁇ App_package ⁇
  • the data in this directory will not be modified during the running of the App
  • the external storage directory stores the running process files of the application, such as the equipment information involved in the game application, the game version, etc.
  • the path is /data/media/0/Android/data/ ⁇ App_package ⁇ , the data in this directory will be modified during the running of the App.
  • first installation directory and second installation directory are used for illustration, and the first installation directory and the second installation directory are owned by different operating systems (such as IOS operating system, Hongmeng operating system, etc.). Different paths store different installation information, and this application does not provide examples one by one.
  • 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 application installed by the enterprise user on the template cloud phone. .
  • the template cloud phone can compress and package the installation information, for example, into a tar.gz format file, and then upload it to the object storage 1322, and the object storage 1322 can decompress the received installation information and store it in the storage medium
  • 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 it is very convenient and quick to store the installation information in the user's OBS data bucket, and the object storage 1322 does not need to be re-installed. Applying to the cloud platform for storage resources can improve processing efficiency.
  • the object storage 1322 can also store installation information in other storage media, such as the OBS data bucket corresponding to the object storage 1322, which is not limited in this application.
  • 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 specifically limit the specific type of the application file storage management performed by the object storage 1322. .
  • the object storage 1322 synchronizes the installation information to the network shared file 1323 .
  • the object storage 1322 when the object storage 1322 does not yet have the corresponding network shared file 1323 (that is, when the user installs the application on the template cloud phone for the first time), or the current object storage remaining storage space is insufficient, the object storage can First, a request for creating a network shared file 1323 is sent to the cloud platform 131. After the cloud platform 131 creates a network shared file 1323, Object Storage sends the installation information to the network shared file 1323, and records the connection between the installation information and the network shared file 1323. corresponding relationship.
  • the object storage 1322 After 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 according to the corresponding relationship, and then send the updated version of the installation information to the corresponding network shared file 1323 to realize Updates to 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.
  • the cloud mobile phone 1321 to be configured accesses the installation information by mounting the network shared file, so as to realize the startup, operation and update of the application.
  • the network shared file can provide a mounting directory (mounting point), such as /data/share_app_center, to the cloud phone 1321 to be configured, so that the cloud phone to be configured can access the installation information in the network shared file 1323 through the mounting directory, and realize application Start and run, thereby reducing the memory usage of the cloud phone, improving the user experience, and reducing the operation and maintenance cost of application manufacturers.
  • This application provides two methods for the cloud phone to be configured to share the installation information in the file 1323 by mounting the network to realize the startup, operation and update of the App. The two methods are explained in detail below.
  • the installation information generated after the App is installed on the mobile phone includes a first installation directory and a second installation directory.
  • the first installation directory will not be modified, and will be generated during the running process.
  • the modified data will be written to the second installation directory, so the cloud phone 1321 to be configured can mount the first installation directory from the network shared file in read-only mode, and then write the modified data through the first multi-layer file system. Enter the second installation directory, so as to realize the startup and operation of the App in the cloud phone 1321 to be configured.
  • the first multi-level file system may include at least an upper-level directory and a lower-level directory, wherein the lower-level directory is the second installation directory in the network shared file 1233, the upper-level directory is used to store modified data, and the first multi-level file system will upload After the directory and the lower-level directory are combined, during the running of the App, the operating system can read and write the second installation directory by accessing the first multi-layer file system, thereby realizing the running of the App in the cloud phone 1321 to be configured.
  • the above-mentioned modified data can be the log-in 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, which can be modified according to the application scenario to determine the applicable preset directory structure. The storage of data is not limited in this application.
  • 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, and in the installation information of the App, the first installation directory It is the application installation directory 1, and the second installation directory is the external storage directory 1.
  • the operating system will access the application installation directory 1' or the external storage directory 1', where the application installation directory 1' starts with
  • the application installation directory 1 in the network shared file 1322 is mounted in read-only mode, and the external storage directory 1' is a composite directory of the upper directory and the lower directory.
  • the lower directory can be realized by mounting the external storage directory 1, and the upper directory is a
  • the directory structure is preset, and the stored data is the modified data generated during the running of the App, so as to realize the running of the App in the cloud phone 1321 to be configured.
  • the cloud phone 1 to be configured and the cloud phone 2 to be configured can be configured.
  • the installation information in the network shared file 1322 is respectively mounted to implement the installation of the application.
  • the cloud phone 1 to be configured and the cloud phone 2 to be configured are both deployed with their respective first multi-layer file systems, and are respectively connected to the application installation directory 1 in the network shared file in a read-only manner, and then respectively through their respective first multi-layer file systems.
  • the multi-layer file system realizes reading and writing to the external storage directory 1, and completes the installation of the application.
  • the upper-layer directory of the first multi-layer file system is used to store the modified data generated during the operation of the respective applications, and the lower-layer directory is connected in a read-only manner.
  • Application installation directory 1 in the network shared file it should be understood that the content not described in FIG. 4B can refer to the embodiment of FIG. 4A, which will not be repeated here, and the above examples are used for illustration. The number of applications is limited.
  • the above-mentioned first multi-layer file system can be realized by the overlay file system, and the read-only mode can be through a soft connection.
  • the first installation directory in the network shared file is mapped to the cloud phone to be configured, so that the When the cloud phone requests to access the first installation directory, it will jump to the first installation directory stored in the network shared file through the network, so that the installation information in the application installation directory can be obtained from the network shared file in a read-only manner .
  • the above-mentioned method combining the first multi-layer file system and the read-only method to mount the network shared file can not only ensure the reading and writing of data during the running process of the App, but also realize the startup and operation of the App on the cloud phone to be configured. Running, you can also update the App by re-mounting the installation information of the new version.
  • 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 1321 to be configured (of course, the mount directory can also be kept unchanged, but only the installation information in the mount directory is updated). Download the directory, and re-mount the new version installation information in the network shared file 1322 to update the App.
  • the cloud phone 1321 to be configured when it re-mounts the installation information of the new version, it can re-mount the first installation directory in a read-only manner, realize the read operation on the first installation directory, and access the updated first installation directory.
  • the layer file system implements read and write operations on the second installation directory, so as to realize the startup and operation of the updated App.
  • the updated first multi-layer file system re-synthesizes the updated upper-level directory and the updated lower-level directory, the updated lower-level directory mounts the updated second installation directory in the network shared file 1322, and the updated The upper directory uses a new preset directory (or still uses the previous preset directory, but clears the modified data in this directory), and the modified data generated when the app runs and starts after the update can be written into the updated upper directory. , so as to start and run the updated App.
  • the above-mentioned method combining the first multi-layer file system and the read-only method for file mounting 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.
  • the object storage and the network shared file can delete the installation information corresponding to the App, thereby realizing the uninstallation of the App.
  • Using this method to uninstall apps eliminates the need to uninstall applications for each cloud phone, reduces the resource scheduling pressure for enterprise users when managing cloud phones, and improves the efficiency of app uninstallation on cloud phones.
  • each cloud mobile phone does not need to install the application in advance, which not only reduces the memory occupation of the cloud mobile phone, but also improves the startup and performance of the App.
  • the operation efficiency is improved, and at the same time, the resource scheduling pressure required by enterprise users to install, update and uninstall applications when managing cloud mobile phones is reduced, reducing operating costs.
  • the modified data generated by the cloud phone to be configured during the running of the App can be sent to the network shared file, and the network shared file can perform read and write operations on the first installation directory and the second installation directory, and the read and write operations are performed.
  • the pressure of the cloud mobile phone to be configured is concentrated in the network shared files, which reduces the processing pressure of the cloud mobile phone to be configured during the app running process, improves the running efficiency of the cloud mobile phone app to be configured, and thus improves the user experience.
  • the above-mentioned second multi-layer file system can be deployed in the network shared file, the second multi-layer file system can mount the installation information, and the cloud mobile phone to be configured can send the modified data generated during the running of the App to
  • the network shared file reads and writes the installation information through the second multi-layer file system by the network shared file.
  • the above-mentioned second multi-layer file system can be realized by the Overlay file system,
  • 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.
  • the first installation directory is the application installation directory 1
  • the second installation directory is the external storage directory 1.
  • the network shared file 1322 can first create a blank directory 1 with the 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 , and then the network shared file 1322 creates a copy directory according to 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 on the in the copy directory.
  • the cloud phone to be configured can read data from the blank directory 1 on which the copy directory is mounted, and write the generated modified data through the second multi-layer file system of the blank directory 1 The blank directory 1.
  • the copy directory can be updated according to the updated installation information, and then the blank directory can be re-mounted in the updated copy directory.
  • the installation information To delete the copied directory, it should be understood that the data in the blank directory is empty when it is created, and after it is mounted on the copied directory, the data in the blank directory is no longer empty.
  • the installation information is mounted, so that each cloud phone does not need to install the application in advance, and realizes the startup, operation, update and uninstallation of the App, which not only reduces the cost of The memory usage of cloud mobile phones is reduced, which improves the efficiency of app startup and operation, and also reduces the resource scheduling pressure required by enterprise users to install, update and uninstall applications when managing cloud mobile phones, reducing operating costs.
  • FIG. 5B when the number of cloud phones to be configured is multiple (FIG. 5B takes the installation of the same application on two cloud phones to be configured as an example), the cloud phone 1 to be configured and the cloud phone 2 to be configured can be configured.
  • Mounting the network shared files 1322 respectively implements the installation of the application.
  • a plurality of second multi-layer file systems are deployed in the network shared file 1322 (that is, the blank directory 1 and the blank directory 2 in FIG. 5B ), which correspond to different cloud phones to be configured, that is, the cloud phone to be configured 1 is mounted In the blank directory 1, 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.
  • FIG. 5B may refer to the embodiment in FIG. 5A , which will not be repeated here, and the above examples are used for illustration, and this application does not limit the number of cloud phones to be configured and the number of applications.
  • the network shared file can be deployed with a server, and the cloud phone to be configured can be deployed with a client, where the client is used to read and write IO requests generated by the cloud phone to be configured (for example, modify the data generated during the running process of the App).
  • the request to write to the external storage directory, the request to read the application installation directory, etc.) is sent to the server of the network shared file, and the server is used to receive the above-mentioned read and write IO request sent by the client and send it to the second Multi-layer file system, the second multi-layer file system realizes the read and write operations of installation information, and then realizes the remote mounting and installation information of the cloud mobile phone to be configured, so that each cloud mobile phone does not need to install the application in advance, and realizes the startup of the App , running, updating and uninstalling, not only reduces the memory usage of cloud mobile phones, improves the efficiency of app startup and operation, but also reduces the resource scheduling required by enterprise users to install, update and uninstall applications when managing cloud mobile phones pressure and reduce operating costs.
  • 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 makes the network shared file more stressful.
  • the IO requests in the cloud phone can be sent to the client. After the client aggregates the received IO requests, it is sent to the server for processing, thereby reducing the number of IO requests received by network shared files and reducing the number of network shared files. Handle stress and improve the efficiency of app launches, runs, updates, and uninstalls.
  • the network shared file can first cache the received IO request in the memory. After receiving the IO request sent by the cloud phone to be configured, the data in the cache is updated first, and then the asynchronous IO request is generated. . Then aggregate the IO requests of a large number of small files into a single IO request, and send the aggregated IO data to the server at one time. The server can parse the received IO requests and then update them to the storage medium in batches.
  • user data will also be generated during the running of the App.
  • the user data may be the running process of the App.
  • Personal business data and personal habit data generated locally in China for example, if the app is a game app, for example, the user data of a mobile game app may include the user's default account information, historical login area server information, etc., and the user data of a stand-alone game app.
  • the app can include game clearance records, game character data, etc.; if the app is an office app, for example, the user data of the mailbox app can include the user's mailbox account binding information, mailbox card settings, etc., and the user data of the office communication app can include User historical chat records, user historical account information, user historical file information, business data, etc., it should be understood that user data may also include other types of personal data generated by the user during the running of the App, which will not be illustrated here.
  • the cloud phone used by the user is a cloud phone on the public cloud in the geographical area where the user is located. For example, if the user is currently in North China, the cloud phone used by the user and the network shared files If it belongs to the North China data center, and the user is currently in the South China region, the cloud phone and network shared files used by the user belong to the South China data center. Usually, data between data centers cannot be communicated, or high costs are required to realize data communication.
  • the above method is used for App management, and when the user's geographic location changes , user data can be quickly synchronized from the historical network shared files to the current network shared files, so as to avoid user data loss due to changes in the user's geographic location, reduce maintenance costs, and improve user experience.
  • FIG. 6 it is assumed that when user A is working in Beijing (North China), user A runs an office app using cloud phone 1 and network shared file 1 in the data center in North China, and then user A travels to Shenzhen for office. (South China), at this time, the object storage device can send a request to create a network shared file 1' to the South China data center, and then synchronize the installation information of the office App to the network shared file 1', and the network shared file 1 will send user A in Beijing
  • the user data generated during the office is quickly synchronized to the network shared file 1', so that the cloud phone 1' mounted on the network shared file 1' can keep the user data while the app is running, and the user does not need to re-enter the account password, Download business data, etc., to improve user experience.
  • the cloud mobile phone that the user is using may migrate cloud mobile phone resources from time to time due to various reasons.
  • Using the above method for App management can reduce the time required for cloud mobile phone resource migration, while ensuring that the cloud mobile phone resource is expensive. In the future, user data will not be lost, improving user experience.
  • the cloud mobile phone resource migration refers to the migration of the cloud mobile phone that the user is using from one server to another server.
  • resource occupancy rate of the server where the cloud mobile phone that the user is using is high. In order to avoid the cloud mobile phone from being stuck, the cloud mobile phone that the user is using can be migrated to another resource occupancy rate.
  • the usage requirements have changed.
  • the user has only installed office apps before, and the configuration of the cloud phone is low.
  • the cloud mobile phone used by the user at this time can also be migrated from one server to another server.
  • the above-mentioned reasons for resource migration are used for illustration and are not limited in this application.
  • the above method is used for App management.
  • the entire migration process is based on the method of mounting network shared files, there is no need for redundant steps such as application installation or data synchronization on the migrated cloud mobile phones.
  • the mobile phone resource migration will be shortened to a few seconds, improving the user experience.
  • the network shared files mounted on the migrated cloud mobile phone are the same as the cloud mobile phone before the migration, the user data after the cloud mobile phone resource migration can still be retained. , the user does not need to re-enter the account password, re-download business data, etc., to further improve the user experience.
  • the cloud phone 2 can be stopped first, and then the mount between the cloud phone 2 and the network shared file can be canceled, and then the The server 2 creates a cloud phone 2', and provides the mount directory on the network shared file to the cloud phone 2', and the cloud phone 2' mounts the network shared file through the mount directory, so as to quickly realize the resources of the cloud phone Migration to improve user experience.
  • the present application provides two methods for implementing application startup, running, updating and uninstallation by mounting network shared files on the cloud mobile phone to be configured, that is, by deploying a second multi-layer file system in the cloud mobile phone to be configured, to implement file mounting.
  • the above two methods are used for illustration, and in the specific implementation, the file mounting can also be realized by other methods, which is not described in this application. limited.
  • the cloud platform automatically executes steps S310 to S340 for the user to implement the application installation of at least one cloud mobile phone to be configured.
  • the solution provided by this application can also be implemented by the cloud platform according to the configuration requirements input by the user.
  • the user can manually set the object storage device, share network files, and the cloud phone to be configured through the console or API, etc., as shown in Figure 8
  • the cloud platform implements the application installation of the cloud mobile phone to be configured according to the user input is explained below.
  • the cloud platform 131 provides the user with a cloud phone configuration interface, where the cloud phone configuration interface is used to configure the template cloud phone according to the user's first input, the template cloud phone is set with multiple applications, and the template cloud phone catalog records multiple applications installation information.
  • the first input of the user may include an App installation package, an update package, the performance configuration information of the template cloud phone, etc. to be installed by the user
  • the cloud phone configuration interface may be a console (console) or an application program interface ( application program interface, API)
  • the console can be an application or web page for users to purchase cloud services and configure cloud services.
  • users can purchase template cloud mobile phones through the website of the cloud platform, and upload them in the template cloud mobile phones and need to be installed. It should be understood that the above examples are for illustration and are not specifically limited in this application.
  • the cloud platform 131 provides the user with a network shared file configuration interface, and the network shared file configuration interface is used to store the directory of the template cloud phone in the network shared file according to the second input of the user.
  • the method before providing the network shared file configuration interface, further includes: providing an object storage interface, where the object storage interface is used to obtain the directory of the template cloud mobile phone according to the fourth input of the user and store the directory of the template cloud mobile phone in the object
  • the network shared file configuration interface is used for synchronizing the directory storage of the template cloud mobile phone stored in the object storage device to the network shared file according to the second input of the user.
  • the user's fourth input may be an instruction to synchronize the network shared file with the object storage device
  • the cloud platform may 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 second input of the user may be to associate the object storage device with the network shared file
  • the object storage device in the embodiment of FIG. 2 is associated with the network shared file 1 and the network shared file 2, wherein each network shared file storage 2 installation information for each application.
  • the method further includes the following steps: providing 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.
  • the seventh input may be an instruction to create an object storage device and configuration information for the object storage device, such as storage capacity of the object storage device, storage directory of the object storage device, and the like.
  • 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 an API command to create an object storage device. For example, the OBS data bucket in the cloud service is used as the object storage device. The directory of the mobile phone is stored.
  • the API instruction for creating the object storage device (the fifth input by the user) can be as follows:
  • the object storage device to be used is created, and then the directory of the template cloud phone can be packaged and compressed (for example, compressed into tar.gz) and uploaded to the above-mentioned OBS data bucket.
  • the interface is a console in the form of a web page or an application program, exemplarily, as shown in Figure 9, 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. For North China Data Center, select the name of the created object storage device as Object Storage Device 1, select the storage type of the object storage device as Standard Storage, etc. Users can drag and drop local files to the "Upload Object" column for storage, or You can click the icon to add a file, import the directory of the template cloud phone into the object storage device, and finally click the upload button to complete the creation of the object storage device 1 and the storage of the directory of the template cloud phone.
  • the configuration content shown in Figure 9 can be are the fifth and seventh input of the user. It should be understood that the console interface shown in FIG. 9 is used for illustration, and is not limited in this application.
  • the method provided by the present application further includes: providing a network shared file creation interface, where the network shared file creation interface is used to create the network shared file according to the sixth input of 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 storage capacity of the network shared file, file system type, etc., which are not specifically limited in this application.
  • the cloud platform 131 provides the user with an interface for creating a network shared file.
  • the interface is an API interface
  • the user can use the API command to create a network shared file, such as an instance of the SFS service in the cloud service, and then store the above OBS data bucket.
  • the directory of the cloud phone in the template is synchronized to the SFS instance.
  • the API instruction (the user's sixth input) to create a network shared file may be as follows:
  • the SFS instance created by 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.
  • the console can show the user some configuration options for creating network shared files, such as configuring the data center where the network shared files are located.
  • the console interface shown in FIG. 10 is used for illustration, and is not limited in this application.
  • the cloud phone configuration interface is further configured to configure at least one cloud phone to be configured to mount a network shared file according to a third input of the user to complete the installation of multiple applications.
  • the cloud phone configuration interface is an API interface
  • the user can use the API command 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.
  • the above API command (the user's third input) can be as follows:
  • the present application provides two mounting methods to implement the above-mentioned at least one cloud mobile phone to be configured to mount a network shared file to complete the installation of multiple applications.
  • the two mounting methods are described below. Explain.
  • the static data is connected in a read-only manner, and the multi-layer file system is used to read and write the dynamic data, so as to realize the template cloud.
  • the mobile phone directory is mounted to complete the installation, operation and startup of the application.
  • 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 third input of the user; the cloud phone configuration interface is also used to The first multi-layer file system is configured on at least one cloud phone to be configured according to the third input of the user, and the first multi-layer file system is used for at least one cloud phone to be configured to read and write operations to the second installation directory, wherein the first The multi-layer file system includes an upper-level directory and a lower-level directory, the lower-level directory is used to connect the second installation directory in a read-only mapping manner, and the upper-level directory is used to store the modification data generated during the running of at least one application installed in the cloud phone to be configured, The first multi-level file system is used to superimpose the upper directory and the lower directory.
  • the above-mentioned third input may include connecting the cloud mobile phone to be configured to the first installation directory in the first network shared file in a read-only manner.
  • the instruction may also include an instruction to set the first multi-layer file system in the cloud phone to be configured, and may also include storing and modifying data in the upper-level directory in the first multi-level file system, and softly linking the lower-level directory with the first installation directory. instruction.
  • the cloud phone configuration interface is an API interface
  • the user can use the API command 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.
  • the API command for the cloud phone to connect to the first installation directory in read-only mode can be as follows:
  • the user can execute ls to view the connection relationship between the cloud phone to be configured and the first installation directory, and the display is similar to the following:
  • Deploy the first multi-layer file system 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 connection between the lower directory and the second installation directory can be as follows:
  • the second installation directory is set as the lower directory (that is, the lowerdir in the above command) to connect with the cloud phone to be configured in a read-only manner, and the upper directory (that is, the upperdir in the above command) is used to store the modified data.
  • a multi-layer file system superimposes the upper and lower directories to complete the application installation of the cloud phone to be configured. It should be understood that the above-mentioned API instructions are used for illustration, and are not limited in this application.
  • the user can also use an API command to register the mounted application in the operating system of the cloud phone to be configured, and the application icon is displayed on the cloud phone to be configured, and the user can click the icon to start the application.
  • the API command to register the application to the cloud phone operating system to be configured can be as follows: "#bash quick-reg.sh/data/app/ ⁇ app_package ⁇ ". It should be understood that the above API commands are used for illustration and are not specifically limited in this application.
  • the cloud platform can receive an instruction input by the user through the console or API to update the application.
  • the user can first update the application in the template cloud mobile phone to generate an update.
  • the directory of the target cloud phone after being updated, and then compressed and packaged and uploaded to the object storage device.
  • the object storage device synchronizes the directory of the updated template cloud phone to the shared network file, and the cloud phone to be configured can be remounted by remounting the cloud phone to be configured.
  • the API for re-mounting the first installation directory in read-only mode on the cloud phone to be configured may be as follows:
  • the API for the cloud phone to be configured to re-use the first multi-layer file system to mount the second installation directory can be as follows:
  • the application update is completed.
  • the new version of the application can be installed on the template cloud mobile phone, and there is no need to update the application of all cloud mobile phones purchased by the user, so that the application update efficiency is improved, thereby improving the user's use. experience.
  • a second multi-layer file system can also be deployed in the network shared file, the static data is connected in a read-only manner, and the multi-layer file system is used to read and write the dynamic data, thereby realizing the template cloud.
  • the mobile phone directory is mounted to complete the installation, operation and startup of the application.
  • 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 third input of the user; the network shared file configuration interface is also used
  • the second multi-layer file system is configured to share files on the first network according to the user's third input, and the second multi-layer file system is used to receive and process at least one data read and write request sent by the cloud phone to be configured, wherein the second multi-layer file system is The layer file system includes an upper-level directory and a lower-level directory, the lower-level directory is used to connect the second installation directory in a read-only mapping manner, the upper-level directory is used to store the modified data generated during the running of the application installed in the first network shared file, and the second A multi-layer file system is used to overlay upper and lower directories.
  • a blank directory 1 with the above-mentioned second multi-layer file system built-in can be created in the network shared file, and mounted to the cloud to be configured.
  • the mobile phone serves as the root directory of its data disk, and then creates a copy directory according to the installation information downloaded from the object storage.
  • the directory structure and data in the copy directory are the same as those in the installation information, and blank Directory 1 hangs in this copy directory.
  • the cloud phone to be configured can read data from the blank directory 1 on which the copy directory is mounted, and write the generated modified data through the second multi-layer file system of the blank directory 1
  • the blank directory 1 For example, when the network shared file configuration interface is an API interface, exemplarily, 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:
  • the cloud mobile phone C1 to be configured can be mounted to the network shared file to implement the installation, operation and update of the application.
  • the network shared file uses the second most common file.
  • the method for implementing the application update by the layer file system is similar to the method for implementing the application update using the first multi-layer file system on the cloud phone to be configured above, and the API for the application update will not be repeatedly described here.
  • 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 the first cloud phone in the at least one cloud phone to be configured is located in the first data center.
  • the network sharing file configuration interface is also used to create a second network sharing file located in the second data center according to the fifth input of the user, and the second network sharing file is located in the second data center.
  • the network share is a mirror image of the first network share.
  • the network shared file configuration interface is further configured to, according to the sixth input of the user, configure the first cloud phone to be configured migrated to the first data center to mount the second network shared file to complete the installation of multiple applications.
  • 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 second network shared file, so that the user can When the geographic location changes, user data will not be lost, and the user experience will be improved.
  • the above process may refer to the embodiment in FIG. 6 for details, which will not be repeated here.
  • the network shared file configuration interface is used to configure the to-be-configured server on the second server.
  • the cloud phone mounts network shared files to complete the installation of multiple applications, shortens the migration time of the cloud phone to be configured in the same data center to seconds, and improves the user experience of the cloud phone.
  • 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, and the cloud platform automatically creates template cloud phones, network shared files and cloud phones according to the number of applications and the application list uploaded by the user.
  • Object storage device, and install the applications in the above application list on the template cloud phone then export the directory of the template cloud phone to the object storage device, synchronize the installation information in the object storage device with the network shared file, and configure x-1 cloud
  • the mobile phone is mounted on the network shared file to implement x-1 applications in the cloud mobile phone installation application list, and the template cloud mobile phone is included to achieve the purpose of x applications in the cloud mobile phone installation application list. The operation is very convenient and improves the user experience.
  • the application installation method based on cloud mobile phone does not need to install the application in each cloud mobile phone, but synchronizes the installation information of the application to the network shared file, and the cloud mobile phone can mount each cloud mobile phone from the network shared file.
  • the installation information of various applications so as to realize the startup, operation and update of the application without installing the application in advance, reduce the memory usage of the cloud mobile phone, reduce the operation and maintenance cost of the cloud mobile phone, and at the same time, the startup, operation and update speed of the app can be improved. Improve, improve the user experience.
  • the present application provides a cloud platform 131, including a cloud mobile 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 an The network shared file configures the interface unit 1150 .
  • a cloud phone configuration interface unit 1110 is provided for providing a cloud phone configuration interface.
  • the cloud phone configuration interface is used to configure the template cloud phone according to the user's first input.
  • the template cloud phone is provided with multiple applications, and the template cloud phone has multiple directory records.
  • the installation information of each application is provided;
  • the network shared file configuration interface unit 1150 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 second input of the user ; wherein, the cloud phone configuration interface is further configured to configure at least one cloud phone to be configured to mount the first network shared file according to the third input of the user to complete the installation of multiple applications.
  • 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 mobile phone according to the fourth input of the user and store the directory of the template cloud mobile phone in the object storage device
  • the providing unit is used for providing the object storage interface;
  • the network shared file configuration interface is used for synchronizing the directory storage of the template cloud mobile phone stored in the object storage device to the first network shared file according to the second input of the user.
  • 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 configuration interface is also used to configure at least one cloud mobile 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 configuration interface of the cloud mobile phone is also used to configure according to the third input of the user.
  • a first multi-layer file system is configured on at least one cloud phone to be configured, 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 layer directory and lower-level directory, the lower-level directory is used to connect the second installation directory in a read-only mapping manner, the upper-level directory is used to store the modified data generated during the running of at least one application installed in the cloud phone to be configured, and the first multi-layer file system Used to overlay upper and lower directories.
  • 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 The 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 third input of the user;
  • the first network shared file configures a second multi-layer file system, 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-layer directory and a lower-layer file system.
  • Directory the lower directory is used to connect the second installation directory in a read-only mapping manner
  • the upper directory is used to store the modified data generated during the running of the application installed in the first network shared file
  • the second multi-layer file system is used to superimpose the upper layer. directory and subdirectories.
  • the first network shared file is located in the first data center, and in the case where 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 file located in the second data center according to the fifth input of the user.
  • the network shared file configuration interface is used to configure the to-be-configured server on the second server.
  • the cloud phone mounts network shared files to complete the installation of multiple applications.
  • a network shared file creation interface unit 1140 is provided for providing a network shared file creation interface, and the network shared file creation interface is used to create a network shared file according to the sixth input of the user.
  • an object storage creation interface unit 1120 is provided, which is used for providing an object storage creation interface, and the object storage creation interface is used for creating an object storage according to the seventh input of the user.
  • the cloud platform provided by this application does not need to install the application in each cloud mobile phone when installing the application on the cloud mobile phone, but synchronizes the installation information of the application to the network shared file, and the cloud mobile phone can share files from the network.
  • Mount the installation information of various applications so as to realize the startup, operation and update of the application without installing the application in advance, so that the memory occupation of the App in the cloud phone is reduced, which can greatly reduce the operation and maintenance cost of the cloud phone.
  • the speed of startup, operation and update of the mobile phone is improved, and the user experience is improved.
  • FIG. 12 is a schematic structural diagram of a computing device 1200 according to an embodiment of the present application.
  • the computing device 1200 may be the cloud platform 131 in the embodiments of FIG. 1 to FIG. 11 .
  • 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 the internal bus 1240, and can also communicate through other means such as wireless transmission.
  • the embodiment of the present application takes the connection through the bus 1240 as an example, and the bus 1240 may be a peripheral component interconnect standard (Peripheral Component Interconnect, PCI) bus or an Extended Industry Standard Architecture (Extended Industry Standard Architecture, EISA) bus or the like.
  • PCI peripheral component interconnect standard
  • EISA Extended Industry Standard Architecture
  • the bus 1240 can be divided into an address bus, a data bus, a control bus, and the like. For ease of representation, only one thick line is shown in FIG. 12, but it does not mean that there is only one bus or one type of bus.
  • the processor 1210 may be composed of at least one general-purpose processor, such as a central processing unit (Central Processing Unit, CPU), or a combination of a CPU and a hardware chip.
  • the above-mentioned hardware chip may be an application-specific integrated circuit (Application-Specific Integrated Circuit, ASIC), a programmable logic device (Programmable Logic Device, PLD) or a combination thereof.
  • the above-mentioned PLD can be a complex programmable logic device (Complex Programmable Logic Device, CPLD), a field programmable gate array (Field-Programmable Gate Array, FPGA), a general array logic (Generic Array Logic, GAL) or any combination thereof.
  • Processor 1210 executes various types of digitally stored instructions, such as software or firmware programs stored in memory 1230, which enable computing device 1200 to provide a wide variety of services.
  • the memory 1230 is used for storing program codes, and is controlled and executed by the processor 1210 to execute the processing steps of the cloud mobile phone management node 310 in any of the embodiments in FIG. 2 to FIG. 10 .
  • One or more software modules may be included in the program code.
  • the one or more software modules may be software modules provided in the embodiment shown in FIG. 12 , such as providing a cloud mobile phone configuration interface unit, providing a network shared file configuration interface unit 1150, etc., wherein the cloud mobile phone configuration interface unit is provided for Provides a cloud phone configuration interface.
  • the cloud phone configuration interface is used to configure the template cloud phone according to the first input of the user.
  • the template cloud phone is set with multiple applications, and the directory of the template cloud phone records the installation information of multiple applications; provides network sharing files
  • the configuration interface unit is used to provide a network shared file configuration interface, and the network shared file configuration interface is used to store the directory of the template cloud mobile phone to the first network shared file according to the second input of the user, which can be specifically used to perform steps S310 to S310 of the foregoing method.
  • S340 , steps S410 to S440 and their optional steps may also be used to perform other steps performed by the cloud platform 131 described in the embodiments of FIG. 3 to FIG. 10 , which will not be repeated here.
  • this embodiment may be implemented by a general-purpose physical server, for example, an ARM server or an X86 server, or may be implemented by a virtual machine based on a general-purpose physical server combined with the NFV technology.
  • a general-purpose physical server for example, an ARM server or an X86 server
  • a virtual machine based on a general-purpose physical server combined with the NFV technology.
  • the simulated complete computer system with complete hardware system functions and running in a completely isolated environment is not specifically limited in this application.
  • the memory 1230 may include a volatile memory (Volatile Memory), such as a random access memory (Random Access Memory, RAM); the memory 1030 may also include a non-volatile memory (Non-Volatile Memory), such as a read-only memory ( Read-Only Memory (ROM), flash memory (Flash Memory), hard disk (Hard Disk Drive, HDD) or solid-state drive (Solid-State Drive, SSD); the memory 1230 may also include a combination of the above types.
  • the memory 1230 may store program codes, and may specifically include program codes for executing other steps described in the embodiments of FIG. 3 to FIG. 10 , which will not be repeated here.
  • the communication interface 1220 may 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 using a wireless local area network interface) to communicate with other devices or modules.
  • a wired interface such as an Ethernet interface
  • PCIe Peripheral Component Interconnect express
  • FIG. 12 is only a possible implementation manner of the embodiment of the present application.
  • the computing device may further include more or less components, which is not limited here.
  • the relevant descriptions in the embodiments described in the foregoing FIG. 3 to FIG. 10 and details are not repeated here.
  • the computing device shown in FIG. 12 may also be a computer cluster composed of at least one server, which is not specifically limited in this application.
  • Embodiments of the present application further provide a computer-readable storage medium, where instructions are stored in the computer-readable storage medium, and when the computer-readable storage medium runs on a processor, the method flow shown in FIG. 3 to FIG. 10 is implemented.
  • the embodiments of the present application further provide a computer program product, when the computer program product runs on a processor, the method flow shown in FIG. 3-FIG. 10 is implemented.
  • the above embodiments may be implemented in whole or in part by software, hardware, firmware or any other combination.
  • the above-described embodiments may be implemented in whole or in part in the form of a computer program product.
  • the computer program product includes at least one computer instruction.
  • the computer may be a general purpose computer, special purpose computer, computer network, or other programmable device.
  • the computer instructions may be stored in or transmitted from one computer readable storage medium to another computer readable storage medium, for example, the computer instructions may be downloaded from a website site, computer, server or data center Transmission to another website site, computer, server or data center by wired (eg coaxial cable, optical fiber, Digital Subscriber Line, DSL) or wireless (eg infrared, wireless, microwave, etc.) means.
  • the computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server, a data center, or the like containing at least one set of available media.
  • the available media may be magnetic media (eg, floppy disks, hard disks, magnetic tapes), optical media (eg, Digital Video Disc (DVD), or semiconductor media.
  • the semiconductor media may be SSDs.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本申请提供了一种基于云手机的应用安装方法、云平台及相关设备,该方法包括以下步骤:云平台向用户提供云手机配置接口,根据用户的第一输入配置模板云手机,云平台再向用户提供网络共享文件配置接口,根据用户的第二输入将上述模板云手机的目录存储至第一网络共享文件,再根据用户的第三输入配置至少一个待配置云手机挂载第一网络共享文件以完成多个应用的安装。使得云平台无需提前为每一台云手机安装,云手机通过挂载网络共享文件实现应用安装、更新和卸载,降低云手机的存储空间占用,降低云手机的运营维护成本,同时提高应用的启动、运行和更新速度,提高用户的使用体验。

Description

基于云手机的应用安装方法、云平台及相关设备 技术领域
本发明涉及云计算技术领域,尤其涉及一种云服务的资源发放方法及相关设备。
背景技术
云手机(cloud phone)是一种带有操作系统且具有虚拟手机功能的云服务器。云手机对物理手机起到了非常好的延伸和拓展作用,可以应用在如云手游、移动办公等场景。在这些应用场景中,应用(Application,App)将安装于云手机中,App使用者可通过个人终端设备远程连接云手机,云手机将应用运行过程中渲染出的音视频画面通过音视频流的形式传输到终端设备,终端设备将接收到的音视频流显示在屏幕上,使得App使用者可以使用图像处理与数据运算能力相对有限、甚至是只有流媒体播放能力的终端设备来使用对硬件资源要求较高的App。
与物理手机使用方式不同的是,云手机中的App,一般由购买了云手机服务的用户管理。如果某用户购买1000部云手机,每个云手机可提供100种App,那么每个云手机都需要安装100种App,如果每个App的安装大小为1GB(实际很可能会超过1GB),那么一台云手机就需要100GB的存储空间,1000部云手机则需要100T的存储空间,其中任何一款App更新也会占用大量的存储空间,使得游戏厂商的运营和维护成本过高,同时,安装100种App的云手机在开机和App运行过程中更容易出现卡顿,降低用户的云手机使用体验。
发明内容
本申请提供了一种基于云手机的应用安装方法、云平台及相关设备,用于解决海量云手机安装和更新应用时,占用大量存储空间、运营维护成本高、且应用运行过程中容易出现卡顿的问题。
第一方面,提供了一种基于云手机的应用安装方法,该方法包括以下步骤:云平台向用户提供云手机配置接口,根据用户的第一输入配置模板云手机,云平台再向用户提供网络共享文件配置接口,根据用户的第二输入将上述模板云手机的目录存储至第一网络共享文件,再根据用户的第三输入配置至少一个待配置云手机挂载第一网络共享文件以完成多个应用的安装。
其中,至少一个待配置云手机可例如为1个待配置云手机或多个待配置云手机,在实际应用中,基于运行云手机的物理服务器的硬件配置,本发明实施例可以支持1-1000个以上待配置云手机同时安装多个应用。
实施第一方面描述的方法,云平台在对海量云应用进行应用安装和更新时,无需在每一个云手机中安装应用,待配置云手机可从网络共享文件挂载各种应用的安装信 息,从而在不提前安装应用的情况下,实现应用的启动、运行和更新,进而降低云手机存储空间的占用,降低云手机的运营维护成本,同时App的启动、运行和更新速度得以提升,提高用户的使用体验。
在第一方面的一种可能的实施方式中,提供网络共享文件配置接口之前,云平台还可向用户提供对象存储接口,根据用户的第四输入获取模板云手机的目录并将模板云手机的目录存储至对象存储设备中,云平台还可通过网络共享文件配置接口,根据用户的第二输入将对象存储设备存储的模板云手机的目录存储同步到第一网络共享文件。
可选地,在提供网络共享文件配置接口之前,该方法还可包括以下步骤:提供网络共享文件创建接口,网络共享文件创建接口用于根据用户的第六输入创建网络共享文件。
可选地,提供对象存储接口之前,该方法还可包括以下步骤:提供对象存储创建接口,对象存储创建接口用于根据用户的第七输入创建对象存储。
实施上述实现方式,模版云手机的目录先导出至对象存储设备中,再由对象存储设备将模版云手机的目录同步至网络共享文件,其中,对象存储设备的存储容量较大,网络共享文件的存储容量较小,因此可以使用多个网络共享文件分别同步对象存储设备中的安装信息,从而提高用户可安装应用的数量,并且,对象存储设备还可对模板云手机导出的安装信息进行管理,比如记录该安装信息的存储路径、版本信息、对应的用户信息、应用名称、类型等等,进一步提高安装效率。
本申请提供了两种方式实现待配置云手机对网络共享文件的挂载,下面分别对两种实现方式进行解释说明。
在第一方面的一种可能的实施方式中,可通过在待配置云手机中配置第一多层文件系统,实现对网络共享文件的挂载,具体地,第一网络共享文件包括第一安装目录和第二安装目录,其中,第二安装目录包括多个应用的动态数据,第一安装目录包括多个应用的静态数据;云手机配置接口,还用于根据用户的第三输入配置至少一个待配置云手机以只读方式连接第一网络共享文件中的第一安装目录;云手机配置接口,还用于根据用户的第三输入在至少一个待配置云手机配置第一多层文件系统,第一多层文件系统用于供至少一个待配置云手机对第二安装目录进行读写操作,其中,第一多层文件系统包括上层目录和下层目录,下层目录用于以只读映射的方式连接第二安装目录,上层目录用于存储至少一个待配置云手机中安装的应用运行过程中生成的修改数据,第一多层文件系统用于叠加上层目录和下层目录。
具体实现中,上述第一多层文件系统可通过Overlay文件系统实现,只读方式可以是通过软连接的方式,将网络共享文件中的第一安装目录映射至云手机中,使得云手机请求访问第一安装目录时,将会通过网络跳转到网络共享文件中存储的第一安装目录中,从而实现以只读方式从网络共享文件中挂载获得应用安装目录下的安装信息。
实施上述实现方式,待配置云手机通过第一多层文件系统和只读方式结合的方式对网络共享文件进行挂载,不但可以确保应用运行过程中的数据的读写,实现应用在待配置云手机上的启动和运行,还可以通过重新挂载新版本安装信息的方式,实现应 用的更新,使得海量云手机配置应用的场景下,云平台无需在每一个云手机中安装应用也可实现应用的安装、运行和更新,降低云手机存储空间的占用,降低云手机的运营维护成本。
在第一方面的一种可能的实施方式中,可通过在网络共享文件中配置第二多层文件系统的方式,实现待配置云手机对网络共享文件的挂载。具体地,云平台可通过网络共享文件配置接口,根据用户的第三输入配置第一网络共享文件以只读方式连接第一网络共享文件中的第一安装目录,再通过网络共享文件配置接口,根据用户的第三输入在第一网络共享文件配置第二多层文件系统,第二多层文件系统用于接收并处理至少一个待配置云手机发送的数据读写请求,其中,第二多层文件系统包括上层目录和下层目录,下层目录用于以只读映射的方式连接第二安装目录,上层目录用于存储第一网络共享文件中安装的应用运行过程中生成的修改数据,第二多层文件系统用于叠加上层目录和下层目录。
具体实现中,上述第二多层文件系统可通过Overlay文件系统实现,网络共享文件可先创建一个内置有上述第二多层文件系统的空白目录,待配置云手机挂以只读方式与空白目录进行连接,然后网络共享文件创建一个拷贝目录,该拷贝目录模版云手机目录的镜像,部署有Overlay文件系统的空白目录挂载于该拷贝目录,待配置云手机以只读方式与空白目录进行连接,从而实现待配置云手机的应用安装,其中,空白目录包括上层目录和下层目录,下层目录用于以只读映射的方式连接拷贝目录中的第二安装目录,上层目录用于存储第一网络共享文件中安装的应用运行过程中生成的修改数据,第二多层文件系统用于叠加上层目录和下层目录。待配置云手机可从挂载了拷贝目录的空白目录1读取数据,并将生成的修改数据通过空白目录1的第二多层文件系统写入该空白目录1,从而实现应用在待配置云手机上的安装。
实施上述实现方式,不但可以确保应用运行过程中的数据的读写,实现应用在待配置云手机上的启动和运行,还可以通过重新挂载新版本安装信息的方式,实现应用的更新,使得海量云手机配置应用的场景下,云平台无需在每一个云手机中安装应用也可实现应用的安装、运行和更新,降低云手机存储空间的占用,降低云手机的运营维护成本。
在第一方面的一种可能的实施方式中,共享网络文件可包括用户数据,用户数据包括应用运行期间产生的本地业务数据和本地习惯数据。比如应用是游戏类应用的情况下,手游应用的用户数据可包括用户默认账号信息、历史登录区服信息等等,单机游戏应用的用户数据可包括游戏通关记录、游戏角色数据等等;应用是办公类应用的情况下,比如邮箱应用的用户数据可包括用户邮箱账号绑定信息、邮箱名片设置等等,办公通讯应用的用户数据可包括用户历史聊天记录、用户历史账号信息、用户历史文件信息、业务数据等等,应理解,用户数据还可包括其他种类的应用在运行过程中用户个人产生的私人数据,这里不一一举例说明。
实施上述实现方式,由于应用运行过程中产生的数据均存储在网络共享文件中,因此应用进行更新时,根据更新后的安装信息生成更新后的拷贝目录后,上述用户数据仍可保留在网络共享文件的空白目录中,使得应用更新后,用户数据仍可保留,用户无需从新设置账号信息、无需重新下载业务数据等等,从而提高用户的使用体验。
在第一方面的一种可能的实施方式中,模板云手机、至少一个待配置云手机、以及第一网络共享文件位于第一数据中心,在至少一个待配置云手机中的第一待配置云手机从第一数据中心迁移到第二数据中心的情况下,网络共享文件配置接口,还用于根据用户的第五输入,创建位于第二数据中心的第二网络共享文件,第二网络共享文件是第一网络共享文件的镜像。
举例来说,假设用户A在北京(华北地区)办公时,用户A使用华北数据中心的云手机1和网络共享文件1运行了某办公应用,之后用户A出差至深圳办公(华南地区),此时对象存储设备可向华南数据中心发送创建网络共享文件1’的请求,然后将该办公应用的安装信息同步至网络共享文件1’,网络共享文件1将用户A在北京办公时生成的用户数据快速同步至网络共享文件1’,从而使得挂载网络共享文件1’的云手机1’在实现App的运行的同时,用户数据得以保留,用户无需重新输入账号密码、重新下载业务数据等等,提升用户使用体验。
实施上述实现方式,由于应用的安装信息和用户数据存储在网络共享文件中,因此待配置云手机出现跨数据中心迁移时,应用的安装信息和用户数据仍可保留,从而避免由于跨区域数据中心数据不互通导致应用安装失败或者应用安装缓慢的问题,提高用户的使用体验。
在第一方面的一种可能的实施方式中,网络共享文件配置接口还用于根据用户的第六输入,配置迁移到第一数据中心的第一待配置云手机挂载第二网络共享文件以完成多个应用的安装。举例来说,假设用户使用的云手机2从服务器1迁移至服务器2,可先停止运行云手机2,再取消云手机2与网络共享文件之间的挂载,然后在服务器2创建一个云手机2’,并将网络共享文件上的挂载目录提供给云手机2’,由云手机2’通过该挂载目录挂载该网络共享文件,实现云手机的资源迁移。
实施上述实现方式,由于应用的安装信息和用户数据存储在网络共享文件中,因此待配置云手机在数据中心内的服务器之间迁移时,迁移后的云手机重新挂载网络共享文件即可实现迁移后的云手机的应用安装,使得数据中心内资源迁移速度缩短至秒级,提高用户的使用体验。
在第一方面的一种可能的实现方式中,网络共享文件可部署有服务端,待配置云手机可部署有客户端,其中,客户端用于将待配置云手机产生的读写IO请求(比如将App运行过程产生的修改数据写入第二安装目录的请求,读取第一安装目录的请求等等)聚合后发送至网络共享文件的服务端处,服务端用于接收客户端发送的上述读写IO请求,并将其拆解后发送至第二多层文件系统,由第二多层文件系统实现安装信息的读写操作。具体实现中,网络共享文件可将接收到的IO请求先缓存(Cache)在内存中,在接收到待配置云手机发送的IO请求后,先更新缓存中的数据,然后再生成异步的IO请求。然后将大量小文件的IO请求聚合成单次的IO请求,一次性发送聚合后的IO数据到服务端,服务端可对接收到的IO请求进行解析后再批量更新到存储介质中。
实施上述实现方式,待配置云手机中的IO请求可发送至客户端,由客户端对接收到的IO请求进行聚合后,统一发送至服务端进行处理,从而减少网络共享文件接收到的IO请求数量,降低网络共享文件的处理压力,提高App启动、运行、更新和 卸载的效率。
可以理解的,待配置云手机也可通过基于云手机的应用安装方法实现应用的更新,具体地,云平台可将更新后的应用安装至模版云手机并导出至对象存储设备(或者由用户操作模版云手机进行应用更新,本申请不作具体限定),对象存储设备将该新版本安装信息同步至网络共享文件中,网络共享文件可向待配置云手机提供新的挂载目录(当然也可以保持挂载目录不变,只是更新挂载目录下的安装信息),待配置云手机可根据上述新的挂载目录,重新对网络共享文件中的新版本安装信息进行挂载,实现App的更新。
同理,将对象存储设备和网络共享文件中的某应用的安装信息删除后,即可完成对该应用的卸载,用户无需操作每一台云手机进行卸载操作,提高用户的使用体验。
可选地,模版云手机和待配置云手机包括虚拟机、容器和裸金属服务器。
可选地,应用包括游戏应用、工作应用、教育应用、视频应用、社交应用和虚拟现实应用。
可选地,用户可通过控制台或者API购买模版云手机,操作模版云手机安装所需的应用,然后由云平台创建网络共享文件和对象存储设备,并对网络共享文件、对象存储设备以及待配置云手机进行配置,使得待配置云手机挂载网络共享文件实现应用的安装。
可选地,用户可通过控制台或者API购买模版云手机,操作模版云手机安装所需的应用,然后通过云平台提供的各种接口创建和配置网络共享文件、对象存储设备以及待配置云手机,使得待配置云手机挂载网络共享文件实现应用的安装。该接口可以是API接口,也可以是网页、应用程序或者其他形式的控制台,本申请不作具体限定。
可选地,用户还可通过控制台或者API上传需安装的应用清单和待配置云手机的数量x,云平台根据用户上传的应用数量和应用清单,创建模版云手机、网络共享文件和对象存储设备,并在模版云手机上安装上述应用清单中的应用,再将模版云手机的目录导出至对象存储设备,网络共享文件同步该对象存储设备中的安装信息,配置x个云手机挂载于该网络共享文件,实现用户所需的x个云手机安装应用清单中应用的目的,整个云手机应用安装中用户的操作十分便捷,提升用户的使用体验。
第二方面,提供了一种云平台,包括:提供云手机配置接口单元,用于提供云手机配置接口,云手机配置接口用于根据用户的第一输入配置模板云手机,模板云手机设置有多个应用,模板云手机的目录记录有多个应用的安装信息;提供网络共享文件配置接口单元,用于提供网络共享文件配置接口,网络共享文件配置接口用于根据用户的第二输入将模板云手机的目录存储至第一网络共享文件;其中,云手机配置接口还用于根据用户的第三输入配置至少一个待配置云手机挂载第一网络共享文件以完成多个应用的安装。
第二方面或第二方面任意一种实现方式是第一方面或第一方面任意一种实现方式对应的装置实现,第二方面或第二方面任意一种实现方式中的描述适用于第一方面或第一方面任意一种实现方式,在此不再赘述。
第三方面,提供了一种计算机可读存储介质,包括指令,当该指令在计算设备上 运行时,使得该计算设备执行如第一方面描述的方法。
第四方面,提供了一种计算设备,包括处理器和存储器,该处理器执行该存储器中的代码时,使得计算设备实现如第一方面描述的方法。
第五方面,提供了一种计算机程序产品,当该计算机程序产品被计算设备读取并执行时,实现如第一方面描述的方法。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍。
图1是一种公有云系统的架构示意图;
图2是本申请提供的一种基于云手机的应用安装系统的结构示意图;
图3是本申请提供的一种基于云手机的应用安装方法的步骤流程示意图;
图4A~图4B是本申请提供的一种待配置云手机挂载网络共享文件的结构示意图;
图5A~图5B是本申请提供的另一种待配置云手机挂载网络共享文件的结构示意图;
图6是本申请提供的一种待配置云手机跨数据中心迁移的流程示意图;
图7是本申请提供的一种待配置云手机数据中心内迁移的流程示意图;
图8是本申请提供的一种基于云手机的应用安装方法的步骤流程示意图;
图9是本申请提供的一种控制台界面示意图;
图10是本申请提供的另一种控制台界面示意图;
图11是本申请提供的一种云平台的结构示意图;
图12是本申请提供的一种计算设备的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
为了便于理解本申请实施例,首先,对本申请涉及的部分术语进行解释说明。
容器(container):容器是一组受到资源限制,彼此间相互隔离的进程。
云手机:一种在物理服务器中虚拟的带有手机操作系统,同时具有虚拟手机功能的容器、虚拟机或者裸金属服务器,其本质是将手机上的应用转移到公有云上的容器、虚拟机或者裸金属服务器来运行,不同的云手机之间相互隔离,互不干扰,云手机可以安装本地手机的应用,该些应用在云手机中运行,运行过程中产生的音视频流可发送至用户本地的终端设备进行显示及播放,用户本地的终端设备根据显示和播放的音视频流产生的控制命令也可以发送至云手机,云手机根据控制命令控制应用的运行状态,从而可将本地手机的应用转移到云手机中运行,用户本地的终端设备无需大量安装耗费硬件资源的应用,可以实现应用的轻量化。
公有云:公有云的核心属性是共享资源服务,是指云供应商为用户(又称为租户)提供的能够通过公共网络(比如因特网(internet))使用的云端基础设施和服务,云端基础设施和服务设置在云供应商的数据中心中,用户通过向云供应商付费获得云端基础设施和服务的使用权限,从而可以远程使用云端基础设施和服务。
对象存储服务(object storage service,OBS):公有云中的一项基于对象的海量存储服务,可为客户提供海量、安全、高可靠、低成本的数据存储能力。OBS是面向internet访问的服务,提供了基于HTTP/HTTPS协议的Web服务接口,用户可以随时随地连接到internet的电脑上,通过OBS管理控制台或者各种OBS工具,访问和管理存储在OBS中的数据。
弹性文件服务(scalable file service,SFS):公有云中的一项提供按需扩展的高性能文件系统的服务,SFS可为公有云上的多个弹性云服务器(elastic cloud server,ECS),容器、裸金属服务器(BMS)提供共享访问。通常情况下,用户创建文件系统后,可使用云服务器来挂载该文件系统,以实现多个云服务器共享使用该文件系统的目的。
挂载(mounting):由操作系统使一个存储设备(如硬盘或者共享资源)上的文件和目录可供用户通过所持设备的文件系统访问的一个过程,举例来说,当用户访问存储设备中的文件A时,如果文件A挂载到了目录B,那么用户可以通过访问目录B,即可达到访问存储设备中的文件A的目的,其中,目录B又称为挂载点,挂载点可以在用户所持设备上,也可以在存储设备上,还可以在一个虚拟盘或者虚拟文件夹中。
其次,对本申请涉及的“公有云”应用场景进行简要说明。
随着云计算技术和各种网络基础设施的快速发展,传统的互联网技术(Internet Technology,IT)业务架构,正在逐步向公有云迁移,越来越多的业务应用也基于公有云架构重新设计和使用。在公有云架构下,用户的手机上的应用将安装于云手机中,云手机可以将应用运行过程中渲染出的音视频画面通过音视频流的形式传输到终端设备110,终端设备110只需要将接收到的音视频流显示在屏幕上,真正做到应用免下载、免安装、即点即用。
图1是一种公有云系统的架构示意图。如图1所示,该系统包括终端设备110、公有云的数据中心130以及应用服务节点140,并且,终端设备110、公有云的数据中心130以及应用服务节点140通过网络120连接。其中,网络120可以是公共网络,比如因特网(internet)。
终端设备110可以是智能手机、掌上处理设备、平板电脑、移动笔记本、虚拟现实设备、可穿戴设备、一体化掌机等等具有流媒体播放能力的电子设备,图1以终端设备110为智能手机为例进行说明,但是本申请不对此进行具体限定。
应用服务节点140用于向用户提供各种应用服务,应用服务节点140可包括游戏服务节点、教育应用服务节点、视频应用服务节点、社交应用服务节点、虚拟现实应用服务节点等,本申请不作具体限定。
公有云的数据中心130可为用户提供共享资源服务,共享资源服务可包括OBS服务、SFS服务、云手机(cloud phone)服务、内容分发网络服务(content delivery  network,CDN)、云备份服务(cloud backup and recovery,CBR)、数据管理服务(data admin service,DAS)等等,本申请不对公有云数的数据中心130可提供的共享资源服务类型进行限定。具体实现中,个人用户可通过网络120租用公有云的数据中心130拥有的云端基础设施和服务,通过租用的共享资源,使用应用服务节点130提供的应用服务,比如租用公有云的虚拟机体验高质量的单机游戏、租用公有云的云手机体验高画质手机游戏等等。企业用户可根据需求购买云服务供企业自身使用,比如租用公有云的虚拟机作为企业的服务器,也可以将购买到的云服务供其他用户使用,比如游戏厂商可购买多部云手机或者虚拟机运作云游戏平台业务,该游戏厂商的游戏用户在启动游戏时,可通过自己的终端设备与游戏厂商购买的云手机或者虚拟机远程连接,使得游戏用户可以使用图像处理与数据运算能力相对有限、甚至是只有流媒体播放能力的终端设备来使用对硬件资源要求较高的应用。应理解,上述举例用于说明,并不能构成具体限定。
示例性地,公有云的数据中心130可包括云平台131以及硬件资源池132,应理解,图1所示的划分方式用于举例说明,公有云的数据中心130还可以使用其他方式进行划分,本申请不对公有云的数据中心130的划分方式进行限定。
其中,云平台131可以是通用的物理服务器实现的,例如,ARM服务器或者X86服务器,也可以是结合网络功能虚拟化(network functions virtualization,NFV)技术实现的虚拟机(virtual machine,VM),云平台131也可以是硬件资源池132中的虚拟机或者物理服务器,本申请不作具体限定。
硬件资源池132可以包括至少一个物理服务器(图1以资源池包括服务器1、服务器2、服务器3和服务器4为例进行了举例说明),其中,物理服务器可以是通用的物理服务器,例如ARM服务器或者X86服务器,本申请不作具体限定。硬件资源池132的物理服务器和云平台之间有内部网络连接,每个物理服务器都可以通过内部网络与其他物理服务器以及云平台131之间进行通信。
其中,每个物理服务器可以运行至少一个云手机,公有云的数据中心130可以向用户提供云手机租用服务,比如按照用户需求的云手机的硬件规格收费,用户可在租用的云手机中安装并使用所需的应用,或者,公有云的数据中心130也可预先在云手机中安装各种应用,向用户提供租用云手机中应用的服务,比如按应用的使用时长收费。举例来说,如图1所示,假设用户需要使用应用111,用户可以向云平台131发送购买请求以租用云手机,云平台131可以根据硬件资源池中的资源使用情况,分配一台安装有应用111的云手机11给该用户使用。应理解,无论是租用云手机或是租用应用,终端设备110付费后都可以远程操纵云手机上的应用,云手机可以响应于用户的远程操作,并将随之产生的音视频流发送至终端设备110进行显示及播放,使得用户可以使用图像处理与数据运算能力相对有限的终端设备110、甚至是只有流媒体播放能力的终端设备110来使用对硬件资源要求较高的应用。
具体实现中,如图1所示,云手机可以是图1中的虚拟机(比如虚拟机21)、容器(比如容器11以及容器22)以及裸金属服务器(bare metal server,BMS)(比如服务器3)中的任一种。其中,云手机若通过容器实现,云平台131可以根据应用所需的运行环境,通知服务器的云平台管理代理节点创建容器,并在云手机安装有应用 111;云手机若通过虚拟机实现,云平台131可以根据应用所需的运行环境,通过虚拟机管理器创建虚拟机,并在云手机安装应用111;云手机如果是BMS,云平台131可以根据应用所需的运行环境选择一台合适的BMS并在其上安装应用111,从而获得安装有应用111的云手机,在本申请中,云手机为公有云的数据中心130上的虚拟资源,该虚拟资源运行有手机操作系统,本申请不对云手机的具体形态进行限定。
应理解,终端设备110停止远程操纵云手机上的应用111之后,云平台131可以释放该云手机(即容器11),释放出的资源可以供其他用户使用,当终端设备110再次请求远程操纵云手机上的应用111时,云平台131可以再次创建一台安装有应用111的云手机以供用户使用。
综上可知,在公有云架构下,用户的应用将安装于云手机中,云手机可以将应用运行过程中渲染出的音视频画面通过音视频流的形式传输到终端设备,终端设备只需要向用户显示接受到的音视频流,真正做到应用免下载、免安装。
但是,对于租用云手机来运作业务的企业用户来说,在购买大量云手机后,需要提前在云手机上部署应用,比如租用云手机供游戏用户使用的游戏厂商,需要在每个云手机上提前安装好该游戏厂商旗下的多款游戏,如果游戏厂商运营了100款游戏,并购买1000部云手机,那么每个云手机都需要安装100种游戏App,如果每个游戏App的安装大小为1GB(实际很可能会超过1GB),那么一台云手机就需要100GB的存储空间,1000部云手机则需要100T的存储空间,任何一款游戏App的更新也会占用大量系统资源,使得游戏厂商的运营和维护成本过高;并且,安装100种App的云手机在开机和App运行过程中更容易出现卡顿,降低用户的使用体验。
为了解决上述云手机需要提前安装应用导致购买云手机的应用厂商运营和维护成本过高、且安装有大量应用的云手机在开机和应用运行时易卡顿的问题,本申请提供了一种基于云平台的云手机应用安装系统,如图2所示,该系统可以部署于图1实施例中的公有云的数据中心130,其中,该系统可包括云平台131以及硬件资源池132,其中,硬件资源池132可包括模版云手机1324、至少一个待配置云手机1321以及网络存储设备1325,图2以2个待配置云手机进行举例说明,本申请不对待配置云手机的数量进行限定。
模版云手机1324和待配置云手机1321可以是图1实施例中的容器、虚拟机以及BMS中的任一种,具体可以参考前述内容中关于云手机的描述,这里不重复赘述。
网络存储设备1325用于提供存储服务,具体可以是图1实施例中的虚拟机以及裸金属服务器中的任一种。可选地,网络存储设备1325可包括对象存储设备1323以及网络共享文件1322。具体实现中,对象存储设备1323可以是公有云中的云存储服务,比如OBS服务,由云平台131创建获得,可存储任意数量和形式的非结构化数据。网络共享文件1323可以是公有云中的一种基于网络的文件系统服务,比如SFS服务,由云平台131创建获得。其中,SFS服务可为多个服务器(具体可以是上述虚拟机、容器、BMS中的一种或者多种)提供共享访问。具体实现中,SFS服务创建的文件系统可以是任何支持NFS协议的网络文件系统,也可以是CIFS/SMB等网络文件系统,本申请不对网络共享文件1323的文件系统类型进行限定。
在本申请实施例中,模版云手机1324可安装用户所需多个应用,生成多个应用的安装信息后,将模版云手机的目录(包含有上述多个应用的安装信息)存储至对象存储设备中。云平台131还可根据用户的第二输入将模版云手机的目录存储至对象存储设备1323中,对象存储设备1323将存储的目标云手机的目录存储同步到网络共享文件1323中,网络共享文件1323可向至少一个待配置云手机提供挂载目录,当App使用者使用待配置云手机时,待配置云手机可通过该挂载目录访问网络共享文件1323中安装信息,实现应用的启动和运行,从而降低云手机的内存占用,提高用户的使用体验,降低应用厂商的运营维护成本。
具体实现中,对象存储1323可对模版云手机1324导出的多款应用程序的安装信息进行全局化的存储和管理,比如每款应用的安装信息的分类管理、版本管理、每款应用与网络共享文件1322的映射管理等等。并且,图2以用户在模版云手机上安装了4个应用,一台网络共享文件同步2个应用的安装信息,一台网络共享文件为一个待配置云手机提供挂载目录为例进行说明,具体实现中,可根据网络共享文件的存储容量确定每台网络共享文件同步的应用数量,本申请不对模版云手机安装应用的数量、网络共享文件1322同步的应用数量以及网络共享文件1322提供挂载的待配置云手机的数量进行限定。
需要说明的,由于文件系统的存储容量有限,因此一个对象存储1322可对接多个网络共享文件1322,比如某游戏厂商旗下拥有100款游戏,该100款游戏的安装信息全部存储于对象存储1322中,但是1个网络共享文件只能存储50款游戏的安装目录和外部存储目录,那么该对象存储可与两个网络共享文件对接,网络共享文件A负责前50款游戏的目录挂载,网络共享文件B负责后50款游戏的目录挂载。应理解,上述举例用于说明,本申请不对对象存储1322和网络共享文件1323的数量进行限定。
可以理解的,图2所示的网络存储设备可以有多种划分,图1仅为一种示例性的划分方式,且各个模块可以是软件模块,也可以是硬件模块,也可以部分是软件模块部分是硬件模块,本申请不对其进行限制。比如网络存储设备在一些应用场景中,可以只包括网络共享文件1322,应理解,如果企业用户所需安装的应用种类较少,没有对多款应用的安装信息进行全局管理的需求,比如某游戏厂商仅需安装1款游戏至云手机,那么模版云手机可将该款游戏安装后生成的安装信息导出至网络共享文件1323中,由网络共享文件1323向待配置云手机提供挂载点进行目录挂载。应理解,上述举例用于说明,本申请不对此进行限定。
同理,当App更新时,更新后的应用数据可先导出至对象存储1323,再同步至网络共享文件1322,云手机可重新挂载更新后的安装信息,从而实现应用更新。因此,使用本申请提供的应用安装系统,如果游戏厂商运营了1000款游戏,并购买1000部云手机,当1000款游戏中的一款游戏A需要更新时,可将更新后的安装信息导出至对象存储,对象存储将更新后的安装信息同步至网络共享文件中,当游戏用户使用云手机启动游戏A时,该云手机可从网络共享文件中挂载上述更新后的安装信息,使得App的更新无需占用云手机大量的存储空间和系统资源,不仅降低了企业用户的运营成本,同时降低了云手机开机和App启动、运行过程中容易出现的卡 顿,提升用户的使用体验。
综上可知,本申请提供的基于云手机的应用安装系统,无需在每一个云手机中安装应用,而是将应用的安装信息同步至网络共享文件中,每次用户使用云手机使用各种应用时,云手机可从网络共享文件挂载各种应用的安装信息,从而在不提前安装应用的情况下,实现应用的启动、运行和更新,使得App在云手机的内存占用降低,可以大大降低应用厂商的运营维护成本,同时App的启动、运行和更新速度得以提升,提高用户的使用体验。
下面结合附图,对上述图2所示的基于云手机的应用安装系统如何进行应用安装的具体步骤过程进行详细介绍。
如图3所示,本申请提供了一种基于云手机的应用安装方法,该方法应用于图2所示的应用安装系统中,该系统的描述可参考图1~图2实施例,这里不重复赘述。该方法包括以下步骤:
S310:模版云手机1324安装App,生成该应用的安装信息。
在一实施例中,App安装于模版云手机1324时,模版云手机1324的操作系统会将App安装包中的数据安装在模版云手机1324设定好的路径中,生成的安装信息通常可包括第一安装目录和第二安装目录,其中,第二安装目录包括多个应用的动态数据,第一安装目录包括多个应用的静态数据,简单来说,静态数据是指App在云手机运行过程中不会发生修改的数据,动态数据是指App运行过程中将会发生修改的数据。以安卓(Android)操作系统为例,第一安装目录可以为应用安装目录,第二安装目录为外部存储目录,其中,应用安装目录存储了App的apk文件、lib库、oat文件等应用的安装信息,路径为/data/App/{App_package},该目录下的数据在App运行过程中不会发生修改;外部存储目录存储应用的运行过程文件,例如游戏应用中涉及的装备信息,游戏版本等,路径为/data/media/0/Android/data/{App_package},该目录下的数据在App运行过程中将会发生修改。应理解,上述第一安装目录和第二安装目录存储的具体文件和路径用于举例说明,第一安装目录和第二安装目录在不同的操作系统(比如IOS操作系统、鸿蒙操作系统等)拥有不同的路径、存储有不同的安装信息,本申请不一一展开举例。
S320:模版云手机1324将安装信息导出至对象存储1322。其中,对象存储1322是企业用户购买云手机后,云平台创建的一个与该企业用户对应的对象存储1322,该对象存储1322可对企业用户在模版云手机上安装的应用的安装信息进行存储管理。
具体地,模版云手机可将安装信息压缩打包,比如压缩为tar.gz格式的文件,然后将其上传至对象存储1322,对象存储1322可对接收到的安装信息进行解压缩后存储至存储介质中,比如用户的OBS数据桶,应理解,在公有云中,每个用户都将拥有一个对应的OBS数据桶,因此将安装信息存储至用户的OBS数据桶十分方便快捷,对象存储1322无需重新向云平台申请存储资源,可以提高处理效率,当然,对象存储1322也可将安装信息存储在其他存储介质中,比如对象存储1322对应的OBS数据桶,本申请不对此进行限定。可选地,对象存储1322还可记录该安装信息 的存储路径、版本信息、对应的用户信息、应用名称、类型等等,本申请不对对象存储1322对应用文件进行存储管理的具体类型作具体限定。
S330:对象存储1322将安装信息同步至网络共享文件1323。
具体实现中,在对象存储1322还未拥有与其对应的网络共享文件1323(即用户第一次在模版云手机上安装应用时),或者当前的对象存储剩余存储空间不足的情况下,对象存储可先向云平台131发送网络共享文件1323的创建请求,云平台131创建一个网络共享文件1323之后,对象存储将安装信息发送至该网络共享文件1323,并记录该安装信息和网络共享文件1323之间的对应关系。这样,当对象存储1322接收到该安装信息的更新版本之后,可根据该对应关系确定该安装信息对应的网络共享文件1323,然后将上述安装信息的更新版本发送至对应的网络共享文件1323,实现应用安装信息的更新。值得注意的是,网络共享文件实例中的安装信息的目录结构与对象存储1322的目录结构保持一致,也与模版云手机1324安装App后生成的安装信息的目录结构保持一致。
S340:待配置云手机1321通过挂载网络共享文件,访问安装信息,实现应用的启动、运行和更新。网络共享文件可向待配置云手机1321提供挂载目录(挂载点),比如/data/share_app_center,使得待配置云手机可通过该挂载目录访问网络共享文件1323中的安装信息,实现应用的启动和运行,从而降低云手机的内存占用,提高用户的使用体验,降低应用厂商的运营维护成本。
本申请提供了两种待配置云手机通过挂载网络共享文件1323中的安装信息,实现App的启动、运行和更新的方法,下面分别对这两种方法进行详细的解释说明。
一、通过在待配置云手机中部署第一多层文件系统实现对文件挂载
在一实施例中,参考前述内容可知,App安装于手机后生成的安装信息包括第一安装目录和第二安装目录,App运行过程中,第一安装目录将不会发生修改,运行过程中产生的修改数据将会写入第二安装目录,因此待配置云手机1321可通过只读方式从网络共享文件中挂载第一安装目录,再通过第一多层文件系统的方式,将修改数据写入第二安装目录,从而实现App在待配置云手机1321中的启动和运行。
具体地,第一多层文件系统可至少包括上层目录和下层目录,其中,下层目录为网络共享文件1233中的第二安装目录,上层目录用于存储修改数据,第一多层文件系统将上传目录和下层目录合成后,在App运行过程中,操作系统可通过访问该第一多层文件系统实现对第二安装目录的读写,从而实现App在待配置云手机1321中的运行。应理解,上述修改数据可以是游戏启动时记录的登录日期、运行过程时生成的游戏数据等等,上层目录的目录结构是预设目录结构,可根据应用场景确定适用的预设目录结构进行修改数据的存储,本申请不对此进行限定。
举例来说,如图4A所示,假设待配置云手机的操作系统为安卓操作系统,某App的安装信息已从对象存储同步至网络共享文件1322,该App的安装信息中,第一安装目录为应用安装目录1,第二安装目录为外部存储目录1,待配置云手机1321运行App时,操作系统将会访问应用安装目录1’或者外部存储目录1’,其中,应用安装目录1’以只读方式挂载了网络共享文件1322中的应用安装目录1,外部存储目录1’是上层目录和下层目录的合成目录,其中,下层目录可通过挂载外部存储目录1 实现,上层目录是一个预设目录结构,存储的数据为App运行过程中产生的修改数据,从而实现App在待配置云手机1321中的运行。
同理,如图4B所示,当待配置云手机的数量为多个时(图4B以两个待配置云手机安装同一个应用为例),待配置云手机1和待配置云手机2可分别挂载网络共享文件1322中的安装信息实现应用的安装。具体地,待配置云手机1和待配置云手机2均部署有各自的第一多层文件系统,并分别通过只读方式连接网络共享文件中的应用安装目录1,然后分别通过各自的第一多层文件系统实现对外部存储目录1的读写,完成应用的安装,其中,第一多层文件系统的上层目录用于存储各自应用运行过程中产生的修改数据,下层目录通过只读方式连接网络共享文件中的应用安装目录1,应理解,图4B中未描述的内容可参考图4A实施例,这里不重复赘述,并且,上述举例用于说明,本申请不对待配置云手机的数量和应用的数量进行限定。
具体实现中,上述第一多层文件系统可通过Overlay文件系统实现,只读方式可以是通过软连接的方式,将网络共享文件中的第一安装目录映射至待配置云手机中,使得待配置云手机请求访问第一安装目录时,将会通过网络跳转到网络共享文件中存储的第一安装目录中,从而实现以只读方式从网络共享文件中挂载获得应用安装目录下的安装信息。
可以理解的,上述第一多层文件系统和只读方式结合的方法对网络共享文件进行挂载,不但可以确保App运行过程中的数据的读写,实现App在待配置云手机上的启动和运行,还可以通过重新挂载新版本安装信息的方式,实现App的更新。具体地,应用A的新版本安装信息安装至模版云手机并导出至对象存储设备之后,对象存储设备可根据之前记录的对应关系,将该新版本安装信息同步至对应的网络共享文件1322中,网络共享文件1322可向待配置云手机1321提供新的挂载目录(当然也可以保持挂载目录不变,只是更新挂载目录下的安装信息),待配置云手机1321可根据上述新的挂载目录,重新对网络共享文件1322中的新版本安装信息进行挂载,实现App的更新。
具体实现中,待配置云手机1321在重新挂载新版本安装信息时,可重新以只读的方式挂载第一安装目录,实现对第一安装目录的读操作,访问更新后的第一多层文件系统实现对第二安装目录的读写操作,从而实现更新后App的启动和运行。其中,更新后的第一多层文件系统重新合成了更新后的上层目录和更新后的下层目录,更新后的下层目录挂载了网络共享文件1322中更新后的第二安装目录,更新后的上层目录使用了新的预设目录(或者仍使用之前的预设目录,但清空该目录下的修改数据),更新后App运行和启动时产生的修改数据可写入该更新后的上层目录中,从而实现更新后App的启动和运行。
同理,上述第一多层文件系统和只读方式结合的方法对文件挂载,不但可以实现App在待配置云手机上的启动、运行和更新,还可以实现App的快速卸载。具体地,企业用户发起卸载App的请求后,对象存储和网络共享文件可删除该App对应的安装信息,从而实现App的卸载。使用该方式卸载App,无需对每一个云手机进行应用卸载的步骤,降低企业用户管理云手机时的资源调度压力,提高云手机的App卸载效率。
可以理解的,通过上述挂载网络共享文件中安装信息的方式,进行App的启动、运行和更新,每个云手机无需提前安装应用程序,不仅降低了云手机的内存占用,使得提高App启动和运行的效率得到提升,同时也降低了企业用户在管理云手机时,安装、更新和卸载应用所需的资源调度压力,降低运营成本。
二、通过在网络共享文件中部署第二多层文件系统实现安装信息的挂载
在一实施例中,可将待配置云手机在App运行过程中产生的修改数据发送至网络共享文件,由网络共享文件对第一安装目录和第二安装目录进行读写操作,将读写操作的压力集中在网络共享文件中,减少待配置云手机在App运行过程中的处理压力,提高待配置云手机App运行的效率,进而提高用户的使用体验。具体地,可将上述第二多层文件系统部署于网络共享文件中,该第二多层文件系统可对安装信息进行挂载,待配置云手机可将App运行过程中生成的修改数据发送至网络共享文件,由网络共享文件通过该第二多层文件系统对安装信息进行读写操作。具体实现中,上述第二多层文件系统可通过Overlay文件系统实现,
仍以上述例子为例,如图5A所示,假设待配置云手机的操作系统为安卓操作系统,某App的安装信息已从对象存储同步至网络共享文件1322,该App的安装信息中,第一安装目录为应用安装目录1,第二安装目录为外部存储目录1。在待配置云手机启动该App之前,网络共享文件1322可先创建一个内置有上述第二多层文件系统的空白目录1,并将其挂载到待配置云手机,作为其数据盘的根目录,然后网络共享文件1322再根据从对象存储下载获得的安装信息,创建一个拷贝目录,该拷贝目录中的目录结构和数据与安装信息中的目录结构和数据相同,并将空白目录1挂载于该拷贝目录中。这样,当待配置云手机运行该App时,待配置云手机可从挂载了拷贝目录的空白目录1读取数据,并将生成的修改数据通过空白目录1的第二多层文件系统写入该空白目录1。同理,App需要更新时,可根据更新后的安装信息对拷贝目录进行更新,然后重新将空白目录挂载于该更新后的拷贝目录中,在App需要卸载时,也可以直接将安装信息、拷贝目录进行删除,应理解,空白目录在创建时目录中的数据为空,在挂载于拷贝目录后,空白目录中的数据不再为空。基于此,通过在网络共享文件中部署第二多层文件系统实现安装信息的挂载,使得每个云手机无需提前安装应用程序的情况下,实现App的启动、运行、更新和卸载,不仅降低了云手机的内存占用,使得提高App启动和运行的效率得到提升,同时也降低了企业用户在管理云手机时,安装、更新和卸载应用所需的资源调度压力,降低运营成本。
同理,如图5B所示,当待配置云手机的数量为多个时(图5B以两个待配置云手机安装同一个应用为例),待配置云手机1和待配置云手机2可分别挂载网络共享文件1322实现应用的安装。具体地,网络共享文件1322中部署有多个第二多层文件系统(即图5B中的空白目录1和空白目录2),分别对应不同的待配置云手机,即待配置云手机1挂载于空白目录1,待配置云手机2挂载于空白目录2,从而实现对待配置云手机1和待配置云手机2的安装。应理解,图5B未描述的内容具体可参考图5A实施例,这里不重复赘述,并且,上述举例用于说明,本申请不对待配置云手机的数量和应用的数量进行限定。
具体实现中,网络共享文件可部署有服务端,待配置云手机可部署有客户端,其 中,客户端用于将待配置云手机产生的读写IO请求(比如将App运行过程产生的修改数据写入外部存储目录的请求,读取应用安装目录的请求等等)发送至网络共享文件的服务端处,服务端用于接收客户端发送的上述读写IO请求,并将其发送至第二多层文件系统,由第二多层文件系统实现安装信息的读写操作,进而实现待配置云手机远程挂载安装信息,使得每个云手机无需提前安装应用程序的情况下,实现App的启动、运行、更新和卸载,不仅降低了云手机的内存占用,使得提高App启动和运行的效率得到提升,同时也降低了企业用户在管理云手机时,安装、更新和卸载应用所需的资源调度压力,降低运营成本。
应理解,由于一个网络共享文件可对接多个待配置云手机,每个待配置云手机将会向网络共享文件发送多个读写IO请求,使得网络共享文件的压力较大,因此,待配置云手机中的IO请求可发送至客户端,由客户端对接收到的IO请求进行聚合后,统一发送至服务端进行处理,从而减少网络共享文件接收到的IO请求数量,降低网络共享文件的处理压力,提高App启动、运行、更新和卸载的效率。具体实现中,网络共享文件可将接收到的IO请求先缓存(Cache)在内存中,在接收到待配置云手机发送的IO请求后,先更新缓存中的数据,然后再生成异步的IO请求。然后将大量小文件的IO请求聚合成单次的IO请求,一次性发送聚合后的IO数据到服务端,服务端可对接收到的IO请求进行解析后再批量更新到存储介质中。
在一实施例中,App运行过程中还会产生用户数据,使用上述方法进行App管理可以使得用户数据在应用更新后仍可保留,提高用户的使用体验,其中,该用户数据可以是App运行过程中本地产生的个人业务数据和个人习惯数据,比如App是游戏类App的情况下,比如手游App的用户数据可包括用户默认账号信息、历史登录区服信息等等,单机游戏App的用户数据可包括游戏通关记录、游戏角色数据等等;App是办公类App的情况下,比如邮箱App的用户数据可包括用户邮箱账号绑定信息、邮箱名片设置等等,办公通讯App的用户数据可包括用户历史聊天记录、用户历史账号信息、用户历史文件信息、业务数据等等,应理解,用户数据还可包括其他种类的App在运行过程中用户个人产生的私人数据,这里不一一举例说明。
应理解,由于App运行过程中产生的数据均存储在网络共享文件中,因此App进行更新时,根据更新后的安装信息生成更新后的拷贝目录后,上述用户数据仍可保留在网络共享文件的空白目录中,使得App更新后,用户数据仍可保留,用户无需从新设置账号信息、无需重新下载业务数据等等,从而提高用户的使用体验。
在一实施例中,由于物理时延的原因,用户使用的云手机是用户所处地理区域的公有云上的云手机,比如用户当前处于华北地区,那么该用户使用的云手机和网络共享文件归属于华北数据中心,用户当前处于华南地区,那么该用户使用的云手机和网络共享文件归属于华南数据中心。通常情况下数据中心之间的数据是无法互通的,或者,需要花费高额费用来实现数据互通,在这一应用场景下,使用上述方法进行App管理,当用户所处的地理位置发生变化时,用户数据可以从历史网络共享文件中快速同步至当前的网络共享文件,从而避免由于用户地理位置的变更导致用户数据丢失,降低维护成本,提高用户的使用体验。
举例来说,如图6所示,假设用户A在北京(华北地区)办公时,用户A使用 华北数据中心的云手机1和网络共享文件1运行了某办公App,之后用户A出差至深圳办公(华南地区),此时对象存储设备可向华南数据中心发送创建网络共享文件1’的请求,然后将该办公App的安装信息同步至网络共享文件1’,网络共享文件1将用户A在北京办公时生成的用户数据快速同步至网络共享文件1’,从而使得挂载网络共享文件1’的云手机1’在实现App的运行的同时,用户数据得以保留,用户无需重新输入账号密码、重新下载业务数据等等,提升用户使用体验。
在一实施例中,用户正在使用的云手机因为多种原因,云手机资源迁移的情况时有发生,使用上述方法进行App管理可以降低云手机资源迁移所需的时间,同时保证云手机资源钱以后,用户数据不会丢失,提高用户的使用体验。其中,云手机资源迁移指的是用户正在使用的云手机从一台服务器迁移到另外一台服务器中。发生资源迁移的原因多种多样,比如,用户正在使用的云手机所在的服务器的资源占用率高,为了避免云手机发生卡顿,可将用户正在使用的云手机迁移至另一台资源占用率较低的服务器中;或者,用户使用云手机的过程中,使用需求发生了改变,比如用户之前只安装了办公类App,云手机的配置较低,如果用户安装了某款高配置需求的游戏App,此时用户使用的云手机也可以从一台服务器迁移至另一台服务器中,应理解,上述资源迁移的原因用于举例说明,本申请不对此进行限定。在这一云手机资源迁移的应用场景下,使用上述方法进行App管理,当用户使用的云手机发生资源迁移时,可先停止运行迁移前的云手机,将迁移后的云手机重新挂载至网络共享文件,从而快速实现云手机的资源迁移,由于整个迁移过程都是基于挂载网络共享文件的方式,无需对迁移后的云手机进行应用安装或者数据同步之类的冗余步骤,使得云手机的资源迁移将缩短至数秒,提高用户的使用体验,同时,由于迁移后的云手机挂载的网络共享文件与迁移前的云手机相同,进而使得云手机资源迁移后的用户数据仍可保留,用户无需重新输入账号密码、重新下载业务数据等等,进一步提升用户使用体验。
举例来说,如图7所示,假设用户使用的云手机2从服务器1迁移至服务器2,可先停止运行云手机2,再取消云手机2与网络共享文件之间的挂载,然后在服务器2创建一个云手机2’,并将网络共享文件上的挂载目录提供给云手机2’,由云手机2’通过该挂载目录挂载该网络共享文件,从而快速实现云手机的资源迁移,提高用户的使用体验。
应理解,本申请提供了两种待配置云手机通过挂载网络共享文件实现应用启动、运行、更新和卸载的方法,即通过在待配置云手机中部署第二多层文件系统实现对文件挂载,以及通过在网络共享文件中部署第二多层文件系统实现安装信息的挂载,上述两种方法用于举例说明,具体实现中,还可通过其他方法实现文件挂载,本申请不作具体限定。
需要说明的,本申请提供的应用安装方法,可以在用户购买云手机服务并在模板云手机中安装应用后,云平台自动执行步骤S310~步骤S340为用户实现至少一个待配置云手机的应用安装,还可以由云平台根据用户输入的配置需求实现本申请提供的方案,具体实现中,用户可通过console或者API手动设置对象存储设备、共享网络文件以及待配置云手机等等,如图8所示,下面对本申请提供的方法中,云平台是如 何根据用户输入实现待配置云手机的应用安装进行解释说明。
S410:云平台131向用户提供云手机配置接口,该云手机配置接口用于根据用户的第一输入配置模板云手机,模板云手机设置有多个应用,模板云手机的目录记录有多个应用的安装信息。
其中,用户的第一输入可包括用户需安装的App安装包、更新包、模版云手机的性能配置信息等等,云手机配置接口可以是云平台131的控制台(console)或者应用程序接口(application program interface,API),控制台具体可以是用户购买云服务、配置云服务的一个应用程序或者网页页面,比如用户可通过云平台的网站购买模版云手机,并在模版云手机中上传需安装的应用,完成应用的更新,应理解,上述举例用于说明,本申请不作具体限定。
S420:云平台131向用户提供网络共享文件配置接口,网络共享文件配置接口用于根据用户的第二输入将模板云手机的目录存储至网络共享文件。
具体实现中,在提供网络共享文件配置接口之前,该方法还包括:提供对象存储接口,对象存储接口用于根据用户的第四输入获取模板云手机的目录并将模板云手机的目录存储至对象存储设备中,网络共享文件配置接口,用于根据用户的第二输入将对象存储设备存储的模板云手机的目录存储同步到网络共享文件。这里,用户的第四输入可以是将网络共享文件与对象存储设备同步的指令,云平台可接收用户的第四输入,获取模版云手机的目录并将目标云手机的目录存储至对象存储设备中,用户的第二输入可以是将对象存储设备与网络共享文件进行关联,比如图2实施例中的对象存储设备与网络共享文件1和网络共享文件2关联,其中,每个网络共享文件存储2个应用的安装信息。应理解,上述举例用于说明,本申请不作具体限定,并且,上述网络共享文件配置接口和对象存储接口可以是上述console或者API,本申请也不作具体限定。
可选地,在提供对象存储接口之前,该方法还包括以下步骤:提供对象存储创建接口,对象存储创建接口用于根据用户的第七输入创建对象存储。其中,第七输入可以是创建对象存储设备的指令以及对对象存储设备的配置信息,比如对象存储设备的存储容量、对象存储设备的存储目录等等。
举例来说,云平台131向用户提供对象存储创建接口,假设该接口为API接口,用户可使用API指令创建一个对象存储设备,比如将云服务中的OBS数据桶作为对象存储设备,对模板云手机的目录进行存储,示例性的,创建对象存储设备的API指令(用户的第五输入)可以如下:
POST/share-stores/
{“bucket_id”:”…”}
从而创建好改用的对象存储设备,然后可将模板云手机的目录进行打包压缩(比如压缩为tar.gz)并上传到上述OBS数据桶中。
同理,如果该接口为网页或者应用程序形态的console,示例性的,如图9所示,该console可向用户展示创建对象存储设备的部分配置选项,比如选择对象存储设备所处的数据中心为华北数据中心,选择所创建的对象存储设备的名称为对象存储设备1,选择对象存储设备的存储类别为标准存储等等,用户可通过拖拽本地文件至 “上传对象”栏进行存储,也可以点击图标添加文件,将模板云手机的目录导入至该对象存储设备中,最后点击上传按钮完成对象存储设备1的创建和模板云手机的目录的存储,其中,图9所示的配置内容可以是用户的第五输入和第七输入。应理解,图9所示的console界面用于举例说明,本申请不对此进行限定。
可选地,在提供网络共享文件配置接口之前,本申请提供的方法还包括:提供网络共享文件创建接口,网络共享文件创建接口用于根据用户的第六输入创建网络共享文件。其中,第六输入可以是创建网络共享文件的指令以及对网络共享文件的配置信息,比如网络共享文件的存储容量、文件系统的类型等等,本申请不作具体的限定。
举例来说,云平台131向用户提供网络共享文件创建接口,假设该接口为API接口,用户可使用API指令创建一个网络共享文件,比如云服务中的SFS服务的实例,然后将上述OBS数据桶中的模板云手机的目录同步至该SFS实例中。示例性的,创建网络共享文件的API指令(用户的第六输入)可以如下:
POST/share-stores/{share_store_id}/instances
{“available_zone”:“…”,“name”:“…”}
应理解,使用上述API创建出来的SFS实例可自动同步对象存储设备中存储的模板云手机的目录,上述API指令用于举例说明,本申请不作具体限定。
同理,如果该接口为网页或者应用程序形态的console,示例性的,如图10所示,该console可向用户展示创建网络共享文件的部分配置选项,比如配置网络共享文件所处的数据中心为华北数据中心,设置网络共享文件的名称为网络共享文件1,配置协议类型为NFS协议,网络共享文件1的容量为500GB,网络共享文件1同步图9所示的对象存储设备1中的数据,即模板云手机的目录,最后点击创建按钮完成网络共享文件的创建,以及对对象存储设备的数据同步,其中,图10所示的配置内容可以是上述用户的第六输入、第二输入以及第四输入。应理解,图10所示的console界面用于举例说明,本申请不对此进行限定。
在一实施例中,云手机配置接口还用于根据用户的第三输入配置至少一个待配置云手机挂载网络共享文件以完成多个应用的安装。举例来说,假设该云手机配置接口为API接口,用户可使用API指令对待配置云手机进行配置,将待配置云手机挂载于上述例子中创建的SFS实例中,示例性的,上述API指令(用户的第三输入)可以如下:
POST/share-stores/{share_store_id}/instances/{id}/action
{“mount”:{“target”:”/data/share_app_center”}}
从系统角度上看,用户还可输入API指令查看挂载信息,显示类似如下:
#mount
{nfs export address}:/on/data/share_app_center type nfs(ro,vers=3,...)
应理解,上述API指令用于举例说明,本申请不作具体限定。
参考图2-图7实施例可知,本申请提供了两种挂载方式以实现上述至少一个待配置云手机挂载网络共享文件以完成多个应用的安装,下面分别对该两种挂载方式进行解释说明。
在一实施例中,可通过在待配置云手机中部署第一多层文件系统,对静态数据以 只读方式进行连接,使用多层文件系统对动态数据进行读写操作,从而实现对模板云手机目录的挂载,完成应用的安装运行和启动。
具体实现中,云手机配置接口,还用于根据用户的第三输入配置至少一个待配置云手机以只读方式连接第一网络共享文件中的第一安装目录;云手机配置接口,还用于根据用户的第三输入在至少一个待配置云手机配置第一多层文件系统,第一多层文件系统用于供至少一个待配置云手机对第二安装目录进行读写操作,其中,第一多层文件系统包括上层目录和下层目录,下层目录用于以只读映射的方式连接第二安装目录,上层目录用于存储至少一个待配置云手机中安装的应用运行过程中生成的修改数据,第一多层文件系统用于叠加上层目录和下层目录。其中,在待配置云手机中部署第一多层文件系统实现挂载的具体描述可参考前述图4A-图4B实施例,这里不重复赘述。
应理解,在云手机中部署第一多层文件系统实现应用挂载的方法中,上述第三输入可包括将待配置云手机以只读方式连接第一网络共享文件中的第一安装目录的指令,还可包括在待配置云手机中设置第一多层文件系统的指令,还可包括将第一多层文件系统中的上层目录存储修改数据,将下层目录与第一安装目录进行软连接的指令。举例来说,假设该云手机配置接口为API接口,用户可使用API指令对待配置云手机进行配置,将待配置云手机挂载于上述例子中创建的SFS实例中,示例性的,将待配置云手机以只读方式连接第一安装目录的API指令可以如下:
#cd/data/app/
#ln-s/data/share_app_center/{app_id}/app/{app_package}/data/app/{app_package}
用户可执行ls查看待配置云手机和第一安装目录之间的连接关系,显示类似如下:
#ls-l
drwxr-xr-x 1 system system 4096 2020-05-25 17:51{app_package}->/data/share_app_center/{app_id}/app/{app_package}
将待配置云手机中部署第一多层文件系统,其中第一多层文件系统的上层目录存储修改数据,下层目录与第二安装目录进行软连接的API指令可以如下:
#mount-t overlay-o
lowerdir=/sfs_dir/{app_id}/sdcard/{app_package},upperdir=/overlay/{app_package}/diff/,workdir=/overlay/{app_package}/work//overlay/{app_package}/merge/
#mount--bind/overlay/{app_package}/merge//sdcard/Android/data/{app_package}
该命令中设置了第二安装目录作为下层目录(即上述指令中的lowerdir)以只读的方式与待配置云手机进行连接,上层目录(即上述指令中的upperdir)用于存放修改数据,第一多层文件系统对上下层目录进行叠加,完成待配置云手机的应用安装。应理解,上述API指令用于举例说明,本申请不对此进行限定。
可选地,用户还可使用API命令将完成挂载的应用注册到待配置云手机的操作系统中,在待配置云手机中显示出应用图标,用户点击图标即可启动应用。将应用注册到待配置云手机操作系统的API命令可以如下:“#bash quick-reg.sh/data/app/{app_package}”。应理解,上述API命令用于举例说明,本申请不作具体 限定。
在一实施例中,在应用发生更新的情况下,云平台可接收用户通过console或者API输入的指令,实现应用的更新,具体的,用户可先在模板云手机中对应用进行更新,生成更新后的目标云手机的目录,然后压缩打包上传到对象存储设备中,对象存储设备将更新后的模板云手机的目录同步至共享网络文件,待配置云手机重新挂载待配置云手机即可实现应用的更新,示例性的,待配置云手机重新以只读方式对第一安装目录进行挂载的API可以如下:
#rm/data/app/{app_package}
#cd/data/app/
#ln-s/data/share_app_center/{app_id}/{version}/app/{app_package}/data/app/{app_packag e}
待配置云手机重新使用第一多层文件系统对第二安装目录进行挂载的API可以如下:
#umount/sdcard/Android/data/{app_package}
#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/
#mount--bind/overlay/{app_package}/merge//sdcard/Android/data/{app_package}
从而完成应用更新,整个更新过程中,对模板云手机进行新版本应用的安装即可,而无需再对用户购买的全部云手机进行应用的更新,使得应用更新效率得到提升,进而提高用户的使用体验。
在一实施例中,还可通过在网络共享文件中部署第二多层文件系统,对静态数据以只读方式进行连接,使用多层文件系统对动态数据进行读写操作,从而实现对模板云手机目录的挂载,完成应用的安装运行和启动。
具体实现中,网络共享文件配置接口,还用于根据用户的第三输入配置第一网络共享文件以只读方式连接第一网络共享文件中的第一安装目录;网络共享文件配置接口,还用于根据用户的第三输入在第一网络共享文件配置第二多层文件系统,第二多层文件系统用于接收并处理至少一个待配置云手机发送的数据读写请求,其中,第二多层文件系统包括上层目录和下层目录,下层目录用于以只读映射的方式连接第二安装目录,上层目录用于存储第一网络共享文件中安装的应用运行过程中生成的修改数据,第二多层文件系统用于叠加上层目录和下层目录。
参考图5A~图5B实施例可知,在待配置云手机启动App之前,可现在网络共享文件中创建一个内置有上述第二多层文件系统的空白目录1,并将其挂载到待配置云手机,作为其数据盘的根目录,然后再根据从对象存储下载获得的安装信息,创建一个拷贝目录,该拷贝目录中的目录结构和数据与安装信息中的目录结构和数据相同,并将空白目录1挂在于该拷贝目录中。这样,当待配置云手机运行该App时,待配置云手机可从挂载了拷贝目录的空白目录1读取数据,并将生成的修改数据通过空白目录1的第二多层文件系统写入该空白目录1。举例来说,在该网络共享文件配置接 口是API接口的情况下,示例性的,假设待配置云手机为C1,为待配置云手机创建作为根目录的空白目录的API可以如下:
POST/share-stores/{share_store_id}/instances/{id}/action
{“create”:{“path”:”/data_C1”}}
将空白目录挂载到待配置云手机C1,作为其数据盘根目录的API可以如下:
POST/share-stores/{share_store_id}/instances/{id}/action
{“mount”:{“path”:”/data_C1”,“target”:“/data”}}
可输入如下API查看挂载信息,显示类似如下:
#mount
{cpsfs address}:/data_C1on/data type cpsfs(rw,ver=1,...)
在网络共享文件中创建拷贝目录,挂载到待配置云手机C1的根目录中的API可以如下:
POST/share-stores/{share_store_id}/instances/{id}/action
{“copy_on_write”:{“src_path”:”/App_A_share/sdcard/App_A”,“dest_path”:“/data_C1/sdcard/Android/data/App_A”}}
基于此,待配置云手机C1即可挂载到网络共享文件,实现应用的安装、运行和更新,应理解,上述举例用于说明,本申请不作具体限定,并且,网络共享文件使用第二多层文件系统实现应用更新的方法与上述待配置云手机使用第一多层文件系统实现应用更新的方法类似,这里不再对应用更新的API进行重复举例说明。
在一实施例中,如果待配置云手机发生了资源迁移,模板云手机、至少一个待配置云手机、以及第一网络共享文件位于第一数据中心,在至少一个待配置云手机中的第一待配置云手机从第一数据中心迁移到第二数据中心的情况下,网络共享文件配置接口,还用于根据用户的第五输入,创建位于第二数据中心的第二网络共享文件,第二网络共享文件是第一网络共享文件的镜像。网络共享文件配置接口,还用于根据用户的第六输入,配置迁移到第一数据中心的第一待配置云手机挂载第二网络共享文件以完成多个应用的安装。简单来说,用户可以在位置发生变化后,通过API或者console创建第二数据中心的第二网络共享文件,并将迁移后的待配置云手机挂载到上述第二网络共享文件,从而使得用户地理位置发生变化时,用户数据不会丢失,提高用户的使用体验,上述过程具体可参考图6实施例,这里不重复赘述。
在一实施例中,在待配置云手机从第一数据中心的第一服务器迁移至第一数据中心的第二服务器的情况下,网络共享文件配置接口,用于配置第二服务器上的待配置云手机挂载网络共享文件以完成多个应用的安装,使得相同数据中心内待配置云手机的迁移时间缩短至秒级,提高云手机用户的使用体验。上述过程具体可参考图7实施例,这里不重复赘述。
在一实施例中,用户还可通过console或者API上传需安装的应用清单和待配置云手机的数量x,云平台根据用户上传的应用数量和应用清单,自动创建模版云手机、网络共享文件和对象存储设备,并在模版云手机上安装上述应用清单中的应用,再将模版云手机的目录导出至对象存储设备,网络共享文件同步该对象存储设备中的安装信息,配置x-1个云手机挂载于该网络共享文件,实现x-1个云手机安装应用清 单中应用,算上模板云手机,实现x个云手机安装应用清单中的应用的目的,整个云手机应用安装中用户的操作十分便捷,提升用户的使用体验。
综上可知,本申请提供的基于云手机的应用安装方法,无需在每一个云手机中安装应用,而是将应用的安装信息同步至网络共享文件中,云手机可从网络共享文件挂载各种应用的安装信息,从而在不提前安装应用的情况下,实现应用的启动、运行和更新,降低云手机的内存占用,降低云手机的运营维护成本,同时App的启动、运行和更新速度得以提升,提高用户的使用体验。
上述详细阐述了本申请实施例的方法,为了便于更好的实施本申请实施例上述方案,相应地,下面还提供用于配合实施上述方案的相关设备。
如图11所示,本申请提供了一种云平台131,包括提供云手机配置接口单元1110,提供对象存储创建接口单元1120,提供对象存储接口单元1130,提供网络共享文件创建接口单元1140以及提供网络共享文件配置接口单元1150。
提供云手机配置接口单元1110,用于提供云手机配置接口,云手机配置接口用于根据用户的第一输入配置模板云手机,模板云手机设置有多个应用,模板云手机的目录记录有多个应用的安装信息;提供网络共享文件配置接口单元1150,用于提供网络共享文件配置接口,网络共享文件配置接口用于根据用户的第二输入将模板云手机的目录存储至第一网络共享文件;其中,云手机配置接口还用于根据用户的第三输入配置至少一个待配置云手机挂载第一网络共享文件以完成多个应用的安装。
在一实施例中,提供对象存储接口单元1130,用于提供对象存储接口,对象存储接口用于根据用户的第四输入获取模板云手机的目录并将模板云手机的目录存储至对象存储设备中提供单元,用于提供对象存储接口;网络共享文件配置接口,用于根据用户的第二输入将对象存储设备存储的模板云手机的目录存储同步到第一网络共享文件。
在一实施例中,第一网络共享文件包括第一安装目录和第二安装目录,其中,第二安装目录包括多个应用的动态数据,第一安装目录包括多个应用的静态数据;云手机配置接口,还用于根据用户的第三输入配置至少一个待配置云手机以只读方式连接第一网络共享文件中的第一安装目录;云手机配置接口,还用于根据用户的第三输入在至少一个待配置云手机配置第一多层文件系统,第一多层文件系统用于供至少一个待配置云手机对第二安装目录进行读写操作,其中,第一多层文件系统包括上层目录和下层目录,下层目录用于以只读映射的方式连接第二安装目录,上层目录用于存储至少一个待配置云手机中安装的应用运行过程中生成的修改数据,第一多层文件系统用于叠加上层目录和下层目录。
在一实施例中,网络共享文件包括第一安装目录和第二安装目录,其中,第二安装目录包括多个应用的动态数据,第一安装目录包括多个应用的静态数据;网络共享文件配置接口,还用于根据用户的第三输入配置第一网络共享文件以只读方式连接第一网络共享文件中的第一安装目录;网络共享文件配置接口,还用于根据用户的第三输入在第一网络共享文件配置第二多层文件系统,第二多层文件系统用于接收并处理至少一个待配置云手机发送的数据读写请求,其中,第二多层文件系统包括上层目录 和下层目录,下层目录用于以只读映射的方式连接第二安装目录,上层目录用于存储第一网络共享文件中安装的应用运行过程中生成的修改数据,第二多层文件系统用于叠加上层目录和下层目录。
在一实施例中,第一网络共享文件位于第一数据中心,在待配置云手机位于第二数据中心的情况下,网络共享文件配置接口,还用于根据用户的第五输入,创建位于第二数据中心的第二网络共享文件,第二网络共享文件是第一网络共享文件的镜像。
在一实施例中,在待配置云手机从第一数据中心的第一服务器迁移至第一数据中心的第二服务器的情况下,网络共享文件配置接口,用于配置第二服务器上的待配置云手机挂载网络共享文件以完成多个应用的安装。
在一实施例中,提供网络共享文件创建接口单元1140,用于提供网络共享文件创建接口,网络共享文件创建接口用于根据用户的第六输入创建网络共享文件。
在一实施例中,提供对象存储创建接口单元1120,用于提供对象存储创建接口,对象存储创建接口用于根据用户的第七输入创建对象存储。
综上可知,本申请提供的云平台在对云手机进行应用安装时,无需在每一个云手机中安装应用,而是将应用的安装信息同步至网络共享文件中,云手机可从网络共享文件挂载各种应用的安装信息,从而在不提前安装应用的情况下,实现应用的启动、运行和更新,使得App在云手机的内存占用降低,可以大大降低云手机的运营维护成本,同时App的启动、运行和更新速度得以提升,提高用户的使用体验。
图12为本申请实施例提供的一种计算设备1200的结构示意图。其中,所述计算设备1200可以是图1-图11实施例中的云平台131。如图12所示,计算设备1200包括:处理器1210、通信接口1220以及存储器1230。其中,处理器1210、通信接口1220以及存储器1230可以通过内部总线1240相互连接,也可通过无线传输等其他手段实现通信。本申请实施例以通过总线1240连接为例,总线1240可以是外设部件互连标准(Peripheral Component Interconnect,PCI)总线或扩展工业标准结构(Extended Industry Standard Architecture,EISA)总线等。所述总线1240可以分为地址总线、数据总线、控制总线等。为便于表示,图12中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。
所述处理器1210可以由至少一个通用处理器构成,例如中央处理器(Central Processing Unit,CPU),或者CPU和硬件芯片的组合。上述硬件芯片可以是专用集成电路(Application-Specific Integrated Circuit,ASIC)、可编程逻辑器件(Programmable Logic Device,PLD)或其组合。上述PLD可以是复杂可编程逻辑器件(Complex Programmable Logic Device,CPLD)、现场可编程逻辑门阵列(Field-Programmable Gate Array,FPGA)、通用阵列逻辑(Generic Array Logic,GAL)或其任意组合。处理器1210执行各种类型的数字存储指令,例如存储在存储器1230中的软件或者固件程序,它能使计算设备1200提供较宽的多种服务。
所述存储器1230用于存储程序代码,并由处理器1210来控制执行,以执行上述图2-图10中任一实施例中云手机管理节点310的处理步骤。所述程序代码中可以包括一个或多个软件模块。这一个或多个软件模块可以为图12所示实施例中提供的软 件模块,如提供云手机配置接口单元、提供网络共享文件配置接口单元1150等等,其中,提供云手机配置接口单元用于提供云手机配置接口,云手机配置接口用于根据用户的第一输入配置模板云手机,模板云手机设置有多个应用,模板云手机的目录记录有多个应用的安装信息;提供网络共享文件配置接口单元用于提供网络共享文件配置接口,网络共享文件配置接口用于根据用户的第二输入将模板云手机的目录存储至第一网络共享文件,具体可用于执行前述方法的步骤S310~步骤S340、步骤S410-步骤S440及其可选步骤,还可以用于执行图3-图10实施例描述的其他由云平台131执行的步骤,这里不再进行赘述。
需要说明的是,本实施例可以是通用的物理服务器实现的,例如,ARM服务器或者X86服务器,也可以是基于通用的物理服务器结合NFV技术实现的虚拟机实现的,所述虚拟机指通过软件模拟的具有完整硬件系统功能的、运行在一个完全隔离环境中的完整计算机系统,本申请不作具体限定。
所述存储器1230可以包括易失性存储器(Volatile Memory),例如随机存取存储器(Random Access Memory,RAM);存储器1030也可以包括非易失性存储器(Non-Volatile Memory),例如只读存储器(Read-Only Memory,ROM)、快闪存储器(Flash Memory)、硬盘(Hard Disk Drive,HDD)或固态硬盘(Solid-State Drive,SSD);存储器1230还可以包括上述种类的组合。存储器1230可以存储有程序代码,具体可以包括用于执行图3-图10实施例描述的其他步骤的程序代码,这里不再进行赘述。
通信接口1220可以为有线接口(例如以太网接口),可以为内部接口(例如高速串行计算机扩展总线(Peripheral Component Interconnect express,PCIe)总线接口)、有线接口(例如以太网接口)或无线接口(例如蜂窝网络接口或使用无线局域网接口),用于与与其他设备或模块进行通信。
需要说明的,图12仅仅是本申请实施例的一种可能的实现方式,实际应用中,所述计算设备还可以包括更多或更少的部件,这里不作限制。关于本申请实施例中未示出或未描述的内容,可参见前述图3-图10所述实施例中的相关阐述,这里不再赘述。
应理解,图12所示的计算设备还可以是至少一个服务器构成的计算机集群,本申请不作具体限定。
本申请实施例还提供一种计算机可读存储介质,所述计算机可读存储介质中存储有指令,当其在处理器上运行时,图3-图10所示的方法流程得以实现。
本申请实施例还提供一种计算机程序产品,当所述计算机程序产品在处理器上运行时,图3-图10所示的方法流程得以实现。
上述实施例,可以全部或部分地通过软件、硬件、固件或其他任意组合来实现。当使用软件实现时,上述实施例可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括至少一个计算机指令。在计算机上加载或执行所述计算机程序指令时,全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以为通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一个计算机可读 存储介质传输,例如,所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(Digital Subscriber Line,DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含至少一个可用介质集合的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如,软盘、硬盘、磁带)、光介质(例如,高密度数字视频光盘(Digital Video Disc,DVD)、或者半导体介质。半导体介质可以是SSD。
以上所述,仅为本发明的具体实施方式,但本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到各种等效的修改或替换,这些修改或替换都应涵盖在本发明的保护范围之内。因此,本发明的保护范围应以权利要求的保护范围为准。

Claims (23)

  1. 一种基于云平台的云手机应用安装方法,其特征在于,包括:
    提供云手机配置接口,所述云手机配置接口用于根据用户的第一输入配置模板云手机,所述模板云手机设置有多个应用,所述模板云手机的目录记录有所述多个应用的安装信息;
    提供网络共享文件配置接口,所述网络共享文件配置接口用于根据所述用户的第二输入将所述模板云手机的目录存储至第一网络共享文件;
    其中,所述云手机配置接口还用于根据所述用户的第三输入配置至少一个待配置云手机挂载所述第一网络共享文件以完成所述多个应用的安装。
  2. 根据权利要求1所述的方法,其特征在于,
    所述提供网络共享文件配置接口之前,所述方法还包括:
    提供对象存储接口,所述对象存储接口用于根据所述用户的第四输入获取所述模板云手机的目录并将所述模板云手机的目录存储至对象存储设备中;则
    所述网络共享文件配置接口,具体用于根据所述用户的第二输入将所述对象存储设备存储的所述模板云手机的目录存储同步到所述第一网络共享文件。
  3. 根据权利要求1或2所述的方法,其特征在于,所述第一网络共享文件包括第一安装目录和第二安装目录,其中,所述第二安装目录包括所述多个应用的动态数据,所述第一安装目录包括所述多个应用的静态数据;
    所述云手机配置接口,还用于根据所述用户的第三输入配置所述至少一个待配置云手机以只读方式连接所述第一网络共享文件中的第一安装目录;
    所述云手机配置接口,还用于根据所述用户的第三输入在所述至少一个待配置云手机配置第一多层文件系统,所述第一多层文件系统用于供所述至少一个待配置云手机对所述第二安装目录进行读写操作,其中,所述第一多层文件系统包括上层目录和下层目录,所述下层目录用于以只读映射的方式连接所述第二安装目录,所述上层目录用于存储所述至少一个待配置云手机中安装的应用运行过程中生成的修改数据,所述第一多层文件系统用于叠加所述上层目录和所述下层目录。
  4. 根据权利要求1或2所述的方法,其特征在于,
    所述网络共享文件包括第一安装目录和第二安装目录,其中,所述第二安装目录包括所述多个应用的动态数据,所述第一安装目录包括所述多个应用的静态数据;
    所述网络共享文件配置接口,还用于根据所述用户的第三输入配置所述第一网络共享文件以只读方式连接所述第一网络共享文件中的第一安装目录;
    所述网络共享文件配置接口,还用于根据所述用户的第三输入在所述第一网络共享文件配置第二多层文件系统,所述第二多层文件系统用于接收并处理所述至少一个待配置云手机发送的数据读写请求,其中,所述第二多层文件系统包括上层目录和下层目录,所述下层目录用于以只读映射的方式连接所述第二安装目录,所述上层目录用于存储所述第一网络共享文件中安装的应用运行过程中生成的修改数据,所述第二多层文件系统用于叠加所述上层目录和所述下层目录。
  5. 根据权利要求4所述的方法,其特征在于,所述模板云手机、所述至少一个待配置云手机、以及所述第一网络共享文件位于第一数据中心,在所述至少一个待配置云手机中的第一待配置云手机从所述第一数据中心迁移到第二数据中心的情况下,
    所述网络共享文件配置接口,还用于根据所述用户的第五输入,创建位于第二数据中心的第二网络共享文件,所述第二网络共享文件是所述第一网络共享文件的镜像。
  6. 根据权利要求5所述的方法,其特征在于,
    所述网络共享文件配置接口,还用于根据所述用户的第六输入,配置迁移到所述第一数据中心的所述第一待配置云手机挂载所述第二网络共享文件以完成所述多个应用的安装。
  7. 根据权利要求1至6任一权利要求所述的方法,其特征在于,在所述提供网络共享文件配置接口之前,所述方法还包括:
    提供网络共享文件创建接口,所述网络共享文件创建接口用于根据所述用户的第六输入创建所述网络共享文件。
  8. 根据权利要求2所述的方法,其特征在于,在所述提供对象存储接口之前,所述方法还包括:
    提供对象存储创建接口,所述对象存储创建接口用于根据所述用户的第七输入创建所述对象存储。
  9. 根据权利要求1至8任一权利要求所述的方法,其特征在于,所述多层文件系统包括overlay文件系统。
  10. 根据权利要求1至9任一项权利要求所述的方法,其特征在于,所述模版云手机和所述待配置云手机包括虚拟机、容器和裸金属服务器。
  11. 根据权利要求1至10任一权利要求所述的方法,其特征在于,所述共享网络文件包括用户数据,所述用户数据包括所述应用运行期间产生的本地业务数据和本地习惯数据。
  12. 根据权利要求1至11任一项权利要求所述的方法,其特征在于,所述应用包括游戏应用、工作应用、教育应用、视频应用、社交应用和虚拟现实应用。
  13. 一种云平台,其特征在于,包括:
    提供云手机配置接口单元,用于提供云手机配置接口,所述云手机配置接口用于根据用户的第一输入配置模板云手机,所述模板云手机设置有多个应用,所述模板云手机的目录记录有所述多个应用的安装信息;
    提供网络共享文件配置接口单元,用于提供网络共享文件配置接口,所述网络共享文件配置接口用于根据所述用户的第二输入将所述模板云手机的目录存储至第一网络共享文件;
    其中,所述云手机配置接口还用于根据所述用户的第三输入配置至少一个待配置云手机挂载所述第一网络共享文件以完成所述多个应用的安装。
  14. 根据权利要求13所述的云平台,其特征在于,所述云平台还包括:
    提供对象存储接口单元,用于提供对象存储接口,所述对象存储接口用于根据所述用户的第四输入获取所述模板云手机的目录并将所述模板云手机的目录存储至对象存储设备中所述提供单元,用于提供对象存储接口;
    所述网络共享文件配置接口,用于根据所述用户的第二输入将所述对象存储设备存储的所述模板云手机的目录存储同步到所述第一网络共享文件。
  15. 根据权利要求13或14所述的云平台,其特征在于,所述第一网络共享文件包括第一安装目录和第二安装目录,其中,所述第二安装目录包括所述多个应用的动态数 据,所述第一安装目录包括所述多个应用的静态数据;
    所述云手机配置接口,还用于根据所述用户的第三输入配置至少一个待配置云手机以只读方式连接所述第一网络共享文件中的第一安装目录;
    所述云手机配置接口,还用于根据所述用户的第三输入在所述至少一个待配置云手机配置第一多层文件系统,所述第一多层文件系统用于供所述至少一个待配置云手机对所述第二安装目录进行读写操作,其中,所述第一多层文件系统包括上层目录和下层目录,所述下层目录用于以只读映射的方式连接所述第二安装目录,所述上层目录用于存储所述至少一个待配置云手机中安装的应用运行过程中生成的修改数据,所述第一多层文件系统用于叠加所述上层目录和所述下层目录。
  16. 根据权利要求14所述的云平台,其特征在于,
    所述网络共享文件包括第一安装目录和第二安装目录,其中,所述第二安装目录包括所述多个应用的动态数据,所述第一安装目录包括所述多个应用的静态数据;
    所述网络共享文件配置接口,还用于根据所述用户的第三输入配置所述第一网络共享文件以只读方式连接所述第一网络共享文件中的第一安装目录;
    所述网络共享文件配置接口,还用于根据所述用户的第三输入在所述第一网络共享文件配置第二多层文件系统,所述第二多层文件系统用于接收并处理所述至少一个待配置云手机发送的数据读写请求,其中,所述第二多层文件系统包括上层目录和下层目录,所述下层目录用于以只读映射的方式连接所述第二安装目录,所述上层目录用于存储所述第一网络共享文件中安装的应用运行过程中生成的修改数据,所述第二多层文件系统用于叠加所述上层目录和所述下层目录。
  17. 根据权利要求16所述的云平台,其特征在于,所述模板云手机、所述至少一个待配置云手机、以及所述第一网络共享文件位于第一数据中心,在所述至少一个待配置云手机中的第一待配置云手机从所述第一数据中心迁移到第二数据中心的情况下,
    所述网络共享文件配置接口,还用于根据所述用户的第五输入,创建位于第二数据中心的第二网络共享文件,所述第二网络共享文件是所述第一网络共享文件的镜像。
  18. 根据权利要求17所述的云平台,其特征在于,所述网络共享文件配置接口,还用于根据所述用户的第六输入,配置迁移到所述第一数据中心的所述第一待配置云手机挂载所述第二网络共享文件以完成所述多个应用的安装。
  19. 根据权利要求13至18任一权利要求所述的云平台,其特征在于,所述云平台还包括:
    提供网络共享文件创建接口单元,用于提供网络共享文件创建接口,所述网络共享文件创建接口用于根据所述用户的第六输入创建所述网络共享文件。
  20. 根据权利要求14所述的云平台,其特征在于,所述云平台还包括:
    提供对象存储创建接口单元,用于提供对象存储创建接口,所述对象存储创建接口用于根据所述用户的第七输入创建所述对象存储。
  21. 一种计算机可读存储介质,其特征在于,包括指令,当所述指令在计算设备上运行时,使得所述计算设备执行如权利要求1至12任一权利要求所述的方法。
  22. 一种计算设备,其特征在于,包括处理器和存储器,所述处理器执行所述存储器中的代码执行如权利要求1至12任一权利要求所述的方法。
  23. 一种计算机程序产品,其特征在于,包括计算机程序,当所述计算机程序被计算设备读取并执行时,使得所述计算设备执行如权利要求1至12任一权利要求所述的方法。
PCT/CN2021/092955 2020-08-11 2021-05-11 基于云手机的应用安装方法、云平台及相关设备 WO2022033090A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP21855146.3A EP4191401A4 (en) 2020-08-11 2021-05-11 CLOUD PHONE AND CLOUD PLATFORM-BASED APPLICATION INSTALLATION METHOD AND ASSOCIATED DEVICE
US18/167,587 US20230185556A1 (en) 2020-08-11 2023-02-10 Cloud-Phone-Based Application Installation Method, Cloud Platform, and Related Device

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
CN202010802212 2020-08-11
CN202010802212.7 2020-08-11
CN202011395057.8A CN114115912A (zh) 2020-08-11 2020-12-03 基于云手机的应用安装方法、云平台及相关设备
CN202011395057.8 2020-12-03

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/167,587 Continuation US20230185556A1 (en) 2020-08-11 2023-02-10 Cloud-Phone-Based Application Installation Method, Cloud Platform, and Related Device

Publications (1)

Publication Number Publication Date
WO2022033090A1 true WO2022033090A1 (zh) 2022-02-17

Family

ID=80247602

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/092955 WO2022033090A1 (zh) 2020-08-11 2021-05-11 基于云手机的应用安装方法、云平台及相关设备

Country Status (3)

Country Link
US (1) US20230185556A1 (zh)
EP (1) EP4191401A4 (zh)
WO (1) WO2022033090A1 (zh)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120005193A1 (en) * 2010-03-19 2012-01-05 Hitachi, Ltd. File-sharing system and method for processing files, and program
CN109683919A (zh) * 2018-12-24 2019-04-26 广州微算互联信息技术有限公司 云手机应用安装和卸载方法
CN110149375A (zh) * 2019-04-30 2019-08-20 广州微算互联信息技术有限公司 网络存储云手机间的数据共享方法、系统及存储介质
CN110417785A (zh) * 2019-07-31 2019-11-05 湖南微算互联信息技术有限公司 一种云手机游戏的安装方法、系统和存储介质
CN110913015A (zh) * 2019-12-12 2020-03-24 长沙摩智云计算机科技有限公司 一种云手机app的分布式快捷安装方法、系统及介质

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11044591B2 (en) * 2017-01-13 2021-06-22 Futurewei Technologies, Inc. Cloud based phone services accessible in the cloud by a remote device
CN110806911B (zh) * 2018-08-06 2022-09-13 中兴通讯股份有限公司 一种云桌面管控方法、装置及系统
CN109391688A (zh) * 2018-09-29 2019-02-26 郑州云海信息技术有限公司 云计算系统中镜像文件的获取方法和装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120005193A1 (en) * 2010-03-19 2012-01-05 Hitachi, Ltd. File-sharing system and method for processing files, and program
CN109683919A (zh) * 2018-12-24 2019-04-26 广州微算互联信息技术有限公司 云手机应用安装和卸载方法
CN110149375A (zh) * 2019-04-30 2019-08-20 广州微算互联信息技术有限公司 网络存储云手机间的数据共享方法、系统及存储介质
CN110417785A (zh) * 2019-07-31 2019-11-05 湖南微算互联信息技术有限公司 一种云手机游戏的安装方法、系统和存储介质
CN110913015A (zh) * 2019-12-12 2020-03-24 长沙摩智云计算机科技有限公司 一种云手机app的分布式快捷安装方法、系统及介质

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4191401A4 *

Also Published As

Publication number Publication date
US20230185556A1 (en) 2023-06-15
EP4191401A4 (en) 2024-01-10
EP4191401A1 (en) 2023-06-07

Similar Documents

Publication Publication Date Title
US10445147B1 (en) System and method for deploying virtual servers in a hosting system
JP6774499B2 (ja) オフラインでのハイブリッドアプリケーションへのアクセスの提供
JP5760088B2 (ja) スナップショットアーカイブの柔軟な格納および取り出しを提供するためのシステムおよび方法
US9946578B2 (en) Managing the persistent data of a pre-installed application in an elastic virtual machine instance
US11093148B1 (en) Accelerated volumes
US20210034423A1 (en) Container orchestration in decentralized network computing environments
US9607004B2 (en) Storage device data migration
US20160092119A1 (en) Data migration between different types of storage systems
US11803405B2 (en) Configurable virtual machines
US9405579B2 (en) Seamless extension of local computing power
US20140007092A1 (en) Automatic transfer of workload configuration
US11080041B1 (en) Operating system management for virtual workspaces
JP2016508349A (ja) クラスタ境界にわたるサービス移行
US11029932B2 (en) Hydration of applications
US11709692B2 (en) Hot growing a cloud hosted block device
TW202004514A (zh) 雲端服務之權限管理方法及其系統
US10742731B2 (en) Maintaining service configuration consistency across nodes of a clustered file system
WO2021135326A1 (zh) 一种数据备份方法、装置、设备及介质
Srinivasan et al. Google Cloud Platform for Architects: Design and manage powerful cloud solutions
CN114115912A (zh) 基于云手机的应用安装方法、云平台及相关设备
WO2022033090A1 (zh) 基于云手机的应用安装方法、云平台及相关设备
US11698755B1 (en) Physical hardware controller for provisioning dynamic storage services on processing devices
US11853783B1 (en) Identifying hosts for dynamically enabling specified features when resuming operation of a virtual compute instance
Hirway Hybrid Cloud for Developers: Develop and deploy cost-effective applications on the AWS and OpenStack platforms with ease
JP7493450B2 (ja) コンテナのグループの動的マイグレーション

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21855146

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2021855146

Country of ref document: EP

Effective date: 20230228

NENP Non-entry into the national phase

Ref country code: DE