UWP アプリ開発に TypeScript + React を導入することの検討 (Node.MSBuild.Npm の紹介)

こんにちは！ 株式会社はてなにて、主に 「はてなブックマーク」 Android アプリの開発を行っている id:nobuoka です。 この記事は、「はてなデベロッパーアドベントカレンダー 2015」 の 14 日目の記事です。 昨日は id:hatz48 による 「TypeScript だけで Web アプリケーションを作る」 でした。

今日は、昨日に引き続き TypeScript の話題となります。 主にクライアントサイド (特に UWP アプリ) での TypeScript と React の組み合わせについて検討したいと思います。

(この記事の内容は、UWP アプリへの導入を目的としたときの TypeScript + React の環境の一例であり、ベストプラクティスではありません。 より良い方法などがありましたら教えてくださいませ。)

UWP アプリと TypeScript + React

UWP アプリとは 「Universal Windows Platform アプリ」 のことで、Windows 10 で導入された Windows プラットフォーム向けのアプリの一種です。 Windows 8 で導入された Windows ストアアプリや Windows Phone 8.1 向けの Windows Phone アプリの進化版という感じですね。

• 参考 : ユニバーサル Windows プラットフォーム (UWP) アプリとは - Windows app development

現在のところ株式会社はてなでは UWP アプリの開発は行っていませんが、Windows ストアアプリ 「はてなブックマーク」 を 2012 年にリリースしています。 *1

JS を快適に書く : TypeScript の導入

Windows ストアアプリや Windows Phone アプリと同様に、UWP アプリも JS + HTML + CSS で開発することができます。 Windows ストアアプリ 「はてなブックマーク」 も JS + HTML + CSS の組み合わせで書かれています。

JS は Web 開発者にとって馴染みのある言語ですので、アプリ開発に取り掛かりやすいというのは利点ですね。 一方で、素の JS には変数に型がないためリファクタリングなどがしづらいという難があります *2。 それを解決するため、いわゆる Alt JS を使用することが検討されると思いますが、UWP アプリ開発で使用するのであればまず TypeScript が候補にあがるでしょう。 UWP アプリ開発に使用される統合開発環境 (IDE) Visual Studio 2015 では標準で TypeScript がサポートされているため、UWP アプリのプロジェクトに容易に TypeScript を導入できます。 Microsoft が TypeScript のリリースを行っているあたりも TypeScript 導入にあたっての安心感につながっています。 よほど TypeScript と比べて有利な言語があればそれを使うとよいかもしれませんが、私自身は現状では TypeScript を使うのが一番だと考えています。

実際に 「はてなブックマーク」 Windows ストアアプリ *3 でも TypeScript を導入して開発しており、素の JS を使うのに比べて楽に開発を進めることができています。

View の処理を快適にするために : React の導入を検討

TypeScript を導入することで JS の変数に型付けが行われて IDE のサポートを受けやすくなり、JS の世界については快適になります。 しかしながら TypeScript を導入するだけでは view 操作 (「何らかのデータを画面に表示する」 という処理) の部分はあまり改善されません。 UWP アプリ開発のための JS のライブラリとして WinJS というものがあり、画面にデータを表示するためのテンプレート・バインディングの機能が提供されているのですが、これがなかなか素朴な仕様で、型の恩恵を受けづらいためです。

「はてなブックマーク」 Windows ストアアプリの開発でも、やはり View を扱う部分がきれいに書けず、よりよい方法を取り入れたいと考えています。

そこで、何らかのライブラリを導入することを検討しました。 候補としては、以下のものを考えました。 いずれも JS 界隈で話題になりやすいライブラリですね。

• React
  • JSX 構文を使って JS 側に HTML 構造を記述する。
  • TypeScript との相性が良い。
  • アプリ開発をするうえで扱いやすそう。
• Polymer
  • 標準の Web Components を意識して開発されており、将来性はあるように見える。
  • 独自の HTML タグを定義して HTML 側で使用できるので、(React と比べて) サーバーサイドで HTML を生成するような場面で扱いやすそう。
  • TypeScript との相性は不明。
• AngularJS
  • 現在 Angular 2 が開発されており、バージョン 1 と 2 の互換性がなくなりそうなことから、現在 Angular を導入するのはリスキーだと考えられる。
  • View 部分を手軽に扱うためだけに導入するには規模が大きいように感じる。

