胡澤銳：移動開發即服務——騰訊雲移動開發平臺技術分享

歡迎你們前往騰訊雲+社區，獲取更多騰訊海量技術實踐乾貨哦~

做者：胡澤銳，2010 年畢業加入騰訊，前後負責過QQ空間、網頁應用、移動應用、移動遊戲相關的工做，有着豐富的平臺產品經驗以及大前端開發經驗，目前在騰訊雲負責前端以及終端相關的工做，提出並推進移動開發平臺產品的落地。

很高興能和你們分享移動開發的歷史、現狀、以及將來，一塊兒探索麪向雲端的全新模式——移動開發即服務。正由於有了移動開發即服務的理念，纔有了移動開發平臺這個產品。傳統模式下，你們都是以單個產品或者能力的方式提供服務，好比推送的就提供推送的服務，分析的就提供分析的服務。也許在單個產品下，能作到體驗的極致，在接入使用，或者管理上能作到很方便。但對整個移動開發來說，這種單品的割裂會致使整個移動開發體驗的不流暢、不完善，各個產品之間的割裂會致使整個移動開發的節奏也是割裂的，咱們沒法完整地作到一件事情從頭至尾只在一個平臺上作，因此騰訊雲提出一個全新的模式——移動開發即服務。

這裏麪包含兩個概念，一是要作移動開發總體的事，咱們要服務移動開發整個的生命週期。二是作服務的事，服務這裏也包含兩點：一是咱們的開發體驗必需要作到完善，二是使用體驗也要盡力作到最好。

移動開發平臺

下圖是騰訊雲和騰訊內的各個產品合做，深度整合各個產品，聯合推出的全新的移動開發平臺。若是隻是看功能的話，這些產品都不是什麼特別新的東西，好比移動分析，這些產品不僅在騰訊公司內部普遍應用，在公司外部也有相似的產品提供對應的服務。好比MTA咱們公司已經使用了好久；bugly在公司內外獲得印證，在業界也有普遍的使用；計費米大師集成了公司全部產品的計費功能，包括應用寶、開發平臺這種toB的產品，也有王者榮耀、QQ飛車具體的應用。

移動開發平臺就是將這些產品進行深度整合，變成一個總體，以一種全新的開發模式和體驗提供給開發者。開發平臺4月份上線，在一個多月的使用過程當中，咱們發現開發者使用的火爆程度超出了咱們的預期。經過對用戶回訪以及統計數據，咱們總結出三個關鍵點。

一、易用

在進行用戶回訪的時候我常常問一個問題，你以爲在接入和使用產品的過程當中有沒有遇到什麼難題？用戶通常給個人反饋都是這樣的：挺順利的、沒有遇到什麼問題；挺好的、能順利接入。其中有兩個回答我印象比較深入，一是說挺好的，文檔能看懂；二是說文檔挺齊全的，想用的幾個功能，如自定義、標籤推送都能很快找到。

也許對外部的人來講，這種反饋很廣泛很正常。但以一個移動開發者多年的經驗，我以爲這兩點實際上是很高的評價。咱們通常在使用其餘的產品時，常常會遇到幾個問題。第一個是文檔看不懂；第二個是跟着文檔操做遇到問題時不知道該怎麼作，不知道要怎麼進行下去；第三個是在遇到一些比較高級功能的時候，找不到文檔應該怎麼作。因此，我認爲上面的兩個回答是對開發平臺易用性比較高的評價。

二、效率提高

這個提高包括兩個方面，在接入過程當中，接入一個能力也好、多個能力也好，開發平臺提供比較簡便便捷的方式，節省用戶接入的時間。第二個是在使用過程當中，由於咱們提供比較齊全的功能，可以讓用戶比較專一在覈心業務上，而減小被打斷的時間。

三、高留存

從統計數據來看，咱們發現使用咱們產品的開發者，最終的留存率能夠達到50%，這是一個很可觀的數字。另外，咱們也接到不少用戶諮詢，但願把線上的產品遷移到咱們的開發者平臺上。咱們如今主要是提供新開發的產品，尚未針對現有產品提供遷移的服務。由於這類用戶的諮詢量也比較大，因此咱們也在準備這方面的事情。

