CN107861739A - ReactNative应用调整方法、客户端及系统 - Google Patents
ReactNative应用调整方法、客户端及系统 Download PDFInfo
- Publication number
- CN107861739A CN107861739A CN201711079012.8A CN201711079012A CN107861739A CN 107861739 A CN107861739 A CN 107861739A CN 201711079012 A CN201711079012 A CN 201711079012A CN 107861739 A CN107861739 A CN 107861739A
- Authority
- CN
- China
- Prior art keywords
- reactnative
- version information
- applications
- adjustment
- service end
- Prior art date
- Legal status (The legal status 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 status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 44
- 238000007689 inspection Methods 0.000 claims abstract description 19
- 230000008569 process Effects 0.000 claims description 14
- 238000012217 deletion Methods 0.000 claims description 6
- 230000037430 deletion Effects 0.000 claims description 6
- 230000005540 biological transmission Effects 0.000 description 9
- 238000005516 engineering process Methods 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 238000000151 deposition Methods 0.000 description 2
- OKTJSMMVPCPJKN-UHFFFAOYSA-N Carbon Chemical compound [C] OKTJSMMVPCPJKN-UHFFFAOYSA-N 0.000 description 1
- 229910052799 carbon Inorganic materials 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000011835 investigation Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000004321 preservation Methods 0.000 description 1
- 238000003672 processing method Methods 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
Abstract
本发明提供了一种ReactNative应用调整方法、客户端及系统，该方法可以包括：获取当前启动的ReactNative应用的版本信息；向相应的服务端发送携带有所述版本信息的调整检查请求，以使所述服务端根据所述版本信息检查本次是否需要进行版本调整；当接收到所述服务端发送的调整指令时，根据所述调整指令获取目标版本信息的ReactNative应用，并加载所述目标版本信息的ReactNative应用，其中，所述调整指令由所述服务端在检查到本次需要进行版本调整时形成并发送。本方案能够在不卸载整个应用程序的基础上实现ReactNative应用的调整，提高用户体验。
Description
技术领域
本发明涉及计算机技术领域，特别涉及一种ReactNative应用调整方法、客户端及系统。
背景技术
ReactNative是facebook开源的开发框架，能够转换为原生代码运行，实现跨平台。一个APP应用程序中可能包含有多个不同的ReactNative应用，与此同时，可能需要对ReactNative应用进行版本更新等多种调整。
目前，主要是通过用户将整个APP卸载，然后再从助手等地方下载包括有调整后的ReactNative应用的APP，最后再安装新下载的APP，从而完成APP中某ReactNative应用的调整。
但是，由于APP中包含多个不同的ReactNative应用，那么每一个ReactNative应用的每一次调整均需要卸载一次APP，然后再重新安装，导致用户体验较差。
发明内容
本发明实施例提供了一种ReactNative应用调整方法、客户端及系统，能够在不卸载整个应用程序的基础上实现ReactNative应用的调整，提高用户体验。
第一方面，本发明实施例提供了一种ReactNative应用调整方法，应用于客户端，包括：
获取当前启动的ReactNative应用的版本信息；
向相应的服务端发送携带有所述版本信息的调整检查请求，以使所述服务端根据所述版本信息检查本次是否需要进行版本调整；
当接收到所述服务端发送的调整指令时，根据所述调整指令获取目标版本信息的ReactNative应用，并加载所述目标版本信息的ReactNative应用，其中，所述调整指令由所述服务端在检查到本次需要进行版本调整时形成并发送。
优选地，
所述调整指令，包括：携带有新版本信息和下载地址的更新子指令；
所述当接收到所述服务端发送的调整指令时，根据所述调整指令获取目标版本信息的ReactNative应用，并加载所述目标版本信息的ReactNative应用，包括：
S1：根据所述下载地址，下载所述新版本信息的ReactNative应用；
S2：将当前的所述版本信息的ReactNative应用从预先创建的缓存区移动至预先创建的旧版本区，将下载的所述新版本信息的ReactNative应用移动至所述缓存区；
S3：加载所述缓存区中的所述新版本信息的ReactNative应用。
优选地，
在所述S1之后，且在所述S2之前，进一步包括：
计算下载的所述新版本信息的ReactNative应用对应的哈希值；
判断计算出的所述哈希值与所述更新子指令中携带的哈希值是否一致；
若是，则执行所述S2；若否，则结束当前流程。
优选地，
所述调整指令，包括：回退子指令；
所述当接收到所述服务端发送的调整指令时，根据所述调整指令获取目标版本信息的ReactNative应用，并加载所述目标版本信息的ReactNative应用，包括：
将预先创建的旧版本区中的一个旧版本信息的ReactNative应用移动至预先创建的缓存区，并覆盖掉所述缓存区中的当前的所述版本信息的ReactNative应用；
加载所述缓存区中的所述旧版本信息的ReactNative应用。
优选地，
所述调整指令，包括：重置子指令；
所述当接收到所述服务端发送的调整指令时，根据所述调整指令获取目标版本信息的ReactNative应用，并加载所述目标版本信息的ReactNative应用，包括：
删除预先创建的旧版本区和缓存区，并重新创建一个新缓存区；
将预置的初始版本信息的ReactNative应用从指定区域复制到所述新缓存区；
加载所述新缓存区中的所述初始版本信息的ReactNative应用。
优选地，
在所述向相应的服务端发送携带有所述版本信息的调整检查请求之后，进一步包括：
当接收到所述服务端发送的待命指令时，加载当前的所述版本信息的ReactNative应用，其中，所述待命指令由所述服务端在检查到本次不需要进行版本调整时形成并发送。
第二方面，本发明实施例提供了一种客户端，包括：获取单元、发送单元以及调整单元；
所述获取单元，用于获取当前启动的ReactNative应用的版本信息；
所述发送单元，用于向相应的服务端发送携带有所述版本信息的调整检查请求，以使所述服务端根据所述版本信息检查本次是否需要进行版本调整；
所述调整单元，用于当接收到所述服务端发送的调整指令时，根据所述调整指令获取目标版本信息的ReactNative应用，并加载所述目标版本信息的ReactNative应用，其中，所述调整指令由所述服务端在检查到本次需要进行版本调整时形成并发送。
优选地，
所述调整指令，包括：携带有新版本信息和下载地址的更新子指令；
所述调整单元，用于执行：
S1：根据所述下载地址，下载所述新版本信息的ReactNative应用；
S2：将当前的所述版本信息的ReactNative应用从预先创建的缓存区移动至预先创建的旧版本区，将下载的所述新版本信息的ReactNative应用移动至所述缓存区；
S3：加载所述缓存区中的所述新版本信息的ReactNative应用。
优选地，
所述调整单元，进一步用于在所述S1之后，且在所述S2之前，计算下载的所述新版本信息的ReactNative应用对应的哈希值；判断计算出的所述哈希值与所述更新子指令中携带的哈希值是否一致；若是，则继续执行所述S2，若否，在结束当前流程。
优选地，
所述调整指令，包括：回退子指令；
所述调整单元，用于将预先创建的旧版本区中的一个旧版本信息的ReactNative应用移动至预先创建的缓存区，并覆盖掉所述缓存区中的当前的所述版本信息的ReactNative应用；加载所述缓存区中的所述旧版本信息的ReactNative应用。
优选地，
所述调整指令，包括：重置子指令；
所述调整单元，用于删除预先创建的旧版本区和缓存区，并重新创建一个新缓存区；将预置的初始版本信息的ReactNative应用从指定区域复制到所述新缓存区；加载所述新缓存区中的所述初始版本信息的ReactNative应用。
第三方面，本发明实施例提供了一种ReactNative应用调整系统，包括：服务端以及至少一个上述任一实施例所述的客户端，其中，
所述服务端，用于接收所述至少一个客户端分别发送的携带有版本信息的调整检查请求；根据所述版本信息检查本次是否需要进行版本调整，若是，则形成相应的调整指令，并将所述调整指令发送给相应的所述客户端。
本发明实施例提供了一种ReactNative应用调整方法、客户端及系统，在相应的ReactNative应用每一次启动时，均会获取该ReactNative应用的版本信息，然后向相应的服务端发送携带该版本信息的调整检查请求，可通过服务端根据该版本信息确定本次是否需要进行版本调整，如果需要调整，则将会接收到服务端发送的调整指令，从而能够根据该调整指令获取到需要调整成的目标版本信息的ReactNative应用，最终加载获取到该目标版本信息的ReactNative应用，完成ReactNative应用的调整。整个过程无需再由用户卸载整个应用程序，而是每一次ReactNative应用启动时均会通过服务端判断是否需要调整，当需要调整时，根据调整指令自动完成ReactNative应用的调整，提高了用户体验。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本发明一个实施例提供的一种ReactNative应用调整方法的流程图；
图2是本发明另一个实施例提供的一种ReactNative应用调整方法的流程图；
图3是本发明一个实施例提供的一种客户端的结构示意图；
图4是本发明一个实施例提供的一种ReactNative应用调整系统的结构示意图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例，基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。
如图1所示，本发明实施例提供了一种ReactNative应用调整方法，应用于客户端，该方法可以包括以下步骤：
步骤101：获取当前启动的ReactNative应用的版本信息。
步骤102：向相应的服务端发送携带有所述版本信息的调整检查请求，以使所述服务端根据所述版本信息检查本次是否需要进行版本调整。
步骤103：当接收到所述服务端发送的调整指令时，根据所述调整指令获取目标版本信息的ReactNative应用，并加载所述目标版本信息的ReactNative应用，其中，所述调整指令由所述服务端在检查到本次需要进行版本调整时形成并发送。
本发明实施例提供了一种ReactNative应用调整方法，在ReactNative应用每一次启动时，均会获取该ReactNative应用的版本信息，然后向相应的服务端发送携带该版本信息的调整检查请求，可通过服务端根据该版本信息确定本次是否需要进行版本调整，如果需要调整，则将会接收到服务端发送的调整指令，从而能够根据该调整指令获取到需要调整成的目标版本信息的ReactNative应用，最终加载获取到该目标版本信息的ReactNative应用，完成ReactNative应用的调整。整个过程无需再由用户卸载整个应用程序，而是每一次ReactNative应用启动时均会通过服务端判断是否需要调整，当需要调整时，根据调整指令自动完成ReactNative应用的调整，提高了用户体验。
在本发明一个实施例中，当需要进行版本更新时，所述调整指令，包括：携带有新版本信息和下载地址的更新子指令；
所述步骤103的具体实施方式，可包括：
S1：根据所述下载地址，下载所述新版本信息的ReactNative应用；
S2：将当前的所述版本信息的ReactNative应用从预先创建的缓存区移动至预先创建的旧版本区，将下载的所述新版本信息的ReactNative应用移动至所述缓存区；
S3：加载所述缓存区中的所述新版本信息的ReactNative应用。
例如，获取到当前启动的ReactNative应用的版本号为1.11，服务端在接收到客户端发送的携带有版本号1.11的调整检查请求后，检查到有1.12版本的ReactNative应用，则此时服务端将会向客户端发送携带有新版本号1.12以及新版本下载地址的更新子指令，那么客户端可根据该下载地址从服务端下载新版本1.12的ReactNative应用，接下来为向用户展示1.12版本的ReactNative应用，则将1.11版本的ReactNative应用从缓存区移动至旧版本区，然后将下载的新版本1.12的ReactNative应用移动至缓存区进行加载，这样，用户看到的将会是最新版本的ReactNative应用，整个过程自动完成，无需卸载掉整个应用程序。
值得说明的是，一个应用程序中可能包含多个不同的ReactNative应用，那么为了互不影响，可针对不同的ReactNative应用，设置不同规则的版本号，从而服务端在接收到相应版本号的调整检查请求时，能够根据该版本号确定本次是否需要进行版本更新等相应的调整。
在本发明实施例中，下载新版本信息的ReactNative应用时，使用到的关键代码可如下：
ReactNativeFlow.downLoadZipFile()；
在完成从当前的版本信息至新版本信息的更新时，使用的关键代码为：
moveFolder(reactCurrentPath,reactTempPath)；
deleteOldVersionFile(reactCurrentPath)；
ZipUtils.upZipFile(reactZipFilePath,reactCurrentPath)；
FileUtils.deleteFile(reactZipFilePath)
为了验证下载的新版本信息的ReactNative应用是否完整，在本发明一个实施例中，在所述S1之后，且在所述S2之前，进一步包括：
计算下载的所述新版本信息的ReactNative应用对应的哈希值；
判断计算出的所述哈希值与所述更新子指令中携带的哈希值是否一致；
若是，则执行所述S2；若否，则结束当前流程。
上述实施例中，当技术人员将新版本信息的ReactNative应用上传至服务端之后，服务端会计算出该新版本信息的ReactNative应用对应的哈希值，如SHA256，之后在检查到客户端的ReactNative应用需要更新到该新版本时，则将该新版本信息、新版本应用的下载地址以及该SHA256值一同发给客户端，从而客户端在根据该下载地址从服务端完成下载后，对自身下载的新版本信息的ReactNative应用进行计算，得到另一个SHA256值，若从服务端接收到SHA256值与自身计算出的SHA256值相同，则说明自身从服务端下载的ReactNative应用是完整的，可以进行更新，但若两个值不同，则说明可能由于网络问题或者是被攻击等原因造成自身从服务端下载的ReactNative应用是不完整的，本次暂不进行更新，等待下一次更新。
在本发明实施例中，验证自身下载的ReactNative应用的完整性时，使用的关键代码可如下：
ReactNativeFlow.isFileCompelete()；
在本发明一个实施例中，当需要由当前的版本信息回退至旧的版本信息时，所述调整指令，包括：回退子指令；
所述步骤103的具体实施方式，可包括：
将预先创建的旧版本区中的一个旧版本信息的ReactNative应用移动至预先创建的缓存区，并覆盖掉所述缓存区中的当前的所述版本信息的ReactNative应用；
加载所述缓存区中的所述旧版本信息的ReactNative应用。
上述实施例中，技术人员可在服务端存储ReactNative应用的调整记录，例如，存储的调整记录为“版本号为2.1的需要回退至旧的版本”，这样，服务端在接收到携带有版本号2.1的调整检查请求时，则根据该版本号2.1，检查到本次需要进行回退，因此向相应的客户端发送回退子指令，由于客户端预先创建的有旧版本区和缓存区，其中，旧版本区用来存储旧的版本信息的ReactNative应用，这样，客户端只要接收到服务端发送的回退子指令，则可将该缓存区中的旧的版本信息(如2.0版)的ReactNative应用在调整至该缓存区中进行加载。
在本发明实施例中，在将旧的版本信息的ReactNative应用移动至缓存区时，使用的关键代码可如下：
moveFolder(reactTempPath,reactCurrentPath)；
同时将旧的版本信息的ReactNative应用从旧版本区进行删除时，使用的关键代码可如下：
deleteOldVersionFile(reactTempPath)
在本发明实施例中，为了节省存储空间，旧版本区中可最多只允许保留一个旧的版本信息的ReactNative应用。
在本发明一个实施例中，当有重大升级需要回退至最初始的版本时，所述调整指令，包括：重置子指令；
所述步骤103的具体实施方式，可包括：
删除预先创建的旧版本区和缓存区，并重新创建一个新缓存区；
将预置的初始版本信息的ReactNative应用从指定区域复制到所述新缓存区；
加载所述新缓存区中的所述初始版本信息的ReactNative应用。
上述实施例中，当有重大升级等需要重置为最初始版本的应用时，则将旧版本区连同其中的内容一并删除，以及将缓存区连同其中的内容一并删除，然后重新加载指定区域中存储的初始版本信息的ReactNative应用。
在本发明一个实施例中，在所述步骤102之后，进一步包括：当接收到所述服务端发送的待命指令时，加载当前的所述版本信息的ReactNative应用，其中，所述待命指令由所述服务端在检查到本次不需要进行版本调整时形成并发送。
上述实施例中，当客户端接收到服务端发送的待命指令时，则说明服务端并未查找到与接收到的版本信息相对应的新版本信息或者是相应的调整记录，也即说明本次不要进行版本调整，因此，客户端只需加载当前的版本信息的ReactNative应用即可。
值得说明的是，若接收到的并非是调整指令或者是待命指令，则与接收到待命指令后的处理方法相同，加载当前的版本信息的ReactNative应用，并等待下一次的调整检查。
下面将以版本更新为例，详细说明本发明实施例提供的一种ReactNative应用调整方法，如图2所示，该方法可以包括如下步骤：
步骤201：获取当前启动的ReactNative应用的版本号。
在本发明实施例中，应预先在应用内部嵌入ReactNative的相关环境，把ReactNative的依赖工程加入到现有工程中，同步工程将依赖工程写入到依赖脚本里去。具体的，完成依赖工程的下载和保存时的关键代码如下：
npm install；
在依赖脚本中加入ReactNative的依赖的关键代码如下：
compile'com.facebook.react:react-native:+'
接下来在应用开始的生命周期里实现管理ReactNative的接口，在此处管理相关的生命周期，加入ReactNative实现原生功能相应的包。具体的，实现ReactNative方法时的关键代码如下：
MyApplication extends MultiDexApplication implements ReactApplication
复写ReactNative方法时的关键代码如下：
初始化参数时的关键代码如下：
步骤202：向相应的服务端发送携带有该版本号的调整检查请求，以使服务端根据该版本号检查本次是否需要进行版本调整，当接收到服务端发送的更新子指令时，执行步骤203，当接收到服务端发送的待命指令时，执行步骤208，其中，更新子指令由服务端在检查到本次需要进行版本调整时形成并发送，待命指令由服务端在检查到本次不需要进行版本调整时形成并发送。
在本发明实施例中，检查是否有调整时的关键代码可如下：
appApiService.getReactNativeUpdate(androidBundleBean.getVersion(),
androidBundleBean.getCreationDate(),clientId)；
除此之外，便于生成日志等记录信息，客户端还可将当前的版本信息对应的更新时间随版本号一同发送至服务端。
步骤203：根据更新子指令中携带的下载地址，下载新版本信息的ReactNative应用。
在本发明实施例中，服务端发送的更新子指令中携带有新版本号、下载地址以及相应的哈希值。
步骤204：计算下载的新版本信息的ReactNative应用对应的哈希值。
步骤205：判断计算出的哈希值与更新子指令中携带的哈希值是否一致，若是，则执行步骤206，若否，则结束当前流程。
步骤206：将当前的版本信息的ReactNative应用从预先创建的缓存区移动至预先创建的旧版本区，将下载的新版本信息的ReactNative应用移动至缓存区。
在发明实施例中，在将当前的版本信息的ReactNative应用从缓存区移动至旧版本区时，若旧版本区中还存在有其它版本信息的ReactNative应用，则可直接利用当前的版本信息的ReactNative应用覆盖掉其它版本信息的ReactNative应用，以此利用覆盖的形式保证旧版本区中只保留一个版本信息的ReactNative应用，既节省了内存空间，又可在接收到回退子指令时选择旧的版本进行回退。
步骤207：加载缓存区中的新版本信息的ReactNative应用，并结束当前流程。
在本发明实施例中，加载和展示时所用到的关键代码可如下：
mReactRootView.startReactApplication(mReactInstanceManager,"discover",createInitBundle())
步骤208：加载当前的版本信息的ReactNative应用。
如图3所示，本发明实施例提供了一种客户端，包括：获取单元301、发送单元302以及调整单元303；
所述获取单元301，用于获取当前启动的ReactNative应用的版本信息；
所述发送单元302，用于向相应的服务端发送携带有所述版本信息的调整检查请求，以使所述服务端根据所述版本信息检查本次是否需要进行版本调整；
所述调整单元303，用于当接收到所述服务端发送的调整指令时，根据所述调整指令获取目标版本信息的ReactNative应用，并加载所述目标版本信息的ReactNative应用，其中，所述调整指令由所述服务端在检查到本次需要进行版本调整时形成并发送。
在本发明一个实施例中，所述调整指令，包括：携带有新版本信息和下载地址的更新子指令；
所述调整单元，用于执行：
S1：根据所述下载地址，下载所述新版本信息的ReactNative应用；
S2：将当前的所述版本信息的ReactNative应用从预先创建的缓存区移动至预先创建的旧版本区，将下载的所述新版本信息的ReactNative应用移动至所述缓存区；
S3：加载所述缓存区中的所述新版本信息的ReactNative应用。
在本发明一个实施例中，所述调整单元，进一步用于在所述S1之后，且在所述S2之前，计算下载的所述新版本信息的ReactNative应用对应的哈希值；判断计算出的所述哈希值与所述更新子指令中携带的哈希值是否一致；若是，则继续执行所述S2，若否，在结束当前流程。
在本发明一个实施例中，所述调整指令，包括：回退子指令；
所述调整单元，用于将预先创建的旧版本区中的一个旧版本信息的ReactNative应用移动至预先创建的缓存区，并覆盖掉所述缓存区中的当前的所述版本信息的ReactNative应用；加载所述缓存区中的所述旧版本信息的ReactNative应用。
在本发明一个实施例中，所述调整指令，包括：重置子指令；
所述调整单元，用于删除预先创建的旧版本区和缓存区，并重新创建一个新缓存区；将预置的初始版本信息的ReactNative应用从指定区域复制到所述新缓存区；加载所述新缓存区中的所述初始版本信息的ReactNative应用。
上述装置内的各单元之间的信息交互、执行过程等内容，由于与本发明方法实施例基于同一构思，具体内容可参见本发明方法实施例中的叙述，此处不再赘述。
如图4所示，本发明实施例提供了一种ReactNative应用调整系统，包括：服务端401以及至少一个上述任一实施例中所述的客户端402；
所述服务端401，用于接收所述至少一个客户端分别发送的携带有版本信息的调整检查请求；根据所述版本信息检查本次是否需要进行版本调整，若是，则形成相应的调整指令，并将所述调整指令发送给相应的所述客户端。
综上，本发明各个实施例至少具有如下有益效果：
1、在本发明实施例中，在相应的ReactNative应用每一次启动时，均会获取该ReactNative应用的版本信息，然后向相应的服务端发送携带该版本信息的调整检查请求，可通过服务端根据该版本信息确定本次是否需要进行版本调整，如果需要调整，则将会接收到服务端发送的调整指令，从而能够根据该调整指令获取到需要调整成的目标版本信息的ReactNative应用，最终加载获取到该目标版本信息的ReactNative应用，完成ReactNative应用的调整。整个过程无需再由用户卸载整个应用程序，而是每一次ReactNative应用启动时均会通过服务端判断是否需要调整，当需要调整时，根据调整指令自动完成ReactNative应用的调整，提高了用户体验。
2、在本发明实施例中，当需要进行版本更新时，客户端通过比对自身计算出的新版本信息的ReactNative应用对应的哈希值以及接收到的更新子指令中携带的哈希值，客户端能够确定出自身下载的新版本信息的ReactNative应用是否完整，从而只有在确定出完整时，才进行更新，避免了更新不完整的ReactNative应用时，导致用户无法正常使用相应功能的情况。
3、在本发明实施例中，当接收到服务端的待命指令时，则说明当前并没有相应的调整需求，因此，为使用户能够正常使用相应的功能，则本次加载当前的版本信息的ReactNative应用。
需要说明的是，在本文中，诸如第一和第二之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个〃····〃”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同因素。
本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储在计算机可读取的存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质中。
最后需要说明的是：以上所述仅为本发明的较佳实施例，仅用于说明本发明的技术方案，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所做的任何修改、等同替换、改进等，均包含在本发明的保护范围内。
Claims (10)
1.一种ReactNative应用调整方法，其特征在于，应用于客户端，包括：
获取当前启动的ReactNative应用的版本信息；
向相应的服务端发送携带有所述版本信息的调整检查请求，以使所述服务端根据所述版本信息检查本次是否需要进行版本调整；
当接收到所述服务端发送的调整指令时，根据所述调整指令获取目标版本信息的ReactNative应用，并加载所述目标版本信息的ReactNative应用，其中，所述调整指令由所述服务端在检查到本次需要进行版本调整时形成并发送。
2.根据权利要求1所述的方法，其特征在于，
所述调整指令，包括：携带有新版本信息和下载地址的更新子指令；
所述当接收到所述服务端发送的调整指令时，根据所述调整指令获取目标版本信息的ReactNative应用，并加载所述目标版本信息的ReactNative应用，包括：
S1：根据所述下载地址，下载所述新版本信息的ReactNative应用；
S2：将当前的所述版本信息的ReactNative应用从预先创建的缓存区移动至预先创建的旧版本区，将下载的所述新版本信息的ReactNative应用移动至所述缓存区；
S3：加载所述缓存区中的所述新版本信息的ReactNative应用。
3.根据权利要求2所述的方法，其特征在于，
在所述S1之后，且在所述S2之前，进一步包括：
计算下载的所述新版本信息的ReactNative应用对应的哈希值；
判断计算出的所述哈希值与所述更新子指令中携带的哈希值是否一致；
若是，则执行所述S2；若否，则结束当前流程。
4.根据权利要求1所述的方法，其特征在于，
所述调整指令，包括：回退子指令；
所述当接收到所述服务端发送的调整指令时，根据所述调整指令获取目标版本信息的ReactNative应用，并加载所述目标版本信息的ReactNative应用，包括：
将预先创建的旧版本区中的一个旧版本信息的ReactNative应用移动至预先创建的缓存区，并覆盖掉所述缓存区中的当前的所述版本信息的ReactNative应用；
加载所述缓存区中的所述旧版本信息的ReactNative应用；
或，
所述调整指令，包括：重置子指令；
所述当接收到所述服务端发送的调整指令时，根据所述调整指令获取目标版本信息的ReactNative应用，并加载所述目标版本信息的ReactNative应用，包括：
删除预先创建的旧版本区和缓存区，并重新创建一个新缓存区；
将预置的初始版本信息的ReactNative应用从指定区域复制到所述新缓存区；
加载所述新缓存区中的所述初始版本信息的ReactNative应用。
5.根据权利要求1至4任一所述的方法，其特征在于，
在所述向相应的服务端发送携带有所述版本信息的调整检查请求之后，进一步包括：
当接收到所述服务端发送的待命指令时，加载当前的所述版本信息的ReactNative应用，其中，所述待命指令由所述服务端在检查到本次不需要进行版本调整时形成并发送。
6.一种客户端，其特征在于，包括：获取单元、发送单元以及调整单元；
所述获取单元，用于获取当前启动的ReactNative应用的版本信息；
所述发送单元，用于向相应的服务端发送携带有所述版本信息的调整检查请求，以使所述服务端根据所述版本信息检查本次是否需要进行版本调整；
所述调整单元，用于当接收到所述服务端发送的调整指令时，根据所述调整指令获取目标版本信息的ReactNative应用，并加载所述目标版本信息的ReactNative应用，其中，所述调整指令由所述服务端在检查到本次需要进行版本调整时形成并发送。
7.根据权利要求6所述的客户端，其特征在于，
所述调整指令，包括：携带有新版本信息和下载地址的更新子指令；
所述调整单元，用于执行：
S1：根据所述下载地址，下载所述新版本信息的ReactNative应用；
S2：将当前的所述版本信息的ReactNative应用从预先创建的缓存区移动至预先创建的旧版本区，将下载的所述新版本信息的ReactNative应用移动至所述缓存区；
S3：加载所述缓存区中的所述新版本信息的ReactNative应用。
8.根据权利要求7所述的客户端，其特征在于，
所述调整单元，进一步用于在所述S1之后，且在所述S2之前，计算下载的所述新版本信息的ReactNative应用对应的哈希值；判断计算出的所述哈希值与所述更新子指令中携带的哈希值是否一致；若是，则继续执行所述S2，若否，在结束当前流程。
9.根据权利要求6所述的客户端，其特征在于，
所述调整指令，包括：回退子指令；
所述调整单元，用于将预先创建的旧版本区中的一个旧版本信息的ReactNative应用移动至预先创建的缓存区，并覆盖掉所述缓存区中的当前的所述版本信息的ReactNative应用；加载所述缓存区中的所述旧版本信息的ReactNative应用；
或，
所述调整指令，包括：重置子指令；
所述调整单元，用于删除预先创建的旧版本区和缓存区，并重新创建一个新缓存区；将预置的初始版本信息的ReactNative应用从指定区域复制到所述新缓存区；加载所述新缓存区中的所述初始版本信息的ReactNative应用。
10.一种ReactNative应用调整系统，其特征在于，包括：服务端以及至少一个权利要求6至9任一所述的客户端，其中，
所述服务端，用于接收所述至少一个客户端分别发送的携带有版本信息的调整检查请求；根据所述版本信息检查本次是否需要进行版本调整，若是，则形成相应的调整指令，并将所述调整指令发送给相应的所述客户端。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711079012.8A CN107861739A (zh) | 2017-11-06 | 2017-11-06 | ReactNative应用调整方法、客户端及系统 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711079012.8A CN107861739A (zh) | 2017-11-06 | 2017-11-06 | ReactNative应用调整方法、客户端及系统 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN107861739A true CN107861739A (zh) | 2018-03-30 |
Family
ID=61700842
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201711079012.8A Pending CN107861739A (zh) | 2017-11-06 | 2017-11-06 | ReactNative应用调整方法、客户端及系统 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN107861739A (zh) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110096295A (zh) * | 2019-05-08 | 2019-08-06 | 吉旗（成都）科技有限公司 | 基于ReactNative的多模块移动应用的热更新方法及系统 |
| CN111090442A (zh) * | 2019-11-11 | 2020-05-01 | 腾讯音乐娱乐科技（深圳）有限公司 | 一种应用更新方法、装置和存储介质 |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105099988A (zh) * | 2014-04-24 | 2015-11-25 | 阿里巴巴集团控股有限公司 | 用于支持灰度发布的方法、访问方法以及装置和系统 |
| CN105528205A (zh) * | 2015-11-30 | 2016-04-27 | 用友优普信息技术有限公司 | 更新控制方法和更新控制系统 |
| CN105704241A (zh) * | 2016-04-06 | 2016-06-22 | 浪潮电子信息产业股份有限公司 | 一种客户端程序更新方法及系统、业务平台 |
| US20170192773A1 (en) * | 2015-12-31 | 2017-07-06 | Kony, Inc. | Mobile applications |
-
2017
- 2017-11-06 CN CN201711079012.8A patent/CN107861739A/zh active Pending
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105099988A (zh) * | 2014-04-24 | 2015-11-25 | 阿里巴巴集团控股有限公司 | 用于支持灰度发布的方法、访问方法以及装置和系统 |
| CN105528205A (zh) * | 2015-11-30 | 2016-04-27 | 用友优普信息技术有限公司 | 更新控制方法和更新控制系统 |
| US20170192773A1 (en) * | 2015-12-31 | 2017-07-06 | Kony, Inc. | Mobile applications |
| CN105704241A (zh) * | 2016-04-06 | 2016-06-22 | 浪潮电子信息产业股份有限公司 | 一种客户端程序更新方法及系统、业务平台 |
Non-Patent Citations (1)
| Title |
|---|
| VV_小虫: "React-Native 热更新尝试（Android）", 《HTTPS://BLOG.CSDN.NET/VV_BUG/ARTICLE/DETAILS/60883436》 * |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110096295A (zh) * | 2019-05-08 | 2019-08-06 | 吉旗（成都）科技有限公司 | 基于ReactNative的多模块移动应用的热更新方法及系统 |
| CN110096295B (zh) * | 2019-05-08 | 2023-08-08 | 吉旗（成都）科技有限公司 | 基于ReactNative的多模块移动应用的热更新方法及系统 |
| CN111090442A (zh) * | 2019-11-11 | 2020-05-01 | 腾讯音乐娱乐科技（深圳）有限公司 | 一种应用更新方法、装置和存储介质 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109117169B (zh) | 用于修复内核漏洞的方法和装置 | |
| KR101643022B1 (ko) | 카탈로그-기반 소프트웨어 컴포넌트 관리 | |
| US20190196805A1 (en) | Controlled rollout of updates for applications installed on client devices | |
| CN111615716B (zh) | 在客户端机器之间分配着色器来进行预缓存 | |
| US9880824B2 (en) | On demand resources | |
| KR101422563B1 (ko) | 데이터 패키지의 효율적인 다운로드 방법 및 시스템 | |
| CN108984224A (zh) | 一种插件管理方法、计算机可读存储介质及终端设备 | |
| US20160357544A1 (en) | On demand resources | |
| JP2003504721A (ja) | 電子装置のアップグレードについて制御する再設定マネージャ | |
| CN111008034B (zh) | 一种补丁生成方法及装置 | |
| CN108228810A (zh) | 表单联动配置方法和系统以及表单更新方法和系统 | |
| CN107896244A (zh) | 一种版本文件的分发方法、客户端及服务器 | |
| JP5395108B2 (ja) | 組み込みシステム内のファームウエアをアップグレードする装置と方法 | |
| CN107220074A (zh) | 对支撑层软件功能的访问、升级方法及装置 | |
| CN106357791A (zh) | 业务处理方法、装置及系统 | |
| CN109908585A (zh) | 一种文件处理方法及系统、计算设备及存储介质 | |
| US8769521B2 (en) | Calendar aware adaptive patching of a computer program | |
| CN107861739A (zh) | ReactNative应用调整方法、客户端及系统 | |
| CN108694049B (zh) | 一种更新软件的方法和设备 | |
| CN109032617B (zh) | 一种自动删除安装包的控制方法及控制装置 | |
| CN115129574A (zh) | 一种代码测试方法和装置 | |
| WO2017036197A1 (zh) | 一种网元模型管理方法及装置 | |
| CN110096295A (zh) | 基于ReactNative的多模块移动应用的热更新方法及系统 | |
| CN113791809B (zh) | 应用异常处理方法、装置以及计算机可读存储介质 | |
| CN115022307A (zh) | 一种文件下载方法及装置、存储介质及电子设备 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20180330 |
|
| RJ01 | Rejection of invention patent application after publication |