2024年10月bitmap原理（oracle 位图索引的原理）
⑴bitmap原理（oracle位图索引的原理
⑵oracle位图索引的原理
⑶语法createbitmapindexindex_nameon表名(字段);、举个例子你就能明白了：如有表test(id,name,address)数据(,张三,大连)(,李四,天津)(,王五,北京)(,赵六,大连)....类似这样的数据，如果查询的时候用到，因为数据库中有很多这样的数据，所以一般的索引起不到查询加速的作用，而建立位图索引后会产生如下位图效果：假设有条数据(就如上所示)大连天津北京这样当查询：select*from表whereaddress=’大连’oraddress=’北京’;的时候数据库很快就能根据同行的和判断出那一条数据符合要求。
⑷位图图像（bitmap,亦称为点阵图像或绘制图像，是由称作像素（图片元素的单个点组成的。这些点可以进行不同的排列和染色以构成图样。当放大位图时，可以看见赖以构成整个图像的无数单个方块。扩大位图尺寸的效果是增大单个像素，从而使线条和形状显得参差不齐。然而，如果从稍远的位置观看它，位图图像的颜色和形状又显得是连续的。常用的位图处理软件是Photoshop。xdxa、原理：xdxa在红绿色盲体检时，工作人员会给你一个本子，在这个本子上有一些图像，而图像都是由一个个的点组成的，这和位图图像其实是差不多的。由于每一个像素都是单独染色的，您可以通过以每次一个像素的频率操作选择区域而产生近似相片的逼真效果，诸如加深阴影和加重颜色。缩小位图尺寸也会使原图变形，因为此举是通过减少像素来使整个图像变小的。同样，由于位图图像是以排列的像素集合体形式创建的，所以不能单独操作（如移动局部位图。一般情况下，位图是工具拍摄后得到的。如数码相机拍摄的照片；xdxa、颜色编码：xdxaRGB：xdxa位图颜色的一种编码方法，用红、绿、蓝三原色的光学强度来表示一种颜色。这是最常见的位图编码方法，可以直接用于屏幕显示；xdxaCMYK：xdxa位图颜色的一种编码方法，用青、品红、黄、黑四种颜料含量来表示一种颜色。常用的位图编码方法之一，可以直接用于彩色印刷；xdxa、图像属性：xdxa索引颜色/颜色表：xdxa位图常用的一种压缩方法。从位图图片中选择最有代表性的若干种颜色（通常不超过种编制成颜色表，然后将图片中原有颜色用颜色表的索引来表示。这样原图片可以被大幅度有损压缩。适合于压缩网页图形等颜色数较少的图形，不适合压缩照片等色彩丰富的图形；xdxaAlpha通道：xdxa在原有的图片编码方法基础上，增加像素的透明度信息。图形处理中，通常把RGB三种颜色信息称为红通道、绿通道和蓝通道，相应的把透明度称为Alpha通道。多数使用颜色表的位图格式都支持Alpha通道；xdxa色彩深度：xdxa色彩深度又叫色彩位数，即位图中要用多少个二进制位来表示每个点的颜色，是分辨率的一个重要指标。常用有位（单色，位（色，CGA，位（色，VGA，位（色，位（增强色，位（真彩色和位等。色深位以上的位图还可以根据其中分别表示RGB三原色或CMYK四原色（有的还包括Alpha通道的位数进一步分类，如位位图图片还可分为RGB，RGBX（有位不携带信息，RGBA，RGBA等等。
⑸BitMap和BitSet
⑹Bit-map的基本思想就是用一个bit位来标记某个元素对应的Value，而Key即是该元素。由于采用了Bit为单位来存储数据，可以很大力度的节省空间，常用于对大量整数做去重和查询操作。
⑺byte=bitkb=bytemb=kbgb=mbjava中int类型占用个字节=*=bit
⑻从上述结果来看，按位存储比按字节存储数字节约了（./.-约等于倍空间，而且按字节存储根据内存G的要求无法一次性在内存中进行处理。
⑼众所周知，每一位的取值无非就是和，给每一位编号，那么用表示数字存在，表示数字不存在。假如现在有一个字节也就是位的空间，那么按照BitMap，可以表示个数字，
⑽按照上图所示，该字节的位表示了整数数组。那么java中int类型占用了个字节，也就是位，那么就可以最多表示个数字。超过位数字呢？那就使用两个以上int去表示。
⑾假设我们要存储的数字最大值位N，则申请inttemp的数组空间，其中：temp可表示~temp可表示-.....以此类推给定任一整数M，M数字所在数组中的下标位置就应该是M/，M数字所在的位就是M%
⑿总共两步.找到整数所在数组temp的下标intindex=M/.将temp的第M%位置
⒀temp|(《《(M%))
⒁根据bitMap的原理可知，想要清除掉一个数字，那就是将对应的位置总共两步.找到整数所在数组temp的下标intindex=M/.将temp的第M%位置temp&（~(《《(M%))
⒂根据每一位代表一个数字，表示存在，表示不存在，那么只需要判断整数对应位是否位即可总共两步.找到整数所在数组temp的下标intindex=M/.将temp的第M%位置temp&(《《(M%)！=？“存在“:“不存在“
⒃BitSet就是实现了Bit-Map算法。BitSet位于java.util包下，从JDK.开始就已经有了。该类实现了一个按需增长的位向量。位集的每一个组件都有一个boolean类型的值。BitSet的每一位代表着一个非负整数。可以检查、设置、清除单个位。一个BitSet可以通过逻辑与、逻辑或、逻辑异或去修改另一个BitSet。默认情况下，所有位的标识都是false。
⒄BitSet有三种构造方法，我们直接来看无参构造器
⒅可以看到BitSet是使用long数组存储。那么long类型占用个字节，即位，一个long类型可表示个数字。默认设置BitSet可表示最大的位数为位。与上述自己实现的基本类似。
⒆可以看到JDK中的BitSet实现原理与第三节中一样，采用Bit-Map思想，BitSet封装较多的API，可供开发者们随意使用。
⒇BitMap及其在ClickHouse中的应用
⒈问题要从面试或者大数据场景下最常见的一个算法说起，问题是这样的，假如有几十亿个unsignedint类型的数据，要求去重或者计算总共有多少不重复的数据？最简单的办法就是直接利用一个HashMap，进行去重。但是这里面有个内存使用量的问题，几十亿个元素，即使不考虑HashMap本身实现所用到的数据结果，单单key本身，假如每个unsignedint占用个字节，简单算一下的话，这里都需要几十GB的内存占用，因此，这里就引出了BItMap。BItMap的思想非常简单，就是用一个bit表示一个二元的状态，比如有或者没有，存在或者不存在，用bit本身的位置信息，对应不同的数据。比如针对上面的问题，我们可以开辟一个^bit的内存空间，每一个bit存储一个unsignedint类型的数据，有就是，没有就是，总共需要存储unsignedint类型的最大范围个数据，也就是^个数据，这个^其实就是所谓的基数。如下图所示：假如存在数字，那就把对应的第位的值赋为。上图插入的数据为、、、。接着依次把所有的数据遍历然后更新这个BitMap。这样我们就可以得到最终结果。假如上面的问题变成了对几十亿个URL做判断，那应该怎么去做呢？URL没有办法和BitMap的位置关系对应上，所以，我们需要加一层哈希，把每个URL经过哈希运算得到一个整数，然后对应上BitMap。如下图所示：但是有哈希，肯定会存在碰撞，如果BitMap基数（也就是长度比较小，那碰撞的概率就大，如果基数比较大，那占用的空间又会比较多。BloomFilter的思想就是引入多个哈希函数来解决冲突的问题。也就是说对每个URL，经过多个哈希函数的运算，得到多个值，每个数值对应的BitMap的对应的位置都赋值为。这个两个URL经过多个哈希函数结果还是一样的概率就大大降低。但是由于依然存在冲突的可能性（其实冲突就是来源于我们BitMap的长度小于了数据量的基数，这也就是牺牲了准确性换来了空间使用的减少，所以BloomFilter存在假阳性的概率，不适用于任何要求%准确率的场景，也就是说BloomFilter只能用来判无，不能用来判有。比如一个URL经过多次哈希运算之后，发现对应的BitMap的位置都已经是了，那也不能说明，这个URL之前存在过了，也有可能是哈希冲突的结果。但是一个URL经过多次哈希运算之后，发现对应的BitMap的位置不是都是，那当前URL之前一定是没有存在过的。可以看到，BloomFilter引入多次哈希，在查询效率和插入效率不变的情况下，用较少空间的BitMap解决大数据量的判断问题。大部分情况下仅仅做有无的判断是不能满足使用需求的，我们还是需要真正意义上的BitMap（可以方便的用来做交并等计算，但是最好可以在基数比较大的时候，依然可以占用相对比较小的空间。这就是RoaringBitMap所要实现的。简单来说RoaringBitMap是BitMap的一种带索引的复杂BitMap数据结构。以位的RoaringBitMap为例，首先划分^个空间（Container，每个Container内部都是一个大小为^bit的BitMap，总的内存使用量还是^=Mb。这样的话和普通的BitMap是没有区别的，而RoaringBitMap的创新之处在于每个Container内的BitMap是在没有使用到的情况下是可以不分配内存空间的。这样可以大大减小内存的使用量。（这个图片是RoaringBitmaps:ImplementationofanOptimizedSoftwareLibrary论文原图要将一个个字节的数据插入RoaringBitMap，首先要用数据的高位，找到对应的Container，然后用数据的低在Container中插入。在每个Container内部，RoaringBitMap不是简单的用BitMap来进行数据的存储，而是把Container的类型划分为几种，不同的Container用来存储不同情况的数据。当个字节（个字节的原数据，低位用来插入具体的Container中的数据，总的个数小于个的时候，当前Container使用arrayContainer。为什么是个呢？*B=Kb，而一个Container如果是bitmap的结构的话，最多也就是^bit=Kb的空间。所以这里当数据个数小于使用arrayContainer会更节省空间。当然这里名字为arrayContainer，实际上是链表结构，不需要最开始就初始化个shortint的数组。当arrayContainer存储的数到个的时候（也就是使用内存到Kb的时候，arrayContainer会转换为bitmapcontainer，bitmapcontainer就是一个^bit普通的bitmap，可以存储^=个数据。这个Kb还有一个好处，是可以放到LCache中，加快计算。这个严格的说，只是一种数据压缩存储方法的实现。其压缩原理是对于连续的数字只记录初始数字以及连续的长度，比如有一串数字,,,,那么经过压缩后便只剩下,。从压缩原理我们也可以看出，这种算法对于数据的紧凑程度非常敏感，连续程度越高压缩率也越高。当然也可以实现其他的压缩方法。RoaringBitMap其核心就在于加了一层索引，利用复杂的数据结构换取了空间上的效率。需要注意的是这里并没有增加计算的复杂度，其出色的数据结构让其在做交并计算的时候性能也毫不逊色。ClickHouse中有bloom_filter类型的Skippingindexs，可以方便的用来过滤数据。ClickHouse实现了大量的BitMap的函数，用来操作BitMap。ClickHouse中的BitMap在位的时候用的是Set实现的，大于位的时候也是使用RoaringBitMap实现的。我们这里不看具体的函数，我们来看一个典型的使用场景。最常见的一个场景是根据标签来进行用户的圈选。常见的解决办法是有一张用户标签表，比如要查询标签tag=’xx’和tag=’xx’的用户需要执行SQL：但是由于不可能对每个tag列构建一级索引，所以这条SQL执行的效率并不高。可选的一种方式是先构建关于标签的BitMap数据结果，然后进行查询：（创建tag的bitmap表：（写入数据（查询如果有多张tag表，进行交并计算（要比普通的用户表进行JOIN或者IN计算要高效很多：
⒉截图框架代码原理android
⒊通过SurfaceControl.screenshot来获取一个bitmap对象，原理就是创造一个graphicBuffer，屏幕上面各个layer经过surfaceFlinger处理后，填充它，然后返回一个bitmap对象/frameworks/base/core/java/android/view/SurfaceControl.java、获取displayToken这IBinder类型的对象，、调整方向，一般调用时候传入的是rotaion是，如果传入或者会重置横竖屏方向。、捕获屏幕上所有的surface，返回一个填充内容的GraphicBuffer、把创建好的GraphicBuffer对象传入硬件支持的位图使用图形缓冲区，返回bitmap对象getPhysicalDisplayIds()返回一个long型的数组，physicalDisplayIds就是主显示设备，数组的其他位置可能会是投屏等其他设备。、通过一系列的调用会走到SurfaceposerClient.cpp的poserService::getposerService()这里获取poserService对象，poservice是一个单例模式，poserSerivce继承Singleton,且类型是poserService?，singleton中的TYPE就poserService。、其回返回一个poserService对象，若poserService已经创建，说明已经链接上了，则直接返回，若没有创建，则创建并执行connectLocked方法。、在connectLocked过程中，首先可以看到通过SurfaceFlinger名称查找服务,死循环，在ServiceMananger中通过名称不停的查找获取对应的服务。getService是一个模板函数，通过参数name去查找获取对应的服务，并将服务的IBinder转化为接口对象输出.创建死亡监听，且绑定.返回poserService单例中的ISurfaceposer对象。我们知道SurfaceFlinger继承BnSurfaceFlinger继承BnInterface《ISurfaceposer》。也就是说返回了SurfaceFlinger对象，我们就可以知道getPhysicalDisplayToken就是执行的SurfaceFlinger中的方法。/frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp在SurfaceFlinger.h/frameworks/native/services/surfaceflinger/SurfaceFlinger.hmPhysicalDisplayTokens是一个map类型，DisplayId对应某个屏幕，sp《IBinder》就是屏幕对应的SurfaceFlinger的IBinder对象。通过mPhysicalDisplayTokends.find(displayId)找到IBinder。这样SurfaceControl.getInternalDisplayToken()过程就完成，很明显返回的IBinder类型DisplayToken就是SurfaceFlinger服务端。这个方法的目的是捕获屏幕上所有的surface，返回一个填充这些surface内容的GraphicBuffer、Display就是surfaceFlinger的代理,后面最重要的截图过程就是在其内部进行的。、捕获屏幕中的bitmap，一般传入newRect,也就是不进行裁剪、接下来就是宽，高，方向，userIdentityTransform是false。nativeScreenshot通过JNI调用到了android_view_SurfaceControl.cpp中，在这个方法里面可以设置setpripority，截图应用的优先级，优先处理截图操作。可以看到了一个关键点sp《GraphicBuffer》buffer，surfaces就是要填充给这个buffer。ScreenshotClient.capture会调用到SurfaceposerClient.cpp中的capture、ISurfaceposer对象赋值，上面也介绍过此过程、调用ISurfaceposer的captureScreen方法，方法内容较多，其中关键句是Status_tresult=remote()-》transact(BnSurfacepser::_CAPTURE_SCREEN,data,&reply);会调用到服务端onTransact中找到CAPTURE_SCREEN因为服务端为SurfaceFlinger所以会执行到SurfaceFlinger中的captureScreen方法流程图如下、DisplayDevice类型display对象通过getDisplayDeviceLocked(displayToken)进行赋值，、构造一个DisplayRenderArea类型对象renderArea、bind函数中执行traverseLayersInDisplay方法,this是sf,display，std::placeholders:_是一个占位符。结果重命名为traverselayers方法。这个方法主要内容是通过getFactory().createGraphicBuffer创建一个GraphicBuffer在SurfaceFlingerDefaultFactory.cpp中可以看到new了一个GraphicBuffer对象，requestorName就是screenshot。继续往下走captureScreenmon方法、获取被调用者的UID，也就是我们系统应用App的UID，只有系统应用才能调用截图接口，、forSystem的值当然就是true了，代表是系统应用、schedule函数把和应用打交道的某个binder线程执行的任务调用到了主线程进行执行，从systrace中能很明显的看到，如下，在一个vsync周期内sf合成完后会进行屏幕的截图工作在captureScreenImplLocked方法中可以获取到各个layer，所以就可以在这块进行layer的处理，比如哪些内容不需要截取等。接下来renderScreenImplLocked方法这方法内容较多，关键语句是GLESRenderEngine继承RenderEnginegetRenderEngine().drawLayers是调用的GLESRenderEngine的drawLayers方法，这个方法主要工作是、通过GPU合成为特定的显示呈现图层、这个方法会被每一个需要通过GPU渲染的显示内容调用、display，绘制图层前显示范围的设置、Layers,绘制到显示器上的图层,z轴次序、Buffer，将layer内容填充到buffer中、userFrameBufferCache缓冲区可用就为true,没有实现缓冲区则这个值没有用、bufferFence，fence标记,看是否准备好了，准备好了就可以draw填充好buffer，这个时候buffer就有了该有的屏幕上layer内容。回到SurfaceControl.java中FinalScreenshotGraphicBufferbuffer=screenshotToBuffer(displayToken,sourceCrop,width,height,userIdentityTransform,rotation);Buffer现在有值了，已经填充好了，接下来就是把Buffer转化成Bitmap调用Bitmap.wrapHardwareBuffer(buffer.getGraphicBuffer(),buffer.getColorSpace());可以得到我们需要的bitmap，截图过程到此完成。
⒋BitMap原理与实现
⒌比较经典的问题是：在只能够使用G的内存中，如何完成以下操作：①：对亿个不重复的整数进行排序。②：找出亿个数字中重复的数字。无论是排序还是找重复的数字都需要将这亿个数字加入到内存中在去进行操作，很明显，题目给出的G内存限制说明了在这样的场景下是不能够将所有数都加入到内存中的*/（**=.G那么这时候就需要用到BitMap结构了
⒍bitMap使用一个bit为/作为map的value来标记一个数字是否存在,而map的key值正是这个数字本身。相比于一般的数据结构需要用个byte去存储数值本身，相当于是节省了*：=倍的内存空间
⒎bitMap不一定要用bit数组,可以使用int,long等等的基本数据类型实现，因为其实质都是在bit位上存数据，用哪种类型只是决定了最终实现出来的BitMap的内置数组中单个元素存放数据的多少????例如：java中的BitSet使用Long数组BitMap的实现当然少不了位运算，先来明确几个常见位运算，这是实现BitMap的基础：
⒏set(bitIndex):添加操作????.确定该数处于数组中的哪个元素的位上????intwordIndex=bitIndex》》;因为我用的是int实现，所以这里右移位（^=????.确定相对于该元素中的位置偏移????intbitPosition=bitIndex&((《《)-);这里相当于是bitIndex%（《《的取模运算，因为当取模运算的除数是的次幂，所以可以使用以下的位运算来计算，提升效率（对比HashMap的容量为什么总是的幂次方的问题，HashMap求下标时也是使用hash&(n-)tips:位运算的优先级是低于+,-等等的，所以要加上括号,防止发生不可描述的错误????.将该位置????bits|=《《bitPosition;相当于是将指定位置处的bit值置，其他位置保持不变，也就是将以这个bitIndex为key的位置为tips:这里是参考了网上的各位大佬的文章,取余+按位或，又对比了下BitSet的源码：????words|=(L《《bitIndex);没有取余操作，直接|，这两个一样吗？答案当然是一样的举个栗子：????《《==《《????????L《《==L《《即对于int和long型数据，直接左移其位数相当于是附带了对其的取模操作
⒐总结：使用Bit-map的思想，我们可以将存储空间进行压缩，而且可以对数字进行快速排序、去重和查询的操作。BloomFliter是Bit-map思想的一种扩展，它可以在允许低错误率的场景下，大大地进行空间压缩，是一种拿错误率换取空间的数据结构
⒑当一个元素加入布隆过滤器中的时候，会进行哪些操作：
⒒当我们需要判断一个元素是否存在于布隆过滤器的时候，会进行哪些操作：
⒓然后，一定会出现这样一种情况：不同的字符串可能哈希出来的位置相同（可以适当增加位数组大小或者调整我们的哈希函数来降低概率,因此：布隆过滤器可能会存在误判的情况
⒔总结来说就是：布隆过滤器说某个元素存在，小概率会误判。布隆过滤器说某个元素不在，那么这个元素一定不在。
⒕BloomFilter的应用:常用于解决缓存穿透等场景。
⒖文件中有亿个QQ号码，请设计算法对QQ号码去重，相同的QQ号码仅保留一个，内存限制G。
⒗BitMap的原理BitMap的基本原理就是用一个bit位来存放某种状态，适用于大规模数据，但数据状态又不是很多的情况。通常是用来判断某个数据存不存在的。
⒘举例：在Java里面一个int类型占个字节，假如要对于亿个int数据进行处理呢？亿*///=个G左右，需要个G的内存。如果能够采用bit储,一个bit是位，就可以标识个数字，那么M=（***位=亿,那么在存储空间方面可以大大节省。M-》bit-》*个bit位在Java里面，BitMap已经有对应实现的数据结构类java.util.BitSet，BitSet的底层使用的是long类型的数组来存储元素。我们来看看具体存储：
⒙对于，，，这四个数，如果存在的话，则可以这样表示：
⒚代表这个数存在，代表不存在。例如表中代表，，，存在，，，，不存在。那如果，，也存在怎么存呢？如图，，，我们可以存在第二个字节里
⒛以此类推。然后从小到大遍历所有正整数(字节)，当bitmapFlag值为时，就表明该数是存在的
Bitmap的内存占用和Bitmap加载优化
内存占用首先要清楚Bitmap的文件大小肯定不是实际的内存加载大小。因为文件只是存储的信息，加载到内存中显示出来时还需要经过转换。获取运行的时的内存占用：?针对Bitmap位图对象，Android的系统框架中的graphics包下的Bitmap类。有bitmap.getByteCount()方法获取内存大小，单位字节（byte?其实本质上Bitmap的内存占用计算非常简单：基本公式：总内存=宽×高×色彩空间但是在实际运行中不是这么简单，公式的每个参数都会有被不同因素影响。影响内存大小的三要素.图片宽高：这个不用解释.色彩空间：即Bitmap.Config枚举：ARGB_：总共位（byte，分别对应个数值，数值单位为bit位=byte字节，分别描述透明度（个+RGB通道（个。每个字节数值范围-。作为Bitmap配置色彩空间的默认值。BitmapFactory加载时默认。?publicBitmap.ConfiginPreferredConfig=Bitmap.Config.ARGB_RGB_总共位（byte，分别对应个数值，位（红+位（绿+位（蓝分别描述RGB通道。Glide加载时默认使用，DecodeFormat类?publicstaticfinalDecodeFormatDEFAULT=PREFER_RGB_可以看到，RGB_只需要ARGB_的一半大小，代价是没有透明度描述。.缩放比：对图片原始宽高的缩放设置认定为缩放比。主动设置：在解析Bitmap时，有个可选的Options对象，其中inSampleSize参数可以影响缩放比的结果。当使用该参数值时要求大于且是的倍数，比如在inSampleSize=时，缩放比被缩小倍（该功能只有缩小没有放大的可能，即“缩放比=原始缩放比×（/”。对内存结果的影响是缩小倍，因为宽/高都被缩小倍。该值默认不生效，需要手动设置。被动设置:在系统中主要由，具体运行设备dpi的和图片文件存储的drawable文件dpi层级决定。首先要引出屏幕密度概念。这是Android为应对众多的不同的屏幕分辨率色设备提出的概念和单位。drawable文件的dpi层级：在Drawable系列文件中保存的Bitmap位图文件。根据Android开发的规范，Drawable的系列文件中的修饰符后命名是有意义的，声明了这个文件所属的Dpi（屏幕密度层级。文件众多也对应了众多的Android设备屏幕密度。设备的dpi层级：参考material.io/devices/可以了解。设备和drawable文件的dpi缩放比计算：?比如drawable-xhdpi（=*=*mdpi下的bitmap被加载到xxxhdpi（=*=*mdpi的Pixel-XL中。?dpi缩放比=设备dpi/drawable的dpi，所以上面的，dpi缩放比=/=。?实际意义就是在高分辨率的xxxhdpi设备中，drawable-xhdpi文件需要放大倍，即宽高各放大倍来适应高密度设备。（假设没有缩放就会图小控件大。需要指出的是如果Bitmap文件保存在drawable没有后缀的文件中，系统会使用drawable的dpi默认值就是；最终公式基于以上认识，丰富上文的基本公式，可以的得到最终的计算Bitmap内存公式最终公式：总内存=(原始宽×缩放比)×(原始高×缩放比)×色彩空间举个例子：原图：宽X高，位于drawable-xxhdpi（dpi=*dpi文件包，设备Pixel-XL（dpi=.*dpi。主动设置inSampleSize=。使用默认Bitmap.Config=ARGB_缩放比=主动设置×被动设置=/×(/)=.×.=.色彩空间=ARGB_=bit=byte原始大小=×内存占用=(原始宽×缩放比)×(原始高×缩放比)×色彩空间?=×.××.×?=××?=byte?≈.MB启示理解Bitmap的最终内存占用计算原理和内存占用各个参数，我们对Bitmap的处理时就有具体的目标。比如常见的优化Bitmap加载过程，其实就是对Bitmap加载时的各个变量参数设置修改。常见的Bitmap优化：修改缩放比：目标是修改最终图片加载的宽高，进而优化内存占用。具体就是设置inSampleSize值，如在适当的View上缩放显示适合的bitmap，实现bitmap的高效加载（Glide图片框架就是这样，让显示组件View的宽高的参与缩放比计算。修改色彩空间：在明确的不需要透明度的情况，使用RGB_替换ARGB_，可以直接达到内存缩小一半的功效。缺点就是有限定条件。（从网络上的博文描述，不推荐使用ARGB_替换，因为这样的图片质量太差转自：
Bitmap图片压缩
图片压缩就是为了避免我们内存的溢出。而BitMap是android系统中对图像处理最重要的一个类，所以我们可以用他来对图像进行剪切，压缩，一系列操作。常用的压缩方法有质量压缩，采样率压缩，缩放法压缩，RGB_压缩等。质量压缩质量压缩不会减少图片的像素，他是在保持像素的前提下来改变图片的透明度，但是图片的长，宽，像素都不会变，所以他占用的内存也不会改变。采样率压缩采样率压缩其实就是缩放bitamp的尺寸，通过调节其inSampleSize参数，比如调节为，宽高会为原来的/，宽高都减少了，内存自然也就减少了。缩放法压缩放缩法压缩使用的是通过矩阵对图片进行裁剪，也是通过缩放图片尺寸，来达到压缩图片的效果，和采样率的原理一样RGB_压缩这是通过压缩像素占用的内存来达到压缩的效果，一般不建议使用ARGB_，因为画质实在是辣鸡，如果对透明度没有要求，建议可以改成RGB_，相比ARGB_将节省一半的内存开销。图片二次采样压缩.第一次采样inJustDecodeBounds设置为ture,只会加载图片的边框，不会加载图片的具体内容。.根据原图的宽高，结合控件的宽高计算出缩放比例，然后通过inSamplesize（in三pouSize对图片进行尺寸的缩放。.二次采样时需要将图片加载出来显示，不能只加载图片的框架，因此inJustDecodeBounds属性要设置为false。