Android画面显示流程分析(1)

本文尝试从硬件认识开始介绍Android如何更新显示系统的图片，希望能android系统如何更新图片，给读者带来感性认知。试着在文章中解释一下App画一帧图片到这帧图片是如何到达屏幕并最终被人眼看到的整个过程，这将涉及一些硬件的基本知识和Android一些重要的软件基软件基本组件。本文将首先介绍图片显示过程中涉及的重要组成部分及其工作原理，然后从Android app渲染第一帧的图片开始逐渐连接到每个组件，期待着最终Android如何在系统下显示图片，给读者一个宏观的理解。本文适合对Android对显示系统有一定了解的学生阅读。由于文章较长，这里将分为10章，共5篇博文介绍。

因为这篇文章是通过阅读各种文章和代码来总结的，有些地方不可避免地理解错误，欢迎批评和纠正。

无论软件的架构设计有多高端、多高档，最终都离不开硬件的支持。软件架构是基于硬件的运行原理。因此，在讨论软件设计之前，有必要对显示硬件的原理有一个初步的了解。

LCD(Liquid Crystal Display)俗称液晶。

液晶是一种材料，液晶有一个特点:液晶分子可以在电信号的驱动下旋转，会影响透光性。

因此，我们可以在整个液晶面板后面使用白光（称为背光），液晶分子可以通过不同的电信号进行选择性透光。此时，我们在液晶面板前看到各种不同的颜色，这就是LCD显示图片的原理。

VGA(Video Graphics Array)即视频图形阵列，具有分辨率高、显示速度快、色彩丰富等优点。VGA接口不但是CRT显示设备的标准接口也是LcD液晶显示设备的标准接口，具有广泛的应用范围。相信很多朋友都很熟悉，因为这个接口是电脑显示器上最重要的接口，从巨大的大块头开始CRT从显示时代开始，VGA界面已经使用，并且一直沿用到今天。

HDMI（High Definition Multimedia Interface） 高清多媒体接口是一种可以发送未压缩音频和视频信号的全数字视频和声音发送接口。HDMI可用于机顶盒，DVD播放机、个人电脑、电视、游戏主机、综合扩展机、数字音响、电视等设备。HDMI音频和视频信号可以同时发送，因为音频和视频信号使用相同的线，大大简化了系统线路的安装难度。

这个写入时序应该首先从过去开始 CRT 从显示原理开始。CRT 电子枪从上到下扫描。扫描完成后，显示器显示一帧图片，然后电子枪返回初始位置继续下一次扫描。显示器显示器的显示过程与系统的视频控制器同步，显示器（或其他硬件）将使用硬件时钟产生一系列定时信号。当电子枪换成新行并准备扫描时，显示器会发出水平同步信号（horizonal synchronization），简称 HSync；画完一帧后，电子枪回到原位，准备画下一帧，显示器会发出垂直同步信号（vertical synchronization），简称 VSync。显示器通常以固定频率刷新，即 VSync 产生信号的频率。虽然目前的设备大多是液晶显示屏，但原理没有改变。

CLK：只有在时钟上升或下降时，像素数据才能有效 ENB：当数据使能信号高时，CLK当信号到达时，输出有效数据。 HBP：行同步信号的前肩沿水平同步信号上升ENABLE上升沿的间隔。 HSW：低电平(非有效电平)的水平同步信号持续时间 HFP：行同步信号的后肩，ENABLE的下降沿到水平同步信号的下升沿的间隔 如下图所示

图中从HSYNC从下降边开始，等待两个CLK产生上升沿，等待HBP随着时间的推移，一行像素数据开始传输，像素数据只写在像素时钟和上升或下降（这里我们只讨论原理，而不是特定平台的具体实现，所以HSW对应的时钟数字不以图中所示为准，具体产品会有调整和变化)，N像素时钟后，一行像素数据成功写入D1-Dn

类似地，两帧画面之间也有一些间隔：

VSW: VSYNC信号下降时间沿着上升边缘下降 VBP: 帧同步信号的前肩 VFP:帧同步信号的后肩 VPROCH: 它被称为消隐区，指 VSW VBP VFP , 这段时间Panel不要更新像素点的颜色

在一个Vsync周期内是由多个Hsync由周期组成的个数是Y方向屏幕上的像素点数，即屏幕上有多少行像素点， 每个Hsync传输一行中所有像素点的数据。通常屏幕给的spec文档还会给出类似下面这样的图，但都是表达一个意思，数据是以行为单位写入的，Hsync是协调行和行之间的同步信号，多个行依次写入构成一帧数据，帧和帧数据之间由Vsync信号来同步协调。

当多帧画面依次输出到屏幕的时候我们就可以看到运动的画面了，通常这个速度到达每秒60帧时人眼就已经感觉画面很流畅了。下图演示了在vsync和hsync同步下两帧画面间的切换时序，以及消隐区(VPorch)在其中的位置关系。在消隐区结束（或开始）时DDIC会向SOC发出一个中断信号，这个信号称为TE信号， SOC这边就是通过该中断信号来判断上一帧数据是否已被DDIC读走，进而决定是否可以将buffer写入下一帧数据。

让我们以下面这张图来说明从SOC到到DDIC再到Panel的画面更新过程，首先SOC准备画面A, DDIC上一帧画面更新完毕进入消隐区，同时向SOC侧发送TE信号，SOC收到TE信号后，A画面的数据开始通过DSI总线向DDIC传输（DSI Write）,当消隐区时间结束时开始这一帧数据从数据变为像素点颜色的过程(Disp Scan), Disp Scan是以行为单位将GRAM内一行的数据内容通过改变电流电压等方式改变Panel上像素点的颜色。进而实现一行画面的更新，按下来Disp Scan将以一定速度逐行读取GRAM的内容，而于此同时DSI Write也还在进行中，由于DSI Write较Disp Scan早了一个Vporch的时间，所以Disp Scan扫描到的数据都是A画面的数据。那么人眼会看到画面“逐渐”出现到显示屏上，当A画面的所有行都经Disp Scan到达屏幕后，下一个Vporch开始，DDIC再次向SOC发出TE信号， 下帧B画面的数据开始经过DSI总线传输到DDIC, 如此循环往复可以将连续的A, B， C画面更新到屏幕上。

