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

2. 言葉あわせ
1

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

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

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

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

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

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

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

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

11. Androidの動作イメージ

12. iOSの動作イメージ

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

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

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

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

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

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

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

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

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

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

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

24. Orz
折れない心

25. Unity→プラグインの連携
5

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

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

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

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

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

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

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

33. プラグイン→Unityの連携
6

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

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

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

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

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

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

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

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

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

43. その他
8

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

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

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

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

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

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