杂谈(app优化、android机制系列)
杂谈(Lrucache机制)
杂谈(android基础知识点梳理笔记)
杂谈(http / https Socket)
android机制系列
Handler机制
Handler机制(Looper、Message、MessageQueue)源码查看笔记
事件分发机制
Bindler机制
IPC通信机制(进程间通信)
通讯方式
- intent: 例如打电话
- contentProvider
- 广播
- service: 远程服务,aidl, Messager
理解:IPC-进程间通信(二)AIDL、Bindler机制
进程保活机制
目前主要分三种: 黑色保活、白色保活、灰色保活
黑色保活
不同的app进程,用广播相互唤醒(包括利用系统提供的广播进行唤醒)
三个场景:
- 开机,网络切换、拍照、拍视频时候,利用系统产生的广播唤醒app
- 接入第三方SDK也会唤醒相应的app进程,如微信sdk会唤醒微信,支付宝sdk会唤醒支付宝。由此发散开去,就会直接触发了下面的 场景3
- 假如你手机里装了支付宝、淘宝、天猫、UC等阿里系的app,那么你打开任意一个阿里系的app后,有可能就顺便把其他阿里系的app给唤醒了。(只是拿阿里打个比方,其实BAT系都差不多)
白色保活
启动前台Service
白色保活手段非常简单,就是调用系统api启动一个前台的Service进程,这样会在系统的通知栏生成一个Notification,用来让用户知道有这样一个app在运行着,哪怕当前的app退到了后台。如QQ音乐这样.
灰色保活
利用系统的漏洞启动前台Service
- 对于 API level < 18 :调用startForeground(ID, new Notification()),发送空的Notification ,图标则不会显示。
- 对于 API level >= 18:在需要提优先级的service A启动一个Service,两个服务同时startForeground,且绑定同样的 ID。Stop 掉Service ,这样通知栏图标即被移除。
app优化系列
优化可以分以下几方面:
App启动优化、apk瘦身优化、布局优化、响应优化、内存优化、电池使用优化、网络优化、图片优化
App启动优化(针对冷启动)
- Application的onCreate(特别是第三方SDK初始化),首屏Activity的渲染都不要进行耗时操作,如果有,就可以放到子线程或者IntentService中
- 首屏的优化
2.1 .透明主题化
<style name="AppTheme" parent="Theme.AppCompat.Light.DarkActionBar">
<item name="android:windowFullscreen">true</item>
<item name="android:windowIsTranslucent">true</item>
</style>
// 这一种属于治标不治本,仔细观察的话,还是存在一定的视觉差。
2.2 .设置闪屏图片主题
<style name="AppTheme" parent="Theme.AppCompat.Light.DarkActionBar">
<item name="android:windowBackground">@mipmap/launch</item> //闪屏页图片
<item name="android:windowFullscreen">true</item>
<item name="android:windowContentOverlay">@null</item>
</style>
//启动 Activity 的 Theme中设置闪屏页图片,这样启动窗口的图片就会是闪屏页图片,而不是白屏。
这种方式并没有真正的加速应用进程的启动速度,而只是通过用户视觉效果带来的优化体验。
2.3 . 借助于layer-list
<style name="mcc_start_activity_theme" parent="Theme.AppCompat.Light.NoActionBar">
<item name="android:windowBackground">@drawable/bg</item>
<item name="android:windowFullscreen">true</item>
</style>
也可以利用下面这种方式做一个组合动画(最起码看着像,嘿嘿)。
<?xml version="1.0" encoding="utf-8"?>
<layer-list xmlns:android="http://schemas.android.com/apk/res/android">
<!--<item android:drawable="@color/white" />-->
<!--因为使用最长图做适配,所以这里不会有需要填充的地方,所以上面注释掉-->
<item>
<bitmap
android:gravity="center"
android:src="@mipmap/bg_splash" />
</item>
</layer-list>
2.4 . MainActivity作为闪屏
a.加载Mainactivity时优先加载一个SplashView(网上有开源库)。
b.借助于Fragment,闪屏结束时移除。Android性能优化系列之App启动优化
c.图片+透明主题的方式:Xml引用时是盖到其他布局上面的。这样不好的就是闪屏时间会长些
apk常用瘦身优化
布局优化
优化方向:
-
减少层级
尽量不要过于复杂的嵌套。可以使用
<merge>,<ViewStub>
标签 -
尽可能少的引用图片
2.1.一些图片可以用shape代替
2.2.如果像微信那种底部Tab,可以用Tint着色器
虽然说可以实现背景和前景变色,但是两个selector还是不能少的:
- shape_msg_selecter
<?xml version="1.0" encoding="utf-8"?>
<selector xmlns:android="http://schemas.android.com/apk/res/android">
<item android:drawable="@drawable/message" android:state_pressed="true" />
<item android:drawable="@drawable/message" />
</selector>
- color_selector
颜色切换selector,在color目录下创建color_selector(如果没有这个目录创建一个):
<?xml version="1.0" encoding="utf-8"?>
<selector xmlns:android="http://schemas.android.com/apk/res/android">
<item android:color="@color/colorAccent" android:state_pressed="true" />
<item android:color="@color/colorPrimary" />
</selector>
- 使用
<ImageView
android:src="@drawable/shape_msg_selecter"
android:layout_width="wrap_content"
android:tint="@color/color_selector"
android:layout_height="wrap_content" />
扩展知识点:
LinearLayout、RelativeLayout、FrameLayout的特性及对比,并介绍使用场景
- RelativeLayout会让子View调用2次onMeasure,LinearLayout 在有weight时。也会调用子View2次onMeasure
- RelativeLayout的子View假设高度和RelativeLayout不同,则会引发效率问题,当子View非常复杂时,这个问题会更加严重。
- 在不影响层级深度的情况下,使用LinearLayout和FrameLayout而不是RelativeLayout。
- 能用两层LinearLayout,尽量用一个RelativeLayout,在时间上此时RelativeLayout耗时更小。
另外LinearLayout慎用layout_weight,也将会添加一倍耗时操作。
响应优化
android屏幕的绘制:每16ms,系统会发出VSYNC信号重绘我们的界面(Activity)。
页面 卡顿/掉帧 的原因:
- 过于复杂的布局.
- UI线程的复杂运算
- 频繁的GC,导致频繁GC有两个原因:
3.1、内存抖动, 即大量的对象被创建又在短时间内马上被释放.
3.2、瞬间产生大量的对象会严重占用内存区域。 - 计算性问题编码不正确吃cpu,导致ui卡顿。
这个16ms包括:CPU和GPU执行所消耗的时间+代码逻辑(我们所写的耗时逻辑)
我们最终的优化目标就是要控制在16ms内
内存优化
可以借助于第三方的一些插件或工具来分析:
- android studio自带的Monitor
- traceview
- leakcanary
- MAT(Memory Analyzer tool)
电池使用优化
-
优化网络请求
-
定位中使用GPS, 请记得及时关闭
工具:Battery Historian
网络优化
网络链接的影响:流量、电量、用户等待
可借助于android studio自带的Network Monitor检测
-
API设计:App与Server之间的API设计要考虑网络请求的频次, 资源的状态等. 以便App可以以较少的请求来完成业务需求和界面的展示.
-
Gzip压缩:使用Gzip来压缩request和response, 减少传输数据量, 从而减少流量消耗.
-
图片的Size:可以在获取图片时告知服务器需要的图片的宽高, 以便服务器给出合适的图片, 避免浪费.
-
网络缓存:适当的缓存, 既可以让我们的应用看起来更快, 也能避免一些不必要的流量消耗.
图片优化
- 对图片本身进行操作。尽量不要使用setImageBitmap、setImageResource、BitmapFactory.decodeResource来设置一张大图,因为这些方法在完成decode后,
最终都是通过java层的createBitmap来完成的,需要消耗更多内存. - 尺寸压缩:改变的是像素
- 质量压缩:图片转换成File文件后在压缩文件,再次读取转换为图片时,所占的内存不会因此减少的。还是会容易导致内存泄漏的
- 利用一些开源的so库进行压缩
- 某些设计大图:利用tinypng有损压缩
- 不用的图片记得调用图片的recycle()方法