前篇博客翻箱倒柜的介紹了優(yōu)化UI設(shè)計(jì)的兩個(gè)方法，***個(gè)就是使用盡量少的組件來(lái)實(shí)現(xiàn)布局功能，第二個(gè)就是使用<meger>標(biāo)簽來(lái)減少不必要的根節(jié)點(diǎn)，這兩個(gè)方法都可以提高應(yīng)用UI的運(yùn)行效率，但是夠了嗎？遠(yuǎn)遠(yuǎn)是不夠的，方法就像money一樣永遠(yuǎn)不嫌多，所以不再介紹多一些UI設(shè)計(jì)優(yōu)化的方法說(shuō)得過(guò)去么？

摸摸口袋里面的都快四歲、運(yùn)行著古老的android 2.2系統(tǒng)的屌絲機(jī)對(duì)于我來(lái)說(shuō)，隨便一個(gè)大于10M的應(yīng)用都有完爆他幾條街死機(jī)崩潰的超能力。但是對(duì)于某信來(lái)說(shuō)，如今已經(jīng)24M大小的它依然在屌絲機(jī)瀕臨垂死的硬件資源上運(yùn)行如飛（至少?zèng)]崩潰過(guò)），讓我不得不感嘆應(yīng)用優(yōu)化做的相當(dāng)不錯(cuò)，也滿足我們這種屌絲在深深的寂寞夜晚來(lái)?yè)u一發(fā)的情感需求。所以來(lái)說(shuō)，一個(gè)應(yīng)用能贏得市場(chǎng)，不僅僅是贏得先機(jī)，而更多的是因?yàn)橄嗤枨笏δ茏龅谋饶愫茫嗤δ芩饶愕暮?jiǎn)約，相同簡(jiǎn)約設(shè)計(jì)它運(yùn)行比你快！

排隊(duì)，一個(gè)一個(gè)慢慢來(lái)

當(dāng)ActivityA跟ActivityB打招呼說(shuō)：“偶要回家了，你來(lái)頂上”。說(shuō)明就馬上溜得無(wú)影無(wú)蹤，這時(shí)候急呀，ActivityB趕緊measure呀、layout呀、draw呀趕緊搞出一個(gè)界面來(lái)應(yīng)付觀眾先，忙的不亦樂(lè)乎；更要命這時(shí)候的是他們還要搞一個(gè)交接儀式——超炫超牛的切換動(dòng)畫！然而在日益無(wú)窮大的欲望與逐漸干癟的資源這強(qiáng)大的根本矛盾下，毫不猶豫的當(dāng)機(jī)了幾百毫秒。這一卡頓讓手機(jī)前的強(qiáng)迫癥患者來(lái)說(shuō)是多大的心理創(chuàng)傷，自然而然會(huì)說(shuō)：“這軟件真渣！切個(gè)畫面都會(huì)總得頓一下才死心”。用戶體驗(yàn)瞬間降為0~

解決方案有哪些？當(dāng)然很簡(jiǎn)單的就是，取消牛逼哄哄的切換動(dòng)畫咯，但是如果你的產(chǎn)品經(jīng)理死活不同意那還不得另尋途徑。在不放棄動(dòng)畫的前提下，我們可以把某些measure呀、layout呀、draw呀的步驟延遲在動(dòng)畫后面執(zhí)行不就行咯，排隊(duì)一個(gè)一個(gè)來(lái)，至于怎么操作呢？那我們要引入一個(gè)輕量級(jí)組件<ViewStub>，也就是動(dòng)態(tài)加載的方法。

我們通常使用它來(lái)做預(yù)加載處理，來(lái)改善頁(yè)面加載速度和提高流暢性，ViewStub本身不會(huì)占用層級(jí)，它最終會(huì)被它指定的層級(jí)取代。有時(shí)候我們也需要復(fù)雜的視圖且少用，我們可以按需要的時(shí)候裝載以便減少內(nèi)存，提高體驗(yàn)。以前我們都是設(shè)置在布局中，然后使用View.GONE屬性來(lái)隱藏組件，但是耗資源影響性能。總得來(lái)說(shuō)這玩意就是一個(gè)輕量級(jí)的View，它一個(gè)看不見的，不占布局位置，占用資源非常小的控件。

