Android應(yīng)用開發(fā)中ListView組件性能優(yōu)化的研究

張延年，米洪

（南京交通職業(yè)技術(shù)學(xué)院，南京　211188）

Android應(yīng)用開發(fā)中ListView組件性能優(yōu)化的研究

張延年，米洪

（南京交通職業(yè)技術(shù)學(xué)院，南京211188）

0　引言

市場(chǎng)上很多Android應(yīng)用存在忽視程序性能優(yōu)化的問題，這些應(yīng)用往往在用戶使用量達(dá)到一定規(guī)模時(shí)出現(xiàn)性能問題，例如操作卡頓、下載變慢、突然閃退。要解決這些問題，就要求產(chǎn)品設(shè)計(jì)師必須提早將程序性能方面的需求作詳細(xì)的分析并提出相應(yīng)的解決方案。因此，性能優(yōu)化問題的研究對(duì)提高程序的健壯性、可擴(kuò)展性，降低后期的修改和維護(hù)成本具有重要的意義［1］。本文主要涉及Android應(yīng)用程序代碼層次上的優(yōu)化，首先分析了常規(guī)的代碼優(yōu)化機(jī)制，然后通過一個(gè)典型案例闡述了ListView組件的具體優(yōu)化方案，并詳細(xì)測(cè)試和分析了優(yōu)化的效果，最后證實(shí)了優(yōu)化方法的正確性和可行性。

1　性能優(yōu)化機(jī)制

（1）增加緩存

緩存就是在內(nèi)存中開辟一塊區(qū)域作為臨時(shí)數(shù)據(jù)交換區(qū)域，其中包括對(duì)象緩存、I/O緩存、網(wǎng)絡(luò)緩存、DB緩存等［2］。由于在內(nèi)存、文件、數(shù)據(jù)庫、網(wǎng)絡(luò)的讀寫速度中，內(nèi)存都是最優(yōu)的，且速度數(shù)量級(jí)差別，所以盡量將需要頻繁訪問或訪問一次消耗較大的數(shù)據(jù)存儲(chǔ)在緩存中。

Android中常使用緩存機(jī)制有：

①線程池。

②圖片緩存，包括圖片Sdcard緩存，數(shù)據(jù)預(yù)取緩存。

③消息緩存，通過handler.obtainMessage復(fù)用之前的message。

④ListView緩存。

⑤文件I/O緩存。

使用具有緩存策略的輸入流，如BufferedInput-Stream替代InputStream。

⑥布局緩存。

（2）數(shù)據(jù)存儲(chǔ)優(yōu)化

①數(shù)據(jù)類型選擇

●字符串拼接用StringBuilder代替String，在非并發(fā)情況下用StringBuilder代替StringBuffer。

●64位類型如long double的處理比32位如int慢。

●使用SoftReference、WeakReference相對(duì)正常的強(qiáng)應(yīng)用來說更有利于系統(tǒng)垃圾回收。

●final類型存儲(chǔ)在常量區(qū)中讀取效率更高。

●LocalBroadcastManager代替普通 BroadcastRe-ceiver，效率和安全性都更高。

②數(shù)據(jù)結(jié)構(gòu)選擇

●ArrayList和LinkedList的選擇，ArrayList根據(jù)index取值更快，LinkedList更占內(nèi)存、隨機(jī)插入刪除更快速、擴(kuò)容效率更高，一般推薦ArrayList。

●ArrayList、HashMap、LinkedHashMap、HashSet的選擇，hash系列數(shù)據(jù)結(jié)構(gòu)查詢速度更優(yōu)，ArrayList存儲(chǔ)有序元素，HashMap為鍵值對(duì)數(shù)據(jù)結(jié)構(gòu)，Linked-HashMap可以記住加入次序的hashMap，HashSet不允許重復(fù)元素。

●HashMap、WeakHashMap選擇，WeakHashMap中元素可在適當(dāng)時(shí)候被系統(tǒng)垃圾回收器自動(dòng)回收，所以適合在內(nèi)存緊張型中使用。

