陳　星　楊春花

(齊魯工業(yè)大學(xué)信息學(xué)院　山東 濟(jì)南 250000)

?

Android異步技術(shù)的對(duì)比實(shí)驗(yàn)及應(yīng)用

陳星楊春花

(齊魯工業(yè)大學(xué)信息學(xué)院山東 濟(jì)南 250000)

摘要異步技術(shù)的選用是制約Android應(yīng)用產(chǎn)品優(yōu)劣的重要因素之一。目前Android應(yīng)用開(kāi)發(fā)的重要異步技術(shù)主要包括AsyncTask、ThreadPool、Thread+Handler這三種。針對(duì)這三種異步技術(shù)在面對(duì)短時(shí)間內(nèi)高爆發(fā)的場(chǎng)景時(shí)的表現(xiàn)，設(shè)計(jì)了一個(gè)Android應(yīng)用，分別在穩(wěn)定性、響應(yīng)速度、資源耗費(fèi)等指標(biāo)方面進(jìn)行了對(duì)比實(shí)驗(yàn)及綜合分析。實(shí)驗(yàn)結(jié)果表明，在這三種異步技術(shù)中，ThreadPool技術(shù)的綜合表現(xiàn)最優(yōu)秀。該技術(shù)能更好地適應(yīng)于短時(shí)間內(nèi)與網(wǎng)絡(luò)進(jìn)行大量數(shù)據(jù)交互的情形，并在一個(gè)移動(dòng)OA項(xiàng)目中采用了ThreadPool技術(shù)，利用此技術(shù)實(shí)現(xiàn)了異步下載文件的功能。

關(guān)鍵詞Android異步AsyncTaskThreadPoolThreadHandler

CONTRAST EXPERIMENT OF ANDROID ASYNCHRONOUS TECHNOLOGIES AND THEIR APPLICATION

Chen XingYang Chunhua

(School of Information,Qilu University,Jinan 250000,Shandong,China)

AbstractThe selection of asynchronous techniques is an important factor restricting the pros and cons of Android applications. At present, the important asynchronous techniques of Android application development include AsyncTask, ThreadPool and Thread+Handler. Aiming at the performance of these three asynchronous techniques when facing the scene of high outbreak in short period, we designed an Android application, and carried out the contrast experiments and analyses on stability, reaction speed and consumption of resource separately. Experimental result showed that the ThreadPool technique had the best comprehensive performance among three asynchronous techniques. This technique could better adapt to the situation of interacting a large amount of data with network in a short period. In a mobile OA project the ThreadPool technique was adopted, and by using it the function of asynchronous files download was realised.

KeywordsAndroidAsynchronousAsyncTaskThreadPoolThreadHandler

0引言

Android系統(tǒng)從投入使用到現(xiàn)在對(duì)智能手機(jī)行業(yè)產(chǎn)生了巨大的影響。據(jù)2010年末數(shù)據(jù)顯示，正式推出僅兩年的Android操作系統(tǒng)在市場(chǎng)占有率上已經(jīng)超越稱霸逾十年的諾基亞Symbian系統(tǒng)，成為全球最受歡迎的智能手機(jī)操作系統(tǒng)[1]。隨著通信技術(shù)的不斷發(fā)展，網(wǎng)絡(luò)技術(shù)的不斷改良，實(shí)時(shí)通信網(wǎng)絡(luò)效率成為了越來(lái)越多的智能手機(jī)使用者所關(guān)注的事情。

Android系統(tǒng)的一個(gè)重要缺陷在于它的響應(yīng)能力不足，它對(duì)用戶的應(yīng)用有直接消極的影響[2]。為了解決低響應(yīng)問(wèn)題和保持圖形用戶界面(GUI)的活躍性，一個(gè)APP應(yīng)用往往包含一個(gè)主UI線程來(lái)更新視圖和若干個(gè)子線程在后臺(tái)異步運(yùn)行來(lái)處理耗時(shí)操作，例如網(wǎng)絡(luò)請(qǐng)求、I/O任務(wù)等[3]。異步技術(shù)是當(dāng)前解決低響應(yīng)問(wèn)題的重要手段。

