Android App性能优化技能，看这篇就够了

lsekfe

一.何为App的性能

拿小车举例，大家知道什么是一辆小车的性能吗？同学甲说，是否省油、加速是否够快、开起来是否稳定、安全等等。

没错，那就是小车的性能。

那App的性能又是指什么呢？同学乙说，App启动是否够快，运行是否流畅，是否省电、省流量，安装包体积是否够小等等。

是的，这就是App的性能。

二.关注App性能，有什么用

我们知道，一辆小车性能越好，加速越快，跑的越稳，越省油。

App也一样，性能越好，运行更流畅、更稳定、更省流量、电量，包的体积也会更小，这能给用户带来优秀的体验，进而也会提升App的知名度。

既然App性能那么重要，那我们就要掌握App性能优化的技能了。

三.如何进行App性能优化

掌握App性能优化，是Android开发人员进阶中高级的必备技能。那如何进行App的性能优化呢？

我们可以从这几个方面入手：卡顿优化、内存优化、稳定性优化、耗电优化、安装包大小优化、数据库SQLite优化、网络优化。

接下来，我们逐一展开讲解。

1.卡顿优化1.1卡顿场景

可分为四个大的方向：

1.1.1UI

UI包括绘制和渲染。

1.1.2启动

启动可分为冷启动、热启动。

1.1.3跳转

跳转包括页面间跳转和前后台切换。

1.1.4响应

包括：点击、滑动、系统事件、按键。

1.2卡顿原因

可分为以下两方面原因：

1.2.1绘制任务太重

首先，我们要明白这样一个概念，人类肉眼在看每秒60帧（即：每帧16ms）的画面时，是不会感受画面卡顿，当低于60帧/秒，我们就会感受到画面卡顿了。

Android系统每隔16ms就发出Vsync，触发对UI的渲染。如果每次都在<=16ms内完成渲染，界面就会流畅；如果每次都在>16ms才能完成渲染，就会造成丢帧，界面就会卡顿。

1.2.2主线程耗时操作

主要包括数据处理耗时，数据处理占用CPU过高，内存增加导致频繁GC等。

1.3分析工具

Hierarchy View，Profile GPU Rendering，TraceView，Systrace

1.4优化手段1.4.1布局优化

减少布局层级嵌套，布局复用，删除无用属性，使用ViewStub提高显示速度。

1.4.2避免过度绘制

常用布局的优化，自定义View的优化。

1.4.3启动优化

UI布局，逻辑加载优化，数据准备策略优化。

1.4.4合理的刷新机制

减少刷新次数，缩小刷新区域，避免后台有较高的CPU线程运行。

其他：比如，使用动画效果，根据不同场景选择合适的动画框架实现。有些情况，可以使用硬件加速来提高流畅度。

2.内存优化2.1Android内存管理机制

Android应用都是在Android虚拟机上运行的，内存分配和垃圾回收都是由Android虚拟机来完成的。

2.1.1Java对象的声明周期

创建-使用-销毁（包括：不可见-不可达-收集-终结-对象再分配）。

Android系统内存分配，实际上是对堆的分配和释放。

2.1.2内存回收机制

年轻代、老年代、持久代。

年轻代

所有新生成的对象都放在年轻代。

年轻代分为一个Eden区和两个Survivor区。

GC时，当Eden区满时，还存活的对象会被复制到其中一个Survivor区（A）。

当这个Survivor区（A）也满时，就会被复制到另一个Survivor区（B）。

当Survivor区（B）也满时，从第一个Survivor（B）复制过来并且还存活的对象，就会被复制到老年代。

老年代

在年轻代经历了N次垃圾回收仍然存活的到对象，就被放到老年代。

持久代

主要存放静态文件，比如Java类，方法等。

持久代对垃圾回收没有明显影响。

如果持久代空间太小，可通过-XX:MaxPermSize =< N配置。

2.2内存泄露场景

资源类的对象未关闭。

注册系统事件未注销：使用Sensor Manager等系统服务，Context.getSystemService(int name)获取系统服务。

类的静态变量持有大数据对象：如，activity的静态变量持有该activty的引用。

非静态内部类的静态实例。

Handler造成内存泄漏。

WebView。

匿名类：new AsyncTask，new Thead，TimerTask。这些匿名类对象结束之前一直持有对应activity的引用，导致activity实例无法被回收，造成内存泄漏。

2.3分析工具

Memory Monitor，Heap Viewer，Allocation Tracker，Memory Analyzer Tool，LeakCanary。

2.4优化手段2.4.1对象引用

根据实际需求，合理使用强引用，软引用，弱引用，虚引用。

2.4.2减少不必要的内存开销

增加内存复用：比如合理使用系统自带的资源，视图，图片，对象池等的复用。

留意自动装箱。

2.4.3使用最优数据类型

使用最优数据类型，比如使用ArrayMap，避免使用枚举类型，使用LruCache等。