●Collections.synchronizedMap和ConcurrentHash-Map的選擇，ConcurrentHashMap為細(xì)分鎖，鎖粒度更小，并發(fā)性能更優(yōu)。Collections.synchronizedMap為對(duì)象鎖，自己添加函數(shù)進(jìn)行鎖控制更方便。

●Android也提供了一些性能更優(yōu)的數(shù)據(jù)類型，如SparseArray、SparseBooleanArray、SparseIntArray、Pair。Sparse系列的數(shù)據(jù)結(jié)構(gòu)是為key為int情況的特殊處理，采用二分查找及簡(jiǎn)單的數(shù)組存儲(chǔ)，不需要泛型轉(zhuǎn)換的開銷，相對(duì)Map來說性能更優(yōu)。

（3）算法優(yōu)化

例如：盡量不用O（n*n）時(shí)間復(fù)雜度以上的算法，必要時(shí)候可用空間換時(shí)間。查詢考慮hash和二分，盡量不用遞歸。

（4）邏輯優(yōu)化

這個(gè)不同于算法，主要是理清程序邏輯，減少不必要的操作。

（5）需求優(yōu)化

對(duì)于部分對(duì)產(chǎn)品使用性能產(chǎn)生重大影響的需求，必須進(jìn)行需求簡(jiǎn)化或變更。

Android應(yīng)用開發(fā)過程中必須遵循單線程模型（Single Thread Model）的原則［3］。因?yàn)锳ndroid的UI操作并不是線程安全的，所以涉及UI的操作必須在UI線程中完成。但是并非所有的操作都能在主線程中進(jìn)行，Android應(yīng)用程序在設(shè)計(jì)上約定，在5s內(nèi)無響應(yīng)的話會(huì)導(dǎo)致ANR（Application Not Response），這就要求開發(fā)者必須遵循兩條法則：第一不能阻塞UI線程，第二確保只在UI線程中訪問Android UI工具包。因此，對(duì)于耗時(shí)操作必須在另外開啟的工作線程中完成，然后通過handler和主線程交互。

（1）延遲操作

不在Activity、Service、BroadcastReceiver的生命周期等對(duì)響應(yīng)時(shí)間敏感函數(shù)中執(zhí)行耗時(shí)操作，可適當(dāng)延遲［4］。

Java中延遲操作可使用ScheduledExecutorService，不推薦使用Timer.schedule；

Android中除了支持ScheduledExecutorService之外，還有一些延遲操作，如：

handler.postDelayed，handler.postAtTime，handler. sendMessageDelayed，

View.postDelayed，AlarmManager定時(shí)等。

（2）提前操作

對(duì)于第一次調(diào)用較耗時(shí)操作，可統(tǒng)一放到初始化中，將耗時(shí)提前。如得到壁紙wallpaperManager.get-Drawable（）。

1.4網(wǎng)絡(luò)優(yōu)化

以下是網(wǎng)絡(luò)優(yōu)化中需要遵守的準(zhǔn)則［5］：

●圖片必須緩存，最好根據(jù)機(jī)型做圖片適配。

●所有http請(qǐng)求必須添加HttpTimeOut。

●API接口數(shù)據(jù)盡量以json格式返回，而不是xml 或html。

●根據(jù)http頭信息中的Cache-Control及expires域確定是否緩存請(qǐng)求結(jié)果。

●發(fā)送網(wǎng)絡(luò)請(qǐng)求前需確定connection是否keepalive。

●減少網(wǎng)絡(luò)請(qǐng)求次數(shù)，服務(wù)器端適當(dāng)做請(qǐng)求合并。

●減少重定向次數(shù)。

●API接口服務(wù)器端響應(yīng)時(shí)間不超過100ms。

2　ListView性能優(yōu)化

