對於上下文中的「長期運行」的任務合理度量，我是通過線程機制的Android的比較閱讀的Tejas的Lagvankar上this very good blog post找到。在這篇文章中，在許多其他的職位和Android文檔，甚至地區，「長時間運行」任務被反覆使用，但我一次也沒有見過什麼資格任務，只要運行一個真正的定義。什麼是Android中
鑑於我們已考慮到基於一個應用程序API級別和其他支持預選賽帳戶不同的設備能力，什麼是符合條件的任務爲「長時間運行」的下限。 （最好以諸如毫秒的測量單位）。
我一次也沒有見過什麼資格任務，只要運行
在很大程度上真正的定義，這將取決於環境。此外，你假定每個人都使用「長跑」這個詞，就是以同樣的方式這樣做。
什麼是符合條件的任務爲「長時間運行」
恕我直言下限，不能真正被抽象地回答。
因此，舉例來說：
避免「JANK」（丟幀）的情況下，我認爲「長時間運行」是任何回調時間超過1ms左右以上。我們的許多回調需要調用的UI渲染的一部分，如果總計爲花費太長的時間，我們可能會丟幀（即，不更新屏幕的時候應該已經發生了更新）。在實踐中，如果你不丟幀，「長跑」的確切閾值取決於你，雖然在數學上它顯然必須小於16ms。
在一個線程/ AsyncTask的上下文中，由一個活動分叉，由於活動被破壞（例如，返回按鈕），清盤毫無意義，我認爲「長時間運行」的數量級爲幾百毫秒。
在過程終止的風險中斷您的後臺工作 - 如果您確實需要完成工作時考慮使用服務的閾值 - 我會認爲「長時間運行」是關於第二。我認爲「長時間運行」大約需要15秒，因爲這是最低的不活動時間。因此，在設備入睡的風險中，因此需要考慮使CPU持續運轉，我認爲「長時間運行」約爲15秒，因爲這是最低的不活動狀態用戶可以指定的超時時間。並假設用戶是觸發這一特定背景工作的人;在其他情況下（例如，AlarmManager，GCM訊息），你所需要的任何東西WakeLock。
依此類推。
雖然我的選擇背後有一些數學，但最終它們是我的選擇，其他Android專家可能有其他選擇。
我發現這個答案最有用，因爲不同背景下的粗略度量標準以及這些粗略度量標準背後的一些基本推理。我並沒有將此作爲事實，而是作爲如何推理任務運行時間的指導。 – stevebot
Android將宣佈「應用無響應」，或者如果主線程被阻塞超過5秒ANR。實際上，用戶注意到延遲小至100毫秒，所以這是一種「最差情況」的起點。如果您的操作可以以任何方式阻止（文件I/O，圖像解碼，網絡訪問等），那麼您應該遵循bg線程。
用戶可以注意到延遲低於100ms。丟棄的幀（60fps速率）可能是可感知的，特別是對於那些注意到這種事情的人，特別是在有比較準備點的情況下（例如，滾動中的口吃）。 – CommonsWare
公平點，謝謝。當然，對於任何類型的遊戲或動畫60fps是明確的基準。 –
我不會嘗試在一定的時間內定義長時間運行的任務，而是通過完成這個任務。您可以成功地在UI線程上執行文件I/O操作，因爲在您的測量中它們需要幾毫秒，但可能會發生I/O將阻塞並且您的代碼將導致ANR。另一個例子是當你解析json數據時，如果它小，那麼它會很快，但是如果它變大，那麼它可能會導致ANR，甚至可能是OOM（內存不足）異常。所以我想通過查看這些任務在做什麼，並考慮它如何擴展 - 如果數據變得更大，會發生什麼情況，以便將長期運行的任務分類。
爲了安全起見，在工作線程中始終執行I/O，數據解析/處理，網絡通信（實際上您沒有選擇）。
作爲一個說明，我目前的指標一直是觀察。我在特定的配置文件中加載應用程序並觀察是否有減速。同樣，我將使用基本分類（例如，如果任務正在進行數據庫調用，或者http）將任務分類爲長時間運行。 – stevebot
我會說長時間運行是一項不會立即結束的任務，也可能是因爲外部原因可能會有所不同。 – njzk2
長時間運行的任務是使UI線程無法在應用程序的最佳位置執行預製，導致jank，stutter，freeze等問題。 – tyczj