转载请注明文章出处LooperJing！
 

 
一、FPS评测应用流畅度不准确
 
说到应用的流畅度，都会想到FPS，系统获取FPS的原理是：手机屏幕显示的内容是通过Android系统的SurfaceFLinger类，把当前系统里所有进程需要显示的信息合成一帧，然后提交到屏幕上进行显示，FPS就是1秒内SurfaceFLinger提交到屏幕的帧数。用FPS来评测一个应用是否真的卡顿存在两个问题。
 
有的时候FPS很低，APP看起来却很流畅；
 
APP停止操作之后，FPS还是在一直变化，这种情况是否会影响到FPS的准确度？
 
有的时候FPS很低，APP看起来却很流畅，是因为当前界面在1秒内只需要10帧的显示需求，当然不会卡顿，此时FPS只要高于10就可以了，如果屏幕根本没有绘制需求，那FPS的值就是0。
 
Android性能优化第(四)篇---Android渲染机制说过，Android系统每隔16ms发出VSYNC信号，触发对UI的渲染，16ms没完成绘制就会卡顿。VSync机制就像是一台转速固定的发动机(60转/s)。每一转会带动着去做一些UI相关的事情，但不是每一转都会有工作去做(就像有时在空挡，有时在D档)。有时候因为各种阻力某一圈工作量比较重超过了16.6ms，那么这台发动机这秒内就不是60转了，当然也有可能被其他因素影响，比如给油不足(主线程里干的活太多)等等，就会出现转速降低的状况。我们把这个转速叫做流畅度。当流畅度越小的时候说明当前程序越卡顿。
 
二、Choreographer帧率检测原理
 
我们有时候会看到这样的log，系统帮助我们打印出了跳帧数。
 
02-07 19:47:04.333 17601-17604/zhangwan.wj.com.choreographertest D/dalvikvm: GC_CONCURRENT freed 143K, 3% free 9105K/9384K, paused 2ms+0ms, total 6ms
 
02-07 19:47:04.337 17601-17601/zhangwan.wj.com.choreographertest I/Choreographer: Skipped 60 frames! The application may be doing too much work on its main thread.
 
02-07 19:47:11.685 17601-17601/zhangwan.wj.com.choreographertest I/Choreographer: Skipped 85 frames! The application may be doing too much work on its main thread.
 
02-07 19:47:12.545 17601-17601/zhangwan.wj.com.choreographertest I/Choreographer: Skipped 37 frames! The application may be doing too much work on its main thread.
 
02-07 19:47:14.893 17601-17601/zhangwan.wj.com.choreographertest I/Choreographer: Skipped 37 frames! The application may be doing too much work on its main thread.
 
02-07 19:47:23.049 17601-17601/zhangwan.wj.com.choreographertest I/Choreographer: Skipped 36 frames! The application may be doing too much work on its main thread.
 
02-07 19:47:23.929 17601-17601/zhangwan.wj.com.choreographertest I/Choreographer: Skipped 37 frames! The application may be doing too much work on its main thread.
 
02-07 19:47:24.961 17601-17601/zhangwan.wj.com.choreographertest I/Choreographer: Skipped 61 frames! The application may be doing too much work on its main thread.
 
02-07 19:47:25.817 17601-17601/zhangwan.wj.com.choreographertest I/Choreographer: Skipped 36 frames! The application may be doing too much work on its main thread.
 
02-07 19:47:26.433 17601-17601/zhangwan.wj.com.choreographertest I/Choreographer: Skipped 36 frames! The application may be doing too much work on its main thread.
 
这个log就出自于Choreographer中(英[ˌkɒrɪ'ɒɡrəfə(r)] 美[ˌkɒrɪ'ɒɡrəfə(r)])。
 
