日本語には漢字の発音を示す「よみがな」があり、とても重要な役割を果たしています。特に人名は、漢字だけでは適切な読み方を推測することが難しく、フォームの入力や自己紹介の際には、漢字とよみがなの両方を伝えることが当たり前となっています。そのため、日本語で名前を登録するウェブサイトやアプリでは、漢字とよみがなを両方入力してもらう場合が多くあります。 画面が小さいスマートフォンの文字入力には、ひらがなかアルファベットが利用されます。その後、該当する漢字の選択肢が表示されるので、ユーザーはその中から適切な漢字を選びます。
日本語には漢字の発音を示す「よみがな」があり、とても重要な役割を果たしています。特に人名は、漢字だけでは適切な読み方を推測することが難しく、フォームの入力や自己紹介の際には、漢字とよみがなの両方を伝えることが当たり前となっています。そのため、日本語で名前を登録するウェブサイトやアプリでは、漢字とよみがなを両方入力してもらう場合が多くあります。

画面が小さいスマートフォンの文字入力には、ひらがなかアルファベットが利用されます。その後、該当する漢字の選択肢が表示されるので、ユーザーはその中から適切な漢字を選びます。

Figure 1: IME(例、Gboard)は 漢字の選択肢を表示
Figure 1: IME(例、Gboard)は 漢字の選択肢を表示



入力処理を行う IME アプリには、下記のような情報が保存されています。
  1. IME内のメニュを表示するための一般的な「漢字↔よみがな」の対応情報
  2. ユーザーが選択した変換の履歴に基づいた「漢字↔よみがな」の対応情報
上記の 1 と 2 の情報は、IME のデータベースで管理されます。このデータベースは、ユーザーの入力や IME の人工知能によって、改善されてゆきます。

つまり IME は「推測しにくい」よみがなを、ユーザーの文字入力によって、簡単に取得することができるように作られているのです。また、そのよみがなは、漢字の情報とともにデバイス上でデータベース化されます。

Q:その貴重なデータをアプリケーションと提供する方法はないのでしょうか?
A:はい!この記事を書いているのは日本語を利用する Android アプリ開発者の皆様にそれをご紹介するためです。Gboard で漢字の変換データをアプリと共有する API が利用可能になりました。

Figure 2: 漢字入力とともに、よみがな情報を提供するIME



この Gboard(v10.1 以降)に追加された API は、IME のテキスト出力に、よみがなを span として追加します。この API を利用するアプリケーションは、その出力を拾うことで、高い精度でユーザーの入力した文章に該当するよみがなを推測できるようになります。

よみがな情報を取得するためには、漢字入力の対象となる TextEdit が下記の条件を満たす必要があります:

  • ア)inputType プロパティの値を textPersonName にする。
  • イ)privateImeOptions プロパティの値を com.google.android.inputmethod.latin.requestPhoneticOutput にする。
Android Studio の Layout エディターで見た場合、設定は下記のようになります。

Figure 3: Android Studioのプロパティ設定

次に、TextWatcher を宣言し、入力通知の際、CharSequence から、getSpans() によって該当する TtsSpan を取得します。
public class MainActivity extends AppCompatActivity {

    private class PhoneticRetriever implements TextWatcher {
        // Extracts phonetic metadata from an incoming text blob
        private String getPhoneticMetadata(CharSequence s) {
            String phonetic = null;
            if (s instanceof SpannableStringBuilder) {
                SpannableStringBuilder textAsSpan = (SpannableStringBuilder) s;
                TtsSpan[] allSpans = textAsSpan.getSpans(0, s.length(), TtsSpan.class);
                if (allSpans.length == 1 && allSpans[0].getType().equals(TtsSpan.TYPE_TEXT)) {
                    // log shows where the span is in the text
                    Log.v("PHON",
                            s.toString() + " [" + textAsSpan.length() + "] start:" +
                            textAsSpan.getSpanStart(allSpans[0]) + " end:" +
                            textAsSpan.getSpanEnd(allSpans[0]));
                    phonetic =  allSpans[0].getArgs().getString(TtsSpan.ARG_TEXT);
                    textAsSpan.removeSpan(allSpans[0]); // avoid consuming again
                }
            }
            return phonetic;
        }
        @Override
        public void afterTextChanged(Editable s) {
            String sphonetic = getPhoneticMetadata(s);
            if (sphonetic == null) {
          // no phonetic data
            } else {
                // phonetic data is in sphonetic - use it as you like
            }
        }

        @Override
        public void beforeTextChanged(CharSequence s, int start, int count, int after) {}

        @Override
        public void onTextChanged(CharSequence s, int start, int before, int count) {}
    }
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        EditText etUserInput = (EditText)findViewById(R.id.editTextPhoneticWithOptions );
        etUserInput.addTextChangedListener(new PhoneticRetriever());
    }
}

このサンプルコードでは、afterTextChanged() のコールバックで TtsSpan を取得しています。TtsSpan.ARG_TEXT がよみがなで、getSpanStart()getSpanEnd() を利用すれば、入力された CharSequence の中で取得したよみがなの位置を取得することができます。

実行可能なコードはこちらのレポジトリをご参照ください。
 → https://github.com/googlesamples/gboard-dev-samples/tree/main/GetIMEPhoneticName

同じコードを使ったサンプルアプリケーションを Play Store からインストールすることも可能です。
 → https://play.google.com/store/apps/details?id=com.ragingsamples.getimephoneticname

