本文轉自微信號EAWorld。掃描下方二維碼，關注成功後，回覆“普元方法+”，將會獲得熱門課堂免費學習機會！
其實文章的題目糾結了很久，最後還是採用了“生態型App”這個詞，這個詞可能不是一個約定俗成的詞，但卻是這篇文章的主線，我將會從以下面三個維度展開，期望能夠給正在從事相應工作的移動架構師以啓發，也歡迎大家一起探討。
本文目錄：
一、什麼是生態型App
二、生態型App的特點
三、生態型App對架構的挑戰與實踐
一、什麼是生態型App
什麼是生態型App？正如開題說的，這個詞我糾結了很久，但是我還是以生態型App來作爲題目的關鍵詞，那就有義務稍微解釋一下這個詞。衆所周知，在移動互聯發展到這個階段，一個新的App推廣起來越來越難。用戶大量的時間都會聚焦微信、支付寶等這些超級App，我稱其爲生態型App。
生態型App一般提供了一共生的生存環境（運行環境）以及相同的約束（規範和API等），允許不同的團隊或個人，在允許的情況下，自行的研發或相同或者不同的移動相關的功能。相關功能運行在一個進程裏，相互間獨立，且與同在的環境有一定的交互。
生態型App區別與傳統的App，除自身提供的功能外（比如微信的IM功能），更多的功能可以由三方的團隊自行完成。除了ToC的超級應用外，也特別適合多團隊、跨地域、多供應商的大中型企業使用。
二、生態型App的特點
區別於傳統的App，生態型App具備以下的特點：
第一、開發的獨立性。
這是生態型App的基礎，開發的獨立性，確保了多個團隊能夠並行開發，並且無需互相依賴，其應用的功能又與生態型App本身獨立，確保了其功能的自由成長。
開發期的獨立型，並不代表沒有約束，恰恰相反，爲了能夠讓生態型App有健康的發展，相同的約束是必須的。正如我們都相對熟悉的微信，在開發公衆號相關的功能時，我們要遵守微信的相關的API的規範。甚至針對現在狂推的微信小程序，我們還必須採用其特有的開發工具，遵守其特有的DSL語言進行開發。
總結來說，開發的獨立性，並不是說技術上的隨意性，不受約束，而是說，從團隊、時間、功能上等角度的獨立性。看似簡單的一個特點，實際上，並不簡單，一個簡單的考量就是，多少App增加一個功能時，都必須調整代碼重新打包，上線。
第二、運行態的共生性。
運行態的共生性是生態型App的重要屬性。從開發的獨立性角度看，這個是現在任何手機操作系統都具備的特點。實際上，共生性是指任何功能的加入都與原有的生態中的功能在同一個運行態中，簡單說是在一個進程或者一組相關進程內。
因爲共生，所以新增的功能才能使用到生態型App帶來的諸多益處，同時可以讓生態型App得到更多新增功能帶來的附贈價值，比如用戶的使用信息等。
如果不考慮共生性，開發期的獨立性完全可以考慮以獨立的App爲單元進行業務功能的開發，實際上真毫無裨益，越來越多的人並不願意讓自己的手機中安裝更多的App，這也是大量用戶在近年來在手機中沒有安裝新的應用的重要原因。
這裏插一句話，我本人暫時（或許將來會改變）並不看好PWA的發展的一個重要原因也在於此，難道用戶不願意安裝新的App真的是簡單的因爲安裝包大，安裝緩慢嗎？
這一點，真對企業用戶來講，尤爲明顯，沒有多少員工真心願意在自己的手機上安裝幾十個爲了企業內工作需要的App的。
第三、業務的隔離性。
業務的隔離性是生態型App是否能夠健康運轉的基礎。這裏需要重要考慮的兩個因素是，業務的相關資源需要單獨規劃，避免業務之間的干擾；同時，避免新增的業務代碼導致整個生態型App的不穩定。
第四、與生態型App的交互性。
三方的功能需要能夠以與整個生態型App進行雙向的交互。提供雙向的交互，包括App的信息能夠傳遞到相關三方的功能，以及相關的三方功能的業務能夠聚合到App內，前者最常見的是鑑權信息（比如微信的授權登陸），後者在微信裏是以消息的方式可以提供。
三、生態型App對架構的挑戰與實踐
生態型App因其自身的特點，導致相對於一般的App對於架構角度的挑戰會更多，針對其特點，相應的架構層面也需要提供一定的支持。
通常有以下三種方式做到類似的方式：
1、每一個三方功能都是一個App。
這意味着每個功能需要開發出針對的iOS、Andriod操作系統的應用，父應用以應用跳轉的方式打開三方應用。早幾年的所謂移動門戶（portal）大多采用這類技術，優點是技術簡單。缺點是，父應用與三方應用之間就是兩個獨立的應用，無法真正的共享生態，跳轉後，基本上就離開了父應用，在互聯網應用中較少出現。
2、每一個三方功能，都是以Web的方式存在。
這種方式很好的解決了跨平臺的問題，也很好的避免了跳出父應用的問題。其主要解決思路是每一個三方應用都是一個Web站，父應用中通過嵌入Webkit，以打開URL的方式進入。爲了解決Web站點與父應用的交互以及本地能力的限制，基本上都會提供擴展後的Webkit內核以及相關的JS SDK。在微信小程序沒有出現之前，微信是通過這個方式提供三方服務的。
這種方式存在一些硬傷，比如，每次打開一個三方功能，幾乎都會有幾秒的短暫白屏，主要原因是每次都要獲取HTML的前端代碼並展現。另外也難以做一些離線式的業務、難以確保業務的良好體驗。比如說，我正在使用某個三方功能，錄入到一半，突然有人微信我一條消息，一般要回到父應用查看一下，之後就得必須重新從頭錄入。
這也就是意味着，實際上，真正的複雜連續性的業務很難採用這種方案得到良好的用戶體驗。
3、每一個三方功能，都是一個微應用（或者是小程序）
區別於第二種，這種方案的UI除第一次訪問的情況下，是可以完全本地化，所以能很好的解決第二種方案的問題，真正達到原生的體驗。
實際上，這也帶來了架構上的挑戰，三方應用的生命週期必須自行管理，包括三方應用的加載、運行、銷燬等一系列動作，甚至更新。微信的小程序就是採用了這個方案，而針對企業應用，還需要關注其針對這個三方應用的權限問題。
這裏有兩個大需要考慮的因素：
（一）微應用的呈現及微應用的更新
（二）微應用獨立加載、銷燬等運行期生命週期的管理
上圖是微應用的呈現及微應用的更新的示意圖，在結合了權限後，會引入了新的挑戰，微應用的呈現過程中需要與服務端進行確認。具體流程如上，就不一一展開描述了，需要說的一點是，前端的架構中，必須針對微應用的本地庫（App內）具備相關的管理功能，我們的經驗是單獨規劃出微應用的資源空間，並且約定好微應用的規格。
另外一點，微應用的運行期生命週期的管理，需要前端結合自身的技術進行支持和實現，如果採用傳統的Web方式是可以交由Webkit進行處理。
這裏需要補充說明的是，如果直接使用React Native 期望達到上述的功能及效果，建議先解決多Bundle的問題。
當然在這個方案中可以提供多種應用類型的支持，兼容第二種以Web集成的方案，下面是以集成M站天貓爲例。
上述的架構考慮主要還是圍繞在父應用與三方功能交互的訴求，基本上能夠做到如下圖的效果
同時，我們還需要讓父應用與三方功能聯動起來，讓三方功能的數據聚合到父應用裏。
如上圖中，流程管控、公文系統的信息都聚合在一起，結合之前圖中提到的“傳遞參數及上下文”，點擊任何一條信息都會準確的跳轉到相關的微應用中進行處理。
這裏的數據聚合可以根據業務特點採用推的方式或者拉的方式，上圖的例子因其特點，採用拉的方式進行。實際上，在非聊天式的場景裏，絕大多數都採用拉的方式。
說到這裏，現在的新的App端呈現無論是在主頁上、還是在類聊天窗口中，都已經趨向於多樓層、多交互的模式，如下圖：
這就意味着，我們需要增加樓層的框架支持、UI模版的支持。
從架構上看，多UI模版的支持與微應用的支持有諸多相似之處，前端也同樣需要管理對應的模版庫，這裏就不增加圖說明其原理了。
那讓我們來回顧一下，看一張圖，前端爲了支撐生態型App的一個基礎架構都包括哪些？
這裏大致包括了五部分，每一部分都各司其職。
1、最下層是一個基礎服務層，包括UI渲染引擎、文件服務、數據庫訪問服務、本地能力等等基礎功能，是支撐一個App正常開發的功能，可以理解爲即使不是生態型App也需要具備的功能。
2、下數第二層，我們將App內分層了三個區域，其中有兩個區域是微應用或者三方無法直接訪問的區域，這些區域包括業務代碼區和緩存目錄區。其中、業務代碼區應用存放可以直接運行的程序代碼，與此區域交互的主要是相關的管理服務、生命週期服務和各個中心。緩存目錄區，是用於支撐整個生態型App的一些資源的，比如我們下載微應用的安裝的包、增量的更新包等等。
三方的服務實際上可以操作的數據是業務數據區，這個區域會根據MicroAppID去創建一個獨立隔離的區域，三方的服務操作也是隻能這個區域。
3、三中心（右中）。包括個性化中心、註冊中心、資源中心，這三個中心一般不會直接暴露服務，也不允許三方直接訪問，而是通過其左側的服務提供，比如微服務管理服務等。個性化中心，主要是記錄與當前手機或者當前用戶的信息，比如說當前用戶某個三方微應用顯示的位置、Icon等一些信息，當然這個可以根據權限進行控制。註冊中心是針對三方服務的註冊，其中包括類型（MicroApp、HTML5、UI模版等等）、ID、下載URL、本地運行版本號、本地上個版本號等等信息。而資源中心，可以存放每個三方應用下載後當前和之前的版本等相關資源。
4、在右上部分，是用於針對不同類型的三方應用的生命週期管理的功能，比如點擊了一個MicroApp後，他需要Load這個微應用，跳轉到指定Page、退出這個微應用後的內存銷燬等一系列的工作都在這裏進行。
5、左上是一些生態型App提供的一些特有的服務，其與最底層的服務一起構成了三方服務能夠使用的全集。
這裏需要提到的一點，對於三方功能，我們不允許存在直接的依賴，而重點要考慮的是儘可能的隔離，避免之間互相的干擾，所以可以看到實際上很多功能不直接對三方服務提供。對於一些可能需要進行一些傳遞的數據或者公用的信息，我們提供了“上下文服務”的功能，三方服務在前端可以通過這種方式共享，當然也可以通過服務器端進行傳遞。
對於UI模版的很多支持技術維度很多的工作都與MicroApp有很多相似之處，但還是有一些區別，我再囉嗦兩句。
1、數據驅動的UI呈現
通常一般的情況下，真實的業務需要傳遞“二號會議室預定成功，會議時間…..”。
實際上，這條信息的傳遞到前端，並以上圖的方式呈現，大概還會包括一下的信息：
用於顯示着一條信息的UI模版ID，上圖是用了帶按鈕的列表。
而這個模版需要的數據包括：
Title Icon、Title DisplayName、Title Info
顯示數據（含期望的樣式）
Button Label[]、Button Event[]
所以，這部分的聚合的數據是採用了統一中臺的方式，在中臺構造帶顯示信息的數據。
2、UI模版的動態獲取
UI模版本質是一種代碼片段，體積上遠比三方應用的體積小，三方應用（比如MicroApp）默認採用的是使用前下載的方式，在使用過程中也會以顯性方式下載爲主，打開MicroApp，在進行傳遞數據。
UI模版的使用是採用的方式是在數據傳遞後，如本地無對應的模版，再向服務器獲取UI模版。簡單說，帶顯示信息的數據傳遞過來後，根據UI模版的ID向註冊中心查詢，如果註冊中心確認本地存在對應的UI模版，直接顯示；如果不存在UI模版管理模塊向服務端發起請求獲取UI模版並註冊到註冊中心，然後進行顯示。
這種加載機制是因爲UI模版是一個羽量化，方便進行快速獲取。
UI模版是一個變化性和數據都有限的，本地命中概率較高。
生態型App是對於絕大多數移動開發者是一個新的事物，可能有很多地方通過文章不一定能講清楚，歡迎加作者微信探討相關技術。
關於作者：
郝振明
普元移動產品線總負責人，十多年 IT 從業經驗，一直專注於企業信息化的工作，近五年間一直從事企業移動信息化、移動互聯網化的諮詢、產品工作，曾主持參與了 Primeton Mobile 產品研發、聯通集團、廣東農信、諾亞財富、中信重工、索菲亞等公司的移動信息化工作。近兩年來，致力於基於 React Native 工程化能力的提升、降低實施難度，以及智能化移動平臺的產品研發，在移動開發智能化的路上不斷進行探索。
關於EAWorld
微服務，DevOps，元數據，企業架構原創技術分享，EAii（Enterprise Architecture Innovation Institute）企業架構創新研究院旗下官方微信公衆號。
掃描下方二維碼，關注成功後，回覆“普元方法+”，將會獲得熱門課堂免費學習機會！
微信號：EAWorld，長按二維碼關注。
