WO2019024229A1 - 移动应用的热更新方法、装置、电子设备及介质 - Google Patents

移动应用的热更新方法、装置、电子设备及介质 Download PDF

Info

Publication number
WO2019024229A1
WO2019024229A1 PCT/CN2017/104531 CN2017104531W WO2019024229A1 WO 2019024229 A1 WO2019024229 A1 WO 2019024229A1 CN 2017104531 W CN2017104531 W CN 2017104531W WO 2019024229 A1 WO2019024229 A1 WO 2019024229A1
Authority
WO
WIPO (PCT)
Prior art keywords
update
framework
hot
frame level
level
Prior art date
Application number
PCT/CN2017/104531
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
Application filed by 上海壹账通金融科技有限公司 filed Critical 上海壹账通金融科技有限公司
Publication of WO2019024229A1 publication Critical patent/WO2019024229A1/zh

Links

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

Definitions

  • Hot update method device, electronic device and medium for mobile applications
  • the present application relates to the field of mobile application technologies, and in particular, to a method, device, electronic device, and medium for updating a hot application of a mobile application.
  • the embodiments of the present application provide a method, a device, an electronic device, and a medium for updating a mobile application, so as to solve the problem that the mobile application is difficult to operate normally due to mutual preemption of different levels of hot update in the prior art.
  • the problem Problem solution
  • a first aspect of the embodiments of the present application provides a hot update method for a mobile application, including:
  • the scheduling priorities corresponding to each of the frame levels are respectively obtained according to the correspondence between the preset frame level and the scheduling priority;
  • a second aspect of the embodiments of the present application provides a hot update apparatus for a mobile application, including:
  • a first obtaining module configured to respectively acquire each frame level in which a version update prompt occurs in the mobile application
  • a second obtaining module configured to: if the frame level of the version update prompt is multiple, Corresponding relationship between the preset framework level and the scheduling priority, respectively obtaining the scheduling priority corresponding to each of the framework levels;
  • the hot update module is configured to sequentially control each of the framework levels to perform a hot update operation based on the order of the scheduling priorities.
  • a third aspect of the embodiments of the present application provides an electronic device, including a memory, a processor, and computer readable instructions stored on the memory and executable on the processor, the processor Performing the computer sequence implementation implements the following steps:
  • the scheduling priorities corresponding to each of the frame levels are respectively obtained according to the corresponding relationship between the preset framework level and the scheduling priority;
  • a fourth aspect of the embodiments of the present application provides a computer readable storage medium storing computer readable instructions, the computer readable instructions being executed by at least one processor The following steps:
  • the number of the framework levels in the version update prompt is multiple, and the scheduling priority corresponding to each frame level is obtained, and the scheduling priority can be sequentially controlled based on the scheduling priority.
  • the hot update operation is performed at each framework level, and the ordered scheduling between multiple framework levels is realized, which avoids the phenomenon of hot update preemption or hot update conflict between multiple framework levels, thereby ensuring that the mobile application is in the hot update process. It is able to continue to operate normally, thereby increasing the stability of the mobile application.
  • FIG. 1 is a flowchart of implementing a hot update method of a mobile application according to an embodiment of the present application
  • FIG. 2 is a flowchart of a specific implementation of a hot update method S103 of a mobile application according to an embodiment of the present disclosure
  • FIG. 3 is a schematic diagram of a prompt window including application update description information provided by an embodiment of the present application
  • FIG. 4 is a flowchart of a specific implementation of a hot update method S301 for a mobile application according to another embodiment of the present disclosure
  • FIG. 6 is a flowchart of an implementation of a hot update method for a mobile application according to another embodiment of the present application.
  • FIG. 7 is a schematic diagram of a progress bar displayed on a mobile terminal interface according to another embodiment of the present application.
  • FIG. 8 is a structural block diagram of a hot update apparatus for a mobile application according to an embodiment of the present application.
  • FIG. 9 is a structural block diagram of a hot update apparatus for a mobile application according to another embodiment of the present application.
  • FIG. 10 is a schematic diagram of an electronic device according to an embodiment of the present application. Embodiments of the invention
  • FIG. 1 shows an implementation flow of a hot update method for a mobile application provided by an embodiment of the present application, where the method process includes steps S101 to S103.
  • the specific implementation principles of each step are as follows:
  • S101 respectively acquire respective framework levels in which a version update prompt appears in the mobile application.
  • the framework level includes but is not limited to the Native layer, React
  • Front-end framework levels such as the Native layer, H5 layer, Xscript layer, JS layer, and WEEX layer.
  • the level of the framework that exists in mobile applications varies from mobile to mobile.
  • the framework level may include the Native layer and the H5 layer.
  • the framework level may include the Native layer, the React Native layer, and the H5 layer. Therefore, before obtaining the various framework levels in the mobile application where the version update prompt appears, the various framework levels present in the mobile application are detected first.
  • the background server is connected to request the server to return a version update prompt related to each framework level.
  • the manner in which the update detection event is triggered may be, for example,: when the mobile application is detected, triggering the update detection event; or, when it is detected that the control for detecting the update in the mobile application is selected, triggering the update detection event.
  • a version update prompt will be detected at the framework level.
  • Each framework level in the mobile application is identified to determine if a version update prompt appears at each framework level, thereby obtaining the various framework levels at which the version update prompt is currently engraved.
  • S102 If there are multiple frame levels of the version update prompt, the scheduling priority corresponding to each of the frame levels is respectively obtained according to a preset correspondence between the frame level and the scheduling priority. [0042] The mobile application has previously set a correspondence between each framework level and each scheduling priority. If it is detected that the number of the frame levels of the version update prompt is greater than one, the scheduling priority corresponding to each frame level in which the version update prompt occurs is obtained according to the preset correspondence. The scheduling priority indicates the priority level of the framework level after performing the hot update operation.
  • S103 Perform a hot update operation by sequentially controlling each of the frame levels in sequence according to the order of the scheduling priorities.
  • the hot updates at the respective framework levels are sequentially performed.
  • the process of hot update includes the downloading, decompression, and validation of the updated data package.
  • the scheduling priority corresponding to the Native layer at the bottom of the mobile application is pre- Set to the highest level
  • the scheduling priority corresponding to the React Native layer in the middle layer is preset to the next highest level
  • the scheduling priority corresponding to the H5 layer on the top layer of the mobile application is preset to the lowest level.
  • the order of the scheduling priority is determined as the Native layer > React Native layer > H5 layer.
  • the Native layer performs the hot update
  • the hot update of the Native layer is completed
  • the H5 layer is controlled to perform the hot update.
  • the principle of higher scheduling priority of hot update can guarantee the update failure at the high-level framework level, and will not affect the normal operation of each component in the underlying framework hierarchy, ensuring mobile applications. There is no crash in the hot update process.
  • it ensures that the various framework levels of the upper layer of the mobile application can properly call the underlying components and the underlying programs that they need to rely on, thus improving the reliability of the mobile application.
  • the number of the framework levels in which the version update prompt occurs is multiple, and the scheduling priority corresponding to each frame level is obtained, and the scheduling priority can be sequentially controlled based on the scheduling priority.
  • FIG. 2 shows a specific implementation process of the hot update method S 103 of the mobile application provided by the embodiment of the present application, which is described in detail as follows:
  • S301 Obtain version update description information of each of the framework levels.
  • the version update description information is preset by the version issuer. After obtaining the version update prompt returned by the background server, the version update description information of each framework level is also obtained. The version update description information of each framework level is used to describe the content modification made to the framework level after the completion of this hot update.
  • S302 Summarize each version update description information to obtain application update description information.
  • S303 Display the application update description information on an interface of the mobile application, and issue an update confirmation request related to the application update description information.
  • the prompt window is a forced update prompt window or a suggested update prompt window.
  • the prompt window is a forced update prompt window
  • the preset position of the prompt window only a certain selection control is displayed, which is used to request the user to issue an update confirmation after browsing the application update description information.
  • the prompt window is a suggestion update prompt window
  • a confirmation selection control and a deselection control are displayed in the prompt window, which are used to request the user to issue an update confirmation after browsing the application update description information, and can also be used to obtain the user issuing Update cancellation instruction.
  • S304 If an update confirmation instruction sent by the user on the interface is received, the hot update operation is sequentially performed in each of the framework levels according to the order of the scheduling priority.
  • the user by displaying the version update description information of multiple framework levels in the same prompt window of the mobile application, the user is required to separately check the prompt window that only contains one version update description information to confirm the update. , reducing the user's operational complexity and improving the efficiency of hot updates.
  • the user can only issue an update confirmation instruction after consulting the application update description information, thereby avoiding the user issuing an update cancellation instruction, thereby implementing the framework level.
  • the mandatory update ensures that mobile applications can run a more stable version and improve the stability of mobile applications.
  • the foregoing S301 specifically includes:
  • S3011 Obtain a hot update mode of each of the framework levels, where the hot update mode includes a forced update, a recommended update, and a silent update.
  • a hot update mode of each frame level that needs to perform a hot update operation is obtained, and a hot update mode of each frame level in a default state is pre-released by a version issuer or a mobile application. Settings.
  • the hot update mode for each framework level is one of forced update, recommended update, and silent update.
  • Forced update means that the framework level can only issue an update confirmation command before the hot update is completed, otherwise the user is not allowed to continue using the mobile application; it is recommended to update the update packet indicating the framework level after downloading, suggesting the user to execute immediately in the prompt window
  • the framework level is hot updated, but the user can also choose to cancel the update to perform the hot update of the framework level next time the mobile application is launched; the silent update indicates that the framework level silently downloads the update packet in the mobile application background, and starts the next time.
  • the mobile app silently performs a hot update whose hot update process is invisible to the user.
  • S3012 In each of the framework levels, determining that the hot update mode is a mandatory update or a suggested update framework level.
  • the hot update mode is filtered to force update or suggestion New individual framework levels. After obtaining the filtered version update description information of each frame level, the subsequent steps S302 to S304 are performed.
  • the hot update mode of different framework levels is determined, and only the version update description information of the framework level whose hot update mode is forced update or recommended update is obtained, so that the display is displayed in the mobile application interface of S304.
  • the application update description information can include the version update description information of the framework level of the silent update, ensuring that the framework level of the silent update can not understand the heat of the silent update framework level even if the hot update is performed sequentially with other framework levels. Updated information to enhance data security at the mobile app framework level.
  • the method further includes:
  • S3014 if there is a first framework level in which the hot update mode is forced update, acquiring a second frame level with the scheduling priority higher than the first frame level, and acquiring the scheduling priority is low. At the first frame level and the hot update mode is a third frame level that is recommended for update.
  • a framework level in which the hot update mode is forced update is referred to as a first frame level; a frame level in which a scheduling priority is higher than the frame level is referred to as a second frame level.
  • the framework level with the scheduling priority lower than the first framework level and the hot update mode to the recommended update is called the third framework level.
  • the framework level in which the hot update mode is the recommended update is referred to as a fourth framework level.
  • S3015 After determining the fourth frame level of each engraving, S3016 is performed.
  • S3015 Adjust the hot update mode of the second frame level and the third frame level to a forced update.
  • S3016 If there is a fourth framework level in which the hot update mode is a recommended update, acquiring a fifth frame level with the scheduling priority higher than the fourth frame level, and the fifth frame level The hot update mode is adjusted to force update or suggest update.
  • the hot update mode of the framework level whose scheduling priority is higher than the fourth framework level is adjusted to be forced update or recommended update.
  • the hot update mode of each frame level in the default state is silent update, the hot update mode of each frame level is not adjusted.
  • the frame level of the version update prompt appears in the mobile application is the Native layer, the React Native layer, and the H5 layer, and the order of the scheduling priority is in the order of the Native layer, the React Native layer, and the H5 layer
  • the hot update mode of the obtained React Native layer is forced update, and the hot update mode of the Native layer is silent update, and the hot update mode of the Native layer whose scheduling priority is higher than that of the React Native layer is adjusted to be forced update;
  • the H5 layer is If the hot update mode is a recommended update, the hot update mode of the H5 layer whose scheduling priority is lower than the Rea ct Native layer is adjusted to be forced update.
  • the hot update mode of the obtained React Native layer is a recommended update
  • the hot update mode of the Native layer is a silent update
  • the hot update mode of the Native layer whose scheduling priority is higher than that of the React Native layer is adjusted to be forced update or Suggested updates.
  • the process returns to S3014 again, and the hot update mode of the React Native layer and the H5 layer whose scheduling priority is lower than the Native layer is adjusted to the forced update. Therefore, in this example, corresponding to the hot update mode adjustment strategy of the above S3014 to S3016, Table 1 shows a combination scheme of the hot update modes of the respective frame levels that may eventually occur under such a hot update mode adjustment policy:
  • the framework level is the lower layer of the mobile application.
  • the framework therefore, requires a mandatory update in the first frame level with a higher scheduling priority, and adjusts the hot update mode of the second frame level whose scheduling priority is lower than the first frame level to a mandatory update, so that the higher layer in the mobile application
  • the underlying framework hierarchy must also be forced to update, ensuring that the higher-level framework hierarchy can still depend on the underlying framework hierarchy to function properly after forced updates.
  • the hot update mode of the third frame level whose scheduling priority is lower than the first frame level and the hot update mode to the recommended update to the forced update By adjusting the hot update mode of the third frame level whose scheduling priority is lower than the first frame level and the hot update mode to the recommended update to the forced update, the need to use the forced update prompt window and the suggestion update prompt window in S302 is avoided. To obtain the update confirmation command issued by the user, it is guaranteed that the version update description information can be summarized in the same window.
  • the hot update mode is a fourth frame level that is recommended to be updated, and the hot update mode of the fifth frame level whose scheduling priority is higher than the fourth frame level is adjusted to a mandatory update.
  • the process returns to execution S3014, thereby realizing the orientation adjustment of the hot update mode to achieve the above advantageous effects.
  • the hot update mode of the fifth frame level with the scheduling priority higher than the fourth frame level to the recommended update the higher layer frame level and the lower layer frame level in the mobile application can be recommended to update simultaneously, and the guarantee is guaranteed.
  • the version update description information of the two framework levels can be summarized in the same suggestion update prompt window.
  • the actual update progress display manner of each frame level is further defined. As shown in FIG. 6, after the above S103, the method further includes:
  • S104 Calculate a second actual update progress of the mobile application according to a first actual update progress corresponding to each of the frame levels.
  • S105 In an interface of the mobile terminal, generate a progress bar based on the progress of the second real update.
  • the actual update progress corresponding to each frame level is detected.
  • the calculation method of the actual update schedule may be, for example, the decompression installation progress of the update packet of each framework level.
  • the actual update progress of the mobile application in the overall sense is calculated by a preset algorithm based on the actual update progress of each frame level. . Moreover, the preset algorithm can make the actual update progress of the last framework level in the hot update process reach 100%, and the actual update progress of the mobile application is also 100%. [0086] As shown in FIG. 7, the progress bar includes a sub-area 1 for characterizing the progress of the hot update, and according to the actual ratio of the total area 2 of the progress bar occupying the progress area, a dynamically changing progress bar can be generated.
  • the second actual update progress of the mobile application is calculated based on the first actual update progress of each framework level, and a progress bar that is convenient for the user to visually observe can be merged and generated in the mobile application interface.
  • a progress bar that is convenient for the user to visually observe can be merged and generated in the mobile application interface.
  • FIG. 8 is a structural block diagram of the hot update device of the mobile application provided by the embodiment of the present application. For the convenience of description, only the present embodiment is shown. Apply for the relevant parts of the embodiment.
  • the device includes:
  • the first obtaining module 81 is configured to separately acquire each frame level of the version update prompt in the mobile application.
  • the second obtaining module 82 is configured to: if the frame level of the version update prompt is multiple, obtain corresponding to each of the frame levels according to a correspondence between a preset frame level and a scheduling priority. Scheduling priority.
  • the hot update module 83 is configured to sequentially control each of the framework levels to perform a hot update operation based on the order of the scheduling priorities.
  • the hot update module 83 includes:
  • an obtaining submodule configured to obtain version update description information of each of the framework levels.
  • a summary sub-module configured to summarize each of the version update description information to obtain an application update description.
  • a display submodule configured to display the application update description information on an interface of the mobile application, concurrently An update confirmation request related to the application update description information.
  • the control submodule is configured to, if receiving an update confirmation instruction issued by the user on the interface, sequentially control each of the framework levels to perform a hot update operation based on the order of the scheduling priorities.
  • the obtaining submodule is specifically configured to:
  • the hot update mode including forced update, recommended update, and silent update
  • the frame level includes a first frame level, a second frame level, a third frame level, a fourth frame level, and a fifth frame level
  • the obtaining submodule is further configured to:
  • a first frame level in which the hot update mode is forced update if there is a first frame level in which the hot update mode is forced update, acquiring a second frame level with the scheduling priority higher than the first frame level, and acquiring the scheduling priority lower than the Describe a first framework level and the hot update mode is a third framework level that is recommended to be updated;
  • the hot update mode is a recommended update
  • acquiring a fifth frame level with the scheduling priority higher than the fourth frame level and the fifth frame level
  • the hot update mode is adjusted to force update or suggest update.
  • the hot update device of the mobile application further includes:
  • the calculation module 84 is configured to calculate a second actual update progress of the mobile application according to a first actual update progress corresponding to each of the frame levels.
  • the generating module 85 is configured to generate, in the interface of the mobile terminal, a progress bar based on the progress of the second real update.
  • the number of the framework levels in which the version update prompt occurs is multiple, and the scheduling priority corresponding to each frame level is obtained, and the scheduling priority can be sequentially controlled based on the scheduling priority.
  • the hot update operation is performed at each framework level, which realizes the orderly scheduling between multiple framework levels, avoiding the phenomenon of hot update preemption or hot update conflict between multiple framework levels, thus ensuring the shift
  • the dynamic application can continue to operate normally during the hot update process, thereby improving the stability of the mobile application.
  • FIG. 10 is a schematic diagram of an electronic device according to an embodiment of the present application.
  • the electronic device 10 of this embodiment includes: a processor 1000, a memory 1001, and computer readable instructions 1002 stored in the memory 1001 and executable on the processor 1000, such as a mobile application. Hot update program.
  • the processor 1000 executes the computer readable instructions 1002 to implement the steps in the thermal update method embodiments of the various mobile applications described above, such as steps 101 through 103 shown in FIG.
  • the processor 1000 executes the computer readable instructions 1002 to implement the functions of the modules/units in the various apparatus embodiments described above, such as the functions of the modules 81 to 83 shown in FIG.
  • the computer readable instructions 1002 may be partitioned into one or more modules/units, the one or more modules/units being stored in the memory 1001, and by the processor 1000 is executed to complete the application.
  • the one or more modules/units may be a series of computer readable instruction instruction segments capable of performing a particular function, the instruction segments being used to describe the execution of the computer readable instructions 1002 in the electronic device 10.
  • the electronic device 10 may be a computing device such as a desktop computer, a notebook, a palmtop computer, and a cloud server.
  • the electronic device may include, but is not limited to, the processor 1000, the memory 1001. It will be understood by those skilled in the art that FIG. 10 is merely an example of the electronic device 10 and does not constitute a limitation on the electronic device 10, and may include more or less components than those illustrated, or combine some components, or different components.
  • the electronic device may further include an input/output device, a network access device, a bus, and the like.
  • the processor 1000 may be a central processing unit (CPU), or may be another general-purpose processor, a digital signal processor (DSP), or an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), ready-to-use programmable gate array
  • CPU central processing unit
  • DSP digital signal processor
  • ASIC Application Specific Integrated Circuit
  • the general purpose processor may be a microprocessor or the processor or any conventional processor or the like.
  • the memory 1001 may be an internal storage unit of the electronic device 10, such as a hard disk or a memory of the electronic device 10.
  • the memory 1001 may also be an external storage device of the electronic device 10, such as a plug-in hard disk equipped on the electronic device 10, a smart memory card (SMC), and a secure digital (SD). Card, flash card, etc. Further, the deposit
  • the reservoir 1001 may also include both an internal storage unit of the electronic device 10 and an external storage device.
  • the memory 1001 is configured to store the computer readable instructions and other programs and data required by the electronic device.
  • the memory 1001 can also be used to temporarily store data that has been output or is about to be output.
  • each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
  • the above integrated unit can be implemented in the form of hardware or in the form of a software functional unit.
  • the integrated unit if implemented in the form of a software functional unit and sold or used as a standalone product, may be stored in a computer readable storage medium.
  • a computer readable storage medium A number of instructions are included to cause a computer device (which may be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods described in various embodiments of the present application.
  • the foregoing storage medium includes: a U disk, a removable hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and the like, which can store program codes. .

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Telephone Function (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

一种移动应用的热更新方法、装置、电子设备及介质，适用于移动应用技术领域，该方法包括：分别获取移动应用中出现版本更新提示的各个框架层级（S101）；若出现版本更新提示的所述框架层级为多个，则根据预设的框架层级与调度优先级的对应关系，分别获取每一所述框架层级对应的调度优先级（S102）；基于所述调度优先级的高低顺序，依次控制各个所述框架层级执行热更新操作（S103）。该方案基于调度优先级的高低顺序，依次控制各个框架层级执行热更新操作，实现了多个框架层级之间的有序调度，避免了多个框架层级之间出现热更新抢占或热更新冲突的现象，从而保证了移动应用在热更新过程中能够持续正常运行，由此提高了移动应用的稳定性。

Description

移动应用的热更新方法、 装置、 电子设备及介质
[0001] 本申请要求于 2017年 07月 31日提交中国专利局、 申请号为 201710637113.6、 发 明名称为"移动应用的热更新方法及终端设备"的中国专利申请的优先权， 其全 部内容通过引用结合在本申请中。
技术领域
[0002] 本申请属于移动应用技术领域， 尤其涉及一种移动应用的热更新方法、 装置、 电子设备及介质。
[]
背景技术
[0003] 为了满足用户的动态化需求， 及吋修复移动应用中的漏洞， 增强移动应用的运 营能力， 目前， 移动应用均已提供了多种层面的热更新功能， 例如 Native层、 Re act Native层以及 H5层等不同框架层的热更新功能。
[0004] 对于一个移动应用而言， 如果多个层面同吋出现热更新， 则可能会出现不同层 面热更新互相抢占以及相互冲突的问题。 例如， 若 React Native层以及 H5层的热 更新吋长不同， 则在 React Native层热更新执行完毕后， 移动应用将会自动返回 应用首页， 由此会导致 H5层的热更新出现中断， 从而无法正常完成 H5层的更新 ， 使得移动应用崩溃以及无法正常运行。 再例如， 由于 Native层为移动应用的最 底层， 因而若 React Native层抢先于 Native层执行热更新， 则更新后的 React Native层会因无法调用未更新的 Native层的组件而同样出现移动应用崩溃的问题
[0005] 综上， 现有技术中， 存在因不同层面热更新的互相抢占而导致移动应用难以正 常运行的问题。
技术问题
[0006] 有鉴于此， 本申请实施例提供了一种移动应用的热更新方法、 装置、 电子设备 及介质， 以解决现有技术中因不同层面热更新的互相抢占而导致移动应用难以 正常运行的问题。 问题的解决方案
技术解决方案
[0007] 本申请实施例的第一方面， 提供了一种移动应用的热更新方法， 包括：
[0008] 分别获取移动应用中出现版本更新提示的各个框架层级；
[0009] 若出现版本更新提示的所述框架层级为多个， 则根据预设的框架层级与调度优 先级的对应关系， 分别获取每一所述框架层级对应的调度优先级；
[0010] 基于所述调度优先级的高低顺序， 依次控制各个所述框架层级执行热更新操作
[0011] 本申请实施例的第二方面， 提供了一种移动应用的热更新装置， 包括：
[0012] 第一获取模块， 用于分别获取移动应用中出现版本更新提示的各个框架层级； [0013] 第二获取模块， 用于若出现版本更新提示的所述框架层级为多个， 则根据预设 的框架层级与调度优先级的对应关系， 分别获取每一所述框架层级对应的调度 优先级；
[0014] 热更新模块， 用于基于所述调度优先级的高低顺序， 依次控制各个所述框架层 级执行热更新操作。
[0015] 本申请实施例的第三方面， 提供了一种电子设备， 包括存储器、 处理器及存储 在所述存储器上并可在所述处理器上运行的计算机可读指令， 所述处理器执行 所述计算机序吋实现如下步骤：
[0016] 分别获取移动应用中出现版本更新提示的各个框架层级；
[0017] 若出现版本更新提示的所述框架层级为多个， 则根据预设的框架层级与调度优 先级的对应关系， 分别获取每一所述框架层级对应的调度优先级；
[0018] 基于所述调度优先级的高低顺序， 依次控制各个所述框架层级执行热更新操作
[0019] 本申请实施例的第四方面， 提供了一种计算机可读存储介质， 所述计算机可读 存储介质存储有计算机可读指令， 所述计算机可读指令被至少一个处理器执行 吋实现如下步骤：
[0020] 分别获取移动应用中出现版本更新提示的各个框架层级；
[0021] 若出现版本更新提示的所述框架层级为多个， 则根据预设的框架层级与调度优 先级的对应关系， 分别获取每一所述框架层级对应的调度优先级；
[0022] 基于所述调度优先级的高低顺序， 依次控制各个所述框架层级执行热更新操作 发明的有益效果
有益效果
[0023] 本申请实施例中， 在出现版本更新提示的框架层级的数量为多个吋， 通过获取 每一框架层级所预设对应的调度优先级， 能够基于调度优先级的高低顺序， 依 次控制各个框架层级执行热更新操作， 实现了多个框架层级之间的有序调度， 避免了多个框架层级之间出现热更新抢占或热更新冲突的现象， 从而保证了移 动应用在热更新过程中能够持续正常运行， 由此提高了移动应用的稳定性。
[]
对附图的简要说明
附图说明
[0024] 为了更清楚地说明本申请实施例中的技术方案， 下面将对实施例或现有技术描 述中所需要使用的附图作简单地介绍， 显而易见地， 下面描述中的附图仅仅是 本申请的一些实施例， 对于本领域普通技术人员来讲， 在不付出创造性劳动性 的前提下， 还可以根据这些附图获得其他的附图。
[0025] 图 1是本申请实施例提供的移动应用的热更新方法的实现流程图；
[0026] 图 2是本申请实施例提供的移动应用的热更新方法 S103的具体实现流程图； [0027] 图 3是本申请实施例提供的包含有应用更新描述信息的提示窗口的示意图； [0028] 图 4是本申请实施例提供的移动应用的热更新方法 S301的具体实现流程图； [0029] 图 5是本申请另一实施例提供的移动应用的热更新方法 S301的具体实现流程图
[0030] 图 6是本申请又一实施例提供的移动应用的热更新方法的实现流程图；
[0031] 图 7是本申请又一实施例提供的展示于移动终端界面的进度条的示意图；
[0032] 图 8是本申请实施例提供的移动应用的热更新装置的结构框图；
[0033] 图 9是本申请又一实施例提供的移动应用的热更新装置的结构框图；
[0034] 图 10是本申请实施例提供的电子设备的示意图。 本发明的实施方式
[0035] 以下描述中， 为了说明而不是为了限定， 提出了诸如特定系统结构、 技术之类 的具体细节， 以便透彻理解本申请实施例。 然而， 本领域的技术人员应当清楚 ， 在没有这些具体细节的其它实施例中也可以实现本申请。 在其它情况中， 省 略对众所周知的系统、 装置、 电路以及方法的详细说明， 以免不必要的细节妨 碍本申请的描述。
[0036] 为了说明本申请所述的技术方案， 下面通过具体实施例来进行说明。
[0037] 图 1示出了本申请实施例提供的移动应用的热更新方法的实现流程， 该方法流 程包括步骤 S101至 S103。 各步骤的具体实现原理如下：
[0038] S101 : 分别获取移动应用中出现版本更新提示的各个框架层级。
[0039] 本申请实施例中， 框架层级包括但不限于 Native层、 React
Native层、 H5层、 Xscript层、 JS层以及 WEEX层等前端框架层级。 根据移动应用 的不同， 存在于移动应用中的框架层级也不同。 例如， 对于一个基于 H5幵发的 移动应用来说， 其框架层级可能包含 Native层和 H5层。 而对于一个 React Native应用， 其框架层级则可能包括 Native层、 React Native层和 H5层。 因此 ， 在获取移动应用中出现版本更新提示的各个框架层级之前， 先检测移动应用 中所存在的各个框架层级。 在基于各个框架层级的更新检测事件被触发吋， 连 接后台服务器， 以请求服务器返回与各个框架层级相关的版本更新提示。 其中 ， 更新检测事件被触发的方式例如可以是： 当检测到移动应用启动吋， 触发更 新检测事件； 或者， 当检测到移动应用中用于检测更新的控件被选取吋， 触发 更新检测事件。
[0040] 若某一框架层级的当前版本低于后台服务器中已发布的该框架层级的最新版本 ， 则在移动应用中， 将检测到该框架层级出现版本更新提示。 对移动应用中的 每一框架层级进行识别， 以确定每一框架层级是否出现版本更新提示， 由此可 获取当前吋刻出现版本更新提示的各个框架层级。
[0041] S102: 若出现版本更新提示的所述框架层级为多个， 则根据预设的框架层级与 调度优先级的对应关系， 分别获取每一所述框架层级对应的调度优先级。 [0042] 移动应用已预先设置有各框架层级与各调度优先级的对应关系。 若检测出当前 吋刻出现版本更新提示的框架层级的数量大于一， 则根据该预设的对应关系， 获取出现版本更新提示的每一框架层级所分别对应的调度优先级。 其中， 调度 优先级表示框架层级在执行热更新操作吋的优先等级。
[0043] S103: 基于所述调度优先级的高低顺序， 依次控制各个所述框架层级执行热更 新操作。
[0044] 根据各个框架层级所对应的调度优先级的高低顺序， 依次执行各个框架层级上 的热更新。 热更新的过程包括更新数据包的下载、 解压以及更新数据的生效。 当 H5层的热更新操作完成吋， 刷新当前移动应用所展示的页面； 当 React Native 层的热更新操作完成吋， 将当前移动应用所展示的页面跳转至应用首页； 当 Nati ve层的热更新操作完成吋， 重新启动移动应用。 并且， 对于移动应用越底层的 框架层级来说， 其对应的调度优先级越高。
[0045] 示例性地， 若当前吋刻出现版本更新提示的框架层级有三个， 分别为 Native层 、 React Native层以及 H5层， 则将处于移动应用最底层的 Native层所对应的调 度优先级预设为最高级， 将处于中间层的 React Native层所对应的调度优先级预 设为次高级， 将处于移动应用顶层的 H5层所对应的调度优先级预设为最低级。 根据 Native层、 React Native层以及 H5层所分别对应的调度优先级， 可得出调 度优先级的高低顺序为 Native层> React Native层> H5层。 因此， 令 Native层执 行热更新， 且在 Native层的热更新完成吋， 再控制 React Native层执行热更新。 同理， 在 React Native层的热更新完成吋， 再控制 H5层执行热更新。 基于越底层 的框架层级， 其热更新的调度优先级越高的原理， 可保证在高层的框架层级出 现更新失败吋， 也不会影响底层的框架层级中各组件的正常运行， 保证了移动 应用不至于在热更新过程中出现崩溃的问题。 另外， 还保证了移动应用上层的 各个框架层级能够正常调用其所需依赖的底层组件以及底层程序， 因而也提高 了移动应用的可靠性。
[0046] 本申请实施例中， 在出现版本更新提示的框架层级的数量为多个吋， 通过获取 每一框架层级所预设对应的调度优先级， 能够基于调度优先级的高低顺序， 依 次控制各个框架层级执行热更新操作， 实现了多个框架层级之间的有序调度， 避免了多个框架层级之间出现热更新抢占或热更新冲突的现象， 从而保证了移 动应用在热更新过程中能够持续正常运行， 由此提高了移动应用的稳定性。
[0047] 作为本申请的一个实施例， 图 2示出了本申请实施例提供的移动应用的热更新 方法 S 103的具体实现流程， 详述如下：
[0048] S301 : 获取每一所述框架层级的版本更新描述信息。
[0049] 本申请实施例中， 版本更新描述信息由版本幵发人员预先设置。 在获取后台服 务器返回的版本更新提示吋， 还将获取每一框架层级的版本更新描述信息。 每 一框架层级的版本更新描述信息用于描述本次热更新完成后， 对该框架层级所 作出的内容修改。
[0050] S302: 将各个所述版本更新描述信息进行汇总， 得到应用更新描述信息。
[0051] S303: 将所述应用更新描述信息展示于所述移动应用的界面， 并发出与所述应 用更新描述信息相关的更新确认请求。
[0052] 不同的框架层级， 其在热更新完成后需要分别作出不同的内容修改。 将各版本 更新描述信息汇总显示于移动应用界面的同一提示窗口。 提示窗口中所描述的 各项内容能够从整体上反映移动应用热更新后所作出的各项修改， 因而将汇总 后的各个版本更新描述信息输出为应用更新描述信息。
[0053] 如图 3所示， 在提示窗口中， 在每一版本更新描述信息后， 分别标注其所对应 的框架层级， 使得移动应用的用户能够在移动应用的同一提示窗口上直接浏览 并区分出各个框架层级的版本更新描述信息。
[0054] 本申请实施例中， 提示窗口为强制更新提示窗口或建议更新提示窗口。
[0055] 当提示窗口为强制更新提示窗口吋， 在提示窗口的预设位置， 仅展示一确定选 择控件， 其用于请求用户在浏览应用更新描述信息后发出更新确认。
[0056] 当提示窗口为建议更新提示窗口吋， 在提示窗口中展示有确定选择控件以及取 消选择控件， 其用于请求用户在浏览应用更新描述信息后发出更新确认， 并且 还可用于获取用户发出的更新取消指令。
[0057] S304: 若接收到用户在所述界面发出的更新确认指令， 则基于所述调度优先级 的高低顺序， 依次控制各个所述框架层级执行热更新操作。
[0058] 当检测到上述确定选择控件被选取吋， 确定接收到用户发出的更新确认指令。 根据各个需要执行热更新操作的框架层级的调度优选级， 依次完成各个框架层 级的热更新。
[0059] 本申请实施例中， 通过将多个框架层级的版本更新描述信息合并显示于移动应 用的同一提示窗口， 避免了用户需要分别査阅仅包含一条版本更新描述信息的 提示窗口来确认更新， 降低了用户的操作复杂度， 提高了热更新的效率。 通过 在强制更新提示窗口中发出基于一确定选择控件的更新确认请求， 使得用户在 査阅完毕应用更新描述信息吋， 仅能发出更新确认指令， 避免了用户发出更新 取消指令， 因而实现了框架层级的强制更新， 保证了移动应用能够运行较为稳 定的版本， 提高了移动应用的稳定性。 通过在建议更新提示窗口中展示确定选 择控件以及取消选择控件， 使得用户能够自由选择框架层级的更新吋机， 实现 了用户对热更新操作的灵活控制。
[0060] 作为本申请的一个实施例， 如图 4所示， 上述 S301具体包括：
[0061] S3011 : 获取每一所述框架层级的热更新模式， 所述热更新模式包括强制更新 、 建议更新以及静默更新。
[0062] 本申请实施例中， 获取需要执行热更新操作的每一框架层级的热更新模式， 每 一框架层级在默认状态下的热更新模式由版本幵发人员或者移动应用的幵发人 员预先设置。 每一框架层级的热更新模式为强制更新、 建议更新以及静默更新 中的一种。
[0063] 强制更新表示框架层级在热更新完成之前， 用户只能发出更新确认指令， 否则 不允许用户继续使用移动应用； 建议更新表示框架层级的更新数据包下载后， 在提示窗口建议用户立即执行该框架层级的热更新， 但用户也可选择取消更新 ， 以在下次启动移动应用吋再执行该框架层级的热更新； 静默更新表示框架层 级在移动应用后台静默下载更新数据包， 并在下次启动移动应用吋静默执行热 更新， 其热更新过程对于用户而言是不可见的。
[0064] S3012: 在各个所述框架层级中， 确定出所述热更新模式为强制更新或建议更 新的框架层级。
[0065] S3013: 获取确定出的各个所述框架层级的版本更新描述信息。
[0066] 在不同热更新模式的多个框架层级中， 筛选出热更新模式为强制更新或建议更 新的各个框架层级。 获取筛选出的各个框架层级的版本更新描述信息后， 执行 后续的步骤 S302至 S304。
[0067] 本申请实施例中， 通过确定不同框架层级的热更新模式， 且仅获取热更新模式 为强制更新或建议更新的框架层级的版本更新描述信息， 使得在 S304的移动应 用界面中所显示的应用更新描述信息能够不包含静默更新的框架层级的版本更 新描述信息， 保证了静默更新的框架层级即使与其他框架层级依序执行热更新 ， 用户也无法了解该静默更新框架层级的各项热更新信息， 增强了移动应用框 架层级的数据安全。
[0068] 作为本申请的另一个实施例， 如图 5所示， 在上述 S3012之前， 还包括：
[0069] S3014: 若存在所述热更新模式为强制更新的第一框架层级， 则获取所述调度 优先级高于所述第一框架层级的第二框架层级， 并获取所述调度优先级低于所 述第一框架层级且所述热更新模式为建议更新的第三框架层级。
[0070] 为了便于区分不同热更新模式的各个框架层级， 将热更新模式为强制更新的框 架层级称为第一框架层级； 将调度优先级比该框架层级高的框架层级称为第二 框架层级； 将调度优先级低于第一框架层级， 且热更新模式为建议更新的框架 层级称为第三框架层级。
[0071] 另外， 将热更新模式为建议更新的框架层级称为第四框架层级。
[0072] 在确定出各个吋刻的第一框架层级、 第二框架层级以及第三框架层级后， 执行
S3015。 在确定出各个吋刻的第四框架层级后， 执行 S3016。
[0073] S3015: 将所述第二框架层级以及所述第三框架层级的所述热更新模式调整为 强制更新。
[0074] S3016: 若存在所述热更新模式为建议更新的第四框架层级， 则获取所述调度 优先级高于所述第四框架层级的第五框架层级， 并将所述第五框架层级的所述 热更新模式调整为强制更新或建议更新。
[0075] 本申请实施例中， 将调度优先级高于第四框架层级的框架层级的热更新模式调 整为强制更新或建议更新。
[0076] 若默认状态下各框架层级的热更新模式均为静默更新， 则不对各框架层级的热 更新模式进行调整。 [0077] 例如， 在移动应用中出现版本更新提示的框架层级为 Native层、 React Native层 以及 H5层， 且调度优先级的高低顺序依次为 Native层、 React Native层以及 H5层 的情况下， 若获取得到的 React Native层的热更新模式为强制更新， Native层的热 更新模式为静默更新， 则将调度优先级高于 React Native层的 Native层的热更新模 式调整为强制更新； 若 H5层的热更新模式为建议更新， 则将调度优先级低于 Rea ct Native层的 H5层的热更新模式调整为强制更新。 又例如， 若获取得到的 React Native层的热更新模式为建议更新， Native层的热更新模式为静默更新， 则将调 度优先级高于 React Native层的 Native层的热更新模式调整为强制更新或建议更新 。 这种情况下， 假设 Native层的热更新模式调整为强制更新， 则可再次返回执行 S3014， 将调度优先级低于 Native层的 React Native层以及 H5层的热更新模式调整 为强制更新。 因此， 在本示例中， 对应于上述 S3014至 S3016的热更新模式调整 策略， 表 1示出了这种热更新模式调整策略下， 最终可能出现的各个框架层级的 热更新模式的组合方案：
[0078] 表 1
[]
[] [表 1]
Figure imgf000011_0001
[0079] 本申请实施例中， 由于调度优先级越高的框架层级， 其为移动应用中越底层的 框架， 因而在调度优先级较高的第一框架层级需要强制更新吋， 通过将调度优 先级低于第一框架层级的第二框架层级的热更新模式调整为强制更新， 使得移 动应用中较高层的框架层级在强制更新的情况下， 底层的框架层级也必须强制 更新， 保证了较高层的框架层级在强制更新后依然能够依赖于底层的框架层级 来正常运行。 通过将调度优先级低于第一框架层级且热更新模式为建议更新的 第三框架层级的热更新模式调整为强制更新， 避免了在 S302中需要同吋使用强 制更新提示窗口以及建议更新提示窗口来获取用户发出的更新确认指令， 保证 了版本更新描述信息能够在同一窗口中汇总显示。
[0080] 本申请实施例中， 通过获取热更新模式为建议更新的第四框架层级， 并将调度 优先级高于第四框架层级的第五框架层级的热更新模式调整为强制更新， 能够 在出现强制更新的第五框架层级的情况下， 重新返回执行 S3014, 由此实现了热 更新模式的定向调整， 以达到上述有益效果。 通过将调度优先级高于第四框架 层级的第五框架层级的热更新模式调整为建议更新， 使得移动应用中较高层的 框架层级以及较底层的框架层级均能同吋建议更新， 在保证了较高层的框架层 级能够依赖于底层的框架层级来正常更新运行的情况下， 还实现了两个框架层 级的版本更新描述信息能够在同一个建议更新提示窗口中汇总显示。
[0081] 作为本申请的又一实施例， 在上述各个实施例的基础之上， 对各框架层级的实 吋更新进度显示方式作进一步地限定。 如图 6所示， 在上述 S103之后， 还包括：
[0082] S104: 根据各个所述框架层级所分别对应的第一实吋更新进度， 计算所述移动 应用的第二实吋更新进度。
[0083] S105: 在所述移动终端的界面中， 生成基于所述第二实吋更新进度的进度条。
[0084] 在各个框架层级执行热更新操作的过程中， 检测各个框架层级对应的实吋更新 进度。 实吋更新进度的计算方式例如可以是各框架层级的更新数据包的解压安 装进度等。
[0085] 由于移动应用的整体更新需要依赖于各个框架层级的更新才能完成， 故基于各 个框架层级分别对应的实吋更新进度， 通过预设算法计算出移动应用在整体意 义上的实吋更新进度。 并且， 该预设算法可使得热更新过程中最后一个框架层 级的实吋更新进度达到 100%吋， 移动应用的实吋更新进度也为 100%。 [0086] 如图 7所示， 进度条中包含有用于表征热更新进度的子区域 1， 根据该子区域占 据进度条总面积 2的实吋比例不同， 可生成动态变化的进度条。
[0087] 当移动应用的实吋更新进度达到 100%吋， 刷新当前吋刻移动应用的页面或者 重新启动移动应用， 以使各框架层级的更新数据能够生效。
[0088] 本申请实施例中， 通过基于各个框架层级的第一实吋更新进度来计算出移动应 用的第二实吋更新进度， 能够在移动应用界面中合并生成便于用户直观观察的 一个进度条， 无需再分别査看不同框架层级的实吋更新进度； 由于用户通常仅 关注移动应用何吋能够更新完毕并恢复正常运行， 因而通过在移动应用界面中 合并显示唯一的一个进度条， 提高了热更新进度的提示有效性。
[0089] 应理解， 上述实施例中各步骤的序号的大小并不意味着执行顺序的先后， 各过 程的执行顺序应以其功能和内在逻辑确定， 而不应对本申请实施例的实施过程 构成任何限定。
[0090] 对应于上文实施例所述的移动应用的热更新方法， 图 8示出了本申请实施例提 供的移动应用的热更新装置的结构框图， 为了便于说明， 仅示出了与本申请实 施例相关的部分。
[0091] 参照图 8， 该装置包括：
[0092] 第一获取模块 81， 用于分别获取移动应用中出现版本更新提示的各个框架层级
[0093] 第二获取模块 82， 用于若出现版本更新提示的所述框架层级为多个， 则根据预 设的框架层级与调度优先级的对应关系， 分别获取每一所述框架层级对应的调 度优先级。
[0094] 热更新模块 83， 用于基于所述调度优先级的高低顺序， 依次控制各个所述框架 层级执行热更新操作。
[0095] 可选地， 所述热更新模块 83包括：
[0096] 获取子模块， 用于获取每一所述框架层级的版本更新描述信息。
[0097] 汇总子模块， 用于将各个所述版本更新描述信息进行汇总， 得到应用更新描述 f π息。
[0098] 展示子模块， 用于将所述应用更新描述信息展示于所述移动应用的界面， 并发 出与所述应用更新描述信息相关的更新确认请求。
[0099] 控制子模块， 用于若接收到用户在所述界面发出的更新确认指令， 则基于所述 调度优先级的高低顺序， 依次控制各个所述框架层级执行热更新操作。
[0100] 可选地， 所述获取子模块具体用于：
[0101] 获取每一所述框架层级的热更新模式， 所述热更新模式包括强制更新、 建议更 新以及静默更新；
[0102] 在各个所述框架层级中， 确定出所述热更新模式为强制更新或建议更新的框架 层级；
[0103] 获取确定出的各个所述框架层级的版本更新描述信息。
[0104] 可选地， 所述框架层级包括第一框架层级、 第二框架层级、 第三框架层级、 第 四框架层级以及第五框架层级， 所述获取子模块还用于：
[0105] 若存在所述热更新模式为强制更新的第一框架层级， 则获取所述调度优先级高 于所述第一框架层级的第二框架层级， 并获取所述调度优先级低于所述第一框 架层级且所述热更新模式为建议更新的第三框架层级；
[0106] 将所述第二框架层级以及所述第三框架层级的所述热更新模式调整为强制更新
[0107] 若存在所述热更新模式为建议更新的第四框架层级， 则获取所述调度优先级高 于所述第四框架层级的第五框架层级， 并将所述第五框架层级的所述热更新模 式调整为强制更新或建议更新。
[0108] 可选地， 如图 9所示， 所述移动应用的热更新装置还包括：
[0109] 计算模块 84， 用于根据各个所述框架层级所分别对应的第一实吋更新进度， 计 算所述移动应用的第二实吋更新进度。
[0110] 生成模块 85， 用于在所述移动终端的界面中， 生成基于所述第二实吋更新进度 的进度条。
[0111] 本申请实施例中， 在出现版本更新提示的框架层级的数量为多个吋， 通过获取 每一框架层级所预设对应的调度优先级， 能够基于调度优先级的高低顺序， 依 次控制各个框架层级执行热更新操作， 实现了多个框架层级之间的有序调度， 避免了多个框架层级之间出现热更新抢占或热更新冲突的现象， 从而保证了移 动应用在热更新过程中能够持续正常运行， 由此提高了移动应用的稳定性。
[0112] 图 10是本申请一实施例提供的电子设备的示意图。 如图 10所示， 该实施例的电 子设备 10包括： 处理器 1000、 存储器 1001以及存储在所述存储器 1001中并可在 所述处理器 1000上运行的计算机可读指令 1002， 例如移动应用的热更新程序。 所述处理器 1000执行所述计算机可读指令 1002吋实现上述各个移动应用的热更 新方法实施例中的步骤， 例如图 1所示的步骤 101至 103。 或者， 所述处理器 1000 执行所述计算机可读指令 1002吋实现上述各装置实施例中各模块 /单元的功能， 例如图 8所示模块 81至 83的功能。
[0113] 示例性的， 所述计算机可读指令 1002可以被分割成一个或多个模块 /单元， 所 述一个或者多个模块 /单元被存储在所述存储器 1001中， 并由所述处理器 1000执 行， 以完成本申请。 所述一个或多个模块 /单元可以是能够完成特定功能的一系 列计算机可读指令指令段， 该指令段用于描述所述计算机可读指令 1002在所述 电子设备 10中的执行过程。
[0114] 所述电子设备 10可以是桌上型计算机、 笔记本、 掌上电脑及云端服务器等计算 设备。 所述电子设备可包括， 但不仅限于， 处理器 1000、 存储器 1001。 本领域 技术人员可以理解， 图 10仅仅是电子设备 10的示例， 并不构成对电子设备 10的 限定， 可以包括比图示更多或更少的部件， 或者组合某些部件， 或者不同的部 件， 例如所述电子设备还可以包括输入输出设备、 网络接入设备、 总线等。
[0115] 所称处理器 1000可以是中央处理单元 (Central Processing Unit, CPU) , 还可以是 其他通用处理器、 数字信号处理器（Digital Signal Processor, DSP)、 专用集成电 路（Application Specific Integrated Circuit, ASIC)、 现成可编程门阵列
(Field-Programmable Gate Array , FPGA)或者其他可编程逻辑器件、 分立门或者 晶体管逻辑器件、 分立硬件组件等。 通用处理器可以是微处理器或者该处理器 也可以是任何常规的处理器等。
[0116] 所述存储器 1001可以是所述电子设备 10的内部存储单元， 例如电子设备 10的硬 盘或内存。 所述存储器 1001也可以是所述电子设备 10的外部存储设备， 例如所 述电子设备 10上配备的插接式硬盘， 智能存储卡 （Smart Media Card, SMC) ， 安全数字 （Secure Digital, SD) 卡， 闪存卡 （Flash Card) 等。 进一步地， 所述存 储器 1001还可以既包括所述电子设备 10的内部存储单元也包括外部存储设备。 所述存储器 1001用于存储所述计算机可读指令以及所述电子设备所需的其他程 序和数据。 所述存储器 1001还可以用于暂吋地存储已经输出或者将要输出的数 据。
[0117] 另外， 在本申请各个实施例中的各功能单元可以集成在一个处理单元中， 也可 以是各个单元单独物理存在， 也可以两个或两个以上单元集成在一个单元中。 上述集成的单元既可以采用硬件的形式实现， 也可以采用软件功能单元的形式 实现。
[0118] 所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用 吋， 可以存储在一个计算机可读取存储介质中。 基于这样的理解， 本申请的技 术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分 可以以软件产品的形式体现出来， 该计算机软件产品存储在一个存储介质中， 包括若干指令用以使得一台计算机设备 （可以是个人计算机， 服务器， 或者网 络设备等） 执行本申请各个实施例所述方法的全部或部分步骤。 而前述的存储 介质包括： U盘、 移动硬盘、 只读存储器 （ROM, Read-Only Memory) 、 随机 存取存储器 （RAM, Random Access Memory) 、 磁碟或者光盘等各种可以存储 程序代码的介质。
[0119] 以上所述， 以上实施例仅用以说明本申请的技术方案， 而非对其限制； 尽管参 照前述实施例对本申请进行了详细的说明， 本领域的普通技术人员应当理解： 其依然可以对前述各实施例所记载的技术方案进行修改， 或者对其中部分技术 特征进行等同替换； 而这些修改或者替换， 并不使相应技术方案的本质脱离本 申请各实施例技术方案的精神和范围。

