Android N DisplayManager服务解析(二)

本文涉及的产品
数据管理 DMS,安全协同 3个实例 3个月
推荐场景:
学生管理系统数据库
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
全局流量管理 GTM,标准版 1个月
简介: 版权声明:转载请联系本人,感谢配合!本站地址:http://blog.csdn.net/nomasp https://blog.csdn.net/NoMasp/article/details/77430743 PowerManagerService:负责协调设备上电源管理功能的服务。
版权声明:转载请联系本人,感谢配合!本站地址:http://blog.csdn.net/nomasp https://blog.csdn.net/NoMasp/article/details/77430743

PowerManagerService:负责协调设备上电源管理功能的服务。

DisplayPowerController:控制屏幕显示相关的电源状态。处理距离传感器、光线传感器和屏幕关闭时的动画等。这个组件在其他电源管理服务中是独立的,也就是说它不会共享任何状态,而只是通过异步回调来通知其他电源管理模块某些状态已经改变。这个类在内部做的一切都是被序列化的,尽管它可能被来自外部的其他线程访问。

DisplayManagerService:它管理显示的整个生命周期,决定怎样基于当前的物理显示设备来配置逻辑显示,并且当状态改变时发生通知给系统和应用。为了发现和配置依附于系统的一系列物理显示设备,DMS依赖于一系列 DisplayAdapter 组件。根据设备的不同分为不同的显示适配器:一个显示适配器用于内置的本地显示器;one for simulated non-functional displays when the system is headless;one for simulated overlay displays used for development;一个用于WiFi显示。通过注册的 DisplayAdapter.Listener ,适配器来和 DMS 异步地交流显示设备的状态。这里有两个主要的原因。 首先它很好的封装了两个类的职责:显示适配器处理各个显示设备,显示管理服务处理全局状态。其次,它消除了异步的查找显示设备时导致的死锁。

DisplayPowerState:控制显示状态。当属性改变的时候,该组件以统一的顺序发生一个回调以应用这些改变。这个组件必须且只能被属于 DPC 的 Looper 线程来创建和访问。

在PMS的systemReady方法中,会初始化各种组件,其中就包括这里的DMI,也就是DisplayManagerInternal,它位于hardware包下,作为显示管理的本地服务借口,而DMS等处于server包下,LocalService就继承于它,而DMS本身继承于SystemService。这SS是运行在系统进程中的用于server的基础类,负责提供了相关的生命周期和回调。

回调到DisplayManagerService LocalService.initPowerManagement
DMS.requestGlobalDisplayStateInternal -> applyGlobalDisplayStateLocked -> updateDisplayStateLocked

LocalDisplayDevice.requestDisplayStateLocked

以下都是在requestDisplayStateLocked返回的Runnable中调用的:
SurfaceControl.setDisplayPowerMode 调到native层
mBacklight.setBrightness

DisplayPowerController

DPC控制屏幕显示相关的电源状态,包括距离传感器和光线传感器等。

这个类比较多庞大,我们逐步来看,首先是构造方法。在这里对它所持有的对象进行了初始化,包括以下内容:

mHandler,内部持有的DisplayControllerHandler,用于分发事件。
mCallbacks,
mBatteryStates,
mSensorManager
mWindowManagerPolicy
mBlanker

调节屏幕电源状态,这里指的是屏幕状态,之后会通过mHandler来发送一条异步的MSG_UPDATE_POWER_STATE消息。

    /**
     * Requests a new power state.
     * The controller makes a copy of the provided object and then
     * begins adjusting the power state to match what was requested.
     *
     * @param request The requested power state.
     * @param waitForNegativeProximity If true, issues a request to wait for
     * negative proximity before turning the screen back on, assuming the screen
     * was turned off by the proximity sensor.
     * @return True if display is ready, false if there are important changes that must
     * be made asynchronously (such as turning the screen on), in which case the caller
     * should grab a wake lock, watch for {@link DisplayPowerCallbacks#onStateChanged()}
     * then try the request again later until the state converges.
     */
    public boolean requestPowerState(DisplayPowerRequest request,
            boolean waitForNegativeProximity) {
        if (DEBUG) {
            Slog.d(TAG, "requestPowerState: "
                    + request + ", waitForNegativeProximity=" + waitForNegativeProximity);
        }

        synchronized (mLock) {
            boolean changed = false;

            if (waitForNegativeProximity
                    && !mPendingWaitForNegativeProximityLocked) {
                mPendingWaitForNegativeProximityLocked = true;
                changed = true;
            }

            if (mPendingRequestLocked == null) {
                mPendingRequestLocked = new DisplayPowerRequest(request);
                changed = true;
            } else if (!mPendingRequestLocked.equals(request)) {
                mPendingRequestLocked.copyFrom(request);
                changed = true;
            }

            if (changed) {
                mDisplayReadyLocked = false;
            }

            if (changed && !mPendingRequestChangedLocked) {
                mPendingRequestChangedLocked = true;
                sendUpdatePowerStateLocked();
            }

            return mDisplayReadyLocked;
        }
    }

