一個通常的錯誤觀念就是使用基本的布局結(jié)構(gòu)(例如：LinearLayout、FrameLayout等)能夠在大多數(shù)情況下
   產(chǎn)生高效率 的布局。 顯然，你的應(yīng)用程序里添加的每一個控件和每一個布局都需要初始化、布局(layout)、
   繪制 (drawing)。舉例來說：嵌入一個LinearLayout會產(chǎn)生一個太深的布局層次。更嚴(yán)重的是，嵌入幾個使
   用 layout_weight屬性的LinearLayout 將會導(dǎo)致大量的開銷，因?yàn)槊總€子視圖都需要被測量兩次。這是反復(fù)解析
   布局文件時重要的一點(diǎn)，例如在ListView或者GridView中使用時。

 觀察你的布局
 
     Android SDK 工具箱包括一個稱作“ Hierarchy Viewer”的工具，它允許你去在你的應(yīng)用程序運(yùn)行時分析
  布局。通過使用這個工具，能幫助你發(fā)現(xiàn)你的布局效率上的瓶頸問題。
 
     “ Hierarchy Viewer”工具允許你在已連接的設(shè)備或模擬器中選擇正在運(yùn)行的進(jìn)程，然后呈現(xiàn)出布局層次樹
   (layout tree)。每個正方塊下的交通燈(見下圖) --- 紅綠藍(lán)表現(xiàn)出了在測量(measure)、布局(layout)、以及繪制
   (draw)過程中的效率值，這能幫助你定位潛在的問題。
 
        假設(shè)ListView 中的一項(xiàng)Item 存在如下(見圖 1)布局 ：

 “Hierarchy Viewer”工具可以在 <sdk>/tools路徑下找到。當(dāng)打開它時，“ Hierarchy Viewer”工具顯示了
   所有可用的設(shè)備以及運(yùn)行在這些設(shè)備上的進(jìn)程。點(diǎn)擊”Load View Hierarchy”來顯示某個你選擇的組件的UI布局
  層次。舉例來說，圖2展現(xiàn)了圖1的布局層次樹。

  在圖2中，你可以直觀看到這個三層的布局結(jié)構(gòu)是存在一些問題的。點(diǎn)擊項(xiàng)體現(xiàn)出了在每個測量(measure)、
    布局(layout)、以及繪制(draw)過程中的時間消耗(見圖3)。很明顯，該項(xiàng)(LinearLayout)花費(fèi)了最長的時間去
    測量、布局、繪制，你應(yīng)該花點(diǎn)精力去優(yōu)化它們。

 完成該布局文件渲染的時間分別為：
                測量過程：0.977ms
                布局過程： 0.167ms
                繪制過程：2.717ms
 
 修改布局文件
 
       由于上圖中布局效率的低下是因?yàn)橐粋€內(nèi)嵌的 LinearLayout控件，通過扁平化布局文件----讓布局變得
  更淺更寬，而不是變得更窄更深層次 ，這樣就能提升效率了。 一個RelativeLayout 作為根節(jié)點(diǎn)也能提供如上
  的布局效果(即圖1)。 因此，  使用RelativeLayout 改變布局的設(shè)計(jì)，你可以看到現(xiàn)在我們的布局層次只有2層了。
  新的布局層次樹如下：

  現(xiàn)在，完成該布局文件渲染的時間分別為：
                      測量過程：0.977ms
                      布局過程：0.167ms
                      繪制過程：2.717ms
  
      也許它只是一點(diǎn)點(diǎn)微小的改進(jìn)，但這次它會被多次調(diào)用，因?yàn)槭荓istView會布局所有的Item，累積起來，
 改進(jìn)后效果還是非?？捎^地。

      大部分的時間差異是由于使用了帶有l(wèi)ayout_weight 屬性的LinearLayout ，它能減緩測量過程的速度。這僅僅
 是一個例子，即每個布局都應(yīng)該合適地被使用以及你應(yīng)該認(rèn)真考慮是否有必要采用“l(fā)ayout_weight" 屬性。
 
 使用Lint工具 

        一個好的實(shí)踐就是在你的布局文件中使用Lint工具去尋求可能優(yōu)化布局層次的方法。Lint已經(jīng)取代了Layoutopt
  工具并且它提供了更強(qiáng)大的功能。一些Lint規(guī)則如下：

  1、使用組合控件 --- 包含了一個  ImageView 以及一個 TextView 控件的 LinearLayout 如果能夠作為一個
     組合控件將會被更有效的處理。
 2、合并作為根節(jié)點(diǎn)的幀布局(Framelayout)  ----如果一個幀布局時布局文件中的根節(jié)點(diǎn)，而且它沒有背景圖片
  或者padding等，更有效的方式是使用<merge />標(biāo)簽替換該< Framelayout />標(biāo)簽 。

                                        
 3、無用的葉子節(jié)點(diǎn)----- 通常來說如果一個布局控件沒有子視圖或者背景圖片，那么該布局控件時可以被移除
       (由于它處于 invisible狀態(tài))。
 
 4、無用的父節(jié)點(diǎn) -----  如果一個父視圖即有子視圖，但沒有兄弟視圖節(jié)點(diǎn)，該視圖不是ScrollView控件或者
    根節(jié)點(diǎn)，并且它沒有背景圖片，也是可以被移除的，移除之后，該父視圖的所有子視圖都直接遷移至之前父視圖
    的布局層次。同樣能夠使解析布局以及布局層次更有效。
 
 5、過深的布局層次  ----內(nèi)嵌過多的布局總是低效率地?？紤]使用一些扁平的布局控件，例如 RelativeLayout、
      GridLayout ，來改善布局過程。默認(rèn)最大的布局深度為10 。
 
 
     當(dāng)使用Eclipse環(huán)境開發(fā)時，Lint能夠自動解決一些問題，提供一些建議以及直接跳轉(zhuǎn)到出錯的代碼中去核查。
  如果你沒有使用Eclipse，Lint也可以通過命令行的方式運(yùn)行。
  
  使用<include />標(biāo)簽復(fù)用布局文件
       盡管Android通過內(nèi)置了各種各樣的控件提供了微小、可復(fù)用的交互性元素，也許你需要復(fù)用較大的
     組件 ---- 某些特定布局文件 。為了更有效率復(fù)用的布局文件，你可以使用<include />以及<merge />
     標(biāo)簽將其他的布局文件加入到當(dāng)前的布局文件中。

          復(fù)用布局文件是一種特別強(qiáng)大的方法，它允許你創(chuàng)建可復(fù)用性的布局文件。例如，一個包含“Yse”or“No”的
     Button面版，或者是帶有文字說明的 Progressbar。復(fù)用布局文件同樣意味著你應(yīng)用程序里的任何元素都能從
     繁雜的布局文件提取出來進(jìn)行單獨(dú)管理，接著你需要做的只是加入這些獨(dú)立的布局文件(因?yàn)樗麄兌际强蓮?fù)用地)。
     因此，當(dāng)你通過自定義View創(chuàng)建獨(dú)立的UI組件時，你可以復(fù)用布局文件讓事情變得更簡單。

 1、創(chuàng)建一個可復(fù)用性的布局文件

        如果你已經(jīng)知道復(fù)用布局的”面貌”，那么創(chuàng)建、定義布局文件( 命名以”.xml”為后綴)。例如，這里是一個來自
 G- Kenya codelab 的布局文件，定義了在每個Activity中都要使用的一個自定義標(biāo)題 (titlebar.xml):由于這些
  可復(fù)用性布局被添加至其他布局文件中，因此，它的每個根視圖(root View)最好是精確(exactly)的。

