本申請涉及互聯(lián)網(wǎng)技術(shù)領(lǐng)域，尤其涉及一種頁面顯示方法及裝置。

背景技術(shù)：

隨著互聯(lián)網(wǎng)技術(shù)的不斷發(fā)展，使用互聯(lián)網(wǎng)的用戶越來越多。特別是隨著無線通信提供的便利性，使得無線客戶端逐漸成為主流。

現(xiàn)有的應(yīng)用程序(application，app)一般是采用html技術(shù)進行開發(fā)的。在使用html技術(shù)開發(fā)時，還無法完全做到頁面之間的動態(tài)性。

技術(shù)實現(xiàn)要素：

本申請?zhí)峁┑囊环N頁面顯示方法及裝置，以解決現(xiàn)有技術(shù)中無法做到頁面之間的動態(tài)性的問題。

根據(jù)本申請實施例提供的一種頁面顯示方法，所述方法包括：

在應(yīng)用程序顯示當(dāng)前頁面后，所述應(yīng)用程序中的預(yù)設(shè)容器向當(dāng)前頁面中添加jsbridge的代碼；

在顯示目標(biāo)頁面的條件被觸發(fā)的情況下，根據(jù)所述jsbridge的代碼提供的jsbridge.call，調(diào)用所述預(yù)設(shè)容器提供的預(yù)設(shè)接口；

根據(jù)所述預(yù)設(shè)接口打開新的頁面，加載并渲染所述目標(biāo)頁面的內(nèi)容。

可選的，所述預(yù)設(shè)容器提供有jsapi、plugin和app離線包功能。

可選的，所述jsapi包括pushwindow、popwindow、exitapp、rpc接口。

可選的，在所述加載并渲染所述目標(biāo)頁面的內(nèi)容之前，所述方法還包括：

根據(jù)所述目標(biāo)頁面的開發(fā)技術(shù)，進行頁面內(nèi)容的加載和渲染。

可選的，所述根據(jù)所述目標(biāo)頁面的開發(fā)技術(shù)，進行頁面內(nèi)容的加載和渲染，具體包括：

在所述目標(biāo)頁面的開發(fā)技術(shù)為html的情況下，使用uiwebview進行頁面內(nèi)容的加載和渲染；

或者，

在所述新頁面的開發(fā)技術(shù)為react-native的情況下，使用reactrootview進行頁面內(nèi)容的加載和渲染。

根據(jù)本申請實施例提供的一種頁面顯示裝置，所述裝置包括：

代碼添加單元，在應(yīng)用程序顯示當(dāng)前頁面后，所述應(yīng)用程序中的預(yù)設(shè)容器向當(dāng)前頁面中添加jsbridge的代碼；

接口調(diào)用單元，在顯示目標(biāo)頁面的條件被觸發(fā)的情況下，根據(jù)所述jsbridge的代碼提供的jsbridge.call，調(diào)用所述預(yù)設(shè)容器提供的預(yù)設(shè)接口；

頁面顯示單元，根據(jù)所述預(yù)設(shè)接口打開新的頁面，加載并渲染所述目標(biāo)頁面的內(nèi)容。

可選的，所述預(yù)設(shè)容器提供有jsapi、plugin和app離線包功能。

可選的，所述jsapi包括pushwindow、popwindow、exitapp、rpc接口。

可選的，所述頁面顯示單元，具體包括：

頁面打開子單元，根據(jù)所述預(yù)設(shè)接口打開新的頁面；

頁面顯示子單元，根據(jù)所述目標(biāo)頁面的開發(fā)技術(shù)，進行頁面內(nèi)容的加載和渲染。

可選的，所述第二頁面顯示子單元，具體包括：

在所述目標(biāo)頁面的開發(fā)技術(shù)為html的情況下，使用uiwebview進行頁面內(nèi)容的加載和渲染；

或者，

在所述目標(biāo)頁面的開發(fā)技術(shù)為react-native的情況下，使用reactrootview進行頁面內(nèi)容的加載和渲染。