ListView是Android中常用的組件之一，常用于新聞列表、產(chǎn)品列表、聯(lián)系人清單等內(nèi)容的展現(xiàn)，要使用ListView主要用到以下幾個(gè)元素。

（1）ListVeiw組件，用來展示列表的View，一般通過編寫xml布局文件來獲取。

（2）Adapter適配器，用來把數(shù)據(jù)映射到ListView上的中介。Android SDK主要提供了BaseAdapter、ArrayAdapter＜T＞，SimpleAdapter等幾個(gè)主要的類。

（3）List集合或數(shù)組，提供要顯示的數(shù)據(jù)，其中的元素一般是自定義的對(duì)象，對(duì)象的屬性可以字符串，圖片等，這些屬性的一部分或全部最后要顯示在ListVeiw組件上。

下面將通過一個(gè)典型的新聞列表案例來說明如何對(duì)ListView進(jìn)行優(yōu)化。

本案例的主要功能是在一個(gè)ListView中顯示100條新聞信息，其中每條信息包含標(biāo)題文本、內(nèi)容文本和小圖標(biāo)（圖片）三項(xiàng)內(nèi)容。為了更清楚地說明解決編程優(yōu)化問題的方法，在此對(duì)實(shí)際項(xiàng)目案例做了一些簡(jiǎn)化，系統(tǒng)所用數(shù)據(jù)均在本地直接生成 （不考慮網(wǎng)絡(luò)傳輸時(shí)延），數(shù)據(jù)信息采用模擬數(shù)據(jù)“新聞標(biāo)題0，新聞標(biāo)題1，…，新聞標(biāo)題99”和“新聞內(nèi)容0，新聞內(nèi)容1，…，新聞內(nèi)容99”，100條新聞的圖片均采用同一圖片。關(guān)鍵代碼如下：

新聞實(shí)體類：News主界面布局文件：activity_main.xml，包含一個(gè)ListView組件。

列表子項(xiàng)布局文件listview_item.xml，包含兩個(gè)TextView組件和一個(gè)ImageView組件，分別用來顯示新聞條目的標(biāo)題、內(nèi)容和圖片。

數(shù)據(jù)提供類：DataProder

public static final int count=100；//新聞條數(shù)/*獲取所有新聞?dòng)涗?/

新聞列表主界面類：MainActivity

/*創(chuàng)建自定義適配器內(nèi)部類*/

/*根據(jù)制定的列表項(xiàng)位置獲取一個(gè)包含要顯示的數(shù)據(jù)的列表項(xiàng)視圖 */

程序運(yùn)行結(jié)果如下圖所示：

圖1　程序運(yùn)行結(jié)果圖

（1）問題分析

在程序測(cè)試過程中，對(duì)ListView組件做滑動(dòng)操作時(shí)會(huì)出現(xiàn)輕微的卡頓現(xiàn)象，這個(gè)案例中僅有100條簡(jiǎn)單數(shù)據(jù)，而且還沒有通過網(wǎng)絡(luò)進(jìn)行數(shù)據(jù)傳輸，可以想象在實(shí)際項(xiàng)目中數(shù)據(jù)量將大很多，且需要網(wǎng)絡(luò)進(jìn)行傳輸，所以直接用以上代碼則卡頓現(xiàn)象會(huì)更嚴(yán)重，甚至出現(xiàn)程序閃退，因此對(duì)程序性能進(jìn)行優(yōu)化是十分必要的。在進(jìn)行優(yōu)化之前必須找出代碼運(yùn)行性能瓶頸所在的位置，這里使用Android SDK所提供的性能測(cè)試工具traceview進(jìn)行測(cè)試。

（2）性能測(cè)試

