冼 進

(華南理工大學(xué)計算機科學(xué)與工程學(xué)院,廣東 廣州 510006)

0 引 言

Android手機的應(yīng)用開發(fā)非?；鸨刂?018年4月，Google Play上的Android應(yīng)用數(shù)達到210萬。現(xiàn)在每天依然有數(shù)以千計的新應(yīng)用上線，要在為數(shù)眾多的應(yīng)用中生存下來，應(yīng)用面臨極大考驗。應(yīng)用除了要具有特色，還要求使用順暢。開發(fā)者應(yīng)當(dāng)考慮在開發(fā)過程中，如何進行測試以及發(fā)布后如何持續(xù)跟蹤，保證應(yīng)用在它的生命周期內(nèi)都能夠完好提供服務(wù)，這是應(yīng)用生存的一大關(guān)鍵[1-3]。Android應(yīng)用性能測試與監(jiān)控應(yīng)考慮2個方面的問題[4-6]，一方面是在保證軟件質(zhì)量的前提下減少軟件測試成本，另一方面是為應(yīng)用持續(xù)跟蹤、完善應(yīng)用服務(wù)質(zhì)量提供更好的途徑。

Android應(yīng)用性能測試與監(jiān)控為應(yīng)用的質(zhì)量和可靠性提供了保障[7-10]。測試功能有：1)這種方式下的性能測試是真實使用場景下的測試，通過用戶使用應(yīng)用獲得性能數(shù)據(jù)；2)用戶作為應(yīng)用的使用者，同時也是應(yīng)用的測試者，參與到軟件生命同期過程中，減少了應(yīng)用開發(fā)過程中人力資源的消耗；3)測試的充分性得到保障，應(yīng)用安裝在不同的手機上，每個安裝應(yīng)用的手機同時也是一部測試機，用戶使用的過程也是應(yīng)用的測試過程，節(jié)省了不同手機上的測試的開銷；4)及時性，應(yīng)用使用過程中產(chǎn)生的監(jiān)測數(shù)據(jù)會及時上報到服務(wù)端，尤其是使用過程中的錯誤信息；5)加速軟件升級，提高軟件質(zhì)量，開發(fā)者通過瀏覽服務(wù)端的分析報告，診斷應(yīng)用出現(xiàn)的問題，及時對軟件進行重構(gòu)，修復(fù)Bug，快速發(fā)布新版本。監(jiān)控功能可以提供用戶群體特征信息，服務(wù)于運營團隊，為應(yīng)用開拓更廣闊的市場空間。

目前對于Android應(yīng)用性能測試與監(jiān)控研究大部分都是分開進行的。應(yīng)用性能測試只關(guān)注性能，而且是在應(yīng)用發(fā)布前進行，這種方式依然沿襲了傳統(tǒng)PC機上的測試方案，其理論指導(dǎo)沒有發(fā)生本質(zhì)變化[11]。應(yīng)用監(jiān)控只關(guān)注監(jiān)控，而且監(jiān)控相對應(yīng)用而言是宏觀層面的，不能對應(yīng)用的內(nèi)部接口進行分析，同時監(jiān)控是針對單個設(shè)備上的應(yīng)用，不能從多個設(shè)備、整體的角度來分析。由于兩者的局限性，因此需要把兩者結(jié)合起來，發(fā)揮它們共同的優(yōu)勢[12-13]。

本文主要工作就是實現(xiàn)一種Android應(yīng)用性能測試與監(jiān)控的方案，包括實現(xiàn)所用的技術(shù)、邏輯原理和實現(xiàn)細(xì)節(jié)[14]。根據(jù)應(yīng)用性能測試與監(jiān)控分析的實際需求，本文提出Android應(yīng)用測試與監(jiān)控方案實現(xiàn)以下7個目標(biāo)：

1)無侵入性。Android應(yīng)用性能測試與監(jiān)控功能不與應(yīng)用代碼耦合，不影響應(yīng)用功能。無侵入性的實現(xiàn)也方便開發(fā)者使用，比較容易被集成到應(yīng)用當(dāng)中去。在Android系統(tǒng)上可以利用字節(jié)碼插樁技術(shù)實現(xiàn)[10]。

2)SDK基礎(chǔ)模塊實現(xiàn)。實現(xiàn)Android應(yīng)用性能測試與監(jiān)控的基礎(chǔ)功能，為其它功能模塊提供技術(shù)支撐。

