970
ANDROID性能調優
https://www.trinea.cn/android/android-performance-demo/#comment-115
本文主要分享自己在appstore項目中的性能調優點，包括同步改異步、緩存、Layout優化、數據庫優化、算法優化、延遲執行等。
性能優化專題已完成五部分：
性能優化總綱——性能問題及性能調優方式
性能優化第三篇——Java(Android)代碼優化
性能優化第二篇——布局優化
性能優化第一篇——數據庫性能優化
一、性能瓶頸點
整個頁麵主要由6個Page的ViewPager，每個Page為一個GridView，GridView一屏大概顯示4*4的item信息(本文最後有附圖)。由於網絡數據獲取較多且隨時需要保持頁麵內app下載進度及狀態，所以出現以下性能問題
a. ViewPager左右滑動明顯卡頓
b. GridView上下滾動明顯卡頓
c. 其他Activity返回ViewPager Activity較慢
d. 網絡獲取到展現速度較慢
二、性能調試及定位
主要使用Traceview、monkey、monkey runner調試，traceview類似java web調優的visualvm，使用方法如下：
在需要調優的activity onCreate函數中添加
|
1
|
android.os.debug.startMethodTracing("Entertainment");
|
onDestrory函數中添加
|
1
|
android.os.debug.stopMethodTracing();
|
程序退出後會在sd卡根目錄下生成Entertainment.trace這個文件，cmd到android sdk的tools目錄下運行traceview.bat Entertainment.trace即可，截圖如下
從中可以看出各個函數的調用時間、調用次數、平均調用時間、時間占用百分比等從而定位到耗時的操作。monkey、monkey runner更詳細的見後麵博客介紹
三、性能調優點
主要包括同步改異步、緩存、Layout優化、數據庫優化、算法優化、延遲執行。
1. 同步改異步
這個就不用多講了，耗時操作放在線程中執行防止占用主線程，一定程度上解決anr。
但需要注意線程和service結合（防止activity被回收後線程也被回收）以及線程的數量
線程池使用可見java的線程池
2. 緩存
java的對象創建需要分配資源較耗費時間，加上創建的對象越多會造成越頻繁的gc影響係統響應。主要使用單例模式、緩存(圖片緩存、線程池、View緩存、IO緩存、消息緩存、通知欄notification緩存)及其他方式減少對象創建。
(1). 單例模式
對於創建開銷較大的類可使用此方法，保證全局一個實例，在程序運行過程中該類不會因新建額外對象產生開銷。示例代碼如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
public
class Singleton
{
private
static Object obj =
new Object();
private
static Singleton
instance =
null;
private
Singleton(){
}
public
static Singleton
getInstance()
{
// if already inited, no need to get lock everytime
if
(instance
== null)
{
synchronized
(obj)
{
if
(instance
== null)
{
instance
= new
Singleton();
}
}
}
return
instance;
}
}
|
(2). 緩存
程序中用到了圖片緩存、線程池、View緩存、IO緩存、消息緩存、通知欄notification緩存等。
a. 圖片緩存：見ImageCache和ImageSdCache
b. 線程池：使用Java的Executors類，通過newCachedThreadPool、newFixedThreadPool、newSingleThreadExecutor、newScheduledThreadPool提供四種不同類型的線程池
c. View緩存：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
@Override
public View
getView(int
position,
View convertView,
ViewGroup parent)
{
ViewHolder
holder;
if
(convertView
== null)
{
convertView
= inflater.inflate(R.layout.type_item,
null);
holder
= new
ViewHolder();
holder.imageView
= (ImageView)convertView.findViewById(R.id.app_icon);
holder.textView
= (TextView)convertView.findViewById(R.id.app_name);
convertView.setTag(holder);
}
else {
holder
= (ViewHolder)convertView.getTag();
}
holder.imageView.setImageResource(R.drawable.index_default_image);
holder.textView.setText("");
return
convertView;
}
/**
* ViewHolder
*/
static
class ViewHolder
{
ImageView
imageView;
TextView textView;
}
|
通過convertView是否為null減少layout inflate次數，通過靜態的ViewHolder減少findViewById的次數，這兩個函數尤其是inflate是相當費時間的
d. IO緩存：
使用具有緩存策略的輸入流，BufferedInputStream替代InputStream，BufferedReader替代Reader，BufferedReader替代BufferedInputStream.對文件、網絡IO皆適用。
e. 消息緩存：通過Handler的obtainMessage回收就的Message對象，減少Message對象的創建開銷
handler.sendMessage(handler.obtainMessage(1));
f. 通知欄notification緩存：下載中需要不斷改變通知欄進度條狀態，如果不斷新建Notification會導致通知欄很卡。這裏我們可以使用最簡單的緩存
Map<String, Notification> notificationMap = new HashMap<String, Notification>();如果notificationMap中不存在，則新建notification並且put into map.
(3). 其他
能創建基類解決問題就不用具體子類：除需要設置優先級的線程使用new Thread創建外，其餘線程創建使用new Runnable。因為子類會有自己的屬性創建需要更多開銷。
控製最大並發數量：使用Java的Executors類，通過Executors.newFixedThreadPool(nThreads)控製線程池最大線程並發
對於http請求增加timeout
3.
Layout優化
使用抽象布局標簽(include, viewstub, merge)、去除不必要的嵌套和View節點、減少不必要的infalte及其他Layout方麵可調優點，順帶提及布局調優相關工具(hierarchy viewer和lint)。具體可見性能優化之布局優化
TextView屬性優化：TextView的android:ellipsize=”marquee”跑馬燈效果極耗性能，具體原因還在深入源碼中
4. 數據庫優化
主要包括索引和事務及針對Sqlite的優化。具體可見性能優化之數據庫優化
5. 算法優化
這個就是個博大精深的話題了，隻介紹本應用中使用的。
使用hashMap代替arrayList，時間複雜度降低一個數量級
6. 延遲執行
對於很多耗時邏輯沒必要立即執行，這時候我們可以將其延遲執行。
線程延遲執行 ScheduledExecutorService scheduledThreadPool = Executors.newScheduledThreadPool(10);
消息延遲發送 handler.sendMessageDelayed(handler.obtainMessage(0), 1000);
四、本程序性能調優結果
1. ViewPager左右滑動明顯卡頓
2. GridView上下滾動明顯卡頓
(1). 去掉TextView的android:ellipsize=”marquee”
(2). 修改圖片緩存的最大線程數，增加http timeout
(3). 修改設置app是否已安裝的狀態，具體代碼修改如下：
|
1
2
3
4
5
6
7
|
List<PackageInfo>
installedPackageList
= getPackageManager().getInstalledPackages(PackageManager.GET_UNINSTALLED_PACKAGES);
List<App>
installedAppList
= function(installedAppList)
for
(App app
: appList)
{
for
(App installedApp
: installedAppList)
{
}
}
|
修改為
|
1
2
3
4
5
6
7
8
|
for
(App app
: appList)
{
Pair<Integer,
String>
versionInfo =
INSTALLED_APP_MAP.get(app.getPackageName());
if
(versionInfo
!= null)
{
}
else {
}
}
|
從每次獲取List<PackageInfo> installedAppList = getPackageManager().getInstalledPackages(PackageManager.GET_UNINSTALLED_PACKAGES);修改為隻在有應用安裝或卸載廣播時獲取應用列表，並且用hashMap代替installedAppList減少查詢時間。
將平均執行時間從201ms降低到1ms。
3. 其他Activity返回ViewPager Activity較慢
定位：在onStart函數
解決：使用延遲策略，具體代碼修改如下：
|
1
2
3
4
5
|
@Override
public void
onStart()
{
super.onStart();
appUpdateListAdapter.notifyDataSetChanged();
}
|
改為
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
public
void onStart()
{
super.onStart();
// delay send message
handler.sendMessageDelayed(handler.obtainMessage(MessageConstants.WHAT_NOTIFY_DATA_CHANGED),
100);
}
private
class MyHandler
extends Handler
{
@Override
public
void handleMessage(Message
msg)
{
super.handleMessage(msg);
switch
(msg.what)
{
case
MessageConstants.WHAT_NOTIFY_DATA_CHANGED:
if
(appUpdateListAdapter
!= null)
{
appUpdateListAdapter.notifyDataSetChanged();
}
break;
}
}
}
|
4. 網絡獲取到展現速度較慢
定位：在HttpURLConnection.getInputStream()之後的處理
解決：使用BufferedReader替代BufferedInputStream獲取時間從100ms降低到3ms，具體代碼修改如下：
|
1
2
3
4
5
|
HttpURLConnection
con =
(HttpURLConnection)url.openConnection();
InputStream input
= con.getInputStream();
while
(input.read(buffer,
0,
1024)
!= -1)
{
}
|
改為
|
1
2
3
4
5
6
|
HttpURLConnection
con =
(HttpURLConnection)url.openConnection();
BufferedReader input
= new
BufferedReader(new
InputStreamReader(con.getInputStream()));
String
s;
while ((s
= input.readLine())
!= null)
{
}
|
性能優化係列總篇
本文為性能優化係列的總綱，主要介紹性能調優專題計劃、何為性能問題、性能調優方式及前麵介紹的數據庫優化、布局優化、Java(Android)代碼優化具體對應的調優方式。
1、調優專題博客計劃
目前調優專題已完成五部分：
性能優化總綱——性能問題及性能調優方式
性能優化第三篇——Java(Android)代碼優化
性能優化第二篇——布局優化
性能優化第一篇——數據庫性能優化
後續計劃性能優化——診斷及工具(目前隻有關於TraceView的介紹)、性能優化——內存篇、性能優化——JNI篇，性能優化——電量篇。
2、何為性能問題
在性能測試中存在兩個概念：
(1). 響應時間
指從用戶操作開始到係統給用戶以正確反饋的時間。一般包括係統處理時間 + 網絡傳輸時間 + 展現時間。對於非網絡類應用不包括網絡傳輸時間。響應時間是用戶對性能最直接的感受。
(2). TPS(Transaction Per Second)
TPS為每秒處理的事務數，是係統吞吐量的指標，在搜索係統中也用QPS(Query Per Second)衡量。TPS一般與響應時間反相關。
通常所說的性能問題就是指響應時間過長、係統吞吐量過低。在web性能測試中，也會將高並發下內存泄漏歸為性能問題。
在Android應用程序中由於係統ANR的限製，所以對主線程的響應時間提出了更高的要求。Android ANR的具體要求是指Activity對事件響應不超過5秒，BroadcastReceiver中執行時間不超過10秒。
3、性能調優方式
明白了何為性能問題之後，就能明白性能優化實際就是優化係統的響應時間，提高TPS。優化響應時間，提高TPS的方式包括：
(1) 降低執行時間
這部分包括：a. 緩存(包括對象緩存、IO緩存、網絡緩存), b. 數據存儲類型優化, c. 算法優化, d. JNI, e. 邏輯優化, f. 需求優化
(2) 同步改異步，利用多線程提高TPS
(3) 提前或延遲操作，錯開時間段提高TPS
對於數據庫優化、布局優化、Java代碼部分優化都可以歸納到上麵的幾種方式中。具體見：
性能優化第三篇——Java(Android)代碼優化
性能優化第二篇——布局優化
性能優化第一篇——數據庫性能優化
性能優化之布局優化
本文為Android性能優化的第二篇——布局優化，主要介紹使用抽象布局標簽(include, viewstub, merge)、去除不必要的嵌套和View節點、減少不必要的infalte及其他Layout方麵可調優點，順帶提及布局調優相關工具(hierarchy viewer和lint)。
性能優化專題已完成五部分：
性能優化總綱——性能問題及性能調優方式
性能優化第三篇——Java(Android)代碼優化
性能優化第二篇——布局優化
性能優化第一篇——數據庫性能優化
1、抽象布局標簽
(1) <include>標簽
include標簽常用於將布局中的公共部分提取出來供其他layout共用，以實現布局模塊化，這在布局編寫方便提供了大大的便利。
下麵以在一個布局main.xml中用include引入另一個布局foot.xml為例。main.mxl代碼如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
<?xml
version="1.0"
encoding="utf-8"?>
<RelativeLayout xmlns:android="https://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent"
>
<ListView
android:id="@+id/simple_list_view"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:layout_marginBottom="@dimen/dp_80"
/>
<include
layout="@layout/foot.xml"
/>
</RelativeLayout>
|
其中include引入的foot.xml為公用的頁麵底部，代碼如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
<?xml
version="1.0"
encoding="utf-8"?>
<RelativeLayout xmlns:android="https://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent"
>
<Button
android:id="@+id/button"
android:layout_width="match_parent"
android:layout_height="@dimen/dp_40"
android:layout_above="@+id/text"/>
<TextView
android:id="@+id/text"
android:layout_width="match_parent"
android:layout_height="@dimen/dp_40"
android:layout_alignParentBottom="true"
android:text="@string/app_name"
/>
</RelativeLayout>
|
<include>標簽唯一需要的屬性是layout屬性，指定需要包含的布局文件。可以定義android:id和android:layout_*屬性來覆蓋被引入布局根節點的對應屬性值。注意重新定義android:id後，子布局的頂結點i就變化了。
(2) <viewstub>標簽
viewstub標簽同include標簽一樣可以用來引入一個外部布局，不同的是，viewstub引入的布局默認不會擴張，即既不會占用顯示也不會占用位置，從而在解析layout時節省cpu和內存。
viewstub常用來引入那些默認不會顯示，隻在特殊情況下顯示的布局，如進度布局、網絡失敗顯示的刷新布局、信息出錯出現的提示布局等。
下麵以在一個布局main.xml中加入網絡錯誤時的提示頁麵network_error.xml為例。main.mxl代碼如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
<?xml
version="1.0"
encoding="utf-8"?>
<RelativeLayout xmlns:android="https://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent"
>
……
<ViewStub
android:id="@+id/network_error_layout"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:layout="@layout/network_error"
/>
</RelativeLayout>
|
其中network_error.xml為隻有在網絡錯誤時才需要顯示的布局，默認不會被解析，示例代碼如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
<?xml
version="1.0"
encoding="utf-8"?>
<RelativeLayout xmlns:android="https://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent"
>
<Button
android:id="@+id/network_setting"
android:layout_width="@dimen/dp_160"
android:layout_height="wrap_content"
android:layout_centerHorizontal="true"
android:text="@string/network_setting"
/>
<Button
android:id="@+id/network_refresh"
android:layout_width="@dimen/dp_160"
android:layout_height="wrap_content"
android:layout_below="@+id/network_setting"
android:layout_centerHorizontal="true"
android:layout_marginTop="@dimen/dp_10"
android:text="@string/network_refresh"
/>
</RelativeLayout>
|
在java中通過(ViewStub)findViewById(id)找到ViewStub，通過stub.inflate()展開ViewStub，然後得到子View，如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
private
View networkErrorView;
private
void showNetError()
{
// not repeated infalte
if
(networkErrorView
!= null)
{
networkErrorView.setVisibility(View.VISIBLE);
return;
}
ViewStub stub
= (ViewStub)findViewById(R.id.network_error_layout);
networkErrorView
= stub.inflate();
Button networkSetting
= (Button)networkErrorView.findViewById(R.id.network_setting);
Button
refresh =
(Button)findViewById(R.id.network_refresh);
}
private void
showNormal()
{
if
(networkErrorView
!= null)
{
networkErrorView.setVisibility(View.GONE);
}
}
|
在上麵showNetError()中展開了ViewStub，同時我們對networkErrorView進行了保存，這樣下次不用繼續inflate。這就是後麵第三部分提到的減少不必要的infalte。
viewstub標簽大部分屬性同include標簽類似。
上麵展開ViewStub部分代碼
|
1
2
|
ViewStub
stub =
(ViewStub)findViewById(R.id.network_error_layout);
networkErrorView =
stub.inflate();
|
也可以寫成下麵的形式
|
1
2
3
|
View
viewStub =
findViewById(R.id.network_error_layout);
viewStub.setVisibility(View.VISIBLE);
// ViewStub被展開後的布局所替換
networkErrorView
= findViewById(R.id.network_error_layout);
// 獲取展開後的布局
|
效果一致，隻是不用顯示的轉換為ViewStub。通過viewstub的原理我們可以知道將一個view設置為GONE不會被解析，從而提高layout解析速度，而VISIBLE和INVISIBLE這兩個可見性屬性會被正常解析。
(3) <merge>標簽
在使用了include後可能導致布局嵌套過多，多餘不必要的layout節點，從而導致解析變慢，不必要的節點和嵌套可通過hierarchy viewer(下麵布局調優工具中有具體介紹)或設置->開發者選項->顯示布局邊界查看。
merge標簽可用於兩種典型情況：
a. 布局頂結點是FrameLayout且不需要設置background或padding等屬性，可以用merge代替，因為Activity內容試圖的parent view就是個FrameLayout，所以可以用merge消除隻剩一個。
b. 某布局作為子布局被其他布局include時，使用merge當作該布局的頂節點，這樣在被引入時頂結點會自動被忽略，而將其子節點全部合並到主布局中。
以(1) <include>標簽的示例為例，用hierarchy viewer查看main.xml布局如下圖：
可以發現多了一層沒必要的RelativeLayout，將foot.xml中RelativeLayout改為merge，如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
<?xml
version="1.0"
encoding="utf-8"?>
<merge xmlns:android="https://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent"
>
<Button
android:id="@+id/button"
android:layout_width="match_parent"
android:layout_height="@dimen/dp_40"
android:layout_above="@+id/text"/>
<TextView
android:id="@+id/text"
android:layout_width="match_parent"
android:layout_height="@dimen/dp_40"
android:layout_alignParentBottom="true"
android:text="@string/app_name"
/>
</merge>
|
運行後再次用hierarchy viewer查看main.xml布局如下圖：
這樣就不會有多餘的RelativeLayout節點了。
2、去除不必要的嵌套和View節點
(1) 首次不需要使用的節點設置為GONE或使用viewstub
(2) 使用RelativeLayout代替LinearLayout
大約在Android4.0之前，新建工程的默認main.xml中頂節點是LinearLayout，而在之後已經改為RelativeLayout，因為RelativeLayout性能更優，且可以簡單實現LinearLayout嵌套才能實現的布局。
4.0及以上Android版本可通過設置->開發者選項->顯示布局邊界打開頁麵布局顯示，看看是否有不必要的節點和嵌套。4.0以下版本可通過hierarchy viewer查看。
3、減少不必要的infalte
(1) 對於inflate的布局可以直接緩存，用全部變量代替局部變量，避免下次需再次inflate
如上麵ViewStub示例中的
|
1
2
3
4
|
if
(networkErrorView
!= null)
{
networkErrorView.setVisibility(View.VISIBLE);
return;
}
|
(2) ListView提供了item緩存，adapter getView的標準寫法，如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
|
@Override
public View
getView(int
position,
View convertView,
ViewGroup parent)
{
ViewHolder
holder;
最後更新：2017-04-03 12:55:27
上一篇： |