void doFrame(long frameTimeNanos, int frame) {
 
final long startNanos;
 
synchronized (mLock) {
 
if (!mFrameScheduled) {
 
return; // no work to do
 
}
 
if (DEBUG_JANK && mDebugPrintNextFrameTimeDelta) {
 
mDebugPrintNextFrameTimeDelta = false;
 
Log.d(TAG, "Frame time delta: "
 
+ ((frameTimeNanos - mLastFrameTimeNanos) * 0.000001f) + " ms");
 
}
 
long intendedFrameTimeNanos = frameTimeNanos;
 
startNanos = System.nanoTime();
 
final long jitterNanos = startNanos - frameTimeNanos;
 
if (jitterNanos >= mFrameIntervalNanos) {
 
final long skippedFrames = jitterNanos / mFrameIntervalNanos;
 
if (skippedFrames >= SKIPPED_FRAME_WARNING_LIMIT) {
 
Log.i(TAG, "Skipped " + skippedFrames + " frames! "
 
+ "The application may be doing too much work on its main thread.");
 
}
 
final long lastFrameOffset = jitterNanos % mFrameIntervalNanos;
 
if (DEBUG_JANK) {
 
Log.d(TAG, "Missed vsync by " + (jitterNanos * 0.000001f) + " ms "
 
+ "which is more than the frame interval of "
 
+ (mFrameIntervalNanos * 0.000001f) + " ms! "
 
+ "Skipping " + skippedFrames + " frames and setting frame "
 
+ "time to " + (lastFrameOffset * 0.000001f) + " ms in the past.");
 
}
 
frameTimeNanos = startNanos - lastFrameOffset;
 
}
 
}
 
}
 
其中SKIPPED_FRAME_WARNING_LIMIT是Choreographer的成员变量。
 
// Set a limit to warn about skipped frames.
 
// Skipped frames imply jank.
 
private static final int SKIPPED_FRAME_WARNING_LIMIT =SystemProperties.getInt( "debug.choreographer.skipwarning", 30);
 
也就是当跳帧数大于设置的SKIPPED_FRAME_WARNING_LIMIT 值时会在当前进程输出这个log。由于 SKIPPED_FRAME_WARNING_LIMIT 的值默认为 30，所以上面的log并不是经常看到，如果我们用反射的方法把SKIPPED_FRAME_WARNING_LIMIT的值设置成1，这样可以保证只要有丢帧，就会有上面的log输出来。
 
static {
 
try {
 
Field field = Choreographer.class.getDeclaredField("SKIPPED_FRAME_WARNING_LIMIT");
 
field.setAccessible(true);
 
field.set(Choreographer.class,1);
 
} catch (Throwable e) {
 
e.printStackTrace();
 
}
 
}
 
注意，这个方案是 API 16 以上才支持。Choreographer就是一个消息处理器，根据vsync 信号 来计算frame，而计算frame的方式就是处理三种回调，包括事件回调、动画回调、绘制回调。这三种事件在消息输入、加入动画、准备绘图layout 等动作时均会发给Choreographer。一句话，我们只要捕获这个log提取出skippedFrames 就可以知道界面是否卡顿。
 
三、如何检测
 
采用上面的方式就可以在App内部观测当前App的流畅度了。并且在丢帧的地方打印，就可以知道丢帧的大概原因，大概位置，定位代码问题。
 
在Choreographer中有个回调接口，FrameCallback。
 
public interface FrameCallback {
 
//当新的一帧被绘制的时候被调用。
 
public void doFrame(long frameTimeNanos);
 
}
 
根据上面的代码，重写doFrame方法，所以照葫芦画瓢，自定义FrameCallback。我们可以在每一帧被渲染的时候记录下它开始渲染的时间，这样在下一帧被处理时，判断上一帧在渲染过程中是否出现掉帧。
 
public class SMFrameCallback implements Choreographer.FrameCallback {
 
public static SMFrameCallback sInstance;
 
private String TAG="SMFrameCallback";
 
public static final float deviceRefreshRateMs=16.6f;
 
public static long lastFrameTimeNanos=0;//纳秒为单位
 
public static long currentFrameTimeNanos=0;
 
public void start() {
 
Choreographer.getInstance().postFrameCallback(SMFrameCallback.getInstance());
 
}
 
public static SMFrameCallback getInstance() {
 
if (sInstance == null) {
 
sInstance = new SMFrameCallback();
 
}
 
return sInstance;
 
}
 
@Override
 
public void doFrame(long frameTimeNanos) {
 
if(lastFrameTimeNanos==0){
 
lastFrameTimeNanos=frameTimeNanos;
 
Choreographer.getInstance().postFrameCallback(this);
 
return;
 
}
 
currentFrameTimeNanos=frameTimeNanos;
 
float value=(currentFrameTimeNanos-lastFrameTimeNanos)/1000000.0f;
 
final int skipFrameCount = skipFrameCount(lastFrameTimeNanos, currentFrameTimeNanos, deviceRefreshRateMs);
 
Log.e(TAG,"两次绘制时间间隔value="+value+" frameTimeNanos="+frameTimeNanos+" currentFrameTimeNanos="+currentFrameTimeNanos+" skipFrameCount="+skipFrameCount+"");
 
lastFrameTimeNanos=currentFrameTimeNanos;
 
Choreographer.getInstance().postFrameCallback(this);
 
}
 
/**
 
*
 
*计算跳过多少帧
 
* @param start
 
* @param end
 
* @param devicefreshRate
 
* @return
 
*/
 
private int skipFrameCount(long start,long end,float devicefreshRate){
 
int count =0;
 
long diffNs=end-start;
 
long diffMs = Math.round(diffNs / 1000000.0f);
 
long dev=Math.round(devicefreshRate);
 
if(diffMs>dev){
 
long skipCount=diffMs/dev;
 
count=(int)skipCount;
 
}
 
return count;
 
}
 
}
 