Google コンタクト アプリ(v3.37 以降)では、連絡先を編集する際、この API を使って漢字名に該当するよみがなが自動入力されます。自動入力の結果が誤っている場合でも、ユーザーは手動でよみがなを直すことができます。

Figure 4: Google コンタクト アプリのよみがな推測

この API を利用して取得したよみがなの使い道はみなさんの作るアプリ次第ですが、いくつか参考になるユースケースをご紹介します:
  • ユーザーの入力した名前から自動的によみがなを推測する。2021 年 5 月現在、この API は 名前にのみ対応しているため、ショッピング アプリや銀行アプリ、カスタム CRM アプリ、 SNS アプリなどで利用することができます。
  • 他の IME が Gboard と同じ API を提供することで、より多くのユーザーによみがなのサポートを提供する。

ほかのユースケースのご提案、名前以外に将来的にサポートして欲しい入力タイプ、改善点などありましたら、ぜひフィードバックをお願いします。


Posted by Alex Gimenez - Technical Solutions Consultant




5 月 18 日から 20 日(日本時間 5 月 19 日から 21 日)に Google I/O 2021 がオンラインで開催されます。

これにあわせて、Google I/O 2021 で発表される内容から、特に日本のデベロッパーの皆さまにお届けしたい話題をご紹介する「I/O Extended for Web developers 2021」を 6 月 8 日に開催します。

当日は、日本の Google 関係者がモデレーターとして、動画の解説、リアルタイムでお寄せいただく質問に回答する場も設けています。

無料のオープンウェビナーとなっておりますので、皆さまお誘い合わせの上、ぜひご参加ください。(事前登録必須です)

開催概要

  • 日時 : 2021 年 6 月 8 日 15:00 〜 17:00
  • 形式 : ウェビナー

タイムテーブル:

  • 15:00 〜 15:05 オープニングのご挨拶

  • 15:00 〜 15:35 Web Vitals の最新情報:(Annie Sullivan & Elizabeth Sweeny)
    • このセッションでは、ツールを活用し、Web Vitals を測定および最適化する方法に関する最新のリサーチ結果を共有致します。
      [ナビゲーター] えーじ & 宍戸俊哉

  • 15:35 〜 16:05 Web のプライバシー強化に向けた準備:(Maud Nalpas)
    • ユーザーはさらなるプライバシーの強化を求めており、Web エコシステムはこの要望に応えるよう進化し、プライバシーはデフォルトになりつつあります。 Web のプライバシー強化に対応するうえで、Web サイトにどのような準備が必要でしょうか。ここでは、何がどのような理由で変わりつつあるか、サードパーティ Cookie の段階的廃止に備える方法、役立つツール、試してみるべき新しい API、ユーザーが使用できる Chrome のコントロールなど、デベロッパーに必要な情報を順番に説明します。
      [ナビゲーター] えーじ & 宍戸俊哉

  • 16:05 〜 16:35 オプトインとしてのセキュリティからデフォルトのセキュリティへ: (えーじ & Camille Lamy)
    • Spectre は、Web のセキュリティ環境に大きな影響を与えました。このセッションでは、Web サイトの安全性と機能性を維持するためのセキュリティ ヘッダーに関するベスト プラクティスについて、お話をさせて頂きます。また、今後予定されている重要な変更や新しいデフォルトについても紹介します。
      [ナビゲーター] えーじ & 宍戸俊哉

  • 16:35 〜 16:55 Q & A
    • イベント配信画面右側に表示されている「質問入力ツールの Slido」を通して随時送っていただいた質問から、「いいね」が多いものを優先して回答させていただきます。
      ※自然検索に関する質問は取り上げない可能性があります。具体的な質問がある場合は #Google検索オフィスアワーやヘルプ コミュニティをご活用ください。

  • 16:55 〜 17:00 クロージングのご挨拶

※登壇者、内容は変更される場合がありますので、最新情報は Web サイトでご確認ください

参加申し込み


こちらの Web サイトからお申し込みください。ライブ配信やアーカイブの再生・閲覧、当日のQ&A で取り上げるご質問は Web サイトからのみ可能です。当日でも参加登録は可能ですが、事前に登録を完了いただくと、スムーズです。なるべく登録をお済ませの上お待ち下さい。

*参加登録は、参加者(視聴者)お一人ごとにお願いいたします
*参加者人数には制限を設けておりません。
*プログラムの内容は予告なく変更になることがございます


皆さまのご参加をお待ちしております。


Posted by Tamao Imura - Developer Marketing Manager, Platforms and Ecosystems

...
この記事は Chrome ソフトウェア エンジニア、Benoît Lizé、Bartek Nowierski による Chromium Blog の記事 "Efficient And Safe Allocations Everywhere!" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google は、パフォーマンス改善の作業を恒常的に続けています。その中で、ほとんどのソフトウェア デベロッパーが立ち入らない領域にまで踏み込んで最適化を行わなければならないエンジニアもいます。シリーズ速さと好奇心の今回の投稿では、シニア エンジニアのチームが、システムレベルのメモリ アロケータを最適化されたバージョンに置き換えるという作業に、どのようにアプローチしたかについて紹介します。これにより、Windows で最大 22% という大幅なメモリの節約が実現されています。


PartitionAlloc は Chromium のメモリ アロケータで、断片化が起こりにくく、高速で強固なセキュリティを持つように設計されています。この機能は、Blink(Chromium のレンダリング エンジン)で広く活用されています。Windows 64 ビット版と Android 版の Chrome 89 では、Chromium 全体のコードベースがあらゆる場所で PartitionAlloc を使うように移行されました(malloc() と new をインターセプトして置換しました)。実地でのデータによると、最大 22% の Chrome のメモリが節約され、応答速度とスクロールのレイテンシが最大 9% 改善されています。





