热门标签 | HotTags
当前位置:  开发笔记 > Android > 正文

android使用okhttp可能引发OOM的一个点

这篇文章主要介绍了android使用okhttp可能引发OOM的一个点,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧

遇到一个问题: 需要给所有的请求加签名校验以防刷接口;传入请求url及body生成一个文本串作为一个header传给服务端;已经有现成的签名检验方法String doSignature(String url, byte[] body);当前网络库基于com.squareup.okhttp3:okhttp:3.14.2.
这很简单了,当然是写一个interceptor然后将request对象的url及body传入就好.于是有:

public class SignInterceptor implements Interceptor {
  @NonNull
  @Override
  public Response intercept(@NonNull Chain chain) throws IOException {
    Request request = chain.request();
    RequestBody body = request.body();
    byte[] bodyBytes = null;
    if (body != null) {
      final Buffer buffer = new Buffer();
      body.writeTo(buffer);
      bodyBytes = buffer.readByteArray();
    }

    Request.Builder builder = request.newBuilder();
    HttpUrl oldUrl = request.url();
    final String url = oldUrl.toString();
    final String signed = doSignature(url, bodyBytes));
    if (!TextUtils.isEmpty(signed)) {
      builder.addHeader(SIGN_KEY_NAME, signed);
    }
    return chain.proceed(builder.build());
  }
}

okhttp的ReqeustBody是一个抽象类,内容输出只有writeTo方法,将内容写入到一个BufferedSink接口实现体里,然后再将数据转成byte[]也就是内存数组.能达到目的的类只有Buffer,它实现了BufferedSink接口并能提供转成内存数组的方法readByteArray. 这貌似没啥问题呀,能造成OOM?

是的,要看请求类型,如果是一个上传文件的接口呢?如果这个文件比较大呢?上传接口有可能会用到public static RequestBody create(final @Nullable MediaType contentType, final File file)方法,如果是针对文件的实现体它的writeTo方法是sink.writeAll(source);而我们传给签名方法时用到的Buffer.readByteArray是将缓冲中的所有内容转成了内存数组, 这意味着文件中的所有内容被转成了内存数组, 就是在这个时机容易造成OOM! RequestBody.create源码如下:

 public static RequestBody create(final @Nullable MediaType contentType, final File file) {
  if (file == null) throw new NullPointerException("file == null");

  return new RequestBody() {
   @Override public @Nullable MediaType contentType() {
    return contentType;
   }

   @Override public long contentLength() {
    return file.length();
   }

   @Override public void writeTo(BufferedSink sink) throws IOException {
    try (Source source = Okio.source(file)) {
     sink.writeAll(source);
    }
   }
  };
 }

可以看到实现体持有了文件,Content-Length返回了文件的大小, 内容全部转给了Source对象。

这确实是以前非常容易忽略的一个点,很少有对请求体作额外处理的操作,而一旦这个操作变成一次性的大内存分配, 非常容易造成OOM. 所以要如何解决呢? 签名方法又是如何处理的呢? 原来这个签名方法在这里偷了个懒——它只读取传入body的前4K内容,然后只针对这部分内容进行了加密,至于传入的这个内存数组本身多大并不考虑,完全把风险和麻烦丢给了外部(优秀的SDK!).

快速的方法当然是罗列白名单,针对上传接口服务端不进行加签验证, 但这容易挂一漏万,而且增加维护成本, 要签名方法sdk的人另写合适的接口等于要他们的命, 所以还是得从根本解决. 既然签名方法只读取前4K内容,我们便只将内容的前4K部分读取再转成方法所需的内存数组不就可了? 所以我们的目的是: 期望RequestBody能够读取一部分而不是全部的内容. 能否继承RequestBody重写它的writeTo? 可以,但不现实,不可能全部替代现有的RequestBody实现类, 同时ok框架也有可能创建私有的实现类. 所以只能针对writeTo的参数BufferedSink作文章, 先得了解BufferedSink又是如何被okhttp框架调用的.

