2. 程式人生 > >Android UI效能優化—過度繪製篇

Android UI效能優化—過度繪製篇

阿新 • • 發佈：2019-02-04

Android UI效能優化——過度繪製篇

過度繪製（overdraw）

過度繪製介紹

每過幾年，就會有傳聞說某個博物館在用x光掃描一副無價的名畫之後，發現畫作的作者其實重用了老的畫布，在名畫的底下還藏著另一副沒有被發現的畫作。有時候，博物館還能用高階的影象技術來還原畫布上的原作。android裡面的view的繪製就是類似的情況。當android系統繪製螢幕的時候，先畫父view，然後子view，再是更深的子view等等。這會導致所有的view都被繪製到了螢幕上，就像畫家的畫布一樣，這些view都被他們的子view覆蓋住了。

簡單來說，過度繪製就是螢幕上的某個畫素點在同一幀的時間內繪製了多次。

當設計上追求更華麗的視覺效果的時候，我們就容易陷入採用越來越多的層疊元件來實現這種視覺效果的怪圈。這很容易導致大量的效能問題，為了獲得最佳的效能，我們必須儘量減少 Overdraw 的情況發生。

當我們來繪製一個介面時，會有一個 windows，然後是建立 Activity，在 Activity 裡可以建立多個 view，或 view group，view 也可以巢狀 view。這些元件從上到下分佈，上面的元件是可以被使用者看見的，而在下面的元件是不可見的，但是我們依然要花很多時間去繪製那些不可見的元件，因為在某些時候，它也可能會顯示出來。

過度繪製檢測

按照以下步驟開啟 Show GPU Overrdraw 的選項：設定 -> 開發者選項 -> 除錯GPU過度繪製 -> 顯示GPU過度繪製


藍色，淡綠，淡紅，深紅代表了4種不同程度的Overdraw情況，

藍色： 意味著overdraw 1倍。畫素繪製了兩次。大片的藍色還是可以接受的（若整個視窗是藍色的，可以擺脫一層）。
綠色： 意味著overdraw 2倍。畫素繪製了三次。中等大小的綠色區域是可以接受的但你應該嘗試優化、減少它們。
淡紅： 意味著overdraw 3倍。畫素繪製了四次，小範圍可以接受。
深紅： 意味著overdraw 4倍。畫素繪製了五次或者更多。這是錯誤的，要修復它們。

我們的目標就是儘量減少紅色 Overdraw，最理想的是藍色,一個畫素只繪製一次，合格的頁面繪製是白色、藍色為主，綠色以上區域不能超過整個的三分之一，顏色越淺越好。

可能有些人覺得不以為然，覺得沒什麼影響。話又說回來，GPU 繪製過渡對應用造成什麼影響。
實際上，GPU 繪製影響的是介面的流暢度和使用者體驗，對於好的手機可能體驗不到差距，對於差的手機，流暢度卻起著關鍵的作用。

背景過度繪製優化

下面我們來通過一個Demo來檢測過度繪製：

  • activity_overdraw ： 

    <?xml version="1.0" encoding="utf-8"?>  
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical"
    android:background="@android:color/white">

    <TextView
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:padding="@dimen/mar_pad_len_30px"
        android:textSize="@dimen/text_size_100px"
        android:text="@string/String_overdraw_list"/>

    <android.support.v7.widget.RecyclerView
        android:id="@+id/overdraw_list"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:background="@android:color/white"
        android:layout_margin="@dimen/mar_pad_len_30px"/>