3 月上旬に M89 リリースのロールアウトが開始された時点で、Windows のブラウザ プロセスのメモリ使用量を詳しく調査したものを示します。







背景

Chrome は、マルチプラットフォーム、マルチプロセス、マルチスレッドのアプリケーションで、Android の小さな埋め込み WebView から宇宙船まで、実に幅広いニーズに対応しています。パフォーマンスとメモリのフットプリントは特に重要で、Chrome とメモリ アロケータには密接な統合が求められます。しかし、それぞれのプラットフォームには Linux と Chrome OS の tcmalloc、Android の jemallocscudo、Windows の LFH などの異なる実装があり、プラットフォームの違いを超えるのは難しい可能性もあります。

このプロジェクトに着手したときの目標は、1)プラットフォーム間でメモリ割り当てを統一すること、2)セキュリティやパフォーマンスを損なうことなく最小メモリ フットプリントを実現すること、3)Chrome のパフォーマンスの最適化にふさわしいアロケータを実現することでした。そこで、Chromium のクロスプラットフォームなアロケータを使う決定をしました。これは、サーバーのワークロードではなくクライアントのメモリ使用量を最適化するため、そして実際の使用例を意識しないマイクロベンチマークではなく有意義なエンドユーザーの活動に注目するためです。



アロケータのセキュリティ


PartitionAlloc は、独立した複数のパーティション(重複しないメモリ領域)をサポートするように設計されました。Blink では、文字列とレイアウト オブジェクトを確実に分離するなど、一部の形態の型混同攻撃を阻むために、全体にわたってこのパーティションを活用しています。しかし、このアプローチでは、別のパーティションで割り当てられた型同士の衝突しか避けることはできません。さらに、衝突する可能性があるオブジェクトのサイズが異なる場合、型の混同を避けるため、PartitionAlloc バケットはサイズを使って割り当てをします。この手法が動作するのは、PartitionAlloc がアドレス空間を再利用しないからです。PartitionAlloc がアドレス空間のある領域を特定のパーティションとサイズのバケットに割り当てる場合、その領域は常にそのパーティションとサイズのバケットに所属することになります。


さらに、PartitionAlloc は、メモリ領域周辺のガードページ(アクセスできない範囲)によって一部のメタデータを保護します。しかし、すべてのメタデータが同じとは限りません。以前に割り当てられた領域内には、フリーリストのエントリが格納されるので、他の割り当てに囲まれることになります。破損したフリーリストのエントリと off-by-one オーバーフローをクライアントのコードから検知するため、これをコード化して隠蔽します。
さらに、独自のアロケータが MiraclePtr*Scan などの高度なセキュリティ機能を実現します。




アーキテクチャの詳細

PartitionAlloc の各パーティションは、メモリを節約するため、1 つの集中管理型のスラブベース アロケータを使用します。また、フロントでのスレッド単位のキャッシュは最低限にとどめ、マルチスレッドなワークロードにスケーリングできるようにしています。このシンプルな処理には、パフォーマンス面でのメリットもあります。Google は幅広いプロファイリングをし、アロケータの高速パスを徹底的に切り詰めました。これにより、スレッドローカルなストレージへのアクセスやロックが改善し、キャッシュ ラインの取得数は減少し、ブランチも削除できるようになっています。

PartitionAlloc は、仮想アドレス空間であらかじめスラブを予約します。割り当てリクエストが到着するにつれて、そこに物理メモリが徐々に割り当てられていきます。少量または中程度の割り当ては、[241; 256]、[257; 288] など、幾何学的に間隔を空けたサイズごとのバケットにグループ化されます。各スラブは、1 つの特定のバケットからのみ配分され、割り当て(「スロット」と呼ばれます)を満たす複数の領域(「スロットスパン」)に分割されます。そのため、キャッシュのローカル性は向上し、断片化は起こりにくくなります。逆に、大量の割り当てはバケットのロジックを通さず、直接オペレーティング システムのプリミティブ(POSIX システムでは mmap()、Windows では VirtualAlloc())を利用して実現します。


この集中管理型アロケータは、パーティション単位の 1 つのロックによって保護されます。競合によるスケーラビリティの問題を緩和するため、スレッド単位の小さなスロットのキャッシュをフロントに追加し、3 層型アーキテクチャを実現しています。





最初のレイヤー(スレッド単位のキャッシュ)は、頻繁に利用される小さなバケットに属する少量のスロットを保持します。これらのスロットはスレッドごとに保存されるため、ロックなしに割り当てることができ、必要になるのは高速なスレッドローカル ストレージの検索のみです。そのため、プロセスでのキャッシュのローカル性が向上します。このスレッドごとのキャッシュは、2 つ目のレイヤーのメモリをまとめて割り当てと解放をすることで、大半のリクエストを満たせるように最適化されています。そのため、過度なメモリを確保することなく、ロックの取得頻度を下げ、ローカル性をさらに向上することができます。

