混合模式為什麼成為佔有率最高的app開發技術

標籤：概念   and   原型   獨立   驗證   編碼   環境   一點   app開發   

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

目前，在各大銀行、保險公司、菸草、電力、航空、鐵路、家電製造、食品、零售等行業的領軍型公司中，都大量的使用混合開發模式來開發和管理自己的app。那麼也許很多人不禁要問“為什麼這些公司和企事業單位，都有足夠的預算和開發資源，非要偏偏選擇混合模式app開發技術來作為企業互連網化的支撐？”，而在行業大部分人印象中，混合開發技術和原生開發技術比，從使用者體驗和產品能力還是有差距的。

 

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

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

 

 第一、數字化推進速度的需求

“試錯”這個互連網名詞不但在互連網公司中蔓延，在傳統公司互連網化過程中也被廣為接納。

 

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

 

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

 

 第二、業務靈活性的需求

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

 

但是在移動時代，使用者對版本的概念變得極其敏感。而CIO對於app的版本管理也變成了頭痛的問題。往往礙於軟體開發商能力的制約，或者說凡事工程性的問題就都會存在bug，讓一些發布出去的app變得難用甚至崩潰。或者一些臨時的行銷活動、很少的但是重要的功能、一些不在規劃內的產品需求調整，都會直接引出同一個問題”使用者必須更新一個版本甚至重新下載，才能滿足上述需求“。這種看似日常的版本發布和使用者的更新，恰恰是傳統公司資訊化過程中全新的課題。

 

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

 

企業業務靈活性的要求，其實本質是希望像”小程式一樣，隨時發布一些新的功能，隨時動態增改一些功能入口，讓使用者隨意使用。但是使用者的體驗，則要與真正的app一樣“。這種業務靈活性的需求，其實需要的便是像小程式或類似APICloud提供的混合app開發技術來支撐，從而達成”累加式更新“、”靜默更新“”開啟獲得新功能和新體驗“，而不是嵌套Webview，網頁類比app的方法，以垃圾體驗的代價換取業務靈活的可行性。

 

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

 

第三、集中管理的需求

業務部門的互連網化意識經過移動互連網的普及，被廣泛帶動起來。所以傳統的IT主導公司資訊化的發展勢態發生了微妙的變化，以前IT部門發起幾乎所有的資訊化需求，但是現在的IT部門越來越像”服務部門“。因為業務團隊在不停的發起各種各樣”業務+互連網“的資訊化需求。這個時候，很多傳統企業IT的領導，沒認識到自己角色的轉變，如果還一味的”拖延“、”不管不問“、”你們自己搞定“這樣的官僚做法，就會導致今天很多企業的資訊化出現“各種移動app徹底片段化”，各個業務部門自己找軟體開發商實現自己的需求的局面。這不但架空了IT部門的資訊化主導地位，更麻煩的是讓後續的集中管理變得艱難無比。幾十家甚至上百家的不同標準的服務摻雜在企業的核心系統中，甚至業務部門為了快速滿足自己的需求部分脫離了IT主導的傳統PC核心系統。這是非常危險的訊號。

如果IT部門要管理業務部門如何滿足業務的互連網化需求，往往發現心有餘而力不足，IT部門人手有限，沒辦法一一滿足所有業務部門的移動化的需求。如果不管，就會產生前面所提到的“技術棧、開發商”片段化的問題。這個時候基於混合模式app開發技術的行動裝置 App平台，又很好的解決了這兩者的矛盾。

 

“定標準”從而實現“集中管理”，企業以一套統一的混合模式app開發技術和移動平台為標準，各個業務部門可以獨立尋找自己的軟體開發商，比如很多大企業的IT資訊化組成中，便會通過APICloud這樣的企業服務平台，來滿足自身的移動業務建設，這樣在技術選型以及企業移動化的需求中都得到了滿足。而盡量給予同一平台帶來了標準化的統一，但這裡麵包括了“技術標準化”、“開發流程標準化”、“代碼管理標準化”、“專案管理標準化”、“驗收標準化”、“管理和運營標準化”等多個標準化制度。

 

第四、資訊化安全的需求

伴隨企業互連網化的最根本的轉化就是，從內網的資訊化變成外網的互連網化；傳統資訊化包括內網、固定場所、固定網路環境、固定的裝置，而移動戰略背景下的企業互連網化，則是外網會隨時隨地通過員工自己的裝置接入。這些不起眼的變化，給企業CIO帶來的卻是天翻地覆的調整。

 

最開始，時興了一段的MDM（mobile devices management）行動裝置管理軟體，但是凡是買了MDM的企業幾乎無一例外發現很難推進，因為MDM伴隨著BYOD（bring your own device）員工內建裝置。如果用企業的管理軟體來管理員工自己的裝置，沒有人會支援這種提議。所以大部分的MDM最終草草收場，只是管理了企業自己購買的一些行動裝置。

那麼企業移動化、互連網化的安全怎麼保障？這要滿足三個層面的安全——裝置安全、傳統安全和雲端安全。

 

混合模式app可以實作類別似於公司專屬應用程式商店（公眾號）這種動態許可權綁定和授權的模式，能夠支援在特定的裝置、特定的人之間選擇不同的子應用。並且可以隨著這個使用者工作內容的調整，動態根據裝置編碼、使用者權限即時分配全新的子應用。

 

這種基於企業行動裝置 App商店的“子應用”模式，也是混合模式app開發技術成為企業移動戰略支撐的關鍵。因此出色的公司專屬應用程式商店，能夠發揮傳統原生模式開發的app所不能賦予企業的各種安全性需求與滿足，同時也實現了業務靈活性的管理目的。

混合模式為什麼成為佔有率最高的app開發技術