如何迅速開發一款移動App？螞蟻金服移動開發平台mPaaS來幫你

小螞蟻說：

時間倒推到兩三年前，大家可能對刷支付寶乘公共汽車和地鐵還感到驚奇。但如今，一個外來遊客要是來到北上杭這些城市旅遊的話，再也不用浪費時間在各個地鐵票售賣處排長隊買地鐵票了。無論是用支付寶掃碼進站，還是打開像上海地鐵的“METRO大都會”這類App，這些應用的出現和存在最終都是為了友善消費者的日常出行體驗。

與此同時，現在的年輕人可能對銀行線下網點和人工櫃台的服務越來越陌生，因為越來越多的轉賬、彙款等交易都發生在了線上。多年前春運期間一大清早去火車票網點排隊購票的場景也逐漸消失，人們已經習慣用網際網路來搞定一切，并習以為常。

但這也變化也不是一夜之間一蹴而就的，那些我們吐槽部分App和線上業務體驗不佳的日子似乎還并不遙遠。而這些體驗的摩擦與交融可以說是各行各業走向數字化轉型的一個縮影與陣痛。或許很多年之後回望2017年，人們會認為此刻是一個時間節點。在這一年，傳統金融機構以及非金融行業都在紛紛發力開發或者革新自己的App，以更好地适應網際網路時代下使用者的需求并提升使用者體驗。這些狀況在不久之後就會得到改變，而這些改變背後少不了今天故事的主人公——螞蟻金服移動開發平台mPaaS。

潛心練功，mPaaS的誕生與成長

mPaaS 是 mobile Platform-as-a-Service的簡稱。如果你熟悉雲計算的話，對PaaS這個概念一定不會陌生。如果你采用PaaS的服務，那麼意味着你既不需要買伺服器，也不需要自己裝伺服器軟體，即可利用這個中間件平台進行定制化研發，開發自己的應用。

而mPaaS這個概念則由螞蟻金服獨創。它是在PaaS的基礎上衍生出移動的平台概念，其中m代表的就是mobile（移動）。類比與PaaS的概念，mPaaS更專注于移動端的研發平台服務。開發者能夠利用螞蟻金服移動開發平台mPaaS做好移動App的開發、管理、釋出，并做好App全生命周期的管理，其中包括了開發期的研發測試、打包建構、釋出管理，還有釋出之後的使用者行為分析、閃退分析等。如果說PaaS平台是對企業背景服務的生命周期的管理，包括研發、釋出、監控這一套流程，那麼mPaaS就是對移動應用App一整套全生命周期的管理服務。

事實上，當傳統金融行業将目光投向移動App開發的時候，前面是一條看似平坦卻暗藏坑窪的一條路。而支付寶早在2013年以前，就開始了這趟淌坑之旅，并逐漸摸索出一條明路，最終基于mPaaS平台對外開放。這就像你剛開始準備學習這門課程，學霸支付寶同學已經早在幾年前就學完并替你總結了一套學習方法和快速學習平台。可以說，目前mPaaS的所有技術服務群組件都是源于支付寶，并在支付寶的各種高并發等極端條件下和實際業務場景中經過重重檢驗的。

為了讓你更好地了解mPaaS的過人之處，我們要先從支付寶這個國民級App的開發曆程開始說起。2013年開始，支付寶開始了All In無線戰略。在那之前，支付寶還是一個單體應用的支付工具，隻擁有一些非常基礎的子產品和工具庫。2013年，随着支付寶的All In 無線戰略之後，業務快速發展，支付寶App裡所能提供的功能和應用也開始井噴式的發展。與此同時，支付寶APP使用者數也開始指數級的增長，其背景支援的開發團隊也日益龐大。這麼一個數量龐大的開發團隊如何高效地進行開發協作呢？這對支付寶App開發架構的設計的合理性提出了很高的要求。

在2013年到2015年期間，螞蟻金服就對支付寶做了一個架構治理，整個支付寶App的開發架構被做了分層，支付寶App被改造成了一個平台型App，它內建了各個應用，并實作了應用的服務化、子產品化，開發工具走向元件化。這樣一來，基于支付寶App上的每一個應用都可以獨立的由一個團隊來開發，而整個支付寶則用一個通用的底層平台架構進行管理。如此，支付寶App就從架構上允許支付寶能夠快速擴充業務，每上一個新業務就相當于開發一個新的子產品，隻需要将新的子產品插到這個架構裡就可以運作了。

在這個期間，支付寶的開發團隊還沉澱了子產品開發的很多通用的能力，包括像消息推送、分析、網關等等。而這些通用能力幾乎所有業務場景裡的應用都會需要。與通用技術能力伴随而生的另一個簡單的理念就是：我們能不能将在支付寶架構上沉澱的這一套經驗和能力更好地對外輸出，以服務更多的金融機構？

