本文由淘寶技術部進階無線開發工程師詳細剖析了手機淘寶的現狀及挑戰。針對手淘問題發現被動、感覺模糊和缺乏經驗積累等衆多問題，阿裡精心研發推出了定制化的移動靜态代碼掃描體系！那麼該自行研發的掃描體系與已有的線上代碼掃描工具相比有何優勢呢？阿裡将其應用于EMAS持續傳遞解決方案中，用資料說明實力！
本次直播視訊精彩回顧，
戳這裡！
演講嘉賓簡介：芸墨（龔能）淘寶技術部，進階無線開發工程師。
以下内容根據演講嘉賓視訊分享以及PPT整理而成。
本文将圍繞一下幾個方面進行介紹：
1. 手機淘寶現狀及挑戰
2. 阿裡巴巴移動靜态代碼掃描體系
3. EMAS持續傳遞解決方案
一． 手機淘寶現狀 1. 研發支撐體系的演進手機淘寶近十年的演進史可以分為以下階段。階段一：工具型APP。2008年手機淘寶的第一個版本正式上線釋出，此階段工作重點從商品體系展開，從商品搜尋、進入商品詳情、下單、支付直至訂單生成，完成商品購買操作的閉環，使得應用功能和基本性能得到保障。階段二：平台型APP。由于手機淘寶的業務得到不斷發展，釋出了2.0版本的平台型APP，也稱為航母級APP。此時不僅僅需要關注淘寶相關業務，也需要關注集團中其他業務，例如聚劃算、天貓、飛豬，都将相應的業務入口放在淘寶中。是以此階段中淘寶每次的版本疊代涉及了衆多人員和業務，工作量較大。這個過程中主要關注航母級平台的疊代效率及穩定性。階段三：生态型超級APP。手機淘寶如今已經成為一個生态型的超級APP。在去年的雙十一，阿裡電商當天的GMV（Gross Merchandise Volume）達到了1670億，一個非常龐大的規模。這意味着淘寶已不單單是一個入口，而是承載着阿裡集團業務中軸的角色。除了阿裡電商，阿裡大文娛和金融體系都會通過淘寶進行協同工作，共同創造了這個了不起的業績。在這些階段發展過程中，淘寶的維護人員也從最初的幾個人發展到如今的千人以上，旨在完成業務的創新以及阿裡體系下生态的協同。
在這樣的大背景下，手淘采用了松耦合的架構體系，實作子產品化開發和高鐵式管理。高鐵式管理原意是指任何購買了高鐵票的乘客都是可以搭乘高鐵的，在手淘中意味着所有業務隻要完成了業務功能，就可以參與內建，但是需要達到一定的傳遞品質标準。是以這裡提供了一整套的品質保障體系，快速保障傳遞物品質。內建的大版本釋出上線後，仍然有一套監控體系，及時保障品質，跟進線上品質體系，同時也提供了動态化和熱修複的能力。若某些業務完成功能開發後未能及時趕上內建，正如乘客購買了高鐵票但沒有趕上車，這種情況下提供了自主灰階和自主釋出可供選擇。
3. 面臨的挑戰在手淘業務發展的過程中也面臨了諸多挑戰。首先，發現問題的過程有時是一個被動的過程。有些問題并不是在開發測試階段就可以發現，而是在釋出上線後通過監控體系發現。發現問題的時間較晚，需要被動追查問題，并且從問題的發現、定位到修複，時間周期長。第二個挑戰是感覺模糊。如何确認開發的應用品質達标，這并沒有一個固定的标準。正如現在正火爆的區塊鍊和數字貨币，曾發生過一個數字貨币的市場價值從60億瞬間清零的事件，這是因為這個貨币支援的智能合約的代碼中有資料類型溢出的問題，這個漏洞被黑客發現了，是以僞造了大量的貨币并在市場抛售，造成了該貨币的市場價值瞬間清零。歸根結底，這就是一行代碼的bug帶來的巨大的損失。類似的，在手淘的業務中，也存在這樣不知不覺帶着很嚴重的錯誤上線的情況，可能對系統的安全等性能造成巨大的威脅。第三個挑戰是缺乏積累。手淘在每年雙十一的體量特别大，這就意味着在雙十一之前需要相當多的準備工作，例如需要組建一個專家組研究分析往年的雙十一crash情況，力求減少crash，還有需要對性能問題進行梳理和優化。那麼每年這些工作都需要重複進行，如何沉澱其中專家的經驗來傳遞給下一次疊代的人員，沒有很好的解決方案。其次由于人員衆多，代碼開發風格各不相同。在一個小團隊中可以通過一個文檔或定期的代碼評審來保證代碼風格的一緻性。但在團隊與團隊之間甚至一個公司中，如何保證代碼風格統一也成了一個棘手的問題。最後，線上問題的排查和解決也存在着大量的重複勞動。為了解決上述問題和調整，阿裡研發推出了移動靜态代碼掃描體系。
二． 阿裡巴巴移動靜态代碼掃描體系 1. 特點分析該移動靜态代碼掃描體系有三大特點，一是橫跨全研發流程。在建立産品時，該體系可以針對該産品或應用自定義規則的開啟或關閉，及其優先級程度。産品開發過程中，可以定時觸發掃描，與CI/CD流程結合。在産品送出內建時，如果存在一些嚴重的問題，例如威脅到系統穩定性和安全性，則不允許送出，必須消除bug改進後才可以允許送出參與內建。這種橫跨了全研發流程的特點保障了産品品質的穩定可用。第二點是資料驅動。根據每天掃描的結果會生成品質大盤。品質大盤可以準确分析出業務品質情況、問題分布。最後針對阿裡巴巴的研發經驗以及crash分析，基于存在的性能、安全問題，将大量的開發經驗沉澱成為規則庫，将其與IDE插件和阿裡平台結合。這些技術經驗的積累可以幫助每個團隊在釋出之前提前對産品進行一次品質過濾。
2. 與其他工具的比較那麼為何不直接使用現有的一些免費開源的掃描工具？為何要自行開發一套移動靜态代碼掃描體系呢？現有的這些掃描工具大多具有以下幾個特點：
1） 手段簡單。絕大多數線上掃描工具僅僅是檢查文法風格問題，但阿裡作為一個企業級研發，需要可以發現潛在的bug。
2） 無限制力。它們隻是一個單純的工具，缺少明确的卡口機制，但阿裡需要能和CI/CD結合在一起的技術服務。
3） 無數字化度量。作為一個開源工具，這些工具手段較為簡單，發現問題的深度較淺，但企業研發過程中需要深入的分析問題并且生成數字化度量的必須名額。
4） 穩定性差。企業級研發通常需要面對上億行代碼的靜态分析，是以這個掃描體系需要對性能和穩定性有很高的要求。
那麼阿裡自行研發的掃描體系與這些線上工具相比有什麼優勢呢？
1） 定制化。首先，阿裡巴巴衆多的研發經驗都沉澱為規則庫，例如阿裡現已開源的安卓開發規範等，基于線上大資料分析crash的成因定制規則，包括安全、性能、穩定性、國際化、格式、正确性。
2） 解決方案。除了指出問題外，還需要指出如何解決。深入研發流程後，将研發經驗沉澱為規則庫，線上上發現問題後再次沉澱，形成閉環。此外，它可以提供平台和IDE插件。
3） 限制力強。整個過程中打包可以自動觸發，不需要人工操作。如果發現問題，會将bug自動分發至各開發人員，改善過的bug會在晚上進行auto-fix，如果該問題沒有解決，那麼第二天上線後仍然會變成reopen狀态。另外會将規則作為每個疊代的內建卡口。
4） 資料化。報表大盤可以跟蹤集團所有用戶端和每個業務子產品的問題分布和趨勢變化，形成對應的品質大盤。
5） 高穩定&低誤報。與其他現有的掃描體系相比，該靜态代碼掃描體系有着較高的穩定性和較低的誤報率。
6） 核心引擎：現主要支援AndroidScan\OSScan\WeexScan。Weex是阿裡一款跨平台的動态解決方案。
該代碼掃描體系與阿裡的終端CI/CD流程結合形成品質閉環的示意圖如下所示。
1） 自定義規則。結合線上crash、性能優化、安全問題、阿裡巴巴無線編碼規範、專家經驗定制掃描規則。
2） 任務觸發。通過IDE插件觸發任務，定時建構任務和打包任務，在任務完成後将提取到的bug自動配置設定至相應的開發人員處理。
3） 資料大盤。每天的掃描結果可以生成品質大盤，問題的類型分布和規則分布會幫助業務開發人員量化分析代碼情況，及時作出調整。
4） 內建卡口。內建時作為最後一道防線，保證內建釋出的代碼穩定可靠。
若上線後發現新問題，那麼便繼續定義新的規則，進行上述閉環操作。目前該靜态代碼掃描體系支援大多數核心業務，包括手機淘寶、飛豬、天貓、優酷、洋芋、聚劃算、鹹魚、釘釘、阿裡健康、菜鳥裹裹、菜鳥驿站等。
系統中，每個用戶端可以應用自定義通過标準，例如多少fatal和多少error可以為通過标準；在每個産品中，可以自定義開啟的規則和等級，例如對淘寶某業務來說該規則無關緊要，那麼便可以調低其優先級或者關閉，但對于聚劃算某個業務來說非常重要，便可以調高優先級；項目建構後便自動觸發任務執行；最後送出內建前，卡口生效，即上線前若該項标準沒有達到定義的可通過級别，那麼便不予上線。下圖為提取出的問題清單，根據産品業務線搜尋到對應的問題清單。在問題詳情頁會對每個問題有詳細的描述，并且提供了bug轉移和關閉的功能。
規則定制有幾大方向，包括文法錯誤、業務問題、性能問題、安全隐患、穩定性、測試全路徑覆寫以及編碼規範。例如在安卓中，通過URL導航進行跳轉操作，這需要對該導航判斷是否為标準格式，若不滿足會出現UnsupportedOperationException異常，那麼這裡定制的規則會幫助判斷是否滿足格式條件。再如，安卓中希望子類調用父類方法CallSuper的annotation來提示時，則必須重寫Super方法。若沒有override，編譯時不會報錯，但運作時會出現SuperNotCalledException異常。是以，該問題也在規則定制中加以預防。此外，這裡還實作了一個典型問題ConcurrentModificationException異常的處理。它是指在疊代器周遊Collection的時候，modCount和expectedModCount不同步。該問題在手淘中的crash多次出現，那麼在其他中小型企業相信也有類似的問題。這裡定制的規則會幫助開發者發現這類隐藏的問題。實作了這些規則後，通過IDE插件結合CI/CD流程進行掃描，操作過程詳見大會視訊。該靜态代碼掃描體系在阿裡使用至今大約2年，在手淘中每天平均上報問題數為3000多，嚴重問題解決率100%，命中規則crash率降低30%。這隻是手淘統計出的資料，加上支援的其他業務，掃描體系在阿裡的承載的工作量是非常大的。
6. 總體架構圖 上圖為阿裡持續內建體系的總體架構。該靜态代碼掃描體系在總體架構的基礎設施中提供四大功能。掃描引擎中心提供基于安卓、IOS、Weex、Python、安全相關的掃描工作。算法中心提供相應的規則管理、模型訓練、政策管理。規則配置中心實作卡口配置、權限配置、消息配置、審批配置。資料中心負責對掃描的結果進行資料分析統計，對上層業務進行服務。在研發支撐體系中，該靜态代碼掃描體系提供了內建管理等服務，為穩定性、性能、安全、通用性提供掃描支援。由此得到的資料為産品度量中心提供支撐。
三． EMAS 1. EMAS持續傳遞解決方案上述掃描體系及持續內建相關功能都在EMAS持續傳遞解決方案中得到承載，然後阿裡将EMAS賦能給商家，希望可以開放阿裡巴巴的研發經驗給社群。現在EMAS支援三種研發模式：傳統的Native開發方式、跨平台的Weex開發、Native和Weex混合開發。并且希望通過EMAS提供三項IT效能名額參考體系：研發團隊的研發效率、應用品質的标準以及應用性能标準。同時EMAS也覆寫了五大持續傳遞職能域，從研發階段、測試階段，到釋出階段、運維階段、營運階段，都提供了工具和基礎服務。具體每個階段提供的工具與能力見下圖所示：
阿裡希望通過EMAS從團隊和業務兩方面提升業務能力。在團隊方面，希望可以将阿裡巴巴内部沉澱的标準賦能給企業，将系統化的工作流和方法論、工程研發理念提供給社群，為使用者提升團隊的人均效能，提高協同效率與工程效能，更新組織架構。在業務方面，希望可以提供完善的基礎設施、優雅的業務架構與頂層設計等。最終是希望将阿裡的架構能力開放給社群，讓使用者獲得更高可用的底層架構。
本文由雲栖志願小組郭雪整理，編輯百見