android优化内存
㈠ android为什么要内存优化
android为什么要内存优化是为了防止Android的内存溢出
Android的内存溢出是如何发生的?
Android的虚拟机是基于寄存器的Dalvik，它的最大堆大小一般是16M，有的机器为24M。因此所能利用的内存空间是有限的。如果内存占用超过了一定的水平就会出现OutOfMemory的错误。
为什么会出现内存不够用的情况呢？原因主要有两个：由于程序的失误，长期保持某些资源（如Context）的引用，造成内存泄露，资源造成得不到释放。
保存了多个耗用内存过大的对象（如Bitmap），造成内存超出限制。
在android的开发中，要时刻主要内存的分配和垃圾回收，因为系统为每一个dalvik虚拟机分配的内存是有限的，在google的G1中，分配的最大堆大小只有16M，后来的机器一般都为24M，实在是少的可怜。这样就需要在开发过程中要时刻注意。不要因为自己的代码问题而造成OOM错误。
Android的优化方式
Android的程序由java语言编写，所以Android的内存管理与Java的内存管理相似。程序员通过new为对象分配内存，所有对象在java堆内分配空间；然而对象的释放是由垃圾回收器来完成的。C／C++中的内存机制是“谁污染，谁治理”，java的就比较人性化了，给我们请了一个专门的清洁工（GC）。
那么GC怎么能够确认某一个对象是不是已经被废弃了呢？Java采用了有向图的原理。Java将引用关系考虑为图的有向边，有向边从引用者指向引用对象。线程对象可以作为有向图的起始顶点，该图就是从起始顶点开始的一棵树，根顶点可以到达的对象都是有效对象，GC不会回收这些对象。如果某个对象 (连通子图)与这个根顶点不可达(注意，该图为有向图)，那么认为这个(这些)对象不再被引用，可以被GC回收
㈡ android开发内存优化之如何有效避免oom
减小对象的内存占用
内存对象的重复利用
避免对象的内存泄露
内存使用策略优化
设计风格很大程度上会影响到程序的内存与性能，相对来说，如果大量使用类似Material Design的风格，不仅安装包可以变小，还可以减少内存的占用，渲染性能与加载性能都会有一定的提升。
内存优化并不就是说程序占用的内存越少就越好，如果因为想要保持更低的内存占用，而频繁触发执行gc操作，在某种程度上反而会导致应用性能整体有所下降，这里需要综合考虑做一定的权衡。
Android的内存优化涉及的知识面还有很多：内存管理的细节，垃圾回收的工作原理，如何查找内存泄漏等等都可以展开讲很多。OOM是内存优化当中比较突出的一点，尽量减少OOM的概率对内存优化有着很大的意义。
㈢ android中怎么实现内存优化
不少人认为JAVA程序，因为有垃圾回收机制，应该没有内存泄露。其实如果我们一个程序中，已经不再使用某个对象，但是因为仍然有引用指向它，垃圾回收器就无法回收它，当然该对象占用的内存就无法被使用，这就造成了内存泄露。如果我们的java运行很久,而这种内存泄露不断的发生，最后就没内存可用了。当然java的，内存泄漏和C/C++是不一样的。如果java程序完全结束后，它所有的对象就都不可达了，系统就可以对他们进行垃圾回收，它的内存泄露仅仅限于它本身，而不会影响整个系统的。C/C++的内存泄露就比较糟糕了，它的内存泄露是系统级，即使该C/C++程序退出，它的泄露的内存也无法被系统回收，永远不可用了，除非重启机器。
http://www.cnblogs.com/kingOfPointer/archive/2012/12/21/2828018.html
详细可以参考这个，有图解教程，希望可以帮到你
㈣ android 性能优化有哪些办法
性能优化的常用方法
主要内容包括布局优化，绘制优化，内存泄露优化，相应速度优化，ListView优化，Bitmap优化，线程优化等，下面主要给你举了其中的几个例子：
(1)布局优化
布局优化的思想很简单，就是尽量减少布局文件的层级。
如何进行优化呢？首先删除布局中无用的控件和层级，其次有选择地使用性能较低的ViewGroup，比如LinearLayout。如果布局中有的布局既可以用LinearLayout也可以用RelativeLayout，那就用LinearLayout,这是因为RelativeLayout比较复杂，他的布局过程花费更多的CPU时间。FrameLayout和LinearLayout一样都是一种简单高效的ViewGroup，因此可以考虑使用他们，但是很多时候，单纯的通过一个LinearLayout或者FrameLayout无法实现产品的效果，需要通过嵌套的方式来完成，这种情况建议采用RelativeLayout，因为ViewGroup的嵌套就相当于增加了布局的层级，同样会降低程序的性能。
布局优化的另一种手段是采用<include>标枪,<merge>标签和ViewStub。<include>标签主要用于布局重用，<merge>标签一般和<include>配合使用，它可以减少布局的层级。而ViewStub则提供了按需加载功能，当需要时才将ViewStub中的布局加载到内存，这提高了程序的初始化效率。
(2)绘制方法
绘制优化是指View的onDraw方法避免执行大量的操作，这主要有两方面。
首先，onDraw中不要创建新的布局对象，这是因为onDraw方法可能会被频繁调用，这样就会在一瞬间产生大量的临时对象，这不仅占用了过多的内存而且还会导致系统更加频繁的gc，降低了程序的执行效率。
另一方面，onDraw方法中不要做耗时的任务，也不能执行成千上万次循环操作，尽管每次循环都很轻量级，但是大量的循环仍然十分抢占CPU的时间片，这会造成View的绘制过程不流畅。
(3)内存泄露优化
内存泄露在开发过程中是一个需要重视的问题，但是由于内存泄露问题对开发人员的经验和开发意识要求比较高，因此这是开发人员最容易犯的错误之一。内存泄露的优化分为两个方面，一方面是在开发过程中避免写出内存泄露的代码，另一方面通过一些分析工具比如MAT来找出潜在的内存泄露继而解决。
关于性能优化的建议
1.避免黄健过多对象；
2.不要过多使用枚举，枚举占用的内存空间比整型大一些。
3.常量使用staticfinal来修饰。
4.使用一些Android特有的数据结构，比如SpareArray和Pair等，他们都具有更好的性能。
5.适当使用软引用和弱引用。
6.采用内存缓存和磁盘缓存
7.尽量采用静态内部类，这样可以避免潜在的内部类而导致的内存泄漏。
㈤ 在Android开发中，有哪些好的内存优化方式
1. 使用更加轻量的数据结构
例如，我们可以考虑使用ArrayMap/SparseArray而不是HashMap等传统数据结构。通常的HashMap的实现方式更加消耗内存，因为它需要一个额外的实例对象来记录Mapping操作。另外，SparseArray更加高效，在于他们避免了对key与value的自动装箱（autoboxing），并且避免了装箱后的解箱。
2. 避免在Android里面使用Enum
Android官方培训课程提到过“Enums often require more than twice as much memory as static constants. You should strictly avoid using enums on Android.”，具体原理请参考《Android性能优化典范（三）》，所以请避免在Android里面使用到枚举。
3. 减小Bitmap对象的内存占用
Bitmap是一个极容易消耗内存的大胖子，减小创建出来的Bitmap的内存占用可谓是重中之重，，通常来说有以下2个措施：
inSampleSize：缩放比例，在把图片载入内存之前，我们需要先计算出一个合适的缩放比例，避免不必要的大图载入。
decode format：解码格式，选择ARGB_8888/RBG_565/ARGB_4444/ALPHA_8，存在很大差异
4.Bitmap对象的复用
缩小Bitmap的同时，也需要提高BitMap对象的复用率，避免频繁创建BitMap对象，复用的方法有以下2个措施
LRUCache : “最近最少使用算法”在Android中有极其普遍的应用。ListView与GridView等显示大量图片的控件里，就是使用LRU的机制来缓存处理好的Bitmap，把近期最少使用的数据从缓存中移除，保留使用最频繁的数据，
inBitMap高级特性:利用inBitmap的高级特性提高Android系统在Bitmap分配与释放执行效率。使用inBitmap属性可以告知Bitmap解码器去尝试使用已经存在的内存区域，新解码的Bitmap会尝试去使用之前那张Bitmap在Heap中所占据的pixel data内存区域，而不是去问内存重新申请一块区域来存放Bitmap。利用这种特性，即使是上千张的图片，也只会仅仅只需要占用屏幕所能够显示的图片数量的内存大小
4. 使用更小的图片
在涉及给到资源图片时，我们需要特别留意这张图片是否存在可以压缩的空间，是否可以使用更小的图片。尽量使用更小的图片不仅可以减少内存的使用，还能避免出现大量的InflationException。假设有一张很大的图片被XML文件直接引用，很有可能在初始化视图时会因为内存不足而发生InflationException，这个问题的根本原因其实是发生了OOM。
5.StringBuilder
在有些时候，代码中会需要使用到大量的字符串拼接的操作，这种时候有必要考虑使用StringBuilder来替代频繁的“+”。
6.避免在onDraw方法里面执行对象的创建
类似onDraw等频繁调用的方法，一定需要注意避免在这里做创建对象的操作，因为他会迅速增加内存的使用，而且很容易引起频繁的gc，甚至是内存抖动。
7. 避免对象的内存泄露
类的静态变量持有大数据对象
静态变量长期维持到大数据对象的引用，阻止垃圾回收。
非静态内部类存在静态实例
非静态内部类会维持一个到外部类实例的引用，如果非静态内部类的实例是静态的，就会间接长期维持着外部类的引用，阻止被回收掉。
资源对象未关闭
资源性对象比如（Cursor，File文件等）往往都用了一些缓冲，我们在不使用的时候，应该及时关闭它们， 以便它们的缓冲及时回收内存。它们的缓冲不仅存在于java虚拟机内，还存在于java虚拟机外。 如果我们仅仅是把它的引用设置为null,而不关闭它们，往往会造成内存泄露。
解决办法： 比如SQLiteCursor（在析构函数finalize（）,如果我们没有关闭它，它自己会调close()关闭）， 如果我们没有关闭它，系统在回收它时也会关闭它，但是这样的效率太低了。 因此对于资源性对象在不使用的时候，应该调用它的close()函数，将其关闭掉，然后才置为null. 在我们的程序退出时一定要确保我们的资源性对象已经关闭。 程序中经常会进行查询数据库的操作，但是经常会有使用完毕Cursor后没有关闭的情况。如果我们的查询结果集比较小， 对内存的消耗不容易被发现，只有在常时间大量操作的情况下才会复现内存问题，这样就会给以后的测试和问题排查带来困难和风险，记得try catch后，在finally方法中关闭连接
Handler内存泄漏
Handler作为内部类存在于Activity中，但是Handler生命周期与Activity生命周期往往并不是相同的，比如当Handler对象有Message在排队，则无法释放，进而导致本该释放的Acitivity也没有办法进行回收。
㈥ 安卓手机运行内存太小怎么进行优化
安卓系统手机为智能机器，和电脑一样，为了保证手机正常使用，会自动开启部分程序进程（不是程序），当您清除之后，进程还是会再次显示。若经常有程序自动启动占用手机内存，建议：
1.关闭后台运行的程序：点击屏幕左下角近期任务键-点击要关闭的应用程序右上角的“X”/下方的关闭全部（部分机器操作方式：长按HOME键（主屏幕键)启动任务管理器，点击左下角饼形图标，点击清除RAM数据）。
2.部分机器支持智能管理器或内存管理器，建议通过该功能手动关闭自动运行的应用程序。
3.部分第三方软件支持开机后自动启动功能，建议打开自动运行的软件禁用此功能。
㈦ android 清理内存的方法
1.打开手机，找到手机的“设置”。
2.找到“应用管理”，点击进入。
3.找到“全部”，点击任意应用，然后清理应用中的“清理缓存”。
4.所用手机应用都可以这样来清理手机缓存的。
备注：最简单粗鲁的办法就是关机重启手机，手机就不太卡了
㈧ android 内存优化
android 内存优化？1.内存模型与分布
我们知道android应用大多是使用java语言进行开发的，这就需要我们了解java的内存模型，此外在android中的应用都是基于Dalvik 虚拟机或者ART虚拟机，那么对这些虚拟机的内存分布也应该有所了解。
Java内存分布模型
上图是常见的java虚拟机的内存分布图：
方法区：主要存储虚拟机加载的类信息，常量，静态变量，及时编译器编译后的代码等数据。内存优化时这一部分主要考虑是不是加载了很多不必要的第三方库。这部分的内存减少主要是常量池的回收和类的卸载（类卸载条件：无引用，类加载器可卸载）
堆：几乎所有的对象都在这个区域产生，该区域属于线程共享的区域，所以写代码时更要注意多线程安全。这个内存区域的大小变化主要是对象的创建和回收，比如：如果短时间内有大量的对象创建和回收，可能会造成内存抖动，如果对象创建之后一直回收不掉，则会导致内存泄漏，严重的内存泄漏会导致频繁的gc，从而是界面卡顿。
虚拟机栈：这个区域描述的是java方法执行的内存模型，我们常说的方法栈的入栈就是将方法的栈帧存储到虚拟机栈，这个区域是线程私有的，其生命周期就是线程的生命周期。也就是说每个线程都会有，默认一个线程的线程栈大小是1M，这不包括在方法中产生的其他对象的大小。这一块我们能控制的就是线程的数量，特别是程序中没有使用线程池或者使用的多个第三方库都带有线程池的情况。
本地方法栈：同虚拟机栈的作用非常类似，是为虚拟机执行native方法服务的，所以需要注意的地方也和虚拟机栈一样，特别是使用了第三方so的情况
程序计数器：当前线程执行的虚拟机字节码的行号记录器，占用的内存较小，可以不考虑
2.内存限制
android是基于linux系统的，android中的进程分为两种：
1.native进程：采用C/C++实现，不包含dalvik实例的linux进程，/system/bin/目录下面的程序文件运行后都是以native进程形式存在的
2.java进程：实例化了dalvik虚拟机实例的linux进程，进程的入口main函数为java函数。dalvik虚拟机实例的宿主进程是fork()系统调用创建的linux进程，所以每一个android上的java进程实际上就是一个linux进程，只是进程中多了一个dalvik虚拟机实例
我们知道，操作系统对进程的内存是有限制的，而且操作系统对dalvik虚拟机自身的堆内存大小也是有限制的。可以通过如下命令查看限制大小：
adb shell getprop | grep dalvik.vm.heapgrowthlimit
可以在Androidmanifest文件中application节点加入android:largeHeap=“true”来增加其dalvik虚拟机中堆的大小
我们常说的堆大小其实是包涵两部分的，一是java的堆，而是native的堆，java堆中主要是一下java对象，由 C/C++申请的内存空间则在native堆中，也有一些对象需要结合native和java堆共同完成，比如bitmap，bitmap分为bitmap对象和其中存储的像素值，对象分配在java堆，而存储的像素值则根据版本不同存储的位置也不同，api 11 - api 25是存储在java堆中的，其他版本是存储在native堆中的
3.内存泄漏
常见的内存泄漏：
1.静态引用（自身代码和第三方代码）
2.集合内引用
3.Handler消息未清除
4.非静态的内部类中持有外部内的应用
5.匿名内部类/非静态内部类和异步线程
检查的方式：
我这里使用的是leakcanary，一般简单的内存泄漏可以直接在leakcanary中查到引用链路，不能查看的我是使用MAT来分析的
当前内存信息
上图中各项详细的指标的意义可以在这里查到，这里主要占比比较大的几个区域：
allocated：表示app内分配的java的对象数，从当前数值可以看出程序内可能存在过多创建对象的情况，比如string对象
Native：从 C 或 C++ 代码分配的对象内存，频繁进出相关页面发现native堆的大小并没有减小，说明存在c/c++层的内存泄漏
Code：您的应用用于处理代码和资源（如 dex 字节码、已优化或已编译的 dex 码、.so 库和字体）的内存。这个区域能优化的就是移除不需要的so库，懒加载使用so库，移除无用代码（import，方法和类）
4.优化实践
了解了android中的内存分布和泄漏相关，接下来就是结合自身业务进行内存优化了，如下：
1.先解决程序中内存占用较大的业务模块中的内存泄漏，不熟悉MAT的使用的可以看看这个
2.移除程序中多余的代码和引用，这里使用默认的lint检测再配合shrinkResources来删除无效资源
3.优化图片，保证图片放置在合理的文件夹，根据View大小加载合适的图片大小，根据手机状态配置bitmap和回收策略
4.优化对象创建，比如string，使用对象池等
㈨ android 内存优化有哪些方法
增加优化代码，在system/build.prop添加指定代码（有变砖风险），楼主慎重操作，
或者刷内核,当然也有一些其他的方法，不过对于安卓手机就这样，除非换手机，毕竟安卓只能拼配置
㈩ android 如何更好的回收内存空间，有没有强
Android内存优化大全
OOM：
内存泄露可以引发很多的问题：
1.程序卡顿，响应速度慢（内存占用高时JVM虚拟机会频繁触发GC）
2.莫名消失（当你的程序所占内存越大，它在后台的时候就越可能被干掉。反之内存占用越小，在后台存在的时间就越长）
3.直接崩溃（OutOfMemoryError）
ANDROID内存面临的问题：
1.有限的堆内存，原始只有16M
2.内存大小消耗等根据设备，操作系统等级，屏幕尺寸的不同而不同
3.程序不能直接控制
4.支持后台多任务处理（multitasking）
5.运行在虚拟机之上
5R：
本文主要通过如下的5R方法来对ANDROID内存进行优化：
1.Reckon（计算）
首先需要知道你的app所消耗内存的情况，知己知彼才能百战不殆
2.Rece（减少）
消耗更少的资源
3.Reuse（重用）
当第一次使用完以后，尽量给其他的使用
5.Recycle（回收）
返回资源给生产流
4.Review（检查）
回顾检查你的程序，看看设计或代码有什么不合理的地方。
详细