七行JSON代碼將你的網站變成移動應用

本文介紹了借助Jasonette將Web視圖和原生組件融合構建真正“混合”應用的做法。

如果我告訴你，只需要上述7行橙色的JSON代碼就可以將一個網站變成移動應用，你相信嗎？完全不需要使用某種框架API重寫網站，就可以獲得與移動應用相同的行為。如果你已經有一個現成的網站，只需要簡單地引用URL就可以將其“打包”為原生應用。

而如果在此基礎上，只需要略微調整JSON代碼內容，就可以直接訪問所有原生API、原生UI組件以及原生視圖切換（View Transition）。

最簡化的范例效果如下圖所示：

從中可以看出，我嵌入了一個GitHub.com的Web頁面，但界面上其余布局均為原生UI組件，例如導航條以及底部的標簽欄。而我們并不需要使用任何API重寫網站，就可以自動獲得原生的切換效果。

在介紹具體做法前你可能會問：“看著挺酷，但除了在原生應用框架內展示Web頁面之外，這種技術還有什么意義？”

問得好！這也是本文要講的重點。我們只需要創建一個無縫的Web視圖與應用間雙向通信，借此，父應用就可以觸發Web視圖內的任何JavaScript函數，隨后Web視圖即可從外部調用原生API。

例如：

請注意，這個視圖包含：

原生導航條，以及內置的切換功能

一個Web視圖，其中嵌入了一個可以生成二維碼的Web應用

在底部包含一個原生的文字輸入組件

上述所有這一切只需要略微調整JSON代碼的屬性即可實現。

最后請注意，隨著在文字輸入區輸入不同內容，二維碼也會產生相應變化。輸入的文字可觸發二維碼生成器Web應用內部的JavaScript函數重新生成二維碼圖像。

目前還沒有任何一個開發框架曾試圖從根本上解決“Web視圖與原生應用無縫集成”的問題，因為這些框架都專注于完全原生，或完全HTML5的做法。

無論什么時候當我們聽到有人討論移動應用的未來時，很可能會聽到類似“到底是HTML5還是原生方法會最終勝出呢？”這樣的說法。

似乎沒人覺得native和html可以共存，而且二者的協同和最終實現似乎也并不容易。

本文我將要介紹：

為何Web引擎與原生組件的融合通常是一種更好的做法。

為何HTML與原生的無縫集成那么難，具體又該如何實現。

更重要的是，該如何使用這樣的技術快速構建自己的應用。

為何要在原生應用中使用HTML？

在進一步介紹前，首先一起看看這樣做是好是壞，以及什么時候適合使用這種方法。這種做法的一些潛在用例如下：

1. 使用Web原生功能

應用中的部分內容使用Web引擎來實現也許是一種更適合的做法。例如WebSocket是一種原生的Web功能，主要面向Web環境而設計。這種情況下就更適合使用內建的Web引擎（iOS的WKWebView以及Android的WebView），而非安裝某些只能“模擬”WebSocket的第三方庫。

無需額外安裝任何代碼，使用免費工具即可實現目標，這樣豈不是更好。同時這也催生了下一個原因。

2. 避免二進制文件體積過大

有些功能也許需要借助龐大的第三方庫，而你可能希望能快速用上這樣的功能。

例如，為了以原生方式包含二維碼圖像生成器，可能需要安裝某些第三方庫，這會導致二進制文件體積增大。但如果使用Web視圖引擎并通過一個簡單的<script src>調用JavaScript庫，就可以免費實現這一切，并且避免了使用第三方原生庫。

3. 缺乏可靠的移動庫

對于一些前沿技術，可能暫時并不具備穩定可靠的移動端實現。

好在大部分此類技術都具備Web實現，因此最高效的集成方法就是使用JavaScript庫。

4. 構建部分原生，部分基于Web的應用

很多新手開發者想要將自己的網站移植為移動應用，但在發現自己現有網站的部分功能過于復雜，無法面向每種移動平臺快速重寫時，往往會感到沮喪或受挫。

例如你可能有一個非常復雜的Web頁面無法快速轉換為移動應用，但網站的其他內容可以很容易地轉換。

面對這種情況，如果通過某種方法將應用的大部分內容以原生方式構建，對于特別復雜的頁面直接將其以HTML的形式無縫集成到應用中，是不是很棒啊。

這是如何實現的？

