Android:一個高效的UI才是一個拉風的UI(一)

來源:互聯網
上載者:User

標籤:android   style   blog   http   color   io   使用   ar   strong   

  混跡部落格園良久,想想還是應該多抽空寫幾篇小部落格來回報下這個平台。

開篇

  Android是一個運行在移動終端上的作業系統,跟傳統PC最大的不同所在就是移動終端的資源緊缺問題“比較”明顯,當然對於一些屌絲機型,應該用“非常“來形容才靠譜。所以經常會出現在一些比較缺乏青春活力的老型機上,運行一些軟體被異常終止的情況;然而作為互連網廠家來說,廣大的屌絲機使用者肯定是一大筆使用者資源,這是能放棄的市場嗎?!當然不行o(╯□╰)o,所以我們要儘可能得提高軟體的效率來贏取客戶的回眸一笑了,屌絲也是客戶!

  這篇部落客要介紹如何在UI設計上提高效率,減少資源的利用,畢竟在終端資源短缺的今天,效率始終為王。我們評判一個UI介面不是認為有多複雜才給力,或者說有多炫才靠譜,一個簡約而又不平凡的高效UI介面才是一個灰常牛逼的介面設計。

引入

  在android應用中,採用寫入程式碼方式編寫介面並不是一個提倡的方法。當然寫入程式碼編寫的介面比基於XML檔案的軟編碼介面高效靈活一些,但是非常不容易維護,錯綜複雜的代碼更會讓程式埋雷重重,說不定哪天就把應用炸的慘不忍睹。所以如果非常必要非常肯定要採用代碼編寫寫入程式碼介面之外,其他情況還是採用易於維護的XML來編寫比較好。

  所以文中對於UI最佳化設計歸結到底也就是對XML布局檔案的最佳化設計。

  在Google給我們的開發環境中,存在這麼一個非常好用的工具——hierarchyviewer,估計很多人都沒搭理過這個藏在偏僻角落的小工具吧;它能非常容易的幫我們分析UI介面的結構和構造效率,這個工具的位置就在sdk/tools/檔案夾。

樓下:

大家好,我是圖~

這是分析的是一個布局上只有一個TextView組件的XML介面,圖告訴我們,構造這個介面總共用了四個組件,也就是需要繪製四次組件,自然每一次繪製組件都需要耗費資源。

下面步入狂拽酷炫吊炸天的主題部分。。。。

----------------------------------我是分割線-------------------------天王蓋地虎-------------------------------------------------------------

盡量用最少的步驟完成布局

  我是社會好青年,我為國家省資源;當然作為組件來說也需要這個覺悟,每個組件的繪製都會多多少少耗費終端的資源。所以我們在這裡可不能聽老祖宗的話:韓信點兵多多益善了,精兵簡政才是UI設計的唯一出路。不相信?行!下面就開始給個對比的例子。

假設項目需要搞這麼一個按鈕:

這不簡單嗎?幾行代碼不是分分鐘的事情嗎?

<RelativeLayout    android:layout_width="wrap_content"    android:layout_height="wrap_content"    android:gravity="center" >    <Button        android:id="@+id/button1"        android:layout_width="wrap_content"        android:layout_height="wrap_content"        android:background="@drawable/btn_backgroup"         />    <ImageView        android:id="@+id/imageView1"        android:layout_width="wrap_content"        android:layout_height="wrap_content"        android:layout_alignParentLeft="true"        android:layout_centerVertical="true"        android:src="@drawable/header_back" /></RelativeLayout>

也別急著看代碼,多累多傷眼睛呀,直接上個hierarchyviewer裡面的圖來瞧瞧唄

一個小小的按鈕就用了3個組件來繪製,這就是3N的複雜度了呀,如果有5個這樣的按鈕就要15個組件,如果有10個按鈕就要有30個,如果有N++個,哎呀媽的,不敢想象下去了。既然這樣,我們是不是應該考慮一下最佳化最佳化,翻翻資料我們發現原來是可以不用這麼多組件來實現的這個按鈕的。

<Button    android:id="@+id/button1"    android:layout_width="wrap_content"    android:layout_height="wrap_content"    android:background="@drawable/btn_backgroup"    android:drawableLeft="@drawable/header_back"    android:gravity="center"    android:padding="10dp"    />

按照國際慣例,二樓

還是原來的按鈕,還是原來的味道,複雜度從3N降低到N!!!你敢說這樣的效率你不想去提升????

小結一個:在我們設計UI布局時,應該從使用盡量少的組件的前提下入手,由於系統組件的封裝比較完善,把多個簡單的組件交由一個複雜一點的組件來實現,是可以得到比較好的效率的。因為每個組件都得需要獨自進行繪製過程,多個組件繪製浪費的資源不僅僅謀害了我們的應用,更深深打擊了用不起高端機的屌絲使用者的自尊心——”他媽的,這軟體又不能用!“。

