int maxMemory = (int)(Runtime.getRuntime().maxMemory() / 1024);
Log.d(“TAG”, “Max memory is” + maxMemory + “KB”);

因此在展示高分辨率图片的时候，最好先将图片进行压缩。压缩后的图片大小应该和用来展示它的控件大小相近，在一个很小的ImageView上显示一张超大的图片不会带来任何视觉上的好处，但却会占用我们相当多宝贵的内存，而且在性能上还可能会带来负面影响。下面我们就来看一看，如何对一张大图片进行适当的压缩，让它能够以最佳大小显示的同时，还能防止OOM的出现。
BitmapFactory这个类提供了多个解析方法(decodeByteArray,decodeFile, decodeResource等)用于创建Bitmap对象，我们应该根据图片的来源选择合适的方法。比如SD卡中的图片可以使用decodeFile方法，网络上的图片可以使用decodeStream方法，资源文件中的图片可以使用decodeResource方法。这些方法会尝试为已经构建的bitmap分配内存，这时就会很容易导致OOM出现。为此每一种解析方法都提供了一个可选的BitmapFactory.Options参数，将这个参数的inJustDecodeBounds属性设置为true就可以让解析方法禁止为bitmap分配内存，返回值也不再是一个Bitmap对象，而是null。虽然Bitmap是null了，但是BitmapFactory.Options的outWidth、outHeight和outMimeType属性都会被赋值。这个技巧让我们可以在加载图片之前就获取到图片的长宽值和MIME类型，从而根据情况对图片进行压缩。如下代码所示：

view plaincopy
BitmapFactory.Options options = newBitmapFactory.Options();
options.inJustDecodeBounds = true;
BitmapFactory.decodeResource(getResources(),R.id.myimage, options);
int imageHeight = options.outHeight;
int imageWidth = options.outWidth;
String imageType =options.outMimeType;
为了避免OOM异常，最好在解析每张图片的时候都先检查一下图片的大小，除非你非常信任图片的来源，保证这些图片都不会超出你程序的可用内存。
现在图片的大小已经知道了，我们就可以决定是把整张图片加载到内存中还是加载一个压缩版的图片到内存中。以下几个因素是我们需要考虑的：

预估一下加载整张图片所需占用的内存。
为了加载这一张图片你所愿意提供多少内存。
用于展示这张图片的控件的实际大小。
当前设备的屏幕尺寸和分辨率。
比如，你的ImageView只有128*96像素的大小，只是为了显示一张缩略图，这时候把一张1024*768像素的图片完全加载到内存中显然是不值得的。

那我们怎样才能对图片进行压缩呢？通过设置BitmapFactory.Options中inSampleSize的值就可以实现。比如我们有一张2048*1536像素的图片，将inSampleSize的值设置为4，就可以把这张图片压缩成512*384像素。原本加载这张图片需要占用13M的内存，压缩后就只需要占用0.75M了(假设图片是ARGB_8888类型，即每个像素点占用4个字节)。下面的方法可以根据传入的宽和高，计算出合适的inSampleSize值：