この 2 つ目のレイヤー(スロットスパンのフリーリスト)は、スレッドごとのキャッシュでキャッシュミスが発生した場合に呼び出されます。PartitionAlloc は、それぞれのバケットのサイズについて、そのサイズに関連付けられた空きスロットがあるスロットスパンを把握しています。そのため、そのスパンのフリーリストからスロットを取得します。この処理もまだ高速パス上にありますが、ロックの取得が必要なので、スレッドごとのキャッシュよりは遅くなります。しかし、このセクションにアクセスされるのは、スレッドごとのキャッシュでは対応できない大きな割り当てがされる場合や、スレッドごとのキャッシュを埋めるバッチとして実行される場合のみです。

最後に、バケットに空きスロットがない場合は、3 つ目のレイヤー(スロットスパン管理)が新しいスロットスパン用にスラブから領域を切り出すか、オペレーティング システムからまったく新しいスラブを割り当てます。これは遅い処理ですが、まれにしか起こらないオペレーションです。

このアロケータの全体的なパフォーマンスと領域の効率性は、キャッシュの量、バケットの数、メモリ再利用ポリシーなど、レイヤー間のさまざまなトレードオフ次第です。設計の詳細については、PartitionAlloc をご覧ください。

全体として、PartitionAlloc が実現するさらなるメモリ節約とパフォーマンスの向上によって、安全、軽量、高速な Chrome が実現し、それを地球上や宇宙空間のユーザーに利用していただけることを期待しています。今後の改善や、近いうちにされるその他のプラットフォームのサポートにもご期待ください。


すべての統計情報の出典 : Chrome クライアントから匿名で集計した実データ
* 中心となる指標として、30 秒ごとにジャンク(ユーザーの入力を処理する際の遅延)を測定。

Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Chrome デベロッパーおよびブロガー Bruce Dawson による Chromium Blog の記事 "Don't Copy That Surface" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

この投稿は新シリーズ速さと好奇心の一部です。このシリーズでは、Chrome の速度と信頼性を向上するという慎重なトレードオフと複雑なエンジニアリングについて詳しく解説します。Chrome デベロッパーおよびブロガーである Bruce Dawson は、ここで紹介するデバッグ作業を通じて、ウェブカメラを使う際の CPU 使用率を約 3% 削減しました。ビデオ通話を多用する私たちにとって、役立つ改善です。

2020 年、ビデオ会議の重要性は飛躍的に上昇しました。私は Google Meet チームの一員ではありませんが、Chrome に携わっているので、何か役立つ情報を見つけようと、日々会議に参加する中でお気に入りのプロファイラを実行してみました。

ビデオ会議では、複数のプロセスにまたがるさまざまな処理が動いています。私はいつも数十個のタブを開いています。Chrome のプロセスは 37 個あり、そのうち 6 つがビデオ会議に密接に関連するものでした。さらに、200 個以上の他のプロセスが動作しており(たとえば、svchost.exe は 87 個ありました)、そのうち 4 つがビデオ会議に関連するものでした。2 人の人をつなぐためになぜプロセスが 10 個も必要になるのか、不思議に思う方もいるかもしれません。そこで、使われるプロセスと役割についてまとめてみます。

  • audiodg.exe - Windows Audio Device Graph Isolation、オーディオ出力
  • dwm.exe - Windows Desktop Window Manager、動画の表示
  • svchost.exe - Windows Camera Frame Server(ウェブカメラのキャプチャ)
  • System - Windows システム プロセス、各プロセスのためにさまざまなタスクを実行
  • chrome.exe - ブラウザのプロセス、マスター コントロール プログラム
  • chrome.exe - レンダラ プロセス、Meet タブ
  • chrome.exe - GPU プロセス、ページのレンダリングを実行
  • chrome.exe - NetworkService ユーティリティ プロセス、ネットワークとの通信
  • chrome.exe - VideoCaptureService、Windows Camera Frame Server との通信
  • chrome.exe - AudioService、オーディオ入出力のコントロール

セキュリティと安定性を確保するため、これらのタスクは複数のプロセスに分散しています。そのため、いずれかがクラッシュしても、すべてをダウンさせずに再起動できます。また、セキュリティ バグのためにいずれかが侵害されても、システムの他の部分から切り離すことで、被害を抑えることができるかもしれません。

これは妥当なことですが、このように多くのプロセスを扱う場合、パフォーマンスのプロファイリングが難しくなることもあります。すべてのプロセスを確認し、改善の余地がある部分を突き止めるのは困難です。さらに難しいことに、私は Meet のアーキテクチャについてほとんど何も知りません。


プロファイルの分析

ビデオ会議は CPU を多用します。記録、圧縮、転送、受信、解凍をし、オーディオと動画の両方を出力しなければなりません。下に示すのは、Microsoft の Event Tracing for Windows(ETW)で記録した CPU のサンプルデータです。このサンプリング プロファイラは、すべての実行中のスレッドを 1 秒に約 1,000 回中断させ、コールスタックを記録します。結果の表示には、Windows Performance Analyzer(WPA)を使いました。下のスクリーンショットでは、ビデオ会議に関係する 10 個のプロセスについて、10 秒間にわたって 16,000 以上のサンプル(CPU 時間で約 16 秒)を記録したものを分析しています。



眺めるには数が多すぎるサンプルですが、コールスタックごとにまとまっているので、最も負荷の高いスタックにドリルダウンできます。最初の Chrome プロセスには気になるものはありませんでしたが、2 つ目のプロセスにはありました。


数は多くはありませんが、124 サンプルの KiPageFault は調査する価値があるとすぐにわかりました。このトレースでは、CPU を多用する作業のほとんどが重要で、省くことはできません。しかし、このサンプルは省くことができる作業、すなわち修正できる部分だと直感しました。また、これはサンプル全体のわずか 0.75% にすぎませんが、それよりも大きなコストがかかっている可能性があるとも考えました。

