時間：2017-05-16 來源：互聯網 瀏覽量：
文章來自：壹佰案例
導讀
自2015年Office移動版推出以來，超過2億下載。其功能集之豐富接近PC版，卻能流暢運行於低配手機、平板上，這無異於讓“大象”跳舞。到底是怎樣讓Office這頭功能巨大的“大象”在移動設備上輕快流暢地跳起舞來的？這有賴於微軟的“性能開發周期”流程。
（全文共6451字 預計閱讀時長：6分鍾）
一、案例背景
2015年全新推出的微軟Office移動版，如圖1所示，重寫了代碼，以適應觸控、小屏幕、移動、雲端、協作等需求。移動版包括Word、Excel、Powerpoint、OneNote等應用，支持Android、iOS、Windows三大平台上的手機和平板設備。
Office移動版推出以來，超過2億下載，Android/ iOS/ Windows商店評分均超過Google Docs，iWork等主要競爭產品。它的功能集之豐富接近PC版，卻能流暢運行於低配手機、平板上，這無異於讓“大象”跳舞。例如，我們主打的一款低價手機Lumia 635內存大小僅為512MB；Word/Excel/Powerpoint三個Windows Phone應用安裝後的文件占硬盤大小僅110MB。
我們是怎樣讓Office這頭功能巨大的“大象”在移動設備上輕快流暢地跳起舞來的？這有賴於我們的“性能開發周期”流程。本文將代表個人觀點為讀者分享這一流程。關於性能編程技術，請讀者參考MSDN文檔：Performance（Windows Store Apps）。
圖1 Office移動版
二、問題提出
●2.1 性能是什麼
性能包括兩方麵：一個是速度要快，一個是資源要省。可以總結為：“又要馬兒跑得快，又要馬兒不吃草”。性能在桌麵軟件、移動應用、網頁應用和後端等不同領域的含義有所不同。表1所示列舉了一些典型含義。
表1 性能的含義舉例
● 2.2 性能有多重要
我稱性能為“看不見的關鍵體驗”。在我看來，性能是軟件的競爭利器。iOS在很多方麵比Android操作係統更受用戶青睞，其原因之一是iOS感覺更流暢，雖然iPhone 4S隻有512MB內存，但是用戶感受比一些1GB內存的Android手機還快。又比如微信在很多類似產品中脫穎而出，其原因之一是微信發消息、語音、圖片時感覺太快了。
研究表明（App Attention Span Study 2014），“近90%受訪者會因為App性能差而卸載；性能是造成App和網頁用戶沮喪的頭號原因；65%的人對App性能的要求越來越高；約1/3移動銀行App用戶會因為App性能不好而換銀行；如果一個產品或服務的App性能比競爭產品好，29%的人寧願多付錢選擇它。”可以說，性能者，“死生之地，存亡之道，不可不察也。”
三、解決思路
為了確保產品的性能，有必要用流程來保證。性能開發周期如圖2所示。在軟件開發流程的每一步，嵌入相關性能環節。注意這個流程在幾天發布一次的快速迭代開發中也是適用的，因為每一步的性能工作可以做大也可以做小，重要的是在原則上有這些環節。
一旦功能需求確定，就應確定性能目標。
在係統設計之前就要確立性能目標，是因為性能目標有可能影響到係統如何架構。
係統設計之後就要做性能風險分析，因為很多性能風險是由係統設計帶來的或決定的。
在寫代碼之前就需要做性能風險分析，因為對性能風險的解決方案有可能影響到如何寫代碼。
寫功能代碼之後要寫相關的性能日誌，這樣測試時可以同時進行性能測試。
在發布後不僅要運營用戶增長，還要同時運營用戶性能體驗，兩者關聯起來有助於我們看到性能對增長的影響。
圖2 性能開發周期
接下來，我將對性能周期裏的每一環節詳細闡述，最後再探討一下怎樣建設一個性能團隊的途徑和方法。
四、案例複現
● 4.1確立性能目標
確立性能目標的一般流程如圖3所示。首先從功能需求出發，確定關鍵場景，再從關鍵場景中抽取幾個比較重要的關鍵指標，最後對這些指標確定性能目標值。
關鍵場景是功能需求中用戶最常用，體驗最重要，最體現產品價值的那幾個場景式功能。關鍵指標在上一節性能的含義中有所舉例。目標值的確定比較有講究，它來自用戶期待，產品的目標永遠是“超出用戶期待”。而用戶期待來自以下多個渠道：
用戶在產品評論中的性能反饋和要求；
競品的類似功能的性能；
用戶設備統計值，比如大部分用戶來自1GB內存的Android手機；
要和公司產品線上姊妹產品當前的性能值保持相當；
不能比產品上一版差。
圖3 確立性能目標
舉個例子，對Word移動版，一個關鍵場景是Word應用的啟動；其中一個關鍵指標是Word啟動到響應用戶交互的時間；它的目標值為1秒。
注意：目標值對自動化測試和用戶數據有不同含義。對自動化測試，我們可以確定一個或幾個典型參考設備和環境，比如iPhone 4s，要求在實驗室這個參考設備上啟動時間永遠不能超過1秒；
而對於真實用戶，他們的設備和環境參差不齊，同樣是iPhone 4s，卻可能因為係統上裝了其他軟件或移動網絡條件不同而產生不同的啟動時間，所以對用戶數據的目標一般使用統計分布值，比如要求90%的用戶啟動時間都不能超過1秒。
性能目標一旦確定，應被寫入功能需求作為產品的成功條件之一。作為“長期靶心”，不應該輕易改變。
● 4.2分析性能風險
一旦係統設計確定，就要在寫代碼之前進行性能風險分析，因為對風險的解決方案有可能影響到如何寫代碼。分析從係統設計出發，頭腦風暴可能的性能逆境，窮舉可能的對響應時間和係統資源的性能威脅，也就是不達標的風險。對每種風險，研究緩解方案和對策。
比如，係統設計是在Word啟動時執行跨網絡的任務，而一個可能的逆境是網絡條件差，導致的風險是Word啟動響應時間有可能超過1秒的目標值。對此研究方案對策，最後的解決方案是推遲相關的網絡任務到啟動響應之後。如圖4所示。
圖4 分析性能風險
方案對策有三個不同的戰略級別：
最有效的是優化架構設計，包括精簡加載模塊，重組文件，UI/工作消息調度，閑時處理任務，按需啟動/下載/升級……等。這項工作直接導致係統設計的修改，這也是為什麼不能把風險分析推遲到寫代碼階段的原因。
其次是根據硬件和環境而進行功能的縮放，硬件包括用戶設備的CPU、內存、分辨率、硬盤大小、電池電量，等等；環境包括網絡延時、網絡帶寬、網絡套餐，等等；根據動態測量設備和環境，功能的縮放包括關閉動畫、多分辨率圖片圖標、精簡加載的資源，等等。
最低一級是優化代碼，包括編譯/鏈接優化、按配置優化(Profile-Guided Optimization)、二進製符號分析、重複源碼分析，等等。
●4.3 寫性能日誌
性能日誌就像printf（見圖5），乍一看沒有太多要注意的，但是好的printf其實學問很深，對debug及其重要。
性能日誌要記錄哪些內容呢？
時間：這樣能通過收集的開始-結束時間的差值得知一個場景所花時間是否超過性能目標值，也能通過時間找到這一時間其他的相關日誌，進行綜合分析。
資源：記錄內存，網絡，讀寫等資源的開銷。
關聯：關聯當前代碼行和別處的有關代碼。有幾類關聯，第一類是記錄調用關係，哪個方法call了我，我又call了誰；第二類是跨線程異步關聯，哪個線程call了我，我又在等待哪個線程完成；第三類是跨客戶-服務器關聯，我是哪個設備，而服務器在哪個數據中心。
注意：日誌要反映真實用戶的體驗。比如響應時間要在UI真正空閑下來可以響應用戶輸入之後才算結束，否則到時候收集上來的數據顯示響應很快，但用戶那邊真實的體驗卻很慢，這就是自己騙自己了。
另外要注意的是性能日誌的性能本身，這聽起來比較諷刺。要測量日誌本身消耗了多少CPU，內存，讀寫，網絡使用資源。日誌應該本著“少而足夠”的原則。日誌應該是能夠分級輸出的，比如是內測還是發布時輸出，是今後一直輸出還是就當前版本輸出，等等，應用有開關統一控製。日誌還要能分離元數據，不需要在每條日誌裏都交代這是什麼用戶設備，是哪個應用版本，是哪個用戶對話；而應該對每個用戶設備隻記錄一次設備信息，對每個應用隻記錄一次應用版本，對每次對話隻記錄一次對話上下文，而這次對話裏發生的十條日誌都隻需要有個關聯ID，能讓我通過JOIN找到對話、應用、設備的元數據就行。
最後，日誌越少不僅消耗資源越少，而且debug時噪聲越少，看日誌越幹淨，越高效。輸出用戶日誌時要請隱私法律方麵的專家進行隱私評審，避免輸出能定位到具體某個用戶的隱私信息，纏上不必要的法律糾紛。
圖5 寫性能日誌
● 4.4自動化性能測試
產品加入新功能常常伴隨著更多的時間開銷和係統資源開銷，而我們要想知道產品的新版本是否仍然能滿足性能目標，最簡單的方法是在可重複、可控製的實驗室環境下，用固定參考設備測試幾個關鍵場景的性能。
當新代碼加入時，要判斷代碼的性質是否有可能影響性能，如果是則開啟自動化性能測試。自動化性能測試的流程如圖6所示。例如，新代碼是在Word的啟動路徑上，從而有可能影響性能。部署的機器包括手機和平板設備，相關的場景包括Word的冷啟動和熱啟動。收集的日誌統計了啟動的耗時、內存、CPU、讀寫等指標。對比結果發現，耗時比上一版有明顯的倒退，並且根據事件日誌分析定位到了一行網絡調用代碼。從而生成bug和報表，交給開發人員。
開發人員應該能一鍵打開相關分析界麵，包括相關代碼的曆史版本對照，可視化性能分析工具，等等，從而高效地理解問題並修改代碼。要把性能倒退的bug放在高優先級，才能不讓性能日漸流失，成為功能的犧牲品。
圖6 自動化性能測試
●4.5 性能運營
自動化性能測試能夠在實驗室純淨的設備環境中可重複、可控製地測試幾個關鍵場景的性能，為上線把關，然而不能得知世界上千差萬別的設備環境上真實用戶的體驗。因此，需要在上線後做用戶性能運營。
性能運營的流程
性能運營的流程如圖7所示。
用戶使用產品時在他們的設備上生成性能日誌。在正式發布之前首先進行內部上線，由企業內部員工內測使用，生成的日誌更少隱私限製，能提供原始豐富的debug信息，能在發布之前及時解決問題，所以內測非常重要。
無論內部或外部的用戶生成的日誌，在他們的設備上根據產品裏指定的收集規則來收集日誌，得到用戶真實體驗到的時間，資源使用等性能指標，並上傳到公司的數據中心。收集到的指標和性能目標比較，達不到性能目標則說明出了問題。前麵提到寫性能日誌時要注意日誌的性能和隱私問題，這裏在收集、上傳、更新收集規則時也要注意性能問題，可以對條件、頻率和采樣率進行限製。比如，每隔1分鍾收集一次日誌，隻有Word空閑時才能每隔十分鍾上傳1次日誌，每隔1天檢查收集規則，采樣率是隻收集千分之一的用戶，以保證大部分用戶不受收集上傳的影響。
數據中心根據上傳的性能結果生成報表，由運營人員監控。
報表的內容分三個層次：
第一是產品的性能有沒有問題（Whether）；
第二是當確定“有問題”的時候定位問題的影響範圍，比如發生時間、地區、相關設備類型，等等，也就是“問題的上下文（Where/ When/ Who/ Which）”；
第三是運營人員把確定了的問題交給開發人員進行技術診斷，也就是“為什麼會有問題（Why）”。
開發人員收到問題的上下文後，根據需要進一步要求收集在這個上下文裏更多的用戶細節數據，比如Call stack，從而找到bug，改善代碼。
圖7 性能運營
性能運營舉例
這裏對報表舉兩個例子。
第一個例子是用戶性能日誌的報表。
首先，運營查看“用戶啟動耗時直方圖”。假設既定性能目標是80%用戶要在1秒內啟動，而報表結果顯示80%的用戶啟動時間超過了1.5秒，則說明有了問題。接下來運營查看“內存大小和啟動時間”散點圖，發現在啟動超過1秒的用戶主要是內存1GB的手機用戶。這說明內存使用需要優化。
散點圖上顯示的是啟動時間的中位數，實際上我們可以畫多個分位數來刻畫分布曲線，比如50%、75%、90%、95%。同樣地，運營查看國家/地區、日期/版本號等上下文數據和啟動時間之間的相關性，從而確定問題的範圍和性質，交給開發人員。開發人員通過要求收集更詳細的日誌，得到代碼每一部分影響到的啟動秒數，從而發現瓶頸代碼，嚐試進行優化。
第二個例子是用戶在應用商店等渠道對產品性能文字反饋的報表。
首先，客服或運營收集並挖掘用戶的文字反饋信息，如圖8所示，得到性能差評占所有評價的百分比隨時間或版本變化的曲線，當發現新版本導致更多性能差評時，則說明性能有了問題。接下來運營查看差評裏具體的熱門話題榜，發現收集信息慢是抱怨最多的一項。
經過一係列定位問題的範圍，運營交給開發人員去診斷收集信息慢的原因。開發人員找到和差評相關聯的客戶端以及服務器端的詳細信息，從而定位相關的代碼並嚐試進行優化。
圖8 用戶對產品性能文字反饋的報表
這裏小結一下實驗室自動化測試，用戶日誌監控以及用戶文字反饋這三種不同的性能衡量手段，如圖9所示。本地測試在發現問題的及時性，信息的深度和可行動性方麵最好，但離用戶真實體驗較遠，也不能發現未知問題。
監控用戶文字反饋能夠近距離了解用戶的感受和需求，發現未知問題的能力很強，但有些問題等到此時發現已經得罪了用戶，而且得到的信息可能不足以幫助定位出問題的代碼。用戶日誌監控的效果介於測試和反饋之間，彌補了兩者各自的不足。要想有效地衡量用戶性能體驗，三者缺一不可。
圖9 自動化測試，用戶日誌監控和用戶反饋監控的比較
● 4.6性能開發周期小結
性能開發周期的好處有如下3點。
避免了性能問題導致用戶體驗致命缺陷，產品失敗/落後競品；
避免了開發後期由於性能問題而不得不重改架構，浪費巨大；
避免了不清楚真實用戶性能體驗，能更好地幫助商業決策。
因此，可以說，性能是用戶體驗的關鍵，需要用流程來保證。因而有了如下的性能開發周期。
團隊和產品線總體從一開始就有量化的用戶體驗目標和係統資源用量預算。
架構師和開發人員能及早發現係統設計中的性能瓶頸問題，提前修改設計。
隨著開發深入，性能測試防止新的功能不以犧牲性能目標為代價。
用戶性能運營使得運營人員和開發人員高效合作，解決用戶性能問題。
● 4.7怎樣建設一個性能團隊
我通過在Office性能團隊的工作，關於如何建設一個性能團隊有些心得。一個性能團隊的人員組成，每個人員負責的方方麵麵，以及他們和功能團隊之間的工作關係，可以用圖10所示來表示。
圖10 如何建設一個性能團隊示意圖
五、 案例啟示
Office性能團隊的價值在於：
幫助功能團隊掌握了技能，預除了隱患，倒逼了設計；
幫助Office有效地、係統化地、穩定地改進性能。
那麼我們做了哪些對的事呢？
從開發早期就滲透，貫穿了產品全周期。
了解產品功能和程序架構，從而深入地進行性能分析和debug。
了解功能團隊桌前行為，從而提供了貼心工具服務。
不間斷警覺地監測，從而使性能天天向上。
信念：性能是關鍵體驗，競爭利器！感染了功能團隊。
早期就得到了高層的“尚方寶劍”：功能團隊的合作承諾。
另外，我們對Office功能團隊也帶來了影響。幾年以前，一般認為，像性能這樣的基礎工作，做得再好也往往不像開發出產品新功能那樣顯眼，因此，大家容易到了開發後期或性能出現問題時才開始解決。然而那時程序架構早已不容易更改，後續版本的性能優化也比較難，如果出了性能問題，解決的代價往往比較高昂。
現在，Office功能團隊已經能夠充分意識到性能對產品就像地基一樣重要和優先，把產品的性能，安全等基礎質量和自己的業績評估掛鉤並且層層掛鉤下去，在產品設計一開始就充分評審討論基礎的質量，在開發周期全程留出人力密切監視基礎的質量。功能團隊開始關注性能，從被動看數據到主動向我們要數據。
總之，好的性能乘以好的功能才能保證產品的成功，兩者缺一不可。讓我們通過性能開發周期來保證軟件的成功以獲得持久發展吧！
★★征稿★★
尋找100個年度最具價值的實踐案例
我們隻要案例幹貨，拒絕廣告
成為特約作者，你將：
◆ 連接100名年度經驗與增長值TOP100的研發精英
◆ 提前入圍「壹佰案例」年度最優案例榜單
◆ 案例整理成冊，出版發行圖書
◆ 成為msup客座教練
◆ 以觀察員身份受邀出席壹佰案例
◆ 所在公司享有msup活動優惠
有意者聯係壹佰案例主編Cynthia
郵箱：fang.cheng@msup.com.cn