</LinearLayout>

  • Recyclerview item 的佈局檔案 : 

    <?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:orientation="horizontal"
    android:paddingTop="@dimen/mar_pad_len_30px"
    android:paddingBottom="@dimen/mar_pad_len_30px">

    <ImageView
        android:id="@+id/item_img"
        android:layout_width="@dimen/mar_pad_len_100px"
        android:layout_height="@dimen/mar_pad_len_100px"
        android:layout_gravity="center_vertical"
        android:layout_margin="@dimen/mar_pad_len_20px"
        android:src="@mipmap/ic_launcher" />

    <LinearLayout
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:background="@android:color/white"
        android:orientation="vertical"
        android:layout_marginTop="@dimen/mar_pad_len_24px">

        <RelativeLayout
            android:layout_width="match_parent"
            android:layout_height="match_parent"
            android:layout_gravity="center_vertical"
            android:background="@android:color/white">

            <TextView
                android:id="@+id/item_title"
                android:layout_width="wrap_content"
                android:layout_height="wrap_content"
                android:layout_alignParentLeft="true"
                android:padding="@dimen/mar_pad_len_4px" />

            <TextView
                android:id="@+id/item_time"
                android:layout_width="wrap_content"
                android:layout_height="wrap_content"
                android:layout_alignParentRight="true"
                android:padding="@dimen/mar_pad_len_4px" />

        </RelativeLayout>

        <TextView
            android:id="@+id/item_msg"
            android:layout_width="match_parent"
            android:layout_height="match_parent"
            android:background="@android:color/white"
            android:padding="@dimen/mar_pad_len_4px" />
    </LinearLayout>

</LinearLayout>

  • Activity 程式碼：

    public class OverdrawActivity extends AppCompatActivity {

    private static final String TAG = "OverdrawActivity";

    @BindView(R.id.overdraw_list)
    RecyclerView mRecyclerView;

    private OverdrawAdapter mAdapter;

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_overdraw);
        ButterKnife.bind(this);
        initOverdrawView();
        initOverdrawData();
    }

    private void initOverdrawView() {
        mAdapter = new OverdrawAdapter(this);
        mRecyclerView.setLayoutManager(new LinearLayoutManager(this));
        mRecyclerView.setAdapter(mAdapter);
    }

    private void initOverdrawData() {
        List<TestItemBean> list = new ArrayList<>();
        for (int i = 0; i < 15; i++) {
            TestItemBean bean = new TestItemBean();
            bean.setTitle("Title " + i);
            bean.setTime("Time " + i);
            bean.setMsg("Msg is ba la ba la ba la ba la ba la!" + i);
            bean.setImgRes(R.mipmap.ic_launcher);
            list.add(bean);
        }
        mAdapter.addItems(list);
    }
}

  • Recyclerview Adapter 程式碼：

    public class OverdrawAdapter extends CommonRecyclerAdapter<TestItemBean> {

    public OverdrawAdapter(Context context) {
        super(context);
    }

    @Override
    public RecyclerView.ViewHolder onCreateViewHolder(ViewGroup parent, int viewType) {
        View view = mLayoutInflater.inflate(R.layout.layout_recycler_item, parent, false);
        return new OverdrawViewHolder(view, mItemClickListener);
    }

    @Override
    public void onBindViewHolder(RecyclerView.ViewHolder holder, int position) {
        bindView((OverdrawViewHolder) holder, getContentList().get(position));
    }

    private void bindView(OverdrawViewHolder holder, TestItemBean bean) {
        if (holder != null && bean != null) {
            holder.setTitleTxt(bean.getTitle());
            holder.setTimeTxt(bean.getTime());
            holder.setMsgTxt(bean.getMsg());
            holder.setImageView(bean.getImgRes());
        }
    }

    class OverdrawViewHolder extends RecyclerViewHolder {

        @BindView(R.id.item_title)
        TextView mTitleTxt;

        @BindView(R.id.item_time)
        TextView mTimeTxt;

        @BindView(R.id.item_msg)
        TextView mMsgTxt;

        @BindView(R.id.item_img)
        ImageView mImageView;

        public OverdrawViewHolder(View itemView, OnItemClickListener listener) {
            super(itemView, listener);
            ButterKnife.bind(this, itemView);
        }

        public void setTitleTxt(String titleTxt) {
            mTitleTxt.setText(titleTxt);
        }

        public void setTimeTxt(String timeTxt) {
            mTimeTxt.setText(timeTxt);
        }

        public void setMsgTxt(String msgTxt) {
            mMsgTxt.setText(msgTxt);
        }

        public void setImageView(int res) {
            mImageView.setImageResource(res);
            mImageView.setBackgroundColor(Color.WHITE);
        }
    }
}
  • 整體效果以及開啟過度繪製效果圖：