這些關鍵詞從正面、側面體現了整個產品的易用性和可用性。後面我會具體分享一下，在整個開發平臺在設計和使用過程當中，咱們都作了哪些事情來提升開發者的易用性和可用性。

移動開發的演進歷史

上圖是根據我的工做經驗及移動開發的歷史進程總結出的四個時間點。2010年是我首次接觸移動APP開發；2012-2013年真正從零到上線參與和主導一個移動APP的開發；2014-2015年在我負責移動遊戲的時候，當時的服務已是比較成熟的階段了；2017年我在騰訊雲負責終端和前端的工做，有一次與合做夥伴進行一個移動APP的項目，首次之外部人員的角度認識如何去構建一個移動應用。在這期間咱們也遇到了各類各樣的問題，使我下定決心去作一個移動開發平臺這樣的產品。

2010年，實際上是移動開發剛興起的階段，我認爲這是一個拓荒的時代。由於當時國內資料特別少，咱們常常從國外找一些資料，早期階段遇到的最大問題就是在性能方面，當時花費了至關多的時間去改進性能。咱們關注內存、渲染、速度，用各類方式去進行優化。

第二個階段是2012-2013年，就是在這個時期提出了移動優先的概念。手機進入大屏時代，比較標誌性的事件是三星note系列的大賣和iPhone5的推出。當時不少開發者一窩蜂地涌入移動開發，但那時的移動服務仍是很不齊全的。有一次咱們須要一個像如今的信鴿這樣的推送服務，咱們嘗試了不少服務，發現都很難知足需求。因此咱們只能本身作一個，但這個過程很是艱難。推送要保證觸達率、時延等，咱們在開發過程當中常常被打斷，好比作到一半，有人提出本身接收不到推送，咱們就必須停下來尋找緣由，在上線以後也會遇到推送觸達率不夠這樣的問題。移動推送只是一個簡單的縮影，當時會遇到不少這種組件不完善的問題。雖然你們都在轉向移動開發，但當時的服務還不夠齊全。

2014-2015年我在公司內部負責移動遊戲，當時開發的過程就行了不少，一些周邊的事情已經不須要本身去作了。我在作架構設計的時候，會將一些不一樣階段用到的功能預先加入進來，好比移動分析、移動推送這類經常使用的服務，像排行榜、公告系統等也會在一開始包含進來。雖然服務比較齊全，可是也會遇到一些問題，好比集成方式不統1、初始化方式不統1、使用方式不統一，不一樣的廠家或不一樣的部門提供的是不一樣的集成方式、初始化方式、使用方式，對於使用者來講就很不友好。因此咱們就作了一些封裝，好比當時把全部初始化的東西放在統一的地方去屏蔽初始化的細節。二是在上面包了薄薄一層，儘可能讓整個使用方式統一。我相信你們作移動應用的時候也常常遇到這樣的事情，須要本身把不一樣廠家提供的不一樣的接口統一塊兒來。

2017年，我和合做夥伴一塊兒進行了一個移動應用的項目，可是也調研了國外的雲廠家是怎樣去作的，好比亞馬遜。當時亞馬遜已經提出了這樣的概念，把全部場景、全部生命週期的東西包含在一塊兒，推出一個Mobile Hub產品，包括移動開發的整個階段，好比開發、測試、部署，整個研發的體驗都作得比較好。國外移動開發者服務進入一個新的階段，咱們認爲這是面向雲的一個階段，但其實國內在這方面作得還比較初級。固然不一樣的產品面向雲的方式會有點不太同樣，咱們如今提供的方式也會與aws有點不同。不過基本上的理念是差很少的，是一個面向雲的全新開發模式，讓移動開發者以整個移動開發的方式來作，而不是以推送、分析這樣的單個產品去作。

咱們回顧一下作移動開發的整個進程。從零開始作一個應用，在沒有開發前就應該去作架構的規劃，我會考慮把可能用到的能力，先統一集成進來。首先我須要分析能力，第一步我就要先去官網註冊一個賬號，而後把SDK集成進來，第三是編碼去使用它，第四是上線以後須要查看數據的管理時候要去控制檯。搞定分析後，發現推送須要將這個過程再作一次，還有不少其餘服務也是如此。這種事情至少作了五六遍，作了不少重複的事情，只是爲了把不一樣的能力整合到一塊兒。

