关于youtube上Android Performance Patterns的总结（部分）

1.熟悉android studio关于Logcat，Memory，CPU，GPU，Network分析窗口的使用。一旦你配置的内存突然下降，那么应该是GC在发挥作用。这些垃圾收集活动通常不会太大影响性能，但是短时间内频繁的出现，会迅速消耗帧时间，还是会导致性能问题的。

2.内存泄露：指的是应用不再使用的对象，但是垃圾收集没有把它们辨认出来。结果是它们一直留在你的内存里。
android运行环境中的内存堆：

android runtime内存堆被有效的划分为不同的区块，根据配置的类型，还根据系统为将来的垃圾收集活动对这些配置的最佳整理。新的对象被配置时，会考虑到这些特点，来决定哪一个区块最合适这个配置。

3.GC的两个主要原则：
1.找到程序里以后都不会使用的数据对象。
2.重新收回这些对象占用的资源。
知道两点：
1.在规定时间内应用垃圾收集时间越长，那么剩下的用于16ms内完成光栅化的逻辑处理时间就更短。如果有连续的大量垃圾收集，或者长时间的垃圾收集，可能会超过16ms，就会导致用户视觉上的卡顿。
2.要知道你的码流可能会执行一些工作，迫使GC发生的更加频繁，或者持续时间更长，比如，在向内部循环中进行一大堆重要对象配置时，就会花费很长时间。这一大堆对象就会污染内存堆。

4.内存流失：在短时间内配置大量的对象，并将它们极短时间内进行释放，就会出现内存流失。如果在内存监控中，看到有内存抖动，那么八九不离十从那里下手。
解决办法：
1.要确保没有在内循环内，为了明显原因配置对象。试着将它们移出到循环之外，或者直接避免它们。还有onDraw函数中也是一样（本质相同）。
2.如果非要创建对象，可以考虑对象池模式。实际上，你会有一个用于配置一组对象的对象池，你的代码不必每次都到堆里去，它可以从内存池里抓取可获得的对象。

这种模式的弊端：你得自己负责释放对象，在使用完要将它们释放进内存池。也就意味着对于高扰动对象，就会需要消耗一些精力，在创建和销毁时合理管理这些对象。（跟getView方法中的模式很像）。

5.关于JobScheduler API的介绍：如何在低电量情况下做事。工具battery historian。

一言以蔽之, 就是把不紧急的工作留待条件更充分的时候完成.

更好的条件包括wifi, 充电, 手机处于休眠状态等…

如果APP有符合如下情况的任务, 可以尝试使用JobScheduler机制执行任务:
可以推迟的非面向用户的任务(如定期数据库数据更新)
当充电时才希望执行的工作(如备份数据)
需要访问网络或 Wi-Fi 连接的任务(如向服务器拉取内置数据)
希望作为一个批次定期运行的许多任务

代码上所需做的工作是将相关任务放置到JobService, 并根据应用情况设置Service启动条件, 可以是如下条件:

当设备充电时启动
当设备连接到不限流量网络(wifi)时启动
当设备空闲时启动
在特定的截止期限之前或以最小的延迟完成
只有当条件得到满足, 系统才会启动计划中的任务.

只要一切执行到位, 对手机续航的提高当然显而易见.

6.关于overdraw：
过度绘制发生的原因是，硬件使用太多的周期来绘制屏幕上的像素，而这些像素到最后都不会组成图片。
现在安卓系统会自动尽量减少过度绘制，它可以试着避免绘制那些完全隐藏于不透明表面之下的项目 。
但是这项技术没有再深入发展，没有复杂的定制视图，还不能覆盖onDraw方法。这些情况下，系统无法了解你是如何绘制内容的，从而很难知道自己应该避免什么。
解决办法：通过使用canvas.cliprect API帮助系统好观察到这一过程。这个功能允许你为自己给出的视图规定可绘制边界，只有矩形框内的项目可以被绘制。
这个API还能保护CPU和GPU的性能：
CPU：每一条canvas绘制命令，将它们提交给OpenGL ES进行绘制时，都会有一点点额外负担。任何clipRect之外的绘制命令都不会提交至硬件，也就不会产生额外负担。
现在，任何与clipRect有部分交叉的内容还是会被绘制。
这也是clipRect在GPU方面可以帮助定义排除矩形，从而从像素层面上让GPU避免为裁剪部分上色的原因。

除了clipRect，还可以使用qucikreject API，他可以让你在你的onDraw功能内部，测试clipRect的交叉部分。

可以使用GPU Overdraw工具进行监测。

7.对于绘制的工作原理：
android系统的工作原理