Androidの仕組み、パート3

この記事では、Androidアプリを構成するコンポーネントと、このアーキテクチャの背後にあるアイデアについて説明します。

シリーズ記事：

• Androidの仕組み、パート1
• Androidの仕組み、パート2
• Androidの仕組み、パート3
• Androidの仕組み、パート4
• ...

Web vsデスクトップ

最新のWebアプリケーションと「通常の」デスクトップアプリケーションの違いを考えると、欠点の中でも、Webのいくつかの利点を強調できます。

• Webアプリケーションは、 Javaのように 、アーキテクチャとプラットフォーム間で移植可能です。
• Webアプリケーションはインストールを必要とせず、 Android Instant Appsと同様に常に更新されます 。

さらに、Webアプリケーションは、同じサイト内およびサイト間の両方で、互いにリンクできるページの形式で存在します。 さらに、あるサイトのページは、別のサイトのメインページへのリンクのみに限定される必要はなく、別のサイト内の特定のページにリンクできます（これはディープリンクと呼ばれます）。 相互に参照すると、個々のサイトが結合されて、共通のネットワークであるWebになります。

1つのページの複数のコピー（ソーシャルネットワーク上の複数のプロファイルなど）は、複数のブラウザータブで同時に開くことができます。 ブラウザーインターフェイスは、個々のサイト間ではなく同時セッション（タブ）を切り替えるように設計されています。同じタブ内で、異なるサイトの異なるページ間でリンクをナビゲート（および履歴を前後に）できます。

これはすべて、各アプリケーションが個別に、そして多くの場合他のアプリケーションとは独立して動作する「デスクトップ」とは反対です。この点で、Androidでのアプリケーションの配置方法は「従来の」アプリケーションよりもWebにより近くなります。

活動と目的

Androidのアプリケーションコンポーネントのメインフォームはactivityです。 アクティビティは1つのアプリケーション画面です。 アクティビティは、Web上のページおよび従来のウィンドウインターフェイスのアプリケーションウィンドウと比較できます。

たとえば、電子メールクライアントアプリケーションでは、受信トレイアクティビティ（受信文字のリスト）、電子メールアクティビティ（1文字を読む）、作成アクティビティ（文字を書く）、設定アクティビティ（設定）などのアクティビティがあります。

1つのサイトのページのように、1つのアプリケーションのアクティビティは、相互に起動することも、相互に独立して（他のアプリケーションによって）起動することもできます。 Web上で別のページにURL（リンク）でアクセスすると、Androidアクティビティではそれらがインテントを介して起動されます。

インテントとは、システムに「何をする」かを指示するメッセージです（たとえば、特定のURLを開く、このアドレスに手紙を書く、この電話番号に電話する、写真を撮るなど）。

アプリケーションはそのようなインテントを作成してシステムに渡すことができ、システムはどのアクティビティ（または他のコンポーネント）がそれを実行するか（ハンドル）を決定します。 このアクティビティは、システムによって（既存のアプリケーションプロセスまたはまだ実行されていない場合は新しいプロセスで）起動され、このインテントが渡されて実行されます。

インテントを作成する標準的な方法は、Androidフレームワークの対応するクラスを使用することです。 Androidのコマンドラインからアクティビティとインテントを操作するには、 amコマンドがありamこれは、標準のアクティビティマネージャークラスのラッパーam 。

 #  -a ACTION -d DATA #   $ am start -a android.intent.action.VIEW -d http://example.com #    $ am start -a android.intent.action.CALL -d tel:+7-916-271-05-83 

インテントは、 明示的 （明示的）および暗黙的 （暗黙的）にすることができます。 明示的なインテントは、起動する必要がある特定のコンポーネントの識別子を示します-ほとんどの場合、同じアプリケーション内の1つのアクティビティから別のアクティビティを起動するために使用されます（インテントには他の有用な情報が含まれない場合もあります）。

暗黙のインテントは、実行するアクションを必ず示す必要があります。 各アクティビティ（および他のコンポーネント）は、アプリケーションマニフェストで、処理の準備ができている意図を示します（たとえば、ドメインhttps://example.comリンクのACTION_VIEW ）。 システムは、インストールされたコンポーネントから適切なコンポーネントを選択して起動します。

システムにインテントを処理する準備ができているいくつかのアクティビティがある場合、ユーザーに選択肢が与えられます。 これは通常、複数の類似したアプリケーション（たとえば、複数のブラウザーや写真エディター）がインストールされている場合に発生します。 さらに、アプリケーションは選択ダイアログを表示するようにシステムに明示的に要求する場合があります（実際、渡されたインテントはACTION_CHOOSER新しいインテントにACTION_CHOOSERされます）。これは通常、美しい共有ダイアログを作成するために使用されます。

