可能很多人不知道，規(guī)模大的企業(yè)和IT預(yù)算多的企業(yè)的移動App大部分都是基于混合模式開發(fā)實現(xiàn)的。

很多做App開發(fā)的技術(shù)人員會存在一種偏見，覺得“采用混合模式，基于HTML5技術(shù)開發(fā)出來的App，體驗以及功能會和原生模式開發(fā)的存在差距”，所以更愿意使用原生模式開發(fā)App。

其實市場上主流的App，絕大部分是基于混合模式開發(fā)的。最典型的就是微信，除了聊天功能以外，包括公眾號、小程序等都是由混合模式開發(fā)技術(shù)實現(xiàn)的。再比如電商領(lǐng)域的淘寶、京東等，旅游領(lǐng)域的攜程，教育領(lǐng)域的VipKid，信息分類的58等不同應(yīng)用范圍的App，混合模式開發(fā)技術(shù)使其商品展示及線上市場活動的運營管理都變得非常靈活。此外，在航空、保險、銀行等行業(yè)中，無論是服務(wù)客戶的toC模式App，還是對員工進行管理的toE和toB的App，多是使用混合模式開發(fā)的，混合模式開發(fā)技術(shù)成為了絕對主力。

人們不禁要問“為什么這些公司和企事業(yè)單位，有著足夠的預(yù)算和開發(fā)資源，還要選擇混合模式App開發(fā)技術(shù)作為企業(yè)互聯(lián)網(wǎng)化的支撐？”答案其實和企業(yè)的互聯(lián)網(wǎng)化及數(shù)字化的需求有著直接的聯(lián)系。以下4個方面，決定了越有實力的企業(yè)越需要混合模式App開發(fā)技術(shù)；同時，也是混合模式App開發(fā)技術(shù)形成不同行業(yè)解決方案的根本優(yōu)勢和企業(yè)選擇的必要性所在。

速度的要求

“試錯”這個詞不但在互聯(lián)網(wǎng)公司中廣為流傳，在傳統(tǒng)公司的互聯(lián)網(wǎng)化過程中也被廣泛接受。

越來越多的CIO在談各自企業(yè)移動戰(zhàn)略的時候，都會提到“能否根據(jù)業(yè)務(wù)部門的一個想法，先在一周之內(nèi)做個原型，快速實現(xiàn)，拿出去讓大家看看，然后基于這個原型再修改”。這種快速發(fā)起、快速驗證、快速調(diào)整的方法，已經(jīng)非常流行。之所以要在短時間內(nèi)先把業(yè)務(wù)從想法落到現(xiàn)實，哪怕App粗糙些，也要先實現(xiàn)出來，原因在于具有鮮明企業(yè)個性的業(yè)務(wù)的創(chuàng)新想法可能沒有先例可循，很難考慮得特別完整。與其花費三五個月不停地思考業(yè)務(wù)需求，還不如用一兩個星期先把基礎(chǔ)的想法落實。哪怕短時間內(nèi)做出的App并不能真正滿足業(yè)務(wù)的需要，但是可以讓業(yè)務(wù)人員的想法在這個過程中變得有據(jù)可依、有的放矢，從而為實現(xiàn)更完整且更切實可行的業(yè)務(wù)方案先行探索。

“業(yè)務(wù)部門的一個想法，IT部門一兩周就做出來了！”這對于企業(yè)的信息化負(fù)責(zé)人而言，是很重要的褒獎。這種對速度的要求，恰恰是混合模式開發(fā)技術(shù)最明顯的特長和優(yōu)勢，一套代碼可同步生成iOS與Android兩個平臺的App，甚至還能部分兼容微信公眾號和小程序。一套代碼，并不代表偷懶或工程技術(shù)的簡化，而更多的是因其不僅節(jié)省了代碼編寫的時間，還避免了多個技術(shù)團隊之間跨知識結(jié)構(gòu)的協(xié)同問題，不再需要iOS與Android工程師們開會討論差異性問題，更是大幅節(jié)省了App與服務(wù)器端聯(lián)機調(diào)試的時間成本。但如果同樣的功能，同樣從零開始，使用傳統(tǒng)的原生開發(fā)技術(shù)基本沒有辦法在一兩個星期內(nèi)完成有價值業(yè)務(wù)需求的實現(xiàn)，因為這個時間可能連不同終端碎片化和差異化的問題都不足以解決。所以，CIO為了滿足業(yè)務(wù)發(fā)展的需求和數(shù)字化速度的要求，在移動戰(zhàn)略中往往都會規(guī)劃使用跨平臺的混合模式App開發(fā)技術(shù)。

