① android 文件流的方式多张图片上传，并多个参数
android 开发中图片上传是很正常的，有两种可用的方式：
下面我们就说明一下以文件流上传图片的方式， 实现网络框架是Retrofit
测试上传3张手机sd卡中的图片，并传人了参数EquipmentCode, Description, ReportUserCode等
其中的思路是: Post的方式，Content-Type:multipart/form-data的类型进行上传文件的。
其中MultipartBody是RequestBody的扩展，
看看请求头的信息, 请求中携带了所有信(如果接口开发人员说不能收到, 叫他自己想想，截图给他，哈哈哈：)
上面的是上传了3张图片，如果一张，只要传一个就行！
就这样，图片上传的两种方式ok拉，测试通过的，保证正确！
参考: https://www.jianshu.com/p/acfefb0a204f
② android oom是什么意思
Android oom 有时出现很频繁，这一般不是Android设计的问题，一般是我们的问题。
就我的经验而言，出现oom，无非主要是以下几个方面：
一、加载对象过大
二、相应资源过多，没有来不及释放。
解决这样的问题，也有一下几个方面：
一：在内存引用上做些处理，常用的有软引用、强化引用、弱引用
二：在内存中加载图片时直接在内存中做处理，如：边界压缩.
三：动态回收内存
四：优化Dalvik虚拟机的堆内存分配
五：自定义堆内存大小
③ android开发三大框架
XUtil框架、volley、ImageLoader框架。
1、XUtil框架：
主要有四大模块：
（1） 数据库模块：Android中的orm框架，一行代码就可以进行增删改查；支持事务，默认关闭；可通过注解自定义表名，列名，外键，唯一性约束，NOT NULL约束，CHECK约束等（需要混淆的时候请注解表名和列名）；支持绑定外键，保存实体时外键关联实体自动保存或更新；自动加载外键关联实体，支持延时加载；支持链式表达查询，更直观的查询语义，参考下面的介绍或sample中的例子。
（2）注解模块：android中的ioc框架，完全注解方式就可以进行UI，资源和事件绑定；新的事件绑定方式，使用混淆工具混淆后仍可正常工作；目前支持常用的20种事件绑定，参见ViewCommonEventListener类和包com.lidroid.xutils.view.annotation.event。
（3）网络模块：支持同步，异步方式的请正拿求；支持大文件上传，上传大文件不会oom；支持GET，POST，PUT，MOVE，COPY，DELETE，HEAD，OPTIONS，TRACE，CONNECT请求；下载支持301/302重定向，支持设置是否根据Content-Disposition重命名下载的文件；返回文本内容的请求（默认只启用了GET请求）支持缓存，可设置默认过期时间和针对当前请求的过期时间。
（4）图片缓存模块：加载bitmap的时候无需考虑bitmap加载过程中出现的oom和android容器快速滑动时候出现的图片错位等现象；支持加载网络图片和本地图片；内存管理使用lru算法，更好的管理bitmap内存；可配置线程加载线程数量，缓存大小，缓存路径，加载显示动画等…
2、volley：JSON，图像等的异步下载；网络请求的排序（scheling）网络请求的优先级处理缓存多级别取消请求和Activity和生命周期的联动（Activity结束时同时取消所有网络请求）。
3、ImageLoader框架：支持多线程图片加载液宽。提供丰富的细节配置，比如线程池大小，闹清亮HTPP请求项，内存和磁盘缓存，图片显示时的参数配置等等；提供双缓存，支持加载过程的监听；提供图片的个性化显示配置接口。
④ android何时会发生oom怎么解决oom
首先，OOM就是内存溢出，即Out Of Memory。也就是说内存占有量超过了VM所分配的最大。
怎么解决OOM，通常OOM都发生在需要用到大量内存的情况下（创建或解析Bitmap，分配特大的数组等），在这样的一种情况下，就可能出现OOM，据我现在了解到，多数OOM都是因为Bitmap太大。所以，这里我就专门针对如何解决Bitmap的OOM。其实最核发的就是只加载可见范围内的Bitmap，试想这样一种情况，在GridView或ListView中，数据量有5000，每一屏只显示20个元素，那么不可见的，我们是不需要保存Bitmap在内在中的。所以我们就是只把那么可见的Bitmap保留在内存中，那些不可见的，就释放掉。当元素滑出来时，再去加载Bitmap。
这里我有两种方式，都可以避免OOM。
⑤ android图片压缩避免OOM
简单吹下牛：很多app都会要加载图片，但是如果不压缩图片就很容易OOM,
个人看来OOM 出现原因总的来说分为两种：
一种是内存溢出（好像在扯淡，OOM本身就是内存溢出）
另一种是：图片过大，一个屏幕显示不完全造成，似乎也是一。。 如有错误纯属扯淡；
为了避免上面的情况：加载图片的时候可以进行压缩，上传的时候要可以进行压缩，在图片不可见的时候进行回收（onDetach()）,再吹一句 用了fresco+压缩之后加载图片完全没问题了。
一、质量压缩方法：
privateBitmap compressImage(Bitmap image) {
ByteArrayOutputStream baos =newByteArrayOutputStream();
image.compress(Bitmap.CompressFormat.JPEG,100, baos);//质量压缩方法，这里100表示不压缩，把压缩后的数据存放到baos中
intoptions =100;
while( baos.toByteArray().length /1024>100) {//循环判断如果压缩后图片是否大于100kb,大于继续压缩
baos.reset();//重置baos即清空baos
image.compress(Bitmap.CompressFormat.JPEG, options, baos);//这里压缩options%，把压缩后的数据存放到baos中
options -=10;//每次都减少10
}
ByteArrayInputStream isBm =newByteArrayInputStream(baos.toByteArray());//把压缩后的数据baos存放到ByteArrayInputStream中
Bitmap bitmap = BitmapFactory.decodeStream(isBm,null,null);//把ByteArrayInputStream数据生成图片
returnbitmap;
}
二、图片按比例大小压缩方法（根据Bitmap图片压缩）
privateBitmap comp(Bitmap image) {
ByteArrayOutputStream baos =newByteArrayOutputStream();
image.compress(Bitmap.CompressFormat.JPEG,100, baos);
if( baos.toByteArray().length /1024>1024) {//判断如果图片大于1M,进行压缩避免在生成图片（BitmapFactory.decodeStream）时溢出
baos.reset();//重置baos即清空baos
image.compress(Bitmap.CompressFormat.JPEG,50, baos);//这里压缩50%，把压缩后的数据存放到baos中
}
ByteArrayInputStream isBm =newByteArrayInputStream(baos.toByteArray());
BitmapFactory.Options newOpts =newBitmapFactory.Options();
//开始读入图片，此时把options.inJustDecodeBounds 设回true了
newOpts.inJustDecodeBounds =true;
Bitmap bitmap = BitmapFactory.decodeStream(isBm,null, newOpts);
newOpts.inJustDecodeBounds =false;
intw = newOpts.outWidth;
inth = newOpts.outHeight;
//现在主流手机比较多是800*480分辨率，所以高和宽我们设置为
floathh = 800f;//这里设置高度为800f
floatww = 480f;//这里设置宽度为480f
//缩放比。由于是固定比例缩放，只用高或者宽其中一个数据进行计算即可
intbe =1;//be=1表示不缩放
if(w > h && w > ww) {//如果宽度大的话根据宽度固定大小缩放
be = (int) (newOpts.outWidth / ww);
}elseif(w < h && h > hh) {//如果高度高的话根据宽度固定大小缩放
be = (int) (newOpts.outHeight / hh);
}
if(be <=0)
be =1;
newOpts.inSampleSize = be;//设置缩放比例
//重新读入图片，注意此时已经把options.inJustDecodeBounds 设回false了
isBm =newByteArrayInputStream(baos.toByteArray());
bitmap = BitmapFactory.decodeStream(isBm,null, newOpts);
returncompressImage(bitmap);//压缩好比例大小后再进行质量压缩
}
⑥ 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日)