下面上代碼：

要加載的ActivityB布局（復(fù)雜的動(dòng)畫代碼請(qǐng)忽略）

<meger xmlns:android="http://schemas.android.com/apk/res/android" 
    android:layout_width="match_parent" 
    android:layout_height="match_parent" 
    > 
    <ViewStub   
        android:id="@+id/mystub"   
        android:layout_width="match_parent" 
        android:layout_height="match_parent" 
        /> 
    <ImageView 
        android:id="@+id/loading_image"   
        android:layout_width="match_parent" 
        android:layout_height="match_parent" 
        android:src="@drawable/loading_image" 
        /> 
</meger> 

在這個(gè)UI界面中，當(dāng)我們切換ActivityB時(shí)，因?yàn)榧骖櫟絼?dòng)畫效果。所以我們就讓ViewStub暫緩加載比較復(fù)雜的布局，而先把較為簡(jiǎn)單的顯示加載畫面loading_image加載出來(lái)，當(dāng)稍后時(shí)間我們就在代碼里面開始加載該布局，見代碼如下：

@Override 
protected void onCreate(Bundle savedInstanceState) {   
　　super.onCreate(savedInstanceState);   
　　setContentView(R.layout.layout_loading);   
           
　　LoadHandler = new Handler();   
　　myStub = (ViewStub)findViewById(R.id.mystub);  
　　loadingView = (ImageView)findViewById(R.id.loading_image);   
　　myStub.setLayoutResource(R.layout.layout_main);//設(shè)置加載資源 
　　LoadHandler.postDelayed(new Runnable() {   
　　　　@Override   
　　　　public void run() {   
　　　　　　myStub.inflate();//開始加載復(fù)雜界面 
　　　　　　loadingView.setVisibility(View.GONE);//隱藏臨時(shí)加載的簡(jiǎn)單界面 
　　　　}   
　　},500); 

上面代碼實(shí)現(xiàn)了先執(zhí)行復(fù)雜動(dòng)畫，當(dāng)切換界面到到500ms時(shí)，handler開始執(zhí)行加載復(fù)雜的界面子線程，從而錯(cuò)開了資源的集中利用，這里使用的是動(dòng)態(tài)添加ViewStub指向布局資源的方法，簡(jiǎn)單而實(shí)用吧，對(duì)于一個(gè)用戶來(lái)說(shuō)，延遲半秒加載界面遠(yuǎn)遠(yuǎn)比切換畫面卡頓更容易接受。

使用ViewStub需要主要幾點(diǎn)：

1、ViewStub只能被Inflate一次，當(dāng)Inflate之后ViewStub對(duì)象就被置為空值，說(shuō)得更通俗點(diǎn)就是當(dāng)ViewStub被某個(gè)布局Inflate后，就不能通過(guò)ViewStub來(lái)控制它，因?yàn)樗呀?jīng)功成身退了，自然對(duì)于需要不同場(chǎng)景下顯示隱藏的情況建議用visibility。

2、ViewStub只能用來(lái)Inflate一個(gè)布局文件，對(duì)于單個(gè)具體的View它是無(wú)能為力的，當(dāng)然如果把View搞在某個(gè)布局文件中也是可以接受的。

3、VIewStub中不能嵌套merge標(biāo)簽。

重用布局是一個(gè)好習(xí)慣

重用是一個(gè)好習(xí)慣，既然大家都常念叨，無(wú)圖無(wú)真相呀樓主，為了避免大家說(shuō)no picture you say a jb~這類回復(fù)，我還是勉勉強(qiáng)強(qiáng)上個(gè)圖吧。