業(yè)務(wù)靈活性的要求

在PC時代的B/S架構(gòu)中，想要實現(xiàn)IT系統(tǒng)的更新并不需要過多地考慮用戶端的影響。因為作為用戶入口的瀏覽器一直處于訪問網(wǎng)絡(luò)的狀態(tài)，只要網(wǎng)絡(luò)連通，用戶隨時訪問網(wǎng)站都會獲得最新的功能和業(yè)務(wù)。對用戶而言，并不真正地存在版本的概念。只要訪問服務(wù)器，服務(wù)器的任何更新都可以隨時展示到用戶界面上，出現(xiàn)使用問題時，往往只需要清空一次瀏覽器Cookie基本就可以解決。

但是在移動時代，用戶對版本的概念變得越發(fā)敏感。而對App的版本管理也成了CIO頭痛的問題。通常因為軟件開發(fā)商能力的制約，或者一些無法避免的bug，讓一些已發(fā)布的App變得難用甚至?xí)罎?。此外，一些臨時的市場活動、很少但重要的功能、一些不在規(guī)劃內(nèi)的產(chǎn)品需求調(diào)整等情況，都會直接引出同一個問題“用戶必須更新一個版本，重新下載安裝，才能滿足上述需求”。這種看似日常的版本發(fā)布和用戶更新，恰恰是傳統(tǒng)企業(yè)信息化過程中面臨的全新問題。

“能否像傳統(tǒng)瀏覽器那樣，用戶打開的永遠(yuǎn)是最新的服務(wù)和功能？”很多企業(yè)的CIO問出了相同的問題，于是大量的、不合規(guī)的軟件服務(wù)商和IT程序員想出了一個“偷懶”的模式。在App中嵌入一些WebView，將一些功能采用傳統(tǒng)網(wǎng)頁的模式，訪問服務(wù)器，動態(tài)獲取。雖然表面上解決了版本更新的問題，實則產(chǎn)生了大量體驗很差的App。

企業(yè)對業(yè)務(wù)靈活性的要求，本質(zhì)是希望像微信小程序一樣，可以隨時發(fā)布一些新的功能，隨時動態(tài)增改一些功能的入口，讓用戶任意使用，同時讓用戶的體驗更好。這種對業(yè)務(wù)靈活性的需求其實需要像小程序一樣有強大的混合模式App開發(fā)技術(shù)來支撐。從而達成“增量更新”“靜默更新”“打開獲得新功能和新體驗”，而不是嵌套WebView，用網(wǎng)頁模擬App的方法，以較差的用戶體驗的代價換取業(yè)務(wù)靈活的可行性。

當(dāng)然，目前傳統(tǒng)模式開發(fā)的App，特別是用Android開發(fā)的App也開始部分支持動態(tài)更新。這也恰恰說明，業(yè)務(wù)靈活性是企業(yè)互聯(lián)網(wǎng)化、數(shù)字化進程的剛需。只是由于傳統(tǒng)技術(shù)的制約以及軟件開發(fā)團隊或者服務(wù)商能力的限制，真正的原生動態(tài)更新始終沒有辦法大規(guī)模進入企業(yè)，實現(xiàn)商用。這也讓企業(yè)對混合模式App開發(fā)技術(shù)的需求更為迫切，成為每個CIO的必備選項。

集中管理的要求

