何时在Android中清除缓存目录?


77

我有一个显示来自互联网的图片的应用程序(用于设计师工作的展示柜)。我开始在内部缓存目录中缓存我的内容,但是应用程序内容可能需要约150 MB的缓存大小。以及android docs怎么说:

您应该始终自己维护高速缓存文件,并保持在合理的空间消耗限制内,例如1MB。当用户卸载您的应用程序时,这些文件将被删除。

因此,我看了一下Currents应用程序(Galaxy Nexus),该应用程序的缓存大小为110 MB。但是奇怪的是,诸如Google Currents和Google Maps之类的应用程序将内容缓存在称为(USB Storage Data)的内容中:

在此处输入图片说明

那么以前的应用程序使用的“ USB存储数据”是什么。而且,如果您在应用程序中实现了缓存,是否需要在缓存中循环所有应用程序文件,以便在每次需要插入内容然后进行比较和清除时获取大小?还是在Android决定清理某个应用程序缓存目录的时间之前一直缓存内容?

我真的很想知道在Android中管理缓存的流程是什么,或者至少是其他应用程序对要缓存的大内容做了什么。


我想USB存储数据是保存在SD中的缓存。我认为,最终用户应在首选项活动中选择高速缓存的大小,并删除最后访问的文件以保持限制。
DanielArgüelles2012年

5
在计算机科学中只有两件难事:缓存无效和命名。-Phil Karlton
桑福德2014年

1
@msanford您知道更难吗?闭幕式……
varun

Answers:


203

在回答您的问题之前,这里简要介绍两种存储类型:

快取

这是文件系统上特定于应用程序的目录。该目录的目的是存储临时数据,您的应用程序可能需要在会话之间保留这些临时数据,但对于永久保留这些数据可能并不重要。通常,您可以使用访问此目录Context.getCacheDir()。这将在您的应用设置上显示为“缓存”。

档案

与缓存目录一样,您的应用程序还具有一个特定于应用程序的目录,用于保存文件。该目录中的文件将一直存在,直到应用程序将其明确删除或将其卸载为止。通常,您可以使用访问此目录Context.getFilesDir()。这可以显示为应用程序信息屏幕上的各种内容,但是在屏幕快照中,这是“ USB存储数据”。

注意:如果要显式放置在外部介质(通常是SD卡)上,则可以使用Context.getExternalFilesDir(String type)

区别

这两个目录仅特定于您的应用程序(其他应用程序无权访问)。缓存和文件目录之间的区别之一是,如果系统存储空间不足,则要释放资源的第一个位置是来自缓存目录。系统不会从文件目录中清除任何数据。另一个区别是,通常可以从应用程序信息屏幕中手动清除缓存目录。文件目录通常也可以,但是清除文件目录也将清除缓存目录。

我要使用哪一个?

这取决于将数据与应用程序生命周期进行比较的重要性。如果您只需要一个会话的数据,并且怀疑是否需要再次使用该数据,则不要使用任何一个。只需将其保留在内存中,直到不需要它为止。如果你怀疑你需要重复使用多个会话之间的数据,但你不具备继续硬拷贝,使用缓存目录。如果无论如何都必须具有此数据,或者需要持久存储的是相当大的数据,请使用files目录。这是我能想到的一些示例:

  • 缓存-最近打开的电子邮件
    • 打开后,缓存数据,以便当用户想要再次阅读该电子邮件时,它立即加载,而不是再次使用网络来检索相同的数据。我不需要永远保留此地址,因为最终用户将可以使用该电子邮件。
  • 文件-从电子邮件下载的附件
    • 这是用户说的“我想保留此数据,以便可以在需要时将其备份”的操作。因此,将其放在文件目录中,因为在用户希望删除该文件之前,我永远不想删除该文件。

什么时候应该清除缓存目录?

Context.getCacheDir()javadocs:

注意:您不应该依赖系统为您删除这些文件;您应该始终为缓存文件占用的空间量有一个合理的最大值,例如1 MB,并在超出该空间时修剪这些文件。

它以1 MB为例,但对于您的应用而言可能合理,也可能不合理。无论如何,您都需要设置一个硬最大值。这样做的原因仅仅是设计一个负责任的应用程序。那你什么时候应该检查?我建议您每次想在缓存目录中放入内容时进行检查。这是一个非常简单的缓存管理器:

public class CacheManager {

    private static final long MAX_SIZE = 5242880L; // 5MB

    private CacheManager() {

    }

    public static void cacheData(Context context, byte[] data, String name) throws IOException {

        File cacheDir = context.getCacheDir();
        long size = getDirSize(cacheDir);
        long newSize = data.length + size;

        if (newSize > MAX_SIZE) {
            cleanDir(cacheDir, newSize - MAX_SIZE);
        }

        File file = new File(cacheDir, name);
        FileOutputStream os = new FileOutputStream(file);
        try {
            os.write(data);
        }
        finally {
            os.flush();
            os.close();
        }
    }

