android - 从 SQLite 数据库流式传输音频

Question

我有一个 SQLite 数据库，其中包含存储为 blob 的音频文件。

是否可以在 android(或任何地方)从数据库流式传输媒体？

Answer 1

我建议不要将音频数据存储在数据库中。前面提到的内存问题可能会导致大量的 GC 抖动，这可能会使系统在几秒钟或更长时间内无响应。

典型的方法包括几个步骤。

将音频存储在应用程序目录中某处的文件中。

在数据库中创建两列。一列(称为任何您喜欢的名称)包含引用数据的“content://” URL。看到“content://” URL 会触发系统然后在同一行中查找“_data”列的内容。该列的内容应该是文件的完整路径。

然后系统透明地读取该文件，并将其呈现给实际请求内容的任何代码。

我有一些使用图像执行此操作的示例代码 - 显然，它并不完全相同，但我可以在这里浏览它，您应该了解要点。

我试图解决的具体问题是为存储在设备外的轨道存储专辑插图。我希望能够在列表中显示专辑插图，并将其缓存在设备本地，以便快速滚动浏览它，并且确实涉及对相同数据的重复网络提取。

我有一个专辑数据库，其中包含从远程服务器延迟填充的各种列。我使用 ContentProvider 框架实现了这个数据库。在 http://developer.android.com/guide/topics/providers/content-providers.html 上有很多关于 ContentProviders 的重要信息，您应该先阅读这些信息，以便其余部分有意义。

涉及的文件是(注意:我已经链接到树中的特定点，因为这是一项正在进行的工作，我希望我给你的行号引用是稳定的):

https://github.com/nikclayton/android-squeezer/blob/02c08ace43f775412cc9715bf55aeb83e7b5f2dc/src/com/danga/squeezer/service/AlbumCache.java

这个类定义了在别处使用的各种常量，并且对于作为 ContentProvider 实现的任何东西都是非常惯用的。

在这个类中，COL_ARTWORK_PATH 是将包含 content://URL 的列。

https://github.com/nikclayton/android-squeezer/blob/02c08ace43f775412cc9715bf55aeb83e7b5f2dc/src/com/danga/squeezer/service/AlbumCacheProvider.java

这是 ContentProvider 的实现。同样，这对于包装 SQLite 数据库的 ContentProvider 来说是非常惯用的。一些兴趣点:

429:专辑列表回调()

每当应用程序从远程服务器接收有关专辑的数据时调用此代码(特定于我的应用程序，与您的问题无关)。至此，数据已被包装为一个 SqueezerAlbums 列表，因此此代码必须解压缩该数据并将其转换为数据库中的行。

456:在这里，我们使用足够的数据调用 updateAlbumArt 以便它可以远程获取专辑插图(我刚刚意识到查看此代码可以提高效率，因为它更新数据库的频率高于它应有的频率。但是我离题了)。

475:更新专辑艺术()

这必须获取远程图像，调整它的大小，将原始版本和调整大小的版本都存储在文件系统中(为什么都是这样？因为我还没有完成这个，稍后会有选择正确缓存大小的代码)。

这将根据需要创建一个缓存目录，下载远程图像，调整其大小，并将其保存到文件中。

535:这可能是您特别感兴趣的部分。这会创建一个 content://URL(使用 AlbumCache.java 中的常量)来引用数据，并将其放入 COL_ARTWORK_PATH。然后它将文件的绝对路径放在 _data 列中。

571:打开文件()

你必须实现这一点。当 ContentProvider 的用户想要打开数据库中的文件时，他们将调用 openFile()。此实现使用 openFileHelper()，它是查找 _data 列中的值、打开该文件并将 ParcelFileDescriptor 返回给调用者的代码。

正如您可能刚刚意识到的那样，您的 openFile() 的开放实现不必这样做——您可以使用另一个列名，或者您可以直接从 URL 转到文件系统中的文件。不过，这似乎是一个非常常见的习语。

假设您已经完成了类似的操作，并且现在您的数据库有一个 ContentProvider，要实际访问图像，您的应用程序将需要生成一个 URI，该 URI 通过其 ID 引用给定的内容。应用程序中打开文件的代码如下所示:

Inputstream f = this.getContentResolver().openInputStream(theUri);

它最终调用您的 openFile() 实现，它最终调用 openFileHelper()，最终到达文件系统中的正确文件。这种方法的另一个优点是 openFile() 在您的应用程序的安全域中被调用，因此它可以访问该文件，并且如果正确实现，并且您的 ContentProvider 可以被完全不同的应用程序调用，如果您制作它响应的 URL众所周知。