BufferedSink相关的类包括Buffer, Source,都属于okio框架,okhttp只是基于okio的一坨, okio没有直接用java的io操作,而是另行写了一套io操作,具体是数据缓冲的操作.接上面的描述, Source是怎么创建, 同时又是如何操作BufferedSink的? 在Okio.java中:

 public static Source source(File file) throws FileNotFoundException {
  if (file == null) throw new IllegalArgumentException("file == null");
  return source(new FileInputStream(file));
 }
 
 public static Source source(InputStream in) {
  return source(in, new Timeout());
 }

 private static Source source(final InputStream in, final Timeout timeout) {
  return new Source() {
   @Override public long read(Buffer sink, long byteCount) throws IOException {
    try {
     timeout.throwIfReached();
     Segment tail = sink.writableSegment(1);
     int maxToCopy = (int) Math.min(byteCount, Segment.SIZE - tail.limit);
     int bytesRead = in.read(tail.data, tail.limit, maxToCopy);
     if (bytesRead == -1) return -1;
     tail.limit += bytesRead;
     sink.size += bytesRead;
     return bytesRead;
    } catch (AssertionError e) {
     if (isAndroidGetsocknameError(e)) throw new IOException(e);
     throw e;
    }
   }

   @Override public void close() throws IOException {
    in.close();
   }

   @Override public Timeout timeout() {
    return timeout;
   }
  };
 }

Source把文件作为输入流inputstream进行了各种读操作, 但是它的read方法参数却是个Buffer实例,它又是从哪来的,又怎么和BufferedSink关联的? 只好再继续看BufferedSink.writeAll的实现体。

BufferedSink的实现类就是Buffer, 然后它的writeAll方法:

 @Override public long writeAll(Source source) throws IOException {
  if (source == null) throw new IllegalArgumentException("source == null");
  long totalBytesRead = 0;
  for (long readCount; (readCount = source.read(this, Segment.SIZE)) != -1; ) {
   totalBytesRead += readCount;
  }
  return totalBytesRead;
 }

原来是显式的调用了Source.read(Buffer,long)方法,这样就串起来了,那个Buffer参数原来就是自身。

基本可以确定只要实现BufferedSink接口类, 然后判断读入的内容超过指定大小就停止写入就返回就可满足目的, 可以名之FixedSizeSink.

然而麻烦的是BufferedSink的接口非常多, 将近30个方法, 不知道框架会在什么时机调用哪个方法,只能全部都实现! 其次是接口方法的参数有很多okio的类, 这些类的用法需要了解, 否则一旦用错了效果适得其反. 于是对一个类的了解变成对多个类的了解, 没办法只能硬着头皮写.

第一个接口就有点蛋疼: Buffer buffer(); BufferedSink返回一个Buffer实例供外部调用, BufferedSink的实现体即是Buffer, 然后再返回一个Buffer?! 看了半天猜测BufferedSink是为了提供一个可写入的缓冲对象, 但框架作者也懒的再搞接口解耦的那一套了(唉,大家都是怎么简单怎么来). 于是FixedSizeSink至少需要持有一个Buffer对象, 它作实际的数据缓存,同时可以在需要Source.read(Buffer ,long)的地方作为参数传过去.

同时可以看到RequestBody的一个实现类FormBody, 用这个Buffer对象直接写入一些数据:

 private long writeOrCountBytes(@Nullable BufferedSink sink, boolean countBytes) {
  long byteCount = 0L;

  Buffer buffer;
  if (countBytes) {
   buffer = new Buffer();
  } else {
   buffer = sink.buffer();
  }

  for (int i = 0, size = encodedNames.size(); i  0) buffer.writeByte('&');
   buffer.writeUtf8(encodedNames.get(i));
   buffer.writeByte('=');
   buffer.writeUtf8(encodedValues.get(i));
  }

  if (countBytes) {
   byteCount = buffer.size();
   buffer.clear();
  }

  return byteCount;
 }

有这样的操作就有可能限制不了缓冲区大小变化!不过数据量应该相对小一些而且这种用法场景相对少,我们指定的大小应该能覆盖的了这种情况。

接着还有一个接口BufferedSink write(ByteString byteString), 又得了解ByteString怎么使用, 真是心力交瘁啊...

 @Override public Buffer write(ByteString byteString) {
  byteString.write(this);
  return this;
 }

