Question

I like to use the assets folder instead of the drawable folder (if it’s not a nine-patch) because I can use multiple folders there. However the method I use to get an drawable required the cpu to do quiet a lot. For example: after adding 10 ImageViews need 10% CPU (I am using Android Assistent and Samsung TouchWiz TaskManager). I haven’t notice it while I was writing a game. And now this game needs 40-100% CPU even if it isn’t in the foreground.

That’s the method I use to create an drawable:

public BitmapDrawable readAsset(path){
    try{

        inputStream = assetManager.open(path);
        //get the Bitmap
        desiredImg = BitmapFactory.decodeStream(inputStream, null, opts);
        //resize for other screen sizes (scale is calculated beforehand)
        scaleX =(int)(desiredImg.getWidth()/scale);
        scaleY = (int)(desiredImg.getHeight()/scale);

        //Bitmap to get config ARGB_8888 (createScaledBitmap returns RGB_565 => bad quality especially in gradients)
        //create empty bitmap with Config.ARGB_8888 with the needed size for drawable
        Bitmap temp = Bitmap.createBitmap(scaleX, scaleY, Config.ARGB_8888);
        //Canvas to draw desiredImg on temp
        Canvas canvas = new Canvas(temp);
        canvas.drawBitmap(convert, null, new Rect(0, 0, scaleX, scaleY), paint);

        //Convert to BitmapDrawable
        BitmapDrawable bitmapDrawable=new BitmapDrawable(temp);
        bitmapDrawable.setTargetDensity(metrics);

        inputStream.close();
        return bitmapDrawable;
    }catch (Exception e) {
        Log.d(TAG, "InputStream failed: "+e.getMessage());
    }
    return null;
}

The only thing I do in the app is adding some ImageViews in a RelativeLayout with this method:

private void addImageToContainer(int paddingLeft, int paddingTop) {
    ImageView imageView = new ImageView(this);
    imageView.setImageDrawable(assetReader.readAsset("test.jpg"));
    imageView.setPadding(paddingLeft, paddingTop, 0, 0);
    container.addView(imageView);
}

Answer 1

Probably the best thing for you to do would be to profile the execution with traceview, as this will give you a full understanding of where your app is spending most of its execution time. Then you can focus on optimizing that specific piece of code.

Just an educated guess, but I have a feeling that the majority of the wasted execution is not because you are pulling the images out of assets/ instead of resources, but all the scaling work being done afterwards (and from the looks of it, this is all being done on the main thread, so there’s no concurrency to speak of).

I might recommend trying to leverage some of the BitmapFactory.Options (Docs link) available to you when you decode the asset. In particular, you should be able to do all the scaling you need with a combination of the inScaled, inDensity, and inTargetDensity options. If you pass these to your decodeStream() method, you could likely remove all the subsequent code used to resize the image before returning.