[20191207][Android10]高德地图导航功耗场景优化

2024-02-09 19:38
文章标签 优化 场景 地图 导航 高德 android10 功耗 20191207

本文主要是介绍[20191207][Android10]高德地图导航功耗场景优化，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

摘要

在这里插入图片描述

1. 测试现象

1.1 EPRODUCING PROCEDURES:

1.进入高德 Map(data) wifi)，起点为自己所在位置，搜索一个位置进行导航；
2.等待30秒后开始记录电流，持续5分钟；
3.按Power键，灭屏待机；
4.手机灭屏15秒后开始记录电流，持续3分钟；

1.2 Test numberSummary
设备高德地图导航
测试机461.82 mA
对比机369.13 mA

2.分析

2.1 拔屏以扣除LCD影响
设备高德地图导航
测试机+450nit带屏幕导航405.18 mA
对比机+450nit带屏幕导航380.11
测试机+拔屏174.45 mA
对比机+拔屏131.76 mA

从上述看扣掉 LCD 同样有功耗差异，即LCD 关系不大

注意：导航场景：一般是带导航语音，即需要考虑Audio的影响

2.2 设计实验找出问题差异

以下是我自己设计的实验方法

1).对比机与测试机的GPS搜星实验
  1. GPS puls 搜星查看，我apk放到附件中
  2. 只开启GPS+飞行模式
  3. 尽量2台机器相同环境下同时测试
    4.放置5分钟后，apk主界面截图
GPS plus+工具搜星情况
对比机无GPS信号增强器观察卫星数量和信号强度
对比机有GPS信号增强器观察卫星数量和信号强度
测试机无GPS信号增强器观察卫星数量和信号强度
测试机有GPS信号增强器观察卫星数量和信号强度

实验发现：基本无差异，故 GPS 单体应该是没问题

2).导航电流测试
  1. 最暗亮度测试，避免扣掉屏幕带来的影响
  2. 静音+插入耳机，去除导航语音带来的影响
  3. 尽量2台机器相同环境下同时测试
测试项目测试机器(mA)对比机(mA)
case 1 静态HOME界面固定墙纸_飞行模式65.2168.19
case 2网络定位条件，高德导航测试：只保持WiFi连接，飞行模式87.6388.95
case 3 GPS定位条件，高德导航测试：开启GPS+插卡+WiFi 连接147.63120.71
case 4 GPS定位条件，高德导航测试：GPS增强器+开启GPS+插卡+WiFi 连接169.64153.48
  • case 1 目的: 对比相同亮度下是否存在差异
  • case 2 目的: 查看是否网络定位有问题
  • case 3 目的：查看是否GPS定位存问题
  • case 3 目的: 查杀是否与GPS信号强度有关，因为室内是GPS信号比较弱

上述：

  • case 1 说明测试机和对比机亮屏下相同亮度的测试电流是基本一致，即基础的系统功耗是相同的
  • case 2 说明网络定位是OK的，说明相同APK在不同机器测试，运行是后台也基本保持一致,且说明如果GPS不开启则是导航是好的；
  • case 3、case 4 说明GPS开启，会带来导航功耗影响
3).GPS单体功耗

这块数据没有，故需要让硬件提供：

测试步骤：

Wi-Fi Off, GPS ON, BT OFF, NFC OFF, Fly mode ON.
灭屏，等待1min，记录平均电流，即是打开GPS时的电流。
在上述的条件时，记录下可以稳定复现的最小电流值，即是 GPS floor current.
Average current when GPS navigation working：Step1:通过下拉菜单，打开飞行模式，打开位置服务；
Step2:进入工程模式 adb shell am start -n com.mediatek.ygps/com.mediatek.ygps.YgpsActivity；
Step3:进入Location->YGPS->Enable in BG.(need restart)，重启后再次进入该界面;
Step4:关闭屏幕，待电流稳定，测试3分钟，记录电流A1；
Step5:通过下拉菜单，关闭位置服务；
Step6:进入工程模式，进入Location->YGPS，再回到YGPS界面；
Step7:关闭屏幕，待电流稳定，测试3分钟，记录电流A2；
GPS ON=A1-A2

由于不知道 ygps 源码，通过测试步骤基本猜到，主要是测试GPS开启电流和工作电流，相当于高德地图的定位场景，非导航场景

测试数据：