Claims

权利要求书
[权利要求 1] 一种移动应用的热更新方法， 其特征在于， 包括：
分别获取移动应用中出现版本更新提示的各个框架层级；
若出现版本更新提示的所述框架层级为多个， 则根据预设的框架层级 与调度优先级的对应关系， 分别获取每一所述框架层级对应的调度优 先级；
基于所述调度优先级的高低顺序， 依次控制各个所述框架层级执行热 更新操作。
[权利要求 2] 如权利要求 1所述的移动应用的热更新方法， 其特征在于， 所述基于 所述调度优先级的高低顺序， 依次控制各个所述框架层级执行热更新 操作， 包括：
获取每一所述框架层级的版本更新描述信息；
将各个所述版本更新描述信息进行汇总， 得到应用更新描述信息； 将所述应用更新描述信息展示于所述移动应用的界面， 并发出与所述 应用更新描述信息相关的更新确认请求；
若接收到用户在所述界面发出的更新确认指令， 则基于所述调度优先 级的高低顺序， 依次控制各个所述框架层级执行热更新操作。
[权利要求 3] 如权利要求 2所述的移动应用的热更新方法， 其特征在于， 所述获取 每一所述框架层级的版本更新描述信息， 包括： 获取每一所述框架层级的热更新模式， 所述热更新模式包括强制更新 、 建议更新以及静默更新；
在各个所述框架层级中， 确定出所述热更新模式为强制更新或建议更 新的框架层级；
获取确定出的各个所述框架层级的版本更新描述信息。
[权利要求 4] 如权利要求 3所述的移动应用的热更新方法， 其特征在于， 所述框架 层级包括第一框架层级、 第二框架层级、 第三框架层级、 第四框架层 级以及第五框架层级， 在所述在各个所述框架层级中， 确定出所述热 更新模式为强制更新或建议更新的框架层级之前， 还包括： 若存在所述热更新模式为强制更新的第一框架层级， 则获取所述调度 优先级高于所述第一框架层级的第二框架层级， 并获取所述调度优先 级低于所述第一框架层级且所述热更新模式为建议更新的第三框架层 级；
将所述第二框架层级以及所述第三框架层级的所述热更新模式调整为 强制更新；
若存在所述热更新模式为建议更新的第四框架层级， 则获取所述调度 优先级高于所述第四框架层级的第五框架层级， 并将所述第五框架层 级的所述热更新模式调整为强制更新或建议更新。
[权利要求 5] 如权利要求 1至 4任一项所述的移动应用的热更新方法， 其特征在于， 还包括：
根据各个所述框架层级所分别对应的第一实吋更新进度， 计算所述移 动应用的第二实吋更新进度；
在所述移动终端的界面中， 生成基于所述第二实吋更新进度的进度条
[权利要求 6] —种移动应用的热更新装置， 其特征在于， 包括：
第一获取模块， 用于分别获取移动应用中出现版本更新提示的各个框 架层级；
第二获取模块， 用于若出现版本更新提示的所述框架层级为多个， 则 根据预设的框架层级与调度优先级的对应关系， 分别获取每一所述框 架层级对应的调度优先级；
热更新模块， 用于基于所述调度优先级的高低顺序， 依次控制各个所 述框架层级执行热更新操作。
[权利要求 7] 根据权利要求 6所述的移动应用的热更新装置， 其特征在于， 所述热 更新模块包括：
获取子模块， 用于获取每一所述框架层级的版本更新描述信息； 汇总子模块， 用于将各个所述版本更新描述信息进行汇总， 得到应用 更新描述信息； 展示子模块， 用于将所述应用更新描述信息展示于所述移动应用的界 面， 并发出与所述应用更新描述信息相关的更新确认请求； 控制子模块， 用于若接收到用户在所述界面发出的更新确认指令， 则 基于所述调度优先级的高低顺序， 依次控制各个所述框架层级执行热 更新操作。
[权利要求 8] 根据权利要求 7所述的移动应用的热更新装置， 其特征在于， 所述获 取子模块具体用于：
获取每一所述框架层级的热更新模式， 所述热更新模式包括强制更新 、 建议更新以及静默更新；
在各个所述框架层级中， 确定出所述热更新模式为强制更新或建议更 新的框架层级；
获取确定出的各个所述框架层级的版本更新描述信息。
[权利要求 9] 根据权利要求 8所述的移动应用的热更新装置， 其特征在于， 所述框 架层级包括第一框架层级、 第二框架层级、 第三框架层级、 第四框架 层级以及第五框架层级， 所述获取子模块还用于： 若存在所述热更新模式为强制更新的第一框架层级， 则获取所述调度 优先级高于所述第一框架层级的第二框架层级， 并获取所述调度优先 级低于所述第一框架层级且所述热更新模式为建议更新的第三框架层 级；
将所述第二框架层级以及所述第三框架层级的所述热更新模式调整为 强制更新；
若存在所述热更新模式为建议更新的第四框架层级， 则获取所述调度 优先级高于所述第四框架层级的第五框架层级， 并将所述第五框架层 级的所述热更新模式调整为强制更新或建议更新。
[权利要求 10] 根据权利要求 6至 9任一项所述的移动应用的热更新装置， 其特征在于 ， 还包括：
计算模块， 用于根据各个所述框架层级所分别对应的第一实吋更新进 度， 计算所述移动应用的第二实吋更新进度； 生成模块， 用于在所述移动终端的界面中， 生成基于所述第二实吋更 新进度的进度条。
[权利要求 11] 一种电子设备， 其特征在于， 包括存储器、 处理器， 所述存储器上存 储有可在所述处理器上运行的计算机可读指令， 所述处理器执行所述 计算机序吋实现如下步骤：
分别获取移动应用中出现版本更新提示的各个框架层级；
若出现版本更新提示的所述框架层级为多个， 则根据预设的框架层级 与调度优先级的对应关系， 分别获取每一所述框架层级对应的调度优 先级；
基于所述调度优先级的高低顺序， 依次控制各个所述框架层级执行热 更新操作。
[权利要求 12] 根据权利要求 11所述的电子设备， 其特征在于， 所述基于所述调度优 先级的高低顺序， 依次控制各个所述框架层级执行热更新操作， 包括 获取每一所述框架层级的版本更新描述信息；
将各个所述版本更新描述信息进行汇总， 得到应用更新描述信息； 将所述应用更新描述信息展示于所述移动应用的界面， 并发出与所述 应用更新描述信息相关的更新确认请求；
若接收到用户在所述界面发出的更新确认指令， 则基于所述调度优先 级的高低顺序， 依次控制各个所述框架层级执行热更新操作。
[权利要求 13] 根据权利要求 12所述的电子设备， 其特征在于， 所述获取每一所述框 架层级的版本更新描述信息， 包括：
获取每一所述框架层级的热更新模式， 所述热更新模式包括强制更新 、 建议更新以及静默更新；
在各个所述框架层级中， 确定出所述热更新模式为强制更新或建议更 新的框架层级；
获取确定出的各个所述框架层级的版本更新描述信息。
[权利要求 14] 根据权利要求 13所述的电子设备， 其特征在于， 所述框架层级包括第 一框架层级、 第二框架层级、 第三框架层级、 第四框架层级以及第五 框架层级， 所述处理器执行所述计算机序吋， 还实现如下步骤： 若存在所述热更新模式为强制更新的第一框架层级， 则获取所述调度 优先级高于所述第一框架层级的第二框架层级， 并获取所述调度优先 级低于所述第一框架层级且所述热更新模式为建议更新的第三框架层 级；
将所述第二框架层级以及所述第三框架层级的所述热更新模式调整为 强制更新；
若存在所述热更新模式为建议更新的第四框架层级， 则获取所述调度 优先级高于所述第四框架层级的第五框架层级， 并将所述第五框架层 级的所述热更新模式调整为强制更新或建议更新。
[权利要求 15] 根据权利要求 11至 14任一项所述的电子设备， 其特征在于， 所述处理 器执行所述计算机序吋， 还实现如下步骤：
根据各个所述框架层级所分别对应的第一实吋更新进度， 计算所述移 动应用的第二实吋更新进度；
在所述移动终端的界面中， 生成基于所述第二实吋更新进度的进度条
[权利要求 16] 一种计算机可读存储介质， 所述计算机可读存储介质存储有计算机可 读指令， 其特征在于， 所述计算机可读指令被至少一个处理器执行吋 实现如下步骤：
分别获取移动应用中出现版本更新提示的各个框架层级；
若出现版本更新提示的所述框架层级为多个， 则根据预设的框架层级 与调度优先级的对应关系， 分别获取每一所述框架层级对应的调度优 先级；
基于所述调度优先级的高低顺序， 依次控制各个所述框架层级执行热 更新操作。
[权利要求 17] 根据权利要求 16所述的计算机可读存储介质， 其特征在于， 所述基于 所述调度优先级的高低顺序， 依次控制各个所述框架层级执行热更新 操作， 包括：
获取每一所述框架层级的版本更新描述信息；
将各个所述版本更新描述信息进行汇总， 得到应用更新描述信息； 将所述应用更新描述信息展示于所述移动应用的界面， 并发出与所述 应用更新描述信息相关的更新确认请求；
若接收到用户在所述界面发出的更新确认指令， 则基于所述调度优先 级的高低顺序， 依次控制各个所述框架层级执行热更新操作。
[权利要求 18] 根据权利要求 17所述的计算机可读存储介质， 其特征在于， 所述获取 每一所述框架层级的版本更新描述信息， 包括： 获取每一所述框架层级的热更新模式， 所述热更新模式包括强制更新 、 建议更新以及静默更新；
在各个所述框架层级中， 确定出所述热更新模式为强制更新或建议更 新的框架层级；
获取确定出的各个所述框架层级的版本更新描述信息。
[权利要求 19] 根据权利要求 18所述的计算机可读存储介质， 其特征在于， 所述框架 层级包括第一框架层级、 第二框架层级、 第三框架层级、 第四框架层 级以及第五框架层级， 所述计算机可读指令被至少一个处理器执行吋 ， 还实现如下步骤：
若存在所述热更新模式为强制更新的第一框架层级， 则获取所述调度 优先级高于所述第一框架层级的第二框架层级， 并获取所述调度优先 级低于所述第一框架层级且所述热更新模式为建议更新的第三框架层 级；
将所述第二框架层级以及所述第三框架层级的所述热更新模式调整为 强制更新；
若存在所述热更新模式为建议更新的第四框架层级， 则获取所述调度 优先级高于所述第四框架层级的第五框架层级， 并将所述第五框架层 级的所述热更新模式调整为强制更新或建议更新。
[权利要求 20] 根据权利要求 16至 19任一项所述的计算机可读存储介质， 其特征在于 ， 所述计算机可读指令被至少一个处理器执行吋， 还实现如下步骤： 根据各个所述框架层级所分别对应的第一实吋更新进度， 计算所述移 动应用的第二实吋更新进度；
在所述移动终端的界面中， 生成基于所述第二实吋更新进度的进度条
PCT/CN2017/104531 2017-07-31 2017-09-29 移动应用的热更新方法、装置、电子设备及介质 WO2019024229A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710637113.6A CN107463400B (zh) 2017-07-31 2017-07-31 移动应用的热更新方法及终端设备
CN201710637113.6 2017-07-31

