混合模式爲何成爲佔有率最高的app開發技術

在企業移動戰略佈局中，app已成爲鏈接業務與用戶最主要的載體，一樣其開發技術目前也處於十分紅熟的階段，而從技術實現的角度去考量，不少從業者可能並不知道，越是大企業、越是IT預算多的企業，他們的移動app大部分是基於混合開發模式實現的，尤爲對於混合app技術開發的B2B、B2C和B2E類型的移動應用，佔比甚至要遠超市場的預期和想象。

目前，在各大銀行、保險公司、菸草、電力、航空、鐵路、家電製造、食品、零售等行業的領軍型公司中，都大量的使用混合開發模式來開發和管理本身的app。那麼也許不少人不由要問「爲何這些公司和企事業單位，都有足夠的預算和開發資源，非要恰恰選擇混合模式app開發技術來做爲企業互聯網化的支撐？」，而在行業大部分人印象中，混合開發技術和原生開發技術比，從用戶體驗和產品能力仍是有差距的。

針對這個行業疑惑的問題，APICloud 創始人兼CEO劉鑫深刻淺出地對行業這一突出現象進行了分析，而答案正是與企業的互聯網化以及數字化的需求有着最直接的聯繫，這也反映出劉鑫當初創辦APICloud平臺時，爲什麼選擇混合開發技術爲平臺用戶提供服務。

本文將經過劉鑫先生四個方面的分析，解釋諸多企業爲什麼選擇混合模式app開發技術，同時結論也揭示了混合app模式對不一樣行業解決方案的根本優點以及企業選擇的必要性。

第1、數字化推動速度的需求

「試錯」這個互聯網名詞不但在互聯網公司中蔓延，在傳統公司互聯網化過程當中也被廣爲接納。

愈來愈多的CIO在談及各自企業移動戰略的時候，都會提到「能不能讓咱們業務部門的一個想法，先在一週以內作個原型，快速實現，丟出去測試下用戶反饋，而後基於這個原型再來改」。這種快速發起、快速驗證、快速調整的方法，已經成爲廣爲流行的方法。之因此要在短期內，先把業務從想法變爲現實，哪怕是粗糙一點也要實現出來，根源在於業務的創新想法可能沒有先例可循，而且具備明確的企業個性，單純的憑空想象很難想的很是完整。與其花三五個月的精細打磨弄清楚業務需求，還不如花一兩個星期先把基礎的想法落實。哪怕這麼短期作出來的東西並不能真正知足業務的需求，可是可讓業務的想法在這個過程當中變得「有據可依」「有的放矢」，從而實現更完整以及更切實可行的業務方案。

「業務部門的一個想法，IT一兩週就能作出來了」這對於企業的信息化負責人而言，也是很重要的一個褒獎。而這種速度的需求，偏偏是APICloud平臺的混合開發技術最明顯的優點，一套代碼同步生成iOS與Android兩個平臺的app，甚至可以部分兼容微信公衆號和小程序。這一套代碼，不表明偷懶以及工程技術的簡化，而更多的是由於節省的不只僅是代碼編寫的時間，更重要的是節省了多個技術團隊之間跨知識結構協同的問題，再也不須要iOS與Android工程師開會討論實現的差別性問題，更是大幅節省了app與服務器端聯調聯試的時間成本。因此，若是一樣的功能，一樣從0開始，使用傳統的原生開發技術根本沒法完成一兩個星期內實現有價值的業務需求落地，這個過程若使用原生技術可能連不一樣終端碎片化和差別化問題都沒有解決。爲了知足CIO對於業務發展和數字化效率的要求，在移動戰略中每每都會規劃使用跨平臺的混合模式app開發做爲移動戰略的支撐基礎。

第2、業務靈活性的需求

在PC時代的B/S架構中，想要實現IT系統的更新並不須要過多考慮用戶端的影響。由於做爲用戶入口的瀏覽器，一直處於訪問網絡的狀態，只要網絡聯通，用戶隨時訪問網站都會得到最新的功能和業務。對用戶而言，並不真正存在版本的概念。只要訪問服務器，服務器的任何更新均可以隨時展現到用戶界面上，真要出現什麼用戶的使用問題，大不了」清空一次瀏覽器cookie「基本均可以獲得解決。

可是在移動時代，用戶對版本的概念變得極其敏感。而CIO對於app的版本管理也變成了頭痛的問題。每每礙於軟件開發商能力的制約，或者說凡事工程性的問題就都會存在bug，讓一些發佈出去的app變得難用甚至崩潰。或者一些臨時的市場活動、不多的可是重要的功能、一些不在規劃內的產品需求調整，都會直接引出同一個問題」用戶必須更新一個版本甚至從新下載，才能知足上述需求「。這種看似平常的版本發佈和用戶的更新，偏偏是傳統企業信息化過程當中全新的課題。