设备平均电流
测试机34mA
对比机34mA

从上面数据看，GPS的工作电流是基本一致的，即GPS单体是OK的

这就奇怪了，GPS单体是好的，为什么导航一开GPS就存问题呢？还需要再排除干扰。例如以下干扰：

  1. WiFi 环境因素
  2. 4G 插卡因素
  3. 应用启动后会进行页面、地图数据、配置文件下载
  4. 测试过程中，如果网络发生变化，热点不稳定
4).离线导航
  1. Wi-Fi Off, GPS ON, BT OFF, NFC OFF, Fly mode ON，排除WiFi带来的干扰
  2. 最小亮度
  3. 使用 what_temp apk抓CPU数据
  4. 静音插耳机
  5. 使用高德离线地图导航
设备测试机对比机
高德地图定位界面55.13mA50.13mA
高德地图导航界面83.00mA60.49mA

上述查看：

  1. 现象复现，即排除了Wi-Fi Off, GPS ON, BT OFF, NFC OFF, Fly mode影响，即wifi、4G都没问题
  2. 定位场景差异不大，导航场景差异比较大。
  3. 需要查看高德地图定位细节
2.3 高德地图的dump信息

dumpsys location|grep -B 2 “com.autonavi.minimap”

Tokyo_Lite:/ $ dumpsys location|grep -B 2 "com.autonavi.minimap"Battery Saver Location Mode: NO_CHANGELocation Listeners:Reciever[35eed63 listener UpdateRecord[passive com.autonavi.minimap(10167 foreground) Request[POWER_NONE passive fastest=0] null], isNeedBgGpsRestrict false monitoring location: true]Reciever[fe54b41 listener UpdateRecord[passive android(1000 foreground) Request[POWER_NONE passive fastest=+30m0s0ms] null], isNeedBgGpsRestrict false monitoring location: true]Reciever[a523146 listener UpdateRecord[passive com.autonavi.minimap(10167 foreground) Request[POWER_NONE passive fastest=+1s0ms] null], isNeedBgGpsRestrict false monitoring location: true]Reciever[4698940 listener UpdateRecord[passive android(1000 foreground) Request[POWER_NONE passive fastest=0] null], isNeedBgGpsRestrict false monitoring location: false]Reciever[3e939ea listener monitoring location: false]Reciever[a629ca9 listener UpdateRecord[gps com.autonavi.minimap(10167 foreground) Request[ACCURACY_FINE gps requested=+1s0ms fastest=+1s0ms] null], isNeedBgGpsRestrict false monitoring location: true]Active Records by Provider:gps:UpdateRecord[gps com.autonavi.minimap(10167 foreground) Request[ACCURACY_FINE gps requested=+1s0ms fastest=+1s0ms] null], isNeedBgGpsRestrict false
--UpdateRecord[passive android(1000 foreground) Request[POWER_NONE passive fastest=0] null], isNeedBgGpsRestrict falseUpdateRecord[passive android(1000 foreground) Request[POWER_NONE passive fastest=+30m0s0ms] null], isNeedBgGpsRestrict falseUpdateRecord[passive com.autonavi.minimap(10167 foreground) Request[POWER_NONE passive fastest=0] null], isNeedBgGpsRestrict falseUpdateRecord[passive com.autonavi.minimap(10167 foreground) Request[POWER_NONE passive fastest=+1s0ms] null], isNeedBgGpsRestrict false
--Active GnssNavigationMessage Listeners:Active GnssStatus Listeners:5600 10167 com.autonavi.minimap: false5600 10167 com.autonavi.minimap: false5600 10167 com.autonavi.minimap: false5766 10167 com.autonavi.minimap: falseHistorical Records by Provider:android: passive: Min interval 0 seconds: Max interval 1800 seconds: Duration requested 99 total, 99 foreground, out of the last 99 minutes: Currently activecom.autonavi.minimap: passive: Min interval 0 seconds: Max interval 1 seconds: Duration requested 2 total, 2 foreground, out of the last 98 minutes: Currently activecom.autonavi.minimap: gps: Interval 1 seconds: Duration requested 2 total, 2 foreground, out of the last 98 minutes: Currently active

