崩塌的都市
在帝国设计中, 处处都隐藏着这样那样的风险, 稍有设计不当, 帝国可能随时可能崩塌.
生态平台 (领主) 为每个帝国都提供了定期的垃圾回收服务, 帝国的贸易和生活所产生的垃圾都会被定期回收, 来保证帝国正常的运转. 回收哪些垃圾是根据一定条件来判断是否将不再作用的 (使用的) 对象进行垃圾回收, 但是, 如果设计存在问题, 可能导致一些活动所产生的垃圾一直无法回收, 这样下去是必垃圾遍地, 很可能会导致帝国的崩塌.
垃圾之城
发生以上情况可能是由内存泄露所引起的. 那么我们先说一说什么是内存泄露吧.
我们帝国的交易在市场频繁地进行, 多数交易并不是独立, 而是相互关联的, 例如我们购买汽车, 汽车制造商对于跟制造轮子的企业进行交易. 这是链式交易或是树形交易, 一旦交易完成, 其相关交易也必将消失. 但是由于某种设计不当, 可能造成有一些本应该消失的交易还在市场占有一席之地, 这样就会多少影响帝国贸易, 让新的交易无法进入市场, 最终导致帝国崩塌.
内存泄露就是一些不再被使用的对象, 由于被另一个存活的对象引用着, 造成垃圾回收无法对其进行处理, 导致其长驻内存.
由于 Activity 和其包含的 View 都存在强引用的关系, 所以特别容易造成内存泄露.
Activity(都市)除了我们主动销毁他, 还有两种情况他可能会在内存中被销毁后重建.
1. 当手机在横屏和竖屏间切换时
2. 当由于内存紧张, Activity 没有处于前端也会被自动销毁.
一旦 Activity 没有被销毁而长驻内存, 他就是消耗资源的空城, 这样吃空头的都市是必会耗尽帝国资源, 所以我们一定一定要防止 Activity 的泄漏, 这段话应该加粗加黑.
当实例化一个对象需要 context, 我们切记不要用 Activity 作为 context. 应该选择 Application 作为 context 传入构造函数.
如果我们定义一个 TextView
如果你将 View 定义为 static 由于 static 位于堆内存呢, 如果你不将赋值 null.
由于他是 Activity 的静态的属性, 所以 Activity 也不会在垃圾回收中被回收. 这样如果有图片作为背景, 看一看 TextView> Activity> Windows 这样. 帝国就一步一步走向崩塌.
静态字段非常危险, 可能会关联 Activity 以及一些其他的对象. 大部分内存问题都是可能是由此引起的. 代码中定义一个静态 View, 这个 View 就会引起 Activity 的泄露.
分析一下原因, 当 Activity.setContentView() 方法时, 布局中的每一个 View 在实例化都会将 Activity 的 Context 作为引用 (作为 View 的构造函数) 来创建一个实例. 如果发生这种情况, 我们就需要及时在 view 不再使用时, 将其赋值为 null 来垃圾回收这个对象. 我们在此基础上, 再更近一层.
解决方案 - 我们需要在 onStop 和 onDestroy 回调函数中, 将 View 赋值为 null. 这里提一下尽量在 onStop 进行处理, 这样更安全. 有关为什么尽量在 onStop 而不是 onDestroy 处理, 请见《都市的轮回》. 但是这个解决方案, 并不完美, 他可能导致 NullPointerException 因为设置为 null 可能在下一次实例化不当.
所以终极解决方案就是 - 避免使用静态类.
待续
来源: http://www.jianshu.com/p/17c7b6563d14