在華為8813Q（Android4.1）上運(yùn)行以上程序，開啟Eclispe里的DDMS工具，單擊Start Mathod Profiling按鈕，開啟traceview工具［6］，在5秒鐘之在手機(jī)上快速向下滑動(dòng)ListView到列表的最底部，最后點(diǎn)擊 Stop Mathod Profiling按鈕，這時(shí)會(huì)自動(dòng)彈出測(cè)試結(jié)果頁面xxx.trace文件，將文件保存到C盤根目錄下，使用traceview工具打開文件，在最下面的Find查找框輸入getview，將測(cè)試結(jié)果進(jìn)行截圖并標(biāo)明重要的數(shù)據(jù)，最終測(cè)試結(jié)果如下圖所示。優(yōu)化后的程序?qū)?yán)格按照以上測(cè)試環(huán)境和步驟進(jìn)行。

對(duì)以上優(yōu)化過的程序進(jìn)行性能測(cè)試，得到如下結(jié)果：

圖2　未優(yōu)化前程序性能測(cè)試結(jié)果圖

性能分析：

在測(cè)試界面上會(huì)發(fā)現(xiàn)其中g(shù)etView函數(shù)占用的cpu時(shí)間非常高，達(dá)到50.4%，而getView中又以inflate函數(shù)耗費(fèi)的時(shí)間最多，居然占據(jù)整個(gè)getView中所有操作95%的時(shí)間，而這個(gè)inflate函數(shù)的操作在整個(gè)應(yīng)用程序中占用的cpu時(shí)間也達(dá)到了48%。通過以上分析定位程序運(yùn)行的瓶頸主要在getView函數(shù)。下面將對(duì)適配器中g(shù)etView函數(shù)的代碼進(jìn)行優(yōu)化。

（1）優(yōu)化方案一：減少getView中填充布局inflate函數(shù)操作，重復(fù)利用布局視圖對(duì)象。

在MyAdapter類中的getView方法中，每次需要一個(gè)View對(duì)象時(shí)，都是通過inflate方法生成。實(shí)際上對(duì)于ListView而言，只需要保留能夠顯示的最大個(gè)數(shù)的view即可，其他新的view可以通過復(fù)用的方式使用消失的條目的view。在getView方法里提供了一個(gè)參數(shù)：convertView，這個(gè)參數(shù)就代表著可以復(fù)用的view對(duì)象，當(dāng)然這個(gè)對(duì)象也可能為空，當(dāng)它為null的時(shí)候，表示該條目view第一次創(chuàng)建，所以系統(tǒng)需要inflate一個(gè)view出來，而當(dāng)它不為null的時(shí)候，系統(tǒng)就可以復(fù)用。關(guān)鍵代碼如下：

對(duì)以上優(yōu)化過的程序進(jìn)行性能測(cè)試，得到如下結(jié)果：

圖3　經(jīng)方案一優(yōu)化后程序性能測(cè)試結(jié)果圖

性能分析：

從以上測(cè)試結(jié)果可以看出，getView函數(shù)占用的cpu時(shí)間有明顯減少，從原來的50.4%減少到12.8%，效率提升了1倍多，而inflate函數(shù)的調(diào)用所占時(shí)間減少更明顯，從原來的getView中所占比例的95%減少到5.6%。因此通過方法一的優(yōu)化，ListView組件的運(yùn)行效率有了較大的提升，若僅從其中g(shù)etView函數(shù)占用的cpu的時(shí)間上比較從2371減少到605，效率提升了大約74%。

（2）優(yōu)化方案二：使用靜態(tài)內(nèi)部類ViewHolder，減少findeViewById方法的操作。

程序每一次獲取view對(duì)象都需要通過資源id，也就是使用findViewById函數(shù)進(jìn)行操作。頻繁的find-ViewById方法調(diào)用將要耗費(fèi)大量的內(nèi)存和時(shí)間，如果可以讓view內(nèi)的組件也隨著view的復(fù)用而復(fù)用則可以大大減少這部分操作。這里采用重新建一個(gè)內(nèi)部靜態(tài)類的方法，里面的成員變量跟view中所包含的組件個(gè)數(shù)類型相同，根據(jù)本案例可以創(chuàng)建如下靜態(tài)類：

