BlogJava-zhaojianhua-随笔分类-Android

Activity四种启动模式

建华 — Tue, 23 Jun 2015 03:04:00 GMT

Activity启动方式有四种，分别是：

standard
singleTop
singleTask
singleInstance

可以根据实际的需求为Activity设置对应的启动模式，从而可以避免创建大量重复的Activity等问题。

设置Activity的启动模式，只需要在AndroidManifest.xml里对应的标签设置android:launchMode属性，例如：

[html] view plain copy

<activity
android:name=".A1"
android:launchMode="standard" />

下面是这四种模式的作用：

standard
默认模式，可以不用写配置。在这个模式下，都会默认创建一个新的实例。因此，在这种模式下，可以有多个相同的实例，也允许多个相同Activity叠加。

例如：
若我有一个Activity名为A1, 上面有一个按钮可跳转到A1。那么如果我点击按钮，便会新启一个Activity A1叠在刚才的A1之上，再点击，又会再新启一个在它之上……
点back键会依照栈顺序依次退出。

singleTop
可以有多个实例，但是不允许多个相同Activity叠加。即，如果Activity在栈顶的时候，启动相同的Activity，不会创建新的实例，而会调用其onNewIntent方法。

例如：
若我有两个Activity名为B1,B2,两个Activity内容功能完全相同，都有两个按钮可以跳到B1或者B2，唯一不同的是B1为standard，B2为singleTop。
若我意图打开的顺序为B1->B2->B2，则实际打开的顺序为B1->B2（后一次意图打开B2，实际只调用了前一个的onNewIntent方法）
若我意图打开的顺序为B1->B2->B1->B2，则实际打开的顺序与意图的一致，为B1->B2->B1->B2。

singleTask
只有一个实例。在同一个应用程序中启动他的时候，若Activity不存在，则会在当前task创建一个新的实例，若存在，则会把task中在其之上的其它Activity destory掉并调用它的onNewIntent方法。
如果是在别的应用程序中启动它，则会新建一个task，并在该task中启动这个Activity，singleTask允许别的Activity与其在一个task中共存，也就是说，如果我在这个singleTask的实例中再打开新的Activity，这个新的Activity还是会在singleTask的实例的task中。

例如：
若我的应用程序中有三个Activity,C1,C2,C3，三个Activity可互相启动，其中C2为singleTask模式，那么，无论我在这个程序中如何点击启动，如：C1->C2->C3->C2->C3->C1-C2，C1,C3可能存在多个实例，但是C2只会存在一个，并且这三个Activity都在同一个task里面。
但是C1->C2->C3->C2->C3->C1-C2，这样的操作过程实际应该是如下这样的，因为singleTask会把task中在其之上的其它Activity destory掉。
操作：C1->C2 C1->C2->C3 C1->C2->C3->C2 C1->C2->C3->C2->C3->C1 C1->C2->C3->C2->C3->C1-C2
实际：C1->C2 C1->C2->C3 C1->C2 C1->C2->C3->C1 C1->C2

若是别的应用程序打开C2，则会新启一个task。
如别的应用Other中有一个activity，taskId为200，从它打开C2，则C2的taskIdI不会为200，例如C2的taskId为201，那么再从C2打开C1、C3，则C2、C3的taskId仍为201。
注意：如果此时你点击home，然后再打开Other，发现这时显示的肯定会是Other应用中的内容，而不会是我们应用中的C1 C2 C3中的其中一个。

singleInstance
只有一个实例，并且这个实例独立运行在一个task中，这个task只有这个实例，不允许有别的Activity存在。

例如：
程序有三个ActivityD1,D2,D3，三个Activity可互相启动，其中D2为singleInstance模式。那么程序从D1开始运行，假设D1的taskId为200，那么从D1启动D2时，D2会新启动一个task，即D2与D1不在一个task中运行。假设D2的taskId为201，再从D2启动D3时，D3的taskId为200，也就是说它被压到了D1启动的任务栈中。

若是在别的应用程序打开D2，假设Other的taskId为200，打开D2，D2会新建一个task运行，假设它的taskId为201，那么如果这时再从D2启动D1或者D3，则又会再创建一个task，因此，若操作步骤为other->D2->D1，这过程就涉及到了3个task了。

