是什么让改造比HttpUrlConnection + AsyncTask更快？

Question

以下blog比较了各种Android Async Http客户端的速度。有人可以解释是什么让改造变得如此荒谬可笑吗？

Answer 1

编辑：再次浏览博客文章后，单对多线程问题可能不正确。问题是他们没有分享他们的分析/基准测试的血腥细节;这组数字并没有提供太多的见解。他们表示，“我们确定从API（网络）检索数据是瓶颈”，但他们并没有打破这一点。他们是否将所有的Volley和Retrofit请求都用于单线程？他们是否尝试多线程化他们的AsyncTask，以便他们可以比较苹果和苹果？他们没有指定。

如果将响应解析为JSONObject会降低您的应用程序速度，我采用的一种方法是使用JSONReader以事件驱动的方式解析响应。这可能涉及更多代码，但好处是您可以获得细粒度控制，因此您可以跳过事物而不是浪费周期来解析您不关心的值。根据您的应用程序，仅这一点就可以加快速度。

就我个人而言，我发现他们声称Retrofit 更容易使用是一个更有说服力的理由选择它来处理我的应用程序中的服务器访问。

来自“执行令”下的AsyncTask文件：

  

首次引入时，AsyncTasks在单个后台线程上串行执行。从DONUT开始，这被更改为一个线程池，允许多个任务并行运行。从HONEYCOMB开始，任务在单个线程上执行，以避免由并行执行引起的常见应用程序错误。

     

如果您真的想要并行执行，可以使用executeOnExecutor(java.util.concurrent.Executor, Object[])调用THREAD_POOL_EXECUTOR。

这意味着每个请求不仅要等待先前的请求完成，还要等待所有JSON的读取/解析。

而AsyncTask默认是单线程的，而Retrofit则不是。为了使测试公平，他们应该使用ThreadPoolExecutor来AsyncTask。没有指出这种区别是不诚实的。我很惊讶他们不知道AsyncTask的单线程特性。