189 8069 5689
应用的启动速度缓慢这是很多开发者都遇到的一个问题，比如启动缓慢导致的黑屏，白屏问题，大部分的答案都是做一个透明的主题，或者是做一个Splash界面，但是这并没有从根本上解决这个问题。那么如何从根本上解决这个问题或者做到一定程度的缓解？
栾川ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景，ssl证书未来市场广阔！成为创新互联的ssl证书销售渠道，可以享受市场价格4-6折优惠！如果有意向欢迎电话联系或者加微信：18980820575（备注：SSL证书合作）期待与您的合作！
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 !
当点击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.延时加载
TextView 是Android中最常用的控件，在这里记录下TextView 的用法；
在Android中可以使用系统自带的4种字体：
在XML中使用 android:typeface="normal" 进行设置
将字体文件放到main/assets/fonts目录下，使用Asset读取字体后进行设置
使用 android:drawableLeft="@mipmap/ic_launcher" 可以设置一张图片显示在文字的上下左右，减少布局层级
使用Span能够在一段TextView中设置不同颜色的字体，链接，图片等内容
使用ClickableSpan 能够设置一段文字的点击事件
创建自己的MyClickableSpan：
之后使用SpannableStringBuilder来创建字符串，并使用setSpan来为字符串的一部分设置Span对象
其中setSpan()方法的最后一个参数标识有以下常量，这些常量标识着在 对SpannableStringBuilder进行insert时 添加的字符适用的规则：
Spanned.SPAN_EXCLUSIVE_EXCLUSIVE
Spanned.SPAN_EXCLUSIVE_INCLUSIVE
Spanned.SPAN_INCLUSIVE_EXCLUSIVE
Spanned.SPAN_INCLUSIVE_INCLUSIVE
前一个 EXCLUSIVE / INCLUSIVE 标识着在设置了Span的一段字符之前（紧挨着）插入字符时，被不被包含到Span范围中， EXCLUSIVE 表示包含， INCLUSIVE 表示不包含；
第二个 EXCLUSIVE / INCLUSIVE 同理表示插入这段字符之后的效果；
ImageSpan用于在TextView中插入图片，可以用来实现图文混排
使用方法：
这样实现的效果是文字与图片底部进行对齐，如果需要图片中线与文字中线对其，需要自己重写ImageSpan
Android 中的TextView中存在着很多EditText中的特性，在setText()方法中会涉及到很多Span相关的操作，比如设置TextWatcher，重新构造Spannable等操作，在我们仅仅显示静态文本的时候这些操作都是没有必要的（通过使用普通的TextView进行Debug来验证普通的TextView的确是Span的）；
在大量显示静态文本的时候就可以通过StaticLayout来计算出TextView的布局信息，这项工作可以放到非UI线程来进行，能够减少在setText()的时候UI线程的耗时，达到优化TextView性能的目的；
StaticLayout是TextView中用于显示多行静态文本的Layout，也是能够支持SpannableString的，只是不能在Span变化之后重新Layout，所以在大部分场景下已经适用；
通过这个自定义的View来显示Text，在onDraw()的时候直接使用layout来进行绘制，而设置需要显示的文本则直接使用setLayout()来实现
使用下面给出的参考链接中的测试Demo在 ZTE A2017 Android7.1.1 高通820设备上，普通TextView在ListView中连续滚动的帧数是55帧，使用StaticLayout的结果为60帧
可以作为在APP使用CPU资源较多的情况下的优化手段
参考链接： TextView预渲染研究
在Android中，TextView的测量消耗了大量的时间，Android P中提供了PrecomputedText能够将测量这个过程放到后台来执行，减轻对于UI线程的卡顿；
非Android P时，使用AppCompatTextView控件，使用setTextFeature()方法来将文本的measure过程放到其他线程来执行，而不是直接将text应用于TextView；
在调用了这个方法之后如果对TextView进行边距，文字大小等的设置都将会报错；
Prefetch Text Layout in RecyclerView
PrecomputedTextCompat
在ListView中仅替换设置Text的方法时未测试出性能与普通方法有什么优势，猜测是ListView没有在getView和显示之间预留时间，
测试项目地址：
通过上图先把用户-电量这一流程抽象出来，设备的耗电根本原因在于对硬件的使用，耗电越严重说明对硬件使用的越频繁。用户对app频繁使用说明了你用户黏性做的好，我们不能左右，所以我们要在app对硬件调用上做优化来达到节省电量的目的。
先看下移动设备元件耗电大户有哪些：
屏幕是耗电最大元件之一，但是用户要和app交互就要点亮屏幕，有人可能会觉得屏幕的明暗是用户自己根据喜好设定的，我们无可奈何。其实不然，在有些时候是可以通过UI的设计来减少屏幕电能消耗的。
在这之前我们先来看下目前常用手机屏幕材质：LCD和LED(OLED)。
无线网络主要是WIFI和移动运营商网络，通常情况下使用移动网络要比WIFI耗电要多一些。
这三种状态有一个转换流程：
通过上面了解网络连接过程，应该心里有了大概的优化建议。
精简后
①请求一个图片时，客户端提供一个分辨率大小，服务器根据分辨率把裁剪缩放后的图片给客户端返回。也可以使用Android端使用Bitmap.Option自行获取缩放的图片
②使用webp图片。
后面的章节会写一些关于电量检测分析工具的使用。
为了耗电优化干的这些活用户感知不到，但是如果不去优化，肆意使用，那用户就很容易感知到了。
即 为什么要优化图片Bitmap资源，具体如下图：
本文将从 以下方面优化图片Bitmap资源的使用 内存管理
下面，我将详细讲解每个优化方向的具体优化方案
至此，关于图片资源Bitmap的使用优化讲解完毕
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