Why would I ever NOT use BitmapFactory's inPurgeable option?

前端 未结 4 1714
臣服心动
臣服心动 2020-12-02 18:48

Android\'s BitmapFactory.Options.inPurgeable has been recommended in various places as a way to avoid OutOfMemory exceptions in Android 2.x and earlier (Android

相关标签:
4条回答
  • 2020-12-02 19:31

    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.

    If you don't have access to the encoded data anymore, then this could be a problem right? What if you were live decoding bitmaps from a streaming ByteArray and your application just decides to reclaim the memory, wouldn't that cause your Bitmap to lose those pixels?

    0 讨论(0)
  • 2020-12-02 19:37

    This flag is currently completely ignored, that's the catch.


    Update by @slodge: please anyone who is reading this and seeing it as the correct answer also read the comments - 'This flag is currently completely ignored' is true in certain cases only - in other cases (e.g. when using decodeByteArray on downloaded data) then this flag is not ignored and is very, very useful

    0 讨论(0)
  • 2020-12-02 19:40

    If your are reading your bitmaps from the filesystem, using this flag wil force Android to keep the file open (at least in 4.0.4) to be able to re-read it. After reading more than 1024 files, you will reach the limit of opened files and get a "Too many open files" error.

    You can observe the beahavior by using the lsof command from a rooted terminal and review all opened files.

    0 讨论(0)
  • 2020-12-02 19:48

    The documentation has subsequently been updated with additional information which addresses your original question.

    Summary: use of this flag is no longer recommended.

    0 讨论(0)
提交回复
热议问题