3)系統(tǒng)資源使用監(jiān)測。監(jiān)測運行過程中系統(tǒng)資源的使用情況，識別應(yīng)用是否是高資源消耗型。

4)用戶數(shù)據(jù)收集。收集用戶使用過程中的相關(guān)數(shù)據(jù)，掌握應(yīng)用每日注冊和使用的用戶數(shù)、劃分用戶成分、分析用戶的存留情況，了解應(yīng)用使用時的最新動態(tài)。

5)Activity和Fragment的加載的時間和頁面呈現(xiàn)質(zhì)量直接影響到用戶的體驗。對Activity和Fragment的監(jiān)測可以識別它們在加載過程中的性能問題，同時可以分析用戶使用過程中的偏好。

6)數(shù)據(jù)訪問性能監(jiān)測。應(yīng)用的使用會不可避免發(fā)生數(shù)據(jù)交互，可能通過網(wǎng)絡(luò)，也可能在本地進行。對應(yīng)用數(shù)據(jù)訪問性能的監(jiān)測，可以發(fā)現(xiàn)應(yīng)用訪問中出現(xiàn)的問題，保證應(yīng)用的質(zhì)量，對出錯信息進行記錄，及時報告應(yīng)用出錯狀況。

7)數(shù)據(jù)分析與展示。對收集的數(shù)據(jù)進行處理，挖掘數(shù)據(jù)中的隱藏信息，通過豐富的圖表將分析結(jié)果呈現(xiàn)給開發(fā)者，開發(fā)者利用這些信息可以有效診斷應(yīng)用問題。

1 Android應(yīng)用性能測試與監(jiān)控設(shè)計

Android應(yīng)用性能測試與監(jiān)控關(guān)注應(yīng)用使用時的性能和用戶體驗質(zhì)量，為應(yīng)用后續(xù)改進提供支撐。在測試與監(jiān)控功能開發(fā)的過程中，按照一般軟件設(shè)計開發(fā)過程，實現(xiàn)功能間的“高內(nèi)聚，低耦合”[15-16]。采用無侵入性的方案對應(yīng)用進行測試與監(jiān)控，實現(xiàn)應(yīng)用代碼與監(jiān)測功能解耦。在不影響應(yīng)用功能的條件下，實施應(yīng)用性能測試和監(jiān)控，收集數(shù)據(jù)并上報服務(wù)端，在服務(wù)端進行數(shù)據(jù)分析，分析結(jié)果以圖表的方式進行展示。

Android應(yīng)用性能測試與監(jiān)控采用Java語言開發(fā)的應(yīng)用，對Android系統(tǒng)各個版本具有高度的兼容性[17]。圖1是Android應(yīng)用測試與監(jiān)控總體架構(gòu)。其主要包括2大部分：1)Android應(yīng)用性能測試與監(jiān)控SDK，其中SDK包括5個功能模塊：SDK基礎(chǔ)模塊、系統(tǒng)資源使用監(jiān)測、Activity和Fragment頁面監(jiān)測、用戶數(shù)據(jù)收集和數(shù)據(jù)訪問性能監(jiān)測；2)服務(wù)端包括3個功能模塊：帳戶管理、SDK下載、應(yīng)用報表分析展現(xiàn)。

圖1 Android應(yīng)用性能測試與監(jiān)控總體架構(gòu)

SDK提供監(jiān)測功能有4個模板，分別為系統(tǒng)資源使用監(jiān)測、用戶數(shù)據(jù)收集、ASF頁面監(jiān)測、數(shù)據(jù)訪問性能監(jiān)測，為了實現(xiàn)4個模塊的獨立性，需要對這個4模板進行解耦操作。工作示意圖如圖2所示。

圖2 SDK基礎(chǔ)模塊工作示意圖

從圖2可知，SDK基礎(chǔ)模塊有配置文件解析、基礎(chǔ)信息獲取、數(shù)據(jù)封裝、網(wǎng)絡(luò)識別、定位、數(shù)據(jù)類型轉(zhuǎn)換和數(shù)據(jù)傳輸?shù)墓δ?，通過這些具體功能，SDK基礎(chǔ)模塊向上為其4個模塊提供服務(wù)。