这里我们思考一个问题： 就像上图中所绘一样总会存在一段时间GRAM内的数据会出现一部分是新画面的数据，一部分是旧画面的数据，那么从上帝视角看GRAM里的画面是“撕裂”的，那Disp Scan会不会把这个“撕裂”的画面显示到Panel上呢？ 用户有没有可能看到一个“撕裂”的画面呢？

答案是有可能会。

为讨论方便我们这里先把DSI write记作写， 把Disp Scan记作读， 正常情况下，我们会将读速度调到和写速度差不多，由于写是在进入vporch时就开始了，而读的动作是离开vproch时，所以在读和写的这场“百米跑”竞赛中总是写跑在前面，这样保证读始终读到的是同一帧画面的数据，这个过程如下面图1所示。

由于读和写的速度受到环境或各种电气因素影响并不是一成不变的，在实际运行过程中会有波动，当读和写两条线离的较近时由于速度波动的存在会出现两条线交叉的情况，如图2所示，那么这时读会先后读到前后两帧的数据，出现花屏现象。

有时我们为了避免由于速率波动引起花屏问题，会放大vporch的时间让读和写尽量拉开距离，这样可以减少花屏现象出现的概率，这里的原理如图3所示

继续思考下一问题： 从上面的分析可以看出Panel上的像素数据是一行行更新下来的，那人眼为什么没有看到更新了一半的画面呢？

这个问题我并不知道答案，这可能涉及到人眼的生物学构造，人眼对事物的成像原理等复杂的原理，总之是在这个时间尺度内人眼看不到。

接下来我们从另一角度来研究一下这个问题，我们把视角切换到上帝视角，假如存在上帝之眼的话，他应该能看到这个更新了一半的画面，我们尝试用高速摄影机来模拟“上帝之眼”。

首先我们先准备一些测试代码， 我们写一个测试用apk, 下面这段代码是向Android框架注册一个Choreographer的监听，Choreographer是Android提供的一个获取vsync信号的通道。当下图中doFrame被调用到时我们这里可以暂时粗略理解为是上面所讨论的TE信号， 这里收到Vsync信号后通过Pthread的Condition通知到另一线程。这用于模拟一个vsync的消息泵。

Choreographer.getInstance().postFrameCallback(new Choreographer.FrameCallback() {
    @Override
    public void doFrame(long frameTimeNanos) {//当vsync信号来时会调用到这里
            Global.lock.lock();
            try {
                Global.syncCondition.signal();//通知另一条线程更新画面
            } catch (Exception e) {
                e.printStackTrace();
            } finally {
                Global.lock.unlock();
            }
            Choreographer.getInstance().removeFrameCallback(this);
            Choreographer.getInstance().postFrameCallback(this);
    }
});

下面代码中每收到一个vsync信号都会去画一帧画面，同时给帧编号编号加1（相当于给每一帧一个编号），如果当前的编号为奇数则画绿色，如果为偶数则画蓝色，那么画面应该是蓝绿交替出现：

public class MySurfaceView extends SurfaceView implements SurfaceHolder.Callback, Runnable {
    .......

    @Override
    public void run() {
        while(true) {
            Global.lock.lock();
            try {
                Global.syncCondition.await();//在这里等待vsync到来的通知消息
            } catch (InterruptedException e) {
                e.printStackTrace();
            } finally {
                Global.lock.unlock();
            }
            draw();//画蓝色或绿色
        }
    }
    ........
    private void draw() {

        Canvas mCanvas = null;
        try {
            mCanvas = mSurfaceHolder.lockCanvas();
            if(autoNum %2 == 0) {
                mPaint.setColor(Color.BLUE);//如果为双数则画面画成蓝色
            } else {
                mPaint.setColor(Color.GREEN);//如果为单数则画面画成绿色
            }
            mCanvas.drawRect(0, 0, getRight(), getBottom(), mPaint);
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            if (mCanvas != null) {
                mSurfaceHolder.unlockCanvasAndPost(mCanvas);
            }
        }
        autoNum++;//数字加1
    }

}

下面是高速摄影机看到的画面变化情况，从下图中可以看出来，画面从绿变蓝的过程中总是能看到先是上面部分变蓝色，接下来才会看到全部变蓝，由蓝变绿也是同样的现象，先是图像上面变成绿色接下来全部变绿色，在“上帝之眼”看来画面的变化是有前后两个画面各占一部分的情况的，这情况是上面是新画面下面是旧画面，但人眼是看不出来这种画面。

下面的图中发现画面是颜色渐变的，这是因为通过高速摄影机是画面再次感光形成的影像，由于物理世界中光线是有衍射及曝光时长因素的，所以最终在高速摄影机留下的图中是颜色渐变的。

在本章节中，我们了解到了一些显示硬件的一些组成要件，以及屏幕是如何按时序更新画面的，以及在画面更新过程中屏和SOC间的一些互动是如何完成的。那么接下来我们再来了解下SOC内部是如何把画面送过来的。

本文转自 https://www.jianshu.com/p/df46e4b39428，如有侵权，请联系删除。

欢迎大家一键三连支持，若需要文中资料，直接点击文末CSDN官方认证微信卡片免费领取【保证100%免费】↓↓↓