Battery Historian2.0使用过程中遇到的一些问题
could not parse aggregated battery stats
- 之前有一篇文章Android5.0系统耗电分析中提到用Battery Historian来分析耗电问题，但是在最近几次用Battery Historian2.0分析的时候点击Submit按钮analyse成功后，进入界面的报错“Note: Could not parse aggregated battery stats.”，点击error按钮，出现如下提示：
也就是说你查看不了Battery Historian2.0视图，可能在解析的时候报错了，那么我们可以不查看Battery Historian2.0的分析视图，只查看Battery Historian1.0的，可以进入…\battery-historian\scripts目录，在这里面你就看到了“historian.py”这个就是把bugreport.txt转化成html文件的py实现，然后在这里目录打开cmd之下一下命令：python historian.py -a bugreport.txt > battery.html就可以看到在这个目录下生成了html文件，然后用谷歌浏览器直接打开html文件即可查看耗电的一些信息，但是个人感觉Battery Historian1.0的耗电分析视图没有2.0来的详细和直观，以下为截图：
Battery Historian1.0耗电分析视图：
但是我对这个问题“could not parse aggregated battery stats”感觉特别不爽，因为我用我们android系统5.0（MTK提供）的user debug版本手表（root）都可以正常使用，为啥一换到root过的手机，还是google官方的6.0系统就不行了呢？于是乎，一顿google，记住。一定要用google，不要用百度，用百度你用换搜索不到重点。在这里我找到灵感：could not parse aggregated battery stats，这里面有很多Battery Historian的issu问答，我们关注的是：
- Definitely not server-side, it means your bugreport is invalid. Yes, a bug in the ROM is likely the cause. It may be possible to fix the report in a text editor though. There will likely be two lines with “,vers,” lines in them. If you delete one of them the first error should disappear. Same should be the case for “,bt,”. If you look for lines with that in it there should be two of them. Delete one and things might work.（大概的意思是说bugreport文件不可用，可能是rom的一个bug导致的，那么要解决这个bug就找到bugreport.txt文件下的“,vers,”发现有两个这个东西，那么删除其中一个，然后再搜“,bt,”也有两个，也删除其中一个，当然，删除哪一个？）
- It definitely helps for the errors, even though it doesn’t fix the fact I only see the Historian-tab. I now get a new error about ‘global network field already exists’, I’ll try to fix this in the same way. I’ll also try another nightly, maybe this is an incidental bug.（当你删除了一个“,vers,”后，你会发现又报错“global network field already exists”）
- If there are a lot of these you can look through this. The “,bt,” and “,vers,” are section identifiers. If you’re seeing “global network field already exists”, you should look for “,gn,”.
I’ll also add that you should probably delete the first line in the case of battery stuff and the second line in the case of version. I think they should probably be ordered chronologically but really there shouldn’t be multiple at all so who knows.（针对2中问提，找到“,bt,”也发现有两个，删除其中一个，这个“,bt,”应该是紧跟着刚才删除的“,vers,”，“,gn,”也是如此，也要删除多余的那一行）
至此：按照如上三个步骤我们已经在bugreport.txt文件中的这三行内容：
9,0,i,vers,15,133,MOB31K,MOB31K
9,0,l,bt,0,0,0,238067037,173720359,1483685378198,0,0
9,0,l,gn,0,0,0,0,0,0,0,0很可惜的是，依然报错：
但是很明显，报错变少了，说明我们以上做的修改还有有点用的，于是我预测是不是还有些东西没有删除掉，经过上面的一个过程下来，隐约感觉到是不是由于bugreport.txt文件里面有些参数重复了导致视图解析不出来，例如“,vers,”，“,bt,”，“,gn,”都是重复的，然后删除掉一行，继续google，证实了这个问题：Battery Historian is complaining because it only expects one log per file.，于是我就再去bugreport.txt文件中找，是不是还有类似的参数没有删除呢？在刚才删除的那三行下面我看到这么一些东西：
9,0,i,vers,15,133,MOB31K,MOB31K
9,0,l,bt,0,0,0,238067037,173720359,1483685378198,0,0
9,0,l,gn,0,0,0,0,0,0,0,0
// 以上三行是已经删除的
9,0,l,gwfl,0,0,0,0,0,0
9,0,l,gble,0,0,0,0
9,0,l,m,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
9,0,l,br,0,0,0,0,0
9,0,l,sgt,0,0,0,0,0
9,0,l,sst,0
9,0,l,sgc,0,0,0,0,0
9,0,l,dct,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
9,0,l,dcc,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
9,0,l,wst,0,0,0,0,0,0,0,0
9,0,l,wsc,0,0,0,0,0,0,0,0
9,0,l,wsst,0,0,0,0,0,0,0,0,0,0,0,0,0
9,0,l,wssc,0,0,0,0,0,0,0,0,0,0,0,0,0
9,0,l,wsgt,0,0,0,0,0
9,0,l,wsgc,0,0,0,0,0
9,0,l,dc,0,0,0,0奇怪的是后面跟的参数都是0，觉得不太对劲，找到那个没有删除的“,bt,”和“,bt,”看了下：
9,0,l,bt,0,4034182,3304371,6220490,5490679,1483917201211,1405309,675499
9,0,l,gn,7688100,795463,27082229,2909975,7858,7960,26650,28479
9,0,l,gwfl,4034182,4034182,1679358,29311,32558,0
9,0,l,gble,0,0,0,0
9,0,l,m,2628873,0,5225,449536,1002609,34,2620589,0,12,0,0,0,0,19,25225
9,0,l,br,468770,582304,1345121,154945,77733
9,0,l,sgt,2612,43469,782137,2361194,844770
9,0,l,sst,0
9,0,l,sgc,2,7,44,157,160
9,0,l,dct,2910827,0,0,0,0,0,0,0,0,0,0,0,0,1123355,0,0,0
9,0,l,dcc,2,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0
9,0,l,wst,0,0,0,0,0,0,0,0
9,0,l,wsc,0,0,0,0,0,0,0,0
9,0,l,wsst,0,149908,0,0,880862,0,15338,1043,13159,104,2973768,0,0
...后面太长了，这里就省略了...其实“,vers,”，“,bt,”和“,bt,”都是在—— CHECKIN BATTERYSTATS (dumpsys batterystats -c) ——下的，只不过这里这三行并不连续，中间穿插一大段数据内容，而刚才删除的那三行却是连续的，而且后面带的参数都是0，经过比较发现，后面带的参数本应该是uid，进程名等参数，这些参数是不可能都为0的所以就猜测刚才删除的那些数据可能是异常数据，也许就是这里导致视图分析报错，于是就把那一整段都全部删除：
9,0,i,vers,15,133,MOB31K,MOB31K
9,0,l,bt,0,0,0,238067037,173720359,1483685378198,0,0
9,0,l,gn,0,0,0,0,0,0,0,0
9,0,l,gwfl,0,0,0,0,0,0
9,0,l,gble,0,0,0,0
9,0,l,m,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
9,0,l,br,0,0,0,0,0
9,0,l,sgt,0,0,0,0,0
9,0,l,sst,0
9,0,l,sgc,0,0,0,0,0
9,0,l,dct,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
9,0,l,dcc,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
9,0,l,wst,0,0,0,0,0,0,0,0
9,0,l,wsc,0,0,0,0,0,0,0,0
9,0,l,wsst,0,0,0,0,0,0,0,0,0,0,0,0,0
9,0,l,wssc,0,0,0,0,0,0,0,0,0,0,0,0,0
9,0,l,wsgt,0,0,0,0,0
9,0,l,wsgc,0,0,0,0,0
9,0,l,dc,0,0,0,0然后保存下bugreport.txt，在去submit分析，发现居然成功的显示出视图了：
到这里有两个tab页面，一个是2.0的，一个是1.0的，1.0的tab显示会被下面的覆盖掉，而1.0关于wake lock唤醒信息比较详细，所以可以用python historian.py -a bugreport.txt > battery.html命令单独转换生成1.0的分析视图，这个上面已经提及，好啦，问题解决！