この重要性にすぐに気づくことができたのは、以前に同じような現象を経験していたからです。KiPageFault は、以前にプロセスに割り当てられていたものの、現在は割り当てられていないメモリにプロセッサがアクセスしたことを示します。これは、メモリを節約するためにページがプロセスから削除されているにもかかわらず、マシンのアクティブなプロセスにはたくさんのメモリがあるということなので、おかしな話です。可能性が高いと思われたのは、最近割り当てられたメモリです。

プログラムが少量のメモリを割り当てる場合、通常はローカルメモリ マネージャー(「ヒープ」と呼ばれることもあります)が保有するメモリがプログラムに渡されます。しかし、適切なメモリブロックがない場合は、オペレーティング システム(OS)にメモリを要求します。プログラムが大量のメモリを割り当てる場合(約 1 MB 以上)、ヒープは確実にメモリを要求します。これ自体は、コストの低いオペレーションです。ヒープは OS にメモリを要求し、OS は「OK」と回答して、このメモリを確保する予定であることを記録するだけです。実際には、このタイミングで OS がプログラムにメモリを提供するわけではありません。Windows、Linux、Android の世界ではそのような仕組みになっています。これは優れた仕組みですが、わかりにくく、意外な動作かもしれません。プロセスがそのメモリにまったくアクセスしない場合、メモリがプロセスに追加されることはありません。しかし、プロセスがメモリにアクセスすると、メモリがゼロで初期化され、個々のページがプロセスに割り当てられます。この動作は、デマンドゼロ ページ フォールトと呼ばれます。需要が発生したタイミングで「フォールト」が起き、ゼロで初期化されたページがプロセスに渡されるからです。

つまり、大きなメモリブロックの割り当ては非常に安価ですが、確保される予定のメモリが実際に準備されるわけではありません。その後にプログラムがメモリを使おうとし、CPU がそのアドレスにメモリがないことを知ると、CPU は例外を発生させて OS をウェイクアップさせます。OS は記録を確認し、そのアドレスでメモリを確保したことが確認できると、そこにメモリを割り当ててプログラムを再起動させます。この処理は一瞬で終わるので、十分気をつけていないと見逃してしまいます。しかし、プロファイリングをすれば、サンプルに KiPageFault として表示されます。

この奇妙な動作は、4 KiB のブロックが割り当てられるごとに発生します。4 KiB というのは、CPU と OS が扱うページのサイズです。

このコストは少なく、10 秒間で KiPageFault に該当するのは 124 サンプルだけです。つまり、124 ミリ秒(0.124 秒)しかかかっていません。これを包含する CopyImage_SSE4_1 関数の合計コストは約 240 ミリ秒なので、この関数の半分以上がページ フォールトの処理時間であることになりますが、15 行目の OnSample 関数のコストの 4 分の 1 ほどでしかありません。

ページ フォールト自体の合計コストはわずかですが、ここから他の部分でコストが生じていることがうかがえます。
  • このメモリが繰り返し(おそらくすべてのフレームで)割り当てられている場合、すべてのフレームで解放する必要もあります。26 行目を見ると、メモリを解放する Release 関数に別の 64 サンプルが使われていることがわかります。
  • ページが解放されたとき、オペレーティング システムはそのページを再利用できるように、ゼロで初期化する必要があります(セキュリティ確保のため)。これは Windows System プロセスが行うので、ほぼ完全に見えないコストになります。実際に System プロセスを見てみると、138 サンプルの MiZeroPageThread を確認できます。システム全体の KiPageFault サンプルの 87% が CopyImage_SSE4_1 の呼び出しによるものであることがわかったので、138 サンプルの MiZeroPageThread の 87% がこのパターンによるものと想定されます。


メモリ割り当ての隠れたコストについては、2014 年のブログ投稿で分析しました。Windows の基本的なメモリ アーキテクチャはその後も変わっていないので、隠れたコストは同程度です。

ETW トレースには、CPU のサンプルだけでなく、すべての VirtualAlloc 呼び出しのコールスタックも含まれています。次の WPA のスクリーンショットは、OnSample 関数が 10 秒の間に 1 回あたり 1.320 MB の割り当てを 298 回(1 秒間におよそ 30 回)行っていることを示しています。


現時点で、この割り当ての繰り返しによるコストは、124(フォールトによる読み込み)+64(解放)+124(ゼロで初期化するサンプルの 87%)の合計 312 サンプルと想定されます。これは、ビデオ会議の合計 CPU コストの最大 1.9% になります。これを修正しても世界が変わることはないでしょうが、変更するだけの価値はあります。

その他のコスト

バッファの内容を確認するためにバッファをロックしていますが、実際には、ロック呼び出しによってバッファをコピーすること自体が不要です。ロック呼び出しにやってもらいたいのは、その場所を見ることができるように、バッファの内容を返してもらうことだけです。つまり、MFCopyImage を呼び出すコストがすべて無駄になっていることになります。これで、さらに 116 サンプルが追加されます。加えて、26 行目の CMF2DMediaBuffer::Unlock 呼び出しでは、別の CMF2DMediaBuffer::ContiguousCopyFrom 呼び出しが行われています。これはバッファのコピーが変更されることを想定した処理で、Unlock 呼び出しによって逆方向にコピーしています。そのため、この 101 サンプルも無駄であることがわかります。

