Speed Inflate Those Custom Views

There are two areas of application initialization that your android application user percieves; the application class initialization itself and the first activity initialization. With the application initialization you have de-encyrpting 3rd party api keys, any dagger initialization, any sharedprefs creation or access, etc and thus the first activity initialization should be faster than the application initialization.

But, with your cool android application you may have one or more custom views. And if you allow the system to inflate that view it will fallback to using reflection in the PhoneLayoutInflater class to inflate that view. You do not want that as you want the fast inflation that rest of the system does for its named views and widgets.

I am going to show you how to create and LayoutInflaterFactory that inflates some named custom views and how to use it in your activity.


In the View class lifecycle, if called for the first time it uses the constructor with no attributes, theme or style. If the Android Framework did not specify a View to inflate via its chain of LayoutInflaters than the last LayoutInflater in that chain will use reflection to find the View class and use its constructor to initialize the View.

But, since its YOUR custom view you want to initialize it with the layout parameters and attributes and any styles or themes that you have created. So to load that custom view we are going to create a custom LayoutInflaterFactory to load all your custom views.


So let’s explain the code. First, obviously this code is meant for non-suport native fragments.

Second, in the Android Framework fragment world we have two constructors to handle when we want to call our InflaterFactory the AppCompatActivity(FragmentActivity) onCreate method and the child Fragment’s onCreateView method.

Third, the support library already sets a layoutinflater so as to enable tinting so we are cloning the layoutinflater in AppCompatActivity so that we can set our own LayoutInflaterFactory.

Okay, its a bit complicated but the AppCompatActivity over-ridden methods getLayoutInflater and getSystemService allow us to when the method call of

LayoutInflaterCompat.setFactory(layoutInflater, new NoReflectionLayoutInflaterFactory()) is made set our own LayoutInflater factory as the system inflaterfactory rather than the default one and because of the way the support library injects inflaters we still get the full tinting support for the support library as a bonus.

On purpose I have left out the Dagger2 example as to get to the point of your own custom view constructors to pass activity-scoped component directly without manual getters and setters you have to do a trade-off of allowing some use of reflection to get the goal of no manual getters and setters and our purpose with this article is to avoid reflection.


With a little knowledge of how the support library is injecting a layoutinflater we can set up our own layout inflater factory to inflate our custom views to avoid a reflection performance hit during activity initialization. This comes in handy when you you have one or more custom views implemented.