建华 2015-06-23 11:04 发表评论

蓝牙发送文件

建华 — Wed, 20 Feb 2013 00:45:00 GMT

系统4.0.3以后的
File file=new File("");

Uri uri1 = Uri.fromFile(file);

Intent intent = new Intent();

intent.setAction(Intent.ACTION_SEND);

//intent.setType("audio/*");

intent.setType("application/octet-stream");

ComponentName comp=new ComponentName("com.mediatek.bluetooth","com.mediatek.bluetooth.BluetoothShareGatewayActivity");

intent.setComponent(comp);

intent.putExtra(Intent.EXTRA_STREAM, uri1);

startActivity(intent);

系统4.0.3以前的

Intent intent = new Intent();

intent.setAction(Intent.ACTION_SEND);

//这个类型函数是自己工具类的方法，你可以自己设置文件类型，例如图片文件：image/*

//不想写类型直接*/*也是可以的

intent.setType("audio/*");

//这里setClassName就是指定蓝牙，不写这句就弹出选择用什么发送

//有蓝牙啊，gmail啊，彩信之类的

intent.setClassName("com.android.bluetooth" , "com.android.bluetooth.opp.BluetoothOppLauncherActivity");

intent.putExtra(Intent.EXTRA_STREAM, Uri.fromFile(new File("")));

startActivity(intent);

ArrayList uris = new ArrayList();

uris.add(Uri.fromFile(new File("/sdcard/111.txt")));

uris.add(Uri.fromFile(new File("/sdcard/222.txt")));

Intent intent = new Intent();

intent.setAction(Intent.ACTION_SEND_MULTIPLE);

intent.setType("video/*");

intent.setClassName("com.android.bluetooth" , "com.android.bluetooth.opp.BluetoothOppLauncherActivity");

//intent.setClassName("com.mediatek.bluetooth","com.mediatek.bluetooth.BluetoothShareGatewayActivity");

//intent.putExtra(Intent.EXTRA_STREAM, Uri.fromFile(new File("/sdcard/111.txt")) );

//intent.putExtra(Intent.EXTRA_STREAM, Uri.fromFile(new File("/sdcard/222.txt")));

intent.putExtra(Intent.EXTRA_STREAM, uris);

startActivity(intent);

建华 2013-02-20 08:45 发表评论

surfaceView 与View 的区别

建华 — Fri, 23 Mar 2012 08:33:00 GMT

如果你的游戏不吃CPU，用View就比较好，符合标准Android操作方式，由系统决定刷新surface的时机。

　　但如果很不幸的，你做不到不让你的程序吃CPU，你就只好使用SurfaceView来强制刷新surface了，不然系统的UI进程很可能抢不过你那些吃CPU的线程。

　　当然其实不止这两种方法来刷新Surface的，这两种只是纯Java应用比较常见的方法。

　　SurfaceView和View最本质的区别在于，surfaceView是在一个新起的单独线程中可以重新绘制画面而View必须在UI的主线程中更新画面。

　　那么在UI的主线程中更新画面可能会引发问题，比如你更新画面的时间过长，那么你的主UI线程会被你正在画的函数阻塞。那么将无法响应按键，触屏等消息。

　　当使用surfaceView 由于是在新的线程中更新画面所以不会阻塞你的UI主线程。但这也带来了另外一个问题，就是事件同步。比如你触屏了一下，你需要surfaceView中 thread处理，一般就需要有一个event queue的设计来保存touch event，这会稍稍复杂一点，因为涉及到线程同步。

　　所以基于以上，根据游戏特点，一般分成两类。

　　1 被动更新画面的。比如棋类，这种用view就好了。因为画面的更新是依赖于 onTouch 来更新，可以直接使用 invalidate。因为这种情况下，这一次Touch和下一次的Touch需要的时间比较长些，不会产生影响。

　　2 主动更新。比如一个人在一直跑动。这就需要一个单独的thread不停的重绘人的状态，避免阻塞main UI thread。所以显然view不合适，需要surfaceView来控制。

