The fragmentation of Android phones does not need to be discussed here, and a summary of what fits and how to match them.
Let's first look at the objects that are adapted.
The first type is the operating system adaptation , which is the adaptation of Android 2.x,4.x,5.x ... Each version of the operating system has its own specific changes, for app developers, the most important thing is to clear each version of the API Changed List. New APIs in the change list can be used selectively, and obsolete APIs can be addressed early, and APIs that change, especially those that change in form and meaning, should be focused on to avoid behavioral differences in different versions. For example, permissions splitting and default value change, from serial to concurrency changes, accurate timing and non-accurate timing changes, and so on, these will bring hidden very deep compatibility problems. In addition, is to carefully deal with minsdkversion, Targetsdkversion, compileversion, each value of the choice is not random, these also affect the adaptation of the operating system.
The second type is the manufacturer model , which is suitable for Samsung, millet, Note5, Rice 2 ... This piece has two kinds of adaptation, one is the public version of the adaptation, the second is the custom development. Let's start with the public version, which is the way most apps are used. the public version of this refers to the existence of only one set of code, an apk, to match all the manufacturers or models. The poor way is usually in the code involved in different vendors or models of the place through the IF statement using the build of the manufacturer's identity and other strategies, the result is the more appropriate, the more complex if statement, the more difficult to maintain. In fact, as long as the use of a factory model can be more flexible, such as:
custom development tends to form a split version, a standalone apk that differs from the public version, which can be combined with the vendor SDK depth, often by pre-assembled, and with Rom closer.
The third class is hardware compatible . Mainly for the inclusion of screen, CPU, memory, external memory, sensors and other adaptation, the main idea is abstract isolation.
after figuring out which objects to match, let's summarize the adaptation approach from the perspective of the three-tier architecture.
in the data layer , our main point is to adapt the external storage, that is to consider the location of data storage, format, volatile and so on. Usually this persistent data storage, to consider the storage location and its volatile issues, do not keep the key data in volatile external storage, as well as the Android 5.X to start the external card accessibility, and can be based on storage space and data characteristics of the plaintext format or ciphertext format, compressed or not compressed.
in the business Logic layer , the main is based on the different operating environment of the policy adjustment, based on the strategy.
in the presentation layer , for screen resolution, orientation, the relative unit DP, SP instead of pix, you can use the general adaptation methods such as layout provided by Android. For interaction and interface elements, we can adopt the idea of interactive demotion and visual demotion, that is, different interactive complexity and visual effect and animation effect are used on different performance phones. For system elements, such as desktop icons, notification bar, and so on, because ROM, launcher difference is too large, it is recommended to stay away from these parts, do not engage, otherwise the cost may be greater than the benefit.
adaptation is hard work, separating changes, isolating changes, and using design solutions more clearly than adding if statements anywhere.
--Welcome reprint, please specify the original source http://blog.csdn.net/caowenbin - -
--Welcome to the attention number "Cao Wenbin's software Thinking", discuss the software life together--
Adaptation in Android app development
