编程知识 cdmana.com

【填坑往事】Android手机锁屏人脸解锁优化过程实录

背景

       写这篇文章,主要是为了以后面试方便。因为我简历上写了,上一份工作的最大亮点是将人脸解锁的速度由1200ms优化到了600ms,所以这些内容已经回答无数遍了。但每次总觉得回答的不完整,或者说总感觉可以发挥得更好,于是这里做一些简单的总结性的记录。

       我2018年4月份进入到某手机公司,在其中工作了两年多的时间,这期间主要负责人脸解锁的功能。人脸解锁的速度优化,是入职开始的一个很重要的任务,前前后后持续了很长时间。做优化前,首先是明确目标,我接手时人脸解锁的速度是1200ms左右,而我们是参照的精品机Oppo、vivo、小米、华为等主流机型解锁速度大约在400~700ms不等,所以这也就成了我优化的目标。

       整个人脸解锁的架构图如下所示:

 

     优化的基本手段是将整个启动过程拆分为多个阶段,然后针对每一个阶段进行优化,优化流程逻辑或者采用更高效技术,归纳起来主要有如下这些步骤:

 

1、从按power键到SystemUI中的KeyguardService

       优化前,使用的是广播方式,但我们知道使用广播方式来实现IPC性能是非常差的,速度很慢。优化后,采用AIDL取代广播方式,提升40ms左右。

       有些面试官会问:为什么使用AIDL比使用广播速度更快?

       网上没有搜到比较权威的答案,我自己整理了一下,我个人认为有如下几个原因:(1)广播的发送和接收过程中,有多次Binder实现的IPC。广播实现跨进程通信的方式也通过Binder实现的,这一点和AIDL一样。但是广播在注册时会将IntentFilter和Receiver信息通过Binder方式注册到AMS中,这里面会有很多封装、过滤等操作,将action,Receiver,Context、IntentFilter进行关联。发送者发送消息时会将action等信息封装到Intent中,然后通过Binder方式与AMS通信,将Intent等信息传入AMS中。AMS中经过匹配action,找到对应的注册者和接收者,然后再通过Binder方式和Receiver通信,这样就完成了一次广播的发送和接收,其中发生了多次Binder。而AIDL方式就过程就简单很多,直接在发送者和接收者之间一次Binder即可。广播是四大组件之一,在使用过程中会存在很多中间的处理过程,比如对Intent等的中间处理等。(2)广播有前台广播和后台广播之分,默认是后台广播。系统的内部存在无数的广播,由于系统资源有限,会优先处理一些非常重要的广播,这就使得默认情况下的广播会低优先级处理这些后台广播。同样也由于系统资源有限,所以不能随意将广播设置为前台广播。(3)根据注册的方式不同,广播有静态注册和动态注册的区分,如果是静态注册,就是并行广播,如果有多个地方注册了该广播,会根据注册的时间来依次处理广播事件。这一点不同于串行广播,动态注册是串行广播。

 

2、SystemUI与FaceId Service长期保持连接。

       SystemUI与FaceId是通过AIDL来通信的, 优化前,SytemUI每次和FaceId通信完毕后都会断开连接,这样就导致在下次使用人脸解锁时,必须重新建立连接,会有一定程度的延迟。优化的方法就是让SystemUI和FaceId保持长久的连接。当然这一点缩短的时间并不太多。

 

3、使用Camera2 API代替Camera1 API

      系统提供了Camera API-2,是官方对API-1的优化,性能更稳定,使用起来也更加方便。官方并没有明确说明使用API-2会比API-1更加快速,但实际开发中发现,使用API-2替换后,整个开启预览和开启相机的过程缩短了150ms左右。

 

4、提高相机帧率,尽量减少人脸解锁算法的等待时间

       人脸解锁的核心流程是:SDK会预先录入使用者的人脸数据,在需要解锁时,相机通过摄像头以一定的帧率获取图像信息,通过API中的回调将图像信息传递给SDK。SDK中封装了人脸匹配算法,该算法会将相机传递的图像信息和预存的人脸数据进行匹配,并根据匹配结果返回对应的值,比如环境太黑、检测不到人脸、和预存的不是同一个人、匹配成功等各种匹配结果,都有一个数字与之对应。

       SDK在匹配时,如果成功,一次匹配的时间大约是30ms,如果是失败的匹配,一次匹配大约50ms~100ms不等(在匹配过程中,如果有新的图像数据传递过来,会被过滤掉)。而平常使用时常常不能一次匹配成功,本次匹配失败后,很快从相机拿下一笔图像来匹配,直到在指定时间(设置的是5s)内匹配成功。为了能够让本次匹配失败后很快拿到下一笔图像,这就要求相机提高获取图像的帧率。这一点督促相机团队的同事,修改相机参数,综合考虑之下,取了15ms每帧的频率。

 

5、合理设置相机的初始曝光值

       相机一般会默认设置一个曝光值,在不同环境中使用时,再根据周围环境来调整,以适应周围的光照环境。如果默认的曝光值设置不合适,会导致刚开启相机时,得到的前几笔图像要么太暗,要么太亮,需要自我调整达到一个高质量的状态。

       在优化前,由于对默认的曝光值设置不合理,导致开启人脸解锁功能时,即便是很正常的光照环境下,面对正确的人脸时,前面多次匹配都因为图像质量太差,导致匹配失败。每次匹配失败都会浪费50~100ms的时间,这就导致每次解锁成功前,都会浪费300ms甚至更多的时间在相机自身调整曝光值上。

       在后面做优化时,通过大量的测试和分析log,发现了每次匹配都不能一次成功的问题,然后将相机提供的数据转为图片,才发现图像的质量问题。后来和相机团队的同事,共同调试,得到一个比较合适的初始曝光值,解决了这个问题。

 

6、在启动人脸解锁时启动CPU拉频,并合理处理速度和省电之间的关系

       人脸解锁算法执行是一个高密集计算的操作,为了提高解锁的速度,优化过程中采用了调度CPU最大核,并提高CPU频率的做法,使得匹配的速度有所提高。

       调度CPU最大核并提高CPU频率,是一个非常耗电的过程。为了更好地平衡匹配速度和省电,这里又做了一个设计:人脸解锁超时时间设置的是5s,但实际上,如果周围环境正常,且是正确的人脸,大部分场景下都能在前1s内解锁完成,只有在环境异常或者非正确人脸的时候,才会在1s后还需要匹配,此种场景能解锁的概率就比较小了。所以这里的处理方法是,在人脸解锁的前1s调度CPU最大核,如果还没有解锁,则将CPU调回正常,而不是一直都使用CPU大核和高频。

 

7、合理使用并行代替串行

       人脸匹配成功后,就可以立刻走解锁流程,并调用相机的关闭方法,而关闭相机需要150ms的时间。优化前原开发者采用的是串行的方式,也就是在人脸匹配完成后,在同一个线程中调用了关闭相机操作,相机关闭后才走锁屏界面消失的流程。这个优化点应该是很明显的,关闭相机的操作放在单独的一个线程去执行就可以了,这样一来就能够再优化150ms的时间。至于原开发者为什么要采用串行,不得而知。

    

       当然,优化过程还有其他很多的细节,比如一些流程的时间复杂度优化,非必要流程的精简,要求sdk人脸匹配算法做优化,新手机中使用了性能更好的CPU、相机硬件等。

       

版权声明
本文为[宋者为王]所创,转载请带上原文链接,感谢
https://www.cnblogs.com/andy-songwei/p/13956320.html

Scroll to Top