图片的性能优化，一张图片占多大内存的计算-android

本文主要是介绍图片的性能优化，一张图片占多大内存的计算-android，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

> 图片的性能优化

图片的性能优化，运行期间检测不合理的图片- https://www.jianshu.com/p/adeeee995bc5
- Bitmap 内存模型
 在 API10 之前，Bitmap 对象本身存在 Dalvik Heap 中，像素是存在 native 中，这样像素并不会占用 Heap 空间，也就不会造成 Heap 内存溢出。但是缺点是Bitmap 对象被回收了，但是 native 层像素回收的时机可能跟 Heap 中 Bitmap 的对象回收时机不对应。
 API10之后，像素也放在 Dalvik Heap；
 API26 像素又放在 native，在 bitmap 被回收时，通过某一种机制能迅速地通知到 native 层回收对应的像素。

- 如何计算 bitmap 占用内存，通过 Bitmap API 在运行时计算：
1.getRowBytes：Since API Level 1
2.getByteCount：Since API Level 12
3.getAllocationByteCount:Since API Level 19

public static int getBitmapSize(Bitmap bitmap) {  
     if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {  //API 19  
         return bitmap.getAllocationByteCount();  
     }  
     if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB_MR1) { //Since API 12  
         return bitmap.getByteCount();  
     }  

     return bitmap.getRowBytes() * bitmap.getHeight();               
 } 

给定一张图片，计算加载到内存中的大小：size= width x height x (一个像素占用内存) x 压缩比例

- Hook 框架 ：Epic
Dynamic java method AOP hook for Android(continution of Dexposed on ART), Supporting 4.0~10.0- https://github.com/tiann/epic

AndroidPerfermance HookSetImageBitmap- https://github.com/liaowjcoder/AndroidPerfermance/blob/master/app/src/main/java/com/example/androidperfermance/memory/HookSetImageBitmap.java

https://github.com/liaowjcoder/AndroidPerfermance- https://github.com/liaowjcoder/AndroidPerfermance

> 一张图片占多大内存的计算