建华 2012-03-23 16:33 发表评论

如果task中已经有这个activity A，那么就把A拿到task的最顶层，而不是创建一个新的activity

建华 — Tue, 20 Dec 2011 11:31:00 GMT

Intent.FLAG_ACTIVITY_REORDER_TO_FRONT的意思是，如果task中已经有这个activity A，那么就把A拿到task的最顶层，而不是创建一个新的activity。

所以不加flag也不会影响界面的切过去，只是会影响task的顺序而已。

建华 2011-12-20 19:31 发表评论

Android开发小知识 ListView几个比较特别的属性

建华 — Wed, 14 Dec 2011 12:14:00 GMT

Android:stackFromBottom="true" 设置该属性之后你做好的列表就会显示在列表的最下面，值为true和false
android:transcriptMode="alwaysScroll" 要用ListView或者其它显示大量Items的控件实时跟踪或者查看信息，并且希望最新的条目可以自动滚动到可视范围内。通过设置的控件 transcriptMode属性可以将Android平台的控件（支持ScrollBar）自动滑动到最底部。 c
acheColorHint属性，很多人希望能够改变一下它的背景，使他能够符合整体的UI设计，改变背景背很简单只需要准备一张图片然后指定属性
android:background="@drawable/bg"，不过当你这么做以后，发现背景是变了，但是当你拖动，或者点击list空白位置的时候发现ListItem都变成黑色的了，破坏了整体效果。如果只是换背景的颜色的话，可以直接指定
android:cacheColorHint为你所要的颜色，如果你是用图片做背景的话，那也只要将
android:cacheColorHint指定为透明（#00000000）就可以了
android:divider="@drawable/list_driver" 其中 @drawable/list_driver 是一个图片资源，如果不想显示分割线则只要设置为android:divider="@drawable/@null" 就可以了 android:scrollbars="none"与setVerticalScrollBarEnabled(true);的效果是一样的，不活动的时候隐藏，活动的时候也隐藏 android:fadeScrollbars="true" 配置ListView布局的时候，设置这个属性为true就可以实现滚动条的自动隐藏和显示。 fadingEdge属性，上边和下边有黑色的阴影 android:fadingEdge="none" 设置后没有阴影了

建华 2011-12-14 20:14 发表评论

做一个透明的activity

建华 — Tue, 13 Dec 2011 06:13:00 GMT

建华 2011-12-13 14:13 发表评论

draw9patch不失真背景

建华 — Thu, 24 Nov 2011 07:00:00 GMT

1.背景自适应且不失真问题的存在
   制作自适应背景图片是UI开发的一个广泛问题，也是界面设计师渴望解决的问题，我相信我们彼此都深有体会。
   比如,列表的背景图一定，但是列表的高度随着列表数据项会发生变化；标题栏的背景，无论横屏还是竖屏，高分辨率还是低分辨率，都能自动填充满，而且不失真等等背景问题。
   根据以往的经验，我们一般采用先切图后拼凑的做法，这种做法本来我想在这里和大家介绍一下，其实有的时候还是很有用的，但是说起来会比较麻烦，就不说这个非重点了，略去，如果大家真的要介绍，在回复中说明，我再考虑一下。
   Android针对这种情况，专门制作了一种.9.PNG格式来解决这个问题。

2.9.PNG格式。
   我不想在这里过多的讨论PNG格式的定义问题。但是.9.PNG确实是标准的PNG格式，只是在最外面一圈额外增加1px的边框，这个1px的边框就是用来定义图片中可扩展的和静态不变的区域。特别说明，left和top边框中交叉部分是可拉伸部分，未选中部分是静态区域部分。right和bottom 边框中交叉部分则是内容部分（变相的相当于定义看一个内边距，神似padding功能，后面我会单独介绍一下），这个参数是可选的, 如下图。
   在Android中以9.PNG格式的图片未背景，则能够自定义拉伸而不失真，比如系统的Button就是一个典型的例子。
   其实呢，无论是left和top，还是right和bottom都是把图片分成9块 (边角四块是不能缩放的，其他的四块则是允许缩放的)，所以叫做9.PNG。

