From a065e04d529da1d847b5062a12c46d916408bf32 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 21:46:22 -0500 Subject: update based on https://github.com/mdn/yari/issues/2028 --- files/ja/archive/firefox_os/index.html | 271 --------- .../platform/apps_architecture/index.html | 33 -- .../platform/feature_support_chart/index.html | 161 ----- .../firefox_os/platform/gaia/gaia_apps/index.html | 91 --- .../gaia/gaia_apps/window_management/index.html | 408 ------------- .../index.html" | 137 ----- .../index.html" | 115 ---- .../ja/archive/firefox_os/platform/gaia/index.html | 79 --- .../ja/archive/firefox_os/platform/gonk/index.html | 23 - files/ja/archive/firefox_os/platform/index.html | 84 --- .../index.html | 645 --------------------- .../index.html | 138 ----- 12 files changed, 2185 deletions(-) delete mode 100644 files/ja/archive/firefox_os/index.html delete mode 100644 files/ja/archive/firefox_os/platform/apps_architecture/index.html delete mode 100644 files/ja/archive/firefox_os/platform/feature_support_chart/index.html delete mode 100644 files/ja/archive/firefox_os/platform/gaia/gaia_apps/index.html delete mode 100644 files/ja/archive/firefox_os/platform/gaia/gaia_apps/window_management/index.html delete mode 100644 "files/ja/archive/firefox_os/platform/gaia/gaia_apps/\343\203\226\343\203\251\343\202\246\343\202\266/index.html" delete mode 100644 "files/ja/archive/firefox_os/platform/gaia/gaia_apps/\350\250\255\345\256\232\343\202\242\343\203\227\343\203\252/index.html" delete mode 100644 files/ja/archive/firefox_os/platform/gaia/index.html delete mode 100644 files/ja/archive/firefox_os/platform/gonk/index.html delete mode 100644 files/ja/archive/firefox_os/platform/index.html delete mode 100644 files/ja/archive/firefox_os/platform/keyboard_events_across_browser_elements/index.html delete mode 100644 files/ja/archive/firefox_os/platform/out_of_memory_management_on_firefox_os/index.html (limited to 'files/ja/archive/firefox_os') diff --git a/files/ja/archive/firefox_os/index.html b/files/ja/archive/firefox_os/index.html deleted file mode 100644 index 5dc8926610..0000000000 --- a/files/ja/archive/firefox_os/index.html +++ /dev/null @@ -1,271 +0,0 @@ ---- -title: Firefox OS -slug: Archive/Firefox_OS -translation_of: Archive/B2G_OS ---- -

このページには Firefox OS 製品と、基になっている B2G OS についての内容がアーカイブされています。現在の B2G OS についての資料は、 B2G OS のページにあります。

- -

Firefox OS プラットフォーム
B2G OS プラットフォームは、多くのコンポーネントで構成されています。B2G OS で動作するアプリケーションを構築するために B2G OS のアーキテクチャを理解する必要はありませんが、プラットフォームの開発や移植の作業を行っている (あるいは単に興味がある) 場合は、以下のドキュメントが重要であるかもしれません。

- -
-

以下は、Firefox OS のページが公開されていた頃の (B2G OS への変更前の) 内容を貼り付けたものです。

- -
-

Firefox OS は、Mozilla によって開発された新しいモバイル OS であり、Linux の技術と Firefox の強力なレンダリングエンジンである Gecko を基盤としています。

-
- -
-

Firefox OS はオープンソースで開発されたソフトウェアであり、開発者がWebで進歩的なエンドユーザアプリケーションを作成できるパワーと柔軟性を強化します。UI 全体を Web アプリとして開発できることです。つまり、他の Web アプリの表示したり、起動したりも可能なのです。Firefox OS の webアプリは、HTML、CSS、JavaScript を使用して作られており、さらに、Firefox OS の webアプリは、アプリケーション・プログラミング・インターフェイス(API)を通じてモバイル端末のハードウェアにもアクセス可能です。

- -

製品としての Firefox OS は、OS 開発コードネーム Boot to Gecko (B2G) の上に適用された、Mozilla (および OEM パートナー) のブランディングおよびサポートサービスのブランド名です。 Boot to Gecko は、Mozilla の開発チームおよび多数のオープンソースコミュニティの外部コントリビュータによって開発されています。

-
- -
-

Firefox OS 向けのアプリを開発する

- -

Firefox OS 向けの Web アプリの開発に必要な全ての情報がそろっているアプリセンターに進む

-
- -
-
-

プラットフォームガイド

- -

Firefox OS の複数の層にわかれたコンポーネントを協調して動作させる方法について書かれたプラットフォーム開発者向けのガイドです。

- - -
- -
-

ビルド & インストール

- -

エミュレータや互換端末、デスクトップシミュレータ向けに Firefox OS をビルドおよびインストールする方法についてのガイドです。

- - -
- -
-

開発用端末

- -

開発用端末(Developer Phone)の設定の変更、アップデート、リカバリ、購入についての情報について。

- - -
-
- -
-
-

Firefox OS アドオンをはじめよう!

- -

Firefox OS アドオンは新しくFirefox OS 2.5で出ました! アドオン開発を開始し、アドオンコミュニティに参加するには、Getting started with Firefox OS add-onsを読んでください。

-
- - -
- -
-

注: Firefox OS documentation status のページで、Firefox OS関連のドキュメントの作業進捗状況を確認できます。ドキュメントまわりの貢献をしたい場合は、どのような作業が必要かを確認すると良いでしょう。

-
- -

- -
-

Firefox OSコミュニティに参加してください

-
-
あなたの好きな方法でディスカッションに参加してください
- -
- -
-

- - - -
    -
  1. イントロダクション
  2. -
  3. プラットフォームガイド -
      -
    1. Firefox OS プラットフォーム
    2. -
    3. アーキテクチャ
    4. -
    5. アプリ構造
    6. -
    7. Gonk
    8. -
    9. Gecko
    10. -
    11. Gaia
    12. -
    13. Gaia アプリガイド
    14. -
    15. セキュリティ -
        -
      1. The Firefox OS セキュリティ概論
      2. -
      3. システムセキュリティ
      4. -
      5. アプリケーションセキュリティ
      6. -
      7. アプリケーションを安全にインストール、更新する
      8. -
      -
    16. -
    17. Firefox OS の低メモリ管理
    18. -
    19. 機能サポート表
    20. -
    21. Firefox OS の設定一覧
    22. -
    -
  4. -
  5. ビルドとインストール -
      -
    1. Firefox OS のビルドとインストール
    2. -
    3. Firefox OS ビルドの概要
    4. -
    5. Firefox OS ビルドの必要条件
    6. -
    7. 初回ビルドの準備
    8. -
    9. Firefox OS のビルド
    10. -
    11. B2G installer add-on
    12. -
    13. Mac OS X で Flame 用の Firefox OS をビルドする
    14. -
    15. GaiaやFirefox OS の実行方法を選択する
    16. -
    17. 互換性のある端末
    18. -
    19. Firefox シミュレータをビルドする
    20. -
    21. Firefox OS エミュレータを使用する
    22. -
    23. Firefox OS をモバイル端末にインストールする
    24. -
    25. Firefox OS の更新パッケージを作成、適用する
    26. -
    27. Building and installing FOTA community builds
    28. -
    29. B2G ビルド変数のリファレンスシート
    30. -
    -
  6. -
  7. Firefox OS の開発 -
      -
    1. Firefox OS の開発
    2. -
    3. Firefox OSのバグを登録する
    4. -
    5. hostsファイルを編集する
    6. -
    7. .userconfig ファイルをカスタマイズする
    8. -
    9. b2g.shスクリプトをカスタマイズする
    10. -
    -
  8. -
  9. Firefox OSを移植する -
      -
    1. Firefox OS を移植する
    2. -
    -
  10. -
  11. Gaiaの開発 -
      -
    1. Gaiaの開発
    2. -
    3. Gaia コードベースを実行する
    4. -
    5. Gaia コードベースを理解する
    6. -
    7. Gaia のコードに変更を加える
    8. -
    9. Gaia のコードの変更をテストする
    10. -
    11. Gaia のパッチを提出する
    12. -
    13. Gaia ビルドシステム入門
    14. -
    15. ビルド時のアプリをカスタマイズする
    16. -
    17. マーケットカスタマイズガイド
    18. -
    19. Firefox OS内でキーボードをカスタマイズする
    20. -
    21. Firefox OSをローカライズする
    22. -
    23. L10nのベストプラクティス
    24. -
    25. make オプションのリファレンス
    26. -
    27. Gaia ツールのリファレンス
    28. -
    -
  12. -
  13. Firefox OS add-ons -
      -
    1. Firefox OS add-ons overview
    2. -
    3. Developing Firefox OS add-ons
    4. -
    -
  14. -
  15. Firefox OS 電話機ガイド -
      -
    1. Firefox OS 端末ガイド
    2. -
    3. Firefox OS 端末とその仕様
    4. -
    5. Geeksphone
    6. -
    7. ZTE OPEN
    8. -
    9. ZTE OPEN C
    10. -
    11. Flame
    12. -
    13. Firefox OS 端末の機能
    14. -
    15. Firefox OS のトラブルシューティング
    16. -
    17. オープンリファレンス端末向けのベストプラクティス
    18. -
    -
  16. -
  17. Firefox OS on TVs and connected devices -
      -
    1. TVs and connected devices overview
    2. -
    3. How to connect WebIDE to TV (VIERA CX/CR series)
    4. -
    5. TV broadcast streams on Firefox OS products
    6. -
    7. Web animations on large screens
    8. -
    9. Implementing TV remote control navigation
    10. -
    11. Keyboard events in Firefox OS TV
    12. -
    13. TV remote control button mapping to keyboard
    14. -
    15. Firefox OS for TV UX Overview
    16. -
    -
  18. -
  19. Firefox OS リリースノート -
      -
    1. Firefox OS 開発者向けリリースノート
    2. -
    3. Firefox OS 2.5 for developers
    4. -
    5. Firefox OS 2.2 for developers
    6. -
    7. Firefox OS 2.1 for developers
    8. -
    9. Firefox OS 2.0 for developers
    10. -
    11. Firefox OS 1.4 for developers
    12. -
    13. Firefox OS 1.3 for developers
    14. -
    15. Firefox OS 1.2 for developers
    16. -
    17. Firefox OS 1.1 for developers
    18. -
    19. Firefox OS 1.0.1 for developers
    20. -
    -
  20. -
  21. 自動テスト -
      -
    1. Firefox OS の自動テスト
    2. -
    3. Firefox OS 上でテストを実行する: 開発者向けガイド
    4. -
    5. The Mozilla integrated tools package
    6. -
    7. Gaia UI テスト
    8. -
    9. Gaia integration tests
    10. -
    11. Gaia ユニットテスト tests
    12. -
    13. Gaia パフォーマンステスト
    14. -
    15. Mochitests
    16. -
    17. Reftests
    18. -
    19. WebAPI テスト
    20. -
    21. xpcshell テスト
    22. -
    23. MTBF テスト
    24. -
    25. Marionette
    26. -
    27. Treeherder
    28. -
    -
  22. -
  23. デバッグ -
      -
    1. Firefox OS をデバッグする
    2. -
    3. Firefox OS 用の開発者設定
    4. -
    5. Firefox OS 端末をコンピュータに接続する
    6. -
    7. Firefox 開発ツールを使用して Firefox OS をデバッグするためのセットアップ
    8. -
    9. 端末上でコンソールログを取る
    10. -
    11. ADB をインストールして使用する
    12. -
    13. スクリーンショットを撮る
    14. -
    15. WebIDE を使用する
    16. -
    17. アプリマネージャを使用する
    18. -
    19. Firefox OS クラッシュレポート
    20. -
    21. Firefox OS の低メモリエラーをデバッグする
    22. -
    23. Firefox OS のデバッグとセキュリティテスト
    24. -
    25. gdb と関連ツールを使用して B2G をデバッグする
    26. -
    27. Valgrind を使用して B2G をデバッグする
    28. -
    -
  24. -
