1-byte array(byte[], boolean[])图片导致的内存过大_boolean[]占用很大-程序员宅基地

技术标签: android  内存  

Android-视图显示大量图片时的内存问题

 昨天优化一个项目(基本上每个ACTIVITY都会有大量图片),查了很多资料,借鉴了一些做法,网上的说法有对有错,这里总结一下。 

android3.0默认heap size为48m,进入ddms,在ddms中“update heap”-“cause gc”,查看应用的内存使用情况,发现每进入一个activity,

1-byte array(byte[], boolean[])的值总是会相应的增加,到最后一个activity的时候啥都不干,heap size已经快30m了。

通过分析,1-byte array就是bitmap的占用空间,这就说明不断有新的bitmap在内存中。由于ui使用了很多图片,比如大背景图,

按钮图片等等,看来是这些图片 都会存在内存中,即使当前activity已经销毁进入下一个activity,前一个activity的图片资源也没有销毁。 

其中一个做法是: 用Bitmap bm = BitmapFactory.decodeResource(this.getResources(), R.drawable.splash); BitmapDrawable bd = new BitmapDrawable(this.getResources(), bm); mBtn.setBackgroundDrawable(bd); 来代替mBtn.setBackgroundResource(R.drawable.splash)。 


销毁的时候使用: BitmapDrawable bd = (BitmapDrawable)mBtn.getBackground(); mBtn.setBackgroundResource(0);

//别忘了把背景设为null,避免onDraw刷新背景时候出现used a recycled bitmap错误 bd.setCallback(null); bd.getBitmap().recycle(); 

因为setBackgroundResource时,会缓存图片的CHCHE,以便重绘时加快速度。如果说,每次都使用recycle的话,就达不到这个目的了。

而且根据以往的经验,对于一般应用,根本就没有这个必要,内存过大,势必还有原因造成。 在“update heap”-“cause gc”,

点击1-byte array(byte[], boolean[])行后,在Heap表里,查看图片内存的占用比例直方图,发现一些图片的占用内存居然高达10M(特别是在三星galaxy note运行时),

但项目里最大的原始图片也才1M多,很明显程序的写法有问题。最后,发现,在资源文件里,设置android:background为某些图片时,导致内存大增。

但如果把设置背景的步骤写在JAVA代码里,问题便解决了。 JAVA代码: testview.setBackgroundResource(R.drawable.testview_bg);

//内存还是会增大两三倍 结合上面的另一种作法,改用setBackgroundDrawable,

如: Bitmap bitmap = null; 

try { bitmap = BitmapFactory.decodeResource(context.getResources(), res, bfOptions); 

} catch (OutOfMemoryError oom) { 

android.util.Log.e("getSDCardImageBitmapByUrl", "OutOfMemoryError"); 

System.gc(); System.runFinalization(); } 

finally { } 

if (bitmap != null && !bitmap.isRecycled()) { 

BitmapDrawable bd = new BitmapDrawable(context.getResources(), bitmap); 

v.setBackgroundDrawable(bd); // bitmapCache.put(key, new WeakReference<Bitmap>(bitmap)); 

drawableCache.put(key, new WeakReference<Drawable>(bd));

 } 内存问题解决。

 但是,setBackgroundResource和setBackgroundDrawable的差别为什么这么大,待研究。。。


==================================另一篇文章===================================

 关于android中使用很多大图片的一些做法

最近在xoom上开发应用,碰到ui设计都是使用图片,而且是多个activity。开始没觉得怎么样,就开始做呗。等做完了,开始在前三个activity运行没问题,一切ok。但在最后一个activity里,会经常出现oom(out of memory),由于在最后一个activity,需要打开一个pdf,然后render,随着multi-touch,reander的pdf页缩放,由于reander的图片本身就比较大(比如,如果pdf放大到当前屏幕的两倍,pdf图片占用的内存为1280*800*4*2/(1024*1024),约等于8m),而且由于为了视觉上感受好,会在其中缓存图片(为了不让用户在使用过程中感受操作有停滞感),所以总是导致oom异常。

oh,my god!最怕碰到这种情况,android对于内存heap size限制让人比较崩溃,ios虽然也号称一个应用有内存限制,但是在实际使用中一个应用使用的内存往往可以超过100m,所以还是挺容易做一个性能满意的应用程序。

我的应用到底哪些地方使用了这么多内存,因为android3.0默认heap size为48m,按道理来说还是可以接受的,怎么应用没跑几下就oom呢?没办法,只能通过ddms来分析,在ddms中“update heap”-》“cause gc”,来查看应用的内存使用情况,发现每进入一个activity,1-byte array(byte[], boolean[])的值总是会相应的增加,到最后一个activity的时候啥都不干,heap size已经快30m了,oh。。。怎么会这样。。。冷静冷静。。。通过分析,1-byte array就是bitmap的占用空间,这就说明不断有新的bitmap在内存中。由于ui使用了很多图片,比如大背景图,按钮图片等等,看来是这些图片都会存在内存中,即使当前activity已经销毁进入下一个activity,前一个activity的图片资源也没有销毁。

原因找到了,但不是太想得通。因为在onCreate中我用mBtn.setBackgroundResource(R.drawable.splash)为控件设置背景图,然后在onDestroy中会用((BitmapDrawable)mBtn.getBackground()).setCallback(null)清理背景图。按道理来说图片资源应该已经清理掉了的。百思不得其解,仔细看Bitmap的源代码,它其实起的作用是销毁java对象BitmapDrawable,而android为了提高效率,Bitmap真正的位图数据是在ndk中用c写的,所以用setCallback是不能销毁位图数据的,应该调用Bitmap的recycle()来清理内存。

所以想当然的在onDestroy加上((BitmapDrawable)mBtn.getBackground()).getBitmap().recycle(),这样跑下来,内存情况很理想,不管在哪个activity中,使用的资源仅仅是当前activity用到的,就不会象之前到最后一个activity的时候,所有之前使用的资源都累积在内存中。在每个activity资源和class等使用的内存都在10m左右,已经很理想了(当然如果是在android低版本比如1.5,16时还是不行的,这得重新构架应用),可以为显示pdf预留了比较多内存了。