Publications (1)

Publication Number Publication Date
WO2019024229A1 true WO2019024229A1 (zh) 2019-02-07

Family

ID=60547937

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/104531 WO2019024229A1 (zh) 2017-07-31 2017-09-29 移动应用的热更新方法、装置、电子设备及介质

Country Status (2)

Country Link
CN (1) CN107463400B (zh)
WO (1) WO2019024229A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113535211A (zh) * 2021-09-15 2021-10-22 中航信移动科技有限公司 应用程序更新方法、装置、计算机设备及存储介质

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109032634B (zh) 2018-07-16 2021-11-26 北京百度网讯科技有限公司 用于更新应用的方法、装置、设备和计算机可读存储介质
JP7354658B2 (ja) * 2018-08-10 2023-10-03 株式会社デンソー 車両用電子制御システム、進捗表示の画面表示制御方法及び進捗表示の画面表示制御プログラム
CN109857403B (zh) * 2018-12-05 2022-04-19 腾讯科技（深圳）有限公司 一种页面更新、页面处理方法及装置
CN109656611A (zh) * 2018-12-24 2019-04-19 成都四方伟业软件股份有限公司 三维可视化应用热更新方法、装置和终端
CN109828772B (zh) * 2019-02-19 2022-03-11 百度在线网络技术（北京）有限公司 热更新方法、操作系统、终端设备和存储介质
CN110995793B (zh) * 2019-11-19 2022-07-05 北京奇艺世纪科技有限公司 一种信息流控件更新系统、方法和装置
CN111596941B (zh) * 2020-05-20 2023-09-29 中国工商银行股份有限公司 应用更新方法、装置、电子设备和介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101533356A (zh) * 2009-04-21 2009-09-16 华为技术有限公司 一种实现软件在线升级的方法、装置及系统
CN103365692A (zh) * 2013-07-15 2013-10-23 北京奇虎科技有限公司 软件升级提示信息的推送方法及装置
CN104598262A (zh) * 2014-11-25 2015-05-06 深圳市腾讯计算机系统有限公司 一种移动应用更新方法及装置
CN106528192A (zh) * 2015-09-15 2017-03-22 阿里巴巴集团控股有限公司 一种业务逻辑更新方法和装置

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102135895B (zh) * 2010-12-29 2013-08-28 华为软件技术有限公司 web系统升级方法及web系统
US9218177B2 (en) * 2011-03-25 2015-12-22 Microsoft Technology Licensing, Llc Techniques to optimize upgrade tasks
CN103914310A (zh) * 2012-12-29 2014-07-09 北京谊安医疗系统股份有限公司 麻醉机升级方法及装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101533356A (zh) * 2009-04-21 2009-09-16 华为技术有限公司 一种实现软件在线升级的方法、装置及系统
CN103365692A (zh) * 2013-07-15 2013-10-23 北京奇虎科技有限公司 软件升级提示信息的推送方法及装置
CN104598262A (zh) * 2014-11-25 2015-05-06 深圳市腾讯计算机系统有限公司 一种移动应用更新方法及装置
CN106528192A (zh) * 2015-09-15 2017-03-22 阿里巴巴集团控股有限公司 一种业务逻辑更新方法和装置

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113535211A (zh) * 2021-09-15 2021-10-22 中航信移动科技有限公司 应用程序更新方法、装置、计算机设备及存储介质
CN113535211B (zh) * 2021-09-15 2021-12-28 中航信移动科技有限公司 应用程序更新方法、装置、计算机设备及存储介质

