
在编写高性能 代码时, 电量消耗是一个需要重点处理的重要因素, 就执行时间和 CPU 资源的利用而言, 我们不仅要实现高效的数据结构和算法, 还需要考虑其他的因素,如果某个应用是个电池黑洞,那么一定不会有人喜欢他
电量消耗除了 CPU 外,还有一些硬件模块:网络硬件, 蓝牙,GPS, 麦克风,加速计,,扬声器,和屏幕.
我们可以带着以下问题来看这篇文章:
消耗电量的关键领域有哪些
如何降低电量的消耗
如何在 IOS 应用中分析电源, CPU 和资源的使用
一 CPU
不论用户是否正在直接使用, CPU 都是应用所使用的主要硬件, 在后台操作和处理推送通知时, 应用仍然会消耗 CPU 资源

应用计算的越多,消耗的电量越多.在完成相同的基本操作时, 老一代的设备会消耗更多的电量(换电池呀 哈哈哈 开个玩笑),计算量的消耗取决于不同的因素
对数据的处理
待处理的数据大小---更大的显示屏允许软件在单个视图中展示更多的信息,但这也意味着要处理更多的数据
处理数据的算法和数据结构
执行更新的次数,尤其是在数据更新后,触发应用的状态或 UI 进行更新(应用收到的推送通知也会导致数据更新,如果此用户正在使用应用,你还需要更新 UI)
没有单一原则可以减少设备中的执行次数,很多规则都取决于操作的本质, 以下是一些可以在应用中投入使用的最佳实践
针对不同的情况选择优化的算法 例如,当你在排序时,如果列表少于43个实例, 则插入排序优于归并排序, 但实例对于286时, 应当使用快速排序,要优先使用双枢轴快速排序而不是传统的单枢轴快速排序
如果应用从服务器接受数据,尽量减少需要在客户端进行的处理
例如如果一段文字需要在客户端进行渲染,尽可能在服务器将数据清理干净
我曾经做个一个项目, 因为服务器的实现主要用于服务桌面用户,所以返回的文本中包含 HTML 标签, 清理 HTML 标签的工作并没有放在客户端进行, 而是放在了服务端实现,从而减少了设备上的计算过程, 降低了处理时间
优化静态编译(ahead-of-time,AOT)处理 动态编译处理的缺点在于他会强制用户等待操作完成, 但是激进的 AOT 处理则会导致计算资源的浪费, 需要根据应用和设备选择精确定量的 AOT 处理.例如,UITableView 中渲染一组记录时,在载入列表是处理全部的记录并不是明智之举,基于单元格的高度,如果设备可以渲染 N 条记录, 那么3N 或4N 则是一个理想的数据载入规模, 类似的,用户快速滑动,则不应立即载入记录,而应推迟带滚动速度下降到某一阈值.精确的阈值应该由每个单元格的处理时间和单元格的 UI 的复杂性来决定
二 网络
智能的网络访问管理可以让应用响应的更快,并有助于延长电池寿命.在无法访问网络时,应该推迟后续的网络请求, 直到网络连接恢复为止.此外,应避免在没有连接 WiFi 的情况下进行高宽带消耗的操作.比如视频流, 众所周知, 蜂窝无线系统(LTE,4G,3G等)对电量的消耗远远大于 WiFi信号, 根源在于 LTE 设备基于多输入,多输出技术,使用多个并发信号以维护两端的 LTE 链接,类似的,所有的蜂窝数据链接都会定期扫描以寻找更强的信号.因此:我们需要
在进行任何网络操作之前,先检查合适的网络连接是否可用
持续监视网络的可用性,并在链接状态发生变化时给与适当的反馈
三 定位管理器和 GPS
这个知识点我项目中并没有用到定位相关的功能 ,不过也总结一下书中所讲的知识点 有用的定位功能的朋友可以参考此知识点来优化自己的 app
本文来自电脑杂谈,转载请注明本文网址:
http://www.pc-fly.com/a/shumachanpin/article-76047-1.html
以前美国绝对不会答应
俺们那的人大部分谈生意都很实诚