本申請實施例中，基于所述預(yù)設(shè)容器，可以在當(dāng)前頁面中注入jsbridge的代碼，使得可以實現(xiàn)在html頁面調(diào)用jsapi從而完成頁面之間跳轉(zhuǎn)的接口，可以實現(xiàn)頁面的動態(tài)性。相對于現(xiàn)有基于html技術(shù)開發(fā)的app，本申請基于預(yù)設(shè)容器開發(fā)的app，無需開發(fā)人員另行寫入別的代碼例如每次頁面之間的跳轉(zhuǎn)所需要寫入帶有uiwebview的h5viewcontroller，通過預(yù)設(shè)容器提供的api就可以實現(xiàn)頁面之間的跳轉(zhuǎn)。

附圖說明

圖1是本申請一實施例提供的客戶端和服務(wù)器(c/s)的示意圖；

圖2是本申請一實施例提供的瀏覽器和服務(wù)器(b/s)的示意圖

圖3是本申請一實施例提供的頁面顯示方法的流程圖；

圖4是本申請一實施例提供的預(yù)設(shè)容器的內(nèi)部關(guān)系的示意圖；

圖5是本申請?zhí)峁┑捻撁骘@示裝置所在設(shè)備的一種硬件結(jié)構(gòu)圖；

圖6是本申請一實施例提供的頁面顯示裝置的模塊示意圖。

具體實施方式

這里將詳細(xì)地對示例性實施例進行說明，其示例表示在附圖中。下面的描述涉及附圖時，除非另有表示，不同附圖中的相同數(shù)字表示相同或相似的要素。以下示例性實施例中所描述的實施方式并不代表與本申請相一致的所有實施方式。相反，它們僅是與如所附權(quán)利要求書中所詳述的、本申請的一些方面相一致的裝置和方法的例子。

在本申請使用的術(shù)語是僅僅出于描述特定實施例的目的，而非旨在限制本申請。在本申請和所附權(quán)利要求書中所使用的單數(shù)形式的“一種”、“所述”和“該”也旨在包括多數(shù)形式，除非上下文清楚地表示其他含義。還應(yīng)當(dāng)理解，本文中使用的術(shù)語“和/或”是指并包含一個或多個相關(guān)聯(lián)的列出項目的任何或所有可能組合。

應(yīng)當(dāng)理解，盡管在本申請可能采用術(shù)語第一、第二、第三等來描述各種信息，但這些信息不應(yīng)限于這些術(shù)語。這些術(shù)語僅用來將同一類型的信息彼此區(qū)分開。例如，在不脫離本申請范圍的情況下，第一信息也可以被稱為第二信息，類似地，第二信息也可以被稱為第一信息。取決于語境，如在此所使用的詞語“如果”可以被解釋成為“在……時”或“當(dāng)……時”或“響應(yīng)于確定”。

現(xiàn)有軟件開發(fā)的整體架構(gòu)主要分為c/s(client/serverstructs)和b/s(browser/server)架構(gòu)。

其中，c/s架構(gòu)，即如圖1所示客戶端和服務(wù)器的示意圖。通常，客戶端上安裝的應(yīng)用程序例如app(application)都是采用c/s架構(gòu)來實現(xiàn)的。

c/s架構(gòu)的優(yōu)點是能充分發(fā)揮客戶端的處理能力，很多工作可以在客戶端處理后再提交給服務(wù)器，因此服務(wù)器的響應(yīng)速度就很快。但是，c/s架構(gòu)的確定是需要用戶下載并安裝客戶端軟件，當(dāng)業(yè)務(wù)邏輯需要更新，例如新增功能時，往往需要用戶下載更新包，或者下載最新的客戶端軟件。

b/s架構(gòu)，如圖2所示即瀏覽器和服務(wù)器的示意圖。b/s架構(gòu)是伴隨著互聯(lián)網(wǎng)的興起，利用了web瀏覽器技術(shù)，結(jié)合瀏覽器的多種腳本語音和activex技術(shù)。

