Android内存泄漏终极解决篇_安卓开发_传送门
Android内存泄漏终极解决篇
来自：本文出自[HCY的微博]链接：http://blog.csdn.net/huang_cai_yuan/article/details/http://blog.csdn.net/huang_cai_yuan/article/details/上篇一、概述Android内存的文章详见：http://blog.csdn.net/linghu_java/article/details/ 在Android的开发中，经常听到“内存泄漏”这个词。“内存泄漏”就是一个对象已经不需要再使用了，但是因为其它的对象持有该对象的引用，导致它的内存不能被回收。“内存泄漏”的慢慢积累，最终会导致OOM的发生，千里之堤，毁于蚁穴。所以在写代码的过程中，应该要注意规避会导致“内存泄漏”的代码写法，提高软件的健壮性。本文将从发现问题、解决问题、总结问题的三个角度出发，循序渐进，彻底解决“内存泄漏”的问题。二、内存泄漏的检查工具Heap工欲善其事必先利其器，要检测“内存泄漏”的发生，需要借助DDMS中的Heap工具及MAT工具，Heap工具用于大致分析是否存在“内存泄漏”，而MAT工具则用于分析“内存泄漏”发生在哪里。Heap工具的使用介绍具体操作 1、在Devices设备列表中，找到你所在的设备，点击你想要监控的进程。 2、点击“Update Heap”按钮更新堆内存的情况。 3、点击“Heap”视图，查看内存的情况。 4、每次在Activity的退出和进入的时候点击“Cause GC”，手动调用GC释放应用的内存。 5、观察data oject那一行，每一次点击“Casue GC”的时候，观察Total Size的值，如果该值不断增加，则说明该应用程序存在“内存泄漏”。我们先模拟一下内存泄漏，然后通过Heap工具来判断一下是否存在内存泄漏。上一段存在内存泄漏的代码：public class LeakAty extends Activity {
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.aty_leak);
testLeak();
* 测试内存泄漏的代码
private void testLeak() {
new Thread(new Runnable() {
public void run() {
while (true) {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}).start();
}上述的代码存在内存泄漏，new Runnable(){}是一个非静态的匿名内部类，所以它会强引用创建它的外围对象LeakAty，我们来测试一下内存泄漏的过程，开启手机的方向旋转功能，不断地旋转手机，让LeakAty不断地创建新的实例。理论上如果不存在上述泄漏的代码，之前的Activity会在onDestory之后被回收内存。而一旦存在上述泄漏的代码，新创建的Ruannale实例会一直处于运行状态，它不会被回收，而它强引用的LeakAty当然也不会被回收，所以在屏幕不断旋转，之前创建的LeakAty就不会被释放，会导致旋转n次，内存中就存在n+1个的LeakAty实例。Heap工具第一次按下Cause GC按钮的截图:上图的data object的Total Size的大小为1.031M。经过多次的旋转屏幕之后，我们再看一下截图Total Size变成了2.059M，从1.031M到2.059M，每次调用GC的过程中data object的总大小没有回落，所以可以证实上面的代码确实是存在内存泄漏的问题，那么泄漏发生在哪里？答案可以通过MAT工具来分析得到。三、内存泄漏的分析工具MAT要通过MAT分析，需要提供一个.hprof文件。我们可以通过”Dump HPROF file”按钮转存当前的堆内存信息。我们将其保存为1.hprof。导出的1.hprof的格式需要通过..\sdk\tools\目录下的hprof-conv.exe工具进行转换才能被MAT成功导入，我们将其转换成out1.hprof将out1.hprof导入到MAT工具中,File->Open Heap Dump…点击左边的标签Overview,Actions->Histogram在Histogram界面中，因为我们想要知道Activity是否泄漏了，所以输入关键词Activity,然后按下回车键。之后便可以得到Activity的相关的搜索结果,下图的搜索结果中Activity的实例有7个。点击选中下图标红色框框的地方，右键->Merge Shortest Paths to GC Roots->exclude all phantom/weak/soft etc. references。排除虚引用、弱引用、软引用的实例，剩下的都是强引用实例。从过滤出来的强引用的列表中，我们可以看到这七个实例都是被Thread所引用了。所以证实上面的代码确实存在内存泄漏。四、本文总结内存泄漏检测可以使用Heap工具，内存分析可以使用MAT工具。本文的案例中提到了一种内存泄漏的情况，就是非静态内部类的对象会强引用其外围对象，一旦这个非静态内部类的实例没有释放，它的外围对象也不会释放，所以就会造成内存泄漏。继续阅读下篇将具体探讨一下，在Android的开发过程中，哪些写法容易造成内存泄漏，该如何解决？五、附件MAT工具下载见：http://download.csdn.net/detail/huang_cai_yuan/9377979下篇一、概述在 上篇中我们介绍了如何检查一个App是否存在内存泄漏的问题，本篇将总结典型的内存泄漏的代码，并给出对应的解决方案。内存泄漏的主要问题可以分为以下几种类型：1、静态变量引起的内存泄漏2、非静态内部类引起的内存泄漏3、资源未关闭引起的内存泄漏二、静态变量引起的内存泄漏在java中静态变量的生命周期是在类加载时开始，类卸载时结束。换句话说，在android中其生命周期是在进程启动时开始，进程死亡时结束。所以在程序的运行期间，如果进程没有被杀死，静态变量就会一直存在，不会被回收掉。如果静态变量强引用了某个Activity中变量，那么这个Activity就同样也不会被释放,即便是该Activity执行了onDestroy(不要将执行onDestroy和被回收划等号)。这类问题的解决方案为：1.寻找与该静态变量生命周期差不多的替代对象。2.若找不到，将强引用方式改成弱引用。比较典型的例子如下:单例引起的Context内存泄漏public class IMManager {
private static IMManager mI
public static IMManager getInstance(Context context) {
if (mInstance == null) {
synchronized (IMManager.class) {
if (mInstance == null)
mInstance = new IMManager(context);
private IMManager(Context context) {
this.context =
}当调用getInstance时，如果传入的context是Activity的context。只要这个单例没有被释放，这个Activity也不会被释放。解决方案 传入Application的context,因为Application的context的生命周期比Activity长，可以理解为Application的context与单例的生命周期一样长，传入它是最合适的。public class IMManager {
private static IMManager mI
public static IMManager getInstance(Context context) {
if (mInstance == null) {
synchronized (IMManager.class) {
if (mInstance == null)
mInstance = new IMManager(context.getApplicationContext());
private IMManager(Context context) {
this.context =
}三、非静态内部类引起的内存泄漏在java中，创建一个非静态的内部类实例，就会引用它的外围实例。如果这个非静态内部类实例做了一些耗时的操作，就会造成外围对象不会被回收，从而导致内存泄漏。这类问题的解决方案为：1.将内部类变成静态内部类 2.如果有强引用Activity中的属性，则将该属性的引用方式改为弱引用。3.在业务允许的情况下，当Activity执行onDestory时，结束这些耗时任务。内部线程造成的内存泄漏public class LeakAty extends Activity {
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.aty_leak);
public void test() {
new Thread(new Runnable() {
public void run() {
while (true) {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}).start();
}解决方案 将非静态匿名内部类修改为静态匿名内部类public class LeakAty extends Activity {
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.aty_leak);
public static void test() {
new Thread(new Runnable() {
public void run() {
while (true) {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}).start();
}Handler引起的内存泄漏public class LeakAty extends Activity {
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.aty_leak);
fetchData();
private Handler mHandler = new Handler() {
public void handleMessage(android.os.Message msg) {
switch (msg.what) {
private void fetchData() {
mHandler.sendEmptyMessage(0);
}mHandler 为匿名内部类实例，会引用外围对象LeakAty.this,如果该Handler在Activity退出时依然还有消息需要处理，那么这个Activity就不会被回收。解决方案public class LeakAty extends Activity {
private TextView tvR
private MyH
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.aty_leak);
tvResult = (TextView) findViewById(R.id.tvResult);
handler = new MyHandler(this);
fetchData();
private static class MyHandler extends Handler {
private WeakReference atyI
public MyHandler(LeakAty aty) {
this.atyInstance = new WeakReference(aty);
public void handleMessage(Message msg) {
super.handleMessage(msg);
LeakAty aty = atyInstance == null ? null : atyInstance.get();
if (aty == null||aty.isFinishing()) {
aty.tvResult.setText("fetch data success");
private void fetchData() {
handler.sendEmptyMessage(0);
protected void onDestroy() {
super.onDestroy();
handler.removeCallbacksAndMessages(null);
}四、资源未关闭引起的内存泄漏当使用了BraodcastReceiver、Cursor、Bitmap等资源时，当不需要使用时，需要及时释放掉，若没有释放，则会引起内存泄漏。五、总结综上所述，内存泄漏的主要情况为上面的三大类型，最终归结为一点，就是资源在不需要的时候没有被释放掉。所以在编码的过程中要注意这些细节，提高程序的性能。●本文编号40，以后想阅读这篇文章直接输入40即可。●输入m可以获取到全部文章目录
觉得不错，分享给更多人看到
安卓开发 微信二维码
分享这篇文章
安卓开发 最新文章Android常见的内存泄漏 - 简书
Android常见的内存泄漏
1. Bitmap使用完忘记回收
因为bitmap实现部分是通过JNI调用了Native方法，GC机制无法正常回收 Bitmap申请的这部分内存空间（API10之前是这样的，之后分配在Heap中，不过为了兼容老版本...显示的调用一下recycled，让对象变为虚引用,也能让GC到来的几率更高）；
那Bitmap应该怎样回收呢？
if(bitmap!=null&&!bitmap.isRecycled){
bitmap.recycled(); //回收bitmap
//使bitmap对象变为虚引用的状态，让GC更快的回收
2.万恶的static
被static修饰的变量，生命周期与整个App的生命周期相同，需要谨慎使用它来修饰一些耗费资源过多的实例
private static Drawable sB
protected void onCreate(Bundlestate){
super.onCreate(state);
label.setText("Leaksarebad");
if(sBackground==null){
sBackground=getDrawable(R.drawable.large_bitmap);
label.setBackgroundDrawable(sBackground);
setContentView(label);
这里的sBackground是个静态变量，也就是说就算Activity销毁掉了，他也无法被释放，就导致了内存浪费，当然这还没完... 当Drawable与View绑定之后，Drawable就将View设置为一个回调，由于View中是包含了Context引用的,最终就是 Context发生内存泄露；
注意：Drawable就将View设置为一个回调，是将View引用为一个WeakReference，这边是否真正引起内存泄漏，还需要测试(API23)。
3.Context的引用问题
当然2中也提到了一部分，咱们再看看这里的
btn_hint.setOnClickListener(new View.OnClickListener() {
public void onClick(View v) {
Toast.makeText(MainActivity.this, "Hello", Toast.LENGTH_SHORT).show();
是不是很常见，平时可能也是这样写的（将其封装意义一样，只要引用了当前activity）,你可能想问，这里有什么问题吗？
问题在于如果用户在Toast消失之前，用户按了返回键，这个Activity就引起了内存泄露，
原因？ Toast持有了当前Activity，导致Activity无法被GC销毁
解决方法：让Toast持有ApplicationC其实只要不是Layout，Context都可以使用ApplicationC
关于Context的tips
在单列模式中，如果用到的Context,应该使用与App的生命周期相同的ApplicationContext.
在非Activity中，正常是不能直接getContext来拿到Context的，获取资源有需要靠Context，这时可以考虑在自己的Application中维护一个全局的Context，供无法直接拿到Context的类使用，省的参数传来传去（视图相关的不建议使用ApplicationContext）
在Application中
private static Context mC
public static MyApplication getInstance() { //供外界调用...
public void onCreate() {
super.onCreate();
mContext = getApplicationContext();
4.线程引发的内存泄露
new Thread() {
public void run() {
//网络请求
}.start();
在Activity中 新建一个线程，进行网络请求，如果线程未结束，用户按了返回键，同样内存泄露
原因：该Thread是匿名内部类，所以会隐式的持有外部类（这里也就是Activity），Handler内存泄漏也是这个原因，详细可以阅读我的博客：
解决方式：多种多样; 不使用匿名内部类，或者整个应用维护一个线程池，或者维护一个线程+消息队列+WeakReference，后两种都是让线程不依赖于Activity从而达到避免内存泄露的目的；
5.资源未关闭造成的内存泄漏
对于使用了BroadcastReceiver，ContentObserver，File，Cursor，Stream，Bitmap等资源的使用，应该在Activity销毁时及时关闭或者注销，否则这些资源将不会被回收，造成内存泄漏。
爱生活，爱分享!
用两张图告诉你，为什么你的 App 会卡顿? - Android - 掘金 Cover 有什么料？ 从这篇文章中你能获得这些料： 知道setContentView()之后发生了什么？ ... Android 获取 View 宽高的常用正确方式，避免为零 - 掘金 相信有很多...
用两张图告诉你，为什么你的 App 会卡顿? - Android - 掘金Cover 有什么料？ 从这篇文章中你能获得这些料： 知道setContentView()之后发生了什么？ ... Android 获取 View 宽高的常用正确方式，避免为零 - 掘金相信有很多朋友...
内存管理的目的就是让我们在开发中怎么有效的避免我们的应用出现内存泄漏的问题。内存泄漏大家都不陌生了，简单粗俗的讲，就是该被释放的对象没有释放，一直被某个或某些实例所持有却不再被使用导致 GC 不能回收。最近自己阅读了大量相关的文档资料，打算做个总结沉淀下来跟大家一起分享和学...
Android 内存泄漏总结 内存管理的目的就是让我们在开发中怎么有效的避免我们的应用出现内存泄漏的问题。内存泄漏大家都不陌生了，简单粗俗的讲，就是该被释放的对象没有释放，一直被某个或某些实例所持有却不再被使用导致 GC 不能回收。最近自己阅读了大量相关的文档资料，打算做个...
###集合类泄漏 集合类如果仅仅有添加元素的方法，而没有相应的删除机制，导致内存被占用。如果这个集合类是全局性的变量 (比如类中的静态属性，全局性的 map 等即有静态引用或 final 一直指向它)，那么没有相应的删除机制，很可能导致集合所占用的内存只增不减。比如上面的典...
iOS10中UICollectionView和UITableView的变化 在iOS 10中，UIKit的两个容器控件得到新的特性，apple在会上强调了这些新特性所带来的性能提升，现总结如下： 1.cell生命周期的变化 只有UICollectionView支持这项更新，...
再一次坐上长途火车，漫长的夜让人焦虑又恐惧，缓缓驶向凶险的未来。
早在前几日，家里就弥漫了浓浓的分别气息，一个月神秘的遮掩，婆婆仿佛也嗅到了异常，哥哥角色全程难看，几乎不跟我说话，没有一丝往时我们归来的喜庆，我焦虑的表情，落寞的神色，窘迫的口袋，控制不住的情绪，都指...
我真的是财商开发得挺早的。 小学一二年级的时候，我就开始想倒腾做生意卖同学东西。后来因为怕影响同学关系就没做成，但商业思维已经在我头脑里形成了。 长大后，我经常寻找家或学校附近的资源，想搞搞0库存创业神马的。但因为没啥市场也就算了。 大学的时候，开始为别人卖命。打过无数的工...
2011年的时候，国内兴起一阵轻博客的热风，国外的Tumblr更是发展迅猛，大我一届的师兄毕业后也到盛大「推他」做了一阵。推他，新浪轻博客，许朝军的点点网都在媒体的肆意报道下夺得各种眼球。 回到2015年，目前国内轻博客市场仅剩LOFTER一枝独秀。LOFTER以摄影社区为...常见的内存泄露有哪些 android_百度知道
常见的内存泄露有哪些 android
答题抽奖
首次认真答题后
即可获得3次抽奖机会，100%中奖。
1. 查询数据库而没有关闭Cursor在Android中，Cursor是很常用的一个对象，但在写代码是，经常会有人忘记调用close, 或者因为代码逻辑问题状况导致close未被调用。通常，在Activity中，我们可以调用startManagingCursor或直接使用managedQuery让Activity自动管理Cursor对象。但需要注意的是，当Activity介绍后，Cursor将不再可用！若操作Cursor的代码和UI不同步（如后台线程），那没需要先判断Activity是否已经结束，或者在调用OnDestroy前，先等待后台线程结束。除此之外，以下也是比较常见的Cursor不会被关闭的情况：虽然表面看起来，Cursor.close()已经被调用，但若出现异常，将会跳过close()，从而导致内存泄露。所以，我们的代码应该以如下的方式编写：Cursor c = queryCursor();
int a = c.getInt(1);
} catch (Exception e) {
} finally {
c.close(); //在finally中调用close(), 保证其一定会被调用
Cursor c = queryCursor();
int a = c.getInt(1);
c.close();
} catch (Exception e) {
2. 调用registerReceiver后未调用unregisterReceiver().在调用registerReceiver后，若未调用unregisterReceiver，其所占的内存是相当大的。而我们经常可以看到类似于如下的代码：这是个很严重的错误，因为它会导致BroadcastReceiver不会被unregister而导致内存泄露。registerReceiver(new BroadcastReceiver() {
}, filter); ...
3. 未关闭InputStream/OutputStream在使用文件或者访问网络资源时，使用了InputStream/OutputStream也会导致内存泄露4. Bitmap使用后未调用recycle()根据SDK的描述，调用recycle并不是必须的。但在实际使用时，Bitmap占用的内存是很大的，所以当我们不再使用时，尽量调用recycle()以释放资源。5. Context泄露这是一个很隐晦的内存泄露的情况。先让我们看一下以下代码：在这段代码中，我们使用了一个static的Drawable对象。这通常发生在我们需要经常调用一个Drawable，而其加载又比较耗时，不希望每次加载Activity都去创建这个Drawable的情况。此时，使用static无疑是最快的代码编写方式，但是其也非常的糟糕。当一个Drawable被附加到View时，这个View会被设置为这个Drawable的callback (通过调用Drawable.setCallback()实现)。这就意味着，这个Drawable拥有一个TextView的引用，而TextView又拥有一个Activity的引用。这就会导致Activity在销毁后，内存不会被释放。private static Drawable sB
protected void onCreate(Bundle state) {
super.onCreate(state);
TextView label = new TextView(this);
label.setText(&Leaks are bad&);
if (sBackground == null) {
sBackground = getDrawable(R.drawable.large_bitmap);
label.setBackgroundDrawable(sBackground);
setContentView(label);
采纳率：74%
1.查询数据库而没有关闭Cursor在Android中，Cursor是很常用的一个对象，但在写代码是，经常会有人忘记调用close, 或者因为代码逻辑问题状况导致close未被调用。通常，在Activity中，我们可以调用startManagingCursor或直接使用managedQuery让Activity自动管理Cursor对象。但需要注意的是，当Activity介绍后，Cursor将不再可用！若操作Cursor的代码和UI不同步（如后台线程），那没需要先判断Activity是否已经结束，或者在调用OnDestroy前，先等待后台线程结束。除此之外，以下也是比较常见的Cursor不会被关闭的情况： 1.try {
Cursor c = queryCursor();
int a = c.getInt(1);
c.close();
6.} catch (Exception e) {
虽然表面看起来，Cursor.close()已经被调用，但若出现异常，将会跳过close()，从而导致内存泄露。 所以，我们的代码应该以如下的方式编写：01.Cursor c = queryCursor();
int a = c.getInt(1);
05.} catch (Exception e) {
06.} finally {
c.close(); //在finally中调用close(), 保证其一定会被调用
2.调用registerReceiver后未调用unregisterReceiver().在调用registerReceiver后，若未调用unregisterReceiver，其所占的内存是相当大的。而我们经常可以看到类似于如下的代码：01.registerReceiver(new BroadcastReceiver() {
03.}, filter); ...
这是个很严重的错误，因为它会导致BroadcastReceiver不会被unregister而导致内存泄露。3.未关闭InputStream/OutputStream在使用文件或者访问网络资源时，使用了InputStream/OutputStream也会导致内存泄露4.Bitmap使用后未调用recycle()根据SDK的描述，调用recycle并不是必须的。但在实际使用时，Bitmap占用的内存是很大的，所以当我们不再使用时，尽量调用recycle()以释放资源。5.Context泄露这是一个很隐晦的内存泄露的情况。先让我们看一下以下代码： 01.private static Drawable sB
03.@Override
04.protected void onCreate(Bundle state) {
super.onCreate(state);
TextView label = new TextView(this);
label.setText(&Leaks are bad&);
if (sBackground == null) {
sBackground = getDrawable(R.drawable.large_bitmap);
label.setBackgroundDrawable(sBackground);
setContentView(label);
在这段代码中，我们使用了一个static的Drawable对象。这通常发生在我们需要经常调用一个Drawable，而其加载又比较耗时，不希望每次加载Activity都去创建这个Drawable的情况。此时，使用static无疑是最快的代码编写方式，但是其也非常的糟糕。当一个Drawable被附加到View时，这个View会被设置为这个Drawable的callback (通过调用Drawable.setCallback()实现)。这就意味着，这个Drawable拥有一个TextView的引用，而TextView又拥有一个Activity的引用。这就会导致Activity在销毁后，内存不会被释放。
本回答被提问者和网友采纳
存在内存泄露问题的Android的版本为5.0.2以及之前的所有安卓版本（包括4.4.4，4.3，2.3等），直到5.1.1版本的推出才修复了该漏洞。
为您推荐：
内存泄露的相关知识
换一换
回答问题，赢新手礼包
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。&>&Android处理内存泄漏的代码例子
Android处理内存泄漏的代码例子
上传大小：2.09MB
Android处理内存泄漏的代码例子。用于演示避免内存泄漏的几种方法，包括：关闭游标、重用适配、回收图像、注销监听、释放引用。
综合评分：0
{%username%}回复{%com_username%}{%time%}\
/*点击出现回复框*/
$(".respond_btn").on("click", function (e) {
$(this).parents(".rightLi").children(".respond_box").show();
e.stopPropagation();
$(".cancel_res").on("click", function (e) {
$(this).parents(".res_b").siblings(".res_area").val("");
$(this).parents(".respond_box").hide();
e.stopPropagation();
/*删除评论*/
$(".del_comment_c").on("click", function (e) {
var id = $(e.target).attr("id");
$.getJSON('/index.php/comment/do_invalid/' + id,
function (data) {
if (data.succ == 1) {
$(e.target).parents(".conLi").remove();
alert(data.msg);
$(".res_btn").click(function (e) {
var parentWrap = $(this).parents(".respond_box"),
q = parentWrap.find(".form1").serializeArray(),
resStr = $.trim(parentWrap.find(".res_area_r").val());
console.log(q);
//var res_area_r = $.trim($(".res_area_r").val());
if (resStr == '') {
$(".res_text").css({color: "red"});
$.post("/index.php/comment/do_comment_reply/", q,
function (data) {
if (data.succ == 1) {
var $target,
evt = e || window.
$target = $(evt.target || evt.srcElement);
var $dd = $target.parents('dd');
var $wrapReply = $dd.find('.respond_box');
console.log($wrapReply);
//var mess = $(".res_area_r").val();
var mess = resS
var str = str.replace(/{%header%}/g, data.header)
.replace(/{%href%}/g, 'http://' + window.location.host + '/user/' + data.username)
.replace(/{%username%}/g, data.username)
.replace(/{%com_username%}/g, data.com_username)
.replace(/{%time%}/g, data.time)
.replace(/{%id%}/g, data.id)
.replace(/{%mess%}/g, mess);
$dd.after(str);
$(".respond_box").hide();
$(".res_area_r").val("");
$(".res_area").val("");
$wrapReply.hide();
alert(data.msg);
}, "json");
/*删除回复*/
$(".rightLi").on("click", '.del_comment_r', function (e) {
var id = $(e.target).attr("id");
$.getJSON('/index.php/comment/do_comment_del/' + id,
function (data) {
if (data.succ == 1) {
$(e.target).parent().parent().parent().parent().parent().remove();
$(e.target).parents('.res_list').remove()
alert(data.msg);
//填充回复
function KeyP(v) {
var parentWrap = $(v).parents(".respond_box");
parentWrap.find(".res_area_r").val($.trim(parentWrap.find(".res_area").val()));
评论共有0条
VIP会员动态
热门资源标签
CSDN下载频道资源及相关规则调整公告V11.10
下载频道用户反馈专区
下载频道积分规则调整V1710.18
spring mvc+mybatis+mysql+maven+bootstrap 整合实现增删查改简单实例.zip
资源所需积分/C币
当前拥有积分
当前拥有C币
输入下载码
为了良好体验，不建议使用迅雷下载
Android处理内存泄漏的代码例子
会员到期时间：
剩余下载个数：
剩余积分：0
为了良好体验，不建议使用迅雷下载
积分不足！
资源所需积分/C币
当前拥有积分
您可以选择
程序员的必选
绿色安全资源
资源所需积分/C币
当前拥有积分
当前拥有C币
为了良好体验，不建议使用迅雷下载
资源所需积分/C币
当前拥有积分
当前拥有C币
为了良好体验，不建议使用迅雷下载
资源所需积分/C币
当前拥有积分
当前拥有C币
您的积分不足，将扣除 10 C币
为了良好体验，不建议使用迅雷下载
无法举报自己的资源
你当前的下载分为234。
你还不是VIP会员
开通VIP会员权限，免积分下载
你下载资源过于频繁，请输入验证码
您因违反CSDN下载频道规则而被锁定帐户，如有疑问，请联络:!
若举报审核通过，可返还被扣除的积分
被举报人：
请选择类型
资源无法下载 （ 404页面、下载失败、资源本身问题）
资源无法使用 （文件损坏、内容缺失、题文不符）
侵犯版权资源 （侵犯公司或个人版权）
虚假资源 （恶意欺诈、刷分资源）
含色情、危害国家安全内容
含广告、木马病毒资源
*投诉人姓名：
*投诉人联系方式：
*版权证明：
*详细原因：
Android处理内存泄漏的代码例子}