**死机现象与表现：**
- **现象：**当手机长时间无法再被用户控制操作时，我们称为死机或者hang 机。
- **表现:**
1、用户操作手机无任何响应, 如触摸屏幕，按键操作等。
2、 手机屏幕黑屏, 无法点亮屏幕。
3、 手机界面显示内容和用户输入风马牛不相及。
----------
##软件层次的死机
**一、当用户对手机进行操作时, 对应的数据流将是：**
>**HW Spage->Input Driver->Input system ->System logic ->Surfaceflinger->Display system->LCM Driver**
* *HW* 如传感器, 触摸屏(TP), 物理按键(KP)等感知到用户操作后，触发相关的中断(ISR) 传递给Kernel, Kernel 相关的driver 对这些ISR 进行处理后，转化成标准的InputEvent.
* User Space 的System Server 中的Input System 则持续监听Kernel 传递上来的原始*InputEvent*, 对其进行进一步的处理后, 变成上层APP 可直接处理的Input Event, 如button 点击, 长按, 滑动等等.
* APP 对相关的事件进行处理后，请求更新相关的逻辑界面，而这个则由System Server 中的WMS 等来负责.
* 相关的逻辑界面更新后(Z-Window), 则会请求**SurfaceFlinger** 来产生FrameBuffer 数据, SurfaceFlinger 则会利用GPU 等来计算生成.
* Display System/Driver 则会将FrameBuffer 中的数据更新显示出来, 这样用户才能感知到他的操作行为.
**二、分析问题的过程**
>软件SW 上，死机的原因可以分成两种:
**(1). 逻辑行为异常**
逻辑判断错误
逻辑设计错误
>**(2). 逻辑卡顿(block)**
死循环 (Deadloop)
死锁 (Deadlock)
**从具体的原因上将，可以进一步分成:**
**(1). Input Driver**
无法接收HW 的中ISR，产生原始的InputEvent, 或者产生的InputEvent 异常.
**(2). Input System**
无法监听Kernel 传递上来的原始InputEvent, 或者转换与传递异常.
**(3). System Logic**
无法正常响应Input System 传递过来的InputEvent, 或者响应出错.
**(4). WMS/Surfaceflinger 行为异常**
WMS/SF 无法正确的对Z-Window 进行叠加转换
**(5). Display System**
无法更新Framebuffer 数据，或者填充的数据错误
**(6). LCM Driver**
无法将Framebuffer 数据显示在LCM 上
**三、死机分析的数据**
1、Backtrace 又分成**Java backtrace, Native Backtrace, Kernel Backtrace.** 它是分析死机的非常重要的手段，我们可以快速的知道，对应的process/thread 在当时正在执行哪些动作，卡住哪里等。可以非常直观的分析死机现场。
详见： https://onlinesso.mediatek.com/_layouts/15/mol/topic/ext/Topic.aspx?id=111
2、客观的反应系统的执行环境，通常包括如CPU 利用率，Memory 使用情况， Storage剩余情况等。这些资料也非常重要，比如可以快速的知道，当时是否有Process 在疯狂的执行，当时是不是处于严重的low memory 情况， Storage 是否有耗尽的情况发生等。