小米稳定版安卓os异常放电怎么办?这个系统耗电占百分之38
发布网友
发布时间：2022-05-11 22:33
共1个回答
热心网友
时间：2023-10-23 06:31
2.关机拔SD卡再开机测试：无效，android os耗电依旧
3.测试2后再插入测试：无效，不解释
好吧，这个问题已经和SIM卡关系很大了，但是之前也做过换若干张SIM卡的测试，无效。唯一有待测试的是，我手头能找到的SIM卡，从32K到128K的都是带SIM卡工具包的，现在就算补卡，好像也补不到那种没有工具包的老卡了，这事非常纠结……
那么会不会真的就是高通内核关于mmc方面驱动的问题呢，拿着小米没法测试，只好等传说中的新内核版本MIUI升级了才知道了……
--------------------------------------------
2月5日，持续测试中。为了方便大家研究，把现在定位的问题范围和测试方法介绍一下。
目前确定不会发生android os异常耗电的情况有两种：
1.飞行模式
2.充电时（电脑和充电器都可以）
基于xda-developers论坛的帖子和其他分析，确定不正常耗电是因为android os在待机时不断唤醒设备造成的。至于具体是什么子进程在不断让android os工作，可以通过wake lock的使用情况来确定。所以安装模拟终端，用take wakelock的方式得到/proc/wakelock文件，然后进行查看，结果数次查看的结果都是mmc_delayed_work进程非常频繁的使用wake lock。（1小时5000次以上）然后重启在充电和飞行模式下做同样的测试，结果mmc_delayed_work进程使用wake lock的次数几乎可以忽略（只有几次），据此基本可以确定，是mmc_delayed_work在不插电的情况下工作不正常，不断请求CPU资源，导致了android os一直唤醒待机时的设备，造成异常耗电。此问题基本上和谷歌服务什么的没任何关系。
但是这里有两个问题我还没有搞清楚：
1.mmc_delayed_work到底是个什么操作或者进程。从名字和百度来看，是和SD卡驱动有关的东西，没找到详细解释。如果说是SD卡造成的话，前前后后我也试过几次去掉SD卡或者卸载SD卡的耗电测试，android os的异常耗电并没有改善。（从耗电表可以看到，android os此时依旧在待机时占用CPU）求大神解释一下mmc_delayed_work到底是啥？
2.飞行模式为什么没有异常。如果说充电时mmc_delayed_work不请求CPU资源，这个还好理解，但是飞行模式为什么android os也不耗电，并且mmc_delayed_work表现正常，我实在想不明白。我曾经试过把wifi，gps，数据上下传都关了，按说此时除了还有射频，和飞行模式也没太大区别了吧，但还是耗电。特别是飞行模式时就算手动再把wifi和gps打开也没事……难道基带也和SD卡有关，要调用mmc_delayed_work？？？这也太那啥了吧……所以第二个问题就是，飞行模式和“关闭wifi，gps，数据通道”除了有射频以外，到底还有什么区别？
现在还在充电，充满电以后的下一步的测试计划：
1.重新做飞行模式的wakelock统计测试：确定飞行模式的确没有问题
2.重新做拔掉SIM卡的wakelock统计测试：确定不是SIM卡的问题
3.先关机，拔SD卡，开机测试，如果正常，直接插SD卡再测试，然后直接拔SD卡测试：确定是否是SD卡的问题，以及会不会存在一种情况，即的确是SD卡的问题，但如果此问题出现了，那么就算是拔掉，问题也不会消失
最后还有个比较奇怪的现象，小米会时不时的自己设定充电时屏幕保持唤醒，这和上面的问题是否有关呢？
-------------------------------------------------------
2月4日，由于耗电问题重现了，并且这次怎么也搞不定，继续去xda-developers找英文资料来学习，其中关于wakelock不正常唤醒方面的各路大神分析给了我不少启发，同时我也在做一些测试，比如通过终端来分析wakelock到底是被哪些进程唤醒使用，关于这个测试的目的和意义，可以参考以下这篇帖子：
发不了#此帖对我帮助很大，有时间会翻译后发过来。
根据这篇帖子提到的分析方法，目前我所知道的是不正常的唤醒大部分是由mmc delayed work造成的，占据了所有唤醒wakelock的90%以上。可是在网上的中文材料中只看到有一篇如何定位华为U8800的相同问题的，但没说如何解决。求大神赐教。
但是目前最让我没法接受的是在另外一篇帖子中（帖子链接：发不了）有一篇谷歌技术员工的回复，如下：
Comment 261 by , Apr 20 (6 days ago)
@nsbu: The message about "'uart_clk' not off" looks alarming but is actually harmless -- this clock doesn't prevent the SoC from suspending, and this message always appears at suspend time in Android kernels running on Qualcomm MSM chipsets. (If other clocks were listed here then those could represent a problem.)
Similar to a previous report on a T-Mobile myTouch 4G discussed here, the data logged on wakeup reasons needs to be interpreted by the OEM that has the hardware specs for the phone and the Qualcomm radio firmware source that generates some of that info. HTC is the OEM for that phone; their support site is 发不了链接 . Or try the T-Mobile support site at 发不了链接, they seem to sell this device under their own brand.
In case anyone's confused, it's recognized that some phones do have battery life problems that stem from: (a) not properly suspending to low-power states and, (b) continually attempting to suspend and resume, burning CPU in the suspend thread. The causes tend to be e to devices continually generating interrupts (that might not be properly handled by device drivers and hence continue to be generated), or drivers rejecting suspend for conditions that should be short-lived but instead persist for long time periods. In many cases the drivers involved are written by OEMs and Google does not have any knowledge of the drivers or devices causing the problem -- the folks who made the phone need to take a look.
Problems with the Google Nexus One described in another issue referenced in previous comments fall in the same category, and in that case we have the hardware and the design info needed to diagnose the problem (wifi driver interrupt handling problem), and a fix is on the way.
