Androidカーネル機能の概要

「そして私は...キャブレターを洗う！」

逸話



はじめに



幼稚園では、志を同じくする人々と私はバッタを解剖し、その構造を整理することを望んでいました。 学校では、ラジオ「ロシア」がはんだ付けされました。 研究所では、ナッツが繰り返し再配置された車の回転でした。 関心は変わりましたが、「分解」したいという欲求が時々目覚め、今日ではAndroidを対象としています。



Androidのソースコードは何回役に立ちましたか？ 数えられません Androidはオープンなプロジェクトですが、残念ながら、読むことができるのは私たちだけです。 Googleの従業員でなくてもAndroidコードを編集することはほとんど不可能です。 この瞬間に悲しみ、リポジトリをロードします。 これを行う方法は、公式Webサイトで詳しく説明されています 。







一般的なアーキテクチャ



Androidのアーキテクチャは、次のように概略的に表すことができます。







元のスキームには、カーネルの機能に関する情報が含まれておらず、バインダーおよびシステムサービスに焦点を合わせていません。 ただし、バインダーは、システムのすべてのコンポーネントをバインドする「接着剤」です。



原則として、本では左上の青い長方形、つまりアプリケーション開発者が利用できるAPIについて説明しています。 以下のすべてに興味があります。 今日はコアのみを検討します。



コア



カーネルは、Linuxと呼ばれるディストリビューションの中心部分です。 「 クリーンな 」カーネルが利用できるにもかかわらず、多くの開発者（Ubuntu、Fedora、SuSeなど）は、ディストリビューションに含まれる前にパッチを追加します。 Androidも同じように動作しますが、直接的な互換性を失うという犠牲を払うだけです。「クリーンな」カーネルでは起動しません。 現在、カーネルのメインバージョンに「アンドロイド」を含める意図があります; 2011年に、Linus Torvalds はこのプロセスを4〜5年与えました 。 カーネルバージョン3.5にwakelocksメカニズムを含めることにより、すでに成功を収めています。



「アンドロイド」についてさらに詳しく考えてみましょう。



ウェイクロック



このメカニズムの歴史は壮大です;「Linuxへのウェイクロックの道」という記事のコレクションを利用します：彼らの議論はLKMLメーリングリストで約2000通の手紙を取りました。



デスクトップコンピューターとラップトップには、エネルギーモードのシステムが確立されています（x86プロセッサーにはいくつかあります）。コンピューターは、何かが実行されると「フルスピード」で実行され、システムがアイドル状態になるとエネルギー効率の高いモードになります。 「スリープ」モードに入るのは、かなり長い時間非アクティブになった後、またはラップトップのふたを閉じるときなど、手動で発生します。



電話では、別のメカニズムが必要でした。システムの主な状態は「休止状態」で、システムからの退出は必要な場合にのみ実行されます。 したがって、アプリケーションがアクティブであっても、システムがスリープ状態になる可能性があります。 Androidは、ウェイクロックメカニズムを実装しました。アプリケーション（またはドライバー）が論理的な結論に達する重要な何かを実行すると、ウェイクロックを「キャプチャ」し、デバイスがスリープ状態になるのを防ぎます。



wakelockメカニズムをカーネルに移植しようとすると、多くの開発者から抵抗がありました。 Androidプログラマーは特定の問題を解決しましたが、その解決策は特定のメカニズムでした。 問題の条件は非常に狭かった。 ターゲットプラットフォームはARMであるため、その機能が使用されました。ARMプロセッサは、当初x86とは異なり、「スリープ」および「ウェイク」動作モードの頻繁な変更を想定していました。 Androidでは、アプリケーションはPowerManagerを介して電源管理システムと通信します。Linuxクライアントアプリケーションは何をすべきですか？



Android開発者は、「将来」に共通のソリューションを見つけようとさえせず、メインコアにシームレスに流れ込み、この問題についてLinuxカーネルコミュニティに相談しませんでした。 それらを責めることはできますか？ 上記のすべての問題と議論にもかかわらず、同じオートスリープ機能を持つAPIがカーネルに登場しました。