2015年9月14日，螞蟻金服宣布啟動“網際網路推進器”計劃，計劃将在5年内助力超過1000家金融機構向新金融轉型更新。螞蟻金服作為“網際網路推進器”将推動平台、資料和技術方面的能力全面對外開放。同年10月，mPaaS 1.0版本正式面世。

1.0時期的mPaaS功能比較簡單，主要包括三大核心功能：網關；使用者行為分析；消息推送。在這一時期，mPaaS就服務了網商銀行和天弘基金兩大客戶。

很快到了2016年底，mPaaS 2.0 版本開始醞釀。mPaaS 2.0 最重要的特征是往共享的方向發展，并實作了架構和子產品的拆分，即mPaaS上提供的功能都可以單獨輸出，這意味着客戶可以比如隻使用單項功能（如消息推送）而完全不用其它任何服務。共享模式也可以說是多租戶模式，就是說開發者在公有雲上可以擁有不止一份mPaaS，不同使用者可以通過邏輯隔離來用同一份mPaaS，這可以有效的降低公有雲上的使用成本。

此外，2.0時期的mPaaS具有着更豐富的功能：一個是MDS功能，即釋出功能，它可以在APP裡提醒使用者下載下傳、更新新版本；另一個是熱修複功能，熱修複功能通過MDS釋出到用戶端，并在緊急情況下，如果代碼有問題，開發者可以在不釋出新版本的情況下，在運作期就将問題修複。

熱修複功能一經推出即受到了市場的熱烈歡迎，在這之前和之後，市場都很難找到同樣提供同類服務的産品。2017年1月，mPaaS 2.0出現在了衆人的視野裡。這一次它服務的客戶進一步擴充，除了蘇甯金融這類金融客戶之外，有了更多非金融行業的客戶的加入，包括阿裡健康、OFO等等，還有我們前文提到的上海地鐵。

2017年5月，螞蟻金服mPaaS技術團隊開始進駐上海地鐵，到10月份上海地鐵“METRO 大都會”App正式上線，并在上線一周以内該App注冊人數超過百萬，這背後所支撐的不過十幾人的開發團隊。上海地鐵“METRO 大都會”App加入了掃碼進站的功能，這意味上海的使用者不再需要在高峰期花半小時排隊買地鐵票。

在“METRO 大都會”App的上線過程中，mPaaS 2.0新上線的“熱修複”功能還經曆了一次生死時速的考驗。為了做好App的資料營運和監測工作，該App開發時即使用了mPaaS的各項能力，在App上線之前就做好了全方位的埋點監控，相關人員能夠密切關注使用者的使用情況，這樣能在出現任何問題的時候也能第一時間發現并修複。果然，在該App剛上線一周的時候，技術小哥敏銳地注意到，部分機型無法順利的完成使用者注冊。在發現這個問題的一天之内，技術小哥們迅速的解決了這個問題，并利用接好的熱修複功能快速修複，最大程度上保證使用者的體驗不受損害。想象一下，要是沒有熱修複功能，而是等到各個手機應用市場重新釋出新版本的話，這其中所耗的稽核和上線時間不可估量，而最終影響的使用者也可能難以計數。

地鐵，春運，銀行—— mPaaS接受挑戰并完成到絕世高手的蛻變

2017年10月開始，mPaaS 開始向3.0階段蛻變。mPaaS 3.0開始支援私有雲，并推出了資料同步服務。資料同步是一個保持mPaaS跟用戶端常連接配接的服務，該服務能夠確定一些關鍵資訊可以在秒級觸達所有的線上使用者，時效性和穩定性都得到了改善。

同時，mPaaS小程式的功能也在3.0版本中被抽離了出來，做成了一個純技術的方案，這意味着mPaaS的開發者可以利用小程式技術為自己的App開發小程式。以上海地鐵為例，該App支援其他開發者、ISV或商戶能夠圍繞上海地鐵開發更多小程式，并且這些小程式可以既運作在上海地鐵裡面，也可以運作在支付寶裡面，為開發者們帶來更多的流量和福利。

在向3.0過渡的2017年9月底，mPaaS開始與12306展開合作。當時這支mPaaS開發團隊還不知道就在短短3個月後，他們就要拿出一個新的産品，也就是部署并開發一個新的12306 App來應對一個巨大的難題——春運。

可春運作為一個老大難問題，按照mPaaS開發團隊的話講：“并不是開玩笑的”。事實上，做12306 App這麼大的産品一般正常的開發周期要一年以上，而mPaaS技術團隊面臨的狀況是在9月底進場，12月份上春運，如此高的強度和如此難的技術挑戰，在國内外都是沒有先例的。

但最後mPaaS團隊還是接受了這任務，10多個人的團隊再加上鐵道部派來的團隊加班加點，終于在1月3日，通過各輪的測試、壓測後上線。最終12306的線上App很順利的支援了春運，為國人順利回家過年出了一份力。