對比上面的參照圖，可以發現一個簡單的 RecyclerView 展示 Item，竟然很多地方被過度繪製了4X 。 那麼，其實主要原因是由於該佈局檔案中存在很多不必要的背景，仔細看上述的佈局檔案，那麼開始移除吧。

  • 不必要的Background 1
    主佈局的檔案已經是 background 為 white 了，那麼可以移除ListView的白色背景;

  • 不必要的Background 2
    主佈局的檔案已經是 background 為 white 了，Item主佈局中的 LinearLayout 的白色背景可以移除；

  • 不必要的Background 3
    主佈局的檔案已經是 background 為 white 了，Item 文字佈局中的 LinearLayout 的白色背景可以移除；

  • 不必要的Background 4
    主佈局的檔案已經是 background 為 white 了，Item 文字佈局中的 RelativeLayout 的白色背景可以移除；

  • 不必要的Background 5
    主佈局的檔案已經是 background 為 white 了，Item 文字佈局中下方的 TextView 的白色背景可以移除；

  • 不必要的Background 6
    Adapter的Bingview時，ImageView 的白色背景可以移除；

  • 不必要的Background 7
    最後一個，這個也是非常容易被忽略的，記得我們之前說，我們的這個 Activity 要求背景色是白色，我們的確在 layout 中去設定了背景色白色，那麼這裡注意下，我們的 Activity 的佈局最終會新增在 DecorView 中，這個 View 會中的背景是不是就沒有必要了，所以我們希望呼叫 mDecor.setWindowBackground(drawable);，那麼可以在 Activity 呼叫 getWindow().setBackgroundDrawable(null); 或者 getWindow().setBackgroundDrawableResource(android.R.color.transparent);。

    setContentView(R.layout.activity_overdraw);
getWindow().setBackgroundDrawable(null);
// getWindow().setBackgroundDrawableResource(android.R.color.transparent);

    下面有效果提，ActionBar上的藍色已經消失了。
    這裡有個比較重要注意點，使用了這個後一定要在自己的layout裡面加上背景，有的機型會出現問題。

好了，優化了不必要的背景後，我們來看看優化的效果：

繪圖過度繪製優化

下面我們繼續Demo走起：

  • CardView 程式碼 ：

    public class CardView extends View {

    private Bitmap[] mCards = new Bitmap[3];

    private int[] mImgId = new int[]{R.mipmap.a, R.mipmap.b, R.mipmap.c};

    public CardView(Context context) {
        super(context);
        for (int i = 0; i < mCards.length; i++) {
            Bitmap bm = BitmapFactory.decodeResource(getResources(), mImgId[i]);
            mCards[i] = Bitmap.createScaledBitmap(bm, 510, 510, false);
        }
    setBackgroundColor(Color.WHITE);
    }

    @Override
    protected void onDraw(Canvas canvas) {
        super.onDraw(canvas);
        canvas.save();
        canvas.translate(50, 200);
        for (Bitmap bitmap : mCards) {
            canvas.translate(150, 0);
            canvas.drawBitmap(bitmap, 0, 0, null);
        }
        canvas.restore();
    }
}

  • Activity 程式碼 ：

    public class ClipOverdrawActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(new CardView(this));
    }
}

  • 整體效果以及開啟過度繪製效果圖：


對比上面的參照圖，可以發現一個簡單的三個圖片展示，竟然也過度繪製了4X 。 那麼，其實主要原因是由於該三個圖片draw的時候繪製了全部區域導致互相重疊，仔細看上述的程式碼，那麼開始優化吧。

  • 修改onDraw方法 ：

    @Override
protected void onDraw(Canvas canvas) {
    super.onDraw(canvas);
    canvas.save();
    canvas.translate(50, 200);
    for (int i = 0; i < mCards.length; i++) {
        canvas.translate(150, 0);
        canvas.save();
        if (i < mCards.length - 1) {
            canvas.clipRect(0, 0, 150, mCards[i].getHeight());
        }
        canvas.drawBitmap(mCards[i], 0, 0, null);
        canvas.restore();
    }
    canvas.restore();
}

    分析得出，除了最後一張需要完整的繪製，其他的都只需要繪製部分；所以我們在迴圈的時候，給i到n-1都添加了clipRect的程式碼。

  • 去除windowbackground ： 

    getWindow().setBackgroundDrawable(null);
// getWindow().setBackgroundDrawableResource(android.R.color.transparent);

優化了以上兩點，可以看一下效果：

