App性能优化学习

App性能优化

对于一个Android开发，一个好的App：

• 流畅
• 稳定
• 省电省流量
• 安装包小

流畅

使用时避免出现卡顿，提高响应速度

卡顿

根本原因：

1. 界面绘制：绘制的层级深、页面复杂、刷新不合理，绘制任务太重，绘制内容耗时太长（>16ms）。
2. 数据处理：导致这种卡顿场景的原因是数据处理量太大，一般分为三种情况，一是数据在处理UI线程，二是数据处理占用CPU高，导致主线程拿不到时间片，三是内存增加导致GC频繁，从而引起卡顿。

布局优化

一个页面的显示测量和绘制过程都是通过递归来完成的，多叉树遍历的时间与树的高度h有关，其时间复杂度O(h)，如果层级太深，每增加一层则会增加更多的页面显示时间。

主要通过减少层级、减少测量和绘制时间，保持布局层级的扁平化、提高复用性三个方面入手

• 减少层级。合理使用RelativeLayout和LinerLayout,constrainLayout，合理使用Merge。
• 在不影响层级深度的情况下，使用LinearLayout而不是RelativeLayout。因为RelativeLayout会让子View调用2次onMeasure，LinearLayout ,Measure的耗时越长那么绘制效率就低。
• 尽可能少用wrap_content。wrap_content 会增加布局measure时计算成本，在已知宽高为固定值时，不用wrap_content 。
• 删除控件中无用的属性。
• 减少使用weight属性，会导致measure两次,Measure的耗时越长那么绘制效率就低。
• 使用merge减少层级
• 用TextView、EditText的灵活运用，减少控件的数量。

避免过度绘制

过度绘制是指在屏幕上的某个像素在同一帧的时间内被绘制了多次。某些像素区域被绘制了多次，从而浪费了多余的CPU以及GPU源。

避免过度绘制：

• 移除XML中非必须的背景，移除Window默认的背景、按需显示占位背景图片

• 自定义View优化。使用 canvas.clipRect()来帮助系统识别那些可见的区域，只有在这个区域内才会被绘制。

如何检测?

• 使用HierarchyViewer来查找Activity中的布局是否过于复杂
• 在开发者选项中打开Show GPU Overdraw选项进行观察是否存在过度绘制
• 使用TraceView来观察CPU执行情况

App启动优化

从心理学角度而言,越快的启动速度往往给用户以性能好,高效可靠的心理暗示,这就很容易让用户对其产生好感。通过ADB命令统计应用的启动时间：adb shell am start -W 首屏Activity。

安卓应用的启动方式分为三种：冷启动、暖启动、热启动，应用发生冷启动时，系统一定会执行：

• 开始加载并启动应用
• 应用启动后，显示一个空白的启动窗口（启动闪屏页）
• application的初始化
• 启动UI线程
• 创建Activity
• 导入视图（inflate view）
• 计算视图大小（onmesure view）
• 得到视图排版（onlayout view）
• 绘制视图（ondraw view）

暖启动

当应用中的 Activities 被销毁，但在内存中常驻时，应用的启动方式就会变为暖启动。相比冷启动，暖启动过程减少了对象初始化、布局加载等工作，启动时间更短。但启动时，系统依然会展示闪屏页，直到第一个 Activity 的内容呈现为止。

热启动

相比暖启动，热启动时应用做的工作更少，启动时间更短。热启动产生的场景很多，常见如：用户使用返回键退出应用，然后马上又重新启动应用。

优化方法:

• 使用Activity的windowBackground主题属性来为启动的Activity提供一个简单的drawable。等Activity加载完毕后，再去加载Activity的界面，而在Activity的界面中，我们将主题重新设置为正常的主题

 @Override
    protected void onCreate(Bundle savedInstanceState) {
            setTheme(R.style.ThemeApp);
           super.onCreate(savedInstanceState);
    }

• 优化闪屏页的UI布局
• 启动加载逻辑优化。可以采用分布加载、异步加载、延期加载策略来提高应用启动速度。
• 数据初始化分析，加载数据可以考虑用线程初始化等策略。
• Application的onCreate(),attachBaseContext()中同样减少复杂和耗时的操作
• 将一张图片通过设置主题的方式显示为启动窗口.
• Application中主要做了各种三方组件的初始化,考虑异步初始化三方组件，不阻塞主线程。有时可能会出现WorkThread中尚未初始化完毕但MainThread中已经使用的错误，因此这种情况建议延迟到使用前再去初始化；比如说根据情况放到SplashActivity，WorkThread，Application中初始化
• 卡顿不能都靠异步来解决，错误的使用工程线程不仅不能改善卡顿，反而可能加剧卡顿。Thread、ThreadPoolExecutor、AsyncTask、HandlerThread、IntentService等都各有利弊；例如通常情况下ThreadPoolExecutor比Thread更加高效、优势明显，但是特定场景下单个时间点的表现Thread会比ThreadPoolExecutor好：同样的创建对象，ThreadPoolExecutor的开销明显比Thread大；
• 正确的开启线程也不能包治百病，例如执行网络请求会创建线程池，而在Application中正确的创建线程池势必也会降低启动速度；因此延迟操作也必不可少。

