又到週末了，大家手頭的工作完成的怎麼樣啦？還沒有完成的繼續加油鴨！想要告別加班，給大家推薦一個移動APP研發提速利器。本文根據2018杭州雲棲大會移動研發平臺EMAS專場，阿里巴巴產品專家言沛的主題演講《移動APP研發提速利器之EMAS跨平臺解決方案》整理成文。

在座各位應該都是移動APP研發負責人，大家平常工作中最關心的一點是研發成本。就像我之前在群裡看見有人提問說開發一個手機淘寶首頁大概要多少錢，計算錢這個問題有點複雜，會受你聘請的程式設計師工資多高的影響，所以我把這個問題改一下，改成開發一個手機淘寶的首頁大概要多少工時，大家來猜一下？我結合自身的經驗和請教了相關同事，如果只是做視覺還原的工作，大概也需要五天。

那有沒有再快一點的辦法，來實現頁面的開發？大家第一個想到的應該是H5的方案。沒錯，因為H5方案開發一次可以在多端投放。而且由於它技術框架的原因，單端開發速度也比APP快。我問過專業的H5前端工程師，他說開發一個手淘首頁只要1.5天。

但是，我們知道業務方對移動APP的研發訴求不僅僅是快，而是著名的“既要、又要、還要”，就是既要迭代快，又要效能好，還要使用者體驗順暢。H5方案可以滿足第一點的需求，但是它有它無法迴避的劣勢。舉例來說對記憶體的控制比較差，當一個列表比較長的時候會佔用比較多的記憶體。第二是頁面的流暢性比較差，直觀的感受就是你的手指在螢幕上快速來回滑動的時候，螢幕響應速度慢，技術上來說就是幀率低。第三是動畫流暢性，特別是大區塊中，做動畫會有卡頓的感覺。有沒有一個辦法既能保持H5的優點，又能克服那些缺點？答案是有的，那就是Weex。

我介紹一下Weex的原理。Weex可以把前端編寫的程式碼編譯成JS Bundle，通過伺服器下放到手機，最關鍵的是在iOS或者安卓環境下是採用Native渲染。如果用Weex實現手淘首頁，大概也需要1.5天的樣子。大家可以用手機淘寶掃一下螢幕上的二維碼，體驗一下用Weex簡單拷貝的手淘首頁。

傳統移動APP開發的時候其實還有一個痛點，就是版本迭代的問題。因為APP的迭代和更新是依賴使用者來不來更新，很難保證使用者都願意及時更新你最新的版本，所以造成線下版本碎片化比較嚴重。Weex天生支援動態更新，可以隨時發版，可以保障每次開啟都是最新的版本。

剛才介紹了Weex各種優點，到底有哪些APP使用了Weex的技術？我相信這也是大家比較關心的。

首先，Weex誕生於手機淘寶。在這裡分享一個小花絮，就是Weex技術在手淘落地的第一個場景是什麼，落地的第一個場景就是“雙十一”的會場列表，就是一堆全是商品的列表頁。我們這個技術一上來就用在“雙十一”的場景上，說明我們當時的開發對自己的技術非常有自信。

我們來看一下資料。雙促會場從之前99%用Weex實現到最近100%用Weex實現；第二是行業導購，從之前小部分頻道業務用Weex來實現也到現在的100%都用Weex來實現。行業導購業務包括有好貨、買遍全球、每日好店等業務。如果大家熟悉淘寶，它們都是在手機首頁上主推的頻道業務。如果大家用過這些業務，會發現它們的體驗做得非常棒，甚至你根本體會不出來它是否用Weex實現；第三是交易鏈路和基礎業務，比如說店鋪、淘寶、足跡等等，這些業務從之前完全沒有用Weex來實現到現在大概有6個頁面用Weex來實現。其實這些頁面是非常底層、核心的業務，也可以用Weex來實現，沒有任何問題。

除了手機淘寶之外，阿里還有很多其他的APP也用Weex實現，我在這裡擷取一部分APP的LOGO，大家可以發現大家平常在用的比較多的阿里集團的APP都基本上採用Weex的技術。我在這裡想簡單介紹一下飛豬。

飛豬有它自己的獨立客戶端，在手淘裡面也有一個比較重要的入口，它的要求都已經不僅僅是跨端了，而是到了一個跨APP投放的需求。飛豬在之前的時候也是用H5來實現的，為了提高使用者體驗，所以他們針對H5的方案也做了非常多的優化。但是Weex的技術推出之後，飛豬同學體驗到Weex的技術優勢之後全面擁抱了Weex的技術，把之前H5頁面紛紛轉向Weex來實現。現在在飛豬業務裡面，幾乎已經很難找到用H5實現的頁面。在這個過程中，他們也做了很多的技術沉澱，比如說Weex UI開源元件就是由他們的團隊負責的。

Weex不僅僅是阿里巴巴的Weex，它也是apache上的開源專案。我這裡擷取apache專案裡面的一些基礎資料，包括star、fork、contributors。其實Weex這個專案做過一次程式碼遷移，從阿里巴巴的倉庫遷到apache專案上，所以如果把這兩個專案的資料加起來，肯定會比這個更多一些。同時，Weex也是阿里巴巴所有開源專案裡面Star數最多的開源專案。

