《Android应用性能优化》3—

7、延长电池续航时间

　　尽管应用有时看起来没做多少事，但实际上可能会很耗电，运行不了多久就会把电量榨干，使设备开机不到半天就没电了。那些被归为“电池杀手”的应用，最终的宿命就是被删除、得差评、不挣钱。因此作为开发者要尽量少用电量，合理使用电池。

　　在三星GalaxyTab10.1中运行愤怒小鸟作为对比，平板各组件耗电可见一般：

　　截图中Screen和Wi-Fi分列一二，远超作为游戏的愤怒小鸟。针对这两个组件，设备提供了相应选项让用户对它们的使用方式进行配置。例如，用户可调节屏幕的亮度（手动或根据所显示的图像自动），设定多长时间没有活动后屏幕关闭，屏幕关闭时Wi-Fi也关闭。例如，Wi-Fi连接如果在屏幕关闭后立即断开，那可能只占电池总使用量的百分之几。

7.2 广播接收器

　　将注册放到onStart()，注销放到onStop()中是最显而易见的做法，为节省更多的电量，通常在onResume()和onPause()中也进行注册与注销

　　如果需要知道当前电池信息，但不想用通知更新的方式，可调用registerReceiver()并把接收器参数设为null，无须注册任何广播接收器，就能得到包含电池信息的Intent。

　　测量电池用量，建议在应用启动时获取电池当前电量，运行一段时间，在退出时再次获取电池电量。两电量之间的差异并不表示应用真实的耗电量，因为有其他应用同时在运行，所以需要有更好的方法测量单个应用的耗电量。如，计算出在电池电量耗光前，应用还可运行多久。

　　为节省电量，应用应避免执行做无用功的代码。

　　Android定义了应用可使用的5个广播Intent：

ACTION_BATTERY_CHANGED
ACTION_BATTERY_LOW
ACTION_BATTERY_OKAY
ACTION_POWER_CONNECTED
ACTION_POWER_DISCONNECTED

　　上述动作只要有一个发生，应用就会启动（如果它尚未启动）。虽然这可能是期望的行为，但很多情况下，你可能希望应用有不同的处理。例如这种情况，应用在前台运行时显示Toast消息是有意义的；若在后台时还出现Toast消息，就会干扰其他应用，损害用户体验

　　当应用不在运行或在后台运行时，禁用这些Toast消息，可采用以下两种方法：

在应用中加入标记变量，在Activity的onResume()中置为true、在onPause()中置为false，并修改接收器的onReceive()方法，检查标记的值
只有当应用在前台运行时才可以启用广播接收器

　　第一种方法虽可行，但只要动作之一被处罚，应用就会启动。最终会导致执行了不必要的指令，相当于执行no-op（无操作）指令，白白耗费电量。此外，如果应用包含多个Activity，修改标记会影响到多个文件

　　第二种方法就好多了，因为我们可以确保只有在真正需要时才执行指令，就不会浪费电池电量。为了达到这一目标，我们需要在应用中做两件事：

广播接收器默认是禁用的；
广播接收器必在onResume()中启用，在onPause()被禁用

7.9 总结

　　用户通常不会注意到应用是否延长了电池寿命。但是，若不做，更有可能会被注意到。因为单个应用可让所有其他人的努力化为泡影，所有应用都需通力配合，最大限度地延长电池的使用时间。用户会卸载耗电的应用，要合理使用电池，但也应当给用户配置选项的自由，因为不同的用户会有不同的需求。给你的用户配置的权利。

8、图形

8.3 OpenGL ES

　　纹理压缩

　　纹理定义了OpenGL ES应用的外观。虽然未压缩的纹理使用起来很方便，但这种纹理会迅速让应用变得冗赘不堪。如，未压缩的256×256的RGBA8888纹理就会占用256KB的内存

　　未压缩的纹理对性能有负面影响，它们不像压缩过的能够缓存（因为比较小），且还要多次访问内存（影响功耗）。使用未压缩过纹理的应用体积也更为庞大，需要更多的时间来下载安装。此外，Android设备的内存通常是有限的，所以应尽可能占用较少内存。

　　Mipmap

　　通常，三维场景中出现在背景的对象，在屏幕上不会占用多少空间。如，屏幕上显示为10×10的对象使用256×256纹理就是浪费资源（内存、宽带）。Mipmap通过提供多层次细节的纹理来解决这个问题。

　　虽然Mipmap包会比原始图像多用掉33%的内存，但它不仅可提升性能，也会提高图像质量。

　　纹理如何渲染也取决于选择的那个glTexParameter()方法（比如glTexParamteri()）设置的纹理参数。如，可调用glTexParamteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, param)设置缩小功能，param可取以下值：

GL_NEAREST
GL_LINEAR
GL_NEAREST_MIPMAP_NEAREST
GL_NEAREST_MIPMAP_LINEAR
GL_LINEAR_MIPMAP_NEAREST
GL_LINEAR_MIPMAP_LINEAR

　　GL_NEAREST一般比GL_LINEAR快，GL_LINEAR又比其他四个更快，越慢的函数得到的视觉质量越好。应用程序会选择什么样的参数可能取决于用户的爱好（加入你提供方法让用户自行配置渲染质量），但许多用户不会有耐心尝试各种配置，找出合适自己设备的组合。因此，应用要自己选出最优的OpenGL配置

　　多APK

　　由于可能要支持多种纹理压缩格式（尽可能为每个设备都做优化），Mipmap需占用较大的空间，应用可能会超过Android Market（目前为50M字节）定义的大小限制

　　若出现这种情况，基本上有三种选择：

减少应用的大小，如只支持ETC1纹理压缩；
安装应用后从远程服务器下载纹理；
生成多个APK，每个对应一套纹理

9、RenderScript

　　Honeycomb(API等级11)引入了RenderScript，它是一个针对高性能3D渲染和计算操作的新框架。Android2.1(Eclair)后来也引入了这个框架，但Honeycomb是第一个正式将RenderScript公之于众的版本。

　　RenderScript和NDK都是为了提高应用的性能而引入的。虽然它们有共同的目标，但应仔细斟酌它们的区别。

9.1 RenderScript优点：

平台独立（ARM、MIPS、Intel）；
易于并行执行；
可使用CPU、GPU或其他处理器。

9.2 RenderScript缺点：

Android独有（脚本不能用在其他平台，如IOS）；
学习难度；
API数量有限

　　RenderScript的实际性能测试结果很难得到，它们实在太依赖Android版本和硬件设备了。一些脚本的运行速度可能远超Java或NDK的对应实现，而其他的可能不会。若因为遗留代码的缘故，或这样做更有意义，那么大可在实际中让应用同时使用RenderScript和NDK。

9.3 小结

　　虽然它似乎仍是Honeycomb带来的略显稚嫩的技术，RenderScript已在Android4.0中有所改善，在将来会更好地发挥硬件的优势。尽管试下ARM是Android移动设备的主要平台，使用NDK时合理的选择，可RenderScript是独立于平台的，这样可显著降低成本，带来巨大的收益。总的来说，RenderScript挺有前景，且很有可能是未来应用的很重要的组成部分，会用在单靠Java不能满足性能需求的地方。