Buffer实现体里可以直接调用ByteString.write(Buffer)因为是包名访问,自己实现的FixedSizeSink声明在和同一包名package okio;也可以这样使用,如果是其它包名只能先转成byte[]了, ByteString应该不大不然也不能这么搞(没有找到ByteString读取一段数据的方法):

  @Override
  public BufferedSink write(@NotNull ByteString byteString) throws IOException {
    byte[] bytes = byteString.toByteArray();
    this.write(bytes);
    return this;
  }

总之就是把这些对象转成内存数组或者Buffer能够接受的参数持有起来!

重点关心的writeAll反而相对好实现一点, 我们连续读取指定长度的内容直到内容长度达到我们的阈值就行.

还有一个蛋疼的点是各种对象的read/write数据流方向:

Caller.read(Callee)/Caller.write(Callee), 有的是从Caller到Callee, 有的是相反,被一个小类整的有点头疼……

最后上完整代码, 如果发现什么潜在的问题也可以交流下~:

public class FixedSizeSink implements BufferedSink {
  private static final int SEGMENT_SIZE = 4096;
  private final Buffer mBuffer = new Buffer();
  private final int mLimitSize;

  private FixedSizeSink(int size) {
    this.mLimitSize = size;
  }

  @Override
  public Buffer buffer() {
    return mBuffer;
  }

  @Override
  public BufferedSink write(@NotNull ByteString byteString) throws IOException {
    byte[] bytes = byteString.toByteArray();
    this.write(bytes);
    return this;
  }

  @Override
  public BufferedSink write(@NotNull byte[] source) throws IOException {
    this.write(source, 0, source.length);
    return this;
  }

  @Override
  public BufferedSink write(@NotNull byte[] source, int offset,
      int byteCount) throws IOException {
    long available = mLimitSize - mBuffer.size();
    int count = Math.min(byteCount, (int) available);
    android.util.Log.d(TAG, String.format("FixedSizeSink.offset=%d,"
             "count=%d,limit=%d,size=%d",
        offset, byteCount, mLimitSize, mBuffer.size()));
    if (count > 0) {
      mBuffer.write(source, offset, count);
    }
    return this;
  }

  @Override
  public long writeAll(@NotNull Source source) throws IOException {
    this.write(source, mLimitSize);
    return mBuffer.size();
  }

