现在的Android
手机真的是越来越高级了,作者有幸买了一台EVA限定版手机,高兴坏了,第一次用90Hz
的高刷新率屏幕手机,桌面、系统App、微信就跟吃了德芙一样,纵享丝滑。
但是,but,然而,我打开QQ
,不对啊,说好的德芙呢,再试试其他App,简直是惨不忍睹,都没有适配高刷新率的屏幕,依然60Hz
我行我素。那我的90Hz屏幕还有个什么用?
按道理说,高刷屏出来也不是一天两天了,难道是没有Api
?一阵抽搐之后,瘫软在椅子上,打开某百毒搜索之,发现抄袭成灾的CSDN
都没人写,简直是令人绝望。
作为有责任心的码农,怎么就能如此放弃,这块德芙,我一定要吃。
那咱就上Google
看看文档吧。
在翻阅到WindowManager.LayoutParams的文档时候,发现了端倪,有一个Api
引起了注意:
preferredRefreshRate
// 注释: API 23 之后过期,使用preferredDisplayModeId代替
再看看文档说明,第一句话就是:
The preferred refresh rate for the window.
// 翻译成人话:window的首选刷新率。
行了,应该就是你了。来吧开弄。
直接上代码,超级少
class MyActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
/*
M 是 6.0,6.0修改了新的api,并且就已经支持修改window的刷新率了。
但是6.0那会儿,也没什么手机支持高刷新率吧,所以也没什么人注意它。
我更倾向于直接判断 O,也就是 Android 8.0,我觉得这个时候支持高刷新率的手机已经开始了。
*/
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
// 获取系统window支持的模式
val modes = window.windowManager.defaultDisplay.supportedModes
// 对获取的模式,基于刷新率的大小进行排序,从小到大排序
modes.sortBy {
it.refreshRate
}
window.let {
val lp = it.attributes
// 取出最大的那一个刷新率,直接设置给window
lp.preferredDisplayModeId = modes.last().modeId
it.attributes = lp
}
}
super.onCreate(savedInstanceState)
setContentView(viewBinding.root)
}
}
完事了,有高刷屏手机的同学,可以试试,无痛接入项目!无痛哦。直接放到BaseActivity
里就好了。
我这里比较粗暴,没有进行分辨率的筛选,一般情况下,分辨率我们是不进行修改的。而且我这里直接是拿出了系统支持的最大刷新率,但是这样不太友好,例如,有的手机是120Hz,那这里就是设置的120,但是对于我们App来说,90就足够了,所以需要更细致控制的,请自己再写判断逻辑
想快速体验的,可以下载我的图片选择器的demo试试,也可以查看里面[LBaseActivity]的代码LPhotoPicker
提醒事项
在之前传统的情况下,我们根深蒂固的思想里是这样的:“只要每一帧的绘制都在16ms以内,就能保持60帧不卡顿”,然而现在的情况是,在90帧
的情况下,每一帧的绘制不能超过 11ms。如果要支持到 120帧
,其绘制时间将进一步压缩。
咳咳,那么布局优化的基本功派上用场了,不会布局优化的,还不赶紧去学!某bai毒那么多教程,我不再赘述了。
这也是为什么我建议判断系统的版本的时候,在8.0
或者9.0
以上的原因:
1、系统在8.0
或者9.0
2、支持高刷新率屏幕
满足以上两点的,手机起码都是64位cpu,性能都不差,只要你的布局不是无脑堆砌,基本上都不会有卡顿问题。
收工收工!
本文使用 mdnice 排版