プラットフォームとドライバーが「スリープ」モードを考慮して義務を処理するため、Androidアプリケーションプログラマーはめったにwakelock-sに対処する必要はありません。 ただし、使い慣れたPowerManagerは、このプロセスに介入するのに役立ちます。 ちなみに、作者は、BroadcastReceiverからサービスを開始するときに携帯電話がスリープ状態にならないようにするシナリオを1つだけ考え出します。これは、AndroidサポートライブラリWakefulBroadcastReceiverの補助クラスによって決定されます。



低メモリキラー



標準のLinuxカーネルにはOut of Memory Killerがあり、badnessパラメーターに基づいて、強制終了するプロセスを決定します。



badness_for_task = total_vm_for_task / (sqrt(cpu_time_in_seconds) *

sqrt(sqrt(cpu_time_in_minutes)))







したがって、プロセスがメモリをより多く消費し、寿命が短いほど、幸運は少なくなります。



ドキュメントを読んだり、インタビューに合格したすべてのプログラマーは、まずプロセスを「殺す」ことができ、次に無料のリソースがある場合は、他の基準に従ってクラウドアウトの候補を選択することを知っています。「ライブ」Androidコンポーネントの存在、可視性ユーザーなど。



メカニズムは非常に単純です：各プロセスには-17から16までの優先度が割り当てられますが、優先度が高いほどプロセスを強制終了する可能性が高くなり、空きメモリの量に応じて、プロセスが完了する優先度が選択されます。 優先順位はProcessList.javaで説明されています。 興味深いことに、HOME_APP_ADJホーム画面アプリケーションの優先順位は非常に高いですが、私は考えました：なぜそれが常に再起動するのですか？



配列mOomAdjおよびmOomMinFreeLow / mOomMinFreeHighは、「いつ何をクリアするか」というルールを設定するだけです。

 private final int[] mOomAdj = new int[] {FOREGROUND_APP_ADJ, VISIBLE_APP_ADJ, PERCEPTIBLE_APP_ADJ, BACKUP_APP_ADJ, CACHED_APP_MIN_ADJ, CACHED_APP_MAX_ADJ}; private final long[] mOomMinFreeHigh = new long[] {49152, 61440, 73728,86016, 98304, 122880};
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、ホーム画面アプリケーションは、画面に1280x800のRAMと700 MBのRAMを持つ73728 KBの残りの空きメモリで強制的に削除されます。

updateOomLevelsメソッドで確認できるように、ProcessListは対応する値をカーネルに渡します。



プロセスの優先順位は、 Activity Managerを介して通信できる多くのシステムサービスの1つであるActivity Managerサービスによって設定されます。



バインダー



Binderは 、他のソリューション（ファイル、シグマ、ソケット、パイプ、セマフォ、共有メモリなど）とともに、プロセス間通信の問題を解決します。 このソリューションの脚はOpenBinderプロジェクトから発展し、その開発者は一度にAndroidチームに切り替えました。



Bionic （libc実装）はSystem V IPCを使用しません。これは、Android環境では標準ツールがリソースリークを引き起こすためです。



機能：

1. フロー制御（AIDLをサポートするサービスはマルチスレッド環境で動作しなければならないことは誰もが覚えています）。 スレッドの最大数は15（ ProcessState.c 、 open_driverメソッド）であるため、不必要な必要がない限り、バインダースレッドを大量にブロックしないでください。
2. バインダー「 死亡へのリンク 」オブジェクトを保持するプロセスの死亡通知メカニズム。 たとえば、 Window Managerは、これを介して、アプリケーションの終了について学習し、それに関連付けられているウィンドウを削除します。 また、 LocationManagerは、すべてのリスナーが死亡すると、GPS受信機への問い合わせを停止します。 Lowmemorykillerは満足しています。 :)
3. 2つの呼び出しモード：ブロッキングとノンブロッキング（片道）。 前者の場合、呼び出しスレッドはブロックされ、メソッドがハンドラープロセスのスレッドで処理されるのを待ちます。 プログラマはポイントを介してメソッドを呼び出すだけで、プラットフォームはスレッドの相互作用を処理します。
4. セキュリティのためにUIDとPIDを渡します。 システムサービスは、それらを介して、呼び出し元プロセスに要求されたアクションを実行する権利があるかどうかを判断します。
5. Javaプログラマーの場合、バインダートランザクションで呼び出しをJavaメソッドに変換するためのプロキシとスタブを作成するためのツール。

