我有點獨特的問題。我正在與我的大學的其他幾位計算機科學專業的學生合作開發Android節拍器應用程序，該應用程序允許兩個用戶使用該應用程序同步節拍器。現在，我可以將節拍器每分鐘所需的節拍從一部手機發送到另一部手機，兩部手機都將開始播放各自的節拍器。由於藍牙的延遲，節拍器僅在20％的時間內同步。在Java中使用藍牙同步兩個節拍器
所以，這裏是問題所在。我們正在努力做到這一點，所以兩個節拍器都將在同一時間開始。我認爲這樣做的一種方式是，一旦第一個用戶按下手機上的發送按鈕，就會創建一個時間戳。這個時間戳會在用戶按下發送按鈕後的兩秒鐘。時間戳然後將被髮送到第二部電話，手機將利用這個時間戳，在與第一部電話相同的時間啓動它的節拍器。我已經嘗試通過將UTC時間放在while循環中，然後不斷檢查時間來完成這一任務，但無濟於事。有沒有人有任何想法，我們如何能夠實施這個？在StackOverflow或其他任何網站上，我找不到任何類似的問題。
我會用(S)NTP來檢查公共時間服務器的時鐘漂移。之後，我只需發送間隔和開始時間，讓設備分別計算間隔。所以你只需要在各個設備的時鐘上同步更改和中繼。再加上現在已知的時鐘漂移，你可以修復這個錯誤。
對於您的項目可能有點晚，但如果感興趣。這有點長，這更像是個案研究。 如果您的項目是關於遠程同步兩個設備時鐘，那麼這不會對您有所幫助，但如果是關於同步節拍器，那麼這可能是一個開始。因爲android並非實時系統（所有睡眠方法和計時器可能無法在您期望的精確毫秒內執行），所以在使用java的android中獲取毫秒精確的時間和回調幾乎是不可能的。你可能想用NDK來觸發你的節拍事件，因爲android中的原生線程可以實現這一點，但如果你對單個節拍器的實現感到滿意，那麼就足以閱讀其餘的內容。
完全披露： 我是JAM的作者，我在剛剛發佈的答案中引用了前幾天。
我在開發應用程序時遇到了同樣的問題。 並且這個答案是否會幫助你，取決於你的情況。 ，並且如果你正在走下「時鐘同步」路線（我計劃探索改進我的應用程序以獲得更多功能），但我發現的解決方案並不涉及時間同步。
我會提到我的方法，然後說明我發現每種方法的優缺點。
而不是同步時鐘（一個非常困難的問題，特別是對於應用程序應該做的事情，這是觸發在同一時間在多個設備上打勾）我選擇了一個訂閱/發佈模型，其中多個設備可以通過藍牙「訂閱」主機設備，並且主機設備控制和「發佈」節拍器拍子。
大多數時間通過藍牙發送幾百字節（關於每個節拍的足夠信息）花費不到2ms，它可能達到10甚至30，但很少發生。 該方法處理同步問題，現在我可以在2ms內將節拍事件從一臺設備發送到另一臺設備，如果發生某種延遲，一旦干擾消失，它將自行更正，因爲其他事件及時發生。
但是，這種方法確實需要不斷的連接，你以後不能啓動和分離設備，但實現起來要容易得多。
現在有趣的部分，這個問題我從來沒有想過什麼時候開始，這是Android 10 millisecond audio path latency問題。我不隸屬於超能力，但我確實在我的應用中使用了他們的引擎來處理這個問題。
總結： 超過Android中藍牙節拍器同步有兩個問題：
1 - 同時觸發（或內可接受的等待時間）的節拍事件
2 - 節拍事件應的節拍事件之後觸發以最小的延遲的聲音事件被收到
＃1與原始問題＃2有關，我認爲這是一個重要的補充原始問題這個問題。
可能重複的[通過GPS時間同步Android設備？]（http://stackoverflow.com/questions/8210264/sync-android-devices-via-gps-time） – 323go
重複的問題解決了同樣的基本問題不同的應用程序。最好的辦法是實現一個NTC客戶端並確定NIST抵消系統時間，然後用它來解決任何抖動。我用同樣的方法讓兩臺設備同步視頻/音頻播放，並且您可以在5-10ms內準確獲得，這對音頻來說似乎足夠了。忘記GPS時間，對我來說，它總是返回系統時間。 – 323go