ViewHolder類復(fù)用的基本思路是在 convertView 為null的時(shí)候，系統(tǒng)不僅重新inflate出來一個(gè)view，并進(jìn)行findviewbyId的查找工作，同時(shí)還需要獲取一個(gè)ViewHolder類的對(duì)象，并將findviewById的結(jié)果賦值給ViewHolder中對(duì)應(yīng)的成員變量。最后將holder對(duì)象與該view對(duì)象“綁”在一塊。

當(dāng)convertView不為null時(shí)，將converView賦值給view，同時(shí)取出這個(gè)view對(duì)應(yīng)的holder對(duì)象，就獲得了這個(gè)view對(duì)象中的TextView組件，它就是holder中的成員變量，這樣在復(fù)用的時(shí)候，就不需要再去find-ViewById了，只需要在最開始的時(shí)候進(jìn)行數(shù)次查找工作。這里的關(guān)鍵在于如何將view與holder對(duì)象進(jìn)行綁定，那么就需要用到兩個(gè)方法：setTag和getTag方法了。關(guān)鍵代碼如下：

對(duì)以上優(yōu)化過的程序進(jìn)行測(cè)試，得到如下結(jié)果：

圖4　經(jīng)方案二優(yōu)化后程序性能測(cè)試結(jié)果圖

性能分析：

從以上測(cè)試結(jié)果可以看出，getView函數(shù)占用的cpu時(shí)間比例有明顯減少，從原來的 12.8%減少到9.1%，而其中findViewById函數(shù)的調(diào)用所占時(shí)間由從原來的getView中所占比例的4.4%減少到0.0%。這里從cpu占用比率無法準(zhǔn)確判斷優(yōu)化的效果，而從cpu占用的絕對(duì)時(shí)間上則可以看出明顯的效率提升，getView由605減少到230，效率提升62%，findView-ById由26減少到0.108，效率提升99%。

（3）優(yōu)化方案三：ListView滑動(dòng)時(shí)不加載數(shù)據(jù)，停下來時(shí)加載數(shù)據(jù)，提升滑動(dòng)流暢度。

經(jīng)過上面的優(yōu)化操作，ListView組件的性能已經(jīng)有了很大的提升，但是當(dāng)用戶頻繁滑動(dòng)操作時(shí)，特別是需要從服務(wù)器端下載大量圖片數(shù)據(jù)時(shí)將出現(xiàn)卡頓現(xiàn)象。具體解決方案如下。

首先，在 Adapter的 getView方法中，在給ViewHolder的屬性賦值前做個(gè)判斷，即當(dāng)組件在滑動(dòng)狀態(tài)時(shí)，由于用戶并不會(huì)關(guān)心列表的任何信息，所以系統(tǒng)可以加載本地的默認(rèn)數(shù)據(jù) （也可以稱為假數(shù)據(jù)），而當(dāng)組件不在滑動(dòng)狀態(tài)時(shí)，再加載真正的數(shù)據(jù)。為此系統(tǒng)需要在MyAdapter里設(shè)置一個(gè)滑動(dòng)狀態(tài)的boolean類型的屬性scrollState，然后由MainAcitvity實(shí)現(xiàn)OnScrollListener接口，作為L(zhǎng)istview滑動(dòng)操作的監(jiān)聽器，在監(jiān)聽器方法onScrollStateChanged中設(shè)置屬性scrollState的值。

其次，由于無法直接調(diào)用getView方法，所以需要在onScrollStateChanged中 當(dāng) 參 數(shù)scrollState== SCROLL_STATE_IDLE （停止?jié)L動(dòng)）時(shí)，通過對(duì)ViewHolder中的每個(gè)屬性的tag屬性值進(jìn)行判斷，來決定ViewHolder的數(shù)據(jù)是否進(jìn)行加載。即getView如果在滑動(dòng)狀態(tài)時(shí)執(zhí)行setTag（默認(rèn)文本信息）或setTag（默認(rèn)圖片文件名），在非滑動(dòng)狀態(tài)時(shí)執(zhí)行setTag（null）或set-Tag（“1”），這樣在onScrollStateChanged中就可以根據(jù)這個(gè)tag的值來判斷是否需要加載數(shù)據(jù)。關(guān)鍵代碼如下：

