一個正在持續增加新功能的軟件，尤其是類似QQ這種做為一個超大規模客戶端軟件，又隨時需要適應用戶要求和發展的需求，需要不斷的做快速的更新，開 發節奏非常快。而且因為我們的用戶是海量用戶，用戶的軟硬件環境非常復雜。性能作為軟件的用戶第一體驗，如何去系統性地保障軟件的性能，對于QQ來說就變 得非常重要。
那么要讓持續開發的軟件的性能能夠得到保障，應該做些什么呢？
1、需求階段開始考慮性能
首先從需求提出階段說起，需求提出階段應該要開始考慮性能問題了，產品經理提出需求之前，必須要系統性地了解哪些因素會影響到軟件的性能，這些因素包括 但不限于：需求的處理時機，需求的處理數量，需求的處理是否涉及大的IO，網絡，以及CPU。尤其是在使用特性上要思考清楚，比如涉及到消息記錄的需求， 可能要考慮到有的用戶的消息記錄很大，比如涉及好友列表的需求，可能要考慮到有的用戶的好友列表很多等。
使用時機的話，比如需求是在登錄過程中那么可能要考慮該需求是否會影響到登錄速度，如果是在登錄后的話，是否會造成登錄后卡。
結合這些特征，對于一些從需求側就可能有問題的需求，要么考慮直接不做這個需求，要么考慮針對不同的使用特征做不同的處理，比如考慮到消息記錄可能有很 大的情況，那么涉及消息記錄的需求盡量不要去讀取整個消息記錄。有的時候，也可以考慮切換需求處理的時機，比如在更新好友資料的需求，如果是做在登錄過程 可能是會引起登錄過程很慢，那么需求可以修改成登錄過程先加載本地數據，登錄后某個空閑時機再去做必要的更新。
2、需求開發階段如何考慮性能
在一個需求開始開發之前，一個有經驗的程序員應該是要先做設計，在架構設計的過程，我們應該要考慮性能，讓架構能夠支持足夠的數據量，保持架構上能在各 種場景都不會出現性能問題。各種處理分別是在什么時機進行也是要在設計的時候就想好的，只有性能出眾的架構才是很好的架構。
在實際開發的過程，要充分考慮用戶的使用場景和并發數量，比如開發一個火車票訂票系統，如果不考慮春運的時候的特殊情況，那么最終只會在春運的時候系統直接癱瘓。
可能這個時候有人會問，春運的時候就是有那么多用戶在訪問，系統就是支持不了那么應該怎么辦呢？至少可以從兩個方面去解決，一個方面可以考慮在訪問量很 大的時候，只提供核心訂票等業務的支持，而網頁上的一些圖片什么的完全可以不提供拉取。另一方方面，可以考慮提供給系統最大支持量的用戶正常的服務，而可 以對一些超出負載的用戶提出的服務短期內進行拒絕。設置可以提供一種排隊進入的機制。
3、測試階段如何關注性能
在測試階段我們還需要做什么來保障性能呢？
首先我想強調的是，測試是保證產品的性能最終是否達標的最后保障，所以這個環節一定要嚴格要求。
從信念上來說，只要開發同學有對代碼進行修改，那么都是要懷疑可能引入性能問題的，之前我們的一個打開好友聊天窗口的時候卡的一個性能問題，就是因為在桌面快捷圖標的時候在打開聊天窗口的過程加了一行代碼。
測試方法上，要注意用接近現實的一些數據來進行測試，包括前面說到的消息記錄的大小和好友列表的數目。另外要注意覆蓋各種使用場景。最后還有一點尤其要 注意的是要注意用多種機器多種網絡環境多種軟件環境來測試，機器的話，主要包括性能好的機器和性能差的機器，機器的網絡環境的話要考慮網絡丟包比較大的一 些情況，還要集合局域網廣域網以及中國的各大運營商之間的不同網絡場景。軟件環境的話，一方面包括不同的操作系統，一方面包括同時運行和安裝的軟件環境，比如殺毒軟件，安全軟件，或者是同時在運行一些大型游戲的情況。
當然最好的情況是，建立一系列的自動化測試框架，把一些我們平常關注的重要數據，比如QQ的登錄速度，登錄后卡不卡，打開好友聊天窗口的速度等等通過自動化跑出來。通過定期進行自動化測試，同時把數據進行各個歷史版本橫向比較，最后可以做到快速監控，最快速度發現性能問題。
4、反饋跟蹤如何關注性能
產品發布之后，依然還要繼續關注它的性能。一方面由于我們的用戶群體非常大，所以難免有些情況和使用場景沒有考慮周全，所以最后運營階段沒有問題的版本才是合格的版本。
我們一般通過定期關注微博，關注產品本身的反饋論壇，以及外面的一些相關論壇來收集信息。同時關注周邊的朋友，以及同事的反饋也是一個很重要的方面。
在用戶反饋有問題的時候，應該要及時去處理，處理方法一方面要先了解用戶的使用場景和使用情況，另一方面可以給用戶一些工具，通過這些工具去記錄當時的 CPU，內存，IO的使用情況，當時是否界面有無響應等信息。同時工具最好能夠記錄在有性能問題的時候軟件正在忙什么，當時的堆棧以及系統調用函數是什 么，有了這些信息就可以快速的解決問題了。
5、總結
整體來看，貫穿整個軟件開發的過程，從需求，到設計，到開發，到測試，最后到發布反饋，都得要持續關注軟件的性能，這樣才能得到一個系統性地保證。可見，性能優化是一個需要持續運營的過程……