How did NetEase Cloud Music and Mobile QQ change their skins?

Android theme skinning can provide skin packages as plug-ins, and can achieve seamless switching without restarting the Activity. It can highly imitate the theme skinning of NetEase Cloud Music.

This link is the sample SkinChangeDemo packaged from this Demo. You can download it and try the effect first. The skin file needs to be placed in the root directory of the memory card.

Changing the theme of Android is a commonplace issue. There are endless solutions on the Internet. Recently, I also want to learn more about this aspect, so I searched and found a lot of articles introducing this aspect, but the final results are not satisfactory. Some of them do provide some better solutions, but there is no substantial demo to refer to, so it can only be paper talk. Some of them do provide a reference demo, but the final result is not what I want. Regarding the summary of Android skin-changing solution technology, this article is still a very valuable reference summary of Android skin-changing technology. Interested students can go and learn about it, just as a knowledge popularization.

The skin-changing solution I am going to implement today is based on the open source framework Android-Skin-Loader on GitHub.

The skinning mechanism of this framework uses a dynamic loading mechanism to load the contents of the skin package. The skin can be changed in real time without restarting the Acitvity. The skin package can be separated from the original installation package and needs to be customized (this skin package is actually an ordinary Android project, but it only has resource files but no class files). The advantage of this is that the skin package can be provided online for users to download, which can also greatly reduce the size of the installation package, and also realize the plug-in very well. In fact, this framework can be used directly. Just a few lines of code can basically solve the Android theme skinning, but as a programmer, how can you just know how to use it? If so, it's really too low. When we encounter a good open source project, we at least need to take a general look at its source code, go through the basic process, and understand its basic principles, so that we can improve our technology. The Demo implemented in this article is based on the Demo in the article "Detailed Explanation of the Use of Android Material Design Compatible Library" that I released some time ago. The final App is also designed in the MaterialDesign style.

Well, having said so much, what can you learn from this article? This may be a point of concern to everyone.

• Design an App based on Material Design style
• Implement a theme skinning framework yourself
• A high imitation of NetEase Cloud Music's theme skin (ps: Actually, I wanted to use this as the title, which can also increase traffic, but I don't want to be a mere title party. Bringing useful information to everyone is the most important thing)
• Take your technology to the next level (it’s useless to say this)

After talking for so long, some people may be impatient: I am here to see the practical stuff, not to listen to your nonsense. Don't worry, the practical stuff will come soon. If you feel it is really boring, you can jump to the end of the article to see the source code. Here are a few effect pictures to refresh yourself

This is the skin-changing interface of NetEase Cloud Music. It provides several default themes and themes that can be downloaded online. Its switching effect is still very good. Students who have used this software must know it. After studying this article, you can make a similar skin-changing effect.

This dynamic image is the final effect of our demo. This demo is generally simple and only provides three skins. It achieves a basic skin-changing effect and is mainly used for learning. Of course, more complex skin-changing can be achieved based on this demo. Here we mainly explain the principle.

Before introducing it, we need to popularize the knowledge related to LayoutInflaterFactory. If you already know this knowledge point, you can skip the following paragraph directly.

You may be familiar with LayoutInflater. You must use it when you need to convert an XML file into a corresponding View. I think I don't need to introduce how to use it. LayoutInflater provides two methods, setFactory(LayoutInflater.Factory factory) and setFactory2(LayoutInflater.Factory2 factory), which allow you to customize the layout filling (a bit like a filter, we can do some extra things before filling the View, but not completely). Factory2 was added in API 11. They provide the following method for you to override. In it, you can completely define and create the View you want. If you return null in the overridden method, the View will be created in the system default way.

 View onCreateView(String name , Context context, AttributeSet attrs)//LayoutInflater.Factory
 View onCreateView( View parent, String name , Context context, AttributeSet attrs)//LayoutInflater.Factory2

LayoutInflater is set with a default Factory, and Activity implements the LayoutInflater.Factory interface, so you can customize the View filling by directly overriding onCreateView in your Activity.

The following sentence is a better understanding of LayoutInflater.Factory

• Inflating your own custom views, instead of letting the system do it

This is also one of the more important technical points of this demo. If you want to know more details, there will be a reference link at the end of the article.

Now let’s officially start to introduce how to change the theme.

Let's take a look at the project structure of this Demo:

As for xRecyclerView, you can ignore it. We don't need it here (it was used before and has nothing to do with this time). It is just an extension framework of RecyclerView, which supports pull-down refresh and pull-up loading. It is an open source project on github.

Let's take a look at the lib_skinloader library here (most of the content here comes from the Android-Skin-Loader framework. I only made some modifications, mainly to adapt to AppCompatActivity. The original framework was developed based on the original Activty. Thanks to the open source author again). This library is the core content of today's talk.

We all know that in Android, if we want to get resource files, we must get them through Resources. The core idea of ​​this library is to dynamically load the package in the third-party package, get its Resources, and then use the obtained Resources to get the resource content in the third-party package, and finally set it to the View that needs to respond to the skin change.

Here I will only introduce the load and base packages. The contents of other packages will be covered in the explanation.

1.load package

Let’s first take a look at the contents of this load package (in fact, this is the core of today’s core content).

There are two class files: SkinInflaterFactory, SkinManager

Let's first look at the implementation of SkinManager and jump directly to the load method

 public void load (String skinPackagePath, final ILoaderListener callback) {
 new AsyncTask<String, Void, Resources>() {
 protected void onPreExecute() {
 if (callback != null ) {
 callback.onStart();
 }
 }
 @Override
 protected Resources doInBackground(String... params) {
 try {
 if (params.length == 1) {
 String skinPkgPath = params[0];
 Log.i( "loadSkin" , skinPkgPath);
 File file = new File(skinPkgPath);
 if (file == null || !file.exists()) {
 return   null ;
 }
 PackageManager mPm = context.getPackageManager();
 PackageInfo mInfo = mPm.getPackageArchiveInfo(skinPkgPath, PackageManager.GET_ACTIVITIES);
 skinPackageName = mInfo.packageName;
 AssetManager assetManager = AssetManager.class.newInstance();
 Method addAssetPath = assetManager.getClass().getMethod( "addAssetPath" , String.class);
 addAssetPath.invoke(assetManager, skinPkgPath);
 Resources superRes = context.getResources();
 Resources skinResource = new Resources(assetManager, superRes.getDisplayMetrics(), superRes.getConfiguration());
 SkinConfig.saveSkinPath(context, skinPkgPath);
 skinPath = skinPkgPath;
 isDefaultSkin = false ;
 return skinResource;
 }
 return   null ;
 } catch (Exception e) {
 e.printStackTrace();
 return   null ;
 }
 }
 protected void onPostExecute(Resources result) {
 mResources = result;
 if (mResources != null ) {
 if (callback != null ) callback.onSuccess();
 notifySkinUpdate();
 } else {
 isDefaultSkin = true ;
 if (callback != null ) callback.onFailed();
 }
 }
 } .execute (skinPackagePath);
 }

This method has two parameters, the first is the path to the skin package, and the second is a simple callback

The doInBackground method dynamically obtains the Resources of the skin package. After the acquisition is successful, the Resources are assigned to the defined variables in the onPostExecute method to facilitate our subsequent use. Note that when the obtained Resources is not empty, that is, we have obtained the resources in the skin package, we call the notifySkinUpdate() method to notify the interface to change the skin. If it is empty, the default skin will still be used.

Let's take a look at the implementation of notifySkinUpdate()

It is very simple here, just traverse the mSkinObservers collection and then notify the update. ISkinUpdate is an interface, and each Activity that needs skin update needs to implement this interface.

The SkinManager class also contains methods such as getColor(int resId) and getDrawable(int resId), which are used to obtain the resource files corresponding to the third-party package. It is worth noting that if there is no corresponding resource file in your third-party package, the default resource file will be used. If you have needs, you can add some methods like getMipmap(int resID).

Oh, there is another important method that I forgot to mention.

This method is to restore the system's default theme. The principle is similar to load, and the implementation is much simpler. That's all I have to say about the SkinManager class. Please check the source code for detailed implementation. I have commented on many places.

Let's take a look at SkinInflaterFactory, which mainly does some work related to filling Views. I implemented the LayoutInflaterFactory interface instead of the LayoutInflater.Factory interface mentioned earlier in the article because it needs to be compatible with AppCompatActivity. If you still use the previous one, some errors will occur. Anyway, I spent a lot of time on it when I first made it. In any case, the principle is always the same. The role of SkinInflaterFactory is to collect Views that need to respond to skin changes. Let's take a look at the implementation of onCreateView