但新的问题又出现了,当返回之前的activity时,会出现“try to use a recycled bitmap"的异常。这真是按了葫芦起了瓢啊,内心那个沮丧。。。没办法,继续分析。看来是后加上recycle引起的, 位图肯定在内存中有引用,在返回之前的activity时,因为位图数据其实已经被销毁了,所以才造成目前的情况。在看了setBackgroundResource的源码以后,恍然大悟,android对于直接通过资源id载入的资源其实是做了cache的了,这样下次再需要此资源的时候直接从cache中得到,这也是为效率考虑。但这样做也造成了用过的资源都会在内存中,这样的设计不是很适合使用了很多大图片资源的应用,这样累积下来应用的内存峰值是很高的。看了sdk后,我用:

Bitmap bm = BitmapFactory.decodeResource(this.getResources(), R.drawable.splash);
BitmapDrawable bd = new BitmapDrawable(this.getResources(), bm);

mBtn.setBackgroundDrawable(bd);

来代替mBtn.setBackgroundResource(R.drawable.splash)。

销毁的时候使用:

BitmapDrawable bd = (BitmapDrawable)mBtn.getBackground();

mBtn.setBackgroundResource(0);//别忘了把背景设为null,避免onDraw刷新背景时候出现used a recycled bitmap错误

bd.setCallback(null);
bd.getBitmap().recycle();

这样调整后,避免了在应用里缓存所有的资源,节省了宝贵的内存,而其实这样也不会造成太大效率问题,毕竟重新载入资源是非常快速,不会对性能造成很严重的影响,在xoom里我没有感受到和之前有什么区别。

总之,在android上使用大量位图是个比较痛苦的事,内存限制的存在对应用是个很大的瓶颈。但不用因噎费食,其实弄明白了它里面的机制,应用可以突破这些限制的。这只是其中的一种处理方法,还可以考虑BitmapFactory.Options的inSampleSize来减少内存占用。


==================================另一篇文章===================================

今天做了个内存优化的小测试,包括两点

 

1,  比较DrawableBitmap占用内存大小

2,  比较BitmapFactory类的decodeResource方法与decodeStream方法的效率

 

 

 

 

好吧,先来看第1个测试!

以下这个是测试加载1000Drawable对象的代码,很简单的,我就不解释了!

 

public class Main extends Activity

{

    int number = 1000;

    Drawable[] array;

 

    @Override

    public void onCreate(Bundle savedInstanceState)

    {

       super.onCreate(savedInstanceState);

       setContentView(R.layout.main);

 

        array = new BitmapDrawable[number];

                     

        for(int i = 0; i < number; i++)

        {

            Log.e("", "测试第" + (i+1) + "张图片");

            array[i] = getResources().getDrawable(R.drawable.img);

        }

    }

}

 

 

输出结果:

04-07 21:49:25.248: D/szipinf(7828): Initializing inflate state

04-07 21:49:25.398: E/(7828): 测试第1张图片

04-07 21:49:25.658: D/dalvikvm(7828): GC_EXTERNAL_ALLOC freed 48K, 50% free 2692K/5379K, external 0K/0K, paused 24ms

04-07 21:49:25.748: E/(7828): 测试第2张图片

04-07 21:49:25.748: E/(7828): 测试第3张图片

………………

………………

04-07 21:49:26.089: E/(7828): 测试第998张图片

04-07 21:49:26.089: E/(7828): 测试第999张图片

04-07 21:49:26.089: E/(7828): 测试第1000张图片

 

程序没有报错,正常运行,加载1000Drawable对象没问题。

 

下面再来看一下加载1000Bitmap对象的代码,同样的,代码很简单的,我就不解释了!

public class Main extends Activity

{

    int number = 1000;

    Bitmap bitmap[];

 

    @Override

    public void onCreate(Bundle savedInstanceState)

    {

       super.onCreate(savedInstanceState);

       setContentView(R.layout.main);

 

       bitmap = new Bitmap[number];

 

       for (int i = 0; i < number; i++)

       {

           Log.e("", "测试第" + (i+1) + "张图片");

           bitmap[i] = BitmapFactory.decodeResource(getResources(), R.drawable.img);

       }

    }

}

 

输出结果:

04-07 22:06:05.344: D/szipinf(7937): Initializing inflate state

04-07 22:06:05.374: E/(7937): 测试第1张图片

04-07 22:06:05.544: D/dalvikvm(7937): GC_EXTERNAL_ALLOC freed 51K, 50% free 2692K/5379K, external 0K/0K, paused 40ms

04-07 22:06:05.664: E/(7937): 测试第2张图片

04-07 22:06:05.774: D/dalvikvm(7937): GC_EXTERNAL_ALLOC freed 1K, 50% free 2691K/5379K, external 6026K/7525K, paused 31ms

04-07 22:06:05.834: E/(7937): 测试第3张图片

04-07 22:06:05.934: D/dalvikvm(7937): GC_EXTERNAL_ALLOC freed <1K, 50% free 2691K/5379K, external 12052K/14100K, paused 24ms

04-07 22:06:06.004: E/(7937): 测试第4张图片

04-07 22:06:06.124: D/dalvikvm(7937): GC_EXTERNAL_ALLOC freed <1K, 50% free 2691K/5379K, external 18078K/20126K, paused 27ms

04-07 22:06:06.204: E/(7937): 测试第5张图片

04-07 22:06:06.315: D/dalvikvm(7937): GC_EXTERNAL_ALLOC freed <1K, 50% free 2691K/5379K, external 24104K/26152K, paused 26ms

04-07 22:06:06.395: E/(7937): 测试第6张图片

04-07 22:06:06.495: D/dalvikvm(7937): GC_EXTERNAL_ALLOC freed <1K, 50% free 2691K/5379K, external 30130K/32178K, paused 22ms

04-07 22:06:06.565: E/(7937): 测试第7张图片

04-07 22:06:06.665: D/dalvikvm(7937): GC_EXTERNAL_ALLOC freed <1K, 50% free 2691K/5379K, external 36156K/38204K, paused 22ms

04-07 22:06:06.745: E/(7937): 测试第8张图片

04-07 22:06:06.845: D/dalvikvm(7937): GC_EXTERNAL_ALLOC freed 2K, 51% free 2689K/5379K, external 42182K/44230K, paused 23ms