當(dāng)前，許多研究針對(duì)采用異步技術(shù)來(lái)解決Android應(yīng)用的低響應(yīng)問(wèn)題提出了一些解決方案，如文獻(xiàn)[4]針對(duì)改善手機(jī)Web Servers的并發(fā)控制，提出了基于異步方法的DRMS；文獻(xiàn)[5]為了減省手機(jī)內(nèi)存，提高加載資源速度的異步加載機(jī)制等。但是，對(duì)于各種異步技術(shù)本身之間的對(duì)比研究卻很少有文獻(xiàn)提及。由于不同的異步技術(shù)具有不同的特點(diǎn)，適應(yīng)的場(chǎng)合也會(huì)不同。對(duì)它們進(jìn)行比較研究可對(duì)Android應(yīng)用開(kāi)發(fā)實(shí)踐中異步技術(shù)的選擇提供一定的參考。

本文通過(guò)一個(gè)Android應(yīng)用實(shí)例，對(duì)Android開(kāi)發(fā)實(shí)踐中常用的三種異步技術(shù)-AsyncTask異步線程技術(shù)[6]、ThreadPool技術(shù)[7]、 Thread+Handler技術(shù)[8,9]進(jìn)行了對(duì)比實(shí)驗(yàn)，從穩(wěn)定性、響應(yīng)速度、資源耗費(fèi)等方面對(duì)比了各自的優(yōu)劣。通過(guò)對(duì)比實(shí)驗(yàn)對(duì)這三種異步技術(shù)所適應(yīng)的場(chǎng)所進(jìn)行了總結(jié)，得出最終結(jié)論，并在一個(gè)移動(dòng)OA項(xiàng)目中采用了ThreadPool技術(shù)，實(shí)現(xiàn)了異步下載文件的功能。

1相關(guān)異步技術(shù)簡(jiǎn)介

1.1AsyncTask異步線程技術(shù)

Android為了降低開(kāi)發(fā)難度，提供了AsyncTask異步線程技術(shù)，它能在不必操作Thread和Handler的情況下在后臺(tái)進(jìn)行耗時(shí)操作并把結(jié)果返回到UI主線程中，讓使用者非常方便地進(jìn)行異步處理，但這種技術(shù)適用于短時(shí)間操作。AsyncTask是一個(gè)封裝過(guò)的后臺(tái)任務(wù)抽象類，其本質(zhì)是一個(gè)靜態(tài)線程池，它派生出的子類可以實(shí)現(xiàn)不同的異步任務(wù)，這些任務(wù)都被提交到靜態(tài)線程池中執(zhí)行，但從Android 3.0開(kāi)始后，為了避免并行執(zhí)行引起的應(yīng)用錯(cuò)誤，任務(wù)則被提交到一個(gè)線程上按先后順序執(zhí)行[6]。

AsyncTask的執(zhí)行分為四個(gè)步驟，每一步都對(duì)應(yīng)一個(gè)回調(diào)方法：onPreExecute()，doInBackground(Params…)，onProgressUpdate(Progress…)和onPostExecute(Result)[10]。onPreExecute()在任務(wù)開(kāi)始之前調(diào)用，為后臺(tái)線程運(yùn)行做準(zhǔn)備工作,當(dāng)它執(zhí)行完畢后運(yùn)行doInBackground(Params…)方法；在doInBackground(Params…)方法中做比較耗時(shí)的操作，因?yàn)樗沁\(yùn)行在后臺(tái)線程中的所以不能直接操作UI，而任務(wù)的處理往往需要一段時(shí)間，為了方便使用者及時(shí)獲知任務(wù)處理的進(jìn)度，可以調(diào)用publicProgress(Progress…)來(lái)更新任務(wù)處理進(jìn)度并在onProgressUpdate(Progress…)中反饋給用戶任務(wù)執(zhí)行的進(jìn)度條；onPostExecute(Result)在主UI線程中執(zhí)行,相當(dāng)于Handler 處理UI的方式，在此方法里可以使用從doInBackground (Params…)中獲得的結(jié)果并操作UI。