3. 使用Draw9Patch.jar制作9.PNG图片之定义拉伸区域。
   前面已经了解到9.PNG格式的工作方式，下面我们使用谷歌提供的Draw9Patch(运行android-sdk-windows\tools目录下的Draw9Patch.bat)来制作.9.PNG图片。
   第一步：准备要拉伸的图片。

   非常小的一张图片，我希望以此为背景，中间部分填充文章内容。
   第二步：制作.9.PNG图片。
   打开Draw9Patch,把图片拖进去，如下：

   默认的拉伸是整体拉伸，其实边框部分我们并不想拉伸，好，我们自己来定义拉伸区域，如下图：

   然后点击File,导出为content.9.png。
   第三步：在layout文件中使用制作的 .9.PNG图片.
   新建工程Draw9Patch，默认主Activity为Draw9PatchActivity.java:

`1`	`@Override`

`2`	`public` `void` `onCreate(Bundle savedInstanceState)`

3 {

`4`	`super.onCreate(savedInstanceState);`

`5`	`setContentView(R.layout.main);`

6 }

我们把content.9.png文件拷贝到/res/drawable文件夹下，打开/res/layout目录下的main.xml，申明如下：

`01`	`xml version="1.0" encoding="utf-8"?>`

`02`	`<LinearLayout` `xmlns:android="http://schemas.android.com/apk/res/android"`

`03`	`android:orientation="vertical"`

`04`	`android:layout_width="fill_parent"`

`05`	`android:layout_height="fill_parent"`

`06`	`android:background="#777"`

`07`	`android:padding="8dip"`

08 >

`09`	`<TextView`

`10`	`android:layout_width="fill_parent"`

`11`	`android:layout_height="wrap_content"`

`12`	`android:text="正文:A NinePatchDrawable graphic is a stretchable bitmap image."`

`13`	`android:background="@drawable/content"`

`14`	`android:textColor="#000"`

15 />

`16`	`LinearLayout>`

如图，

我们修改text，

`01`	`xml version="1.0" encoding="utf-8"?>`

`02`	`<LinearLayout` `xmlns:android="http://schemas.android.com/apk/res/android"`

`03`	`android:orientation="vertical"`

`04`	`android:layout_width="fill_parent"`

`05`	`android:layout_height="fill_parent"`

`06`	`android:background="#777"`

`07`	`android:padding="8dip"`

08 >

`09`	`<TextView`

`10`	`android:layout_width="fill_parent"`

`11`	`android:layout_height="wrap_content"`

`12`	`android:text=" 正文:A NinePatchDrawable graphic is a stretchable bitmap image, which Android will automatically resize to accommodate the contents of the View in which you have placed it as the background. A NinePatch drawable is a standard PNG image that includes an extra 1-pixel-wide border."`

`13`	`android:background="@drawable/content"`

`14`	`android:textColor="#000"`

15 />

`16`	`LinearLayout>`

如图，

可以看出，边框非常的清晰。下图是未使用.9.PNG的对比图，而且也不是我们要的效果：

到这里为止，我们已经基本会制作.9.PNG图片了。为了知识体系的全面性和深入性，我们继续。

4.使用Draw9Patch.jar制作9.PNG图片之定义内容区域。
   是不是觉得文字和边距挨的太近，好，我们使用right和bottom边的线来定义内容区域，来达到增大内边距的目的。

   我们定义了一个很小的内容区域，其他的地方则自动充当边框，从而使内边距显的很大，如下图，

   在这里，我要特别说明，一开始为了增大内边距，很容易惯性思维，在中申明 android:padding="10dip" 之类的，我在这里劝告朋友们不要这么做，一是你将无法预知你的显示，二是这比较混淆，因为设置内容区域就是确定padding，所以我在前面部分说他们是神似。我个人认为通过内容区域设定padding比在布局xml中定义padding更优雅，更简洁！
   关于Draw9Patch工具的其他使用说明，我在次不再累述，因为要说的话太多，为了节省篇幅，请参考官方文档。