通过对traceview的详细跟踪以及代码的详细比对，我发现Phihome卡顿发生在：

部分数据库及IO的操作发生在首屏Activity主线程；
Application中创建了线程池；
首屏Activity网络请求密集；
工作线程使用未设置优先级；
信息未缓存，重复获取同样信息；
流程问题：例如闪屏图每次下载，当次使用；

以及其它细节问题：

执行无用老代码；
执行开发阶段使用的代码；
执行重复逻辑；
调用三方SDK里或者Demo里的多余代码；

启动总结

利用主题快速显示界面
** 异步初始化组件；**
** 梳理业务逻辑，延迟初始化组件、操作；**
** 正确使用线程；**
** 去掉无用代码、重复逻辑等。**

合理的刷新机制

有时数据的变化会促使页面刷新，但频繁的刷新会导致资源开销增加。如ListView、RecycleView。

• 减少刷新的次数和刷新的区域（只刷新需要更新的部分数据）
• 尽量避免后台有高的CPU线程运行
• ondraw方法不需要创建新的局部对象，这是因为ondraw方法是实时执行的，这样会产品大量的临时对象，导致占用了更多内存，并且使系统不断的GC。降低了执行效率。
• Ondraw方法不需要执行耗时操作，在ondraw方法里少使用循环，因为循环会占用CPU的时间。导致绘制不流畅，卡顿等等。

内存优化

Android系统会限制每个App可分配的最大内存。当内存不足时，会导致内存溢出，爆出OutOfMemoryError。当内存紧张时，会触发GC，占用cpu的时间片，因此频繁的GC会导致会导致系统卡顿。

优化内存空间

在移动设备上，由于物理设备的存储空间有限,因此使用最小内存对象或者资源可以减小内存开销，同时让GC 能更高效地回收不再需要使用的对象，让应用堆内存保持充足的可用内存，使应用更稳定高效地运行。常见做法如下：

• 对象引用。强引用、软引用、弱引用、虚引用四种引用类型，根据业务需求合理使用不同，选择不同的引用类型。
  减少不必要的内存开销。注意自动装箱，增加内存复用，比如有效利用系统自带的资源、视图复用、对象池、Bitmap对象的复用(修改Bitmap的颜色格式)。还比如字符串资源，如果需要拼接，不要使用string，而是使用stringbuilder。

• 使用最优的数据类型。比如针对数据类容器结构，可以使用ArrayMap/SparseArray数据结构(Hashmap自动装箱意味着需要产生额外的对象，这对于内存的使用和垃圾回收产生影响.相对于HashMap来说每一次put会少创建一个对象(HashMapEntry)。)，避免使用枚举类型，使用缓存Lrucache等等。

• 图片内存优化。可以设置位图规格，根据采样因子做压缩，用一些图片缓存方式对图片进行管理等

• 减少帧动画的使用,如果需要,通过SurfaceView实现

• 使用更轻量级的数据结构,比如ArrayMap/SparseArray

• 初始化时，尽可能指定HashMap的大小

• 合理的使用多进程

• 及时关闭service

• 在该onStop（）里做释放资源（例如网络连接、注销广播等）的工作

• 相比于静态常量，枚举会有超过其两倍以上的内存开销，在android中需严格避免使用枚举

常见内存泄漏场景

• 资源性对象未关闭。比如Cursor、File文件等，往往都用了一些缓冲，在不使用时，应该及时关闭它们。

• 注册对象未注销。比如事件注册后未注销，会导致观察者列表中维持着对象的引用。

• 类的静态变量持有大数据对象。

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

• Handler临时性内存泄漏。如果Handler是非静态的，容易导致Activity或Service不会被回收。

• 容器中的对象没清理造成的内存泄漏。

• 错误的上下文引用，尽量使用Application。

• 单例造成内存泄露

• Animation导致内存泄露，在Activity的ondestory（）方法中调用Animation.cancle（）进行停止，一些简单的动画我们可以通过自定义view来解决。

内存分析工具

• Memory Monitor
• LeakCanary
• Heap Viewer
• Android Device Monitor中的Application Tracker追踪内存分配信息
• 使用MAT分析Java堆

稳定

Android应用的稳定性定义很宽泛，影响稳定性的原因很多，比如内存使用不合理、代码异常场景考虑不周全、代码逻辑不合理等，都会对应用的稳定性造成影响。其中最常见的两个场景是：Crash和ANR，这两个错误将会使得程序无法使用，比较常用的解决方式如下：