既然是開源的Weex，那麼除了阿里巴巴集團之外，業界又有不少APP用了Weex的技術。這些APP都是在我們的Weex官網上自主提交的資訊，我這裡截取了一小部分。我覺得使用了Weex而沒有提交的APP，可能也不在少數。

剛剛講了各種Weex的優勢，這麼牛，有人想問Weex到底還有什麼不足之處？就像人無完人，Weex也有一點點不足的地方。Weex支援的樣式和語法是滿足W3C標準，但是並不是所有的W3C標準都支援，所以這就有學習成本。以我自己為例，從小白開始學習到上手簡單的頁面開發，大概需要花我7天的時間。但是7天之後，就可以體驗全新的移動APP研發模式。

當你學會了 Weex 這個技術，也想用Weex開發自己的APP的時候，你會怎麼做？如果按照Weex的官網教程下來，可以構建出你的APP，但這可能會花費比較長一點的時間。而且我們知道生產環境下對一個APP的研發要求，不僅僅是在你本地的電腦上構建一個包就可以了，所以針對這種場景的完整解決方案，我們的EMAS跨平臺產品就此誕生。

EMAS跨平臺產品矩陣大概包括開發者社群、IDE、商業元件、DevOps，應該說覆蓋了從研發、除錯、測試、釋出、運維完整的生命週期的管理需求。

我們首先看一下開發者社群。做過研發的都知道如果我們要學習掌握一門新的技術，僅僅是文件還是不夠的，最好是能看到一些前人的經驗總結以及豐富的生動的demo供我參考。所以我們在Weex官網基礎上補充了它所不具備的東西，主要目的是幫大家降低學習Weex的成本。開發者社群，有後續取代現在官網的計劃。

然後是EMAS studio，這是我們推出的第二代Weex IDE，基於VisualStudio Code定製開發，在這裡你可以完成新建專案、編碼、除錯、預覽等等，所有的功能都在IDE裡面完成，就不需要IDE和瀏覽器之間來回切換。特別是除錯功能，通過手機掃IDE裡面的二維碼建立debug服務，可進行單步除錯，對定位端上遇到的問題是非常有幫助的。

當我用了專業的開發者工具，以我的經驗來看還有一個點比較影響我開發業務的時間，那就是有沒有元件可以供我使用。Weex內建元件以及Weex UI開源元件可以滿足常規業務的開發，但深入到有行業特徵屬性的時候，比如說手勢密碼或者是雷達圖等就有所缺失了。所以我們把一些具有行業特徵屬性的元件封裝在一起供商業客戶使用，幫助大家提高用Weex實現業務的效率。

剛才提到了社群、IDE、元件，都是為了幫我們快速用Weex實現自己的業務，但我們最終想要拿到的是什麼？可不僅僅是一個Weex的程式碼或者是Js Bundle，而是一個穩健的實實在在的APP。跨平臺DevOps就可以實現這個工作，在這裡可以實現DEMO生成、雲構建、灰度釋出、正式釋出、測試等都可以在DevOps上完成。

如果從功能點上劃分，大概可以分成四點：業務管理、程式碼監控、產品釋出和監控運維，每一項又包含很多的小點，我列在PPT上了，不一一展開念。我想具體解讀幾個亮點。首先是我們建議業務按照合理的邏輯進行拆分，按模組管理來降低業務之間的耦合度；第二，利用雲構建能力，對APP進行持續交付；第三，利用我們所提供的預載入能力，可以把資源提前載入到手機裡，提高頁面秒開率，提高使用者體驗；第四，通過後臺監控平臺來看APP執行狀況，做到對程式碼質量心中有數。

前面提到了這四個產品，如何把它們串聯起來來完成APP的研發？為了給大家一個更加直觀的感受，我畫了這張圖。圖裡面綠色代表了研發流程，藍色代表了我們所提供的產品。總結來看，EMAS Studio、開發者社群和元件都是圍繞在Weex端，幫助大家更快用Weex實現自己的業務。在native層我們可以參考devops上生成的DEMO工程，稍微修改下，就可以滿足你自己的需求，這一塊的開發工作量非常少，最後在DevOps上完成構建、釋出。

剛才介紹了產品，我們再來講一下有哪些客戶使用了我們的跨平臺產品。這裡出於對客戶隱私的保護，不具體講哪個APP。可以看到覆蓋餐飲、交通、金融、能源、地產和教育行業等，行業的覆蓋度還是比較廣。有一個新零售的客戶要對他的超級APP進行重新開發，大概包含了零售的業務提供、互動、短視訊、社交等等很多的功能。他們最後技術選型採用Weex去實現，再配合跨平臺提供的能力，大概一共用了6個開發，花了大概三個月的時間，完成了120多個複雜頁面的開發。而這時間不僅僅是開發，從學習開始一直到釋出。另外，因為Weex所做的頁面也可以以H5的方式開啟，所以他們順便還做了公眾號專案裡面10來個頁面的改造升級。

前面講了很多Weex的優勢和對weex開發的支援，那我們的跨平臺僅僅是Weex嗎？答案肯定是“不是”的。我們深諳行業裡面還有很多業務是用H5來實現的，所以我們後續會推出相容H5的方案，第二是最近比較流行的Flutter方案，我們也是在學習和研究之中。應該說對未來主要流行的跨平臺的技術方案，我們都會保持密切的關注，在合適的時候推出相應的產品。