值得為Android音樂播放器生成播放列表文件嗎？

Question

我將為Android編寫一個滿足特定需求的音樂播放器（與我的問題無關）。

我想用sdcard上的目錄（在一個主目錄內）標識內部播放列表，因為我知道我的用戶將設置有組織的目錄。 因此，簡單地讀取單個列表中的所有音頻文件，然后讓用戶手動創建播放列表可能會很煩人。

我想知道為此目的生成分層播放列表文件是否值得。

我目前的計划是在應用啟動時運行“圖書館檢查員”。 該檢查器將使用包含以下形式的分層數據的“庫狀態”

String filename;
long   modified; // timestamp of last modification

檢查庫遞歸是否需要創建新的播放列表文件 。 如果此匹配檢查失敗，則將創建包括新的“庫狀態”的此分層文件（元數據：標題，藝術家，專輯等，例如xml）。 此文件應防止在每次運行該應用程序時讀取所有元數據。

明確地說：我正在尋找一種播放音樂的有效方法-但電池安全！

由於我是移動應用程序開發的新手，因此我對節電不太熟悉。 讀取一個文件而不是遞歸元數據讀取是否更省錢？ 或者也許我將要過度操作？ 您知道建立應用程序的一些策略嗎？

我對您的想法非常感興趣:)，希望我的英語不好不會妨礙您的理解...對此我感到抱歉。

謝謝！

最高

Answer 1

我無法從使用MediaStore或SQLite的角度回答，但可以為您提供一些有關最大程度地減少電池使用量的建議。

• 不要使用遞歸。 遞歸在結構上很緊湊，但是效率卻很差。 由於訪問堆棧，可能進行上下文切換等，每個調用都非常昂貴。如果遞歸非常深，則在磁盤使用率，頁面交換等方面也存在問題。
• 對任何大列表使用有效的搜索算法。 完成工作的速度越快，處理器空閑的時間就越多，電源狀態越深，節省的電量就越多。
• 盡可能將您的搜索/訪問聚集在一起。 例如，如果您必須進行3次搜索，每1秒間隔一次，並花費0.5秒執行時間，則可以讓處理器在高功率狀態下保持活動狀態超過4.5秒，然后使其靜止並降至低功率狀態。 。 如果將查詢匯總在一起，則在高功率狀態下花費1.5秒，在低功率狀態下花費3秒。 粗略地說，您使用的功率小於1/3。
• 盡可能使用板載內存。 我不知道對sdcard的訪問速度有多慢，但是它會減慢算法速度並可能增加功耗。
• 嘗試設置數據庫條目和其他數據結構，使它們與處理器的緩存自然對齊（例如，對齊16B）。 這將大大提高例程的速度（L1緩存訪問可能為1個周期，L2為10個周期，而內存為100個周期-這些值僅是示例性的，但很粗略）。 而且您的例行程序越快，閑置就越多，並且節省的電能也就更多。

我的計時時長（例如相隔1秒）僅用於說明目的。 存在多個空閑狀態，而放入這些狀態的規則不同，這可能會使真實的說明非常復雜。

我對數據庫的能效了解不多。 我確實知道有一些針對移動和低功耗設備設計的數據庫。 不幸的是，我不記得他們是什么。 （對此，我不予贅述，但我想起了有關伯克利和實時性的內容。

PS您的英語似乎很棒。