轉載本文需註明出處：微信公衆號EAWorld，違者必究。
引言：
隨着移動信息化的發展，近年來很多大型企業建設了許多C端App。用戶在同一家企業辦理不同的業務需要下載多個App，越來越不方便，建設統一的企業官方App已是一種必然趨勢。
建設官方App過程中會面臨諸多挑戰，選擇什麼技術？如何快速整合，保障原有業務正常運轉？RN如何支持多團隊多應用協作開發？……本文將會爲大家逐一解答。
目錄：
一、大型企業C端業務移動化挑戰分析
二、基於RN+微應用打造多業務支撐的企業官方App
三、某保險公司官方App案例
四、總結
1.大型企業C端業務移動化挑戰分析
隨着移動信息化的飛速發展，很多大型企業近年來建設了許多C端App，每個App都各具特色，用戶在同一家辦理不同的業務需要下載多個App，越來越不方便。
隨着市場需求和用戶需求的不斷增加，問題也逐漸顯露出來，主要體現在以下四個方面：
一、用戶體驗差
大型企業裏不同C端業務大都是由不同的團隊開發，所使用的技術以及頁面風格都不相同，有的使用原生開發，體驗較好；有的使用h5，體驗較差。很難做到統一。
二、碎片化嚴重
不同的業務建設相互獨立的App,獨立分發推廣，浪費資源不說，還顯得很雜亂。對於市場和需求的變更，很難形成合力。
三、需求響應緩慢
市場需求變化非常快，越來越多的業務都在手機端處理了，以保險業務爲例，用戶辦理了壽險的業務同時引導用戶辦理財產險業務，這個時候希望可以直接辦理而不是去下載一個產險的App再去辦理。
四、用戶留存率低
App業務的單一化導致用戶需求量大大減少，用戶大多是在業務員的推廣中下載安裝了App,但App只涉及到單一業務，很難吸引用戶再次開啓去查看。
綜上，大型企業建設統一的官方App是一種必然趨勢。當然，在建設的過程中也將面臨諸多挑戰,接下來給大家分享建設官方App所面臨的三大挑戰：
挑戰一：用戶體驗與技術門檻的抉擇
隨着移動技術的的發展，智能手機的普及，越來越多的App建設把用戶體驗放在了第一位，要求界面好看，操作要流暢，簡單來說就是要像微信支付寶一樣好用。需要完成這樣的需求首要選擇是使用原生開發。原生開發無疑體驗是最好的，但同時也帶來了新的問題，操作系統的多樣性如何快速適配，業務如何快速上線，如何可以不經過Appstore的審覈即可靈活控制上線流程……
挑戰二:獨立建設的App如何整合
很多企業在移動信息化的浪潮中建立了許多App，建設統一的官方App不可能從零開始，不然原有的投入浪費不說，大型企業的業務相對複雜，如此多的業務很難在短時間內開發完成。
挑戰三:不同的團隊如何協作開發
獨立建設的App往往是有不同的團隊開發，所採用的技術語言不同，引用的第三方sdk的版本不同。相同的功能模塊選擇了不同的實現，如OCR，有的團隊使用的是前端解析，有的是後端。整合到一起後的App如何協同開發是第三大挑戰。
2.基於RN+微應用打造多業務支撐的
企業官方App
爲什麼選擇RN作爲整合技術?
選擇什麼樣的技術作爲官方App的整合技術是關鍵，既要良好的用戶體驗，又需要快速開發、易於整合。我們來看下移動端技術的演進，大致分爲如下四個階段：
1、網頁開發
相信早期做移動App還記得，Appstore剛推出來的時候，還是允許App做個殼，直接連的是後端的一個網站，目前這種App上不了Appstore，體驗實在是太差。當然本地能力也是缺失了，比如調用攝像頭。
2、原生開發
隨着智能手機的普及，原生開發興起。原生開發的體驗好，但是成本相對來講高，業務一致性相對比較低，業務上線的時候，Android和iOS都要上線纔可以。當然，對於這種方式還有個硬傷，更新應用嚴重依賴與市場和用戶是不是主動下載最新版本，推廣的難度也比較高。原生熱更方案難以落地，特別是上Appstore的應用，會直接被拒絕。
3、混合開發
是結合了網頁開發的和原生開發的優點，其大致的思路是採用HTML（或者很多人說的H5）作爲UI，通過嵌入或者系統的瀏覽器作爲渲染（通常採用Webkit），當需要本地能力的時候，採用原生語言的方式編寫，並提供接口給UI端調用。因其UI的渲染採用瀏覽器的方式，難免會影響到用戶的體驗。
4、驅動原生
對於驅動原生,這種方案的大致思路是，在運行態的時候，通過調用操作系統提供的接口，對UI進行渲染，而不是把渲染交給瀏覽器內核。無論從用戶體驗、跨平臺、性能、以及熱更方案，都得到了廣泛的認可。
綜上我們選擇的RN作爲整合官方App的主要開發語言。
選擇RN的優勢一：技術先進，用戶體驗好
RN技術的三大特性：體驗好，熱更新，原生能力。可以實現一個真正的Mobile Native App，降低了技術門檻的同時帶來了良好的用戶體驗。
但RN有一個缺陷就是開發人員開發的所有業務代碼最終都會打包成一個bundle文件：
1、隨着業務的增加，bundle文件越來越大，應用啓動和運行速度都會較慢，達不到原來預想的原生體驗。
2、對於多個開發團隊，開發的代碼耦合性太高，必須打包一起纔可以發佈，開發維護成本非常高；對於需求的響應會變的緩慢。
選擇RN的優勢二：RN多bundle模式支撐多團隊開發
針對原生的RN應用，我們團隊將其拆分成了多bundle，有效支撐多團隊並行開發：
1、將RN基礎能力和公共的一些API打包成了單獨bundle文件，隨着apk和ipa一起發佈到應用市場。
2、業務代碼拆分打包成了多個bundle文件，每個bundle文件都可以獨立發佈。
3、應用啓動的時候加載badebundle+所需要的業務bundle，做到按需加載，業務代碼再多也不用擔心首次啓動過慢問題。
選擇RN的優勢三：底層原生，易於整合多應用
很多大型企業早期對於C端業務也建設了一些App，建設統一的官方App並不是從零開始，如何有效的整合原有的應用，保障業務的正常運轉是官方App必須考慮的問題，原有的多個App都使用了三方SDK，如何處理呢？
第一步：需要梳理出公共的SDK，封裝公共API
第二步：對於一些偏向業務的原生模塊，封裝成業務API
選擇RN做爲整合語言，因爲RN底層是原生應用，易於整合現有的三方SDK和公共的API，可以很好的和其他微應用通信。
爲什麼選擇微應用模式？
微應用模式區別於傳統的App開發模式，具備以下三個特點：
第一：開發期項目獨立，這是微應用模式的基礎
開發的獨立性，確保了多個團隊能夠並行開發且無需要相互依賴，其應用的功能又可以與官方App相互獨立，確保其自身功能的自由性。當然開發期的獨立性並不意味着沒有相關的約束。爲了能讓官方App健康的發展，相同的約束是必須的。我們熟悉的微信，在開發公衆號時，需要遵守微信的相關的API規範。總結來說，開發期項目的獨立性，並不是隨意性，而是從團隊、時間、功能等角度的獨立性。
第二：業務上隔離性是官方App能夠正常運轉的基礎
這裏需要考慮兩個因素，業務的相關資源需要單獨規劃，避免業務之間相互干擾；同時需要避免新增代碼導致整個官方App的不穩定性。
第三：運行態支持動態部署
開發完成的App既可以運行在官方App中，也可以打包成單獨的App在手機上運行。開發人員不用關心開發完成的App是在微應用中運行，還是獨立的App。
選擇微應用模式的優勢一：既支持獨立開發，又能約束引用
微應用模式的好處就是獨立開發，對於使用RN結合微應用模式，RN使用的公共接口我們在basebundle里約定，可以很好的控制App的安全性和穩定性（特別是三方SDK的引用，可以有效控制，避免衝突），會有專門的團隊去維護basebundle。各業務功能的開發團隊只需要根據API文檔開發相應的業務功能即可，然後打包成微應用提供給官方App即可。
選擇微應用模式的優勢二：統一開發流程，易於整合現有業務
官方App建設不是說所有的功能都完美了再發布，而是一個快速迭代的過程。微應用模式的第二個優勢：可以制定統一的開發流程，從RN微應用的開發調試、編譯、測試、發佈更新全生命週期的管理。保障了各模塊新的業務功能能夠獨立的開發測試及發佈上線，互不影響。
3.某保險公司官方App案例
某保險公司C端App現狀
某保險公司有着千萬級別的用戶羣體，包含產險、壽險、健康險、養老、保險箱等多項業務，而這些觸點都是獨立開發維護的，所使用技術也不一樣，原生+RN+H5+混合開發，移動端的技術基本都使用了，如何有效的整合現有的App到官方App裏，是非常大的難點。
基於RN+微應用聚合官方生態App
在該客戶實施過程中，我們採用了RN+微應用的模式，整合了現有App共同打造了集團的官方App。對於原有的業務，依然由原有的開發團隊使用微應用模式開發，通過統一的編譯服務，最終整合成統一的官方App，保障了原有業務的正常使用。
統一的官方App
建設完成的統一的官方App,小夥伴們在首頁就可以看到熟悉的業務App圖標，點擊立即到達。
建設完成統一的官方App：
一、提升用戶體驗
一站式APP內體驗跨子公司的服務，統一入口，全面提升用戶體驗
二、提高用戶覆蓋數
全集團統一APP，實現各BG客戶關鍵旅程的融合，提高用戶覆蓋量達分發數80%
三、提高用戶活躍度
統一APP入口，提供多元化服務，滿足客戶多樣化業務需求，提升整體用戶活躍度
四、降低開發成本
基於同一套APP基座進行應用層面功能開發，統一管理，有效降低開發成本
4.總結
建設統一的官方App是一種必然趨勢，通過本文主要和大家分享了採用RN+微應用模式建設統一的官方App，採用RN技術有效整合原有的開發資源，帶來原生的用戶體驗；採用微應用模式，支撐了多團隊快速開發業務需求並能整合到官方App中，降低了開發維護成本。建設完整的官方App打造了一站式服務體驗，提供多元化服務，滿足客戶多樣化業務需求，提升整體用戶活躍度。
精選提問：
問1：微應用的原理是啥？
1）有沒有侵入RN jsbundle的打包，id轉化爲name之類的
2）支不支持動態的刪除和加載微應用（在不重啓的情況下）
3）RN不同版本的適配問題
4）微應用動態加載過程中能夠定位出現的問題嗎？
5）微應用的開發調試
答：微應用是應用存在的另一種模式，支持動態加載
1）我們修改的RN的js編譯流程，對rn的編譯做了優化
2）對於所有的微應用支持在不重啓的情況動態加載，刷新RN的緩存
3）對於RN的版本我們約定統一版本，所有接入微應用會統一升級
4）在開發期調試錯誤會正常顯示，運行太實用框架收集錯誤日誌
5）我們提供了微應用的調試服務和調試基座，支持動態調試
問2：rn和flutter，該怎麼選呢？
答：RN 是Facebook2015年推出的驅動原生框架，Facebook自己也在使用，各大主流的互聯網公司使用類似的技術開發App。開發期使用js，一次開發可以運行在Android和iOS兩個平臺，運行時接近原生的體驗。google自己推出的框架在自己公司的產品裏都沒有使用，建議觀望其發展而不要冒然跟進。
問3：請問微應用也是rn開發的嗎？
答：是的，大多說的微應用是使用RN開發的，也有部分微應用採用的混合模式，後續會遷移使用RN開發。
問4：APP基座主要負責提供哪些能力給微應用？
答：基座負責整個App框架的搭建，所有接入的三方能力（如微信分享、支付、OCR、活體）等等。提供微應用運行能力，微應用之間業務流轉能力等。
問5：原生渲染和h5相比，效率差很多嗎？
答：原生渲染使用的操作系統底層的能力渲染，而h5使用的是webkit的殼渲染，效率相差很大。
問6：目前很多app，原生部分已經很少了，大部分是h5頁面，那麼替換成rn是否有必要呢？另外rn只是實現原來原生的部分，還是一些h5也要改成rn呢？
答：感興趣的話您可以去關注下目前各大互聯網公司的App，基本都是採用原生或運行時原生處理的。對於需要交互的界面爲了用戶體驗大都採用原生，而瀏覽類的使用h5。h5有使用的場景，不是所有的都要替換，建議用戶交互類的使用RN開發,單純的瀏覽功能使用h5。
問7：還是不明白這幾種不同方式開發的app是如何整合到統一官方的app，能否再詳細點說說這個過程。
答：對於採用不同開發技術及語言開發的App整合到一起確實不是一件容易的事情，前期需要做大量的調研工作。
1、調研各App團隊所使用的技術語言，開發框架
2、需要各團隊整理出使用的三方組件
3、制定統一的開發規範和集成規範
4、整合開發集成
問8：airbnb早期宣佈放棄rn，能分享下rn做業務開發遇到的坑嗎，還建議使用嗎？
答：任何的技術語言和開發框架都有利有弊，主要是合理利用其優勢部分。RN 的優勢在於快速開發、迭代，支持熱更新，業務可以快速到達。
問9：上面說的案例，各個團隊按微應用方式開發，是說按新框架進行原有應用的整個開發吧？
答：微應用模式開發，但不是推翻重新開發，而是按照統一的開發規範改造原有應用使其能夠在統一的官方App正常運行。