さらに、アクティビティは結果をその原因となったアクティビティに返すことができます。 たとえば、「写真を撮る」というインテントを処理できるカメラアプリケーションのアクティビティ（ ACTION_IMAGE_CAPTURE ）は、撮影した写真をこのインテントを作成したアクティビティに返します。

この場合、元のアクティビティを含むアプリケーションには、カメラへのアクセス許可が必要ありません。

したがって、Androidアプリケーションが写真を撮る正しい方法は、カメラにアクセスしてCamera APIを使用する許可を必要とせず、目的の意図を作成し、システムカメラアプリケーションに写真を撮らせることです。 同様に、 READ_EXTERNAL_STORAGE権限を使用してユーザーのファイルに直接アクセスする代わりに、システムファイルマネージャーでファイルを選択する機会をユーザーに与える必要があります（元のアプリケーションはこのファイルへのアクセスを許可されます）。

Androidシステム設計のユニークな側面は、どのアプリでも別のアプリのコンポーネントを起動できることです。 たとえば、ユーザーにデバイスのカメラで写真をキャプチャさせる場合、おそらくそれを行う別のアプリがあり、アプリは自分で写真をキャプチャするアクティビティを開発する代わりにそれを使用できます。 カメラアプリのコードを組み込む必要も、リンクする必要もありません。 代わりに、写真をキャプチャするカメラアプリでアクティビティを開始するだけです。 完了すると、写真はアプリに返されて使用できるようになります。 ユーザーには、カメラが実際にアプリの一部であるかのように見えます。

同時に、「システム」アプリケーションは、メーカー（またはAndroidアセンブリの作成者）によって事前にインストールされたものである必要はありません。 この意味で、この意図を処理できるすべてのインストール済みアプリケーションは同等です。 ユーザーはそれらのいずれかをそのようなintent'ovのデフォルトアプリケーションとして選択でき、毎回適切なものを選択できます。 ユーザーがシステムで発生するこのタイプのすべてのタスク（つまり、意図）を実行することを選択したという意味で、選択されたアプリケーションは「システム」になります。

カメラ自体へのアクセス許可は、カメラインターフェイスを実装するアプリケーション（カメラアプリケーション自体、ビデオ通話アプリケーション、拡張現実など）にのみ必要です。 それどころか、普通のメッセンジャーは 「写真を送信できるように」カメラにアクセスする必要はありません 。 大銀行のアプリケーションへの呼び出しにアクセスする必要がないのと同じです。

多くのオペレーティングシステムは、オペレーティングシステム自体と、その上にインストールされているアプリケーションに分かれています。これらのアプリケーションは、お互いについて何も知らず、対話する方法も知りません。 Androidコンポーネントとintent'ovのシステムにより、アプリケーションは、 まだお互いについて何も知らずに、ユーザーのために1つの統合システムユーザーエクスペリエンスを構成できます。インストールされたアプリケーションは、 1つの大きなシステムの一部を実装し、システムを構成します。 そして、これは一方ではユーザーにとって透過的であり、他方ではカスタマイズの無限の可能性を提示します。

私の意見では、それは非常に美しいです。

タスクとバックスタック

既に述べたように、ブラウザでは、ユーザーはサイト間ではなくタブ間を切り替えることができます。各タブの履歴には、異なるサイトの多くのページを含めることができます。 同様に、Androidでは、ユーザーはタスク （タスク）を切り替えることができます 。 タスクは、 最近の画面にカードの形で表示されます 。 各タスクはバックスタックです-いくつかのアクティビティが互いに「重ね合わされ」ます。

あるアクティビティが別のアクティビティを起動すると、新しいアクティビティが古いアクティビティの上にあるスタックにプッシュされます。 スタックの一番上のアクティビティが完了すると（たとえば、ユーザーがシステムの戻るボタンを押すと）、スタックの前のアクティビティが再び画面に表示されます。

各スタックには異なるアプリケーションのアクティビティを含めることができ、1つのアクティビティの複数のコピーを異なるタスクの一部として、または同じスタック内で同時に開くことができます。

新しいアクティビティを開始するとき、このメカニズムを変更するsingleTop 、 singleTask 、 singleInstance 、 CLEAR_TOPなどの特別なフラグを指定できます。 たとえば、ブラウザアプリケーションは通常、メインアクティビティのコピーを1つだけ起動でき、開いているページを切り替えるために、独自のタブシステムを実装します。 一方、 カスタムタブはブラウザー（ほとんどの場合Chrome）でのアクティビティの例であり、ほぼ「通常どおり」に動作します。つまり、1ページのみを表示しますが、そのコピーのいくつかを同時に開くことができます。