First, we need to determine whether the current View needs to change its skin. If not, we return to the default implementation. If yes, we will handle it ourselves and see the implementation of the createView method.

It seems like a lot, but in fact, this method is to dynamically create a View.

Let's take a look at the implementation of parseSkinAttr:

This method actually collects the attributes that can be changed when changing the skin in the View. When we change the skin, we change the values ​​of these attributes. Here you must pay attention to the fact that the value of this attribute must be a reference type (for example: @color/red), and it must not be hard-coded. The second if judgment is for this purpose. At this point, you may have a question, how do I know which attributes need to be changed when changing the skin. If you are careful, you must have noticed this line of code

 SkinAttr mSkinAttr = AttrFactory.get(attrName, id, entryName, typeName);

There is an AttrFacory whose function is to dynamically create SkinAttr based on the attribute name. In AttrFacory, some constants like this are defined:

These are the attributes that can be changed when we change skins. SkinAttr is an abstract class. For example, background will create a BackgroundAttr. All the attributes used in this project are in the attr package. SkinAttr is a more flexible place. If you need to change any attribute when changing skins, you can implement a corresponding SkinAttr.

At the end of the parseSkinAttr method, we encapsulate View and SkinAttr into a SkinItem and add it to a collection. Finally, it should be noted that if the current skin is not the default skin, it must be applied. This is mainly to prevent the problem of delayed skin change when starting some new pages after changing the skin. The SkinInflaterFactory class also provides a method for dynamically adding SkinItem. The principle is similar to this, so I won't go into details.

We have almost finished talking about the two classes in the load package. If you understand the following content, it will be a piece of cake. I believe that after reading this, it will be much easier for you to read the source code.

2.base package

You can see that this package must contain the implementation of Activity, Fragment, and Application, and its function is to encapsulate some common methods and properties in it.

Let’s analyze them one by one.

SkinBaseApplication:

You can see that we have done some initialization operations on SkinManager. In the future, if we have applications that need to change skins, we must remember to inherit from SkinBaseApplication.

SkinBaseActivity Let's take a look at its onCreate method

Here we use the InflaterFactory of the custom View to replace the default Factory. Remember to call it before super.onCreate(savedInstanceState);. SkinBaseActivity also provides methods for dynamically adding Views that can respond to skin changes. Of course, any Activity that needs to respond to skin changes needs to inherit SkinBaseActivity. See the source code for detailed implementation.

SkinBaseFragment is similar to SkinBaseActivity in concept. For the specific implementation, see the source code. Here I just provide you with the idea of ​​this skinning framework to make it easier for you to read the source code.

This is the end of the introduction to this framework. Let’s see how to use it.

When using it, you must remember that Activity should inherit from SkinBaseActivity, Fragment should inherit from SkinBaseFragment, and Application should inherit from SkinBaseApplication. Of course, it is essential to use this framework as a dependency of your project. For the simplicity of the Demo, I only use the following three colors as skinnable resources. Of course, if you want to use drawable files, you can do it, provided that you understand this Demo.

Let's look at a layout file

Among them, xmlns:skin="http://schemas.android.com/android/skin" is customized by us and is available in SkinConfig. We only need to add skin:enable="true" to the View that needs to change the skin.

Let's take a look at some of the code for MainActivity

Here is the dynamic addition of the View with skin change requirements.

The above introduces how to use it in layout files and how to use it in code.

How should we change the skin? It's very simple. Just call the load method of SkinManager and pass in the skin path. For the sake of simplicity, my Demo does not have the function of online skin changing. It only provides replaceable skins locally. Seeing this, I believe you already have an idea of ​​how to change the skin online.

Finally, let's see how to develop a skin package. In fact, this is the simplest. A skin package is actually a basic Android project that does not contain class files, only resource files. Here you just need to pay attention to the resource file name here must be the same as the original project, and only include those that need to be changed when the skin is changed! For example, my demo simply switches the three colors above. Two skins, brown and black, were developed, so there are only three color values ​​in the resource file. After the development is completed, we need to package it into an apk file. To prevent users from clicking to install, we changed its suffix to skin, which is also an identification. If you are still not clear, you can directly check it in the source code.

Now let's take a look at the effect picture at the beginning of the article. Does it suddenly become more interesting? Move your little finger to tap a theme skinning framework~~~