所以遇到類似的需要繪製的自定義view時，大家要多注意這方面的問題，這裡只是舉例clipRect方法，還有比如畫兩個圓重疊時，可以畫一個圓以及一個圓環，以此類推，這樣可以大大的減少過度繪製，優化UI效能。

過度繪製（overdraw）優化總結

  • 在佈局中，如果存在多個線性佈局重疊時，可以考慮只針對最上層的佈局設定背景色，而不需要每一個佈局（例如LinearLayout）都設定背景色，過多的相同的背景色會導致過度繪製；
  • 在設計到activity類中，如果牽涉到的佈局存在背景色，可以考慮消除視窗的背景色，減少1X的繪製。
  • 在自定義view的onDraw中，如果涉及到重疊的繪製view時，可以考慮利用區域性繪製避免過度繪製。
  • 考慮到效率和效能問題，介面是有一定重新整理頻率的，每一次重新整理都會呼叫View的onDraw方法，而View提前繪製就是在onDraw中進行，避免在onDraw建立物件，避免在onDraw進行繪製，應在建構函式中畫好，交給onDraw。

相關推薦

Android UI效能優化—過度繪製篇

Android UI效能優化——過度繪製篇 過度繪製（overdraw） 過度繪製介紹 每過幾年，就會有傳聞說某個博物館在用x光掃描一副無價的名畫之後，發現畫作的作者其實重用了老的畫布，在名畫的底下還藏著另一副沒有被發現的畫作。有時候，博物館還能用

Android UI效能優化實戰 識別繪製中的效能問題

                     1、概述2015年初google釋出了Android效能優化典範，發了16個小視訊供大家欣賞，當時我也將其下載，通過微信公眾號給大家推送了百度雲的下載地址（地址在文末，ps:歡迎大家訂閱公眾號），那麼近期google又在udacity上開了系列類的相關課程。有了上述的

Android效能優化--過度繪製

渲染機制 前提知識 android 的渲染主要分為兩個元件：1.CPU 2.GPU，由這兩者共同完成在螢幕上繪製 。 CPU：中央處理器,它集成了運算,緩衝,控制等單元,包括繪圖功能.CPU將物件處理為多維圖形,紋理(Bitmaps、Drawable

Android效能優化-過度繪製解決方案

過度繪製： 螢幕上某一畫素點在一幀中被重複繪製多次，就是過度繪製。 下圖中多個卡片跌在一起，但是隻有第一個卡片是完全可見的。背後的卡片只有部分可見。但是android系統在繪製時會將下層的卡片進行繪製，接著再將上層的卡片進行繪製。但其實，

[譯]Android UI 效能優化

。水平有限，翻譯不妥之處請多多指教。UI渲染是指從App生成幀並顯示在螢幕上的行為。為了保證使用者體驗的流暢性，App需要在16ms內渲染完一幀以達到60fps的幀率（為什麼是60fps?)。如果你的App UI渲染緩慢，那麼系統會強制跳過某些幀，使用者就會感知到介面的“口吃”，也就是卡頓。（以下三段Goog

Android UI效能優化實戰 解決佈局複雜導致的程式奔潰

1、概述 2015年初google釋出了Android效能優化典範，發了16個小視訊供大家欣賞，當時我也將其下載，通過微信公眾號給大家推送了百度雲的下載地址（地址在文末，ps:歡迎大家訂閱公眾號），那麼近期google又在udacity上開了系列類的相關課程

Android 系統性能優化（34）---Android UI 效能優化

Android官網 Slow rendering；個人覺得非常有價值，比如指出 物件分配、垃圾回收(GC)、執行緒排程以及Binder呼叫 是Android系統中常見的卡頓原因，更重要的是給出了定位和解決這些問題的方案；而非簡單地告訴你避免物件分配，減少佈局層級，減少過度

Android UI效能優化 檢測應用中的UI卡頓

一、概述 在做app效能優化的時候，大家都希望能夠寫出絲滑的UI介面，以前寫過一篇部落格，主要是基於Google當時釋出的效能優化典範，主要提供一些UI優化效能示例： 實際上，由於各種機型的配置不同、程式碼迭代歷史悠久，程式碼中可能會存在很多在U

效能優化之過度繪製篇

最近接到一個任務，優化專案中的過度繪製問題。提到過度繪製，腦海中會浮現出include，merge，ViewStub標籤，減少ViewTree的層次等等優化佈局相關，但具體怎麼進行優化，有一種無從下手的感覺。認真仔細閱讀了官方文件中關於繪製過度的講解，豁然開朗。