接下来就看看对于MSG_UPDATE_POWER_STATE消息是如何处理的,在handler中直接调用了updatePowerState()方法。

initialize() 为默认显示设备初始化电源状态,包括根据屏幕状态和亮度反馈给电源Line 508

根据mPowerRequest.policy来设置state和brightness

对距离传感器做相应的操作

执行屏幕状态变化的动画

息屏时亮度设为BRIGHTNESS_OFF

判断和使用自动亮度

boost这个没有理解,再看看源码,

再分别对自动亮度和手动亮度调节做处理

如果低电量模式开启,在亮度的阀值之上,对亮度进行减半

在屏幕点亮状态或休眠时,animate屏幕亮度。如果是息屏、挂起,或者从VR状态转入转出时,跳过动画。

判断对于新的状态请求,显示设备是否就绪

通知policy屏幕已经点亮,真正执行时在mWindowManagerPolicy.screenTurnedOn()

获取锁、通知状态、释放锁


DisplayPowerState

该组件用于控制显示状态,当属性改变的时候,其以统一的顺序将这些改变回调出去。这个组件只能被DisplayPowerController的Looper线程来创建和访问。

DisplayPowerState主要负责设置屏幕状态和屏幕亮度等。这里的dozing也是一种屏幕状态,它是指在低电量模式下,屏幕的休眠状态,但是此时仍然是亮屏的,这是为了让屏幕在没有发生交互时而显示内容的一种优化(其中又分为DOZE和DOZE_SUSPEND两种状态,后者能够实现always-on等功能)。

    /**
     * Sets whether the screen is on, off, or dozing.
     */
    public void setScreenState(int state) {
        if (mScreenState != state) {
            if (DEBUG) {
                Slog.d(TAG, "setScreenState: state=" + state);
            }

            mScreenState = state;
            mScreenReady = false;
            scheduleScreenUpdate();
        }
    }

    /**
     * Sets the display brightness.
     *
     * @param brightness The brightness, ranges from 0 (minimum / off) to 255 (brightest).
     */
    public void setScreenBrightness(int brightness) {
        if (mScreenBrightness != brightness) {
            if (DEBUG) {
                Slog.d(TAG, "setScreenBrightness: brightness=" + brightness);
            }

            mScreenBrightness = brightness;
            if (mScreenState != Display.STATE_OFF) {
                mScreenReady = false;
                scheduleScreenUpdate();
            }
        }
    }

其中最重要的就是这个scheduleScreenUpdate方法,它会去在mPhotonicModulator中异步地设置屏幕状态和亮度。

    private final Runnable mScreenUpdateRunnable = new Runnable() {
        @Override
        public void run() {
            mScreenUpdatePending = false;

            int brightness = mScreenState != Display.STATE_OFF
                    && mColorFadeLevel > 0f ? mScreenBrightness : 0;
            if (mPhotonicModulator.setState(mScreenState, brightness)) {
                if (DEBUG) {
                    Slog.d(TAG, "Screen ready");
                }
                mScreenReady = true;
                invokeCleanListenerIfNeeded();
            } else {
                if (DEBUG) {
                    Slog.d(TAG, "Screen not ready");
                }
            }
        }
    };

这个PhotonicModulator线程在DPS的构造函数中就已经start了,始终在运行着。那么对于一次setState操作,这个现场里究竟会发生什么呢?