1.2ThreadPool技術(shù)

在面向?qū)ο缶幊讨校€程的創(chuàng)建、運(yùn)行和銷毀不僅占用了部分內(nèi)存資源而且消耗了一些時(shí)間，所以為了讓?xiě)?yīng)用更加高效，引入了“池資源化”的思想，而線程池也是和這一思想相符合的。

線程池是一種多線程處理形式。因?yàn)榫€程的生命周期隨著線程的停止而結(jié)束，為了能讓線程循環(huán)重用而不是每當(dāng)完成一項(xiàng)任務(wù)后就停止，應(yīng)先在應(yīng)用程序啟動(dòng)或者運(yùn)行過(guò)程中創(chuàng)建一定數(shù)量的線程并讓它們進(jìn)入阻塞狀態(tài)等待，還應(yīng)把所需完成的任務(wù)放在隊(duì)列或者其他數(shù)據(jù)結(jié)構(gòu)中[11]。當(dāng)有任務(wù)到達(dá)時(shí)，不應(yīng)該為每個(gè)任務(wù)都創(chuàng)建一個(gè)新的子線程來(lái)服務(wù)它，而應(yīng)從已經(jīng)存在的線程池中選一個(gè)空閑線程來(lái)完成任務(wù)，等任務(wù)完成結(jié)束后，子線程再回到空閑池中[12]。

線程池的使用不僅節(jié)省了處理時(shí)間與內(nèi)存資源，而且它的一個(gè)特點(diǎn)在于線程池中的線程是由系統(tǒng)管理的，不需要人為管理，更加方便了使用者的開(kāi)發(fā)。線程池技術(shù)的應(yīng)用范圍比較廣泛，特別適用于有大量并發(fā)訪問(wèn)，但任務(wù)短小的應(yīng)用中[13]。

1.3Thread + Handler技術(shù)

一個(gè)線程就是一個(gè)輕量級(jí)的過(guò)程，每一個(gè)線程都有自己的內(nèi)存緩存，把讀取的共享文件儲(chǔ)存在自己的內(nèi)存緩存中[14]，它也是一個(gè)并發(fā)執(zhí)行的單位，而每個(gè)應(yīng)用程序在啟動(dòng)時(shí)至少有一個(gè)線程在運(yùn)行，稱為主線程[8]。Android應(yīng)用的主線程是UI線程，是不安全的線程，也就是說(shuō)UI控件的更新只能在主線程中完成，子線程不允許操作UI，所以Android為了實(shí)現(xiàn)線程間的通信，開(kāi)發(fā)了Handler、 Message、MessageQueue、Looper機(jī)制。

在Android系統(tǒng)中，子線程不能直接更新主線程的UI控件，須使用Handler和Looper將子線程中的數(shù)據(jù)傳遞給主線程，由主線程來(lái)刷新UI控件，Looper提供了一種消息循環(huán)機(jī)制，負(fù)責(zé)循環(huán)獲取由Handler存放于MessageQueue中的數(shù)據(jù)[15]。使用多線程的目的是為了更充分地利用資源，但資源總數(shù)是有限的，需要在線程數(shù)量與程序性能之間確定一個(gè)平衡，線程過(guò)多會(huì)嚴(yán)重影響程序本身的性能，線程過(guò)少軟件和硬件性能得不到充分發(fā)揮[16]。

2實(shí)驗(yàn)測(cè)試和比較

為了對(duì)比三種異步技術(shù)的優(yōu)劣，本文設(shè)計(jì)了一個(gè)簡(jiǎn)單的Android應(yīng)用實(shí)例-圖片下載，分別利用上述三種異步技術(shù)進(jìn)行實(shí)現(xiàn)。同時(shí)，針對(duì)需要對(duì)比的穩(wěn)定性、響應(yīng)速度、資源耗費(fèi)等指標(biāo)增加了相應(yīng)的代碼進(jìn)行衡量。測(cè)試環(huán)境由一臺(tái)計(jì)算機(jī)和一部手機(jī)組成，計(jì)算機(jī)充當(dāng)服務(wù)器，手機(jī)充當(dāng)客戶端，兩者由100 Mbit的網(wǎng)絡(luò)連接。計(jì)算機(jī)的操作系統(tǒng)選用WIN 7，使用Google的PLAY框架構(gòu)成服務(wù)器環(huán)境，系統(tǒng)中承載實(shí)驗(yàn)所需軟件的所有需求，手機(jī)的操作系統(tǒng)為Android 4.4，測(cè)試所用的軟件為Ecplise。

