第十章目录

10.1 布局优化

10.1.1 Android UI渲染机制

10.1.2 避免Overdraw

10.1.3 优化布局层级

10.1.4 避免嵌套过多无用布局

10.1.5 Hierarchy Viewer

10.2 内存优化

10.2.1 什么是内存

10.2.2 获取Android系统内存信息

10.2.3 内存回收

10.2.4 内存优化实例

10.3 Lint工具

10.4 使用Android Studio的Memory Monitor工具

10.5 使用TraceView工具优化App性能

10.5.1 生成TraceView日志的两种方法

10.5.2 打开TraceView日志

10.5.3 分析TraceView日志

10.6 使用MAT工具分析App内存状态

10.6.1 生成HPROF文件

10.6.2 分析HPROF文件

10.7 使用Dumpsys命令分析系统状态

第十章读书笔记

布局优化

内存优化

使用各种工具来进行分析、优化

10.1 布局优化

10.1.1 Android UI 渲染机制

玩过射击游戏的兄弟都知道，FPS保持在60以后才算比较流畅，有的好电脑好显卡在100多甚至200多

Android中通过VSYNC信号触发对UI的渲染，间隔时间是16ms，1秒钟显示60帧画面的时间，也就是1000/60

如果系统每次渲染的时间都在16ms以内，那么是很流畅的

16ms内无法完成绘制，即使耗时20ms，那么也会在下一个16ms后再绘制

那么本来16ms的时候我要显示了，结果变成了在32ms的时候才显示，延迟了一倍，32ms显示值显示了一帧

真的不要小看几ms的时间，直接导致严重的卡顿，玩穿越火线60的fps和30的fps，完全是两种体验

检测UI渲染的工具，那就是开发者选项中的监控一栏下的“GPU”呈现模式分析，选择在屏幕上显示条形图

蓝色：测量绘制Display List的时间

红色：OpenGl渲染Display List的时间

黄色：CPU等待GPU处理的时间

绿色的横线：YSYNC时间16ms，尽量保证所有的条形图都控制在这条绿线之下

10.1.2 避免Overdraw

定义：屏幕上某一像素点被重复绘制多次，就是过度绘制

过度绘制会浪费很多的CPU、GPU资源，常见的就是我们在多个布局中重复设置背景色，这个是很重要的

不要对背景设置alpha值，会导致两次draw，所以在需要时再去设置

开发者选项中硬件加速渲染一栏下的“调试GPU过度绘制”，显示过度绘制区域

常见的原因：太多叠加的背景，太多叠加的View，复杂的Layout层级

手机过度绘制再结合JakeWharton大神的Scalple的开源插件，过度绘制这一块，没什么问题了

github链接：https://github.com/JakeWharton/scalpel

使用步骤：

1、在gradle中加入如下代码：
compile 'com.jakewharton.scalpel:scalpel:1.1.2'
2、使用的时候你的根节点必须是ScalpelFrameLayout
View mainView = getLayoutInflater().inflate(R.layout.activity_main, null);
ScalpelFrameLayout mScalpelFrameLayout = new ScalpelFrameLayout(this);
mScalpelFrameLayout.addView(mainView);
mScalpelFrameLayout.setLayerInteractionEnabled(true); //开启 3D 效果
//mScalpelFrameLayout.setDrawIds(true); //是否显示控件 id
//mScalpelFrameLayout.setDrawViews(false); //是否展示控件内容，默认为 true
//mScalpelFrameLayout.setChromeColor(Color.RED); //修改边框颜色
//mScalpelFrameLayout.setChromeShadowColor(Color.YELLOW); //修改阴影颜色
setContentView(mScalpelFrameLayout);
10.1.3 优化布局层级

Android中，系统对View进行测量、布局和绘制时，都是通过对View数的遍历来进行操作的

如果View树太高，就会严重影响测量、布局和绘制的速度，因此适当减少View树的高度，Google建议View树高度不宜超过10层

现在版本的Android，Google已经使用RelativeLayout来替代LinearLayout作为默认的根布局，，其原因就是降低LinearLayout嵌套所产生布局树高度

那么现在的版本其实是用约束布局来作为默认的布局