b/s最大的優(yōu)點就是可以在任何地方進行操作而不用安裝任何專門的軟件，只要有一臺能上網(wǎng)的電腦就能使用，客戶端零安裝、零維護。系統(tǒng)的擴展非常容易。相應(yīng)地，缺點就是功能比較單一。

現(xiàn)有的app開發(fā)一般是采用html技術(shù)進行開發(fā)的。在使用html技術(shù)開發(fā)時，還無法完全做到頁面之間的動態(tài)性，基本上還是停留在單頁面上的動態(tài)布局。例如，想要在app中點擊某個圖片來實現(xiàn)跳轉(zhuǎn)到目標(biāo)頁面，開發(fā)人員一般需要寫入一個帶有uiwebview的h5viewcontroller，并且還需要寫入該h5viewcontroller對應(yīng)的url(uniformresourcelocator，統(tǒng)一資源定位符)，該url即為需要跳轉(zhuǎn)到的目標(biāo)頁面?？蛻舳巳绻邮盏接脩酎c擊了該uiwebview，就可以打開h5viewcontroller，從而打開對應(yīng)的url的頁面。通過上述描述，可以知道，開發(fā)人員想要實現(xiàn)頁面之間的跳轉(zhuǎn)時，不是僅寫入目標(biāo)頁面的url即可，還需要寫入帶有uiwebview的h5viewcontroller，所以基于html技術(shù)開發(fā)的app無法做到頁面之間的動態(tài)性。

本申請為了解決現(xiàn)有的app無法做到頁面之間的動態(tài)性的問題，請參見圖3，為本申請一實施例提供的頁面顯示方法的流程圖，所述方法可以應(yīng)用于客戶端，所述方法包括以下步驟：

步驟110：在應(yīng)用程序顯示當(dāng)前頁面后，所述應(yīng)用程序中的預(yù)設(shè)容器向當(dāng)前頁面中添加jsbridge的代碼。

本實施例中所述的預(yù)設(shè)容器，可以為native層面(例如ios系統(tǒng)上使用的objective-c開發(fā))實現(xiàn)的nebula容器。

所述nebula容器可以包括：nebulasdk、nebulaposeidon、nebulaappmanager。

其中，所述nebulasdk是對外提供的sdk(softwaredevelopmentkit，軟件開發(fā)工具包)，可以實現(xiàn)既有通用的方法，包括session管理、api等；

所述nebulaposeidon是內(nèi)核sdk，可以實現(xiàn)api、bridge、proxy、monitor等；

所述nebulaappmanager是離線包管理。

所述nebula容器可以對外提供jsapi、plugin和app離線包功能。

其中，所述jsapi，即為javascript接口，該jsapi包括了常用的一些接口例如pushwindow、popwindow、exitapp、rpc等接口。

所述plugin即插件，用于實現(xiàn)所述nebula容器擴展新業(yè)務(wù)。例如，在開發(fā)了一個新業(yè)務(wù)后，可以通過插件插入nebula容器中，使得所述nebula容器業(yè)務(wù)更完善。

所述app離線包，通常是指新業(yè)務(wù)可以通過離線包下發(fā)。

所述nebula容器還提供頁面之間的管理技術(shù)，例如push、pop、或者settitle等

其中，所述push表示推入一個新窗口；所述pop表示退出當(dāng)前窗口。

本實施例中，所述nebula容器對外提供jsbridge接口，調(diào)用方可以通過所述jsbridge接口調(diào)用jsapi，從而實現(xiàn)頁面之間的跳轉(zhuǎn)(即調(diào)用pushwindow)、關(guān)閉(即調(diào)用popwindow接口)、以及其它native的接口。

具體地，所述nebula容器可以向當(dāng)前頁面寫入jsbridge的代碼；

用戶如果點擊了攜帶所述jsbridge的代碼，會觸發(fā)jsbridge.call接口，從而調(diào)用所述nebula容器的jsapi。

如下請參考圖4所示的預(yù)設(shè)容器(nebula)的內(nèi)部關(guān)系的示意圖，包括如下3個部分：