<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android" 
 android:layout_width=”match_parent” 
 android:layout_height="wrap_content" 
 android:background="@color/titlebar_bg"> 
 
 <ImageView android:layout_width="wrap_content" 
    android:layout_height="wrap_content" 
    android:src="@drawable/gafricalogo" /> 
</FrameLayout> 

 2、使用<include />標(biāo)簽

          在需要添加這些布局的地方，使用<include />標(biāo)簽 。 例如，下面是一個來自G-Kenya codelab的布局文件，
  它復(fù)用了上面列出的“title bar”文件， 該布局文件如下：

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" 
 android:orientation="vertical" 
 android:layout_width=”match_parent” 
 android:layout_height=”match_parent” 
 android:background="@color/app_bg" 
 android:gravity="center_horizontal"> 
 
 <include layout="@layout/titlebar"/> 
 
 <TextView android:layout_width=”match_parent” 
    android:layout_height="wrap_content" 
    android:text="@string/hello" 
    android:padding="10dp" /> 
 
 ... 
 
</LinearLayout> 

       
          你也可以在<include />節(jié)點(diǎn)中為被添加的布局文件的root View定義特別標(biāo)識，重寫所有l(wèi)ayout參數(shù)即可(任何
  以“android：layout_”為前綴的屬性)。例如：

