具体实施方式
在相关技术中,APP可以通过原生native页面,向用户提供一些快速稳定的业务服务,比如各种充值业务,然而APP在部署一些新业务时,例如一些特殊时段的运营业务,由于这类业务并不追求过高的稳定性,只是在特殊时段进行运营,如果仍然通过原生native页面向用户提供服务,APP可能会要求用户对版本进行升级后,才能正常的提供该服务,而且这类新业务通常具有一定的临时性,当该运营业务运营结束后,APP将不得不再次要求用户对版本进行升级,恢复为最初的版本。可见,通过这种方式,会频繁的要求用户对版本进行升级,用户体验很差。
在相关技术中,可以通过引入hybrid技术,即APP中的页面采用原生native页面和html5页面混编的方式来解决上述问题。当APP需要部署新业务时,APP可以将服务器上部署完成的该新业务的html5页面下载到本地,对原有的html5页面进行动态替换后,然后加载该新业务的html5页面来运行该新业务。然而,在这种实现方案中,由于APP中的原生native页面通常无法被替换,因此APP在部署新业务时,通常只能够动态替换APP中的html5页面,而html5页面的稳定性比原生native页面差,随着APP中html5页面的不断增多,会影响APP运行的稳定性,造成很不好的用户体验。
因此,为了提升用户体验,尽可能的减少APP中html5页面的数量,APP在部署新业务时,可以通过动态修改APP中写死的跳转逻辑,将原生native页面跳转到新业务的html5页面,以实现使用新业务来替代原生native页面上的业务。
例如,假设该新业务为淘宝客户端APP的双11购物节的运营业务,在该业务运营期间,该APP的主页需要加载具有图片、声音、文本混排的富文本页面,而通过APP原生native页面通常无法实现,因此该APP可以从服务器上下载需要显示的富文本页面,然后通过编辑lua脚本,为该APP打补丁,将该APP中写死的跳转逻辑,修改为跳转到该富文本页面。比如,假设该APP原有的跳转逻辑为从页面A跳转到页面B,该富文本页面为页面C,那么可以通过编辑lua脚本将该写死的跳转逻辑从页面A跳转到页面B,修改为从页面A跳转到页面C。
然而,通过动态修改APP写死的跳转逻辑来完成页面跳转,由于需要动态修改该APP的代码,因此可能面临一定的安全风险。例如,当APP进行了动态修改了代码后,可能会因为安全风险被拒绝。另外,通过动态修改APP写死的跳转逻辑来完成页面跳转,需要该APP不断的加载补丁,因此灵活性也较差。
有鉴于此,本申请提出一种页面跳转方法,通过获取待跳转的页面标识,并根据获取到的所述页面标识在页面路由表中查找对应的跳转路由,其中跳转路由包括所述页面标识与跳转页面的对应关系;然后基于查找到的所述跳转路由跳转到对应页面,实现了可以通过在页面路由表中查找到的跳转路由,动态灵活的进行页面跳转,从而可以快速灵活的部署新业务,而不需要进行APP的版本升级。而且,由于在本申请中,在进行页面跳转时,不需要修改APP中的跳转逻辑,因此该APP不会由于存在安全性风险而被拒绝。
下面通过具体实施例并结合具体的应用场景对本申请进行描述。
请参考图1,图1是本申请一实施例提供的一种页面跳转方法,应用于客户端,所述方法执行以下步骤:
步骤101,获取待跳转的页面标识;
步骤102,根据获取到的所述页面标识在页面路由表中查找对应的跳转路由;所述跳转路由包括所述页面标识与跳转页面的对应关系;
步骤103,基于查找到的所述跳转路由跳转到对应页面。
在本实施例中,上述客户端可以是面向用户提供服务的客户端软件,例如,该客户端可以是淘宝的客户端APP。上述待跳转的页面标识,可以携带在该客户端预先设定的跳转逻辑中,而该跳转逻辑可以预先写死在该客户端的程序中,而不发生变化。
例如,假设该客户端的程序中写死的一条跳转逻辑为从页面A跳转到页面B,页面B的页面标识为viewid1,此时viewid1即为该跳转逻辑中携带的待跳转的页面标识。
其中,跳转逻辑中的待跳转的页面标识,在不同的业务场景中,可以分别对应不同的跳转页面。
在本实施例中,客户端可以在本地预先创建一张页面路由表,该页面路由表可以用于存储由服务器下发的跳转路由。该页面路由表中的跳转路由可以包括页面标识和跳转页面之间的对应关系。
其中,对于不同的业务,服务器可以通过向客户端下发不同的跳转路由,为同一个页面标识来分别对应不同的跳转页面。
例如,以该客户端为淘宝客户端为例,该淘宝客户端在执行日常业务时,本地的页面路由表中可以存储一条如下所示出的与日常业务对应的跳转路由:
待跳转的页面标识 |
跳转页面 |
viewid1 |
PageA |
上述跳转路由表示在执行日常业务时,客户端在执行与viewid1对应的跳转逻辑时,将跳转到页面PageA。
当该淘宝客户端在执行双11购物节的运营业务时,由于此时需要在该客户端的主页中加载具有图片、声音、文本混排的富文本页面Page B,此时服务器可以向该客户端下发一条如下所示出的与该运营业务对应的跳转路由:
待跳转的页面标识 |
跳转页面 |
viewid1 |
Page B |
上述跳转路由表示在执行该运营业务时,客户端在执行与viewid1对应的跳转逻辑时,将跳转到富文本页面Page B。
在本实施例中,客户端还可以在本地预先创建一个页面数据库,该页面数据库可以用于保存服务器离线下发的最新的跳转页面的页面数据。
其中,客户端可以通过与服务器交互来对本地的页面路由表以及页面数据库进行更新。
请参见图2,图2为本实施例中示出的一种客户端与服务器进行交互的示意图。
在本例中,该服务器可以包括路由表服务器和业务服务器。
其中,该路由器表服务器负责与客户端交互向客户端下发最新的跳转路由。该业务服务器负责与客户端交互向客户端下发最新的跳转页面的页面数据。当然,在实现时,服务器也可以不划分为路由表服务器和业务服务器,即路由表服务器和业务服务器的功能也可以集成在同一台物理服务器上。
如图2所示,客户端在启动后,可以定时向路由表服务器发送第一查询消息,其中,该定时的时长间隔在本实施例中不进行特别限定;例如,可以定时每15秒向该路由表服务器发送一次第一查询消息;该第一查询消息可以用于向该路由表服务器查询是否有最新的跳转路由,并触发该路由表服务器将最新的跳转路由下发给客户端。
其中,在业务服务器一侧,可以预先部署新业务。当新业务在服务器一侧部署完成后,业务服务器可以主动将与新业务相关的跳转路由同步至路由表服务器。路由表服务器在接收到业务服务器同步的与新业务相关的跳转路由后,可以将接收到的跳转路由在本地保存。当然,在实现时,也可以直接在路由表服务器一侧部署与新业务相关的跳转路由。
当该路由表服务器收到客户端发送的该第一查询消息后,可以判断本地是否保存了与新业务相关的跳转路由,如果本地保存了与新业务相关的跳转路由时,此时该路由表服务器可以立即将与该新业务对应的最新的跳转路由下发给客户端。
当然,除了以上描述的通过客户端发送第一查询求来触发路由表服务器将最新的跳转路由下发至客户端以外,在实现时,路由表服务器也可以将业务服务器同步至本地的与新业务相关的跳转路由主动下发至客户端。
例如,当路由表服务器接收到业务服务器同步的与新业务相关的跳转路由后,可以触发路由表服务器将该与新业务相关的跳转路由,主动将该跳转路由下发至客户端。即每当业务服务器上部署了新业务后,都会触发业路由表服务器主动将与新业务相关的跳转路由下发至客户端。
另外,为了提高安全性,该路由表服务器在向客户端下发最新的跳转路由时,该路由表服务器还可以对该最新的跳转路由进行加密传输,或者提前对后台保存的与该新业务相关的最新的跳转路由进行加密,客户端在收到该路由表服务器下发的该最新的跳转路由后,可以对接收到的该跳转路由进行解密后存储到页面路由表中,以对页面路由表进行更新。
请继续参见图2,如果当前在业务服务器一侧并未部署新业务,该路由表服务器本地并未保存于新业务相关的跳转路由,此时客户端无法查询到最新的跳转路由,该路由表服务器可以向客户端返回一个空值,以表示当前未部署新业务,此时客户端可以在在页面路由表中加载默认的跳转路由或者上一次接收到的由路由表服务器下发的跳转路由。
可见,通过这种方式,可以保持页面路由表中存储的跳转路由均为最新的跳转路由,从而可以保证在部署了新业务后,客户端可以第一时间将路由表服务器下发的与该新业务对应的最新的跳转路由存储到页面路由表中,以对页面路由表进行更新。
请继续参见图2,客户端在启动后,还可以定时向业务服务器发送第二查询消息,其中,该第二查询消息可以用于向业务服务器查询是否有最新的跳转页面的页面数据,并触发该业务服务器将最新的跳转页面的页面数据下发给客户端。
在该业务服务器一侧,可以预先部署与新业务相关的跳转页面的页面数据。当该业务服务器收到该第二查询消息后,可以判断当前是否部署了新业务,如果已经部署了新业务,此时该业务服务器可以立即将与该新业务对应的最新的跳转页面的页面数据离线下发给客户端;例如,该业务服务器可以将最新的跳转页面的页面数据以离线数据包的形式下发给客户端。
当然,除了以上描述的通过客户端发送第二查询求来触发业务服务器将最新的跳转页面的页面数据下发至客户端以外,在实现时,业务服务器也可以将与新业务相关的最新的跳转页面的页面数据主动下发至客户端。
例如,当在业务服务器上部署了新业务后,可以触发业务服务器将该与新业务相关的最新的跳转页面的页面数据,主动下发至客户端。即每当业务服务器上部署了新业务后,都会触发业业务服务器主动将与新业务相关的最新的跳转页面的页面数据下发至客户端。
另外,为了提高安全性,该业务服务器在向客户端离线下发最新的跳转页面的页面数据时仍然还可以对该最新的跳转页面的页面数据进行加密传输,或者提前对后台保存的与该新业务相关的最新的跳转页面的页面数据进行加密,客户端在收到该业务服务器下发的该最新的跳转页面的页面数据后,可以对接收到的该最新的跳转页面的页面数据进行解密后存储到页面数据库中,以对页面数据库进行更新。
请继续参见图2,如果该业务服务器并未部署新业务,此时客户端无法查询到最新的跳转页面的页面数据,该业务服务器可以向客户端返回一个空值,以表示当前未部署新业务,此时客户端可以在页面数据库中加载默认的跳转页面的页面数据或者上一次接收到的由该业务服务器下发的跳转页面的页面数据。
可见,通过这种方式,可以保持页面数据中存储的页面数据均为与最新的跳转页面的页面数据,从而可以保证该业务服务器在部署了与新业务相关的跳转页面的跳转数据后,客户端可以第一时间将业务服务器下发的与该新业务对应的最新的跳转页面的页面数据存储到页面数据库中,以对页面数据库进行更新。
以上结合图2描述了客户端与服务器进行交互对在本地创建的创建页面路由表和页面数据库进行更新的过程。
以下对客户端基于本地的页面路由表和页面数据库完成新业务的页面跳转的过程进行描述。
在本实施例中,客户端在执行页面跳转时,仍然可以通过执行设定的跳转逻辑来完成。
其中,客户端在执行设定的跳转逻辑时,可以通过监测用户的前台操作来触发。
在示出的一种应用场景中,在客户端的操作界面上可以预先提供对应的跳转控件,比如该跳转控件可以包括跳转按钮、跳转链接等,用户在客户端的操作界面上执行对应的业务操作时,客户端可以实时监听用户针对客户端的操作界面中的跳转控件的触发事件,比如以该客户端加载在触屏终端上为例,该触发事件可以是针对跳转控件的点击事件,当监听到用户针对客户端的操作界面中的跳转控件的触发事件时,则可以立即触发客户端调用并执行已设定的跳转逻辑,来完成对应的页面跳转。
另外,需要指出的是,本实施例中描述的设定的跳转逻辑与现有实现中的跳转逻辑相比,在实现细节上略有差异。
在现有实现中,客户端设定的跳转逻辑中,通常只包括预先设定的待跳转的页面,客户端在执行该跳转逻辑后,可以根据该跳转逻辑中设定的待跳转的页面,直接跳转到对应的跳转页面以完成跳转。
而在本实施例中,客户端设定的跳转逻辑中,除了可以包括预先设定的待跳转的页面的页面标识以外,还可以包括基于待跳转的页面标识在页面路由表中查找对应的跳转路由的查找逻辑。
当客户端在执行设定的跳转逻辑时,首先可以从该跳转逻辑中读取待跳转的页面标识,然后再根据该待跳转的页面标识在页面路由表中查找对应的跳转路由,当查找到对应的跳转路由后,再根据查找到的该跳转路由来完成页面跳转。
在本实施例中,当客户端根据该待跳转的页面标识在页面路由表中查找对应的跳转路由后,如果当前业务服务器已经部署了新业务,那么该页面路由表中存储的跳转路由均为最新的跳转路由,此时客户端查找到的与该页面标识对应的跳转路由已为与该新业务对应的最新的跳转路由。
当然,如果此时服务器并未部署新业务,那么该页面路由表中存储的跳转路由则仍为预先存储的默认跳转路由,或者上一次接收到的由路由表服务器下发的跳转路由。
在这种情况下,当客户端在页面路由表中查找到了最新的跳转路由后,客户端可以读取该最新的跳转路由,并基于该最新的跳转路由中保存的待跳转的页面标识与跳转页面之间的对应关系,来获取与上述待跳转的页面标识对应的跳转页面。此时获取到的该跳转页面为与新业务相关的跳转页面。
当获取到与上述待跳转的页面标识对应的跳转页面后,客户端可以跳转到该跳转页面中,并将从本地的页面数据库中读取到的与该跳转页面对应的页面数据加载在该跳转页面中,以完成页面跳转。
其中,与上述待跳转的页面标识对应的跳转页面可以是APP的原生native页面,也可以是html5页面,在本实施例不进行特别限定。即在本实施例中,通过服务器下发的跳转路由可以实现原生native页面与html5之间的页面跳转,而没有任何限制。
在本实施例中,客户端在从本地的页面数据库中读取与该跳转页面对应的页面数据时,可以通过将该最新的跳转页面的页面标识作为索引在该页面数据库查找对应的页面数据,来判断本地的页面数据库中是否存储了与该最新的跳转页面对应的页面数据。
如果查找到了对应的页面数据,客户端可以确定本地的页面数据库中离线存储了与该最新的跳转页面对应的页面数据,此时客户端可以从本地的页面数据库中直接读取该页面数据。
当然,如果客户端判断出该页面数据库中并未离线存储与该最新的跳转页面对应的页面数据时,此时客户端可以向服务器请求与该最新的跳转页面的页面数据。例如,客户端可以向服务器发送一个携带该跳转页面的url地址或者其它标识的页面数据获取请求,向服务器请求该跳转页面的页面数据。
当客户端从本地的页面数据库中直接读取到与该最新的跳转页面对应的页面数据时,此时该页面数据为服务器部署的新业务的页面数据,客户端可以将读取到的该新业务的页面数据加载到最新的跳转页面中,以完成页面跳转。当客户端基于读取到的该新业务的页面数据完成页面跳转后,此时该客户端开始执行服务器部署的该新业务。
其中,值得说明的是,客户端在将该新业务的页面数据加载到最新的跳转页面中时,可以通过协议来传递,比如可以通过约定协议接口,然后通过约定的协议接口完成页面数据的传递。
在本实施例中,如果服务器还需要继续部署其它的新业务,此时仍然可以通过以上方式重新向客户端下发新的跳转路由,来触发客户端在执行设定的跳转逻辑后跳转到该新业务的跳转页面,来执行该新业务。
当然,如果服务器部署的新业务执行完成,而服务器此时并未部署其它新的业务时,服务器还可以向客户端发送一个触发客户端恢复到日常业务的触发消息,客户端在收到该触发消息后,可以使用默认的跳转路由以及默认的跳转页面的页面数据对本地的页面路由表和页面数据库分别进行恢复。当恢复成功时,此时客户端再次执行相同的跳转逻辑后,将会跳转到默认页面,执行日常业务。
可见,通过这种方式,当服务器部署了新业务时,通过与服务器交互,客户端可以第一时间将该新业务的跳转路由存储到本地的页面路由表,将该新业务的跳转页面的页面数据存储到本地的页面数据库中。
从而,客户端在执行对应的跳转逻辑后,可以从该跳转逻辑中读取待跳转的页面标识,并在本地的页面路由表中查找与该页面表示跳转逻辑对应的最新的跳转路由。当查找到对应的最新的跳转路由后,客户端可以从该最新的跳转路由中读取对应的跳转页面,然后从本地的页面数据库中读取该跳转页面的页面数据,并基于读取到的页面数据跳转到对应的页面。
由于在整个过程中,跳转逻辑中的待跳转的页面标识并不会发生更改,服务器可以通过动态下发新的跳转路由,为该待跳转的页面标识动态对应不同的跳转页面,因此服务器可以更加灵活的部署业务,而且不需要对APP进行版本升级。
另外,由于在本申请中,客户端在进行页面跳转时,是通过服务器动态的下发跳转路由来实现的,不再需要修改APP中的跳转逻辑,因此不再需要该APP不断的加载补丁,灵活性更好。而且,不再修改APP中的跳转逻辑,该APP也不会面临由于存在安全性风险而被拒绝的风险。
以下通过一个具体的应用实例对以上实施例中的技术方案进行说明。
假设上述客户端为淘宝客户端,该淘宝客户端在执行日常业务时,本地的页面路由表中可以存储一条如表1中所示出的与日常业务对应的跳转路由:
待跳转的页面标识 |
跳转页面 |
viewid1 |
PageA |
表1
上述跳转路由表示在执行日常业务时,客户端在执行与viewid1对应的跳转逻辑时,将跳转到页面PageA。
同时,在本地的页面数据库中也可以对应存储PageA的页面数据。
假设服务器部署了新业务,该新业务为双11购物节的运营业务,客户端可以定时向服务器发送上述第一查询消息和第二查询消息,以触发服务器将该新业务的跳转路由以及与该跳转路由对应的跳转页面的页面数据下发给客户端。
由于客户端在执行该新业务时,需要在该客户端的主页中加载具有图片、声音、文本混排的富文本页面Page B,此时服务器可以向该客户端下发一条如表2所示出的与该运营业务对应的跳转路由:
待跳转的页面标识 |
跳转页面 |
viewid1 |
Page B |
表2
上述跳转路由表示在执行该运营业务时,客户端在执行与viewid1对应的跳转逻辑时,将跳转到富文本页面Page B。此时客户端中的跳转逻辑不发生变化,而该跳转逻辑中设定的待跳转的页面标识所对应的跳转页面发生了变化。
当客户端收到服务器下发的如上述表2示出的该新业务的跳转路由后,可以使用该新业务的跳转路由对本地的页面路由表中存储的如表1中所示出的与日常业务对应的跳转路由进行更新。
同时,服务器也可以将Page B的页面数据下发给客户端。客户端在收到该Page B的页面数据后,可以对本地的页面数据库中存储的PageA的页面数据进行更新。
当本地的页面路由表和页面数据库均更新完成后,客户端再次执行相同的跳转逻辑,在从该跳转逻辑中读出viewid1后,可以在本地的页面路由表中查找到与viewid1对应的跳转页面Page B。当查找到Page B后,客户端可以跳转到Page B,并在页面数据库中读取Page B的页面数据,将读取到的Page B的页面数据加载到Page B中,然后跳转到Page B。可见,在整个过程中,新业务的跳转路由的下发过程,对于用户来说是完全无感知的,有助于提升用户体验。
当该新业务执行完成后,如果服务器重新部署了其它新业务,此时服务器可以通过相同的方式重新向客户端下发其它新业务的跳转路由。当然,如果该新业务执行完成后,服务器并未部署其它新业务,服务器也可以向客户端发送一个触发客户端恢复为日常业务的触发消息,客户端在收到该触发消息后,可以将对本地的页面路由表中保存的如表2中所示出的跳转路由恢复为如表1中所示出的跳转路由。同时,客户端在接收到该触发消息后,还可将本地的页面数据库中存储的Page B的页面数据恢复为Page A的页面数据。当恢复完成后,客户端再次执行相同的跳转逻辑,将会跳转到页面Page A,执行日常业务。
在以上实施例中,通过获取待跳转的页面标识,并根据获取到的所述页面标识在页面路由表中查找对应的跳转路由,然后基于查找到的所述跳转路由跳转到对应页面,实现了可以通过在页面路由表中查找到的跳转路由,动态灵活的进行页面跳转,从而可以快速灵活的部署新业务,而不需要进行APP的版本升级。而且,由于在本申请中,在进行页面跳转时,不需要修改APP中的跳转逻辑,因此该APP不会面临由于存在安全性风险而被拒绝的风险
与上述方法实施例相对应,本申请还提供了装置的实施例。
请参见图3,本申请提出一种页面跳转装置30,应用于客户端;其中,请参见图4,作为承载所述页面跳转装置30的客户端所涉及的硬件架构中,通常包括CPU、内存、非易失性存储器、网络接口以及内部总线等;以软件实现为例,所述页面跳转装置30通常可以理解为加载在内存中的计算机程序,通过CPU运行之后形成的软硬件相结合的逻辑装置,所述装置30包括:
获取模块301,用于获取待跳转的页面标识;查找模块302,用于根据获取到的所述页面标识在页面路由表中查找对应的跳转路由;所述跳转路由包括所述页面标识与跳转页面的对应关系;跳转模块303,用于基于查找到的所述跳转路由跳转到所述跳转页面。在本实施例中,上述待跳转的页面标识,可以携带在该客户端预先设定的跳转逻辑中,而该跳转逻辑可以预先写死在该客户端的程序中,而不发生变化。
其中,跳转逻辑中的待跳转的页面标识,在不同的业务场景中,可以分别对应不同的跳转页面。
在本实施例中,所述装置30还包括:
发送模块304,用于定时向服务器发送第一查询请求;所述第一查询请求用于触发所述服务器下发最新的跳转路由;
接收模块305,用于接收所述服务器下发的所述最新的跳转路由;
更新模块306,用于根据接收到的所述最新的跳转路由对所述页面路由表进行更新。
在本实施例中,客户端可以在本地预先创建一张页面路由表,该页面路由表可以用于存储由服务器下发的跳转路由。该页面路由表中的跳转路由可以包括页面标识和跳转页面之间的对应关系。其中,对于不同的业务,服务器可以通过向客户端下发不同的跳转路由,为同一个页面标识来分别对应不同的跳转页面。
其中,客户端可以通过向服务器发送第一查询请求与服务器进行交互,来对本地的页面路由表进行更新。
可选的,所述发送模块304进一步用于:
定时向服务器发送第二查询请求;所述第二查询请求用于触发所述服务器离线下发最新的跳转页面的页面数据;
所述接收模块305进一步用于:
接收所述服务器离线下发的所述最新的跳转页面的页面数据;
所述更新模块306进一步用于:
根据接收到的所述最新的跳转页面的页面数据对所述页面数据库进行更新。
在本实施例中,客户端还可以在本地预先创建一个页面数据库,该页面数据库可以用于保存服务器离线下发的最新的跳转页面的页面数据。
其中,客户端可以通过向服务器发送第二查询请求与服务器进行交互,来对本地的页面路由表进行更新。
在本实施例中,所述跳转模块303具体用于:
基于查找到的所述跳转路由获取与所述页面标识对应的跳转页面;
读取所述跳转页面的页面数据;
跳转到所述跳转页面,并将读取到的所述页面数据加载到所述跳转页面中完成跳转。
在本实施例中,客户端在执行页面跳转时,仍然可以通过执行设定的跳转逻辑来完成。在示出的一种应用场景中,在客户端的操作界面上可以预先提供对应的跳转控件,比如该跳转控件可以包括跳转按钮、跳转链接等,用户在客户端的操作界面上执行对应的业务操作时,客户端可以实时监听用户针对客户端的操作界面中的跳转控件的触发事件,比如以该客户端加载在触屏终端上为例,该触发事件可以是针对跳转控件的点击事件,当监听到用户针对客户端的操作界面中的跳转控件的触发事件时,则可以立即触发客户端调用并执行已设定的跳转逻辑,来完成对应的页面跳转。
当客户端根据该待跳转的页面标识在页面路由表中查找对应的跳转路由后,如果当前业务服务器已经部署了新业务,那么该页面路由表中存储的跳转路由均为最新的跳转路由,此时客户端查找到的与该页面标识对应的跳转路由已为与该新业务对应的最新的跳转路由。
在这种情况下,当客户端在页面路由表中查找到了最新的跳转路由后,客户端可以读取该最新的跳转路由,并基于该最新的跳转路由中保存的待跳转的页面标识与跳转页面之间的对应关系,来获取与上述待跳转的页面标识对应的跳转页面,然后跳转到该跳转页面中,并将从本地的页面数据库中读取到的与该跳转页面对应的页面数据加载在该跳转页面中,以完成页面跳转
在本实施例中,所述跳转模块303进一步用于:
判断本地的页面数据库中是否离线存储了所述跳转页面的页面数据;
当所述页面数据库中离线存储了所述跳转页面的页面数据时,从所述页面数据库中读取该跳转页面的页面数据;
当所述页面数据库中未存储所述跳转页面的页面数据时,向所述服务器请求该跳转页面的页面数据。
在本实施例中,客户端在从本地的页面数据库中读取与该跳转页面对应的页面数据时,可以通过将该最新的跳转页面的页面标识作为索引在该页面数据库查找对应的页面数据,来判断本地的页面数据库中是否存储了与该最新的跳转页面对应的页面数据。
如果查找到了对应的页面数据,客户端可以确定本地的页面数据库中离线存储了与该最新的跳转页面对应的页面数据,此时客户端可以从本地的页面数据库中直接读取该页面数据。
当然,如果客户端判断出该页面数据库中并未离线存储与该最新的跳转页面对应的页面数据时,此时客户端可以向服务器请求与该最新的跳转页面的页面数据。例如,客户端可以向服务器发送一个携带该跳转页面的url地址或者其它标识的页面数据获取请求,向服务器请求该跳转页面的页面数据。
当客户端从本地的页面数据库中直接读取到与该最新的跳转页面对应的页面数据时,此时该页面数据为服务器部署的新业务的页面数据,客户端可以将读取到的该新业务的页面数据加载到最新的跳转页面中,以完成页面跳转。
本领域技术人员在考虑说明书及实践这里公开的发明后,将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的,本申请的真正范围和精神由下面的权利要求指出。
应当理解的是,本申请并不局限于上面已经描述并在附图中示出的精确结构,并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。
以上所述仅为本申请的较佳实施例而已,并不用以限制本申请,凡在本申请的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本申请保护的范围之内。