我绑扫描usb msc在stm32的音频文件。这mp3文件分散在许多文件夹是未知的应用程序。首先我扫描目录在根文件夹和找到文件夹，然后我扫描文件夹的mp3文件。这是非常耗时的，并为8个文件夹的深度与许多文件在每个文件夹。是否有任何方法来扫描只是文件夹中有MP3文件使用更好的方法.目录结构测试是这样的东西：
92vpleto1#
目前尚不清楚您的问题可能是什么，因为您没有提供任何代码来查看您是如何扫描的，也没有提供有关文件/文件夹结构的定量信息（“许多文件”相当模糊），甚至没有指定所使用的介质类型。然而，一种解决方案可以克服文件系统性能、硬件I/O、驱动器实现和介质类型的所有可变因素，并且无论如何都使得访问更加确定，是在根目录下的单个文件中维护单独的索引文件或数据库，以将每个MP3文件Map到其路径，这样您只需搜索所需MP3的索引/数据库（或使用它直接列出所有MP3，而无需扫描文件系统）。如果你保持这个文件是有序的（或者是一个单独的索引文件是有序的），那么你可以使用二进制搜索来查找一个特定的文件，或者简单地使用一个真实的的数据库--尽管这可能是一个相当重量级的解决方案，你甚至可以将元数据加载到内存中以获得更快的访问速度，并且只在它改变的时候才将它写入文件系统。无论哪种方式，我建议的解决方案都是通过维护您自己的“元数据”文件，将您的应用程序与文件系统/介质的可变性以及FAT缺乏可伸缩性隔离开来（s）指示存储了什么以及存储在哪里，以便您可以使用它来直接访问文件，而不需要使用findfirst/findnext语义的文件系统扫描，以及总是最好避免的递归，但这是扫描目录树的明显方式。顺便说一句，iTunes就是这样工作的。“iTunes Library.xml”包含了关于“歌曲”的元数据，包括它们的位置。显然，你不需要那么详细的信息，但是原理是相同的，如果你的应用程序有一个合适的库来更新和访问这样的文件，那么使用XML或JSON可能会有好处。这样，性能就可以更直接地由您控制，而不是依赖于文件系统、介质和/或设备驱动程序级别。但是，您仍然对介质及其接口具有一定的控制/责任（SPI、SDIO、USB等）和设备I/O层（DMA、中断、轮询、位碰撞），虽然您可能无法控制FAT和ELM FatFs实现的选择，你当然可以在设备驱动程序、硬件接口和物理介质级别上极大地影响它的性能。
1条答案
按热度按时间92vpleto1#
目前尚不清楚您的问题可能是什么，因为您没有提供任何代码来查看您是如何扫描的，也没有提供有关文件/文件夹结构的定量信息（“许多文件”相当模糊），甚至没有指定所使用的介质类型。
然而，一种解决方案可以克服文件系统性能、硬件I/O、驱动器实现和介质类型的所有可变因素，并且无论如何都使得访问更加确定，是在根目录下的单个文件中维护单独的索引文件或数据库，以将每个MP3文件Map到其路径，这样您只需搜索所需MP3的索引/数据库（或使用它直接列出所有MP3，而无需扫描文件系统）。
如果你保持这个文件是有序的（或者是一个单独的索引文件是有序的），那么你可以使用二进制搜索来查找一个特定的文件，或者简单地使用一个真实的的数据库--尽管这可能是一个相当重量级的解决方案，你甚至可以将元数据加载到内存中以获得更快的访问速度，并且只在它改变的时候才将它写入文件系统。
无论哪种方式，我建议的解决方案都是通过维护您自己的“元数据”文件，将您的应用程序与文件系统/介质的可变性以及FAT缺乏可伸缩性隔离开来（s）指示存储了什么以及存储在哪里，以便您可以使用它来直接访问文件，而不需要使用findfirst/findnext语义的文件系统扫描，以及总是最好避免的递归，但这是扫描目录树的明显方式。
顺便说一句，iTunes就是这样工作的。“iTunes Library.xml”包含了关于“歌曲”的元数据，包括它们的位置。显然，你不需要那么详细的信息，但是原理是相同的，如果你的应用程序有一个合适的库来更新和访问这样的文件，那么使用XML或JSON可能会有好处。
这样，性能就可以更直接地由您控制，而不是依赖于文件系统、介质和/或设备驱动程序级别。但是，您仍然对介质及其接口具有一定的控制/责任（SPI、SDIO、USB等）和设备I/O层（DMA、中断、轮询、位碰撞），虽然您可能无法控制FAT和ELM FatFs实现的选择，你当然可以在设备驱动程序、硬件接口和物理介质级别上极大地影响它的性能。