業(yè)務(wù)部門的互聯(lián)網(wǎng)化意識是因為互聯(lián)網(wǎng)的廣泛普及被帶動起來的。所以，傳統(tǒng)的由IT部門主導(dǎo)企業(yè)信息化的態(tài)勢發(fā)生了微妙的變化。過去，都是由IT部門發(fā)起信息化需求，但現(xiàn)在的IT部門越來越像“服務(wù)部門”。因為業(yè)務(wù)團隊在不停地發(fā)起各種各樣“業(yè)務(wù)+互聯(lián)網(wǎng)”的信息化需求。這個時候，很多傳統(tǒng)企業(yè)的IT部門領(lǐng)導(dǎo)，沒認(rèn)識到自己角色的轉(zhuǎn)變，如果還存有拖延、不管不問、你們自己搞不定等類似的想法，就會導(dǎo)致當(dāng)下很多企業(yè)的信息化面臨的“各種移動App的徹底碎片化”“各個業(yè)務(wù)部門自己找軟件開發(fā)商實現(xiàn)各自的需求”等問題。這不但架空了IT部門的信息化主導(dǎo)地位，更麻煩的是，讓后續(xù)的集中管理變得艱難無比。幾十家甚至上百家不同標(biāo)準(zhǔn)的服務(wù)摻雜在企業(yè)的核心系統(tǒng)中，甚至有些業(yè)務(wù)部門為了快速滿足自己的需求而脫離了IT部門主導(dǎo)的傳統(tǒng)PC核心系統(tǒng)，這些操作都是非常危險的。

IT部門在被業(yè)務(wù)部門要求滿足業(yè)務(wù)的互聯(lián)網(wǎng)化需求時，往往發(fā)現(xiàn)心有余而力不足。IT部門人手有限，實在沒辦法逐一滿足所有業(yè)務(wù)部門的移動化需求。如果不管，就會產(chǎn)生前面所提到的“技術(shù)棧、開發(fā)商”碎片化的問題。這個時候，基于混合模式App開發(fā)技術(shù)的移動應(yīng)用平臺，就很好地解決了這二者之間的矛盾。

定標(biāo)準(zhǔn)，從而實現(xiàn)“集中管理”。如果企業(yè)能夠制訂一套統(tǒng)一的混合模式App開發(fā)技術(shù)和移動平臺標(biāo)準(zhǔn)，各個業(yè)務(wù)部門就可以獨立尋找自己的軟件開發(fā)商，用各種方法滿足自己的移動業(yè)務(wù)需求。平臺的一致性可以帶來標(biāo)準(zhǔn)化的統(tǒng)一。這其中包括技術(shù)標(biāo)準(zhǔn)化、開發(fā)流程標(biāo)準(zhǔn)化、代碼管理標(biāo)準(zhǔn)化、項目管理標(biāo)準(zhǔn)化、驗收標(biāo)準(zhǔn)化、管理和運營標(biāo)準(zhǔn)化等。

既要放，也要抓。這就是互聯(lián)網(wǎng)時代企業(yè)信息化的要求，更是IT部門的職責(zé)。混合模式App開發(fā)技術(shù)，有望成為實現(xiàn)企業(yè)移動戰(zhàn)略的利器之一。

信息化安全的要求

企業(yè)互聯(lián)網(wǎng)化帶來的最根本轉(zhuǎn)變就是，內(nèi)網(wǎng)的信息化變成了外網(wǎng)的互聯(lián)網(wǎng)化。

傳統(tǒng)信息化一般包括內(nèi)網(wǎng)、固定場所、固定網(wǎng)絡(luò)環(huán)境和固定的設(shè)備等關(guān)鍵詞。而移動戰(zhàn)略背景下的企業(yè)互聯(lián)網(wǎng)化，則同時包括外網(wǎng)、隨時、隨地、員工個人設(shè)備、4G和Wi-Fi等關(guān)鍵詞。這些不起眼的變化，給企業(yè)的業(yè)務(wù)帶來的卻是天翻地覆的調(diào)整。

