内存优化

1.避免创建不需要的对象。对于生命周期较短的临时变量,尽量想办法规避掉每次都要去创建它,这样GC回收被强制调用机会就会更少,留给Android系统进行UI渲染或者音频加载的时间就会更多,从而避免了卡顿现象。
2.当使用Service应当小心小心再小心!当你需要启动一个服务在后台执行一项任务时,应当在其完成工作之后尽快的停止此服务。可以考虑使用IntentService—当在子线程完成耗时操作之后,IntentService会自动停止并结束自身。然而在实际开发中经常会碰到需要服务去执行一项耗时比较长的任务,比如:音乐播放器,下载APP等等。像这样的应用可以分隔为两个进程:一个进程负责 UI 工作, 另外一个则在后台服务中运行其它的工作. 在AndroidManifest 文件中为各个组件申明 android:process 属性就可以分隔为不同的进程。注意一点:在后台运行的Service绝对不能处理或者持有任何UI,否则系统可能会分配双倍甚至三倍的空间来维护UI资源!!
3.当你加载 bitmap 时, 需要根据当前设备的分辨率加载相应分辨率的bitmap进入内存,如果下载下来的原图分辨率比设备分辨率高则要压缩它. 要小心bitmap的分辨率增加后所占用的内存也要进行相应的增加(平方级increase2的增长), 因为它是根据x和y的大小来增加内存占用的。
4.避免使用枚举Enum,一个Enum分配的空间是一个普通常量的两倍,因此尽量少使用枚举。
5.试着使用Android框架优化后的数据容器,譬如:SparseArray, SparseBooleanArray, 以及 LongSparseArray containers. 使用这些类来替代HashMap的使用。 原因是传统的 HashMap 在内存上的实现十分的低效,因为它需要为 HashMap 中每一项在内存中建立映射关系. 另外, SparseArray类非常高效因为它避免了对key和value的自动封箱.万事都有两面性,这些个被优化过的容器也不例外,千万记住SparseArray等容器并不适应于内部元素很多的集合,当集合的长度超过1000条时,使用SparseArray进行增删改查的效率远比HashMap低。
6.慎用桥接模式,虽然从程序的设计角度来看,抽象能够帮助我们创建更加灵活的软件架构。但是在手机系统中,这种设计模式有可能会造成很多副作用。 除非大有必要,否则尽量不要用桥接模式
7.检测App内存中的可用堆的大小,在代码中可以通过动态的调用ActivityManager::getMemoryClass()方法来查询你的App中的可用内存堆大小。如果系统检测到需要分配的内存大小超过了此值,则会抛出OOM错误。
8.**可以适当适应onTrimMemory回调方法。OnTrimMemory 回调是 Android 4.0 之后提供的一个API,这个 API 是提供给开发者的,它的主要作用是提示开发者在系统
内存不足的时候,通过处理部分资源来释放内存,从而避免被 Android 系统杀死。这样应用在下一次启动的时候,速度就会比较快。
9.使用代码混淆工具 ProGuard 通过去除没有用的代码和通过语义模糊来重命名类, 字段和方法来缩小, 优化和混淆你的代码. 使用它能使你的代码更简洁, 更少量的RAM
映射页.如果构建apk后你没有做后续的任何处理(包括根据你的证书进行签名), 你必须运行 zipalign 工具为你的apk进行优化, 如果不这样做会导致你的应用使用更多的 内存,zipalign之后像资源这样的东西不会再从apk中映射(mmap)入内存.注意:goole play store 不接受没有进行zipalign的apk。

推荐阅读更多精彩内容