圖3是用戶數(shù)據(jù)收集示意圖。用戶數(shù)據(jù)收集模塊對用戶身份進行識別，監(jiān)測應(yīng)用使用情況，收集用戶使用數(shù)據(jù)，將數(shù)據(jù)上報服務(wù)端，服務(wù)端匯總不同用戶的使用信息，從不同角度分析用戶使用數(shù)據(jù)；獲得應(yīng)用每日新增用戶數(shù)和應(yīng)用每日使用次數(shù)信息[18-20]；同時根據(jù)最近一段時間應(yīng)用的使用信息，對應(yīng)用的使用人群進行劃分，分析用戶的存留狀況。

圖3 用戶數(shù)據(jù)收集示意圖

應(yīng)用的易用性體現(xiàn)在交互，在Android系統(tǒng)中Activity和Fragment是應(yīng)用開發(fā)中最重要的2個視圖組件，它們作為一個容器裝載其他的組件和內(nèi)容，是用戶可以直接感知的部分。Activity和Fragment監(jiān)測示意圖如圖4所示。

圖4 Activity和Fragment監(jiān)測示意圖

監(jiān)測Activity和Fragment這2個視圖組件的加載時間、使用時間以及用戶在使用時Activity和Fragment頁面跳轉(zhuǎn)的序列。數(shù)據(jù)傳輸組件將監(jiān)測到的數(shù)據(jù)上報到服務(wù)端[21]。服務(wù)端對監(jiān)測的數(shù)據(jù)進行歸檔和整理，分析頁面的加載時長、使用時長和訪問次數(shù)，以及Activity和Fragment頁面的跳轉(zhuǎn)關(guān)系。

應(yīng)用運行時需要進行數(shù)據(jù)交互，可以通過網(wǎng)絡(luò)，也可以在本地進行。數(shù)據(jù)訪問性能監(jiān)測就是對數(shù)據(jù)交互性能的跟蹤,其示意圖如圖5所示。應(yīng)用使用時執(zhí)行了數(shù)據(jù)訪問功能，會觸發(fā)數(shù)據(jù)訪問性能監(jiān)測動作。監(jiān)測主要是2個方面：一個是網(wǎng)絡(luò)訪問中的HTTP請求；另一個是本地數(shù)據(jù)訪問，包括訪問數(shù)據(jù)庫和內(nèi)容提供者。訪問過程會記錄訪問用時和訪問出錯的信息。數(shù)據(jù)訪問性能監(jiān)測通過數(shù)據(jù)傳輸功能將數(shù)據(jù)上報到服務(wù)端，服務(wù)端對數(shù)據(jù)訪問進行分析，識別超時和高頻的訪問，對最新的訪問錯誤進行提示，對HTTP請求還分析其地理位置來源。

圖5 數(shù)據(jù)訪問性能監(jiān)測示意圖

1.1 用戶數(shù)據(jù)收集

用戶數(shù)據(jù)收集就是用戶在移動設(shè)備上進行操作后產(chǎn)生的有關(guān)這個用戶有價值信息的獲取。在用戶數(shù)據(jù)收集過程中將一臺設(shè)備定義成一個用戶。收集用戶的數(shù)據(jù)，需要對安裝應(yīng)用的每一臺設(shè)備進行識別，為設(shè)備生成唯一ID號。對同一個應(yīng)用來說，生成的設(shè)備ID號是唯一的，使用通用唯一識別碼(Universally Unique Identifier， UUID)可以滿足要求。

UUID通過設(shè)置生成參數(shù)，可實現(xiàn)同類信息表示?？紤]到設(shè)備ID的唯一性，用于生成UUID的參數(shù)內(nèi)容要唯一。綜合移動設(shè)備和應(yīng)用的信息，本文選擇了硬件設(shè)備標(biāo)識、硬件序列號、系統(tǒng)的fingerprint和應(yīng)用的包名作為生成UUID的參數(shù)，這些參數(shù)組合在一起足以保證字符串的唯一性，對應(yīng)的UUID也就是唯一的。