diff --git a/files/ja/archive/firefox_os/platform/apps_architecture/index.html b/files/ja/archive/firefox_os/platform/apps_architecture/index.html deleted file mode 100644 index 5ff3b86b19..0000000000 --- a/files/ja/archive/firefox_os/platform/apps_architecture/index.html +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: B2G OS アプリのアーキテクチャ -slug: Archive/Firefox_OS/Platform/Apps_architecture -tags: - - Apps - - B2G OS - - Guide -translation_of: Archive/B2G_OS/Platform/Apps_architecture ---- -

アプリケーションを開発、配布するにあたって、B2G OS 上でアプリがどのように起動、管理されるのか、その詳細について理解する必要はありませんが、多少なりとも関心はあるかもしれません。また、この情報は B2G OS プラットフォーム開発者や、OS を新しいハードウェアへ移植するチームにとっても有益なものとなるでしょう。

- -

アプリの起動プロセス

- -

ユーザが起動したいアプリを選択した場合、あるいはアプリが起動される必要がある場合、App API からのアプリ参照を得ることによってホーム画面アプリが起動し、App.launch() メソッドを呼び出してアプリを起動します。

- -

Gecko はそのリクエストを受け取り、System アプリへ mozChromeEvent を送り、アプリの詳細を伝えます。System アプリは、自身の DOM ツリーへ新しい <iframe> を挿入し、そこにアプリを読み込むことで、そのイベントを処理します。アプリが終了するまで、そのフレームがアプリの居場所となります。

- -

各アプリはアプリの情報を記述したマニフェストを必要とし、そのパッケージ内で特定のファイル構造を持ちます。詳しくは アプリマニフェスト の記事を参照してください。

- -

Gecko との通信

- -

Gecko と Gaia の System アプリ間の通信は mozChromeEventmozContentEvent を通じて行われます。mozChromeEvent はクロームからコンテンツへの送出であり、mozContentEvent はコンテンツからクロームへの送出です。この通信は、信頼された UI の作成と閉鎖を管理したり、通知やその他のタスクのために必要な機能を挿入したりするのに使用されます。これにはあるアプリを起動するよう System アプリへ伝えることも含まれます。

- -
-

注: これに関するドキュメントは、System アプリやその下層の対応コードに取り組んでいる開発者が主に関心を持つものとはいえ、整備する必要があります。今のところ、b2g/chrome/content/shell.js にあるコードを参照することで、これがどのように使われているか、多くの情報を収集できます。

-
- -

関連記事

- - diff --git a/files/ja/archive/firefox_os/platform/feature_support_chart/index.html b/files/ja/archive/firefox_os/platform/feature_support_chart/index.html deleted file mode 100644 index 5e37cc2be4..0000000000 --- a/files/ja/archive/firefox_os/platform/feature_support_chart/index.html +++ /dev/null @@ -1,161 +0,0 @@ ---- -title: 機能サポート表 -slug: Archive/Firefox_OS/Platform/Feature_support_chart -tags: - - B2G - - QA - - Testing -translation_of: Archive/B2G_OS/Platform/Feature_support_chart ---- -

- -
-

あなたが自分でダウンロードやビルドできる、Firefox OS の種々のビルドがあります、そして各端末で利用可能な機能の種類はいくらか異なっています。下記の図表は、色々なビルドで何が動いて何が動かないかを理解するのに役立ちます。

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
機能端末エミュレータデスクトップ
ダイヤラー全てUI のみ、ネットワークなしUI のみ、ネットワークなし
連絡先全て全て全て
SMS全てUI のみ、ネットワークなしUI のみ、ネットワークなし
カメラ全てUI のみ、カメラサポートなしUI のみ、デスクトップのカメラサポートは現在不明
ギャラリー全て全て全て
ビデオ全てUI のみ全て
音楽全て 全て
FM ラジオ全て全てUI のみ
Eメール全て全て全て
電卓全て全て全て
ブラウザ全て全て全て
Marketplace全て全て全て
時計全て全て全て
カレンダー全て全て全て
ホーム画面全て全て全て
ロック画面全て全て全て
キーボード全て全て全て
タスクマネージャ全て全て全て
初回起動全て??
通知全て全て全て
ステータスバー全ていくつかのネットワーク状態はテスト不可いくつかのネットワーク状態はテスト不可
設定全て全て全て
- -

 

diff --git a/files/ja/archive/firefox_os/platform/gaia/gaia_apps/index.html b/files/ja/archive/firefox_os/platform/gaia/gaia_apps/index.html deleted file mode 100644 index 79630998cd..0000000000 --- a/files/ja/archive/firefox_os/platform/gaia/gaia_apps/index.html +++ /dev/null @@ -1,91 +0,0 @@ ---- -title: Gaia アプリ -slug: Archive/Firefox_OS/Platform/Gaia/Gaia_apps -tags: - - Apps - - Architecture - - B2G OS - - Gaia -translation_of: Archive/B2G_OS/Platform/Gaia/Gaia_apps ---- -
-

Gaia は B2G OS のフロントエンドで、システム管理機能とB2G OS端末に組み込まれて出荷されるアプリスイートを含んでいます。Gaia のソースコード全ては(システムやキーボード IME さえも)完全にHTML5 (HTML + CSS + JavaScript) と オープンな WebAPIで実装されています。この一連の文書は、Gaiaファミリーの中で利用できる各デフォルトアプリがどのように動作するのかについての情報を含みます。

-
- -

Gaia 機能性カテゴリ

- -

Gaiaの内部の様々なアプリは、おおまかに下記のグループに分類できます。

- -
-

: 個々のアプリの動作について詳しく説明するための多くのリンク先は、Gaia Github repo の中の READMEページです。その理由は、多くのアプリが高速開発サイクルの途中で、ゆえに高速に (しばしば毎日) 変わり、よってその変更と合わせてMDNページを更新し続けるのはほとんど意味がないためです。エンジニアがメンテする READMEページが、現在最も正確な情報元です。

-
- -

プラットフォーム

- -

システム、設定、ロック画面、ビルドスクリプト、Bluetoothアプリを含みます。

- -

- -

プラットフォームアプリ: 更なる説明

- -
-
システム
-
システムアプリは B2G OS 起動処理の中でGeckoによりロードされる最初のwebアプリで、一般的にシステムを動作させるのに必要となり、ゆえに個々のwebアプリに含まれない、多数の責務を処理します。
-
ブラウザ
-
ブラウザアプリ (いまはシステムの一部です) はブラウザ同様の機能を、必要に応じて (ページナビゲーションや、検索、ブックマークを含めて) 提供します。
-
ウィンドウ管理
-
B2G OSのウィンドウ管理機能 (アプリのライフサイクルや相互作用、通知、アニメーションその他たくさん) はシステムアプリの特定部分によって処理されます。この記事では B2G OS のウィンドウ管理を詳細に見ていきます。
-
設定
-
設定アプリは B2G OS ユーザに端末設定の調整を可能にし、外から来るアクティビティ(configureという名のWebアクティビティ) に応答します。このアクティビティは、他のアプリに対し設定アプリの他のパネルへの移動を可能にして、必要な調整が (例えば、データ接続が利用できない時に、wifi 設定パネルを表示する) できるようにします。
-
- -

