当点击app的启动图标时，安卓系统会从Zygote进程中fork创建出一个新的进程分配给该应用，之后会依次创建和初始化Application类、创建MainActivity类、加载主题样式Theme中的
通山网站建设公司创新互联公司,通山网站设计制作，有大型网站制作公司丰富经验。已为通山近千家提供企业网站建设服务。企业网站搭建\成都外贸网站建设公司要多少钱，请找那个售后服务好的通山做网站的公司定做！
windowBackground等属性设置给MainActivity以及配置Activity层级上的一些属性、再inflate布局、当onCreate/onStart/onResume方法都走完了后最后才进行contentView的measure/layout/draw显示在界面上，所以直到这里，
应用的第一次启动才算完成，这时候我们看到的界面也就是所说的第一帧。所以，总结一下，应用的启动流程如下：
Application的构造器方法——attachBaseContext()——onCreate()——Activity的构造方法——onCreate()——配置主题中背景等属性——onStart()——onResume()——测量布局绘制显示在界面上。
1、冷启动：当启动应用时，后台没有该应用的进程，这时系统会重新创建一个新的进程分配给该应用，这个启动方式就是冷启动。
2、热启动：当启动应用时，后台已有该应用的进程（例：按back键、在已有进程的情况下，这种启动会从已有的进程中来启动应用，这个方式叫热启动
1、冷启动：冷启动因为系统会重新创建一个新的进程分配给它，所以会先创建和初始化Application类，再创建和初始化MainActivity类（包括一系列的测量、布局、绘制），最后显示在界面上。
2、热启动：热启动因为会从已有的进程中来启动，所以热启动就不会走Application这步了，而是直接走MainActivity（包括一系列的测量、布局、绘制），所以热启动的过程只需要创建和初始化一个MainActivity就行了，而不必创建和初始化Application
黑白屏产生原因：当我们在启动一个应用时，系统会去检查是否已经存在这样一个进程，如果不存在，系统的服务会先检查startActivity 中的intent 的信息，然后在去创建进程，最后启动Acitivy，即冷启动。
而启动出现白黑屏的问题，就是在这段时间内产生的。系统在绘制页面加载布局之前，首先会初始化窗口（Window），而在进行这一步操作时，系统会根据我们设
置的Theme 来指定它的Theme 主题颜色，我们在Style 中的设置就决定了显示的是白屏还是黑屏。
1.Application 优化(懒加载,延时加载)
2.UI效果，背景图
3.fragment的懒加载
4.延时加载
通过上图先把用户-电量这一流程抽象出来，设备的耗电根本原因在于对硬件的使用，耗电越严重说明对硬件使用的越频繁。用户对app频繁使用说明了你用户黏性做的好，我们不能左右，所以我们要在app对硬件调用上做优化来达到节省电量的目的。
先看下移动设备元件耗电大户有哪些：
屏幕是耗电最大元件之一，但是用户要和app交互就要点亮屏幕，有人可能会觉得屏幕的明暗是用户自己根据喜好设定的，我们无可奈何。其实不然，在有些时候是可以通过UI的设计来减少屏幕电能消耗的。
在这之前我们先来看下目前常用手机屏幕材质：LCD和LED(OLED)。
无线网络主要是WIFI和移动运营商网络，通常情况下使用移动网络要比WIFI耗电要多一些。
这三种状态有一个转换流程：
通过上面了解网络连接过程，应该心里有了大概的优化建议。
精简后
①请求一个图片时，客户端提供一个分辨率大小，服务器根据分辨率把裁剪缩放后的图片给客户端返回。也可以使用Android端使用Bitmap.Option自行获取缩放的图片
②使用webp图片。
后面的章节会写一些关于电量检测分析工具的使用。
为了耗电优化干的这些活用户感知不到，但是如果不去优化，肆意使用，那用户就很容易感知到了。
常用的Android性能优化方法：
一、布局优化：
1）尽量减少布局文件的层级。
层级少了，绘制的工作量也就少了，性能自然提高。
2）布局重用 include标签
3）按需加载：使用ViewStub,它继承自View,一种轻量级控件，本身不参与任何的布局和绘制过程。他的layout参数里添加一个替换的布局文件，当它通过setVisibility或者inflate方法加载后，它就会被内部布局替换掉。
二、绘制优化：
基于onDraw会被调用多次，该方法内要避免两类操作：
1）创建新的局部对象，导致大量垃圾对象的产生，从而导致频繁的gc，降低程序的执行效率。
2）不要做耗时操作，抢CPU时间片，造成绘制很卡不流畅。
三、内存泄漏优化：
1）静态变量导致内存泄漏 比较明显
2）单例模式导致的内存泄漏 单例无法被垃圾回收，它持有的任何对象的引用都会导致该对象不会被gc。
3）属性动画导致内存泄漏 无限循环动画，在activity中播放，但是onDestroy时没有停止的话，动画会一直播放下去，view被动画持有，activity又被view持有，导致activity无法被回收。
四、响应速度优化：
1）避免在主线程做耗时操作 包括四大组件，因为四大组件都是运行在主线程的。
2）把一些创建大量对象等的初始化工作放在页面回到前台之后，而不应该放到创建的时候。
五、ListView的优化：
1）使用convertView，走listView子View回收的一套：RecycleBin 机制
主要是维护了两个数组，一个是mActiveViews,当前可见的view,一个是mScrapViews，当前不可见的view。当触摸ListView并向上滑动时，ListView上部的一些OnScreen的View位置上移，并移除了ListView的屏幕范围，此时这些OnScreen的View就变得不可见了，不可见的View叫做OffScreen的View，即这些View已经不在屏幕可见范围内了，也可以叫做ScrapView，Scrap表示废弃的意思，ScrapView的意思是这些OffScreen的View不再处于可以交互的Active状态了。ListView会把那些ScrapView（即OffScreen的View）删除，这样就不用绘制这些本来就不可见的View了，同时，ListView会把这些删除的ScrapView放入到RecycleBin中存起来，就像把暂时无用的资源放到回收站一样。
当ListView的底部需要显示新的View的时候，会从RecycleBin中取出一个ScrapView，将其作为convertView参数传递给Adapter的getView方法，从而达到View复用的目的，这样就不必在Adapter的getView方法中执行LayoutInflater.inflate()方法了。
RecycleBin中有两个重要的View数组，分别是mActiveViews和mScrapViews。这两个数组中所存储的View都是用来复用的，只不过mActiveViews中存储的是OnScreen的View，这些View很有可能被直接复用；而mScrapViews中存储的是OffScreen的View，这些View主要是用来间接复用的。
2）使用ViewHolder避免重复地findViewById
3)快速滑动不适合做大量异步任务，结合滑动监听，等滑动结束之后加载当前显示在屏幕范围的内容。
4）getView中避免做耗时操作，主要针对图片：ImageLoader来处理(原理：三级缓存)
5）对于一个列表，如果刷新数据只是某一个item的数据，可以使用局部刷新，在列表数据量比较大的情况下，节省不少性能开销。
六、Bitmap优化：
1）减少内存开支：图片过大，超过控件需要的大小的情况下，不要直接加载原图，而是对图片进行尺寸压缩，方式是BitmapFactroy.Options 采样，inSampleSize 转成需要的尺寸的图片。
2）减少流量开销：对图片进行质量压缩，再上传服务器。图片有三种存在形式：硬盘上时是file，网络传输时是stream，内存中是stream或bitmap，所谓的质量压缩，它其实只能实现对file的影响，你可以把一个file转成bitmap再转成file，或者直接将一个bitmap转成file时，这个最终的file是被压缩过的，但是中间的bitmap并没有被压缩。bitmap.compress(Bitmap.CompressFormat.PNG,100,bos);
七、线程优化：
使用线程池。为什么要用线程池？
1、从“为每个任务分配一个线程”转换到“在线程池中执行任务”
2、通过重用现有的线程而不是创建新线程，可以处理多个请求在创建销毁过程中产生的巨大开销
3、当使用线程池时，在请求到来时间 ，不用等待系统重新创建新的线程，而是直接复用线程池中的线程，这样可以提高响应性。
4、通过和适当调整线程池的大小 ，可以创建足够多的线程以使处理器能够保持忙碌状态，同时还可以防止过多线程相互竞争资源而使应用程序耗尽内存或者失败。
5、一个App里面所有的任务都放在线程池中执行后，可以统一管理 ，当应用退出时，可以把程序中所有的线程统一关闭，避免了内存和CPU的消耗。
6、如果这个任务是一个循环调度任务，你则必须在这个界面onDetach方法把这个任务给cancel掉，如果是一个普通任务则可cancel，可不cancel，但是最好cancel
7、整个APP的总开关会在应用退出的时间把整个线程池全部关闭。
八、一些性能优化建议：
1）避免创建过多对象，造成频繁的gc
2)不要过多使用枚举，枚举占用的空间比整型大很多
3）字符串的拼接使用StringBuffer、StringBuilder来替代直接使用String,因为使用String会创建多个String对象，参考第一条。
4）适当使用软引用，（弱引用就不太推荐了）
5）使用内存缓存和磁盘缓存。
2个基本原则
既然需要的内存公式已得到，那优化就显而易见了，无非就是减小的这三个参数的值，具体的策略如下：
这里我们将图片分为2种情况来探讨：
图片占用的内存 大小为：
为什么mipmap不在这种情况的考虑范围之内呢？
因为mipmap是Android系统为了避免Launcher Icon变形而添加的资源目录，也就是说，mipmap中的图片不会被缩放。所以Google也不推荐将除Launcher Icon之外的图片放在mipmap目录中。
本地图片通常都是通过Android提供的BitmapFactory来加载的, 这里看几个常用的API：
图片的优化可通过Options参数来实现(Options的介绍可参考 从fresco 看图片优化 ：
inPreferredConfig的取值为Bitmap.Config类型(这里只考虑以下几种情况)，它是一个枚举类型，用来设置每个像素需要的字节数：
1.jpeg和gif
2.webp
3.png8, png24, png32
网络图片通常我们都是使用开源库进行加载, 所以不需要拿到Bitmap再进行缩放或裁剪。
这时可让后台实现网络图片的裁剪，即：根据图片的请求参数返回合适的尺寸，最大也只需要控件的大小即可。
再大也没意义，不仅浪费流量，还占用内存。
如果你的APP中有很多图片，那么可对图片的宽高根据设备的内存情况进行适当的缩小：
尽量为所有分辨率创建资源 资源匹配分辨率 = 减少不必要的缩放，从而提高UI绘制效率
对于一个多图片的APP来说，图片所占内存的优化是一项必不可少的工作。
总的来说，其优化也就是通过 缩放 和指定 Bitmap.Config的值 来实现的，只是不同位置，不同格式的图片有所差异而已。
;utm_source=weixinqun
应用的启动速度缓慢这是很多开发者都遇到的一个问题，比如启动缓慢导致的黑屏，白屏问题，大部分的答案都是做一个透明的主题，或者是做一个Splash界面，但是这并没有从根本上解决这个问题。那么如何从根本上解决这个问题或者做到一定程度的缓解？
1、冷启动：当启动应用时，后台没有该应用的进程，这时系统会首先会创建一个新的进程分配给该应用，这种启动方式就是冷启动。
2、热启动：当启动应用时，后台已有该应用的进程，比如按下home键，这种在已有进程的情况下，这种启动会从已有的进程中来启动应用，这种启动方式叫热启动。
3、温启动 ：当启动应用时，后台已有该应用的进程，但是启动的入口Activity被干掉了，比如按了back键，应用虽然退出了，但是该应用的进程是依然会保留在后台，这种启动方式叫温启动。
adb shell am start -W [PackageName]/[PackageName.MainActivity]
执行成功后将返回三个测量到的时间：
这里面涉及到三个时间，ThisTime、TotalTime 和 WaitTime。WaitTime 是 startActivityAndWait 这个方法的调用耗时，ThisTime 是指调用过程中最后一个 Activity 启动时间到这个 Activity 的 startActivityAndWait 调用结束。TotalTime 是指调用过程中第一个 Activity 的启动时间到最后一个 Activity 的 startActivityAndWait 结束。如果过程中只有一个 Activity ，则 TotalTime 等于 ThisTime。
总结:如果只关心某个应用自身启动耗时，参考TotalTime；如果关心系统启动应用耗时，参考WaitTime；如果关心应用有界面Activity启动耗时，参考ThisTime。
从我们Application开始到首页显示出来，这个过程，我们应该注意一些什么，将这个过程细分一下，会有下面的时间点需要注意。
Application的构造器方法——attachBaseContext()——onCreate()——Activity的构造方法——onCreate()——配置主题中背景等属性——onStart()——onResume()——测量、布局、绘制显示在界面上。
因为上面这些阶段全部都是在主线程中执行的，任何不经意的操作都可能拖慢应用的启动速度。所以我们不应在Application以及Activity的生命周期回调中做任何费时操作，具体指标大概是你在onCreate，onResume，onStart等回调中所花费的总时间最好不要超过400ms，否则用户在桌面点击你的应用图标后，将感觉到明显的卡顿。但是有些 不得以的任务 又必须在UI显示之前执行。所以我们要将 任务 划分优先级。
对于首页渲染完成后，开始加载，或者延迟加载，延迟加载的目的就是界面先显示出来，然后加载，但是你觉得要延迟多久呢？在 Android 的高端机型上,应用的启动是非常快的 , 这时候只需要 Delay 很短的时间就可以了, 但是在低端机型上,应用的启动就没有那么快了,而且现在应用为了兼容旧的机型,往往需要 Delay 较长的时间,这样带来体验上的差异是很明显的。延迟加载有一种方式。
极力推荐用第二种，在窗口完成以后进行加载，这里面的run方法是在onResume之后运行的。关于这种懒加载机制，参考 Android应用启动优化:一种DelayLoad的实现和原理(上篇) ，给出了详细的解释。
通过上面我们知道一种懒加载机制，所以我们可以将Application中和首页的onCreate中的有些耗时任务，放到首页渲染完毕后加载。如何找出这些耗时任务，TraceView就派上用场了，TraceView的用法，移步我的前面的博客 Android性能优化第（六）篇---TraceView 分析图怎么看？
比如在首页的onCreate中我们进行了用户启动上报，这个进行懒加载是不是分分钟减少139毫秒呢？
在比如在Application里面用到了GSON，将String转化成json,我将这个移动到懒加载里面，是不是又减少了100毫秒呢？
在比如，有些Application中做了支付SDK的初始化，用户又不会一打开App就要支付，放在Application中加载干嘛？
此处我们这里举得例子是优化了139毫秒和100毫秒的，其实真正耗时的任务有的有1秒多，都被我优化完了，所以trace图中看不到了，就举个了这两个例子，还有SharedPreferences也是耗时大户，经过检测保存一个boolean变量耗时120+毫秒以上。
利用TraceView可以清楚我们每一个方法的耗时时间，极大的帮助了我们做优化工作。
五、优化思路总结
1、UI渲染优化，去除重复绘制，减少UI重复绘制时间，打开设置中的GPU过度绘制开关，各界面过度绘制不应超过2.5x；也就是打开此调试开关后，界面整体呈现浅色，特别复杂的界面，红色区域也不应该超过全屏幕的四分之一；
2、根据优先级的划分，KoMobileApplication的一些初始化工作能否将任务优先级划分成3,在首页渲染完成后进行加载，比如：PaySDKManager。
3、主线程中的所有SharedPreference能否在非UI线程中进行，SharedPreferences的apply函数需要注意，因为Commit函数会阻塞IO，这个函数虽然执行很快，但是系统会有另外一个线程来负责写操作，当apply频率高的时候，该线程就会比较占用CPU资源。类似的还有统计埋点等，在主线程埋点但异步线程提交，频率高的情况也会出现这样的问题。
4、检查BaseActivity,不恰当的操作会影响所有子Activity的启动。
5、对于首次启动的黑屏问题，对于“黑屏”是否可以设计一个.9图片替换掉，间接减少用户等待时间。
6、对于网络错误界面，友好提示界面，使用ViewStub的方式，减少UI一次性绘制的压力。
7、任务优先级为2，3的，通过下面这种方式进行懒加载的方式
8、Multidex的使用，也是拖慢启动速度的元凶，必须要做优化。后面有空专门写一篇Multidex。
相关链接：
Android应用启动优化:一种DelayLoad的实现和原理(上篇)
Android性能优化之加快应用启动速度
手机淘宝性能优化全记录
Android客户端性能优化（魅族资深工程师毫无保留奉献）
Please accept mybest wishes for your happiness and success !
3）查看进程列表：adb shell "ps"，同时也能获取到应用的UID，方式如下（不需root权限）：
u0_a开头的都是Android的应用进程，Android的应用的UID是从10000开始，到19999结束，可以在Process.java中查看到（FIRST_APPLICATION_UID和LAST_APPLICATION_UID），u0_a后面的数字就是该应用的UID值减去FIRST_APPLICATION_UID所得的值，所以，对于截图这个应用进程，它是u0_a155，按前面的规制，它的UID就是155 + FIRST_APPLICATION_UID = 10155。
VSS - Virtual Set Size 虚拟耗用内存（包含共享库占用的内存）
RSS - Resident Set Size 实际使用物理内存（包含共享库占用的内存）
PSS - Proportional Set Size 实际使用的物理内存（比例分配共享库占用的内存）
USS - Unique Set Size 进程独自占用的物理内存（不包含共享库占用的内存）
一般来说内存占用大小有如下规律：VSS = RSS = PSS = USS
使用 adb shell "dumpsys meminfo -s pakagename | pid"命令，输出结果分以下4部分:
PS：在apk内调用运行获取其他app的内存数据则需要root权限
adb命令：adb shell dumpsys gfxinfo package | pid
正常情况下帧率应该在16.67ms左右，1秒60帧，执行结果如下：
详细计算方法如下：
还有一个命令是: adb shell dumpsys SurfaceFlinger --latency LayerName
其中LayerName在各个不同系统中获取的命令是不一样的
在Android 6系统直接就是SurfaceView
在Android 7系统中可以通过 dumpsys window windows | grep mSurface | grep SurfaceView 然后通过数据截取到
在Android 8系统中可以通过 dumpsys SurfaceFlinger | grep android包名获取到
执行命令结果如下：
计算方法比较简单，一般打印出来的数据是129行（部分机型打印两次257行，但是第一部分是无效数据，取后半部分），取len-2的第一列数据为end_time，取len-128的第一列数据为start_time
fps = 127/((end_time - start_time) / 1000000.0)
至于为啥要取第一列数据，这里不做过多介绍，欢迎参看这两篇文章
老罗的文章SurfaceView原理
Android性能测试之fps获取
至于为啥要处于1000000，因为命令打印出来的是纳秒单位，要转为毫秒进行计算，127就是因为命令一次打印出来127帧的数据而已
有两种方法可以获取
1） adb shell "top -n 5 | grep package | pid" ，第三列就是实时监控的CPU占用率（-n 指定执行次数，不需root权限），这边top命令执行需要2到3s左右，一般可以采用busybox 的top命令执行，效率会快很多
2） adb shell "dumpsys cpuinfo | grep package | pid"
两种方法直接区别在于，top是持续监控状态，而dumpsys cpuinfo获取的实时CPU占用率数据
adb命令：adb shell "dumpsys batterystats package | pid" (Android 5.0后引入)
获取单个应用的耗电量信息，具体返回结果待研究
adb命令：adb shell "dumpsys battery"
出现信息解读：
AC powered：false 是否连接AC（电源）充电线
USB powered：true 是否连接USB（PC或笔记本USB插口）充电
Wireless powered：false 是否使用了无线电源
status: 1 电池状态，2为充电状态，其他为非充电状态
level：58 电量（%）
scale: 100. 电量最大数值
voltage: 3977 当前电压（mV）
current now: -335232. 当前电流（mA）
temperature:355 电池温度，单位为0.1摄氏度
adb 命令：adb shell "dumpsys package | pid | grep UID" [通过ps命令，获取app的UID（安装后唯一且固定）]
adb shell cat /proc/uid_stat/UID/tcp_rcv [cat为查看命令，读取tcp_rcv获取应用接收流量信息（设备重启后清零）]
adb shell cat /proc/uid_stat/UID/tcp_snd [cat为查看命令，读取tcp_snd获取应用发送流量信息（设备重启后清零）]
计算流量消耗步骤：
或者还有一种方式获取应用流量消耗：
首先判断类型：
cat /sys/class/thermal/thermal_zone*/type
只有红框框出来的是有效的
cat /sys/class/thermal/thermal_zone*/temp
获取CPU温度
dumpsys battery | grep temperature 单位0.1摄氏度
获取/proc/stat文件内容（无权限限制）
总的cpu时间片是 total = user+nice+system+idle+iowait+irq+softirq
忙碌时间为 notidle = user+nice+system +iowait+irq+softirq
cpu使用率计算方法为，先取开始的total值和忙碌时间notidle，隔一段时间片，再取一次计算total2，notidle2, cpuuse = (notidle2 – notidle) * 100 / (total2 - total)%
PS:由于Android 8权限收紧，在Android 8系统手机内apk内读取文件内容为空，需要shell权限才可获取文件内容，下同
读/sys/devices/system/cpu/cpuX/cpufreq/scaling_cur_freq文件的值，X不定，看是几核手机，scaling_cur_freq是否存在也不一定，需要判断
至于为啥不取cpuinfo_cur_freq文件的值，原因是android 6,7系统获取的时候，这个文件shell没有读取权限，需要root权限
参考文章：
Android 6,7系统可执行
dumpsys window windows | grep "mCurrentFocus"
执行结果一般为类似：
mCurrentFocus=Window{81caaa5 u0 com.tencent.mobileqq/com.tencent.mobileqq.activity.SplashActivity}
按照一定规则把com.tencent.mobileqq提取出来即可
直接apk内读取文件即可，不需要shell权限（支持到Android8）
Gpu使用率获取：会得到两个值，（前一个/后一个）*100%=使用率
adb shell cat /sys/class/kgsl/kgsl-3d0/gpubusy
Gpu工作频率：
adb shell cat /sys/class/kgsl/kgsl-3d0/gpuclk
adb shell cat /sys/class/kgsl/kgsl-3d0/devfreq/cur_freq
Gpu最大、最小工作频率：
adb shell cat /sys/class/kgsl/kgsl-3d0/devfreq/max_freq
adb shell cat /sys/class/kgsl/kgsl-3d0/devfreq/min_freq
Gpu可用频率
adb shell cat /sys/class/kgsl/kgsl-3d0/gpu_available_frequencies
adb shell cat /sys/class/kgsl/kgsl-3d0/devfreq/available_frequencies
Gpu可用工作模式：
adb shell cat /sys/class/kgsl/kgsl-3d0/devfreq/available_governors
Gpu当前工作模式：
adb shell cat /sys/class/kgsl/kgsl-3d0/devfreq/governor