全部試してみてどれが良いか評価できればよかったのですが、まずは TypeScript と相性がよく、アプリ開発で扱いやすそうな React だけを試してみました。

TypeScript と React (JSX) の相性

React では JSX 構文 (JSX syntax) を用いて JS の中に DOM 構造を記述します。 そして、TypeScript では JSX 構文がサポートされています。

• 参考 : JSX · Microsoft/TypeScript Wiki · GitHub

JSX 構文での型チェックなどもサポートされているので、React を使うことで View の処理の部分でも IDE のサポートが受けられやすくなります。 プラグインなどではなく　TypeScript の処理系に JSX 構文の処理が組み込まれているので、TypeScript と JSX の相性は非常に良いといえます。

TypeScript + React の環境

さて、ここからは実際に TypeScript + React を UWP アプリ開発で用いるための環境について考えます。 UWP アプリは、ローカルファイル上の HTML + JS + CSS をブラウザ上に表示するのと似たような仕組みで動きますので、まずはローカルファイルシステム上でビルドしてブラウザ上に表示できるようにする環境を考えます。

TypeScript + React の環境を整えるためには、npm を使用するのが簡単でしょう。

• TypeScript のビルド : npm の typescript モジュール
• React のソースコード : npm の react モジュール
• React の型定義 : npm の dtsm モジュールを使用して DefinitelyTyped から react.d.ts を取得

React を使うにあたっては CommonJS モジュールシステムを使うことが推奨されていますので、TypeScript を記述する際はモジュール形式で記述し、CommonJS 形式でコンパイルするようにしました。

We recommend using React with a CommonJS module system like browserify or webpack. Use the react and react-dom npm packages.

Getting Started | React

コンパイルした JS をブラウザ上で実行するために、また、UWP アプリの JS ファイルとして使用するためには、webpack や Browerify などを使用してパックしてやる必要があります。 今回は私は webpack を使用してみました。 (webpack を選択した理由は特にありません。 同僚からは、「webpack は大艦巨砲という感じなので、Browserify で事足りるなら Browserify で良さそう」 という意見をもらいました。)

これらのツールを使用して TypeScript + React のビルドを行うようにしたサンプルプロジェクトを GitHub で公開しています。 (ここではビルドシステムとして Gradle を使用しています。)

• nobuoka/typescript-react-sample-project · GitHub

UWP アプリのプロジェクトへの TypeScript + React 開発環境の導入 : Node.MSBuild.Npm の紹介

さて、最後に UWP アプリのプロジェクトに上述の環境を構築することを考えましょう。

上で紹介した Gradle を使ったプロジェクトでは、Gradle から Node.js と npm を使用するために Gradle Plugin for Node を使用しています。 このプラグインは、ビルド時に Node.js と npm をダウンロードしてきて、セットアップしてくれるというものです。

一般的な UWP アプリのプロジェクトのビルドシステムである MSBuild でも同様の機能を使えれば、上で紹介したプロジェクトの Gradle 部分を MSBuild に置き換えることで、UWP アプリのプロジェクトに TypeScript + React の開発環境を導入できるでしょう。

MSBuild に似たような機能を提供する NuGet パッケージがないかどうか探したのですが、NuGet パッケージの中に node.exe や npm の各種ファイルを含むようなものは見つけられたものの、ビルド時にセットアップするタイプのものはなさそうでした *4。 そこで、そのような機能を持つ Node.MSBuild.Npm という NuGet パッケージを作成し、公開しました。

www.nuget.org

使用方法は簡単です。 まず、Visual Studio で NuGet パッケージマネージャを起動して 「Node.MSBuild.Npm」 を検索してインストールしてください。 あとは package.json を記述して、ビルド時に実行したい処理を build スクリプトとして package.json に定義するだけです。

例えば、TypeScript + React 環境を構築してビルド時に TypeScript のビルドや webpack による変換を実行するには、以下のように記述します。

{
  "name": "my-app",
  "private": true,
  "devDependencies": {
    "react": "^0.13.3",
    "webpack": "^1.12.9",
    "typescript": "^1.7.3",
    "dtsm": "^0.13.0"
  },
  "scripts": {
    "build": "dtsm install & tsc -p ts --outDir built\\typescript & webpack"
  },
  // 一部略
}

