Android性能优化系列篇UI优化

目录
  • 前言
  • 一、UI优化
    • 1.1 系统做的优化
      • 1.1.1 硬件加速
    • 1.2 优化方案
      • 1.2.1 java代码布局
      • 1.2.2 View重用
      • 1.2.3 异步创建view
      • 1.2.4 xml布局优化
      • 1.2.5 异步布局框架Litho
      • 1.2.6 屏幕适配
      • 1.2.7 Flutter
      • 1.2.8 Jetpack Compose
    • 1.3 工具篇
      • 1.3.1 Choreographer
      • 1.3.2 LayoutInspector/Android Device Monitor
      • 1.3.3 Systrace

前言

从网上汇总搜集众多大佬的性能优化文章,整理出来部分知识点,主要包含:

UI优化/启动优化/崩溃优化/卡顿优化/安全性优化/弱网优化/APP深度优化等等等~

本篇是第一篇:UI优化!  [非商业用途,如有侵权,请告知我,我会删除]

一、UI优化

UI优化知识点主要分为三部分:

  • 第一部分,系统为我们做的优化。由于前端中UI展示的特殊性和重要性,Android团队也是在不断想办法提高UI方面的渲染速度,所以也是更新了很多系统优化方案,比如:

硬件加速、黄油计划、RenderThread。

  • 第二部分,我们可以具体实施的优化方案。主要包括:

java代码布局、View重用、异步创建View、xml布局优化、异步布局框架Litho、屏幕适配、Flutter、Jetpack Compose

  • 第三部分,工具使用,主要包括:

Choreographer、monitor、Systrace

1.1 系统做的优化

1.1.1 硬件加速

之前我们说过,一个图形的绘制是CPU,GPU和屏幕三方合作的结果。

Android3.0之前,还没有硬件加速,都是通过CPU进行数据计算,然后通过Skia库进行软件绘制,但是CPU对于图形处理并不高效。

于是从3.0开始,Android支持了硬件加速,到Android4.0默认开启硬件加速。

开启硬件加速后,就是由CPU进行图形缓存数据的绘制。这样CPU和GPU就能比较好的分工,各司其职了。CPU用于控制复杂绘制逻辑、构建或更新DisplayList(基础元素);GPU用于完成图形计算、渲染DisplayList(基础元素)。

这里也找了一张各种场景下,硬件加速前后的流程与加速效果(Android6.0背景):

但是硬件加速也是有缺点的:

  • 启用硬件加速需要更多资源,因此应用会占用更多内存。
  • 比较低的版本,由于有些Canvas API还没有支持,所以使用硬件加速可能会有问题。那么我们就可以手动关闭某个view的硬件加速:
    myView.setLayerType(View.LAYER_TYPE_SOFTWARE, null)

Project Butter

黄油计划,你有可能没怎么听说,但是其实之前两章内容都提到过,Android4.1之后,Google提出了黄油计划,主要包括两个内容:

  • VSYNC
  • Triple Buffering(三重缓存)

这些都熟悉了吧,上两节都说过的,这里再简单提一下:

  • VSYNC

垂直同步信号,每当收到这个信号后,CPU就开始准备Buffer数据,并在16ms之内和GPU把屏幕需要的缓存数据准备好。

  • Triple Buffering(三重缓存)

Android4.1之前,是双缓存机制,大部分是没问题的。但是当CPU/GPU绘制过程较长,超过一个vsync信号周期,一般是16ms,就会导致丢帧,CPU无法使用被GPU或者屏幕占用的缓存区。如果下一帧绘制如果又超时,那么又会丢帧。

所以再加上一个缓存区,这样,CPU、GPU、Display三者都有各自的缓存区,互不影响,就能保证时间的最大化利用,也就能减少上述的情况了。

RenderThread

RenderThread是在Android5.0提出的,从这个名字就能知道,它是一个线程,一个专门执行GL命令的线程,也就是一部分的绘制工作。

有了它之后,当CPU处理数据给GPU后,就不需要等GPU渲染完毕了,而是将一些绘制任务交给RenderThread,这样就能减少主线程的工作,保证画面的流畅。同时还提供了RenderNode,用来做view的属性封装,渲染帧的信息等等。