DisplayMetrics 的两个变量，摘录官方文档的解释：

    density：The logical density of the display. This is a scaling factor for the Density Independent Pixel unit, where one DIP is one pixel on an approximately 160 dpi screen (for example a 240x320, 1.5”x2” screen), providing the baseline of the system’s display. Thus on a 160dpi screen this density value will be 1; on a 120 dpi screen it would be .75; etc.This value does not exactly follow the real screen size (as given by xdpi and ydpi, but rather is used to scale the size of the overall UI in steps based on gross changes in the display dpi. For example, a 240x320 screen will have a density of 1 even if its width is 1.8”, 1.3”, etc. However, if the screen resolution is increased to 320x480 but the screen size remained 1.5”x2” then the density would be increased (probably to 1.5).
    densityDpi：The screen density expressed as dots-per-inch.

 

可以理解为 density 的数值是 1dp=density px；densityDpi 是屏幕每英寸对应多少个点（不是像素点），在 DisplayMetrics 当中，这两个的关系是线性的：

density	1	1.5	2	3	3.5	4
densityDpi	160	240	320	480	560	640

 >>> Android中有四种，分别是：
ALPHA_8：  每个像素占用1byte内存
ARGB_4444:每个像素占用2byte内存
ARGB_8888:每个像素占用4byte内存
RGB_565:     每个像素占用2byte内存

注：ARGB指的是一种色彩模式，里面A代表Alpha，R表示red，G表示green，B表示blue，其实所有的可见色都是红绿蓝组成的，所以红绿蓝又称为三原色。

简单点说

图片格式（Bitmap.Config）	占用内存的计算方向	一张100*100的图片占用内存的大小
ALPHA_8	图片长度*图片宽度	100*100=10000字节
ARGB_4444	图片长度*图片宽度*2	100*100*2=20000字节
ARGB_8888	图片长度*图片宽度*4	100*100*4=40000字节
RGB_565	图片长度*图片宽度*2	100*100*2=20000字节

Bitmap.Config  ARGB_4444，ARGB  分别占四位
Bitmap.Config  ARGB_8888，ARGB  分别占八位
Bitmap.Config  RGB_565  ，没有透明度（A）   R占5位   G 占6位   B占5位 。

> Bitmap 在内存当中占用的大小其实取决于：
 1.色彩格式，前面我们已经提到，如果是 ARGB8888 那么就是一个像素4个字节，如果是 RGB565 那就是2个字节
 2.原始文件存放的资源目录（是 hdpi 还是 xxhdpi 可不能傻傻分不清楚哈）
 3.目标屏幕的密度（所以同等条件下，红米在资源方面消耗的内存肯定是要小于三星S6的）

 jpg 是一种有损压缩的图片存储格式，而 png 则是 无损压缩的图片存储格式，显而易见，jpg 会比 png 小，代价也是显而易见的。
 抛开 Android 这个平台不谈，从出图的角度来看的话，jpg 格式的图片大小也不一定比 png 的小，这要取决于图像信息的内容：
JPG 不适用于所含颜色很少、具有大块颜色相近的区域或亮度差异十分明显的较简单的图片。对于需要高保真的较复杂的图像，PNG 虽然能无损压缩，但图片文件较大。

 如果仅仅是为了 Bitmap 读到内存中的大小而考虑的话，jpg 也好 png 也好，没有什么实质的差别；二者的差别主要体现在：
  1.alpha 你是否真的需要？如果需要 alpha 通道，那么没有别的选择，用 png。
  2.你的图色值丰富还是单调？就像刚才提到的，如果色值丰富，那么用jpg，如果作为按钮的背景，请用 png。
  3.对安装包大小的要求是否非常严格？如果你的 app 资源很少，安装包大小问题不是很凸显，看情况选择 jpg 或者 png（不过，我想现在对资源文件没有苛求的应用会很少吧。。）
  4.目标用户的 cpu 是否强劲？jpg 的图像压缩算法比 png 耗时。这方面还是要酌情选择，前几年做了一段时间 Cocos2dx，由于资源非常多，项目组要求统一使用 png，可能就是出于这方面的考虑。

 -- 在我们的例子中，

scaledWidth = int( 522 * 640 / 480f + 0.5) = int(696.5) = 696

scaledHeight = int( 686 * 640 / 480f + 0.5) = int(915.16666…) = 915

下面就是见证奇迹的时刻：
915 * 696 * 4 = 2547360 bit

 

ARGB8888格式的图片，每像素占用 4 Byte，而 RGB565则是 2 Byte。我们先看下有多少种格式可选：

格式	描述
ALPHA_8	只有一个alpha通道
ARGB_4444	这个从API 13开始不建议使用，因为质量太差
ARGB_8888	ARGB四个通道，每个通道8bit
RGB_565	每个像素占2Byte，其中红色占5bit，绿色占6bit，蓝色占5bit

--- 获取图片占用内存的大小：源码跟踪，java-->JNI --> C++

 

public final int getByteCount() {
    // int result permits bitmaps up to 46,340 x 46,340
    return getRowBytes() * getHeight();
}

public final int getrowBytes() {
   if (mRecycled) {
          Log.w(TAG, "Called getRowBytes() on a recycle()'d bitmap! This is undefined behavior!");
   }
   return nativeRowBytes(mFinalizer.mNativeBitmap);
}

static jint Bitmap_rowBytes(JNIEnv* env, jobject, jlong bitmapHandle) {
     SkBitmap* bitmap = reinterpret_cast<SkBitmap*>(bitmapHandle)
     return static_cast<jint>(bitmap->rowBytes());
}
size_t SkBitmap::ComputeRowBytes(Config c, int width) {
    return SkColorTypeMinRowBytes(SkBitmapConfigToColorType(c), width);
}

SkImageInfo.h
static int SkColorTypeBytesPerPixel(SkColorType ct) {
   static const uint8_t gSize[] = {
    0,  // Unknown
    1,  // Alpha_8
    2,  // RGB_565
    2,  // ARGB_4444
    4,  // RGBA_8888
    4,  // BGRA_8888
    1,  // kIndex_8
  };
  SK_COMPILE_ASSERT(SK_ARRAY_COUNT(gSize) == (size_t)(kLastEnum_SkColorType + 1),
                size_mismatch_with_SkColorType_enum);
 
   SkASSERT((size_t)ct < SK_ARRAY_COUNT(gSize));
   return gSize[ct];
}
 
static inline size_t SkColorTypeMinRowBytes(SkColorType ct, int width) {
    return width * SkColorTypeBytesPerPixel(ct);
}

跟踪到这里，我们发现 ARGB_8888（也就是我们最常用的 Bitmap 的格式）的一个像素占用 4byte，那么 rowBytes 实际上就是 4*width bytes。结论出来了，一张 ARGB_8888 的 Bitmap 占用内存的计算公式.

我们读取的是 drawable 目录下面的图片，用的是 decodeResource 方法，该方法本质上就两步：
  1.读取原始资源，这个调用了 Resource.openRawResource 方法，这个方法调用完成之后会对 TypedValue 进行赋值，其中包含了原始资源的 density 等信息；
  2.调用 decodeResourceStream 对原始资源进行解码和适配。这个过程实际上就是原始资源的 density 到屏幕 density 的一个映射。

BitmapFactory.java
public static Bitmap decodeResourceStream(Resources res, TypedValue value,
    InputStream is, Rect pad, Options opts) {
 
//实际上，我们这里的opts是null的，所以在这里初始化。
if (opts == null) {
    opts = new Options();
}
if (opts.inDensity == 0 && value != null) {
    final int density = value.density;
    if (density == TypedValue.DENSITY_DEFAULT) {
        opts.inDensity = DisplayMetrics.DENSITY_DEFAULT;
    } else if (density != TypedValue.DENSITY_NONE) {
        opts.inDensity = density; //这里density的值如果对应资源目录为hdpi的话，就是240
    }
}
if (opts.inTargetDensity == 0 && res != null) {
//请注意，inTargetDensity就是当前的显示密度，比如三星s6时就是640
    opts.inTargetDensity = res.getDisplayMetrics().densityDpi;
} 
return decodeStream(is, pad, opts);
}

我们看到 opts 这个值被初始化，而它的构造居然如此简单：
public Options() {
   inDither = false;
   inScaled = true;
   inPremultiplied = true;
}
---------------------------------------------------
BitmapFactory.cpp
static jobject doDecode(JNIEnv* env, SkStreamRewindable* stream, jobject padding, jobject options) {
......
    if (env->GetBooleanField(options, gOptions_scaledFieldID)) {
        const int density = env->GetIntField(options, gOptions_densityFieldID);//对应hdpi的时候，是240
        const int targetDensity = env->GetIntField(options, gOptions_targetDensityFieldID);//三星s6的为640
        const int screenDensity = env->GetIntField(options, gOptions_screenDensityFieldID);
        if (density != 0 && targetDensity != 0 && density != screenDensity) {
            scale = (float) targetDensity / density;
        }
    }
}
 
const bool willScale = scale != 1.0f;
......
SkBitmap decodingBitmap;
if (!decoder->decode(stream, &decodingBitmap, prefColorType,decodeMode)) {
   return nullObjectReturn("decoder->decode returned false");
}
//这里这个deodingBitmap就是解码出来的bitmap，大小是图片原始的大小
int scaledWidth = decodingBitmap.width();
int scaledHeight = decodingBitmap.height();
if (willScale && decodeMode != SkImageDecoder::kDecodeBounds_Mode) {
    scaledWidth = int(scaledWidth * scale + 0.5f);
    scaledHeight = int(scaledHeight * scale + 0.5f);
}
if (willScale) {
    const float sx = scaledWidth / float(decodingBitmap.width());
    const float sy = scaledHeight / float(decodingBitmap.height());
 
    // TODO: avoid copying when scaled size equals decodingBitmap size
    SkColorType colorType = colorTypeForScaledOutput(decodingBitmap.colorType());
    // FIXME: If the alphaType is kUnpremul and the image has alpha, the
    // colors may not be correct, since Skia does not yet support drawing
    // to/from unpremultiplied bitmaps.
    outputBitmap->setInfo(SkImageInfo::Make(scaledWidth, scaledHeight,
            colorType, decodingBitmap.alphaType()));
    if (!outputBitmap->allocPixels(outputAllocator, NULL)) {
        return nullObjectReturn("allocation failed for scaled bitmap");
    }
 
    // If outputBitmap's pixels are newly allocated by Java, there is no need
    // to erase to 0, since the pixels were initialized to 0.
    if (outputAllocator != &javaAllocator) {
        outputBitmap->eraseColor(0);
    }
 
    SkPaint paint;
    paint.setFilterLevel(SkPaint::kLow_FilterLevel);
 
    SkCanvas canvas(*outputBitmap);
    canvas.scale(sx, sy);
    canvas.drawBitmap(decodingBitmap, 0.0f, 0.0f, &paint);
}
......
}
  注意到其中有个 density 和 targetDensity，前者是 decodingBitmap 的 density，这个值跟这张图片的放置的目录有关（比如 hdpi 是240，xxhdpi 是480），这部分代码我跟了一下，太长了，就不列出来了；targetDensity 实际上是我们加载图片的目标 density，这个值的来源我们已经在前面给出了，就是 DisplayMetrics 的 densityDpi，如果是三星s6那么这个数值就是640。sx 和sy 实际上是约等于 scale 的，因为 scaledWidth 和 scaledHeight 是由 width 和 height 乘以 scale 得到的。我们看到 Canvas 放大了 scale 倍，然后又把读到内存的这张 bitmap 画上去，相当于把这张 bitmap 放大了 scale 倍。

