Unity
ネイティブプラグインの
作成について
Terasurware
山村 達彦
http://terasur.blog.fc2.com/
@tsubaki_t1

言葉あわせ
1

アセット。C#やらテクスチャ等、ゲームを構成する資産の総称

DLL。C#を（ソース隠蔽の目的で）DLLに変換したもので、特に制限はない。
C++のプラグインもDLLなのでややこしい

プラグイン。正しくはネイティブプラグイン。今日のお題

ネイティブプラグインとは何ぞや
2

UnityとiOSやらAndroid（あとPC)を連動させる機能

あとUnityからC/C++で作ったソースコードを使用する機能

例えば、アプリに好きなアドサービスを導入したり、
例えば、アプリ内課金を実装したり
例えば、上の2つを概ねコピペで実装したり

例えば、WebViewを動かしたり、
例えば、日本語フォントを利用したり、
例えば、Androidの特殊なデバイスにアクセスしたり.

Androidの動作イメージ

iOSの動作イメージ

ちなみに、Unity Web Playerでは動作しない。

ネイティブプラグインをアプリにインス
トール
3

プラグイン諸々（DLLやら.hやら.mm）
を「Plugins/iOS」フォルダに入れる。
必要なフレームワーク等は
ビルドした後の途中成果物を編集
iOS環境で動かすために必要なプラグインをインストール

プラグイン（.jar）のソースコード諸々
を「Plugins/Android」フォルダに入れ
る。
AndroidManifest.xmlをプラグインが動く
ように書き換える
iOS環境で動かすために必要な操作を行う

AndroidManifest.xmlのひな形は
PlaybackEngines/AndroidPlayerにある
もしくはAndroidビルド時に
Temp/StagingArea下に生成される
マニフェストファイルが無い場合は、適当な箇所からコピーしてきて、Plugins/Androidにポイ。
このファイルは競合し上書きされる可能性が滅法高いので、バックアップは忘れずに。

後はPluginsにあるプラグインにアクセスするC#のコードから、プラグインにアクセス

必要に応じて、対応プラットフォーム用の途中成果物のソースコードを書き換える時もある

PostprocessBuildPlayerで、この作業を自動化できるらしい

プラグインを作るために必要なもの
4

対応OSのライセンス。PC版の場合はProライセンス
（絶対必要ではないが、無いと動作確認できない）

対応するプラットフォームのアプリを構築できる知識
対応するプラットフォームのネイティブアプリを構築できる環境
対応するプラットフォームが実行できるデバイス

Orz
折れない心

Unity→プラグインの連携
5

Activity/UIViewControllerを改造し、
勝手に開始してもらう
UnityのC#からプラグインを呼び出す
プラグインを呼び出す方法は概ね２通り
基本的には後者でやるべき

UnityPlayerActivityを継承したクラスを
eclipseあたりで作成する
（ビルドにはclasses.jarをビルドパスに含める、
Unityフォルダ下のPlaybackEngines/AndroidPlayer/binにある
またAndroidの機能を使うなら、それもインポートする）
上で作成したクラスをjarにエクスポート
して、Plugins/Androidフォルダに配置
AndroidManifest.xmlの
UnityPlayerProxyActivityと書かれている
箇所を、作成したクラス名に書き換える
前者のActivityを改造して実行する方法。
Activityを改造して実行するプラグインは、他のActivityを改造して実行するプラグインと競合する
UnityPlayerNativeActivityのほうが早いが、古いAndroidでは動作しないらしい

resやassetsはPlugins/Androidフォルダ
に入れておくと、自動でインポート
namespaceの問題で、resを使っているプラグインは動かない時がある。
resでnamespaceを固定するか（そんな方法はあるのか？）、プラグインのRが
使っているnamespaceをアプリのbunleIDと合わせると動作する
resやassetも使えるが、R.classのnamespacecがbundleId依存なので注意

Unity4からまさかのEclipse出力機能が登場
UnityPlayerActivityを直接編集できるかも（ActivityとNativeActivityを継承したクラス等）

AndroidJavaClassで
Javaのコードを呼び出す
C#のコード
Javaのコード
Androidのプラグイン連携その２。他にもJNIとかJNIHelper等があるが、これが一番楽
C#はPluginsフォルダに入れておく
Javaのコードはjarに変換してPlugins/Androidへ

DllImport(“__Internal”)で、
Objective-Cのコードを呼び出す
C#のコード
Objective-Cのコード
Pluginsフォルダ下に置いたC#は、Plugins/iOS下に置いたObjective-CやCの関
数を呼べる
iOSの場合。
C#のコードはPlugins下にでも置いておく。Javaと違い、コードのままビルド可能

直接DLLを呼ぶこともできる

プラグイン→Unityの連携
6

UnityのSendMessageと同じ感じで使える
Pluginsを処理の起点にできるが、
届くのに１Fかかる
SendMessageは戻り値が使えない
●
SendMessageを使う

Android向け
iOS向け
●
戻り値（return）を使う

SQLite
PlayerPrefs等
●
I/Oに書き込む

プラグインを作る上での注意
7

Unityからプラグインの呼び出しは
重い処理
Androidの場合は関数をキャッシュする
１フレームに何回も呼ぶ事は避けて、
データをキャッシュしていくべきらしい
Unityからプラグインを呼び出す処理は基本的に重いので、乱発は避けるべき

Unityのゲームが終了しているのに、
プラグインの処理が継続する的な事が
たまにある。
困る場合は戻り値ではなく
結果をI/Oにでも入れて、
Unity側から承認プロセスを用意
プラグインは色々なところで面倒くさい

iOSビルドはARCがOFFなので、
自分で開放してやらないと大惨事
さり気なくメモリリークを起こしてる
プラグインが稀によくある
String型のみMono側で開放するので
開放は不要らしい（ドキュメント談）
メモリの開放も自己責任。プロファイラーでよくよく確認する。

プラグインのコードは
端末の影響をモロに受けるかもしれない
（HTMLを使用したりする場合等）
プラットフォームの細分化に注意（主にAndroid）

実機で動かさないと動作しない
（iphoneシミュレータ等では動かない）
プラグインの動作検証は毎回ビルドして実機確認

その他
8

プラグインの構造は可能な限りシンプル
に
機能は最小限にして実装しとくと管理が楽

Platform Dependent Compilationで
プラットフォーム毎に機能わけると楽
（こうしないと、iphoneビルド時にAndroidJavaClassがエラーになる）
エディター上で動作している時に仮デー
タを入れておくと、ゲームが作りやすい
プラグインを呼び出すコードは、PlatformDependentCompilationで管理

iOSはconst char*stringで渡された時、
Stringを使用する場合はUTF8に変換する
iosに投げた文字をそのまま使うと文字化けするかも

Ad等の描画やUIに関わる処理は
UIThreadから呼び出す
UnityのActivityは
UnityPlayer.currentActivityで取得可能
Androidのルールがけっこう面倒くさいので注意

プラグイン配布の際、
package形式を使うと
フォルダ構成等を簡単にインポート
（あとファイルサイズが減る事がある
出力は必要なファイルのみ選択してAssets>Export Package）
ただしファイルがすでにある場合は上書きするので、
AndroidManifest.xml等は含めない方が良いかも
プラグインはpackage形式で保持しとくと、導入が超楽になる

デバッグログは
iOSならXcodeのロガー、
AndroidならLogcatでチェック
パフォーマンスの確認は
iOSならXcodeのアナライザ
Androidは…まあ頑張ろう
デバッグは各プラットフォームのデバッガで行う