1.在setState之后,该方法就会获取到mLock,这样在run中只会走到for循环里,但不会进到synchronized里面的代码中。
2.在setState中,首先会判断屏幕状态和背光是否发生改变,如果是就继续往下走,将这两个值赋给现场内部的mPending*,这个会在run()中使用。
3.判断状态是否都在改变中,判断完后分别进行赋值,如果不在就调用mLock.notifyAll()通知现场可以进行修改了。然后setState方法返回false,因为还没有设置完毕。
4.此时就轮到run方法中获取mLock了,在这里首先state和backlight会获取到来自setState中存储到线程内的值,如果设置的状态和实际的状态不一样,就不会将InProgress的值设为false,因为现在正是要进行修改。
5.然后就会去调用mBlander去设置屏幕状态和背光。
6.在屏幕状态和背光都设置好之后,因为是run方法,for循环还得继续,此时因为值没有变化,不用修改,所以就会去wait。

        public boolean setState(int state, int backlight) {
            synchronized (mLock) {
                boolean stateChanged = state != mPendingState;
                boolean backlightChanged = backlight != mPendingBacklight;
                if (stateChanged || backlightChanged) {
                    if (DEBUG) {
                        Slog.d(TAG, "Requesting new screen state: state="
                                + Display.stateToString(state) + ", backlight=" + backlight);
                    }

                    mPendingState = state;
                    mPendingBacklight = backlight;

                    boolean changeInProgress = mStateChangeInProgress || mBacklightChangeInProgress;
                    mStateChangeInProgress = stateChanged;
                    mBacklightChangeInProgress = backlightChanged;

                    if (!changeInProgress) {
                        mLock.notifyAll();
                    }
                }
                return !mStateChangeInProgress;
            }
        }
        @Override
        public void run() {
            for (;;) {
                // Get pending change.
                final int state;
                final boolean stateChanged;
                final int backlight;
                final boolean backlightChanged;
                synchronized (mLock) {
                    state = mPendingState;
                    stateChanged = (state != mActualState);
                    backlight = mPendingBacklight;
                    backlightChanged = (backlight != mActualBacklight);
                    if (!stateChanged) {
                        // State changed applied, notify outer class.
                        postScreenUpdateThreadSafe();
                        mStateChangeInProgress = false;
                    }
                    if (!backlightChanged) {
                        mBacklightChangeInProgress = false;
                    }
                    if (!stateChanged && !backlightChanged) {
                        try {
                            mLock.wait();
                        } catch (InterruptedException ex) { }
                        continue;
                    }
                    mActualState = state;
                    mActualBacklight = backlight;
                }

                // Apply pending change.
                if (DEBUG) {
                    Slog.d(TAG, "Updating screen state: state="
                            + Display.stateToString(state) + ", backlight=" + backlight);
                }
                mBlanker.requestDisplayState(state, backlight);
            }
        }
