Android性能典範:拯救計劃

現如今的app都離不開動畫,複雜的切換和自己定義View,用戶體驗必須直觀的而且在任何設備上保持一致。這些模式會幫助你去構建一個平滑的,敏捷的用電儘可能少的app,它包括微優化可以提高應用程序的整體性能。

避免糟糕表現的模式

  • 避免阻塞主線程
  • 避免不必要的失效引發更多的失效
  • 在高的層次結構中作用RelativeLayout
  • 避免在LinearLayout中嵌套Weight(會導致子控件被測量兩次)
  • 避免自定View不正確
  • 避免創建不必要的對象
  • 用static final 修飾常量(static 要快15%-20%)
  • 使用原生類型(像Integer和Float這些封裝類要慢2倍)
  • 避免內部的Getters/Setters方法(直接訪問字段要快3倍)
  • 使用增強性循環語句(foreach)
  • 當有內部類訪問外部類字段的時候考慮使用包級訪問代替私有訪問對外部類字段的修飾(編譯器會增加方法來不訪問外部類中的私有字段)
  • 小心使用Native方法

自定義View

  • 儘量保持簡單
  • 用merge標籤作爲你的Layout的根佈局(避免inflation額外的ViewGroup)
  • 使用inclue標籤(重複使用共用的佈局)
  • 避免不必要的layout
  • 不要將內存分配和過重的操作放在onDraw方法裏
  • 移除不必要的invalidate()方法的調用
  • 考慮寫你自己的ViewGroup
  • 使用RecyclerView代替ListView和GridView

避免內存擾動

  • 避免創建出大量不必要的對象,如下
    * 不可改變的類(String)*
    * 自己裝箱:Integer,Boolean*
  • 考慮使用對象池和緩存來減少擾動
  • 注意枚舉的開銷(一個枚舉的常量引用佔用4個字節)

避免內存泄露

  • 避免Context引起的內存泄露
  • 不要在activity中泄露view
  • 儘量用靜態內部類代替非靜態內部類
  • 不要使用WeakHashMap作爲緩存。只有鍵是WeakPeference

CPU

  • 不要嵌套多重佈局
  • 在複雜的數據被需要時才計算它
  • 緩存經過複雜計算的結果來爲重用做準備
  • 要考慮渲染腳本的性能
  • 主線程能隨時工作

避免過渡渲染

  • 精簡你的drawables
  • 具體情況下使用.9.png
  • 在你的view裏面小心設置alpha值
  • 從你的view中移除不用的背景

Bitmaps

  • 解碼bitmaps到想要的尺寸:BitmapFactory.Options(inSampleSize,inDensity,inTargetDensity)
  • 在bitmap將在顯示時加載加到內存中
  • 如果你不需要就不要去縮放(createScaledBitmap(bitmap,int ,int))
  • 使用LRU緩存

Service

  • 當這個service不再工作的時候就不要讓它運行,當它工作完成後也要小心的關閉它
  • 系統會優先保持服務進程的正常運行。RAM會被service使用而不能被其它使用或Service不能被paged out。
  • 限制你service的壽命最好的方法就是使用IntentService,一旦執行完調用它的intent的時候就會儘快地finish自己的。
  • 讓一個不需要運行的service運行的是一個糟糕的內存管理錯誤。

Thread

  • 在一個線程的run方法裏面使用Process.setThreadPriority() ,用THREAD_PRIORITY_BACKGROUND.來設置該方法,這個辦法可以減少其它線程和主線程之間的資源競爭。
  • 如果你沒有將線程設置爲低優先級,那麼這個線程可能會拖慢你的程序因爲它默認的優先級與注線程的一樣
  • 存儲這個線程的引用方便你去中斷這個線程,比如:如果連網失敗你可以取消這個線程的操作。

避免ANR

  • 儘量讓主線程少做事。
  • 如果你的app在後臺響應用戶的輸入,顯示出這個操作的進展(比如顯示出ProgressBar).
  • 使用Systrace和Traceview這類的性能工具來表明你的app在響應過程中碰到的瓶頸。
  • 如果你的應用在初始化階段有耗時操作,考慮使用加載界面或者儘快的渲染主界面,表明正在加載和異步地填充信息。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章