1.2 优化方案

1.2.1 java代码布局

我们一般都是用XML文件进行布局,但是XML解析也是很耗时的,并在这个解析过程在主线程进行。

所以我们有的时候也许可以通过Java代码或者kotlin进行View的创建?

理论中,这样确实能减少布局加载的消耗时间,但是Java代码创建View太麻烦了,而且无法可视化。

当然,也有一些库可以帮助我们将xml代码转换成java代码,比如X2C(github.com/iReaderAndr… ),但是它并不支持所有的情况,比如merge标签,appCompat兼容控件等等。

所以我们需要在这之中找到平衡点,有的时候,UI简单并且要求高性能的前提下,我们可以试试用这样的方法,即用java代码代替XmL代码。

1.2.2 View重用

参照Recyclerview的做法,我们也可以将一些常用的view保存到缓存池中,这样在不同的界面中就能复用缓存池里面的view。

1.2.3 异步创建view

这是Google提出的一个方案——AsyncLayoutInflater。它可以异步加载布局文件,并且回调给主线程,从而减少主线程耗时。简单贴下主要代码:

new AsyncLayoutInflater(MainActivity.this).inflate(R.layout.activity_main, null, new AsyncLayoutInflater.OnInflateFinishedListener() {
        @Override
        public void onInflateFinished(@NonNull View view, int i, @Nullable ViewGroup viewGroup) {
        //回调给主线程
            setContentView(view);
    }
});

1.2.4 xml布局优化

在写xml布局文件的时候,我们要做的也有很多,比如:

  • 减少布局嵌套。多使用ViewStub、Merge、ConstraintLayout来代替。
  • 优化开销。RelativeLayout和 使用weight的LinearLayout 开销比较大,建议使用ConstraintLayout,LinearLayout代替。

1.2.5 异步布局框架Litho

Litho是Facebook开源的一款在Android上高效建立UI的声明式框架。

主要有以下特点:

1)声明式:它使用了声明式的API来定义UI组件。

2)异步布局:它把 measurelayout 都放到了后台线程,只留下了必须要在主线程完成的 draw,这大大降低了 UI 线程的负载

3)视图扁平化:由于 Litho 使用了自有的布局引擎(Yoga),在布局阶段就可以检测不必要的层级、减少 ViewGroups,来实现 UI 扁平化。

4)优化 RecyclerView:Litho 还优化了 RecyclerView 中 UI 组件的缓存和回收方法。

1.2.6 屏幕适配

关于屏幕适配问题,也是老生常谈了。主要有以下几种方案:

  • dp适配方案。

这是系统自带的适配单位,dp是基于屏幕物理分辨率一个抽象的单位,用于说明与密度无关的尺寸和位置。所以它能在不同分辨率的手机上有相对大小的适配性。计算公式是:px=dp * (dpi/160)。但是dpi有可能会被人为调整(比如几部相同分辨率不同尺寸的手机的ppi可能分别是是430,440,450,那么在Android系统中,可能dpi会全部指定为480),所以还是有可能在一些设备上出现适配问题。

  • 宽高限定符适配方案。

简单地说,这个方案就是穷举市面上所有的Android手机的宽高像素值。然后找到对应的文件夹使用下面的资源文件所对应的px值。

但是这方案有个缺陷,就是必须精确命中才行。比如1920x1080的手机就一定要找到1920x1080的限定符,否则就只能用统一的默认的dimens文件了。

所以容错性太低,不推荐。

  • smallestWidth适配方案。

这个方案就是通过手机的宽度值来找到对应限定符文件夹下的资源文件,可以看做宽高限定符屏幕适配方案的升级版。

假如我们的设计图宽为360dp,那么就创建values-sw360dp文件夹,并添加资源文件:

<?xml version="1.0" encoding="UTF-8"?>
<resources>
    <dimen name="dp_1">1dp</dimen>
    <dimen name="dp_2">2dp</dimen>
    <dimen name="dp_3">3dp</dimen>
    ...
    <dimen name="dp_359">359dp</dimen>
    <dimen name="dp_360">360dp</dimen>
</resources>