5.制作.9.PNG的高级技巧。
对于初学Draw9Patch的人来说，这可以算是高级技巧，那就是：拉伸区域，可以不是连续的，可以不止一块，而且是和自定义的边框线的长度成正比。
直接上图说明：

6.SDK中如何处理9.PNG图片。
SDK专门针对9.PNG做了定义和处理，这里我们只是做个简单的流程分析，Bitmap在读取图像流数据的时候，会把判断图片的 NinePatchChunk(9Patch数据块)，如果NinePatchChunk不为空，则是 NinePatchDrawable，NinePatchDrawable则又会交给NinePatch处理：

`1`	`setNinePatchState(new` `NinePatchState(`

`2`	`new` `NinePatch(bitmap, bitmap.getNinePatchChunk(),` `"XML 9-patch"),`

`3`	`padding, dither), r);`

NinePatch检验成功则调用本地方法，绘制出最终的图片：

`1`	`nativeDraw(canvas.mNativeCanvas, location,`

`2`	`mBitmap.ni(), mChunk, paint !=` `null` `? paint.mNativePaint :` `0,`

`3`	`canvas.mDensity, mBitmap.mDensity);`

7.android系统中大量应用了9.PNG图片。
   通过解压随便一个rom，找到里面的framework_res.apk,里面有大量的9.PNG格式文件，被广泛的应用起来，比如常见的有：
   按钮：
   解锁：
   下拉框：
   标题栏：
   Toast：
   还有搜索，键盘，放大缩小控件，时间加减等等，我就不一一列举。

8.最后送上一些图例，以飨读者，以做后鉴：

赏图1 本人之作

赏图2 下拉按钮

赏图3 文章头部背景

赏图4 系统头部背景

转载于

http://www.cnblogs.com/qianxudetianxia/archive/2011/04/17/2017591.html

建华 2011-11-24 15:00 发表评论

android 保存图片到数据库

建华 — Thu, 17 Nov 2011 06:09:00 GMT

方法一：

Java代码

public void saveIcon(Bitmap icon) {
if (icon == null) {
return;
}
// 最终图标要保存到浏览器的内部数据库中，系统程序均保存为SQLite格式，Browser也不例外，因为图片是二进制的所以使用字节数组存储数据库的
// BLOB类型
final ByteArrayOutputStream os = new ByteArrayOutputStream();
// 将Bitmap压缩成PNG编码，质量为100%存储
icon.compress(Bitmap.CompressFormat.PNG, 100, os);
// 构造SQLite的Content对象，这里也可以使用raw
ContentValues values = new ContentValues();
// 写入数据库的Browser.BookmarkColumns.TOUCH_ICON字段
values.put(Browser.BookmarkColumns.TOUCH_ICON, os.toByteArray());
DBUtil.update(....);//调用更新或者插入到数据库的方法
}

方法二：如果数据表入口时一个content:URI

Java代码

import android.provider.MediaStore.Images.Media;
import android.content.ContentValues;
import java.io.OutputStream;
// Save the name and description of an image in a ContentValues map.
ContentValues values = new ContentValues(3);
values.put(Media.DISPLAY_NAME, "road_trip_1");
values.put(Media.DESCRIPTION, "Day 1, trip to Los Angeles");
values.put(Media.MIME_TYPE, "image/jpeg");
// Add a new record without the bitmap, but with the values just set.
// insert() returns the URI of the new record.
Uri uri = getContentResolver().insert(Media.EXTERNAL_CONTENT_URI, values);
// Now get a handle to the file for that record, and save the data into it.
// Here, sourceBitmap is a Bitmap object representing the file to save to the database.
try {
OutputStream outStream = getContentResolver().openOutputStream(uri);
sourceBitmap.compress(Bitmap.CompressFormat.JPEG, 50, outStream);
outStream.close();
} catch (Exception e) {
Log.e(TAG, "exception while writing image", e);
}

建华 2011-11-17 14:09 发表评论

android 使用contentobserver监听数据库内容变化

建华 — Thu, 27 Oct 2011 14:11:00 GMT