ビルド時に実行したい処理の記述方法に関しては、もう少し扱いやすいようにできると良いなぁと思っています。

ぜひご利用ください。

TypeScript + React 環境に対する評価

まだ軽く試している段階ですが、現時点での評価は以下のような感じで、個人的には他のライブラリ (Polymer や AngularJS) を試すまでもなく UWP アプリ開発に導入して良さそうという気がしています。

• (良い) TypeScript が JSX をサポートしているので、JSX 構文内でも IDE のサポートを受けやすくて記述しやすい。
  • これは本当に便利です。
• (良い) React 自体は大きなフレームワークではなく、導入がしやすい。
  • 画面内の一部の DOM 構造の構築のみに React を使用するなど。
• (良い) React により View のコンポーネント化ができ、開発しやすくなる。
• (良い) WinJS 側で React 用のアダプタが用意されており、WinJS と一緒に使いやすい。
• (微妙) TypeScript + React の環境を作るのが少し面倒。 慣れれば問題はなさそう。
  • TypeScript をモジュールとして記述するかどうかや、モジュールとして記述する場合には browserify を使うか webpack を使うか、といったことで悩みそうです。 (React は CommonJS のモジュールシステムを使用することを推奨している。)
• (不明、問題なさそう) 将来にわたってメンテナンスしやすいかどうか。
  • Facebook によりリリースされているので、ライブラリのメンテナンスの心配はそれほどなさそう。
  • 使い方次第ではあるが、React を使いながら徐々に別のライブラリに移行するというのも難しくはなさそう。

「はてなブックマーク」 の Windows ストアアプリを更新する際には、こういった技術を導入することでより開発しやすく、メンテナンスしやすいコードを書けるようになりそうです。 *5

おわりに

はてなでは、より開発しやすく、よりメンテナンスしやすいコードを記述していこうとするエンジニアを募集しています！

hatenacorp.jp

明日の 「はてなデベロッパーアドベントカレンダー 2015」 の担当は id:motemen です。 お楽しみに！

*1:以下 UWP アプリ向けの話をしますが、Windows ストアアプリでも基本的に同様です。

*2:UWP アプリに限らず

*3:UWP アプリではないですが、大体一緒です。

*4:NuGet パッケージ内に node.exe や npm を含むようなタイプでも悪くはないのですが、exe ファイルを複数プロジェクトで共有したかったり、プロジェクトの階層が深い場所にあると npm のパッケージのインストールに失敗するという問題があったりするので、ビルド時にホームディレクトリにインストールしてくれるタイプのものが欲しいのでした。

*5:この文は 「はてなブックマーク」 Windows ストアアプリの大幅な更新を予告するものではありません。

Windows 10 へのアップグレード時に 「C1900101-2000C」 エラーが発生して失敗する問題を回避した

Windows 10 がリリースされて数日が経ちましたね。 皆様ぼちぼちアップグレードされているでしょうか。

アップグレード時に問題発生

私の自宅 PC (自作機) にも先日 Windows 10 へのアップグレードが降ってきたのでアップグレードしてみようとしたのですが、何度やっても下のようにエラーが発生してしまってうまくアップグレードできませんでした。

0xC1900101 - 0x2000C
APPLY_IMAGE 操作中にエラーが発生したため、インストールは SAFE_OS フェーズで失敗しました

現象としては、Windows 10 へのアップグレードを開始した後、ファイルのコピー中に PC がシャットダウンしてしまう、というものです。 その後 PC を起動すると、「以前の Windows に復元しています」 と表示されて復元処理が行われ、元の Windows (Windows 8.1) が起動します。 (アップグレードに失敗するのは困りますが、失敗してもちゃんと復元してくれるあたりは安心です。)

解決

何度か試してうまくいかなかったので諦めてクリーンインストールしようとしかけたところで、次のような情報を見つけました。

Solved: I removed the "unallocated" HDD, installed it into a different computer, with no other
HDD, tried one of the DVDs I made, IT INSTALLED!!

After this I moved the HDD back to the other computer, and all works fine. Even upgraded to 9860.

http://answers.microsoft.com/en-us/insider/forum/insider_wintp-insider_install/getting-error-code-0xc1900101-0x2000c-when/fb688fd3-f6cb-463a-bbad-155459877c8f