アプリのライフサイクル

組み込みおよびモバイルデバイスの主な制限の1つは、少量のランダムアクセスメモリ（RAM）です。 最新のフラッグシップデバイスにすでに数ギガバイトのRAMが搭載されている場合、2008年9月にリリースされた最初のAndroidスマートフォンであるHTC Dream（別名T-Mobile G1）では、わずか192メガバイトでした。

「通常の」コンピューターとは異なり、モバイルデバイスではスワップパーティション（およびスワップファイル）が使用されないという事実により、メモリ制限の問題はさらに複雑になります-SSDおよびHDDと比較してアクセス速度が遅いためなどSDカードと内蔵フラッシュメモリに保存します。 KitKatのバージョン4.4以降、Android は zRAMスワップを使用します。つまり、メモリの使用頻度の低い部分を効果的に圧縮します。 ただし、メモリの制限の問題は残ります。

すべてのプロセスがシステムのブラックボックスである場合、空きメモリが不足した場合の最善の戦略は、一部のプロセスを強制的に終了（「強制終了」）することです。これがLinux Out Of Memory（OOM）Killerの機能です。 しかし、Androidはシステムで何が起こっているかを知っており、どのアプリケーションとそのコンポーネントが実行されているかを知っているため、より「スマートな」メモリ解放スキームが可能になります。

まず、空きメモリがなくなると、AndroidはonTrimMemory / onLowMemory呼び出して、不要なメモリを解放する（たとえば、キャッシュをonTrimMemory ）ようにアプリケーションに明示的に要求します。 第二に、Androidはバックグラウンドアプリケーションでガベージを効率的に収集し、現在使用しているアプリケーションの速度を落とすことなく、（Javaレベルで）使用しなくなったメモリを解放します。

しかし、Androidでメモリを解放する主なメカニズムは、 使用頻度の低いアプリケーションの終了です 。 システムは、ユーザーにとって最も重要でないアプリケーション（たとえば、ユーザーが長く残っているアプリケーション）を自動的に選択し、 onDestroyなどのメソッドを呼び出すことでコンポーネントにリソースをさらに解放する機会を与え、それらを終了し、使用するメモリとリソースを完全に解放します。

ユーザーがメモリ不足のためにシステムによって終了したアプリケーションのアクティビティに戻ると、このアクティビティが再び開始されます。 この場合、アクティビティは完了時にその状態を保持し（ onSaveInstanceState ）、次回の起動時に復元するため、ユーザーに対して透過的に再起動が発生します。 Androidフレームワークに実装されたウィジェットは、このメカニズムを使用して、再起動時にインターフェイス（UI）の状態を自動的に保存します（EditTextに入力されたテキスト、カーソル位置、スクロール位置など）。 アプリケーション開発者は、このアプリケーション固有の他のデータの保存と復元をさらに実装できます。

Androidはアプリケーションを完全に再起動することはできませんが、 コンポーネントごとに未使用部分を完全に再起動できることを強調します。たとえば、1つのアクティビティの2つのコピーから、1つを再起動し、もう1つを完了したままにすることができます。

ユーザーの観点から見ると、このメカニズムはスワップの使用に似ています：どちらの場合も、アプリケーションのアンロードされた部分に戻ると、再びロードされるまで少し待つ必要があります-ある場合にはディスクから、別の場合には-保存された状態によって再作成されます

自動的に再起動して状態を復元するこのメカニズムにより、ユーザーはアプリケーションが「常に実行されている」と感じ、アプリケーションを明示的に起動および終了し、入力されたデータを保存する必要がなくなります。

サービス

アプリケーションは、アクティビティに直接関係しないアクションを実行する必要がある場合があります。これには、このアプリケーションのすべてのアクティビティが完了したときにバックグラウンドで実行し続けることも含まれます。 たとえば、アプリケーションは、ネットワークから大きなファイルをダウンロードしたり、写真を処理したり、音楽を再生したり、データを同期したり、サーバーへのTCP接続を維持して通知を受信したりできます。

このような機能は、個別のスレッドを起動するだけでは実装できません。これはシステムのブラックボックスになります。 特に、このようなバックグラウンド操作の状態に関係なく、プロセスはすべてのアクティビティの完了時に完了します。 代わりに、Androidは別の種類のコンポーネント- サービスを使用することをお勧めします 。

アプリケーションは、アプリケーション中にこのアプリケーションのアクティビティの一部ではないアクションが実行されていることをシステムに通知するために必要です。 サービス自体は、別個のスレッドまたはプロセスを作成することを意味するものではありません。そのエントリポイントは、アプリケーションのメインスレッドで起動されます。 通常、サービス実装は追加のスレッドを起動し、それらを独立して管理します。