04-07 22:06:06.845: E/dalvikvm-heap(7937): 6170724-byte external allocation too large for this process.

04-07 22:06:06.885: I/dalvikvm-heap(7937): Clamp target GC heap from 48.239MB to 48.000MB

04-07 22:06:06.885: E/GraphicsJNI(7937): VM won't let us allocate 6170724 bytes

04-07 22:06:06.885: D/dalvikvm(7937): GC_FOR_MALLOC freed <1K, 51% free 2689K/5379K, external 42182K/44230K, paused 25ms

04-07 22:06:06.885: D/AndroidRuntime(7937): Shutting down VM

04-07 22:06:06.885: W/dalvikvm(7937): threadid=1: thread exiting with uncaught exception (group=0x40015560)

04-07 22:06:06.885: E/AndroidRuntime(7937): FATAL EXCEPTION: main

04-07 22:06:06.885: E/AndroidRuntime(7937): java.lang.OutOfMemoryError: bitmap size exceeds VM budget

04-07 22:06:06.885: E/AndroidRuntime(7937):   at android.graphics.Bitmap.nativeCreate(Native Method)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at android.graphics.Bitmap.createBitmap(Bitmap.java:477)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at android.graphics.Bitmap.createBitmap(Bitmap.java:444)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at android.graphics.Bitmap.createScaledBitmap(Bitmap.java:349)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at android.graphics.BitmapFactory.finishDecode(BitmapFactory.java:498)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:473)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at android.graphics.BitmapFactory.decodeResourceStream(BitmapFactory.java:336)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at android.graphics.BitmapFactory.decodeResource(BitmapFactory.java:359)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at android.graphics.BitmapFactory.decodeResource(BitmapFactory.java:385)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at bassy.test.drawable.Main.onCreate(Main.java:37)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1047)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1722)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1784)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at android.app.ActivityThread.access$1500(ActivityThread.java:123)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at android.app.ActivityThread$H.handleMessage(ActivityThread.java:939)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at android.os.Handler.dispatchMessage(Handler.java:99)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at android.os.Looper.loop(Looper.java:130)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at android.app.ActivityThread.main(ActivityThread.java:3835)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at java.lang.reflect.Method.invokeNative(Native Method)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at java.lang.reflect.Method.invoke(Method.java:507)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:847)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:605)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at dalvik.system.NativeStart.main(Native Method)

 

 

看看上面的输出,才加载到第8张图片,程序就报错了“java.lang.OutOfMemoryError: bitmap size exceeds VM budget”。

 

通过上面的例子,可以看清楚地看出来,使用Drawable保存图片对象,占用更小的内存空间。

而使用Biamtp对象,则会占用很大内存空间,很容易就出现OOM了!

 

下面我们再来看一个例子,这个也是加载Bitmap对象。

只不过,之次不是使用BitmapFactorydecodeResource方法,

而是使用decodeStream方法,看代码。

public class Main extends Activity

{

    int number = 1000;

    Bitmap bitmap[];

 

    @Override

    public void onCreate(Bundle savedInstanceState)

    {

       super.onCreate(savedInstanceState);

       setContentView(R.layout.main);

 

       bitmap = new Bitmap[number];

 

       for (int i = 0; i < number; i++)

       {

           Log.e("", "测试第" + (i+1) + "张图片");

           bitmap[i] =BitmapFactory.decodeStream(getResources().openRawResource(R.drawable.img));//这里换了方法

       }

    }

}

 

 

输出结果:

04-07 22:16:12.676: E/(8091): 测试第561张图片

04-07 22:16:12.756: E/(8091): 测试第562张图片

04-07 22:16:12.826: E/(8091): 测试第563张图片

04-07 22:16:12.906: E/(8091): 测试第564张图片

04-07 22:16:12.906: D/skia(8091): ---------- mmap failed for imageref_ashmem size=2744320 err=12

04-07 22:16:12.906: E/(8091): 测试第565张图片

04-07 22:16:12.906: D/skia(8091): ---------- mmap failed for imageref_ashmem size=2744320 err=12

04-07 22:16:12.906: E/(8091): 测试第566张图片

04-07 22:16:12.916: E/filemap(8091): mmap(0,416798) failed: Out of memory

04-07 22:16:12.916: D/filemap(8091): munmap(0x0, 0) failed

04-07 22:16:12.916: W/asset(8091): create map from entry failed

04-07 22:16:12.916: D/AndroidRuntime(8091): Shutting down VM

04-07 22:16:12.916: W/dalvikvm(8091): threadid=1: thread exiting with uncaught exception (group=0x40015560)

04-07 22:16:12.936: E/AndroidRuntime(8091): FATAL EXCEPTION: main

04-07 22:16:12.936: E/AndroidRuntime(8091): java.lang.RuntimeException: Unable to start activity ComponentInfo{bassy.test.drawable/bassy.test.drawable.Main}: android.content.res.Resources$NotFoundException: File res/drawable-mdpi/img.png from drawable resource ID #0x7f020001

04-07 22:16:12.936: E/AndroidRuntime(8091):   at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1768)

04-07 22:16:12.936: E/AndroidRuntime(8091):   at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1784)

04-07 22:16:12.936: E/AndroidRuntime(8091):   at android.app.ActivityThread.access$1500(ActivityThread.java:123)

04-07 22:16:12.936: E/AndroidRuntime(8091):   at android.app.ActivityThread$H.handleMessage(ActivityThread.java:939)

04-07 22:16:12.936: E/AndroidRuntime(8091):   at android.os.Handler.dispatchMessage(Handler.java:99)

04-07 22:16:12.936: E/AndroidRuntime(8091):   at android.os.Looper.loop(Looper.java:130)

04-07 22:16:12.936: E/AndroidRuntime(8091):   at android.app.ActivityThread.main(ActivityThread.java:3835)

04-07 22:16:12.936: E/AndroidRuntime(8091):   at java.lang.reflect.Method.invokeNative(Native Method)

04-07 22:16:12.936: E/AndroidRuntime(8091):   at java.lang.reflect.Method.invoke(Method.java:507)

04-07 22:16:12.936: E/AndroidRuntime(8091):   at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:847)

04-07 22:16:12.936: E/AndroidRuntime(8091):   at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:605)