nebulaposeidon、nebulaappmanager和nebula。

其中，關(guān)于所述nebulaposeidon，是所述預(yù)設(shè)容器(nebula)的core(核心)部分，可以實現(xiàn)基于事件模型的開發(fā)能力，主要為后續(xù)jsapi、plugin的實現(xiàn)提供基礎(chǔ)支持。

具體地，如圖4所示，所述nebulaposeidon中包括了service、proxy、kernel、monitor、event、config和bridge。

關(guān)于所述nebulaappmanager，可以實現(xiàn)解決用戶體驗問題，例如可以將新業(yè)務(wù)打成一個離線包下載至本地。

具體地，如圖4所示，所述nebulaappmanager中包括了appmanager、datasource、appstorage、downloadmanager、monitor、zip和config。

關(guān)于所述nebula，實現(xiàn)了app上的session管理、頁面之間的viewcontroller管理、以及jsapi的實現(xiàn)。

具體地，所述nebula中包括了service、sessionmanager、protocol、appdatasourcemanager、config、monitor、event、jsapi、pugin、foundation、common和3rd。

值得一提的時，所述jsbridge，可以用于java代碼和javascript代碼之間的調(diào)用。

在本實施例中，基于所述預(yù)設(shè)容器，在當(dāng)前頁面中注入了jsbridge的代碼，使得

因此，基于所述預(yù)設(shè)容器，可以實現(xiàn)在html頁面調(diào)用jsapi從而完成頁面之間跳轉(zhuǎn)的接口，可以實現(xiàn)頁面的動態(tài)性。相對于現(xiàn)有基于html技術(shù)開發(fā)的app，本申請基于預(yù)設(shè)容器開發(fā)的app，無需開發(fā)人員另行寫入別的代碼例如每次頁面之間的跳轉(zhuǎn)所需要寫入帶有uiwebview的h5viewcontroller，通過預(yù)設(shè)容器提供的api就可以實現(xiàn)頁面之間的跳轉(zhuǎn)。并且，該預(yù)設(shè)容器還可以實現(xiàn)頁面的關(guān)閉，以及其它native的接口。

步驟120：在顯示目標(biāo)頁面的條件被觸發(fā)的情況下，根據(jù)所述jsbridge的代碼提供的jsbridge.call，調(diào)用所述預(yù)設(shè)容器提供的預(yù)設(shè)接口。

本實施例中，所述顯示目標(biāo)頁面的條件可以是預(yù)先設(shè)定的，例如在智能手機上，可以是點擊觸發(fā)，即在顯示目標(biāo)頁面的按鈕被觸發(fā)的情況下，可以根據(jù)所述jsbridge的代碼提供的jsbridge.call，調(diào)用所述預(yù)設(shè)容器提供的預(yù)設(shè)接口。

所述預(yù)設(shè)接口為所述預(yù)設(shè)容器提供的用于打開新的頁面的接口。如前所述，所述預(yù)設(shè)接口可以為pushwindow，所述pushwindow接口即用于執(zhí)行打開新的頁面。

步驟130：根據(jù)所述預(yù)設(shè)接口打開新的頁面，加載并渲染所述目標(biāo)頁面的內(nèi)容。

本實施例中，所述預(yù)設(shè)接口打開新的頁面后，可以根據(jù)所述目標(biāo)頁面的url來進行加載并渲染內(nèi)容，從而完成頁面之間的跳轉(zhuǎn)。

通過本申請實施例，基于所述預(yù)設(shè)容器，可以在當(dāng)前頁面中注入jsbridge的代碼，使得可以實現(xiàn)在html頁面直接調(diào)用jsapi從而完成頁面之間跳轉(zhuǎn)的接口，可以實現(xiàn)頁面的動態(tài)性。相對于現(xiàn)有基于html技術(shù)開發(fā)的app，本申請基于預(yù)設(shè)容器開發(fā)的app，無需開發(fā)人員另行寫入別的代碼例如每次頁面之間的跳轉(zhuǎn)所需要寫入帶有uiwebview的h5viewcontroller，通過預(yù)設(shè)容器提供的api就可以實現(xiàn)頁面之間的跳轉(zhuǎn)。