對(duì)以上優(yōu)化過的程序進(jìn)行測(cè)試，得到如下結(jié)果：

圖5　經(jīng)方案二優(yōu)化后程序性能測(cè)試結(jié)果圖

性能分析：

從以上測(cè)試結(jié)果可以看出，getView函數(shù)占用的cpu時(shí)間比例又有明顯減少，從原來的9.1%減少到2.2%，而findViewById函數(shù)的調(diào)用在getView中所占比例為0.3%，沒有顯著變化，說明增加的代碼并沒有影響減少findeViewById函數(shù)的操作的優(yōu)化效果。

（4）其他優(yōu)化方案

本案例中的ListView都是顯示的本地的List集合中的內(nèi)容，而且List的長(zhǎng)度也只有100個(gè)，數(shù)據(jù)量很小，系統(tǒng)可以一次性加載完成測(cè)試數(shù)據(jù)。但是實(shí)際應(yīng)用中，系統(tǒng)往往會(huì)需要使用ListView來顯示網(wǎng)絡(luò)上的大量?jī)?nèi)容，一般有以下兩個(gè)問題需要考慮：

其一：假如網(wǎng)絡(luò)情況很好，使用的手機(jī)也許能夠一下子加載完所有新聞數(shù)據(jù)，然后顯示在ListView中，用戶可能感覺還好，假如說在網(wǎng)絡(luò)不太順暢的情況下，用戶加載完所有網(wǎng)絡(luò)的數(shù)據(jù)，可能這個(gè)list有上千條新聞，那么用戶可能需要面對(duì)一個(gè)空白的Activity好幾分鐘，這個(gè)顯然是不合適的。

其二：Android虛擬機(jī)給每個(gè)應(yīng)用分配的運(yùn)行時(shí)內(nèi)存是一定的，一般性能不太好的機(jī)器只有16M，好一點(diǎn)的可能也就是64M的樣子，假如要瀏覽的新聞總數(shù)為上萬條，可能出現(xiàn)內(nèi)存溢出，應(yīng)用崩潰的情況。

如何解決上面所述兩個(gè)問題呢？由于這部分優(yōu)化方法的使用一般都與實(shí)際項(xiàng)目的需求有關(guān)，是否有必要優(yōu)化以及如何優(yōu)化都要具體問題具體分析，優(yōu)化方法不能通用，因此只能對(duì)以上問題的解決方法做如下簡(jiǎn)單說明。

首先，采用數(shù)據(jù)分批加載，例如1000條新聞的List集合，系統(tǒng)一次加載20條，等到用戶翻頁到底部的時(shí)候，再添加下面的20條到List中，并使用Adapter刷新ListView，這樣用戶一次只需要等待20條數(shù)據(jù)的傳輸時(shí)間，并可以預(yù)防內(nèi)存溢出，應(yīng)用崩潰的情況。

其次，分批加載有時(shí)候也不能完全解決問題，因?yàn)殡m然在分批中一次只增加20條數(shù)據(jù)到List集合中，但假如有10萬條數(shù)據(jù)，如果系統(tǒng)要順利讀到最后，這個(gè)List集合中還是會(huì)累積海量條數(shù)的數(shù)據(jù)，將可能會(huì)造成OOM的情況，這時(shí)候就需要用到分頁技術(shù)，每頁加載時(shí)都覆蓋掉上一頁中List集合中的內(nèi)容。

3　結(jié)語

本文主要對(duì)Android應(yīng)用開發(fā)中ListView組件編程過程中的性能優(yōu)化做了較為深入的研究，通過一個(gè)典型的新聞客戶端列表案例詳細(xì)闡述了三種通用的編程優(yōu)化方案，包括性能瓶頸的分析、優(yōu)化的思路和方法、優(yōu)化的步驟、程序運(yùn)行測(cè)試等，另外簡(jiǎn)要概述了其他一些較為復(fù)雜的優(yōu)化方法。

