Android 客户端性能优化（魅族资深工程师毫无保留奉献）

下面分别介绍出现这些问题的常见原因以及分析这些问题的一般步骤。

1.卡顿常见原因

1）人为在UI线程中做轻微耗时操作，导致UI线程卡顿；

2） 布局Layout过于复杂，无法在16ms内完成渲染；

3）同一时间动画执行的次数过多，导致CPU或GPU负载过重；

4） View过度绘制，导致某些像素在同一帧时间内被绘制多次，从而使CPU或GPU负载过重；

5） View频繁的触发measure、layout，导致measure、layout累计耗时过多及整个View频繁的重新渲染；

6） 内存频繁触发GC过多（同一帧中频繁创建内存），导致暂时阻塞渲染操作；

7） 冗余资源及逻辑等导致加载和执行缓慢；

8）工作线程优先级未设置为

Process.THREAD_PRIORITY_BACKGRO 《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》无偿开源 徽信搜索公众号【编程进阶路】 UND

导致后台线程抢占UI线程cpu时间片，阻塞渲染操作；

9） ANR；

2. 卡顿分析解决的一般步骤

1）解决过度绘制问题

在设置开发者选项调试GPU过度绘制中打开调试，看对应界面是否有过度绘制，如果有先解决掉：

定位过渡绘制区域

利用Android提供的工具进行位置确认以及修改(HierarchyView , Tracer for OpenGL ES)

定位到具体的视图(xml文件或者View)

通过代码和xml文件分析过渡绘制的原因

结合具体情况进行优化

使用Lint工具进一步优化

1. 检查是否有主线程做了耗时操作：

严苛模式（StrictMode），是Android提供的一种运行时检测机制，用于检测代码运行时的一些不规范的操作，最常见的场景是用于发现主线程的IO操作。应用程序可以利用StrictMode尽可能的发现一些编码的疏漏。

开启 StrictMode

对于应用程序而言，Android 提供了一个最佳使用实践：尽可能早的在

android.app.Application 或 android.app.Activity 的生命周期使能 StrictMode，onCreate()方法就是一个最佳的时机，越早开启就能在更多的代码执行路径上发现违规操作。

监控代码

publicvoidonCreate(){

if(DEVELOPER_MODE){

StrictMode.setThreadPolicy(newStrictMode.ThreadPolicy.Builder()

.detectAll().penaltyLog().build());

StrictMode.setVmPolicy(newStrictMode.VmPolicy.Builder()

.detectAll().penaltyLog().build());

}

super.onCreate();

}

如果主线程有网络或磁盘读写等操作，在logcat中会有"D/StrictMode"tag的日志输出，从而定位到耗时操作的代码。

3）如果主线程无耗时操作，还存在卡顿，有很大可能是必须在UI线程操作的一些逻辑有问题，比如控件measure、layout耗时过多等，此时可通过Traceview以及systrace来进行分析。

4）Traceview：Traceview主要用做热点分析，找出最需要优化的点。

打开DDMS然后选择一个进程，接着点击上面的“Start Method Profiling”按钮（红色小点变为黑色即开始运行），然后操作我们的卡顿UI,然后点击"Stop Method Profiling",会打开如下界面：

图中展示了Trace期间各方法调用关系，调用次数以及耗时比例。通过分析可以找出可疑的耗时函数并进行优化；

5）systrace：抓取trace：

执行如下命令：

$cdandroid-sdk/platform-tools/systrace

$pythonsystrace.py–time=10-omynewtrace.htmlschedgfxviewwm复制代码

操作APP，然后会生成一个mynewtrace.html 文件，用Chrome打开。

图示如下：

通过分析上面的图，可以找出明显存在的layout，measure，draw的超时问题。

6）导入如下插件，可通过在方法上添加@DebugLog来打印方法的耗时：

build.gradle:

buildscript{

dependencies{

//用于方便调试性能问题的打印插件。给访法加上@DebugLog，就能输出该方法的调用参数，以及执行时间；

classpathcom.jakewharton.hugo:hugo-plugin:1.2.1

}

}

//用于方便调试性能问题的打印插件。给访法加上@DebugLog，就能输出该方法的调用参数，以及执行时间；

applyplugin:com.jakewharton.hugo

java：

@DebugLog

publicvoidtest(inta){

intb=a*a;

}

四、内存性能分析优化

1.内存泄露

该问题目前在项目中一般用leakcanary基本就能搞定，配置起来也相当简单：

build.gradle:

dependencies{

debugCompilecom.squareup.leakcanary:leakcanary-android:1.3.1//or1.4-beta1

releaseCompilecom.squareup.leakcanary:leakcanary-android-no-op:1.3.1//or1.4-beta1

testCompilecom.squareup.leakcanary:leakcanary-android-no-op:1.3.1//or1.4-beta1

}

java:

publicclassExampleApplicationextendsApplication{

@OverridepublicvoidonCreate(){

super.onCreate();

LeakCanary.install(this);

}

}

一旦有内存泄露，将会在通知栏生成一条通知，点开可看到泄露的对象以及引用路径：

2.内存抖动

如果代码中存在在onDraw或者For循环等多次执行的代码中分配对象的行为，会导致运行过程中gc次数增多，影响ui流畅度。一般这些问题都可通过lint工具检测出来。

五、耗电量优化建议

电量优化主要是注意尽量不要影响手机进入休眠，也就是正确申请和释放WakeLock，另外就是不要频繁唤醒手机，主要就是正确使用Alarm。

六、一些好的代码实践

1. 节制地使用Service

2. 当界面不可见时释放内存

3. 当内存紧张时释放内存

4. 避免在Bitmap上浪费内存

对大图片，先获取图片的大小信息，根据实际需要展示大小计算inSampleSize，最后decode；

publicstaticBitmapdecodeSampledBitmapFromFile(Stringfilename,

intreqWidth,intreqHeight){

//FirstdecodewithinJustDecodeBounds=truetocheckdimensions

finalBitmapFactory.Optionsoptions=newBitmapFactory.Options();

options.inJustDecodeBounds=true;

BitmapFactory.decodeFile(filename,options);

//CalculateinSampleSize

options.inSampleSize=

reqHeight);

calculateInSampleSize(options,

reqWidth,

//DecodebitmapwithinSampleSizeset

options.inJustDecodeBounds=false;

returnBitmapFactory.decodeFile(filename,options);

}

publicstaticintcalculateInSampleSize(BitmapFactory.Optionsoptions,

intreqWidth,intreqHeight){

//Rawheightandwidthofimage

finalintheight=options.outHeight;

finalintwidth=options.outWidth;

intinSampleSize=1;

if(height>reqHeight||width>reqWidth){

if(width>height){

inSampleSize=Math.round((float)height/(float)reqHeight);

}else{

inSampleSize=Math.round((float)width/(float)reqWidth);

}

}