背景：
《Google的性能優(yōu)化典范》一文是Android程序內(nèi)存優(yōu)化的指導(dǎo)，分別從渲染、電量、運算和內(nèi)存幾個方面闡述了優(yōu)化方向。
本文關(guān)注渲染方向：
渲染其實是指GPU渲染，是App計算--繪制--渲染 過程中的最后一步。CPU負(fù)責(zé)Measure Layout，Execute GPU負(fù)責(zé)Rasterization（柵格化）。
CPU通常存在的問題是 非必需的視圖組件、視圖層級；GPU的問題是過度繪制。
Overdraw 過度繪制：
定義：屏幕上的某個像素在同一幀的時間內(nèi)被繪制了多次
例如UI是層疊的，看不見的UI也做繪制操作，就是多余的。當(dāng)設(shè)計效果上更加華麗炫酷時，堆疊視圖層級是常見的情況，但這很容易產(chǎn)生性能問題。
怎么過度繪制打開開關(guān)和如何看，不介紹了就。
解決方案：
1.寫合理而高效的布局
Android的布局可以通過xml來實現(xiàn)，這使得開發(fā)者布局時較為隨意，只以實現(xiàn)功能為目的，忽略性能問題的累積效應(yīng)。
在開發(fā)設(shè)計之初，就應(yīng)該考慮布局的效率問題，以免出現(xiàn)后期修改的高成本。
降低Layout層級，有很多方法 不列舉了。
2.移除非必須的background: Activity的DecorView有默認(rèn)的背景色，可以改為透明
getWindow().getDecorView().setBackgroundColor(getResources().getColor(R.color.transparent));
這個顏色從ActivityTheme設(shè)置，被decorView所持有
<style name="Theme">
...
<!-- Window attributes -->
<item name="windowBackground">@drawable/screen_background_selector_dark</item>
...
</style>
screen_background_selector_dark在sdk中定義為純黑色
所以也可以android:windowbackground="null"方法來修改
后續(xù)會在Theme自定義，或BaseActivity 統(tǒng)一優(yōu)化
3.View BackGround 優(yōu)化：
- 所有的View都可以設(shè)置Background，ImageView除了可以設(shè)置BackGround外，還可以設(shè)置imageResource
在使用ImageView時，尤其是ListView ViewHolder中，可能imageView設(shè)置默認(rèn)bitmap給background，然后
真正的bitmap給imageResource，導(dǎo)致了重復(fù)繪制。解決方法是都通過imageResource設(shè)置 - 有時采用selector背景，可以normal狀態(tài)設(shè)置為transparent
4.移除不必要的背景色
比如Activity中含F(xiàn)ragment,如果Fragment有背景色而且是全屏的，Activity就不必要。
又比如ViewPager中含fragment ViewPager的背景色是不必要的
5.ClipRect
在ViewGroup的drawChild方法中，
protected boolean drawChild(Canvas canvas, View child, long drawingTime)
在ViewGroup的Canvas上繪制子child，不同的child都在同一個canvas繪制，如果view相互遮蓋，則重復(fù)繪制難免。
Canvas的clipRect方法，提供了限定繪制區(qū)域的功能，在某個child 繪制時，可以限定繪制區(qū)域為自己的顯示區(qū)域，解決了這個問題。
v4包中的DrawerLayout，就專門做了ClipRect優(yōu)化
@Override
protected boolean drawChild(Canvas canvas, View child, long drawingTime) {
final int height = getHeight();
final boolean drawingContent = isContentView(child);//是否mainContent
int clipLeft = 0, clipRight = getWidth();
//如果是繪制mainContent，則先canvas.save 再 canvas.restore
//并拿到drawerContent的right作為自己繪制的left，通過canvas.clipRect限定繪制區(qū)域
final int restoreCount = canvas.save();
if (drawingContent) {
final int childCount = getChildCount();
//此for循環(huán)找到drawerCotnent，
for (int i = 0; i < childCount; i++) {
final View v = getChildAt(i);
//注意此處對于drawerContent的篩選條件：
//visible，背景非透明!hasOpaqueBackground(v)
//如果drawerContent無背景色，此優(yōu)化直接continue,因為mainContent要全顯示
if (v == child || v.getVisibility() != VISIBLE ||
!hasOpaqueBackground(v) || !isDrawerView(v) ||
v.getHeight() < height) {
continue;
}
if (checkDrawerViewAbsoluteGravity(v, Gravity.LEFT)) {
final int vright = v.getRight();
if (vright > clipLeft) clipLeft = vright;
} else {
final int vleft = v.getLeft();
if (vleft < clipRight) clipRight = vleft;
}
}
canvas.clipRect(clipLeft, 0, clipRight, getHeight());
}
final boolean result = super.drawChild(canvas, child, drawingTime);
canvas.restoreToCount(restoreCount);
pilot端的問題就在于DrawerContent沒有背景，而是把背景設(shè)置在了里面的Fragment，導(dǎo)致DrawerLayout優(yōu)化沒有生效
此優(yōu)化一般用于自定義view中，而且控件交互存在View之間重疊的情況
Android中每個Window對應(yīng)一個Canvas，window下所有view繪制公用一個canvas，viewtree的父節(jié)點在調(diào)用child.draw之前都會根據(jù)child的layout邊界對canvas進(jìn)行裁剪，這也是為什么超過view邊界的內(nèi)容不會被顯示的原因。
但是對于各child大部分重疊的控件，會產(chǎn)生過度繪制，就需要clipRect優(yōu)化。大部分容易重疊的控件FrameLayout RelativeLayout本身沒有優(yōu)化，需要開發(fā)者根據(jù)實際情況對自定義控件進(jìn)行優(yōu)化。
優(yōu)化前：[圖片上傳失敗...(image-5fc76c-1513077609721)]
優(yōu)化后：[圖片上傳失敗...(image-87aa6e-1513077609721)]
6.善用9patch，背景圖如果只顯示邊框，選用9patch，中間的透明會被2D渲染器優(yōu)化overdraw
過度繪制的原因無外乎：復(fù)雜的Layout層級、重疊的背景、重疊的View幾種。開發(fā)人員在設(shè)計之初就要充分考慮過度繪制等性能敏感地帶，要知道等到功能實現(xiàn)之后再去改Layout層級，onDraw方法等，成本和風(fēng)險都會指數(shù)型提高。
