IntelliJ IDEA 2020.2でJavaFXのランタイムが同梱されなくなりました

IntelliJ IDEA の最新版 2020.2 がリリースされましたね。日本語でも新機能について案内する記事がアップされています。

www.jetbrains.com

この記事の最後のように次のような個人的に気になる記述がありました。

• パフォーマンスと表示の問題を回避するため、新たに JCEF との統合機能を提供して IntelliJ Platform のプラグインを実行できるようにしました。

まず多くの人は「JCEFって何？」ってなると思います。これはアプリケーションに Chromium を組み込めるようにするためのフレームワーク CEF (Chromium Embedded Framework) の Java ラッパーのことです。

• CEF のプロジェクトページ - https://bitbucket.org/chromiumembedded/cef
• JCEF のプロジェクトページ - https://bitbucket.org/chromiumembedded/java-cef

IntelliJ は IDE 内部で使う Web ブラウザコンポーネント (Markdown エディタの HTML プレビューなどで使っています) として今後は JCEF を使うようになったということです。これまでは IDE 内部で使う Web ブラウザコンポーネントとしては JavaFX の WebView を使っていましたが、2020.2 でこれをやめることになります。本件について JetBrains の Blog 記事で説明がありました。

blog.jetbrains.com

ご存じの通り IntelliJ は Swing をベースに作られています。従って JavaFX の WebView は JFXPanel を通して使うことになりますが、そのために性能やレンダリングの問題を解決できなかったとのことです。

実際、JavaFX と Swing はレンダリングスレッドもタイミングも異なり、Swing アプリの上で JavaFX ノードを描画するときは JavaFX のレンダリングエンジンである Prism エンジンではなく Java2D を使って描画するため、JavaFX のパフォーマンスを 100% 発揮することができないのも確かです。この不整合を解決しようとする計画も過去にはありましたが、 Oracle の JavaFX へのやる気が無くなった ので...。

というわけで上記の記事では IntelliJ のプラグイン開発者に対して今後は JavaFX への依存をやめ、Web ブラウザコンポーネントを使いたいときは JCEF を使うことを促しています。

ですが、JCEF は現在絶賛開発中のステータスで、ユーザーとして利用できるような段階にありません。ビルド方法のガイドはありますが利用方法のガイドはなく、API ドキュメントもありません。ラップ対象の CEF については既に利用可能なステータスにあり (C++ のライブラリです) 、ある程度ドキュメントもあるので、こちらを参照して利用方法を推測することになります。

さすがにこの状態で使うのは辛いので、JetBrains 側でラップした API をプラグイン開発者向けに用意したようです。以下のドキュメントで解説されています。

jetbrains.org

というわけで IntelliJ IDEA 2020.2 からは JavaFX のランタイムは同梱されなくなります。この点について個人的に1点気になることがありました。

実は IntelliJ は Java IDE の中で唯一 JavaFX Scene Builder を内部に組み込んでいた IDE でした。JavaFX のランタイムが同梱されなくなる 2020.2 ではどうなってしまうのでしょうか？

というわけで早速 FXML ファイルを開いてみました。すると...

「Scene Builder Kit をダウンロードしてくれ」というリンクが表示されました。このリンクをクリックすると次に JavaFX Runtime のダウンロードが求められ、それも行うと次のように Scene Builder が表示されました。

というわけで別途ランタイムをダウンロードする必要があるものの、Scene Builder が使えなくなったわけではないのでご安心ください。

以上、誰も気付かないであろう IDEA 2020.2 の変更点についてのお話でした。

横須賀軍港めぐりに乗ってきました

これまで横須賀には 2 回ほど遊びに行ったことがありましたが、今回初めて横須賀軍港めぐりのフェリーに乗ってきました。

www.tryangle-web.com

文字通り横須賀の軍港をぐるっと一周するクルージングで、ヴェルニー公園からは見えないところ (特に米軍基地のところ) を見ることができます。

写真を色々撮ったのでここにまとめてアップしました。

最初に見えるのは米軍の場所に停泊させてもらっている海自のおやしお型潜水艦。これはヴェルニー公園からも見えますね。

添乗員からの説明が無かったのですが、米軍側のところに停泊していた古びた船が目に付きました。これは宿泊艦だそうで、横須賀の地元の人にはお馴染みの風景だとか。

