安卓内存溢出是什么
1. 请问安卓5.x当初的内存溢出是什么原理导致的
纠正一下，是内存泄露
打开设置——应用——正在运行，你会发现“系统”占用越来越大，最后挤满整个运行内存，导致软件无法挂后台，经常自动结束运行，而且系统运行越来越卡，只能通过重启解决。
说白了就是该内存空间使用完毕之后未回收，导致“系统”占用内存过大。
2. android中内存泄漏和内存溢出是一个概念吗
内存泄漏是指分配出去的内存无法回收了
内存泄漏指由于疏忽或错误造成程序未能释放已经不再使用的内存的情况,是应用程序分配某段内存后，由于设计错误，失去了对该段内存的控制，因而造成了内存的浪费。
一般我们常说的内存泄漏是指堆内存的泄漏。堆内存是指程序从堆中分配的，大小任意的（内存块的大小可以在程序运行期决定），使用完后必须显示释放的内存。应用程序一般使用malloc，realloc，new等函数从堆中分配到一块内存，使用完后，程序必须负责相应的调用free或delete释放该内存块，否则，这块内存就不能被再次使用，我们就说这块内存泄漏了。
内存溢出是指程序要求的内存，超出了系统所能分配的范围，从而发生溢出。
内存溢是指在一个域中输入的数据超过它的要求而且没有对此作出处理引发的数据溢出问题，多余的数据就可以作为指令在计算机上运行。
3. 安卓的eclipse内存溢出问题
Eclipse下内存溢出错误(OutOfMemoryError)
Exception in thread "Image Fetcher 0" java.lang.OutOfMemoryError: Java heap space
解决方法：
在Eclipse里选：Window->Preference->Installed JREs->Edit(选中jre)，
在Default VM Arguments里输入-Xms256m -Xmx1024m，表示最小内存256M，最大1G，然后运行就可以了。
4. Android 内存溢出怎么解决
Android 内存溢出的原因和解决方案如下：
1.Android的虚拟机是基于寄存器的Dalvik,它的最大堆大小一般是16M,有的机器为24M.因此我们所能利用的内存空间是有限的.如果我们的内存占用超过了一定的水平就会出现OutOfMemory的错误.原因主要有两个:
l 由于我们程序的失误,长期保持某些资源(如Context)的引用,造成内存泄露,资源造成得不到释放.
l 保存了多个耗用内存过大的对象(如Bitmap),造成内存超出限制.
2. Static
static是Java中的一个关键字,当用它来修饰成员变量时,那么该变量就属于该类,而不是该类的实例.所以用static修饰的变量,它的生命周期是很长的,如果用它来引用一些资源耗费过多的实例(Context的情况最多)就要谨慎对待了.例如xxx源码:
public class IntentMapping {
private static Contextcontext;
//. . .
}
5. 手机内存溢出是怎么回事该怎么办
这个真没办法了，这受手机硬件限制，RAM用来执行JAVA程序的内存太小，运行稍大软件时就出现内存溢出的情况，也就是说有JAVA程序安装上限，真没办法了…你试试你的JAVA上限是多少K，下载比上限小的程序执行。
6. Android 内存溢出和内存泄漏的区别
内存溢出是指当对象的内存占用已经超出分配内存的空间大小，这时未经处理的异常就会抛出。比如常见的内存溢出情况有：bitmap过大；引用没释放；资源对象没关闭
如图，这是常见的bitma对象的溢出，显示像素过高或图片尺寸远远大于显示空间的尺寸时，通常都要将其缩放，减小占用内存。
内存泄漏（memory
leak）
有些对象只有有限的生命周期。当它们的任务完成之后，它们将被垃圾回收。如果在对象的生命周期本该结束的时候，这个对象还被一系列的引用，这就会导致内存泄漏。随着泄漏的累积，app将消耗完内存。
比如，在Activity.onDestroy()被调用之后，view树以及相关的bitmap都应该被垃圾回收。如果一个正在运行的后台线程继续持有这个Activity的引用，那么相关的内存将不会被回收，这最终将导致OutOfMemoryError崩溃。
memory
leak会最终会导致out
of
memory！
如图，这是使用MAT工具查找内存泄漏的结果，例子是
handle
延时发送
message
而在关闭
activity
后
context
被销毁所引发的泄漏，这是作为目的性的测试所以问题比较容易找到，在实际开发中内存泄漏不易察觉并难以找到，当泄漏累积到一定程度是会引发
OOM
的。
7. android开发什么叫内存泄露
下面图片是解决内存泄露的例子。例子来自android学习手册，android学习手册，里面有源码。android学习手册包含9个章节，108个例子，源码文档随便看，例子都是可交互，可运行，源码采用android studio目录结构，高亮显示代码，文档都采用文档结构图显示，可以快速定位。360手机助手中下载,图标上有贝壳
在android程序开发中，当一个对象已经不需要再使用了，本该被回收时，而另外一个正在使用的对象持有它的引用从而导致它不能被回收，这就导致本该被回收的对象不能被回收而停留在堆内存中，内存泄漏就产生了。
内存泄漏有什么影响呢？它是造成应用程序OOM的主要原因之一。由于android系统为每个应用程序分配的内存有限，当一个应用中产生的内存泄漏比较多时，就难免会导致应用所需要的内存超过这个系统分配的内存限额，这就造成了内存溢出而导致应用Crash。
了解了内存泄漏的原因及影响后，我们需要做的就是掌握常见的内存泄漏，并在以后的android程序开发中，尽量避免它。下面小编搜罗了5个android开发中比较常见的内存泄漏问题及解决办法，分享给大家，一起来看看吧。
一、单例造成的内存泄漏
Android的单例模式非常受开发者的喜爱，不过使用的不恰当的话也会造成内存泄漏。因为单例的静态特性使得单例的生命周期和应用的生命周期一样长，这就说明了如果一个对象已经不需要使用了，而单例对象还持有该对象的引用，那么这个对象将不能被正常回收，这就导致了内存泄漏。
如下这个典例：
public class AppManager {
private static AppManager instance;
private Context context;
private AppManager(Context context) {
this.context = context;
}
public static AppManager getInstance(Context context) {
if (instance != null) {
instance = new AppManager(context);
}
return instance;
}
}
这是一个普通的单例模式，当创建这个单例的时候，由于需要传入一个Context，所以这个Context的生命周期的长短至关重要：
1、传入的是Application的Context：这将没有任何问题，因为单例的生命周期和Application的一样长 ；
2、传入的是Activity的Context：当这个Context所对应的Activity退出时，由于该Context和Activity的生命周期一样长（Activity间接继承于Context），所以当前Activity退出时它的内存并不会被回收，因为单例对象持有该Activity的引用。
所以正确的单例应该修改为下面这种方式：
public class AppManager {
private static AppManager instance;
private Context context;
private AppManager(Context context) {
this.context = context.getApplicationContext();
}
public static AppManager getInstance(Context context) {
if (instance != null) {
instance = new AppManager(context);
}
return instance;
}
}
这样不管传入什么Context最终将使用Application的Context，而单例的生命周期和应用的一样长，这样就防止了内存泄漏。
二、非静态内部类创建静态实例造成的内存泄漏
有的时候我们可能会在启动频繁的Activity中，为了避免重复创建相同的数据资源，会出现这种写法：
public class MainActivity extends AppCompatActivity {
private static TestResource mResource = null;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
if(mManager == null){
mManager = new TestResource();
}
//...
}
class TestResource {
//...
}
}
这样就在Activity内部创建了一个非静态内部类的单例，每次启动Activity时都会使用该单例的数据，这样虽然避免了资源的重复创建，不过这种写法却会造成内存泄漏，因为非静态内部类默认会持有外部类的引用，而又使用了该非静态内部类创建了一个静态的实例，该实例的生命周期和应用的一样长，这就导致了该静态实例一直会持有该Activity的引用，导致Activity的内存资源不能正常回收。正确的做法为：
将该内部类设为静态内部类或将该内部类抽取出来封装成一个单例，如果需要使用Context，请使用ApplicationContext 。
三、Handler造成的内存泄漏
Handler的使用造成的内存泄漏问题应该说最为常见了，平时在处理网络任务或者封装一些请求回调等api都应该会借助Handler来处理，对于Handler的使用代码编写一不规范即有可能造成内存泄漏，如下示例：
public class MainActivity extends AppCompatActivity {
private Handler mHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
//...
}
};
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
loadData();
}
private void loadData(){
//...request
Message message = Message.obtain();
mHandler.sendMessage(message);
}
}
这种创建Handler的方式会造成内存泄漏，由于mHandler是Handler的非静态匿名内部类的实例，所以它持有外部类Activity的引用，我们知道消息队列是在一个Looper线程中不断轮询处理消息，那么当这个Activity退出时消息队列中还有未处理的消息或者正在处理消息，而消息队列中的Message持有mHandler实例的引用，mHandler又持有Activity的引用，所以导致该Activity的内存资源无法及时回收，引发内存泄漏，所以另外一种做法为：
public class MainActivity extends AppCompatActivity {
private MyHandler mHandler = new MyHandler(this);
private TextView mTextView ;
private static class MyHandler extends Handler {
private WeakReference<Context> reference;
public MyHandler(Context context) {
reference = new WeakReference<>(context);
}
@Override
public void handleMessage(Message msg) {
MainActivity activity = (MainActivity) reference.get();
if(activity != null){
activity.mTextView.setText("");
}
}
}
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mTextView = (TextView)findViewById(R.id.textview);
loadData();
}
private void loadData() {
//...request
Message message = Message.obtain();
mHandler.sendMessage(message);
}
}
创建一个静态Handler内部类，然后对Handler持有的对象使用弱引用，这样在回收时也可以回收Handler持有的对象，这样虽然避免了Activity泄漏，不过Looper线程的消息队列中还是可能会有待处理的消息，所以我们在Activity的Destroy时或者Stop时应该移除消息队列中的消息，更准确的做法如下：
public class MainActivity extends AppCompatActivity {
private MyHandler mHandler = new MyHandler(this);
private TextView mTextView ;
private static class MyHandler extends Handler {
private WeakReference<Context> reference;
public MyHandler(Context context) {
reference = new WeakReference<>(context);
}
@Override
public void handleMessage(Message msg) {
MainActivity activity = (MainActivity) reference.get();
if(activity != null){
activity.mTextView.setText("");
}
}
}
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mTextView = (TextView)findViewById(R.id.textview);
loadData();
}
private void loadData() {
//...request
Message message = Message.obtain();
mHandler.sendMessage(message);
}
@Override
protected void onDestroy() {
super.onDestroy();
mHandler.removeCallbacksAndMessages(null);
}
}
使用mHandler.removeCallbacksAndMessages(null);是移除消息队列中所有消息和所有的Runnable。当然也可以使用mHandler.removeCallbacks();或mHandler.removeMessages();来移除指定的Runnable和Message。
四、线程造成的内存泄漏
对于线程造成的内存泄漏，也是平时比较常见的，如下这两个示例可能每个人都这样写过：
//——————test1
new AsyncTask<Void, Void, Void>() {
@Override
protected Void doInBackground(Void... params) {
SystemClock.sleep(10000);
return null;
}
}.execute();
//——————test2
new Thread(new Runnable() {
@Override
public void run() {
SystemClock.sleep(10000);
}
}).start();
上面的异步任务和Runnable都是一个匿名内部类，因此它们对当前Activity都有一个隐式引用。如果Activity在销毁之前，任务还未完成， 那么将导致Activity的内存资源无法回收，造成内存泄漏。正确的做法还是使用静态内部类的方式，如下：
static class MyAsyncTask extends AsyncTask<Void, Void, Void> {
private WeakReference<Context> weakReference;
public MyAsyncTask(Context context) {
weakReference = new WeakReference<>(context);
}
@Override
protected Void doInBackground(Void... params) {
SystemClock.sleep(10000);
return null;
}
@Override
protected void onPostExecute(Void aVoid) {
super.onPostExecute(aVoid);
MainActivity activity = (MainActivity) weakReference.get();
if (activity != null) {
//...
}
}
}
static class MyRunnable implements Runnable{
@Override
public void run() {
SystemClock.sleep(10000);
}
}
//——————
new Thread(new MyRunnable()).start();
new MyAsyncTask(this).execute();
这样就避免了Activity的内存资源泄漏，当然在Activity销毁时候也应该取消相应的任务AsyncTask::cancel()，避免任务在后台执行浪费资源。
五、资源未关闭造成的内存泄漏
对于使用了BraodcastReceiver，ContentObserver，File，Cursor，Stream，Bitmap等资源的使用，应该在Activity销毁时及时关闭或者注销，否则这些资源将不会被回收，造成内存泄漏。
8. 如何定位和解决Android的内存溢出问题（大总
一、定位内存泄漏：
可以用LeakCanary:检测所有的内存泄漏
http://www.jcodecraeer.com/a/anzhuokaifa/androidkaifa/2015/0509/2854.html
二、解决：
1.对各种流，文件资源这些比如：InputStream/OutputStream，SQLiteOpenHelper，SQLiteDatabase，Cursor，文件，I/O，Bitmap图片等操作等都应该记得显示关闭。
2.尽量避免static成员变量引用资源耗费过多的实例,比如Context。因为Context的引用超过它本身的生命周期，会导致Context泄漏。所以尽量使用Application这种Context类型。
3.使用线程池，不要newthread
4.UI视图检查，减少视图层级（hierarchyviewer）。
5.图片优化
6. 重用系统资源：系统定义id，系统图片，系统布局，系统style，系统字符串，系统颜色定义
9. 安卓开发中的内存溢出怎样解决
一、内存溢出
现在的智能手机内存已经足够大，但是对于一个应用程序来说智能手机当中稀缺的内存，仍然是应用程序的一大限制。在Android应用程序开发当中，最常见的内存溢出问题（OOM）是在加载图片时出现的，尤其是在不知道图片大小的情况下。
潜在的内存溢出操作主要包括以下几点：
1、从网络当中加载用户特定的图片。因为直到我们在下载图片的时候我们才知道图片的大小。
2、向Gallery加载图片。因为现在智能手机的摄像头有很高的分辨率，在加载图片的时候需要最图片进行处理，然后才能正常的使用。
请注意一点，Android系统是从系统全局的观念来分配内存以加载图片的，这就意味着，即使你的应用有足够大的内存可用，内存溢出问题（out of memroy，OOM）仍然可能出现，因为所有的应用共享一个加载图片的内存池（我们使用BitmapFactory进行解析）。
二、解决内存溢出问题
原文（Downsampling为了好理解，解释为，程序A）。程序A通过调整像素，同时使其均衡化来降低图片的分辨率。因为不管问题图片是因为太大而不能再手机上正常显现，这个图片都会缩短其宽度以在ImageView当中显示，当图片在ImageView当中显示时，我们会因为加载一些没有必要的原始图片而浪费掉内存。
因此，更加有效的加载图片的时机是在其初始化处理的时候。
以下是处理代码：
1: private static Bitmap getResizedImage(String path, byte[] data, int targetWidth){2:3: BitmapFactory.Options options = new BitmapFactory.Options();
14: options.inSampleSize = ssize;15:16: Bitmap bm = null;17: try{18: bm = decode(path, data, options);
19: }catch(OutOfMemoryError e){
39: result = result * 2;40:41: }42:43: return result;44: }三、AQuery当在Android应用程序开发当中使用AQuery组件时，处理这个问题会变的更加的简单。