Android内存占用过高如何优化？Activity方法数量是否影响内存消耗？

首先可以明确：Activity内的方法数量几乎不会对运行时RAM占用产生可感知的影响。
Android系统加载Dex文件时，方法代码会存放在所有进程实例共享的代码段内存区域，每个Activity实例不会单独复制一份方法代码，实例本身的内存占用仅包含成员变量、上下文引用、View树实例等实例数据，和方法数量无关。

关于静态方法的优化思路：完全不推荐为了降内存刻意增加静态方法。静态方法如果持有短生命周期对象（Activity、View、上下文等）的强引用，会直接导致对应对象无法被GC回收，引发内存泄漏的风险远高于普通实例方法。同时静态方法会大幅降低代码的可测试性和可维护性，没有任何实际的内存收益。

你已经完成了基础的内存优化动作，可进一步落地以下优化方案：

• 上下文引用合规化：所有长生命周期的依赖优先注入Application上下文，仅在需要使用界面相关能力的场景才传入Activity上下文，且所有持有Activity上下文的引用需在onDestroy阶段手动置空，切断泄漏链
• 集合类内存优化：替换高内存开销的HashMap为更轻量的ArrayMap、SparseArray系列容器；全局/长生命周期的集合使用完及时调用clear()，避免扩容后保留大量无用的空闲空间
• 对象池复用：针对频繁创建销毁的对象（如列表条目、网络请求体、数据解析实体）实现复用池，减少频繁创建销毁对象带来的内存抖动，降低GC触发频率
• 打包裁剪优化：构建release包时开启minifyEnabled true混淆裁剪冗余代码，开启shrinkResources true移除所有未使用的资源文件；仅保留目标用户群体覆盖度最高的1-2套dpi资源，避免全量保留所有分辨率的drawable资源
• 动画与Drawable优化：所有页面内的动画在onDestroy阶段主动调用cancel()；和View绑定的自定义Drawable在页面销毁时调用drawable.setCallback(null)切断引用链
• 内存泄漏专项排查：
  • 所有单例类禁止持有Activity实例，仅接收Application上下文作为依赖
  • 页面内的Handler、延迟Runnable在onDestroy时调用handler.removeCallbacksAndMessages(null)清空所有待执行任务
  • 排查注册类逻辑（广播、EventBus、系统服务回调等），确保注册和反注册成对出现
• 低内存状态适配：实现ComponentCallbacks2回调，在onTrimMemory方法中根据系统返回的内存等级，主动清理内存缓存、无用Bitmap、闲置资源等；仅在极端场景下可在Manifest中声明largeHeap属性申请更大内存，该方案为兜底选项不推荐优先使用

内容的提问来源于stack exchange，提问作者Juan Pablo Leiva Burgos