2.4.5图片内存优化

图片压缩，图片缓存。

3.稳定性优化3.1异常场景

Crash，ANR。

3.2分析工具

稳定性主要依赖代码优化，逻辑实现的优化来提升。所以从代码层面来看，分析工具主要有：Android Lint，Findbugs，Checkstyle，PMD，FireLine。

3.3优化手段3.3.1提高代码质量。3.3.2代码扫描。3.3.3Crash监控。3.3.4Crash上报机制。4.耗电优化4.1耗电后果

App耗电严重，会给用户带来非常差的体验，导致用户卸载应用。

4.2优化手段4.2.1Battery Historian

这是Google出的Android系统电量分析工具。

4.2.2计算优化

避免浮点运算等等。

4.2.3避免WakeLock不当使用。4.2.4使用Job Schedule。5.安装包大小优化5.1优化体积大小的原因

节省流量，提高用户对App的好感度。

5.2优化手段及工具5.2.1代码混淆

使用ProGuard工具进行压缩，优化，混淆。ProGuard的原理：压缩，优化，混淆。

5.2.2资源优化

使用Android Lint删除冗余资源，使资源文件最小化。

5.2.3图片优化

使用AAPT，TinyPng压缩图片，使用webP图片格式等。

5.2.4避免引入重复功能的库

对比选择最优库，不要引入多个类似功能的库。如果有相关库的源码，可根据实际需求，抽取需要的代码重新编译库，让库尽可能的小。

5.2.5插件化

可将功能模块放服务器，需要用时再加载。

文章APK极限压缩：

mp.weixin.qq.com/s?__biz=MzA…

6.数据库SQLite优化6.1优化手段6.1.1索引概念：

索引是对数据库表中一列或多列数据进行排序的一种数据结构。可理解为一个指向表中数据的指针，与一本书的目录类似。

优点：

加快表中数据查询速度。

缺点：

创建索引本身也会造成资源开销。

类别：

表索引：CREATE INDEX index_name ON table_name。

单列索引：CREATE INDEX index_name ON table_name(column_name)。

唯一索引：CREATE UNIQUE INDEX index_name ON table_name(column_name)。

组合索引：CREATE INDEX index_name ON table_name(column1,column2)。

主键索引：ALTER TABLE table_name ADD CONSTRAINT index_name PRIMARY KEY(primaryKey)。

总结：

合理使用索引，可加快数据库表数据的查询速率。

6.1.2事务概念：

对数据库原子性的操作。

优点：

为数据的整体性执行带来可靠安全性，为更新和删除操作带来很大优化。

总结：

保证数据的完整性，安全性，提高数据更新，删除操作的效率。

6.1.3其他手段

尽量少用cursor.getColumnIndex()。

用StringBuilder(非线程安全)或StringBuffer(线程安全)来拼接字符串。

查询时，只返回需要的数据或结果。

cursor使用后要及时关闭。

7.网络优化7.1原因

网络优化不好，造成用户流量消耗大，耗电快，用户等待时间长体验差等。

7.2工具

Network Monitor，Charles，Fiddler，Stecho。

7.3优化手段7.3.1接口设计

API设计要合理。

使用GZIP压缩。

选择合适的数据格式：json，xml，protocol Buffer。

7.3.2图片处理

图片下载：

使用缩略图。

使用WebP图片。

根据设备规格，指定图片尺寸请求图片。

使用完善的合适的图片加载框架：Glide，Picasso等。

图片上传：一般要支持断点续传。

7.3.3网络缓存

适当缓存，可让App看起来更快。

使用DiskLruCache。

7.3.4打包网络请求

网络状况好(如：WiFi状态下)，可一次异步发起多个业务模块的数据请求。

7.3.5监听相关状态变化

休眠状态(即：熄屏状态下)，尽量不要发起网络请求。

充电状态，可适当做一些必要的网络请求，但要控制频率。

弱网状态下，可压缩和减少数据传输量；不要自动加载图片，用占位图显示；页面视图先显示，网络请求延迟提交。

7.3.6优化网络请求机制

划分网络请求的优先级，同一页面，同一模块，重要的数据优先请求。

网络差，减少请求量；网络好，提高请求量。

合并网络请求，减少请求次数。比如，本地埋点数据，无需实时上报，可先本地缓存，再根据上报策略，选择合适时机一并上报。

7.3.8IP直连和HttpDns

IP直连，省去DNS解析时间。

使用HttpDns，防止运营商域名劫持或跨网访问问题。

7.3.9优化请求频率

使用本地缓存，让App在离线状态也能使用。

优先使用缓存；当没有缓存或缓存国旗，再请求网络数据。

App性能优化，是一个持续地过程，需要我们不断提高自己性能优化的能力，才能提高App的性能，才能打造出”快，省，稳”的极佳体验App。

出自：https://zhuanlan.zhihu.com/p/72047792