」能不能像傳統瀏覽器那樣，用戶打開永遠是最新的服務和功能？「不少企業CIO問出了相同的問題，因而大量三流的軟件服務商以及IT程序員想出來一個」偷懶「的模式。在app中嵌入一些WebView，把一些功能用傳統網頁的模式，訪問服務器，動態獲取。這表面上解決了版本更新的問題，實則上大量垃圾體驗的app就此產生。

企業業務靈活性的要求，其實本質是但願像」微信小程序同樣，隨時發佈一些新的功能，隨時動態增改一些功能入口，讓用戶隨意使用。可是用戶的體驗，則要與真正的app同樣「。這種業務靈活性的需求，其實須要的即是像微信小程序或相似APICloud提供的混合app開發技術來支撐，從而達成」增量更新「、」靜默更新「」打開得到新功能和新體驗「，而不是嵌套Webview，網頁模擬app的方法，以垃圾體驗的代價換取業務靈活的可行性。

固然，傳統模式開發的app，特別是Android端也開始部分支持動態更新，這也偏偏說明，業務靈活性是企業互聯網化、數字化過程當中的剛需。只是礙於傳統技術的制約以及軟件開發團隊或者服務商的能力所限，真正的原生動態更新始終沒有辦法大範圍進入企業實現商用。這也讓企業開始選擇混合開發的模式來支撐移動戰略，逐漸成爲CIO的主流選項。

第3、集中管理的需求

業務部門的互聯網化意識通過移動互聯網的普及，被普遍帶動起來。因此傳統的IT主導企業信息化的發展勢態發生了微妙的變化，之前IT部門發起幾乎全部的信息化需求，可是如今的IT部門愈來愈像」服務部門「。由於業務團隊在不停的發起各類各樣」業務+互聯網「的信息化需求。這個時候，不少傳統企業IT的領導，沒認識到本身角色的轉變，若是還一味的」拖延「、」無論不問「、」大家本身搞定「這樣的官僚作法，就會致使今天不少企業的信息化出現「各類移動app完全碎片化」，各個業務部門本身找軟件開發商實現本身的需求的局面。這不但架空了IT部門的信息化主導地位，更麻煩的是讓後續的集中管理變得艱難無比。幾十家甚至上百家的不一樣標準的服務摻雜在企業的核心繫統中，甚至業務部門爲了快速知足本身的需求部分脫離了IT主導的傳統PC核心系統。這是很是危險的信號。

若是IT部門要管理業務部門如何知足業務的互聯網化需求，每每發現愛莫能助，IT部門人手有限，沒辦法一一知足全部業務部門的移動化的需求。若是無論，就會產生前面所提到的「技術棧、開發商」碎片化的問題。這個時候基於混合模式app開發技術的移動應用平臺，又很好的解決了這二者的矛盾。

「定標準」從而實現「集中管理」，企業以一套統一的混合模式app開發技術和移動平臺爲標準，各個業務部門能夠獨立尋找本身的軟件開發商，好比不少大企業的IT信息化組成中，便會經過APICloud這樣的企業服務平臺，來知足自身的移動業務建設，這樣在技術選型以及企業移動化的需求中都獲得了知足。而儘可能給予同一平臺帶來了標準化的統一，但這裏麪包括了「技術標準化」、「開發流程標準化」、「代碼管理標準化」、「項目管理標準化」、「驗收標準化」、「管理和運營標準化」等多個標準化制度。

第4、信息化安全的需求

伴隨企業互聯網化的最根本的轉化就是，從內網的信息化變成外網的互聯網化；傳統信息化包括內網、固定場所、固定網絡環境、固定的設備，而移動戰略背景下的企業互聯網化，則是外網會隨時隨地經過員工本身的設備接入。這些不起眼的變化，給企業CIO帶來的倒是天翻地覆的調整。

最開始，時興了一段的MDM（mobile devices management）移動設備管理軟件，可是凡是買了MDM的企業幾乎無一例外發現很難推動，由於MDM伴隨着BYOD（bring your own device）員工自帶設備。若是用企業的管理軟件來管理員工本身的設備，沒有人會支持這種提議。因此大部分的MDM最終草草收場，只是管理了企業本身購買的一些移動設備。

那麼企業移動化、互聯網化的安全怎麼保障？這要知足三個層面的安全——設備安全、傳統安全和雲端安全。

混合模式app能夠實現相似於企業應用商店（微信公衆號）這種動態權限綁定和受權的模式，可以支持在特定的設備、特定的人之間選擇不一樣的子應用。而且能夠隨着這個用戶工做內容的調整，動態的根據設備編碼、用戶權限實時分配全新的子應用。

這種基於企業移動應用商店的「子應用」模式，也是混合模式app開發技術成爲企業移動戰略支撐的關鍵。所以出色的企業應用商店，可以發揮傳統原生模式開發的app所不能賦予企業的各類安全性需求與知足，同時也實現了業務靈活性的管理目的。