Why fresco chose not put bitmap in ashmem on android 5.0 or higher

Question

As Fresco project on git hub said: "In Android 4.x and lower, Fresco puts images in a special region of Android memory. This lets your application run faster - and suffer the dreaded OutOfMemoryError much less often."

And from this answer, i know it using ashmem to place bitmap.

And my question is : why fresco dose not put bitmap in ashmem on android 5.0 or higher? Does Android change some system feature and disable it?

Autogiro

What is ashmem? – Honeysuckle

Answer 1

Yes, Google disabled purgeable bitmaps in Android 5.0.

Dorsman

Answer 2

  you can see here 

https://android.googlesource.com/platform/frameworks/base/+/android-cts-7.1_r2/graphics/java/android/graphics/BitmapFactory.java

 /**
     * @deprecated As of {@link android.os.Build.VERSION_CODES#LOLLIPOP}, this is
     * ignored.
     *
     * In {@link android.os.Build.VERSION_CODES#KITKAT} and below, if this
     * is set to true, then the resulting bitmap will allocate its
     * pixels such that they can be purged if the system needs to reclaim
     * memory. In that instance, when the pixels need to be accessed again
     * (e.g. the bitmap is drawn, getPixels() is called), they will be
     * automatically re-decoded.
     *
     * <p>For the re-decode to happen, the bitmap must have access to the
     * encoded data, either by sharing a reference to the input
     * or by making a copy of it. This distinction is controlled by
     * inInputShareable. If this is true, then the bitmap may keep a shallow
     * reference to the input. If this is false, then the bitmap will
     * explicitly make a copy of the input data, and keep that. Even if
     * sharing is allowed, the implementation may still decide to make a
     * deep copy of the input data.</p>
     *
     * <p>While inPurgeable can help avoid big Dalvik heap allocations (from
     * API level 11 onward), it sacrifices performance predictability since any
     * image that the view system tries to draw may incur a decode delay which
     * can lead to dropped frames. Therefore, most apps should avoid using
     * inPurgeable to allow for a fast and fluid UI. To minimize Dalvik heap
     * allocations use the {@link #inBitmap} flag instead.</p>
     *
     * <p class="note"><strong>Note:</strong> This flag is ignored when used
     * with {@link #decodeResource(Resources, int,
     * android.graphics.BitmapFactory.Options)} or {@link #decodeFile(String,
     * android.graphics.BitmapFactory.Options)}.</p>
     */
    @Deprecated
    public boolean inPurgeable;

Coadjutor

Answer 3

In Fresco documentation they mention:

Android 5.0 and newer has much improved memory management than earlier versions, so it is safer to leave the bitmap cache on the Java heap.

Farnese