app都受这个限制，排除内置播放器厂商自己修改

没有没有这个

当前只有一个activity 运行activity使用了110个array对象  如果开启一个activity array数值增长 那么在关闭的时候就会对应关闭新开启的array对象，但是由于内存泄漏导致新开启的activity被Thread引用关闭不了 所以其中的array对象会一直增加

老师讲的不错，代码如果现场敲估计效果会更好。。。

官方的LruCache是维护一个队列，每次被使用到的都放到队头，队尾那个就是最少使用的，思路供你参考。

可以，但要注意空指针

我也想要

我不是老师哈，但我可以给你简单的聊一下。

虚拟机的内存不是说一上来就给你分多少，然后就不变了，是会根据程序的需要变化的。你可以多多的写几个APP然后run.totalMemory();看看每个的总内存，肯定都是在变化的。

这个所谓的虚拟机，说白了也就是操作系统的一个进程而已，你通过任务查看器看看进程，有哪个进程的内存是一直不变化的啊？系统分配给进程的内存肯定是动态的，记住“随用随取”四个字就好了

一开始就创建一个数组，并且逐一对数组进行随机赋值，如此循环下去。简单的说就是外面那一层循环再短时间之内创建了大量的strMatrix，而内存抖动发生的原因就是短时间内有大量的对象被创建或者被回收的现象两种情况，所以讲师给的解释是将创建数组这个行为放到外部，以此避免大量对象被短时间内创建。

这里应该只是模拟gc没有对它进行回收

此课程的重点在于介绍内存的优化，用哪种方法演示都可。

一般不特殊指定的话  一个APP就是对应一个 虚拟机。但是大部分时候  尤其是大公司   会在manifest.xml  的process中 指定 进程名字。所以就会出现一个 APP对应多个进程的情况

gc回收不是你控制的,在最后的那个地方回收了,所以变小了,中间的是因为还没有回收

hashMap默认容量16，装载因子0.75，超过装载因子容量自动翻倍，这个过程要重组数组结构，比较费时和费内存。所以如果动态加载大量数据时要注意。但查找数据正常时快于以下两个，因为hash是直接定位，而下面两个是二分法查找。

所以，如果是装载静态字典，继续用HashMap。

满足下面两个条件我们可以使用SparseArray代替HashMap：

数据量不大，最好在千级以内

key必须为int类型，这中情况下的HashMap可以用SparseArray代替：

SparseArray和ArrayMap都差不多，使用哪个呢？ 

假设数据量都在千级以内的情况下：

1、如果key的类型已经确定为int类型，那么使用SparseArray，因为它避免了自动装箱的过程，如果key为long类型，它还提供了一个LongSparseArray来确保key为long类型时的使用

2、如果key类型为其它的类型，则使用ArrayMap

详见：

http://blog.csdn.net/u010687392/article/details/47809295