CODEWITHSUNDEEP
androidfontsandroid-appcompat
ccpizza
ccpizza

Reputation: 31801

Android font assets vs font resources (API 26)

In order to use custom fonts in an android app there seem to be two approaches:

  1. Classic way: place TTF or OTF files in the /assets/fonts directory and then build a Typeface with Typeface.createFromAsset(getAssets(), "fonts/custom.ttf").
  2. Natively since API 26, or with AppCompat since API 16: create an XML font family by placing lowercased TTF/OTF files in res/font folder and then reference them directly in XML layouts with android:fontFamily="@font/custom", or access them programatically with ResourcesCompat.getFont(this, R.font.custom).

What are the key differences to keep in mind between font resources and assets?

Specifically, are they rendered in the same way, and is any of them faster or more efficient in terms of performance?

Can it be assumed that font resources are only suitable for fonts that come pre-packaged in the APK, while font assets are more flexible since you can create a Typeface from an arbitrary file inside or outside the APK?

Update: After a bit of experimentation it looks like font resources are the only way to set custom fonts in AppWidget TextViews without having to manually paint them as bitmaps but that requires the device to actually run API 26 (using the Support Library does not help in this specific case).

Upvotes: 6

Views: 2415

Answers (1)

Eugen Pechanec
Eugen Pechanec

Reputation: 38243

Specifically, are they rendered in the same way, and is any of them faster or more efficient in terms of performance?

ResourcesCompat.getFont works like this:

  1. Check in-memory cache if we already resolved a font resource ID to Typeface. If we have a hit, we're done.
  2. Copy the resource to a disk file.
  3. Create Typeface from the file using Typerface.createFromFile and cache it.

That's true for fonts bundled in the APK. I won't go into how downloadable fonts work. You can explore that in the docs or in the source.

Both approaches work the same. They create a Typeface object from a source.

One key difference: If you're directly using Typeface API, you're responsible for caching. You don't want to load the same font multiple times because each Typeface instance takes up loads of memory.

Historically, I was using this code from Calligraphy to take care of caching when loading typefaces from assets.

After a bit of experimentation it looks like font resources are the only way to set custom fonts in AppWidget TextViews [...]

Looks like you're right. Notifications and widgets (anything that uses RemoteViews) can only use natively available resources and attributes on views.

See also: How to use a custom typeface in a widget?

Upvotes: 7

Related Questions