app開發(fā)除了采用html技術(shù)之外，還可以采用reactnative技術(shù)。

對于大多數(shù)app開發(fā)來說，通常需要面對移動終端開發(fā)，先在市面上主流的系統(tǒng)包括安卓系統(tǒng)和ios系統(tǒng)，其中安卓系統(tǒng)主要使用java，而ios系統(tǒng)主要使用objective-c。因此，通常，一個app需要開發(fā)兩套分別適用于安卓和iso。然而，隨著reactnative的出現(xiàn)，有效解決了這一問題。使用reactnative技術(shù)開發(fā)的app可以同時適用于安卓系統(tǒng)和ios系統(tǒng)。

針對不同的開發(fā)技術(shù)，加載和渲染目標(biāo)頁面的內(nèi)容也會出現(xiàn)不同。為了應(yīng)對這種情況，基于上述圖3所示的實施例基礎(chǔ)上，在步驟130中所述加載并渲染所述目標(biāo)頁面的內(nèi)容之前，所述方法還包括：

根據(jù)所述目標(biāo)頁面的開發(fā)技術(shù)，進行頁面內(nèi)容的加載和渲染。

本實施例中，可以通過查看所述目標(biāo)頁面的content-type，來確定開發(fā)技術(shù)。一般的，所述開發(fā)技術(shù)可以是html技術(shù)，也可以是reactnative技術(shù)。

具體地，在所述目標(biāo)頁面的開發(fā)技術(shù)為html的情況下，使用uiwebview進行頁面內(nèi)容的加載和渲染。

或者，

在所述目標(biāo)頁面的開發(fā)技術(shù)為reactnative的情況下，使用reactrootview進行頁面內(nèi)容的加載和渲染。

通常，html技術(shù)開發(fā)的頁面，可以使用uiwebview進行頁面內(nèi)容的加載和渲染。reactnative技術(shù)開發(fā)的頁面，可以使用reactrootview進行頁面內(nèi)容的加載和渲染。

通過本申請實施例，可以自動地根據(jù)目標(biāo)頁面的開發(fā)技術(shù)，使用相應(yīng)的方式進行頁面內(nèi)容的加載和渲染。

與前述頁面顯示方法實施例相對應(yīng)，本申請還提供了一種頁面顯示裝置的實施例。所述裝置實施例可以通過軟件實現(xiàn)，也可以通過硬件或者軟硬件結(jié)合的方式實現(xiàn)。以軟件實現(xiàn)為例，作為一個邏輯意義上的裝置，是通過其所在設(shè)備的處理器將非易失性存儲器中對應(yīng)的計算機程序指令讀取到內(nèi)存中運行形成的。從硬件層面而言，如圖5所示，為本申請頁面顯示裝置所在設(shè)備的一種硬件結(jié)構(gòu)圖，除了圖5所示的處理器、網(wǎng)絡(luò)接口、內(nèi)存以及非易失性存儲器之外，實施例中裝置所在的設(shè)備通常根據(jù)該頁面顯示實際功能，還可以包括其他硬件，對此不再贅述。

參見圖6，為本申請一實施例提供的頁面顯示裝置的模塊圖，所述裝置包括：代碼添加單元210、接口調(diào)用單元220和頁面顯示單元230。

其中，所述代碼添加單元210，在應(yīng)用程序顯示當(dāng)前頁面后，所述應(yīng)用程序中的預(yù)設(shè)容器向當(dāng)前頁面中添加jsbridge的代碼；

所述接口調(diào)用單元220，在顯示目標(biāo)頁面的條件被觸發(fā)的情況下，根據(jù)所述jsbridge的代碼提供的jsbridge.call，調(diào)用所述預(yù)設(shè)容器提供的預(yù)設(shè)接口；

頁面顯示單元230，根據(jù)所述預(yù)設(shè)接口打開新的頁面，加載并渲染所述目標(biāo)頁面的內(nèi)容。