    public static byte[] retrieveData(Context context, String name) throws IOException {

        File cacheDir = context.getCacheDir();
        File file = new File(cacheDir, name);

        if (!file.exists()) {
            // Data doesn't exist
            return null;
        }

        byte[] data = new byte[(int) file.length()];
        FileInputStream is = new FileInputStream(file);
        try {
            is.read(data);
        }
        finally {
            is.close();
        }

        return data;
    }

    private static void cleanDir(File dir, long bytes) {

        long bytesDeleted = 0;
        File[] files = dir.listFiles();

        for (File file : files) {
            bytesDeleted += file.length();
            file.delete();

            if (bytesDeleted >= bytes) {
                break;
            }
        }
    }

    private static long getDirSize(File dir) {

        long size = 0;
        File[] files = dir.listFiles();

        for (File file : files) {
            if (file.isFile()) {
                size += file.length();
            }
        }

        return size;
    }
}

当然,这可能是一项昂贵的操作,因此您应该计划在后台线程上进行缓存。

此外,这可能会像您需要的那样复杂。在我的示例中,我假设所有缓存的文件都放置在缓存目录的根目录中,所以我不检查潜在的子目录。删除文件的例程也可能变得更加复杂,例如按最早的访问日期删除文件。

决定缓存数据时要记住的一件事是,您需要始终为缓存数据不再存在的情况进行计划。当缓存中没有存储数据时,请务必有一个例程可以通过外部方式检索数据。同样,在从外部检索数据之前,请始终检查缓存。缓存的目的是减少网络活动,减少冗长的过程,并在您的应用程序中提供响应式UI。因此,请负责任地使用它:)


如果我的应用程序需要大文件的软存储该怎么办?我是否应该将缓存设置得很高,而不是由于规格或存储在filesDir中而负责,并找到一种从那里删除文件的方法?
hipkiss15年

2
@hipkiss缓存的大小将根据应用程序的要求而有所不同。将最大值设置为您认为对您的应用程序合理的值。
杰森·罗宾逊

@JasonRobinson缓存目录是否有最大大小限制,或者某个应用程序可以在其中存储尽可能多的数据(例如500 MB)?
2016年

@Diffy据我所知没有,但我不确定。
杰森罗宾逊

@JasonRobinson我有一个问题要问。我正在构建一个电子图书馆应用程序,该应用程序需要从Web服务器访问大型pdf或epub文件。我应该使用什么缓存目录或文件?谢谢。
伊什沃尔·卡纳尔(Ishwor Khanal)

15

我是在活动结束时清除应用程序缓存的最佳方法,以便在每次调用新活动时清除每次缓存。

将此代码放在onDestroy()中以清除应用程序缓存

@Override
protected void onDestroy() {

    super.onDestroy();
    try {
        trimCache(this);
       // Toast.makeText(this,"onDestroy " ,Toast.LENGTH_LONG).show();
    } catch (Exception e) {
        // TODO Auto-generated catch block
        e.printStackTrace();
    }
}

public static void trimCache(Context context) {
    try {
       File dir = context.getCacheDir();
       if (dir != null && dir.isDirectory()) {
          deleteDir(dir);
       }
    } catch (Exception e) {
       // TODO: handle exception
    }
 }

public static boolean deleteDir(File dir) {
    if (dir != null && dir.isDirectory()) {
       String[] children = dir.list();
       for (int i = 0; i < children.length; i++) {
          boolean success = deleteDir(new File(dir, children[i]));
          if (!success) {
             return false;
          }
       }
    }
    // The directory is now empty so delete it
    return dir.delete();
}

5
onDestroy()supercall?先生
Yousha Aleayoub

1

我认为缓存背后的想法是在缓存上写任何您想要的东西,如果缓存太大,Android会控制它的大小。

您应该记住,可以将文件写入缓存,但是在尝试访问文件时始终检查文件是否仍然保存。并让android管理缓存。


1

取决于应用程序的类型:

  • 一些应用程序仅使用单个会话,不需要记住任何数据,因此您可以根据需要清除缓存(某些应用程序甚至在其onStop活动中自动执行此操作)
  • 大多数应用程序保留数据是因为它们会记住您的设置,您用于登录的帐户...。在这种情况下,最好仅在不经常使用该应用程序时才清除缓存。

也:

So i took a look at Chrome app (Galaxy Nexus) and the cache size for the application is 110 MB. But what wired is that applications like Google current & Google maps cache the content in something called (USB Storage Data) :

AFAIK,Usb存储数据的用途与高速缓存不同:存储用于存储程序特定的信息(例如GPS应用程序的地图),高速缓存用于存储用户特定的信息(例如登录名)

如果是谷歌地图:我假设它们将地图数据存储在USB存储器中,并将您的设置和搜索历史记录保留在缓存中==>地图数据是特定于应用程序的,设置和搜索历史是特定于用户的


0

根据文档,系统将在以下情况下清除缓存: 设备内部存储空间不足。从API8开始,您拥有getExternalCacheDir()方法,该方法自读取以来我认为很有用,您可以拥有约150MB的数据,但是外部缓存的缺点是,如果缓存目录太大,您必须自己清理缓存目录。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.