精华内容
下载资源
问答
  • 耗电的主要来源: CPU处理,Processing 网络,Networking 定位,Location 图像,Graphics 耗电的优化: 尽可能降低CPU、GPU功耗 尽量减少定时器的使用 优化I/O操作 尽量不要频繁写入小数据,最好批量一次性...

    耗电的主要来源:

    • CPU处理,Processing
    • 网络,Networking
    • 定位,Location
    • 图像,Graphics

    耗电的优化:

    • 尽可能降低CPU、GPU功耗
    • 尽量减少定时器的使用
    • 优化I/O操作
    1. 尽量不要频繁写入小数据,最好批量一次性写入
    2. 读写大量重要数据时,考虑用dispatch_io,其提供了基于GCD的异步操作文件I/O的API ,用dispatch_io系统会优化磁盘的访问
    3. 数据量比较大时,建议使用数据库(比如CoreData、Sqlite等)
    • 网络优化
    1. 减少、压缩网络数据
    2. 如果多次请求的结果是相同的,尽量使用缓存
    3. 使用断点续传,否则网络不稳定时可能会多次传输相同的内容
    4. 网络不可用时,不要尝试执行网络请求
    5. 让用户可以取消长时间运行或者速度很慢的网络操作,设置网络超时时间
    6. 批量传输,比如,下载视频流时,不要传输很小的数据包,直接下载整个文件或者一大块一大块地下载。如果下载广告,一次性多下载一些,然后再慢慢展示。如果下载电子邮件,一次下载多封,不要一封一封地下载
    • 定位优化
    1. 如果只需要快速确定用户位置,最好用CLLocationManager的requestLocation方法。定位完成后,会自动让定位硬件断电
    2. 如果不是导航应用,尽量不要实时更新位置,定位完毕就关掉定位服务
    3. 尽量降低定位精度,比如尽量不要使用精度最高的kCLLocationAccuracyBest
    4. 需要后台定位时,尽量设置pausesLocationUpdatesAutomatically为YES,如果用户不太可能移动的时候,系统会自动暂停位置更新
    5. 尽量不要使用startMonitoringSignificantLocationChanges,优先考虑startMonitoringForRegion:
    • 硬件检测优化
    1. 用户移动、摇晃、倾斜设备时,会产生动作(motion)事件,这些事件由加速度计、陀螺仪、磁力计等硬件检测。在不需要检测的场合,应该及时关闭这些硬件

     

    展开全文
  • 如何检测单个APP的耗电

    千次阅读 2016-12-31 14:07:42
    急求思路,最好源代码。检测单个APP的电量,不是系统总电量。
    急求思路,最好源代码。检测单个APP的电量,不是系统总电量。 
    展开全文
  • 电量和硬件1.1 App 通过使用硬件模块消耗相应电能1.2 资源调度机制是厂商功耗优化重要手段2. 电量和应用程序2.1 评估不同应用程序的耗电情况结论:把电量测量转化为功能模块使用时间或者次数2.2 尽可能...

    1. 电量和硬件

    1.1 App 通过使用硬件模块消耗相应的电能

    应用程序不会直接去消耗电池,而是通过使用硬件模块消耗相应的电能,下图是手机中一些比较耗电的硬件模块

    在这里插入图片描述
    CPU屏幕WiFi数据网络GPS 以及音视频通话都是我们日常的耗电大户。

    坦白说,智能手机硬件的飞速提升,许多其实都是厂商叫卖的噱头。绝大部分硬件对于我们来说都已经处于性能过剩的状态,但多余的性能同时也在消耗电量

    1.2 资源调度机制是厂商功耗优化最重要的手段

    eg:

    • CPU 芯片会分大小核架构,会灵活地为不同任务分配相应的运算资源
    • 手机基带、GPS 这些模块在不使用时也会进入低功耗或者休眠模式,达到降低功耗的目的
    • 现在越来越多厂商利用深度学习的本地 AI 来优化资源的调度,对 GPU、运行内存等资源进行合理分配,确保可以全面降低耗电量。厂商需要在高性能跟电量续航之间寻找一个平衡点,有的厂商可能倾向于用户有更好的性能,有的厂商会倾向于更长的续航

    2. 电量和应用程序

    2.1 评估不同应用程序的耗电情况

    根据物理学的知识,电能的计算公式为:

    电能 = 电压 * 电流 * 时间
    

    对于手机来说电压一般不会改变,所以在电压恒定的前提下,只需要测量电流和时间就可以确定耗电。

    最终不同模块的耗电情况可以通过下面的这个公式计算:

    模块电量(mAh) = 模块电流(mA) * 模块耗时(h)
    

    模块耗时比较容易理解,但是模块电流应该怎样去获取呢?Android 系统要求不同的厂商必须在 /frameworks/base/core/res/res/xml/power_profile.xml 中提供组件的电源配置文件

    power_profiler.xml 文件定义了不同模块的电流消耗值以及该模块在一段时间内大概消耗的电量,你也可以参考 Android Developer 文档《Android 电源配置文件》

    当然电流的大小和模块的状态也有关系,例如屏幕在不同亮度时的电流肯定会不一样

    在这里插入图片描述
    Android 系统的电量计算 PowerProfile 也是通过读取 power_profile.xml 的数值而已,不同的厂商具体的数值都不太一样,我们可以通过下面的方法获取:

    • 从手机中导出 /system/framework/framework-res.apk文件
    • 使用反编译工具(如 apktool)对导出文件framework-res.apk进行反编译。
    • 查看power_profile.xml文件在framework-res反编译目录路径:/res/xml/power_profile.xml

    对于系统的电量消耗情况,我们可以通过 dumpsys batterystats 导出:

    
    adb shell dumpsys batterystats > battery.txt
    // 各个Uid的总耗电量,而且是粗略的电量计算估计。
    Estimated power use (mAh):
        Capacity: 3450, Computed drain: 501, actual drain: 552-587
        ...
        Idle: 41.8
        Uid 0: 135 ( cpu=103 wake=31.5 wifi=0.346 )
        Uid u0a208: 17.8 ( cpu=17.7 wake=0.00460 wifi=0.0901 )
        Uid u0a65: 17.5 ( cpu=12.7 wake=4.11 wifi=0.436 gps=0.309 )
        ...
    
    // reset电量统计
    adb shell dumpsys batterystats --reset
    

    BatteryStatsService 是对外的电量统计服务,但具体的统计工作是由 BatteryStatsImpl 来完成的,而 BatteryStatsImpl 内部使用的就是 PowerProfileBatteryStatsImpl 会为每一个应用创建一个 UID 实例来监控应用的系统资源使用情况,统计的系统资源包括下面图里的内容

    在这里插入图片描述

    结论:把电量的测量转化为功能模块的使用时间或者次数

    电量的使用也会跟环境有关,例如在零下十度的冬天电量会消耗得更快一些,系统提供的电量测量方法只是提供一个参考的数值。不过通过上面的这个方法,我们可以成功把电量的测量转化为功能模块的使用时间或者次数

    2.2 尽可能准确的测量电量

    参考 《大众点评 App 的短视频耗电量优化实战》

    在这里插入图片描述

    bug report结合 Battery Historian 是最好的排查方法

    3. Android 耗电的演进历程

    在这里插入图片描述

    3.1 野蛮生长:Pre Android 5.0

    在 Android 5.0 之前,系统并不是那么完善,对于电量优化相对还是比较少的。

    特别没有对应用的后台做严格的限制,多进程、fork native 进程以及广播拉起等各种保活流行了起来。用户手机用电如流水,会明显感受到下面几个问题:

    • 耗电与安装应用程序的数量有关。用户安装越多的应用程序,无论是否打开它们,手机耗电都会更快。
    • App 耗电量与 App 使用时间无关。用户希望 App 的耗电量应该与它的使用时间相关,但是有些应用即使常年不打开,依然非常耗电。
    • 电量问题排查复杂。无论是电量的测量,还是耗电问题的排查都异常艰难。

    3.2 逐步收紧:Android 5.0~Android 8.0

    3.2.1 Android 5.0

    • Volta 项目
    • Job Scheduler – 适应各种场景的任务(无线网络,充电时…)
    • dumpsys batterystats
    • Battery Historian
    • 修复 native fork 进程保活
      • 原理就是通过 JNI fork出一个 c 进程,c 进程监控主进程是否存活,主要通过管道和文件监控的方式实现监控,发现主进程死后,通过调起一个 service 将主进程拉活

    3.2.2 Android 6.0

    • Doze and App Standby
    • Doze (低电耗模式):如果用户拔下设备的电源插头,并在屏幕关闭后的一段时间内使其保持不活动状态,设备会进入低电耗模式,在该模式下设备会尝试让系统保持休眠状态。在该模式下,设备会定期短时间恢复正常工作,以便进行应用同步,还可让系统执行任何挂起的操作。
    • App Standby (应用待机模式):应用待机模式允许系统判定应用在用户未主动使用它时处于空闲状态。当用户有一段时间未触摸应用时,系统便会作出此判定。如果拔下了设备电源插头,系统会为其视为空闲的应用停用网络访问以及暂停同步和作业。

    总结:

    3.2.3 仍然存在的问题

    Android 6.0 开始,Google 开始着手清理后台应用和广播来进一步优化省电。在这个阶段还存在以下几个问题:

    • 省电模式不够省电。Doze 低功耗模式限制得不够严格,例如屏幕关闭还可以获取位置、后台应用的网络权限等。

    • 用户对应用控制力度不够。用户不能简单的对某些应用做更加细致的电量和后台行为的控制,但是其实国内很多的厂商已经提前实现了这个功能。

    • Target API 开发者响应不积极。为了不受新版本的某些限制,大部分国内的应用坚持不把 Target API 升级到 Oreo 以上,所以很多省电的功能事实上并没有生效。

    3.2.5 导致的各种骚操作 App 保活

    坏孩子:

    3.3 最严限制:Android 9.0

    在这里插入图片描述

    • 通过应用待机分组功能,我们可以确保应用使用的电量和它们的使用时间成正比,而不是和手机上安装的应用数量成正比。对于不常用的应用,它们可以“作恶”的可能性更小了。

    • 通过省电模式和应用后台限制,用户可以知道哪些应用是耗电的应用,我们也可以对它们做更加严格的限制

    展开全文
  • 前段时间一直有个别用户反馈 app 耗电量很快,手机发烫。问了下设备信息,判断不应该是设备过时原因,自己手头测试也没有发现什么问题。 直到今天,亲眼看到 app 界面反应特别卡顿,而且手机发烫确实很严重。最后...

    前段时间一直有个别用户反馈 app 耗电量很快,手机发烫。问了下设备信息,判断不应该是设备过时的原因,自己手头测试也没有发现什么问题。

    直到今天,亲眼看到 app 界面反应特别卡顿,而且手机发烫确实很严重。最后经过排查,发现是跑马灯导致的。

    跑马灯使用 UIView 动画实现的,由于一直循环,导致控件没有释放,动画一直持续,最后 CPU 占用过多,手机耗电巨大。

    下面根据测试用例说明下这个问题。测试用例可以在这里下载。

    首先测试用例中有三个控制器 ViewController FirstViewController SecondViewControllerViewController 中有一个按钮可以跳转到 FirstViewControllerFirstViewController 中有一个按钮可以跳转到 SecondViewControllerFirstViewController 中再添加一个红色 view ,并写代码使其做 frame 移动的 UIView 动画。

    动画代码的不同,会造成不一样的结果,分情况讨论一下:

    1. 一般情况下,没有什么问题:

       - (void)startAction
       {
           CGFloat x = 0;
           if (self.redView.frame.origin.x != 375) {
               x = 375;
           }
           [UIView animateWithDuration:5 animations:^{
               self.redView.frame = CGRectMake(x, self.redView.frame.origin.y, self.redView.frame.size.width, self.redView.frame.size.height);
           } completion:^(BOOL finished) {
               if (finished) {
                   [self startAction];
               }µ
           }];
       }
      

    这种情况下,不会有什么 cpu 电量上的问题,只是当从 SecondViewController 返回到 FirstViewController 时动画会结束。app 运行情况如图。

    正常

    1. 为了使返回的时候,动画继续进行,对代码进行了部分改造:

       - (void)startAction
       {
           CGFloat x = 0;
           if (self.redView.frame.origin.x != 375) {
               x = 375;
           }
           [UIView animateWithDuration:5 animations:^{
               self.redView.frame = CGRectMake(x, self.redView.frame.origin.y, self.redView.frame.size.width, self.redView.frame.size.height);
           } completion:^(BOOL finished) {
       //        if (finished) {
                   [self startAction];
       //        }
           }];
       }
      

    这样的话,返回的时候动画就不会停止,但是,问题也就出现了。此时的 app 运行状态如图。

    非正常

    可以看到这时候 CPU 使用率已经超出了负载,电量耗费很大,而且 FirstViewController 没有释放掉。

    1. 为了解决以上两种问题,继续对代码进行改造。

        - (void)startAction
       {
           CGFloat x = 0;
           if (self.redView.frame.origin.x != 375) {
               x = 375;
           }
           [UIView animateWithDuration:5 animations:^{
               self.redView.frame = CGRectMake(x, self.redView.frame.origin.y, self.redView.frame.size.width, self.redView.frame.size.height);
           } completion:^(BOOL finished) {
               if (finished) {
                   [self startAction];
               }
           }];
       }
       
       - (void)viewWillAppear:(BOOL)animated
       {
           [self startAction];
       }
      

    app运行状态如图。

    解决方案

    这时,页面返回时动画能够继续进行,FirstViewController 正常释放,CPU 电量使用也正常。

    展开全文
  • 我们都知道,我们的APP在运行的时候,会对应一个Mach Task,而Task下可能有多条线程同时执行任务,每个线程都是作为利用CPU的基本单位。所以我们可以通过获取当前Mach Task下,所有线程占用 CPU 的情况,来计算APP的...
  • 冷启动重要。 首屏启动就是加载首页内容页算进去了 兼容性测试 几个硬件之间,几个软件之间或是软硬件之间配合程度。 接口性能分析 webview性能分析 app打开webview方法: H5性能分析 ...
  • 关注上方“测试开发技术”,选择星标,干货技术,第一时间送达!普遍apk性能测试,主要是以下七类1、响应2、内存3、cpu4、FPS (app使用流畅度)5、GPU过度渲染6、耗电7、耗...
  • 也有在后台淘气耗电的熊孩子! 那么,作为一枚不愿错过任何热点的 新闻类APP吃瓜群众, 如何才能一边知晓天下新闻, 一边让自己的爱机能量满格? 选择哪款应用,才可能让后台耗电降到最低? 华为终...
  • 常见的appbug(转)

    2019-10-03 18:10:49
    移动App Bug的影响是用户体验差、App的商店评级下降、用户换用竞争对手的App,声誉和信誉损失、最后销售量减少,如果它是一个付费App的话。  移动App测试与传统台式机测试相比有一定的复杂性。这些复杂性可以被...
  • Android耗电评估

    千次阅读 2015-12-09 15:52:57
    这里只是使用简单的方法对你的app的电量消耗进行评估,如果还想更加详细或者复杂的方法,可以使用一些比较专用的工具,比如Emmagee(https://github.com/NetEase/Emmagee),这个就很好用。第一招:看系统的 设置-...
  • MacBook买来有一段时间了,但待机耗电这个问题一直没解决。有的时候待机一天就掉2%-3%的电,但有的...好,首先我们要在mac里找到一个叫终端的app。 打开终端方法: 1.点击启动台 此时,在上方有一个搜索框,长这样⬇
  • 1.用户角度对APP使用关注点APP操作如何占用内容大不大耗电量高不高性能如何干扰信息是否多视觉体验是否导致手机发烫2.APP让用户难以忍受问题:严重程度依次降低卡死闪退反应慢耗电快广告多3.公司测试团队不...
  • 假如要Google Play上做一个失败案例,那最好秘诀就是界面奇慢无比、耗电、耗内存。接下来就会得到用户消极评论,最后名声也就臭了。即使你应用设计精良、创意无限也没用。 耗电或者内存占用等影响产品效率...
  • 本文讲述了如何尽可能地缩短运行时间,以及如何开发用户喜欢的App。 假如要Google Play上做一个失败的案例,那最好的秘诀就是界面奇慢无比、耗电、耗内存。接下来就会得到用户的消极评论,最后名声也就臭了...
  • 耗电或者内存占用等影响产品效率每一个问题都会影响App的成功。这就是为什么在开发中确保优化、运行流畅而且不会使Android系统出问题是至关重要了。这里不需要讨论高效编程,因为我们不会关心你写代码是否...
  • 打开cydia,搜索ifile(威锋源,版本2.1.0-1)。打开ifile,进入路径/Applications....找到mobilemail.app,点击该栏右侧蓝色“i"图标,进入后下滑到下方,找到”ACCESS PERMISSIONS“单元。单...
  • 耗电或者内存占用等影响产品效率每一个问题都会影响App的成功。这就是为什么在开发中确保优化、运行流畅而且不会使Android系统出问题是至关重要了。这里不需要讨论高效编程,因为我们不会关心你写代码是否...
  • 因为影响APP产品效率每一个问题,如:耗电或内存占用情况等,都是关乎APP成功与否关键因素。小编为大家总结了十条高效开发AndroidAPP的建议,希望对你有所帮助。 建议一:高效地利用线程 我们知道App运行过程中...

空空如也

空空如也

1 2 3 4 5 ... 8
收藏数 159
精华内容 63
关键字:

最耗电的app