LocationManagerの例でこれがどのように機能するかを見てみましょう。







GPS情報を取得したい場合、次のことが起こります。

1. アプリケーションは、LocationManagerで適切なメソッドを呼び出します。
2. LocationManagerは、Javaメソッドとオブジェクトをバインダートランザクションに変換するプロキシオブジェクトへの呼び出しを委任します（ locationManagerのプロキシオブジェクトはmServiceです）。
3. トランザクションはカーネルドライバーに送信され、カーネルドライバーは.LocationManager.Stubから継承したLocationManagerServiceにリダイレクトします。
4. .LocationManager.Stubは逆の処理を行います。トランザクションをJavaメソッドの呼び出しに展開します。
5. .LocationManagerServiceは要求を処理します（たとえば、GPSドライバーを使用して）。
6. スタブオブジェクトは応答をトランザクションにパックし、プロセスは反対方向に進みます。
7. ドライバーは応答を送り返します。
8. プロキシオブジェクトは、メソッド呼び出しの結果をJavaオブジェクトに解凍します。

ご覧のとおり、システムサービスメソッドの呼び出しの背後にはかなり多くのロジックが隠れています。



アシュメム



匿名共有メモリ（ashmem）-共有メモリメカニズム。 Linuxでは、原則として、このメカニズムはPOSIX SHMを介して実装されます。 Android開発者は、それが十分に保護されていないと考え、マルウェアの手に渡る可能性があります。 ashmemの機能は、リセット時に共有メモリを解放できる参照カウンター（たとえば、使用しているすべてのプロセスが完了するとメモリが解放される）、およびシステムに十分なメモリがない場合の共有領域の削減です。



ashmemの使用例としては、zygoteプロセスがあります。このプロセスでは、Dalvik VMの開始バージョンに基本クラスとリソースがロードされ、残りのアプリケーションはこのメモリを参照するだけです。



バインダーには1 MBのトランザクションサイズ制限があります（そうでない場合、 TransactionTooLargeExceptionがスローされます）。 あるプロセスから別のプロセスに大量のデータを転送する必要がある場合は、 Ashmemを使用できます。MemoryFileを作成し、ファイル記述子を別のプロセスに転送します。



ロガー



通常、従来のディストリビューションでは、dmesgコマンドでアクセスできるカーネルログと、通常/ var / logディレクトリにあるシステムログの2つのログシステムを使用します。



Androidシステムには、ユーザープログラムのメッセージを格納するための循環バッファーがいくつかあり（読み書きサイクルが無駄にならないため、メモリカードの寿命が延びます）、標準syslogで使用されるソケットの操作による追加の遅延はありません。







この図は、一般的なAndroidロギングシステムを示しています。 ロギングドライバーは、/ dev / log / *を介して各バッファーへのアクセスを提供します。 アプリケーションは直接アクセスすることはできませんが、liblogライブラリを介してアクセスします。 liblogライブラリは、 Log 、Slog 、およびEventLogクラスと通信します 。 adb logcatコマンドは、「メイン」バッファーの内容を表示します。



おわりに



この記事では、LinuxシステムとしてのAndroidの機能のいくつかを簡単に調べました。 システムサービス、システムスタートアッププロセスなど、プラットフォーム全体の重要な側面だけでなく、一部のその他の部分（pmem、RAMコンソールなど）も括弧の外に残りました。 このトピックが興味深い場合は、次の記事でそれらを検討します。