view plaincopy
public static intcalculateInSampleSize(BitmapFactory.Options options,
int reqWidth, int reqHeight) {
// 源图片的高度和宽度
final int height = options.outHeight;
final int width = options.outWidth;
int inSampleSize = 1;
if (height > reqHeight || width > reqWidth) {
// 计算出实际宽高和目标宽高的比率
final int heightRatio = Math.round((float) height / (float)reqHeight);
final int widthRatio = Math.round((float) width / (float)reqWidth);
// 选择宽和高中最小的比率作为inSampleSize的值，这样可以保证最终图片的宽和高
// 一定都会大于等于目标的宽和高。
inSampleSize = heightRatio < widthRatio ? heightRatio : widthRatio;
}
return inSampleSize;
}
使用这个方法，首先你要将BitmapFactory.Options的inJustDecodeBounds属性设置为true，解析一次图片。然后将BitmapFactory.Options连同期望的宽度和高度一起传递到到calculateInSampleSize方法中，就可以得到合适的inSampleSize值了。之后再解析一次图片，使用新获取到的inSampleSize值，并把inJustDecodeBounds设置为false，就可以得到压缩后的图片了。
view plaincopy
public static BitmapdecodeSampledBitmapFromResource(Resources res, int resId,
int reqWidth, int reqHeight) {
// 第一次解析将inJustDecodeBounds设置为true，来获取图片大小
final BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;
BitmapFactory.decodeResource(res, resId, options);
// 调用上面定义的方法计算inSampleSize值
options.inSampleSize = calculateInSampleSize(options, reqWidth,reqHeight);
// 使用获取到的inSampleSize值再次解析图片
options.inJustDecodeBounds = false;
return BitmapFactory.decodeResource(res, resId, options);
}
下面的代码非常简单地将任意一张图片压缩成100*100的缩略图，并在ImageView上展示。
view plaincopy
mImageView.setImageBitmap(
decodeSampledBitmapFromResource(getResources(), R.id.myimage, 100,100));
使用图片缓存技术
在你应用程序的UI界面加载一张图片是一件很简单的事情，但是当你需要在界面上加载一大堆图片的时候，情况就变得复杂起来。在很多情况下，（比如使用ListView, GridView 或者 ViewPager 这样的组件），屏幕上显示的图片可以通过滑动屏幕等事件不断地增加，最终导致OOM。
为了保证内存的使用始终维持在一个合理的范围，通常会把被移除屏幕的图片进行回收处理。此时垃圾回收器也会认为你不再持有这些图片的引用，从而对这些图片进行GC操作。用这种思路来解决问题是非常好的，可是为了能让程序快速运行，在界面上迅速地加载图片，你又必须要考虑到某些图片被回收之后，用户又将它重新滑入屏幕这种情况。这时重新去加载一遍刚刚加载过的图片无疑是性能的瓶颈，你需要想办法去避免这个情况的发生。

这个时候，使用内存缓存技术可以很好的解决这个问题，它可以让组件快速地重新加载和处理图片。下面我们就来看一看如何使用内存缓存技术来对图片进行缓存，从而让你的应用程序在加载很多图片的时候可以提高响应速度和流畅性。

内存缓存技术对那些大量占用应用程序宝贵内存的图片提供了快速访问的方法。其中最核心的类是LruCache (此类在android-support-v4的包中提供) 。这个类非常适合用来缓存图片，它的主要算法原理是把最近使用的对象用强引用存储在 LinkedHashMap 中，并且把最近最少使用的对象在缓存值达到预设定值之前从内存中移除。
在过去，我们经常会使用一种非常流行的内存缓存技术的实现，即软引用或弱引用 (SoftReference or WeakReference)。但是现在已经不再推荐使用这种方式了，因为从 Android 2.3 (API Level 9)开始，垃圾回收器会更倾向于回收持有软引用或弱引用的对象，这让软引用和弱引用变得不再可靠。另外，Android 3.0 (API Level 11)中，图片的数据会存储在本地的内存当中，因而无法用一种可预见的方式将其释放，这就有潜在的风险造成应用程序的内存溢出并崩溃。
为了能够选择一个合适的缓存大小给LruCache, 有以下多个因素应该放入考虑范围内，例如：

你的设备可以为每个应用程序分配多大的内存？
设备屏幕上一次最多能显示多少张图片？有多少图片需要进行预加载，因为有可能很快也会显示在屏幕上？
你的设备的屏幕大小和分辨率分别是多少？一个超高分辨率的设备（例如 Galaxy Nexus) 比起一个较低分辨率的设备（例如 Nexus S），在持有相同数量图片的时候，需要更大的缓存空间。
图片的尺寸和大小，还有每张图片会占据多少内存空间。
图片被访问的频率有多高？会不会有一些图片的访问频率比其它图片要高？如果有的话，你也许应该让一些图片常驻在内存当中，或者使用多个LruCache 对象来区分不同组的图片。
你能维持好数量和质量之间的平衡吗？有些时候，存储多个低像素的图片，而在后台去开线程加载高像素的图片会更加的有效。
并没有一个指定的缓存大小可以满足所有的应用程序，这是由你决定的。你应该去分析程序内存的使用情况，然后制定出一个合适的解决方案。一个太小的缓存空间，有可能造成图片频繁地被释放和重新加载，这并没有好处。而一个太大的缓存空间，则有可能还是会引起 java.lang.OutOfMemory 的异常。
下面是一个使用 LruCache 来缓存图片的例子：

