常見問題

• 性能優化通用方法

  緩存：沒有什么性能問題是緩存解決不了的，如果有，那就再加一級緩存。緩存的本質是加速訪問，需要用空間換時間，在緩存空間有限的情況下，需要優秀的置換換算來保證緩存有較高的命中率。
  并發：一個人干不完的活，那就找兩個人干。并發既增加了系統的吞吐，又減少了用戶的平均等待時間。這里的并發是指廣義的并發，粒度包括多機器（集群）、多進程、多線程。
  惰性：將計算推遲到必需的時刻，這樣很可能避免了多余的計算，甚至根本不用計算。
  批量：在有IO（網絡IO，磁盤IO）的時候，合并操作、批量操作往往能提升吞吐，提高性能。
  更高效的實現：同一個算法，肯定會有不同的實現，那么就會有不同的性能；有的實現可能是時間換空間，有的實現可能是空間換時間，那么就需要根據自己的實際情況權衡。
  縮小解空間：縮小解空間的意思是說，在一個更小的數據范圍內進行計算，而不是遍歷全部數據。索引就是其中一種，通過索引，能夠很快定位數據，對數據庫的優化絕大多數時候都是對索引的優化。其他如權限校驗，排除超過權限范圍的數據也是常用的方法。
   

• 性能優化注意事項

  性能優化的目的，就是為了提供給用戶更好的體驗，這些體驗包含這幾個方面：展示更快、交互響應快、頁面無卡頓情況。
   
  在用戶輸入url到站點完整把整個頁面展示出來的過程中，通過各種優化策略和方法，讓頁面加載更快；在用戶使用過程中，讓用戶的操作響應更及時，有更好的用戶體驗。對于前端工程師來說，要做好性能優化，需要理解瀏覽器加載和渲染的本質。理解了本質原理，才能更好的去做優化。所以我們先來看看瀏覽器架構是怎樣的。
   
   

• 性能優化常用工具

  性能優化其實就是找出應用存在性能瓶頸點，然后設法通過一些調優手段去緩解。性能瓶頸點的定位是較困難的，快速、直接地定位到瓶頸點，需要具備下面兩個條件，恰到好處的工具和一定的性能優化經驗。
   
  一、應用codeReview工具
  1、StrictMode：檢測應用主線程不規范代碼。
  2、Lint：AS中提供的代碼分析工具，它能夠檢查出代碼當中存在的問題，定義該問題的嚴重程度，并給出相應的解決方案，這樣我們就可以快速地定位和修復問題。如果自定義一套Lint檢測工具，那非常強大。
   
  二、內存問題分析工具
  1、Allocation Tracker 查看堆內存分配情況，可以直接跳轉源碼
  2、Heap Viewer：查看堆內存分配數據，提供初步判斷
  3、命令 android：內存分析系統開發必備，當然，對app內存分析也是非常不錯的幫手
  4、對cpu、memory、network進行更全面直觀的分析，屬于androidProfiler monitor加強版
   
   

• 性能優化一般性原則

  1、依據數據而不是憑空猜測
  懷疑性能有問題時，應通過測試、日志、profillig等手段分析哪里出現了問題。有可能是CPU、內存、IO（磁盤IO，網絡IO）等，定位大方向可以使用top及stat系列來定位（vmstat，iostat，netstat等），針對單個進程，可以使用pidstat分析。
  2、忌過早優化
  在典型的互聯網應用開發與編程模式下，追求的是快速迭代與試錯。過早優化往往是無用功，而且過早優化很容易導致優化的點不是真正的性能瓶頸。
  3、忌過度優化
  性能優化的目標是追求合適的性價比。
  4、深入理解業務
  代碼是服務于業務的，也許是服務于最終用戶，也許是服務于其他程序員。不了解業務，很難理解系統流程，很難找出系統設計的不足之處。
  5、性能優化是持久戰
  當核心業務方向明確后，應該開始關注性能問題。當項目上線后，更應持續進行性能檢測與優化。現在的互聯網產品，在上線之后還需持續開發。用戶的涌入會帶來性能問題，因此需要自動化檢測性能問題，保持穩定的測試環境，持續的發現并解決性能問題，而不是被動地等待用戶投訴。
  6、選擇合適的衡量指標、測試用例、測試環境
  性能優化是一個長期的行為，需要固定衡量指標、測試用例、測試環境，才能客觀反映性能的實際情況，展現優化效果。衡量性能的指標有以下幾個，比如：系統響應時間、系統吞吐量、系統并發量。不同的系統核心指標不一樣，首先要明確系統的核心性能訴求，固定測試用例；其次也要兼顧其他指標。
   
   

• 性能優化層次

  性能優化的層次可以分為需求階段，設計階段，實現階段。越上層的階段優化效果越明顯，同時也更需要對業務、需求的深入理解。
   
  需求階段
  程序員的需求可能來自PM、UI的業務需求（或者說是功能性需求），也可能來自Team Leader的需求。拿到一個需求時，首先需要思考、討論需求的合理性，而不是立刻去設計、去編碼。需求是為了解決某個問題，問題是本質，需求是解決問題的手段。需求討論的前提是對業務的深入了解，即使需求已經實現了，當我們發現性能有問題的時候，也可以從需求出發。
  需求分析對性能優化的幫助：1、為了達到同樣的目的，解決同樣的問題，也許可以有性能更優（消耗更小）的辦法。這種優化是無損的，即不改變需求本質，又能達到性能優化的目的；2、有損的優化，即在不明顯影響用戶體驗的條件下，稍微修改需求、放寬條件，就能大大解決性能問題。
   
  設計階段
  設計包括架構設計、技術選型、接口設計等等。架構設計約束了系統的擴展、技術選型決定了代碼實現。編程語言、框架都是工具，不同的系統、業務需要選擇適當的工具集。如果設計的時候做的不夠好，那么后面就很難優化，甚至需要推倒重來。
   
  實現階段
  實現是把功能翻譯成代碼的過程，這個層面的優化，主要是針對一個調用流程，一個函數，一段代碼的優化。各種profile工具也主要是在這個階段生效。除了靜態的代碼優化，還有編譯時優化，運行時優化。代碼層面，造成性能瓶頸的原因通常是高頻調用的函數、或者單次消耗非常高的函數、或者二者的結合。