移动应用的热更新方法及终端设备
技术领域
本发明属于移动应用技术领域,尤其涉及一种移动应用的热更新方法及终端设备。
背景技术
为了满足用户的动态化需求,及时修复移动应用中的漏洞,增强移动应用的运营能力,目前,移动应用均已提供了多种层面的热更新功能,例如Native层、React Native层以及H5层等不同框架层的热更新功能。
对于一个移动应用而言,如果多个层面同时出现热更新,则可能会出现不同层面热更新互相抢占以及相互冲突的问题。例如,若React Native层以及H5层的热更新时长不同,则在React Native层热更新执行完毕后,移动应用将会自动返回应用首页,由此会导致H5层的热更新出现中断,从而无法正常完成H5层的更新,使得移动应用崩溃以及无法正常运行。再例如,由于Native层为移动应用的最底层,因而若React Native层抢先于Native层执行热更新,则更新后的React Native层会因无法调用未更新的Native层的组件而同样出现移动应用崩溃的问题。
综上,现有技术中,存在因不同层面热更新的互相抢占而导致移动应用难以正常运行的问题。
发明内容
有鉴于此,本发明实施例提供了一种移动应用的热更新方法及终端设备,以解决现有技术中因不同层面热更新的互相抢占而导致移动应用难以正常运行的问题。
本发明实施例的第一方面提供了一种移动应用的热更新方法,包括:
分别获取移动应用中出现版本更新提示的各个框架层级;
若出现版本更新提示的所述框架层级为多个,则根据预设的框架层级与调度优先级的对应关系,分别获取每一所述框架层级对应的调度优先级;
基于所述调度优先级的高低顺序,依次控制各个所述框架层级执行热更新操作。
本发明实施例的第二方面提供了一种移动应用的热更新装置,包括:
第一获取单元,用于分别获取移动应用中出现版本更新提示的各个框架层级;
第二获取单元,用于若出现版本更新提示的所述框架层级为多个,则根据预设的框架层级与调度优先级的对应关系,分别获取每一所述框架层级对应的调度优先级;
热更新单元,用于基于所述调度优先级的高低顺序,依次控制各个所述框架层级执行热更新操作。
本发明实施例的第三方面提供了一种终端设备,包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序,所述处理器执行所述计算机程序时,实现如下步骤:
分别获取移动应用中出现版本更新提示的各个框架层级;
若出现版本更新提示的所述框架层级为多个,则根据预设的框架层级与调度优先级的对应关系,分别获取每一所述框架层级对应的调度优先级;
基于所述调度优先级的高低顺序,依次控制各个所述框架层级执行热更新操作。
本发明实施例的第四方面提供了一种计算机可读存储介质,所述计算机可读存储介质存储有计算机程序,所述计算机程序被处理器执行时实现如下步骤:
分别获取移动应用中出现版本更新提示的各个框架层级;
若出现版本更新提示的所述框架层级为多个,则根据预设的框架层级与调度优先级的对应关系,分别获取每一所述框架层级对应的调度优先级;
基于所述调度优先级的高低顺序,依次控制各个所述框架层级执行热更新操作。
本发明实施例中,在出现版本更新提示的框架层级的数量为多个时,通过获取每一框架层级所预设对应的调度优先级,能够基于调度优先级的高低顺序,依次控制各个框架层级执行热更新操作,实现了多个框架层级之间的有序调度,避免了多个框架层级之间出现热更新抢占或热更新冲突的现象,从而保证了移动应用在热更新过程中能够持续正常运行,由此提高了移动应用的稳定性。
附图说明
为了更清楚地说明本发明实施例中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。
图1是本发明实施例提供的移动应用的热更新方法的实现流程图;
图2是本发明实施例提供的移动应用的热更新方法S103的具体实现流程图;
图3是本发明实施例提供的包含有应用更新描述信息的提示窗口的示意图;
图4是本发明实施例提供的移动应用的热更新方法S301的具体实现流程图;
图5是本发明另一实施例提供的移动应用的热更新方法S301的具体实现流程图;
图6是本发明又一实施例提供的移动应用的热更新方法的实现流程图;
图7是本发明又一实施例提供的展示于移动终端界面的进度条的示意图;
图8是本发明实施例提供的移动应用的热更新装置的结构框图;
图9是本发明又一实施例提供的移动应用的热更新装置的结构框图;
图10是本发明实施例提供的终端设备的示意图。
具体实施方式
以下描述中,为了说明而不是为了限定,提出了诸如特定***结构、技术之类的具体细节,以便透彻理解本发明实施例。然而,本领域的技术人员应当清楚,在没有这些具体细节的其它实施例中也可以实现本发明。在其它情况中,省略对众所周知的***、装置、电路以及方法的详细说明,以免不必要的细节妨碍本发明的描述。
为了说明本发明所述的技术方案,下面通过具体实施例来进行说明。
图1示出了本发明实施例提供的移动应用的热更新方法的实现流程,该方法流程包括步骤S101至S103。各步骤的具体实现原理如下:
S101:分别获取移动应用中出现版本更新提示的各个框架层级。
本发明实施例中,框架层级包括但不限于Native层、React Native层、H5层、Xscript层、JS层以及WEEX层等前端框架层级。根据移动应用的不同,存在于移动应用中的框架层级也不同。例如,对于一个基于H5开发的移动应用来说,其框架层级可能包含Native层和H5层。而对于一个React Native应用,其框架层级则可能包括Native层、React Native层和H5层。因此,在获取移动应用中出现版本更新提示的各个框架层级之前,先检测移动应用中所存在的各个框架层级。在基于各个框架层级的更新检测事件被触发时,连接后台服务器,以请求服务器返回与各个框架层级相关的版本更新提示。其中,更新检测事件被触发的方式例如可以是:当检测到移动应用启动时,触发更新检测事件;或者,当检测到移动应用中用于检测更新的控件被选取时,触发更新检测事件。
若某一框架层级的当前版本低于后台服务器中已发布的该框架层级的最新版本,则在移动应用中,将检测到该框架层级出现版本更新提示。对移动应用中的每一框架层级进行识别,以确定每一框架层级是否出现版本更新提示,由此可获取当前时刻出现版本更新提示的各个框架层级。
S102:若出现版本更新提示的所述框架层级为多个,则根据预设的框架层级与调度优先级的对应关系,分别获取每一所述框架层级对应的调度优先级。
移动应用已预先设置有各框架层级与各调度优先级的对应关系。若检测出当前时刻出现版本更新提示的框架层级的数量大于一,则根据该预设的对应关系,获取出现版本更新提示的每一框架层级所分别对应的调度优先级。其中,调度优先级表示框架层级在执行热更新操作时的优先等级。
S103:基于所述调度优先级的高低顺序,依次控制各个所述框架层级执行热更新操作。
根据各个框架层级所对应的调度优先级的高低顺序,依次执行各个框架层级上的热更新。热更新的过程包括更新数据包的下载、解压以及更新数据的生效。当H5层的热更新操作完成时,刷新当前移动应用所展示的页面;当React Native层的热更新操作完成时,将当前移动应用所展示的页面跳转至应用首页;当Native层的热更新操作完成时,重新启动移动应用。并且,对于移动应用越底层的框架层级来说,其对应的调度优先级越高。
示例性地,若当前时刻出现版本更新提示的框架层级有三个,分别为Native层、React Native层以及H5层,则将处于移动应用最底层的Native层所对应的调度优先级预设为最高级,将处于中间层的React Native层所对应的调度优先级预设为次高级,将处于移动应用顶层的H5层所对应的调度优先级预设为最低级。根据Native层、React Native层以及H5层所分别对应的调度优先级,可得出调度优先级的高低顺序为Native层>ReactNative层>H5层。因此,令Native层执行热更新,且在Native层的热更新完成时,再控制ReactNative层执行热更新。同理,在React Native层的热更新完成时,再控制H5层执行热更新。基于越底层的框架层级,其热更新的调度优先级越高的原理,可保证在高层的框架层级出现更新失败时,也不会影响底层的框架层级中各组件的正常运行,保证了移动应用不至于在热更新过程中出现崩溃的问题。另外,还保证了移动应用上层的各个框架层级能够正常调用其所需依赖的底层组件以及底层程序,因而也提高了移动应用的可靠性。
本发明实施例中,在出现版本更新提示的框架层级的数量为多个时,通过获取每一框架层级所预设对应的调度优先级,能够基于调度优先级的高低顺序,依次控制各个框架层级执行热更新操作,实现了多个框架层级之间的有序调度,避免了多个框架层级之间出现热更新抢占或热更新冲突的现象,从而保证了移动应用在热更新过程中能够持续正常运行,由此提高了移动应用的稳定性。
作为本发明的一个实施例,图2示出了本发明实施例提供的移动应用的热更新方法S103的具体实现流程,详述如下:
S301:获取每一所述框架层级的版本更新描述信息。
本发明实施例中,版本更新描述信息由版本开发人员预先设置。在获取后台服务器返回的版本更新提示时,还将获取每一框架层级的版本更新描述信息。每一框架层级的版本更新描述信息用于描述本次热更新完成后,对该框架层级所作出的内容修改。
S302:将各个所述版本更新描述信息进行汇总,得到应用更新描述信息。
S303:将所述应用更新描述信息展示于所述移动应用的界面,并发出与所述应用更新描述信息相关的更新确认请求。
不同的框架层级,其在热更新完成后需要分别作出不同的内容修改。将各版本更新描述信息汇总显示于移动应用界面的同一提示窗口。提示窗口中所描述的各项内容能够从整体上反映移动应用热更新后所作出的各项修改,因而将汇总后的各个版本更新描述信息输出为应用更新描述信息。
如图3所示,在提示窗口中,在每一版本更新描述信息后,分别标注其所对应的框架层级,使得移动应用的用户能够在移动应用的同一提示窗口上直接浏览并区分出各个框架层级的版本更新描述信息。
本发明实施例中,提示窗口为强制更新提示窗口或建议更新提示窗口。
当提示窗口为强制更新提示窗口时,在提示窗口的预设位置,仅展示一确定选择控件,其用于请求用户在浏览应用更新描述信息后发出更新确认。
当提示窗口为建议更新提示窗口时,在提示窗口中展示有确定选择控件以及取消选择控件,其用于请求用户在浏览应用更新描述信息后发出更新确认,并且还可用于获取用户发出的更新取消指令。
S304:若接收到用户在所述界面发出的更新确认指令,则基于所述调度优先级的高低顺序,依次控制各个所述框架层级执行热更新操作。
当检测到上述确定选择控件被选取时,确定接收到用户发出的更新确认指令。根据各个需要执行热更新操作的框架层级的调度优选级,依次完成各个框架层级的热更新。
本发明实施例中,通过将多个框架层级的版本更新描述信息合并显示于移动应用的同一提示窗口,避免了用户需要分别查阅仅包含一条版本更新描述信息的提示窗口来确认更新,降低了用户的操作复杂度,提高了热更新的效率。通过在强制更新提示窗口中发出基于一确定选择控件的更新确认请求,使得用户在查阅完毕应用更新描述信息时,仅能发出更新确认指令,避免了用户发出更新取消指令,因而实现了框架层级的强制更新,保证了移动应用能够运行较为稳定的版本,提高了移动应用的稳定性。通过在建议更新提示窗口中展示确定选择控件以及取消选择控件,使得用户能够自由选择框架层级的更新时机,实现了用户对热更新操作的灵活控制。
作为本发明的一个实施例,如图4所示,上述S301具体包括:
S3011:获取每一所述框架层级的热更新模式,所述热更新模式包括强制更新、建议更新以及静默更新。
本发明实施例中,获取需要执行热更新操作的每一框架层级的热更新模式,每一框架层级在默认状态下的热更新模式由版本开发人员或者移动应用的开发人员预先设置。每一框架层级的热更新模式为强制更新、建议更新以及静默更新中的一种。
强制更新表示框架层级在热更新完成之前,用户只能发出更新确认指令,否则不允许用户继续使用移动应用;建议更新表示框架层级的更新数据包下载后,在提示窗口建议用户立即执行该框架层级的热更新,但用户也可选择取消更新,以在下次启动移动应用时再执行该框架层级的热更新;静默更新表示框架层级在移动应用后台静默下载更新数据包,并在下次启动移动应用时静默执行热更新,其热更新过程对于用户而言是不可见的。
S3012:在各个所述框架层级中,确定出所述热更新模式为强制更新或建议更新的框架层级。
S3013:获取确定出的各个所述框架层级的版本更新描述信息。
在不同热更新模式的多个框架层级中,筛选出热更新模式为强制更新或建议更新的各个框架层级。获取筛选出的各个框架层级的版本更新描述信息后,执行后续的步骤S302至S304。
本发明实施例中,通过确定不同框架层级的热更新模式,且仅获取热更新模式为强制更新或建议更新的框架层级的版本更新描述信息,使得在S304的移动应用界面中所显示的应用更新描述信息能够不包含静默更新的框架层级的版本更新描述信息,保证了静默更新的框架层级即使与其他框架层级依序执行热更新,用户也无法了解该静默更新框架层级的各项热更新信息,增强了移动应用框架层级的数据安全。
作为本发明的另一个实施例,如图5所示,在上述S3012之前,还包括:
S3014:若存在所述热更新模式为强制更新的第一框架层级,则获取所述调度优先级高于所述第一框架层级的第二框架层级,并获取所述调度优先级低于所述第一框架层级且所述热更新模式为建议更新的第三框架层级。
为了便于区分不同热更新模式的各个框架层级,将热更新模式为强制更新的框架层级称为第一框架层级;将调度优先级比该框架层级高的框架层级称为第二框架层级;将调度优先级低于第一框架层级,且热更新模式为建议更新的框架层级称为第三框架层级。
另外,将热更新模式为建议更新的框架层级称为第四框架层级。
在确定出各个时刻的第一框架层级、第二框架层级以及第三框架层级后,执行S3015。在确定出各个时刻的第四框架层级后,执行S3016。
S3015:将所述第二框架层级以及所述第三框架层级的所述热更新模式调整为强制更新。
S3016:若存在所述热更新模式为建议更新的第四框架层级,则获取所述调度优先级高于所述第四框架层级的第五框架层级,并将所述第五框架层级的所述热更新模式调整为强制更新或建议更新。
本发明实施例中,将调度优先级高于第四框架层级的框架层级的热更新模式调整为强制更新或建议更新。
若默认状态下各框架层级的热更新模式均为静默更新,则不对各框架层级的热更新模式进行调整。
例如,在移动应用中出现版本更新提示的框架层级为Native层、React Native层以及H5层,且调度优先级的高低顺序依次为Native层、React Native层以及H5层的情况下,若获取得到的React Native层的热更新模式为强制更新,Native层的热更新模式为静默更新,则将调度优先级高于React Native层的Native层的热更新模式调整为强制更新;若H5层的热更新模式为建议更新,则将调度优先级低于React Native层的H5层的热更新模式调整为强制更新。又例如,若获取得到的React Native层的热更新模式为建议更新,Native层的热更新模式为静默更新,则将调度优先级高于React Native层的Native层的热更新模式调整为强制更新或建议更新。这种情况下,假设Native层的热更新模式调整为强制更新,则可再次返回执行S3014,将调度优先级低于Native层的React Native层以及H5层的热更新模式调整为强制更新。因此,在本示例中,对应于上述S3014至S3016的热更新模式调整策略,表1示出了这种热更新模式调整策略下,最终可能出现的各个框架层级的热更新模式的组合方案:
表1
组合方案 |
Native层 |
React Native层 |
H5层 |
1 |
强制更新 |
强制更新 |
强制更新 |
2 |
强制更新 |
强制更新 |
静默更新 |
3 |
强制更新 |
静默更新 |
静默更新 |
4 |
建议更新 |
建议更新 |
建议更新 |
5 |
建议更新 |
建议更新 |
静默更新 |
6 |
建议更新 |
静默更新 |
静默更新 |
7 |
静默更新 |
静默更新 |
静默更新 |
本发明实施例中,由于调度优先级越高的框架层级,其为移动应用中越底层的框架,因而在调度优先级较高的第一框架层级需要强制更新时,通过将调度优先级低于第一框架层级的第二框架层级的热更新模式调整为强制更新,使得移动应用中较高层的框架层级在强制更新的情况下,底层的框架层级也必须强制更新,保证了较高层的框架层级在强制更新后依然能够依赖于底层的框架层级来正常运行。通过将调度优先级低于第一框架层级且热更新模式为建议更新的第三框架层级的热更新模式调整为强制更新,避免了在S302中需要同时使用强制更新提示窗口以及建议更新提示窗口来获取用户发出的更新确认指令,保证了版本更新描述信息能够在同一窗口中汇总显示。
本发明实施例中,通过获取热更新模式为建议更新的第四框架层级,并将调度优先级高于第四框架层级的第五框架层级的热更新模式调整为强制更新,能够在出现强制更新的第五框架层级的情况下,重新返回执行S3014,由此实现了热更新模式的定向调整,以达到上述有益效果。通过将调度优先级高于第四框架层级的第五框架层级的热更新模式调整为建议更新,使得移动应用中较高层的框架层级以及较底层的框架层级均能同时建议更新,在保证了较高层的框架层级能够依赖于底层的框架层级来正常更新运行的情况下,还实现了两个框架层级的版本更新描述信息能够在同一个建议更新提示窗口中汇总显示。
作为本发明的又一实施例,在上述各个实施例的基础之上,对各框架层级的实时更新进度显示方式作进一步地限定。如图6所示,在上述S103之后,还包括:
S104:根据各个所述框架层级所分别对应的第一实时更新进度,计算所述移动应用的第二实时更新进度。
S105:在所述移动终端的界面中,生成基于所述第二实时更新进度的进度条。
在各个框架层级执行热更新操作的过程中,检测各个框架层级对应的实时更新进度。实时更新进度的计算方式例如可以是各框架层级的更新数据包的解压安装进度等。
由于移动应用的整体更新需要依赖于各个框架层级的更新才能完成,故基于各个框架层级分别对应的实时更新进度,通过预设算法计算出移动应用在整体意义上的实时更新进度。并且,该预设算法可使得热更新过程中最后一个框架层级的实时更新进度达到100%时,移动应用的实时更新进度也为100%。
如图7所示,进度条中包含有用于表征热更新进度的子区域1,根据该子区域占据进度条总面积2的实时比例不同,可生成动态变化的进度条。
当移动应用的实时更新进度达到100%时,刷新当前时刻移动应用的页面或者重新启动移动应用,以使各框架层级的更新数据能够生效。
本发明实施例中,通过基于各个框架层级的第一实时更新进度来计算出移动应用的第二实时更新进度,能够在移动应用界面中合并生成便于用户直观观察的一个进度条,无需再分别查看不同框架层级的实时更新进度;由于用户通常仅关注移动应用何时能够更新完毕并恢复正常运行,因而通过在移动应用界面中合并显示唯一的一个进度条,提高了热更新进度的提示有效性。
应理解,上述实施例中各步骤的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本发明实施例的实施过程构成任何限定。
对应于上文实施例所述的移动应用的热更新方法,图8示出了本发明实施例提供的移动应用的热更新装置的结构框图,为了便于说明,仅示出了与本发明实施例相关的部分。
参照图8,该装置包括:
第一获取单元81,用于分别获取移动应用中出现版本更新提示的各个框架层级。
第二获取单元82,用于若出现版本更新提示的所述框架层级为多个,则根据预设的框架层级与调度优先级的对应关系,分别获取每一所述框架层级对应的调度优先级。
热更新单元83,用于基于所述调度优先级的高低顺序,依次控制各个所述框架层级执行热更新操作。
可选地,所述热更新单元83包括:
获取子单元,用于获取每一所述框架层级的版本更新描述信息。
汇总子单元,用于将各个所述版本更新描述信息进行汇总,得到应用更新描述信息。
展示子单元,用于将所述应用更新描述信息展示于所述移动应用的界面,并发出与所述应用更新描述信息相关的更新确认请求。
控制子单元,用于若接收到用户在所述界面发出的更新确认指令,则基于所述调度优先级的高低顺序,依次控制各个所述框架层级执行热更新操作。
可选地,所述获取子单元具体用于:
获取每一所述框架层级的热更新模式,所述热更新模式包括强制更新、建议更新以及静默更新;
在各个所述框架层级中,确定出所述热更新模式为强制更新或建议更新的框架层级;
获取确定出的各个所述框架层级的版本更新描述信息。
可选地,所述框架层级包括第一框架层级、第二框架层级、第三框架层级、第四框架层级以及第五框架层级,所述获取子单元还用于:
若存在所述热更新模式为强制更新的第一框架层级,则获取所述调度优先级高于所述第一框架层级的第二框架层级,并获取所述调度优先级低于所述第一框架层级且所述热更新模式为建议更新的第三框架层级;
将所述第二框架层级以及所述第三框架层级的所述热更新模式调整为强制更新;
若存在所述热更新模式为建议更新的第四框架层级,则获取所述调度优先级高于所述第四框架层级的第五框架层级,并将所述第五框架层级的所述热更新模式调整为强制更新或建议更新。
可选地,如图9所示,所述移动应用的热更新装置还包括:
计算单元84,用于根据各个所述框架层级所分别对应的第一实时更新进度,计算所述移动应用的第二实时更新进度。
生成单元85,用于在所述移动终端的界面中,生成基于所述第二实时更新进度的进度条。
本发明实施例中,在出现版本更新提示的框架层级的数量为多个时,通过获取每一框架层级所预设对应的调度优先级,能够基于调度优先级的高低顺序,依次控制各个框架层级执行热更新操作,实现了多个框架层级之间的有序调度,避免了多个框架层级之间出现热更新抢占或热更新冲突的现象,从而保证了移动应用在热更新过程中能够持续正常运行,由此提高了移动应用的稳定性。
图10是本发明一实施例提供的终端设备的示意图。如图10所示,该实施例的终端设备10包括:处理器1000、存储器1001以及存储在所述存储器1001中并可在所述处理器1000上运行的计算机程序1002,例如移动应用的热更新程序。所述处理器1000执行所述计算机程序1002时实现上述各个移动应用的热更新方法实施例中的步骤,例如图1所示的步骤101至103。或者,所述处理器1000执行所述计算机程序1002时实现上述各装置实施例中各模块/单元的功能,例如图8所示单元81至83的功能。
示例性的,所述计算机程序1002可以被分割成一个或多个模块/单元,所述一个或者多个模块/单元被存储在所述存储器1001中,并由所述处理器1000执行,以完成本发明。所述一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段,该指令段用于描述所述计算机程序1002在所述终端设备10中的执行过程。
所述终端设备10可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。所述终端设备可包括,但不仅限于,处理器1000、存储器1001。本领域技术人员可以理解,图10仅仅是终端设备10的示例,并不构成对终端设备10的限定,可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件,例如所述终端设备还可以包括输入输出设备、网络接入设备、总线等。
所称处理器1000可以是中央处理单元(Central Processing Unit,CPU),还可以是其他通用处理器、数字信号处理器(Digital Signal Processor,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)、现成可编程门阵列(Field-Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
所述存储器1001可以是所述终端设备10的内部存储单元,例如终端设备10的硬盘或内存。所述存储器1001也可以是所述终端设备10的外部存储设备,例如所述终端设备10上配备的插接式硬盘,智能存储卡(Smart Media Card,SMC),安全数字(Secure Digital,SD)卡,闪存卡(Flash Card)等。进一步地,所述存储器1001还可以既包括所述终端设备10的内部存储单元也包括外部存储设备。所述存储器1001用于存储所述计算机程序以及所述终端设备所需的其他程序和数据。所述存储器1001还可以用于暂时地存储已经输出或者将要输出的数据。
所属领域的技术人员可以清楚地了解到,为了描述的方便和简洁,仅以上述各功能单元、模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能单元、模块完成,即将所述装置的内部结构划分成不同的功能单元或模块,以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中,上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。另外,各功能单元、模块的具体名称也只是为了便于相互区分,并不用于限制本申请的保护范围。上述***中单元、模块的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述或记载的部分,可以参见其它实施例的相关描述。
本领域普通技术人员可以意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本发明的范围。
在本发明所提供的实施例中,应该理解到,所揭露的装置/终端设备和方法,可以通过其它的方式实现。例如,以上所描述的装置/终端设备实施例仅仅是示意性的,例如,所述模块或单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个***,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口,装置或单元的间接耦合或通讯连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本发明各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
所述集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明实现上述实施例方法中的全部或部分流程,也可以通过计算机程序来指令相关的硬件来完成,所述的计算机程序可存储于一计算机可读存储介质中,该计算机程序在被处理器执行时,可实现上述各个方法实施例的步骤。。其中,所述计算机程序包括计算机程序代码,所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括:能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是,所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减,例如在某些司法管辖区,根据立法和专利实践,计算机可读介质不包括电载波信号和电信信号。
以上所述实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围,均应包含在本发明的保护范围之内。