ご存じ、海自のヘリ空母いずも。やっぱりでかかった。

こちらは米海軍が利用しているところ。アーレイ・バーク級駆逐艦達がずらっと並んでいます。

空母ロナルド・レーガンも停泊していました。そしてその手前を隠すかのようにタイコンデロガ級巡洋艦達がずらっと並んでいました。添乗員の説明によると米空母は機密の塊なので余り近くには寄らせてくれないそうです。

空母ロナルド・レーガン。やや遠目ですが、それでもでかい！

何やら四角いブロックが並んでいたのですが、これは船の消磁のためのものだそうです。日本では横須賀にだけあるのだとか。遠目には大きなコンテナ船が見えますね。

掃海母艦うらが。この船も大きかったです。

最近就役した潜水救難艦のちよだです。確か墜落した F-35 の捜索に加わっていたはずですがもう帰ってきてたんですね。

手前は海洋観測艦のしょうなんです。そして奥にいる艦番号が消された船は退役した旧ちよだです。まさか新旧ちよだを同時に見られるとは思わなかったのでちょっと感激しました。 *1

ずらっと並んだ汎用護衛艦達。左からいかづち、あまぎり、ゆうぎりです。むらさめ型のいかづちが一回り大きいのが分かりますね。

新鋭のそうりゅう型潜水艦も見ることができました。舵がX型になっているのが特徴的です。

こんなのも見られました。日産の工場と、そこで生産された自動車を運ぶためのコンテナです。

手前からてるづき、むらさめ、たかなみ、補給艦のときわ、そしてイージス艦のきりしまです。

きりしまは錨に塗装をしている珍しい場面に遭遇しました。

こんな感じで陸側からは見ることができない様々な風景を見ることができました。軍艦好きなにはお勧めのクルージングなので、横須賀に寄った際にはぜひ。

*1:細かいところですが、旧ちよだには喫水線部に黒帯の水線塗装がされていましたが、新しいちよだにはありませんでした。なんでだろう？

とにかく簡単にEmacsのフォントを設定する方法

最近仕事場のマシンを新しくし、Mac をやめて Windows にしました。でもエディタはどの OS でも Emacs を使う人間なので、Windows にも Emacs をインストールし、その際に久々に Emacs の設定を色々いじったのですが、フォントについてもプログラミング向け等幅フォントを使うように設定したりしました。

Emacs の設定で良く鬼門とされるのがフォント設定です。Emacs は文字集合別にきめ細かくフォントを設定できるようになっているので、よく知らない人にはすごく難しいように思われています。でも、実は最近の Emacs ではとりあえず Ascii と日本語の文字集合に対してサクッとフォントを設定すればいいのならば実に簡単に設定できるようになっています。Emacs のフォント設定をぐぐっても小難しい方法ばかり出てきて、一番簡単な方法にたどり着かない人が多いのではないかと思い、メモっておくことにしました。

メニューから [Options] - [Set Default Font...] を選択します。

すると、次のようなフォント選択ダイアログが出てきます。ここで使いたいフォントを選択します。日本語と Ascii 文字で同じフォントが使われるようにするため、[欧文] に対して選択します。この例ではプログラミング向けフォントとして割と定番の Takaoゴシック を選んでいます。

選択すると Emacs のフォント設定が変わります。ここで再びメニューから [Options] - [Save Options] をクリックして設定を保存します。

以上です。

え、 .emacs ファイルに S 式をごちゃごちゃ書くんじゃないの？ と思われた方がいるかもしれません。実は Emacs はこのように GUI で結構設定変更ができるように進化しているのです。「Emacs って小難しい設定ファイルをいじくり回さないといけない古くさいエディタなんでしょ？」なんてと思っている方は認識を改めてください！

とは言え、この設定結果は結局 .emacs に書き込まれます。non ascii な文字が入っているフォントファミリーを選ぶ場合、.emacs には予めマジックコメントを入れてファイルエンコーディングを明記しておいた方がいいかもしれません (やっぱり .emacs 覗かないといけないじゃねーか、って突っ込まれそうですがw) 。

;;; -*- coding: utf-8 -*-

なお、「自分はあくまで .emacs をいじる派だ！」という方は次のように default-frame-alist 変数にフォントファミリーと文字の大きさをハイフンでつなげて設定すれば OK です。ざっくり設定ならばこれで十分です。