04-07 22:16:12.936: E/AndroidRuntime(8091):   at dalvik.system.NativeStart.main(Native Method)

04-07 22:16:12.936: E/AndroidRuntime(8091): Caused by: android.content.res.Resources$NotFoundException: File res/drawable-mdpi/img.png from drawable resource ID #0x7f020001

04-07 22:16:12.936: E/AndroidRuntime(8091):   at android.content.res.Resources.openRawResource(Resources.java:860)

04-07 22:16:12.936: E/AndroidRuntime(8091):   at android.content.res.Resources.openRawResource(Resources.java:836)

04-07 22:16:12.936: E/AndroidRuntime(8091):   at bassy.test.drawable.Main.onCreate(Main.java:43)

04-07 22:16:12.936: E/AndroidRuntime(8091):   at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1047)

04-07 22:16:12.936: E/AndroidRuntime(8091):   at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1722)

04-07 22:16:12.936: E/AndroidRuntime(8091):   ... 11 more

04-07 22:16:12.936: E/AndroidRuntime(8091): Caused by: java.io.FileNotFoundException: res/drawable-mdpi/img.png

04-07 22:16:12.936: E/AndroidRuntime(8091):   at android.content.res.AssetManager.openNonAssetNative(Native Method)

04-07 22:16:12.936: E/AndroidRuntime(8091):   at android.content.res.AssetManager.openNonAsset(AssetManager.java:429)

04-07 22:16:12.936: E/AndroidRuntime(8091):   at android.content.res.Resources.openRawResource(Resources.java:857)

04-07 22:16:12.936: E/AndroidRuntime(8091):   ... 15 more

 

从上面可以看出,程序在加载到第566张的时候,就出现了OOM错误。

不过,跟第2个例子比起来,你会发现,程序可以加载更多的图片。

这说明了使用BitmapFactorydecodeResource方法会占据大量内存,

而使用使用decodeStream方法,则占据更小的内存。

 

从时间上来说,看看日志输出,大概估算了一下加载一张图片所需要的时间,发现,

decodeResource加载图片需要约0.17秒的时间,

而使用decodeStream方法,只需要约0.08秒的时间!

这说明了,decodeStream无论是时间上还是空间上,都比decodeResource方法更优秀!!

 

 

从上面三个例子,可以看出,用第一种方法(即用Drawable加载图片)可以加载更加的图片,加载32张图片的时间约为0.01秒!

我试着把Drawable的数量调至1000000,程序在运行时,停在了153761张图片里,手机提示,“应用程序无响应

个人猜测,Drawable应该不属于常驻内存的对象,不然的话,不可能不会出现OOM的~~

 

网上关于DrawableBitmap的资料太少,不能深入学习,真是遗憾~

 

 

刚才又做了个测试,把第一个例子中的

array[i] = getResources().getDrawable(R.drawable.img);

方法换成了

array[i] = Drawable.createFromStream(getResources().openRawResource(R.drawable.img), null);

结果和第三个例子一样,在第566张图片中,出现了OOM错误!

而且,加载的时间都是一样~~

这样一来,我就更加迷惑了~~

 

posted @ 2012-08-10 13:55 肆意感受 阅读(292) 评论(0)  编辑

(本文对我帮助很大,在此谢谢原作者)

原创作品,允许转载,转载时请务必以超链接形式标明文章  原始出处 、作者信息和本声明。否则将追究法律责任。 http://mzh3344258.blog.51cto.com/1823534/804237
 

在最近做的工程中发现加载的图片太多或图片过大时经常出现OOM问题,找网上资料也提供了很多方法,但自己感觉有点乱,特此,今天在不同型号的三款安卓手机上做了测试,因为有效果也有结果,今天小马就做个详细的总结,以供朋友们共同交流学习,也供自己以后在解决OOM问题上有所提高,提前讲下,片幅有点长,涉及的东西太多,大家耐心看,肯定有收获的,里面的很多东西小马也是学习参考网络资料使用的,先来简单讲下下:

一般我们大家在遇到内存问题的时候常用的方式网上也有相关资料,大体如下几种:

一:在内存引用上做些处理,常用的有软引用、强化引用、弱引用

二:在内存中加载图片时直接在内存中做处理,如:边界压缩

三:动态回收内存

四:优化Dalvik虚拟机的堆内存分配

五:自定义堆内存大小

可是真的有这么简单吗,就用以上方式就能解决OOM了?不是的,继续来看...

下面小马就照着上面的次序来整理下解决的几种方式,数字序号与上面对应:

1:软引用(SoftReference)、虚引用(PhantomRefrence)、弱引用(WeakReference),这三个类是对heap中java对象的应用,通过这个三个类可以和gc做简单的交互,除了这三个以外还有一个是最常用的强引用

1.1:强引用,例如下面代码:

  1. Object o=new Object();
  2. Object o1=o;

上面代码中第一句是在heap堆中创建新的Object对象通过o引用这个对象,第二句是通过o建立o1到new Object()这个heap堆中的对象的引用,这两个引用都是强引用.只要存在对heap中对象的引用,gc就不会收集该对象.如果通过如下代码:

  1. o=null;
  2. o1=null

heap中对象有强可及对象、软可及对象、弱可及对象、虚可及对象和不可到达对象。应用的强弱顺序是强、软、弱、和虚。对于对象是属于哪种可及的对象,由他的最强的引用决定。如下:

  1. String abc=new String("abc"); //1
  2. SoftReference<String> abcSoftRef=new SoftReference<String>(abc); //2
  3. WeakReference<String> abcWeakRef = new WeakReference<String>(abc); //3
  4. abc=null; //4
  5. abcSoftRef.clear();//5

上面的代码中:

第一行在heap对中创建内容为“abc”的对象,并建立abc到该对象的强引用,该对象是强可及的。第二行和第三行分别建立对heap中对象的软引用和弱引用,此时heap中的对象仍是强可及的。第四行之后heap中对象不再是强可及的,变成软可及的。同样第五行执行之后变成弱可及的。

1.2:软引用

软引用是主要用于内存敏感的高速缓存。在jvm报告内存不足之前会清除所有的软引用,这样以来gc就有可能收集软可及的对象,可能解决内存吃紧问题,避免内存溢出。什么时候会被收集取决于gc的算法和gc运行时可用内存的大小。当gc决定要收集软引用是执行以下过程,以上面的abcSoftRef为例:

 