在需要检测的Activity中调用 SMFrameCallback.getInstance().start()即可。一般优化一下，可以在BaseActivity去调用或者Activitylifecyclecallbacks中去调用.
 
正常情况下输出的日志是：
 
02-07 20:18:52.605 6683-6683/zhangwan.wj.com.choreographertest E/SMFrameCallback: 两次绘制时间间隔value=16.666666 frameTimeNanos=6996166386820 currentFrameTimeNanos=6996166386820 skipFrameCount=0
 
02-07 20:18:52.621 6683-6683/zhangwan.wj.com.choreographertest E/SMFrameCallback: 两次绘制时间间隔value=16.666666 frameTimeNanos=6996183053486 currentFrameTimeNanos=6996183053486 skipFrameCount=0
 
02-07 20:18:52.637 6683-6683/zhangwan.wj.com.choreographertest E/SMFrameCallback: 两次绘制时间间隔value=16.666666 frameTimeNanos=6996199720152 currentFrameTimeNanos=6996199720152 skipFrameCount=0
 
02-07 20:18:52.657 6683-6683/zhangwan.wj.com.choreographertest E/SMFrameCallback: 两次绘制时间间隔value=16.666666 frameTimeNanos=6996216386818 currentFrameTimeNanos=6996216386818 skipFrameCount=0
 
02-07 20:18:52.673 6683-6683/zhangwan.wj.com.choreographertest E/SMFrameCallback: 两次绘制时间间隔value=16.666666 frameTimeNanos=6996233053484 currentFrameTimeNanos=6996233053484 skipFrameCount=0
 
02-07 20:18:52.689 6683-6683/zhangwan.wj.com.choreographertest E/SMFrameCallback: 两次绘制时间间隔value=16.666666 frameTimeNanos=6996249720150 currentFrameTimeNanos=6996249720150 skipFrameCount=0
 
有跳帧的时候输出的日志是
 
02-07 20:21:53.909 9530-9530/zhangwan.wj.com.choreographertest E/SMFrameCallback: 两次绘制时间间隔value=16.666666 frameTimeNanos=7177466379568 currentFrameTimeNanos=7177466379568 skipFrameCount=0
 
02-07 20:21:53.925 9530-9530/zhangwan.wj.com.choreographertest E/SMFrameCallback: 两次绘制时间间隔value=16.666666 frameTimeNanos=7177483046234 currentFrameTimeNanos=7177483046234 skipFrameCount=0
 
02-07 20:21:54.133 9530-9530/zhangwan.wj.com.choreographertest E/SMFrameCallback: 两次绘制时间间隔value=200.0 frameTimeNanos=7177683046226 currentFrameTimeNanos=7177683046226 skipFrameCount=11
 
02-07 20:21:54.745 9530-9530/zhangwan.wj.com.choreographertest E/SMFrameCallback: 两次绘制时间间隔value=616.6666 frameTimeNanos=7178299712868 currentFrameTimeNanos=7178299712868 skipFrameCount=36
 
02-07 20:21:54.757 9530-9530/zhangwan.wj.com.choreographertest E/SMFrameCallback: 两次绘制时间间隔value=16.666666 frameTimeNanos=7178316379534 currentFrameTimeNanos=7178316379534 skipFrameCount=0
 
02-07 20:21:54.773 9530-9530/zhangwan.wj.com.choreographertest E/SMFrameCallback: 两次绘制时间间隔value=16.666666 frameTimeNanos=7178333046200 currentFrameTimeNanos=7178333046200 skipFrameCount=0
 