2.1測(cè)試方法與指標(biāo)

把本文設(shè)計(jì)的應(yīng)用安裝到手機(jī)上，通過(guò)手機(jī)WIFI連接電腦，并訪問(wèn)本機(jī)服務(wù)器。此應(yīng)用分別利用AsyncTask、ThreadPool、Thread+Handler這三種技術(shù)來(lái)實(shí)現(xiàn)相同的功能，亦即下載本機(jī)服務(wù)器上的圖片并加載顯示到手機(jī)上。

實(shí)驗(yàn)主要比較各自技術(shù)的穩(wěn)定性、響應(yīng)速度、資源耗費(fèi)等指標(biāo)。其中穩(wěn)定性的衡量選用短時(shí)間內(nèi)成功下載的圖片個(gè)數(shù)與圖片總數(shù)的比值來(lái)體現(xiàn)；響應(yīng)速度的衡量主要通過(guò)下載時(shí)間、下載并發(fā)性來(lái)體現(xiàn)；資源耗費(fèi)的衡量選用內(nèi)存消耗來(lái)體現(xiàn)。

實(shí)驗(yàn)分別針對(duì)圖片的下載數(shù)量做了100、200、300張這三次變化, 用于模擬短時(shí)間高爆發(fā)請(qǐng)求的實(shí)驗(yàn)環(huán)境，記錄使用各自技術(shù)所需的下載完成情況、下載并發(fā)性、下載完成時(shí)間、內(nèi)存消耗情況這四種實(shí)驗(yàn)數(shù)據(jù)，分別用于體現(xiàn)相應(yīng)指標(biāo)。由于實(shí)驗(yàn)測(cè)試所用的網(wǎng)絡(luò)環(huán)境及應(yīng)用所消耗的手機(jī)資源等因素不能保證每次測(cè)試得到的結(jié)果都準(zhǔn)確一致，為了確保實(shí)驗(yàn)的準(zhǔn)確性，本文進(jìn)行了三次測(cè)試，并記錄了每一次的測(cè)試結(jié)果，最后取三次的平均值作為最終實(shí)驗(yàn)結(jié)果。

2.2測(cè)試結(jié)果及分析

2.2.1穩(wěn)定性

圖1　不同圖片總數(shù)的下載率

在本實(shí)驗(yàn)中，穩(wěn)定性選用下載率來(lái)體現(xiàn)，而下載率為短時(shí)間內(nèi)已下載的圖片個(gè)數(shù)與所有圖片總數(shù)的比值，這個(gè)比值越接近1越好，比值為1說(shuō)明短時(shí)間內(nèi)下載的圖片已全部下載完成。不同圖片總數(shù)的下載率如圖1所示。

實(shí)驗(yàn)結(jié)果表明，當(dāng)下載圖片個(gè)數(shù)從100張遞增到300張時(shí)，利用AsyncTask技術(shù)和ThreadPool技術(shù)的下載率都為1，說(shuō)明這兩種技術(shù)都能穩(wěn)定的完成下載任務(wù)；而利用Thread+Handler技術(shù)，在下載100張圖片時(shí)能穩(wěn)定完成下載任務(wù)，但隨著下載圖片總數(shù)的增加，它的下載性越低，即它穩(wěn)定完成任務(wù)的成功率越低。

從實(shí)驗(yàn)結(jié)果得出結(jié)論，利用ThreadPool技術(shù)與AsyncTask技術(shù)加載大量數(shù)據(jù)時(shí)所體現(xiàn)的穩(wěn)定性一樣，且都很穩(wěn)定可靠，而利用Thread+Handler技術(shù)加載大量數(shù)據(jù)時(shí)的穩(wěn)定性較一般，特別是當(dāng)下載數(shù)量較大時(shí)這種表現(xiàn)更為明顯。

