一、Android P 系统稳定性问题分析方法总结
Android系统最开始是为手机设计的，在机顶盒，电视，带屏音箱等大屏上运行后，芯片厂家做些适配，产品厂家也会做系统客制化，有时候还要适配第三方应用..等待
这种适配容易引人系统的稳定性问题，系统稳定性对于用户体验至关重要，很多问题也都比较类似，android系统对系统性能，稳定性分析工具也比较多，下面根据工作中遇到的问题做个总结。
从表现来看有:死机重启,自动关机,无法开机,冻屏,黑屏以及闪退,无响应等情况;
从技术层面来划分无外乎两大类:长时间无法执行完成(Timeout)以及异常崩溃(crash).主要分类如下:
ANR(Application Not responding)，是指普通app进程超过一定时间没有执行完，系统会弹出应用无响应对话框.如果
该进程运行在system进程,更准确的来说,应该是(System Not Responding, SNR)
ANR产生的原因可能是各种各样的，但常见的原因可以分为：
1.logcat日志
2.trace文件(保存在/data/anr/traces.txt)
从logcat里可以看到死锁的打印
从traces.txt可以看到线程的函数调用栈
10-16 00:50:10 820 907 E ActivityManager: ANR in com.android.systemui, time=130090695
10-16 00:50:10 820 907 E ActivityManager: Reason: Broadcast of Intent{ act=android.intent.action.TIME_TICK ***=0x50000114(has extras)}
10-16 00:50:10 820 907 E ActivityManager: Load: 30.4/ 22.34/ 19.94
10-16 00:50:10 820 907 E ActivityManager: Android time:[2015-10-16 00:50:05.76] [130191,266]
10-16 00:50:10 820 907 E ActivityManager: CPU usage from 6753ms to-4ms ago:
10-16 00:50:10 820 907 E ActivityManager: 47% 320/netd: 3.1% user+ 44% kernel/ faults: 14886 minor 3 major
10-16 00:50:10 820 907 E ActivityManager: 15% 10007/com.sohu.sohuvideo: 2.8% user+ 12% kernel/ faults: 1144 minor
10-16 00:50:10 820 907 E ActivityManager: 13% 10654/hif_thread: 0% user+ 13% kernel
10-16 00:50:10 820 907 E ActivityManager: 11% 175/mmcqd/0: 0% user+ 11% kernel
10-16 00:50:10 820 907 E ActivityManager: 5.1% 12165/app_process: 1.6% user+ 3.5% kernel/ faults: 9703 minor 540 major
10-16 00:50:10 820 907 E ActivityManager: 3.3% 29533/com.android.systemui: 2.6% user+ 0.7% kernel/ faults: 8402 minor 343 major
......
10-16 00:50:10 820 907 E ActivityManager:+0% 12832/cat: 0% user+ 0% kernel
10-16 00:50:10 820 907 E ActivityManager:+0% 13211/zygote64: 0% user+ 0% kernel
10-16 00:50:10 820 907 E ActivityManager: 87% TOTAL: 3% user+ 18% kernel+ 64% iowait+ 0.5% softirq
发生ANR的时间 00:50:10,可以从这个时间点之前的日志中，还原ANR出现时系统的运行状态
发生ANR的进程 com.android.system.ui
发生ANR的原因 Reason关键字表明了ANR的原因是处理TIME_TICK广播消息超时
CPU负载 Load关键字表明了最近1分钟、5分钟、15分钟内的CPU负载分别是30.4、22.3、19.94.CPU最近1分钟的负载最具参考价值，因为ANR的超时限制基本都是1分钟以内，这可以近似的理解为CPU最近1分钟平均有30.4个任务要处理，这个负载值是比较高的
CPU使用统计时间段 CPU usage from XX to XX ago关键字表明了这是在ANR发生之前一段时间内的CPU统计,类似的还有CPU usage from XX to XX after关键字，表明是ANR发生之后一段时间内的CPU统计
各进程的CPU使用率
以com.android.systemui进程的CPU使用率为例，它包含以下信息：
总的CPU使用率: 3.3%，其中systemui进程在用户态的CPU使用率是2.6%，在内核态的使用率是0.7%
缺页次数fault：8402 minor表示高速缓存中的缺页次数，343 major表示内存的缺页次数。minor可以理解为进程在做内存访问，major可以理解为进程在做IO操作。当前minor和major值都是比较高的，从侧面反映了发生ANR之前，systemui进程有有较多的内存访问操作，引发的IO次数也会较多
CPU使用汇总 TOTAL关键字表明了CPU使用的汇总，87%是总的CPU使用率，其中有一项iowait表明CPU在等待IO的时间，占到64%，说明发生ANR以前，有大量的IO操作。app_process、 system_server, com.android.systemui这几个进程的major值都比较大，说明这些进程的IO操作较为频繁，从而拉升了整个iowait的时间
traces.txt如下
----- pid 29533 at 2015-10-16 00:48:29-----
Cmd line: com.android.systemui
DALVIK THREADS(54):
"main" prio=5 tid=1 Blocked
| group="main" sCount=1 dsCount=0 obj=0x75bd5818 self=0x7f8549a000
| sysTid=29533 nice=0 cgrp=bg_non_interactive sched=0/0 handle=0x7f894bbe58
| state=S schedstat=( 289080040422 93461978317 904874) utm=20599 stm=8309 core=0 HZ=100
| stack=0x7fdffda000-0x7fdffdc000 stackSize=8MB
| held mutexes=
at com.mediatek.anrappmanager.MessageLogger.println(SourceFile:77)
Android系统中，有硬件WatchDog用于定时检测关键硬件是否正常工作，类似地，在framework层有一个软件WatchDog用于定期检测关键系统服务是否发生死锁事件。
watchdog每过30s检测一次，如果要监控的线程30s后没有响应，系统会dump出此进程堆栈，如果超过60s没有相应，会触发watchdog，并重启系统
10:57:23.718 579 1308 W Watchdog:*** WATCHDOG KILLING SYSTEM PROCESS: Blocked in monitor com.android.server.am.ActivityManagerService on foreground thread(android.fg), Blocked in handler on main thread(main), Blocked in handler on ActivityManager(ActivityManager)
10:57:23.725 579 1308 W Watchdog: android.fg annotated stack trace:
10:57:23.726 579 1308 W Watchdog: at com.android.server.am.ActivityManagerService.monitor(ActivityManagerService.java:26271)
10:57:23.727 579 1308 W Watchdog:- waiting to lock<0x0bb47e39>(a com.android.server.am.ActivityManagerService)
10:57:23.727 579 1308 W Watchdog: at com.android.server.Watchdog DeliveryTracker.alarmTimedOut(AlarmManagerService.java:4151)
10:57:23.733 579 1308 W Watchdog:- waiting to lock<0x00aaee38>(a java.lang.Object)
......
10:57:23.736 579 1308 W Watchdog: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:838)
10:57:23.739 579 1308 W Watchdog: ActivityManager annotated stack trace:
10:57:23.740 579 1308 W Watchdog: at com.android.server.am.ActivityStack$ActivityStackHandler.handleMessage(ActivityStack.java:405)
10:57:23.740 579 1308 W Watchdog:- waiting to lock<0x0bb47e39>(a com.android.server.am.ActivityManagerService)
10:57:23.740 579 1308 W Watchdog: at android.os.Handler.dispatchMessage(Handler.java:106)
10:57:23.741 579 1308 W Watchdog:*** GOODBYE!
分析：
提示 ActivityManagerService的android.fg,main,ActivityManager线程Block了,但logcat里只能看到
android.fg等待0x0bb47e39锁,main等待0x00aaee38锁,ActivityManager等待0x0bb47e39锁,无法进一步分析,需要看traces.txt
Cmd line: system_server
......
"main" prio=5 tid=1 Blocked
当出现应用闪退，可以从两个方面查看：
1、是否应用崩溃：
可以通过logcat–s AndroidRuntime DEBUG过滤日志，查看应用奔溃的具体堆栈信息。
其中AndroidRuntime的TAG打印java层信息，DEBUG的TAG打印native层的信息。
2、是否被lowmemorykiller杀掉：
可以通过 logcat–s lowmemorykiller过滤日志，注意adj 0是代表前台进程。例如：
03-08 04:16:58.084 310 310 I lowmemorykiller: Killing'com.google.android.tvlauncher'(2520), uid 10007, adj 0
发生这种情况，需要dumpsys meminfo查看当前内存状态，是否有进程内存泄漏，导致系统内存不够，出现前台进程被杀，造成闪退。
测试过程中，经常遇到屏幕闪烁的现象，需要排除是OSD层闪烁，还是video层闪烁。
1、先通过android原生方法：screencap截图, screenrecord录制视频，这里都是截取的OSD层，查看是否有闪屏现象。
2、OSD没有问题，就需要从更底层的显示模块分析，一般需要芯片厂家提供debug手段，不同芯片厂家方案不一样。
3,有时候输出不稳定，hdmi/mipi信号干扰，输出频率异常等也会导致闪屏，这种情况需要硬件协助分析。
如果OSD层也闪烁，则需从系统和应用层面分析。如曾遇到在开机向导界面，有个应用不断被唤起，导致走开机向导时出现连续闪灰屏的现象。
黑屏分UI黑屏，视频播放黑屏但UI正常等，2种场景
1、screencap截屏，排查OSD层图形是否正常，
2、如果OSD图形正常，需要排查显示输出模块是否异常。
3、电视机里面屏显是单独控制，如果屏参配置错误会导致整改黑屏。
OSD异常，需要排查顶层activity是否黑屏，window是否有异常等.
1，排查视频图层或者window是否创建成功。
2，排查解码是否有异常，不同的应用*******,netflix,iptv解码方式不一样，需要具体问题具体分析。
如下，ActivityManager因为空对象引用而挂掉，导致system_server重启
*** [FATAL EXCEPTION IN SYSTEM PROCESS: ActivityHanager [
^ava.lang.NullPointerException: Attempt to invoke virtual method'void co®.android.internal.os.KernelSingleUidTimeReader.iBarkDataAsStale(boolean)' on a null object reference
at com.android.internal.os.BatteryStatsIiaplSConstants.upddteTrackCpuTiinesByProcStdteLocked(BatteryStatslnpl.java:13355)
at com.android.internal.os.BatteryStatsInplSConstants.upddteConstants(BatteryStatsImpl.java:13330)
at com.android.internal-o-batteryStatslMpl$Constants-onChange(BatteryStatsInpl-java:13316)
at android.database.Contentobserver.onChange(ContentObserver.java:145)
解决方法：修复空指针
DEBUG: pid: 296, tid: 1721, name: Binder：296_4>>>/system/bin/surfaceflinger<<<
DEBUG: signal 6(SIGABRT), code-6(SI_TKILL), fault addr------
DEBUG: Abort message:'status.cpp:149] Failed HIDL return status not checked: Status(EXTRANSACTIONFAILED):
DEBUG: r0 00000000 rl 000006b9
DEBUG： C4 00000128 r5 000006b9
r2 00000006 r3 a5c5d620
r6 a235d60c r7 0000010c
DEAD_OB3ECT：
DEBUG: r8 00000019 r9 0000015d
DEBUG: ip a6ablbec sp a235d5f8
rlO a568f090 rll a620dce9
Ir a5be901d pc a5be0da2
/system/lib/libc.so(abort+62)
/system/lib/libbase.so(android::base::DefaultAborter(char const)+6)
backtrace:
/system/lib/libsurfaceflinger.so
/system/lib/libsurfaceflinger.so
/system/lib/libsurfaceflinger.so
/system/lib/libsurfaceflinger.so
/system/lib/libbase.so(android::base::LogMessage::~LogMessage()+502)
/system/lib/libhidlbase.so(android::hardware::details::return_status::~return_status()+184)
(android::Hwc2::impl::Composer::getActiveConfig(unsigned long long, unsigned int)+56)
(HWC2::Display::getActiveConfig(std::_1::shared_ptr<HWC2：:Display::Config const>*) const+38)
(android::HWComposer::getActiveConfig(int) const+64)
(android::SurfaceFlinger::resyncToHardwareVsync(bool)+64)
可以根据backtrace来进行定位异常崩溃的地方。Android P上， backtrace使用Java上下文来显示，省去使用addr2line来转换的一个过程，方便调试分析问题。但是实际场景中，
有些native进程崩溃只有pc地址，而无函数信息，或者需要定位到具体的某个文件某个函数，则可借助堆栈分析工具addr2line。
addr2line：根据堆栈定位具体函数和文件
addr2line-e libsurfaceflinger.so-f 00071a09
addr2line-e libsurfaceflinger.so-f 00071a09
_ZN7android14SurfaceFlinger12waitForEventEv
frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp:1229
需注意两点：
1、需用带debug信息的LINK目录里面的so库，机顶盒上的so库是无法定位的：
out/target/product/xx/obj/SHARED_LIBRARIES/libsurfaceflinger_intermediates/LINKED/libsurfaceflinger.so
或者：out/target/product/xx/symbols/system/lib/libsurfaceflinger.so
2、定位的文件，必现和机器上出现问题的版本一致，否则定位不准确
debuggerd：打印当前进程实时堆栈：debuggerd–b pid
主要可以分为以下3类
1)Data abort
Unable to handle kernel NULL pointer dereference at virtual address...
Unable to handle kernel paging request at virtual address...
Unhandled fault...at...
Unhandled prefetch abort...at...
2)BUG/BUG_ON
Oops- BUG...
例如：
Out of memory and no killable processes...
rbus timeout...
...
PS:WARN_ON只dump stacks，kernel还是正常
3)bad mode
Oops- bad mode...
日志打印:
〃错误类型原因
[214.962667] 08:14:19.315(2)-0488 Unable to handle kernel paging request at virtual address 6b6b6cl7
[214.973889] 08:14:19.326(2)-0488 addr：6b6b6c17 pgd= d0824000
[214.980132] [6b6b6c17J•pgd=O000eO0e
〃Oopsttl误码序号
[214.983865] 08:14:19.336(2)-0488 Internal error： Oops： 805 [#1] PREEMPT SMP ARM
[214.9914S3] Modules linked in: 8192eu ufsd(PO) jnl(O) fusion(O)
〃发生也错误的CPU序号
(215.001878] 08:14:19.354(2)-0488 CPU： 2 PID: 488 Comm: system_server Tainted: P 4.4.3+#113
(2)-0488 Hardware name: rtd284x
[215.011865] 08:14:19.364
〃当前PC指针 98:14:19.377(2)-0488 PC is at mutex_unlo<k+0xc/0x38
(21S.024846] 08:14:19.383(2)-0488 LR is at storage_pm_event+0xb4/0xe8
(21S.031026]
//Registers 08:14:19.390(2)-0488：[<ceb78ffc>] Ir: [<C0542034>] psr: 200f0013
I 215.037644] sp: ccf79e38 ip: eceoeeee fp: 9b34648c
I 215.037644]
08:14:19.404(2)-0488 rlO： 00000080 r9：Cl8b3864 r8: oeeeeeoe
215.051370]
215.058692] 08:14:19.411(2)-0488 P7： C1293a98 P6：C1293940 r5: C1293940 r4：C1293a80
21S.067345]
[ 215.076014] 08:14:19.420(2)-0488 r3: 00000033 r2：00000000 ri: 000^000 re：6b6b6c07
[ 215.085307]
08:14:19.428(2)-0488 Flags: nzCv IRQs on FIQs on Mode SVC 32 ISA ARM Segment user
08:14:19.438(2)-0488 Control: 10c5383d Table： 1082406a DAC： 00000055
//Process.不,定是该process的错误，只是发生错误时,刚好在运行该process
[215.093168]
//Stacks 08:14:19.446(2)-0488 Process syste«i_server(pid: 488, stack limit= 0xccf78218)
(21S.101827] 08:14:19.454(2)-0488 Stack: 0xccf79e38(Oxccf79d7。 to 0xccf7a08Q)- par(0xcf796d4)
---[ end trace 45d55384id6a0974 ]--- Kernel panic not syncing: Fatal exception
[217.359794] 08:14:21.712(0)-0488
解决方案: kernel异常一般找芯片原厂协助分析。
系统卡顿时，一般先分三步走：
1、查看当前系统的CPU，IO等参数，输入top、iotop命令：（如：iotop-s io-m 9）
如果有异常飙高的进程，kill掉后会发现系统恢复正常。
之前项目上遇到过某些U盘IO性能比较差，媒体中心又在后台扫描媒体问题，导致系统各种卡顿，io wait时间比较长。
2、系统进程卡住，触发Watchdog：ps–A|grep system_server,一般而言，system_server正常的进程号是200多，如果发现进程号变成几千，则可能出现重启，结合tombstone和/data/anr下的trace文件分析重启原因
3、当前应用出现卡顿，造成ANR。输入logcat| grep ANR，如果有ANR打印，再去/data/anr下面查看相应进程的traces文件
有时在应用里面操作卡顿，按键响应延迟，但是却没有生成ANR，此时如果退出该应用（如果无法退出，在抓取足够信息的情况下，可以串口直接kill掉卡顿的应用），则一切正常，可能是应用自身实现问题，或者调用了其它接口导致（例如曾遇到应用调用了中间件、mediaplayer某些接口导致操作严重卡顿，按键响应延迟），这种情况则需应用和相应接口的实现者去排查。
系统完全卡死，一般分三种情况
1，串口无响应，大概率kernel panic，
2，串口日志狂输出，把系统堵塞，优化日志输出，关注关闭后压测。
3，Input系统完全堵塞，导致任何输入都无响应。
二、android 关机重启流程
https://developer.android.com/intl/zh-CN/reference/android/os/PowerManager.html
在PowerManager的API文档中，给出了一个关机/重启接口：
public void reboot(String reason)
对于这个接口的描述很简单，就是几句话。
接口的作用就是重启设备，而且，就算重启成功了也没有返回值。
需要包含REBOOT权限，也就是android.permission.REBOOT
唯一参数reason代表需要的特定重启模式，比如recovery，当然也可以为null。
1.frameworks/base/core/java/android/os/PowerManager.java
2.frameworks/base/core/java/android/os/IPowerManager.aidl
3.frameworks/base/services/java/com/android/server/PowerManagerService.java
4.frameworks/base/services/java/com/android/server/pm/ShutdownThread.java
5.frameworks/base/services/jni/com_android_server_PowerManagerService.cpp
---------------------》
6.system/core/libcutils/android_reboot.c
7.bionic/libc/unistd/reboot.c
8.__reboot通过syscall来到内核
9.kernel/sys.c
frameworks/base/core/java/android/os/PowerManager.java
mService为IPowerManager Binder接口服务。
frameworks/base/core/java/android/os/IPowerManager.aidl
frameworks/base/services/java/com/android/server/PowerManagerService.java
frameworks/base/services/java/com/android/server/pm/ShutdownThread.java
这里说明是需要重启，且不是安全模式，重启参数为传递下来的reason，shutdownInner的confirm参数是用来设置是否有确认提示框的，通过reboot接口调用重启是没有的，为false。
重启的实现在run()中，因为ShutdownThread是Thread的扩展，所以run会自动运行。
frameworks/base/services/java/com/android/server/pm/ShutdownThread.java
在重启前会将重启原因写入sys.shutdown.requested，如果没有则为空，如果是安全模式还会将persist.sys.safemode置1，之后会进行一些关机前的预处理，关闭ActivityManager以及MountService，最终调用rebootOrShutdown进行关机操作。
如果确认重启，则调用PowerManagerService的lowLevelReboot函数，参数就是传递下来的reason，稍后分析。如果不是重启，即mReboot=false,那就是需要关机了，在shutdown函数中就能够知道。
frameworks/base/services/java/com/android/server/PowerManagerService.java
frameworks/base/services/jni/com_android_server_PowerManagerService.cpp
可以看到无论是关机还是重启，都是调用android_reboot来实现的，只是参数不一样而已。
system/core/libcutils/android_reboot.c
以reboot recovery为例，arg即为recovery,所在在第五步的时候会传入ANDROID_RB_RESTART2。到了android_reboot函数中，会看到这样的定义#ifdef RECOVERY_PRE_COMMAND，即属于重启前会执行的命令，如果定义了就会执行。
下面也是做了一些关机重启前的预处理工作，sync()作用是将缓存中的信息写入磁盘，以免程序异常结束导致文件被损坏，linux系统关机前会做几次这样的动作；而remount_ro()作用是通过调用emergency_remount()强制将文件系统挂载为只读，不再允许任何写入操作，同时会通过检查/proc/mounts的设备状态来确认是否当前的所有写入工作已经完成，这个检查过程是阻塞操作。
接下来才是对参数的解析处理：
1）普通重启 ANDROID_RB_RESTART， reason= RB_AUTOBOOT；
2）关机 ANDROID_RB_POWEROFF，无需reason，直接调用reboot进行关机；
3）带参数的特殊重启 ANDROID_RB_RESTART2， reason将为默认值-1
这里又出现一个#ifdef RECOVERY_PRE_COMMAND_CLEAR_REASON，如果定义了它，则无论上层传下来的参数是什么样的，最终都只是普通重启而已。定义它的方式是在BoardConfig.mk中加入TARGET_RECOVERY_PRE_COMMAND_CLEAR_REASON:= true，应该有厂商会喜欢这么做的，毕竟除了普通重启，都可能带给用户一定的风险。
最后会对reason进行一个检测，那么通过上边的分析，其实只有带参数的特殊重启才会为-1,而不等于-1的情况中有普通重启和关机，而关机已经自行解决了……所以，不等于-1的情况到了这里也只有普通重启了。最终这里就是区分普通重启与特殊重启的地方了。这里再插入一个问题，其他的几个cmd都是什么值呢？答案在bionic/libc/include/sys/reboot.h中：
reboot(reason)-> reboot(RB_AUTOBOOT)-> __reboot( LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_RESTART, NULL)
__reboot通过syscall来到内核bionic/libc/arch-arm/syscalls/__reboot.S
其被指定了一个固定的偏移量，在被调用的时候就是通过这个偏移量去内核中寻找对应的入口的，由此可见，内核中一定有着相同的定义，否则将不能成功调用。内核中对syscall偏移量的定义在内核源码中的arch/arm/include/a**/unistd.h，相关信息完全一致。
已经找到了内核中的对应映射，那么下一步就要去找寻真正的实现函数了，在include/a**-generic/unistd.h中可以找到内核对__NR_reboot的syscall函数映射，即
同时，能够发现如此温馨的一幕，内核已经指引我们下一步该去哪里寻找sys_reboot，即kernel/sys.c。
include/linux/syscalls.h
与__reboot的调用参数一致。
进入sys.c文件后，并没有找到名为sys_reboot的函数，而通过仔细查找，发现一个很有趣的函数，其定义为SYSCALL_DEFINE4(reboot, int, magic1, int, magic2, unsigned int, cmd, void __user*, arg)，对比__reboot的参数，能够符合。究竟是不是这个函数？
同样在include/linux/syscalls.h文件中，能够找到这样几个定义：
而pm_power_off为空的话，就把用户的关机命令转换为挂起：
arch/arm/kernel/process.c
pm_power_off= m**_pm_power_off;
SYSCALL_DEFINE4(reboot, int, magic1, int, magic2, unsigned int, cmd, void __user*, arg)
这个过程是用reboot_mutex互斥锁来进行保护的，以保证同一时间只可能有一个解析过程，避免冲突。
bionic/libc/include/sys/reboot.h中可以看到android定义的启动方式
RESTART
POWER_OFF
RESTART2
对框架进行赋值，qcom平台 845上已经不是这函数，自己查找
arm_pm_restart= m**_pm_restart;
下面是qcom实现，每个平台不同
可以在跟踪这个流程的过程中会发现，确实是有存在关机的相关接口的。那么关机该怎么用呢？
frameworks/base/services/java/com/android/serverBatteryService.java
重启方式：最后就是设定寄存器，Uboot解析不同寄存器的值进入不同的启动模式
recovery如果传下来的字符串是recovery那么，就在RTC寄存器里设置某个特定值，当uboot里读取RTC寄存器的时候如果获取了这个特定值，那就可以起recovery这个动作了。
Ref: https://blog.csdn.net/leerobin83/article/details/7162751
上面主要讲到流程，在实际开发中，主动调用系统开机关机如何做
(Ref: https://blog.csdn.net/luzhenrong45/article/details/42092007)
一.发送系统广播方式
二.通过init.rc启动系统服务来运行sh文件
三. Runtime调用Linux-shell
四. PowerManager reboot以及反射调用PowerManagerService shutdown
五．使用ShutdownThread（尝试不成功，但想法觉得可行）
Intent.java位于源码/frameworks/base/core/java/android/content/Intent.java下面
脚本方式，实际都是基于指令的
使用PowerManager或ShutdownThread都是基于关机流程
三、如何快速对android系统重启问题进行分析归类
电脑自动从启应该考虑的问题如下：一、软件方面 1．病毒“冲击波”病毒发作时还会提示系统将在60秒后自动启动。木马程序从远程控制你计算机的一切活动，包括让你的计算机重新启动。用360杀毒等杀毒清除病毒，木马，或重装系统。 2．系统文件损坏系统文件被破坏，如Win2K下的KERNEL32.DLL，Win98 FONTS目录下面的字体等系统运行时基本的文件被破坏，系统在启动时会因此无法完成初始化而强迫重新启动。解决方法：覆盖安装或重新安装。 3．定时软件或计划任务软件起作用如果你在“计划任务栏”里设置了重新启动或加载某些工作程序时，当定时时刻到来时，计算机也会再次启动。对于这种情况，我们可以打开“启动”项，检查里面有没有自己不熟悉的执行文件或其他定时工作程序，将其屏蔽后再开机检查。当然，我们也可以在“运行”里面直接输入“Msconfig”命令选择启动项。二、硬件方面 1．机箱电源功率不足、直流输出不纯、动态反应迟钝。用户或装机商往往不重视电源，采用价格便宜的电源，因此是引起系统自动重启的最大嫌疑之一。①电源输出功率不足，当运行大型的3D游戏等占用CPU资源较大的软件时，CPU需要大功率供电时，电源功率不够而超载引起电源保护，停止输出。电源停止输出后，负载减轻，此时电源再次启动。由于保护/恢复的时间很短，所以给我们的表现就是主机自动重启。②电源直流输出不纯，数字电路要求纯直流供电，当电源的直流输出中谐波含量过大，就会导致数字电路工作出错，表现是经常性的死机或重启。③CPU的工作负载是动态的，对电流的要求也是动态的，而且要求动态反应速度迅速。有些品质差的电源动态反应时间长，也会导致经常性的死机或重启。④更新设备（高端显卡/大硬盘/视频卡），增加设备（刻录机/硬盘）后，功率超出原配电源的额定输出功率，就会导致经常性的死机或重启。解决方法：现换高质量大功率计算机电源。 2．内存热稳定性不良、芯片损坏或者设置错误内存出现问题导致系统重启致系统重启的几率相对较大。①内存热稳定性不良，开机可以正常工作，当内存温度升高到一定温度，就不能正常工作，导致死机或重启。②内存芯片轻微损坏时，开机可以通过自检（设置快速启动不全面检测内存），也可以进入正常的桌面进行正常操作，当运行一些I/O吞吐量大的软件（媒体播放、游戏、平面/3D绘图）时就会重启或死机。解决办法：更换内存。③把内存的CAS值设置得太小也会导致内存不稳定，造成系统自动重启。一般最好采用BIOS的缺省设置，不要自己改动。 3．CPU的温度过高或者缓存损坏①CPU温度过高常常会引起保护性自动重启。温度过高的原因基本是由于机箱、CPU散热不良，CPU散热不良的原因有：散热器的材质导热率低，散热器与CPU接触面之间有异物（多为质保帖），风扇转速低，风扇和散热器积尘太多等等。还有P2/P3主板CPU下面的测温探头损坏或P4 CPU内部的测温电路损坏，主板上的BIOS有BUG在某一特殊条件下测温不准，CMOS中设置的CPU保护温度过低等等也会引起保护性重启。②CPU内部的一、二级缓存损坏是CPU常见的故障。损坏程度轻的，还是可以启动，可以进入正常的桌面进行正常操作，当运行一些I/O吞吐量大的软件（媒体播放、游戏、平面/3D绘图）时就会重启或死机。解决办法：在CMOS中屏蔽二级缓存（L2）或一级缓存（L1），或更换CPU排除。 4．AGP显卡、PCI卡（网卡、猫）引起的自动重启①外接卡做工不标准或品质不良，引发AGP/PCI总线的RESET信号误动作导致系统重启。②还有显卡、网卡松动引起系统重启的事例。 5.并口、串口、USB接口接入有故障或不兼容的外部设备时自动重启①外设有故障或不兼容，比如打印机的并口损坏，某一脚对地短路，USB设备损坏对地短路，针脚定义、信号电平不兼容等等。②热插拔外部设备时，抖动过大，引起信号或电源瞬间短路。 6．光驱内部电路或芯片损坏光驱损坏，大部分表现是不能读盘/刻盘。也有因为内部电路或芯片损坏导致主机在工作过程中突然重启。光驱本身的设计不良，FireWare有Bug。也会在读取光盘时引起重启。 7．机箱前面板RESET开关问题机箱前面板RESET键实际是一个常开开关，主板上的RESET信号是+5V电平信号，连接到RESET开关。当开关闭合的瞬间，+5V电平对地导通，信号电平降为0V，触发系统复位重启，RESET开关回到常开位置，此时RESET信号恢复到+5V电平。如果RESET键损坏，开关始终处于闭合位置，RESET信号一直是0V，系统就无法加电自检。当RESET开关弹性减弱，按钮按下去不易弹起时，就会出现开关稍有振动就易于闭合。从而导致系统复位重启。解决办法：更换RESET开关。还有机箱内的RESET开关引线短路，导致主机自动重启。 8.主板故障主板导致自动重启的事例很少见。一般是与RESET相关的电路有故障；插座、插槽有虚焊，接触不良；个别芯片、电容等元件损害。三、其他原因 1．市电电压不稳①计算机的开关电源工作电压范围一般为170V－240V，当市电电压低于170V时，计算机就会自动重启或关机。解决方法：加稳压器（不是UPS）或130－260V的宽幅开关电源。②电脑和空调、冰箱等大功耗电器共用一个插线板的话，在这些电器启动的时候，供给电脑的电压就会受到很大的影响，往往就表现为系统重启。解决办法就是把他们的供电线路分开。 2．强磁干扰不要小看电磁干扰，许多时候我们的电脑死机和重启也是因为干扰造成的，这些干扰既有来自机箱内部CPU风扇、机箱风扇、显卡风扇、显卡、主板、硬盘的干扰，也有来自外部的动力线，变频空调甚至汽车等大型设备的干扰。如果我们主机的搞干扰性能差或屏蔽不良，就会出现主机意外重启或频繁死机的现象。 3、交流供电线路接错有的用户把供电线的零线直接接地（不走电度表的零线），导致自动重启，原因是从地线引入干扰信号。 4．插排或电源插座的质量差，接触不良。电源插座在使用一段时间后，簧片的弹性慢慢丧失，导致插头和簧片之间接触不良、电阻不断变化，电流随之起伏，系统自然会很不稳定，一旦电流达不到系统运行的最低要求，电脑就重启了。解决办法，购买质量过关的好插座。 5.积尘太多导致主板RESET线路短路引起自动重启。四、部分实例 1. CPU二级缓存坏的实例一台几年前配置的兼容机：K6-2 200MHz CPU，采用VX-Pro+芯片组的主板，两根16MB 72线EDO内存， Windows 98操作系统。在出现蓝天白云画面后自动重启，安全模式同样无法进入，只能进入MS-DOS模式。笔者猜想由于内存条质量问题导致电脑重启的可能性较大，所以首先更换同型号内存条测试，故障依旧。再更换电源仍无法解决问题。排除到最后只剩下主板、CPU和显卡，试过显卡没有问题后，苦于找不到能安装K6-2 200MHz CPU的旧主板只能作罢。当时也怀疑过BIOS设置可能有误，试过恢复到缺省值，也未能解决问题。过了几天，再次摆弄电脑时，无意进入BIOS并将CPU Internal Cache一项设为Disable，保存退出后重启，系统竟然可以启动了！由此估计应当是CPU的缓存有问题，于是再将缓存设置为打开状态并启动电脑，果然系统又不能正常启动了。由于将缓存关闭后大幅度降低了CPU的性能，所以Windows 98在启动和运行程序时比以往慢了许多，最后换了一块CPU才算解决问题 2.电源故障的实例笔者上班的地方计算机每天都要开着（因为上网的人多），十天半月不关机是常事。在如此高的工作强度下，硬件设备的故障率也很高。故障现象：两台兼容机，一台CPU为Athlon XP 1700+，一台CPU为P4 1.7GHz，主机电源均为世纪之星电源。当计算机处于满负荷状态运行一段时间后（此时CPU使用率保持在100%，硬盘也在大量读写数据），经常性地自动重启。其中一台在挂接一块60GB硬盘和一块80GB硬盘时，出现供电不足的现象。故障分析处理：由于这两台计算机平时用于文档编辑、上网等一般工作时正常，只有进行大量计算时才出问题。开始怀疑是CPU温度过高所致，但检测表明温度正常。检查硬盘发现，其中一块硬盘出现了坏道，但是在更换硬盘重装系统后故障依旧，看来硬盘出现坏道很可能是计算机经常非正常重启导致的。在更换新电源后，故障消失。拆开两个旧电源，发现其中一个电源的两个相同型号的电解电容（3300μF/10V）顶端有黄褐色的颗粒状凝结物，另一个电源的两个不同型号的电解电容（1000μF/16V，3300μF/16V）顶端也有黄褐色的颗粒状凝结物，这是电容被击穿漏液所导致的。在电子市场花钱购买了相同型号的电容更换后，经测试均恢复正常。这里提醒一下，千万别把电容正负极接反了！事后分析发现，笔者单位电网常因检修或用电不当突然停电，导致配件上的电容被击穿，一块主板也曾经在一次突然停电后**，检查发现几个大电解电容被击穿漏液，更换电容后恢复正常。 3.显卡接触不良的实例故障现象：朋友电脑配置为明基BenQ 77G的显示器、技嘉8IRX的主板、P4 1.6G CPU、80G硬盘、小影霸速配3000显卡、全向极云飞瀑内猫、主板自带AC97的声卡。因装修房子，要挪动电脑，就把电脑后的连线都拆了。后来自己接好线后，电脑却怎么也启动不起来了。电脑自检正常，闪过主板LOGO后，出现WINDOWS 98启动画面，接着光标闪动，一切很正常，可是约摸着快要进入系统的时候，电脑突然“嘀”的一声重启动了，重新启动几次都是这样。故障分析：笔者的这位朋友是个纯纯的“菜鸟”，初步判断可能是一般性的接线问题，很有可能是鼠标和键盘接反导致的。先是检查了一遍电脑接线，没有问题，会不会是接线松动呢？重新把所有电脑连线接了一遍故障依旧。启动时选安全模式能进入系统，运行也正常，重启后进入BIOS里查看CPU温度，在正常范围内，排除因CPU过热导致的重启。朋友也没安装新的硬件，故排除电源供电不足导致重启现象。引起故障的原因可能有以下四个方面：一是软件冲突；二是显示分辨率或刷新率设置高于额定的值；三是显卡和其它硬件冲突、或驱动程序问题导致；四是显卡故障。故障排除：问朋友发生故障前对机器进行了哪些操作？朋友说拆机前一直都用的很好，没有安装过新软件。没有蛛丝马迹，只有从上面的四个可能的故障原因里排查。重启后，进入安全模式，运行msconfig命令，把启动项里不是操作系统所必需的项都去掉，重启后，故障依旧。看来不是软件安装导致的。接下来看看是不是分辨率和刷新率过高，在安全模式下，将监视器删除，重启动，故障依旧。最后问题都集中在显卡身上了。再次进入安全模式，删除显卡驱动程序，重启动后，跳过显卡驱动安装，能进入正常启动模式，看来故障是驱动程序的问题或显卡与其它硬件冲突引起的了。下载一个新的驱动看能不能解决这个问题呢？拨号上网，机器突然又重启了，难道猫也坏了吗？这可怎么办，真的山穷水复了吗？这台电脑是因为拆了以后就启不起来了，显卡和猫总不会因搬一下机器就坏了吧？想到搬运机器，是不是因为拆装电脑时把显卡碰松导致接触不良而引起的故障呢？抱着最后试一试的心理，打开机箱，将显卡和猫拔出重新插紧安好，装好显卡驱动，重启，竟然看到美丽的桌面了，试着拨号，也没问题了，故障排除了。原来故障是显卡接触不良的导致。
关于android系统重启分析过程和如何快速对android系统重启问题进行分析归类的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。
