阿里巴巴《Android性能优化》
Android性能优化之Systrace分析基础
Android性能优化之Systrace分析基础适⽤平台Android Version： 6.0及以上Platform：通⽤1. 分析前准备最好是在userdebug或者开启root权限的user版本设备上来进⾏systrace的抓取。
在实际的操作⽤，我⼀直使⽤了普通的user版本，需要的信息也都抓到了。
2. ubuntu环境下systrace抓取的⽅法这⾥介绍两种⽐较通⽤的使⽤⽅法，命令⾏式的和图形界⾯式的。
当然还有其他封装的⼯具，⽐如MTK出的⼿机端的apk以及GAT⼯具中的插件等，这⾥就不介绍，我们只需掌握最原始和最基础的，万变不离其宗。
这⾥使⽤的Android SDK⼯具的版本需要升级的6.0也就是level 24。
2.1 命令⾏式使⽤的为Android SDK⽬录下的systrace.py脚本来做android-sdk-linux/platform-tools/systrace/systrace.py -b xxx -t xxx -o trace.html <tag>介绍下参数的使⽤： -b是定义buffer size，单位为KB，-t定义的是抓取的时间，⼀般抓5秒的systrace就将buffer size设成20480差不多，如果buffer size过⼩有可能导致信息丢失。
-o后⾯为⽬标⽂件的名称，最重要和困难的就是tag，那么有⼏种tag呢？可以使⽤命令systrace.py -l来查看，⽽tag的使⽤场景在后⾯会继续介绍。
2.2 图形界⾯式google还提供了图形界⾯式的抓取⼯具，先启动位于android-sdk-linux/tools⽬录下的monitor⼯具，如果sdk的环境变量都配置正确可以直接在命令⾏中执⾏：monitor如果有安装android studio，也可以在studio启动monitor，连接⼿机，会启动如下⼯具界⾯(部分相关截图) 然后点击红框部分的按钮会启动如下systrace抓取前的配置界⾯图中的tag配置为LG项⽬中测试Touch Performance时抓取的配置，适⽤于抓取界⾯启动相关信息的测试项。
Android性能优化
•一、App启动速度优化•二、App内存优化•三、App绘制优化•四、App瘦身•五、APP电量优化App启动速度优化一、认识启动加速含义从点击图标到用户可操作的全部过程意义避免用户一安装应用就卸载分类•冷启动•热启动•温启动过程冷启动前•1、点击相应应用图标•2、App启动之后立即展示一个空白的Window（预览窗口显示）•3、创建App进程冷启动后•1、创建App对象•2、启动Main Thread•3、创建启动的Activity对象，闪屏显示•4、创建启动的MainActivity对象，主页显示•5、其它工作二、优化工具力求获取准确的数据评估1、TraceView性能损耗太大，得出的结果并不真实作用：主要做热点分析，得到两种数据•单次执行最耗时的方法•执行次数最多的方法使用：•1、代码中添加：Debug.startMethodTracing()、检测方法、Debug.stopMethodTracing()•2、打开Profile->CPU->点击Record->点击Stop->查看Profile下方Top Down/Bottom Up找出耗时的热点方法。
2、Systrace+函数插桩Systrace原理在系统的一些关键链路（如SystemServcie、虚拟机、Binder驱动）插入一些信息（Label），通过Label的开始和结束来确定某个核心过程的执行时间，然后把这些Label信息收集起来得到系统关键路径的运行时间信息，最后得到整个系统的运行性能信息。
Android Framework里面一些重要的模块都插入了label信息(Java 层通过android.os.Trace类完成， native层通过ATrace宏完成），用户App中可以添加自定义的Lable。
特性•系统版本越高，Android Framework中添加的系统可用Label就越多，能够支持和分析的系统模块也就越多。
安卓APP开发中的性能优化技巧分享
安卓APP开发中的性能优化技巧分享想要开发一个好的安卓APP必须要注意到性能优化问题。
性能优化不仅可以改善用户体验，同时也可以增加APP的市场占有率与收益。
在日益竞争激烈的市场中，性能优化已经成为了一个制胜的关键。
本文就来分享一些安卓APP开发中的性能优化技巧。
一、CPU、内存与存储的合理利用CPU、内存与存储是每个APP的主要资源，保证它们的充分利用才能获得更好的性能。
比如，在代码编写方面，优化冗长的代码、消除重复计算可以减少CPU的负担，在编写布局文件方面，使用合适的布局文件也可以节省运行时内存和CPU负担。
使用内存缓存（如Glide的内存缓存或者picasso的LruCache）可以达到减少与服务器交互，提高读写速度的目的，同时，对于宣传、新闻类的APP，使用离线缓存会有效降低用户对存储空间的占用需求。
二、网络优化在安卓APP中，网络是非常重要的一个部分，由于网络信号的波动性，大多数情况下通过网络请求取得数据，完美地完成显示数据的并不是特别容易，除了前面提到的离线缓存，我们还可以利用大大提高网络速度的HTTP连接池。
同时，在处理大文件、大数据集或者高频操作上，采用“慢、快、慢”的网络请求策略（先使用低质量、缩放图片作为显示，减少请求量；超时后展示加载动画，提示用户正在加载更多信息；采用分页加载等方法提供更好的用户体验）。
三、减小APK体积APK的大小会影响下载速度和安装时间，因此减小APK体积是提高APP响应速度的重要手段之一。
可以在优化资源上做文章，比如对于不同分辨率的设备，可以根据不同的Imageview设置不同的图片资源，比如drawable-xhdpi、drawable-mdpi等。
同时使用App Bundle可以有效减少APK的体积，通过推迟apk中的某些资源的下载以达到减小apk体积的目的。
四、多进程优化多进程是许多APP通过共享内存、提高APP的响应速度的解决手段之一，但是同步锁和寄存器之间的读写等操作会变得更加耗时。
Android系统调优工具介绍
Android系统调优工具介绍系统调优方向：•最小成本 / 最大化效果优化（硬件加速、UI资源精简、问题代码优化【算法、并发等】）•和谐优化除掉无用功能（重构）•微架构优化（使用新的架构Volley/RxJava/Retrofit）•硬件更新（CPU/GPU/RAM SoC组件硬件升级）•操作系统调优（bootloader启动、系统内存回收机制、驱动更新、优化的补丁、漏洞补丁）度量目标：•CPU/GPU/SoC动态性能指标。
•系统层面(网络、线程调度、硬件（CPU/内存/IO）超频、视频、图形图像处理、磁盘、缓存等)性能指标。
•内存使用动态指标。
•代码结构、算法及效率性能指标。
•调用栈动态性能指标。
•等待/暂停时间性能指标（同步、线程、I/O、网络等等）•延迟指标（受干扰、执行耗时操作、以及不稳定等带来的）•精准分析定位及代码跟踪展望工具的强大功能：•泄露分析：内存泄露•阻塞分析：定位到代码级别•工具化分析：结合原生的工具对数据专项采集进行代码层分析•电源分析：功耗分析•平台级别：针对平台带来的问题跟踪、调查•网络分析：网络数据分析和统计分析Systrace: 侧重于系统层面的CPU/GPU/IO/SurfaceFlinger, 可以快速过滤出问题瓶颈的大方向。
•1.1 Systrace简介•Systrace是Android4.1中新增的性能数据采样和分析工具。
它可帮助开发者收集Android关键子系统（如surfaceflinger、WindowManagerService等Framework部分关键模块、服务）的运行信息，从而帮助开发者更直观的分析系统瓶颈，改进性能。
•Systrace的功能包括跟踪系统的I/O操作、内核工作队列、CPU负载以及Android 各个子系统的运行状况等。
在Android平台中，它主要由3部分组成：•内核部分：Systrace利用了Linux Kernel中的ftrace功能。
Android应用性能优化最佳实践
目录分析
1.1 Android Studio的优势
1.2 Android Studio使用入 门
1.3 Android Studio实用技
巧
1.4本章小结
1.2 Android Studio使用入门
1.2.1 Android Studio安装 1.2.2创建一个Android Studio工程 1.2.3从Eclipse项目迁移到Android Studio
1.3 Android Studio实用技巧
1.3.1代码管理 1.3.2代码编辑技巧 1.3.3调试技巧
2.1 Android系统显 示原理
2.2性能分析工具
2.3布局优化 2.4避免过度绘制
1
2.5启动优化
2
2.6合理的刷 新机制
3
2.7提升动画 性能
4
2.8卡顿监控 方案与实现
5
2.9本章小结
读书笔记
读书笔记
性能优化还蛮系统的，部分内容深度不够，但是作为正常工作的注意点看一看还是挺好的。 所有的性能优化过程都差不多，即发现问题，再去寻找问题解决方案，最后解决问题。 对于安卓开发的优化有个系统全面的介绍，不错，更深入的需要自己再去研究。 性能优化是一个app的难点，但同时也是重点。 书中的笔误特别多，不知道是不是电子版的缘故后面两章写的很仓促整本书深度不够。 有些笔误，但瑕不掩瑜，毕竟有关性能优化写的这么全的太少了，后悔没早点看到[捂脸] 。 这本书作为Android移动测试的入门挺不错的，基本的知识都有介绍，包括移动测试的要点。 介绍挺全面的，涨了很多知识，某些方面深度不够，但对于一般的日常开发够用了。 作为性能优化知识框架还挺不错的，在这个基础上再总结下目前业界常见的优化手段，沉淀出APP优化的方 法论。 挑着看的，只看了绘制/内存/稳定/功耗，整体而言性能测试大同小异，基本上性能测试也比较少，不过书 中有些方案倒是蛮新颖有趣的~绘制和稳定讲的蛮详细的，给五颗星吧~~。
阿里巴巴Android开发手册
tween 动 画 资 源 ： 尽 可 能 以 通 用 的 动 画 名 称 命 名 ， 如 module_fade_in , module_fade_out , module_push_down_in (动画+方向)； frame 动画资源：尽可能以模 块+功能命名+序号。如：module_loading_grey_001 5. 【推荐】 color 资源使用#AARRGGBB 格式，写入 module_colors.xml 文件中，命 名格式采用以下规则：
3.【强制】Activity 间通过隐式 Intent 的跳转，在发出 Intent 之前必须通过 resolveActivity 检查，避免找不到合适的调用组件，造成 ActivityNotFoundException 的异常。
正例：
public void viewUrl(String url, String mimeType) { Intent intent = new Intent(Intent.ACTION_VIEW); intent.setDataAndType(Uri.parse(url), mimeType); if (getPackageManager().resolveActivity(intent, PackageManager.MATCH_DEFAULT_
模块名_逻辑名称_颜色
如：
<color name="module_btn_bg_color">#33b5e5e5</color>
-4-
阿里巴巴 Android 开发手册
6.【推荐】dimen 资源以小写单词+下划线方式命名，写入 module_dimens.xml 文件中， 采用以下规则：
Android App 性能优化
性能优化Android应用程序运行的移动设备受限于其运算能力，存储空间，及电池续航。
由此，它必须是高效的。
电池续航可能是一个促使你优化程序的原因，即使他看起来已经运行的足够快了。
由于续航对用户的重要性，当电量耗损陡增时，意味这用户迟早会发现是由于你的程序。
虽然这份文档主要包含着细微的优化，但这些绝不能成为你软件成败的关键。
选择合适的算法和数据结构永远是你最先应该考虑的事情，但这超出这份文档之外。
简介写出高效的代码有两条基本的原则：●不作没有必要的工作。
●尽量避免内存分配。
明智的优化这份文档是关于Android规范的细微优化，所以先确保你已经了解哪些代码需要优化，并且知道如何去衡量你所做修改所带来的效果（好或坏）。
开发投入的时间是有限的，所以明智的时间规划很重要。
(更多分析和笔记参见总结。
)这份文档同时确保你在算法和数据结构上作出最佳选择的同时，考虑API选择所带来的潜在影响。
使用合适的数据结构和算法比这里的任何建议都更有价值，优先考虑API版本带来的影响有助于你找到更好的实现。
（这在类库代码中更为重要，相比应用代码）(如果你需要这样的建议，参见 Josh Bloch's Effective Java, item 47.)在优化Android程序时，会遇到的一个棘手问题是，保证你的程序能在不同的硬件平台上运行。
虚拟机版本和处理器各部相同，因此运行在之上的速度也大不一样。
但这并且不是简单的A比B快或慢，并能在设备间做出排列。
特别的，模拟器上只能评测出一小部分设备上体现的东西。
有无JIT的设备间也存在着巨大差异，在JIT设备上好的代码有时候会在无JIT的设备上表现的并不好。
如果你想知道一个程序在设备上的具体表现，就必须在上面进行测试。
避免创建不必要的对象对象创建永远不会是免费的。
每个线程的分代GC给零时对象分配一个地址池以降低分配开销，但往往内存分配比不分配需要的代价大。
如果在用户界面周期内分配对象，就会强制一个周期性的垃圾回收，给用户体验增加小小的停顿间隙。
Android 图片加载性能优化总结
Android 图片加载性能优化总结一、Android Bitmap加载大尺寸图片优化：压缩原因：1.imageview大小如果是200*300那么加载个2000*3000的图片到内存中显然是浪费可耻滴行为;2.最重要的是图片过大时直接加载原图会造成OOM异常(out of memory内存溢出)所以一般对于大图我们需要进行下压缩处理看不懂英文的话木有关系,本篇会有介绍主要处理思路是:1.获取图片的像素宽高(不加载图片至内存中,所以不会占用资源)2.计算需要压缩的比例3.按将图片用计算出的比例压缩,并加载至内存中使用官网大图片加载教程(上面网址里的)对应代码就是:/*** 获取压缩后的图片* @param res* @param resId* @param reqWidth 所需图片压缩尺寸最小宽度* @param reqHeight 所需图片压缩尺寸最小高度* @return*/public static Bitmap decodeSampledBitmapFromResource(Resourcesres, int resId, int reqWidth, int reqHeight) {// 首先不加载图片,仅获取图片尺寸final BitmapFactory.Options options= new BitmapFactory.Options();// 当inJustDecodeBounds设为true时,不会加载图片仅获取图片尺寸信息options.inJustDecodeBounds = true;// 此时仅会将图片信息会保存至options对象内,decode方法不会返回bitmap 对象BitmapFactory.decodeResource(res, resId, options);// 计算压缩比例,如inSampleSize=4时,图片会压缩成原图的1/4options.inSampleSize = calculateInSampleSize(options, reqWidth, reqHeight);// 当inJustDecodeBounds设为false时,BitmapFactory.decode...就会返回图片对象了options.inJustDecodeBounds = false;// 利用计算的比例值获取压缩后的图片对象return BitmapFactory.decodeResource(res, resId, options);}代码详解:核心方法是BitmapFactory.decode...(...., options)...的意思是此外还有一系列的decodeFile/decodeStream等等方法,都是利用options灵活解析获取图片,只不过解析图片的来源不同罢了,比如网络图片获取,一般就是解析字节流信息然后decode获取图片实例Options是图片配置信息,参数详细介绍下:inJustDecodeBounds 是否只解析边界设为true时去decode获取图片,只会加载像素宽高信息设为false时decode则会完全加载图片inSampleSize 压缩比例比如原图200*300,如果值是2时会压缩成100*150; 是4则图片压缩成50*75最好是2的幂数,比如2 4 8 16 .....outHeight 图片原高度outWidth 图片原宽度其他参数自行研究,这里暂时只用到这几个decodeSampledBitmapFromResource方法内的三段代码对应上面的三步流程难点在于中间那步,压缩比例的计算,官网同样提供了个calculateInSampleSize方法其中reqWidth和reqHeight是所需图片限定最小宽高值/*** 计算压缩比例值* @param options 解析图片的配置信息* @param reqWidth 所需图片压缩尺寸最小宽度* @param reqHeight 所需图片压缩尺寸最小高度* @return*/public static int calculateInSampleSize(BitmapFactory.Options options, int reqWidth, int reqHeight) {// 保存图片原宽高值final int height = options.outHeight;final int width = options.outWidth;// 初始化压缩比例为1int inSampleSize = 1;// 当图片宽高值任何一个大于所需压缩图片宽高值时,进入循环计算系统if (height > reqHeight || width > reqWidth) {final int halfHeight = height / 2;final int halfWidth = width / 2;// 压缩比例值每次循环两倍增加,// 直到原图宽高值的一半除以压缩值后都~大于所需宽高值为止while ((halfHeight / inSampleSize) >= reqHeight&& (halfWidth / inSampleSize) >= reqWidth) {inSampleSize *= 2;}}return inSampleSize;}利用此方法获取到所需压缩比例值,最终获取到压缩后的图片~以上代码能够看懂的话,下面这段/*扯淡*/可以跳过逻辑是将原图宽高一半一半的缩减,一直减到宽高都小于自己设定的限定宽高时为止,测试的时候问题来了原图400*300,我限定值200*150,if满足进入,while循环第一次,400/2/1=200不满足>的条件~结束循环,最终返回了个inSampleSize=1给我马丹我限定值正好是原图的一半啊,你应该返回给我2啊~你特么最后返回个1给我,那压缩处理后的图还是400*300!!!当我将限定值稍微改一下变成195*145稍微降低一点点时~if满足进入,while循环第一次,400/2/1>195满足~然后压缩比例1*2变成了2,在下一次while循环时不满足条件结束,最后返回比例值2~ 满足压缩预期官网的这个方法是: 将图片一半一半的压缩,直到压缩成成大于所需宽高数的那个最低值大于~不是大于等于,所以就会出现我上面那种情况,我觉得方法不是太好= = 能满足压缩的需求,但是压缩的比例不够准确~所以最好改成大于等于,如下(个人意见,仅供参考,在实际压缩中很少遇到恰巧等于的这个情况,所以>和>=差别也不大额~看我这扯扯淡就当对计算比例的逻辑加深个理解吧)while ((halfHeight / inSampleSize) >= reqHeight&& (halfWidth / inSampleSize) >= reqWidth) {inSampleSize *= 2;}优化:还是上面例子,如果限定了200*150,而原图是390*290会是个啥情况?还是第一次while循环,390/2/1结果是195不满足>200的情况,结束循环,比例值为1,最后图片压缩成400*300虽然压缩一次以后没有满足大于所需宽高,但是和所需宽高很接近啊!!!能不能做一个获取压缩成最接近所需宽高数的比例值呢?我也不知道= = 回头可以慢慢研究, 这个"接近"的定义比较模糊,不好掌握~找了几个有名的图片加载开源框架发现也都没有这种处理- -不知道是这样设计是不需要呢,还是没啥用呢以上,图片的像素大小已经做了缩放,但是图片的大小除了和像素有关,还和色彩样式有关不同的样式决定了图片单个像素占的字节数比如,图片默认的色彩样式为ARGB_8888,每个像素占4byte(字节)大小可以看到一共有四种色彩样式ALPHA_8 每个像素只要1字节~可惜只能代表透明度,没有颜色属性ARGB_4444 每个像素要2字节~带透明度的颜色~可惜官方不推荐使用了ARGB_8888 每个像素要4字节~带透明度的颜色, 默认色样RGB_565 每个像素要2字节~不带透明度的颜色默认为ARGB_8888,如果想丧心病狂的继续减少图片所占大小~不需要透明度参数的话,那就可以把色彩样式设为RGB_565设置方法是在BitmapFactory.decode..获取图片事例时修改配置参数的inPreferredConfig 参数opts.inPreferredConfig = Bitmap.Config. RGB_565 ;想亲自撸一撸试一试压缩图片了吧?要注意点问题,如果用res包下图片测试的话,你会发现有图片尺寸有点混乱那是因为在drawable-*dpi文件夹中的图片会根据对应对应的屏幕密度值不同自动进行一定的缩放,比如放在drawable-hdpi里的图片,直接不经过压缩BitmapFactor.decode..出来,会发现bitmap的宽高值是原图的2/3,测试的时候图片记得放在drawable包下(没有的话自己res下新建一个),否则你会被奇怪的宽高值弄凌乱的，具体变化原因参考源代码处理,或者网上搜搜看。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
移动互联网开发者大会2016
14
回收内存
Bitmap.recycle Tab切换时释放Bitmap 资源释放 onTrimMemory
移动互联网开发者大会2016
15
内存泄露-原因
Handler，内部类 Static field Context View.post内存泄露
移动互联网开发者大会2016
Android性能优化
李侦跃 阿里巴巴
移动互联网开发者大会2016
0
目录
背景 策略 建议
致谢
移动互联网开发者大会2016
1
背景
本地播放器 种子用户
吸引新用户 在线曲库
增加活跃度 社区化探索
商业模式
店铺 交易 直播
移动互联网开发者大会2016
2
背景
65536
冷启 动
技术问题 包体
积
内存
卡顿 网络
移动互联网开发者大会2016
23
谢谢聆听
hibrucehi hi大头鬼hi bruceinpeking@
二维码
移动互联网开发者大会2016
24
16
内存泄露-检测
Memory Monitor
Leak Canary
移动互联网开发者大会2016
17
内存泄露-检测
Allocation Tracker
移动互联网开发者大会2016
18
内存泄露-检测
MAT
移动互联网开发者大会2016
19
内存泄露-检测
Lint
移动互联网开发者大会2016
20
网络优化
HTTPDNS 预加载
spdy 页面分块加载
缓存
网络请求时机
监控
移动互联网开发者大会2016
21
其他优化
Fastjson预训练 Blockcanary检测页面卡顿 开启strict mode Inspect code（lint）
移动互联网开发者大会2016
22
建议
避免过早优化 持续集成配置lint 资源混淆 Code Review 线上监控
3dex • 优化前 2dex • 优化后
冷启动减少3s
移动互联网开发者大会2016
10
启动优化-流程
有向无环图（DAG）+进程判断
启动 必要主线程启动项
/
有 向 图 关 键 路 径
DONE
必要多线程启动项
进入闪屏
优先启动项
是否进入 闪屏
是 启动首页
前台启动项 否
等待闪屏
移动互联网开发者大会2016
次优先启动项
11
内存优化
减少内存占用 复用内存 回收内存 内存泄露
移动互联网开发者大会2016
12
减少内存占用
减少图片的使用 图片格式的选择 图片需要的格式和尺寸decode 使用阿里云OSS图片裁剪处理 数据结构
移动互联网开发者大会2016
13
内存复用
对象池 Bitmap复用 Bitmap缓存 ViewHolder 避免不必要的创建
移动互联网开发者大会2016
7
启动优化-瘦身
资源
APK 瘦身
代码
42M • 优化前 32M • 优化后
移动互联网开发者大会2016
8
启动优化-dex
dexOpt
Hale Waihona Puke Multidex同 步Application attach
dex
异步加 载
按需加 载
插件 化
1个dex
移动互联网开发者大会2016
9
启动优化-dex
移动互联网开发者大会2016
3
策略
启动优化 内存优化 网络优化 其他
移动互联网开发者大会2016
4
启动优化
Apk体积 Dex数量 启动流程
移动互联网开发者大会2016
5
体积裁剪-inspect code
移动互联网开发者大会2016
6
体积裁剪
代码混淆 图片格式选择（webP） TinyPng压缩图片 资源混淆 https:///shwenzhang/AndResGuard