此外，在2.0到3.0期間，mPaaS還幫助蘇州銀行順利完成了雲端的部署，為直銷銀行多樣化場景提供了強力的支撐；通過mPaaS離線包幫助廣發銀行提升了APP性能，使其“發現精彩”的啟動時間從降低近70%；印度的Paytm則利用mPaaS的這套能力更好的對在即的App内部進行資料監測與統計，進而更好地優化使用者體驗……

而至此，mPaaS也完成了自己的蛻變，就App開發領域的某個單個問題的解決而言，或許還有一些對手能夠與mPaaS勉強抗衡，但就用戶端App移動次元的一個整體解決方案而言，金融行業已不再有對手能跟mPaaS相提并論。而mPaaS基于支付寶的能力沉澱而來，使得它更适合如出行類的高并發需求；或是金融行業所要求的強容災和安全性。

承擔責任，迎接新挑戰的mPaaS 3.0

回過頭來看mPaaS的成長與蛻變，我們會看到mPaaS依托于支付寶掌握了如下關鍵技能：

1.依托于支付寶長期發展而積累下來的業務場景，成長為做2C端産品營運的大師。

很多傳統金融，非金融機構也許并不知道應該如何做一個成功的面向大衆消費者（to C）端的産品，更是在如何做業務營運，營銷上缺乏經驗。對于傳統行業來說，無論是交通出行行業還是銀行等金融機構，由于沒有相關背景，即便将業務外包，當涉及到數字化轉型這樣大的場景需要成體系方案時，外包公司多由于沒有能力給出完整方案而讓傳統行業繼續面臨困境。

mPaaS由于依托支付寶這個經過長期技術積累，實力雄厚，有曆史，技術經得起最各種極端挑戰，并逐漸成長為能夠給出有前瞻性的解決方案來解決潛在的未來問題的專家，它能給傳統行業提供完整的生命周期性的整套數字化解決方案。而這，形成了mPaaS和其他同類産品的代差。

2.從開發架構次元支援團隊協同開發，效率更高。

回顧mPaaS的誕生曆史，一開始它的出現就是為了服務各個團隊協作而産生的，進而更好的支援業務的快速擴張和團隊協作。此外，mPaaS提供了很多現成的開發元件和模闆，不用重複造輪子，進一步提升了開發者開發App的效率。這一點在12306的3個月快速開發案例上就是一個很好的例證。

3.強大的App性能優化能力，保證使用者體驗。

關于“如何實作App的秒開，縮短使用者的等待時間”這一問題的探索，支付寶技術團隊的鑽研之深遠超你想象。如今，借助mPaaS平台，支付寶将這一技術貢獻給大家，讓各位開發者們也能開發自己的高性能應用。目前，經過mPaaS優化過的銀行類App打開時間由原來的十幾秒到秒開，這與其背後的技術經驗密切相關。

4.從小程式到人臉識别技術，支付寶的創新技術加持

目前mPaaS團隊還在不斷為在目前的基礎上對外開放更多的功能。從當下幾乎各個金融類App必備的人臉識别技術，到能夠更好建構自身生态的小程式技術。這些你能想象到的前沿技術熱點都在mPaaS上逐漸實作，而未來基于螞蟻BASIC技術戰略的區塊鍊技術等等，更是值得期待。

5.不僅是技術的輸出，更是經驗的輸出，推廣先進的經驗從根本上改變研發方式

mPaaS 離線包，熱修複，App 灰階釋出，小程式等可以從根本上改變研發，釋出方式，提高效率。比如離線包徹底解決了H5加載的性能問題及對網絡的依賴，開發者可以更多的去關注業務邏輯而不必太過關心性能。下面是在某銀行 App上線灰階過程中，一線的運維工程師對灰階釋出經驗的高度認可，也是mPaaS 對外服務的初衷。

尾聲

一年前， 全球知名管理咨詢公司麥肯錫釋出了報告稱，在網際網路時代，随着中國經濟增長進入新常态，傳統銀行的經營環境日益嚴峻，大量金融科技公司正在各細分領域威脅傳統銀行的核心業務。傳統銀行面臨着前所未有的機遇和挑戰，數字化轉型迫在眉睫。那麼在這樣的大背景下，各個組織機構如何做好自己的數字化轉型呢？數字化轉型的敲門磚——移動App的開發又應該如何起步呢？螞蟻金服mPaaS已經給出了它的答案。

2018年9月19日，一年一度的螞蟻金服ATEC科技探索大會将作為雲栖大會的一部分在雲栖小鎮再次召開。新一代的企業金融級智能化mPaaS平台4.0即将在此次大會上退出，盡請期待~！持續關注“螞蟻金服科技”官方微信賬号，了解更多一手資訊！

mPaaS技術交流群

想和志同道合的技術同學們一起探讨技術問題嗎？想認識螞蟻金服mPaaS團隊的技術專家們并且即時交流嗎？

掃描下方二維碼聯系螞蟻金服加群小助手，快速加入mPaaS技術交流群！