2

I have an activity that measures how long does animate/layout/measure/etc of layout takes. 

class RenderingMeasureActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.skeleton)

        val view = layoutInflater.inflate(R.layout.simple, root, false)
        root.postDelayed({
            root.addView(view)
        }, 5000)
    }
}

Skeleton layout is nothing but FrameLayout with match_parent and id root. Simple layout is just:

<FrameLayout
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <TextView
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_gravity="center"
        android:text="ahoj"
        android:textSize="32sp" />

</FrameLayout>

In the activity, I have delayed addView() so I am sure I am measuring just that and no other influence is there.

Now, whatever I do, the measurements are off the charts. It takes at least 17ms (average more like 25ms) which is definite source of JANK (>16.7ms). Longest duration is Command Issue and I get same results from FrameMetrics, gpu profiling bars and similar duration also from systrace.

What am I doing wrong? Is it possible that addView (or inflate) of any layout is so expensive that Android SDK apps will always have JANK? Why, if the same layout (merged into one) is set in setContentView(), it takes less time (not by much though)?

P.S.: I tried other layouts, such as constraint, linear, relative. Merge tag helps a little, but is not always usable.
P.P.S.: Creating layout programmatically has no effect as I have separated inflating part.

Majkeee
  • 960
  • 1
  • 8
  • 28
  • so your problem is that `LayoutInflater` takes too much time? and UI thread freezes? – pskink Apr 28 '19 at 10:50
  • @pskink no, `LayoutInflater` is separate process. I care about `addView`. It is not really a problem, I am just curious if it's normal, that any dynamically added view causes jank. And if not, then what is problem with the code. – Majkeee Apr 28 '19 at 10:56
  • it depends on what you are adding: if it is just a `View` (like `ImageView` or `TextView`) it should be light fast, but if it is a `ViewGroup` (like any layout) it may need complex measure/layout phases – pskink Apr 28 '19 at 11:01
  • @pskink Alright thanks, that does make sense, though I am just surprised it is so much. As you can see in question, it is just one FrameLayout (one layout pass) with one TextView child. So I would guess it should be definitely less than 16ms. – Majkeee Apr 28 '19 at 11:06
  • hmmm, i agree `FrameLayout`'s measurement / layout code should be much faster than `RelativeLayout` / `ConstraintLayout` - how exactly do you get those ms numbers? – pskink Apr 28 '19 at 11:08
  • @pskink Developer options > profile rendering gpu as bars. It is always above 16ms line. For precise numbers I use `FrameMetrics` https://developer.android.com/reference/android/view/FrameMetrics It is actually much faster then Relative/Constraint, I am more concerned about the duration itself then comparison between types of ViewGroup. – Majkeee Apr 28 '19 at 11:23

0 Answers0