通信

- -

ダイヤラー、連絡先、SMSアプリと、FTUアプリを含みます。

- -

- -

通信アプリ: 更なる説明

- -

TBD

- -

生産性

- -

Eメール、カレンダー、時計アプリを含みます。

- -

- -

生産性アプリ: 更なる説明

- -
-
カレンダー
-
B2G OS にビルトインされたカレンダーアプリ
-
時計
-
B2G OSのデフォルト時計アプリで、アラームやタイマーやストップウォッチ機能を含む。
-
Eメール
-
Gaia Eメールアプリ
-
- -

メディア

- -

カメラ、ギャラリー、音楽、ビデオアプリと、DRMや壁紙のようないくつかのメディア関連機能を含みます。

- -

- -

メディアアプリ: 更なる説明

- -
-
ビデオ
-
ビデオは単純なビデオプレイヤーアプリで、B2G OS 端末のストレージメディアにあるビデオ再生をします。
-
カメラ
-
カメラでは B2G OS ユーザが自分の端末のカメラからビデオ・写真を撮影・管理するようにできて、カメラ機能を使ってメディアを捉えようとする、 他のアプリからの pick タイプのWeb アクティビティに応答します。
-
- -

その他のGaiaの機能

- -

これらの機能に加えて、その他の主要な機能、例えばブラウザ、ホーム画面、marketplace、テストフレームワーク、PDF ビューワ、アプリマネージャ、といったGaiaに緊密に開発されるものがあります。

- -
-
pdf.js
-
pdf.js はHTML5ベースのPDFビューワで、Gaia内でPDFを見るのに使われます。気をつける点として、pdf.js のコードベースはGaiaの外にある独立したリポジトリで保守されています。
-
diff --git a/files/ja/archive/firefox_os/platform/gaia/gaia_apps/window_management/index.html b/files/ja/archive/firefox_os/platform/gaia/gaia_apps/window_management/index.html deleted file mode 100644 index 91d69c539f..0000000000 --- a/files/ja/archive/firefox_os/platform/gaia/gaia_apps/window_management/index.html +++ /dev/null @@ -1,408 +0,0 @@ ---- -title: Window Management -slug: Archive/Firefox_OS/Platform/Gaia/Gaia_apps/Window_Management -tags: - - Apps - - B2G - - Firefox OS - - Window Management - - system -translation_of: Archive/B2G_OS/Platform/Gaia/Gaia_apps/Window_Management ---- -
-

一般的に、ウィンドウマネージャーはグラフィックユーザーインターフェイスのウィンドウの配置や表示を制御するアプリケーションの一部です。この記事では Firefox OS がウィンドウ管理をどのようにハンドリングしているか記載しています。

-
- -

Firefox OS では、ウィンドウ管理は System アプリの一部で、以下の責務があります。

- - - -

各アイテムの説明にいく前に、Gaia でアプリがどのように起動するかを説明します。

- -

Gaia でのアプリ起動説明

- -

Firefox OS ではアプリの起動方法はいくつかあります。例えばほかのアプリから作られたシステムメッセージ経由で起動したり、ホームスクリーン上のアイコンをタップすることによる起動などあります。

- -

- -

アプリを開く制御のイベントは Gecko エンジンや System アプリによってハンドリングされます。これについては下で説明します。

- -

アプリ構造

- -

Gaia の webapps はHTML、CSS、JavaScript、image、マニフェストなどのアプリケーションアセットのすべてが含まれる zip ファイルである パッケージ型アプリがあります。Gaia の webapp は以下の基本構造で構成されています。

- -
-
-
apps/[app name]/
- - js
- - styles
- - locales
- - test
- - index.html
- - manifest.webapp
-
-
-
- -

- -

ビルトインの Gaia アプリがホームスクリーンから起動した際、Gecko は manifest://[app name].gaiamobile.org:8080 という URL を開こうとし、manifest.webapp の場所に変換して マニフェストの launch_path で定義されている index ファイルを実行します。(すべてのビルトインアプリは launch_path は index.htmlです。)  index.html ファイルでは必要となるスタイルシートや JavaScript をロードします。

- -
-

注意:インフォーマルな慣習として、Gaia アプリの メイン JavaScript のエントリーポイントは通常 [app name].js もしくは main.js です。

-
- -

アプリ起動シーケンス

- -

イベントは Gecko へ通知されます。Gecko の準備ができていれば、system/js/app_window_factory.js から AppwindowFactory に アプリの起動イベントである webapps イベントか、システムメッセージの保留をハンドリングするための open-app イベントが送られます。

- -
window.addEventListener('applicationready', function appReady(e) {
-  window.removeEventListener('applicationready', appReady);
-  window.addEventListener('webapps-launch', self);
-  window.addEventListener('webapps-close', self);
-  window.addEventListener('open-app', self);
-});
- -

イベントハンドリング部分の詳しい説明として、this.launch(config) はアプリウィンドウもしくはアクティビティとして起動します。アプリを閉じると、Appwindow は 閉じるイベントである webapps-close イベントを受信します。

- -

launch() メソッドのメイン処理は以下の通りです。

- -
var app = AppWindowManager.getApp(config.origin);
-if (app) {
-  app.reviveBrowser();
-} else if (config.origin !== homescreenLauncher.origin) {
-  new AppWindow(config);
-} else if (config.origin == homescreenLauncher.origin) {
-  homescreenLauncher.getHomescreen().ensure();
-}
- -

コードでは最初に、アプリ変数の存在をチェックし、Gecko で再度起動させます。アプリ変数が無いとき、通常アプリであれば アプリのための AppWindow インスタンスを生成します。それ意外は homesecreenLauncher から起動した場合です。最後のケースの場合、必要となる操作を実行します。

- -

AppWindow

- -

Firefox OS はウェブページがアプリとして動作するように特殊な mozBrowser API を利用します。ウィンドウ管理のルートは内部の iFrame(ウィンドウ) をラップするための mozBrowserAPI です。moz-browser タイプの特殊な iFrame は実際のブラウザとして動作する iFrame を作成します。

- -

AppWindow mozBrowser iFrame の生成、包含、管理をします。AppWindow は自信の mozBrowser iFrame が発火したすべての mozBrowser イベントを操作し、適切な UI 機能を表示します。

- -

アプリライフサイクル管理

- -

アプリの完全なライフサイクルは以下の通りです。

- - - -

アプリの起動

- -

ユーザーがホームスクリーン上のアイコンをタップしたとき、ホームスクリーンは  Gecko エンジンに適切なアプリがオープンされたことを mozApps API を使って通知します。

- -

アプリの kill

- -

アプリは以下の条件下で終了されます。

- - - -

アクティビティアプリは、非表示アニメーションを表示する前に、DOM ツリーから終了されたアプリの iFrame を削除します。前面でないアプリのとき、アプリ終了する際即時に iframe を除去します。

- -

アプリは以下の条件下で中断します。

- - - -

アプリの再起動

- -

アプリは以下の条件で再起動します。

- - - -

アプリのレンダリング

- -

アプリ起動時、以下のブロックによりスクリーンは描画されます。

- - - -

- -

アプリレイアウト

- -

アプリの iFrame のメインコンテナは以下のようになっています。

- -
<iframe id="browser2" mozallowfullscreen="true" mozbrowser="true" remote="true"...
-... src="", data-url="" data-frame-type="window" data-frame-origin="...">
-</iframe>
- -

iframe には以下の要素を含みます。

- - - -

AppWindow のリサイズ

- -

AppWindow は以下の条件の場合にリサイズします。

- - - -

- -

要約すると、ウィンドウサイズは以下のものに影響を受けます。

- - - -

- -

アプリウィンドウの回転

- -

アプリ画面の回転は各アプリから制御可能です。もしくはシステムから全体的に回転の制御はできます。orientation プロパティを manifest.webapp に記載することで、アプリ画面の回転を指定出来ます。以下はその一例です。

- -
"orientation": "default",
- -

orientation API を利用して回転のロック / アンロックを制御することも出来ます。

- -
screen.mozLockOrientation([‘portrait-primary’]);
-
-screen.mozUnlockOrientation();
- -

強制的に回転させるパラメータ値はいくつか存在します。

- - - -

入手可能な詳細な情報については、Screen.lockOrientation を参照してくたさい。また、サンプルは gaia/dev_apps/uitest/js/API/orientation.js から入手出来ます。

- -

- -

アプリの可視性

- -

System アプリはスクリーンがオフになった時だけバックグラウンドになりますが、一般のアプリは以下のいくつかの条件の時にバックグラウンドになります。

- - - -
-

注意: ページの可視性は親 iframe が非アクティブの期間は継承されます。

-
- -

アプリは以下の時は常にフォアグランドになります。

- - - -

以下の時は、常にバックグラウンドです。

- - - -

上記以外の例外もいくつかあります。

- - - -

アプリウィンドウのアニメーションとトランジション

- -

Gaia のウィンドウマネージャーも、アプリウィンドウのアニメーションと滑らかなユーザーエクスペリエンスを実現するためのトランジションを提供してます。

- -

アプリウィンドウのアニメーションとトランジションは、以下の状態で管理されています。

- - - -

setDisplayedApp() メソッド呼び出し中は、アプリは以下の図にあるとおりの状態を遷移して起動します。

- -

- -

Firefox OS アニメーション管理のための以下のようなトリックが組み込まれています。

- - - -