<include android:id=”@+id/news_title” 
   android:layout_width=”match_parent” 
   android:layout_height=”match_parent” 
   layout=”@layout/title”/> 

 3、使用<merge />標(biāo)簽

        當(dāng)在布局文件中復(fù)用另外的布局時， <merge />標(biāo)簽?zāi)軌蛟诓季謱哟蜗嘤嗟囊晥D元素。例如，如果你的
   主布局文件是一個垂直地包含兩個View的LinearLayout，該布局能夠復(fù)用在其他布局中，而對任意包含兩個View的
   布局文件都需要一個root View(否則， 編譯器會提示錯誤)。然而，在該可復(fù)用性布局中添加一個LinearLayout
   作為root View，將會導(dǎo)致一個垂直的LinearLayout包含另外的垂直LinearLayout。內(nèi)嵌地LinearLayout只能減緩
   UI效率，其他毫無用處可言。
            該復(fù)用性布局利用.xml呈現(xiàn)如下：

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" 
  android:orientation="vertical" 
  android:layout_width=”match_parent” 
  android:layout_height=”match_parent” 
  android:background="@color/app_bg" 
  android:gravity="horizontal"> 
 
 <Button 
  android:layout_width="fill_parent" 
  android:layout_height="wrap_content" 
  android:text="@string/add"/> 
 
 <Button 
  android:layout_width="fill_parent" 
  android:layout_height="wrap_content" 
  android:text="@string/delete"/> 
</LinearLayout> 

      為了避免冗余的布局元素，你可以使用<merge />作為復(fù)用性布局文件地root View 。例如：
           使用<merge />標(biāo)簽的布局文件：

<merge xmlns:android="http://schemas.android.com/apk/res/android"> 
 
 <Button 
  android:layout_width="fill_parent" 
  android:layout_height="wrap_content" 
  android:text="@string/add"/> 
 
 <Button 
  android:layout_width="fill_parent" 
  android:layout_height="wrap_content" 
  android:text="@string/delete"/> 
 
</merge> 

         現(xiàn)在，當(dāng)你添加該布局文件時(使用<include />標(biāo)簽)，系統(tǒng)忽略< merge />節(jié)點(diǎn)并且直接添加兩個Button去
  取代<include />節(jié)點(diǎn)。
  
   越少越好

        為了加速視圖，從那些調(diào)用頻繁的活動中減少不必要的代碼。在OnDraw()方法中開始繪制，它會給你最大的
   效益。特別低，你也應(yīng)該減少在onDraw()方法中的內(nèi)存分配，因?yàn)槿魏蝺?nèi)存分配都可能導(dǎo)致內(nèi)存回收，這將會
   引起不連貫。 在初始化或者動畫之間分配對象。絕不要在動畫運(yùn)行時分配內(nèi)存。

        另一方面需要減少onDraw()方法中的開銷，只在需要時才調(diào)用onDraw()方法。通常invalidate()方法會調(diào)用
  onDraw()方法，因此減少對invalidate()的不必要調(diào)用。如果可能，調(diào)用它的重載版本即帶有參數(shù)的invalidate()
  方法而不是無參的invalidate()方法。該帶參數(shù)的方法invalidate()能使draw過程更有效，以及減少對落在該矩形
  區(qū)域(參數(shù)指定的區(qū)域)外視圖的不必要重繪 。

       注，invalidate()的三個重載版本為：
            1 、public void invalidate (Rect dirty)
            2、public void invalidate (int l, int t, int r, int b)
            3、public void invalidate ()

        另外的一個高代價的操作是布局過程(layout)。 任何時刻對View調(diào)用requestLayout()方法，Android UI 框架
  都需要遍歷整個View樹，確定每個視圖它們所占用的大小。如果在measure過程中有任何沖突，可能會多次遍歷
  View樹。UI設(shè)計(jì)人員有時為了實(shí)現(xiàn)某些效果，創(chuàng)建了較深層次的ViewGroup。但這些深層次View樹會引發(fā)效率
  問題。確保你的View樹層次盡可能淺。

        如果你有的UI設(shè)計(jì)是復(fù)雜地，你應(yīng)該考慮設(shè)計(jì)一個自定義ViewGroup來實(shí)現(xiàn)layout過程。不同于內(nèi)置View控件，
  自定義View能夠假定它的每個子View的大小以及形狀，同時能夠避免為每個子View進(jìn)行measure過程。 PieChart
  展示了如何繼承ViewGroup類。 PieChart帶有子View，但它從來沒有measure它們。相反，它根據(jù)自己的布局算法
  去直接設(shè)置每個子View的大小。
         
       如下代碼所示：

/** 
 * Custom view that shows a pie chart and, optionally, a label. 
 */ 
public class PieChart extends ViewGroup { 
 ... 
 // 
 // Measurement functions. This example uses a simple heuristic: it assumes that 
 // the pie chart should be at least as wide as its label. 
 // 
 @Override 
 protected int getSuggestedMinimumWidth() { 
  return (int) mTextWidth * 2; 
 } 
 @Override 
 protected int getSuggestedMinimumHeight() { 
  return (int) mTextWidth; 
 } 
 