サービスは多くの点でアクティビティと非常によく似ています。サービスはインテントを使用して起動され、メモリ不足でシステムによって終了される可能性があります。

実行中のサービスには、次の3つの状態があります。

• フォアグラウンドサービス-ファイルのダウンロードや音楽の再生など、ユーザーにとってステータスが重要なアクションを実行するサービス。 このようなサービスは、システム通知カーテンに通知を表示するために必要です（例：ダウンロードステータス、現在の曲の名前、再生コントロール）。 システムは、このようなサービスをユーザーにとって現在のアクティビティとほぼ同じくらい重要であると見なし、最後の手段としてのみそれを完了します。

• バックグラウンドサービス-状態がユーザーに関係のないバックグラウンドアクション（ほとんどの場合、同期）を実行するサービス。 そのようなサービスは、はるかに高い確率でメモリ不足で終了できます。 古いバージョンのAndroidでは、同時に実行される多数のバックグラウンドサービスが「ブレーキ」の原因になることがよくありました。 Oreoのバージョン8.0以降では、Androidはバックグラウンドサービスの使用を厳しく制限し 、ユーザーがアプリケーションを終了してから数分後に強制的に終了します。

  
  

• バインドされたサービス-着信バインダー接続を処理するサービス。 このようなサービスは、他のアプリケーションやシステムに何らかの機能を提供します（ WallpaperServiceやGoogle Play Servicesなど）。 この場合、システムはクライアントが接続すると自動的にサービスを開始し、切断されたときにサービスを停止できます。

  
  

バックグラウンドアクションを実行する推奨方法は、システムベースのバックグラウンドスケジューリングメカニズムであるJobSchedulerを使用することです。 JobSchedulerを使用すると、アプリケーションは次のようなサービスを開始するための基準を指定できます。

• ネットワークの可用性 。 ここで、アプリケーションはこのサービスがネットワーク接続を必要とするかどうかを示すことができます。必要な場合は、ローミングで動作するか、従量制接続を使用するかを指定できます。
• 電源に接続すると、 「バッテリーを着陸させることなく」サービスを実行できます。
• 非アクティブ （アイドル）。デバイスを使用していないときに、アクティブな使用中に速度を落とすことなくサービスを実行できます。
• コンテンツの更新 -たとえば、新しい写真の外観。
• 起動の期間と期限 -たとえば、キャッシュは毎日クリアでき、カレンダーイベントは1時間ごとに同期できます。

JobSchedulerは、指定された基準に従って登録されたサービスを実行する（バインダーを介した呼び出しとして実装）予定です。 JobSchedulerはシステム全体のメカニズムであるため、インストールされているすべてのアプリケーションの登録サービスの基準を計画する際に考慮されます。 たとえば、使用中にデバイスに急激な負荷がかかるのを防ぐために、同時にではなく順番にサービスを開始し、定期的に小さなグループ（バッチ）で複数のサービスを実行して、無線機器の継続的なエネルギー消費のオン/オフを防ぐことができます。

放送受信機とコンテンツプロバイダー

アクティビティとサービスに加えて、Androidアプリケーションには、議論にはあまり興味のない2つのタイプのコンポーネントがあります。これらはブロードキャストレシーバーとコンテンツプロバイダーです。

ブロードキャストレシーバー -アプリケーションがブロードキャストを受信できるようにするコンポーネント。システムまたは他のアプリケーションからの特別なタイプのメッセージ。 最初は、名前が示すように、ブロードキャストは主にすべてのサブスクライブ済みアプリケーションにブロードキャストメッセージを送信するために使用されました。たとえば、飛行機モードをオンまたはオフにすると、システムはAIRPLANE_MODE_CHANGEDメッセージを送信します。

これで、アプリケーションはNEW_PICTUREやNEW_VIDEOなどのブロードキャストをサブスクライブする代わりに、JobSchedulerを使用する必要があります。 ブロードキャストは、よりまれなイベント（ BOOT_COMPLETEDなど）に使用されるか、明示的なインテントを使用して、つまり、あるアプリケーションから別のアプリケーションへのメッセージとして正確に使用されます。

コンテンツプロバイダーは、アプリケーションが管理するデータへのアクセスを他のアプリケーションに提供できるようにするコンポーネントです。 この方法でアクセスできるデータの例は、ユーザーの連絡先リストです。

, , (SQLite) . content provider — , .

content provider' REST API. - URI (, content://com.example.Dictionary.provider/words/42 ) ContentResolver. - , , UriMatcher , (query, insert, update, delete).

content provider' Storage Access Framework , , (, Dropbox Google Photos) , .

Android, , , , root-.