[Four features of sound: pitch, sound length, volume, and tone] --- basic five-line spectrum tutorial
Android project analysis generally starts from androidmanifest. starting from the XML file, we can see the configuration of the activity, service, and other four components defined by this app, as well as the SDK version and declared permissions.
1. Order of tags
First, use the android lint tool to check the configuration file. We found a lint warning:
This description indicates that the <uses-Permission> label should be located in front of the <Application> label. When the positions of the two labels are adjusted, another warning will appear:
That is, the <uses-SDK> tag should also be placed before the <Application> tag.
2. Android: installlocation attribute of the <manifest> tag
You can see that the installlocation attribute has three values to indicate the program installation policy:
1) "Auto": The program is installed in the memory by default. If the memory space is insufficient, it will be installed in the external memory; then, the user can switch the installation location of the program between the internal and external storage at will through the system settings;
2) "internalonly": The program can only be installed in the memory. When the memory space is insufficient, the program will fail to be installed. When we do not specify the installlocation attribute, This is the default behavior of our program.
3) "preferexternal": The program is preferentially installed in the external storage (SD card). However, when the external storage space is insufficient or is affected by other reasons, the program can also be installed in the memory; then, the user can switch the installation location of the program between the internal and external storage at will through the system settings;
The installlocation value of an application is usually determined based on the application type. The following types of applications should not be installed in external storage (SD card ):
Services, alarm services, input method engines, live wallpapers, appwidgets, account managers, sync adapters, device administrators, broadcast receivers listening for "Boot completed", and copy protection.
Therefore, for general programs, if there are no special requirements, the value is generally "Auto ".
For more information about the installlocation attribute, see:
Http://developer.android.com/guide/topics/manifest/manifest-element.html#install
Http://developer.android.com/guide/topics/data/install-location.html
Samjamendoapplication
Jamendoapplication inherits from the application class and represents the unique instance of the program. It is mainly used to maintain public resource instances used by the entire program, imagecache, requestcache, playerengine, mediaplayer currently in use, equalizer, playlist, downloadmanager, and gesture processor. This section describes the implementation of the two caches.
3.1) imagecache
Imagecache is used to cache image resources downloaded from the network to the memory, which is easy to save mobile phone traffic. The code is simple and inherits the weakhashmap class. Most of the work is done by this class. Weakhashmap is implemented based on the key-value pair. It features that when there are no references pointing to a key other than its own reference to a key, this map will discard the value of the value corresponding to the key. The Code is as follows:
public class ImageCache extends WeakHashMap<String, Bitmap> {public boolean isCached(String url){return containsKey(url) && get(url) != null;}}
Because jamendo involves a small amount of image resources, it mainly displays the album cover. Therefore, this method is feasible. When there are many images to be processed, such as wallpaper applications and Image Browsing applications, a level-2 cache is generally required, that is, the memory cache and the external memory cache, specify the cache size and use the LRU algorithm to replace image resources. See http://developer.android.com/training/displaying-bitmaps/index.html for details
3.2) requestcache
This class is implemented in combination with the shortlist and hashtable to delete the oldest URL policy when the cache space is insufficient. The shortlist is used to insert the latest URL into the head of the linked list. When the cache space is insufficient, remove the URL at the end of the linked list. hashtabel is used to store the ing between the URL request and the corresponding response data. The Code is as follows:
Public class requestcache {Private Static int cache_limit = 10; // cache size private history list <string> mhistory; // cache the URL in the form of a linked list. When the cache is full, private hashtable <string, string> mcache; Public requestcache () {mhistory = new history list <string> (); mcache = new hashtable <string, string> ();} public void put (string URL, string data) {mhistory. add (URL); // If the cache is full, remove the old one if (mhistory. size ()> cache_limit) {string old_url = (string) mhistory. poll (); // get the oldest urlmcache. remove (old_url);} mcache. put (URL, data);} Public String get (string URL) {return mcache. get (URL );}}