 @Override 
 protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) { 
  // Try for a width based on our minimum 
  int minw = getPaddingLeft() + getPaddingRight() + getSuggestedMinimumWidth(); 
 
  int w = Math.max(minw, MeasureSpec.getSize(widthMeasureSpec)); 
 
  // Whatever the width ends up being, ask for a height that would let the pie 
  // get as big as it can 
  int minh = (w - (int) mTextWidth) + getPaddingBottom() + getPaddingTop(); 
  int h = Math.min(MeasureSpec.getSize(heightMeasureSpec), minh); 
 
  setMeasuredDimension(w, h); 
 } 
 
 @Override 
 protected void onLayout(boolean changed, int l, int t, int r, int b) { 
  // Do nothing. Do not call the superclass method--that would start a layout pass 
  // on this view's children. PieChart lays out its children in onSizeChanged(). 
 } 
  
 @Override 
 protected void onSizeChanged(int w, int h, int oldw, int oldh) { 
  super.onSizeChanged(w, h, oldw, oldh); 
 
  // 
  // Set dimensions for text, pie chart, etc 
  // 
  // Account for padding 
 
  ... 
 
  // Lay out the child view that actually draws the pie. 
  mPieView.layout((int) mPieBounds.left, 
    (int) mPieBounds.top, 
    (int) mPieBounds.right, 
    (int) mPieBounds.bottom); 
  mPieView.setPivot(mPieBounds.width() / 2, mPieBounds.height() / 2); 
 
  mPointerView.layout(0, 0, w, h); 
  onDataChanged(); 
 } 
 
} 

使用硬件加速

          Android 3.0版本后，Android 2D圖形庫能在大多數(shù)Android設(shè)備上使用GPU(圖形處理單元)加速。GPU硬件
  加速可以極大的優(yōu)化多數(shù)應(yīng)用程序，但它并不是每個應(yīng)用程序的最優(yōu)選擇。Android框架給予你是否在應(yīng)用程序中
  使用硬件加速的控制力。

值得注意的是，我們必須手動在配置文件中設(shè)置應(yīng)用程序API級別為11或者更高級別，即在 AndroidManifest.xml進(jìn)行如下配置：
 

 <uses-sdk android:targetSdkVersion="11"/>

         一旦你開啟了硬件加速，你可能看不到效率的提升。Mobile GPUs 善于處理特定的任務(wù)，例如：伸縮、旋轉(zhuǎn)、
   平移圖片。它也有一些不擅長處理的任務(wù)，例如：繪制直線或曲線。常言道物盡其用，揚(yáng)長避短，盡可能讓GPU
   處理它擅長的任務(wù)，減少讓其處理弱勢任務(wù)的。

         在PieChart 示例中，例如，相對來說繪制一個圓形是比較耗費(fèi)資源的。每次旋轉(zhuǎn)引起的重繪導(dǎo)致UI的遲緩。
   解決辦法就是讓View來呈現(xiàn)該圓形，并且設(shè)置該View的layer type屬性為 LAYER_TYPE_HARDWARE,因此GPU
   能夠緩存靜態(tài)圖片。示例中該View作為 PieChart類的內(nèi)部類存在，減少了為了實(shí)現(xiàn)這個方法的代碼開銷。

private class PieView extends View { 
 
 public PieView(Context context) { 
  super(context); 
  if (!isInEditMode()) { 
   setLayerType(View.LAYER_TYPE_HARDWARE, null); 
  } 
 } 
  
 @Override 
 protected void onDraw(Canvas canvas) { 
  super.onDraw(canvas); 
 
  for (Item it : mData) { 
   mPiePaint.setShader(it.mShader); 
   canvas.drawArc(mBounds, 
     360 - it.mEndAngle, 
     it.mEndAngle - it.mStartAngle, 
     true, mPiePaint); 
  } 
 } 
 
 @Override 
 protected void onSizeChanged(int w, int h, int oldw, int oldh) { 
  mBounds = new RectF(0, 0, w, h); 
 } 
 
 RectF mBounds; 
} 

          改變之后，只有View第一次顯示的時候才會調(diào)用PieChart.PieView.onDraw()方法。在應(yīng)用程序的其他
   時間，繪制的圖像將會作為圖片緩存，重繪時GPU將任意旋轉(zhuǎn)圖像。

         然而這只是一個折中手段。緩存圖片作為硬件層導(dǎo)致 video memory開銷，video memory卻是一種受限制的
 資源。 出于這個原因，在PieChart.PieView的最終版本上，只有在用戶滑動時才設(shè)置它的layer type屬性為
  LAYER_TYPE_HARDWARE。在其他時間，僅僅設(shè)置它的layer type屬性為 LAYER_TYPE_HARDWARE，這
  允許GPU停止緩存圖片。

        最后，不要忘記分析你的代碼。在一個View上做的優(yōu)化技術(shù)可能會在其他View上產(chǎn)生不好的影響。