這個(gè)界面由三個(gè)小部分組成，分別是標(biāo)題欄、內(nèi)容顯示和底端按鈕。如果你手指閑不住前前后后點(diǎn)一點(diǎn)，按一按；會(huì)發(fā)覺各個(gè)界面的風(fēng)格驚人的相似！而且不僅僅是在這軟件上會(huì)體現(xiàn)，而且市場(chǎng)上大部分應(yīng)用都是這樣！其實(shí)說(shuō)白了這就是一個(gè)風(fēng)格的問(wèn)題。

那么，既然這么多重復(fù)了，作為二十一世紀(jì)標(biāo)準(zhǔn)碼農(nóng)的我們來(lái)說(shuō)，我們能忍受這種浪費(fèi)嗎？所以我們要用用<include>標(biāo)簽——模塊化布局。

布局如下：多簡(jiǎn)單的layout復(fù)用，你還會(huì)說(shuō)你不喜歡用<include>標(biāo)簽嗎？

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" 
    android:layout_width="fill_parent" 
    android:layout_height="fill_parent" 
    android:orientation="vertical" 
    > 
 <include android:id="@+id/head_menu" layout="@layout/head_menu" /> 
 <include android:id="@+id/content" layout="@layout/content_showweibo" /> 
 <include android:id="@+id/bottom_menu" layout="@layout/bottom_menu" /> 
</LinearLayout> 

使用<include>的好處有：

1、模塊化布局，提高重用率，易于日后的維護(hù)和擴(kuò)展。

2、降低生成的app的體重，用戶的流量是很貴的！

簡(jiǎn)單說(shuō)說(shuō)剩下的點(diǎn)

1、減少不必要的inflate

(1)對(duì)于inflate的布局可以直接緩存，用全部變量代替局部變量，避免下次需再次inflate

if (loadingView != null) { 
    loadingView.setVisibility(View.VISIBLE); 
} 
else{ 
    loadingView =LayoutInflater.from(context).inflate(R.layout.loadingView, this, true); 

(2)BaseAdapter中item的convertView緩存用法，詳細(xì)請(qǐng)參考《關(guān)于BaseAdapter的使用及優(yōu)化心得》

PS：***次寫的博文，寫的渣得不能看。。。。。。

2、避免有太多的視圖

每個(gè)視圖都會(huì)消耗內(nèi)存，在一個(gè)布局中布置太多的視圖，布局會(huì)占用過(guò)多的內(nèi)存，假設(shè)一個(gè)布局包含超過(guò)80個(gè)視圖，layoutopt可能會(huì)給出下面這樣的建議：

-1:-1 This layout has too many views: 83 views, it should have <= 80!  

上面給出的建議是視圖數(shù)量不能超過(guò)80，當(dāng)然***的設(shè)備有可能能夠支持這么多視圖，但如果真的出現(xiàn)性能不佳的情況，***采納這個(gè)建議。

3、千萬(wàn)別布局嵌套太多

布局不應(yīng)該有太多的嵌套，layoutopt（和Android團(tuán)隊(duì)）建議布局保持在10級(jí)以內(nèi)，即使是***的平板電腦屏幕，布局也不應(yīng)該超過(guò)10級(jí)，RelativeLayout可能是一個(gè)解決辦法，但它的用法更復(fù)雜，好在Eclipse中的Graphical Layout資源工具更新后，使得這一切變得更簡(jiǎn)單。

下面是布局嵌套太多時(shí)，layoutopt的輸出內(nèi)容：

-1:-1 This layout has too many nested layouts: 12 levels, it should have <= 10!305:318 This LinearLayout layout or its RelativeLayout parent is possibly useless 

嵌套布局警告通常伴隨有一些無(wú)用布局的警告，有助于找出哪些布局可以移除，避免屏幕布局全部重新設(shè)計(jì)。

4、在某些場(chǎng)景下使用非主線程繪制的UI組件，具體組件名稱我忘了，后面想起來(lái)補(bǔ)上哈。

本文鏈接：http://www.cnblogs.com/net168/p/4017921.html