- -

アプリウィンドウの UI 仕様

- -

ブラウザーの chrome やモーダルダイアログ、コンテキストメニュー、ポップアップやエラーページのように、特定のアプリに関連するいくつかの UI 要素が存在します。

- -

この事について以下の議論をしてみましょう。

- -

モーダルダイアログ

- -

Oデスクトップ版 Firefox では、web 開発ツールのコンソールを開き alert()や confirm() 、prompt()  コマンドを入力すると、コンテンツ上にの中央に表示されるダイアログを得ることができます。これは、Firefox OS でモーダルダイアログと同等のものになります。

- -


-

- -

コンテキストメニューダイアログ

- -

コンテキストメニュー(もきくは長押メニュー)はモバイル開発のコンセプトの1つです。一般のアプリとして作られている場合、頻繁に利用されるアクションはユーザーにとってアプリを利用しやすいように表示されるべきです。コンテキストメニューは、すぐには表示されないが、すぐに利用可能にするべきアクションのための配置場所を提供します、
-
-

- -

(https)認証ダイアログ

- -

system/js/app_authentication_dialog.js に定義しています

- -

日付、時刻等の選択ダイアログ

- -

system/js/value_selector/ に定義しています

- -

権限ダイアログ

- -

system/js/permission_manager.jssystem/js/media_recording.js (トレイパネルのユーティリティ)に定義しています

- -

特殊なアプリ

- -

特殊なアプリに含まれる特殊な機能を実行するために、特別なアプリウィンドウオブジェクトを必要とするアプリが存在します。

- - - -

子ウィンドウ管理

- -

子アプリウィンドウは直接的または、間接的にほかのアプリやページから開かれます。例えば、以下のようなものです。

- - - -

子ウィンドウが通常終了した場合、親ウィンドウは再度開かれます。ある種の子ウィンドウは、他の子ウィンドウを伴うこともあります。親子のプロセス管理が重要になってきます。

- -

警告ウィンドウ

- -

警告ウィンドウは以下の警告で利用されます。

- - - -

現在これらの警告ウィンドウは、デフォルト回転(ポートレート優先)に強制されます。

- -

信頼された UI

- -

Persona や mozPay API は信頼された UI を利用します。これらは全体の 80% に定められています。信頼された UI が動作している間はホームスクリーンの一部が表示されるようになっています。
-
-

- -

履歴管理

- -

このセクションでは、FIrefox OS での履歴管理のハンドリングをする、いくつかのコンポーネントを説明します。

- -

タスクマネージャー

- -

タスクマネージャー(カードビュー)はホームボタンの長押しでトリガーされます。端末のアプリ履歴を表示し、アプリを終了することが可能です。

- -

Firefox 2.0 から、表示されて存在しているふりをするゾンビアプリも取得可能な機能になっています。

- -

Web activity 配置

- -

インラインのアクティビティはアクティビティのデータを提供するための新しい参照ページを作成します。
-
- ウィンドウアクティビティは、存在しているウィンドウが消費したアクティビティデータを再利用します。

- -

エッジジェスチャー(実験的)

- -

実験的エッジジェスチャー機能は Firefox OS 2.0 以上の開発者モードで利用可能です。そして、アプリや web ページ間の移動を画面端の右/左からスワイプすることで可能にします。

- -

次に表示されるアプリはどのように選ばれるの?

- - - -

前に表示されるアプリはどのように選ばれるの?

- - - -

スクリーンショット管理

- -

スクリーンショットツールはタスクマネージャーがアプリの履歴を表示するために利用します。アプリの終了アニメーション中にアプリのスクリーンショットは撮られます。

- -

関連項目

- -

From Browser to Browser

diff --git "a/files/ja/archive/firefox_os/platform/gaia/gaia_apps/\343\203\226\343\203\251\343\202\246\343\202\266/index.html" "b/files/ja/archive/firefox_os/platform/gaia/gaia_apps/\343\203\226\343\203\251\343\202\246\343\202\266/index.html" deleted file mode 100644 index 3e2906a61f..0000000000 --- "a/files/ja/archive/firefox_os/platform/gaia/gaia_apps/\343\203\226\343\203\251\343\202\246\343\202\266/index.html" +++ /dev/null @@ -1,137 +0,0 @@ ---- -title: ブラウザ -slug: Archive/Firefox_OS/Platform/Gaia/Gaia_apps/ブラウザ -tags: - - Apps - - B2G - - B2G OS - - Browser - - Gaia - - Guide -translation_of: Archive/B2G_OS/Platform/Gaia/Gaia_apps/Browser ---- -
-

ブラウザアプリ (現在は System の一部です) は、ページナビゲーション・検索・ブックマークなどを含むブラウザとして必要な機能を持っています。この記事では ブラウザアプリの基本的な機能の動作と、巨大なシステムの一部として動作していることについて説明します。

-
- -

Gaia は Gecko 上で動作しています。これは、Gekco インスタンスとして一般的な Web ページをナビゲートするブラウザアプリや System ブラウザ を設計可能にしています。これは、mozBrowser API を操作することにより可能になっています。

- -
-

注意: B2G OS 2.1 以上から、ブラウザアプリは System アプリの一部となっています。これは、ブラウザアイコンをクリックして開いたり、ユニバーサルサーチからアクセスしたり、ナビゲーションケイパビリティからアクセスできることを意味しています。このアプリとブラウジングタブは今後 Haida ユーザーエクスペリエンスとして共通のエクスペリエンスとして統合され、タスクマネージャーに表示・シートとして表示(エッジジェスチャー)されます。

-
- -

システムブラウザ (Browser Chromeブラウザ クローム)

- -

B2G OS ユーザーがホームスクリーンに表示されるように Web ページをブックマークした際、ブラウザアプリの代わりにシステムブラウザを開くサブシーケンスが動作します。これは画面下に戻る・進む・更新機能を含むツールバーを持っています。Gaia では、この機能を Browser Chrome または wrapper と呼んでいます。以下の図のように右下の矢印を押したときに表示されます。

- -

A diagram showing that when a web page is opened in the system browser, it is given a toolbar.

- -

もし Web ページで戻る・進む・更新機能を利用したい場合、アプリマニフェストに以下のように Browser Chrome を有効にすることで実現できます。

- -
declare { chrome: { navigation: true } }
- -
-

注意: Browser Chrome のツールバーはコンテンツの高さに影響します。そのため、Web ページレイアウトに考慮する必要があります。

-
- -

処理順番

- -

B2G OS 上で新しい Web ページを開いた際、以下の処理順番になります。

- -
Gecko > WrapperFactory > Window Manager > AppWindow > BrowserFrame
- -

system/js/wrapper_factory から継承している Wrapper は mozbrowseropenwindow イベントをブックマークページから受信します。

- -

handleEvent 部分で、ハンドラーは Web ページをブラウザアプリ・Browser Chrome どちらで開くかを定義したイベントをチェックします。

- -

最後に、一致するウィンドウ上で起動するために launchWrapper が実行されます。

- -

ユニバーサルサーチとナビゲーション

- -

新しい検索とナビゲーションバーでは、B2G OS 上からユーザーはお気に入りページや、入力した URL 、新しいアプリを入手することができます。

- -

B2G OS は web アプリを利用しており、欲しいアプリがインストールされていない新しいアプリだとしてもすぐに開くことができます。そのため、この機能はブラウザからのスマートロケーションバーやホームスクリーンからの adaptive app search の組み合わせとみなせます。全ては web ライクですぐに使えるため、何もインストールする必要はありません。

- -

ブラウザアプリ

- -

ブラウザアプリは一般的なブラウザ体験を提供するための認定 web アプリです。メイン機能は apps/browser/js/browser.js にあります。