當全部的能力集合在一塊兒，還須要作代碼總體體系的設計。設計完成後，我就會發現一些存在的問題，好比代碼散亂，我花了很大的精力去解決代碼散亂的問題。這個問題是怎麼形成的？第一是集成方式不統一，有些是給我一個SDK的包手動集成進去，有些是用工具如gradle，cocoapods集成進來，還有是提供另外的方式讓我集成進來。集成這一部分沒有辦法作到在同一個地方把全部的服務所有整合在一塊兒，在一我的開發的時候可能問題不大，但在多人合做的時候就會出現一些問題。好比當我在作項目溝通或者項目交接的時候，必需要說清楚推送服務的集成方式，還須要寫文檔說明每一個能力是如何實現的，咱們花了不少的時間和精力去解決這樣的問題。二是初始化和使用方式不統一，有的是按需初始化，有的是讓我在項目一開始就進行初始化。使用方式也不太統一，各類模式混雜所致使的問題就是使用的時候讓人難以理解，項目交接的時候也很是困難。有些初始化的部分代碼不同，並且代碼也散亂在不一樣的地方。在一個架構師的角度看來，這是一個很是很差的體驗。

第二個是溝通成本高。當我作完總體的架構設計以後，還必須召集整個團隊的開發人員一塊兒開會，告訴他們如何使用這個產品，如何使用每一個能力。這是啓動階段的開發和培訓，須要佔用一部分的時間。整個開發團隊在開發過程當中也沒法作到只專一業務，他們常常會遇到一些問題。好比在使用某個服務的時候須要一個功能，找不到的話就找人聯繫我，我再去查看對應的文檔，或是嘗試解決後並反饋給他，這中間有一個時間成本。並且在這種狀況下，開發過程當中每次的打斷其實都讓整個團隊的效率下降。

第三個是研發效率的低下。看到雲服務帶來的便捷，會感受到傳統模式下的方式實際上是不夠高效的。舉個簡單的例子，若是想要集成一個簡單的文件上傳下載的服務，之前我會搭建一個存儲的服務器，本身實現上傳下載的細節。但如今不是這樣了，你們均可以用對象存儲服務去作這樣的功能，提供了便捷的SDK去作這樣的事。可是我須要本身把這個能力集成進來，集成服務以後才能夠便捷地使用，使用幾行代碼實現文件上傳和下載。如今是雲時代，雲能夠提高研發效率、提升各類研發性能，可是移動開發者沒有辦法直接享受到雲的便捷，須要作一些事情把雲的服務整合進來。當時作架構時只能花不少精力、寫不少文檔和範例解決溝通成本高的問題，將雲的功能整合進來，提供給團隊的開發者。

我以爲這種事情其實應該規範化、批量化，咱們應該給移動開發者提供一個更好的服務，將整個移動開發做爲一個總體的服務。我想起2015年看到的某諮詢機構調研中的一個片段，當時的體會並非特別深，但當我作完這個應用的時候，腦海裏就想起了這個圖。2015年中國移動開發者使用第三方服務工具最看重的因素，排名第一和第二的分別是豐富性和易用性。剛看到時也沒有特別大的感覺，但2017年在進行應用的時候發現確實是這樣。豐富性和易用性，是咱們移動開發者真正考慮的很重要的因素。

移動開發即服務

當咱們下定決心作移動開發平臺的時候，首先咱們進行了用戶調研，經過各類手段跟用戶面對面的溝通。經過調查問卷，調研了移動開發者的訴求到底是什麼。一輪調查下來，不停地抽象，最後總結出一句話：把精力放在覈心業務上，提高效率。這是一個很是樸素的需求，但事實上咱們的現狀很難知足這樣的需求。好比作到一半時須要一個存儲能力，常常就須要放下手頭的事去調研一下市面上都提供了哪些存儲服務，再把它集成進來。作到一半時須要一個推送服務，也要調研一下市面上推送服務的廠家，通過調研再把它肯定下來。特別是架構師，常常把精力花費在一些本應該很容易解決的事上。因此咱們認爲移動開發者的核心訴求是把精力放在覈心業務上、提高效率。讓一些能夠通用化的，相似於分析服務、推送服務、存儲服務的這些服務由第三方廠家提供，由於這不是我核心的邏輯。

肯定了核心訴求後，咱們通過分析後認爲移動開發平臺應該從下面幾個方面去設計。