A. Jasonette

Jasonette是一種基于標記語言，構建跨平臺原生應用的開源方法。

該技術看似Web瀏覽器，但并不會將HTML標記語言解釋為Web頁面，而是會將JSON標記解釋為iOS和Android上的原生應用。

正如所有Web瀏覽器都有完全相同的代碼，但只要按需解釋不同類型的HTML標記，即可為用戶提供所有不同類型的Web應用，所有Jasonette應用也有著完全相同的庫，可按需解釋不同類型的JSON標記并創建出你的應用。開發者完全無需觸及代碼本身，只需要編寫標記，將代碼實時“翻譯”為原生應用，即可開發出自己的應用來。

有關Jasonette的詳細介紹可以參閱這里。

雖然Jasonette的核心作用在于構建原生應用，但本文的重點在于介紹如何將HTML集成到核心原生引擎中，接下來就一起了解一下吧。

B. Jasonette Web容器

原生應用很棒，但有時候我們依然需要使用Web功能。

但Web視圖與原生應用的集成是個麻煩的過程。無縫的集成要求：

Web視圖應作為原生布局的一部分進行集成：Web視圖應作為原生布局的一部分納入應用中，并且操作方式應與其他任何原生UI組件保持一致。否則會讓用戶感覺很笨拙，并且感覺上就像自己實際上是在訪問網站那樣。

父應用可以控制子Web容器：父應用應能隨意控制子Web視圖。

子Web容器可觸發父應用的原生事件：子應用應該能觸發父應用的事件以運行原生API。

這是一個非常繁重的工作，因此先從第一個環節著手介紹：直接將Web容器嵌入原生布局?—并將其作為第1版發布：

JSON Web容器，JSON中的HTML將變為原生應用組件。

僅這一點就已經很實用了，但由于無法交互，依然存在一定的局限。

父應用無法控制子Web容器，子容器無法向父應用發送任何事件通知，這導致Web容器與外界完全隔離。

C. Jasonette Web容器2.0：使其可交互

發布第1版之后，我們開始處理第二個問題：為Web容器添加交互能力。

下文將介紹如何為之前創建的靜態Web容器添加交互能力，讓它變得更強大。

實現：交互式Web容器

1. 通過URL加載

問題

之前在第1版中，為了使用Web容器作為后臺視圖組件，我們首先需要將$jason.body.background.type設置為"html"，隨后在$jason.body.background.text屬性下添加硬編碼的HTML文本，例如這樣：

一般來說，人們往往更希望直接使用Web URL對容器進行實例化，而不希望將整個HTML代碼以硬編碼的方式作為一行代碼加入。

解決方案

Web容器2.0增加了url屬性，我們可以嵌入file://形式的本地HTML，例如這樣（可以從伴隨應用發布的本地HTML文件加載）：

或者也可以嵌入遠程的http[s]:// URL，例如這樣（可以從遠程HTML加載）：

2. 父應用與Web容器的雙向通信

問題

之前，Web容器只能用于展示內容，無法交互。這意味著下列做法全部無法實現：

Jasonette到Web容器的通信：從Jasonette中調用Web容器內部的JavaScript函數。

Web容器到Jasonette的通信：從Web容器代碼中調用原生API。

此時我們只能展示Web容器的內容。這就像網頁中嵌入的iframe框架，主頁面完全無法訪問iframe框架中的內容。

解決方案

Jasonette最大的目標在于設計一種可以描述跨平臺移動應用的標準化標記語言。因此我們需要這個標記語言能夠全面地描述父應用和子Web容器之間的雙向通信。

為此我在父應用和子Web容器之間使用了一種基于JSON-RPC的通信管道。由于Jasonette中的一切都是通過JSON對象表達的，因此使用JSON-RPC標準格式作為通信協議就成了一種非常自然合理的方式。

為了讓JavaScript函數能夠調用Web容器，需要聲明一個名為$agent.request的操作：

$agent.request是一種原生API，可觸發JSON-RPC請求并發送給Web容器。為了使用該API，必須將options對象作為參數傳遞。

options對象實際上是發送給Web容器的JSON-RPC請求。每個屬性的含義如下：

id：Web容器構建在一種名為Agent的底層架構基礎上，通常來說，我們可以為一個視圖使用多個Agent，每個Agent可以有自己的唯一ID。但Web容器是一種特殊類型的Agent，只能使用$webcontainer作為ID，因此這里需要使用ID。

