背景
產(chǎn)品反饋在天氣的小時趨勢圖中, 左右滑動非常的卡頓. 在我的sony低版本手機上, 確實發(fā)現(xiàn)卡頓的比較嚴(yán)重, 因此需要優(yōu)化一下, 看看UI線程的耗時操作的具體位置.
使用Hugo初步定位
WeatherHourlyTrendsView.java
@Override
@DebugLog
protected void onDraw(Canvas canvas) {
final DataSet dataSet = mDataSet;
final int size;
if (dataSet == null || (size = dataSet.size()) == 0)
return;
Log打印結(jié)果:
hugo_1.png
可以看到, onDraw()方法執(zhí)行了324ms, 顯然這里存在很大的問題.
使用TraceView具體分析
先把@DebugLog注釋去掉, 否則抓取的trace文件沒有可讀性.
直接使用DDMS中的start method profiling和stop method profiling 抓取到.trace文件.
在Find輸入框, 輸入 "WeatherHourlyTrendsView" 找到onDraw()方法.
traceview_1.png
可以看到onDraw()的執(zhí)行內(nèi)部, JLog.i()方法的耗時占據(jù)了64.8%. 其實就是簡單的Log打印造成了UI卡頓的最重要的原因.
使用Hugo初步確認(rèn)優(yōu)化結(jié)果
去掉JLog.i()調(diào)用后, 再次看hugo的輸出.
hugo_2.png
現(xiàn)在onDraw()方法執(zhí)行了66ms, 可見優(yōu)化結(jié)果還是非常理想的.
再次用TraceView分析
traceview_2.png
可見, 優(yōu)化后, 現(xiàn)在onDraw()方法中最耗時的操作在getWeatherIcon()中.
public Bitmap getWeatherIcon(int position) {
int weatherCode = Integer.valueOf(data.get(position).getWeathercode());
int resId = WeatherCommon.getIconByWeatherCode(weatherCode);
Bitmap bitmap = BitmapFactory.decodeResource(mContext.getResources(), resId);
return bitmap;
}
這里也是一個比較明顯的可優(yōu)化點. 現(xiàn)在每次都new 一個Bitmap對象出來, 顯然是不合理的, 應(yīng)該用一個LruCache對這些Bitmap對象進行統(tǒng)一的管理, 避免每次都new對象出來用.
-------DONE.------
