可能很多人不知道,規模大的企業和IT預算多的企業的移動App大部分都是基于混合模式開發實現的。
很多做App開發的技術人員會存在一種偏見,覺得“采用混合模式,基于HTML5技術開發出來的App,體驗以及功能會和原生模式開發的存在差距”,所以更愿意使用原生模式開發App。
其實市場上主流的App,絕大部分是基于混合模式開發的。最典型的就是微信,除了聊天功能以外,包括公眾號、小程序等都是由混合模式開發技術實現的。再比如電商領域的淘寶、京東等,旅游領域的攜程,教育領域的VipKid,信息分類的58等不同應用范圍的App,混合模式開發技術使其商品展示及線上市場活動的運營管理都變得非常靈活。此外,在航空、保險、銀行等行業中,無論是服務客戶的toC模式App,還是對員工進行管理的toE和toB的App,多是使用混合模式開發的,混合模式開發技術成為了絕對主力。
人們不禁要問“為什么這些公司和企事業單位,有著足夠的預算和開發資源,還要選擇混合模式App開發技術作為企業互聯網化的支撐?”答案其實和企業的互聯網化及數字化的需求有著直接的聯系。以下4個方面,決定了越有實力的企業越需要混合模式App開發技術;同時,也是混合模式App開發技術形成不同行業解決方案的根本優勢和企業選擇的必要性所在。
速度的要求
“試錯”這個詞不但在互聯網公司中廣為流傳,在傳統公司的互聯網化過程中也被廣泛接受。
越來越多的CIO在談各自企業移動戰略的時候,都會提到“能否根據業務部門的一個想法,先在一周之內做個原型,快速實現,拿出去讓大家看看,然后基于這個原型再修改”。這種快速發起、快速驗證、快速調整的方法,已經非常流行。之所以要在短時間內先把業務從想法落到現實,哪怕App粗糙些,也要先實現出來,原因在于具有鮮明企業個性的業務的創新想法可能沒有先例可循,很難考慮得特別完整。與其花費三五個月不停地思考業務需求,還不如用一兩個星期先把基礎的想法落實。哪怕短時間內做出的App并不能真正滿足業務的需要,但是可以讓業務人員的想法在這個過程中變得有據可依、有的放矢,從而為實現更完整且更切實可行的業務方案先行探索。
“業務部門的一個想法,IT部門一兩周就做出來了!”這對于企業的信息化負責人而言,是很重要的褒獎。這種對速度的要求,恰恰是混合模式開發技術最明顯的特長和優勢,一套代碼可同步生成iOS與Android兩個平臺的App,甚至還能部分兼容微信公眾號和小程序。一套代碼,并不代表偷懶或工程技術的簡化,而更多的是因其不僅節省了代碼編寫的時間,還避免了多個技術團隊之間跨知識結構的協同問題,不再需要iOS與Android工程師們開會討論差異性問題,更是大幅節省了App與服務器端聯機調試的時間成本。但如果同樣的功能,同樣從零開始,使用傳統的原生開發技術基本沒有辦法在一兩個星期內完成有價值業務需求的實現,因為這個時間可能連不同終端碎片化和差異化的問題都不足以解決。所以,CIO為了滿足業務發展的需求和數字化速度的要求,在移動戰略中往往都會規劃使用跨平臺的混合模式App開發技術。
業務靈活性的要求
在PC時代的B/S架構中,想要實現IT系統的更新并不需要過多地考慮用戶端的影響。因為作為用戶入口的瀏覽器一直處于訪問網絡的狀態,只要網絡連通,用戶隨時訪問網站都會獲得最新的功能和業務。對用戶而言,并不真正地存在版本的概念。只要訪問服務器,服務器的任何更新都可以隨時展示到用戶界面上,出現使用問題時,往往只需要清空一次瀏覽器Cookie基本就可以解決。
但是在移動時代,用戶對版本的概念變得越發敏感。而對App的版本管理也成了CIO頭痛的問題。通常因為軟件開發商能力的制約,或者一些無法避免的bug,讓一些已發布的App變得難用甚至會崩潰。此外,一些臨時的市場活動、很少但重要的功能、一些不在規劃內的產品需求調整等情況,都會直接引出同一個問題“用戶必須更新一個版本,重新下載安裝,才能滿足上述需求”。這種看似日常的版本發布和用戶更新,恰恰是傳統企業信息化過程中面臨的全新問題。
“能否像傳統瀏覽器那樣,用戶打開的永遠是最新的服務和功能?”很多企業的CIO問出了相同的問題,于是大量的、不合規的軟件服務商和IT程序員想出了一個“偷懶”的模式。在App中嵌入一些WebView,將一些功能采用傳統網頁的模式,訪問服務器,動態獲取。雖然表面上解決了版本更新的問題,實則產生了大量體驗很差的App。
企業對業務靈活性的要求,本質是希望像微信小程序一樣,可以隨時發布一些新的功能,隨時動態增改一些功能的入口,讓用戶任意使用,同時讓用戶的體驗更好。這種對業務靈活性的需求其實需要像小程序一樣有強大的混合模式App開發技術來支撐。從而達成“增量更新”“靜默更新”“打開獲得新功能和新體驗”,而不是嵌套WebView,用網頁模擬App的方法,以較差的用戶體驗的代價換取業務靈活的可行性。
當然,目前傳統模式開發的App,特別是用Android開發的App也開始部分支持動態更新。這也恰恰說明,業務靈活性是企業互聯網化、數字化進程的剛需。只是由于傳統技術的制約以及軟件開發團隊或者服務商能力的限制,真正的原生動態更新始終沒有辦法大規模進入企業,實現商用。這也讓企業對混合模式App開發技術的需求更為迫切,成為每個CIO的必備選項。
集中管理的要求
業務部門的互聯網化意識是因為互聯網的廣泛普及被帶動起來的。所以,傳統的由IT部門主導企業信息化的態勢發生了微妙的變化。過去,都是由IT部門發起信息化需求,但現在的IT部門越來越像“服務部門”。因為業務團隊在不停地發起各種各樣“業務+互聯網”的信息化需求。這個時候,很多傳統企業的IT部門領導,沒認識到自己角色的轉變,如果還存有拖延、不管不問、你們自己搞不定等類似的想法,就會導致當下很多企業的信息化面臨的“各種移動App的徹底碎片化”“各個業務部門自己找軟件開發商實現各自的需求”等問題。這不但架空了IT部門的信息化主導地位,更麻煩的是,讓后續的集中管理變得艱難無比。幾十家甚至上百家不同標準的服務摻雜在企業的核心系統中,甚至有些業務部門為了快速滿足自己的需求而脫離了IT部門主導的傳統PC核心系統,這些操作都是非常危險的。
IT部門在被業務部門要求滿足業務的互聯網化需求時,往往發現心有余而力不足。IT部門人手有限,實在沒辦法逐一滿足所有業務部門的移動化需求。如果不管,就會產生前面所提到的“技術棧、開發商”碎片化的問題。這個時候,基于混合模式App開發技術的移動應用平臺,就很好地解決了這二者之間的矛盾。
定標準,從而實現“集中管理”。如果企業能夠制訂一套統一的混合模式App開發技術和移動平臺標準,各個業務部門就可以獨立尋找自己的軟件開發商,用各種方法滿足自己的移動業務需求。平臺的一致性可以帶來標準化的統一。這其中包括技術標準化、開發流程標準化、代碼管理標準化、項目管理標準化、驗收標準化、管理和運營標準化等。
既要放,也要抓。這就是互聯網時代企業信息化的要求,更是IT部門的職責。混合模式App開發技術,有望成為實現企業移動戰略的利器之一。
信息化安全的要求
企業互聯網化帶來的最根本轉變就是,內網的信息化變成了外網的互聯網化。
傳統信息化一般包括內網、固定場所、固定網絡環境和固定的設備等關鍵詞。而移動戰略背景下的企業互聯網化,則同時包括外網、隨時、隨地、員工個人設備、4G和Wi-Fi等關鍵詞。這些不起眼的變化,給企業的業務帶來的卻是天翻地覆的調整。
移動設備管理軟件(Mobile Devices Management,MDM)曾風靡一時,但是購買了MDM的企業幾乎無一例外地發現其很難推進。因為MDM伴隨著員工自帶設備(Bring Your Own Device,BYOD)。如果用企業的管理軟件來管理員工個人設備,肯定會有很多人反對。所以,大部分的MDM最終草草收場,只是管理了企業自己購買的一些移動設備。
企業移動化、互聯網化的安全怎么保障? 這要滿足3個層面的安全,即設備安全、傳統安全和云端安全。
混合模式App開發技術可以實現類似于企業應用商店(如微信公眾號)的動態權限綁定和授權模式,能夠支持特定設備、特定的人,也可以選擇不同的子應用。此外,還可以實現隨著用戶工作內容的調整,根據設備編碼和用戶權限來實時分配全新子應用的功能。
這種基于企業移動應用商店的“子應用”模式,也是混合模式App開發技術成為企業移動戰略支撐的關鍵。因為做得好的企業應用商店,不僅能夠滿足傳統原生模式開發的App所不能賦予企業的、對各種安全性的需求,還實現了對業務靈活性的管理目的。
APICloud作為中國主流的混合模式App開發技術服務提供商,一直在以布道者的身份推進混合技術在國內的發展和應用。我們不僅提供技術,也提供商業服務,因此會更多地深入到大量的商業用戶中去,如海爾、春秋航空、英特爾、中信證券、上汽等。我們的團隊結合不同的商業場景和實際的商業客戶需求,編寫了《30天App開發從0到1:APICloud移動開發實戰》,希望能夠為不同規模的企業在移動信息化和互聯網化進程中提供有價值的參考,同時也能夠讓從事App開發的技術人員有更多可借鑒的實戰經驗。
主要內容
本文從總體上介紹APICloud平臺,包括APICloud應用的開發模式、設計思想、控制臺使用流程等,并以一個HelloWorld App為例讓讀者體驗一個完整的APICloud App的開發流程。
學習目標
(1)了解APICloud平臺,了解APICloud相關的學習資源、入門資料和常見的問題。讓沒有接觸過APICloud平臺的讀者,對平臺有一個基礎的了解;讓學習過APICloud并且已掌握一部分技能的讀者,通過本文的學習,可以快速找到需要的資料和解決問題的方法。
(2)學習如何在APICloud平臺上創建、修改、調試、編譯和運行一個最簡單的APICloud App。掌握APICloud App完整的開發流程。
要對APICloud平臺做一個全面的介紹,需要花很長的時間和很多的篇幅來講解每一個細節,而本文作者希望能用更多的篇幅來講解一個App的實際開發過程,講解具體的代碼實現。所以,本文在介紹APICloud平臺的時候,是通過拋出一個個問題,然后告訴讀者應該到哪兒去找對應的學習資源,到哪兒能夠找到解決問題的方案。
1.1 APICloud平臺介紹
本文將從APICloud可以做什么,如何獲取使用幫助,APICloud的技術、產品和生態等多個方面對APICloud平臺加以介紹。
1.1.1 查看APICloud平臺能力
開發者在接觸一個開發平臺的時候,通常第一個想法就是去查看這個平臺的能力。特別是那些想做App的、有著明確需求的開發者,他們會非常關心自己的需求在這個開發平臺上是否能夠滿足。所以,本文開篇就先來解決這個開發者普遍關心的問題,讀者可以帶著自己預先想好的需求來了解APICloud平臺,昆山做app公司了解如何能夠快速地在APICloud平臺上查找相關的能力。
1.通過官方文檔快速搜索功能模塊
查看APICloud平臺提供的能力,一個最基礎也是最有效的方法就是查看APICloud的API文檔。
APICloud官方網站中的文檔頁面如圖1-1所示。如需要查看視頻播放的功能,可以在文檔中搜索“視頻播放”,搜索結果如圖1-2所示,可以看到在APICloud平臺上有多種提供視頻播放功能的模塊,如videoPlayer(播放本地視頻)、moviePlayer(播放網絡視頻)、polyvPlayer(保利威視播放器)、baiduPlayer(百度播放器)等。
圖1-1
圖1-2
點擊其中一個搜索結果,查看模塊的詳細文檔。比如點擊“videoPlayer”之后可以看到這個模塊對于視頻播放提供了很多API,這些API基本覆蓋了一個視頻播放器所有常見的功能,如圖1-3所示。
圖1-3
再比如要查找支付功能,可以在文檔中搜索“支付”,通過搜索結果可以看到在APICloud平臺上有很多個提供支付功能的模塊,如aliPay(支付寶)、wxPay(微信支付)、unionPay(銀聯支付)、paypal(PayPal支付)、iap(iOS應用內支付)等;也有ping++、beeCloud等第三方聚合類的支付模塊。點擊每個模塊均可以查看具體的API詳情。
讀者想了解APICloud平臺有哪些能力,最簡單的方法就是到APICloud官方文檔中去搜索相應的功能,這樣就可以一目了然地知道APICloud平臺有沒有相應的模塊來支持自己想要的功能。
2. APICloud能力支撐體系
目前在APICloud平臺上已經提供了600多個模塊,上萬個API。這些API基本可以覆蓋一款App所需的所有常用功能,為方便表述,它們被分為“平臺使用”“基礎功能”“界面布局”“設備特性”“功能擴展”和“開放服務”六大類,其分類與具體包含內容如圖1-4所示。
圖1-4
1.1.2 開發模式、技術語言和平臺定位
很多APICloud初學者會關心這些問題:APICloud App的開發模式是什么樣的、使用什么技術語言、目前自己的開發團隊是否適合使用APICloud開發App、整個APICloud的學習曲線是什么樣的、入門簡不簡單等。
1.開發模式和技術語言
APICloud應用的開發模式是使用標準的HTML、CSS和JavaScript+APICloud擴展API來進行App開發,如圖1-5所示。APICloud的App開發使用的是標準的HTML5技術,針對標準HTML5所不具備的功能或是用HTML5實現體驗不好的功能(這些功能也是開發者在App開發過程中非常常用的功能)。APICloud提供了600多個擴展模塊和上萬個API,通過這些模塊和API來擴展HTML5的功能,滿足App的開發需求。
圖1-5
2.擴展API調用方式
APICloud擴展API的調用方式與調用標準的JavaScript方法是完全一樣的。APICloud引擎的核心API是放在window.api這個對象下面的,這個對象是APICloud在JavaScript全局作用域內擴展的唯一一個對象,可直接調用。如果想調用某個模塊下面的方法,可以通過require的方式動態引入,通過在api.require方法的參數中指定某個模塊的名稱來引入相應的模塊,然后調用模塊下面的方法,具體演示如下。
1 //核心API在window.api對象下,可以直接調用 2 api.methodName(param, callback); 3 //擴展模塊需要require引入,遵守CommonJS規范 4 var module = api.require('moduleName'); 5 module.methodName(param, callback); 6 param: {} //參數,是一個JSON對象 7 callback: function(ret, err){} //回調函數,是一個Function對象,異步方法調用的結果通過此函數返回
所有API的調用方式都是相同的,第一個參數是一個JSON對象,承載著要傳遞給模塊的信息;第二個參數是一個callback函數。APICloud大部分的API調用都是異步方式,在調用的時候,要指定一個callback函數,當這個API操作完成時,操作結果將通過該callback函數回調。
一些常用的調用方式,比如打開一個新窗口,可以調用api.openWin();打開通訊錄可以調用api.openContacts(),錄音、圖片緩存等也是調用相應的方法。如果想去加載文件系統模塊,可以通過api.require("fs")來加載fs模塊,然后調用fs模塊下面的方法。使用條碼掃描模塊也是類似的。示例如下。
● 打開新窗口:api.openWin()。
● 打開系統通訊錄:api.openContacts()。
● 錄音:api.startRecord()。
● 緩存網絡圖片:api.imageCache()。
● 加載fs模塊:var fs = api.require('fs')。
● 新建一個文件:fs.createFile()。
● 加載二維碼/條形碼掃描模塊:var scanner = api.require('FNScanner')。
● 打開二維碼/條形碼掃描:scanner.openScanner()。
APICloud技術是基于標準的HTML、CSS和JavaScript技術,并在標準的JavaScript基礎上擴展了一個核心對象-api對象和數百個模塊。這些模塊可以使用api.require函數載入,并使用操作標準JavaScript對象的方式調用上述模塊列舉出方法。
3.擴展API的作用
讀者可能會問,APICloud為什么要擴展這么多API呢?其實APICloud所擴展的API都是標準的JavaScript所不支持的方法,或是用標準HTML5來實現但體驗不好的功能。讀者可以把HTML5理解成一門技術、一門語言,但是它還沒有達到一個平臺的水平。這就是APICloud為什么要做這些擴展。APICloud所有的擴展主要是圍繞以下這4個方面進行的。
兼容性:在PC互聯網時代,瀏覽器具有多種內核,JavaScript框架產生的最初原因就是為了實現JavaScript代碼在各種瀏覽器上的兼容和適配。在移動互聯網時代,雖然在主流的手機系統中,Android和iOS的瀏覽器內核都是webkit,但是出于商業原因,谷歌從webkit中建立了一個新的分支,叫blink。現在兩個分支的主要貢獻者分別是蘋果和谷歌,所以未來這兩個內核的兼容性問題會一直存在。
實用性:
Page不等于App,標準的HTML、CSS和JavaScript規范更多是用來定義網頁和文檔的,例如現在的一些框架都在講SPA結構,它是以單頁面為主的,很多HTML標簽是針對于文本信息展示的;而App則不然,App更多是強調功能和體驗,在原生系統中有很多的組件,HTML5標簽和Native組件的設計規范是完全不同的。所以,想用標準的HTML5技術開發一個App是不現實的,人們不能直接把為WebPage所制定的規范直接搬到App上。
B/S架構與Client/Cloud架構:在PC互聯網時代,終端產品的主要架構還是B/S架構;但是在移動互聯網時代,終端產品的主要類型是App,而App是一個完整的Client/Cloud架構。在移動端,實現界面和功能,在云端提供數據和服務。頁面布局是存放在移動端的,功能實現也是在移動端完成,所以用戶在使用時可以感受到App的啟動、頁面渲染和布局展示是很快響應的。
速度、交互和體驗:這3個問題是用HTML5技術直接開發App的最大挑戰。其實,如果使用HTML5技術實現一個界面,渲染之后顯示出來,用戶看到這個界面時并不能立刻分辨出它是用HTML5實現的還是用Native技術實現的。但是當用戶做一個交互,點擊一下,體驗一下響應速度或者做一個手勢,觸發一個動畫,這時用戶就可以非常清楚地感受到,并能分辨出該界面是用Native技術開發的還是用HTML5開發的。所以速度、交互和體驗也是使用HTML5技術開發App必須去解決的問題。
持續性、靜態標準與動態標準:HTML5的定稿花了7年時間,并且整個標準的迭代是緩慢的;而Android和iOS每一次版本更新都會新增很多功能,這些新增的恰恰都是當前行業里最需要的功能,但這些功能很難快速通過制定新的HTML5標準進行更新,并在各個瀏覽器里支持起來。那會是一個非常漫長的過程。
擴展性:在開發一款App的時候,開發人員需要擴展很多的功能,有時候要和行業特點結合,有時候還要跟硬件結合,這就會用到大量國內的開放服務,如推送、直播、智能識別等。所有的這些功能,標準的HTML5規范中都沒有定義,所有的標準瀏覽器引擎也沒有默認支持。
總的來說,APICloud擴展的所有功能都是標準HTML5所沒有的,如果HTML5有并且在App中運行起來沒有任何問題,APICloud平臺也沒有必要去做這個擴展。APICloud所有擴展的功能其實就是為了去解決HTML5在兼容性、實用性、持續性和擴展性等方面的問題。