一种应用程序更新的方法及装置与流程

1.本技术涉及计算机技术领域，具体涉及了一种应用程序更新的方法及装置。


背景技术：

2.目前，采用跨平台移动应用开发框架(react native，rn)进行开发的应用程序(即react native应用)在启动后，会自动地从服务器中获最新的react native代码包，用以更新本地的react native代码包。但是，在目前的更新react native代码包的方法中，采用的是全量更新的模式，即需要将react native应用的全部代码进行下载后再全部更新。这样的更新方法过多的消耗了服务器资源以及用户的流量。并且，在客户端获取更新react native代码包时，会直接获取最新版本的代码包，可能与客户端中react native应用版本不匹配，导致更新异常的问题。


技术实现要素：

3.本技术提供一种应用程序更新的方法及装置，用以解决应用程序更新时资源占用过多、更新异常等的问题。
4.第一方面，本技术提供一种应用程序更新的方法，应用于客户端，所述客户端安装有目标应用，其中所述目标应用为基于跨平台移动应用开发框架rn开发的应用，所述目标应用的程序包包括业务包和基础包两种类型；所述方法包括：所述客户端向服务端发送第一请求消息，所述第一请求消息携带：所述目标应用对应的最新第一业务包的版本号；或者，所述目标应用的本地版本号、以及所述目标应用对应的本地第一业务包的版本号；所述客户端接收来自所述服务端的第一响应，所述第一响应中携带所述最新第一业务包；使用所述最新第一业务包更新所述本地第一业务包。
5.通过本方案，客户端可以对目标应用中的业务包代码单独进行更新，节省了服务器资源以及用户流量。并且，客户端将自身需求的第一业务包的版本号发送至服务端，有效地避免了客户端获取到的第一业务包与目标应用的本地版本不匹配的问题。或者，客户端将目标应用的本地版本号以及本地第一业务包的版本号发送至服务端，使得服务端可以发送与客户端将目标应用的本地版本相对应的最新第一业务包至客户端，同样避免了发送至客户端的第一业务包与目标应用的本地版本不匹配的问题。
6.可选的，在所述客户端向所述服务端发送所述第一请求消息之前，所述方法还包括：所述客户端根据所述目标应用的本地版本号、所述目标应用对应的本地第一业务包的版本号、以及第一映射关系，确定所述本地第一业务包需要更新；其中，所述第一映射关系包含所述目标应用的本地版本号、以及所述目标应用的本地版本号对应的所述最新第一业务包的版本号。
7.在本方式中，客户端可以通过第一映射关系对本地第一业务包进行更新判断，在确认本地第一业务包需要进行更新时，直接向服务端发送客户端所需要的第一业务包的版本号，可以提高第一业务包的更新效率以及更新准确性。
8.可选的，在所述客户端确定所述本地第一业务包需要更新之前，所述方法还包括：所述客户端向所述服务端发送第二请求消息，所述第二请求消息用于请求获取所述第一映射关系；所述客户端接收来自所述服务端的第二响应，所述第二响应中携带所述第一映射关系；所述客户端保存所述第一映射关系。
9.在本方式中，客户端从服务端获取第一映射关系，进而用以对本地第一业务包进行更新判断，提高了应用程序更新的准确性。
10.可选的，在所述客户端确定所述本地第一业务包需要更新之前，所述方法还包括：所述客户端从所述目标应用对应的本地配置文件中读取所述目标应用的本地版本号、以及所述目标应用对应的本地第一业务包的版本号；或者，所述客户端从本地保存的第二映射关系中读取所述目标应用的本地版本号、以及所述目标应用对应的本地第一业务包的版本号，其中所述第二映射关系包含所述目标应用的本地版本号、以及所述目标应用对应的本地第一业务包的版本号。
11.在本方式中，客户端以不同的方式对第一业务包进行更新判断，提高了本方案的灵活性。
12.可选的，在所述客户端向所述服务端发送所述第一请求消息之前，所述方法还包括：所述客户端根据所述目标应用的本地版本号、所述目标应用对应的本地第一基础包的版本号、以及第三映射关系，确定所述本地第一基础包是否需要更新；其中，所述第三映射关系包含所述目标应用的本地版本号、以及所述目标应用的本地版本号对应的最新第一基础包的版本号。若所述本地第一基础包需要更新，则从所述服务端获取所述目标应用对应的最新第一基础包，并基于所述最新第一基础包更新所述本地第一基础包。
13.在本方式中，客户端单独更新第一基础包，节省了服务端资源以及用户流量。同时，客户端基于第三映射关系、目标应用的本地版本以及本地第一基础包的版本号对本地第一基础包进行更新，有效地避免了目标应用的本地版本与获取到的第一基础包的版本不匹配的问题。
14.可选的，所述客户端向所述服务端发送第三请求消息，所述第三请求消息携带：所述目标应用对应的最新第二业务包的版本号；或者，所述目标应用的本地版本号、以及所述目标应用对应的本地第二业务包的版本号；所述客户端接收来自所述服务端的第三响应，所述第三响应中携带所述最新第二业务包。
15.在本方式中，客户端单独更新第二业务包，使得目标应用的代码更新更具针对性，提高了目标应用的更新效率。
16.可选的，所述客户端发送所述第一请求消息，包括：在所述目标应用被启动后的预设时间范围内，向所述服务端发送所述第一请求消息。
17.可选的，所述基础包中的第一代码在所述目标应用对应的所有程序包中的重复率超过设定阈值。
18.在本方式中，重复率超过设定阈值的代码文件多为程序包中的基础文件，这样的代码文件更新频率较低，将该部分代码文件打包为基础包，可以提高应用程序更新的针对性，避免浪费服务器资源，节省用户流量。
19.第二方面，本技术提供一种应用程序更新的方法，应用于服务端，所述服务端保存有目标应用对应的程序包，其中所述目标应用为基于rn开发框架开发的应用，所述目标应
用对应的程序包包括业务包和基础包两种类型；所述方法包括：所述服务端接收来自客户端的第一请求消息，所述第一请求消息携带：所述目标应用对应的最新第一业务包的版本号；或者，所述目标应用的本地版本号、以及所述目标应用对应的本地第一业务包的版本号；所述服务端响应于所述第一请求消息，向所述客户端发送第一响应，所述第一响应中携带所述最新第一业务包。
20.在本方案中，服务端基于目标应用对应的最新第一业务包的版本号或目标应用的本地版本号向客户端发送最新第一业务包，确保了所发送的第一业务包与客户端中的目标应用的本地版本相匹配，并且，单独更新第一业务包，节省了服务端的资源也节省了用户流量。
21.可选的，在所述服务端接收来自所述客户端的所述第一请求消息之前，所述方法还包括：所述服务端获取所述目标应用对应的最新第一业务包；所述服务端将所述目标应用的版本号与所述最新第一业务包的版本号的对应关系保存至第一映射关系；和/或，所述服务端获取所述目标应用对应的最新第一基础包；所述服务端将所述目标应用的版本号与所述最新第一基础包的版本号的对应关系保存至第二映射关系。
22.通过本方式，服务器可以及时更新第一映射关系和/或第二映射关系，为后续应用程序更新的准确性提供了基础。
23.可选的，在接收所述第一请求消息之前，所述服务端接收来自所述客户端的第二请求消息，其中所述第二请求消息用于请求获取所述第一映射关系；所述服务端将所述第一映射关系发送至所述客户端。
24.可选的，所述第一请求消息携带所述目标应用的本地版本号、以及所述目标应用对应的本地第一业务包的版本号；所述服务端向所述客户端发送第一响应，包括：所述服务端根据所述第一映射关系、所述目标应用的本地版本号、以及所述目标应用对应的本地第一业务包的版本号，判断所述本地第一业务包是否需要更新；若需要更新，所述服务端向所述客户端发送所述第一响应。
25.通过本方式，由服务端判断本地第一业务包是否需要更新，客户端只需要向服务端发送目标应用的本地版本号以及目标应用对应的本地第一业务包的版本号，节省了用户流量，也提高了应用更新的准确性。
26.可选的，所述服务端接收来自所述客户端的第三请求消息，所述第三请求消息携带：所述目标应用对应的最新第二业务包的版本号；所述服务端响应于所述第三请求消息，向所述客户端发送第三响应，所述第三响应中携带所述最新第二业务包；或者，所述服务端接收来自所述客户端的所述第三请求消息，所述第三请求消息携带：所述目标应用的本地版本号、以及所述目标应用对应的本地第二业务包的版本号；所述服务端响应于所述第三请求消息，根据所述目标应用的本地版本号、所述目标应用对应的本地第二业务包的版本号、以及第四映射关系，判断所述目标应用对应的本地第二业务包是否需要更新，若所述本地第二业务包需要更新，则所述服务端向所述客户端发送所述第三响应；其中，所述第四映射关系包含所述目标应用的本地版本号、以及所述目标应用的本地版本号对应的所述最新第二业务包的版本号。
27.通过本方式，单独更新客户端中本地第二业务包，提高了应用程序更新的针对性以及更新效率。
28.可选的，所述基础包中的第一代码在所述目标应用对应的所有程序包中的重复率超过设定阈值。
29.在本方式中，重复率超过设定阈值的代码文件多为程序包中的基础文件，这样的代码文件更新频率较低，将该部分代码文件打包为基础包，可以提高应用程序更新的针对性，避免浪费服务器资源，节省用户流量。
30.第三方面，本技术提供一种应用程序更新的装置，应用于客户端，所述客户端安装有目标应用，其中所述目标应用为基于跨平台移动应用开发框架rn开发的应用，所述目标应用的程序包包括业务包和基础包两种类型；所述装置包括：第一发送模块，用于向服务端发送第一请求消息，所述第一请求消息携带：所述目标应用对应的最新第一业务包的版本号；或者，所述目标应用的本地版本号、以及所述目标应用对应的本地第一业务包的版本号；第一接收模块，用于接收来自所述服务端的第一响应，所述第一响应中携带所述最新第一业务包；使用所述最新第一业务包更新所述本地第一业务包。
31.可选的，所述第一发送模块还用于根据所述目标应用的本地版本号、所述目标应用对应的本地第一业务包的版本号、以及第一映射关系，确定所述本地第一业务包需要更新；其中，所述第一映射关系包含所述目标应用的本地版本号、以及所述目标应用的本地版本号对应的所述最新第一业务包的版本号。
32.可选的，所述第一发送模块还用于向所述服务端发送第二请求消息，所述第二请求消息用于请求获取所述第一映射关系；所述第一接收模块还用于接收来自所述服务端的第二响应，所述第二响应中携带所述第一映射关系；保存所述第一映射关系。
33.可选的，所述第一发送模块还用于从所述目标应用对应的本地配置文件中读取所述目标应用的本地版本号、以及所述目标应用对应的本地第一业务包的版本号；或者，从本地保存的第二映射关系中读取所述目标应用的本地版本号、以及所述目标应用对应的本地第一业务包的版本号，其中所述第二映射关系包含所述目标应用的本地版本号、以及所述目标应用对应的本地第一业务包的版本号。
34.可选的，所述第一发送模块还用于根据所述目标应用的本地版本号、所述目标应用对应的本地第一基础包的版本号、以及第三映射关系，确定所述本地第一基础包是否需要更新；其中，所述第三映射关系包含所述目标应用的本地版本号、以及所述目标应用的本地版本号对应的最新第一基础包的版本号；若所述本地第一基础包需要更新，则从所述服务端获取所述目标应用对应的最新第一基础包，并基于所述最新第一基础包更新所述本地第一基础包。
35.可选的，所述第一发送模块还用于向所述服务端发送第三请求消息，所述第三请求消息携带：所述目标应用对应的最新第二业务包的版本号；或者，所述目标应用的本地版本号、以及所述目标应用对应的本地第二业务包的版本号；所述第一接收模块还用于接收来自所述服务端的第三响应，所述第三响应中携带所述最新第二业务包。
36.可选的，所述第一发送模块发送用于发送所述第一请求消息，包括：在所述目标应用被启动后的预设时间范围内，向所述服务端发送所述第一请求消息。
37.可选的，所述基础包中的第一代码在所述目标应用对应的所有程序包中的重复率超过设定阈值。
38.第四方面，本技术提供一种应用程序更新的装置，应用于服务端，所述服务端保存
有目标应用对应的程序包，其中所述目标应用为基于rn开发框架开发的应用，所述目标应用对应的程序包包括业务包和基础包两种类型；所述装置包括：第二接收模块，用于接收来自客户端的第一请求消息，所述第一请求消息携带：所述目标应用对应的最新第一业务包的版本号；或者，所述目标应用的本地版本号、以及所述目标应用对应的本地第一业务包的版本号；第二发送模块，用于响应于所述第一请求消息，向所述客户端发送第一响应，所述第一响应中携带所述最新第一业务包。
39.可选的，所述第二接收模块接收来自所述客户端的所述第一请求消息之前，还用于获取所述目标应用对应的最新第一业务包；将所述目标应用的版本号与所述最新第一业务包的版本号的对应关系保存至第一映射关系；和/或，取所述目标应用对应的最新第一基础包；将所述目标应用的版本号与所述最新第一基础包的版本号的对应关系保存至第二映射关系。
40.可选的，在接收所述第一请求消息之前，所述第二接收模块还用于接收来自所述客户端的第二请求消息，其中所述第二请求消息用于请求获取所述第一映射关系；所述第二发送模块还用于将所述第一映射关系发送至所述客户端。
41.可选的，所述第一请求消息携带所述目标应用的本地版本号、以及所述目标应用对应的本地第一业务包的版本号；所述第二发送模块用于向所述客户端发送第一响应，所述第二发送模块还用于根据所述第一映射关系、所述目标应用的本地版本号、以及所述目标应用对应的本地第一业务包的版本号，判断所述本地第一业务包是否需要更新；若需要更新，向所述客户端发送所述第一响应。
42.可选的，所述第二接收模块还用于接收来自所述客户端的第三请求消息，所述第三请求消息携带：所述目标应用对应的最新第二业务包的版本号；所述服务端响应于所述第三请求消息，向所述客户端发送第三响应，所述第三响应中携带所述最新第二业务包；或者，接收来自所述客户端的所述第三请求消息，所述第三请求消息携带：所述目标应用的本地版本号、以及所述目标应用对应的本地第二业务包的版本号；所述服务端响应于所述第三请求消息，根据所述目标应用的本地版本号、所述目标应用对应的本地第二业务包的版本号、以及第四映射关系，判断所述目标应用对应的本地第二业务包是否需要更新，若所述本地第二业务包需要更新，则所述服务端向所述客户端发送所述第三响应；其中，所述第四映射关系包含所述目标应用的本地版本号、以及所述目标应用的本地版本号对应的所述最新第二业务包的版本号。
43.可选的，所述基础包中的第一代码在所述目标应用对应的所有程序包中的重复率超过设定阈值。
44.第五方面，本技术提供一种电子设备，包括：至少一个处理器；以及与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述至少一个处理器通过执行所述存储器存储的指令，使得所述装置通过执行第一方面或第一方面任一种可选的实施、第二方面或第二方面任一可选的实施方式中任一项所述的方法。
45.第六方面，提供一种计算机可读存储介质，用于存储指令，当所述指令被执行时，使上述第一方面或第一方面任一可选的实施方式、第二方面或第二方面任一可选的实施方式中任一项所述的方法被实现。
46.本技术实施例中第三、第四、第五以及第六方面中提供的一个或多个技术方案所具有的技术效果或优点，均可以由第一方面、第二方面中提供的对应的一个或多个技术方案所具有的技术效果或优点对应解释。
附图说明
47.为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
48.图1是本技术实施例提供的一种应用程序更新的方法的流程图；
49.图2是本技术实施例提供的另一种应用程序更新的方法的流程图；
50.图3是本技术实施例提供的一种映射关系的表现形式的示意图；
51.图4是本技术实施例提供的一种应用程序更新的装置的结构图；
52.图5是本技术实施例提供的另一种应用程序更新的装置的结构图；
53.图6是本技术实施例提供的一种电子设备的结构图。
具体实施方式
54.下面通过附图以及具体实施例对本技术技术方案做详细的说明，应当理解本技术实施例以及实施例中的具体特征是对本技术技术方案的详细的说明，而不是对本技术技术方案的限定，在不冲突的情况下，本技术实施例以及实施例中的技术特征可以相互组合。
55.需要理解的是，在本技术实施例的描述中，“第一”、“第二”等词汇，仅用于区分描述的目的，而不能理解为指示或暗示相对重要性，也不能理解为指示或暗示顺序。在本技术实施例的描述中“多个”，是指两个或两个以上。
56.本技术实施例中的术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
57.react native是一种跨平台移动应用开发框架，支持ios和安卓两大平台。通过该开发框架开发的应用程序，当应用程序进行更新时，会从服务端获取最新的全量代码包，用以更新应用程序在客户端本地的代码包。而这样全量更新的模式，会过多消耗服务器资源同时也过多消耗了用户的流量。并且，在客户端获取待更新的react native代码包时，会直接获取最新版本的代码包，但客户端中目标应用版本不一定是最新，因此更新后的代码包可能与客户端中目标应用版本不匹配，导致更新异常。
58.因此，在本技术中提出一种应用程序的更新方法，用以解决上述一个或多个问题。
59.参见图1，为本技术实施例提供的一种应用程序的更新方法的流程图，其具体实施步骤如下：
60.s101：客户端向服务端发送第一请求，该第一请求携带目标应用对应的最新第一业务包的版本号；服务端接收该第一请求。
61.通过react native开发框架进行开发的应用程序，支持将应用程序代码进行分包处理。
62.可选的，在本技术实施例中，目标应用的开发人员在将应用代码上传至服务端前可以将目标应用的代码包可以拆分为基础包和业务包两个部分，或者，开发人员将目标应用的完整代码包上传至服务端，由服务端将目标应用的代码包拆分为基础包和业务包。而如何将目标应用的完整代码包进行拆分，可以依据如下判断条件。
63.应明确，在一个完整的react native应用中，通常会包括能够实现不同类型功能的业务线。例如，在一个购物应用程序中，搭建商品购买界面的代码文件可以是一个业务线，而商品购买流程所需的代码文件可以是另一个业务线。
64.基于此，在进行代码文件拆包时，可以按照以下逻辑进行拆分：首先，将所有代码文件按照其所完成的不同业务进行拆分，得到多个业务包，此时，这多个业务包之和即为目标应用完整的代码包。其次，获取在这多个业务包中重复出现率达到预设阈值的代码文件，将这些文件进行打包得到基础包。这一部分的代码文件多为程序中的基础文件，适用性广，更新频率低，将该部分代码文件单独拆分，可以有效地避免后续更新过程中，因全量更新导致基础包中的代码文件重复无效更新的情况。最后，将目标应用的完整代码包中基础包包括的代码文件剔除，则可以得到最终的业务包。
65.应理解，本技术对业务包的数量、基础包的数量不做限制。
66.在一种可能的实施方式中，目标应用的完整代码包可以拆分为一个基础包和一个业务包，如第一基础包和第一业务包，其中，基础包中所包含的代码文件是在目标应用中的代码中重复出现率达到预设阈值的代码，业务包包含的则是目标应用代码除基础包以外的全部代码。
67.在另一种可能的实现方式中，目标应用的完整代码包可以拆分为一个基础包和多个业务包，如第一基础包、第一业务包以及第二业务包。具体的，在将基础包拆分完成后，业务包可以根据代码所完成的功能的不同，继续进行拆分，得到多个业务包。例如，一个购物软件可以依据其代码完成的功能的不同，拆分出多个业务包：用以搭建购物车界面的第一业务包，用以搭建商品详情页界面的第二业务包，或是用以提供商品搜索界面的第三业务包等等。
68.在另一种可能的实现方式中，目标应用的完整代码包可以拆分为多个基础包和多个子业务包。如第一基础包、第二基础包、第一业务包以及第二业务包等。
69.在本方式中，目标应用的代码包被拆分为基础包和业务包两种类型，这样，在客户端更新目标应用时，可以更具有针对性的对需要更新的代码进行更新。
70.s102：服务端向客户端发送第一响应，其中，第一响应携带目标应用对应的最新第一业务包；客户端接收该第一响应。
71.服务端接收到客户端用于更新的第一请求后，将已经保存在服务端的目标应用对应的最新第一业务包发送至客户端。
72.可选的，对于保存在服务端的第一业务包，服务端包括但不限于通过以下两种方式获取：
73.方式一、服务端接收目标应用的完整代码包，然后，依据上述拆分逻辑，将完成代码包拆分为基础包和第一业务包。
74.方式二、服务端直接接收到目标应用的基础包与第一业务包。
75.通过以上方式，服务端可以采用不同的方式得到目标应用的基础包与第一业务
包，提高了本方案的灵活性。
76.s103：客户端根据接收到目标应用对应的最新第一业务包，更新客户端本地第一业务包。
77.通过本方案，客户端在对react native应用进行更新时，可以采取单独更新业务包的方式，对react native应用进行更新。避免了大量基础代码的重复更新导致的服务器资源的浪费，并且节省了用户更新所需的流量。同时，服务端根据客户端发送的第一请求中的第一业务包的版本号，向客户端发送相应的第一业务包，有效的避免了客户端盲目获取最新版本的业务包，从而导致本地react native应用版本与业务包版本不匹配的问题。
78.在一种可能的实施方式中，客户端还可以在执行步骤s101之前，对本地第一业务包进行更新判断。在判断结果表征本地第一业务包需要更新之后，进一步获取待更新的第一业务包的版本号，然后发送第一请求。
79.具体的，客户端包括但不限于通过以下两种方式，用以完成上述方案。
80.在一种可能的实现方式中，客户端在发送第一请求之前，向服务端发送第二请求，用以获取保存在服务端中的第一映射关系。
81.具体的，在客户端检测到目标应用启动后，客户端在预设时间范围内向服务端发送第二请求，该第二请求用以请求获取第一映射关系。
82.在本技术实施例中，目标应用会包含三种版本号：目标应用的版本号、基础包版本号以及业务包版本号。其中基础包版本号可以分为第一基础包版本号、第二基础包版本号等，业务包版本号也可以分为第一业务包版本号、第二业务包版本号等，本技术仅为举例说明，不做限制。
83.第一映射关系中包含了目标应用的版本号与目标应用各个不同的版本所支持的最新的第一业务包的版本号的对应关系。通过第一映射关系，客户端与服务端都可以得知不同版本的目标应用所对应的最新第一业务包的版本号。
84.可选的，在服务端获得目标应用的最新第一业务包时，可以将目标应用的版本号与该目标应用对应的最新第一业务包的版本号的对应关系保存至第一映射关系。
85.通过上述方式，服务端可以及时地更新第一映射关系中的对应关系，确保了应用更新时的准确性。
86.同时，第一映射关系中还保留有目标应用历史版本与第一业务包的对应关系，这样可以为更多版本的目标应用提供更新服务，而避免了本地目标应用更新后，应用版本与第一业务包版本不匹配的问题。
87.可选的，第一映射关系可以通过不同的表现形式完成。例如，可以通过关系图的形式，反应该第一映射关系；或是可以通过表格的形式(如表1)，反应该第一映射关系；还可以以文本的形式，记录该第一映射关系。
88.示例性的，参见表1，为本技术实施例提供的一种可能的映射关系的表现形式，在表1中，包含了应用a与应用b两个应用，其中每个应用对应有不同的应用版本号，并且不同的应用版本号也会对应不同的第一业务包的版本号。应理解，表1中各个版本对应关系仅用于说明本技术实施例可能的实现方式，而不做限定。
89.表1
[0090][0091]
在将获取到的第一映射关系保存至本地后，客户端根据该第一映射关系以及目标应用对应的本地配置文件中的本地版本号、本地第一业务包的版本号，判断本地第一业务包是否需要更新。若确定第一业务包需要更新，则从第一映射关系中获取目标应用的本地版本号支持的最新第一业务包的版本号，并向服务端发送第一请求。
[0092]
示例性的，在从服务端获取到第一映射关系(即表1)后，客户端可以从中获取目标应用的本地版本号对应的最新第一业务包的版本号，进而判断本地第一业务包是否需要更新。例如，当客户端中的目标应用为应用a，客户端从应用a对应的本地配置文件中获取到应用a的本地版本号为v2.0时，客户端从表1中获取到该版本的应用a对应的最新第一业务包的版本号是v2.2，若此时，应用a对应的本地第一业务包的版本号是v2.1，则客户端即可确定本地第一业务包需要更新，否则，客户端判定本地第一业务包不需要更新。
[0093]
通过本方式，客户端从服务端中获取第一映射关系用以对本地第一业务包进行更新判断，可以提高更新判断的准确性。
[0094]
在另一种可能的实现方式中，客户端可以通过保存在客户端本地的第二映射关系，对本地第一业务包进行更新判断。
[0095]
具体的，客户端依据目标应用的本地版本号以及本地第一业务包的版本号，创建第二映射关系。该第二映射关系中，包含了目标应用的本地版本号、以及目标应用对应的本地第一业务包的版本号。应理解，该第二映射关系的表现形式与第一映射关系类似，具体请参见上文中第一映射关系的创建，在此不做赘述。
[0096]
在客户端获取到第一映射关系后，通过对比第一映射关系和第二映射关系，即可得知本地第一业务包是否需要更新，且若本地第一业务包需要更新，则可以从第一映射关系中获取待更新的第一业务包的版本号。
[0097]
在上述方法中，客户端可以通过不同的方式获取待更新的第一业务包的版本号，提高了本方案的灵活性。
[0098]
参见图2，为本技术实施例提供的另一种应用程序的更新方法的流程图，其具体实施步骤如下：
[0099]
s201：客户端向服务端发送第一请求，该第一请求携带目标应用的本地版本号、以及目标应用对应的本地第一业务包的版本号；服务端接收该第一请求。
[0100]
在步骤s201中，客户端可以从目标应用的本地配置文件中，获取目标应用的本地版本号以及本地第一业务包版本号，也可以从第二映射关系中获取目标应用的本地版本号以及本地第一业务包版本号。
[0101]
关于版本号的不同获取方式，可以参考上文客户端对第一业务包是否需要更新的判断过程以及第二映射关系的创建过程，此处不再赘述。
[0102]
s202：服务端根据接收到的目标应用的本地版本号、该目标应用的本地第一业务
包版本号、以及第一映射关系，判断目标应用的本地第一业务包是否需要更新。若确认需要更新，则执行步骤s203，若确认无需更新，则不做响应，或者向客户端返回用于指示无需更新的响应。
[0103]
其中，服务端根据第一映射关系以及接收到的目标应用的本地版本号、该目标应用的本地第一业务包版本号对本地第一业务包是否需要更新进行判断，而该判断过程可以参考前文中客户端对本地第一业务包是否需要更新的判断过程，在此不做赘述。
[0104]
s203：服务端向客户端发送第一响应，该第一响应中携带目标应用对应的最新第一业务包；客户端接收该第一响应。
[0105]
s204：客户端根据接收到的最新第一业务包，更新客户端本地的第一业务包。
[0106]
在本方案中，客户端单独更新第一业务包，节省了服务器的资源以及用户流量。同时，客户端向服务端发送目标应用的本地版本号以及本地第一业务包版本号，由服务端判断是否更新本地第一业务包，提高了更新时的准确性，避免了因客户端获取错误版本的业务包导致本地目标应用版本与业务包版本不匹配的问题。
[0107]
以上介绍了本技术实施例中如何更新目标应用的本地第一业务包。
[0108]
可选的，本技术实施例所提供的方法还包括，在更新第一业务包之前，客户端还需要检测本地是否存在目标应用对应的第一业务包。
[0109]
具体的，客户端检测到目标应用启动后，在预设时间范围内，客户端检测本地是否存在第一业务包。
[0110]
若确定本地第一业务包存在，则对该第一业务包进行更新判断。
[0111]
若确定本地第一业务包不存在，则向服务端发送第四请求消息，该第四请求消息中携带目标应用的本地版本号。服务端接收第四请求消息后，会根据目标应用的本地版本号以及第一映射关系，将目标应用对应的版本所能支持的最新第一业务包发送至客户端。
[0112]
可选的，客户端本地不存在第一业务包这种情况，也可以判定为目标应用本地版本与对应的第一业务包版本不匹配，此时，客户端通过发送第三请求消息从服务端获取与目标应用本地版本相匹配的第一业务包。
[0113]
通过上述方式，客户端确保了本地存在目标应用以及其对应的第一业务包，提高了更新的成功率。
[0114]
以上介绍了如何单独更新目标应用的第一业务包的方法。但是，在实际应用中，客户端本地除第一业务包，还可以包括有第一基础包和/或第二业务包等，所以上述方法也可以延伸到第一基础包和/或第二业务包的更新。
[0115]
在一种可能的实施方式中，客户端向服务端发送第三请求消息，第三请求消息中携带目标应用对应的最新第二业务包的版本号；服务端响应于第三请求消息，向客户端发送第三响应，该第三响应中携带最新第二业务包。
[0116]
上述过程具体实现可以参考步骤s101-s103，此处不做赘述。
[0117]
或者，第三请求消息中携带目标应用的本地版本号、以及目标应用对应的本地第二业务包的版本号；服务端响应于该第三请求消息，判断本地第二业务包是否需要更新，若确定需要更新，则向客户端发送第三响应。
[0118]
上述过程具体实现可以参考前文步骤s201-s204，此处不再赘述。
[0119]
在一种可能的实施方式中，在更新第一业务包之前，还可以通过如下方式对第一
基础包进行更新。
[0120]
具体的，客户端根据目标应用的本地版本号、目标应用对应的本地第一基础包的版本号、以及第三映射关系，确定本地第一基础包是否需要更新。
[0121]
其中，第三映射关系包含所述目标应用的本地版本号、以及所述目标应用的本地版本号对应的最新第一基础包的版本号。可选的，该第三映射关系的获取方式与第一映射关系的获取方式相同，且该第三映射关系与第一映射关系的创建方式也相同；进一步的，第一映射关系与第三映射关系可以保存在同一文件中，也可以分别保存在不同的文件中。示例性的，参见图3，为本技术实施例提供的一种映射关系示意图，在图3中，第一映射关系与第三映射关系同时保存在同一个关系图中。
[0122]
若确认本地第一基础包需要更新，则客户端从服务端获取目标应用对应的最新第一基础包，并基于最新第一基础包更新本地第一基础包。
[0123]
通过上述方式，客户端可以在本地判断基础包是否需要更新，只有基础包需要更新时，才向服务端发送更新请求，这样有效地节省了服务端资源。
[0124]
在另一种可能的实施方式中，客户端可以获取本地第一基础包的版本号、目标应用的本地版本号，将上述两个版本号同时发送至服务端。服务端根据两个版本号以及第三映射关系判断客户端本地第一基础包是否需要更新；若确认需要更新，则将待更新的第一基础包发送至客户端，用以客户端更新本地第一基础包。
[0125]
通过上述方式，直接由服务端判断基础包是否需要更新，省略了客户端从服务端获取第一映射关系的步骤，节省了用户流量的使用。
[0126]
应理解，在实际应用中，react native应用的第一基础包、第一业务包和第二业务包既可以分别更新，也可以同时更新。在上述介绍中将其更新方法分开介绍仅是举例说明，并不做限定。同时，第一业务包的更新发送的可选方案也可以适应性的应用于第二业务包和/或第一基础包的更新。
[0127]
应理解，本文中的各实施方式可以相互结合以实现不同的技术效果。
[0128]
以上介绍了本技术实施例提供的方法，以下介绍本技术实施例提供的装置。
[0129]
参见图4，本技术实施例提供一种应用程序更新的装置，该装置可以是上文中的客户端或者是该设备中的芯片或集成电路等，该装置包括用于执行上述方法实施例中由客户端设备执行的方法的模块/单元/技术手段。
[0130]
示例性的，该装置400可以包括：
[0131]
第一发送模块401，用于向服务端发送第一请求消息，所述第一请求消息携带：所述目标应用对应的最新第一业务包的版本号；或者，所述目标应用的本地版本号、以及所述目标应用对应的本地第一业务包的版本号；
[0132]
第一接收模块402，用于接收来自所述服务端的第一响应，所述第一响应中携带所述最新第一业务包；使用所述最新第一业务包更新所述本地第一业务包。
[0133]
参见图5，本技术实施例提供一种应用程序更新的装置，该装置可以是上文中的服务端或者是该设备中的芯片或集成电路等，该装置包括用于执行上述方法实施例中由服务端设备执行的方法的模块/单元/技术手段。
[0134]
示例性的，该装置500可以包括：
[0135]
第二接收模块501，用于接收来自客户端的第一请求消息，所述第一请求消息携
sdram，ddr sdram)、增强型同步动态随机存取存储器(enhanced sdram，esdram)、同步连接动态随机存取存储器(synchlink dram，sldram)和直接内存总线随机存取存储器(direct rambus ram，dr ram)。
[0147]
需要说明的是，当处理器为通用处理器、dsp、asic、fpga或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件时，存储器(存储模块)可以集成在处理器中。
[0148]
应注意，本文描述的存储器旨在包括但不限于这些和任意其它适合类型的存储器。
[0149]
作为另一种可能的产品形态，本技术实施例还提供一种计算机可读存储介质，该计算机可读存储介质用于存储指令，当所述指令被执行时，使得计算机执行上述方法实例中任一设备所执行的方法步骤。
[0150]
本领域内的技术人员应明白，本技术的实施例可提供为方法、系统、或计算机程序产品。因此，本技术可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本技术可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
[0151]
本技术是参照根据本技术的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
[0152]
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
[0153]
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
[0154]
显然，本领域的技术人员可以对本技术进行各种改动和变型而不脱离本技术的精神和范围。这样，倘若本技术的这些修改和变型属于本技术权利要求及其等同技术的范围之内，则本技术也意图包含这些改动和变型在内。