  @Override
  public BufferedSink write(@NotNull Source source, long byteCount) throws IOException {
    final long count = Math.min(byteCount, mLimitSize - mBuffer.size());
    final long BUFFER_SIZE = Math.min(count, SEGMENT_SIZE);
    android.util.Log.d(TAG, String.format("FixedSizeSink.count=%d,limit=%d"
             ",size=%d,segment=%d",
        byteCount, mLimitSize, mBuffer.size(), BUFFER_SIZE));
    long totalBytesRead = 0;
    long readCount;
    while (totalBytesRead 

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持。


推荐阅读
  • 在Android开发中,使用Picasso库可以实现对网络图片的等比例缩放。本文介绍了使用Picasso库进行图片缩放的方法,并提供了具体的代码实现。通过获取图片的宽高,计算目标宽度和高度,并创建新图实现等比例缩放。 ... [详细]
  • PHP图片截取方法及应用实例
    本文介绍了使用PHP动态切割JPEG图片的方法,并提供了应用实例,包括截取视频图、提取文章内容中的图片地址、裁切图片等问题。详细介绍了相关的PHP函数和参数的使用,以及图片切割的具体步骤。同时,还提供了一些注意事项和优化建议。通过本文的学习,读者可以掌握PHP图片截取的技巧,实现自己的需求。 ... [详细]
  • 本文介绍了Java工具类库Hutool,该工具包封装了对文件、流、加密解密、转码、正则、线程、XML等JDK方法的封装,并提供了各种Util工具类。同时,还介绍了Hutool的组件,包括动态代理、布隆过滤、缓存、定时任务等功能。该工具包可以简化Java代码,提高开发效率。 ... [详细]
  • 本文介绍了Redis的基础数据结构string的应用场景,并以面试的形式进行问答讲解,帮助读者更好地理解和应用Redis。同时,描述了一位面试者的心理状态和面试官的行为。 ... [详细]
  • t-io 2.0.0发布-法网天眼第一版的回顾和更新说明
    本文回顾了t-io 1.x版本的工程结构和性能数据,并介绍了t-io在码云上的成绩和用户反馈。同时,还提到了@openSeLi同学发布的t-io 30W长连接并发压力测试报告。最后,详细介绍了t-io 2.0.0版本的更新内容,包括更简洁的使用方式和内置的httpsession功能。 ... [详细]
  • eclipse学习(第三章:ssh中的Hibernate)——11.Hibernate的缓存(2级缓存,get和load)
    本文介绍了eclipse学习中的第三章内容,主要讲解了ssh中的Hibernate的缓存,包括2级缓存和get方法、load方法的区别。文章还涉及了项目实践和相关知识点的讲解。 ... [详细]
  • 显卡驱动对游戏的影响及其提升效果的研究
    本文研究了显卡驱动对游戏体验的提升效果,通过比较新旧驱动加持下的RTX 2080Ti显卡在游戏体验上的差异。测试平台选择了i9-9900K处理器和索泰RTX 2080Ti玩家力量至尊显卡,以保证数据的准确性。研究结果表明,显卡驱动的更新确实能够带来近乎50%的性能提升,对于提升游戏体验具有重要意义。 ... [详细]
  • 图解redis的持久化存储机制RDB和AOF的原理和优缺点
    本文通过图解的方式介绍了redis的持久化存储机制RDB和AOF的原理和优缺点。RDB是将redis内存中的数据保存为快照文件,恢复速度较快但不支持拉链式快照。AOF是将操作日志保存到磁盘,实时存储数据但恢复速度较慢。文章详细分析了两种机制的优缺点,帮助读者更好地理解redis的持久化存储策略。 ... [详细]
  • JVM 学习总结(三)——对象存活判定算法的两种实现
    本文介绍了垃圾收集器在回收堆内存前确定对象存活的两种算法:引用计数算法和可达性分析算法。引用计数算法通过计数器判定对象是否存活,虽然简单高效,但无法解决循环引用的问题;可达性分析算法通过判断对象是否可达来确定存活对象,是主流的Java虚拟机内存管理算法。 ... [详细]
  • 计算机存储系统的层次结构及其优势
    本文介绍了计算机存储系统的层次结构,包括高速缓存、主存储器和辅助存储器三个层次。通过分层存储数据可以提高程序的执行效率。计算机存储系统的层次结构将各种不同存储容量、存取速度和价格的存储器有机组合成整体,形成可寻址存储空间比主存储器空间大得多的存储整体。由于辅助存储器容量大、价格低,使得整体存储系统的平均价格降低。同时,高速缓存的存取速度可以和CPU的工作速度相匹配,进一步提高程序执行效率。 ... [详细]
  • 本文介绍了在Oracle数据库中创建序列时如何选择cache或nocache参数。cache参数可以提高序列的存取速度,但可能会导致序列丢失;nocache参数可以避免序列丢失,但在高并发访问时可能导致性能问题。文章详细解释了两者的区别和使用场景。 ... [详细]
  • 在重复造轮子的情况下用ProxyServlet反向代理来减少工作量
    像不少公司内部不同团队都会自己研发自己工具产品,当各个产品逐渐成熟,到达了一定的发展瓶颈,同时每个产品都有着自己的入口,用户 ... [详细]
  • 开发笔记:计网局域网:NAT 是如何工作的?
    篇首语:本文由编程笔记#小编为大家整理,主要介绍了计网-局域网:NAT是如何工作的?相关的知识,希望对你有一定的参考价值。 ... [详细]
  • 达人评测 酷睿i5 12450h和锐龙r7 5800h选哪个好 i512450h和r75800h对比
    本文介绍了达人评测酷睿i5 12450h和锐龙r7 5800h选哪个好的相关知识,包括两者的基本配置和重要考虑点。希望对你在选择时提供一定的参考价值。 ... [详细]
  • Java中包装类的设计原因以及操作方法
    本文主要介绍了Java中设计包装类的原因以及操作方法。在Java中,除了对象类型,还有八大基本类型,为了将基本类型转换成对象,Java引入了包装类。文章通过介绍包装类的定义和实现,解答了为什么需要包装类的问题,并提供了简单易用的操作方法。通过本文的学习,读者可以更好地理解和应用Java中的包装类。 ... [详细]
author-avatar
琳宝灬幸福
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有