outputBitmap->setInfo(SkImageInfo::Make(scaledWidth, scaledHeight,
            colorType, decodingBitmap.alphaType()));

我们看到最终输出的 outputBitmap 的大小是scaledWidth*scaledHeight，我们把这两个变量计算的片段拿出来给大家一看就明白了：
if (willScale && decodeMode != SkImageDecoder::kDecodeBounds_Mode) {
    scaledWidth = int(scaledWidth * scale + 0.5f);
    scaledHeight = int(scaledHeight * scale + 0.5f);
}

-- 想办法减少 Bitmap 内存占用: Jpg 和 Png;使用 inSampleSize;使用矩阵Matrix;合理选择Bitmap的像素格式;高能：索引位图(Indexed Bitmap);
public enum Config {
    // these native values must match up with the enum in SkBitmap.h
 
    ALPHA_8     (2),
    RGB_565     (4),
    ARGB_4444   (5),
    ARGB_8888   (6);
 
    final int nativeInt;
}


研究一下 Skia 引擎
bool SkPNGImageDecoder::getBitmapColorType(png_structp png_ptr, png_infop info_ptr,
                                       SkColorType* colorTypep,
                                       bool* hasAlphap,
                                       SkPMColor* SK_RESTRICT theTranspColorp) {
png_uint_32 origWidth, origHeight;
int bitDepth, colorType;
png_get_IHDR(png_ptr, info_ptr, &origWidth, &origHeight, &bitDepth,
             &colorType, int_p_NULL, int_p_NULL, int_p_NULL);
 
#ifdef PNG_sBIT_SUPPORTED
  // check for sBIT chunk data, in case we should disable dithering because
  // our data is not truely 8bits per component
  png_color_8p sig_bit;
  if (this->getDitherImage() && png_get_sBIT(png_ptr, info_ptr, &sig_bit)) {
#if 0
    SkDebugf("----- sBIT %d %d %d %d\n", sig_bit->red, sig_bit->green,
             sig_bit->blue, sig_bit->alpha);
#endif
    // 0 seems to indicate no information available
    if (pos_le(sig_bit->red, SK_R16_BITS) &&
        pos_le(sig_bit->green, SK_G16_BITS) &&
        pos_le(sig_bit->blue, SK_B16_BITS)) {
        this->setDitherImage(false);
    }
}
#endif
 
 
if (colorType == PNG_COLOR_TYPE_PALETTE) {
    bool paletteHasAlpha = hasTransparencyInPalette(png_ptr, info_ptr);
    *colorTypep = this->getPrefColorType(kIndex_SrcDepth, paletteHasAlpha);
    // now see if we can upscale to their requested colortype
    //这段代码，如果返回false，那么colorType就被置为索引了，那么我们看看如何返回false
    if (!canUpscalePaletteToConfig(*colorTypep, paletteHasAlpha)) {
        *colorTypep = kIndex_8_SkColorType;
    }
} else {
...... 
}
return true;

转载地址：http://blog.csdn.net/theone10211024/article/details/50801099
 

这篇关于图片的性能优化，一张图片占多大内存的计算-android的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---