摘要: android 使用contentobserver监听数据库内容变化在android中经常会用到改变数据库内容后再去使用数据库更新的内容，很多人会重新去query一遍，但是这样的问题就是程序会特别占内存，而且有可能会搂关cursor而导致程序内存未释放等等。其实android内部提供了一种ContentObserver的东西来监听数据库内容的变化。ContentObserver的构造函数需要一个参... 阅读全文

建华 2011-10-27 22:11 发表评论

Activity的生命周期

建华 — Wed, 03 Aug 2011 07:41:00 GMT

注意到在Activity的API中有大量的onXXXX形式的函数定义，除了我们前面用到的onCreate以外，还有onStart，onStop以及onPause等等。从字面上看，它们是一些事件回调，那么次序又是如何的呢？其实这种事情，自己做个实验最明白不过了。在做这个实验之前，我们先得找到在Android中的Log是如何输出的。

显然，我们要用的是android.util.log类，这个类相当的简单易用，因为它提供的全是一些静态方法：

Log.v(String tag, String msg);        //VERBOSE
Log.d(String tag, String msg);     //DEBUG
Log.i(String tag, String msg);        //INFO
Log.w(String tag, String msg);   //WARN
Log.e(String tag, String msg);      //ERROR

前面的tag是由我们定义的一个标识，一般可以用“类名_方法名“来定义。
输出的LOG信息，如果用Eclipse+ADT开发，在LogCat中就可以看到，否则用adb logcat也行，不过我是从来都依赖于IDE环境的。

好了，现在我们修改前面的HelloThree代码：

   public void onStart()
    {
        super.onStart();
        Log.v(TAG,"onStart");
    }
    public void onStop()
    {
        super.onStop();
        Log.v(TAG,"onStop");
    }
    public void onResume()
    {
        super.onResume();
        Log.v(TAG,"onResume");
    }
    public void onRestart()
    {
        super.onRestart();
        Log.v(TAG,"onReStart");
    }
    public void onPause()
    {
        super.onPause();
        Log.v(TAG,"onPause");
    }
    public void onDestroy()
    {
        super.onDestroy();
        Log.v(TAG,"onDestroy");
    }
    public void onFreeze(Bundle outState)
    {
        super.onFreeze(outState);
        Log.v(TAG,"onFreeze");
    }

在HelloThreeB中也同样增加这样的代码，编译，运行一下，从logcat中分析输出的日志。
在启动第一个界面Activity One时，它的次序是：
onCreate (ONE) - onStart (ONE) - onResume(ONE)
虽然是第一次启动，也要走一遍这个resume事件。然后，我们点goto跳到第二个Activity Two中（前一个没有关闭），这时走的次序是：
onFreeze(ONE) - onPause(ONE) - onCreate(TWO) - onStart(TWO) - onResume(TWO) - onStop(ONE)
说明，第二个Activity Two在启动前，One会经历一个：冻结、暂停的过程，在启动Two后，One才会被停止？
然后，我们再点back回到第一个界面，这时走的次序是：
onPause(TWO) - onActivityResult(ONE) - onStart(ONE) - onRestart(ONE) - onResume(ONE) - onStop(TWO) - onDestroy(TWO)
说明，返回时，Two没有经历冻结就直接暂停了，在One接收参数，重启后，Two就停止并被销毁了。
最后，我们点一下Exit退出应用，它的次序是：
onPause(ONE) - onStop(ONE) - onDestroy(ONE)
说明如果我们用了finish的话，不会有freeze，但是仍会经历pause - stop才被销毁。

这里有点疑问的是：为什么回来时先是Start才是Restart？可是文档中的图上画的却是先restart再start的啊？不过，后面的表格中的描述好象是正确的，start后面总是跟着resume（如果是第一次）或者restart（如果原来被stop掉了，这种情况会在start与resume中插一个restart）。

下面不跑例子了，看看文档吧。

1.Android用Activity Stack来管理多个Activity，所以呢，同一时刻只会有最顶上的那个Activity是处于active或者running状态。其它的Activity都被压在下面了。

2.如果非活动的Activity仍是可见的（即如果上面压着的是一个非全屏的Activity或透明的Activity），它是处于paused状态的。在系统内存不足的情况下，paused状态的Activity是有可被系统杀掉的。只是不明白，如果它被干掉了，界面上的显示又会变成什么模样？看来下回有必要研究一下这种情况了。