10.1.4 避免嵌套过多无用布局

10.1.4.1 使用<include>标签重用Layout

使用<include>标签重用Layout

比如这个名叫common_ui的xml文件，宽高设为0dp，迫使开发则在使用时对宽高进行赋值：
<?xml version="1.0" encoding="utf-8"?>
<TextView 
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="0dp"
    android:layout_height="0dp"
    android:text="this is a common ui"
    android:textSize="30sp">
</TextView>
在主布局中引用，include里面的属性会覆盖common_ui里的属性：
<RelativeLayout 
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <include
        layout="@layout/common_ui"
        android:layout_width="match_parent"
        android:layout_height="wrap_content" />
</RelativeLayout>
10.1.4.2 使用<ViewStub>实现View的延迟加载

命名一个not_often_use的xml文件
<RelativeLayout 
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <TextView
        android:id="@+id/tv"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="not often use"
        android:textSize="30sp" />
</RelativeLayout>
在主布局中引用：
<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout 
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <ViewStub
        android:id="@+id/not_often_use"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:layout="@layout/not_often_use" />
</RelativeLayout>
这个时候在布局中看不到这个ViewStub布局的，有两种方法可以显示这个View
ViewStub mViewStub = (ViewStub) findViewById(R.id.not_often_use);
mViewStub.setVisibility(View.VISIBLE);
// 或者
ViewStub mViewStub = (ViewStub) findViewById(R.id.not_often_use);
View inflateView = mViewStub.inflate();
// 区别：
// inflate可以返回引用布局
<ViewStub>和View.GONE的区别：

都在初始化时不显示

<ViewStub>会在需要时才去渲染，效率更高些

View.GONE是在初始化布局的时候就已经加载了，只不过不可见

10.1.5 Hierarchy Viewer

通常情况下，Hierarchy Viewer无法在真机上使用，只能在模拟器上使用

Google大神提供了一个开源软件View Server，让普通手机也能使用Hierarchy Viewer，项目地址：http://github.com/romainguy/ViewServer

Hierarchy Viewer位于sdk\tools目录下，打开hierarchyviewer.bat启动程序

关于Hierarchy Viewer的使用可查看下面的博客：Hierarchy Viewer

布局优化的一些小总结

借这个机会说一下LinearLayout和RelativeLayout的性能对比

有的人说LinearLayout性能好，有的人说RelativeLayout性能好，真是到底哪个好

一个View要绘制到屏幕上，会经历onMeasure、onLayout、onDraw三个阶段，探讨性能问题，那么我们比较一下这三个方法执行时间的长短：
LinearLayout
    Measure：0.738ms
    Layout：0.176ms
    draw：7.655ms
RelativeLayout
    Measure：2.280ms
    Layout：0.153ms
    draw：7.696ms
onMeasure方法的执行时间，LinearLayout比RelativeLayout短很多

因为RelativeLayout是基于相对位置的，B依赖A，C依赖B，所以会对子View做两次measure，横向一次，纵向一次

因为LinearLayout是进行横向或者纵向的一次，所以只会measure一次，但如果设置了weight，LinearLayout会避开设置过weight的view再measure一次，所以也会measure两次

