Blocking operations are those operations that force the app to wait for a result before being able to move on to the next operation. Executing a blocking operation on the UI thread will force the UI to freeze, and this will produce a bad user experience.
After we have enabled StrictMode
, we start receiving unpleasant messages about how our app is doing badly on disk I/O:
D/StrictMode﹕ StrictMode policy violation; ~duration=998 ms: android.os.StrictMode$StrictModeDiskReadViolation: policy=31 violation=2 at android.os.StrictMode$AndroidBlockGuardPolicy.onReadFromDisk (StrictMode.java:1135) at libcore.io.BlockGuardOs.open(BlockGuardOs.java:106) at libcore.io.IoBridge.open(IoBridge.java:393) at java.io.FileOutputStream.<init>(FileOutputStream.java:88) at android.app.ContextImpl.openFileOutput(ContextImpl.java:918) at android.content.ContextWrapper.openFileOutput(ContextWrapper. java:185) at com.packtpub.apps.rxjava_essentials.Utils.storeBitmap (Utils.java:30)
The previous message is telling us that our Utils.storeBitmap()
function is taking 998
ms to complete: that's 1 second of unnecessary work on our UI thread and 1 second of unnecessary slowness of our app. This is happening because we are accessing the disk in a blocking way. Our storeBitmap()
function contains:
FileOutputStream fOut = context.openFileOutput(filename, Context.MODE_PRIVATE);
This is a direct access to the smartphone's solid memory and it's slow. How can we improve this? The storeBitmap()
function saves the installed app icon. It returns void
, so there is no reason to wait until it completes before executing the next operation. We could just launch it and let it execute on a different thread. Thread management in Android has changed during the years and this has led to weird app behaviors. We could use AsyncTask
, but we saved ourselves from that onPre… onPost… doInBackGround
hell a few chapters ago. We are going to do it the RxJava way; long live the Schedulers!
3.21.248.162