- -
var Browser = {
-  init: function browser_init() {
-    this.getAllElements();
-      ...
-    BrowserDB.init((function() {
-      ...
-    }
-  }
-};
-
-window.addEventListener('load', function browserOnLoad(evt) {
-  window.removeEventListener('load', browserOnLoad);
-  Browser.init();
-});
- -

ブラウザは DOM がロードされた時に init() 関数を実行します。

- -
getAllElements: function browser_getAllElements() {
-  var elementIDs = [
-    'toolbar—start', ... 'danger—dialog'];
-
-  // Loop and add element with camel style name to Modal Dialog attribute.
-  elementIDs.forEach(function createElementRef(name) {
-    this[this.toCamelCase(name)] = document.getElementById(name);
-  }, this);
-},
- -

getAllElements 関数は全てのキャメルケース要素のハンドラーを取得した後に、 apps/browser/js/browser_db.js を実行しデフォルトのサーチエンジンやブックマークの追加の準備をするために利用します。

- -

ブックマーク

- -

B2G OS 2.0 から apps/bookmark はブックマークの保存 / 削除アクティビティのハンドラーとして利用しています。

- -

最も興味深い実装として、以下のような apps/bookmark/webapp.manifest の部分です。

- -
"activities": {
-  "save—bookmark": {
-    "filters": {
-      "type": "url",
-      "url": { "required":true, "pattern":"https?:.{1,16384}" }
-    },
-    "disposition": "inline",
-    "href": "/save.html",
-    "returnValue": true
-  },
-  "remove—bookmark": {
-    "filters": {
-      "type": "url",
-      "url": { "required":true, "pattern":"https?:.{1,16384}" }
-    },
-    "disposition": "inline",
-    "href": "/remove.html",
-    "returnValue": true
-  }
-},
- -

上述しているように、アクティビティは save.html や remove.html によってハンドリングされています。この操作は apps/bookmark/js/activity_handler.js によってデリゲートされています。

- -
var ActivityHandler = {
-  'save—bookmark': function ah_save(activity) {
-  },
-
-  'remove—bookmark': function ah_remove(activity) {
-  }
-};
-
-navigator.mozSetMessageHandler('activity', function onActivity(activity) {
-  var name = activity.source.name;
-  switch (name) {
-    case 'save—bookmark':
-    case 'remove—bookmark':
-      if (activity.source.data.type === 'url') {
-        ActivityHandler[name](activity);
-      }
-    ...
-  }
-}
- -

メッセージハンドラのリスナーである navigator.mozSetMessageHandler('activity') が save-bookmark または remove-bookmark アクティビティのメッセージを受信したときに、ActivityHandler 関数は対応する操作のハンドラーを呼び出します。

diff --git "a/files/ja/archive/firefox_os/platform/gaia/gaia_apps/\350\250\255\345\256\232\343\202\242\343\203\227\343\203\252/index.html" "b/files/ja/archive/firefox_os/platform/gaia/gaia_apps/\350\250\255\345\256\232\343\202\242\343\203\227\343\203\252/index.html" deleted file mode 100644 index d3713c8627..0000000000 --- "a/files/ja/archive/firefox_os/platform/gaia/gaia_apps/\350\250\255\345\256\232\343\202\242\343\203\227\343\203\252/index.html" +++ /dev/null @@ -1,115 +0,0 @@ ---- -title: 設定アプリ -slug: Archive/Firefox_OS/Platform/Gaia/Gaia_apps/設定アプリ -tags: - - Apps - - B2G - - B2G OS - - Gaia - - JavaScript - - Settings -translation_of: Archive/B2G_OS/Platform/Gaia/Gaia_apps/Settings ---- -
-

設定アプリは、デバイスの設定変更する事を許可し、アプリから表示要求のあったアクティビティに反応します。(例えば、ネットワーク接続していない時に、アプリが設定アプリに対して wifi 設定パネルを要求するなど) この記事では、この設定アプリがどのように動作しているか説明します。

-
- -

mozSettings API と Data binding

- -

技術的にいうと、設定アプリは認定アプリが利用できる  window.navigator.mozSettings API を利用して設定にアクセスするための UI を提供しています。設定アプリはバインドされたデータフィールドや mozSettings 値の様な基本的な設定操作を自動でハンドリングします。全ての

- -

The Settings app automatically handles basic settings operations such as binding data fields and mozSettings values — all basic operations such as toggling a setting or changing an input value will also result in the relevant mozSettings value being changed.

- -

The window.navigator.mozSettings API accesses the settings data from Gecko. The usage looks something like this:

- -
navigator.mozSettings.createLock().set(values);
- -

For set data.

- -
-

Note: We need to use createLock() to lock the settings before reading or writing any mozSettings values.

-
- -

To retrieve data, we could use get and set a callback function to start some operation upon the data:

- -
var reqTimerGoBack =
-window.navigator.mozSettings.createLock().get('icc.goBackTimeout');
-reqTimerGoBack.onsuccess = function icc_getTimerGoBackSuccess() {
-  goBackTimer.timeout = reqTimerGoBack.result['icc.goBackTimeout'];
-    ...
-};
- -

The data is stored in an instance.result dict.

- -

From B2G OS 2.0, a single mozSettings instance can be reused via js/modules/settings_cache.js:

- -
var SettingsCache = require('modules/settings_cache');
-
-SettingsCache.getSettings(function(result){
-  var onlineSupportTitle = result['support.onlinesupport.title'];
-    ...
-});
- - - -

When users open the Settings app, they see several panels listed on the overview page, which are functional independent pages. SettingsService.navigate (js/module/settings_service.js) controls navigation between those pages.

- -
-

Note: For legacy panels (which are not yet ported to the new structure), settings.currentPanel is used instead of SettingsService.navigate to navigate
- between panels.

-
- -

Since B2G OS will support tablet devices as well as mobiles, the Settings app has two different types of navigation model implemented:

- - - -

While called, SettingsService.navigate determines what navigation model to use via the following code:

- -
if (_isTabletAndLandscape()) {
-  PageTransitions.twoColumn(oldPanel, newPanel, callback);
-} else {
-  PageTransitions.oneColumn(oldPanel, newPanel, callback);
-}
- -

Panels

- -

From B2G OS 2.0 onwards, the basic panel structure is defined in js/modules/panel.js. It defines six lifecycle stats:

- - - -

All new settings panels are inherited from SettingsPanel, which extends Panel’s functionalities. The code is contained in js/modules/settings_panel.js:

- -
onInit: function(panel, initOptions) {
-  ...
-
-  PanelUtils.activate(panel);
-},
-
-onBeforeShow: function(panel, beforeShowOptions) {
-  // Preset the panel every time when it is presented.
-  PanelUtils.preset(panel);
-  _addListeners(panel);
-  ...
-},
- -

PanelUtils.activate — defined in js/modules/panel_utils.js — is used to parse all links in the panel and adds corresponding handlers in onInit stat, and PanelUtils.preset is used to preset elements with the settings values in the onBeforeShow stat.

- -

All new settings panels are defined in the js/panels folder.

- -

AMD module and Build time optimization

- -

From B2G OS 2.0 onwards, the Settings app uses the AMD modules pattern to implement each panel. The AMD modules are loaded via Alemeda (a lighter version of RequireJS) and built/optimized using r.js (the RequireJS optimizer). The Settings app still had dependencies on files (shared/js) which aren’t AMD modules. For those it uses the shim options defined in settings/js/config/require.js.

- -

See also

- -

The Settings app has a build-in README which is useful to read for a further information on Settings (Mainly written by Arthur Chen and Fred Lin).

diff --git a/files/ja/archive/firefox_os/platform/gaia/index.html b/files/ja/archive/firefox_os/platform/gaia/index.html deleted file mode 100644 index 254aabf34f..0000000000 --- a/files/ja/archive/firefox_os/platform/gaia/index.html +++ /dev/null @@ -1,79 +0,0 @@ ---- -title: Gaia -slug: Archive/Firefox_OS/Platform/Gaia -tags: - - B2G - - Gaia - - Mobile -translation_of: Archive/B2G_OS/Platform/Gaia ---- -

Gaia は B2G OS のユーザインタフェース層です。B2G OS の起動後にスクリーンに表示されるものは、ロック画面、ホーム画面、電話、その他のアプリケーションも含め、全て Gaia によって描画されます。Gaia は 完全に HTMLCSSJavaScript で記述されています。下層のオペレーティングシステムとハードウェアに対するインタフェースのみ、Gecko で実装されている、標準 Web API が使用されています。

- -

この設計のおかげで、Gaia は B2G OS デバイスだけではなく、他のオペレーティングシステムや Web ブラウザ(ブラウザの性能によって機能が低下する可能性がありますが)でも実行することが可能です。

- -

サードパーティアプリケーションは Gaia と併せてインストールされ、Gaia によって起動されます。

- - - - - - - - -
-

Gaia に関するドキュメント

- -
-
Gaia 概論
-
Gaia は B2G OS デバイスのユーザインタフェースアプリケーションです。シンプルな Web アプリケーションで、B2G OS ソフトウェアスタックの最上層で動作します。このガイドは Gaia を高いレベルで紹介します。
-
Gaia アプリ
-
Gaia ファミリー内で利用できるデフォルトアプリそれぞれの情報と、使用法や修正方法を含む。
-
Gaia ハッキングガイド
-
Gaia インタフェースのハッキングや変更と、Gaiaプロジェクトへの貢献に関するガイド
-
- -

全て表示...

-
-

コミュニティの支援を受ける

- -

もし Gaia で作業をしていたり、Gaia アプリケーションを開発したりしているなら、あなたを支援するコミュニティリソースがあります!

- - - -
    -
  • Mozilla の Gaia IRC チャンネルで質問する : #gaia
  • -
- -

ネチケットを忘れないでください...

- - - - - - -

リソース

- - -
- -


-  

diff --git a/files/ja/archive/firefox_os/platform/gonk/index.html b/files/ja/archive/firefox_os/platform/gonk/index.html deleted file mode 100644 index e9ea7d198f..0000000000 --- a/files/ja/archive/firefox_os/platform/gonk/index.html +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: Gonk -slug: Archive/Firefox_OS/Platform/Gonk -tags: - - B2G - - Firefox OS - - Gonk - - NeedsContent -translation_of: Archive/B2G_OS/Platform/Gonk ---- -
-

GonkはFirefox OSプラットフォームのための、Android Open Source Project のLinux Kernelベースと、Userspace Hardware Abstraction Lyaer(HAL)から構成される低レベルオペレーティングシステムです。この記事では、Gonkの構成を説明することに的を絞っています。Firefox OSの全般的なアーキテクチャやGonkがどのようにFirefox OSに最適化されているかは、Firefox OS architecture を読んでください。

-
-

Gonkの概要

-

Geckoのソースコードの中にはb2g/フォルダがあり、モバイルハードウェア機能をウェブ用にアンロックするための、Gonkポートが含まれます。それらにはLinux KernelとHAL、そしてOEMライブラリが含まれます。数種類のGonkのライブラリはcommonオープンソースプロジェクトです。(libusb, bluezなど) いくつかのHALの一部はAndroid プロジェクトと共有しています。(GPS, Cameraなど)

-

Gonkはデバイスを移植するレイヤー(ハードウェアとGecko間をつなぐアダプター役)です。GonkはGeckポーティングレイヤーとペアをなしているGeckoポートを扱うことができる比較的シンプルなLinuxディストリビューションです。(だから、GeckoをOS XやWindows, Androidにポーティングするように、GonkはGeckoをポーティングターゲットとしています。)

-
-

Note:モバイルデバイスはそれぞれ異なるチップセット、異なるハードウェア仕様になります。そのためデバイス毎に異なるGonkディストリビューションが存在します。 

-
-

Firefox OSプロジェクトがGonk全てコントロールするようになって以来、他のオペレーティングシステムでは見せることができないインターフェイスを見せることができています。例えばGeckoは直接テレフォニースタックの全てにアクセスしたり、Gonkのバッファーフレームに描画することができます。

-

Gonk ソースコード

-

B2G repo on Githubには複数のデバイスにポーティングされた公式サポートのGonkをが含まれ、Gonkレポジトリを自身で扱うことができます。サポートしているデバイスリストは B2G/config.shから入手できます。 

-

Gonk作業の日々の大半では、異なるボード上への移植や、異なるデバイス上でGeckoがうまく動作することを確認することです。

diff --git a/files/ja/archive/firefox_os/platform/index.html b/files/ja/archive/firefox_os/platform/index.html deleted file mode 100644 index 75e5786e3c..0000000000 --- a/files/ja/archive/firefox_os/platform/index.html +++ /dev/null @@ -1,84 +0,0 @@ ---- -title: Firefox OS プラットフォーム -slug: Archive/Firefox_OS/Platform -tags: - - Firefox OS - - Landing - - TopicStub -translation_of: Archive/B2G_OS/Platform ---- -
-

B2G OS プラットフォームは、多くのコンポーネントで構成されています。B2G OS で動作するアプリケーションを構築するために B2G OS のアーキテクチャを理解する必要はありませんが、プラットフォームの開発や移植の作業を行っている (あるいは単に興味がある) 場合は、以下のドキュメントが重要であるかもしれません。

-
- - - - - - - - -
-

B2G OS プラットフォームに関するドキュメント

- -
-
B2G OS アーキテクチャの概要
-
B2G OS が内部でどのように組み立てられているかの概要です。これは主に、プラットフォームの開発者や移植作業を行う人々にとって重要です。
-
B2G OS のアプリアーキテクチャ
-
B2G OS のアプリケーションモデルの概要です。
-
Gaia
-
B2G OS 向けのユーザインターフェイスアプリケーションである、Gaia のドキュメントです。これはB2G OS のソフトウェアスタック上で動作する Web アプリケーションです。
-
Gonk
-
Gaia の下のオペレーティングシステム層である、Gonk のドキュメントです。これは Linux カーネルと、Gecko が通信する ハードウェア抽象化層 で構成されています。
-
Gecko
-
Gecko は、Firefox や Thunderbird で使用されているものと同じオープン Web 標準の実装を、その他多くのアプリケーションにも提供するB2G OS のレイヤーです。
-
セキュリティ
-
B2G OS のセキュリティに関するドキュメントです。ここにはあらゆる見地 (アプリ開発者向け、デバイスインテグレータなど) からの、セキュリティの仕組みに関するトピックがあります。
-
B2G OSでの低メモリ管理
-
この記事では、B2G OSにおいて低メモリキラーと低メモリ通知を使って、低メモリな状況をいかに管理するかを説明します。
-
機能サポート表
-
どの種類の B2G OS ビルドでどの機能が利用可能かを示した表です。
-
B2G OS 設定一覧
-
API の設定に使用できる一般的な設定名称の一覧です。
-
- -

すべて見る...

-
-

コミュニティの支援を受ける

- -

もし B2G OS で作業をしていたり、B2G OS デバイスで実行したいアプリケーションを開発したりしているなら、あなたを支援するコミュニティリソースがあります!

- - - -
    -
  • Mozilla の Boot to Gecko IRC チャンネルで質問する (英語): #b2g
  • -
- -

ネチケットを忘れないでください...

- - - - - - -

リソース

- - -
diff --git a/files/ja/archive/firefox_os/platform/keyboard_events_across_browser_elements/index.html b/files/ja/archive/firefox_os/platform/keyboard_events_across_browser_elements/index.html deleted file mode 100644 index 14ff0b1f6d..0000000000 --- a/files/ja/archive/firefox_os/platform/keyboard_events_across_browser_elements/index.html +++ /dev/null @@ -1,645 +0,0 @@ ---- -title: ブラウザ要素をまたいだキーボードイベント -slug: Archive/Firefox_OS/Platform/Keyboard_events_across_browser_elements -tags: - - B2G - - Firefox OS - - TV - - events - - keyboard - - mozbrowser - - mozbrowserafterkeydown - - mozbrowserafterkeyup - - mozbrowserbeforekeydown - - mozbrowserbeforekeyup -translation_of: Archive/B2G_OS/Platform/Keyboard_events_across_browser_elements ---- -

- -

このポストでは、 Firefox OS スマートTVプラットフォームにてTVリモコンをプログラムしてキーボードイベントを管理する試みを紹介します。

- -

The behavior of input events via hardware keys in Firefox OS varies widely from app to app. Early smartphones came with a limited number of keys — Power, Home, Volume up, Volume down — so it was easy for the software to determine an appropriate response for each keypress event. However, Smart TV remotes now come with many hardware keys, and defining the appropriate behavior when a key is pressed has become an important issue on the Firefox OS TV platform. If a hardware key on a smart remote can be used both by apps and by the system, it’s important to determine which response is triggered when the key is pressed.

- -

Here we’ll classify keyboard events into four scenarios, describe dispatch scenarios for each, including how they interact with the system. This is the first of two posts about keyboard events for Firefox OS Smart TV.

- -

Figure.1
- We begin with the ‘Info’ key on a TV remote. Often, it’s used by the hardware to display system information, although it’s possible for an application to use the same key to display app information. When a user presses the key, what action will be shown on screen — system info or app info?

- -

4つのキーボードイベントシナリオ

- -

To determine the appropriate behavior when hardware keys are pressed, we start by describing four scenarios for keyboard events.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
シナリオ説明イベント順序
SYSTEM-ONLYFor keys that should be handled by mozbrowser-iframe-host-page only.system
SYSTEM-FIRSTFor keys that can be handled by mozbrowser-iframe-host-page first and can then also be handled by mozbrowser-iframe-embedded-page.system > app
APP-CANCELLEDFor keys that should be handled by mozbrowser-iframe-embedded-page only.app
APP-FIRSTFor keys that can be handled by mozbrowser-iframe-embedded-page first and can then also be handled by mozbrowser-iframe-host-page.app > system
- -

The mozbrowser-iframe-host-page and mozbrowser-iframe-embedded-page mentioned above are illustrated in the figure below. If A.html represents a host page whose source is B.html, then A.html is the mozbrowser-iframe-host-page, and B.html is mozbrowser-iframe-embedded-page. mozbrowser uses the non-standard Firefox Browser API, built for the implementation of key features and content experiences in Firefox OS apps.

- -

Fig. 2

- -

Suitable responses for any given keyboard events depend on the scenario. In the case illustrated above, let’s suppose that the Info key is categorized as APP-FIRST and the default action set by the system is to show system information. Thus, when we press the ‘Info’ key with app Z in the foreground, there are two possible results:

- -
    -
  1. If app Z has an event handler that tells the ‘Info’ key to show app information, then app information will appear on screen when the user presses the ‘Info’ key on the remote.
  2. -
  3. If app Z doesn’t set an event handler for the ‘Info’ key, the default action is triggered — the screen will show the system information.
  4. -
- -

4つのシナリオ用のサンプルを実装する方法

- -

To implement examples illiustrating the four keyboard event scenarios described above, we’ve introduced four new keyboard events:

- - - -

These four keyboard events are only received by the window that embeds a mozbrowser-iframe.

- -

The keyboard events occur in a specific sequence over time: mozbrowserbeforekeydown, mozbrowserafterkeydown, mozbrowserbeforekeyup, keyup, mozbrowserafterkeyup.

- -

This gives developers a way to implement the four scenarios mentioned above. Conceptually, the scenarios SYSTEM-ONLY, SYSTEM-FIRST and APP-CANCELLED, and APP-FIRST can be implemented by setting proper handlers for the mozbrowserbeforekey* and mozbrowserafterkey* events. The SYSTEM-ONLY and SYSTEM-FIRST scenarios can be implemented by setting proper handlers for mozbrowserbeforekey* events and the APP-CANCELLED and APP-FIRST scenarios can be implemented via mozbrowserafterkey* events.

- -

Firefox OS 内の iframe 構造

- -

- -

To understand how to implement the four scenarios, let’s first take a look at iframe structure in Firefox OS. The outermost iframe in Firefox OS is shell.html. It embeds an in-process iframe sourced from system/index.html. The system app (system/index.html) contains several web apps (essentially iframes) that can be in-process (remote=”false”) or out-of-process (remote=”true”.) The relationship of these three layers is summarised in the following table:

- - - - - - - - - - - - - - - - - - -
mozbrowser iframe host pagemozbrowser iframe embedded page
shell.htmlsystem/index.html
system/index.htmlweb apps(essentially iframes)
- -

キーボードイベントのディスパッチ順序

- -

When a keydown event is sent to some element in a mozbrowser-iframe-embedded-page, the owner of the embedded iframe, i.e., the mozbrowser-iframe-host-page, will receive the mozbrowserbeforekeydown event before the keydown event is sent and the mozbrowserafterkeydown event after the event is sent to the mozbrowser-iframe-embedded-page.

- -

In Gecko, once there is one keydown event with the target in an out-of-process iframe, embedded in an HTML document, the keydown event is duplicated on the HTML document as well. The target of this duplicated event is set as the embedded <iframe> element.

- -

This results in the keyboard event sequence shown in the diagram below. It illustrates all related keydown events and their relationship when a keydown event with a target in a mozbrowser-iframe-embedded-page needs to be dispatched.

- -

- -

In brief, events follow this sequence:

- -
    -
  1. Before dispatching any keydown event, the mozbrowserbeforekeydown event is first dispatched to the window of mozbrowser-iframe-host-page.
  2. -
  3. The original keydown event (with a target in a mozbrowser-iframe-embedded-page) will be duplicated on the mozbrowser-iframe-host-page HTML document. Its target will be set to be the iframe that contains the mozbrowser-iframe-embedded-page.
  4. -
  5. The original keydown event will be dispatched to its target.
  6. -
  7. After the original keydown event dispatch is complete, the mozbrowserafterkeydown event will be dispatched to the window of mozbrowser-iframe-host-page.
  8. -
- -

Notice that the event dispatch process described above follows the DOM tree event flow. Event sequence and event targets are organized as shown in the following table:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
OrderEventTarget
1mozbrowserbeforekeydownwindow in mozbrowser-iframe-host-page
2keydowniframe that contains the mozbrowser-iframe-embedded-page in mozbrowser-iframe-host-page
3keydownoriginal one in mozbrowser-iframe-embedded-page
4mozbrowserafterkeydownwindow in mozbrowser-iframe-host-page
- -

- -

The keyboard events mozbrowserbeforekeydown, keydown, and mozbrowserafterkeydown can be extended to nested mozbrowser iframes, like the iframe structure in Firefox OS described earlier. In this case, the mozbrowserbeforekeydown and mozbrowserafterkeydown events will be dispatched to the innermost mozbrowser-iframe-host-page as well as the outer one. Thus, in Firefox OS, mozbrowserkeydown and mozbrowserafterkeydown will be dispatched to the window of system/index.html and the window of shell.html. the above diagram illustrates the whole dispatch sequence of related events when a keydown event is dispatched to a web app. The sequence of events is as follows:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
順序イベントターゲット
1mozbrowserbeforekeydownwindow in shell.html
2mozbrowserbeforekeydownwindow in system/index.html
3keydowniframe that contains the web app in system/index.html
4keydownoriginal one in web app
5mozbrowserafterkeydownwindow in system/index.html
6mozbrowserafterkeydownwindow in shell.html
- -

Although the keyup event must be fired after keydown, the keydown event and the keyup event are independent of each other. Moreover, the path mozbrowserbeforekeyup, keyup, mozbrowserafterkeyup is independent of the path mozbrowserbeforekeydown, keydown, mozbrowserafterkeydown. Therefore, it’s possible for these two paths to cross each other. The mozbrowserbeforekeyup event may arrive before the keydown event.

- -

In Firefox OS, most apps run out-of-process. This means that the app runs on its own process, not on the main process. After dispatching a given key* event to the system app, it takes time to send the original key* event to the process where the mozbrowser-iframe-embedded-page is located. In a similar manner, after a given key* event is dispatched to the mozbrowser-iframe-embedded-page’s process, time is required to send the mozbrowserafterkey* event back to the process where the mozbrowser-iframe-host-page is located.

- -

Consequently, the mozbrowserbeforekeyup event may arrive in the main Firefox OS process (where the system app lives), before the keydown event is dispatched to the app’s own process. Common results of the order of the key* events are demonstrated in the diagram below. The yellow series represents the keydown path, and the blue series show the keyup path. And yes, these two paths may cross each other.

- -

- -

キーボードイベント向けの詳細実装

- -

In this section we’ll take a closer look at each of the four scenarios, complete with example code for each event-handling scenario.

- -

SYSTEM-ONLY

- -

If a keyboard event is categorized as SYSTEM-ONLY, then the desired response is defined in mozbrowserbeforekey*’s event handler. Once this key is pressed, the system receives the mozbrowserbeforekey* event before the key* event is dispatched to an app. In addition, the key* events dispatch is cancelled once the system event handler is called. Now, we need to figure out a way to stop the event dispatch. Above we saw that the keyboard events are dispatched to the system process, then also to the app process. To stop dispatching events to the the embedded page, event.preventDefault() is a straightforward solution. The defined default action of the mozbrowserbeforekey* event is to dispatch the key* event. For this reason, by calling event.preventDefault() in mozbrowserbeforekey*’s event handler, key* events won’t be dispatched. The final result as follows:

- -

- -

SYSTEM-FIRST

- -

This is very similar to the implementation of SYSTEM-ONLY. The only difference is that it’s not necessary to call event.preventDefault() in mozbrowserbeforekey*’s event handler. Apps are able to handle the key* event after the system finishes processing it.

- -

- -

APP-CANCELLED

- -

If specific keyboard events are designated for use by apps only, such as those assigned to the four colored keys on smart TV remotes, then event.preventDefault() will be called in the app’s key* event handler.

- -

- -

The event.preventDefault() call cannot prevent the mozbrowserafterkey* event from being dispatched to the system, but the property embeddedCancelled of mozbrowserafterkey* will be set to true once the embedded app calls event.preventDefault(). The value of embeddedCancelled tells the system whether or not this event has been handled already. If the value is true, the system does nothing.

- -

- -

APP-FIRST

- -

The difference between APP-FIRST and APP-CANCELLED is that with APP-FIRST event.preventDefault() will not be called in the app’s event handler. Therefore, the value of embeddedCancelled is false and the system can take over the keyboard event.

- -

- -

サンプルコード

- -

Here's some sample code to illustrate how developers can handle such events in their own apps.

- -

イベントハンドラ

- -
function handleEvent(event) {
-  dump("Receive event '" + event.type + "'.");
-  // Handle event here.....
-};
-
-function handleEventAndPreventDefault(event) {
-  dump("Receive event '" + event.type + "'.");
-  // Handle event here.....
-
-  // Call preventDefault() to stop the default action.
-  // It means that the event is already handled.
-  event.preventDefault();
-};
-
-function checkAttrAndHandleEvent(event) {
-  dump("Receive event '" + event.type +
-       "' with embeddedCancelled equals to '" +
-       event.embeddedCancelled + "'.");
-  if (!event.embeddedCancelled) {
-    // Do something if the event wasn't being handled before!
-    // The following code should be executed in APP-FIRST scenario only!
-  }
-};
- -

SYSTEM-ONLY

- -

mozbrowser iframe host page:

- -
window.addEventListener('mozbrowserbeforekeydown', handleEventAndPreventDefault);
-window.addEventListener('mozbrowserbeforekeyup', handleEventAndPreventDefault);
-window.addEventListener('mozbrowserafterkeydown', function() { }); // no use
-window.addEventListener('mozbrowserafterkeyup', function() { }); // no use
- -

The embedded page:

- -
// This function will never be triggered because the preventDefault() is called in mozbrowserbeforekeyXXX's handler.
-window.addEventListener('keydown', handleEvent);
-window.addEventListener('keyup', handleEvent);
- -

Results of keydown-related events:

- - - - - - - - - - - - - - - - - - - - - - - -
OrderThe embedded pagemozbrowser iframe host pageOutput
1mozbrowserbeforekeydown Receive event mozbrowserbeforekeydown.
2mozbrowserafterkeydown 
- -

Results of keyup-related events:

- - - - - - - - - - - - - - - - - - - - - - - -
OrderThe embedded pageThe host pageOutput
1mozbrowserbeforekeyup Receive event mozbrowserbeforekeyup.
2mozbrowserafterkeyup 
- -

SYSTEM-FIRST

- -

mozbrowser iframe host page:

- -
window.addEventListener('mozbrowserbeforekeydown', handleEvent);
-window.addEventListener('mozbrowserbeforekeyup', handleEvent);
-window.addEventListener('mozbrowserafterkeydown', function() { }); // no use
-window.addEventListener('mozbrowserafterkeyup', function() { }); // no use
- -

The embedded page:

- -
window.addEventListener('keydown', handleEvent);
-window.addEventListener('keyup', handleEvent);
- -

Received results of keydown-related events:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Ordermozbrowser-embedded pagemozbrowser iframe host pageOutput
1mozbrowserbeforekeydown Receive event mozbrowserbeforekeydown.
2 keydownReceive event keydown.
3mozbrowserafterkeydown 
- -

Received results of keyup-related events:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
OrderThe embedded pagemozbrowser iframe host pageOutput
1mozbrowserbeforekeyup Receive event mozbrowserbeforekeyup.
2 keyupReceive event keyup.
3mozbrowserafterkeyup Receive event mozbrowserafterkeyup with embeddedCancelled set to true.
- -

APP-CANCELLED

- -

mozbrowser iframe host page:

- -
window.addEventListener('mozbrowserbeforekeydown', function() { }); // no use
-window.addEventListener('mozbrowserbeforekeyup', function() { }); // no use
-window.addEventListener('mozbrowserafterkeydown', checkAttrAndHandleEvent);
-window.addEventListener('mozbrowserafterkeyup', checkAttrAndHandleEvent);
- -

mozbrowser iframe embedded page:

- -
window.addEventListener('keydown', handleEventAndPreventDefault);
-window.addEventListener('keyup', handleEventAndPreventDefault);
- -

Received results of keydown-related events:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
OrderThe embedded pagemozbrowser iframe host pageOutput
1mozbrowserbeforekeydown  
2 keydownReceive event keydown.
3mozbrowserafterkeydown Receive event mozbrowserafterkeydown with embeddedCancelled set to true.
- -

Received results of keyup-related events:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Ordermozbrowser-embedded pagemozbrowser iframe host pageOutput
1mozbrowserbeforekeyup  
2 keyupReceive event keyup.
3mozbrowserafterkeyup Receive event mozbrowserafterkeyup with embeddedCancelled equals to true.
- -

APP-FIRST

- -

mozbrowser iframe host page:

- -
window.addEventListener('mozbrowserbeforekeydown', function() { }); // no use
-window.addEventListener('mozbrowserbeforekeyup', function() { }); // no use
-// This will be trigger after keydown event is
-// dispatched to mozbrowser iframe embedded page
-window.addEventListener('mozbrowserafterkeydown', checkAttrAndHandleEvent);
-window.addEventListener('mozbrowserafterkeyup', checkAttrAndHandleEvent);
- -

mozbrowser iframe embedded page:

- -
window.addEventListener('keydown', handleEvent);
-window.addEventListener('keyup', handleEvent);
- -

Received results of keydown-related events:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Ordermozbrowser-embedded pagemozbrowser-iframe host pageOutput
1mozbrowserbeforekeydown  
2 keydownReceive event keydown.
3mozbrowserafterkeydown Receive event mozbrowserafterkeydown with embeddedCancelled set to false.
- -

Received results of keyup-related events:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Ordermozbrowser-embedded pagemozbrowser iframe host pageOutput
1mozbrowserbeforekeyup  
2 keyupReceive event keyup.
3mozbrowserafterkeyup Receive event mozbrowserafterkeyup with embeddedCancelled set to false.
diff --git a/files/ja/archive/firefox_os/platform/out_of_memory_management_on_firefox_os/index.html b/files/ja/archive/firefox_os/platform/out_of_memory_management_on_firefox_os/index.html deleted file mode 100644 index 83ba2f718d..0000000000 --- a/files/ja/archive/firefox_os/platform/out_of_memory_management_on_firefox_os/index.html +++ /dev/null @@ -1,138 +0,0 @@ ---- -title: Firefox OSの低メモリ管理 -slug: Archive/Firefox_OS/Platform/Out_of_memory_management_on_Firefox_OS -tags: - - Firefox OS - - Gaia - - LMK - - OOM - - Out of memory - - low memory killer - - low memory notifications - - oom_adj -translation_of: Archive/B2G_OS/Platform/Out_of_memory_management_on_Firefox_OS ---- -

-

-

-
-

Firefox OSはメモリが制約された端末で実行され、そうしたシステムにおいて、使用可能なメモリをアプリが使い果たすのは簡単です。システムで使用可能なメモリが使い果たされた時、カーネルはメモリを解放するために、その他のプロセスを停止しなければなりません。この記事では低メモリキラーと低メモリ通知 ( この2つの端末上システムはシステムが低メモリになった時に、メインシステムを続けるためにどのプロセスを停止するかを管理する ) が動作する方法を説明します。

-
- -

Firefox OS の操作はマルチプロセス ( 1つ動作している基本システムサービス「メインプロセス」と、潜在的なたくさんの「子プロセス」) を含んでいます。一般的に、各アプリはその子プロセスとして実行されます。Firefox OS 環境上でアプリケーションはユーザーによって滅多に終了される事が無いので、新しいアプリがメモリを必要としたときや起動しているアプリが更なるメモリを必要としたときにメモリ空間を作る事が出来るようにシステムは自動でアプリのライフサイクルを管理しています。

- -

2つのサブシステム (低メモリキラー (LMK) 低メモリ通知) はこの管理に利用されています。

- -

低メモリキラー(LMK)

- -

LMK は メモリの要求があったときにメモリ空間を確保するためにプロセスを終了させる Android カーネル のサブシステムです。メモリを確保するために最初に終了させるプロセスを選択するために、/proc/<pid>/oom_adj か /proc/<pid>/oom_score_adj ファイルによって各プロセスは優先度を決められています。プロセスの優先度は adjustment スコアまたは、oom_adj として知られています。oom_adj の値は小さいほど優先度の高いプロセスです。

- -

一般的に、大きい adjustment スコアはプロセスが終了されやすくなります。 LKM は一定のメモリ空き容量と、最小の adjustment スコアに応じて、複数のレベルを提供しています。システムの空き容量がある一定のレベルよりも低くなったときはいつも、望ましいレベルで定義された最小の adjustment スコアよりも高い adjustment スコアのプロセスは終了します。LKM は最初に大きいプロセスを終了させます。そして、閾値以上にメモリが確保されるまでくりかえします。

- -
-

: バックグラウンドのアプリがLMKに停止された時、タスクマネージャで端をスワイプすると"ゾンビアプリ"になっています: 次にそのアプリをブラウズした時、復活するでしょう。この状態で維持できるアプリの最大数は現在10個です。

-
- -
-

: 端末がメモリ不足になった時に停止されたプロセスは、必ずしもOOM(メモリ不足)の "原因" とは限りません。

-
- -

プロセスの優先順位

- -

Firefox OS では、アプリは以下の優先順ポリシーに従って終了されます。このポリシーは各アプリケーションに優先度を与え、このレベル(現在は prefs のセット値として設定されている)に OOM adjustment スコアを関連づける事によって実現しています。

- -
    -
  1. 最初に終了されるアプリは、最初に利用して起動しているバックグラウンドアプリです。
  2. -
  3. ユーザーによって認識されているバックグラウンドアプリは次に終了されます。(例えば、音楽プレイヤーがバックグラウンドで音楽を再生していたり、アプリが高い優先度を持っていたり、CPU  wakelock やシステムメッセージのハンドラーを登録していたりするバックグラウンドアプリの事)
  4. -
  5. もしキーボードアプリが起動していたら、次に終了されます。
  6. -
  7. フォアグランドアプリケーションは次に終了されます。
  8. -
  9. 最後に、 high-priority(高い優先度) や CPU wakelocks を要求しているフォアグランドアプリケーションが最後に終了されます。
  10. -
- -
-

: たいていの子プロセスは、フォアグランド動作時は oom_adj 2 で動作します。バックグラウンドの子プロセスは、oom_adj 3 から 6 (を含む)の間で実行されます。ある子プロセスがバックグラウンド時にどの oom_adj を持っているかは、正確にファクタ数(音を鳴らしているのか、キーボードアプリなのか、など)で決まります。

-
- -

このルールには2つの例外があります。

- - - -

低メモリ通知

- -

次のメモリが少なくなったときに利用するメカニズムは低メモリ通知です。 LMK は動作しているメモリが少なくなった事を通知する事が出来る特別な閾値を提供しています。システムアプリケーションと一般的なユーザーアプリケーションは監視サービスから通知される memory-pressure イベントに反応するために条件がくるのを待ち続けています。このイベントは C++ と chrome JS のコードだけに利用でき、直接アプリケーションが利用する事は出来ません。Gecko のコードベースを通じて、我々は利用可能なメモリを空けるためにイベントを利用します。(通常、内部キャッシュ(画像、DNS、sqlite等) を破棄し、再生可能なアセット(WebGL context等) を破棄したり、ガベッジコレクターやサイクルコレクターを実行させたりします)
-
- メモリが少ない状況に直面したら、最初の memory-pressure イベントが low-memory ペイロード付きで送信されるでしょう。定義した時間 (5秒) を経過してもメモリが少ない状況が続いていた場合、他の memory-pressure イベントが、low-memory-ongoing ペイロード付きで発火されます。このペイロードはメモリ不足の状態が継続しているときに利用され、私たちはキャッシュをフラッシュしたり、他のメモリを最少化するための安い方法を望みます。しかし、GC のような処理の重たいアプローチは成功しにくいでしょう。

- -

LMKと低メモリ通知が協働する方法

- -

現在、低メモリーの閾値は バックグラウンドアプリケーションの LMK レベル以上に設定されていますが、ホームスクリーンより低く設定されています。そのため、LMK と低メモリー通知の両方のアクションは、out of memory が端末で発生したときに以下のようにしないといけません。

- -

現在、2つの低メモリ閾値が使われています(ソフトハード閾値)。ソフトレベルはバックグラウンドアプリケーションのLMKレベルより大きく設定されていて、低メモリエラーが始まっているがアプリケーションが停止される前に、メモリ使用を最小化するのに使われます。いっぽうハードレベルは、LMKによってすべてのバックグラウンドアプリケーションが停止された後に、フォアグラウンドアプリケーションを生かし続けるために使われます。ただ1つのカーネルトリガーだけが利用できるため、この2つのレベルは、Geckoが動的にトリガーを調整できることにより、実装されています。端末が低メモリとなった時に、LMKと低メモリ通知の集約されたアクションは次の通り:

- -
    -
  1. すべてのアプリに memory-pressure イベントを通知する
  2. -
  3. メモリがまだ不足している場合は、最近使用されていない順でバックグラウンドアプリを停止する
  4. -
  5. メモリがまだ不足している場合は、すべての残っているアプリに memory-pressure イベントを通知する
  6. -
  7. メモリ不足が継続している場合、5秒間隔で memory-pressure イベントを送信する。しかしGC/CC が反応しないように、実行中にマークする
  8. -
  9. 認知していたり、高い優先度のバックグラウンドアプリを終了する
  10. -
  11. もし動作していたらキーボードアプリを終了する
  12. -
  13. フォアグランドアプリケーションを終了する
  14. -
  15. フォアグランドアプリケーションの高い優先度のものを終了する
  16. -
  17. preallocated process を終了する
  18. -
-- cgit v1.2.3-54-g00ecf