設(shè)備ID是應(yīng)用安裝到移動設(shè)備上第一次啟動時生成的，生成后這個ID被Android輕量級存儲類SharedPreferences進行保存，在以后的使用過程中這個ID就不需要再次生成，直接從SharedPreferences獲取。設(shè)備識別解決后，就可以處理用戶數(shù)據(jù)收集的其他問題。在之前的配置文件中定義了2個屬性：appRegistCollection和appUsageCollection，它們是開啟應(yīng)用注冊收集和應(yīng)用使用收集的開關(guān)；還有一個配置項是minNoOpTime，單位是秒，用戶不操作應(yīng)用，或者應(yīng)用處于后臺的時間大于minNoOpTime時都表示一次使用結(jié)束，再使用就是新的使用過程。當(dāng)開啟了appRegistCollection和appUsageCollection選項時，應(yīng)用在每次啟動時都會定位設(shè)備的位置、應(yīng)用使用的時間，識別出手機的廠商、應(yīng)用下載安裝的渠道(通過配置文件定義)等信息。這些信息通過使用接口發(fā)送到服務(wù)端，代表一次用戶使用記錄，如果應(yīng)用是第一次安裝，有可能是一個新用戶(考慮到卸載后安裝)，需要將用戶的信息通過注冊接口發(fā)到服務(wù)端，服務(wù)端通過識別應(yīng)用的設(shè)備ID驗證是否為新用戶，如果是就存儲用戶的注冊信息，否則就丟棄，如此就完成了一次用戶數(shù)據(jù)的收集。

用戶的成分劃分是考察用戶每周使用應(yīng)用的情況，按周對用戶的成分進行分解，并且通過對分解的數(shù)據(jù)建立一個分析模型，預(yù)測在未來一段時間內(nèi)，應(yīng)用使用和用戶增長趨勢[22-23]。對后續(xù)用戶的活躍和留存情況進行科學(xué)預(yù)測，方便團隊制定有效的規(guī)劃和目標(biāo)?！暗趇周”表示的意義如圖6所示。0表示當(dāng)前一周，0之前的數(shù)值表示已經(jīng)過去的某一周，0之后的數(shù)值表示是未來的某一周。

圖6 “第i周”表示的意義

定義1每周新增用戶：每周安裝了應(yīng)用并且使用的用戶集合，用Un(i)表示，其中，i表示第幾周，i∈Z。根據(jù)定義Un(i)是一個有限集。

定義2每周使用用戶：每周使用了應(yīng)用的用戶集合，用Uu(i)，其中，i表示周數(shù)，i∈Z。Uu(i)為有限集。根據(jù)定義1有：

Un(i)?Uu(i)

(1)

定義3回流用戶：第i-1周未使用過應(yīng)用，第i周使用過應(yīng)用的用戶，用Ub(i)表示，其中i∈Z，Ub(i)為有限集，同時根據(jù)定義1和定義2有：

Ub(i)=Uu(i)-Un(i)-(Uu(i)∩Uu(i-1))

=Uu(i)-Un(i)-Uu(i-1)

(2)

定義4連續(xù)使用用戶：從第i-n+1周開始，到第i周，在連續(xù)n周，每周都使用應(yīng)用的用戶，使用Uf(i,n)表示,其中i∈Z,n∈N*，Uf(i,n)為有限集。則有：

(3)

定義5忠誠用戶：連續(xù)使用應(yīng)用5周及以上的用戶，用Ul(i)表示，其中i∈Z，Ul(i)為有限集，則有：

(4)

由公式(3)和公式(4)得：

=Uf(i,5)

(5)

定義6活躍用戶：連續(xù)使用應(yīng)用2周及以上的用戶，使用Ua(i)表示，其中i∈Z，Ua(i)為有限集。則有：

(6)

同理可得：

Ua(i)=Uf(i,2)

(7)

定義7流失用戶：以第i周作為參考，用戶在第k周(k﹤i)使用過應(yīng)用，連續(xù)n(n=i-k)周未使用應(yīng)用的用戶，使用Uo(i,n)表示，其中i∈Z,n∈N*。Uo(i,n)為有限集，則有：

(8)

定義8近期流失用戶：連續(xù)n(1≤n≤4)周未使用應(yīng)用的用戶。使用Ur(i)表示,其中i∈Z,Ur(i)為有限集，則有：

(9)

根據(jù)上文對用戶成分的定義，要實現(xiàn)用戶成分劃分，首先需要明確數(shù)據(jù)篩選的區(qū)間，數(shù)據(jù)篩選區(qū)間的算法實現(xiàn)如圖7所示。