針對(duì)這一結(jié)論，分析其造成的可能原因是因?yàn)锳syncTask技術(shù)與ThreadPool技術(shù)歸根結(jié)底都是線程池，而線程池一個(gè)的獨(dú)特優(yōu)點(diǎn)在于線程都是由系統(tǒng)統(tǒng)一管理的。各線程之間互不影響，這就避免了像Thread+Handler技術(shù)中會(huì)為每個(gè)任務(wù)創(chuàng)建一個(gè)新線程，各線程之間相互擠占系統(tǒng)資源所出現(xiàn)個(gè)別線程卡住，造成任務(wù)完成失敗的情況。因此AsyncTask技術(shù)和ThreadPool技術(shù)的穩(wěn)定性都是一樣穩(wěn)定可靠的，而Thread+Handler技術(shù)的穩(wěn)定性較一般，在任務(wù)量變得越來(lái)越大時(shí)體現(xiàn)的更加明顯。

2.2.2響應(yīng)速度

在本實(shí)驗(yàn)中，響應(yīng)速度選用下載完成時(shí)間，下載并發(fā)性來(lái)體現(xiàn)。三種技術(shù)的下載圖片個(gè)數(shù)及所用時(shí)間的折線如圖2所示。

圖2　不同圖片總數(shù)的所需下載時(shí)間

實(shí)驗(yàn)結(jié)果表明，不同圖片總數(shù)的所需下載時(shí)間如圖2所示。利用ThreadPool技術(shù)加載大量數(shù)據(jù)時(shí)所需時(shí)間最短，利用Thread+Handler技術(shù)的次之，利用 AsyncTask技術(shù)的時(shí)間最長(zhǎng)。從下載并發(fā)性說(shuō)明，利用Thread+Handler技術(shù)和ThreadPool技術(shù)一樣都是并發(fā)執(zhí)行的，而利用AsyncTask技術(shù)加載時(shí)則出現(xiàn)了順序性。

從實(shí)驗(yàn)結(jié)果得出結(jié)論，ThreadPool技術(shù)的反應(yīng)能力最強(qiáng)，Thread+Handler技術(shù)次之，AsyncTask技術(shù)最弱。針對(duì)這一結(jié)論，分析造成的可能原因是因?yàn)門hreadPool技術(shù)在任務(wù)到達(dá)時(shí)就已經(jīng)創(chuàng)建好了一定量的線程并儲(chǔ)存在“池”中，只需從“池”中拿出空閑的線程來(lái)執(zhí)行任務(wù)即可，因此省去了創(chuàng)建、切換線程的時(shí)間，所以ThreadPool技術(shù)比Thread+Handler技術(shù)省時(shí)。在Android 3.0之后，Android對(duì)AsyncTask技術(shù)做了修改，讓它execute()提交的任務(wù)按照先后順序每次只運(yùn)行一個(gè)，則用它加載時(shí)就出現(xiàn)了順序性，而ThreadPool技術(shù)與Thread+Handler技術(shù)都是并發(fā)執(zhí)行的，所以AsyncTask技術(shù)最為耗時(shí)。

2.2.3資源耗費(fèi)

在本實(shí)驗(yàn)中，資源耗費(fèi)選用各技術(shù)的內(nèi)存資源消耗情況來(lái)體現(xiàn)。三種技術(shù)的下載圖片的內(nèi)存消耗情況如圖3所示。

圖3　不同圖片總數(shù)的內(nèi)存耗費(fèi)

實(shí)驗(yàn)結(jié)果表明,利用ThreadPool技術(shù)下載圖片時(shí)所消耗的內(nèi)存最少，利用AsyncTask技術(shù)的次之，而利用Thread+Handler技術(shù)的內(nèi)存消耗最大。