Windows に割り当てられていない (?) HDD を外してアップグレードを試したところ成功したということのようです。 うちのマシンにも SSD と HDD が接続されていて HDD の方は単なるストレージとしてしか使っていないので、試しに HDD を外してアップグレードを試したところ成功しました！

今度こそアップグレード成功しそう pic.twitter.com/UrfmAo1tQ5

— Yu Nobuoka (@nobuoka) August 2, 2015

複数 HDD/SSD が接続されていると常に失敗するのかどうかはわかりませんが、失敗することもあるようなので、もし同様の状況で同様の問題が発生してしまった場合は Windows のインストール先 HDD/SSD 以外を外してみるというのをお試しください。

それでは良き Windows 10 ライフを！

別の解決方法

• windows10 インストールできない c1900101-4000D : 新しく admin 権限のあるアカウントを作成して、upgrade したら成功した、とのこと。
  • 【c1900101-4000D】windows10へのアップグレードができない - マイクロソフト コミュニティ

Windows Runtime Support Lib for JavaScript version 0.1.0 をリリースしました

Windows Runtime Support Lib for JavaScript (WinRSJS) の最初のバージョンである version 0.1.0 をリリースしました。

• nobuoka/WindowsRuntimeSupportLibForJS · GitHub

どんなライブラリか

Windows ストアアプリ、および Windows Phone アプリを JS で開発する際に使用できる便利な機能を詰め込んだライブラリです。 C# で書かれた Windows Runtime コンポーネントと JavaScript (TypeScript) で書かれた便利クラス群、およびそれらの API の TypeScript 型定義ファイル (.d.ts ファイル) で構成されています。

JS からの直接の生成方法がわからない Windows Runtime 型のオブジェクトの生成を行う機能や Google Analytics のクライアントが含まれていたりします。

バージョン 0.1.0 のターゲットプラットフォームは Windows 8.1 と Windows Phone 8.1 です。

セットアップ方法

バージョン 0.1.0 では NuGet パッケージの配布は行っていませんので、直接 ZIP ファイルをダウンロードして展開して、ライブラリを使用するソリューションのディレクトリ中に展開して使用してください。

1. 下記のダウンロードページから ZIP ファイルをダウンロードする。
   • Release Version 0.1.0 · nobuoka/WindowsRuntimeSupportLibForJS · GitHub
2. ダウンロードした ZIP ファイルを展開し、ソリューションのディレクトリに展開する。 (ソリューションの中の libs ディレクトリなどに置く。 配置場所はどこでも良い。)
3. ライブラリを使用するプロジェクトの References に、ライブラリの WinRS.winmd ファイルを追加する。
4. ライブラリを使用するプロジェクトの HTML ファイル (default.html ファイルなど) に 「/js/winrsjs.js」 ファイルの読み込みを追加する。
   • <script src="/js/winrsjs.js"></script> という感じ。
   • この JS ファイルはライブラリ中に PRIResource として含まれているので、別途用意する必要はない。
5. TypeScript から使用する場合は、ライブラリ中の winrsjs.d.ts ファイルを reference path に追加する。

これでセットアップは完了です。 後は JavaScript あるいは TypeScript のコードを書いて実際に使用していきます。

将来的には NuGet パッケージも配布したいと思います。

ライブラリに含まれる機能

Windows Runtime 型のオブジェクトの生成機能

Windows Runtime 型のオブジェクトの一部は、JS から直接生成することが困難です。 例えば IMap 型のオブジェクトを生成することは、Windows Runtime API を使用するだけではできません *1。 そのようなオブジェクトを生成する機能があります。

IMap<K, V> オブジェクト

WinRSJS.Collections.createMap(keyType: string, valType: string) メソッドにより、IMap<K, V> オブジェクトを生成できます。 Key および Value の型は、文字列によって C# での型を指定する必要があります。

//  IMap<string, string> オブジェクトを生成。 (C# において String 型は System.String。)
var map = <Windows.Foundation.Collections.IMap<string, string>>WinRSJS.Collections.createMap("System.String", "System.String");

Guid オブジェクト

