回答:
場合によっては、AsyncTaskまたはのいずれかを使用して同じタスクを実行することができますが、Service通常、一方が他方よりもタスクに適しています。
AsyncTaskは、UIスレッドで実行できない、一度限りの時間のかかるタスク用に設計されています。一般的な例は、ボタンが押されたときのデータのフェッチ/処理です。
Serviceは、バックグラウンドで継続的に実行されるように設計されています。ボタンが押されたときにデータをフェッチする上記の例では、サービスを開始し、データをフェッチさせてから停止することができますが、これは非効率的です。AsyncTaskを実行してデータを返し、実行されるを使用する方がはるかに高速です。
ただし、バックグラウンドで継続的に何かを行う必要がある場合Serviceは、a が最善の策です。この例には、音楽の再生、新しいデータの継続的な確認などが含まれます。
また、Sherifがすでに述べたように、サービスは必ずしもUIスレッドから実行されるとは限りません。
ほとんどの場合、Servicesは、アプリケーションActivityが開いていなくてもコードを実行したい場合に使用します。AsyncTaskは、UIスレッドから実行コードを信じられないほど簡単にするように設計されています。
サービスは完全に異なります。サービスはスレッドではありません。
アクティビティがサービスにバインドされ、サービスには、呼び出されたときに呼び出しスレッドをブロックするいくつかの関数が含まれています。サービスは、摂氏から度に温度を変更するために使用される場合があります。バインドするアクティビティはすべて、このサービスを取得できます。
ただしAsyncTask、バックグラウンドでいくつかの作業を行うと同時に、呼び出し元のスレッドに結果を報告する機能を持つスレッドです。
ちょうど考え：サービスにはAsyncTaskオブジェクトがあるかもしれません！
Serviceは、Androidフレームワークのコンポーネントの1つであり、実行にUIを必要としません。つまり、ユーザーがアプリをアクティブに使用していない場合でも、サービスで何らかの操作を実行できます。これは、サービスが別のスレッドで実行されるわけではありませんが、メインスレッドで実行され、必要に応じて操作を別のスレッドで実行できます。使用例としては、バックグラウンドで音楽を再生したり、ユーザーとのやり取りなしでデータをバックグラウンドでサーバーと同期したりします。
AsyncTask一方、別のスレッドで実行されるUIブロックタスクに使用されます。これは、新しいスレッドを作成し、スレッドを作成して維持し、結果をメインスレッドに返送するすべてのタスクがAsyncTaskによって処理されるときにタスクを実行するのと同じです。
サービスとasynctasksは、ほぼ、同じことをやっているほとんどのサービスやasynctaskを.usingあなたの要件がされているかに依存します。
例として、ボタンを押した後、または画面を変更した後、サーバーからリストビューにデータをロードする場合は、asynctask.itをメインUIスレッドと並行して実行する（バックグラウンドで実行する）ようにします。メインUIスレッドでは、アプリの終了後に非同期タスクはありません。
しかし、サービスはそのようなものではありません。サービスを開始すると、アプリを終了した後に実行できます。ただし、サービスを停止している場合を除きます。たとえば、要件によって異なります。データの受信を確認し続けるか、ネットワーク状態を確認するか継続的にサービスを利用する方がよいでしょう。
幸せなコーディング。
比較ローカル、インプロセス、基底クラスのサービスに✱AsyncTask：
✱（この回答は、エクスポートされたサービス、またはクライアントのプロセスとは異なるプロセスで実行されるサービスには対応していません。これは、予想されるユースケースがのユースケースと大幅に異なるためAsyncTaskです。また、簡潔にするために、Serviceサブクラスは、（例えばIntentService、JobService）ここでは無視されます。）
プロセス寿命
A ServiceはOSに対して、「ユーザーと対話せずに長時間実行される操作を実行したいというアプリケーションの要望」を表します[ ref ]。
実行しているService間、Androidはプロセスを強制終了させたくないことを理解しています。これは、Activity画面に表示されている場合にも当てはまります。フォアグラウンドサービスを実行している場合は特に当てはまります。（すべてのアプリケーションコンポーネントがなくなると、Androidは「ああ、今はこのアプリを終了するのに良いタイミングなので、リソースを解放できる」と考えます。）
また、からの最後の戻り値に応じてService.onCreate()、Androidは、リソースのプレッシャーのために強制終了されたアプリ/サービスを「復活」しようとする可能性があります[ 参照 ]。
AsyncTasks何もしないでください。アプリがCPUを使用しているからといって、Androidがアプリを存続させることはできません。アプリにはまだやるべき作業があることを知るための何らかの方法が必要です。そのためServices、OSに登録されていますが、登録されてAsyncTasksいません。
マルチスレッド
AsyncTasks すべては、作業を行うバックグラウンドスレッドを作成し、その作業の結果をスレッドセーフな方法でUIスレッドに提示することです。
スレッドプール[ ref ]のAsyncTask制限に従い、新しい実行が行われるたびに、一般に同時実行性（スレッド数）が増加しAsyncTasks'sます。
Service一方、メソッドは常にUIスレッド [ ref ]で呼び出されます。これが適用されるonCreate()、onStartCommand()、onDestroy()、onServiceConnected()、などだから、ある意味では、Servicesバックグラウンドでない「実行」を行います。起動したら（onCreate()）、そこに "座って"います-クリーンアップする時間になるまで、onStartCommand()、などを。
つまり、追加を追加Servicesしても同時実行性は向上しません。サービスメソッドは、UIスレッドで実行されるため、大量の作業を行うには適していない。
もちろん拡張できます Serviceて独自のメソッドを追加し、必要な任意のスレッドから呼び出すことができます。ただし、それを行う場合、スレッドセーフティの責任はフレームワークではなくあなたにあります。
バックグラウンドスレッド（または他の種類のワーカー）をに追加するService場合は、自由に追加できます。あなたは/バックグラウンドスレッドを開始することができますAsyncTaskでService.onCreate()、たとえば、。ただし、すべてのユースケースでこれが必要なわけではありません。例えば：
Service「バックグラウンド」で位置情報の更新を継続して取得できるように、実行を継続したい場合があります（つまり、Activities画面上に）。BroadcastReceiver長期的に「暗黙的」に登録を維持することもできます（API 26以降、マニフェストを使用してこれを常に実行できるわけではないため、代わりに実行時に登録する必要があります。 [ ref ]）。これらの使用例のどちらも、大量のCPUアクティビティを必要としません。彼らはただアプリが殺されないことを要求します。
労働者として
Servicesタスク指向ではありません。これらは、「タスクを実行する」および「結果を配信する」ようにAsyncTasksは設定されていません。Services（すべてのメソッドが単一のスレッドで実行されるという事実にもかかわらず）スレッド安全性の問題を解決しません。AsyncTasks一方で、その複雑さを処理します。
注意AsyncTaskされて廃止される予定。しかし、それはあなたのあなたを交換する必要がありますという意味ではありませんAsyncTasksとServices！（もしあなたがこの答えから何かを学んだなら、それだけははっきりしているはずです。）
TL; DR
Servicesほとんどが「存在する」ためにそこにいます。これらはオフスクリーンのようなものActivityで、アプリが生き続ける理由を提供しますが、他のコンポーネントが「作業」を行います。AsyncTasks「働く」ことはできますが、それ自体では、プロセスを存続させることはできません。