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

What makes retrofit faster than HttpUrlConnection + AsyncTask?

下面的blog比较了各种Android异步Http客户端的速度。谁能解释一下是什么让改造如此之快?

编辑:再次浏览博客 post 后,单线程与多线程问题可能不正确。问题是他们没有分享他们 profiling/benchmarking 的血腥细节;那一组数字并不能提供太多的洞察力。他们说,“我们确定从 API(网络)检索数据是瓶颈”,但他们并没有详细说明。他们是否将所有 Volley 和 Retrofit 请求设为单线程?他们是否尝试对他们的 AsyncTask 进行多线程处理,以便他们可以同类比较?他们没有具体说明。

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

就我个人而言,我发现他们断言 Retrofit 更易于使用 作为选择它来处理我的应用程序中的服务器访问的更有说服力的理由。


来自“执行顺序”下的 AsyncTask 文档:

When first introduced, AsyncTasks were executed serially on a single background thread. Starting with DONUT, this was changed to a pool of threads allowing multiple tasks to operate in parallel. Starting with HONEYCOMB, tasks are executed on a single thread to avoid common application errors caused by parallel execution.

If you truly want parallel execution, you can invoke executeOnExecutor(java.util.concurrent.Executor, Object[]) with THREAD_POOL_EXECUTOR.

这意味着每个请求不仅在等待前一个请求完成,而且还在等待其所有 JSON 成为 read/parsed。

AsyncTask 默认是单线程的,而 Retrofit 不是。为了测试公平,他们应该使用 ThreadPoolExecutor 作为 AsyncTask。不指出这种区别是虚伪的。我很惊讶他们不知道 AsyncTask.

的单线程性质