移動設(shè)備管理軟件（Mobile Devices Management，MDM）曾風(fēng)靡一時，但是購買了MDM的企業(yè)幾乎無一例外地發(fā)現(xiàn)其很難推進。因為MDM伴隨著員工自帶設(shè)備（Bring Your Own Device，BYOD）。如果用企業(yè)的管理軟件來管理員工個人設(shè)備，肯定會有很多人反對。所以，大部分的MDM最終草草收場，只是管理了企業(yè)自己購買的一些移動設(shè)備。

企業(yè)移動化、互聯(lián)網(wǎng)化的安全怎么保障？ 這要滿足3個層面的安全，即設(shè)備安全、傳統(tǒng)安全和云端安全。

混合模式App開發(fā)技術(shù)可以實現(xiàn)類似于企業(yè)應(yīng)用商店（如微信公眾號）的動態(tài)權(quán)限綁定和授權(quán)模式，能夠支持特定設(shè)備、特定的人，也可以選擇不同的子應(yīng)用。此外，還可以實現(xiàn)隨著用戶工作內(nèi)容的調(diào)整，根據(jù)設(shè)備編碼和用戶權(quán)限來實時分配全新子應(yīng)用的功能。

這種基于企業(yè)移動應(yīng)用商店的“子應(yīng)用”模式，也是混合模式App開發(fā)技術(shù)成為企業(yè)移動戰(zhàn)略支撐的關(guān)鍵。因為做得好的企業(yè)應(yīng)用商店，不僅能夠滿足傳統(tǒng)原生模式開發(fā)的App所不能賦予企業(yè)的、對各種安全性的需求，還實現(xiàn)了對業(yè)務(wù)靈活性的管理目的。

APICloud作為中國主流的混合模式App開發(fā)技術(shù)服務(wù)提供商，一直在以布道者的身份推進混合技術(shù)在國內(nèi)的發(fā)展和應(yīng)用。我們不僅提供技術(shù)，也提供商業(yè)服務(wù)，因此會更多地深入到大量的商業(yè)用戶中去，如海爾、春秋航空、英特爾、中信證券、上汽等。我們的團隊結(jié)合不同的商業(yè)場景和實際的商業(yè)客戶需求，編寫了《30天App開發(fā)從0到1：APICloud移動開發(fā)實戰(zhàn)》，希望能夠為不同規(guī)模的企業(yè)在移動信息化和互聯(lián)網(wǎng)化進程中提供有價值的參考，同時也能夠讓從事App開發(fā)的技術(shù)人員有更多可借鑒的實戰(zhàn)經(jīng)驗。

主要內(nèi)容

本文從總體上介紹APICloud平臺，包括APICloud應(yīng)用的開發(fā)模式、設(shè)計思想、控制臺使用流程等，并以一個HelloWorld App為例讓讀者體驗一個完整的APICloud App的開發(fā)流程。

學(xué)習(xí)目標(biāo)

（1）了解APICloud平臺，了解APICloud相關(guān)的學(xué)習(xí)資源、入門資料和常見的問題。讓沒有接觸過APICloud平臺的讀者，對平臺有一個基礎(chǔ)的了解；讓學(xué)習(xí)過APICloud并且已掌握一部分技能的讀者，通過本文的學(xué)習(xí)，可以快速找到需要的資料和解決問題的方法。

（2）學(xué)習(xí)如何在APICloud平臺上創(chuàng)建、修改、調(diào)試、編譯和運行一個最簡單的APICloud App。掌握APICloud App完整的開發(fā)流程。

要對APICloud平臺做一個全面的介紹，需要花很長的時間和很多的篇幅來講解每一個細(xì)節(jié)，而本文作者希望能用更多的篇幅來講解一個App的實際開發(fā)過程，講解具體的代碼實現(xiàn)。所以，本文在介紹APICloud平臺的時候，是通過拋出一個個問題，然后告訴讀者應(yīng)該到哪兒去找對應(yīng)的學(xué)習(xí)資源，到哪兒能夠找到解決問題的方案。

 1.1　APICloud平臺介紹