你不幹活?把你辭了。

  我們還記剛開始給的一個圖嗎?我們在布局中使用的到僅僅是一個TextView,而RelativeLayout貌似啥子活兒都沒乾的樣子。。。。。。

   我們從來都不提倡吃空餉不幹活,軟體界的潛規則也是這樣的。出於構建和諧社會的正義感,我們當然不能坐視RelativeLayout這種站著茅坑不拉屎的流氓行為,所以我們就需要藉助一個解決措施——<merge>標籤,它能幫我們幹掉一些不需要的根節點。為了擁有更好的即視感,所以我用了一個更為複雜點的布局(其實一點都不複雜)、、

主布局XML檔案:

<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"    android:id="@+id/layout1"    android:layout_width="match_parent"    android:layout_height="match_parent"    >    <ImageView android:id="@+id/image1"        android:layout_width="match_parent"        android:layout_height="wrap_content"        android:src="@drawable/bg"        />    <com.net168.text.MyLayout         android:id="@+id/layout2"        android:layout_width="match_parent"        android:layout_height="match_parent"        >    </com.net168.text.MyLayout></FrameLayout>

群組控制項布局XML檔案:

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"    android:layout_width="wrap_content"    android:layout_height="wrap_content"    android:orientation="horizontal"    >    <Button android:id="@+id/button2"        android:layout_width="wrap_content"        android:layout_height="wrap_content"        android:text="button2"        />    <TextView android:id="@+id/text1"        android:layout_width="wrap_content"        android:layout_height="wrap_content"        android:text="text1"        android:textColor="#ff0000"        /></LinearLayout>

這個介面很醜的,不忍直視:

醜歸醜,我們還是需要繼續用神器hierarchyviewer看看這個XML產生的介面結構圖來探索一下醜女內心豐富多彩的世界~~~~~~~

我靠。。。。三個組件的布局竟然用了六層嵌套布局,瞬間有了一種大花姑娘嫁給老光棍的一種深深的浪費感。我們開始看圖說話,第一層和第二層的組件是系統都會自動產生的,這個是板上DingTalk沒法商量的事情,除非你去底層跟他們好好談談。但是~但是這個第三層的FrameLayout和第五層的LinearLayout完完全全是在自我秀存在感而已,所以我們要狠下心做掉他們,怎麼來呢?用<merge>標籤。

由於<merge>標籤只能作為根項目,所以我們可以將這兩個根項目都稍加修改,如下:

主布局XML檔案:

<merge xmlns:android="http://schemas.android.com/apk/res/android"    android:id="@+id/layout1"    android:layout_width="match_parent"    android:layout_height="match_parent"    >    <ImageView android:id="@+id/image1"        android:layout_width="match_parent"        android:layout_height="wrap_content"        android:src="@drawable/bg"        />    <com.net168.text.MyLayout         android:id="@+id/layout2"        android:layout_width="match_parent"        android:layout_height="match_parent"        >    </com.net168.text.MyLayout></merge>

群組控制項布局XML檔案:

<merge xmlns:android="http://schemas.android.com/apk/res/android"    android:layout_width="wrap_content"    android:layout_height="wrap_content"    >    <Button android:id="@+id/button2"        android:layout_width="wrap_content"        android:layout_height="wrap_content"        android:text="button2"        />    <TextView android:id="@+id/text1"        android:layout_width="wrap_content"        android:layout_height="wrap_content"        android:text="text1"        android:textColor="#ff0000"        /></merge>

PS:注意需要在群組控制項的類中加上一句setOrientation(LinearLayout.HORIZONTAL)來保證自組件的水平排列。

繼續用神器看看結構:

 呼呼呼~~是不是從六層降低到了四層結構,好一股小清新的感覺呀,我都感覺飄飄然了,自然效率的提升是毋容置疑滴。。。。。

小結一個:<merge>標籤能百分百代替<FrameLayout>這個布局組件,對於不複雜的其他布局組件如線性布局等組合組件中,可以在繼承子類中對其屬性進行設定後也可以使用<merge>標籤,<merge>標籤不佔資源,自然在產生介面時也不會產生對應的組件。另外需要注意一點是<merge>只能作為根項目,對於需要用inflate產生布局檔案時,必須指定一個ViewGroup作為其父元素,並且要設定inflate的attachToRoot參數為true。(參照inflate(int, ViewGroup, boolean))。

 

enjoy風鈴
出處:http://www.cnblogs.com/net168/
本文著作權歸作者和部落格園共有,歡迎轉載,但未經作者同意必須保留此段聲明,且在文章頁面明顯位置給出原文串連,否則下次不給你轉載了。

Android:一個高效的UI才是一個拉風的UI(一)

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.