割り当て / コピー / コピー / 解放という動作をせずにこのバッファを参照できれば、312 サンプルに加えて、116 サンプル(残りのコピーのコスト)+101 サンプル(逆コピーのコスト)を節約できます。これで節約可能な合計は 3.2% になり、さらなる向上が見込めます。

なお、サンプルデータは統計的にのみ有効なので、実際の割合はコンピュータや細かなワークロードによって大きく異なります。しかし、重要な点は変わりません。劇的ではないものの、調査してみる価値がある変更です。

長年ビデオゲーム業界に関わってきたにもかかわらず、私のグラフィック関係のバッファのロックやアンロックをする API に関する知識は豊富ではありません。最終的にコピーを完全に回避できるという結論にたどりつき、大まかな修正パターンに行き着くには、Twitter フォロワーの皆さんの知恵に頼らざるを得ませんでした。長文なバグを報告し、実際の修正作業を委任しました。修正は M85 で実施され、重要性が高いと評価されたため、M84 にもバックポートされました。

この修正は、Chrome やシステムのさまざまなプロセスにまたがっているので、実際に差を確認するには、かなり細かい注意を払う必要があります。しかし、一部のコンピュータで少しだけ熱くならずに実行できるようになったり、電池が少しだけ長持ちしたりするようになることを期待しています。また、この非効率な処理は Google Meet のプロファイリングによって見つかりましたが、実際には、Chrome(とその他の Chromium ベースのブラウザ)でウェブカメラを使うプロダクトであれば、どのようなものであっても改善の恩恵を受けることができます。

確認

この修正が実施された後、変更の前後の Chrome Canary で、2 つの 10 秒間の ETW トレースを比較してみました。どちらのトレースも、1 つの Chrome タブで Google Meet のミーティング前ページを開く以外、他のプログラムを実行しない状態で取得したものです。また、どちらもプロファイラでの 10 秒間を対象としました。結果は次のようになりました。


OnSample の CPU 時間 :
変更前 : 458 ミリ秒(そのうち 432 ミリ秒が Lock/Unlock/KiPageFault)
変更後 : 27 ミリ秒


割り当て :
変更前 : 1 秒あたり 1.32 MB の割り当てが 30 回(30 fps のフレーム 1 つにつき 1 回。さらに高いフレームレートでは割り当てがさらに多くなる)、10 秒間で合計 396 MB
変更後 : 0 回


System プロセスの MiZeroPageThread の CPU 時間 :
変更前 : 36 ミリ秒
変更後 : 0 ミリ秒

この 3 とおりの測定結果から、パフォーマンスの問題が修正されたことがわかります。OnSample によるメモリのコピーがなくなり、繰り返しの割り当てがなくなり、システム プロセスの作業量も減っています。任務は完了、バグはクローズです。



Reviewed by Eiji Kitamura - Developer Relations Team

