androidui刷新
1. Android更新UI界面的几种方法的使用
1. 利用Android Handler机制和message消息传递
我们知道 , Android Handler机制主要用作线程之间的通信，为了易于理解，我们暂不考虑每个线程的Looper问题。UI更新一般是在主线程中完成的，而Handler就是定义在主线程中，然后通过在Handler构造方法中重写HandlerMessage()方法，来处理有其他线程（子线程）传递过来的消息，从而达到更新UI的目的。相应的，在其他线程（子线程）中，我们通过SendMessage(message)方法来传递消息。
2.利用Android Handler机制和post
这个比较容易理解，也是UI更新常用的方法。 在一个新建的线程中进行更新界面的操作，然后在主线程中利用mHandler.post(Runnable runnable)来达到更新界面的目的，其中mHandler是在主线程中定义的。
3、通过runOnUiThread()方法来实现
java">classMyThreadextendsThread{
@Override
publicvoidrun(){
//TODOAuto-generatedmethodstub
super.run();
//数据处理
//...
runOnUiThread(newnewRunnable(){
publicvoidrun(){
//刷新界面
list.add(dog);
adapter.notifyDataSetChanged();
}
}
})
}
2. Android中Fragment怎样刷新UI
刷新UI要在主线程，Fragment和Activity是类似的，所以在要刷新UI的地方handler发送消息，在主线程中定义的hanler处理消息，更新UI，建议看下安卓的安卓handler机制。
3. android怎么更新UI
首先，android的UI刷新是在主线程（UI线程）中完成的。四大组件中，activity和service运行在主线程中。现在总结自己在项目中常用到的UI刷新方式。
第一，利用子线程发消息刷新UI。
子线程负责处理UI需要的数据，然后发消息到主线程来刷新UI。代码结构如下：
new Thread(new Runnable() {
@Override
public void run() {
Person person=new Person();
person.setName(mName.getText().toString().trim());
person.setPhone(mPhone.getText().toString().trim());
Log.i("person",person.toString());
DatabaseInfoFactory.getPersonDao(mContext).addPerson(person);
Looper.prepare();
Message msg=Message.obtain();
msg.what=0x123456;
handler.sendMessage(msg);
Looper.loop();
}
}).start();
主线程中：
private Handler mHandler=new Handler(){
@Override
public void handleMessage(Message msg) {
// TODO Auto-generated method stub
super.handleMessage(msg);
if(msg.what==0x123456||msg.what==0x123){
fillData();
setListener();
}
}
};
第二，利用异步任务更新UI。代码结构如下：
new AsyncTask<void,void,void>() {
@Override
protected void onPostExecute(Void result) {
if(mAdapter==null){
mAdapter=new LeaveInfoAdapter();
//设置数据适配器
mLVleaveInfos.setAdapter(mAdapter);
Log.i("测试", "异步任务显示后台获得数据库数据");
}
else {
mAdapter.notifyDataSetChanged();
}
super.onPostExecute(result);
}
@Override
protected Void doInBackground(Void... params) {
//获得要显示的数据
mleaveInfos=mLeaveInfosDao.findAll();
if (mleaveInfos==null) {
Toast.makeText(HomeActivity.this,"请假数据不存在或是已经清除！", 500).show();
}
Log.i("测试", "异步任务后台获得数据库数据"+mleaveInfos.size());
return null;
}
}.execute();</void,void,void>
第三，利用配置文件+activity的生命周期方法刷新UI。
4. android中如何实现UI的实时更新
1、在主线程中启动一个子线程
首先，我们需要在主线程中启动一个子线程，这个比较简单，直接在MainActivity的onCreate()方法中调用如下方法即可：
newThread(mRunnable).start();
2、在子线程中发送Message给Handler
在创建子线程时，我们使用了Runnable接口对象mRunnable。这里，只需要实现Runnable接口，并重写该接口的run()方法，在run()方法中实现每1秒发送一条Message给Handler即可。具体实现方法如下：
/*
*Function:实现run()方法，每1秒发送一条Message给Handler
*/
privateRunnablemRunnable=newRunnable(){
publicvoidrun(){
while(true){
try{
Thread.sleep(1000);
mHandler.sendMessage(mHandler.obtainMessage());
}catch(InterruptedExceptione){
e.printStackTrace();
}
}
}
};
3、Handler接收Message通知
最后，我们创建一个Handler对象，用来接收Message通知。在收到Message通知后，完成刷新UI的操作即可。具体实现方法如下：
/*
*Function:实现handleMessage()方法，用于接收Message，刷新UI
*/
privateHandlermHandler=newHandler(){
publicvoidhandleMessage(Messagemsg){
super.handleMessage(msg);
refreshUI();
}
};
4、刷新UI
由以上的代码可以看出，刷新UI的操作，我们是放在refreshUI()方法中来完成的。refreshUI()方法的实现也很简单，调用HttpUtils工具类中的getInputStream()方法，获得图1所示Web工程的页面内容输入流，再将该输入流转化为字符串，放入TextView控件中进行显示即可。具体实现方法如下：
/*
*Function:刷新UI
*/
privatevoidrefreshUI(){
try{
InputStreaminputStream=HttpUtils.getInputStream();
StringresultData=HttpUtils.getResultData(inputStream);
mTextView.setText(resultData);
}catch(IOExceptione){
e.printStackTrace();
}
}
5. Android UI卡顿原因及解决办法
渲染机制介绍
为了分析UI卡顿，我们有必要理解一下渲染机制，这套渲染机制适用于绝大部分的屏幕渲染，其中包括Android手机等众多屏幕设备。
渲染的一些重要参数：
屏幕刷新理想的频率（硬件的角度）：60Hz
理想的一秒内绘制的帧数，帧率（屏幕刷新的角度）：60fps
这两个参数都是理想值，指代的都是同一个概念。实际情况中难免会比它们低。在60fps内，系统会得到发送的VSYNC(垂直刷新/绘制)信号去进行渲染，就会正常地绘制出我们需要的图形界面。Android手机进行绘制的时候，GPU帮助我们将UI组件等计算成纹理Texture和三维图形Polygons，同时会使用OpenGL---会将纹理和Polygons缓存在GPU内存里面。
其中，VSYNC：有两个概念
Refresh Rate：屏幕在一秒时间内刷新屏幕的次数----有硬件的参数决定，比如60HZ，即屏幕每秒刷新60次
Frame Rate：GPU在一秒内绘制操作的帧数，比如：60fps，
基本结论
要达到60fps，就要求：每一帧只能停留16ms。（大概就是1000ms/60 ~= 16ms刷新一次）
内存抖动是因为大量的对象被创建又在短时间内马上被释放。
瞬间产生大量的对象会严重占用Young Generation的内存区域，当达到阀值，剩余空间不够的时候，也会触发GC。即使每次分配的对象占用了很少的内存，但是他们叠加在一起会增加Heap的压力，从而触发更多其他类型的GC。这个操作有可能会影响到帧率，并使得用户感知到性能问题。
Android里面是一个三级Generation的内存模型，最近分配的对象会存放在Young Generation区域，当这个对象在这个区域停留的时间达到一定程度，它会被移动到Old Generation，最后到Permanent Generation区域。
Android每个16ms就会绘制一次Activity，通过上述的结论我们知道，如果由于一些原因导致了我们的逻辑、CPU耗时、GPU耗时大于16ms( 应用卡顿的根源就在于16ms内不能完成绘制渲染合成过程,16ms需要完成视图树的所有测量、布局、绘制渲染及合成 )，UI就无法完成一次绘制，那么就会造成卡顿。
比如说，在16ms内，发生了频繁的GC：
在第一个16ms内，UI正常地完成了绘制，那么屏幕不会卡顿。
在第二个16ms内，由于某些原因触发了频发的GC，UI无法在16ms内完成绘制，就会卡顿。
UI卡顿外部和内部常见原因
下面总结一些常见的UI卡顿原因：
1.内存抖动的问题
2.方法太耗时了（CPU占用）
1） CPU计算时间，CPU的测量、布局时间
2）CPU将计算好的Polygons和Texture传递到GPU的时候也需要时间。OpenGL ES API允许数据上传到GPU后可以对数据进行保存，缓存到display list。因此，我们平移等操作一个view是几乎不怎么耗时的 。
3） GPU进行格栅化
当我们的布局是用的FrameLayout的时候，我们可以把它改成merge，可以避免自己的帧布局和系统的ContentFrameLayout帧布局重叠造成重复计算(measure和layout)。
使用ViewStub：当加载的时候才会占用。不加载的时候就是隐藏的，仅仅占用位置。
CPU优化建议
针对CPU的优化，从减轻加工View对象成Polygons和Texture来下手：
View Hierarchy中包涵了太多的没有用的view，这些view根本就不会显示在屏幕上面，一旦触发测量和布局操作，就会拖累应用的性能表现。那么我们就需要利用工具进行分析。
如何找出里面没用的view呢？或者减少不必要的view嵌套。
我们利用工具：Hierarchy Viewer进行检测，优化思想是：查看自己的布局，层次是否很深以及渲染比较耗时，然后想办法能否减少层级以及优化每一个View的渲染时间。
我们打开APP，然后打开Android Device Monitor，然后切换到Hierarchy Viewer面板。除了看层次结构之外，还可以看到一些耗时的信息：
三个圆点分别代表：测量、布局、绘制三个阶段的性能表现。
1）绿色：渲染的管道阶段，这个视图的渲染速度快于至少一半的其他的视图。
2）黄色：渲染速度比较慢的50%。
3）红色：渲染速度非常慢。
GPU优化建议就是一句话：尽量避免过度绘制（overdraw）
一、背景经常容易造成过度绘制。
手机开发者选项里面找到工具：Debug GPU overdraw，其中，不同颜色代表了绘制了几次：
6. Android UI线程
思考：
先必须了解下面2个问题
1.顾名思义 UI线程 就是刷新UI 所在线程
2.UI是单线程刷新
1.对Activity 来说 UI线程就是其主线程
2.对View来说 UI线程就是创建ViewRootImpl所在的线程
可以通过 WindowManager 内部会创建ViewRootImpl对象
好了，进入主题。我们来慢慢揭开面纱。
我们可以分别从几个方面切入
我们可能都有使用过 runOnUiThread 现在来看看的源码实现。
可以从上面的源码 看到
不是UI线程 就用Handler切到Handler所在的线程中，如果是UI线程直接就调用run方法。
Activity的创建：
1.Activity创建：mInstrumentation.newActivity
2.创建Context ：ContextImpl (r)
我们经常用这个方法干的事情就是，要么在onCreate中获取View宽高的值。要么就是在子线程中做一些耗时操作 ，然后post切到对应View所在的线程 来绘制UI操作。那么这个对应的线程就是UI线程了。
那么这个UI线程就一定是主线程吗？
接来继续来看。它的源码View:post
mAttachInfo 在dispatchAttachedToWindow 中被赋值 ，也就是在ViewRootImpl创建的时候，所以是创建ViewRootImpl所在的线程。
attachInfo 上面时候为null 呢？在ViewRootImpl 还没来得及创建的时候，ViewRootImpl 创建是在 “onResume" 之后。所以在 Activity 的 onCreate 去View.post 那么AttachInfo 是为null 。
当 AttachInfo == null 那么会调用 getRunQueue().post(action) 。
最终这个Runnable 被 缓存到 HandlerActionQueue 中。
直到ViewRootImpl 的 performTraversals 中 调用dispatchAttachedToWindow(mAttachInfo, 0);， 那么才会去处理 RunQueue() 中的Runnable。
来张图 便于理解这个流程
我们有时候去子线程操作UI的时候(如：requestLayout)，会很经常见到下面的 报错日志：
Only the original thread that created a view hierarchy can touch its views
为什么会报这个错误呢？
翻译一下：只有创建视图层次结构的原始线程才能接触到它的视图。
也就是操作UI的线程要和ViewRootImpl创建的线程是同一个线程才行，并不是只有主线程才能更新UI啊。
ViewRootImpl创建的线程？那么 ViewRootImpl 在哪里被创建的呢？
从上图可以看到ViewRootImpl创建最开始是从 ActivityThread 的HandleResumeActivity中开始 一直 ViewRootImpl 创建，也就是说ViewRootImpl 对应的UI线程和 ActivityThread 在同一个线程 也就是主线程。
好了 通过上面的讲解，上面的问题相信你可以自己回答啦~