相关实践学习
MySQL基础-学生管理系统数据库设计
本场景介绍如何使用DMS工具连接RDS,并使用DMS图形化工具创建数据库表。
目录
相关文章
|
1月前
|
Java 开发工具 Android开发
Android与iOS开发环境搭建全解析####
本文深入探讨了Android与iOS两大移动操作系统的开发环境搭建流程,旨在为初学者及有一定基础的开发者提供详尽指南。我们将从开发工具的选择、环境配置到第一个简单应用的创建,一步步引导读者步入移动应用开发的殿堂。无论你是Android Studio的新手还是Xcode的探索者,本文都将为你扫清开发道路上的障碍,助你快速上手并享受跨平台移动开发的乐趣。 ####
|
24天前
|
存储 Linux API
深入探索Android系统架构:从内核到应用层的全面解析
本文旨在为读者提供一份详尽的Android系统架构分析,从底层的Linux内核到顶层的应用程序框架。我们将探讨Android系统的模块化设计、各层之间的交互机制以及它们如何共同协作以支持丰富多样的应用生态。通过本篇文章,开发者和爱好者可以更深入理解Android平台的工作原理,从而优化开发流程和提升应用性能。
|
24天前
|
Java 调度 Android开发
安卓与iOS开发中的线程管理差异解析
在移动应用开发的广阔天地中,安卓和iOS两大平台各自拥有独特的魅力。如同东西方文化的差异,它们在处理多线程任务时也展现出不同的哲学。本文将带你穿梭于这两个平台之间,比较它们在线程管理上的核心理念、实现方式及性能考量,助你成为跨平台的编程高手。
|
1月前
|
域名解析 缓存 网络协议
浏览器中输入URL返回页面过程(超级详细)、DNS域名解析服务,TCP三次握手、四次挥手
浏览器中输入URL返回页面过程(超级详细)、DNS域名解析服务,TCP三次握手、四次挥手
|
1月前
|
开发框架 Dart Android开发
安卓与iOS的跨平台开发:Flutter框架深度解析
在移动应用开发的海洋中,Flutter作为一艘灵活的帆船,正引领着开发者们驶向跨平台开发的新纪元。本文将揭开Flutter神秘的面纱,从其架构到核心特性,再到实际应用案例,我们将一同探索这个由谷歌打造的开源UI工具包如何让安卓与iOS应用开发变得更加高效而统一。你将看到,借助Flutter,打造精美、高性能的应用不再是难题,而是变成了一场创造性的旅程。
|
1月前
|
安全 Java Linux
深入解析Android系统架构及其对开发者的意义####
【10月更文挑战第21天】 本文旨在为读者揭开Android操作系统架构的神秘面纱,探讨其如何塑造现代移动应用开发格局。通过剖析Linux内核、硬件抽象层、运行时环境及应用程序框架等关键组件,揭示Android平台的强大功能与灵活性。文章强调了理解Android架构对于开发者优化应用性能、提升用户体验的重要性,并展望了未来技术趋势下Android的发展方向。 ####
47 0
|
1月前
|
监控 Java 应用服务中间件
高级java面试---spring.factories文件的解析源码API机制
【11月更文挑战第20天】Spring Boot是一个用于快速构建基于Spring框架的应用程序的开源框架。它通过自动配置、起步依赖和内嵌服务器等特性,极大地简化了Spring应用的开发和部署过程。本文将深入探讨Spring Boot的背景历史、业务场景、功能点以及底层原理,并通过Java代码手写模拟Spring Boot的启动过程,特别是spring.factories文件的解析源码API机制。
76 2
|
2月前
|
缓存 Java 程序员
Map - LinkedHashSet&Map源码解析
Map - LinkedHashSet&Map源码解析
79 0
|
2天前
|
存储 设计模式 算法
【23种设计模式·全精解析 | 行为型模式篇】11种行为型模式的结构概述、案例实现、优缺点、扩展对比、使用场景、源码解析
行为型模式用于描述程序在运行时复杂的流程控制,即描述多个类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务,它涉及算法与对象间职责的分配。行为型模式分为类行为模式和对象行为模式,前者采用继承机制来在类间分派行为,后者采用组合或聚合在对象间分配行为。由于组合关系或聚合关系比继承关系耦合度低,满足“合成复用原则”,所以对象行为模式比类行为模式具有更大的灵活性。 行为型模式分为: • 模板方法模式 • 策略模式 • 命令模式 • 职责链模式 • 状态模式 • 观察者模式 • 中介者模式 • 迭代器模式 • 访问者模式 • 备忘录模式 • 解释器模式
【23种设计模式·全精解析 | 行为型模式篇】11种行为型模式的结构概述、案例实现、优缺点、扩展对比、使用场景、源码解析
|
2天前
|
设计模式 存储 安全
【23种设计模式·全精解析 | 创建型模式篇】5种创建型模式的结构概述、实现、优缺点、扩展、使用场景、源码解析
结构型模式描述如何将类或对象按某种布局组成更大的结构。它分为类结构型模式和对象结构型模式,前者采用继承机制来组织接口和类,后者釆用组合或聚合来组合对象。由于组合关系或聚合关系比继承关系耦合度低,满足“合成复用原则”,所以对象结构型模式比类结构型模式具有更大的灵活性。 结构型模式分为以下 7 种: • 代理模式 • 适配器模式 • 装饰者模式 • 桥接模式 • 外观模式 • 组合模式 • 享元模式
【23种设计模式·全精解析 | 创建型模式篇】5种创建型模式的结构概述、实现、优缺点、扩展、使用场景、源码解析

推荐镜像

更多