13518219792
Android的Glide在加载图片时候内部默认使用了缓存机制，Glide的缓存机制分为两级，第一级是内存缓存，然后第二级是硬盘缓存。缓存的过程首先是在内存中缓存，然后将加载的图片资源缓存到硬盘，这样就可以在随后的再次加载中使用缓存了，Glide使用缓存时候首先要检查内存这一层级是否缓存了相应的缓存，如果有，则直接使用，如果没有，则深入到硬盘缓存中检查是否有，如果有，则加载之，如果到这一步骤还没有，那么就只能作为一个全新的资源加载了。
创新互联建站坚持“要么做到，要么别承诺”的工作理念，服务领域包括：成都网站设计、成都做网站、外贸网站建设、企业官网、英文网站、手机端网站、网站推广等服务，满足客户于互联网时代的喀喇沁网站设计、移动媒体设计的需求，帮助企业找到有效的互联网解决方案。努力成为您成熟可靠的网络建设合作伙伴！
安卓图片的缓存可以根据当前日期,时间为名字缓存到SD卡中的指定图片缓存目录, 同时数据库中做相应记录,记录办法可以采用两个关键字段控制,一个字段是该图片的URL地址,另一个字段是该图片的本机地址.取图片时根据URL在数据中检索,如果没有则连接服务器下载,下载之后再服务器中作出相应记录.
共有七个周期函数，按顺序分别是: onCreate(), onStart(), onRestart(), onResume(), onPause(),onStop(), onDestroy()。
onCreate(): 创建Activity时调用，设置在该方法中，还以Bundle的形式提供对以前存储的任何状态的访问。
onStart(): Activity变为在屏幕上对用户可见时调用。
onResume(): Activity开始与用户交互时调用(无论是启动还是重新启动一个活动，该方法总是被调用。
onPause(): Activity被暂停或收回cpu和其他资源时调用，该方法用户保护活动状态的，也是保护现场。
onStop(): Activity被停止并转为不可见阶段及后续的生命周期事件时调用。
onRestart(): Activity被重新启动时调用。该活动仍然在栈中，而不是启动新的Activity。
1、完整生命周期: 即从一个Activity从出现到消失，对应的周期方法是从onCreate()到onDestroy()。
2、可见生命周期: 当Activity处于可以用户看见的状态，但不一定能与用户交互时，将多次执行从onStart()到onStop()。
3、前景生命周期: 当Activity处于Activity栈最顶端，能够与其他用户进行交互时，将多次执行从onResume()到onPause()。
2. 两个Activity之间跳转时必然会执行的是哪几个方法。
答: 两个Activity之间跳转必然会执行的是下面几个方法。
onCreate()//在Activity生命周期开始时调用。
onRestoreInstanceState()//用来恢复UI状态。
onRestart()//当Activity重新启动时调用。
onStart()//当Activity对用户即将可见时调用。
onResume()//当Activity与用户交互时，绘制界面。
onSaveInstanceState()//即将移出栈顶保留UI状态时调用。
onPause()//暂停当前活动Activity，提交持久数据的改变，停止动画或其他占用GPU资源的东西，由于下一个Activity在这个方法返回之前不会resume，所以这个方法的代码执行要快。
onStop()//Activity不再可见时调用。
onDestroy()//Activity销毁栈时被调用的最后一个方法。
3. 横竖屏切换时候Activity的生命周期。
答:
1、不设置Activity的android: configChanges时，切屏会重新调用各个生命周期，切横屏时会执行一次，切竖屏时会执行两次。
2、设置Activity的android: configChanges=“orientation”时，切屏还是会重新调用各个生命周期，切横、竖屏时只会执行一次。
3、设置Activity的android: configChanges=“orientation|keyboardHidden”时，切屏不会重新调用各个生命周期，只会执行onConfiguration方法
4. 如何将一个Activity设置成窗口的样式。
答: 第一种方法，在styles.xml文件中，可以新建如下的类似Dialog的style。
style name=“Theme.FloatActivity” parent=“android:style/Theme.Dialog” /style。
第二种方法，在AndroidManifest.xml中在需要显示为窗口的Activity中添加如下属性: android: theme=“@style/Theme.FloatActivity”即可。也可以直接添加对应需要展示为Dialog style的Activity的android: theme属性为android: theme=“@ android: style/Theme.Dialog”。
5. 两个Activity之间怎么传递数据？
答: 可以在Intent对象中利用Extra来传递存储数据。
在Intent的对象请求中，使用putExtra(“键值对的名字”，”键值对的值”)；在另外一个Activity中将Intent中的请求数据取出来:
Intent intent = getIntent();
String value = intent.getStringExtra(“testIntent”);
6. 怎么让在启动一个Activity是就启动一个service？
答: 首先定义好一个service，然后在Activity的onCreate里面进行连接并bindservice或者直接startService。
7. Activity怎么和service绑定，怎么在activity中启动自己对应的service？
答:
1、activity能进行绑定得益于Serviece的接口。为了支持Service的绑定，实现onBind方法。
2、Service和Activity的连接可以用ServiceConnection来实现。需要实现一个新的ServiceConnection，重现onServiceConnected和OnServiceDisconnected方法，一旦连接建立，就能得到Service实例的引用。
3、执行绑定，调用bindService方法，传入一个选择了要绑定的Service的Intent(显示或隐式)和一个你实现了的ServiceConnection的实例
8.什么是Service以及描述下它的生命周期。Service有哪些启动方法，有什么区别，怎样停用Service？
答: Android Service是运行在后台的代码，不能与用户交互，可以运行在自己的进程，也可以运行在其他应用程序进程的上下文里。需要通过某一个Activity或者Context对象来调用。Service有两个启动方法，分别是Context.startService()和Context.bindService()。如果在Service执行耗时的操作需要启动一个新线程来执行。
Android Service只继承了onCreate(), onStart(),onDestroy()三个方法，当我们第一次启动Service时，先后调用onCreate(), onStart()这两个方法，当停止Service时，则执行onDestroy()方法时。如果Service已经启动了，当我们再次启动Service时，不会再执行onCreate()方法，而是直接执行onStart()方法。
9. 什么时候使用Service？
答: 比如播放多媒体的时候，用户启动了其他Activity，这个时候程序要在后台继续播放，比如检测SD卡上文件的变化，再或者在后台记录你的地理信息位置的改变等等。
10. 请描述一下Intent 和 Intent Filter。
答: Intent在Android中被翻译为”意图”，他是三种应用程序基本组件-Activity，Service和broadcast receiver之间相互激活的手段。在调用Intent名称时使用ComponentName也就是类的全名时为显示调用。这种方式一般用于应用程序的内部调用，因为你不一定会知道别人写的类的全名。而Intent Filter是指意图过滤，不出现在代码中，而是出现在android Manifest文件中，以intent-filter的形式。（有一个例外是broadcast receiver的intent
filter是使用Context.registerReceiver()来动态设定的，其中intent filter也是在代码中创建的）
一个intent有action，data，category等字段。一个隐式intent为了能够被某个intent filter接收，必须通过3个测试，一个intent为了被某个组件接收，则必须通过它所有的intent filter中的一个。
11. Intent传递数据时，可以传递哪些类型数据？
答: intent间传送数据一般有两种常用的方法: 1、extra 2、data。
extra可以用Intent.putExtra放入数据。新启动的Activity可用Intent.getExtras取出Bundle，然后用Bundles.getLong,getInt,getBoolean,getString等函数来取放进去的值。
Data则是传输url。url可以是指我们熟悉的http，ftp等网络地址，也可以指content来指向ContentProvider提供的资源。Intent.setData可以放入数据，Intent.getData可以取出数据。
12. 说说Activity，Intent，Service是什么关系 ？
答: 一个Activity通常是一个单独的屏幕，每一个Activity都被实现为一个单独的类，这些类都是从Activity基类中继承而来的。Activity类会显示由视图控件组成的用户接口，并对视图控件的事件做出响应。
Intent的调用是用来进行屏幕之间的切换。Intent描述应用想要做什么。Intent数据结构中两个最重要的部分是动作和动作对应的数据，一个动作对应一个动作数据。
Service是运行在后台的代码，不能与用户交互，可以运行在自己的进程里，也可以运行在其他应用程序进程的上下文里。需要一个Activity或者其他Context对象来调用。
Activity跳转Activity，Activity启动Service，Service打开Activity都需要Intent表明意图，以及传递参数，Intent是这些组件间信号传递的承载着。
13. 请描述一下BroadcastReceiver。
答: Broadcast Receiver用于接收并处理广播通知(broadcast announcements)。多数的广播是系统发起的，如地域变换、电量不足、来电短信等。程序也可以播放一个广播。程序可以有任意数量的broadcast receivers来响应它觉得重要的通知。Broadcast receiver可以通过多种方式通知用户: 启动activity、使用NotificationManager、开启背景灯、振动设备、播放声音等，最典型的是在状态栏显示一个图标，这样用户就可以点它打开看通知内容。通常我们的某个应用或系统本身在某些事件(电池电量不足、来电短信)来临时会广播一个Intent出去，我们利用注册一个broadcast
receiver来监听这些Intent并获取Intent中的数据。
14. 在manifest和代码中如何注册和使用 broadcast receiver 。
答: 在android的manifest中注册
receiver android: name =“Receiver1”
intent-filter
!----和Intent中的action对应---
actionandroid: name=“com.forrest.action.mybroadcast”/
/intent-filter
/receiver
在代码中注册
1、 IntentFilter filter = new IntentFilter(“com.forrest.action.mybroadcast”);//和广播中Intent的action对应;
2、 MyBroadcastReceiver br= new MyBroadcastReceiver();
3、 registerReceiver(br, filter);
15. 请介绍下ContentProvider是如何实现数据共享的。
答: 一个程序可以通过实现一个Content provider的抽象接口将自己的数据完全暴露出去，而且Content provider是以类似数据库中的表的方式将自己的数据暴露。Content provider存储和检索数据，通过它可以让所有的应用程序访问到，这也是应用程序之间唯一共享数据的方法。
要想使应用程序的数据公开化，可通过2种方法：创建一个数据自己的Content Provider或者将你的数据添加到一个已经存在的Content Provider中，前提是有相同数据类型并且有写入Content Provider的权限，Android提供了Content Resolverr，外界的程序可以通过Content Resolver接口访问Content Provider提供的数据。
16. 请介绍下Android的数据存储方式。
答: Android提供了5中存储数据的方式，分别是以下几种
1、使用Shared Preferences存储数据，用来存储key-value，pairs格式的数据，它是一个轻量级的键值存储机制，只可以存储基本数据类型。
2、使用文件存储数据，通过FileInputStream和FileOutputStream对文件进行操作。在Android中，文件是一个应用程序私有的，一个应用程序无法读写其他应用程序的文件。
3、使用SQLite数据库存储数据，Android提供的一个标准数据库，支持SQL语句。
4、使用Content Provider存储数据，是所有应用程序之间数据存储和检索的一个桥梁，它的作用就是使得各个应用程序之间实现数据共享。它是一个特殊的存储数据的类型，它提供了一套标准的接口用来获取数据，操作数据。系统也提供了音频、视频、图像和个人信息等几个常用的Content Provider。如果你想公开自己的私有数据，可以创建自己的Content Provider类，或者当你对这些数据拥有控制写入的权限时，将这些数据添加到Content Provider中实现共享。外部访问通过Content Resolver去访问并操作这些被暴露的数据。
5、使用网络存储数据
17. 请介绍下Android中常用的五种布局。
答: 最常用的布局方式为Absolute Layout、Relative Layout、Linear Layout、FrameLayout、TableLayout。其中Linear Layout和Relative Layout是最常用的方式，他们可以通过在xml配置文件或者代码中进行布局。
1、Frame Layout是最简单的布局方式，放置的控件都只能罗列到左上角，控件会有重叠，不能进行复杂的布局。
2、Linear Layout可以通过orientation属性设置线性排列的方向是垂直还是纵向的,每行或每列只有一个元素，可以进行复杂的布局。
3、Absolute Layout可以让子元素指定准确的x、y坐标值，并显示在屏幕上。Absolute Layout没有页边框，允许元素之间相互重叠。它是绝对坐标，所以在实际中不提倡使用。
4、Relative Layout允许子元素制定他们相对于其他元素或父元素的位置(通过ID制定)。因此，你可以以右对齐，或上下，或置于屏幕中央的形式来排列两个元素。元素按顺序排列，因此如果第一个元素在屏幕的中央，那么相对于这个元素的其他元素将以屏幕中央的相对位置来排列。这个是相对于Absolute Layout的，采用相对坐标，所以在实际中比较常用。
5、Table Layout将以子元素的位置分配到行或列。一个Table Layout由许多的Table Row组成，每个Table Row都会定义一个row。Table Layout容器不会显示row、column或者cell的边线框。每个row拥有0个或多个的cell； 和html中的table差不多。在实际中也经常使用。
18. 谈谈UI中， Padding和Margin有什么区别？
答: Padding是控件的内容相对控件的边缘的边距，而Margin是控件边缘相对于其他控件的边距。如下图所示：
19. android本身的一些限制，比如apk包大小限制，读取大文件时的时间限。
答：apk包大小限制不好说，有的apk为100M，还是能装到手机上。一般的apk大小为5~10M左右。读取大文件的时间应该是在main线程里面，时间限制为5秒左右。
20. ListView如何提高其效率？
答:1、使用分页加载，不要一次性加载所有数据。
2、复用convertView。在getItemView中，判断converView是否为空，如果不为空，可复用。
3、异步加载图片。Item中如果包含有webimage，那么最好异步加载。
4、快速滑动时，不显示图片。当快速滑动列表(SCROLL_STATE_FLING)，item中的图片或获取需要消耗资源的view，可以不显示出来；而处于其他两种状态(SCROLL_STATE_IDLE和SCROLL_STATE_TOUCH_SCROLL)，则将那些view显示出来
写入文件上也可以，你在sd卡上创建一个文件，写入其中也是可以的，这样还可以保存好数据。如果写入缓存中也不是不行但是如果忽然关机啥的程序退出，或者有其他程序调用缓存的就可能出错，所以如果不是必须的话不要直接存入缓存中。还有就是如果数据十分小就几个字符串或数字啥的我想你也知道应该放到SharedPreferences中。
UI 优化系列专题，来聊一聊 Android 渲染相关知识，主要涉及 UI 渲染背景知识 、 如何优化 UI 渲染 两部分内容。
《 View 绘制流程之 setContentView() 到底做了什么？ 》
《 View 绘制流程之 DecorView 添加至窗口的过程 》
《 深入 Activity 三部曲（3）View 绘制流程 》
《 Android 之 LayoutInflater 全面解析 》
《 关于渲染，你需要了解什么？ 》
《 Android 之 Choreographer 详细分析 》
《 Android 之如何优化 UI 渲染（上） 》
《 Android 之如何优化 UI 渲染（下） 》
现在我们已经很少能够听到关于 Android UI 卡顿的话题了，这得益于 Google 长期以来对 Android 渲染性能的重视，基本每次 Google I/O 都会花很多篇幅讲这一块。随着时间的推移，Android 系统一直在不断进化、壮大，并且日趋完善。
其中，Google 在 2012 年的 I/O 大会上宣布了 Project Butter 黄油计划，那个曾经严重影响 Android 口碑的 UI 流程性问题，首先在这得到有效的控制，并且在 Android 4.1 中正式开启了这个机制。
Project Butter 对 Android Display 系统进行了重构，引入了三个核心元素，即 VSYNC 、 Triple Buffer 和 Choreographer 。
其中 VSYNC 是理解 Project Butter 的核心。接下来，我们就围绕 VSYNC 开始介绍 Project Butter 对 Android Display 系统做了哪些优化。
VSYNC 最初是由 GPU 厂商开发的一种，用于防止屏幕撕裂的技术方案，全称 Vertical Synchronization，该方案很早就已经被广泛应用于 PC 上。我们可以把它理解为一种时钟中断。
VSYNC 是一种图形技术，它可以同步 GPU 的 帧速率 和显示器的 刷新频率 ，所以在理解 VSYNC 产生的原因及其作用之前，我们有必要先来了解下这两个概念。
表示屏幕在一秒内刷新画面的次数， 刷新频率取决于硬件的固定参数，单位 Hz（赫兹）。例如常见的 60 Hz、144 Hz，即每秒钟刷新 60 次或 144 次。
逐行扫描
显示器并不是一次性将画面显示到屏幕上，而是从左到右边，从上到下逐行扫描显示，不过这一过程快到人眼无法察觉到变化。以 60 Hz 刷新率的屏幕为例，即 1000 / 60 ≈ 16ms。
表示 GPU 在一秒内绘制操作的帧数，单位 fps。例如在电影界采用 24 帧的速度足够使画面运行的非常流畅。而 Android 系统则采用更加流程的 60 fps，即每秒钟绘制 60 帧画面。更多内容参考《 Why 60 fps 》。
现在，刷新频率和帧率需要一起合作，才能使图形内容呈现在屏幕上，GPU 会获取图形数据进行绘制， 然后硬件负责把图像内容呈现到屏幕上，这一过程在应用程序的生命周期内一遍又一遍的发生。
如上图，CPU / GPU 生成图像的 Buffer 数据，屏幕从 Buffer 中读取数据刷新后显示。理想情况下帧率和刷新频率保持一致，即每绘制完成一帧，显示器显示一帧。不幸的是，刷新频率和帧率并不总是能够保持相对同步，如果帧速率实际比刷新率快，例如帧速率是 120 fps，显示器的刷新频率为 60 Hz。此时将会发生一些视觉上的问题。
当 GPU 利用一块内存区域写入一帧数据时，从顶部开始新一帧覆盖前一帧，并立刻输出一行内容。当屏幕刷新时，此时它并不知道图像缓冲区的状态，因此从缓冲区抓取的帧并不是完整的一帧画面（绘制和屏幕读取使用同一个缓冲区）。此时屏幕显示的图像会出现上半部分和下半部分明显偏差的现象，这种情况被称之为 “tearing”（屏幕撕裂）。
那如何防止 “tearing” 现象的发生呢？由于图像绘制和读取使用的是同一个缓冲区，所以屏幕刷新时可能读取到的是不完整的一帧画面。解决方案是采用 Double Buffer。
Double Buffer（双缓冲）背后的思想是让绘制和显示器拥有各自的图像缓冲区。GPU 始终将完成的一帧图像数据写入到 Back Buffer ，而显示器使用 Frame Buffer ，当屏幕刷新时，Frame Buffer 并不会发生变化，Back Buffer 根据屏幕的刷新将图形数据 copy 到 Frame Buffer，这便是 VSYNC 的用武之地。
在 Android 4.1 之前，Android 便使用的双缓冲机制。怎么理解呢？一般来说，在同一个 View Hierarchy 内的不同 View 共用一个 Window，也就是共用同一个 Surface。
每个 Surface 都会有一个 BufferQueue 缓存队列，但是这个队列会由 SurfaceFlinger 管理，通过匿名共享内存机制与 App 应用层交互。
整个流程如下：
但是 UI 绘制任务可能会因为 CPU 在忙别的事情，导致没来得及处理。所以 从 Android 4.1 开始， VSYNC 则更进一步，现在 VSYNC 脉冲信号开始用于下一帧的所有处理 。
Project Butter 首先对 Android Display 系统的 SurfaceFlinger 进行了改造，目标是提供 VSYNC 中断。每收到 VSYNC 中断后，CPU 会立即准备 Buffer 数据，由于大部分显示设备刷新频率都是 60 Hz（一秒刷新 60 次），也就是说一帧数据的准备工作都要在 16ms 内完成。
这样应用总是在 VSYNC 边界上开始绘制，而 SurfaceFlinger 总是在 VSYNC 边界上进行合成。这样可以消除卡顿，并提升图形的视觉表现。
如果理解了双缓冲机制的原理，那就非常容易理解什么是三缓冲区了。如果只有两个 Graphic Buffer 缓冲区 A 和 B，如果 CPU / GPU 绘制过程较长，超过一个 VSYNC 信号周期。
由上图可知：
为什么 CPU 不能在第二个 16ms 处理绘制工作呢？原因是只有两个 Buffer，缓冲区 B 中的数据还没有准备完成，所以只能继续展示 A 缓冲区的内容，这样缓冲区 A 和 B 都分别被显示设备和 GPU 占用，CPU 则无法准备下一帧的数据。如果再提供一个缓冲区，CPU、GPU 和显示设备都能使用各自的缓冲区工作，互不影响。
简单来说，三重缓冲机制就是在双缓冲机制基础上增加了一个 Graphic Buffer 缓冲区，这样可以最大限度的利用空闲时间，带来的坏处是多使用的一个 Graphic Buffer 所占用的内存。
由上图可知：
Choreographer 也是 Project Butter 计划新增的机制，用于配合系统的 VSYNC 中断信号。它本质是一个 Java 类，如果直译的话为舞蹈指导，这是一个极富诗意的表达，看到这个词不得不赞叹设计者除了 Coding 之外的广泛视野。舞蹈是有节奏的，节奏使舞蹈的每个动作更加协调和连贯；视图刷新也是如此。
Choreographer 可以接收系统的 VSYNC 信号，统一管理应用的输入、动画和绘制等任务的执行时机。Android 的 UI 绘制任务将在它的统一指挥下，井然有序的完成。业界一般通过它来监控应用的帧率。
Choreographer 的构造方法：
优先级的高低和处理顺序有关。当收到 VSYNC 信号时，Choreographer 将首先处理 INPUT 类型的回调，然后 ANIMATION 类型，最后才是 TRAVERSAL 类型。
另外，Android 在 4.1 还对 Handler 机制进行了略微改造，使之支持 Asynchronous Message（异步消息） 和 Synchronization Barrier（同步屏障）。一般情况下同步消息和异步消息的处理方式并没有什么区别，只有在设置了 同步屏障 时才会出现差异。 同步屏障为 Handler 消息机制增加了一种简单的优先级关系，异步消息的优先级要高于同步消息 。简单点说，设置了同步屏障之后，Handler 只会处理异步消息。
以 View 的绘制流程为例：
scheduleTraversals 首先禁止了后续消息的处理能力，一旦设置了消息队列的 postSyncBarrier，所有非 Asynchronous 的消息将被停止派发。
UI 绘制任务设置了 CALLBACK 类型为 TRAVERSAL 类型的任务，即 mTraversalRunnable：
Choreographer 的 postCallback 方法将会申请一次 VSYNC 中断信号，通过 DisplayEventReceiver 的 scheduleVsync 方法。当 VSYNC 信号到达时，便会回调 Choreographer 的 doFrame 方法，内部会触发已经添加的回调任务：
此时 UI 绘制任务 doTraversal 方法被回调，即在 Android 4.1 之后， UI 绘制任务被放置到了 VSYNC 中断处理中了。Choreographer 确实做到了统一协调管理 UI 的绘制工作。有关 Choreographer 更详细的分析，可以参考《 Android 之 Choreographer 详细分析 》。
在从根本解决 Android UI 不流畅的问题上，Project Butter 黄油计划率先迈出了最重要一步，Android 的渲染性能也确实有了很大改善。
不过优化是无止境的，Google 在后续版本中又引入了一些比较大的改变，例如 Android 5.0 的 RenderThread，Android 将所有的绘制任务都放到了该线程，这样即便主线程有耗时的操作也可以保证动画流畅性。
关于 UI 渲染所涉及的内容非常多，而且 Android 渲染框架演进的非常快，文章最后也会附上一些扩展资料，便于更好的学习理解。
文中如有不妥或有更好的分析结果，欢迎您的留言或指正。文章如果对你有帮助，请留个赞吧。
其他系列专题
无论大型或小型应用，灵活的缓存可以说不仅大大减轻了服务器的压力，而且因为更快速的用户体验而方便了用户。
Android的apk可以说是作为小型应用，其中99%的应用并不是需要实时更新的，而且诟病于蜗牛般的移动网速，与服务器的数据交互是能少则少，这样用户体验才更好，这也是我们有时舍弃webview而采用json传输数据的原因之一。
采用缓存，可以进一步大大缓解数据交互的压力，特此，我们简略列举一下缓存管理的适用环境：
1. 提供网络服务的应用
2. 数据更新不需要实时更新，但是哪怕是3-5分钟的延迟也是可以采用缓存机制。
3. 缓存的过期时间是可以接受的(不会因为缓存带来的好处，导致某些数据因为更新不及时而影响产品的形象等)
带来的好处：
1. 服务器的压力大大减小
2. 客户端的响应速度大大变快(用户体验)
3. 客户端的数据加载出错情况大大较少，大大提高了应有的稳定性(用户体验)
4. 一定程度上可以支持离线浏览(或者说为离线浏览提供了技术支持)
一、缓存管理的方法
这里的缓存管理的原理很简：通过时间的设置来判断是否读取缓存还是重新下载。
里面会有一些细节的处理，后面会详细阐述。
基于这个原理，目前鄙人见过的两种比较常见的缓存管理方法是:数据库法和文件法。
二、数据库法缓存管理
这种方法是在下载完数据文件后，把文件的相关信息如url，路经，下载时间，过期时间等存放到数据库，下次下载的时候根据url先从数据库中查询，如果查询到当前时间并未过期，就根据路径读取本地文件，从而实现缓存的效果。
从实现上我们可以看到这种方法可以灵活存放文件的属性，进而提供了很大的扩展性，可以为其它的功能提供一定的支持；
从操作上需要创建数据库，每次查询数据库，如果过期还需要更新数据库，清理缓存的时候还需要删除数据库数据，稍显麻烦，而数据库操作不当又容易出现一系列的性能，ANR问题，实现的时候要谨慎，具体作的话，但也只是增加一个工具类或方法的事情。
还有一个问题，缓存的数据库是存放在/data/data/package/databases/目录下，是占用内存空间的，如果缓存累计，容易浪费内存，需要及时清理缓存。
当然这种方法从目前一些应用的实用上看，我没有发现什么问题。
本文我侧重强调第二种方法，第一种方法的实现，就此掠过。
三、文件法缓存管理
这种方法，使用File.lastModified()方法得到文件的最后修改时间，与当前时间判断是否过期，从而实现缓存效果。
实现上只能使用这一个属性，没有为其它的功能提供技术支持的可能。
操作上倒是简单，比较时间即可。本身处理也不容易带来其它问题，代价低廉。
四、文件法缓存管理的两点说明
1. 不同类型的文件的缓存时间不一样。
笼统的说，不变文件的缓存时间是永久，变化文件的缓存时间是最大忍受不变时间。
说白点，图片文件内容是不变的，直到清理，我们是可以永远读取缓存的。
配置文件内容是可能更新的，需要设置一个可接受的缓存时间。
2. 不同环境下的缓存时间标准不一样。
无网络环境下，我们只能读取缓存文件，哪怕缓存早就过期。
WiFi网络环境下，缓存时间可以设置短一点，一是网速较快，而是流量不要钱。
移动数据流量环境下，缓存时间可以设置长一点，节省流量，就是节省金钱，而且用户体验也更好。
举个例子吧，最近本人在做的一个应用在wifi环境下的缓存时间设置为5分钟，移动数据流量下的缓存时间设置为1小时。
这个时间根据自己的实际情况来设置：数据的更新频率，数据的重要性等。
五、何时刷新
开发者一方面希望尽量读取缓存，用户一方面希望实时刷新，但是成都网站制作响应速度越快越好，流量消耗越少越好，是一个矛盾。
其实何时刷新我也不知道，这里我提供两点建议：
1. 数据的最长多长时间不变，对应用无大的影响。
比如，你的数据更新时间为1天，则缓存时间设置为4~8小时比较合适，一天他总会看到更新，如果你觉得你是资讯类应用，再减少，2~4小时，如果你觉得数据比较重要或者比较受欢迎，用户会经常把玩，再减少，1~2小时，依次类推。
为了保险起见，你可能需要毫无理由的再次缩减一下。
2. 提供刷新按钮。
上面说的保险起见不一定保险，最保险的方法使在相关界面提供一个刷新按钮，为缓存，为加载失败提供一次重新来过的机会，有了这个刷新按钮，我们的心也才真的放下来。
