すべての人は、安全で強力、そして高速なオープンウェブの恩恵を受けています。私たちはここ 1 年で、次にあげる 3 つの領域について、集中的にウェブの強化を行ってきました。
この投稿では、本日（元記事公開当時）の Chrome Dev Summit の基調講演で共有したアップデートの概要をまとめます。
私たちはプライバシー サンドボックスの作業を継続し、ウェブのプライバシーを抜本的に強化するオープンな基準を作ろうとしています。そして、ウェブ コミュニティと協力しつつ、サードパーティ Cookie やクロスサイト トラッキング メカニズムに代わり、プライバシーを守ることができる新たな仕組みを構築しようとしています。Client Hints API では Chrome でフィンガープリンティングに使える領域を減らし、Chrome オリジン トライアルを通して実験できる 2 つのソリューションも提供しています。Click Conversion Measurement API は、クロスサイト識別子を使わずに広告コンバージョンを測定します。Trust Token API は、パッシブなトラッキングを行うことなく、あるコンテキストから別のコンテキストに信頼を伝える際に役立ちます。
同様に、数億人のユーザーが利用する Chrome ウェブストアの 250,000 件以上の拡張機能でも、セキュリティとプライバシーが最重要になっています。私たちは、拡張機能はデフォルトで信頼できるものでなければならないと考えています。そのため、拡張機能プラットフォームにたくさんの変更を行うドラフト提案についてお知らせしました。拡張機能デベロッパーからのさまざまな提案を反映すれば、Manifest V3 の安定版リリースに向けた準備が整います。その目的は、セキュリティの強化、ユーザーの制御とプライバシーの向上、パフォーマンスの改善です。
Manifest V3 と合わせて、リモートでホストされたコードは許可されなくなります。これは、ユーザーのプライバシーやセキュリティを侵害する悪意のある拡張機能を防ぐためです。また、新しい拡張機能モデルでは、ユーザーがインストール時にセンシティブな情報へのアクセスを許可しないことを選択できるようになります。さらに、バックグラウンド ロジックに新たなアプローチを導入します。バックグラウンド ページに Service Worker を導入し、拡張機能 API に新たな宣言的モデルを適用することで、ユーザーに一貫したパフォーマンス保証を提供します。現在、Manifest V3 は Chrome 88 ベータ版で試験運用版として利用できます。Chrome ウェブストアは、Chrome 88 が安定版になる 1 月中旬から、Manifest V3 拡張機能を受け付ける予定です。
ウェブで新しい体験を構築しているデベロッパーから、すばらしい活用例が登場しています。Gravit Designer は、File System Access API を使ってユーザーが簡単にファイルの読み書きを行えるようにし、さらに新しい Local Font Access API でローカルにインストールした特別なフォントを利用できるようにしています。Adobe は、Spark ウェブアプリでユーザーがすばらしいビジュアル ストーリーや美しいデザインのコンテンツを簡単に作れるようにしています。
本日（元記事公開当時）、Progress Web App（PWA）に新機能を追加します。これによって、PWA を Google Play ストアに掲載して見つけてもらいやすくすることができます。Chrome 86 では、Trusted Web Activity を使っている PWA を Play ストアで一覧表示できるようになります。また、Chrome 88 では、新しい Digital Goods API を使って支払いを受け取れるようにしています。
デベロッパーの皆さんがすべてのユーザーに最適な体験を提供できるようにするため、Chrome のパフォーマンス（スピードのほか、電力、メモリ、CPU などのリソースの使用量）は常に私たちの最優先事項になっています。
今年は、プロファイルによる最適化とタブ スロットリングによって、スピードに関するいくつかの重要な改善を行いました。そして本日は、V8 のメモリ フットプリントを大幅に削減したことをお知らせします。V8 ポインタ圧縮でメモリの節約に向けた大きな一歩を踏み出したことに加え、ウェブページの JavaScript ファイルを並列に読み込むことで解析による中断を完全に無くしました。これによって、ページで必要になるときには既にスクリプトの実行準備が整っているように、スクリプトの解析とコンパイルを実行できます。
Web Vitals の取り組みについて発表して以来、ウェブページのパフォーマンスを測定する際にこの基準が使われることが多くなっています。Google 検索は、2021 年 5 月より、検索ランキングの新たなシグナルに Core Web Vitals を含めることを発表しました。Chrome ユーザー エクスペリエンス レポートに加え、Search Console の Core Web Vitals レポートやその他多くの Google 製ツール、Cloudflare などの他のプロバイダで、Core Web Vitals がウェブページのパフォーマンス指標として表示されています。
この夏、Google アナリティクスを使っているサイト向けに、web-vitals Javascript ライブラリをリリースしました。本日、オープンソースのウェブサイトおよびツールである Web Vitals Report についてお知らせしました。これを使うと、Google アナリティクスで Web Vitals 指標データのクエリや視覚化ができるので、セグメント間で簡単にパフォーマンス データを比較することもできます。
最後になりますが、皆さんのフィードバックや、ウェブ インターフェースの構築が難しい点についてのご意見をお待ちしています。私たちは、ウェブのスタイリング機能の改善を進めており、レンダリング パフォーマンスを大幅に向上させる content-visibility CSS 機能を公開しました。簡単に CSS を拡張できる API セットである Houdini.how のお知らせなど、UI スタイリングを改善するアップデートやツールにご期待ください。
Chrome Dev Summit は、常にコミュニティとのつながりを大切にしています。今回は直接顔を合わせることはできませんでしたが、Chrome チームは、偶然の会話や新しい発見、記念品の収集など、実際のカンファレンスのいい所を集めた PWA、Chrome Dev Summit Adventure をリリースしました。この実験について皆さんからの感想を聞いたり、リアルタイムでチャットしたりするのが楽しみです。
コミュニティの一員になり、世界中の Google Developer Group に参加しましょう。CDS Extended イベントでは、地域のデベロッパー コミュニティを集めて、Chrome Dev Summit 2020 のハイライトを確認したり、インタラクティブなセッションがライブで行われたりします。このイベントのすべてのリストをチェックしてください。
YouTube チャンネルでは、いつでもセッションを視聴できます。また、web.dev ニュースレターにサインアップしてウェブの最新アップデートを受け取ってください。
また来年にお会いしましょう！
※ 日本では Chrome Dev Summit の日本版となる Chrome Dev Summit Recap 2020 を開催しました。アーカイブは 2021 年 1 月中旬まで閲覧可能ですので、ぜひ今からでも登録・ご視聴下さい。
社会課題をテクノロジーで解決に導く スタートアップを対象とした 3 か月集中型のプログラム 「 Google for Startups Accelerator Class 3 」の参加企業を発表します。昨年 9 月 より募集を開始し、多くの素晴らしい目標を持ったスタートアップにご応募をいただきました。ありがとうございました。
アクセラレーターに参加が決定したのは、下記 11 社です。
今後 3 ヶ月に渡って、社会課題解決に特化したセッションをはじめ、機械学習などのテクノロジーに関するセッションや世界の外部や Google 社員によるオンライン メンタリング等を提供し、参加企業のさらなる成長を支援していきます。
プログラムについての詳細は、Google for Startups のページをご参照ください。
本日、Google は Discover に Web Stories を導入することをお知らせしました。Discover は、Android および iOS 向けの Google 製アプリの一部です。米国、インド、ブラジルでは、Discover の上部に Stories カルーセルが表示されます。ユーザーはこれを使って、ウェブ全体から優れたビジュアル コンテンツを見つけることができます。詳しいお知らせは、こちらからお読みいただけます。
このお知らせと合わせて、Google で Web Stories がどのように表示されるかを説明した新しいウェブサイトもリリースしています。このニュースは、Web Stories にとって重要なマイルストーンです。AMP コミュニティは、このオープンソース フォーマットを活用するユーザーが広がることをうれしく思っています。
Web Stories フォーマットの新機能について詳しく知りたい方は、10 月 13 日に開催される AMP Fest にご登録ください。
私たちはいつも、Google アカウントのセキュリティ保護の改善に努めています。私たちのセキュリティ システムは、さまざまなセキュリティ脅威を自動的に検知して警告し、ユーザーを保護しています。「中間者攻撃」（MITM）として知られる形態のフィッシングは、ブラウザ フレームワーク（例: Chromium Embedded Framework - CEF）に埋め込まれたり、他の自動化プラットフォームが認証に使われていたりすると、検出が難しくなります。MITM は、このようなプラットフォームの認証フローを表示し、ユーザーと Google との間の通信をインターセプトすることで、ユーザーの認証情報（場合によっては、多要素認証の 2 段階目の要素も含まれます）を集めてログインを行います。このようなタイプの攻撃からユーザーを保護するため、2021 年 1 月 4 日以降、すべての埋め込みフレームワークからの Google アカウントへのログインがブロックされます。CEF ベースのアプリやその他のサポート外ブラウザは、このブロックによって影響を受けます。
パートナーへのサービス中断を最低限にとどめるため、デベロッパーがサポート対象のユーザー エージェントで OAuth 2.0 フローを設定する際に役立ててもらえるよう、この情報を提供します。本ドキュメントでは、以下について概要を説明します。
デバイスでの認証に CEF などのクライアントを使っているアプリのデベロッパーは、ブラウザベースの OAuth 2.0 フローを使ってください。または、対応するネイティブの完全なブラウザを使ってログインすることもできます。
ブラウザにアクセスできない場合や入力機能が限られている場合など、入力に制限のあるデバイスのアプリケーションでは、入力が制限されるデバイスの OAuth 2.0 フローを使ってください。
セキュリティ アップデートが行われているモダンブラウザは、引き続きサポートされます。
ブラウザでは、JavaScript が有効になっている必要があります。詳細については、以前のブログ投稿をご覧ください。
ブラウザは、ネットワーク通信のプロキシとなったり、変換を行ったりしてはいけません。ブラウザでは、以下のことを行ってはいけません。
ブラウザは、妥当な範囲のウェブ標準とブラウザ機能の実装を完了している必要があります。ブラウザには、以下が含まれていないことを確認する必要があります。
ブラウザは、User-Agent で自身を明確に識別できる必要があります。ブラウザは、Chrome や Firefox などの別のブラウザになりすまそうとしてはいけません。
ブラウザは、自動化機能を提供してはいけません。これには、キー入力やクリックを自動化するスクリプト（特に自動ログイン）を含みます。CEF や Embedded Internet Explorer などのフレームワークに基づいたブラウザからのログインは許可されません。
現在 CEF を使ってログインを行っているデベロッパーは、このタイプの認証のサポートが 2021 年 1 月 4 日で終了することに注意してください。変更によって影響を受けるかどうかを確認するには、アプリケーションで互換性テストを行います。アプリケーションをテストするには、特殊な HTTP ヘッダーと値を追加して許可リストを無効にします。以下の手順で、許可リストを無効にする方法を説明します。
次の例は、CEF で許可リストを無効にする方法を説明しています。
注: カスタム ヘッダーは、CefRequestHandler#OnBeforeResourceLoad で追加できます。
CefRequest::HeaderMap hdrMap; request->GetHeaderMap(hdrMap); hdrMap.insert(std::make_pair("Google-Accounts-Check-OAuth-Login", "true"));
Chrome で手動テストを行うには、 ModHeader を使ってヘッダーを設定します。このヘッダーを使うと、特定のリクエストに対して変更が有効になります。
この記事は Chris Banes による Android Developers - Medium の記事 "Jetpack Compose — Before and after" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
今年になってから、サンプル アプリTivi の UI を Jetpack Compose に徐々に移行していました。そして 2020 年 12 月第 2 週、移行作業の第一段階がほぼ完了しました。
今回のブログ投稿では、重要な指標の数値を振り返って比較し、Compose によって何が変わるのかを確認してみましょう。比較するのは、APK サイズ、ビルド速度、コードの行数です。
Compose の話題を進める前に、まずは簡単にアプリについて説明します。
Tivi はかなり細かくモジュール化されており、それぞれの UI の「画面」ごとに Gradle モジュール（ui-$NAME）があります。それぞれの画面は Fragment で実装され、メインアプリ モジュールでは AndroidX Navigation を使ってそれらを組み合わせています。
ナビゲーション グラフはディープリンク URI を使って実装されているので、ほとんどの Fragment はお互いのことを知りません。そのため、疎結合が保証されます。しかし、それよりも重要なことは、独立してコンパイルできるため、ビルドの並列化がしやすくなることでしょう。
Compose に移行する前の Tivi は、Android デベロッパーが利用できるありとあらゆるクールな UI を利用していました。一例をあげれば、データ バインディング、Epoxy、マテリアル デザイン コンポーネント、Insetter DBX、MotionLayout などです。しかし残念ながら、これらの大半ではアノテーション処理が使われているため、ビルドのコストがかかります。
先ほど、移行の「第一段階」を終えたばかりだと書きました。これはどういう意味でしょうか。2020 年 1 月にこの作業を始めたときから、アプリの見た目はほとんど変わっていません。
アプリがモジュール化されているということは、移行自体も部品単位になり、一度に 1 つの Fragment だけ移行できるということです。この 11 か月間はまさにそれを実践し、46 個のプル リクエストに対応しています。
最初に簡単な画面 Episode details を移行し、次に Show details、そして ‘Discover’、‘Search’、‘Followed shows’ と移行を進めました。最近追加された Compose の Paging3 サポートと合わせて、最後の画面となった ‘list’ グリッドを移行できました。
2020 年 12 月 10 日（日本時間 12 月 11 日）、アプリから AppCompat、マテリアル デザイン コンポーネント、その他の AndroidX ウィジェット ライブラリを削除する処理を始めました。これは、Tivi の UI が Compose ベースになったことを意味します。
Remove AppCompat + MDC by chrisbanes · Pull Request #737 · chrisbanes/tivi
アプリで Fragment と Navigation を使っている点は変わりませんが、論理的な次のステップは、Fragment から移行して直接新しい Navigation Compose コンポーネントを使うようになります。
この移行の過程は近日中に別のブログ記事で書きたいと思いますが、本投稿の最後の「まとめ」から、私自身の言葉を引用しておきます。
いろいろ考えなくても、Compose が Android の UI 開発の未来であることはわかります。
では、いくつかの指標を確認してみましょう。
以下のそれぞれの指標では、3 つのバージョンのアプリを比較します。
ユーザーが最も気にする指標は、APK サイズです。
以下の結果は、リソース圧縮を有効にし、R8 を使って最小化した release APK を APK Analyzer で測定したものです。
‘adjusted’（調整済み）の値と ‘Pre-Compose’ を比較すると、Compose を使った場合は APK サイズが 41%、メソッド数は 17% 削減されていることがわかります。
Compose を使った場合は、APK サイズが 41%、メソッド数は 17% 削減されていることがわかる
この数から、AppCompat や MDC などがアプリ内でどれほどの容量を占めているかがわかります。それだけではなく、レイアウト ファイルで使われる場合に備えてすべての View クラスを保持しなければならない場合には、最小化ツールはほとんど役に立たないこともわかります。
ソフトウェア プロジェクトを比較する場合、ソースの行数を数えても特に役立つ統計情報にはならないことは承知していますが、この比較によって、どのような変化が起きているのかは確実に把握できます。
このテストでは、cloc ツールで以下のコマンドを使い、すべてのビルドと生成されたファイル、設定ファイルを除外しました。
cloc . --exclude-dir=build,.idea,schemas
cloc ツールにはコメントを無視する機能が組み込まれているので（ただし、検証はしていません）、上記は実際の「コード」の結果です。当然ながら、XML の行数は大幅に少なくなり、76% 削減されています。レイアウト ファイル、スタイル、テーマなど、たくさんの XML ファイルとお別れできます。
同じように興味深いのは、Kotlin の合計行数も減っていることです。仮説としては、アプリ内のボイラープレートが減り、たくさんのビューヘルパーやユーティリティ コードを削除できたためだと考えられます。3,000 行近くを削除できたこちらの PR をご覧ください。
Remove a load of old code 🗑️ by chrisbanes · Pull Request #713 · chrisbanes/tivi
ビルド速度はデベロッパーの関心が非常に高い指標です。このプロセスを開始する前は、多くのアノテーション プロセッサを削除できることでビルド速度が向上するものと考えていましたが、どの程度かはよくわかりませんでした。
テストの設定
説明を続ける前に、以下の数値をどのようにして測定したのかを知っておくことが重要になります。ここでは、Chris Horner が異なる CPU でビルド速度を測定したときと同じ設定を使いました。
テストに使ったマシンは、192 GB の RAM と超高速な Xeon® Gold 6154 CPU を搭載した Lenovo P920 です。言うまでもなく、このマシンは一般的なデベロッパーの設定ではありません。そこで、現実に近いテストを行うため、CPU を最低クロック周波数に固定しました。
# Use performance governor to allow tweaking of max freq
sudo cpupower frequency-set -g performance
# Set max frequency to CPU minimum: 1.2GHz
sudo cpupower frequency-set -u 1.2GHz
その後、すべてのリモート アーティファクト キャッシュを準備するため、./gradlew assembleDebug を実行しました。
そして、テストを実行するため、次のコマンドをループで 5 回実行します。
./gradlew --profile \
--offline \
--rerun-tasks \
--max-workers=4 \
assembleDebug
厳密には --max-workers は必要ありませんが、この CPU では、デフォルトで Gradle が利用できる 64 個の「コア」のすべてが使われます。これを 4 に制限することで、通常のラップトップ CPU と比較しやすくします。
テスト結果は以下のとおりです。それぞれの結果プロファイル レポートの ‘Total Build Time’（合計ビルド時間）の値をご覧ください。
この結果にはかなり驚かされました。ほとんど数値が変わらなかったからです。予想では、多くのアノテーション プロセッサが削除されることで、‘Without view libs’（ビュー ライブラリなし）が大幅に速くなると思っていました。
結果の明細を見てみると、kapt の実行時間はすべて同じくらいでした。おそらくこれは、View Binding、Dagger/Hilt、Room の使用を継続しているためではないかと思います。
しかし、Kotlin コンパイラや Compose コンパイラ プラグインが行ってくれることを考えれば、ビルド時間が 5% 削減されたことに何も不満はありません。
これまでに説明してきた全ての結果に当てはまる注意点があります。
この 11 か月間、Tivi には何の機能も追加しませんでしたが、この点を厳密に制限したわけではありません。移行とはあまり関係のない部分で多くの変更を行っており、それが結果に影響した可能性もあります。
移行を行った 11 か月間で、多くの依存性が更新されました。ほとんどの依存性の更新はランタイム ライブラリの依存性だったので、APK サイズ指標に影響する可能性は低いはずです。
Gradle のアップデート（6.0.1 から 6.7.0）、Android Gradle Plugin のアップデート（3.6.0 から 4.2.0）、そして Kotlin のアップデート（1.3.61 から 1.4.20）などは、すべてビルド速度に大きな影響があります。
Compose は現在アルファ版なので、すべての成果物は開発中のスナップショットになります。来年 1.0 の安定版になったとき、これらのテストを再実行して違いが出るかを見るのが楽しみです。
結果と注意点を見る限り、リンゴ 🍎 とリンゴ 🍏 を比較しているわけではない（同じ条件で比較しているわけではない）ので、あまり多くの結論を出すべきではありません。これは、リンゴ 🍎 とそれよりも少し甘いナシ 🍐 を比べているようなものです。
果物の例はさておき、最大のポイントは Compose がほとんどのデベロッパー指標で良好な（または中立的な）影響を示していることです。この点と Compose でデベロッパーの生産性が大幅に向上することを踏まえれば、いろいろ考えなくても、Compose が Android の UI 開発の未来であることはわかります。
個人や小規模グループでゲームを開発するデベロッパーの情熱やイノベーションを称えるため、今年 3 年目となる Google Play | Indie Games Festival 2020 を開催しました。例年のようにファイナルイベントを公開対面形式で実施できないため、オンラインでの最終選考会をデベロッパーや、株式会社 Sisilala 安藤様を始めとする業界のさまざまな方からのご協力のもと開催することができました。
多くの取り組みが変更を余儀なくされる中でも、従来のイベントでは実現できなかった Top 20 全作品のプレゼンテーション枠の確保など、オンラインだからこそ実現できることに取り組みました。動画内では、Top 3 に入賞した合同会社リビルドゲームスの「METBOY!」様からイベントに対する感想も頂戴しています。
Google Play | Indie Gaes Festival 2020 の詳細をまとめた動画をご覧ください。
この記事は Nick Rout による Android Developers Blog の記事 "MAD Skills Material Design Components: Wrap-Up" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Modern Android Development（最先端の Android 開発）について取り上げる連載シリーズ MAD Skills の動画と記事の 3 番目のトピックが完結しました。今回は、マテリアル デザイン コンポーネント（MDC）についてご説明しました。このライブラリは、マテリアル コンポーネントを Android ウィジェットとして提供します。これを使うと、マテリアル テーマ、ダークテーマ、モーションなど、material.io で使われているデザイン パターンを簡単に実装できます。
説明した内容については、下記にまとめた各エピソードからご確認ください。これらの動画では、MDC についての最新の記事や、既存のサンプルアプリ、Codelab を詳しく説明しています。また、MCD チームのエンジニアによる Q&Aセッションも含まれています 。
最初のエピソードは、Nick Butcher が、なぜ私たちが MDC の利用を推奨するのかなど、今回の MAD Skills シリーズ全体の概要を説明しています。その後、マテリアル テーマ、ダークテーマ、モーションについて詳しく掘り下げていきます。また、MDC を Jetpack Compose と合わせて使う方法、MDC やテーマ、スタイルのベスト プラクティスを含むようにアップデートされた Android Studio のテンプレートについてもお話ししています。
エピソード 2 では、Nick Rout がマテリアル テーマについて説明し、Android で MDC を使ってこれを実装するチュートリアルについて解説しています。主な内容は、Theme.MaterialComponents.* アプリのテーマを設定し、material.io のツールを使用して色や種類、形状の属性を選択し、最終的にそれらをテーマに追加して、ウィジェットがどのように自動的に反応して UI を適応させるかを確認します。また、テーマカラー属性を解決する、イメージに図形を適用するなど、MDC が特定のシナリオ向けに提供している便利なユーティリティ クラスについても説明します。
Theme.MaterialComponents.*
Chris Banes が、Android アプリで MDC を使ってダークテーマを実装する方法を紹介しています。説明する内容は、Force Dark を使って短時間で変換しビューを除外する方法、デザインを選んでダークテーマを手動で作成する方法、`.DayNight` MDC アプリテーマ、`.PrimarySurface` MDC ウィジェット スタイル、そしてシステム UI を扱う方法などです。
エピソード 4 では、Nick Rout がマテリアルのモーション システムについて解説しています。また、既存の「Android でマテリアル モーションを使って美しい画面遷移を構築する」Codelab の手順を詳しくフォローしています。この Codelab では、Reply サンプルアプリを使って、コンテナ変換、共有軸、フェードスルー、フェードという遷移パターンを活用してスムーズでわかりやすいユーザー エクスペリエンスを実現する方法を紹介しています。また、Fragment（Navigation コンポーネントを含む）、Activity、View を使うシナリオについて説明しています。
エピソード 5 は、Android コミュニティから Google Developer Expert (GDE) の Zarah Dominguez さんが、MDC カタログアプリをウィジェットの機能や API の例として参考にしながら紹介してくれました。そのほか、異なる画面やフローにまたがる一貫したデザイン言語を確保するために、彼女が取り組んでいるアプリに「テーマショーケース」ページを構築することが、どのように有益であるかを説明しています。
最後のまとめとして、Chet Haase が MDC エンジニアリング チームの Dan Nizri と Connie Shi と一緒に Q&A セッションを行い、Twitter や YouTube で寄せられた皆さんからの質問に回答しました。このセッションでは MDC の起源、AppCompat との関係、今までの改善点について解説したほか、テーマやリソースを整理するためのベストプラクティス、さまざまなフォントやタイポグラフィ スタイルの使用方法、シェイプ テーミングなどについてお話しました。また、私たちはお気に入りの Material コンポーネントをすべて公開し、最後に、将来的に MDCと Jetpack Compose という Androidの次世代 UI ツールキットでは、デフォルトで Material Design が組み込まれる新しいコンポーネントが登場することについて議論しました。
このシリーズでは、MDC のデモとして、次の 2 つのサンプルアプリを使いました。
これらは、もう 1 つの Material Studies のサンプルアプリである Owl とともに、GitHub リポジトリの MDC サンプルで確認できます。
Reviewed by Takeshi Hagikura - Developer Relations Team and Hidenori Fujii - Google Play Developer Marketing APAC
