Android skin changing technology data sorting

Android skin changing technology summary

background

Throughout the current Android apps, their skin changing needs can be classified as

-Day / night theme switching (or other names, usually 2 sets), such as Huashun / optional stocks / beautiful every day, etc. the UI is represented as a switcher- Multiple topic switching, usually member privileges, such as QQ / QQ space.

For the first, visual inspection should be done directly through the local theme, that is, all picture / color resources are packaged in APK.

For the second, it is relatively complex. As an online service, it may launch new skin, and so many skin packages take up too much volume in APK. Therefore, skin resources will be downloaded after selection, so you can't directly use the Android theme.

Technical scheme

Internal resource loading scheme and dynamic resource downloading.

Dynamic download can be called a kind of black technology. Because some methods of hack system are often required, there may be holes in some models and new APIs, but there are many relative benefits

-Since images / color values and other resources are distributed in the background, they can be updated at any time - APK volume is reduced - for application developers, skin change is almost transparent, and there is no need to care about several sets of skin - they can be sold as value-added services!!

Internal resource loading scheme

Internal resource loading is done through Android's own set of themes. Compared with business development, the workload is larger (attr and theme need to be defined). Different schemes similarly do settheme in baseactivity. The difference mainly lies in the strategies to solve the following two problems:

-How to refresh in real time after settheme without re creating the page (especially the item in listview)- Which views need to be refreshed and what to refresh (background? Font color? SRC of ImageView?).

Custom view

MultipleTheme

The custom view is made to refresh immediately after settheme and update the corresponding resources of the page UI (such as textview replacing the background image and text color). In the above project, it is realized by traversing the rootview and settheme operation on all view / viewgroups that implement coloruiinterface.

Obviously, this is too heavy. You need to replace various view / viewgroups in the application.

Manually bind the view and the resource type to be changed

Colorful

This... Let's see the usage

I just want to change the skin. I have to set the attributes of which view and which attribute to change in the activity? Is the cost too high? And the logic of activity can easily be messed up.

Dynamic resource loading scheme

Resource replacement

Override the getresource method of the application, implement its own resources, and give priority to loading the resource packages under the local skin package folder. For performance problems, you can optimize them through attribute or resource name specification (start with skin_if skin change is required), so as to avoid additional inspection overhead for resources that do not need skin change.

However, in the Android 5.1 source code, loaddrawable is called during initialization instead of resource.getdrawable, and loaddrawable is a private method and cannot be overwritten. Therefore, although it is very convenient, it cannot continue to be used (do not care about any skin related matters. Just specify the color in Android: color, and Magic drops will change the skin automatically).

Customize layoutinflator.factory

Open source projects can refer to Android skin loader.

That is, setfactory uses a custom layoutinflator.factory, and can focus on skininflaterfactory and skinmanager in the project (it implements its own getcolor, getdrawable, getbitmap, getcolorstatelist and other methods).

You need to customize a tag, such as app: customstyle, rewrite all styles and turn them into set methods. The sacrifice is to increase the cost of skin changing. You have to write a lot of styles and set them yourself, which is not completely transparent.

Hack Resources internally

Black technology method, hack resources directly, resources. Java:

Directly replace the three longsparsearrays in resources. Since the resources in APK runtime are loaded from these three arrays, as long as the interceptor mode is adopted:

Implement a longsparsearray by yourself, and set it back by reflection to realize skin change. See the source code of resources for details on how to get the preload array in getdrawable and other methods.

Wait, that's it?, Nono, boy, you are too naive. How to load XML, how to update the padding of 9patch, how to package / load custom skin packages, how to refresh the drawable status, and so on. These are all things you need to consider. In apps with plug-ins, you also need to consider whether resource IDS will overlap each other. Then, you need to modify apt and put resource IDS in two ranges.

Hand QQ and independent QQ space use this scheme, and the effect is very good.

summary

Although the dynamic loading scheme is relatively black technology, it may have problems due to the change of system API, but relatively speaking

Benefits

-High flexibility, the background can update the skin package at any time - relatively transparent, developers hardly need to care about how many sets of skin, do not need to define various themes and attrs, and even the packaging of the skin package can be handed over to the design or special students - APK volume saving

Existing problems

There is no perfect open source project. If we adopt the second scheme of dynamic loading, the required project functions include:

-Custom skin package structure - skin change engine, load skin package resources and load, refresh in real time- Skin package packaging tool - compatible with various ROMs

If there is such a project, it will be done once and for all. Interested students can contact us and do it together.

The internal loading scheme is similar, which mainly solves the problem of instant refresh. However, from the perspective of some open source projects, there is still no particularly simple scheme. If I choose, I'd rather have the interface recreated, such as restarting the activity, or removing all views and adding them back (or you may want to traverse the rootviews, check whether you need to change the skin one by one, and then set...).

Thank you for reading, hope to help you, thank you for your support to this site!