okio和okhttp为什么比Java io以及HttpClient/HttpUrlConnection好？

    答案在这里：https://www.youtube.com/watch?v=WvyScM_S88c

    大概总结一下，主要有以下几点：

    • Java IO类被设计为decoration模式的，但是缓存逻辑却可能同时在多个decoration层级中存在，这属于历史问题，而okio作为一个新的项目完全可以避免这样的问题；
    • Java IO使用起来不方便，如果我们使用Java IO提供给我们的封装类，能够某种程度上缓解这个问题，但是很多时候我们想要使用的是一个“万能”的封装类，而Java IO却利用decoration模式，将不同的功能分散在了不同的封装类中，比如DataInputStream，以及ReaderInputStream，如果我们想要同时使用这两个类提供的接口，就非常尴尬了，因此okio提供了两个完全通用的上层类：BufferedSink和BufferedSource，提供了开发者在文件读写时需要的一切接口；
    • Java IO，以及nio，共同提供了一套高效的io接口（android里nio很少用，App很少真的需要考虑多路IO复用这种事情，Framework层面倒是用了不少多路io复用，但他们都是直接用C的epoll和select去了），okio在提供了更加易用的接口的同时，实现层面也做了精细的内存复用优化，通过精心设计的接口和实现，将不必要的内存拷贝尽可能减少，业务使用由这些库提供的接口，而不是jdk的io、nio接口，不仅能够获得更易用的接口，也能够更轻松获得良好的效率；如果不使用okio，你可能会发现自己经常分配一些临时的内存空间，久而久之你会希望对这样的代码进行重构，通过对内存块进行一定程度的抽象，尽可能的减少临时内存空间的分配，增加内存利用率，这时候你会发现自己开始重新实现okio了。

    如果只是做benchmark，会发现Java IO和nio在时间上效率几乎没差多少，这是因为nio本来也是基于Java IO接口实现的，而且android的jdk实现也在不断改进，真正让我们选择okio的，是接口的易用性加上良好的效率，总体上而言在降低开发成本的同时又能获得优化后的效率。如果有业务场景只是想读出整个文件内容存到内存中，然后作为纹理上传到GPU，那还是直接使用最底层的Java IO更合适些，okio所提供的接口以及所做的内存优化在这种场景完全帮不上忙，还可能会存在少许负优化。