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は…まあ頑張ろうデバッグは各プラットフォームのデバッガで行う