1. 架構師思惟。幫助開發者以架構師的思惟構建移動應用，咱們應該讓一兩年、兩三年經驗的移動開發者很容易以架構師的角度去構建整個移動應用。
2. 傻瓜式應用。使用的方式越簡單越好，最好是讓傻瓜都能用。
3. 靈活搭配。我可能會在各類階段引進能力，例如在一開始的開發階段，或者運營階段。好比我一開始可能不打算作付費，必定階段以後發現我能夠作付費，我要開始作付費了，這時候須要引進付費能力。移動開發者應該能在任意階段去作這樣一個事情，在任何階段即插即用、按需使用，幫助開發者提高效率。

說到架構師思惟，當時認爲能夠分兩部分考慮這樣的問題。第一部分就是服務，架構師是如何考慮服務的？一是易用，二是性能，三是可擴展，第二和部分是代碼，代碼的可讀性、可維護性和可拓展性是我做爲架構師必需要重點關注的幾個問題。因此咱們的移動開發平臺所提供的服務，必須是知足易用、可擴展和高性能的。咱們應該也能讓架構師在代碼層面，作到可讀可維護可擴展。這是從架構師的角度去思考問題，咱們須要作到的一些事情。

既然咱們的思路已經肯定了，要怎麼去作呢？咱們的產品一共分爲控制檯和SDK兩個部分，一是控制檯，控制檯必須是統一的，全部的服務必須在同一個地方控制，這是沒有任何疑問的。全部的服務必須在統一的地方去作控制和管理，集成也應該是統一的。SDK是移動開發者最最關注的一個點。當時思考把SDK分爲三個方面，SDK的集成、SDK的初始化、SDK的使用，咱們從這三個象限來考慮整個用戶的使用體驗。SDK的部分咱們考慮了幾種方式，首先咱們提出all in one的模式，也是按需打包的模式，這是國內廠家最多見的模式。但它們在初始化的時候是獨立的，使用的時候也是獨立的，這種方式很快就被我斃掉了，這種模式會存在比較多的問題，好比打包下載，手動集成，當我有版本升級的時候怎麼處理？很麻煩。第二是當我須要一個新能力的時候怎麼處理？是單獨勾一個仍是把之前用的所有勾上下載呢？用戶會有這樣的困擾。這種體驗，跟傳統的體驗方式可能會有一些優化，但我以爲達不到個人預期。

第二種模式，統一配置，按需使用。如今咱們使用的也主要是這種方式，全部包的集成和使用都是用配置來實現的，集成是不須要任何代碼，經過配置方式去作的。而後各自獨立初始化，這點可能你們以爲初始化跟以前仍是同樣，但其實會有點不同的點。正常狀況下是不須要初始化的，好比使用標準配置就不須要進行初始化。可是若是須要定製服務，好比說個人分析是多少秒上報一次或實時上報，仍是說一段時間整合在一塊兒上報或達到必定的量上報，這是開發者根據他的須要去作獨立配置的，這種狀況就須要去作初始化，作不到零代碼集成。你使用標準配置的狀況下，你的使用和初始化集成都是零代碼的，但當你須要作定製的時候可能就須要代碼去作一些事情。

怎麼能用更好的方式給移動開發者提供服務呢？這是我一直在思考的問題，有一天忽然想到像咱們這種不懂服務器的人都能獨立搭建一個服務器，好比ngnix，tomcat，那是爲何？是否是咱們的移動開發也能作到這樣，集成和初始化其實都不須要代碼去作參與？延着這條路去想，就想出了一種新的方式，零代碼集成、基於配置。如今也正在向這方面去作，但願能作到徹底的自動初始化。

首先集成跟之前同樣，經過配置的方式去集成，零代碼。二是初始化，剛纔說對於標準狀況能作到自動初始化的，但對於定製的服務須要代碼，如今針對這種狀況也是基於配置來作，配置完以後一下載就自動初始化了。這種狀況下全部的集成和初始化所有用配置文件來作，真正作到零代碼的集成。

從一個架構師的角度，我認爲這樣成本會降得特別特別低。由於全部的初始化和集成，都是經過配置文件來作。當有版本升級的時候，改一個配置就能夠了。當我須要一個新的策略的時候，也是改一個配置就能夠了。這種狀況下無論作項目交接也好，或者對下面人培訓也好，整個溝通的成本都特別低。