;; Initial frame settings
(setq default-frame-alist
      (append (list
              '(font . "Takaoゴシック-10"))
              default-frame-alist))

以上、Emacs のフォント設定を行う一番簡単な方法についてでした。

JavaFX 11に追加されたRobotクラスの紹介

このエントリは じゃばえふえっくす Advent Calendar 2018 の 3 日目のエントリとしてぶっ込みました。もうクリスマスは終わってますが、まだ空いていますし、 1 日目のエントリ で次のようなことを書いていたのをまだ放置していたので、それを拾うエントリとなります。

上記の Maven リポジトリをご覧になると分かりますが、Java FX 11 もリリースされました。リリースノートは次の通りです。

https://github.com/javafxports/openjdk-jfx/blob/jfx-11/doc-files/release-notes-11.md

まあ新機能は少ないのですが、 Spinner コントロールに改善が加えられていたり (詳しくは Yucchi_jp さんのこのブログエントリ を) 、新たに Robot というクラスが追加されています。この Robot クラスについては別のエントリで触れる予定です。

というわけで、JavaFX 11 になって新たに追加された Robot クラスについて触れたいと思います。

Robot クラスはプログラムから画面操作を行うために必要なメソッドが実装されたクラスです。あたかもロボットが画面操作を人の代わりに行うようなことを実現するというわけです。 AWT にも同様のクラス があります。一番のユースケースは GUI の自動テストを実装することで、それを実現するために次のような操作を実行するためのメソッドが実装されています。

• マウスの各種操作 (移動、クリック、スクロールホイール) を行う
  • マウスの現在位置を取得するためのメソッドもあります
• キーボードをタイプする
  • タイプとは別にプレスとリリースにもメソッドが用意されています
• 画面のスクリーンショットを撮る
• 指定した座標の色を取得する

モジュールは javafx.graphics に、パッケージは javafx.scene.robot に入っています。

画面を操作するのに必要なものは一通りそろっているので、これで定形作業を肩代わりするプログラムを作るのに使えますね。ゲームの周回操作とかにもいいかも。

実はこのクラス、昔からあったのですが internal なクラスとなっていました。このクラスを使って自動テストフレームワークを作っていたライブラリが多く、Java のモジュール化に伴い「外に出してほしい」というリクエストが非常に多かったのですが、11 になって晴れて表に出てきてくれました。

ところで以前、自分の書いた次のエントリで、JavaFX で xeyes のクローンを作った話をしました。

aoe-tk.hatenablog.com

そこでこんなことを書いていました。

• 以前は Mac 上で Swing の EDT を実行すると HeadlessException が飛ぶ問題があり、仕方なく Swing を土台として作っていたのですが、現在はこの問題は解消されているので、JavaFX を土台としたものに変更しています。
  • 唯一、グローバルなマウスカーソルのアドレスを取得するのに AWT に頼っていますが、JavaFX 11 で待望の Robot クラスが追加されるので、11 になれば "Pure JavaFX" なアプリケーションにできる見込みです。

てなわけで、早速この Robot を使って "Pure JavaFX" なアプリにしちゃいましょう。

まずは 10 以前のマウスポジションを取得するコード。

private void updateMousePosition() {
    SwingUtilities.invokeLater(() -> {
        final Point pointerLocation = MouseInfo.getPointerInfo().getLocation();
        Platform.runLater(() -> updateEye(pointerLocation.x, pointerLocation.y));
    });
}

Swing の EDT と JavaFX のアプリケーションスレッドを行ったり来たりして見通しが悪いですね。これを 11 の Robot クラスを使うように変更します。使い方は簡単で、普通にインスタンスを取得すればいいです。Controller の初期化処理で取得しておきます。

private Robot robot;

@Override
public void initialize(URL location, ResourceBundle resources) {
    robot = new Robot();
    // (以下略)

後はこのインスタンスを使ってマウスカーソルのグローバルポジションを取得するだけです。 updateMousePosition() メソッドの内容が次のように変わりました。

private void updateMousePosition() {
    updateEye(robot.getMouseX(), robot.getMouseY());
}

はい、これで複数スレッドを行き来する必要がなくなりました。しかも java.desktop モジュールへの依存も無くなるので、配布 JRE のイメージサイズも小さくすることができますね。 *1

少し付け加えると、 Robot から取得するマウス座標の値は AWT と違って double 型になります。なので updateEye() メソッドの引数の型を変える必要がありました。

というわけで JavaFX 11 の新機能である Robot クラスの紹介でした。さすがに今年の Advent Calendar への投稿はこれで終わりかな。皆様良いお年を。

*1:AWT、Java2D、Swing を全部雑に java.desktop モジュールにぶち込んでるんですよね...。お陰でサーバーサイドアプリケーションでも JavaBeans 関連の API を使うだけなのにこのモジュールへの依存が必要がだったり。

IntelliJ形式のJavaFXプロジェクトをJavaFX 11にアップグレードしたら色々ハマった話

このエントリは じゃばえふえっくす Advent Calendar 2018 の 2 日目のエントリとして作成しました。場所がたくさん空いてるので、みんなも気軽に参加してねー。

さて今回は 1 日目 として書いた記事で次の様なことを書いていたのですが、その内容について触れたいと思います。

Java 11 から JavaFX は Java の 1 ライブラリになりましたが、Maven のリポジトリにも "org.openjfx" というグループ名でアーティファクトが登録されました。

https://mvnrepository.com/artifact/org.openjfx

モジュール別にアーティファクトが登録されています (実はこれを利用する際にちょっとした罠にはまったのですが、それは別のエントリで) 。

IntelliJ プロジェクトからこの Maven リポジトリを利用しようとした際に罠にはまりました。まあ、純粋な IntelliJ 形式のプロジェクトで開発している人は少ないと思うのですが、OpenJFX の Maven リポジトリの解説にもなるので、独立したエントリとしました。

IntelliJ プロジェクトを JDK11 にアップする

まず、既存の JDK10 を利用するプロジェクトとして作成した IntelliJ プロジェクトを JDK11 にアップしてみます。

JDK11 には JavaFX は入っていません。当然このように JavaFX 関連の API が赤くなってしまいます。悲しい。

IntelliJ から Maven を利用したライブラリ設定を行う

嘆いていても仕方ないので、JavaFX のライブラリ設定を行うことにします。IntelliJ には依存するライブラリを Maven リポジトリから取ってくる機能があるので、これを利用して MavenCentral に登録された OpenJFX のライブラリを取ってくることにします。

次のように MavenCentral からアーティファクトを検索してくれます。

これでエディタから赤色が無くなる...と期待したのですが無くなりませんでした！ Maven からダウンロードした OpenJFX の JAR の中身を見ると MANIFEST ファイルしか置いていないのです！

Maven リポジトリへの OpenJFX JAR の配置について

どうしてこうなったのかは Maven のリポジトリの内容を見て分かりました。OpenJFX は OS 別のネイティブ実装を含むため、OS 別に JAR ファイルが用意されていたのです。例えば javafx-controls モジュールのリポジトリ を覗いてみると次のようになっています。

Windows、Mac、Linux 向けに artifact classifier を使って JAR が分けられています。色々調べましたが、IntelliJ では artifact classifier で細分化された JAR を取ってくることができませんでした。しくしく。

普通に OpenJFX SDK をダウンロードして利用する

仕方が無いので古き良きライブラリ直接ダウンロードという方法を採ることにします。なお、今回対象としたプロジェクトは一応 GitHub に公開しており、また自分自身 Windows と Mac の両方で使うようにしていたので、環境依存的な設定が入ることを避けるようにします。

ダウンロードは前回のエントリで紹介した かっこいい Web サイト からできます。実行する環境に利用する OS のものを選んでダウンロードして解凍します。なお、IntelliJ はホームディレクトリ以下のパス設定は自身の環境変数を使って設定に記述するので、どの OS でもホームディレクトリの下のディレクトリに解凍すると環境依存が無くなるのでお勧めです。

ダウンロード、解凍が終わったら IntelliJ からこれを利用するように設定します。プロジェクト設定の [Libraries] から普通に [Java] を選んで、先ほどダウンロードした OpenJFX SKD ディレクトリの lib サブディレクトリを選択します。

これでエディタから赤色が消えました。が、これで終わりではありませんでした。OpenJFX SKD の lib ディレクトリの下にはソースコードをアーカイブした src.zip が置かれています。そのままでは IntelliJ がこれもコンパイル対象にしようとして、ビルド時にエラーになってしまいました...。

そこで、lib ディレクトリの下にある src.zip ファイルを別の場所に移動し、さらに IntelliJ のライブラリ設定からソース参照の設定 (次の図で赤色で囲っている部分) を除去します。

これで無事にビルドもできるようになりました。やれやれ。

忘れてはいけない実行時の注意点

さて、実際に実行する際にも注意点があります。これは IntelliJ 固有の話では無く、Java 11 以降の JavaFX アプリケーション実行時の共通した注意点です。

詳細については id:torutk さんの次のエントリで解説されていますが、Main クラスが javafx.application.Application を継承している場合、実行時に --add-modules による JavaFX モジュールの指定が必須です。

torutk.hatenablog.jp

また、アプリケーション自体をモジュール化している場合は実行時にモジュールパスの指定も必要になります。次のように実行設定を編集して、必要なパスの設定を忘れないでください。

以上です。えっと結論としては素直に Maven か Gradle で開発プロジェクトを作りましょう、ですw 今はどの IDE もこれらのツールで作ったプロジェクトならそのまま取り込めるので *1 、一見面倒そうに見えても後がすごく楽です。

*1:NetBeans の最新版だけ Gradle プラグインの対応が遅れていたかも...

2018年のJavaFXに関するできごと

このエントリは じゃばえふえっくす Advent Calendar 2018 の 1 日目のエントリとして作成しました。今年は無いかと思っていたのですが、@Yucchi_jp さんが立ててくださったので、まずは 1 日目を埋めることにしました。

とりあえず初日分と言うことで 2018 年に JavaFX に関して起こった出来事をまとめます。大きな出来事はこんなところでしょうか (最後だけは個人的に注目していた小ネタかな) 。今年は激動の 1 年でしたね。

1. Oracle による Client Roadmap の発表とそれに伴う JavaFX の JDK からの分離
2. OpenJFX コミュニティ環境の整備が進む
3. JavaFX 11 のリリース
4. OpenJDK ディストリビュータによる JavaFX サポート表明が相次ぐ
5. 生きていた JSR-377

以降、順番にその詳細について記載していきます。

Oracle による Client Roadmap の発表とそれに伴う JavaFX の JDK からの分離

はい、2018 年の前半に出た衝撃の発表です。詳細については私自身が 2 回に分けてポエムを書いたので、そちらをご覧になってください。

aoe-tk.hatenablog.com

aoe-tk.hatenablog.com

これにより、Oracle JDK からも JavaFX は分離され、Java 標準の GUI ツールキットとしての地位は失いました。しかしながら、結果として OpenJFX プロジェクトはより独立して自由に動けるようになりました。

OpenJFX コミュニティ環境の整備が進む

OpenJDK と OpenJFX のつながりが小さくなったので、OpenJFX プロジェクトはより自由に動けるようになりました。これまではどうしても Oracle の動向に縛られることが多かったのですが、JavaFX をビジネスの中心に据えている Gluon 社主導でより外部の人が自由に参加できるような環境が急速に整えられました。

まず、リポジトリのクローンが GitHub に作成されました。

github.com

プルリクエストを出すためには OCA へのサインが必要ですが、Issue の報告などがこれまでよりもずっとやりやすくなりました。何しろ OpenJDK の JIRA は誰もが参加できるものでは無かったですから (ただし、メインのバグトラッカは依然としてここです) 。

そしてかっこいい Web サイトもできあがりました。

https://openjfx.io/

この Web サイトからドキュメントの閲覧やライブラリのダウンロード、GitHub リポジトリへのジャンプなどができます。今後は JavaFX の動向をチェックする際はこの Web サイトを拠点にするといいでしょう。

Java 11 から JavaFX は Java の 1 ライブラリになりましたが、Maven のリポジトリにも "org.openjfx" というグループ名でアーティファクトが登録されました。

https://mvnrepository.com/artifact/org.openjfx

モジュール別にアーティファクトが登録されています (実はこれを利用する際にちょっとした罠にはまったのですが、それは別のエントリで) 。Maven や Gradle 用のプラグインも用意され、それらと併用することで簡単にOpenJFX のライブラリが利用できるようになります。

このように Gluon が旗振り役となり、急速に環境が整えられました。「主体が Oracle から Gluon に変わっただけ？」みたいな言われ方をすることもありますが、やる気があるところが引っ張るようになっただけでも大きいと思います。

JavaFX 11 のリリース

上記の Maven リポジトリをご覧になると分かりますが、Java FX 11 もリリースされました。リリースノートは次の通りです。

https://github.com/javafxports/openjdk-jfx/blob/jfx-11/doc-files/release-notes-11.md

まあ新機能は少ないのですが、 Spinner コントロールに改善が加えられていたり (詳しくは Yucchi_jp さんのこのブログエントリ を) 、新たに Robot というクラスが追加されています。この Robot クラスについては別のエントリで触れる予定です。

OpenJDK ディストリビュータによる JavaFX サポート表明が相次ぐ

Oracle JDK の有償化に伴い、Linux 黎明期を彷彿とさせるような OpenJDK ディストリビューションの戦国時代に突入した感のある Java 界ですが、次の OpenJDK ディストリビューションが JavaFX の同梱を表明しました。

• Amazon Corretto
  • https://stackoverflow.com/questions/53375201/is-javafx-supported-by-corretto
• Zulu
  • https://www.azul.com/zulu-gets-graphical-with-openjfx/

Amazon の Correto については、AWS が提供しているサービスの中に JavaFX を利用したツール (AWS Schema Conversion Tool が JavaFX で作られています) が存在することが一番大きな理由でしょうね。

Zulu については Azul 社の顧客に JavaFX を利用しているところが多かったのが理由だそうです。CTO が JavaFX と関わりの深かった Simon Ritter 氏であることも大きかったでしょうね。

生きていた JSR-377

最後は割と小ネタです。以前、自分のブログでも取り上げたことのある JSR-377 がまだ生きていましたw Java のデスクトップ、組み込み GUI アプリケーションのフレームワークを作ろうというもので、JavaFX に限ったものではないですが、ほぼ JavaFX をターゲットとしたものです。

aoe-tk.hatenablog.com

この JSR 引っ張っていた方が Oracle の発表を受けて こんなツイート をしていたので、てっきりもうやめるのかと思いましたが、GitHub を見ると、再び更新が行われるようになっています。

ただこの JSR、Renewal Ballot が 3 回も行われており、 3 度目 では Oracle から「もう次はないぞ」と言われ、JetBrains からは「もっと真剣に取り組めよ」といった旨のコメントをチクリと言われる始末ですが。ですが、とても価値のあるものだと思っているので個人的には進めてほしいと思っています。

Pixel 3 XLを購入しました

これまで 10 年以上スマートフォンとしては iPhone を使っていました。日本に最初に上陸したバージョンである 3G からです。3G→4→5c→7 と使い続けていたのですが、この度遂に iPhone やめて Google の純正ブランドである Pixel 3 XL に機種変しちゃいました。

長年連れ添った iPhone に別れを告げて、Android の参照実装機とも言える Pixel に乗り換えたのは次のような理由です。

• 単純に iPhone というか Apple ブランド全般に飽きたw
  • 流石に 10 年以上も使っていると飽きてきました
  • Mac も飽きてきて、新しい持ち運び用のノートには Windows 機を選びましたし、仕事場のマシンも新しくするときは Windows にしようと考えています
• iPhone XS シリーズがクソ高い
  • Pixel も結構高いですが、それでも iPhone XSシリーズよりは安いです

無印か XL かはちょっと迷ったのですが、実機を触ってみて、XL でも辛うじて片手でも扱えるぎりぎりの大きさに絞られており、個人的にもファブレットを使いたかった（スマートフォンとタブレットを統一したかった）ので、XL を選択しました。

良かった点

• 最近のスマートフォン界で流行のナローベゼルのお陰で、片手で使えるファブレットになっている
  • ちょっと重いですがほぼ片手で操作できます
  • 大きい画面がほしいときは安物の Android タブレットを使っていたのですが、これでさよならできそうです
• 最新の Android の機能が使える
  • 自分が今まで使ったことがある Android 機は Huawei のタブレットだったのですが、メーカーが色々手を入れまくっていたので古い Android のままでした
  • こちらは Google 純正機なので最新のアップデートがやってくることが保証されます
  • 仕事場でも GSuite を使い、家でも GMail を使っているし、ブラウザは Chrome だしと、何だかんだで Google のサービスへの依存度が高いので、シームレスにそれらのサービスへアクセスできる Android の方が iOS よりも有利でした
  • 一番面白かったのが Google アシスタントによる画像検索機能で、次のように写真に写っている動植物や物品が何であるかを調べてくれたりします
• カメラが暗所に強い
  • これはメディアでもよく話題にされていたので知ってる人も多いと思いますが、Google の AI 技術による補正で、暗いところでも中々くっきりとした写真を撮ってくれます
• iPhone からの移行が楽だった
  • 移行はちょっと大変になるかな？ と思ったのですが、セットアップ時に次のようにケーブルでつなぐだけで iPhone 内の住所力や MMS メッセージ、写真、音楽などのデータをまるっと移してくれました！
  • ソフトウェアについても Play ストアに同じものがあるときはそれをダウンロードできるようにリストアップしてくれます
  • 壁紙設定まで移行されたのには驚きました
  • なお、このセットアップを行うに当たっては注意点があるので、それは後述します
• 背面指紋認証は意外と使い易い
  • 実は iPhone が顔認証のみになってしまったのも Pixel に乗り換える要因だったりします
  • 片手で持ったときに丁度人差し指で触れやすいポジションにあって、iPhone のそれよりも使い易いと感じました
  • iPhone の指紋認証は指の状態によってはうまく働かないことがありましたが、Pixel はまず大丈夫です

イマイチな点

• Google Pay はまだまだ発展途上
  • 現状 Suica のようなプリペイド系のカードしか純正の Google Pay ソフトでは扱えないものと思った方がいいです
    • JCB のクレジットカードだけは非接触決済に使えると出ましたが、そもそも対応している店舗を見かけない...
    • コンビニでも「対応している」と書いていても小さな字で「一部の店舗です」との注意書きがあり、実際使えないw
  • クレジットカードは登録から実際に使えるようになるまで少し時間が掛かります
    • 確か Apple Pay は即座に使えるようになったはず
    • お陰で Suica にすぐにチャージができずに困り、結局モバイル Suica アプリを別途インストールしました
      • 各種メニューページに入ると、いきなりガラケー向け UI が表示されるアレですw
  • そのこともあってか、最初からおサイフケータイアプリが別途インストールされているので、QUICPay とか iD とかを使いたい場合はこちらを使いましょう
    • これはキャリア側 (自分は SoftBank で契約しました) が入れているんだと思います
• 自分の手に馴染ませるには色々設定が必要
  • デフォルトの動きでは自分に合わないところが結構あり、設定画面を隅々まで探検して色々設定を変える必要がありました
  • 逆に言うと細かくカスタマイズできるので、うまく設定すればものすごく馴染みます
    • そういう意味でも Android はやっぱりコンピューターに詳しい人向けの OS だと思います (詳しくない人には間違いなく iPhone を奨めますね)
• メッセージアプリはいわゆるガラケーメール向きではない
  • 登録した連絡先から送信する場合は電話番号の選択のみで、メールアドレスの場合は直打ちが必要です
  • SoftBank が別途専用アプリを入れてくれているのでそれを使いましょう
• そこまで爆速ではない
  • これはメディアでも言われていましたが、最高クラスのチップが積まれているわけではないので、とにかくスピードを求める人には向かないかもです
  • Geekbench でスコアを取ってみてたところ (左が iPhone7、右が Pixel3XL) 、iPhone7 と比べてシングルコアでは負けており、マルチコアの総合性能では勝っているという結果でした
  • まあでも十分速いのも確かで、ストレスは全く感じません
    • 具体的な例を挙げるとアズレンで弾幕が激しく飛び交う画面でもコマ落ちせずスムーズに動く

注意点

最初のセットアップで、iPhone からの移行はケーブルでつなぐだけで OK と上に書きましたが、実際には iPhone 側で事前に次のような準備が必要です (この点は紙のセットアップガイドには書いておらず、Web を見る必要があるんだな、これが) 。

• バックアップの暗号化を解除する
  • これを解除しないとほとんどのデータを転送できません
  • デフォルトで暗号化設定になっているので、ほとんどの人は解除が必要です
• iMessage、FaceTime を「使用しない」という設定に変更する
  • これをしないと MMS が iMessage に紐づけられたままになり、MMS が全部そっちに転送されてしまいます