启动优化的理由:
所谓的8秒定理,在移动和PC端,当用户对于响应的页面超过8秒,基本已经给当前应用否定的态度,已经将产品的竞争能力降到了最低。
接起来了解下优化的方向:
一、分析优化方向
app启动的三种状态
冷启动
1.加载并启动应用 2.在启动后立即显示应用的空白页面 3.创建应用进程
热启动
耗时最短,将activity从后台带到前台
温启动
耗时最长,重走了Activity的生命周期
从应用的启动状态中,我们可以分析得出,剥除系统本身的任务动作外(这部分我们是无法进行操作修
改的),其实我们的启动优化方向主要就是:
Application
和
Activity
的生命周期
、主视图的布局优化
二、相关数据测量
可以针对MainActivity进行侧重优化
启动优化技巧
闪屏,业务,UI,进程
1.闪屏
<!-- 新建layer-list的xml文件 -->
<layer-list xmlns:android="http://schemas.android.com/apk/res/android" android:opacity="opaque">
<item android:drawable="@android:color/white"/>
<item>
<bitmap //这里是我们想要展示的开屏图片 android:src="@mipmap/longkong_splash" android:gravity="fill"/>
</item>
</layer-list>
然后新建Theme:
<style>
<item name="android:windowBackground">@drawable/lanucher</item>
<item name="windowActionBar">false</item>
<item name="android:windowNoTitle">true</item>
<item name="windowNoTitle">true</item>
</style>
在我们的启动页设置这个Theme:
<activity android:name=".business.MainActivity" android:configChanges="keyboardHidden|orientation|screenSize" android:hardwareAccelerated="true" //设置theme android:theme="@style/ThemeActivitySplash" android:windowSoftInputMode="stateUnspecified">
<intent-filter> <action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity
记得在页面
onCreat
中切换回我们原用的
Theme:
@Override protected void onCreate(@Nullable Bundle savedInstanceState) { setTheme(R.style.ThemeActivity);
super.onCreate(savedInstanceState);
}
2
、业务优化
梳理我们的模块,对有哪些必要展示,那些可以不加载,那些可以延迟加载
可以不加载的指多余的功能。延迟加载比如调用扫一扫,地图定位,再触发事件的时候对其初始化操作,也可以再用户数据加载结束进行操作
Looper.myQueue().addIdleHandler(new MessageQueue.IdleHandler() {
@Override public boolean queueIdle() {
//执行延迟加载的代码 return false;
}
});
IdleHandler
的运行机制是:只有在
CPU
空闲的时候才会去执行操作,这样就不会造成首页用户操
作时卡顿的情况。
3
、线程优化
线程优化其实就是合理利用
CPU
的核心数,将几个耗时的任务进行并发处理,可以极大减少总的运行时间。
线程优化需要注意几点:
1.合理控制线程的数量:每台机子的核心数都不同,如果我们线程开得太多,可能会相互竞争
CPU
资源,除了要用线程池进行统一管理外,设置合适的线程数也很重要。
2.任务的依赖关系:有些任务可能是需要前一个任务执行完后再进行操作,如果在线程优化中,没有处理好这个相关,可能会造成空转,如下图:
4、UI优化
UI
优化主要是对我们的视图布局进行优化,尽量减少绘制时间,对于一些界面复杂的项目,效果也是非常的显著
在
Android
中系统对
View
进行测量、布局和绘制时,都是通过对
View
树的遍历来进行操作的。如果一个 View
树的高度太高就会严重影响测量、布局和绘制的速度。
Google
也在其
API
文档中建议
View高度不宜超过10
层。
尽可能少用 wrap_content
其他优化
除了上面的优化之处,还是有很多其他的优化技巧。比如根据我们具体的业务,还可以做一些类加载的优化,I/O
上的优化,
GC
的优化,磁盘文件的优化,还可以通过保活来达到快速重启,甚至还有一些CPU锁频的黑科技。