本文將從APICloud可以做什么，如何獲取使用幫助，APICloud的技術(shù)、產(chǎn)品和生態(tài)等多個方面對APICloud平臺加以介紹。

1.1.1　查看APICloud平臺能力

開發(fā)者在接觸一個開發(fā)平臺的時候，通常第一個想法就是去查看這個平臺的能力。特別是那些想做App的、有著明確需求的開發(fā)者，他們會非常關(guān)心自己的需求在這個開發(fā)平臺上是否能夠滿足。所以，本文開篇就先來解決這個開發(fā)者普遍關(guān)心的問題，讀者可以帶著自己預(yù)先想好的需求來了解APICloud平臺，昆山做app公司了解如何能夠快速地在APICloud平臺上查找相關(guān)的能力。

1．通過官方文檔快速搜索功能模塊

查看APICloud平臺提供的能力，一個最基礎(chǔ)也是最有效的方法就是查看APICloud的API文檔。

APICloud官方網(wǎng)站中的文檔頁面如圖1-1所示。如需要查看視頻播放的功能，可以在文檔中搜索“視頻播放”，搜索結(jié)果如圖1-2所示，可以看到在APICloud平臺上有多種提供視頻播放功能的模塊，如videoPlayer（播放本地視頻）、moviePlayer（播放網(wǎng)絡(luò)視頻）、polyvPlayer（保利威視播放器）、baiduPlayer（百度播放器）等。

 

圖1-1                

圖1-2

點擊其中一個搜索結(jié)果，查看模塊的詳細(xì)文檔。比如點擊“videoPlayer”之后可以看到這個模塊對于視頻播放提供了很多API，這些API基本覆蓋了一個視頻播放器所有常見的功能，如圖1-3所示。

圖1-3

再比如要查找支付功能，可以在文檔中搜索“支付”，通過搜索結(jié)果可以看到在APICloud平臺上有很多個提供支付功能的模塊，如aliPay（支付寶）、wxPay（微信支付）、unionPay（銀聯(lián)支付）、paypal（PayPal支付）、iap（iOS應(yīng)用內(nèi)支付）等；也有ping++、beeCloud等第三方聚合類的支付模塊。點擊每個模塊均可以查看具體的API詳情。

讀者想了解APICloud平臺有哪些能力，最簡單的方法就是到APICloud官方文檔中去搜索相應(yīng)的功能，這樣就可以一目了然地知道APICloud平臺有沒有相應(yīng)的模塊來支持自己想要的功能。

2． APICloud能力支撐體系

目前在APICloud平臺上已經(jīng)提供了600多個模塊，上萬個API。這些API基本可以覆蓋一款A(yù)pp所需的所有常用功能，為方便表述，它們被分為“平臺使用”“基礎(chǔ)功能”“界面布局”“設(shè)備特性”“功能擴展”和“開放服務(wù)”六大類，其分類與具體包含內(nèi)容如圖1-4所示。

圖1-4

1.1.2　開發(fā)模式、技術(shù)語言和平臺定位

很多APICloud初學(xué)者會關(guān)心這些問題：APICloud App的開發(fā)模式是什么樣的、使用什么技術(shù)語言、目前自己的開發(fā)團隊是否適合使用APICloud開發(fā)App、整個APICloud的學(xué)習(xí)曲線是什么樣的、入門簡不簡單等。

1．開發(fā)模式和技術(shù)語言

APICloud應(yīng)用的開發(fā)模式是使用標(biāo)準(zhǔn)的HTML、CSS和JavaScript+APICloud擴展API來進行App開發(fā)，如圖1-5所示。APICloud的App開發(fā)使用的是標(biāo)準(zhǔn)的HTML5技術(shù)，針對標(biāo)準(zhǔn)HTML5所不具備的功能或是用HTML5實現(xiàn)體驗不好的功能（這些功能也是開發(fā)者在App開發(fā)過程中非常常用的功能）。APICloud提供了600多個擴展模塊和上萬個API，通過這些模塊和API來擴展HTML5的功能，滿足App的開發(fā)需求。

 

