云手机应用增量的更新方法、装置、设备、介质及产品与流程

1.本公开涉及数据处理领域，尤其涉及云计算技术领域，具体涉及一种云手机应用增量的更新方法、装置、设备、介质及产品。


背景技术：

2.在云手机组网中，一般由一个交换机对多台物理设备进行控制，在一台物理设备上可以部署多台云手机，实现多台云手机通过交换机与公网服务器进行连接。
3.由于云手机中应用会不定时进行资源更新升级，如果所有云手机设备同时对待更新应用进行资源更新，即同时向公网服务器请求获取更新资源，则会引发流量突升而导致网络卡顿，同时增加了用户等待应用资源更新的时长。


技术实现要素：

4.本公开提供了一种用于云手机应用增量的更新方法、装置、设备、介质及产品。
5.根据本公开的一方面，提供了一种云手机应用增量的更新方法，包括：
6.基于联合挂载服务，在目标云手机中创建挂载目录，并根据所述挂载目录执行挂载操作；其中，所述挂载目录包括容器可写层目录；
7.对目标应用进行更新得到所述容器可写层目录中记录的所述目标应用更新的增量文件；
8.解除挂载操作，根据所述增量文件确定所述目标应用的待更新文件；
9.向其他云手机发送所述待更新文件，用于指示所述其他云手机根据所述待更新文件对目标应用进行更新。
10.根据本公开的另一方面，提供了一种云手机应用增量的更新装置，包括：
11.应用挂载模块，用于基于联合挂载服务，在目标云手机中创建挂载目录，并根据所述挂载目录执行挂载操作；其中，所述挂载目录包括容器可写层目录；
12.应用更新模块，用于对目标应用进行更新得到所述容器可写层目录中记录的所述目标应用更新的增量文件；
13.更新文件确定模块，用于解除挂载操作，根据所述增量文件确定所述目标应用的待更新文件；
14.更新文件发送模块，用于向其他云手机发送所述待更新文件，用于指示所述其他云手机根据所述待更新文件对目标应用进行更新。
15.根据本公开的另一方面，提供了一种电子设备，包括：
16.至少一个处理器；以及
17.与所述至少一个处理器通信连接的存储器；其中，
18.所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行本公开中任一实施例所述的云手机应用增量的更新方法。
19.根据本公开的另一方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行根据本公开中任一实施例所述的云手机应用增量的更新方法。
20.根据本公开的另一方面，提供了一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现根据本公开中任一实施例所述的云手机应用增量的更新方法。
21.应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。
附图说明
22.附图用于更好地理解本方案，不构成对本公开的限定。其中：
23.图1是根据本公开实施例的一种云手机应用增量的更新方法的示意图；
24.图2是根据本公开实施例的overlayfs中挂载点、底层文件目录以及容器可写层目录的基本结构示意图
25.图3是根据本公开实施例的云手机组网的结构示意图；
26.图4是根据本公开实施例的另一种云手机应用增量的更新方法的示意图；
27.图5是根据本公开实施例的又一种云手机应用增量的更新方法的示意图；
28.图6是根据本公开实施例的一种云手机应用增量的更新装置的结构示意图；
29.图7是用来实现本公开实施例的云手机应用增量的更新方法的电子设备的框图。
具体实施方式
30.以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。
31.图1是根据本公开实施例的一种云手机应用增量的更新方法的示意图，本实施例可适用于对多个云手机中的应用批量更新的方法进行优化的情况，该方法可以通过云手机应用增量的更新装置执行，该装置可以通过软件和/或硬件的方式实现，并集成在电子设备中；本实施例中涉及到的电子设备可以为等本地服务器等具有通信和计算能力的设备。具体的，参考图1，该方法具体包括如下：
32.s110、基于联合挂载服务，在目标云手机中创建挂载目录，并根据挂载目录执行挂载操作；其中，挂载目录包括容器可写层目录。
33.其中，联合挂载服务是一种文件系统服务，面向其他文件系统的联合挂载，其主要机制涉及当两个文件系统提供同一名称的目录时目录访问的合并。示例性的，联合挂载服务可以基于overlayfs(overlay文件系统)进行实现，overlayfs是一种堆叠文件系统，其依赖并建立在其它的文件系统之上，并不直接参与磁盘空间结构的划分，仅仅将原来底层文件系统中不同的目录进行合并，然后向用户呈现。因此，对于用户来说，所见到的overlay文件系统根目录下的内容就来自挂载时所指定的不同目录的合集。挂载目录是指联合挂载服务中的所需要进行合并的目录，该挂载目录可以由用户进行指定。挂载操作是指对挂载目
录进行合并的操作。容器可写层目录是指可以进行读写的目录层，挂载过程中涉及到对合并目录的修改时，可以体现在该容器可写层目录中。示例性的，当基于overlayfs进行挂载操作时，容器可写层目录为upper目录。当用户向upper目录写入数据时，数据将直接写入upper目录下原来的文件中；当用户向不支持写操作的合并目录添加或修改内容时，添加和修改的内容也会体现在upper目录下。因此，通过挂载目录中的容器可写层目录可以实现在挂载过程中，实现对合并目录更新内容的获取，更新内容包括删除内容和增加内容等。
34.具体的，将云手机组网中任一连接公网服务器的云手机确定为目标云手机，在目标云手机上安装目标应用，该目标应用为未更新前的待更新应用。并将目标应用中涉及到应用资源数据存储的目录确定为需要合并的目录，即挂载目录，并创建一个容器可写层目录，由于容器可写层中目录中需要体现更新内容，则容器可写层目录在对目标应用更新前为空目录。基于联合挂载服务，对挂载目录执行挂载操作，即对挂载目录进行合并操作，以实现不同层目录中同名文件覆盖，修改操作体现在容器可写层目录中。示例性的，基于overlayfs进行挂载操作时，在目标云手机中创建一个新目录作为upper目录，即容器可写层目录，并将目标应用中需要进行应用资源合并的目录确定为挂载目录，进行挂载操作。
35.在本实施例的另一个可选实现方式中，挂载目录还包括底层文件目录；
36.在目标云手机中创建挂载目录，包括：
37.将目标应用的资源存储目录中的原始资源数据移动到底层文件目录中，并对资源存储目录进行清空；
38.将资源存储目录作为挂载点。
39.其中，底层文件目录是指不可写目录，用于存储目标应用的未更新前的原始资源数据，其中原始资源数据是目标应用在使用过程中所需要使用到的全部资源数据，示例性的，原始资源数据包括登录应用的相关账号和密码，配置、时间戳、资源包等数据以及资源包文件等。目标应用中的资源存储目录是指根据该应用具体启动设置的存储资源数据的目录，该目录可以为至少一个，根据该应用的实际情况进行设置，示例性的，资源存储目录可以为/data/data/${package_name}目录或者/sdcard/android/data/${package_name}目录，对于一般应用来说，默认将登录应用的相关账号和密码，配置、时间戳、资源包等数据存储到/data/data/${package_name}目录下，将应用下载时的资源包数据存储到/sdcard/android/data/${package_name}目录下，并且在后续更新时的更新文件也会默认存储在该目录下，有些应用更新时，会先将更新包下载在此目录中，然后解压到/data/data/${package_name}目录中，因此根据应用的实际情况，将这两个目录都作为资源存储目录。挂载点是指呈现合并结果的目，挂载点中文件的变化将体现在容器可写层目录中，示例性的，当基于overlayfs进行挂载操作时，底层文件目录为lower目录，挂载点为merge目录。
40.由于联合挂载服务中会将挂载目录中的文件进行合并，并将更新内容进行体现，需要先制作目标应用原始资源数据的母版数据，并保持该母版数据在后续更新过程中不受改变，因此创建不可写的底层文件目录，用于存储母版数据。
41.具体的，在目标云手机中创建空的不可写的底层文件目录以及可读写的容器可写层目录，确定目标云手机中存储目标应用全部资源数据的资源存储目录，并将资源存储目录中的原始资源数据拷贝到底层文件目录中作为母版数据，同时清空资源存储目录，将资源存储目录作为挂载点进行执行挂载操作。由于后续对目标应用进行更新时，按照目标应
用的设置原理更新的资源包将存储在资源存储目录中，因此将资源存储目录作为挂载点。示例性的，基于overlayfs进行挂载操作时，资源存储目录为/data/data/${package_name}目录，在目标云手机的/data/local/目录中创建lower目录和upper目录，将/data/data/${package_name}目录用cp-af方式完全拷贝到/data/local/lower目录中后，清空/data/data/${package_name}目录里面的文件，此时应用模板数据准备完毕，进入overlayfs挂载步骤。
42.通过在目标手机中创建底层文件目录和可读写的容器可写层目录作为挂载目录，并将目标应用的资源存储目录作为挂载点，将原始资源数据保存在底层文件目录中，挂载目录的设置既能实现对更新前母版数据的保存，又能实现后续更新后增量文件的自动确定，提高增量文件获取的准确性。
43.如图2所示为overlayfs中挂载点、底层文件目录以及容器可写层目录的基本结构示意图。其中，底层文件目录为lower dira和lower dirb目录，容器可写层目录为upper dir，挂载点为merge dir，lower dira/lower dirb目录和upper dir目录为来自目标云手机文件系统的不同目录，用户可以自行指定，内部包含了用户想要合并的文件和目录，merge dir目录为挂载点。当文件系统挂载后，在merge目录下会同时看到来自各lower和upper目录下的内容，并且用户无需感知这些文件分别哪些来自lower dir，哪些来自upper dir，用户看见的只是一个普通的文件系统根目录，其中，lower dir可以只有一个，也可以有多个。
44.虽然overlayfs将不同的各层目录进行合并，但是upper dir和各lower dir这几个不同的目录并不完全等价，存在层次关系。首先当upper dir和lower dir两个目录存在同名文件时，lower dir的文件将会被隐藏，用户只能看见来自upper dir的文件，然后各个lower dir也存在相同的层次关系，较上层屏蔽较下层的同名文件。除此之外，如果存在同名的目录就继续合并，其中，lower dir和upper dir合并到挂载点目录其实就是一个典型的合并例子。
45.upper dir是可读写的目录，当用户通过merge dir向其中一个来自upper dir的文件写入数据时，数据将直接写入upper dir下原来的文件中，删除文件也是同理。而各lower dir则是只读的，在overlayfs挂载后，无论如何操作merge目录中对应来自lower dir的文件或目录，lower dir中的内容均不会发生任何的改变。当用户对lower层的文件添加或修改内容时，overlayfs首先会拷贝一份lower dir中的文件副本到upper dir中，后续的写入和修改操作将会在upper dir下的副本文件中进行，而lower dir原文件被隐藏，不对用户展示，但其实仍然存在。
46.基于overlayfs最基本的特性：(1)上下层同名目录合并；(2)上下层同名文件覆盖；(3)lower dir文件写时拷贝。使用overlayfs对目标应用的挂载目录进行挂载，以实现在文件系统挂载时对应用更新准确提取更新的增量文件。
47.s120、对目标应用进行更新得到容器可写层目录中记录的目标应用更新的增量文件。
48.由于容器可写层目录是挂载目录中可以进行写入的目录层，而在基于联合挂载服务下对目标应用进行更新时，目标应用所更新的增量文件将直接写入容器可写层目录中，并且由于容器可写层目录在挂载之前为创建的空目录，因此在对目标应用更新完成后，容
器可写层目录中所存储的文件均为此次应用更新得到的增量文件。
49.具体的，在目标云手机中创建容器可写层目录和底层文件目录，并将底层文件目录作为母版资源数据的存储目录，在将目标应用的资源存储目录作为挂载点后，对目标应用进行更新，所更新的应用全部资源数据将存储在挂载点中，挂载点目录下的文件相较于底层文件目录中的文件产生变化的文件将直接体现在容器可写层目录中，即目标应用此次更新的增量文件。
50.示例性的，基于overlayfs进行挂载，底层文件目录为lower dir，容器可写层目录为upper dir，目标应用的资源存储目录为merge dir，基于上述对原始资源数据在lower dir中的保存操作，进行挂载操作。由于在overlayfs中，读upper dir没有而lower dir有的文件时，需从lower dir读；读只在upper dir有的文件时，则直接从upper dir读；读upper dir和lower dir都有的文件时，则直接从upper dir读。对只在upper dir有的文件时，则直接在upper dir写；对在upper dir和lower dir都有的文件时，则直接在upper dir写；对只在lower dir有的文件时，则会做一个copy-up操作，先从lower dir将文件拷贝一份副本到upper dir，后续的写入和修改操作都在副本中进行，而lower dir原文件不会被改变。删除upper dir和lower dir都有的文件时，upper dir的会被删除，并在upper dir创建一个whiteout文件，而lower dir的不会被删除；删除upper dir没有而lowerr dir有的文件时，会为被删除的文件在upper dir创建一个whiteout文件，而lower dir的不会被删除；删除upper dir和lower dir都有的目录时，upper dir的会被删除，并在upper dir创建一个类似whiteout文件的opaque目录，而lower dir的不会被删除。基于上述特性，在目标应用更新后，将更新后的全量资源文件解压到作为merge dir的资源存储目录下时，相当于比较于lower dir中的文件执行写入或删除操作，lower dir中存储的为更新前的原始资源数据，因此更新的增量文件将记录在upper dir中。
51.s130、解除挂载操作，根据增量文件确定目标应用的待更新文件。
52.应用更新时不仅涉及到对资源文件的添加还会涉及到对资源文件的移动或者删除操作，而基于联合挂载服务的特性，只要资源文件发生变化后，发生变化的文件都将体现在容器可写层中，因此在增量文件中将会存在不需要添加的文件，例如删除文件。
53.具体的，由于增量文件存储在容器可写层目录下，为了从增量文件中筛选出真正的目标应用的待更新文件需要对增量文件进行操作，因此在操作之前需要执行解除挂载操作，再根据联合挂载服务的特性从增量文件中筛选出此次更新删除的文件等，得到目标应用的待更新文件。
54.s140、向其他云手机发送待更新文件，用于指示其他云手机根据待更新文件对目标应用进行更新。
55.由于待更新文件是此次应用更新发生变化的文件，因此目标手机直接将该待更新文件发送给其他云手机，其他云手机直接根据该待更新文件对手机上的目标应用进行更新即可，避免了其他云手机向公网服务器发送资源更新请求带来的流量消耗。示例性的，在目标云手机上获取增量文件时，所创建的挂载目录的权限和所属根据目标云手机的目标应用所属进行设置，因此在将待更新文件发送至其他云手机上时，需要将文件数据的所属转成对应其他云手机的对应应用所属。
56.在本实施例的另一个可选实现方式中，向其他云手机发送待更新文件，包括：
57.将待更新文件通过局域网发送至与目标云手机处于同一局域网中的其他云手机中。
58.如图3所示为云手机组网的结构示意图，从图3中可知，在一个机房中的云手机组网中，每一个机箱内有4组设备，而每一组设备中可以部署n台物理设备，每一台物理设备可以部署m台云手机，一个机房由s个机箱组成云手机集群。那么，在一个机房中的云手机组网中所部署的理论最大云手机数为4*n*m*s台。当目标应用有资源更新时，如果所有云手机同时更新，即同时向公网服务器发送请求应用更新，公网服务器接收到请求后，向各云手机下发目标应用的更新资源，则可能会引发流量突升而导致网络卡顿，并增加了用户等待游戏应用资源更新的时长。
59.在本实施例的方案中，由云手机组网中的任一云手机作为目标云手机向公网服务器请求应用更新，公网服务器只需要向该一台设备发送更新资源即可，目标云手机获取到目标应用的待更新文件后，通过局域网将该待更新文件发送至其他云手机中，避免了多并发同时更新引发流量突升而导致网络卡顿的情况。
60.对于其他云手机组网中的云手机应用更新，可以采取本实施例的方案，或者由任一云手机组网作为目标云手机组网，由目标云手机组网中的目标云手机将待更新文件发送至其他云手机组网中的任一云手机上，以完成应用更新，在本公开中对此并不限制。
61.本实施例的方案，基于联合挂载服务获取目标云手机中目标应用的待更新文件，实现了目标应用资源更新增量文件的准确获取，并基于目标云手机确定的待更新文件通过在本地网络内部实现对其他云手机设备进行应用资源增量更新，避免了多并发同时更新引发流量突升而导致的网络卡顿情况，节省了用户等待应用资源更新的时长。
62.图4是根据本公开实施例的另一种云手机应用增量的更新方法的示意图，本实施例是对上述技术方案的进一步细化，本实施例中的技术方案可以与上述一个或者多个实施例中的各个可选方案结合。如图4所示，云手机应用增量的更新方法包括如下：
63.s410、基于联合挂载服务，在目标云手机中创建挂载目录，并根据挂载目录执行挂载操作；其中，挂载目录包括容器可写层目录和底层文件目录。
64.s420、对目标应用进行更新得到容器可写层目录中记录的目标应用更新的增量文件。
65.s430、解除挂载操作，根据增量文件和底层文件目录中的原始资源数据，确定增量文件中的中间移动文件。
66.其中，中间移动文件在更新过程中由原始路径移动到其他路径，且由其他路径返回原始路径。
67.由于在应用更新过程中，会存在文件移动现象，例如将文件从第一路径移动至第二路径，或者将文件从第一路径移动至第二路径，在从第二路径移动返回至第一路径。由于联合挂载服务的特性，只要文件移动了就相当于该文件发生了变更，就会体现在容器可写层目录中，例如将文件从第一路径移动至第二路径，相当于删除第一路径中的文件，在第二路径中添加该文件。对于移动前和移动后路径不一致时，则需要按照该操作对其他云手机中的文件进行操作，以保证更新前后文件所在路径相同。而对于移动前和移动后路径一致时，即由原始路径移动到其他路径，且由其他路径返回原始路径，由于文件本质上并没有任何改变，但是在增量文件中体现仍然是在原始路径和其他路径中删除和添加一次该文件。
若直接将该增量文件发送给其他云手机进行更新，则会导致在其他云手机上增加无效文件，导致资源浪费。因此需要从增量文件中筛选出该中间移动文件，对于中间移动文件，并不限制中间移动的其他路径的数量，只要保证移动前和移动后的路径一致即可。
68.由于文件移动只导致了路径的变化，并不引起文件内容的变化，因此可以通过对文件内容比对从增量文件中筛选中间移动文件。具体的，根据增量文件中各文件和底层文件目录中的原始资源数据中各文件的文件内容比对结果筛选中间移动文件。在进行文件内容比对前，需要进行文件路径对齐，根据文件路径对齐的结果筛选出路径一致的文件，再根据文件内容比对结果筛选出中间移动文件。
69.在本实施例的另一个可选实现方式中，根据增量文件和底层文件目录中的原始资源数据，确定增量文件中的中间移动文件，包括：
70.将增量文件中md5值与原始资源数据中任一文件md5值相同的文件确定为中间移动文件。
71.md5值等同于文件的id，其值是唯一的。因此通过文件的md5值确定中间移动文件有利于提高对更新过程中无效移动文件筛选的准确率，进而提高对增量文件中待更新文件确定的准确性和效率。
72.具体的，从容器可写层目录中导出全部增量文件的md5值，以及从底层文件目录中导出原始资源数据的md5值，对容器可写层目录和底层文件目录中的文件路径进行对齐，校对各文件的md5值，将md5值相同的和不同的文件分别进行转存，md5值相同的文件即为中间移动文件，md5值不同的文件即为增量文件中的此次更新带来的文件。
73.s440、删除增量文件中的中间移动文件，得到目标应用的待更新文件。
74.为了保证发送至其他云手机的文件中不存在移动文件，以避免其他云手机对无效文件的更新，需要从容器可写层目录下的增量文件中删除中间移动文件，得到目标应用的待更新文件。
75.示例性的，在上述示例的基础上，获取待更新文件前，首先在目标云手机上按照常规方式安装好待获取更新资源数据的目标应用，并且启动一次应用，以保证下载的资源数据保存在对应的资源存储目录中，然后退出应用。连接到云手机的控制台，执行停止应用操作，确保应用为停止状态。
76.在目标云手机的本地目录/data/local/目录中创建lower目录，权限为第一权限，该权限值根据目标云手机的目标应用进行适应性设置，在lower目录中创建apk_data、apk_sdcard目录，权限为第一权限；在/data/local/目录中创建upper和work目录，权限为第一权限。在upper目录中创建apk_data目录，权限和所属跟随/data/data/${package_name}目录，在upper目录中创建apk_sdcard目录，权限和所属跟随/sdcard/android/data/${package_name}目录。在work目录中创建apk_data目录，权限和所属跟随/data/data/${package_name}目录，在work目录中创建apk_sdcard目录，权限和所属跟随/sdcard/android/data/${package_name}目录。
77.将/data/data/${package_name}目录用cp-af方式完全拷贝到/data/local/lower/apk_data目录中后，清空/data/data/${package_name}目录里面的文件。将/sdcard/android/data/${package_name}目录用cp-af方式完全拷贝到/data/local/lower/apk_sdcard目录中后，清空/sdcard/android/data/${package_name}目录里面的文
件。应用母版原始资源数据准备完毕，进入overlayfs挂载步骤。
78.执行busybox mount-t overlay-o lowerdir＝/data/local/lower/apk_data/${package_name},upperdir＝/data/local/u pper/apk_data,workdir＝/data/local/work/apk_data overlay/data/data/${package_name}；以及执行busybox mount-t overlay-o lowerdir＝/data/local/lower/apk_sdcard/${package_name},upperdir＝/data/local/upper/apk_sdcard,workdir＝/data/local/work/apk_sdcard overlay/mnt/runtime/default/emulated/0/android/data/${package_name}。在执行以上命令后，母版原始资源数据挂载成功。
79.母版原始资源数据挂载成功，对目标应用进行更新并启动。依据overlayfs的特性，如有新的文件或目录生成，或原文件或目录被修改或删除时，将会在/data/local/upper/apk_data和/data/local/upper/apk_sdcard目录中体现出来，实现方便快捷的获取到目标应用的资源更新增量文件。
80.为保证upper中的文件是待更新文件，执行md5值比对操作，得到最终的待更新文件。首先执行应用停止操作，保证更新后的目标应用完全结束，然后解除挂载，由于可能存在文件或目录名中有空格的情况，用换行符做分割符。从/data/local/lower/apk_data和/data/local/lower/apk_sdcard中导出全部原始资源数据的md5值，并且从/data/local/upper中导出全部增量文件的md5值，对/data/local目录下的文件进行路径对齐。校对路径对齐后的文件的md5值，将相同的和不同的分别转存，相同的文件即为中间移动文件，不同的文件即为待更新文件。从增量文件的目录下删除与原始资源数据相同的文件。至此，/data/local/upper/apk_data和/data/local/upper/apk_sdcard目录中的文件为待更新文件。
81.另外的，在目标应用的资源存储目录下会存在保持用户账号等私有数据信息的目录，该信息根据不同云手机的不同使用用户进行设置，因此不需要作为增量文件，删除增量文件中保存用户私有数据目录下的文件，得到待更新文件。示例性的，/data/data/${package_name}目录中的app_webview、databases和shared_prefs三个目录一般保存的是用户账号等私有数据信息，如/data/local/upper/apk_data目录有这三个目录，可根据实际情况进行删除，不当成增量文件。
82.s450、向其他云手机发送待更新文件，用于指示其他云手机根据待更新文件对目标应用进行更新。
83.本实施例的方案，通过与原始资源数据进行比对确定增量文件中的中间移动文件，实现了对无效更新文件的筛选，提高了待更新文件确定的准确性；并将删除中间移动文件后的待更新文件发送至其他云手机，避免了其他云手机在根据待更新文件进行更新时对中间移动文件的更新带来的资源浪费，提高了其他云手机对目标应用更新的效率。
84.图5是根据本公开实施例的又一种云手机应用增量的更新方法的示意图，本实施例是对上述技术方案的进一步细化，本实施例中的技术方案可以与上述一个或者多个实施例中的各个可选方案结合。如图5所示，云手机应用增量的更新方法包括如下：
85.s510、基于联合挂载服务，在目标云手机中创建挂载目录，并根据挂载目录执行挂载操作；其中，挂载目录包括容器可写层目录。
86.s520、对目标应用进行更新得到容器可写层目录中记录的目标应用更新的增量文
件。
87.s530、解除挂载操作，确定增量文件中的删除格式文件；其中，删除格式文件为在目标应用更新过程中被删除的文件。
88.根据联合挂载服务的特性：删除容器可写层目录和底层文件目录都有的文件时，容器可写层目录的会被删除，并在容器可写层目录创建一个whiteout文件，而底层文件目录的不会被删除；删除容器可写层目录没有而底层文件目录有的文件时，会为被删除的文件在容器可写层目录创建一个whiteout文件，而底层文件目录的不会被删除；删除容器可写层目录和底层文件目录都有的目录时，容器可写层目录的会被删除，并在容器可写层目录创建一个类似whiteout文件的opaque目录，而底层文件目录的不会被删除。whiteout文件并非普通文件，而是主次设备号都为0的字符设备。示例性的，当用户在挂载点层通过ls命令来检查父目录的目录项时，overlayfs会自动过滤掉和whiteout文件自身以及和它同名的lower dir文件和目录，达到了隐藏文件的目的，让用户以为文件已经被删除了，但是实际whiteout文件仍然存在于upper dir中。
89.根据该特性，当目标应用在更新时会出现对原始资源数据中某文件进行删除的现象，因此删除文件将会以whiteout文件的格式出现在容器可写层的增量文件中。该删除格式文件并不属于需要其他云手机添加的更新文件，需要从其他云手机中进行删除，以保证其他云手机中目标应用的成功更新。
90.具体的，删除格式文件为根据联合挂载服务设置的特殊格式文件，因此可以通过该特殊格式直接从增量文件中进行确定。
91.s540、在增量文件中添加删除格式文件的文件删除路径，并从增量文件中删除该删除格式文件，得到目标应用的待更新文件。
92.由于删除格式文件为此次更新删除的文件，因此需要从增量文件中进行删除，以保证增量文件中文件的准确性。但是同时由于删除格式文件也需要从其他云手机中进行删除，因此在从增量文件中对该删除格式文件进行删除前，需要在增量文件中添加该删除格式文件的文件删除路径，以指示其他云手机根据该路径对删除格式文件对应的文件进行删除，根据删除后的增量文件以及添加了文件删除路径的增量文件生成最终的待更新文件。
93.示例性的，在上述示例的基础上，根据删除格式文件的文件删除路径生成txt文件，例如生成/data/local/c_apk_data_upper.txt和/data/local/c_apk_sdcard_upper.txt文件，作为待更新文件，并从母版原始资源数据中删除对应的文件。
94.s550、向其他云手机发送待更新文件，用于指示其他云手机根据待更新文件对目标应用进行更新。
95.向其他云手机发送待更新文件，其他云手机根据删除文件路径对目标应用对应的文件进行删除，再根据待更新文件中的其他增量文件对目标应用进行更新。
96.本实施例的方案，通过确定增量文件中的删除格式文件，实现了对另一种无效更新文件的筛选，提高了待更新文件确定的准确性；并将添加删除格式文件的文件删除路径的待更新文件发送至其他云手机，避免了其他云手机在根据待更新文件进行更新时对删除格式文件的漏删带来的存储资源浪费，提高了其他云手机对目标应用更新的效率和成功率。
97.图6是根据本公开实施例的一种云手机应用增量的更新装置的结构示意图，该装
置可以执行本公开任一实施例中涉及到的云手机应用增量的更新方法；参考图6，云手机应用增量的更新装置600，包括：应用挂载模块610、应用更新模块620、更新文件确定模块630以及更新文件发送模块640。
98.本实施例的方案，基于联合挂载服务获取目标云手机中目标应用的待更新文件，实现了目标应用资源更新增量文件的准确获取，并基于目标云手机确定的待更新文件通过在本地网络内部实现对其他云手机设备进行应用资源增量更新，避免了多并发同时更新引发流量突升而导致的网络卡顿情况，节省了用户等待应用资源更新的时长。
99.在本实施例的一个可选实现方式中，所述挂载目录还包括底层文件目录；
100.应用挂载模块包括挂载目录创建单元，用于：
101.将所述目标应用的资源存储目录中的原始资源数据移动到所述底层文件目录中，并对所述资源存储目录进行清空；
102.将所述资源存储目录作为挂载点。
103.在本实施例的一个可选实现方式中，更新文件确定模块，包括：
104.移动文件确定单元，用于根据所述增量文件和所述底层文件目录中的原始资源数据，确定所述增量文件中的中间移动文件；其中，所述中间移动文件在更新过程中由原始路径移动到其他路径，且由其他路径返回原始路径；
105.移动文件删除单元，用于删除所述增量文件中的中间移动文件，得到所述目标应用的待更新文件。
106.在本实施例的一个可选实现方式中，移动文件确定单元，具体用于：
107.将所述增量文件中md5值与所述原始资源数据中任一文件md5值相同的文件确定为中间移动文件。
108.在本实施例的一个可选实现方式中，更新文件确定模块，包括：
109.删除文件确定单元，用于确定所述增量文件中的删除格式文件；其中，所述删除格式文件为在所述目标应用更新过程中被删除的文件；
110.文件路径添加单元，用于在所述增量文件中添加所述删除格式文件的文件删除路径，并从所述增量文件中删除所述删除格式文件，得到所述目标应用的待更新文件。
111.在本实施例的一个可选实现方式中，更新文件发送模块，具体用于：
112.将所述待更新文件通过局域网发送至与所述目标云手机处于同一局域网中的其他云手机中。
113.上述云手机应用增量的更新装置可执行本公开任意实施例所提供的云手机应用增量的更新方法，具备执行方法相应的功能模块和有益效果。未在本实施例中详尽描述的技术细节，可参见本公开任意实施例提供的云手机应用增量的更新方法。
114.本公开的技术方案中，所涉及的用户个人信息的收集、存储、使用、加工、传输、提供和公开等处理，均符合相关法律法规的规定，且不违背公序良俗。
115.根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。
116.图7示出了可以用来实施本公开的实施例的示例电子设备700的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种
形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。
117.如图7所示，设备700包括计算单元701，其可以根据存储在只读存储器(rom)702中的计算机程序或者从存储单元708加载到随机访问存储器(ram)703中的计算机程序，来执行各种适当的动作和处理。在ram 703中，还可存储设备700操作所需的各种程序和数据。计算单元701、rom 702以及ram 703通过总线704彼此相连。输入/输出(i/o)接口705也连接至总线704。
118.设备700中的多个部件连接至i/o接口705，包括：输入单元706，例如键盘、鼠标等；输出单元707，例如各种类型的显示器、扬声器等；存储单元708，例如磁盘、光盘等；以及通信单元709，例如网卡、调制解调器、无线通信收发机等。通信单元709允许设备700通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。
119.计算单元701可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元701的一些示例包括但不限于中央处理单元(cpu)、图形处理单元(gpu)、各种专用的人工智能(ai)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(dsp)、以及任何适当的处理器、控制器、微控制器等。计算单元701执行上文所描述的各个方法和处理，例如云手机应用增量的更新方法。例如，在一些实施例中，云手机应用增量的更新方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元708。在一些实施例中，计算机程序的部分或者全部可以经由rom 702和/或通信单元709而被载入和/或安装到设备700上。当计算机程序加载到ram 703并由计算单元701执行时，可以执行上文描述的云手机应用增量的更新方法的一个或多个步骤。备选地，在其他实施例中，计算单元701可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行方法云手机应用增量的更新。
120.本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(fpga)、专用集成电路(asic)、专用标准产品(assp)、芯片上系统的系统(soc)、负载可编程逻辑设备(cpld)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。
121.用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。
122.在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电
子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦除可编程只读存储器(eprom或快闪存储器)、光纤、便捷式紧凑盘只读存储器(cd-rom)、光学储存设备、磁储存设备、或上述内容的任何合适组合。
123.为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，crt(阴极射线管)或者lcd(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。
124.可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(lan)、广域网(wan)、区块链网络和互联网。
125.计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，也可以为分布式系统的服务器，或者是结合了区块链的服务器。
126.应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。
127.上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。