method：要調用的JavaScript函數名稱。

params：傳遞給JavaScript函數的參數數組。

因此完整來看，所用的標記應該是類似這樣的：

這串標記實際上是在說：

當視圖加載（load）時，向Web容器Agent發送一個JSON-RPC請求（$agent.request），而具體的請求是通過options指定的。

Web容器在$jason.body.background下定義，本例中將會加載一個名為file://index.html的本地文件。

隨后會查找一個名為login的JavaScript函數并傳遞params下的兩個參數（"alice"和"1234"）。

上文介紹了父應用如何觸發子Web容器的JavaScript函數調用，我們還可以反著來，讓Web容器觸發父應用的原生API。

詳情請參閱Agent文檔。

范例

繼續回到上文介紹的二維碼生成器范例：

其中底部的文字輸入組件是100%原生的。

二維碼由作為Web應用運行的Web容器生成。

當用戶輸入內容并按下“生成”，將調用Web容器Agent中的$agent.request操作，進而調用JavaScript函數“qr”。

具體示例可以參閱這里。

3. 腳本注入

問題

有時候我們可能需要在Web容器完成初始HTML加載后，動態地將JavaScript代碼注入Web容器。

假設要構建一個自定義的Web瀏覽器應用，我們可能希望將自己的自定義JavaScript注入到每個Web視圖，借此定制Web視圖的行為，這有點類似于Web瀏覽器的擴展。

就算不需要構建Web瀏覽器，當希望為所包含的內容不由我們控制的URL實現自定義行為時，同樣需要使用腳本注入的方法。原生應用和Web容器只能通過$agent API通信，但如果無法更改HTML內容，只能通過動態注入的方式將$agent接口加入Web容器。

解決方案

正如上文所述，$jason.body.background這個Web容器也是一個agent，這意味著我們可以使用與普通Agent完全相同的$agent.inject方法。

4. 對URL點擊的處理

以往，Web容器只能通過兩種方式處理鏈接點擊操作：

只讀：將Web容器視作只讀的，忽略所有諸如觸控或滾動等事件。此時所有Web容器都是只讀的，除非明確令其表現得像是普通瀏覽器，具體做法見下文。

普通瀏覽器行為：像是普通瀏覽器那樣，允許用戶與頁面交互。為此需要進行聲明，將"type": "$default"設置為action屬性。

問題

兩者均為“全無或全有（All or nothing）”解決方案。

對于“只讀”，Web容器會忽略用戶的所有交互操作。

對于“普通瀏覽器行為”，Web容器的表現將與瀏覽器一致。點擊鏈接后，將像普通網頁那樣刷新頁面展示鏈接內容，但無法劫持該點擊并調用其他原生API。

解決方案

通過使用新的Web容器，可以將任何action附加到$jason.body.background這個Web容器，進而處理鏈接點擊之類的事件。

一起看一個例子：

在這里我們為Web容器附加了"trigger": "displayBanner"，這意味著當用戶點擊Web容器內的任何鏈接后，將觸發displayBanner操作，而非直接交由Web視圖處理。

此外如果查看displayBanner操作會發現，這里出現了變量$jason。在本例中，點擊的鏈接將通過$jason變量傳遞。例如，如果點擊一個名為""的URL，$jason將獲得下列值：

這意味著我們可以檢查$jason.url的值進而選擇性地觸發不同操作。

用自定義Web瀏覽器的實現作為另一個例子一起來看看：

我們會檢查URL是否包含字符串signin，并根據結果執行兩個不同操作。

如果包含signin，打開一個新視圖并以原生方式完成登錄操作。

如果不包含signin，則直接運行"type": "$default"操作，實現類似普通瀏覽器的行為。

用法示范

構建自定義Web瀏覽器

利用新版Web容器的下列特性，可以實現很多有趣的操作：

通過url屬性實現自我加載，并充當一個功能齊備的瀏覽器。

根據URL的不同，選擇性地處理鏈接點擊操作。

我們甚至可以通過幾十行JSON代碼構建一個自定義的Web瀏覽器。由于現在可以劫持每個鏈接點擊，因此可以檢查$jason.url，并根據結果運行我們需要的任何操作。

例如下面的例子：

從左圖可以看到，點擊鏈接后的行為與普通瀏覽器無異（"type": "$default"）。