從實(shí)驗(yàn)結(jié)果得出結(jié)論，ThreadPool技術(shù)的耗費(fèi)能力最好，即消耗內(nèi)存最少，AsyncTask技術(shù)次之，Thread+Handler技術(shù)最差。針對(duì)這一結(jié)論，分析造成的可能原因是因?yàn)門hreadPool技術(shù)能限制應(yīng)用程序在同一時(shí)刻運(yùn)行的線程數(shù)。一般每當(dāng)開(kāi)啟運(yùn)行一個(gè)新線程時(shí)都會(huì)占用一部分內(nèi)存資源，而ThreadPool技術(shù)是在任務(wù)到達(dá)前就創(chuàng)建好了固定的線程數(shù)。用這些線程來(lái)并發(fā)執(zhí)行任務(wù)，所以省去了為每個(gè)任務(wù)創(chuàng)建、切換線程的內(nèi)存消耗，所以它的耗費(fèi)能力最好，在這三種異步技術(shù)中消耗內(nèi)存最少。

2.3測(cè)試總結(jié)

通過(guò)以上測(cè)試指標(biāo)，能得知各自的技術(shù)的特點(diǎn)及面對(duì)不同環(huán)境時(shí)體現(xiàn)出的優(yōu)劣，最后對(duì)這三種技術(shù)所較為適應(yīng)的環(huán)境做出總結(jié)。當(dāng)短時(shí)間內(nèi)進(jìn)行大量數(shù)據(jù)交換時(shí)， ThreadPool技術(shù)更有優(yōu)勢(shì)；而當(dāng)用戶遇到在保證任務(wù)完成穩(wěn)定性的同時(shí)但對(duì)耗費(fèi)時(shí)間要求較寬松的情景下，可以選擇AsyncTask技術(shù)；當(dāng)用戶遇到需要完成的任務(wù)量較少，對(duì)任務(wù)完成穩(wěn)定性要求較寬松但對(duì)耗費(fèi)時(shí)間要求比較嚴(yán)格的情境下，可以選擇Thread+Handler技術(shù)。

3異步技術(shù)的應(yīng)用

通過(guò)對(duì)比實(shí)驗(yàn)得知，ThreadPool技術(shù)在面對(duì)短時(shí)間內(nèi)進(jìn)行大量數(shù)據(jù)交換的情景時(shí)更有優(yōu)勢(shì)，并在一個(gè)移動(dòng)OA項(xiàng)目中采用了ThreadPool技術(shù)，實(shí)現(xiàn)了用戶能在短時(shí)間內(nèi)下載附件內(nèi)容的功能。

移動(dòng)OA項(xiàng)目主要包括八大模塊：登錄模塊、請(qǐng)假申請(qǐng)模塊、請(qǐng)假審批模塊、公文審批模塊、通訊錄模塊、通知公告模塊、值班信息、值班管理。其中在公文審批模塊中，有的審批內(nèi)容包含了所對(duì)應(yīng)的公文附件，而公文附件主要是一些圖片和Word、Excel文件等，這就需要用戶下載下來(lái)進(jìn)行審閱。為了方便用戶能在最短的時(shí)間內(nèi)完成下載，所以不同的下載任務(wù)需滿足并發(fā)執(zhí)行，且要避免因并發(fā)執(zhí)行時(shí)因相互擠占系統(tǒng)資源所出現(xiàn)死鎖的現(xiàn)象，而ThreadPool技術(shù)能有效的解決上述問(wèn)題，最終采用ThreadPool技術(shù)實(shí)現(xiàn)了下載附件內(nèi)容的功能。

3.1關(guān)鍵技術(shù)的實(shí)現(xiàn)

利用ThreadPool技術(shù)實(shí)現(xiàn)下載公文附件內(nèi)容的結(jié)構(gòu)流程如圖4所示。

圖4　線程池下載流程圖

如圖所示，因?yàn)锳ndroid系統(tǒng)會(huì)為每個(gè)程序運(yùn)行時(shí)僅創(chuàng)建一個(gè)Application類的對(duì)象，故在程序的Application中利用Executors.newFixedThreadPool()創(chuàng)建線程池對(duì)象。當(dāng)線程池開(kāi)啟時(shí)，創(chuàng)建一個(gè)獨(dú)立的輪詢子線程，此輪詢子線程的作用是不斷的檢查工作隊(duì)列，如果隊(duì)列中有未執(zhí)行的任務(wù)，就將任務(wù)交給線程池來(lái)執(zhí)行。下面的代碼部分實(shí)現(xiàn)了線程池及輪詢子線程的創(chuàng)建：

