轉載本文需註明出處：微信公衆號EAWorld，違者必究。android
目錄：web
1、移動跨平臺已成爲必然數據庫
2、驅動原生是移動跨平臺的最佳選擇編程
3、以工程化的形式解決移動跨平臺問題小程序
4、普元在企業移動跨平臺上的優秀實踐微信
5、總結與展望網絡
1、移動跨平臺已成爲必然架構
隨着移動更加快速的發展，移動IT建設已是企業不可迴避的事情；在這過程當中必然會面對如何快速的、低成本的開發出多平臺使用的APP這樣一個問題，因此首先咱們就來講說是什麼因素讓移動跨平臺開發成爲大多數企業移動建設的一種首選。框架
咱們一直在說移動跨平臺，那跨平臺到底應該是個什麼樣子？開發一套代碼能打出多平臺運行的安裝包就算是移動跨平臺了嗎？那其實我的以爲不該當只是這麼簡單，它不只僅是指能開發跨平臺運行的APP，還應包含以下內容：微服務
擁有集成的跨平臺開發工具
同一套APP代碼可以跨平臺運行（業務代碼）
能作到多屏適配
具備跨平臺的消息推送能力
具備統一的跨平臺開發調試能力
瞭解了跨平臺的大體內容，那爲何咱們要作移動跨平臺？雖說移動終端用戶量、活躍量巨大而且仍在每一年遞增導致企業IT建設須要向移動化轉型，這難道就意味着移動建設必定要跨平臺？這個問題其實不太容易從正面回答，咱們能夠換個角度來想：若是不跨平臺、對開發人員來講可能就意味着既要編寫android代碼又得會iOS，得忍受低下的調試效率，還得處理不一樣機型的樣式、兼容性等問題；對企業而言若是不跨平臺而又要保證應用按時上線則可能須要投入更多的人力成本（人員數量、人員質量）參與開發。（企業更但願的是但願下降成本、擴大收益）。
另外正面來看經過移動跨平臺能給企業和開發人員帶來了以下利好：
下降企業成本投入
提供統一穩定的接入平臺
提供統一的版本管理，一套業務代碼能多平臺運行
鑑於這些，咱們是須要進行移動跨平臺建設的。
2、驅動原生是移動跨平臺的最佳選擇
既然須要移動跨平臺，那應該如何建設呢？首先須要明確的是有哪些技術手段能支撐移動跨平臺的實現，而後再考慮如何優化解決跨平臺過程當中的問題。
在技術支撐手段的選擇上，固然這裏你們看到標題已經知道了，那爲何說驅動原生是當下移動跨平臺的最佳選擇呢？
移動開發從web流經歷原生到如今的跨平臺開發，其中跨平臺開發目前有兩種技術實現手段：
1）Hybrid
2）驅動原生
驅動原生做爲時下最領先的移動開發技術手段，它究竟是什麼？相比Hybrid混合開發其優點又何在？
首先驅動原生是一種運行態時，可動態的與操做系統直接交互，讓操做系統提供原生UI渲染方式的移動開發技術。相比Hybrid （eg. Cordova），驅動原生不用Webkit 作UI渲染所以在性能和體驗上更好，對網絡依賴性相對更低，同時能提供更豐富的原生能力（指紋識別、藍牙）和更方便的本地調用（數據庫存儲）；固然它也不是編譯型原生（eg. Xamarin ），編寫的代碼無需編譯成對應平臺的二進制便可運行。
咱們來看一下web、驅動原生型、原生這三種APP在性能上的對比（下圖），能夠看出驅動原生手段開發的APP在系統資源消耗上更接近原生APP，低於web形式的APP。所以在運行時驅動原生APP也就相對穩定、不會由於資源消耗太高而被操做系統關閉部分服務或者殺死。同時驅動原生開發的APP能實現多級熱更新，不只能夠上APPStore進行大版本更新也能夠只更新一個界面的內容；這樣既提高了業務響應、更新、上線的速度也從更細的粒度上讓應用變的更可控。
若是選擇了驅動原生，那該如何去搭建他的框架？實現方式可能會有多種，咱們普元選擇的是一種稱之爲JavaScript Framework for Native Mobile的實現（可簡單理解爲JS驅動原生）。在2016年，Gartner將JavaScript Frameworks for Native Mobile列入「Advantage」（優點）技術，認爲它可以支撐將來5到10年移動發展，目前該技術流派常見的只有咱們普元、阿里的Weex和Facebook的ReactNative。因此不管從性能、體驗、業務的快速響應上考慮仍是從技術先進性上考慮，驅動原生都是目前移動跨平臺建設更好的選擇。
那到底該如何判斷一個應用是否是經過操做系統渲染的呢，這裏能夠經過Android手機上【設置】-【開發者選項】-【顯示佈局邊界】這個功能來查看；若是一個界面上，被Android劃出邊框來，就是原生渲染（固然這有兩種方式實現，一種是原生語言開發的，一種是驅動原生的方式）。若是明明是個Button，卻沒有被識別出來（如上圖的右側），那就是Webkit作渲染,好比Hybrid型APP。經過研究你會發現：天貓、淘寶、京東等APP的主要操做的界面已經採用原生渲染了，而不是使用webkit作渲染了。
而後說一個你們比價關心的：小程序究竟是不是用驅動原生作的？目前看來還不是（下圖是上週所截），它仍然是採用web方式進行渲染的，它是驅動型但不是驅動原生。不過並不妨礙咱們把他做爲先進例子來講，爲何呢？由於他引入了咱們接下來要說的重點內容：工程化。小程序封裝了本身的DSL，能夠隔離開發人員對底層技術的依賴，實現技術的可替換。那麼到底什麼是工程化？如何用工程化的思惟去實現移動跨平臺建設？
3、以工程化的形式解決移動跨平臺問題
工程化通俗的理解你們能夠認爲是拿平臺建設的思路去解決問題，即：不僅僅以完成一個項目的開發爲目標而是但願經過平臺框架將某一能力開放給開發者。在移動跨平臺工程化過程當中須要考慮的幾點是：
1）用什麼技術手段實現跨平臺（前文已經介紹，驅動原生）
2）如何方便開發人員實現快速調試
3）如何處理應用更新作到業務快速響應、上線
4）如何作到技術的可替換
只有工程化的去解決這些考量點才能真正的下降成本投入；從這些考量點入手也就引出了移動跨平臺建設所須要解決的問題：
正如上圖所見是我列出的我的以爲移動跨平臺面臨的問題，爲此工程化的移動跨平臺應當具有（我的拙見）：
專業跨平臺運行引擎（技術、性能考量）
跨平臺的IDE開發工具
跨平臺調試引擎
穩定、完備的服務接入層
統一的企業級應用管控商店
因此工程化的移動跨平臺應當能爲移動化提供從開發、調試、測試、部署、到上線的全生命週期管控與支持而非只針對一個項目或者一個開發過程而言。
那何爲專業的跨平臺引擎？我覺的不是僅僅的把驅動原生技術拿來用就好了，還應當考慮技術的可替換性、下降技術學習成本等問題，這一點就回到了前文所說：小程序是值得咱們借鑑，他封裝本身的DSL實現技術的可替換，以類web語法和基礎js作開發下降了學習成本。
從上圖的結構分析能夠看出，封裝DSL不只下降開發人員對底層技術的依賴還能在更先進技術誕生後作到替換（紅色框），提升業務代碼的可重用度。
另外移動跨平臺還需在引擎和工具層提供用戶可擴展編程接口能力，對企業而言這有利於迭代集聚代碼，縮短之後應用的開發週期。
在工程化解決提高開發效率的問題上，普元移動平臺和小程序同樣採用類web的開發語法並提供多屏快速調試能力，使得開發人員能夠將更多精力專一於業務開發上。
在移動跨平臺的後臺處理上，爲了不移動化給原有PC端的IT系統帶來較大的入侵；應當建設下圖紅框的集成接入平臺，經過集成平臺能夠對外提供統一的消息推送、文檔轉換服務而不是在原有的每一個系統中都加入消息推送、文檔轉換的能力（豎井架構）。
最後在工程化面對應用版本管控上，建設適合企業的應用商店是比較行之有效的手段。經過企業應用商店對微應用（組件模塊）、H5應用、原生應用提供統一的發佈、更新途徑來解決多級應用版本管理的問題。
能夠看出企業移動跨平臺在工程化的過程當中並非那麼簡單，也包含了至關多的建設內容。接下來和你們分享普元在企業移動平臺實踐上的一些可借鑑經驗。
4、普元在企業移動跨平臺上的優秀實踐
經驗1：【大平臺+微應用】組合
經過大平臺能讓企業各部門之間有統一的協同辦公、交流平臺；而微應用（加上權限管控）又能保證各條業務線或部門擁有自身的獨立性、開發自身特點的業務。這中模式既方便了對下設部門的業務管理也能提高企業的精細化運營。
經驗2：【企業級應用商店+多級應用發佈】
建設企業級應用商店能夠幫助企業管理多供應商開發APP發佈的混亂局面，經過提供統一的更新、發佈渠道並結合組織機構權限實現對的人看對的應用的目標。多級應用發佈則能夠保證業務測試到上線的平穩過渡，「讓一部分人先用起來」既能知足小部分的急需也避免了測試覆蓋不全致使上線後大面積癱瘓的尷尬。
5、總結與展望
說在最後：普元移動一直致力於以工程化的思惟來解決企業關注的諸多跨平臺問題並有着豐富的實踐經驗。
關於做者：
黃家偉
現任普元移動團隊高級研發工程師
在移動安卓開發、微信接入開發、IDE開發領域有比較深的看法。曾參與過移動平臺7.1微信構件、實時聯調功能的研發。
關於EAWorld
微服務，DevOps，元數據，企業架構原創技術分享，EAii（Enterprise Architecture Innovation Institute）企業架構創新研究院旗下官方微信公衆號。
微信號：eaworld，長按二維碼關注
8月-9月，PWorld系列技術趴還將繼續上演。目前，8月27日將在北京舉行PWorld MeetUP「微服務&DevOps專場」已啓動報名，戳「閱讀原文」可直達報名頁面，並瞭解更多詳情~
本文分享自微信公衆號 - EAWorld（eaworld）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。