1 首先将abcSoftRef的referent设置为null,不再引用heap中的new String("abc")对象。

2 将heap中的new String("abc")对象设置为可结束的(finalizable)。

3 当heap中的new String("abc")对象的finalize()方法被运行而且该对象占用的内存被释放, abcSoftRef被添加到它的ReferenceQueue中。

注:对ReferenceQueue软引用和弱引用可以有可无,但是虚引用必须有,参见:

  1. Reference(T paramT, ReferenceQueue<? super T>paramReferenceQueue)

被 Soft Reference 指到的对象,即使没有任何 Direct Reference,也不会被清除。一直要到 JVM 内存不足且 没有 Direct Reference 时才会清除,SoftReference 是用来设计 object-cache 之用的。如此一来 SoftReference 不但可以把对象 cache 起来,也不会造成内存不足的错误 (OutOfMemoryError)。我觉得 Soft Reference 也适合拿来实作 pooling 的技巧。

  1. A obj = new A();
  2. Refenrence sr = new SoftReference(obj);
  3. //引用时
  4. if(sr!=null){
  5. obj = sr.get();
  6. }else{
  7. obj = new A();
  8. sr = new SoftReference(obj);
  9. }

1.3:弱引用

当gc碰到弱可及对象,并释放abcWeakRef的引用,收集该对象。但是gc可能需要对此运用才能找到该弱可及对象。通过如下代码可以了明了的看出它的作用:

  1. String abc=new String("abc");
  2. WeakReference<String> abcWeakRef = new WeakReference<String>(abc);
  3. abc=null;
  4. System.out.println("before gc: "+abcWeakRef.get());
  5. System.gc();
  6. System.out.println("after gc: "+abcWeakRef.get());

运行结果:

before gc: abc

after gc: null

gc收集弱可及对象的执行过程和软可及一样,只是gc不会根据内存情况来决定是不是收集该对象。如果你希望能随时取得某对象的信息,但又不想影响此对象的垃圾收集,那么你应该用 Weak Reference 来记住此对象,而不是用一般的 reference。

 

  1. A obj = new A();
  2. WeakReference wr = new WeakReference(obj);
  3. obj = null;
  4. //等待一段时间,obj对象就会被垃圾回收
  5.   ...
  6.   if (wr.get()==null) {
  7.   System.out.println("obj 已经被清除了 ");
  8.   } else {
  9.   System.out.println("obj 尚未被清除,其信息是 "+obj.toString());
  10.   }
  11.   ...
  12. }

 

在此例中,透过 get() 可以取得此 Reference 的所指到的对象,如果返回值为 null 的话,代表此对象已经被清除。这类的技巧,在设计 Optimizer 或 Debugger 这类的程序时常会用到,因为这类程序需要取得某对象的信息,但是不可以 影响此对象的垃圾收集。

1.4:虚引用

 

就是没有的意思,建立虚引用之后通过get方法返回结果始终为null,通过源代码你会发现,虚引用通向会把引用的对象写进referent,只是get方法返回结果为null.先看一下和gc交互的过程在说一下他的作用.

1.4.1 不把referent设置为null, 直接把heap中的new String("abc")对象设置为可结束的(finalizable).

1.4.2 与软引用和弱引用不同, 先把PhantomRefrence对象添加到它的ReferenceQueue中.然后在释放虚可及的对象. 