/** 線程池 */

private ExecutorService threadPool;

/** 工作隊(duì)列 */

private LinkedList asyncTasks;

// 創(chuàng)建線程池

public ThreadPoolManager (int poolSize) {

this.poolSize = poolSize;

threadPool= Executors.newFixedThreadPool(this.poolSize);

asyncTasks = new LinkedList();

}

// 輪詢子線程的創(chuàng)建

private class PoolRunnable implements Runnable {

@Override

public void run() {

try {

while(!Thread.currentThread().isInterrupted()) {

ThreadPoolTask task = getAsyncTask();

if (task == null) {

try {

Thread.sleep(2000);

} catch (InterruptedException e) {

Thread.currentThread().interrupt();

}

continue;

}

threadPool.execute(task);

}

} catch (Exception e) {

} finally {

threadPool.shutdown();

}

}

}

工作隊(duì)列是一個(gè)存放下載任務(wù)單元的LinkedList，每次添加新的任務(wù)時(shí)利用LinkedList.addLast()從尾部進(jìn)行添加，取出任務(wù)時(shí)利用LinkedList.removeFirst()從頭部取出，即實(shí)現(xiàn)了隊(duì)列的先進(jìn)先出原則。工作隊(duì)列中存放的是一個(gè)個(gè)不同的下載任務(wù)，而這些下載任務(wù)實(shí)際上是實(shí)現(xiàn)Runnable接口的子線程，每個(gè)子線程中都承載了不同的下載目標(biāo)，在各自的run()中實(shí)現(xiàn)不同的功能，其結(jié)構(gòu)如下:

public abstract class ThreadPoolTask implements Runnable{

//網(wǎng)絡(luò)連接的url

private String mUrl;

//參數(shù)

List mParamList = new ArrayList();

//Handler

private Handler mHandler;

//HttpClient

private HttpClient mhClient = null;

/**

* 構(gòu)造函數(shù)

*/

public ThreadPoolTask(String url, List paramList, Handler handler, HttpClient httpClient) {

this.mUrl = url;

this.mParamList = paramList;

this.mHandler = handler;

this.mhClient = httpClient;

}

public abstract void run();

...

}

3.2實(shí)現(xiàn)結(jié)果

將項(xiàng)目打包安裝到真機(jī)上，其下載附件的實(shí)際效果如圖5所示。

圖5　下載效果圖

4結(jié)語(yǔ)

本文先通過(guò)一個(gè)下載圖片的Android應(yīng)用，對(duì)AsyncTask、ThreadPool和Thread+Handler三種異步技術(shù)進(jìn)行了對(duì)比實(shí)驗(yàn)。實(shí)驗(yàn)結(jié)果表明，AsyncTask技術(shù)的穩(wěn)定能力不錯(cuò)，但它運(yùn)行時(shí)出現(xiàn)了順序性，所以在短時(shí)間內(nèi)下載大量數(shù)據(jù)時(shí)，比較耗時(shí)；Thread+Handler技術(shù)的運(yùn)行是并發(fā)執(zhí)行的，但穩(wěn)定性較為一般，而且內(nèi)存消耗較大，特別是當(dāng)任務(wù)量較大時(shí)體現(xiàn)的更加明顯；ThreadPool技術(shù)，它的穩(wěn)定能力不錯(cuò)，反應(yīng)能力跟耗費(fèi)能力都是最好的。因此，在短時(shí)間內(nèi)進(jìn)行大量數(shù)據(jù)交換時(shí)，選用ThreadPool技術(shù)更有優(yōu)勢(shì)。