この記事はデベロッパー アドボケート、Eiji Kitamura、プロダクト マネージャー、Ali Sarraf による Chromium Blog の記事 "Help users log in across affiliated sites on Chrome" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Chrome は、新しいパスワードを生成したり、保存されたパスワードの自動入力や同期をしたり、侵害されたパスワードについてユーザーに警告したりすることができます。つまり、ユーザーは自分でパスワードを管理する必要がなくなります。しかし、複数のドメインで同じアカウント管理バックエンドを利用している場合(たとえば、https://www.example.comhttps://www.example.co.uk のような複数のトップレベル ドメイン)、Chrome はドメインをまたいで自動入力をしてくれません。その結果、異なるドメインに対して同じパスワードのエントリが 2 つできることになり、同期がとれなくなることもあります。

バージョン 91 以降の Chrome では、Digital Asset Links(DAL)で関連付けられたドメイン間で、保存したパスワードの自動入力が提案されます。DAL は、Android アプリとウェブサイトを関連付けるために、2015 年から利用されています。Chrome 91 では、サイト間で DAL を設定すると、Chrome がサイトをまたいでユーザーのログインをアシストしてくれます。DAL の関連付けをするには、両方のドメインの /.well-known/assetlinks.jsonDAL 構文に従った JSON ファイルを配置する必要があります。

DAL の関連付けの詳しい設定方法については、すべての連携サイトで Chrome がログイン認証情報を共有できるようにするをご覧ください。


Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Chromium Blog の記事 "Chrome 91: Handwriting Recognition, WebXR Plane Detection and More" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2021 年 4 月 22 日の時点で Chrome 91 はベータ版です。

オリジン トライアル

このバージョンの Chrome には、以下のオリジン トライアルが導入されています。オリジン トライアルとして新機能を試せるようにすることで、ウェブ標準コミュニティにユーザビリティ、実用性、有効性についてのフィードバックを提供することができます。以下の項目を含め、現在 Chrome でサポートされているオリジン トライアルに登録するには、Chrome オリジントライアル ダッシュボードをご覧ください。Chrome のオリジン トライアルの詳細については、ウェブ デベロッパーのためのオリジントライアル ガイドをご覧ください。Microsoft Edge は、Chrome とは別に独自のオリジン トライアルをしています。詳細については、Microsoft Edge オリジントライアル デベロッパー コンソールをご覧ください。

新しいオリジン トライアル

PWA の宣言的リンク キャプチャ

新しいウェブアプリ マニフェストのメンバーとして、capture_links が追加されます。これを使うと、ユーザーがインストール済みのウェブアプリのスコープ内でページを移動したときの動作をコントロールできます。ユーザーがアプリへのリンクをクリックしたときに自動的に新しい PWA ウィンドウを開いたり、モバイルアプリのようなシングル ウィンドウ モードにしたりすることが可能です。オリジン トライアルに登録すると、オリジントライアル ダッシュボードで詳細を確認できます。

WebTransport

WebTransport は、ウェブのセキュリティ モデルの制約を受けるクライアントがリモート サーバーと通信する際に、安全な多重化転送をできるようにするプロトコル フレームワークです。

現在、ウェブ アプリケーション デベロッパーがリモート サーバーと双方向通信をする場合、WebSocketsRTCDataChannel という 2 つの API を使うことができます。WebSockets は TCP ベースなので、すべての TCP の欠点(ヘッドオブライン ブロッキング、信頼できないデータ転送の未サポート)を引き継ぐことになり、レイテンシが重要なアプリケーションには適しません。RTCDataChannel は Stream Control Transmission Protocol(SCTP)ベースなので、そのような欠点はありません。しかし、ピアツーピアで使うことを念頭に置いて設計されているので、クライアント サーバー設定で使われることはほとんどありません。WebTransport は、信頼できないデータと信頼できるデータの両方の双方向通信をサポートするクライアント サーバー API で、UDP 的なデータグラムによるキャンセル可能なストリームを利用します。WebTransport の呼び出しは DevTools の [Network] パネルで確認できます。[Type] 列を見ると、このプロトコルが使われていることがわかります。

詳しくは、WebTransport の試験運用をご覧ください。オリジン トライアルに登録すると、オリジントライアル ダッシュボードで詳細を確認できます。

WebXR Plane Detection API

WebXR アプリケーションで、ユーザーの環境内の平面についてのデータを取得できるようになります。これにより、低い処理能力でも高いユーザー エクスペリエンスを実現できます。この機能なしに平面検出をするには、MediaDevices.getUserMedia() のデータを利用してカスタムのコンピュータ ビジョン アルゴリズムを実行する必要があります。通常、このようなソリューションは、AR エクスペリエンスに求められる質や精度を満たせず、ワールドのスケールもサポートされません。オリジン トライアルに登録すると、ダッシュボードで詳細を確認できます。

完了したオリジン トライアル

Chrome で以前にオリジン トライアルが行われていた以下の機能は、現在デフォルトで有効化されています。

battery-savings メタタグ

サイトがユーザー エージェントに対し、ページよりもユーザー エージェントのほうが得意とする方法で電池寿命を節約し、CPU の利用を最適化することを推奨できるようになります。たとえば、フレームレートを落とすことを許可したり、スクリプトの速度を下げることを許可したりできます。詳しくは、解説をご覧ください。

非表示テキストの検索

ユーザーがページ内検索をし、ある要素で一致するテキストが見つかると、beforematch イベントが発行されます。これまでは、content-visiblityhidden に設定されていた場合、このイベントは発行されませんでした。content-visibility: hidden-matchable CSS プロパティは、content-visibility: hidden と同じように動作しますが、ページ内検索で非表示テキストを検索でき、beforematch イベントも発行されます。beforematch イベントと content-visibiliy: hidden-matchable を組み合わせて使うと、ページ内検索に反応して非表示コンテンツを展開するウェブサイトを実現できます。詳しくは、解説をご覧ください。

WebAssembly SIMD

WebAssembly SIMD は、プラットフォームに依存しない方法でハードウェア SIMD 命令を WebAssembly アプリケーションに公開します。これにより、さまざまな種類の圧縮データを表す新しい 128 ビット型や、圧縮データを扱ういくつかのベクトル演算を導入できます。SIMD は、データレベルの並列化を利用してパフォーマンスを大きく向上できることに加え、ネイティブ コードを WebAssembly にコンパイルする場合にも役立ちます。詳しくは、WebAssembly SIMD の V8 機能の解説をご覧ください。

今回のリリースに追加されたその他の機能

Performance API のタイマー解像度とクロスオリジン分離機能の一致

サイト分離の有無に基づいた performance.now() と関連するタイムスタンプの精度を下げる処理が、プラットフォーム間で一貫した動作になりました。これにより、デスクトップ版の分離されていないコンテキストでは、解像度が 5 マイクロ秒から 100 マイクロ秒に下がります。また、Android 版でクロスオリジン分離されているコンテキストでは、解像度が 100 マイクロ秒から 5 マイクロ秒に上がります。

クリップボード : 読み取り専用ファイルのサポート

デスクトップ版で、アプリがクリップボードからファイルを読み取ることができるようになります(ただし、クリップボードにファイルを書き込むことはできません)。アプリは、クリップボードのファイルに読み取り専用でアクセスします。

async function onPaste(e) {
  let file = e.clipboardData.files[0];
  let contents = await file.text();  
}

CSS

カスタムのカウンター スタイル

リストマーカーや CSS カウンターで CSS の @counter-style ルールを使うと、ウェブ制作者がカスタムのカウンター スタイルを指定できます。これは国際化に役立ちます。この変更は、以下を除くすべての CSS Counter Styles Level 3 機能で実装されます。

  • どのブラウザもサポートしておらず、仕様によれば「危険性がある」イメージ シンボル
  • ユーザー補助機能である speak-as ディスクリプタ
  • symbols() 関数

:host() と :host-context() での単一の <compound-selector>

:host() と :host-context() 疑似クラスが、<compound-selector-list> に加えて単一の <compound-selector> を受け取れるようになります

Android 版でのフォーム コントロールの外観の更新

フォーム コントロールの外観が刷新され、ユーザー補助機能とタッチのサポートが向上します。これは Microsoft と Google の共同作業です。詳しい情報は、以前の CDS トークMicrosoft のブログ投稿をご覧ください。

今回のリリースでは、すでに他のプラットフォームでリリースしたものと同じフォーム コントロール UX を Android 版にも提供します。新しいフォーム コントロールには、ダークモードでフォーム コントロールやスクロールバーが自動的に暗い色になる機能が含まれています。

ダークモードは、ウェブ制作者がウェブページをダークモードで表示できるようにするユーザー補助機能です。これを有効にすると、ユーザーは Android デバイスでダークモード設定を切り替えることにより、サポートされているウェブサイトをダークモードで表示できます。ダークモードは低光量環境で目にやさしく、電池の消費も少なくなります。

GravitySensor インターフェース

GravitySensor インターフェースは、重力の 3 軸読み取り値を提供します。これまでも、Accelerometer の読み取り値から LinerAccelerometer の読み取り値を除くことで、このインターフェースで提供される値に近い値を算出することができました。

File System Access API でのファイル名と場所の提案

ウェブアプリで File System Access API を使う場合、作成または読み込みをするファイルやディレクトリの名前と場所を提案できるようになります。これにより、ユーザー エクスペリエンスが向上し、ウェブアプリの動作がシステムアプリに近づきます。File System Access API の詳細については、File System Access API: ローカル ファイルへのアクセスを簡単にするをご覧ください。

WebOTP API: クロスオリジン iframe のサポート

パーミッション ポリシーで許可されている場合、WebOTP API をクロスオリジン iframe で利用できるようになります。WebOTP API を使うと、プログラムによってそのオリジンが宛先となった特別な形式の SMS メッセージからワンタイム コードを読み取り、ユーザーの手間を減らすことができます。認証を扱う iframe は、多くのサイトに埋め込まれています。

WebSockets over HTTP/2

Chrome は、Chromium の WebSockets over HTTP/2RFC 8441 で規定)をサポートします。これは、すでに HTTP/2 で接続しており、サーバーが仕様で規定されている HTTP/2 の SETTINGS パラメータによって WebSockets over HTTP/2 のサポートをアドバタイズしていて、安全な WebSockets リクエストが行われた場合のみ利用されます。

