电脑卡是什么原因造成的，是因为电脑内存太小了吗。_百度知道6438人阅读
android（21）
在网上看了部分Android中OOM的问题，现在根据理解，做一下笔记。
Android OOM 产生的几种原因
1. 程序中使用了太多自己创建的Bitmap.
这种情况通常是最好解决的. 因为你明白你在哪里使用了这些Bitmap, 在什么时候就不需要了.
大部分情况是因为重复创建bitmap, 而不使用的bitmap没有被及时释放, 导致了 oom. 所以在不使用的时候要将bitmap对象回收bitmap.recycle(), 并将bitmap对象置为null.
还有就是当你一次性使用过多bitmap的时候也会导致oom. 比如使用系统的Gallery组件, 然后在每一项使用自己的图片, 这个时候我们通常自定义Gallery的adapter. 当Gallery需要显示很多图片的时候, 而我们没有做图片缓存机制的话必然会导致oom发生. 所以这个时候需要做图片缓存机制. 例如只保存当前显示项前后3项的图片, 滑动Gallery的时候再根据当前项动态回收前后不需要的图片和加载需要的图片.
2. 程序中一些对象创建的时候需要context的时候.
这种情况, 通常我们会使用create(this);这个时候引用的时候activity的context, 如果该对象没有被及时回收, activity的引用将被它保留, 从而导致activity不能被及时销毁, 当重复创建activity后, 就会导致activity有多个实例, 从而导致内存泄露.所以在用到context的时候尽量使用application的context: getApplicationContext().
3. 查询数据库没有关闭游标
程序中经常会进行查询数据库的操作，但是经常会有使用完毕Cursor 后没有关闭的情况。如果我们的查询结果集比较小，对内存的消耗不容易被发现，只有在常时间大量操作的情况下才会复现内存问题，这样就会给以后的测试和问题排查带来困难和风险。所以在使用完游标以后要cursor.close();
4.构造Adapter时，没有使用缓存的convertView
以构造ListView的BaseAdapter为例，在BaseAdapter中提供了方法：
publicView getView(int position, ViewconvertView, ViewGroup parent)
来向ListView提供每一个item所需要的view对象。初始时ListView会从BaseAdapter中根据当前的屏幕布局实例化一定数量的 view对象，同时ListView会将这些view对象缓存起来。当向上滚动ListView时，原先位于最上面的list item的view对象会被回收，然后被用来构造新出现的最下面的listitem。这个构造过程就是由getView()方法完成的，getView()的第二个形参View convertView就是被缓存起来的list
item的view对象(初始化时缓存中没有view对象则convertView是null)。由此可以看出，如果我们不去使用convertView，而是每次都在getView()中重新实例化一个View对象的话，即浪费资源也浪费时间，也会使得内存占用越来越大。&
MAT定位内存泄露
看Histogram(类统计图)
histogram视图显示了每个类有多少实例，并可以按照这些实例占据的Retained size和Shallow size排序。通过过滤包名，很容易发现有问题的类。
看Dominator Tree
这个视图非常强大，它把所有实例按Retainedheap和Shallow
heap列出来；并且，只要展开就可以看到这个实例所占有的实例（换句话说，如果该对象被释放，还会有哪些对象被释放）
有效解决加载多图，大图产生的OOM问题。
在你应用程序的UI界面加载一张图片是一件很简单的事情，但是当你需要在界面上加载一大堆图片的时候，情况就变得复杂起来。在很多情况下，（比如使用ListView, GridView 或者 ViewPager 这样的组件），屏幕上显示的图片可以通过滑动屏幕等事件不断地增加，最终导致OOM。
为了保证内存的使用始终维持在一个合理的范围，通常会把被移除屏幕的图片进行回收处理。此时垃圾回收器也会认为你不再持有这些图片的引用，从而对这些图片进行GC操作。用这种思路来解决问题是非常好的，可是为了能让程序快速运行，在界面上迅速地加载图片，你又必须要考虑到某些图片被回收之后，用户又将它重新滑入屏幕这种情况。这时重新去加载一遍刚刚加载过的图片无疑是性能的瓶颈，你需要想办法去避免这个情况的发生。
这个时候，使用内存缓存技术可以很好的解决这个问题，它可以让组件快速地重新加载和处理图片。下面我们就来看一看如何使用内存缓存技术来对图片进行缓存，从而让你的应用程序在加载很多图片的时候可以提高响应速度和流畅性。
内存缓存技术对那些大量占用应用程序宝贵内存的图片提供了快速访问的方法。其中最核心的类是LruCache (此类在android-support-v4的包中提供) 。这个类非常适合用来缓存图片，它的主要算法原理是把最近使用的对象用强引用存储在LinkedHashMap 中，并且把最近最少使用的对象在缓存值达到预设定值之前从内存中移除。
在过去，我们经常会使用一种非常流行的内存缓存技术的实现，即软引用或弱引用 (SoftReference or WeakReference)。但是现在已经不再推荐使用这种方式了，因为从 Android 2.3 (API Level 9)开始，垃圾回收器会更倾向于回收持有软引用或弱引用的对象，这让软引用和弱引用变得不再可靠。另外，Android 3.0 (API Level
11)中，图片的数据会存储在本地的内存当中，因而无法用一种可预见的方式将其释放，这就有潜在的风险造成应用程序的内存溢出并崩溃。
内存分配大小考虑因素：
你的设备可以为每个应用程序分配多大的内存？
设备屏幕上一次最多能显示多少张图片？有多少图片需要进行预加载，因为有可能很快也会显示在屏幕上？
你的设备的屏幕大小和分辨率分别是多少？一个超高分辨率的设备（例如 Galaxy Nexus)比起一个较低分辨率的设备（例如 Nexus S），在持有相同数量图片的时候，需要更大的缓存空间。
图片的尺寸和大小，还有每张图片会占据多少内存空间。
图片被访问的频率有多高？会不会有一些图片的访问频率比其它图片要高？如果有的话，你也许应该让一些图片常驻在内存当中，或者使用多个LruCache对象来区分不同组的图片。
你能维持好数量和质量之间的平衡吗？有些时候，存储多个低像素的图片，而在后台去开线程加载高像素的图片会更加的有效。
针对大图的图片压缩技术
在展示高分辨率图片的时候，最好先将图片进行压缩。压缩后的图片大小应该和用来展示它的控件大小相近，在一个很小的ImageView上显示一张超大的图片不会带来任何视觉上的好处，但却会占用我们相当多宝贵的内存，而且在性能上还可能会带来负面影响。下面我们就来看一看，如何对一张大图片进行适当的压缩，让它能够以最佳大小显示的同时，还能防止OOM的出现。
BitmapFactory这个类提供了多个解析方法(decodeByteArray,decodeFile, decodeResource等)用于创建Bitmap对象，我们应该根据图片的来源选择合适的方法。比如SD卡中的图片可以使用decodeFile方法，网络上的图片可以使用decodeStream方法，资源文件中的图片可以使用decodeResource方法。这些方法会尝试为已经构建的bitmap分配内存，这时就会很容易导致OOM出现。为此每一种解析方法都提供了一个可选的BitmapFactory.Options参数，将这个参数的inJustDecodeBounds属性设置为true就可以让解析方法禁止为bitmap分配内存，返回值也不再是一个Bitmap对象，而是null。虽然Bitmap是null了，但是BitmapFactory.Options的outWidth、outHeight和outMimeType属性都会被赋值。这个技巧让我们可以在加载图片之前就获取到图片的长宽值和MIME类型，从而根据情况对图片进行压缩。
解决OOM问题的Demo
的工程结构如图所示：
LruMemoryCache主要是用来管理图片的缓存。MainActivity中有个GridView主要用来显示大量的大图片。MyAdapter中是为GridView加载图片用的。
主要代码：
LruMemoryCache.java
public class LruMemoryCache extends LruCache&String, Bitmap& {
public LruMemoryCache(int maxSize) {
super(maxSize);
protected int sizeOf(String key, Bitmap bitmap) {
// 重写此方法来衡量每张图片的大小，默认返回图片数量。
return bitmap.getByteCount() / 1024;
public void addBitmapToMemoryCache(String key, Bitmap bitmap) {
if (getBitmapFromMemCache(key) == null) {
put(key, bitmap);
public Bitmap getBitmapFromMemCache(String key) {
return get(key);
MyAdapter.java
class MyAdapter extends BaseAdapter {
private Context context =
private LruMemoryCache mMemoryCache =
private int[] resIDs =
public MyAdapter(Context context, LruMemoryCache memoryCacher, int[] ids) {
this.context =
mMemoryCache = memoryC
public int getCount() {
return resIDs.
public Object getItem(int arg0) {
return resIDs[arg0];
public long getItemId(int position) {
public View getView(int position, View convertView, ViewGroup parent) {
if (convertView == null) {
ImageView imageView = new ImageView(context);
convertView = imageV
// 交替执行下面两句代码，看看显示结果。
((ImageView) convertView).setImageResource(resIDs[position]);
loadBitmap(resIDs[position], (ImageView)convertView);
return convertV
public void loadBitmap(int resId, ImageView imageView) {
final String imageKey = String.valueOf(resId);
final Bitmap bitmap = mMemoryCache.getBitmapFromMemCache(imageKey);
if (bitmap != null) {
imageView.setImageBitmap(bitmap);
imageView.setImageResource(R.drawable.ic_launcher);
BitmapWorkerTask task = new BitmapWorkerTask(imageView);
task.execute(resId);
public static int calculateInSampleSize(BitmapFactory.Options options, int reqWidth, int reqHeight) {
// 源图片的高度和宽度
final int height = options.outH
final int width = options.outW
int inSampleSize = 1;
if (height & reqHeight || width & reqWidth) {
// 计算出实际宽高和目标宽高的比率
final int heightRatio = Math.round((float) height / (float) reqHeight);
final int widthRatio = Math.round((float) width / (float) reqWidth);
// 选择宽和高中最小的比率作为inSampleSize的值，这样可以保证最终图片的宽和高
// 一定都会大于等于目标的宽和高。
inSampleSize = heightRatio & widthRatio ? heightRatio : widthR
return inSampleS
public static Bitmap decodeSampledBitmapFromResource(Resources res, int resId, int reqWidth, int reqHeight) {
// 第一次解析将inJustDecodeBounds设置为true，来获取图片大小
final BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds =
BitmapFactory.decodeResource(res, resId, options);
// 调用上面定义的方法计算inSampleSize值
options.inSampleSize = calculateInSampleSize(options, reqWidth, reqHeight);
// 使用获取到的inSampleSize值再次解析图片
options.inJustDecodeBounds =
return BitmapFactory.decodeResource(res, resId, options);
class BitmapWorkerTask extends AsyncTask&Integer, Void, Bitmap& {
ImageView mImageV
public BitmapWorkerTask(ImageView imageView) {
mImageView = imageV
// 在后台加载图片。
protected Bitmap doInBackground(Integer... params) {
final Bitmap bitmap = decodeSampledBitmapFromResource(context.getResources(), params[0], 100, 100);
mMemoryCache.addBitmapToMemoryCache(String.valueOf(params[0]), bitmap);
Log.i(&TAG_SYL&, &====memoryCache sum: & + mMemoryCache.size() / 1024);
protected void onPostExecute(Bitmap result) {
mImageView.setImageBitmap(result);
super.onPostExecute(result);
MainActivity.java
public class MainActivity extends Activity {
private LruMemoryCache mMemoryC
private GridView gridView =
private TextView textView =
private int[] imageResIds = { R.drawable.a1, R.drawable.a2, R.drawable.a3, R.drawable.a4, R.drawable.a5, R.drawable.a6, R.drawable.a7, R.drawable.a8, R.drawable.a9, R.drawable.a10,
R.drawable.a11, R.drawable.a12, R.drawable.a13, R.drawable.a14, R.drawable.a15, R.drawable.a16, R.drawable.a17, R.drawable.a18, R.drawable.a19, R.drawable.a20, R.drawable.a21, R.drawable.a22,
R.drawable.a23, R.drawable.a24, R.drawable.a25, R.drawable.a26, R.drawable.a27, R.drawable.a28, R.drawable.a29, R.drawable.a30, R.drawable.a31, R.drawable.a32, R.drawable.a33, R.drawable.a34};
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
initLruCache();
setupView();
private void setupView() {
gridView = (GridView) findViewById(R.id.gridview);
MyAdapter myAdapter = new MyAdapter(this, mMemoryCache, imageResIds);
gridView.setAdapter(myAdapter);
textView = (TextView) findViewById(R.id.textView);
textView.setText(&缓存空间大小： & + mMemoryCache.maxSize() / 1024 + &MB&);
public boolean onCreateOptionsMenu(Menu menu) {
// I this adds items to the action bar if it is present.
getMenuInflater().inflate(R.menu.activity_main, menu);
private void initLruCache() {
// 获取到可用内存的最大值，使用内存超出这个值会引起OutOfMemory异常。
// LruCache通过构造函数传入缓存值，以KB为单位。
int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);
// 使用最大可用内存值的1/8作为缓存的大小。
int cacheSize = maxMemory / 8;
mMemoryCache = new LruMemoryCache(cacheSize);
运行环境：本机的内存64M，设置缓存大小为8M,可以看到有图片被回收后加载默认的图片。在打印信息中可以看出，缓存大小一直小于8M。
感兴趣的可以调整缓存大小，看看现实效果和打印结果。
当不使用缓存，直接加载图片，会出现OOM的错误显示结果和打印信息如下
源码地址：
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：147492次
积分：1817
积分：1817
排名：第15665名
原创：26篇
转载：23篇
评论：66条
(1)(1)(1)(1)(1)(2)(1)(2)(2)(1)(1)(1)(3)(1)(1)(1)(1)(6)(15)(1)(3)(4)(1)显示卡和内存够不够游戏的最低配置会造成什么问题拜托了各位 谢谢_百度知道问一个小问题电脑内存条是DDR4的用不一样的牌子会不会不兼容谢谢谢谢_百度知道8g的内存，但是只打开几个程序就运行不动了，各位大神看看，是否有那些硬件冲突？？_百度知道}