还有一个问题，view的measure存在以下优化：
public final void measure(int widthMeasureSpec, int heightMeasureSpec) {  
        if ((mPrivateFlags & FORCE_LAYOUT) == FORCE_LAYOUT ||  
                widthMeasureSpec != mOldWidthMeasureSpec ||  
                heightMeasureSpec != mOldHeightMeasureSpec) {  
        ...  
        mOldWidthMeasureSpec = widthMeasureSpec;  
        mOldHeightMeasureSpec = heightMeasureSpec;  
}  
如果我们或者我们的子View没有要求强制刷新，而父View给子View传入的值也没有变化（也就是说子View的位置没变化），就不会做无谓的测量。RelativeLayout在onMeasure中做横向测量时，纵向的测量结果尚未完成，只好暂时使用myHeight传入子View系统。这样会导致在子View的高度和RelativeLayout的高度不相同时（设置了Margin），上述优化会失效，在View系统足够复杂时，效率问题就会很明显。LinearLayout在这方面不需要考虑，所以，在使用RelativeLayout时，尽量使用padding来代替margin，

总体来说：

LinearLayout对子View进行一次measure，Relative对子View进行两次measure，LinearLayout的性能肯定要优于RelativeLayout，

使用LinearLayout尽量减少使用weight属性

如果同样的布局需求，用LinearLayout需要两层，但是RelativeLayout可能只需要一层，那么RelativeLayout肯定就优于LinearLayout了

使用RelativeLayout时，尽量用padding代替margin，在measure时会有一个优化，如果在刷新界面时，没有变化就不measure，但是

再举个例子，说一下渲染和过度绘制，一个这样的布局，嵌套了5个RelativeLayout：
<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context="com.example.administrator.eventbustest.MainActivity">
    <RelativeLayout
        android:layout_width="match_parent"
        android:layout_height="match_parent">
        <RelativeLayout
            android:layout_width="match_parent"
            android:layout_height="match_parent">
            <RelativeLayout
                android:layout_width="match_parent"
                android:layout_height="match_parent">
                <RelativeLayout
                    android:layout_width="match_parent"
                    android:layout_height="match_parent">
                    <TextView
                        android:id="@+id/text_view"
                        android:layout_width="wrap_content"
                        android:layout_height="wrap_content"
                        android:layout_centerInParent="true"
                        android:textSize="40sp"
                        android:text="主界面" />
                    <Button
                        android:id="@+id/button"
                        android:layout_width="wrap_content"
                        android:layout_height="wrap_content"
                        android:layout_alignParentTop="true"
                        android:layout_alignParentRight="true"
                        android:text="跳转到下一个Activity"/>
                </RelativeLayout>
            </RelativeLayout>
        </RelativeLayout>
    </RelativeLayout>
</RelativeLayout>
过度渲染情况：可以看出尽管有5层嵌套，但是并没有背景图片或是背景色

一个像素点只被绘制了一次，所以并没有过度绘制

渲染时间：可以看出来只启动这么一个简单的界面，渲染却用了可能是4*0.16还多的时间，嵌套导致渲染很费时

下面我们给每一个RelativeLayout都加一个背景色

过度渲染情况：可以说是严重的过度绘制了，4x+，每一个像素点绘制了5次

渲染时间：可以说时间已经超了太多，快爆了，直观感觉可能有1.5秒左右才打开此界面

使用JakeWharton大神的插件scalple来看一下，套了多少层：

通过这几个简单的开发技巧，可以优化不少布局的问题

10.2 内存优化

10.2.1 什么是内存

由于Android的沙箱机制，每个应用所分配的内存大小是有限度的，内存太低就会触发LMK：Low Memory Killer机制，我们所说的内存是指手机的RAM，它包括以下几个部分：

寄存器(Registers)
速度最快的存储场所，因为寄存器位于处理器内部，在程序中无法控制

栈（Stack）
存放基本类型的数据和对象的引用，但对像本身不存放在栈中，而是存放在堆中

堆（Heap）
堆内存用来存放由new创建的对象和数组，在堆中分配的内存，由Java虚拟机的自动垃圾回收（GC）来管理

静态存储区域(Static Field)
静态存储区域就是指在固定的位置存放应用程序运行时一直存在的数据，Java在内存中专门划分了一个静态存储区域来管理一些特殊的数据变量如静态的数据变量

常量池(Constant Pool)
JVM虚拟机必须为每个被装载的类型维护一个常量池，常量池就是该类型所用到常量的一个有序集合，包括直接常量(基本类型，String)和对其他类型、字段和方法的符号引用

这些概念中最容易搞错的是堆和栈的区分：

栈：当定义一个变量时，栈会为该变量分配内存空间，当该变量作用域结束后，这部分内存控件会被用作新的空间进行分配

堆：使用new的方式创建一个变量，那么就会在堆中为这个对象分配内存控件，即使该对象的作用域结束，这部分内存也不会立即被回收，而是等待系统的GC进行回收

我们可以通过代码分析Heap中的内存状态：
ActivityManager manager = (ActivityManager)getSystemService(Context.ACTIVITY_SERVICE);
int heapSize = manager.getLargeMemoryClass();
10.2.2 获取Android系统内存信息

10.2.2.1 Process Stats

Process Stats：

系统内存监视服务，通过”Setting-Developer-options-Process Stats”来开启这个功能

也可以使用Dumpsys命令来获取这些信息：adb shell dumpsys procstats

这个应该也是开发者选项中的

10.2.2.2 Meminfo

Meminfo：

内存监视工具，通过”Settings-Apps-Running”中打开这个界面

也可以使用Dumpsys命令来获取这些信息：adb shell dumpsys meminfo

手机设置中的开发者选项中正在运行的服务

10.2.3 内存回收

Java对于C、C++这类语言最大的优势就是不用手动管理系统资源，Java创建了垃圾收集器线程来自动进行资源的管理

Java的GC是系统自动进行的，但何时进行却是开发者无法控制的，即使调用System.gc()方法，也只是建议系统进行GC，系统不一定会采取你的建议

尽管再强大的算法，也难免存在部分对象忘记回收的想象，这就是造成内存泄露的原因

10.2.4 内存优化实例

10.2.4.1 Bitmap优化

Bitmap优化：Bitmap是造成内存占用过高或OOM的最大威胁

使用适当分辨率和大小的图片，开发中要根据对应的情况使用缩略图或原图

及时回收内存，使用完bitmap后要及时recycler()释放，不过Android4.0后被放置在堆中，不需要释放了

使用图片缓存，通过内存缓存和硬盘缓存可以更好的使用Bitmap

10.2.4.2 代码优化

代码优化：任何Java类占用大约500字节的内存空间，创建一个类的实例会消耗大概15字节的内存

对常量使用static修饰符

使用静态方法，静态方法会比普通方法提高15%左右的访问速度

减少不必要的成员变量 ,这点在Android Lint工具上已经集成检测了，如果一个变量可以定义为局部变量，则会建议你不要定义为成员变量

减少不必要的对象，使用基础类型会比使用对象更加节省资源, 同时更应该避免频繁创建短作用域的变量

尽量不要使枚举、少使用迭代器

对Cursor、Receiver、Sensor、Fiie等对象，要非常注意对它们的创建，回收与注册、解注册

避免使用IOC框架，IOC通常使用注解、反射来进行实现，虽然现在Java对反射的效率已经进行了很好的优化，但大量使用反射依然会带来性能的下降

使用RenderScript、OpenGL来进行非常复杂的绘图操作

使用SurfaceView来替代View进行大量、频繁的绘图操作

尽量使用视图缓存，而不是每次都执行inflaler()方法解析视图

10.3 Lint工具

Android Lint工具是Android Studio中集成的一个Android代码提示工具，可以给你的布局、代码提供非常强大的帮助。

工具栏->Analyze->Inspect Code，选择后可以选择对应的范围，可以全部文件，也可以选择当前的类

选全部文件呢，可以删除无用的代码

选当前类，你可以看到你编写完的代码的一些问题，真的很好用

10.4 使用Android Studio的Memory Monitor工具

Memory Monitor工具是Android Studio自带的一个内存监视工具，通过Android Studio右下角”Memory Monitor”打开”Memory Monitor”工具

Android Studio3.0之后改为Android Profiler,比较全面

10.5 使用TraceView工具优化App性能

TraceView也是Android SDK内置的一个工具

10.5.1 生成TraceView日志的两种方法

利用Debug类帮助我们生成日志文件

利用Android Device Monitor 工具辅助生成日志文件

10.5.1.1 通过代码生成精确范围的TraceView日志

10.5.1.2 通过Android Device Monitor生成TraceView日志

还有一个就是通过Android profiler来生成

这里不提了，网上一搜一大推使用的方法

10.5.2 打开TraceView日志

可以使用SDK中的”sdk\tools\traceview.bat”工具打开

可以在Android Device Monitor工具下，的File菜单选择Open File打开

10.5.3 分析TraceView日志

10.5.3.1 时间轴区域

时间轴区域：显示了不同线程在不同时间段内的执行情况

在时间轴中，每一行都代表了一个独立的线程

使用鼠标滚轮可以放大时间轴

不同色块代表不同的执行方法，色块的长度，代表了方法所执行的时间

10.5.3.2 Profile区域

Profile区域：显示你选择的色块所代表的方法在该色块所处的时间段内的性能分析

Incl CPU Time：某方法占用CPU的时间

Excl CPU Time：某方法本身（不包含子方法）占用CPU的时间

Incl Real Time：某方法真正执行的时间

Excl Real Time：某方法本身（不包含子方法）真正执行的时间

Calls+RecurCalls：调用次数+递归回调的次数

每个时间都包含两列，一个是实际的时间，另一个是百分比，如果占用时间长且Calls+RecurCalls次数少，那么就可以列为怀疑对象

10.6 使用MAT工具分析App内存状态

MAT工具是一个分析内存的强力助手

10.6.1 生成HPROF文件

打开Android Device Monitor工具，选择要监听的线程，并点击菜单栏中的”Update Heap”按钮

在Heap标签中点击”Cause GC”按钮，就会显示当前内存状态

这里有一个判断当前是否存在内存泄漏的小技巧：当我们不停地点击”Cause GC”按钮的时，如果”data object”一栏中的”Total size”有明显变化，就代表可能存在内存泄漏

上面是手动查看Heap状态，下面点击菜单栏的”Dump HPROF File”按钮

系统会生成一个.hprof文件，默认名为包名.hprof，不过还不能直接使用MAT工具查看，还需要进行格式转换，在SDK目录的platform-tools目录下，使用hprof-conv工具帮助转换，命令如下：

D:\sdk\platform-tools>hprof-conv F:\Heap\com.handsome.heap.hprof heap.hprof

格式命令：”hprof-conv infile outfile”生成heap.hprof文件利用MAT工具就可以进行内存分析

10.6.2 分析HPROF文件

打开MAT工具，选择”Open a Heap Dump”选项，进入分析：

Histogram

Histogram直方图，用于显示内存中每个对象的数量、大小和名称

在选择对象上单击鼠标右键，在弹出的快捷菜单中选择”List objects-with incoming references”选项查看具体的对象

Dominator Tree

Dominator Tree支配树会将内存中的对象按照大小进行排序，并显示对象之间的引用结构

对象已经按照”Retained Heap”进行排序了，即按照对象及其持有的引用的内存总和进行排序，通过分析内存占用大的对象找出内存消耗的原因

10.7 使用Dumpsys命令分析系统状态

Dumpsys命令的功能非常强大，可使用的参数配置也非常多，Dumpsys官方信息：https://source.android.com/devices/input/dumpsys.html

使用Dumpsys命令，只需要输入”adb shell dumpsys+参数”即可

adb shell dumpsys activity：查看Activity栈的详细信息

adb shell dumpsys meminfo：查看内存信息

adb shell dumpsys battery：查看电池信息

adb shell dumpsys package：查看包信息

adb shell dumpsys wifi：显示Wi-Fi信息

adb shell dumpsys alarm：显示alarm信息

adb shell dumpsys procstats：显示内存信息

总结

这章学到的内容还是很多的

布局的优化，开发者选项中几种工具的使用，Scalple，Hierarchy Viewer等等

内存的优化，主要是Android Lint工具真是非常的方便，然后就是Android Profiler

TraceView、MAT工具、Dumpsys这几个工具等到之后需要的话再去好好熟悉一下

Android群英传读书笔记——第十章：Android性能优化

第十章目录

第十章读书笔记

布局优化

内存优化

使用各种工具来进行分析、优化

10.1 布局优化

手机过度绘制再结合JakeWharton大神的Scalple的开源插件，过度绘制这一块，没什么问题了

布局优化的一些小总结

借这个机会说一下LinearLayout和RelativeLayout的性能对比

再举个例子，说一下渲染和过度绘制，一个这样的布局，嵌套了5个RelativeLayout：

下面我们给每一个RelativeLayout都加一个背景色

10.2 内存优化

10.3 Lint工具

10.4 使用Android Studio的Memory Monitor工具

10.5 使用TraceView工具优化App性能

10.6 使用MAT工具分析App内存状态

10.7 使用Dumpsys命令分析系统状态

总结

猜你喜欢