android 数据管理,Android中的数据管理

概述

我们知道，一个应用无非是由UI、逻辑、数据所构成，数据在应用中的地位举足重轻。我们讨论数据需要讨论数据的来源，数据保持(存储)，数据的销毁等生命周期的管理。数据是有时效性的，也就是说，数据存在的时间是不同的，有的可以持久保存，比如说历史登录账户，有的是跟应用周期等同，比如应用的配置数据，有的只在应用的部分时期内，比如用户登录后的sessionId等。

本文将介绍数据的存储管理，根据数据存储的介质，可以分为ram cache(内存缓存)，以及persistence store(持久化存储)，我们主要讨论下数据在内存中的缓存。

在android中，我们根据平台的特性以及数据的生命周期，一般划分局部数据和全局数据。

局部数据

一般跟android的组件生命周期等同的数据，我们把它归属为局部数据。比如activity中的数据，service中的数据等。局部数据伴随着组件的消亡而消亡。

全局数据

全局数据是application生命周期的数据，它一般是跨几个组件的数据，比如说是多个activity共享的数据。比如说用户的sessionId，其中一个组件改变了数据，其他组件应当立马得到新的数据，这就需要保证全局数据只应该有一份拷贝。

一般的，我们可以使用单例，或者直接在Application中持有全局数据。但实际上，全局数据也不完全是整个应用生命周期都需要存在的数据，比如很多用户的数据是需要用户登录后才需要存在的，这样的数据使用单例就不是特别的好了(因为单例的生命周期是跟类加载器一致的，也就是说和dalvik实例一致，当然如果显式的去管理生命周期也没什么问题)，所以，我们一般会通过application来引用全局数据。

当进程被重启的时候

在android环境中，我们知道有许多第三方的应用(比如进程查杀器，360安全卫士等)可以直接kill进程，特别的，在4.0的系统里，更是在开发人员设置里增加了一些设置(比如不保存当前活动)，这样数据的生命周期管理更增加了许多的复杂度。

在android中，一个进程被重启后，它的数据将会被重新的初始化。但对于activity以及一些View，android提供了onSaveInstanceState，onRestoreInstanceState等回调方法来处理数据的连贯性，因为对于android来说，进程被kill了，但activity records会被保存，也就是说应用重启后还可以回到最后停留的activity，保持用户体验的连贯性。这些机制，类似于wp7的墓碑化。

下面分别来讨论下局部数据和全局数据的保存和恢复。

局部数据的保存和恢复

如果是activity组件中的局部数据，我们完全可以遵循android的机制，也就是在onSaveInstanceState中保存数据，在onRestoreInstanceState恢复数据。如果是service的局部数据，就不需要保存了吧，直接全部重新初始化。

全局数据的保存和恢复

全局数据的保存和恢复比较棘手。因为目前我们没法感知application的墓碑化，也就是说android没有提供相应的回调方法。有以下思考： - 持久化全局数据，每次写(set)数据的时候，都及时同步到persistence store，每次读(get)数据的时候都需要保证数据不是脏数据，是最新的数据 - 对应用需要有显式的退出，在退出的时候清除相应的全局数据 - 数据的安全？比如说sessionId是否可以持久化存储

缓存

此处说的缓存是只内存的缓存。

对于android的数据缓存，我们需要对数据类型做不同的区分对待。比如说文本，多媒体(图片对android来说有独立的存储空间，而且非常容易造成OOM)，可以分别对他们做个缓存池(LRU)，当内存不足的时候可以把使用的少的一些数据持久化。缓存应该对使用者透明。

持久化

android支持的持久化方式有sqlite,shareprefrence,file。对于k-v的，而且数据量不大的尽量考虑shareprefrence。

content provider

可以考虑用content provider来做数据提供者，把网络请求什么的都封装起来。

-EOF-

supern lee(sanping.li#alipay.com)