02-07 20:21:54.789 9530-9530/zhangwan.wj.com.choreographertest E/SMFrameCallback: 两次绘制时间间隔value=16.666666 frameTimeNanos=7178349712866 currentFrameTimeNanos=7178349712866 skipFrameCount=0
 
看到两次绘制的时间间隔相差616.6666毫秒，跳过了36帧，这个卡顿用户是能够明显感知的。
 
Please accept mybest wishes for your happiness and success ！

 
原标题：最新手机性能/流畅度排名：黑鲨锁定性能之王，一加9R最流畅
 
近日，国内知名两大跑分软件安兔兔和鲁大师，均公布了4月最新手机性能和流畅度排名，如果大家最近有更换手机的念头，不妨了解一下，但笔者建议大家不要太把榜单当回事，因为排名不代表一切。
 

 
2021年4月Android旗舰手机性能排名
 
从最新的性能榜单可以看出，前十款手机跑分均超过了80万，其中游戏手机排名都很靠前，尤其是黑鲨4 Pro的16GB+512GB版本，配合定制SSD，最终跑分达到了86W+，排在榜单第一名，如果是重度游戏玩家，黑鲨4 Pro会是不错的选择。
 
主流手机中，OPPO Find X3 Pro的12GB+256GB跑分最高，来到了83W+，具体排名榜单如下。
 
【性能榜单】
 
第一名：黑鲨4 Pro
 
第二名：OPPO Find X3 Pro
 
第三名：红魔6 Pro
 
第四名：一加9 Pro
 
第五名：拯救者2 Pro
 
第六名：vivo X60 Pro+
 
第七名：iQOO 7
 
第八名：一加9
 
第九名：小米11UItra
 
第十名：小米11
 

 
2021年4月新发布手机流畅度排名
 
看完了Android旗舰手机性能榜单，接下来看看4月新发布手机里，流畅度排名如何。
 
搭载骁龙870处理器，频繁让你相信“有光”的一加9R成为了最流畅的手机，原因是其系统从氢OS升级到了Color OS，功能升级的前提下，流畅度丝毫不输氢OS系统。
 
具体排名如下。
 
【流畅度榜单】
 
第一名：一加9R
 
第二名：拯救者2 Pro
 
第三名：Redmi K40游戏增强版
 
第四名：realme Q3 Pro
 
第五名：realme Q3
 
第六名：中兴Axon30 UItra
 
第七名：realme X7 Pro至尊版
 
第八名：Xperia 1 III
 
第九名：中兴Axon30 Pro
 
第十名：Xperia 5 III
 

 
黑鲨4 Pro有小米做背书，系统体验和销量渠道上完全无需担心，加上黑鲨4 Pro产品力又如此强，性能与销量双赢。
 
黑鲨4 Pro标配8GB内存，采用增强版LPDDR5，频率为6400MHz，标配增强版UFS3.1，同时该机内置了SSD磁盘阵列系统，大幅提升了游戏加载速度。
 
另外，黑鲨4 Pro内置4500mAh电池，支持120W快充，续航与充电兼得，屏幕方面则采用了一块6.67英寸E4屏，支持144Hz刷新率。
 

 
一加9R起售价2999，搭载骁龙870处理器，这款手机相比同级别的realme GT、Redmi K40 Pro来说，除了充电，其他几乎都比不过友商机型。
 
一加9R搭载骁龙870，却标配LPDDR4X+UFS3.0，配备6.55英寸AMOLED直面屏，虽然素质不错，但不是E4，放在2021年显然力不从心了，后置4800万+1600万+500万+200万四摄，覆盖全场景拍照，但拍照水平并不出色，内置4500mAh电池，支持65W快充，充电方面还是挺强的。
 

 
以上是安兔兔公布的2021年4月Android旗舰手机性能榜单，以及鲁大师公布的2021年4月新发布手机流畅度榜单，两款手机脱颖而出，排在了榜单第一名，分别是黑鲨4 Pro和一加9R，一款定位游戏体验的旗舰手机，另一款定位3000档次旗舰手机，你会考虑哪款呢？或者都不考虑？返回搜狐，查看更多
 
责任编辑：

 
直奔主题
 
消息气泡，
 
Android 11系统通过增添悬浮的聊天气泡，让我们如今可以直接在主屏幕上一键打开并创建对话、发送消息，使我们的日常聊天操作可以变得更加快速便捷，更加的贴近我们的使用习惯，更加的人性化。
 

 
省电，
 