3.几个事件的配对可以比较清楚地理解它们的关系。Create与Destroy配成一对，叫entrie lifetime，在创建时分配资源，则在销毁时释放资源；往上一点还有Start与Stop一对，叫visible lifetime，表达的是可见与非可见这么一个过程；最顶上的就是Resume和Pause这一对了，叫foreground lifetime，表达的了是否处于激活状态的过程。

4.因此，我们实现的Activity派生类，要重载两个重要的方法：onCreate()进行初始化操作，onPause()保存当前操作的结果。

除了Activity Lifecycle以外，Android还有一个Process Lifecycle的说明：

在内存不足的时候，Android是会主动清理门户的，那它又是如何判断哪个process是可以清掉的呢？文档中也提到了它的重要性排序：

1.最容易被清掉的是empty process，空进程是指那些没有Activity与之绑定，也没有任何应用程序组件（如Services或者IntentReceiver）与之绑定的进程，也就是说在这个process中没有任何activity或者service之类的东西，它们仅仅是作为一个cache，在启动新的Activity时可以提高速度。它们是会被优先清掉的。因此建议，我们的后台操作，最好是作成Service的形式，也就是说应该在Activity中启动一个Service去执行这些操作。

2.接下来就是background activity了，也就是被stop掉了那些activity所处的process，那些不可见的Activity被清掉的确是安全的，系统维持着一个LRU列表，多个处于background的activity都在这里面，系统可以根据LRU列表判断哪些activity是可以被清掉的，以及其中哪一个应该是最先被清掉。不过，文档中提到在这个已被清掉的Activity又被重新创建的时候，它的onCreate会被调用，参数就是onFreeze时的那个Bundle。不过这里有一点不明白的是，难道这个Activity被killed时，Android会帮它保留着这个Bundle吗？

3.然后就轮到service process了，这是一个与Service绑定的进程，由startService方法启动。虽然它们不为用户所见，但一般是在处理一些长时间的操作（例如MP3的播放），系统会保护它，除非真的没有内存可用了。

4.接着又轮到那些visible activity了，或者说visible process。前面也谈到这个情况，被Paused的Activity也是有可能会被系统清掉，不过相对来说，它已经是处于一个比较安全的位置了。

5.最安全应该就是那个foreground activity了，不到迫不得已它是不会被清掉的。这种process不仅包括resume之后的activity，也包括那些onReceiveIntent之后的IntentReceiver实例。

在Android Application的生命周期的讨论中，文档也提到了一些需要注意的事项：因为Android应用程序的生存期并不是由应用本身直接控制的，而是由Android系统平台进行管理的，所以，对于我们开发者而言，需要了解不同的组件Activity、Service和IntentReceiver的生命，切记的是：如果组件的选择不当，很有可能系统会杀掉一个正在进行重要工作的进程。

建华 2011-08-03 15:41 发表评论

android 的短信数据库的读取

建华 — Wed, 23 Feb 2011 07:25:00 GMT

android 的短信数据库的读取
android短信的数据库的Uri是不公开的, 读取起来时灰常不方便的, 这里做了下总结.
用adb指令将mmssms.db从/data/data/com.android.providers.telephony/databases中pull出来
经常使用到的表有
canonical_addresses, sms, threads三个表格
sms是存储着所有的短信, 主要的列有_id, thread_id, address, person, date, read, type, body
关于的sms的Uri有
发件箱 content://sms/outbox
收件箱 content://sms/inbox
草稿箱 content://sms/draft
conversations content://sms/conversations
threads表存储着每一个短信对话的线程. 主要列有_id, date, message_count, recipient_ids, snippet, read
recipient_ids 存放的是参与此次对话的person的id, 然而这个id不是通讯录里面的id, 而是canonical_addresses 的id. 这就是canonical_addresses 表格的作用
threads 表 uri: content://mms-sms/conversations?simple=true
canonical_addresses 表 uri content://mms-sms/canonical-addresses

建华 2011-02-23 15:25 发表评论