你会发现在收集heap中的new String("abc")对象之前,你就可以做一些其他的事情.通过以下代码可以了解他的作用.

 

  1. import java.lang.ref.PhantomReference;
  2. import java.lang.ref.Reference;
  3. import java.lang.ref.ReferenceQueue;
  4. import java.lang.reflect.Field;
  5. public class Test {
  6. public static boolean isRun = true;
  7. public static void main(String[] args) throws Exception {
  8. String abc = new String("abc");
  9. System.out.println(abc.getClass() + "@" + abc.hashCode());
  10. final ReferenceQueue referenceQueue = new ReferenceQueue<String>();
  11. new Thread() {
  12. public void run() {
  13. while (isRun) {
  14. Object o = referenceQueue.poll();
  15. if (o != null) {
  16. try {
  17. Field rereferent = Reference.class
  18. .getDeclaredField("referent");
  19. rereferent.setAccessible(true);
  20. Object result = rereferent.get(o);
  21. System.out.println("gc will collect:"
  22. + result.getClass() + "@"
  23. + result.hashCode());
  24. catch (Exception e) {
  25. e.printStackTrace();
  26. }
  27. }
  28. }
  29. }
  30. }.start();
  31. PhantomReference<String> abcWeakRef = new PhantomReference<String>(abc,
  32. referenceQueue);
  33. abc = null;
  34. Thread.currentThread().sleep(3000);
  35. System.gc();
  36. Thread.currentThread().sleep(3000);
  37. isRun = false;
  38. }
  39. }

 

结果为

class java.lang.String@96354

gc will collect:class java.lang.String@96354 好了,关于引用就讲到这,下面看2

2:在内存中压缩小马做了下测试,对于少量不太大的图片这种方式可行,但太多而又大的图片小马用个笨的方式就是,先在内存中压缩,再用软引用避免OOM,两种方式代码如下,大家可参考下:

方式一代码如下:

  1. @SuppressWarnings("unused")
  2. private Bitmap copressImage(String imgPath){
  3. File picture = new File(imgPath);
  4. Options bitmapFactoryOptions = new BitmapFactory.Options();
  5. //下面这个设置是将图片边界不可调节变为可调节
  6. bitmapFactoryOptions.inJustDecodeBounds = true;
  7. bitmapFactoryOptions.inSampleSize = 2;
  8. int outWidth = bitmapFactoryOptions.outWidth;
  9. int outHeight = bitmapFactoryOptions.outHeight;
  10. bmap = BitmapFactory.decodeFile(picture.getAbsolutePath(),
  11. bitmapFactoryOptions);
  12. float imagew = 150;
  13. float imageh = 150;
  14. int yRatio = (int) Math.ceil(bitmapFactoryOptions.outHeight
  15. / imageh);
  16. int xRatio = (int) Math
  17. .ceil(bitmapFactoryOptions.outWidth / imagew);
  18. if (yRatio > 1 || xRatio > 1) {
  19. if (yRatio > xRatio) {
  20. bitmapFactoryOptions.inSampleSize = yRatio;
  21. else {
  22. bitmapFactoryOptions.inSampleSize = xRatio;
  23. }
  24. }
  25. bitmapFactoryOptions.inJustDecodeBounds = false;
  26. bmap = BitmapFactory.decodeFile(picture.getAbsolutePath(),
  27. bitmapFactoryOptions);
  28. if(bmap != null){
  29. //ivwCouponImage.setImageBitmap(bmap);
  30. return bmap;
  31. }
  32. return null;
  33. }

方式二代码如下:

  1. package com.lvguo.scanstreet.activity;
  2. import java.io.File;
  3. import java.lang.ref.SoftReference;
  4. import java.util.ArrayList;
  5. import java.util.HashMap;
  6. import java.util.List;
  7. import android.app.Activity;
  8. import android.app.AlertDialog;
  9. import android.content.Context;
  10. import android.content.DialogInterface;
  11. import android.content.Intent;
  12. import android.content.res.TypedArray;
  13. import android.graphics.Bitmap;
  14. import android.graphics.BitmapFactory;
  15. import android.graphics.BitmapFactory.Options;
  16. import android.os.Bundle;
  17. import android.view.View;
  18. import android.view.ViewGroup;
  19. import android.view.WindowManager;
  20. import android.widget.AdapterView;
  21. import android.widget.AdapterView.OnItemLongClickListener;
  22. import android.widget.BaseAdapter;
  23. import android.widget.Gallery;
  24. import android.widget.ImageView;
  25. import android.widget.Toast;
  26. import com.lvguo.scanstreet.R;
  27. import com.lvguo.scanstreet.data.ApplicationData;
  28. public class PhotoScanActivity extends Activity {
  29. private Gallery gallery ;
  30. private List<String> ImageList;
  31. private List<String> it ;
  32. private ImageAdapter adapter ;
  33. private String path ;
  34. private String shopType;
  35. private HashMap<String, SoftReference<Bitmap>> imageCache = null;
  36. private Bitmap bitmap = null;
  37. private SoftReference<Bitmap> srf = null;
  38. @Override
  39. public void onCreate(Bundle savedInstanceState) {
  40. super.onCreate(savedInstanceState);
  41. getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN,
  42. WindowManager.LayoutParams.FLAG_FULLSCREEN);
  43. setContentView(R.layout.photoscan);
  44. Intent intent = this.getIntent();
  45. if(intent != null){
  46. if(intent.getBundleExtra("bundle") != null){
  47. Bundle bundle = intent.getBundleExtra("bundle");
  48. path = bundle.getString("path");
  49. shopType = bundle.getString("shopType");
  50. }
  51. }
  52. init();
  53. }
  54. private void init(){
  55. imageCache = new HashMap<String, SoftReference<Bitmap>>();
  56. gallery = (Gallery)findViewById(R.id.gallery);
  57. ImageList = getSD();
  58. if(ImageList.size() == 0){
  59. Toast.makeText(getApplicationContext(), "无照片,请返回拍照后再使用预览", Toast.LENGTH_SHORT).show();
  60. return ;
  61. }
  62. adapter = new ImageAdapter(this, ImageList);
  63. gallery.setAdapter(adapter);
  64. gallery.setOnItemLongClickListener(longlistener);
  65. }
  66. private OnItemLongClickListener longlistener = new OnItemLongClickListener() {
  67. @Override
  68. public boolean onItemLongClick(AdapterView<?> parent, View view,
  69. final int position, long id) {
  70. //此处添加长按事件删除照片实现
  71. AlertDialog.Builder dialog = new AlertDialog.Builder(PhotoScanActivity.this);
  72. dialog.setIcon(R.drawable.warn);
  73. dialog.setTitle("删除提示");
  74. dialog.setMessage("你确定要删除这张照片吗?");
  75. dialog.setPositiveButton("确定", new DialogInterface.OnClickListener() {
  76. @Override
  77. public void onClick(DialogInterface dialog, int which) {
  78. File file = new File(it.get(position));
  79. boolean isSuccess;
  80. if(file.exists()){
  81. isSuccess = file.delete();
  82. if(isSuccess){
  83. ImageList.remove(position);
  84. adapter.notifyDataSetChanged();
  85. //gallery.setAdapter(adapter);
  86. if(ImageList.size() == 0){
  87. Toast.makeText(getApplicationContext(), getResources().getString(R.string.phoSizeZero), Toast.LENGTH_SHORT).show();
  88. }
  89. Toast.makeText(getApplicationContext(), getResources().getString(R.string.phoDelSuccess), Toast.LENGTH_SHORT).show();
  90. }
  91. }
  92. }
  93. });
  94. dialog.setNegativeButton("取消",new DialogInterface.OnClickListener() {
  95. @Override
  96. public void onClick(DialogInterface dialog, int which) {
  97. dialog.dismiss();
  98. }
  99. });
  100. dialog.create().show();
  101. return false;
  102. }
  103. };
  104. private List<String> getSD() {
  105. File fileK ;
  106. it = new ArrayList<String>();
  107. if("newadd".equals(shopType)){
  108. //如果是从查看本人新增列表项或商户列表项进来时
  109. fileK = new File(ApplicationData.TEMP);
  110. }else{
  111. //此时为纯粹新增
  112. fileK = new File(path);
  113. }
  114. File[] files = fileK.listFiles();
  115. if(files != null && files.length>0){
  116. for(File f : files ){
  117. if(getImageFile(f.getName())){
  118. it.add(f.getPath());
  119. Options bitmapFactoryOptions = new BitmapFactory.Options();
  120. //下面这个设置是将图片边界不可调节变为可调节
  121. bitmapFactoryOptions.inJustDecodeBounds = true;
  122. bitmapFactoryOptions.inSampleSize = 5;
  123. int outWidth = bitmapFactoryOptions.outWidth;
  124. int outHeight = bitmapFactoryOptions.outHeight;
  125. float imagew = 150;
  126. float imageh = 150;
  127. int yRatio = (int) Math.ceil(bitmapFactoryOptions.outHeight
  128. / imageh);
  129. int xRatio = (int) Math
  130. .ceil(bitmapFactoryOptions.outWidth / imagew);
  131. if (yRatio > 1 || xRatio > 1) {
  132. if (yRatio > xRatio) {
  133. bitmapFactoryOptions.inSampleSize = yRatio;
  134. else {
  135. bitmapFactoryOptions.inSampleSize = xRatio;
  136. }
  137. }
  138. bitmapFactoryOptions.inJustDecodeBounds = false;
  139. bitmap = BitmapFactory.decodeFile(f.getPath(),
  140. bitmapFactoryOptions);
  141. //bitmap = BitmapFactory.decodeFile(f.getPath());
  142. srf = new SoftReference<Bitmap>(bitmap);
  143. imageCache.put(f.getName(), srf);
  144. }
  145. }
  146. }
  147. return it;
  148. }
  149. private boolean getImageFile(String fName) {
  150. boolean re;
  151. String end = fName
  152. .substring(fName.lastIndexOf(".") + 1, fName.length())
  153. .toLowerCase();
  154. if (end.equals("jpg") || end.equals("gif") || end.equals("png")
  155. || end.equals("jpeg") || end.equals("bmp")) {
  156. re = true;
  157. else {
  158. re = false;
  159. }
  160. return re;
  161. }
  162. public class ImageAdapter extends BaseAdapter{
  163. int mGalleryItemBackground;
  164. private Context mContext;
  165. private List<String> lis;
  166. public ImageAdapter(Context c, List<String> li) {
  167. mContext = c;
  168. lis = li;
  169. TypedArray a = obtainStyledAttributes(R.styleable.Gallery);
  170. mGalleryItemBackground = a.getResourceId(R.styleable.Gallery_android_galleryItemBackground, 0);
  171. a.recycle();
  172. }
  173. public int getCount() {
  174. return lis.size();
  175. }
  176. public Object getItem(int position) {
  177. return lis.get(position);
  178. }
  179. public long getItemId(int position) {
  180. return position;
  181. }
  182. public View getView(int position, View convertView, ViewGroup parent) {
  183. System.out.println("lis:"+lis);
  184. File file = new File(it.get(position));
  185. SoftReference<Bitmap> srf = imageCache.get(file.getName());
  186. Bitmap bit = srf.get();
  187. ImageView i = new ImageView(mContext);
  188. i.setImageBitmap(bit);
  189. i.setScaleType(ImageView.ScaleType.FIT_XY);
  190. i.setLayoutParams( newGallery.LayoutParams(WindowManager.LayoutParams.WRAP_CONTENT,
  191. WindowManager.LayoutParams.WRAP_CONTENT));
  192. return i;
  193. }
  194. }
  195. }

上面两种方式第一种直接使用边界压缩,第二种在使用边界压缩的情况下间接的使用了软引用来避免OOM,但大家都知道,这些函数在完成decode后,最终都是通过java层的createBitmap来完成的,需要消耗更多内存,如果图片多且大,这种方式还是会引用OOM异常的,不着急,有的是办法解决,继续看,以下方式也大有妙用的:

  1. 1. InputStream is = this.getResources().openRawResource(R.drawable.pic1);
  2. BitmapFactory.Options options=new BitmapFactory.Options();
  3. options.inJustDecodeBounds = false;
  4. options.inSampleSize = 10; //width,hight设为原来的十分一
  5. Bitmap btp =BitmapFactory.decodeStream(is,null,options);
  6. 2. if(!bmp.isRecycle() ){
  7. bmp.recycle() //回收图片所占的内存
  8. system.gc() //提醒系统及时回收
  9. }

上面代码与下面代码大家可分开使用,也可有效缓解内存问题哦...吼吼...
  1. public static Bitmap readBitMap(Context context, int resId){
  2. BitmapFactory.Options opt = new BitmapFactory.Options();
  3. opt.inPreferredConfig = Bitmap.Config.RGB_565;
  4. opt.inPurgeable = true;
  5. opt.inInputShareable = true;
  6. //获取资源图片
  7. InputStream is = context.getResources().openRawResource(resId);
  8. return BitmapFactory.decodeStream(is,null,opt);
  9. }

3:大家可以选择在合适的地方使用以下代码动态并自行显式调用GC来回收内存:

  1. if(bitmapObject.isRecycled()==false) //如果没有回收
  2. bitmapObject.recycle();

4:这个就好玩了,优化Dalvik虚拟机的堆内存分配,听着很强大,来看下具体是怎么一回事

对于Android平台来说,其托管层使用的Dalvik JavaVM从目前的表现来看还有很多地方可以优化处理,比如我们在开发一些大型游戏或耗资源的应用中可能考虑手动干涉GC处理,使用 dalvik.system.VMRuntime类提供的setTargetHeapUtilization方法可以增强程序堆内存的处理效率。当然具体原理我们可以参考开源工程,这里我们仅说下使用方法: 代码如下:

  1. private final static floatTARGET_HEAP_UTILIZATION = 0.75f;
  2. 在程序onCreate时就可以调用
  3. VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION);
  4. 即可

5:自定义我们的应用需要多大的内存,这个好暴力哇,强行设置最小内存大小,代码如下:

  1. private final static int CWJ_HEAP_SIZE = 6* 1024* 1024 ;
  2. //设置最小heap内存为6MB大小
  3. VMRuntime.getRuntime().setMinimumHeapSize(CWJ_HEAP_SIZE);

好了,文章写完了,片幅有点长,因为涉及到的东西太多了,其它文章小马都会贴源码,这篇文章小马是直接在项目中用三款安卓真机测试的,有效果,项目原码就不在这贴了,不然泄密了都,吼吼,但这里讲下还是会因为手机的不同而不同,大家得根据自己需求选择合适的方式来避免OOM,大家加油呀,每天都有或多或少的收获,这也算是进步,加油加油!


版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/nnmmbb/article/details/18660463

智能推荐

稀疏编码的数学基础与理论分析-程序员宅基地

文章浏览阅读290次,点赞8次,收藏10次。1.背景介绍稀疏编码是一种用于处理稀疏数据的编码技术,其主要应用于信息传输、存储和处理等领域。稀疏数据是指数据中大部分元素为零或近似于零的数据,例如文本、图像、音频、视频等。稀疏编码的核心思想是将稀疏数据表示为非零元素和它们对应的位置信息,从而减少存储空间和计算复杂度。稀疏编码的研究起源于1990年代,随着大数据时代的到来,稀疏编码技术的应用范围和影响力不断扩大。目前,稀疏编码已经成为计算...

EasyGBS国标流媒体服务器GB28181国标方案安装使用文档-程序员宅基地

文章浏览阅读217次。EasyGBS - GB28181 国标方案安装使用文档下载安装包下载,正式使用需商业授权, 功能一致在线演示在线API架构图EasySIPCMSSIP 中心信令服务, 单节点, 自带一个 Redis Server, 随 EasySIPCMS 自启动, 不需要手动运行EasySIPSMSSIP 流媒体服务, 根..._easygbs-windows-2.6.0-23042316使用文档

【Web】记录巅峰极客2023 BabyURL题目复现——Jackson原生链_原生jackson 反序列化链子-程序员宅基地

文章浏览阅读1.2k次,点赞27次,收藏7次。2023巅峰极客 BabyURL之前AliyunCTF Bypassit I这题考查了这样一条链子:其实就是Jackson的原生反序列化利用今天复现的这题也是大同小异,一起来整一下。_原生jackson 反序列化链子

一文搞懂SpringCloud,详解干货,做好笔记_spring cloud-程序员宅基地

文章浏览阅读734次,点赞9次,收藏7次。微服务架构简单的说就是将单体应用进一步拆分,拆分成更小的服务,每个服务都是一个可以独立运行的项目。这么多小服务,如何管理他们?(服务治理 注册中心[服务注册 发现 剔除])这么多小服务,他们之间如何通讯?这么多小服务,客户端怎么访问他们?(网关)这么多小服务,一旦出现问题了,应该如何自处理?(容错)这么多小服务,一旦出现问题了,应该如何排错?(链路追踪)对于上面的问题,是任何一个微服务设计者都不能绕过去的,因此大部分的微服务产品都针对每一个问题提供了相应的组件来解决它们。_spring cloud

Js实现图片点击切换与轮播-程序员宅基地

文章浏览阅读5.9k次,点赞6次,收藏20次。Js实现图片点击切换与轮播图片点击切换<!DOCTYPE html><html> <head> <meta charset="UTF-8"> <title></title> <script type="text/ja..._点击图片进行轮播图切换

tensorflow-gpu版本安装教程(过程详细)_tensorflow gpu版本安装-程序员宅基地

文章浏览阅读10w+次,点赞245次,收藏1.5k次。在开始安装前,如果你的电脑装过tensorflow,请先把他们卸载干净,包括依赖的包(tensorflow-estimator、tensorboard、tensorflow、keras-applications、keras-preprocessing),不然后续安装了tensorflow-gpu可能会出现找不到cuda的问题。cuda、cudnn。..._tensorflow gpu版本安装

随便推点

物联网时代 权限滥用漏洞的攻击及防御-程序员宅基地

文章浏览阅读243次。0x00 简介权限滥用漏洞一般归类于逻辑问题,是指服务端功能开放过多或权限限制不严格,导致攻击者可以通过直接或间接调用的方式达到攻击效果。随着物联网时代的到来,这种漏洞已经屡见不鲜,各种漏洞组合利用也是千奇百怪、五花八门,这里总结漏洞是为了更好地应对和预防,如有不妥之处还请业内人士多多指教。0x01 背景2014年4月,在比特币飞涨的时代某网站曾经..._使用物联网漏洞的使用者

Visual Odometry and Depth Calculation--Epipolar Geometry--Direct Method--PnP_normalized plane coordinates-程序员宅基地

文章浏览阅读786次。A. Epipolar geometry and triangulationThe epipolar geometry mainly adopts the feature point method, such as SIFT, SURF and ORB, etc. to obtain the feature points corresponding to two frames of images. As shown in Figure 1, let the first image be ​ and th_normalized plane coordinates

开放信息抽取(OIE)系统(三)-- 第二代开放信息抽取系统(人工规则, rule-based, 先抽取关系)_语义角色增强的关系抽取-程序员宅基地

文章浏览阅读708次,点赞2次,收藏3次。开放信息抽取(OIE)系统(三)-- 第二代开放信息抽取系统(人工规则, rule-based, 先关系再实体)一.第二代开放信息抽取系统背景​ 第一代开放信息抽取系统(Open Information Extraction, OIE, learning-based, 自学习, 先抽取实体)通常抽取大量冗余信息,为了消除这些冗余信息,诞生了第二代开放信息抽取系统。二.第二代开放信息抽取系统历史第二代开放信息抽取系统着眼于解决第一代系统的三大问题: 大量非信息性提取(即省略关键信息的提取)、_语义角色增强的关系抽取

10个顶尖响应式HTML5网页_html欢迎页面-程序员宅基地

文章浏览阅读1.1w次,点赞6次,收藏51次。快速完成网页设计,10个顶尖响应式HTML5网页模板助你一臂之力为了寻找一个优质的网页模板,网页设计师和开发者往往可能会花上大半天的时间。不过幸运的是,现在的网页设计师和开发人员已经开始共享HTML5,Bootstrap和CSS3中的免费网页模板资源。鉴于网站模板的灵活性和强大的功能,现在广大设计师和开发者对html5网站的实际需求日益增长。为了造福大众,Mockplus的小伙伴整理了2018年最..._html欢迎页面

计算机二级 考试科目,2018全国计算机等级考试调整,一、二级都增加了考试科目...-程序员宅基地

文章浏览阅读282次。原标题:2018全国计算机等级考试调整,一、二级都增加了考试科目全国计算机等级考试将于9月15-17日举行。在备考的最后冲刺阶段,小编为大家整理了今年新公布的全国计算机等级考试调整方案,希望对备考的小伙伴有所帮助,快随小编往下看吧!从2018年3月开始,全国计算机等级考试实施2018版考试大纲,并按新体系开考各个考试级别。具体调整内容如下:一、考试级别及科目1.一级新增“网络安全素质教育”科目(代..._计算机二级增报科目什么意思

conan简单使用_apt install conan-程序员宅基地

文章浏览阅读240次。conan简单使用。_apt install conan