Introduction

Getting the width and height of an ImageView in Android is a common task for dynamic layouts, image scaling, and animations. The challenge is that view dimensions are not available until Android completes its measure and layout passes. Calling getWidth() or getHeight() too early, such as in onCreate() or onCreateView(), returns zero. This article covers the correct timing and APIs for reliably retrieving view dimensions.

Why Dimensions Are Zero in onCreate

Android views go through three phases before they appear on screen: measure, layout, and draw. In onCreate(), none of these phases have completed, so every view reports a width and height of zero.

1override fun onCreate(savedInstanceState: Bundle?) {
2    super.onCreate(savedInstanceState)
3    setContentView(R.layout.activity_main)
4
5    val imageView = findViewById<ImageView>(R.id.myImage)
6    // Both return 0 because layout has not happened yet
7    Log.d("Size", "width=${imageView.width}, height=${imageView.height}")
8}

This behavior is consistent across all view types, not just ImageView. You need to defer the measurement until after the layout pass completes.

Using View.post

The simplest approach is View.post(), which queues a Runnable on the view's message queue. By the time it executes, the view has been measured and laid out.

1imageView.post {
2    val width = imageView.width
3    val height = imageView.height
4    Log.d("Size", "width=$width, height=$height")
5}

This works reliably in most cases. The Runnable executes after the current layout pass, so dimensions are available. However, if the view is not yet attached to the window, post may not execute.

Using doOnLayout (AndroidX)

The AndroidX Core KTX library provides doOnLayout, which is a more explicit and reliable callback. It fires exactly once after the next layout pass.

1import androidx.core.view.doOnLayout
2
3imageView.doOnLayout { view ->
4    val width = view.width
5    val height = view.height
6    Log.d("Size", "width=$width, height=$height")
7}

If the view has already been laid out, doOnLayout fires immediately. This eliminates a common race condition where the callback is registered after layout has already completed.

For cases where you need to react to every layout change (for example, during animations or orientation changes), use addOnLayoutChangeListener instead.

1imageView.addOnLayoutChangeListener { view, left, top, right, bottom,
2    oldLeft, oldTop, oldRight, oldBottom ->
3    val width = right - left
4    val height = bottom - top
5    Log.d("Size", "width=$width, height=$height")
6}

Using ViewTreeObserver

Before AndroidX KTX, the standard approach was ViewTreeObserver.OnGlobalLayoutListener. This fires when the global layout state changes.

1imageView.viewTreeObserver.addOnGlobalLayoutListener(
2    object : ViewTreeObserver.OnGlobalLayoutListener {
3        override fun onGlobalLayout() {
4            // Remove listener to avoid repeated calls
5            imageView.viewTreeObserver.removeOnGlobalLayoutListener(this)
6
7            val width = imageView.width
8            val height = imageView.height
9            Log.d("Size", "width=$width, height=$height")
10        }
11    }
12)

This approach works in Java projects or when AndroidX KTX is not available. Always remove the listener after the first invocation to prevent it from firing on every layout change, which wastes CPU and can cause infinite loops if the callback itself triggers a layout.

View Size vs Intrinsic Image Size

There is an important distinction between the ImageView dimensions and the underlying image dimensions. The ImageView size depends on layout parameters (match_parent, wrap_content, fixed dp), while the intrinsic size is the actual pixel dimensions of the image resource or downloaded bitmap.

1imageView.doOnLayout {
2    // View size (how much space it occupies in the layout)
3    val viewWidth = imageView.width
4    val viewHeight = imageView.height
5
6    // Intrinsic image size (original image dimensions)
7    val drawable = imageView.drawable
8    val imageWidth = drawable?.intrinsicWidth ?: 0
9    val imageHeight = drawable?.intrinsicHeight ?: 0
10
11    Log.d("Size", "View: ${viewWidth}x${viewHeight}")
12    Log.d("Size", "Image: ${imageWidth}x${imageHeight}")
13}

For a 1920x1080 image displayed in a 200x200 dp ImageView, the view dimensions reflect the layout size while the intrinsic dimensions report the original image resolution. The scaleType attribute (centerCrop, fitCenter, etc.) controls how the image maps into the view bounds but does not change either measurement.

Getting Dimensions in Java

The same approaches work in Java with slightly different syntax.

1imageView.post(new Runnable() {
2    @Override
3    public void run() {
4        int width = imageView.getWidth();
5        int height = imageView.getHeight();
6        Log.d("Size", "width=" + width + ", height=" + height);
7    }
8});

For the ViewTreeObserver approach in Java, the pattern is identical to the Kotlin version shown above, using an anonymous inner class.

Handling Dynamic Image Loading

When loading images asynchronously with libraries like Glide or Coil, the ImageView may have dimensions from the layout pass, but the drawable might not be set yet.

1Glide.with(this)
2    .load(imageUrl)
3    .into(object : CustomTarget<Drawable>() {
4        override fun onResourceReady(
5            resource: Drawable,
6            transition: Transition<in Drawable>?
7        ) {
8            imageView.setImageDrawable(resource)
9            val imgW = resource.intrinsicWidth
10            val imgH = resource.intrinsicHeight
11            Log.d("Size", "Loaded image: ${imgW}x${imgH}")
12        }
13
14        override fun onLoadCleared(placeholder: Drawable?) {}
15    })

Using CustomTarget (Glide) or an image request listener (Coil) gives you access to the drawable dimensions at the moment the image is ready.

Common Pitfalls

• Reading width/height in onCreate or onCreateView always returns zero because the measure and layout passes have not run yet.
• Forgetting to remove the OnGlobalLayoutListener causes the callback to fire on every layout change, leading to performance issues or infinite layout loops.
• Confusing view size with image intrinsic size leads to incorrect scaling calculations; the view size comes from layout params while intrinsic size is the original image resolution.
• Using View.post on a detached view means the runnable may never execute; prefer doOnLayout which handles this case by firing immediately if layout already happened.
• Not accounting for padding and margins when calculating usable image area; use imageView.paddingLeft, paddingRight, etc., to get the actual content area within the view bounds.

Summary

• View dimensions are only available after the measure and layout passes; never read them in onCreate().
• Use doOnLayout from AndroidX Core KTX as the preferred one-shot callback for getting dimensions after layout.
• Use View.post as a simpler alternative that works in most cases by deferring execution until after the current layout pass.
• Distinguish between view dimensions (getWidth()/getHeight()) and image dimensions (drawable.intrinsicWidth/intrinsicHeight) for correct scaling logic.
• Always remove ViewTreeObserver.OnGlobalLayoutListener after first use to prevent repeated and unnecessary callback invocations.