Retrofit 2 — Analyze Cache Files

In a previous tutorial you've learned how you can activate Retrofit's response caching. In this tutorial we'll explore how you access the cache files and use them to analyze the app's network and cache behavior. This can be very helpful during the development phase.

Retrofit Series Overview

  1. Callbacks (Coming soon)
  2. Annotations (Coming soon)
  3. Fluent Interface with Builders (Coming soon)

Access Cache Files

Before you can analyze the cache files you need to find them. Where Retrofit, or more specifically OkHttp, stores the cache files depends on the configuration. We recommended using Android's getCacheDir() method to set the app's private cache directory:

Cache cache = new Cache(getCacheDir(), cacheSize);

OkHttpClient okHttpClient = new OkHttpClient.Builder()  
        .addNetworkInterceptor(new StethoInterceptor())
        .cache(cache)
        .build();

If you also used this directory, you can access the cache files at: /data/data/<your application package>/cache. You could access this directory via the Android Device Monitor, which you can find in Android Studio under Tools > Android > Android Device Monitor.

Cache Files

You can pull the files for further analyses from the device or emulator using the Android Device Monitor. Of course, any other file explorer would work too. In the next step, we'll take a closer look at those files.

Analyze Cache Files

In the image above you saw five files. One of them is a journal file, which as the name suggests, keeps a record of all cache writes and reads. Let's open the file.

Journal File

A short sample journal file could have the following content:

libcore.io.DiskLruCache  
1  
201105  
2

DIRTY b28f3c89d9bd032214753775f500a9fc  
CLEAN b28f3c89d9bd032214753775f500a9fc 4055 10279  
DIRTY 9b6ee83a44cd510ae380a839a143c702  
CLEAN 9b6ee83a44cd510ae380a839a143c702 5310 4841  
READ 9b6ee83a44cd510ae380a839a143c702  

The first four lines are merely information for OkHttp. The last five lines are the relevant ones for us. DIRTY indicates the process of starting to write a response to the cache. When this is completed, we'll see a second line CLEAN with the same key.

Speaking of the key, which is b28f3c89d9bd032214753775f500a9fc for the first two lines, this is a hash of the request URL. Thus, every request URL will be only once in the cache, which makes sense. The two numbers at the end (4055 and 10279) are the file sizes for the meta data and the actual response payload. We'll examine those files in the next section.

As you can guess, a READ indicates when the cache object is being accessed by Retrofit. Of course, for real-world apps this list can get pretty long.

Meta Data File .0

If you take a second look at the cache file directory, you'll see that each request URL hash has two files, one ending with .0 and one ending with .1. The first one, ending in .0, is storing meta data about the request. This includes all response headers and more:

https://gist.githubusercontent.com/planetoftheweb/98f35786733c8cccf81e/raw/f3dad774ed1fe20b36011b1261bb392ee759b867/data.json  
GET  
1  
Accept-Encoding: gzip  
HTTP/1.1 200 OK  
26  
Content-Security-Policy: default-src 'none'; style-src 'unsafe-inline'  
Strict-Transport-Security: max-age=31536000  
X-Content-Type-Options: nosniff  
X-Frame-Options: deny  
X-XSS-Protection: 1; mode=block  
Content-Type: text/plain; charset=utf-8  
X-Geo-Block-List:  
X-GitHub-Request-Id: 673A:61ED:26EA810:28611A2:58E3C402  
Content-Length: 4841  
Accept-Ranges: bytes  
Connection: keep-alive  
Date: Tue, 04 Apr 2017 16:11:38 GMT  
Via: 1.1 varnish  
Cache-Control: max-age=300  
ETag: "5a481bf446bd7513cbd73953d22895365c606d56"  
X-Served-By: cache-hhn1542-HHN  
X-Cache: MISS  
X-Cache-Hits: 0  
X-Timer: S1491322298.525447,VS0,VE111  
Vary: Authorization,Accept-Encoding  
Access-Control-Allow-Origin: *  
X-Fastly-Request-ID: 1750b5c4ea8ff0857e4ca9ae07dea98bf9f639da  
Expires: Tue, 04 Apr 2017 16:16:38 GMT  
Source-Age: 0  
OkHttp-Sent-Millis: 1491322298244  
OkHttp-Received-Millis: 1491322298382

…

Response Payload File .1

The actual response payload is stored in the file, which combines the request URL hash with a .1. You might need to change the file ending depending on the payload. For example, a loaded image could need the file ending .png to open the suitable application with the correct encoding. When you can't seem to figure out the payload encoding, you can check the meta data file: the Content-Type the server hopefully sent you gives you an excellent indication.

Summary

In this tutorial you've learned how you can access the cache files OkHttp and Retrofit will create once you have activated caching. You've also seen how to get more information out of these files.

Do you have further questions on this topic or about Retrofit in general? Just let us know on Twitter @futurestud_io or leave a comment below.

Enjoy coding & make it rock!

Explore the Library

Find interesting tutorials and solutions for your problems.

Miscellaneous