A. android的Bitmap操作
src是你的原图"你好"
下面就衫告是得到裤塌携原图的一半胡伏宽度
Bitmap newBitmap = Bitmap.createBitmap(src, 0, 0, src.getWidth()/2, src.getHeight());
B. Android Bitmap理解
参考：
Android Bitmap 详解：关于 Bitamp 你所要知道的一切
Android Bitmap（位图）详解
图片是由大量且有限个数的像素点组成。把一张图片通过bitmap的方式创建到内存中，实际上就是在内存中创建了一个叫做Bitmap的对象，然后把 图片所有像素 解码后的数据存放在Bitmap对象里面，Bitmap就拥有了图片的宽高，透明度，颜色值等数据。所以Bitmap的创建是通过BitmapFactory.decodeXxx()。
Config是Bitmap类中的枚举类。像素由ARGB四个颜色通道组成。Config描述位图中像素的存储方式。 这里的存储方式，无非就是对颜色通道和用多大的容器（bit）来存储的排列组合。所以config会影响图片透明度，占用内存大小，保存成文件的大小，图片质量。
Config的字母表示该配置存储的像素的颜色通道，数字表示对应通道的数据用多少位来存储。
ALPHA_8：表示只存储alpha通道，使用8bit（1字节）的内存（容器）来存储一个像素。
RGB_565：表示存储RGB三个通道，分别使用5bit，6bit，5bit的内存（容器）来存储一个像素。
ARGB_4444：表示存储ARGB四个通道，每个通道都是以4bit的内存（容器）来存储一个像素。
ARGB_8888：表示存储ARGB四个通道，每个通道都是以8bit的内存（容器）来存储一个像素。
所以，ARGB_8888配置占用内存最大，图片质量最高。
图片压缩的一个思路就是降低图片的配置。
总内存 = 宽的像素数 × 高的像素数 × 每个像素点占用的大小
注：
1 byte = 8 bit
1 KB = 1024 byte
C. Android-Bitmap复用时内存大小计算
主要是Bitmap的这两个方法得到的Bitmap的值，会在内存复用体现。
如果不使用内存复用，这两个方法是一样的效果。
在通过复用 Bitmap 来解码图片时，那么 getByteCount() 表示新解码图片占用内存的大 小，getAllocationByteCount() 表示被复用 Bitmap真实占用的内存大小。
比如：上面的图片，黑色区域是当前Bitmap对象实际内存占用大小，但是这部分内存中，只有红色区域是新占用的，而其他的区域是可以复用的但是没被复用（即Bitmap中新的图片只是占用了8个大小，但是Bitmap实际大小其实是有20），那么如果使用getByteCount()就只会返回被复用区域的内存大小，所以使用getByteCount()返回内存区域的大小，其实是小于等于实际大小的。
以为你Bitmap占用内存大小，是由最大的图片来决定的，如果放入一张更小的图片，其实并不会减少Bitmap占用的内存大小。
可以认为：
getByteCount()只是图片的大小
getAllocationByteCount()是Bitmap的大小
因为Bitmap可以复用，所以Bitmap可以放入不同的图片，当Bitmap放入更大的图片的时候，就会占用更大的内存，但是这个时候如果对Bitmap对象进行复用，放入一张小图片，并不会改变Bitmap的大小。
D. Android Bitmap 与 Drawable之间的区别和转换
Android bitmap和drawable的区别和转换如下：
1.bitmap 转换 drawable
java">Bitmapbitmap=newBitmap(...);Drawabledrawable=newBitmapDrawable(bitmap);
//Drawabledrawable=newFastBitmapDrawable(bitmap);
2.Drawable to Bitmap
BitmapDrawable, FastBitmapDrawable直接用getBitmap
b. 其他类型的Drawable用Canvas画到一个bitmap上
Canvascanvas=newCanvas(bitmap)
drawable.draw(canvas);
Drawabled=ImagesList.get(0);Bitmapbitmap=((BitmapDrawable)d).getBitmap();
区别如下：
1.Bitmap - 称作位图，一般位图的文件格式后缀为bmp，当然编码器也有很多如RGB565、RGB888。作为一种逐像素的显示对象执行效率高，但是缺点也很明显存储效率低。
2.Drawable - 作为Android平下通用的图形对象，它可以装载常用格式的图像，比如GIF、PNG、JPG，当然也支持BMP，当然还提供一些高级的可视化对象，比如渐变、图形等。
另外还有如下相类似的格式：
Canvas - 名为画布，可以看作是一种处理过程，使用各种方法来管理Bitmap、GL或者Path路径，同时它可以配合Matrix矩阵类给图像做旋转、缩放等操作，同时Canvas类还提供了裁剪、选取等操作。
Paint - 可以把它看做一个画图工具，比如画笔、画刷。管理了每个画图工具的字体、颜色、样式。
E. Android-Bitmap的getByteCount()和getAllocationByteCount()的区别
如果不使用内存复用，这两个方法是一样的效果。
在通过复用 Bitmap 来解码图片时，那么 getByteCount() 表示新解码图片占用内存的大 小，getAllocationByteCount() 表示被复用 Bitmap真实占用的内存大小。
getByteCount()只是图片的大小
getAllocationByteCount()是Bitmap的大小亮仔
因为Bitmap可烂饥以复用，所以Bitmap可以放入不同的饥键返图片，当Bitmap放入更大的图片的时候，就会占用更大的内存，但是这个时候如果对Bitmap对象进行复用，放入一张小图片，并不会改变Bitmap的大小。
比如，最初Bitmap放入一张大小为4M的图片，这个时候Bitmap占用了4M的内存，然后当这张图片使用完成之后，对Bitmap进行复用，放入一张1M的图片，这个时候其实只是复用了Bitmap之前内存大小的四分之一，如果使用getByteCount()，得到的其实就是1M，但是这个时候Bitmap对象实际占用内存其实还是4M，虽然对Bitmap进行了复用，但是并不会因为放入的图片变小了而改变了原本Bitmap对象占用内存的大小，所以getAllocationByteCount()返回的是4M
F. Android Bitmap 内存以及OOM问题讨论
都知道在Android中, 每个应用所使用的内存是有限的,现在的手机通常最大的内存使用为256M, 目前还没发现Android中一个应用的最大内存分配超过256M的(经测试华为手机的最大内存是385M)
相关API:
ActivityManager.getMemoryClass(),首先获取系统服务中的ActivityManager
如下:
(ActivityManager) context.getSystemService(Context.ACTIVITY_SERVICE);
可以获取到相关信息
最近一直被项目的OOM问题困扰, 在网上查阅相关资料,前前后后读了不下于30篇,这些篇幅讲解的东西都是千篇一律,并没有解决到实际问题
也在慕课网学习了内存优化章节
这是慕课网讲师的PPT,我截屏的
这里来仔细分析一下:
第一个, 注意临时Bitmap对象的及时回收, 来看下相关API
直接上图
经过我无数次的使用Android studio工具自带的MAT分析工具后, 得出一个很严谨的结论, 此方法并不奏效...
Android中Bitmap的内存存放在堆区, Google 的Bitmap的recycle方法注释也可以了解到
Android历史版本不是很清楚, 据说Android3.0之前Bitmap是存放在native区域,可以进行手动释放,然而3.0之后Bitmap是存放在Java层的堆区,没错是heap, 内存管理直接交由系统GC管理,你还这样释放资源有意义?无非是给自己的一点心理安慰罢了, 告诉你没卵用
又有人在说要释放内存使用System.gc() ??? 对就是主动触发垃圾回收,这个API是开发者自行调用的吗?那么系统管理内存还有什么意义?这不是误人子弟吗,这个API不能调用的, 因为没卵用的, 具体自己参照MAT工具自行分析.即便垃圾回收真的被触发了, 所有线程停滞由系统来清理垃圾, 造成的后果是严重卡顿!!!
再看一个API:
我在网上苦苦追寻内存过高的问题后,发现了这个API,经过无数次实践后我得出一个结论,没卵用...开发者可以抛弃它
综上所诉, 第一点讲解的内存优化问题可以直接PASS掉, 无非给自己一点心理安慰: 我已经处理好了内存问题, 程序不会OOM?
第二点. 避免Bitmap的浪费
直接说结论, 这个是非常行之有效的,并且是一定能解决问题的
具体怎么操作呢? 自己实现LruCache这个类, 就是这么弄, 原理就是解码复用, 在内存中已经解码好的Bitmap直接拿出来使用, 没有的在加载到内存进行解析, 这个非常有效,但是并不能让你避免OOM
第三点, try-catch某些大内存分配的操作
这点上,我又要开始疑问了, 我Java功底不是很好
Java中发生内存溢出时,抛出的是OutOfMemoryError, 它的父类是VirtualMachineError
这玩意能catch住? 它属于Error范畴, 你能捕获?请Java大神出来说一下,我解释不清楚
第四点, 加载Bitmap 缩放比例, 解码格式, 局部加载
先来分析一下缩放比例:
按照市面上主流的手机分辨率来分析现在Android主流的分辨率是1920X1080, 如果一个ImageView控件刚好就是屏幕全屏,怎么说?直接占用掉8M内存, 想想一个实际的需求情况
一个查看大图的页面, 不断的关闭,打开查看新的大图,问题就来了,内存一直在暴增,迟早会突破界限OOM掉
分辨率是2K屏呢? 更恐怖了, 随着手机设备的屏幕分辨率提升, 加载图像需要的内存也是倍增的, 因为应用的最大内存并没有增加
结论: 缩放比例可以有效的降低内存占用问题, 但不是绝对的救命稻草, 该缩放的还是要缩放,而且必须缩放,就是采样 现在通常都是图片加载框架来完成,类似Glide.Picasso,Fresco等,他们可以帮助你减少工作量, 内存问题还是存在
再来分析一下解码格式:
这个跟缩放比例效果差不多, 只是同样的分辨率的图片加载到内存中时占用内存减少了
比如ARGB_8888 共32位
RGB_565 共16位
ARGB_4444 共16位
很明显这样格式图片加载的内存情况是ARGB_8888是其他格式的两倍内存
另外的问题是ARGB_8888看起来很清晰的, 其它的看起来图片有种糊了的感觉,自己选择吧
结论, 降低内存占用非常有效
最后一个是局部加载, 并没有怎么使用到,也不清楚就不说了
最后还有一个方法避免OOM, 开启largeHeap属性, 但是但是, 以前我们开启这个属性后被Oppo应用市场认定为占用内存过高, 不建议用户安装......所以我们又取消了!
总的来说, Bitmap在内存是变现的是不可控, 我项目OOM问题一直没有得到有效解决,因为图片编辑视频编辑之类的功能占用内存过高,继续使用OOM是必然的, 跟IOS的同学交流了一番,他们说IOS的应用内存可以占用到1个G以上, 轻松跑到500M是没问题的, IOS的内存机制可以持续给内存使用, 具体我也不清楚,并且他们可以手动释放内存?malloc, free这样子?
如果大家有比较好的方案,还望留言交流互相帮助 [笑脸.gif]
补充: Android8.0开始Bitmap数据内存存在native层, 单个应用可用的内存显着增长, 极大的降低了OOM的概率(2018年3月22日)
G. Android：窗口、自定义view、bitmap
1、ViewRoot 对应于 ViewRootImpl 类，它是连接 WindowManager 和 DecorView 的纽带，View 的三大流程均是通过 ViewRoot 来完成的。在 ActivityThread 中，当 Activity 对象被创建完毕后，会将 DecorView 添加到 Window 中，同时会创建 ViewRootImpl 对象，并将 ViewRootImpl 对棚弯象和 DecorView 建立关联
2、 自定义View-绘制流程概述
4、 Android Handler
6、 Android Bitmap
2、MeasureSpec：
3、一般来说，使用多进程会造成以下几个方面的问题：
5、Window 概念与分类：
Window 是一个抽象类，它的具体实现是 PhoneWindow。WindowManager 是外界访问 Window 的入口，Window 的具体实现位于 WindowManagerService 中，WindowManager 和 WindowManagerService 的交互是一个 IPC 过程。Android 中所有的视图都是通过 Window 来呈现，因此 Window 实际是 View 的直接管理者。
6、window的三大操作：addView、upView、removeView
7、 Bitmap 中有两个内部枚举类：
保存图片资源：
图片压缩：
基本使用：
8、Context 本身是一个抽象类，是对一系列系统服务接口的封装，包括：内部伏丛资源、包、类加载、I/O操作、权限、主线程、IPC 和组件启动等操作的管理。ContextImpl, Activity, Service, Application 这些都是 Context 的直接或间接子类
9、SharedPreferences 采用key-value（键值对）形式, 主要用于轻量级的数据存储, 尤其适合保存应用的配置参数, 但不建议使用 SharedPreferences 来存储大规模的数据, 可能会降低性能
10、SharedPreferences源码有用synchronize进行加锁同步
11、Handler 有两个主要用途：
（1）安排 Message 和 runnables 在将来的某个时刻执行;
（2）将要在不同链厅闷于自己的线程上执行的操作排入队列。(在多个线程并发更新UI的同时保证线程安全。)
只有主线程能对UI进行操作，所以在对UI进行跟改之前，ViewRootImpl 对UI操作做了验证，这个验证工作是由 ViewRootImpl的 checkThread 方法完成：
12、ThreadLocal 是一个线程内部的数据存储类，通过它可以在指定的线程中存储数据，其他线程则无法获取。Looper、ActivityThread 以及 AMS 中都用到了 ThreadLocal。当不同线程访问同一个ThreadLocal 的 get方法，ThreadLocal 内部会从各自的线程中取出一个数组，然后再从数组中根据当前 ThreadLcoal 的索引去查找对应的value值：
13、Android 提供了几种途径来从其他线程访问 UI 线程:
Android单线程模式必须遵守的规则：
14、HandlerThread 集成了 Thread，却和普通的 Thread 有显着的不同。普通的 Thread 主要用于在 run 方法中执行一个耗时任务，而 HandlerThread 在内部创建了消息队列，外界需要通过 Handler 的消息方式通知 HanderThread 执行一个具体的任务。
15、IntentService 可用于执行后台耗时的任务，当任务执行后会自动停止，由于其是 Service 的原因，它的优先级比单纯的线程要高，所以 IntentService 适合执行一些高优先级的后台任务。在实现上，IntentService 封装了 HandlerThread 和 Handler。IntentService 第一次启动时，会在 onCreatea 方法中创建一个 HandlerThread，然后使用的 Looper 来构造一个 Handler 对象 mServiceHandler，这样通过 mServiceHandler 发送的消息最终都会在 HandlerThread 中执行。每次启动 IntentService，它的 onStartCommand 方法就会调用一次，onStartCommand 中处理每个后台任务的 Intent，onStartCommand 调用了 onStart 方法。可以看出，IntentService 仅仅是通过 mServiceHandler 发送了一个消息，这个消息会在 HandlerThread 中被处理。mServiceHandler 收到消息后，会将 Intent 对象传递给 onHandlerIntent 方法中处理，执行结束后，通过 stopSelf(int startId) 来尝试停止服务。（stopSelf() 会立即停止服务，而 stopSelf(int startId) 则会等待所有的消息都处理完毕后才终止服务）。
16、RecyclerView 优化
H. Bitmap使用详解
用到的图片不仅仅包括.png、.gif、.9.png、.jpg和各种Drawable系对象，还包括位图Bitmap
图片的处理也经常是影响着一个程序竖睁的高效性和健壮性。
为什么不直接用Bitmap传输？
位图文件虽好，但是非压缩格式，占用较大存储空间。
Bitmap主要方法有：获取图像宽高、释放，判断是否已释放和是否可修改，压缩、创建制定位图等功能
用于从不同的数据源(如文件、输入流、资源文件、字节数组、文件描述符等)解析、创建Bitmap对象
允许我们定义图片以何种方式戚饥如何读到内存。
推荐阅读： Android - Bitmap-内存分析
注意事项：
decodeFileDescriptor比decodeFile高效
查看源码可以知道
替换成
建议采用decodeStream代替decodeResource。
因为BitmapFactory.decodeResource 加载的图片可能会经过缩放，该缩放目前是放在 java 层做的，效率比较低，而且需要消耗 java 层的内存。因此，如果大量使用该接口加载图片，容余仔岁易导致OOM错误，BitmapFactory.decodeStream 不会对所加载的图片进行缩放，相比之下占用内存少，效率更高。
这两个接口各有用处，如果对性能要求较高，则应该使用 decodeStream；如果对性能要求不高，且需要 Android 自带的图片自适应缩放功能，则可以使用 decodeResource。
推荐阅读：[ BitmapFactory.decodeResource加载图片缩小的原因及解决方法
canvas和Matrix可对Bitmap进行旋转、放缩、平移、切错等操作
可以用Bitmap.onCreateBitmap、Canvas的clipRect和clipPath等等方式
推荐阅读： android自定义View学习4--图像剪切与变换
对初始化Bitmap对象过程中可能发生的OutOfMemory异常进行了捕获。如果发生了OutOfMemory异常，应用不会崩溃，而是得到了一个默认的Bitmap图。
如果不进行缓存，尽管看到的是同一张图片文件，但是使用BitmapFactory类的方法来实例化出来的Bitmap，是不同的Bitmap对象。缓存可以避免新建多个Bitmap对象，避免内存的浪费。
如果图片像素过大，使用BitmapFactory类的方法实例化Bitmap的过程中，需要大于8M的内存空间，就必定会发生OutOfMemory异常。
可以将图片缩小，以减少载入图片过程中的内存的使用，避免异常发生。
推荐阅读：
Bitmap详解与Bitmap的内存优化
I. Android Bitmap 与 Drawable之间的区别和转换
Bitmap - 称作位图，一般位图的文件格式后缀为bmp，当然编码器也有很多如RGB565、RGB888。作为一种逐像素的显示对象蠢念执行效率高，但是缺点也很明显存储效率低。我们理解为一种存储对象比较好。
Drawable - 作为Android平下通用的图形对象，它可以装载常用格式的图像，比如GIF、PNG、JPG，带银困当然也支持BMP，当然还提供一些搏历高级的可视化对象，比如渐变、图形等。
A bitmap is a Drawable. A Drawable is not necessarily a bitmap. Like all thumbs are fingers but not all fingers are thumbs.
Bitmap是Drawable . Drawable不一定是Bitmap .就像拇指是指头,但不是所有的指头都是拇指一样.
The API dictates: API规定:
Though usually not visible to the application, Drawables may take a variety of forms: 尽管通常情况下对于应用是不可见的,Drawables 可以采取很多形式:
Bitmap: the simplest Drawable, a PNG or JPEG image. Bitmap: 简单化的Drawable, PNG 或JPEG图像.
Nine Patch: an extension to the PNG format allows it to specify
information about how to stretch it and place things inside of it.
Shape: contains simple drawing commands instead of a raw bitmap, allowing it to resize better in some cases.
Layers: a compound drawable, which draws multiple underlying drawables on top of each other.
States: a compound drawable that selects one of a set of drawables based on its state.
Levels: a compound drawable that selects one of a set of drawables based on its level.
Scale: a compound drawable with a single child drawable, whose overall size is modified based on the current level.