在一個可選的實施例中：

所述預(yù)設(shè)容器提供有jsapi、plugin和app離線包功能。

在一個可選的實施例中：

所述jsapi包括pushwindow、popwindow、exitapp、rpc接口。

在一個可選的實施例中：

所述頁面顯示單元230，具體包括：

頁面打開子單元，根據(jù)所述預(yù)設(shè)接口打開新的頁面；

頁面顯示子單元，根據(jù)所述目標(biāo)頁面的開發(fā)技術(shù)，進行頁面內(nèi)容的加載和渲染。

在一個可選的實施例中：

所述第二頁面顯示子單元，具體包括：

在所述目標(biāo)頁面的開發(fā)技術(shù)為html的情況下，使用uiwebview進行頁面內(nèi)容的加載和渲染；

或者，

在所述目標(biāo)頁面的開發(fā)技術(shù)為react-native的情況下，使用reactrootview進行頁面內(nèi)容的加載和渲染。

通過本申請實施例，基于所述預(yù)設(shè)容器，可以在當(dāng)前頁面中注入jsbridge的代碼，使得可以實現(xiàn)在html頁面調(diào)用jsapi從而完成頁面之間跳轉(zhuǎn)的接口，可以實現(xiàn)頁面的動態(tài)性。相對于現(xiàn)有基于html技術(shù)開發(fā)的app，本申請基于預(yù)設(shè)容器開發(fā)的app，無需開發(fā)人員另行寫入別的代碼例如每次頁面之間的跳轉(zhuǎn)所需要寫入帶有uiwebview的h5viewcontroller，通過預(yù)設(shè)容器提供的api就可以實現(xiàn)頁面之間的跳轉(zhuǎn)。

上述實施例闡明的系統(tǒng)、裝置、模塊或單元，具體可以由計算機芯片或?qū)嶓w實現(xiàn)，或者由具有某種功能的產(chǎn)品來實現(xiàn)。一種典型的實現(xiàn)設(shè)備為計算機，計算機的具體形式可以是個人計算機、膝上型計算機、蜂窩電話、相機電話、智能電話、個人數(shù)字助理、媒體播放器、導(dǎo)航設(shè)備、電子郵件收發(fā)設(shè)備、游戲控制臺、平板計算機、可穿戴設(shè)備或者這些設(shè)備中的任意幾種設(shè)備的組合。

上述裝置中各個單元的功能和作用的實現(xiàn)過程具體詳見上述方法中對應(yīng)步驟的實現(xiàn)過程，在此不再贅述。

對于裝置實施例而言，由于其基本對應(yīng)于方法實施例，所以相關(guān)之處參見方法實施例的部分說明即可。以上所描述的裝置實施例僅僅是示意性的，其中所述作為分離部件說明的單元可以是或者也可以不是物理上分開的，作為單元顯示的部件可以是或者也可以不是物理單元，即可以位于一個地方，或者也可以分布到多個網(wǎng)絡(luò)單元上?？梢愿鶕?jù)實際的需要選擇其中的部分或者全部模塊來實現(xiàn)本申請方案的目的。本領(lǐng)域普通技術(shù)人員在不付出創(chuàng)造性勞動的情況下，即可以理解并實施。

本領(lǐng)域技術(shù)人員在考慮說明書及實踐這里公開的發(fā)明后，將容易想到本申請的其它實施方案。本申請旨在涵蓋本申請的任何變型、用途或者適應(yīng)性變化，這些變型、用途或者適應(yīng)性變化遵循本申請的一般性原理并包括本申請未公開的本技術(shù)領(lǐng)域中的公知常識或慣用技術(shù)手段。說明書和實施例僅被視為示例性的，本申請的真正范圍和精神由下面的權(quán)利要求指出。

應(yīng)當(dāng)理解的是，本申請并不局限于上面已經(jīng)描述并在附圖中示出的精確結(jié)構(gòu)，并且可以在不脫離其范圍進行各種修改和改變。本申請的范圍僅由所附的權(quán)利要求來限制。