而後是統一的使用方式，這一部分咱們也但願作到零代碼，這個聽起來好像不太可能，但實際上咱們已經在往這個方向努力。好比自定義事件上報功能，點擊一個按紐後上報一條信息。正常使用的狀況是在代碼里加點擊事件，加一行代碼就上報了。如今是經過配置來作這樣的事，配置點擊什麼按鈕，上報什麼事件，集成以後點擊按鈕以後自動上報一個新事件，經過配置的方式來作到自定義的上報或使用，零代碼使用。

因此咱們但願使用方式也能作到零代碼，整個過程都作到零代碼，經過配置去使用，這是咱們的目標和願景。這樣才能真正爲移動開發者提供移動開發即服務的產品，之後移動開發者對於全部周邊的事情，都不須要去關注了。只須要關注你們都能看懂的配置文件，之後的項目交接或者項目培訓都很簡單了，以後但願能夠作到這種全站的無代碼集成使用。

咱們但願提供一個一體化的閉環體驗。上圖是咱們即將推出的一些功能，好比分享和廣告監測。咱們常常須要經過分享來擴大影響力或者拉來一些新的用戶，正常的分享SDK只提供了分享功能，但咱們提供分享功能是但願分享以後還能監測每個階段，好比用戶是否點擊，讓每個環節可追蹤可優化。廣告監測主要是由於如今獲客成本愈來愈高，咱們也常常作一些廣告拉一些新客戶進來。但每個廣告的效果其實很難作到精確追蹤，咱們也但願有一個廣告監測的功能，幫助開發者監測每個廣告的效果，幫助你們省錢。

第三是計算，第四是數據庫。咱們但願優化中國移動開發的方式，再也不和後臺強耦合，直接經過雲端去構建整個應用，從demo到上線、運行、上量，咱們的計算服務都是可用的，提供的是彈性的能力，如今能用上線以後也能用，數據庫也是。咱們但願經過這些產品打造雲端一體化的產品閉環體驗，從開始的計算、數據存儲、文件存儲到後面用戶的分析、廣告的監測，用戶的推送和活躍的運營、支付，一切都在一個平臺上能夠作到。從研發、測試、發佈、運維到運營，但願咱們的移動開發平臺能成爲整個開發生態閉環的產品。

Q/A

Q：剛纔聽到最終的方案是有一個控制檯，經過一些配置，下一個包，集成到好比說移動應用裏面，直接就能夠實現你的無代碼。但假設咱們在開發過程當中，或者說產品不斷迭代中可能改需求了，好比某一個配置我想改了，但那個SDK已經集成到APP裏面了，有什麼方式能夠去解決這個需求嗎？

A：咱們在一開始設計的時候已經考慮到了，你可能在不一樣的階段，都會使用咱們的功能，甚至去優化咱們的一些功能。這種狀況下怎麼辦？第一，咱們提供的是一個通用服務，你的需求可能變了，好比在推送的時候一開始須要對賬號進行推送，以後須要對標籤進行推送。這種變動不該該涉及到通用服務這一部分，咱們應該能適配大家的需求，大家的需求達不到，那是咱們本身作得不夠。第二點，你的配置已經集成到服務中了，若是須要一些變動，修改配置文件就行了。咱們但願在任何階段任什麼時候候使用咱們的服務，無論更改也好、從新使用也好，或是優化也好，咱們都應該用一個最便捷的方式去幫助你去作這樣的事。

Q:是否是跟可視化埋點同樣？

A：有點像，我只是舉個例子，但願後面用配置的方式去使用咱們每個服務，從開發到後面整個的使用所有用配置文件實現。

更多相關資料，請點擊下方連接獲取：
胡澤銳：移動開發即服務.pdf

問答
如何在雲服務器已有的開發系統下搭建開發環境？
相關閱讀
楊列昂：騰訊移動分析與服務架構
微服務架構雲端應用
移動開發之css3實現背景幾種漸變效果

此文已由做者受權騰訊雲+社區發佈，原文連接：https://cloud.tencent.com/developer/article/1138312?fromSource=waitui

歡迎你們前往騰訊雲+社區或關注雲加社區微信公衆號（QcloudCommunity），第一時間獲取更多海量技術實踐乾貨哦~