Android手机开关机、重启时间优化
本篇文章主要介绍 Android
开发中开关机 重启时间 部分知识点,通过阅读本篇文章,您将收获以下内容:
zygote,预加载class、resources
开机动画进程 bootanimation
SystemServer.java 代码逻辑
非必要服务请放在system_server进程外启动
kernel init 时间过长
排查驱动设备初始化是否完成
apk dex2oat时间过长
尽量少把APP设置为persist
定频定核,调高CPU频率,会带来一定的功耗
PackageManagerService 扫描apk 优化
关机时间优化
优化第三apk 后台服务
谷歌官方参考资料
欢迎关注微信公众号:程序员Android
微信公众号:ProgramAndroid
我们不是牛逼的程序员,我们只是程序开发中的垫脚石。
开机性能优化
开机性能是用功能和其它因素多方面平衡的结果,片面追求单方面的性能没有太大意义;
1.zygote,预加载class、resources
zygote预加载多了,会影响开机时间,所以需要优化预加载内容。
MTK 平台 开机时间信息保存在 /proc/bootprof
下,或mtklog/mobilelog/Aplog
下。
开机时间信息
<< /proc/bootprof >>:
----------------------------------------0 BOOT PROF (unit:msec)
---------------------------------------- 1612 : preloader 1915 : lk (Start->Show logo: 981)
---------------------------------------- 34.132076 : ON 88.563768 : 1-swapper/0 : initcall: of_init 17.915384ms 131.311461 : 1-swapper/0
......
38411.551244 : 325-Binder:300_1 : BOOT_Animation:END
38411.595629 : OFF
----------------------------------------
================ END of FILE ===============
预加载Class
因为少加载类会影响APP启动速度,开机过程会涉及到APP启动,此地没有优化空间;/frameworks/base/config/preloaded-classes
预加载Class
预加载资源
/frameworks/base/core/res/
下的资源文件会被打包成 framework-res.apk
。
2.开机动画进程 bootanimation
开机动画保存在手机system/media
下,开机动画要求图片越少越好,不宜占用过大的内存空间,否则系统会浪费在加载开机动画图片上,这样导致开机时间慢,就不好了。
两种开机动画
1.播放开机声音
开机动画需要等待开机铃声播放完,动画才能退出,开机才能完成;所以开机铃声的mp3文件不能过长,最好不要超过system_server
启动时间;
system_server 启动时间
23340.916362 : 727-system_server : Android:SysServerInit_START
24217.928364 : 727-system_server : Android:PackageManagerService_Start
....
31891.278382 : 727-system_server : Android:SysServerInit_END
2.不播放开机声音
不播放开机声音,不会影响开机时间,bootanimation.zip中图片越少越好。
3. SystemServer.java 代码逻辑
不建议更改SystemServer
代码逻辑,修改风险较大,除非对开机速度有特别严苛的要求才修改:/frameworks/base/services/java/com/android/server/SystemServer.java
比如:DropBoxManagerService
PinnerService
其他Service可以挨个排查;
4. 非必要服务请放在system_server进程外启动
system_server
特定的服务导致开机变慢,比如:指纹系统;system_server
进程外启动;
5. kernel init 时间过长
kernel init
需要先看一下客户的版本上init.rc
文件相对Driveronly
版本是否有添加新的init
,这些是否都是必须添加的。
在uartlog
中,需要查关键字 cut here ,找到在kernel init
过程中,频繁打出的这些call stack
,看这些call stack
,排查一下贵司所客制化的点。
6. 排查驱动设备初始化是否完成
在uartlog
中排查驱动设备初始化是否有完成或延时较长。
比如之前驱动代码异常问题,耗时8s
,这个有很大优化空间。
遇到问题举例
7. apk dex2oat时间过长
如果是刷机后第一次因为对apk进行dex2oat
导致的开机慢:
bootprof
文件中包含PMS:performDexOpt,说明在编译时没有打开dex2oat
选项;/device
和/build
目录下,修改下面的宏,具体下面3个宏的位置可以在代码中搜索一下:
build/core/dex_preopt.mk
WITH_DEXPREOPT := true WITH_DEXPREOPT_PIC := true
DONT_DEXPREOPT_PREBUILTS := false //或者注释掉
Log 举例:
67720.299622 : 1211-system_server : PMS:performDexOpt:com.mediatek.ims
67727.107469 : 1211-system_server : PMS:performDexOpt:com.google.android.ext.services
67732.884007 : 1211-system_server : PMS:performDexOpt:com.android.providers.telephony
67740.281545 : 1211-system_server : PMS:performDexOpt:com.micromaxinfo.coreupdater
67750.098776 : 1211-system_server : PMS:performDexOpt:com.touchtype.swiftkey
82794.094658 : 1211-system_server : PMS:performDexOpt:com.mediatek.fwk.plugin
82798.845812 : 1211-system_server :
.......
116880.481509 : 1211-system_server : PMS:performDexOpt:com.android.keychain
116884.277509 : 1211-system_server : PMS:performDexOpt:com.android.chrome
116901.748740 : 1211-system_server : PMS:performDexOpt:com.android.gallery3d
116909.980047 : 1211-system_server :
126659.802071 : 1211-system_server : PMS:performDexOpt:com.google.android.syncadapters.calendar
126665.240840 : 1211-system_server : PMS:performDexOpt:com.android.managedpr
134272.287243 : 1211-system_server : PMS:performDexOpt:com.jio.adc.embedded
134581.037782 : 1211-system_server : PMS:performDexOpt:com.android.wallpaperbackup
134583.934936 : 1211-system_server : PMS:performDexOpt:com.android.providers.blockednumber
134589.891166 : 1211-system_server :
137465.599866 : 1211-system_server : PMS:performDexOpt:com.android.captiveportallogin
8. 尽量少把APP设置为persist
优化每一个有源码的
persist
APP;使他们启动尽可能快;
com.android.systemui(PersistAP)
com.mediatek.ims(PersistAP)
com.android.phone(PersistAP)
com.android.settings
精简apk包
(1)删除没有用到的,图片、资源文件、没有用到的 jar包文件、不需要使用的so文件;drawable-xxhdpi
中的资源,那么可以在drawable
包 重复的资源可以直接删除;values-da、values-fa
这样的多语言支持资源都 可以删除;
App 的
onCreate
方法中不要用耗时的代码片段。修改app的启动模式
通过修改--compiler-filter
为 speed、quick、speed-profile
来提高apk
的启动速度;speed 模式优化的类较多,这时优化后的vdex、odex
的文件较大,应用启动过程包括映射apk
文件的过程,文件偏大导致有一定的时间损耗;speed
模式优化后,Java
类执行更快;所以这个需要针对具体的应用多次验证,没有普适性;
9. 定频定核,调高CPU频率,会带来一定的功耗
以6763
的O1版本代码为例:/system/core/rootdir/init.rc
on early-init#mtk beginwrite /proc/ppm/policy/ut_fix_core_num "4 4"write /proc/ppm/policy/ut_fix_freq_idx "0 0"#mtk endon property:sys.boot_completed=1
bootchart stop#mtk beginwrite /proc/ppm/policy/ut_fix_core_num "-1 -1"write /proc/ppm/policy/ut_fix_freq_idx "-1 -1"#mtk end
10.PackageManagerService 扫描apk 优化
scanDirTracedLI
(1)减少预置APP
的数量(对开机速度会有较为明显的提升);apk
包;scan
分区里面的apk
并不一定能充分使用IO
资源,尝试改为多线程异步scan;(部分手机厂商有做出此种修改,且效果较为明显,但修改需谨慎);apk
包、有重复功能的apk
移除(比如:我司代码默认包含 有计算器APP
,如果贵司有自己单独的计算器APP
则可以移除我司apk
),这样既可以使系统有更大的剩余存储空间又可以减少scan
的时间,加快开机;
11.关机时间优化
以MTK6763
为例:[ro.mediatek.version.branch]: [alps-mp-o1.mp1]
1s
(贵司可以自己测试找一个最优值),然后关机音频控制在1s
(否则音频播放不完整),或者关机时不播放铃声,把这个值设置为10ms
;
/frameworks/base/services/core/java/com/android/server/power/ShutdownThread.java
149 // Shutdown Animation150 private static final int MIN_SHUTDOWN_ANIMATION_PLAY_TIME = 1 * 1000;
12.优化第三apk 后台服务
关机时间长的另外一个原因有可能是后台应用乱跑;APP
,在后台都在积极抢占CPU
,在手机系统资源紧张时对系统的性能影响是非常大的;
手机使用过程中,适当的限制后台进程的数量,会一定程度提高系统性能和更快的关机;
还有些APP
一直保持有1
个像素的悬浮窗,使自己一直为可见进程,可见进程能更多的占用系统资源,手机系统可以增加悬浮窗的权限管控开关只有获取到了才允许悬浮,可以更加合理的非配系统资源。
13.谷歌官方参考资料
谷歌官方启动时间优化链接
至此,本篇已结束,如有不对的地方,欢迎您的建议与指正。期待您的关注,
如有侵权,请联系小编,小编对此深感抱歉,同时小编会立即停止侵权行为。
欢迎关注微信公众号:程序员Android
微信公众号:ProgramAndroid
我们不是牛逼的程序员,我们只是程序开发中的垫脚石。
点击阅读原文,获取更多福利