查看高德地图的dump信息，我们基本知道高德地图申请了哪些定位：

  1. GPS 定位，定位间隔1秒一个
    Reciever[a629ca9 listener UpdateRecord[gps com.autonavi.minimap(10167 foreground) Request[ACCURACY_FINE gps requested=+1s0ms fastest=+1s0ms] null], isNeedBgGpsRestrict false monitoring location: true]
  2. passive 定位
    Reciever[a523146 listener UpdateRecord[passive com.autonavi.minimap(10167 foreground) Request[POWER_NONE passive fastest=+1s0ms] null], isNeedBgGpsRestrict false monitoring location: true]
  3. 监听了 GnssStatus 数据
    Active GnssStatus Listeners:
    5600 10167 com.autonavi.minimap: false
    5600 10167 com.autonavi.minimap: false
    5600 10167 com.autonavi.minimap: false
    5766 10167 com.autonavi.minimap: false
2.4 分析高德地图定位和导航调用的函数

我们在dump locaiton已经知道高德地图会申请使用GPS，并且定位间隔为1秒，故不需要在

1) LocationManager 埋点
public class LocationManager {public boolean addNmeaListener(@NonNull OnNmeaMessageListener listener, @Nullable Handler handler) {boolean result;// huazhi.suif("true".equals(SystemProperties.get("persist.sys.tct.addNmeaListener.debug", "false"))) {Log.e(TAG, "skip addNmeaListener");return false;}// huazhi.su@RequiresPermission(ACCESS_FINE_LOCATION)public boolean registerGnssStatusCallback(@NonNull GnssStatus.Callback callback, @Nullable Handler handler) {boolean result;synchronized (mGnssStatusListeners) {// huazhi.suif("true".equals(SystemProperties.get("persist.sys.tct.registerGnssStatusCallback.debug", "false"))) {if("com.autonavi.minimap".equals(mContext.getPackageName())) {Log.e(TAG, "skip registerGnssStatusCallback  packageName:" + mContext.getPackageName());}return false;}// huazhi.su
2) 查看导航场景高德地图使用的sdk情况
场景API接口
定位场景requestLocationUpdates、registerGnssStatusCallback
导航场景requestLocationUpdates、registerGnssStatusCallback、addNmeaListener

即导航场景比定位场景多了 addNmeaListener

12-06 14:10:44.728  3716  3716 W System.err:    at android.location.LocationManager.addNmeaListener(LocationManager.java:2046)
12-06 14:10:44.736  3716  4034 W System.err:    at android.location.LocationManager.registerGnssStatusCallback(LocationManager.java:1944)locationManager.registerGnssStatusCallback(new GnssStatus.Callback() {@Overridepublic void onSatelliteStatusChanged(GnssStatus status) {super.onSatelliteStatusChanged(status);Log.d(TAG, "onSatelliteStatusChanged");}});locationManager.addNmeaListener(new OnNmeaMessageListener() {@Overridepublic void onNmeaMessage(String message, long timestamp) {Log.d(TAG, "onNmeaMessage message :" + message + ", timestamp :" + timestamp);sendRequestWithHttpClient();}});locationManager.requestLocationUpdates(GPS_PROVIDER, 1000, 0, mMyLocationListener);
  1. 之前的测试GPS单体的功耗基本是 requestLocationUpdates 这个接口的功能，故 基本问题不大
  2. 且导航和定位场景中，导航场景存在和定位场景不同，故我们可以单独屏蔽掉 registerGnssStatusCallback、addNmeaListener

3. 问题根源研究

3.1 禁止监听 GnssStatus 和 Nmea
测试项平均电流备注
离线导航133异常电流波形
离线导航+禁止监听 GnssStatus120异常电流波形
离线导航+禁止监听 Nmea110异常电流波形
离线导航+禁止监听 Nmea + GnssStatus100正常电流波形

首先我们看下异常电流：特征是一秒钟一个波峰，且单个异常波形平均电流就有166mA，基本功耗不被拉大才怪
异常电流

上述说明：监听 Nmea + GnssStatus 会带来功耗，但是肯定要给第三方应用正常使用这个数据

3.1 拦截 GnssStatus 和 Nmea

拦截位置

package com.android.server.location;public class GnssLocationProvider ...{@NativeEntryPoint // libgnss.so上报private void reportNmea(long timestamp) {// 新增拦截...// 对应上层的：public void onNmeaMessage(String message, long timestamp) 方法...}@NativeEntryPoint // libgnss.so上报private void reportSvStatus(int svCount, int[] svidWithFlags, float[] cn0s,// 新增拦截...// 对应上层的：public void onSatelliteStatusChanged(GnssStatus status) { 方法...}}
测试项平均电流备注
离线导航133异常电流波形
离线导航+拦截 GnssStatus 数据上报123异常电流波形
离线导航+拦截 Nmea 数据上报110异常电流波形
离线导航+拦截 Nmea + GnssStatus 数据上报100正常电流波形

拦截测试也说明 Nmea + GnssStatus 有影响，难道高德地图会收到数据做一些耗电操作，还是对比机有优化呢？
由于高德地图、对比机没有源码，所以我们无法知道，从源码一个函数一个函数地分析。看是否源代码有问题，即了解GPS的Nmea + GnssStatus上报给上层的源码

4. 源码分析并新增日志

4.1 源码数据通路新增日志

例如 Nmea 数据如何上报给上层apk，在这个数据传递的通路新增日志，每个函数调用的地方都加

1.数据源头-------------------------------------------------
package com.android.server.location;@NativeEntryPointprivate void reportNmea(long timestamp) {if (!mItarSpeedLimitExceeded) {int length = native_read_nmea(mNmeaBuffer, mNmeaBuffer.length);String nmea = new String(mNmeaBuffer, 0 /* offset */, length);mGnssStatusListenerHelper.onNmeaReceived(timestamp, nmea);}}2.-------------------------------------------------
public abstract class GnssStatusListenerHelper extends RemoteListenerHelper<IGnssStatusListener> {public void onNmeaReceived(final long timestamp, final String nmea) {// 遍历 addNmeaListener 监听数量，例如高德地图使用了2个，一个定位注册的，一个导航场景注册的foreach((IGnssStatusListener listener, CallerIdentity callerIdentity) -> {// 检查是否与定位权限if (hasPermission(mContext, callerIdentity)) {logPermissionDisabledEventNotReported(TAG, callerIdentity.mPackageName, "NMEA");return;}// 消息传递到上层listener.onNmeaReceived(timestamp, nmea);});}
}
3.-------------------------------------------------
public class LocationManager {@Overridepublic void onNmeaReceived(long timestamp, String nmea) {...mGnssHandler.obtainMessage(NMEA_RECEIVED).sendToTarget();...}for (Nmea nmea : mNmeaBuffer) {// 数据给上层mGnssNmeaListener.onNmeaMessage(nmea.mNmea, nmea.mTimestamp);}
4.2 现象发现
1）日志大量打印，这里1秒钟70组数据从底层上报出来，都需要经过上述的函数，简直是太频繁
01-01 00:04:54.516  3740  4447 E LocationManager: skip onNmeaReceived: nmea$GNGGA,160454.011,8960.0000,N,00000.0000,E,0,0,,137.0,M,13.0,M,,*5F
01-01 00:04:54.516  3328  4561 E LocationManager: skip onNmeaReceived: nmea$GNGGA,160454.011,8960.0000,N,00000.0000,E,0,0,,137.0,M,13.0,M,,*5F
01-01 00:04:54.518  3328  4561 E LocationManager: skip onNmeaReceived: nmea$GNGGA,160454.011,8960.0000,N,00000.0000,E,0,0,,137.0,M,13.0,M,,*5F
01-01 00:04:54.519  3740  4447 E LocationManager: skip onNmeaReceived: nmea$GPGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*30
01-01 00:04:54.520  3328  4561 E LocationManager: skip onNmeaReceived: nmea$GPGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*30
01-01 00:04:54.522  3328  4051 E LocationManager: skip onNmeaReceived: nmea$GPGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*30
01-01 00:04:54.522  3328  4561 E LocationManager: skip onNmeaReceived: nmea$GPGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*30
01-01 00:04:54.522  3740  4447 E LocationManager: skip onNmeaReceived: nmea$GLGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*2C
01-01 00:04:54.524  3328  4561 E LocationManager: skip onNmeaReceived: nmea$GLGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*2C
01-01 00:04:54.524  3328  4051 E LocationManager: skip onNmeaReceived: nmea$GLGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*2C
01-01 00:04:54.526  3328  4051 E LocationManager: skip onNmeaReceived: nmea$GLGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*2C
01-01 00:04:54.526  3740  4447 E LocationManager: skip onNmeaReceived: nmea$BDGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*21
01-01 00:04:54.527  3328  4051 E LocationManager: skip onNmeaReceived: nmea$BDGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*21
01-01 00:04:54.527  3328  4051 E LocationManager: skip onNmeaReceived: nmea$BDGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*21
01-01 00:04:54.527  3328  4561 E LocationManager: skip onNmeaReceived: nmea$BDGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*21
01-01 00:04:54.528  3740  4447 E LocationManager: skip onNmeaReceived: nmea$GAGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*21
01-01 00:04:54.529  3328  4561 E LocationManager: skip onNmeaReceived: nmea$GAGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*21
01-01 00:04:54.529  3328  4051 E LocationManager: skip onNmeaReceived: nmea$GAGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*21
01-01 00:04:54.529  3328  4051 E LocationManager: skip onNmeaReceived: nmea$GAGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*21
01-01 00:04:54.531  3740  4447 E LocationManager: skip onNmeaReceived: nmea$GPGSV,1,1,0*49
01-01 00:04:54.531  3328  4051 E LocationManager: skip onNmeaReceived: nmea$GPGSV,1,1,0*49
01-01 00:04:54.531  3328  4561 E LocationManager: skip onNmeaReceived: nmea$GPGSV,1,1,0*49
01-01 00:04:54.533  3740  4447 E LocationManager: skip onNmeaReceived: nmea$GLGSV,1,1,0*55
01-01 00:04:54.533  3328  4561 E LocationManager: skip onNmeaReceived: nmea$GLGSV,1,1,0*55
01-01 00:04:54.534  3328  4051 E LocationManager: skip onNmeaReceived: nmea$GPGSV,1,1,0*49
01-01 00:04:54.534  3328  4051 E LocationManager: skip onNmeaReceived: nmea$GLGSV,1,1,0*55
01-01 00:04:54.535  3328  4051 E LocationManager: skip onNmeaReceived: nmea$GLGSV,1,1,0*55
01-01 00:04:54.535  3740  4447 E LocationManager: skip onNmeaReceived: nmea$BDGSV,1,1,0*58
01-01 00:04:54.536  3328  4051 E LocationManager: skip onNmeaReceived: nmea$BDGSV,1,1,0*58
01-01 00:04:54.536  3328  4561 E LocationManager: skip onNmeaReceived: nmea$BDGSV,1,1,0*58
01-01 00:04:54.536  3328  4561 E LocationManager: skip onNmeaReceived: nmea$BDGSV,1,1,0*58
01-01 00:04:54.537  3740  4447 E LocationManager: skip onNmeaReceived: nmea$GAGSV,1,1,0*58
01-01 00:04:54.537  3328  4561 E LocationManager: skip onNmeaReceived: nmea$GAGSV,1,1,0*58
01-01 00:04:54.538  3328  4051 E LocationManager: skip onNmeaReceived: nmea$GAGSV,1,1,0*58
01-01 00:04:54.538  3328  4051 E LocationManager: skip onNmeaReceived: nmea$GAGSV,1,1,0*58
01-01 00:04:54.539  3740  4447 E LocationManager: skip onNmeaReceived: nmea$GNRMC,160454.011,V,8960.0000,N,00000.0000,E,0.000,0.00,311218,,,N*55
01-01 00:04:54.539  3328  4051 E LocationManager: skip onNmeaReceived: nmea$GNRMC,160454.011,V,8960.0000,N,00000.0000,E,0.000,0.00,311218,,,N*55
01-01 00:04:54.539  3328  4051 E LocationManager: skip onNmeaReceived: nmea$GNRMC,160454.011,V,8960.0000,N,00000.0000,E,0.000,0.00,311218,,,N*55
01-01 00:04:54.540  3740  4447 E LocationManager: skip onNmeaReceived: nmea$GNVTG,0.00,T,,M,0.000,N,0.000,K,N*2C
01-01 00:04:54.541  3328  4561 E LocationManager: skip onNmeaReceived: nmea$GNVTG,0.00,T,,M,0.000,N,0.000,K,N*2C
01-01 00:04:54.542  3328  3345 E LocationManager: skip onNmeaReceived: nmea$GNVTG,0.00,T,,M,0.000,N,0.000,K,N*2C
01-01 00:04:54.542  3328  4051 E LocationManager: skip onNmeaReceived: nmea$GNRMC,160454.011,V,8960.0000,N,00000.0000,E,0.000,0.00,311218,,,N*55
01-01 00:04:54.542  3328  4051 E LocationManager: skip onNmeaReceived: nmea$GNVTG,0.00,T,,M,0.000,N,0.000,K,N*2C
01-01 00:04:54.542  3740  4447 E LocationManager: skip onNmeaReceived: nmea$PMTKTSX1,5012,326233.306,43.336,38.845,59000000,32.622746,32.623331,0.000000,-0.225000,0.000000,32.623*7C
01-01 00:04:54.543  3328  4051 E LocationManager: skip onNmeaReceived: nmea$PMTKTSX1,5012,326233.306,43.336,38.845,59000000,32.622746,32.623331,0.000000,-0.225000,0.000000,32.623*7C
01-01 00:04:54.544  3328  4051 E LocationManager: skip onNmeaReceived: nmea$PMTKTSX1,5012,326233.306,43.336,38.845,59000000,32.622746,32.623331,0.000000,-0.225000,0.000000,32.623*7C
01-01 00:04:54.544  3328  3345 E LocationManager: skip onNmeaReceived: nmea$PMTKTSX1,5012,326233.306,43.336,38.845,59000000,32.622746,32.623331,0.000000,-0.225000,0.000000,32.623*7C
01-01 00:04:54.544  3740  4447 E LocationManager: skip onNmeaReceived: nmea$PMTKGEPH,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*04
01-01 00:04:54.545  3328  3345 E LocationManager: skip onNmeaReceived: nmea$PMTKGEPH,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*04
01-01 00:04:54.545  3328  4051 E LocationManager: skip onNmeaReceived: nmea$PMTKGEPH,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*04
01-01 00:04:54.546  3328  4051 E LocationManager: skip onNmeaReceived: nmea$PMTKGEPH,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*04
01-01 00:04:54.546  3740  4447 E LocationManager: skip onNmeaReceived: nmea$PMTKGALM,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*19
01-01 00:04:54.547  3328  4051 E LocationManager: skip onNmeaReceived: nmea$PMTKGALM,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*19
01-01 00:04:54.547  3328  3345 E LocationManager: skip onNmeaReceived: nmea$PMTKGALM,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*19
01-01 00:04:54.548  3328  4051 E LocationManager: skip onNmeaReceived: nmea$PMTKGALM,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*19
01-01 00:04:54.548  3740  4447 E LocationManager: skip onNmeaReceived: nmea$GNACCURACY,3162.1,180.0,3.5,500.0*29
01-01 00:04:54.548  3328  4051 E LocationManager: skip onNmeaReceived: nmea$GNACCURACY,3162.1,180.0,3.5,500.0*29
01-01 00:04:54.549  3328  3345 E LocationManager: skip onNmeaReceived: nmea$GNACCURACY,3162.1,180.0,3.5,500.0*29
01-01 00:04:54.549  3328  3345 E LocationManager: skip onNmeaReceived: nmea$GNACCURACY,3162.1,180.0,3.5,500.0*29
01-01 00:04:54.550  3740  4447 E LocationManager: skip onNmeaReceived: nmea$PMTKAGC,160454.011,6174,6241,7189,7273,0,0,0*68
01-01 00:04:54.550  3328  3345 E LocationManager: skip onNmeaReceived: nmea$PMTKAGC,160454.011,6174,6241,7189,7273,0,0,0*68
01-01 00:04:54.551  3328  3345 E LocationManager: skip onNmeaReceived: nmea$PMTKAGC,160454.011,6174,6241,7189,7273,0,0,0*68
01-01 00:04:54.551  3328  4051 E LocationManager: skip onNmeaReceived: nmea$PMTKAGC,160454.011,6174,6241,7189,7273,0,0,0*68
01-01 00:04:54.553  3740  4447 E LocationManager: skip onNmeaReceived: nmea$PMTKAG2,160454.011,6*1C
01-01 00:04:54.553  3328  4051 E LocationManager: skip onNmeaReceived: nmea$PMTKAG2,160454.011,6*1C
01-01 00:04:54.553  3328  3345 E LocationManager: skip onNmeaReceived: nmea$PMTKAG2,160454.011,6*1C
01-01 00:04:54.554  3328  3345 E LocationManager: skip onNmeaReceived: nmea$PMTKAG2,160454.011,6*1C
2）异常发现

发现只要去掉 hasPermission 的调用，功耗就能掉下来，没想到是这个函数搞得鬼

    public void onNmeaReceived(final long timestamp, final String nmea) {foreach((IGnssStatusListener listener, CallerIdentity callerIdentity) -> {// huazhi.su add startif("true".equals(SystemProperties.get("persist.sys.Helper.hasPermission", "false"))) {// 实测1秒中被调用了70次，去除后平均电流减少20mA// 这个判断作用:若用户定位的时候突然关闭GPS权限，则也要相应停止数据上报到上层// 出发点是好：但是1秒钟判断了70次就不厚道了，且不同应用注册的数量不同，故这里的次数也不一样if (!hasPermission(mContext, callerIdentity)) {logPermissionDisabledEventNotReported(TAG, callerIdentity.mPackageName, "NMEA");return;}}// huazhi.su add endlistener.onNmeaReceived(timestamp, nmea);});protected boolean hasPermission(Context context, CallerIdentity callerIdentity) {if (LocationPermissionUtil.doesCallerReportToAppOps(context, callerIdentity)) {// The caller is identified as a location provider that will report location// access to AppOps. Skip noteOp but do checkOp to check for location permission.return mAppOps.checkOpNoThrow(AppOpsManager.OP_FINE_LOCATION, callerIdentity.mUid,callerIdentity.mPackageName) == AppOpsManager.MODE_ALLOWED;}return mAppOps.noteOpNoThrow(AppOpsManager.OP_FINE_LOCATION, callerIdentity.mUid,callerIdentity.mPackageName) == AppOpsManager.MODE_ALLOWED;}

上述中 reportSvStatus 也使用到了 hasPermission 的判断，但是实测回调的次数没有 reportNmea多，故功耗电流小一些

    public void onSvStatusChanged (...hasPermission(mContext, callerIdentity)...}

5. 问题发现与解决

5.1. 功耗问题原因

去掉了 hasPermission 就好，说明系统也经不起频繁执行某个函数的方法

5.2. 分析

源码也存在问题，为什么这么频繁调用的地方，每次都是执行一个函数，干嘛不把这个变量的状态保持下来。读状态比去执行函数的效率高多了。
估计 Google 写这个函数的时候，没考虑的这里实际会被频繁调用到

5.3. 解决方案
  1. 监听权限变化事件，当权限改变的时候，更新下对应uid的权限，并保存起来
    context.getPackageManager().addOnPermissionsChangeListener(mOnPermissionsChangedListener);private OnPermissionsChangedListener mOnPermissionsChangedListener = new OnPermissionsChangedListener() {public void onPermissionsChanged(int uid) {updatePermissionsChanged(uid);}};
  1. 若当前保存了uid的权限状态，则读状态，而不是每次执行函数获取，提高效率
    private boolean isHasPermission(Context context, CallerIdentity callerIdentity) {if(mPermissionsList.containsKey(callerIdentity.mUid)) {return mPermissionsList.get(callerIdentity.mUid);} else {boolean isHasPermission = hasPermission(mContext, callerIdentity);mPermissionsList.put(callerIdentity.mUid, isHasPermission);return isHasPermission;}}

5.4 高德地图导航场景电流优化了 30mA

优化后电流由 133mA 下降到100mA, 1秒钟一个的异常波形也消失了。
由于这里数据是我自己测的

在这里插入图片描述

这篇关于[20191207][Android10]高德地图导航功耗场景优化的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/695110。

相关文章

SpringBoot3实现Gzip压缩优化的技术指南

SpringBoot3实现Gzip压缩优化的技术指南

《SpringBoot3实现Gzip压缩优化的技术指南》随着Web应用的用户量和数据量增加,网络带宽和页面加载速度逐渐成为瓶颈,为了减少数据传输量,提高用户体验,我们可以使用Gzip压缩HTTP响应,... 目录1、简述2、配置2.1 添加依赖2.2 配置 Gzip 压缩3、服务端应用4、前端应用4.1 N
阅读更多...
Spring Boot + MyBatis Plus 高效开发实战从入门到进阶优化(推荐)

Spring Boot + MyBatis Plus 高效开发实战从入门到进阶优化(推荐)

《SpringBoot+MyBatisPlus高效开发实战从入门到进阶优化(推荐)》本文将详细介绍SpringBoot+MyBatisPlus的完整开发流程,并深入剖析分页查询、批量操作、动... 目录Spring Boot + MyBATis Plus 高效开发实战：从入门到进阶优化1. MyBatis
阅读更多...
MyBatis 动态 SQL 优化之标签的实战与技巧(常见用法)

MyBatis 动态 SQL 优化之标签的实战与技巧(常见用法)

《MyBatis动态SQL优化之标签的实战与技巧(常见用法)》本文通过详细的示例和实际应用场景,介绍了如何有效利用这些标签来优化MyBatis配置,提升开发效率,确保SQL的高效执行和安全性,感... 目录动态SQL详解一、动态SQL的核心概念1.1 什么是动态SQL？1.2 动态SQL的优点1.3 动态S
阅读更多...
Python如何使用__slots__实现节省内存和性能优化

Python如何使用__slots__实现节省内存和性能优化

《Python如何使用__slots__实现节省内存和性能优化》你有想过,一个小小的__slots__能让你的Python类内存消耗直接减半吗,没错,今天咱们要聊的就是这个让人眼前一亮的技巧,感兴趣的... 目录背景：内存吃得满满的类__slots__：你的内存管理小助手举个大概的例子：看看效果如何？1.
阅读更多...
一文详解SpringBoot响应压缩功能的配置与优化

一文详解SpringBoot响应压缩功能的配置与优化

《一文详解SpringBoot响应压缩功能的配置与优化》SpringBoot的响应压缩功能基于智能协商机制,需同时满足很多条件,本文主要为大家详细介绍了SpringBoot响应压缩功能的配置与优化,需... 目录一、核心工作机制1.1 自动协商触发条件1.2 压缩处理流程二、配置方案详解2.1 基础YAML
阅读更多...
MySQL中慢SQL优化的不同方式介绍

MySQL中慢SQL优化的不同方式介绍

《MySQL中慢SQL优化的不同方式介绍》慢SQL的优化,主要从两个方面考虑,SQL语句本身的优化,以及数据库设计的优化,下面小编就来给大家介绍一下有哪些方式可以优化慢SQL吧... 目录避免不必要的列分页优化索引优化JOIN 的优化排序优化UNION 优化慢 SQL 的优化，主要从两个方面考虑，SQL 语
阅读更多...
Java中&和&&以及|和||的区别、应用场景和代码示例

Java中&和&&以及|和||的区别、应用场景和代码示例

《Java中&和&&以及|和||的区别、应用场景和代码示例》：本文主要介绍Java中的逻辑运算符&、&&、|和||的区别,包括它们在布尔和整数类型上的应用,文中通过代码介绍的非常详细,需要的朋友可... 目录前言1. & 和 &&代码示例2. | 和 ||代码示例3. 为什么要使用 & 和 | 而不是总是使
阅读更多...
MySQL中慢SQL优化方法的完整指南

MySQL中慢SQL优化方法的完整指南

《MySQL中慢SQL优化方法的完整指南》当数据库响应时间超过500ms时,系统将面临三大灾难链式反应,所以本文将为大家介绍一下MySQL中慢SQL优化的常用方法,有需要的小伙伴可以了解下... 目录一、慢SQL的致命影响二、精准定位问题SQL1. 启用慢查询日志2. 诊断黄金三件套三、六大核心优化方案方案
阅读更多...
Redis中高并发读写性能的深度解析与优化

Redis中高并发读写性能的深度解析与优化

《Redis中高并发读写性能的深度解析与优化》Redis作为一款高性能的内存数据库,广泛应用于缓存、消息队列、实时统计等场景,本文将深入探讨Redis的读写并发能力,感兴趣的小伙伴可以了解下... 目录引言一、Redis 并发能力概述1.1 Redis 的读写性能1.2 影响 Redis 并发能力的因素二、
阅读更多...
使用Folium在Python中进行地图可视化的操作指南

使用Folium在Python中进行地图可视化的操作指南

《使用Folium在Python中进行地图可视化的操作指南》在数据分析和可视化领域,地图可视化是一项非常重要的技能,它能够帮助我们更直观地理解和展示地理空间数据,Folium是一个基于Python的地... 目录引言一、Folium简介与安装1. Folium简介2. 安装Folium二、基础使用1. 创建
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2