圖7 數(shù)據(jù)篩選區(qū)間算法實現(xiàn)

getRange的參數(shù)代表要處理的星期數(shù)，第2行為根據(jù)當(dāng)前日期創(chuàng)建一個日歷對象，第3到第6行將當(dāng)前時間設(shè)定到今天的最后一毫秒。第7行獲取今天是本周的第幾天，周日到周六用數(shù)字1到7表示。第9行求出離今天最近的周六最后一毫秒的時間(如果今天是周六則求出的是它的上一個周六)。第10行求出從great時間起前week周的周六的最后一毫秒。所求的時間區(qū)間為(less，great)。

用戶存留分析：一個應(yīng)用最終的目標(biāo)就是留住用戶，讓越來越多的人使用。用戶存留反映的是初期不穩(wěn)定用戶轉(zhuǎn)化為連續(xù)用戶和忠誠用戶的過程。在對應(yīng)用進行存留分析時先要明白幾個定義。

定義9存留用戶：第i-1周使用應(yīng)用，第i周依然使用應(yīng)用的用戶，使用Up(i)表示,其中i∈Z，Up(i)為有限集。根據(jù)定義4，存留用戶就是連續(xù)活躍的用戶，即：

Up(i)=Uf(i,2)=Uu(i-1)∩Uu(i)

(10)

定義10存留率：第i周存留用戶數(shù)與第i-1周使用用戶數(shù)的比值，使用R(i)表示,其中i∈Z，|Uu(i-1)|≠0。則：

(11)

定義11流失率：第i周用戶的流失率是1減第i周存留率的差，使用O(i)表示,其中i∈Z，|Uu(i-1)|≠0。則：

(12)

定義12用戶生命周期：第i周用戶生命周期定義為第i周用戶流失率的倒數(shù)，使用L(i)表示,其中i∈Z，|Uu(i-1)-Uu(i)|≠0，單位是周。則：

(13)

利用groupByWeek算法獲取按周分組的用戶使用集合，可以計算出用戶存留信息，用戶存留算法實現(xiàn)如圖8所示。參數(shù)useMap是按周進行分組的用戶Map集合。rst是保存結(jié)果的集合，其值是5個集合，分別保存第i-1周的使用用戶數(shù)、第i周的存留用戶數(shù)、第i周存留率、第i周流失率和第i周用戶生命周期。week表示要分析的周數(shù)，names表示某周的名字。for表示處理week個周，第5行set添加第names[i+1]周的用戶使用集合，v保存用戶數(shù)，然后用set與names[i]周的用戶使用集合做差運算，獲得第i周存留用戶集合。w保存第i周的存留用戶數(shù)。第9～13行分別計算第i-1周的使用用戶數(shù)、第i周的存留用戶數(shù)、第i周用戶存留率、第i周用戶流失率和第i周用戶用戶生命周期，其中生命周期轉(zhuǎn)換成天數(shù)。如此完成用戶存留分析。

圖8 用戶存留分析算法實現(xiàn)

1.2 Activity與Fragment監(jiān)測

Activity和Fragment是Android應(yīng)用重要的視圖組件，是與用戶直接進行交互的界面。對Activity和Fragment的監(jiān)測從2個方面考慮：一是Activity和Fragment使用的性能，通過它們的加載時間進行衡量；另一個是用戶在Activity和Fragment上的操作習(xí)慣，表現(xiàn)為用戶使用頁面的時間長短，以及操作過程中頁面的跳轉(zhuǎn)關(guān)系。

Fragment有自己的生命周期，它的生命周期如圖9所示。

圖9 Fragment生命周期

在Fragment被添加到Activity的過程中會調(diào)用onAttach方法，然后調(diào)用創(chuàng)建方法onCreate，這個方法完成Fragment視圖組的整體框架繪制，一些固定的視圖內(nèi)容在這個方法中進行渲染。然后就是調(diào)用視圖創(chuàng)建方法onCreateView，這個方法完成一些變化視圖內(nèi)容的繪制。每次從back棧中回到Fragment頁面，onCreateView方法都會被調(diào)用，在這里根據(jù)條件可以重繪Fragment組件。在onCreateView方法執(zhí)行結(jié)束后，開始執(zhí)行onActivityCreated和onStart方法，onPause方法執(zhí)行結(jié)束后，F(xiàn)ragment處于可見可用狀態(tài)，用戶可對Fragment中的內(nèi)容進行操作。onPause方法執(zhí)行時，F(xiàn)ragment方法變得不可用。

