当前位置：首页 > news >正文

90%的开发者都不知道的UI本质原理和优化方式

news 2026/8/27 12:02:45

前言

很多开发者在工作中一直和UI打交道，所以认为UI非常的简单！

事实上对于90%的开发者来说，不知道UI的本质原理。

虽然在开发中，我们在接到产品的UI需求之后，可以走捷径照抄大型APP代码，但是copy来的代码一旦出了问题，也只是百度或者靠猜的方案去解决。

真正高级的工程师也会使用别人的代码，但是他们深入理解了高级UI的原理及性能优化方法，就能避免卡顿的情况。

相信大家多多少少看过一些高级UI原理的文章，但是一到用的时候就不知道了，本文就给大家讲清楚！

从生命周期分析UI原理

Activity的attach 方法里创建PhoneWindow。
onCreate方法里的 setContentView 会调用PhoneWindow的setContentView方法，创建DecorView并且把xml布局解析然后添加到DecorView中。
在onResume方法执行后，会创建ViewRootImpl，它是最顶级的View，是DecorView的parent，创建之后会调用setView方法。
ViewRootImpl 的 setView方法，会将PhoneWindow添加到WMS中，通过 Session作为媒介。setView方法里面会调用requestLayout，发起绘制请求。
requestLayout 一旦发起，最终会调用 performTraversals 方法，里面将会调用View的三个measure、layout、draw方法，其中View的draw 方法需要一个传一个Canvas参数。
最后通过relayoutWindow 方法将Surface跟当前Window绑定，通过Surface的lockCanvas方法获取Surface的的Canvas，然后View的绘制就通过这个Canvas，最后通过Surface的unlockCanvasAndPost 方法提交绘制的数据，最终将绘制的数据交给SurfaceFlinger去提交给屏幕显示。

UI优化

UI优化主要包括布局优化以及view的绘制优化。先说下UI的优化到底是什么？

有些时候我们打开某个软件，会出现卡顿的情况。这就是UI的问题。那么我们想一下，什么情况会导致卡顿呢？一般是如下几种情况：

人为在UI线程中做轻微耗时操作，导致UI线程卡顿；
布局Layout过于复杂，无法在16ms内完成渲染；
同一时间动画执行的次数过多，导致CPU或GPU负载过重；
View过度绘制，导致某些像素在同一帧时间内被绘制多次，从而使CPU或GPU负载过重；
View频繁的触发measure、layout，导致measure、layout累计耗时过多及整个View频繁的重新渲染；
内存频繁触发GC过多（同一帧中频繁创建内存），导致暂时阻塞渲染操作；
冗余资源及逻辑等导致加载和执行缓慢；
臭名昭著的ANR；

可以看见，上面这些导致卡顿的原因都是我们平时开发中非常常见的。

有些人可能会觉得自己的应用用着还蛮OK的，其实那是因为你没进行一些瞬时测试和压力测试，一旦在这种环境下运行你的App你就会发现很多性能问题。

下面就分享给大家几种常见的UI 优化方式。

所谓UI优化，就是拆解渲染过程的耗时，找到瓶颈的地方，加以优化。

前面分析了UI原理，Activity、Window、DecorView、ViewRootImpl之间的关系，以及XML布局文件是如何解析成View对象的。

耗时的地方：

View的创建在主线程，包括measure、layout、draw，界面复杂的时候，这一部分可能会很耗时。
解析XML，反射创建VIew对象，这一过程的耗时。

下面介绍一些常用的UI优化方式~

3.1 常规方式

减少UI层级、使用merge、Viewstub标签优化
优化layout开销、RelativeLayout和带有weight的Linearlayout会测量多次,可以尝试使用ConstraintLayout 来代替。
背景优化，分析DecorView创建的时候，发现DecorView会设置一个默认背景，可以统一将DecorView背景设置为通用背景，其它父控件就无需设置背景，避免重复绘制。

3.2 xml转换成代码

使用xml编写布局，很方便，但是最终要通过LayoutInflater的inflate方法，将xml解析出来并递归+反射去创建View对象，布局比较复杂的时候，这一部分会非常耗时。

使用代码创建可以减少xml递归解析和反射创建View的这部分耗时。当然，如果将xml都换成代码来写，开发效率将不忍直视，并且代码可读性也是个问题。

掌阅开源的一个库，编译期自动将xml转换成java代码，X2C

它的原理是采用APT（Annotation Processor Tool）+ JavaPoet技术来完成编译期间【注解】-【解注解】->【翻译xml】->【生成java】整个流程的操作

即在编译生成APK期间，将需要翻译的layout翻译生成对应的java文件，这样对于开发人员来说写布局还是写原来的xml，但对于程序来说，运行时加载的是对应的java文件。

侵入性极低，去除注解则回退到原生的运行时解析方式。当然，有些情况是不支持转换的，比如merge标签，编译期没法确定它的parent。

3.3 异步创建View

通过子线程创建View，减少主线程耗时。

private void threadNewView() { new Thread(){ @Override public void run() { mSplashView = LayoutInflater.from(MainActivity.this).inflate(R.layout.activity_splash,null); } }.start(); }

当然，这种方式需要处理同步问题，并且没有从源头上解决创建View耗时，只是将这部分耗时放到线程去做。UI更新的操作还是要切换到主线程，不然会触发ViewRootImpl的checkThread检测。

void checkThread() { if (mThread != Thread.currentThread()) { throw new CalledFromWrongThreadException( "Only the original thread that created a view hierarchy can touch its views."); } }