解决方法:
我建议不要将音频数据存储在数据库中.前面提到的内存问题可能会导致大量的GC抖动,这会使系统在几秒钟或更长时间内无响应.
典型的方法涉及一些步骤.
>将音频存储在应用程序目录中的某个文件中.
>在数据库中创建两列.一列(称为您喜欢的任何内容)包含引用数据的“content：//”URL.看到“content：//”URL是系统的触发器,然后查找同一行中“_data”列的内容.该列的内容应该是文件的完整路径.
>系统然后透明地读取该文件,并将其呈现给实际请求内容的任何代码.
我有一些示例代码用图像做这个 – 显然,它不完全相同,但我可以在这里完成它,你应该得到要点.
我试图解决的具体问题是为存储在设备外的曲目存储专辑封面.我希望能够在列表中显示专辑图片,并将其本地缓存在设备上,以便反复滚动它很快,并且确实涉及对相同数据的重复网络提取.
我有一个专辑数据库,其中包含从远程服务器延迟填充的各种列.我使用ContentProvider框架实现此数据库.在http://developer.android.com/guide/topics/providers/content-providers.html有很多关于ContentProviders的很好的信息,你应该先阅读它,以便其余部分有意义.
涉及的文件是(注意：我已经链接到树中的特定点,因为这是一项正在进行的工作,我希望我给你的行号参考稳定)：
这个类定义了在别处使用的各种常量,对于任何作为ContentProvider实现的东西来说都非常惯用.
在此类中,COL_ARTWORK_PATH是将包含content：// URL的列.
这是ContentProvider的实现.同样,对于包装sqlite数据库的ContentProviders来说,这是非常惯用的.一些兴趣点：
429：albumListCallback()
只要应用程序从远程服务器接收有关相册的数据(特定于我的应用程序,与您的问题无关),就会调用此代码.到目前为止,数据已被包装为SqueezerAlbums列表,因此此代码必须解压缩该数据并将其转换为数据库中的行.
456：在这里我们调用updatealbumart有足够的数据,它可以远程获取专辑图片(我刚刚意识到这个代码,我可以使这更高效,因为它更频繁地更新数据库.但是我离题了).
475：updatealbumart()
这必须获取远程映像,调整大小,将原始版本和调整大小的版本存储在文件系统中(为什么两者都有？因为我还没有完成此操作,并且稍后会有代码选择正确的缓存大小).
这将根据需要创建缓存目录,下载远程映像,调整其大小并将其保存到文件中.
535：这是您可能特别感兴趣的位.这将创建一个引用数据的content：// URL(使用AlbumCache.java中的常量),并将其放在COL_ARTWORK_PATH中.然后它将文件的绝对路径放在_data列中.
571：openFile()
你必须实现这一点. ContentProvider的用户在想要打开数据库中的文件时会调用openFile().此实现使用openFileHelper(),该代码在_data列中查找值,打开该文件,并将ParcelFileDescriptor返回给调用者.
正如您可能已经意识到的那样,openFile()的开放实现不必执行此操作 – 您可以使用其他列名称,或者您可以直接从URL直接到文件系统中的文件.这似乎是一个非常普遍的习语.
假设您已经完成了类似的操作,并且现在有了数据库的ContentProvider,要实际访问该图像,您的应用程序将需要生成一个URI,该URI通过它的ID引用给定的内容.应用程序中打开文件的代码如下所示：
Inputstream f = this.getContentResolver().openInputStream(theUri);
最终调用openFile()的实现,最终调用openFileHelper(),最终到达文件系统中的正确文件.这种方法的另一个优点是在应用程序的安全域中调用openFile(),因此它可以访问该文件,如果正确实现,如果您创建它响应的URL,则可以由完全不同的应用程序调用ContentProvider.众所周知的.