圖1-5

2．?dāng)U展API調(diào)用方式

APICloud擴展API的調(diào)用方式與調(diào)用標(biāo)準(zhǔn)的JavaScript方法是完全一樣的。APICloud引擎的核心API是放在window.api這個對象下面的，這個對象是APICloud在JavaScript全局作用域內(nèi)擴展的唯一一個對象，可直接調(diào)用。如果想調(diào)用某個模塊下面的方法，可以通過require的方式動態(tài)引入，通過在api.require方法的參數(shù)中指定某個模塊的名稱來引入相應(yīng)的模塊，然后調(diào)用模塊下面的方法，具體演示如下。

1  //核心API在window.api對象下，可以直接調(diào)用 2  api.methodName(param, callback); 3 //擴展模塊需要require引入，遵守CommonJS規(guī)范 4  var module = api.require('moduleName'); 5  module.methodName(param, callback); 6  param: {} //參數(shù)，是一個JSON對象 7  callback: function(ret, err){} //回調(diào)函數(shù)，是一個Function對象，異步方法調(diào)用的結(jié)果通過此函數(shù)返回

 

所有API的調(diào)用方式都是相同的，第一個參數(shù)是一個JSON對象，承載著要傳遞給模塊的信息；第二個參數(shù)是一個callback函數(shù)。APICloud大部分的API調(diào)用都是異步方式，在調(diào)用的時候，要指定一個callback函數(shù)，當(dāng)這個API操作完成時，操作結(jié)果將通過該callback函數(shù)回調(diào)。

一些常用的調(diào)用方式，比如打開一個新窗口，可以調(diào)用api.openWin()；打開通訊錄可以調(diào)用api.openContacts()，錄音、圖片緩存等也是調(diào)用相應(yīng)的方法。如果想去加載文件系統(tǒng)模塊，可以通過api.require("fs")來加載fs模塊，然后調(diào)用fs模塊下面的方法。使用條碼掃描模塊也是類似的。示例如下。

● 打開新窗口：api.openWin()。 

● 打開系統(tǒng)通訊錄：api.openContacts()。 

● 錄音：api.startRecord()。 

● 緩存網(wǎng)絡(luò)圖片：api.imageCache()。 

● 加載fs模塊：var fs = api.require('fs')。 

● 新建一個文件：fs.createFile()。 

● 加載二維碼/條形碼掃描模塊：var scanner = api.require('FNScanner')。 

● 打開二維碼/條形碼掃描：scanner.openScanner()。 

APICloud技術(shù)是基于標(biāo)準(zhǔn)的HTML、CSS和JavaScript技術(shù)，并在標(biāo)準(zhǔn)的JavaScript基礎(chǔ)上擴展了一個核心對象-api對象和數(shù)百個模塊。這些模塊可以使用api.require函數(shù)載入，并使用操作標(biāo)準(zhǔn)JavaScript對象的方式調(diào)用上述模塊列舉出方法。

3．?dāng)U展API的作用

讀者可能會問，APICloud為什么要擴展這么多API呢？其實APICloud所擴展的API都是標(biāo)準(zhǔn)的JavaScript所不支持的方法，或是用標(biāo)準(zhǔn)HTML5來實現(xiàn)但體驗不好的功能。讀者可以把HTML5理解成一門技術(shù)、一門語言，但是它還沒有達到一個平臺的水平。這就是APICloud為什么要做這些擴展。APICloud所有的擴展主要是圍繞以下這4個方面進行的。