然后根據(jù)得出的結(jié)論選用了ThreadPool技術(shù)并將其應(yīng)用在一個(gè)移動(dòng)OA項(xiàng)目中，實(shí)現(xiàn)了異步下載文件的功能，并對(duì)線程池應(yīng)用的關(guān)鍵技術(shù)做了較詳細(xì)的說(shuō)明。下一步的工作是進(jìn)一步優(yōu)化下載模塊的性能，由于在創(chuàng)建線程池的同時(shí)就規(guī)定了線程池的大小，而線程數(shù)過(guò)多或過(guò)少都會(huì)對(duì)產(chǎn)品的性能產(chǎn)生一定的影響，所以選用一個(gè)合適的大小顯得尤為重要。

參考文獻(xiàn)

[1] 劉亞麗.Android軟件前景淺析[J].科技創(chuàng)新導(dǎo)報(bào),2011(25):32.

[2] Shengqian Yang,Dacong Yan,Rountev A.Testing for poor responsiveness in Android applications[C]//Engineering of Mobile-Enabled Systems (MOBS).San Francisco,CA,USA:IEEE,2013:1-6.

[3] Sai Zhang,Hao Lü,Michael D Ernst.Finding errors in multithreaded GUI applications[C]//Proceedings of the 2012 International Symposium on Software Testing and Analysis.New York,NY,USA:ACM,2012:243-253.

[4] Mishra S,Sarasvati S,Srivastava S,et al.An Asynchronous Based Approach to Improve Concurrency Control in Mobile Web Servers[C]//Proceedings of the 8th International Collaborative Computing.Pottsburgh,PA:IEEE,2012:355-362.

[5] Gejian Ding,Xue Liu,Huajiang Zhang,et al.Research of an Optimized Asynchronous Loading Mechanism[J].Applied Mechanics and Materials,2013(278-280):1809-1813.

[6] Android Developers website.AsyncTask[EB/OL].[2014-3-18].http://developer.Android.com/refreence/Android/os/AsyncTask.html.

[7] 封瑋,周世平.Java中的線程池及實(shí)現(xiàn)[J].計(jì)算機(jī)系統(tǒng)應(yīng)用,2004(8):16-18.

[8] Android Developers website.Thread[EB/OL].[2014-3-18].http://developer.Android.com/reference/java/lang/Thread.html.

[9] Android Developers website.Handler[EB/OL].[2014-3-18].http://developer.Android.com/reference/Android/os/Handler.html.

[10] 周兵.Android中UI線程與后臺(tái)線程交互的探討[J].鄖陽(yáng)師范高等?？茖W(xué)校學(xué)報(bào),2013,33(3):14-16.

[11] 邵孟良.Java線程池技術(shù)在多媒體網(wǎng)絡(luò)教室中的應(yīng)用與實(shí)現(xiàn)[J].科技與生活,2011(15):188.

[12] 劉海燕,呂延崗,張紅瑞.基于線程池技術(shù)DHCP服務(wù)器的設(shè)計(jì)與實(shí)現(xiàn)[J].計(jì)算機(jī)技術(shù)與發(fā)展,2006,16(7):76-78.

[13] 王華,馬亮,顧明.線程池技術(shù)研究與應(yīng)用[J].計(jì)算機(jī)應(yīng)用研究,2005,22(11):141-142.

[14] Kai Ni.A Data Delivery Controller for Mobile Communication Based on Multiple Threads Mechanism[J].Applied Mechanics and Materials,2013(433-435):1613-1617.

[15] 王秀敏,張麒,李婷婷.Android平臺(tái)下多路傾角傳感器驅(qū)動(dòng)的設(shè)計(jì)與實(shí)現(xiàn)[J].儀表技術(shù)與傳感器,2013(9):18-20.

[16] 眭俊華,劉慧娜,王建鑫,等.多核多線程技術(shù)綜述[J].計(jì)算機(jī)應(yīng)用,2013,33(A01):239-242.

中圖分類號(hào)TP311.52

文獻(xiàn)標(biāo)識(shí)碼A

DOI:10.3969/j.issn.1000-386x.2016.02.045

收稿日期：2014-07-28。山東省自然科學(xué)基金項(xiàng)目(ZR2011FQ0 17)。陳星，碩士生，主研領(lǐng)域：移動(dòng)應(yīng)用開(kāi)發(fā)。楊春花，教授。