從右圖可以看到，點擊鏈接后可以用原生方式轉換至另一個JASON視圖。

這一切都可以根據$jason.url的值選擇性地觸發實現。

第1步：向Web容器附加一個名為visit的操作：

第2步：根據$jason.url的值運行visit內部的相關操作

在下列代碼中，我們會檢查$jason.url是否與newest、show、ask等內容（均為頂級菜單項鏈接）相符。如果相符，設置"type": "$default"即可讓Web容器做出與普通瀏覽器一樣的行為。

如果模式不符，則可通過原生的$href轉換打開一個新視圖，并將點擊的鏈接作為參數傳遞過去。

該Web瀏覽器的完整JSON標記請參閱這里（僅48行?。?。

瞬間構建“混合”應用

人們通常在說“混合”應用時，主要是指封裝在原生應用框架內部的HTML Web應用。

但此處說的并不是這種應用。這里所謂的“混合”是指真正的混合應用，也就是可以同時包含多個原生視圖以及多個基于Web的視圖的應用。在這種應用中，一個視圖可以有多個原生UI組件，以及一個用相同原生布局渲染的Web容器。

Web視圖與原生視圖的交織應當盡可能無縫，使得用戶完全無法分辨。

在這個例子中，我創建了一個可以在Web容器中顯示jasonbase.com的內容，并將其作為主頁視圖的應用。

Jasonbase是我開發的免費JSON托管服務，該服務可以很簡單地用于托管Jasonette應用所用到的JSON標記。

當然，這本身是個網站，但我將其嵌入到Jasonette中，因此在點擊鏈接后并不會打開網頁，而是會通過原生的$href轉換展示原生的JASON視圖。

完全無需觸及Jasonbase.com的代碼就可以構建出這個應用。

只需要將網站作為Web容器嵌入Jasonette，隨后劫持鏈接點擊操作的原生處理方式，這樣就可以實現原生應用所具備的各類功能，例如觸發原生API以及進行原生轉換。

完整代碼可參閱這里。

結論

在我看來，讓這一切如此令人贊嘆的原因在于，在框架層面上即可妥善處理好一切。所有最困難的工作都是在后臺完成的。

應用開發者并不需要自行費時費力從零開始實現下列這一切：

將Web視圖嵌入原生布局

創建JavaScript橋，以便讓應用能夠調用Web視圖中的函數

創建原生事件處理架構，以便讓Web視圖能夠觸發父應用的原生事件

整個解決方案創建了下列內容組成的抽象：

聲明式標記語言：用于描述如何將Web視圖嵌入原生應用。

通信協議（JSON-RPC）：用于在應用及其子Web視圖之間實現極為簡單的通信。

我并不覺得這種方法可以解決所有問題，但從自己的用例來看，至少可以說這是個不錯的解決方案。

我試著以非常前沿的技術來構建應用，而這些技術已經前沿到在移動端還沒有任何穩定可靠的實現（由于協議的一些本質，甚至不清楚最終是否會有移動端的實現）。好在這些技術都有JavaScript實現，因此不費什么事就可以輕松地將其與應用相集成。

總的來說，這種技術很棒，我對目前的效果非常滿意。最新版文檔已經包含了所有新功能，歡迎大家深入研究并嘗試。

聲明：能力越大，需要擔負的責任也就越大

最后我想說：雖然這種新技術確實很強大，但我覺得大家在開發應用時都應該在用戶體驗方面進行更全面的權衡。

有些人可能會借助這種技術構建完全由Web視圖組成的應用，但說到底這樣的做法，你的應用實際上就只是一個網站，已經與開發專屬應用的本意背道而馳了。

需要強調的是，我并不認為你的每個應用都應同時包含HTML和原生組件。我只是認為，這樣的做法對很多面臨某些具體狀況的人會顯得較為有用。只不過別過火就好。

閱讀原文

本文最初發布于Ethan的博客，經原作者授權由InfoQ中文站翻譯并分享。英文原文請看：How to Turn Your Website into a Mobile App with 7 Lines of JSON

關鍵詞： web容器 web技術 html代碼 移動應用設計 web開發 html語言 軟

上一篇：知名代碼托管網站GitHub遭受有史以來最嚴重DDoS攻擊 現已恢復

下一篇：馬布里:愿幫北京推廣冬奧 盼與姚明商量如何做貢獻