大连企业建设网站,单页网站仿制教程,企业网站设计有名 乐云seo,wordpress播放一、App内存组成以及管理
Android 给每个 App 分配一个 VM #xff0c;让App运行在 dalvik 上#xff0c;这样即使 App 崩溃也不会影响到系统。系统给 VM 分配了一定的内存大小#xff0c; App 可以申请使用的内存大小不能超过此硬性逻辑限制#xff0c;就算物理内存富余让App运行在 dalvik 上这样即使 App 崩溃也不会影响到系统。系统给 VM 分配了一定的内存大小 App 可以申请使用的内存大小不能超过此硬性逻辑限制就算物理内存富余如果应用超出 VM 最大内存就会出现内存溢出 crash即OOM。
由程序控制操作的内存空间在 heap 上分 java heapsize 和 native heapsize 。
1Java申请的内存在 vm heap 上所以如果 java 申请的内存大小超过 VM 的逻辑内存限制,就会出现内存溢出的异常。
2native层内存申请不受其限制, native 层受 native process 对内存大小的限制。
二、Android设备对App的内存限制
如何查看APP的内存大小限制
1. 主要查看系统配置文件 build.prop 我们可以通过 adb shell 在 命令行窗口查看
adb shell cat /system/build.prop 2. 通过代码获取
ActivityManager activityManager
(ActivityManager)context.getSystemService(Context.ACTIVITY_SERVICE)
activityManager.getMemoryClass();//以m为单位
3.修改内存限制
修改 \frameworks\base\core\jni\AndroidRuntime.cpp
int AndroidRuntime::startVm(JavaVM** pJavaVM, JNIEnv** pEnv, bool zygote)
{/** The default starting and maximum size of the heap. Larger* values should be specified in a product property override.*/parseRuntimeOption(dalvik.vm.heapstartsize, heapstartsizeOptsBuf,-Xms, 4m);parseRuntimeOption(dalvik.vm.heapsize, heapsizeOptsBuf, -Xmx,16m);//修改这里
}
修改 platform/dalvik//eclair-release/vm/Init.c
gDvm.heapSizeStart 2 * 1024 * 1024; // Spec says 16MB; too big for us.
gDvm.heapSizeMax 16 * 1024 * 1024; // Spec says 75% physical mem
三、Android内存分配与回收机制
1、内存分配
Android的Heap空间是一个 Generational Heap Memory 的模型最近分配的对象会存放在 Young Generation 区域当一个对象在这个区域停留的时间达到一定程度它会被移动到 Old Generation 最后累积一定时间再移动到 Permanent Generation 区域。 1Young Generation
由一个Eden区和两个Survivor区组成程序中生成的大部分新的对象都在Eden区中当Eden区满时还存活的对象将被复制到其中一个Survivor区当次Survivor区满时此区存活的对象又被复制到另一个Survivor区当这个Survivor区也满时会将其中存活的对象复制到年老代。
2Old Generation
一般情况下年老代中的对象生命周期都比较长。
3Permanent Generation
用于存放静态的类和方法持久代对垃圾回收没有显著影响。
总结内存对象的处理过程如下
1. 对象创建后在Eden区。 2. 执行GC后如果对象仍然存活则复制到S0区。 3. 当S0区满时该区域存活对象将复制到S1区然后S0清空接下来S0和S1角色互换。 4. 当第3步达到一定次数系统版本不同会有差异后存活对象将被复制到Old Generation。 5. 当这个对象在Young Generation区域停留的时间达到一定程度时它会被移动到Old Generation最后累积一定时间再移动到Permanent Generation区域。
2、Generation GC
系统在Young Generation、Old Generation上采用不同的回收机制。每一个Generation的内存区域都有固定的大小。随着新的对象陆续被分配到此区域当对象总的大小临近这一级别内存区域的阈值时会触发GC操作以便腾出空间来存放其他新的对象。
1执行GC占用的时间与Generation和Generation中的对象数量有关
1. Young Generation Old Generation Permanent Generation 2. Gener中的对象数量与执行时间成正比。
2Young Generation GC
由于其对象存活时间短因此基于Copying算法扫描出存活的对象并复制到一块新的完全未使用的控件中来回收。新生代采用空闲指针的方式来控制GC触发指针保持最后一个分配的对象在YoungGeneration区间的位置当有新的对象要分配内存时用于检查空间是否足够不够就触发GC。
3Old Generation GC
由于其对象存活时间较长比较稳定因此采用Mark标记算法扫描出存活的对象然后再回收未被标记的对象回收后对空出的空间要么合并要么标记出来便于下次分配以减少内存碎片带来的效率损耗来回收。
3、Java内存分配模型 4、可达性分析与GCRoots
通过一系列称为“GC Roots”的对象作为起始点从这些节点向下搜索搜索所有的引用链当一个对象到GC Roots没有任何引用链即GC Roots到对象不可达时则证明此对象是不可用的。 GC管理的主要区域是Java堆一般情况下只针对堆进行垃圾回收。方法区、栈和本地方法区不被GC所管理,因而选择这些区域内的对象作为GC roots,被GC roots引用的对象不被GC回收。
5、GC 回收算法
1标记清除算法
1 位置不连续产生碎片 2 效率略低 3 扫描两遍。 2复制算法
1 实现简单、运行高效 2 没有内存碎片 3 利用率只有一半 。 3标记整理算法
1 没有内存碎片 2 效率偏低 3 扫描两遍、指针需要调整 。 四、内存三大问题
1、内存抖动
通过Memory Profiler检测内存波动图形呈锯齿张频繁GC容易导致页面卡顿。常出现于循环里创建对象自定义onDraw创建对象等。
2、内存泄漏
在当前应用周期内不再使用的对象被GC Roots引用导致不能回收使实际可使用内存变小Android内存泄漏分析工具Memory Profiler和LeakCanary查看文章LeakCanary内存泄漏检测框架分析http://t.csdn.cn/SEpWC
Android内存泄漏常见场景以及解决方案
1. 资源性对象未关闭 对于资源性对象不再使用时应该立即调用它的close()函数将其关闭然后再置为null。例如文件、数据库和Bitmap等资源未关闭会造成内存泄漏此时我们应该在Activity销毁时及时关闭。
2. 注册对象未注销 例如BraodcastReceiver、EventBus未注销造成的内存泄漏我们应该在Activity销毁时及时注销。
3 .类的静态变量持有大数据对象 尽量避免使用静态变量存储数据特别是大数据对象建议使用数据库存储。
4 .单例造成的内存泄漏 优先使用Application的Context如需使用Activity的Context可以在传入Context时使用弱引用进行封装然后在使用到的地方从弱引用中获取Context如果获取不到则直接return即可。
5. 非静态内部类的静态实例 该实例的生命周期和应用一样长这就导致该静态实例一直持有该Activity的引用Activity的内存资源不能正常回收。此时我们可以将该内部类设为静态内部类或将该内部类抽取出来封装成一个单例如果需要使用Context尽量使用Application Context如果需要使用Activity Context就记得用完后置空让GC可以回收否则还是会内存泄漏。
6. Handler临时性内存泄漏 Message发出之后存储在MessageQueue中在Message中存在一个target它是Handler的一个引用Message在Queue中存在的时间过长就会导致Handler无法被回收。如果Handler是非静态的则会导致Activity或者Service不会被回收。并且消息队列是在一个Looper线程中不断地轮询处理消息当这个Activity退出时消息队列中还有未处理的消息或者正在处理的消息并且消息队列中的Message持有Handler实例的引用Handler又持有Activity的引用所以导致该Activity的内存资源无法及时回收引发内存泄漏。解决方案如下所示 1使用一个静态Handler内部类然后对Handler持有的对象一般是Activity使用弱引用这样在回收时也可以回收Handler持有的对象。 2在Activity的Destroy或者Stop时应该移除消息队列中的消息避免Looper线程的消息队列中有待处理的消息需要处理。需要注意的是AsyncTask内部也是Handler机制同样存在内存泄漏风险但其一般是临时性的。对于类似AsyncTask或是线程造成的内存泄漏我们也可以将AsyncTask和Runnable类独立出来或者使用静态内部类。
7、容器中的对象没清理造成的内存泄漏 在退出程序之前将集合里的东西clear然后置为null再退出程序。
8、WebView WebView都存在内存泄漏的问题在应用中只要使用一次WebView内存就不会被释放掉。我们可以为WebView开启一个独立的进程使用AIDL与应用的主进程进行通信WebView所在的进程可以根据业务的需要选择合适的时机进行销毁达到正常释放内存的目的。
9、使用ListView时造成的内存泄漏 在构造Adapter时使用缓存的convertView。
3、内存溢出
即OOMOOM时会导致程序异常。Android设备出厂以后java虚拟机对单个应用的最大内存分配就确定下来了超出这个值就会OOM。
1OOM原因分类 2OOM代码分析
Android 虚拟机最终抛出OutOfMemoryError的地方/art/runtime/thread.cc
void Thread::ThrowOutOfMemoryError(const char* msg) {LOG(WARNING) StringPrintf(Throwing OutOfMemoryError \%s\%s,msg, (tls32_.throwing_OutOfMemoryError ? (recursive case) : ));if (!tls32_.throwing_OutOfMemoryError) {tls32_.throwing_OutOfMemoryError true;ThrowNewException(Ljava/lang/OutOfMemoryError;, msg);tls32_.throwing_OutOfMemoryError false;} else {Dump(LOG_STREAM(WARNING)); // The pre-allocated OOME has no stack, sohelp out and log one.SetException(Runtime::Current()-GetPreAllocatedOutOfMemoryError());}
}
堆内存分配失败/art/runtime/gc/heap.cc
void Heap::ThrowOutOfMemoryError(Thread* self, size_t byte_count,
AllocatorType allocator_type) {// If were in a stack overflow, do not create a new exception. It wouldrequire running the// constructor, which will of course still be in a stack overflow.if (self-IsHandlingStackOverflow()) {self-SetException(Runtime::Current()-GetPreAllocatedOutOfMemoryErrorWhenHandlingStackOverflow());return;}std::ostringstream oss;size_t total_bytes_free GetFreeMemory();//为对象分配内存时达到进程的内存上限oss Failed to allocate a byte_count byte allocation with total_bytes_free free bytes and PrettySize(GetFreeMemoryUntilOOME()) until OOM, target footprint target_footprint_.load(std::memory_order_relaxed) , growth limit growth_limit_;//没有足够大小的连续地址空间// There is no fragmentation info to log for large-object space.if (allocator_type ! kAllocatorTypeLOS) {CHECK(space ! nullptr) allocator_type: allocator_type byte_count: byte_count total_bytes_free: total_bytes_free;space-LogFragmentationAllocFailure(oss, byte_count);}
}
创建线程失败/art/runtime/thread.cc
void Thread::CreateNativeThread(JNIEnv* env, jobject java_peer, size_t
stack_size, bool is_daemon) {CHECK(java_peer ! nullptr);Thread* self static_castJNIEnvExt*(env)-GetSelf();// TODO: remove from thread group?env-SetLongField(java_peer,WellKnownClasses::java_lang_Thread_nativePeer, 0);{std::string msg(child_jni_env_ext.get() nullptr ?StringPrintf(Could not allocate JNI Env: %s, error_msg.c_str()) :StringPrintf(pthread_create (%s stack) failed: %s,PrettySize(stack_size).c_str(),strerror(pthread_create_result)));ScopedObjectAccess soa(env);soa.Self()-ThrowOutOfMemoryError(msg.c_str());}
}
OOM问题比较常出现在Bitmap没有进行任何压缩处理直接加载原图到APP上面而导致OOM长时间的内存泄漏也是导致OOM问题的原因之一。