Android 11系统其同样也还带来了全新的性能模式和省电模式，其超级省电功能更是同样也是得到了不小的提升，并且Android 11还可以通过AI技术来进行动态调整电池的使用模式，以此来节省设备更多的电量，提高其硬件整体的续航时间，再次的减少了我们电量不够用的困扰。
 
相机，
 
Android 11系统取消了应用调用第三方相机应用的功能，其系统会自动的进行选择预装的相机应用，当然了这么做的原因自然也是考虑到了有关我们发隐私和安全。当然，第三方相机App的使用并不受影响，我们的确也仍是可以用第三方相机应用来进行拍照、摄像，Android 11封堵的大多都只是应用的一部分调用权限而已。
 

 
隐私保护，
 
Android 11系统对此项功能的升级，使得如今不少应用在使用涉及到我们的一些隐私时，其会需经过用户多次的许可才可以接触到我们的重要隐私权限；这个我们同样也可以这样理解，那就是应用在请求我们给予其一次重要隐私比如说使用定位后，当应用再次需要这个权限时，其还得必须向我们进行重新发起请求才行，这着实也是变向的提升了一下我们隐私的安全等级不是吗？
 
个性化定制，
 
与此同时，Android 11系统还支持了更多的个性化定制，包括修改系统风格色彩、控制中心定制图标形状与颜色、桌面支持第三方图标包、三种暗色模式等等，这着实又是使其增加了不少的可玩性，不是吗？
 

 
最后
 
那么对于如今的Android 11系统，大家又是怎么看的呢？另外在如今你又是否升级到了Android 11系统呢？欢迎在下方评论区留言讨论，谢谢。
 

 
android提高UI的流畅度
 
Android中所有的界面绘制工作都是在UI线程中进行的，提高UI流畅度的最核心根本在于释放UI线程。即:不在主线程中做耗时的操作。
 
很多人都知道，耗时的操作要放到子线程中去做，比如访问网络，比如读写sd卡。像这类操作大家都会很自然的想到使用子线程来完成耗时的操作，等操作结束之后，再通过Handler通知主线程进行界面的更新。这是非常正确的方法。但是有一类方法，它必须得运行在在UI线程中，就是布局文件的加载。如果这类方法花的时间太多了，也是会对流畅度产生很大的影响。今天我们就来讲讲布局文件的优化。
 
加载布局文件，是必须在UI线程中完成的。我们通常是在onCreate方法中直调用setContentView，传入一个布局文件的id值，或者是通过LayoutInflater来将某一个布局文件转化成View对象。其实这两种方式的本质都是一样的，都是将xml文件转换成View对象。
 
我们现在要做的事，就是如何让xml文件转换成View对象所花的时间最少。做到了这点，就可以很大程度的提高UI的流畅度。
 
1、优化布局, 减少布局的嵌套层级
 
** a、使用drawableXXX属性**
 

 
image.png
 
如果要实现这样一个效果，布局文件可以这样写
 
优化后：
 
直接一个TextView就搞定，不需要在外面多一层LinearLayout
 
** b、多使用RelativeLayout，少使用LinearLayout**
 

 
image.png
 
如果这样的布局使用LinearLayout来做的话，那么会是以下这个效果
 

 
image.png
 
这样就莫名其妙的多出了好多个LinearLayout.
 
这样过多的LinearLayout嵌套LinearLayout，会造成UI加载的非常慢。这样的布局完全可以使用一个RelativeLayout来完成，里面的子元素根据相对于其他控件的位置即可确定。
 
嵌套使用LinearLayout很容易会导致视图层级过深。如果使用layout_weight这个参数不断的进行嵌套，有可能会让各个子View付出计算两次的昂贵代价
 
优化后代码：
 
....
 
** c、使用merge标签**
 
使用merge标签也是能够减少一些布局的层次。merge标签经常会和include标签相联系。
 
那么什么时候使用merge标签呢？下面举例子说明。
 
......
 
......
 
而include_view_layout.xml 的代码如下：
 
我们看到Button的父控件是LinearLayout，而include的父控件也是LinearLayout，这样子的布局最终的结果是
 
红色部分的LinearLayout完全是多余，于是这时候，我们就可以在include_view_layout.xml文件中使用merge标签了。如下：
 
这样，在加载这个include标签的时候，系统会忽略merge标签，直接将merge标签内的元素添加到外层的LinearLayout去了，达到减少层级的效果。
 
