// :唯一的标示BaseUI的子类
// 每增加一个界面150K-16M
// 内存不足的时候
// 处理的方案:
// 第一种方式:控制VIEWCAHCE集合的size
// 第二种方式:使用Fragment代替,replace方法,不会缓存界面
// 第三种方式:将BaseUI引用级别降低
// 当前级别---强引用(GC宁可抛出OOM,也不会回收BaseUI)
// 还有其他引用级别:
// 软引用:在OOM之前被GC回收掉------十分有用
// 弱引用:一旦GC发现了就回收掉
// 虚引用:一旦创建了就会回收
// 三个方案都存在优点和缺点
// 方案一:优点-实现简单,但是适应性不强
// 方案二:上一个Fragment被回收了,就不会有什么缓存数据了,当内存充足的时候,运行速度就没办法提升了,运行速度回损失过大
// 方案三:优点....缺点明显:虽然引用级别降低,必须等待GC区回收,必须要提供GC一个回收时间,所以一旦内存申请速度过快,不适用
// -----瀑布流---Lrucache
// 每增加一个界面150K-16M
// 内存不足的时候
// 处理的方案:
// 第一种方式:控制VIEWCAHCE集合的size
// 第二种方式:使用Fragment代替,replace方法,不会缓存界面
// 第三种方式:将BaseUI引用级别降低
// 当前级别---强引用(GC宁可抛出OOM,也不会回收BaseUI)
// 还有其他引用级别:
// 软引用:在OOM之前被GC回收掉------十分有用
// 弱引用:一旦GC发现了就回收掉
// 虚引用:一旦创建了就会回收
// 三个方案都存在优点和缺点
// 方案一:优点-实现简单,但是适应性不强
// 方案二:上一个Fragment被回收了,就不会有什么缓存数据了,当内存充足的时候,运行速度就没办法提升了,运行速度回损失过大
// 方案三:优点....缺点明显:虽然引用级别降低,必须等待GC区回收,必须要提供GC一个回收时间,所以一旦内存申请速度过快,不适用
// -----瀑布流---Lrucache
8万+

被折叠的 条评论
为什么被折叠?