WinRSJS.Guid.newGuid() メソッドにより、Guid 型の値を生成できます。 Windows Runtime の Guid 型は JS では string 型で現されるので、実際に JS で扱う際は文字列となります。

UUID (GUID) を JS で生成したい場合に使用できます。

// 文字列の形式は "12345678-abcd-abcd-abcd-123456789abc" というハイフン区切りの 16 進数表記。
var guid: string = WinRSJS.Guid.newGuid();

このメソッドは、Guid.NewGuid() メソッドのラッパーです。

HResult に関する機能

Windows Runtime API 内部でエラーが発生して HResult 値が返された場合、JS 側には例外として WinRTError オブジェクトが届きます。 そして、WinRTError#number プロパティを見ることで HResult 値を得ることができます。

一般的に、HResult 値は 16 進数文字列で表示されますが、WinRTError#number プロパティには値を符号付 32 ビット整数値として解釈された数値が入っています。 ユーザーに表示する場合 (HResult 値をユーザーに表示するのがいいかどうかは謎ですが)、HResult 値を符号無 32 ビット整数値として解釈して 16 進数文字列に変換して表示すべきです。 そのための関数がライブラリに含まれています。

if (err instanceof WinRTError) {
    var hresultHexStr = WinRSJS.HResults.convertHResultStyleFromInt32To8DigitHexStr(err.number);
    // 必要に応じて hresultHexStr をユーザーに表示。
}

HTTP 通信に関する機能

application/x-www-form-urlencoded 形式の POST リクエストを投げるための機能も含まれています。 WinRSJS.HttpUtils.postWwwFormUrlEncodedContent(uriStr: string, data: { [key: string]: string; }) メソッドです。

Google Analytics のクライアント

Google Analytics のクライアントとして WinRSJS.GoogleAnalytics.GAClient クラスが含まれています。

var gaClient = new WinRSJS.GoogleAnalytics.GAClient("tracking_id", "app_name", "app_version", "client_id");
// Send Appview.
gaClient.sendAppview("screen_name");
// Send Event.
gaClient.sendEvent("category", "action", "label");

是非ご利用ください

最近 MADOSMA がリリースされましたしもうすぐ Windows 10 がリリースされて Windows ストアアプリも便利になりますし、この機会に Windows / Windows Phone アプリを開発してみようという方は是非ご利用ください！

フィードバック等頂けると嬉しいです。

*1:いろいろ調べた結果できないという結論に達しましたが、もしかしたら実はできるのかもしれません。

WinJS 4.0 では HTML コントロールにスタイルを当てるためにクラスを明示的に指定する必要がある

WinJS 4.0 がリリースされましたね！！ めでたい！

• WinJS 4.0 Released

2015 年 6 月 14 日時点では、Try WinJS のダウンロードページのリンク先がバージョン 4.0.0 になっていますが、最新バージョンは 4.0.1 です。 (Windows Phone 10 におけるバグの修正がされたようです。)

• WinJS 4.0.1 (ZIP)

私も Windows ストアアプリ開発で使用している WinJS のバージョンを 4.0 にしてみましたが、便利なコントロールがいくつか追加されていたり、見た目がかっこよくなっていたりして良いです。 ロードマップを見たところ、バージョン 4.1 のリリースは Windows 10 リリースと同時とのことなので、Windows ユニバーサルアプリ開発には WinJS 4.1 を使えそうです。 UX に磨きがかけられるとのことなので、それも今から楽しみですね。

WinJS 4.0 での変更点

WinJS 4.0 では、API の変更も UI/UX の変更もいろいろと行われています。 詳細は GitHub 上の Changelog を見ましょう。

• Changelog · winjs/winjs Wiki · GitHub

スタイルの適用方法の変更

変更点のうちの 1 つ、スタイルの適用方法についてこのエントリでは紹介します。

Styling

Styling of intrinsic elements is no longer by default

Changelog · winjs/winjs Wiki · GitHub

Changelog に書かれているように、HTML の通常の要素にはデフォルトでは WinJS のスタイルが当たらないように変更されました。 WinJS 3.0 では、例えば button 要素そのものに WinJS 用のスタイルが当たるように CSS が書かれていましたが、WinJS 4.0 では button 要素を単に書くだけでは WinJS のスタイルは適用されません。 WinJS のスタイルを適用したい場合には、明示的にクラスを指定する必要があります。