2、延迟加载
 
在开发某些功能时候，有时候需要动态的根据条件来判断显示哪一个View，不显示哪一个View。一般的做法是将所有的View都写在布局文件中去，然后根据条件再来设置他们的可见度Visibility为GONE或者VISIBLE。这种做法逻辑简单，便于理解。但是缺点就是那些不显示出来的View也占用了内存，消耗了inflate的时间。因为一个View，不论他的Visibility的值是什么，它都会被inflate出来，并占用内存空间。这时候其实就可以用到延迟加载的控件ViewStub了。
 
ViewStub是一个非常轻量级的控件，它占的资源非常小。注意，是ViewStub这个对象所占的资源小，但是你可以为ViewStub指定一个布局文件，这个布局文件被inflate的时候占的空间有可能很大。默认的情况下，ViewStub的所指定的布局文件是不被inflate的，只有当你调用了ViewStub的inflate方法时，ViewStub所指向的布局文件才会被inflate。所以ViewStub是一个延迟加载的控件。
 

 
android:orientation="vertical"
 
android:layout_width="fill_parent"
 
android:layout_height="fill_parent"
 
android:gravity="center_horizontal">
 

 
android:id="@+id/viewstub1"
 
android:layout_width="wrap_content"
 
android:layout_height="wrap_content"
 
android:layout="@layout/viewstub_layout1"/>
 

 
android:id="@+id/viewstub2"
 
android:layout_width="wrap_content"
 
android:layout_height="wrap_content"
 
android:layout="@layout/viewstub_layout2"/>
 
在java代码中使用
 
ViewStub stub1 = (ViewStub) findViewById(R.id.viewstub1);
 
ViewStub stub2 = (ViewStub) findViewById(R.id.viewstub2);
 
if(isLogin()) {
 
stub1.inflate();
 
} else {
 
stub2.inflate();
 
}
 
这样就不会有浪费资源空间去加载没必要的控件了。
 
３、减少inflate的次数
 
这个的典型例子就是ListView的优化。我们说ListView的优化，实际上说的就是Adapter中getView方法的优化，我们来看一个没有优化过的getView方法。
 
@Override
 
public View getView(int position, View convertView, ViewGroup parent) {
 
MyItem product = list.get(position);
 
convertView = getLayoutInflater()
 
.inflate(R.layout.item_record, null);
 
TextView tvDate = (TextView) convertView
 
.findViewById(R.id.tvDate);
 
TextView tvYongtu = (TextView) convertView
 
.findViewById(R.id.tvYongtu);
 
TextView tvMoney = (TextView) convertView
 
.findViewById(R.id.tvMoney);
 
tvDate.setText(product.detaildate);
 
tvYongtu.setText(product.auditmessage);
 
tvMoney.setText(product.detailmoney);
 
return convertView;
 
}
 
我们知道，ListView中的每一个Item被显示出来都要调用getView方法，这个Item如果滑出屏幕，又滑回来，重新显示在界面上的时候，又会再次调用getView方法。所以getView是不断的被调用的。而上面的代码，只要调用了getView方法，就一定会去inflate一个布局文件，真简直就是不敢想象的非常耗时的操作。于是，利用系统给我们的缓存convertView进行判断，可以大大减少inflate的次数。其实，findViewById也是一个很耗时的操作，我们可以利用ViewHolder来减少findViewById的次数。优化后的代码如下：
 
@Override
 
public View getView(int position, View convertView, ViewGroup parent) {
 
MyItem product = list.get(position);
 
ViewHolder holder;
 
if (convertView == null) {
 
convertView = getLayoutInflater().inflate(
 
R.layout.item_record, null);
 
holder = new ViewHolder();
 
holder.tvDate = (TextView) convertView
 
.findViewById(R.id.tvDate);
 
holder.tvYongtu = (TextView) convertView
 
.findViewById(R.id.tvYongtu);
 
holder.tvMoney = (TextView) convertView
 
.findViewById(R.id.tvMoney);
 
convertView.setTag(holder);
 
} else {
 
holder = (ViewHolder) convertView.getTag();
 
}
 
holder.tvDate.setText(product.detaildate);
 
holder.tvYongtu.setText(product.auditmessage);
 
holder.tvMoney.setText(product.detailmoney);
 
return convertView;
 
}
 
static class ViewHolder {
 
TextView tvDate;
 
TextView tvYongtu;
 
TextView tvMoney;
 
}