• 提高代码质量。比如开发期间的代码审核，看些代码设计逻辑，业务合理性等。

• 代码静态扫描工具。常见工具有Android Lint、Findbugs、Checkstyle、PMD等等。

• Crash监控。把一些崩溃的信息，异常信息及时地记录下来，以便后续分析解决。

• Crash上传机制。在Crash后，尽量先保存日志到本地，然后等下一次网络正常时再上传日志信息

ANR问题
Android官方规定：activity如果5s内无响应事件（屏幕触摸事件或者键盘输入事件）。BroadcastReceiver如果在10s内无法处理完成。Service如果20s内无法处理完成。绝大多数就是因为线程阻塞导致的。

• Asynctask：为UI线程与工作线程之间进行快速处理的切换提供一种简单便捷的机制。适用于当下立即需要启动，但是异步执行的生命周期短暂的场景。
• HandlerThread：为某些回调方法或者等待某些执行任务的执行设置一个专属的线程，并提供线程任务的调度机制。
• ThreadPool：把任务分解成不同的单元，分发到各个不同的线程上，进行同时并发处理。
• IntentService：适合执行由Ui触发的后台任务。并可以把这些任务执行的情况通过一定的机制反馈给UI。

省电

节省流量和好点，减少cpu和Gpu的计算，优化网络访问。

计算优化，避开浮点运算等。

• 避免WaleLock使用不当。

• 需要进行网络请求时，我们需先判断网络当前的状态。如果非必要，可将网络请求放在wifi的环境下，因为wifi请求的耗电量远比移动数据的耗电量低的低。

• 使用Job Scheduler。（延迟非必须的操作到充电状态时,比如日志上报完全可以在夜间充电时完成,这点可以结合JobScheduler使用）

• 使用传感器采集数据时,一旦不需要记得取消注册.

如何检测：

• 手机选项中通过查看APP的电量消耗的统计数据
• 使用Battery Historian Tool来查看详细的电量消耗

网络优化

做好网络优化一方面可以提高体验,另一方面可以减少流量和电量的损耗.

如何优化:

• 根据实际场景设计缓存策略。比如说根据数据是否经常变化设置缓存时间。
• 减少数据传输量,对传输的数据做压缩.如果传输的是图片,需要选择合适的图片格式以及根据显示大小请求合适规格的图片.
• 某些情况下可以采用IP直连,一方面可以减少DNS解析时间,另一方面可以防止域名劫持
• 根据实际场景确定请求策略(比如说连接wifi和充电的情况下，修改请求频率)
• 根据情况选择图片格式，和图片色彩位数。
• 刷新数据时，尽可能使用局部刷新，而不是全局刷新

安装包小

应用的安装包越大，用户下载的门槛越高，特别是在移动网络情况下，用户在下载应用时，对安装包大小的要求更高，因此，减小安装包大小可以让更多用户愿意下载和体验产品。

减少安装包大小的常用方案:

• 代码混淆。使用ProGuard代码混淆器工具，它包括压缩、优化、混淆等功能。
• 资源优化。比如使用Android Lint删除冗余资源，资源文件最少化等。
• 图片优化。比如利用AAPT工具对PNG格式的图片做压缩处理，降低图片色彩位数等。使用Vertor Drawable替代png/jpeg，有选择的提供对应分辨率的图片资源
• 复用已经存在的图片,多用通过代码对已有图片进行变换的方式实现复用
• 避免重复功能的库，使用WebP图片格式等。
• 插件化。比如功能模块放在服务器上，按需下载，可以减少安装包大小。
• 减少so文件的数量,根据实际情况提供so文件
• 使用Gradle中的shrinkResource来将无用的代码和资源排除在APK安装包之外
• 减少不必要的依赖库/Jar,在满足需求的前提下优先选择体积小的.

使代码高效的建议

• 如果方法不需要访问某对像的字段，将该方法设置为静态，调用速度会提升15%~20%
• 对于常量使用 final static
• int的数组比Integer对象数组要好得多。两个平行的int数组要比一个（int,int）型的对象数组高效。这对于其他任何基本数据类型的组合都通用
• 循环数组结构的数据时，建议使用普通for循环，链表结构时使用增强for循环
• 避免使用浮点数，通常的经验是，在Android设备中，浮点数会比整型慢两倍

数据库操作方法的优化

• 尽量利用原生的SQL语句
• 当操作条数较多时，利用事务进行批处理
  这样SQLite将把全部要执行的SQL语句先缓存在内存当中，然后等到COMMIT的时候一次性的写入数据库，这样数据库文件只被打开关闭了一次，效率自然大大的提高