view plaincopy
private LruCache<String, Bitmap>mMemoryCache;

@Override
protected void onCreate(BundlesavedInstanceState) {
// 获取到可用内存的最大值，使用内存超出这个值会引起OutOfMemory异常。
// LruCache通过构造函数传入缓存值，以KB为单位。
int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);
// 使用最大可用内存值的1/8作为缓存的大小。
int cacheSize = maxMemory / 8;
mMemoryCache = new LruCache<String, Bitmap>(cacheSize) {
@Override
protected int sizeOf(String key, Bitmap bitmap) {
// 重写此方法来衡量每张图片的大小，默认返回图片数量。
return bitmap.getByteCount() / 1024;
}
};
}

public void addBitmapToMemoryCache(Stringkey, Bitmap bitmap) {
if (getBitmapFromMemCache(key) == null) {
mMemoryCache.put(key, bitmap);
}
}

public Bitmap getBitmapFromMemCache(Stringkey) {
return mMemoryCache.get(key);
}

在这个例子当中，使用了系统分配给应用程序的八分之一内存来作为缓存大小。在中高配置的手机当中，这大概会有4兆(32/8)的缓存空间。一个全屏幕的 GridView 使用4张 800×480分辨率的图片来填充，则大概会占用1.5兆的空间(800*480*4)。因此，这个缓存大小可以存储2.5页的图片。
当向 ImageView 中加载一张图片时,首先会在 LruCache 的缓存中进行检查。如果找到了相应的键值，则会立刻更新ImageView ，否则开启一个后台线程来加载这张图片。
view plaincopy
public void loadBitmap(int resId, ImageViewimageView) {
final String imageKey = String.valueOf(resId);
final Bitmap bitmap = getBitmapFromMemCache(imageKey);
if (bitmap != null) {
imageView.setImageBitmap(bitmap);
}else {
imageView.setImageResource(R.drawable.image_placeholder);
BitmapWorkerTask task = new BitmapWorkerTask(imageView);
task.execute(resId);
}
}
BitmapWorkerTask 还要把新加载的图片的键值对放到缓存中。
view plaincopy
class BitmapWorkerTask extendsAsyncTask<Integer, Void, Bitmap> {
// 在后台加载图片。
@Override
protected Bitmap doInBackground(Integer… params) {
final Bitmap bitmap = decodeSampledBitmapFromResource(
getResources(), params[0], 100,100);
addBitmapToMemoryCache(String.valueOf(params[0]), bitmap);
return bitmap;
｝

http://ineice.blog.51cto.com/10426190/1690402

代码如下：

先是在AndroidManifest中的application和mainActivity下添加两个meta-data属性。

    <application
        android:allowBackup="true"
        android:icon="@drawable/ic_launcher"
        android:label="@string/app_name"
        android:theme="@style/AppTheme" >
        <meta-data
            android:name="com.lzy.test"
            android:value="测试" />

        <activity
            android:name=".MainActivity"
            android:label="@string/app_name" >
            <meta-data
                android:name="com.example.metatest.MainActivity.com.lzy.activity.test"
                android:value="Activity测试" />

            <intent-filter>
                <action android:name="android.intent.action.MAIN" />

                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>
    
 

接下来在mainActivity中来获取这两个属性的值。

package com.example.metatest;

import android.app.Activity;
import android.content.ComponentName;
import android.content.pm.ActivityInfo;
import android.content.pm.ApplicationInfo;
import android.content.pm.PackageManager;
import android.content.pm.PackageManager.NameNotFoundException;
import android.os.Bundle;
import android.util.Log;
import android.widget.Toast;

/**
 * meta 测试
 * 
 * @author Administrator
 * 
 */

public class MainActivity extends Activity {

	public static final String TEST = "com.lzy.test";

	public static final String ACTIVITYTEST = MainActivity.class.getName()+".com.lzy.activity.test";

	@Override
	protected void onCreate(Bundle savedInstanceState) {
		super.onCreate(savedInstanceState);
		setContentView(R.layout.activity_main);
		
		String test = getMetaDataStringApplication(TEST, null);
		
		String activityTest = getMetaDataStringFromActivity(ACTIVITYTEST, null);
		
		Toast.makeText(this, test+"--"+activityTest, Toast.LENGTH_LONG).show();
	}
	
	/**
	 * 根据key从Application中返回的Bundle中获取value
	 * 
	 * @param key
	 * @param defValue
	 * @return
	 */
	private String getMetaDataStringApplication(String key, String defValue) {
		Bundle bundle = getAppMetaDataBundle(getPackageManager(), getPackageName());
		if (bundle != null && bundle.containsKey(key)) {
			return bundle.getString(key);
		}
		return defValue;
	}
	
	/**
	 * 获取Application中的meta-data.
	 * 
	 * @param packageManager
	 * @param packageName
	 * @return
	 */
	private Bundle getAppMetaDataBundle(PackageManager packageManager,
			String packageName) {
		Bundle bundle = null;
		try {
			ApplicationInfo ai = packageManager.getApplicationInfo(packageName,
					PackageManager.GET_META_DATA);
			bundle = ai.metaData;
		} catch (NameNotFoundException e) {
			Log.e("getMetaDataBundle", e.getMessage(), e);
		}
		return bundle;
	}
	
	/**
	 * 根据key从Activity中返回的Bundle中获取value
	 * 
	 * @param key
	 * @param defValue
	 * @return
	 */
	private String getMetaDataStringFromActivity(String key, String defValue) {
		Bundle bundle = getActivityMetaDataBundle(getPackageManager(), getComponentName());
		if (bundle != null && bundle.containsKey(key)) {
			return bundle.getString(key);
		}
		return defValue;
	}
	
	/**
	 * 获取Activity中的meta-data.
	 * 
	 * @param packageManager
	 * @param component
	 * @return
	 */
	private Bundle getActivityMetaDataBundle(PackageManager packageManager, ComponentName component) {
		Bundle bundle = null;
		try {
			ActivityInfo ai = packageManager.getActivityInfo(component,
					PackageManager.GET_META_DATA);
			bundle = ai.metaData;
		} catch (NameNotFoundException e) {
			Log.e("getMetaDataBundle", e.getMessage(), e);
		}

		return bundle;
	}

}
    

源码下载：http://download.csdn.net/detail/u012527802/9070361

来源：http://blog.csdn.net/u012527802/article/details/48157637

这里所说的统计系统的启动时间，并不是简单地用秒表和肉眼来统计，而是通过分析系统输出的log信息来统计，这样才显得更加专业。

首先了解2个概念：

（1） Android是基于Linux内核的系统，因此Android的启动过程是分为两个阶段的，第一个阶段就是Linux内核的启动，第二个阶段就是Android框架的启动（包括核心服务和程序）。

（2）Android的log系统是独立于Linux内核的log系统的。Linux内核通过printk打印的log信息，这些log写入到了/dev/kmsg文件中，在Shell终端可以通过dmesg命令查看这些log信息。Android框架则是通过Logger驱动打印log信息，这些log并没有归并到kmesg文件中，而是单独存储的，位于/dev/log目录下，在Shell终端可以通过logcat命令来查看。

下面我们分别从两种log信息中找到如何统计系统启动时间的方法。

1. 通过dmesg信息统计系统启动时间

首先，我们通过dmesg命令抓取Linux内核的log信息（部分系统可能需要先执行 adb root）：

$ adb shell dmesg > dmesg.txt

Linux内核启动完成，一般都有如下的标准输出信息：

<6> [ 6.613861] Freeing init memory: 176K

因此，只要我们在dmesg.txt文件中找到“Freeing init memory”这一行即可，从上面的log可以看出，Linux内核启动只用了6.613861s。

那么，如何找到Android系统启动完成的标志呢？

很多Android设备在系统启动完成后，会在内核log中打印如下信息：

<6>[ 29.913726] init: processing action 0x96bb8 (property:sys.boot_completed=1)

因此，找到“boot_completed”这一行也就得到了整个系统的启动时间了，从这一行可以看出，整个系统启动用了29.913726s。

当然，并不是所有的Android设备都会打印出这条log，因此，我们一般用下面介绍的方法来专门统计Android系统的启动时间，

2. 通过logcat统计系统的启动时间

文章开头我们已经介绍过，Android的log系统是独立于Linux内核log系统的，通过在终端输入adb shell 进入Android系统，cd到/dev/log目录，你会发现里面有四个文件，分别是：events，main，radio，system.

Android系统把Log分为了四类，不同的类别记录不同的Log信息：

main – 主要的Log信息，大部分应用级别的Log信息都在这里
events – 系统事件相关的Log信息
radio – 无线/电话相关的Log信息
system – 低级别的系统调试Log信息

默认通过logcat抓取的是main信息，如果想抓取指定类别的log信息的方法，在logcat命令后加-b参数，例如：

$ adb logcat -d -v time -b “main” > main.txt
$ adb logcat -d -v time -b “events” > events.txt
$ adb logcat -d -v time -b “system” > system.txt
$ adb logcat -d -v time -b “radio” > radio.txt

关于Android Log系统的分类，你可以访问如下页面详细了解： 《Android Logging System》

那么，如何统计Android系统的启动时间呢？

我们可以重点关注events类别的log信息，通过如下命令：

$ adb logcat -d -b events | grep “boot”

如图所示，这是我在高通的APQ8064开发板上抓取的log信息：

“boot_progress_start”代表着Android部分启动开始，即15.492s开始启动。

“boot_progress_enable_screen”代表着整个系统启动结束，即用了29.986s。

 
原文：http://ticktick.blog.51cto.com/823160/1660996

界面截图1：

界面截图2：

界面截图3：

附件中Android界面设计psd文件截图：

下载：Android界面设计psd下载

方法一：
Display mDisplay = getWindowManager().getDefaultDisplay();
int W = mDisplay.getWidth();
int H = mDisplay.getHeight();
Log.i(“Main”, “Width = ” + W);
Log.i(“Main”, “Height = ” + H);
复制代码
Display是在android.view.Display包中的。

方法二：
DisplayMetrics mDisplayMetrics = new DisplayMetrics();
getWindowManager().getDefaultDisplay().getMetrics(mDisplayMetrics);
int W = mDisplayMetrics.widthPixels;
int H = mDisplayMetrics.heightPixels;
Log.i(“Main”, “Width = ” + W);
Log.i(“Main”, “Height = ” + H);
复制代码
DisplayMetrics是在android.util.DisplayMetrics包中的，getWindowManager()是Activity中的方法。

我使用的测试手机是M9，我们看一下Logcat的打印信息：

显示正确，M9确实是这个分辨率。

注：android.os.Build.VERSION.RELEASE获取版本号
android.os.Build.MODEL 获取手机型号

解：退出模拟器中的应用程序，然后再重启程序！

2、在添加环境变量的时候发现Tools目录下没有adb.exe文件！所以无法使用命令行

解：发现较新版本的SDK的adb.exe文件在platform-tools文件夹里面

3、在命令行输入adb shell命令时提示错误:error : adb shell device not found

解：开启相应版本的模拟器或者是连接到手机就可以了！

4、在接收短消息广播的时候出错: requires android.permission.RECEIVE_SMS due to sendercom.android.phone

解：需要在manifest配置一句话：

<uses-permission android:name=”android.permission.RECEIVE_SMS”/>