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

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

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

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

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

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

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

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

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

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

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

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

        如果你已經(jīng)知道復(fù)用布局的”面貌”，那么創(chuàng)建、定義布局文件( 命名以”.xml”為后綴)。例如，這里是一個(gè)來(lái)自
 G- Kenya codelab 的布局文件，定義了在每個(gè)Activity中都要使用的一個(gè)自定義標(biāo)題 (titlebar.xml):由于這些
  可復(fù)用性布局被添加至其他布局文件中，因此，它的每個(gè)根視圖(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è)來(lái)自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)識(shí)，重寫(xiě)所有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ù)用另外的布局時(shí)， <merge />標(biāo)簽?zāi)軌蛟诓季謱哟蜗嘤嗟囊晥D元素。例如，如果你的
   主布局文件是一個(gè)垂直地包含兩個(gè)View的LinearLayout，該布局能夠復(fù)用在其他布局中，而對(duì)任意包含兩個(gè)View的
   布局文件都需要一個(gè)root View(否則， 編譯器會(huì)提示錯(cuò)誤)。然而，在該可復(fù)用性布局中添加一個(gè)LinearLayout
   作為root View，將會(huì)導(dǎo)致一個(gè)垂直的LinearLayout包含另外的垂直LinearLayout。內(nèi)嵌地LinearLayout只能減緩
   UI效率，其他毫無(wú)用處可言。
            該復(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)你添加該布局文件時(shí)(使用<include />標(biāo)簽)，系統(tǒng)忽略< merge />節(jié)點(diǎn)并且直接添加兩個(gè)Button去
  取代<include />節(jié)點(diǎn)。
  
   越少越好

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

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

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

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

        如果你有的UI設(shè)計(jì)是復(fù)雜地，你應(yīng)該考慮設(shè)計(jì)一個(gè)自定義ViewGroup來(lái)實(shí)現(xiàn)layout過(guò)程。不同于內(nèi)置View控件，
  自定義View能夠假定它的每個(gè)子View的大小以及形狀，同時(shí)能夠避免為每個(gè)子View進(jìn)行measure過(guò)程。 PieChart
  展示了如何繼承ViewGroup類(lèi)。 PieChart帶有子View，但它從來(lái)沒(méi)有measure它們。相反，它根據(jù)自己的布局算法
  去直接設(shè)置每個(gè)子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圖形庫(kù)能在大多數(shù)Android設(shè)備上使用GPU(圖形處理單元)加速。GPU硬件
  加速可以極大的優(yōu)化多數(shù)應(yīng)用程序，但它并不是每個(gè)應(yīng)用程序的最優(yōu)選擇。Android框架給予你是否在應(yīng)用程序中
  使用硬件加速的控制力。

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

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

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

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

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第一次顯示的時(shí)候才會(huì)調(diào)用PieChart.PieView.onDraw()方法。在應(yīng)用程序的其他
   時(shí)間，繪制的圖像將會(huì)作為圖片緩存，重繪時(shí)GPU將任意旋轉(zhuǎn)圖像。

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

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

最新評(píng)論