通過對Fragment的分析可知，從Fragment調(diào)用onAttach方法開始，到恢復(fù)方法onResume執(zhí)行結(jié)束，都是Fragment繪制內(nèi)容所做的操作，這一段時間就是Fragment的加載時間，在onResume方法執(zhí)行結(jié)束后，到onPause方法執(zhí)行前這一段時間，F(xiàn)ragment是可見可用的，用戶可以瀏覽Fragment中的內(nèi)容，與Fragment發(fā)生交互，這段時間就是用戶使用Fragment的時間。在Fragment及其子類上，對添加方法onAttach、恢復(fù)方法onResume和暫停方法onPause進行插樁，在onAttach方法上添加前置通知，在onResume方法上添加后置通知，在onPause方法是施加前置通知。在編譯過程通過AspectJ的植入功能，將通知方法植入到目標(biāo)對象中，實現(xiàn)Fragment的監(jiān)測。

1.3 數(shù)據(jù)訪問性能監(jiān)測

Android應(yīng)用絕大多數(shù)使用HTTP協(xié)議發(fā)送和接收數(shù)據(jù)。AndroidAsync Http組件提供了異步HTTP訪問功能，開發(fā)人員只要關(guān)注核心的業(yè)務(wù)處理功能，使用Android Async Http既減少了代碼量，又提高了應(yīng)用的可維護性，在Android開發(fā)中普遍使用。

數(shù)據(jù)訪問性能分析分為2個部分：一個是HTTP網(wǎng)絡(luò)訪問；另一個是本地數(shù)據(jù)訪問，包括SQLite數(shù)據(jù)庫和ContentResolver。

HTTP網(wǎng)絡(luò)分析包括5個方面：

1)HTTP接口響應(yīng)時間是刻畫HTTP訪問質(zhì)量最重要的指標(biāo)，它通過3個指標(biāo)(接口的平均響應(yīng)時間、接口響應(yīng)時間中位數(shù)和接口響應(yīng)時間標(biāo)準(zhǔn)差)來表示。

2)HTTP接口訪問頻率分析對一個應(yīng)用中所有接口訪問進行歸類，計算出不同接口的訪問次數(shù)和頻率。HTTP接口訪問頻率的分析可以發(fā)現(xiàn)訪問次數(shù)多的接口(稱為高頻接口)。高頻接口是服務(wù)端并發(fā)壓力的最大來源，結(jié)合HTTP接口響應(yīng)時間，發(fā)現(xiàn)高頻接口的訪問性能。保證高頻接口訪問性能也是應(yīng)用質(zhì)量的保證。

3)HTTP訪問性能監(jiān)測還對接口請求的地理分布進行了分析。地理分布是對不同省份HTTP請求發(fā)起情況的分析。掌握HTTP請求的地理分布可以調(diào)節(jié)服務(wù)端的分布，優(yōu)化服務(wù)端的配置。

4)HTTP請求發(fā)生錯誤是一個比較嚴(yán)重的問題，會影響大范圍的用戶，通過查詢記錄HTTP請求的最新錯誤，開發(fā)者可以快速定位問題，進行修復(fù)工作，把錯誤造成的損失降到最低。

5)用戶使用應(yīng)用時會處于不同的網(wǎng)絡(luò)環(huán)境，對HTTP請求的網(wǎng)絡(luò)訪問類型進行分析，可以知道2G、3G和4G等不同網(wǎng)絡(luò)類型訪問比例，用它來對接口返回的數(shù)據(jù)進行調(diào)整，以合適的數(shù)據(jù)量返回給用戶，避免在網(wǎng)絡(luò)情況差的條件下返回大量數(shù)據(jù)給用戶，造成用戶等待時間過長的糟糕體驗，也避免返回的數(shù)據(jù)量過小，用戶頻繁請求增大并發(fā)壓力。

本地數(shù)據(jù)訪問分析主要有4個方面：1)數(shù)據(jù)訪問用時；2)數(shù)據(jù)訪問發(fā)生的頻率；3)最近發(fā)生的數(shù)據(jù)訪問錯誤；4)不同數(shù)據(jù)訪問類型的比例。前3個方面的分析與HTTP請求分析類似。數(shù)據(jù)訪問類型分析是根據(jù)數(shù)據(jù)訪問內(nèi)容將其分為insert、update、query、delete和other幾類，分析這些類型的比例。通過分析結(jié)果，開發(fā)者可根據(jù)各類別接口訪問的頻率有針對性地改進接口。