Also Published As

Publication number Publication date
CN107463400B (zh) 2019-12-13
CN107463400A (zh) 2017-12-12

Similar Documents

Publication Publication Date Title
WO2019024229A1 (zh) 移动应用的热更新方法、装置、电子设备及介质
WO2019095563A1 (zh) 屏幕水印的显示方法、装置、计算机设备及存储介质
US20220391232A1 (en) Content sharing method, device, terminal and storage medium
RU2607275C2 (ru) Способ управления яркостью, а также устройство и программный продукт для реализации этого способа
US9484003B2 (en) Content bound graphic
WO2020151306A1 (zh) 一种容器自适应伸缩方法、服务器及存储介质
US20150220239A1 (en) Global keyboard shortcuts management for web applications
WO2013086988A1 (zh) 软件安装方法及装置
US20170118216A1 (en) Substitution of requests or results in access control systems
WO2013133916A1 (en) Tiers of data storage for web applications and browser extensions
US20210240914A1 (en) System and method for dynamic webpage rendering with no flicker or flash of original content
US20180081712A1 (en) Information processing apparatus, information processing method, and computer program product
US9483301B2 (en) Dynamic virtual machine function enabling
US9697360B2 (en) System and method for changing secure boot and electronic device provided with the system
US10885229B2 (en) Electronic device for code integrity checking and control method thereof
US11671379B1 (en) System and method for subscription management using dynamically composed management entities
WO2016144898A1 (en) Video content play
JP2010238083A (ja) 画面表示装置、画面表示方法、及び、プログラム
US20230221784A1 (en) System and method for power state enforced subscription management
WO2016185577A1 (ja) プログラム検証方法、検証プログラム、及び情報処理装置
CN109710622A (zh) 一种数据更新方法、装置和系统
JP2013037391A5 (zh)
KR102455639B1 (ko) 이동 단말 시스템 인터페이스 설정 방법, 장치, 매체 및 기기
CN112579927A (zh) 显示导航栏的方法和装置
US10565287B2 (en) Web content layout engine instance sharing across mobile devices

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: 17919881

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17919881

Country of ref document: EP

Kind code of ref document: A1

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 28.05.2020)

122 Ep: pct application non-entry in european phase

Ref document number: 17919881

Country of ref document: EP

Kind code of ref document: A1