兼容性：在PC互聯(lián)網(wǎng)時代，瀏覽器具有多種內(nèi)核，JavaScript框架產(chǎn)生的最初原因就是為了實現(xiàn)JavaScript代碼在各種瀏覽器上的兼容和適配。在移動互聯(lián)網(wǎng)時代，雖然在主流的手機系統(tǒng)中，Android和iOS的瀏覽器內(nèi)核都是webkit，但是出于商業(yè)原因，谷歌從webkit中建立了一個新的分支，叫blink。現(xiàn)在兩個分支的主要貢獻者分別是蘋果和谷歌，所以未來這兩個內(nèi)核的兼容性問題會一直存在。

實用性：

Page不等于App，標(biāo)準(zhǔn)的HTML、CSS和JavaScript規(guī)范更多是用來定義網(wǎng)頁和文檔的，例如現(xiàn)在的一些框架都在講SPA結(jié)構(gòu)，它是以單頁面為主的，很多HTML標(biāo)簽是針對于文本信息展示的；而App則不然，App更多是強調(diào)功能和體驗，在原生系統(tǒng)中有很多的組件，HTML5標(biāo)簽和Native組件的設(shè)計規(guī)范是完全不同的。所以，想用標(biāo)準(zhǔn)的HTML5技術(shù)開發(fā)一個App是不現(xiàn)實的，人們不能直接把為WebPage所制定的規(guī)范直接搬到App上。

B/S架構(gòu)與Client/Cloud架構(gòu)：在PC互聯(lián)網(wǎng)時代，終端產(chǎn)品的主要架構(gòu)還是B/S架構(gòu)；但是在移動互聯(lián)網(wǎng)時代，終端產(chǎn)品的主要類型是App，而App是一個完整的Client/Cloud架構(gòu)。在移動端，實現(xiàn)界面和功能，在云端提供數(shù)據(jù)和服務(wù)。頁面布局是存放在移動端的，功能實現(xiàn)也是在移動端完成，所以用戶在使用時可以感受到App的啟動、頁面渲染和布局展示是很快響應(yīng)的。

速度、交互和體驗：這3個問題是用HTML5技術(shù)直接開發(fā)App的最大挑戰(zhàn)。其實，如果使用HTML5技術(shù)實現(xiàn)一個界面，渲染之后顯示出來，用戶看到這個界面時并不能立刻分辨出它是用HTML5實現(xiàn)的還是用Native技術(shù)實現(xiàn)的。但是當(dāng)用戶做一個交互，點擊一下，體驗一下響應(yīng)速度或者做一個手勢，觸發(fā)一個動畫，這時用戶就可以非常清楚地感受到，并能分辨出該界面是用Native技術(shù)開發(fā)的還是用HTML5開發(fā)的。所以速度、交互和體驗也是使用HTML5技術(shù)開發(fā)App必須去解決的問題。

持續(xù)性、靜態(tài)標(biāo)準(zhǔn)與動態(tài)標(biāo)準(zhǔn)：HTML5的定稿花了7年時間，并且整個標(biāo)準(zhǔn)的迭代是緩慢的；而Android和iOS每一次版本更新都會新增很多功能，這些新增的恰恰都是當(dāng)前行業(yè)里最需要的功能，但這些功能很難快速通過制定新的HTML5標(biāo)準(zhǔn)進行更新，并在各個瀏覽器里支持起來。那會是一個非常漫長的過程。

擴展性：在開發(fā)一款A(yù)pp的時候，開發(fā)人員需要擴展很多的功能，有時候要和行業(yè)特點結(jié)合，有時候還要跟硬件結(jié)合，這就會用到大量國內(nèi)的開放服務(wù)，如推送、直播、智能識別等。所有的這些功能，標(biāo)準(zhǔn)的HTML5規(guī)范中都沒有定義，所有的標(biāo)準(zhǔn)瀏覽器引擎也沒有默認(rèn)支持。

總的來說，APICloud擴展的所有功能都是標(biāo)準(zhǔn)HTML5所沒有的，如果HTML5有并且在App中運行起來沒有任何問題，APICloud平臺也沒有必要去做這個擴展。APICloud所有擴展的功能其實就是為了去解決HTML5在兼容性、實用性、持續(xù)性和擴展性等方面的問題。