2 案例分析

本章選擇一個具有代表性的電商應(yīng)用作為分析案例，介紹如何在應(yīng)用中集成Android應(yīng)用性能測試與監(jiān)控SDK，同時也對SDK功能模塊和服務(wù)端分析進行驗證。

2.1 待測應(yīng)用介紹

在豐富的移動應(yīng)用中，每種應(yīng)用都有各自的特點，其中有代表性的一類是購物應(yīng)用。移動購物已經(jīng)是群眾生活的常見需求，具有廣大的用戶群體。因為購物應(yīng)用廣泛，用戶對應(yīng)用的質(zhì)量要求比較高，希望應(yīng)用具有良好的用戶體驗和較為豐富的功能[24-25]。本案例分析惠海88平臺移動購物應(yīng)用，它提供了豐富的應(yīng)用功能：包括商品展示、商品查找、購物、支付、訂單管理、地址管理、個人信息管理和協(xié)同通訊等功能。

2.2 監(jiān)測實驗分析

在應(yīng)用過程中收集用戶使用情況，每日用戶應(yīng)用增長情況如圖10所示。

圖10 應(yīng)用日新增用戶

從圖10中可以知道每一天應(yīng)用的增長人數(shù)，通過分析用戶數(shù)量的變化，可預(yù)測未來較短時間段內(nèi)應(yīng)用的人數(shù)增長變化。圖10中該應(yīng)用每日的平均新增用戶為4.37個。

圖11是該應(yīng)用每日的使用次數(shù)，由圖可知應(yīng)用每日的使用次數(shù)在逐漸增加，說明應(yīng)用的人氣增加了，這也和越來越多的用戶使用有關(guān)。

圖11 應(yīng)用每日使用次數(shù)

圖12是用戶存留分析的結(jié)果。從圖中知道，隨著時間的推移，應(yīng)用每一周的使用人數(shù)在逐漸增加，每周的存留用戶數(shù)也在逐漸增加，用戶每周的存留率亦在增加，對于應(yīng)用來說這是一個良好的趨勢，應(yīng)用在一周內(nèi)留住用戶的能力越來越強。

圖12 存留用戶分析

2.3 Activity和Fragment監(jiān)測

圖13是Activity加載時間分析結(jié)果，從圖中知道GuideActivity平均加載時間是1450 ms，中位數(shù)是1310 ms，標(biāo)準(zhǔn)差是122 ms。由這組數(shù)據(jù)可推斷出GuideActivity頁面加載時間長，頁面展現(xiàn)給用戶的速度比較慢，應(yīng)用開發(fā)者需要對GuideActivity進行修改以提高頁面響應(yīng)速度。

圖13 Activity使用時間

對HTTP接口訪問的頻率分析，其中findInfoList.action接口訪問次數(shù)最多，達到1355次。對這些高頻接口，開發(fā)者需要密切關(guān)注，隨著用戶的增長，這些接口的訪問次數(shù)也會增加，它們是服務(wù)端并發(fā)壓力的主要來源。

3 結(jié)束語

本文對移動應(yīng)用性能測試與監(jiān)控技術(shù)進行研究，采用了代碼無侵入性的方案，設(shè)計并且實現(xiàn)了Android應(yīng)用性能測試與監(jiān)控方案。無侵入性的實現(xiàn)方便開發(fā)者使用，也易集成到應(yīng)用當(dāng)中去，提高其適用性。同時通過對監(jiān)測結(jié)果進行分析，開發(fā)者可以獲取有關(guān)應(yīng)用性能和運營方面的數(shù)據(jù)信息，幫助開發(fā)者快速定位問題，有效改進軟件產(chǎn)品質(zhì)量。接下來還有以下2個值得改進和深入研究的方面：1)研究和實現(xiàn)更多Android組件的監(jiān)測，捕獲更細(xì)膩的用戶行為習(xí)慣；2)進一步挖掘應(yīng)用監(jiān)測數(shù)據(jù)，從更多的維度去解讀應(yīng)用。