Digital Asset Links で連携したサイト間の認証情報の共有

2015 年より、デベロッパーは Digital Asset Links(DAL)を使って Android アプリとウェブサイトを関連付け、ユーザーのログインをアシストしています。複数のドメインで同じアカウント管理バックエンドを共有している場合は、それらを相互に関連付けることで、Chrome のパスワード マネージャーがすべての連携するウェブサイトで保存した認証情報を提案するようになります。詳しくは、すべての連携サイトで Chrome がログイン認証情報を共有できるようにするをご覧ください。

JavaScript

このバージョンの Chrome には、V8 JavaScript エンジンのバージョン 9.1 が組み込まれます。具体的には、以下の変更点が含まれます。最新の機能リストをすべて確認したい方は、V8 リリースノートをご覧ください。

Service Worker の ES モジュール('module' タイプ オプション)

JavaScript が Service Worker でモジュールをサポートします。コンストラクタの type 属性に 'module' タイプを設定すると、ワーカーのスクリプトが ES モジュールとして読み込まれ、ワーカーのコンテキストで import 文が利用できるようになります。この機能を使うと、組み合わせ可能なプログラムを簡単に書けるようになり、ページやワーカー間でプログラムを共有しやすくなります。

プライベート フィールドのチェック

#foo in obj 構文により、オブジェクトでプライベート フィールドの存在チェックをできるようになります。

サポートの終了と機能の削除

このバージョンの Chrome では、デベロッパーに関連するサポートの終了や機能の削除はありません。以前の機能の削除リストは、ChromeStatus.com をご覧ください。


Reviewed by Eiji Kitamura - Developer Relations Team


Google Open Source Live イベントシリーズを開催いたします。

第 8 回目の今回のイベントは「Open data lake day」です。

 

Google に在籍するデータ アナリティクスのエキスパートが、オープンテーブル フォーマットや、イノベーションとクラウドのバリアの克服方法などについてお話しします。

 

セッション中には質問を投稿できるフォーラムが立ち上がります。Google 社員に直接質問ができるチャンスとなりますのでぜひ、ご活用ください。

 

また、セッション終了後に Google Meet にてアフターパーティーを開催いたします。他の参加者の方達と交流したり、Google オリジナルグッズが当たるクイズゲームなどをご用意しておりますのでぜひ、ご参加ください。

 

日本語版のイベントでは、日本語での MC、日本語の字幕付きセッション、そして日本語開催のアフターパーティーとなります。

英語版をご希望の方は太平洋時間の 9:00 am PST、日本語版をご希望の方は日本時間の 9:00 am JST にご参加ください。



事前お申込み受付中 : http://goo.gle/OpenDataLakeDayJP


開催概要

名 称 『Open data lake day』

日 程 日本語版 : 5 月 7 日(金)9:00 am - 11:00 am JST (日本時間)

    英 語 版 : 5 月 6 日(木)9:00 am - 11:00 am PST (太平洋時間)

対 象 開発エンジニア、インフラ エンジニア、運用エンジニア

参加費 無料(事前登録制)

登 録 http://goo.gle/OpenDataLakeDayJP


基調講演

オープンソースによってイノベーションとクラウドの壁を取り除く

アマー・アワダラ

クラウド・デベロッパー・リレーションズ 担当 副社長 (Google)