很简单,分为360份,然后我们实际写布局文件的时候,直接引用对应的dimen值即可。

然后新建其他设备宽度的文件夹,并在每个文件夹里添加对应的资源文件,这里以400dp为例:

├── src/main
│   ├── res
│   ├── ├──values
│   ├── ├──values-sw320dp
│   ├── ├──values-sw400dp
│   ├── ├──...
│   ├── ├──values-sw640dp
<?xml version="1.0" encoding="UTF-8"?>
<resources>
    <dimen name="dp_1">1.1111dp</dimen>
    <dimen name="dp_2">2.2222dp</dimen>
    <dimen name="dp_3">3.3333dp</dimen>
    <dimen name="dp_4">4.4444dp</dimen>
    ...
    <dimen name="dp_359">398.8889dp</dimen>
    <dimen name="dp_360">400.0000dp</dimen>
</resources>

也就是说,所有的设备都分为360份了,这样就能保证在不同宽度设备上都能有差不多的效果。

如果我们的设备宽度为400dp,那么就会调用values-sw400dp对应的资源文件,如果找不到,就会向下查找。比如我们宽度是402dp,找不到对应的,就会向上找到400dp对应的资源文件,所以也有比较好的容错性。也是一个比较好的适配方案。

当然这种重复性工作肯定不需要我们自己手动去实现,有专门的插件可以生成相应的文件和文件夹,这里也推荐一个:github.com/ladingwu/di…

  • 今日头条适配方案。

这个大家应该都很熟悉了,主要是通过动态修改density值来保证所有设备的屏幕宽度都是固定的dp值。用到的公式就是px = density * dp

比如设计图宽为360dp,我们只要保证所有设备的宽度都是360dp就能适配了。而宽度的px值我们是已知的,所以就是要修改这个 density 值来完成我们的适配目的。具体代码我就不贴了,网上很多。

这种方案侵入性低,使用方便,是个不错的适配方案。

1.2.7 Flutter

Flutter是 Google 推出并开源的移动应用开发框架,开发者可以通过 Dart 语言开发 App,一套代码同时运行在 iOS 和 Android 平台。

Flutter框架现在也是特别火,实际运用到很多的大厂项目,比如闲鱼今日头条。它相对于Android其实是另外一套APP架构了,它没有基于系统本身的渲染引擎,而是app中自带Skia引擎,虚拟机也是使用的Dart虚拟机。

主要有以下几个特点:

  • 跨平台:现在flutter至少可以跨5种平台,常见的平台:MacOS,Windows ,Linux ,Android ,iOS ,到目前为止,Flutter算是支持平台最多的框架了。良好的跨平台性,大大减少了开发成本。
  • 丝滑般的体验:使用Flutter内置的Material Design(android风格)和Cupertino(ios风格)风格组件,以及丰富的motion API,平滑而自然的滑动效果和平台感知,为用户带来全新的体验。
  • 响应式框架:使用一系列基础组件和响应式框架,可以轻松构建用户界面。使用功能强大且灵活的API可以实现复杂的界面效果。
  • 支持插件:使用插件可以访问平台本地API,如相机,蓝牙,WIFI等等。借助现有的Java,swift ,object c , c++代码实现对原生系统的调用。
  • 60fps超高性能:Flutter编写的应用可以达到60fps(每秒传输帧数)。Flutter采用GPU渲染技术,所以性能很好。完全可以胜任游戏开发。

1.2.8 Jetpack Compose

Jetpack Compose 是用于构建原生 Android 界面的新工具包

原来我们的布局文件都是写在xml文件中的,现在提供了一种新的view构建方式,也就是Compose

它是一种声明式UI,不再使用xml,而是使用kotlin进行UI布局。其实就跟我们之前提到的一点,用java代码去构建view一样的效果。这样就减少了xml解析的时间,提高了效率。

声明式UI。指的是只需要把界面声明出来,不需要手动更新。比如我们这里的Compose只需要写一遍,后续的UI改变会随着变量自动更新。而传统的xml布局方式就无法做到这一点,属于命令式UI,需要我们手动命令纸牌屋UI的修改。

官方也是宣称有以下几点优势:

更少更直观的代码,更强大的功能,能提高开发速度。

最后贴一段代码,感受下Compose的写法:

class MainActivity : AppCompatActivity() {
  override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContent {
      Greeting("Android")
    }
  }
}
​
@Composable
fun Greeting(name: String) {
    Text (text = "Hello $name!")
}

复制

1.3 工具篇

1.3.1 Choreographer

Choreographer其实也是一个监控应用帧率的工具。它主要有以下特性:

  • 能获取整体的帧率。
  • 能在线上使用。
  • 获取的帧率几乎是实时的。

主要原理就是利用postFrameCallback计算两次绘制的间隔时间,简单贴下代码:

private long mLastFrameTime;
Choreographer.getInstance().postFrameCallback(new Choreographer.FrameCallback() {
    @Override
    public void doFrame(long frameTimeNanos) {
        if (mLastFrameTime == 0) {
            mLastFrameTime = frameTimeNanos;
        }
        float diff = (frameTimeNanos - mLastFrameTime) / 1000000.0f;//得到毫秒,正常是 16.66 ms
        if (diff > 500) {
            double fps = (((double) (mFrameCount * 1000L)) / diff);
            mFrameCount = 0;
            mLastFrameTime = 0;
            Log.d("doFrame", "doFrame: " + fps);
        } else {
            ++mFrameCount;
        }
        Choreographer.getInstance().postFrameCallback(this);
    }
});