本文中所涉及的案例代碼都已通過實(shí)際上機(jī)運(yùn)行測(cè)試，通過對(duì)優(yōu)化前后測(cè)試結(jié)果的比較和分析，證明以上優(yōu)化方法是切實(shí)可行的，對(duì)組件的運(yùn)行效率有較大的提高，對(duì)程序的整體性能有較大的改善和提升。

［1］丁振凡，吳小元.Android系統(tǒng)ListView控件數(shù)據(jù)遞增顯示研究［J］.智能計(jì)算機(jī)與應(yīng)用，2014，4（2）：49-52.

［2］王海峰.基于Android技術(shù)校園信息平臺(tái)客戶端的研究與設(shè)計(jì)［J］.軟件工程師，2014，17（9）：43-45.

［3］鮑曉.基于Android平臺(tái)的新聞資訊閱讀軟件的設(shè)計(jì)與實(shí)現(xiàn)［J］.計(jì)算機(jī)應(yīng)用，2013，33（S2）：279-282.

［4］邱忠權(quán)，候雪莉，張德新.基于Android系統(tǒng)的列車移動(dòng)信息服務(wù)平臺(tái)設(shè)計(jì)與訂餐系統(tǒng)的實(shí)現(xiàn)［J］.交通運(yùn)輸工程與學(xué)報(bào)，2015，13 （1）：18-25.

［5］（美）Ronan Schwarz，Phil Dutson，James Steele，Nelson To.Android開發(fā)秘籍（第2版）［M］.錢昊譯.北京：人民郵電出版社，2014.8.

［6］武永亮.Android開發(fā)范例實(shí)戰(zhàn)寶典［M］.北京：清華大學(xué)出版社，2014.9

Android；ListView；Performance Optimization；TraceView

Research on ListView Performance Optimization in Android Application Development

ZHANG Yan-nian，MI Hong
（Nanjing Communications Institute of Technology，Nanjing 211188）

1007-1423（2015）36-0058-07

10.3969/j.issn.1007-1423.2015.36.014

張延年（1977-），男，山東聊城人，碩士，講師，研究方向?yàn)橐苿?dòng)互聯(lián)網(wǎng)、云計(jì)算等

2015-11-19

2015-12-19

概述Android應(yīng)用開發(fā)中代碼層次上性能優(yōu)化的常規(guī)機(jī)制，然后通過一個(gè)典型案例詳細(xì)闡述對(duì)ListView組件進(jìn)行性能優(yōu)化的三種解決方案，其中包括性能瓶頸的分析、具體的優(yōu)化步驟和優(yōu)化結(jié)果的測(cè)試與分析，最后對(duì)其他一些特定場(chǎng)景下ListView組件的優(yōu)化方法作簡(jiǎn)要的介紹。使用TraceView性能分析工具對(duì)優(yōu)化前后的程序進(jìn)行多次測(cè)試實(shí)驗(yàn)，實(shí)驗(yàn)結(jié)果表明優(yōu)化方案的實(shí)施顯著提高程序的性能，提升程序的運(yùn)行效率。

Android；ListView；性能優(yōu)化；TraceView

米洪（1974-），男，山東泰安人，碩士，副教授，研究方向?yàn)橐苿?dòng)互聯(lián)網(wǎng)、信息安全等

Outlines the general mechanism of code level performance optimization in Android application development，and then elaborates the three solutions to the performance optimization of ListView components，including the analysis of the performance bottleneck，the specific optimization steps and the test and analysis of the optimization results，and finally gives a brief introduction to the optimization method of ListView components in some specific scenarios.Uses TraceView performance analysis tool to test the program.The experimental results show that the optimized scheme can significantly improve the performance of the program and improve the operating efficiency of the program.