在这里先说一下在android 系统中使用最广泛的防止内存抖动的一个机制 Message
在android 系统中 Message 是使用最频繁的一个类之一了,整个系统的运行都是建立在 Message 只上的,那么为了防止频繁的创建和销毁对象,Message 又是使用的什么方式来防止内存抖动的呢
1.对象缓存池
public static Message obtain() {
synchronized (sPoolSync) {
if (sPool != null) {
Message m = sPool;
sPool = m.next;
m.next = null;
m.flags = 0; // clear in-use flag
sPoolSize--;
return m;
}
}
return new Message();
}
void recycleUnchecked() {
// Mark the message as in use while it remains in the recycled object pool.
// Clear out all other details.
flags = FLAG_IN_USE;
what = 0;
arg1 = 0;
arg2 = 0;
obj = null;
replyTo = null;
sendingUid = UID_NONE;
workSourceUid = UID_NONE;
when = 0;
target = null;
callback = null;
data = null;
synchronized (sPoolSync) {
if (sPoolSize < MAX_POOL_SIZE) {
next = sPool;
sPool = this;
sPoolSize++;
}
}
}
Message 内部有一个叫做 是Message 的next 属性,用来记录下一个Message 内容,还有一个 sPool 的静态变量,用来保存当前缓存的头结点,那么这就形成了一个由无用消息组成的单链表
由于是无用消息,我们不关心这个消息的内容,所以非常适合现在这种场景
适用场景
在循环中创建重复的对象 , 在onDraw 中组装绘制对象 , ,生产消费模式也比较使用这种情况
下面我们句一个小例子来看一下profiler 中创建了多少个对象
class MainActivity : AppCompatActivity() {
private var isRunning=false
private val queue: LinkedBlockingQueue<TsmMessage> = LinkedBlockingQueue<TsmMessage>()
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
findViewById<View>(R.id.tv_click).setOnClickListener {
isRunning=true
test()
}
findViewById<View>(R.id.tv_end).setOnClickListener {
isRunning=false
}
}
fun test(){
thread {
while (isRunning){
kotlin.runCatching {
queue.add(TsmMessage())
sleep(2)
}
}
}
thread {
while (isRunning){
kotlin.runCatching {
queue.take()
sleep(2)
}
}
}
}
}
在这4秒多的时间里面我们一共创建了9872 个 TsmMessage 的对象
点击一个TsmMessage 可以看到 这个对象的创建和运行的位置,kotlin 有点不准确,但是足够用了
再来看一下我们优化后的效果
从这里我们可以看到 在这个时间段里面,他只创建了12个对象,大大减少了我们创建对象的个数
在项目中比较常见的 String+="abc"
相信绝大多数人在看了这段代码都知道 string + "abc" 都知道jvm 会为我们创建重复的对象 ,如果这句话写在了 循环中 也会造成内存抖动
对于数组 byte[] 数组的回收 Glide Array数据回收机制 LruArrayPool
这个类的路径是 package com.bumptech.glide.load.engine.bitmap_recycle; LruArrayPool
先来说一下他这个类的思想
先来说一下他的put 方法,比较简单
用这个数据的lenght 作为key 放入到map 中, 之后将这个lenght 的数据个数放入到treemap 中,整体的逻辑就是这样的
再来说一下他的get 方法,思想特别神奇,
入参是 length ,他的意思是我要获取一个length 的Array 数据,他会先去treemap 中获取一个等于或者大于length 最接近这个长度的数组key,再根据这个key去map中拿到一个链表中的数据,最后将treemap 的length 的数据个数-1,整个过程完成
他的非常重要的思想就是你想获取一个长度为length 的 array ,我返回给你一个大于或者等于这个length 的array ,满足你的需求
对于数组的回收 Glide Array数据回收机制 LruArrayPool 弊端
再来说一下这个方法的弊端
private final Map<Class<?>, NavigableMap<Integer, Integer>> sortedSizes = new HashMap<>();
弄了一个简易的测试方法发现,在使用Interger 做了Map 的key ,但是我们实际传入的是int 类型,在get 与 put 的过程中 jvm 就会自动实现 对象拆箱装箱的这个操作,也创建了非常多的对象,那么如何去优化他呢, int 作为key 的 Array ,没错 就是SparseArray 的思想,
网友评论