1. Declare a system configuration change event for the Activity
System configuration change events refer to screen conversion, regional language changes, screen size changes, and so on. If the Activity does not declare to handle these events, the system will kill the Activity and restart it when an event occurs, and try to restore the status. The Activity has the opportunity to save some basic data to the Bundle through onSaveInstanceState (). Then the Bundle will be passed in onCreate () of the Activity. Although this seems to be normal, it may cause problems because many other things such as Dialog depend on specific Activity instances. Therefore, this default system behavior is generally not what we want.
To avoid these default behaviors, You need to declare these configurations for the Activity. The following two parameters must be stated for each Activity:
<Activity android: configChanges = "orientation | keyboardHidden">
Almost all activities must be declared as above. Why does Android not change them to Default?
2. Use Android APIs whenever possible
This seems nonsense. What is the use of Android APIs in Android development? Because Android supports almost all Java SE APIs, there are many places where Android APIs and Java SE APIs are duplicated. For example, it is best to use the Context encapsulated API in Android for file operations, instead of directly using the File object:
Context. openFileOutput (String); // no File file File = new File (String)
The reason is that the API will take into account the features of the Android platform itself; for example, use less Thread, and use more AsyncTask.
3. The Activity and process should be killed.
If you exit the Activity normally and the Activity is killed for other reasons, for example, the system memory is too low, the system configuration is changed, and there are exceptions, you should consider and test this situation, especially when an Activity processes important data, it stores the data well.
4. Be careful with multiple languages
Some languages are really coorse. When something that can be expressed in Chinese or English is very short, it becomes too long to be expressed in other languages, therefore, if it is wrap_content, other controls may be squeezed out of the visible range; if it is a specified length, it may not be displayed completely. Pay attention to special languages, such as those that read from the right to the left.
5. Do not use four major components to implement interfaces.
First, components have large objects, resulting in a waste of interfaces, making code easier to read and understand. More importantly, it causes multi-party references and may cause memory leakage.
6. Use getApplication () to get Context as a parameter.
For functions that require the Context object as a parameter, use getApplication () to obtain the Context object as a parameter rather than this unless you need a specific component instance! The Context returned by getApplication () belongs to the Application. It exists throughout the Application lifecycle, much larger than the lifecycle of a component, therefore, even if a reference holds a Context object for a long time, it will not cause memory leakage.
7. The main thread only performs UI control and Frameworks callback. The affiliated thread only performs time-consuming background operations. The interaction is only through Handler. In this way, a large number of thread problems can be avoided.
8. Do not do too many things in Frameworks callbacks, but only perform necessary initialization. Other things that are not very important can be put in other threads, or use Handler Schedule to do it later.
9. Multi-Resolution considerations
Prepare images and la s for at least hdpi, mdpi, and ldpi. The unit of the element also tries to use dip instead of px.
10. Use the hard key of the Android phone
Almost all Android phones have BACK and MENU, which are used to return and pop up menus. Therefore, do not design return and MENU buttons in the UI. Many excellent applications such as notes and return keys are available because they are all transplanted from iOS. In order to save the same experience, they also have the return and menu. However, this is not Android-based. A pure Android system does not have to repeat hard keys.