ボタンの場合は、win-button クラスです。

<button class="win-button">WinJS のスタイルが適用されたボタン</button>
<button>WinJS のスタイルは適用されないボタン</button>

詳細は次のページに書かれています。

• Styling HTML Controls · winjs/winjs Wiki · GitHub

ボタンのようにスタイルが当たっていないことがすぐにわかるものは動作確認時に気づきやすいのですが良いのですが、h1 要素や progress 要素など、スタイルが当たっているのかどうか動作確認時に見てもわかりづらいものもあるので注意しましょう。 body 要素に win-type-body クラスを付与することが推奨されている のも移行当初は見落としがちなので気を付けたいですね。 win-button-primary の存在も見落としやすそうです。

Android の Canvas#saveLayer メソッドと xfermode について

Android アプリ開発に関して Canvas クラスの saveLayer メソッドや Paint の xfermode について調べたのでまとめておきます。

Canvas#saveLayer メソッド

saveLayer メソッドのドキュメントには、『This behaves the same as save(), but in addition it allocates and redirects drawing to an offscreen bitmap.』 と書かれています。

• save メソッドと基本的には同じ。
• 異なる点は、キャンバス外 (offscreen) のビットマップを用意し、以降の描画処理をそちらにリダイレクトするようにする、ということ。

save メソッドは何をするのか

じゃあ save メソッドは何をするのか調べましょう。 save メソッドのドキュメントには、『Saves the current matrix and clip onto a private stack. Subsequent calls to translate, scale, rotate, skew, concat or clipRect, clipPath will all operate as usual, but when the balancing call to restore() is made, those calls will be forgotten, and the settings that existed before the save() will be reinstated.』 と書かれています。

• 呼びだし時点の座標変換行列とクリッピングの設定を保存する。
• それ以降に、座標変換行列を変化させるメソッド (translate や scale など) やクリッピング設定を変化させるメソッド (clipRect と clipPath) が呼ばれると通常通り適用される。
• 対応する restore メソッドが呼ばれると save メソッド呼び出し前の状態に戻される。

つまり、描画される位置を決定するための情報が保存され、あとから復元することができるようになる、という感じですね。 描画されているビットマップの情報が保存されるわけではないので注意しましょう。

ちなみに、save(int) メソッドを使い、引数として Canvas.MATRIX_SAVE_FLAG や Canvas.CLIP_SAVE_FLAG を渡すことで、保存・復元の対象を座標変換行列だけにしたり、クリッピングの設定だけにしたりできます。 (が、両方を保存・復元の対象にする方が単純で速いので、できるだけ使わない方がいいみたいです。)

何度も save した後、指定のところまで一気に復元する

save メソッドを何度も呼び出した場合、restore メソッドを同じ回数呼び出すことで元の状態に戻せます。 しかし何度も呼ぶのは面倒ですね。 save 時の返り値を保持しておき、復元時にその値を restoreToCount メソッドに渡すと、その状態まで一気に復元できます。

// 返り値を保持しておく。
final int sc = canvas.save(); // 位置 A

/* ... ここで何度も save メソッドを呼ぶ。 ... */

// 途中で何度 save メソッドを呼んでいたとしても、位置 A のときの状態まで復元される。
canvas.restoreToCount(sc);

キャンバス外のビットマップに描かれたものはどこへ？

さて、saveLayer メソッドの話に戻りましょう。 save レイヤーと同じように座標変換行列とクリッピングの設定の保存ができることについては説明は不要だと思います。

問題は、saveLayer メソッド呼び出し後の描画がキャンバス外のビットマップにリダイレクトされて、最終的にそのビットマップに描かれたものがどうなるのか、です。 メソッドの説明には次のように書かれています。