基於Spark UI效能優化與除錯——初級篇

Spark有幾種部署的模式，單機版、叢集版等等，平時單機版在資料量不大的時候可以跟傳統的java程式一樣進行斷電除錯、但是在叢集上除錯就比較麻煩了...遠端斷點不太方便，只能通過Log的形式進行資料分析，利用spark ui做效能調整和優化。 那麼本篇就介紹下如何利用Ui做效能分析，因為本人的經驗也不是很

Android效能優化-過度渲染

過度渲染 去除過度渲染可以從下面渲染階段的幾方面入手： 交換緩衝區階段，表示 CPU 等待 GPU 完成其工作的時間。 如果此豎條升高，則表示應用在 GPU 上執行太多工作。 命令問題階段， 表示 Android 的 2D 渲染器向 OpenGL 發起繪製和重

android效能優化實戰前篇

本文地址：http://blog.csdn.net/iamws/article/details/51629160 前言：         最近因為某專案cpu，記憶體的使用率實在讓人不敢恭維；手機發燙，電量下降已經讓使用者無法忍受；頻繁快速迭代發版導致各種效能問題突出；由

[看圖說話] 基於Spark UI效能優化與除錯——初級篇

Spark有幾種部署的模式，單機版、叢集版等等，平時單機版在資料量不大的時候可以跟傳統的java程式一樣進行斷電除錯、但是在叢集上除錯就比較麻煩了...遠端斷點不太方便，只能通過Log的形式進行資料分析，利用spark ui做效能調整和優化。 那麼本篇就介紹下如何利用Ui做效

[Android 效能優化系列]佈局篇之減少你的介面層級

轉載請標明出處(http://blog.csdn.net/kifile),再次感謝 在接下來的一段時間裡，我會每天翻譯一部分關於效能提升的Android官方文件給大家 效能優化之佈局篇: 題外話: 複雜的佈局，既會提高我們的設計難度，也會降低我們的程式碼效

Android 效能優化之String篇

Android 效能優化之 String篇 關於String相關知識都是老掉牙的東西了，但我們經常可能在不經意的String 字串拼接的情況下浪費記憶體，影響效能，也常常會成為觸發記憶體OOM的最後一步。 所以本文對String字串進行深度解析，有

Android UI效能專項測試及優化

1 UI卡頓（Jank） 內容的快速載入很重要，渲染的流暢性也很重要。android團隊把滯緩，不流暢的動畫定義為jank，一般是由於丟幀引起的。安卓裝置的螢幕重新整理率一般是60幀每秒（1/60fps＝16.6ms每幀），所以你想要渲染的內容能在16ms內完

Android效能優化之工具篇 — — Android Lint

Lint簡介 Android lint是在ADT16提供的新工具，它是一個程式碼掃描工具，能夠幫助我們識別資源、程式碼結構存在的問題。 Lint優化哪些問題 遺漏的翻譯（沒用上的翻譯）比如國際化未被翻譯的欄位值 佈局效能（以前是 layoutop

Android App效能優化之UI流暢度優化

一、卡頓的問題本質 UI流暢度的優化主要是解決UI卡頓的現象，而UI卡頓的源頭就是渲染效能的問題。佈局太複雜或者是一個元素重複繪製多次等原因，Android系統無法及時完成那些複雜的介面渲染操作，這樣就發生了丟幀，使用者就會感覺到不流暢，卡頓。 Androi

Android效能優化之記憶體篇

Google近期在Udacity上釋出了Android效能優化的線上課程，分別從渲染，運算與記憶體，電量幾個方面介紹瞭如何去優化效能，這些課程是Google之前在Youtube上釋出的Android效能優化典範專題課程的細化與補充。 下面是記憶體篇章的學習筆記，部分內容與前面的效能優化典範有重合，歡

Android效能優化之檢視篇（渲染機制）

** 本篇重點是——–如何解決過度繪製 ** 眾所周知的Android系統每隔16ms重新繪製一次activity，也就是說你的app必須在16ms內完成螢幕重新整理的所有邏輯操作，這樣才能達到60幀/s。而使用者一般所看到的卡頓是由於Android的