想细细研究的可以看看这个库(github.com/friendlyrob…

1.3.2 LayoutInspector/Android Device Monitor

LayoutInspectorAndroidStudio种的一个布局检查器,可以通过Tools > Layout Inspector找到,他可以检查应用中的某个界面的视图结构,但是无法查看非调式状态的应用。

如果要看其他应用的布局情况,可以使用Android Device Monitor,在Android Studio 3.1 以后,需要单独从文件夹打开了:

android-sdk/tools/monitor

1.3.3 Systrace

Systrace是分析Android性能问题的神器,获取Systrace文件的方式有两种:

  • 一是AndroidSDK/tools目录下,通过monitor.batAndroid Device Monitor可视化工具得到。
  • 二是通过python脚本获取。

以上就是Android性能优化系列篇UI优化的详细内容,更多关于Android性能UI优化的资料请关注我们其它相关文章!

(0)

相关推荐

  • Android 性能优化实现全量编译提速的黑科技

    目录 一.背景描述 二.效果展示 2.1.测试项目介绍 三.思路问题分析与模块搭建: 3.1.思路问题分析 3.2.模块搭建 四.问题解决与实 编译流程启动,需要找到哪一个 module做了修改 module 依赖关系获取 module 依赖关系 project 替换成 aar 技术方案 hook 编译流程 五.一天一个小惊喜( bug 较多) 5.1 output 没有打包出 aar 5.2 发现运行起来后存在多个 jar 包重复问题 5.3 发现 aar/jar 存在多种依赖方式 5.4 发

  • Android性能优化之线程监控与线程统一详解

    目录 背景 常规解决方案 线程监控 当前线程统计 线程信息具体化 线程统一 Thread创建 注意 总结 背景 在我们日常开发中,多线程管理一直是非常头疼的问题之一,尤其在历史性长,结构复杂的app中,线程数会达到好几百个甚至更多,然而过多的线程不仅仅带来了内存上的消耗同时也降低了cpu调度的效率,过多的cpu调度带来的消耗的坏处甚至超过了多线程带来的好处. 在我们日常开发中,通常会遇到以下几个问题 某个场景会创造过多的线程,最终导致oom 线程池过多问题,比如三方库有一套线程池,自己项目也有一

  • Android性能优化之RecyclerView分页加载组件功能详解

    目录 引言 1 分页加载组件 1.1 功能定制 1.2 手写分页列表 1.3 生命周期管理 2 github 引言 在Android应用中,列表有着举足轻重的地位,几乎所有的应用都有列表的身影,但是对于列表的交互体验一直是一个大问题.在性能比较好的设备上,列表滑动几乎看不出任何卡顿,但是放在低端机上,卡顿会比较明显,而且列表中经常会伴随图片的加载,卡顿会更加严重,因此本章从手写分页加载组件入手,并对列表卡顿做出对应的优化 1 分页加载组件 为什么要分页加载,通常列表数据存储在服务端会超过100条

  • Android性能优化之JVMTI与内存分配

    目录 前言 JVMTI JVMTI 简介: native层开启jvmti 前置准备 复写Agent 开启jvmtiCapabilities 设置jvmtiEventCallbacks 开启监听 java层开启agent 验证分配数据 总结 前言 内存治理一直是每个开发者最关心的问题,我们在日常开发中会遇到各种各样的内存问题,比如OOM,内存泄露,内存抖动等等,这些问题都有以下共性: 难发现,内存问题一般很难发现,业务开发中关系系数更少 治理困难,内存问题治理困难,比如oom,往往堆栈只是压死骆驼

  • Android性能优化之弱网优化详解

    目录 弱网优化 1.Serializable原理 1.1 分析过程 1.2 Serializable接口 1.3 ObjectOutputStream 1.4 序列化后二进制文件的一点解读 1.5 常见的集合类的序列化问题 1.5.1 HashMap 1.5.2 ArrayList 2.Parcelable 2.1 Parcel的简介 2.2 Parcelable的三大过程介绍(序列化.反序列化.描述) 2.2.1 描述 2.2.2 序列化 2.2.3 反序列化 2.3 Parcelable的实

  • Android性能优化之捕获java crash示例解析

    目录 背景 java层crash由来 为什么java层异常会导致crash 捕获crash 总结 背景 crash一直是影响app稳定性的大头,同时在随着项目逐渐迭代,复杂性越来越提高的同时,由于主观或者客观的的原因,都会造成意想不到的crash出现.同样的,在android的历史化过程中,就算是android系统本身,在迭代中也会存在着隐含的crash.我们常说的crash包括java层(虚拟机层)crash与native层crash,本期我们着重讲一下java层的crash. java层cr

  • Android性能优化之plt hook与native线程监控详解

    目录 背景 native 线程创建 PLT PLT Hook xhook bhook plt hook总结 背景 我们在android超级优化-线程监控与线程统一可以知道,我们能够通过asm插桩的方式,进行了线程的监控与线程的统一,通过一系列的黑科技,我们能够将项目中的线程控制在一个非常可观的水平,但是这个只局限在java层线程的控制,如果我们项目中存在着native库,或者存在着很多其他so库,那么native层的线程我们就没办法通过ASM或者其他字节码手段去监控了,但是并不是就没有办法,还有

  • Android性能优化死锁监控知识点详解

    目录 前言 死锁检测 线程Block状态 获取当前线程所请求的锁 通过锁获取当前持有的线程 线程启动 nativePeer 与 native Thread tid 与java Thread tid dlsym与调用 系统限制 死锁检测所有代码 总结 前言 “死锁”,这个从接触程序开发的时候就会经常听到的词,它其实也可以被称为一种“艺术”,即互斥资源访问循环的艺术,在Android中,如果主线程产生死锁,那么通常会以ANR结束app的生命周期,如果是两个子线程的死锁,那么就会白白浪费cpu的调度资

  • Android性能优化系列篇UI优化

    目录 前言 一.UI优化 1.1 系统做的优化 1.1.1 硬件加速 1.2 优化方案 1.2.1 java代码布局 1.2.2 View重用 1.2.3 异步创建view 1.2.4 xml布局优化 1.2.5 异步布局框架Litho 1.2.6 屏幕适配 1.2.7 Flutter 1.2.8 Jetpack Compose 1.3 工具篇 1.3.1 Choreographer 1.3.2 LayoutInspector/Android Device Monitor 1.3.3 Systr

  • Asp.Net 网站优化系列之数据库优化措施 使用主从库(全)

    网站规模到了一定程度之后,该分的也分了,该优化的也做了优化,但是还是不能满足业务上对性能的要求:这时候我们可以考虑使用主从库. 主从库是两台服务器上的两个数据库,主库以最快的速度做增删改操作+最新数据的查询操作:从库负责查询较旧数据,做一些对实效性要求较小的分析,报表生成的工作.这样做将数据库的压力分担到两台服务器上从而保证整个系统响应的及时性. SQL Server提供了复制机制来帮我们实现主从库的机制.我们看下如何在sql server 2005中实践: 实践前需要新创建一个Test的数据库

  • Asp.Net 网站优化系列之数据库优化分字诀上 分库

    如果你有先见之明的话,会给表名,存储过程的名字加上前缀,例如论坛表命名为BBS_xxx,博客表命名为BLOG_xxx:这样的话在分表处理时会比较容易一些.说到这儿也许你会想到外键约束怎么办,我的博客表,论坛帖子表都有用了User表的主键做外键呀.这个很容易处理,我们需要当机立断的删掉外键,这个当机立断可能会带来一些麻烦,我们来分析下可能会遇到一些什么问题: 1. 分成多个库,没了外键了以前的inner join操作要跨库吗? 假定场景:博客表有对用户表的外键引用,我们需要在首页显示博客列表,博客

  • Asp.Net 网站优化系列之数据库优化 分字诀 分表(纵向拆分,横向分区)

    1. 纵向分表 纵向分表是指将一个有20列的表根据列拆分成两个表一个表10列一个表11列,这样单个表的容量就会减少很多,可以提高查询的性能,并在一定程度上减少锁行,锁表带来的性能损耗. 纵向分表的原则是什么呢,应该怎样拆分呢?答案是根据业务逻辑的需要来拆分,对于一张表如果业务上分两次访问某一张表其中一部分数据,那么就可以根据每次访问列的不同来做拆分; 另外还可以根据列更新的频率来拆分,例如某些列每天要更新3次,有些列从创建开始基本上很少更新. 举例: 假定场景,我有一张用户表,这张表包含列: I

  • Android 性能优化系列之bitmap图片优化

    背景 Android开发中,加载图片过多.过大很容易引起OutOfMemoryError异常,即我们常见的内存溢出.因为Android对单个应用施加内存限制,默认分配的内存只有几M(具体视不同系统而定).而载入的图片如果是JPG之类的压缩格式(JPG支持最高级别的压缩,不过该压缩是有损的),在内存中展开会占用大量的内存空间,也就容易形成内存溢出.那么高效的加载Bitmap是很重要的事情.Bitmap在Android中指的是一张图片,图片的格式有.jpg .jpg .webp 等常见的格式. 如何

  • Android性能优化之ANR问题定位分析

    目录 前言 1 ANR原因总结 1.1 KeyDispatchTimeout 1.2 BroadCastTimeout 1.3 ServiceTimeout 1.4 ContentProviderTimeout 2 ANR问题解决 2.1 线下问题解决 2.2 线上问题解决 2.2.1 Bugly 2.2.2 FileObserver 2.2.3 WatchDog 前言 ANR(Application Not Response)应用程序未响应,当主线程被阻塞时,就会弹出如下弹窗 要么关闭当前ap

  • PHP性能优化工具篇Benchmark类调试执行时间

    这是PHP性能优化系列第二期,如何使用PEAR工具类Benchmark逐行获取代码或函数的执行时间. 工欲善其事,必先利其器! 如何安装PEAR和Benchmark 请参考PHP性能优化系列第一期 [PHP性能优化准备篇图解PEAR安装] Benchmark工具类包说明 直接下载:http://pear.php.net/package/Benchmark/downloadBenchmark工具类包共有三个文件,分别是Timer.php.Iterate.php和Profiler.php,三个工具类

  • Android性能优化以及数据优化方法

    Android性能优化-布局优化 今天,继续Android性能优化 一 编码细节优化. 编码细节,对于程序的运行效率也是有很多的影响的.今天这篇主题由于技术能力有限,所以也不敢在深层去和大家分享.我将这篇主题分为以下几个小节: (1)缓存 (2)数据 (3)延迟加载和优先加载 1> 缓存 在Android中缓存可以用在很多的地方:对象.IO.网络.DB等等..对象缓存能减少内存分配,IO缓存能对磁盘的读写访问,网络缓存能减少对网络的访问,DB缓存能减少对数据库的操作. 缓存针对的场景在Andro

随机推荐