Only when the balancing call to restore() is made, is that offscreen buffer drawn back to the current target of the Canvas (either the screen, it's target Bitmap, or the previous layer).

restore メソッドの呼び出しが行われて初めてターゲットとなるキャンバス (スクリーンだったり、Bitmap だったり、より前に作られたレイヤーだったりする) に描き戻されるわけですね！

引数の Paint オブジェクトの属性は描き戻し時に適用される

saveLayer メソッドは引数として Paint オブジェクトを受け取ります。 この Paint オブジェクトの属性のアルファ値と xfermode、そして ColorFilter は store メソッドが呼ばれて描き戻される際に適用されます。 Xfermode については下で説明します。

Xfermode と PorterDuffXfermode

Xfermode について

Xfermode クラスのドキュメントには 『Xfermode is the base class for objects that are called to implement custom "transfer-modes" in the drawing pipeline.』 と書かれています。 「xfermode」 は transfer-mode を表すみたいですね。 (これが世間一般での命名なのか Android の世界だけの命名なのかよくわかりません。)

ちゃんとドキュメントには書かれていませんが、2 つの画像を合成する場合や、既に何かが描かれているところに新たに描画する際に、どのように合成するのかを表すもののようです。

PorterDuffXfermode

昔 Porter さんと Duff さんが画像合成の 12 通りのルールを論文にしたそうで、それが Porter-Duff ルールと呼ばれているそうです。

• Merlin の魔術: Porter-Duff のルール！
• Android アプリ開発 - PorterDuff.Mode とは何なのか

具体的にどういうものかは上のページを見るとわかりやすいです。 例となる画像があります。

これらのルールは、Android SDK では PorterDuffXfermode クラスで表現されます。 (Android SDK では 12 通り以上のモードが定義されているので、Porter-Duff ルールに含まれないものも入っているのかも？)

例えば、次のページに書かれているように PorterDuff.Mode.CLEAR を使うことで対象となるキャンバスの内容 (destination) も描くもの (source) も両方消去することができます (つまり消しゴムにできる)。

• Android - Canvasを透明色で塗りつぶす - Qiita
• Android - Canvasを部分的に任意の色で塗りつぶす（消しゴムみたいの） - Qiita

ちなみに、ImageView#onDraw メソッドなどに渡されてくる Canvas オブジェクトは背景が透明ではないので、透明にしようとしても透明にならないようです。 (真っ黒になった。)

saveLayer メソッドと xfermode のサンプルコード

赤い四角をもとのキャンバス (destination) に描き、青い円を新しく用意したレイヤー (source) に描き、Porter-Duff の Overlay モードで合成するサンプルコードです。

// 必要な import 文。
import android.graphics.Bitmap;
import android.graphics.Canvas;
import android.graphics.Paint;
import android.graphics.PorterDuff;
import android.graphics.PorterDuffXfermode;

// 使用する Paint オブジェクトの用意。
Paint redPaint = new Paint();
redPaint.setAntiAlias(true);
redPaint.setColor(getResources().getColor(android.R.color.holo_red_light));
Paint bluePaint = new Paint();
bluePaint.setAntiAlias(true);
bluePaint.setColor(getResources().getColor(android.R.color.holo_blue_bright));
Paint xfermodePaint = new Paint();
xfermodePaint.setXfermode(new PorterDuffXfermode(PorterDuff.Mode.OVERLAY));
// Canvas 用意。
Bitmap bm = Bitmap.createBitmap(300, 300, Bitmap.Config.ARGB_8888);
bm.setDensity(DisplayMetrics.DENSITY_XXHIGH);
Canvas c = new Canvas(bm);
// 四角を描画。
c.drawRect(0, 0, 210, 210, redPaint);
// 新しいレイヤーを準備。
int sc = c.saveLayer(null, xfermodePaint, Canvas.CLIP_TO_LAYER_SAVE_FLAG);
// 新しいレイヤーに円を描画。
c.drawCircle(180, 180, 120, bluePaint);
// 新しいレイヤーに描かれたものを描き戻す。
// (saveLayer 時に指定した xfermodePaint の xfermode である Porter-Duff の OVERLAY モードで。)
c.restoreToCount(sc);
// 表示してみる。 (imageView は android.widget.ImageView オブジェクト。)
imageView.setImageBitmap(bm);

結果は以下の画像のようになります。

DST_ATOP や SRC_ATOP、SRC_OUT などを使うとマスク処理みたいなこともできますし、面白いですね。

備考

• Xfermode を指定して画像の合成をする方法はいろいろあって、Canvas#saveLayer メソッドを使う必要は必ずしもありません。

参考にしたページ

• AndroidのCanvasを使いこなす！ – 基本的な描画 | NET BIZ DIV. TECH BLOG
• Canvasの状態を保存/復帰させる « Tech Booster