//tips
//unityにおけるhttp通信理解
Unityのwwwクラス/unitywebrequest(Unityの通信APIに)を用いたhhtp通信と .NETからのhttp通信の違いを理解する。また、それに関わるサーバの立ち位置も確認していく。
まずは通信から理解する。
規模が大きくなったり、ソーシャル機能を実装したい場合には、HTTP通信を行って外部のサーバーとデータのやり取りが必要になってくる。
この際に用いられる通信方法がなぜ重要かというと、
・通信によって待たされる時間
・通信するための費用
・通信することによって消費するバッテリー
・通信異常時の適切なハンドリング
・通信内容の保護
という顧客体験にかなりの影響を与えるものだから。
UnityでHTTP通信をしたい場合、以下のような選択肢が存在する。
・WWWクラスを用いた通信
昔から提供されているAPIで、wwwクラスではGET、POSTにしか対応してい
コスパも良くなく、下記のような問題もあるよう。
①www.bytesが返すbyte[]は、ヒープ領域にbodyのサイズに等しい大きいゴミを残して、ガベージコレクト（GC)やメモリ断片化を促進する
ヒープ領域とは、動的に確保と解放を繰り返せるメモリ領域のことで、プログラムの実行時には、OSからソフトウェアに対して一定量のヒープ領域が与えられる。ソフトウェアは、必要に応じて任意にヒープ領域を確保・解放できる。ヒープ領域はデータの仮置き場や、臨時の作業台のような存在。
この場合、どのような順序で確保・解放するかは、ソフトウェア側で自由に決められるため、あらかじめどのくらいのデータ領域が必要なのか分からなくても、ソフトウェア側が必要に応じて対応できる。
一方、それらの判断をソフトウェアに任せることになる以上、全体の管理は難しくなり、解放されないままのヒープ領域が発生する。そのような放置されたヒープ領域が発生する問題を、メモリ・リーク（メモリの回収漏れ）という。
ガベージ・コレクションとは、未開放のヒープ領域を回収する仕組み。
ヒープ領域の空き容量が不足し、ソフトウェアに支障をきたすようになるため、別途ガベージ・コレクション（ごみ収集）により対応していくことになる。
メモリを高速で使ううえでは、ヒープ領域はあまり好ましくなく、あらかじめ割り当てる容量や順序が決まっているスタック領域のほうがスムーズに活用できる。
メモリ・リークの問題も相まって、予想以上の容量が消費され、ソフトウェアがクラッシュする可能性がある。また、使う場合は、予備のメモリを準備しておくなどの対策が不可欠。
②受信が全て完了してから処理を始めるので、受信にかかる時間を有効活用できない
またファイル書込を同期的にやってメインスレッドを止めてしまうが、書き込み処理を非同期化するようカスタマイズすることも可能のよう。
スレッドは処理の流れを表すもので、プログラム開始から終了までの一筋の線として理解できる。
ただ、マルチスレッド・プログラムでは，処理の流れを表す糸が一本ではなく、枝分かれする場合もあり、複数のスレッドを同時に実行するには二つ以上のプロセサ・コアが必要。
または、少し実行しては切り替えるといった動作をさせる。
基本的には枝分かれしたスレッドは、別のスレッドと合流する仕組みは存在せず、処理の終わったスレッドは、システムから消滅する。ただ、あたかもその場所で二つのスレッドの処理が合流したように見えるケースもある。
Windowsの場合は、CreateProcess APIによってプロセスを生成すると、必ず同時に一つスレッドを作成し、それがプロセスにおけるプログラムの実行を担うことになる。このスレッドをメイン・スレッドと呼ぶ。
マルチスレッドといっても結局は順にスレッドを切り替えて実行しているだけなので、あまりたくさんのスレッドを起動してしまうとパフォーマンスが低下する。
一般にはあらかじめ最大のスレッド数を決めておき、その数を超えた場合にはクライアントに少し待ってもらう、という実装を行うことになる。
③ネイティブ側からC#へのメモリコピーコストが存在する
ファイルサイズが大きいほど、これらの影響を深刻に受けることになる。特にガベージコレクト（GC）によるstop the worldを誘発しやすくするので、これを回避するためにはWWWを使わない方向性がとられる。
Unity対応通信APIをフルスクラッチで作成する場合、このwwwクラスの通信がベースとして、独自APIを作成していくことになる。
・UnityWebRequestを用いた通信
WWWに代わる次世代のAPIとして5.4から正式にUnityに導入され、WWWと比べてAPIのカスタマイズが柔軟にできるようになる。
仕様のためC#へのコピーコストは回避できないが、UnityWebRequestの強みである、DownloadHandlerのカスタム化のためのDownloadHandlerScriptを併用することで、単一固定長バッファを用いた受信データの逐次処理が可能となるため、WWWで問題となったようなメモリのゴミや無駄な時間は回避することができる。
一方で、受信データの逐次処理が必ずメインスレッドから呼ばれるという制約が回避不可能で効率が悪い。
また、iOSの通信のキャッシュ機構に起因した問題も存在し、もともとiOSには通信のレスポンスをキャッシュするNSURLCacheと呼ばれる仕組みがあり、これを活用すると通信量や時間を節約できるが、これを使うことによってストレージを少なからず圧迫する。この圧迫が確認された。
参考：
https://developers.cyberagent.co.jp/blog/archives/6649/
https://docs.unity3d.com/ja/current/Manual/UnityWebRequest.html
https://www.g2.com/compare/appcelerator-vs-unity
ベースとしてはUnityWebRequest+DownloadHandlerScriptでの対処となるが、それ以上を求める場合は独自開発で、
・OSのAPIを利用することで、OSの総合的なサポートを受けられる形に変更
・受信からファイル書込までネイティブ側で完結できるようにし、C#側への無駄なメモリコピーコストを発生しなくする
・メインスレッドに負荷をかけずに処理を完結できる設計にする
を満たせば良くなる。ただ、OSのAPIの変更にある程度追従するための保守をする必要があったり、実装コストもかかる。
昨日の議論の帰結としては、上記点を独自開発する必要がある規模のものなのかどうかがポイントとなりそう。
.NETからのhttp通信はできることにはできるがバージョンの制約やインストールを別途しなければいけないなどがあり、やり方が面倒だということのよう。
https://stackoverflow.com/questions/38645336/use-nets-own-httpclient-class-on-unity
https://qiita.com/ruccho_vector/items/406eef15557f1a3f0f93
https://docs.unity3d.com/ja/2019.4/Manual/dotnetProfileSupport.html
サーバの問題はphpサーバーを別途きちんと作るようにとのことだと理解した。
上記より、今のところ3dワールドマーケットを作る上でunityから他のシステムに乗り換える必要はなさそう。
早速こちらのunity-ecommerceの中身を見ていくことにする。
https://assetstore.unity.com/packages/templates/systems/fair-deal-e-commerce-template-185828
The front-end is made in C # (in the Unity3D environment), the server back-end works in the MySQL + PHP bundle.なので知識的には問題なさそう。
パッケージ購入によって得られるものは、
• Completely ready-to-customize e-commerce project.
• Fully documented MySQL database integration via PHP scripts in JSON format.
JSON formatで書かれている点では注意が入りそう。
• Module of endless scrolling of the product list.
• Module for dynamic sorting and filtering of the list.
• Module for caching images.
• Module for commenting (maintaining dialogs, quoting, likes) with reference to the product.
• Module for searching goods in MySQL database.
• Module for setting and viewing the ratings of sellers, selected products, recent comments.
• Module for choosing an Avatar from a tile view.
• Module of the Multilingual interface (in the template only English and Russian).
• Module for portioned telegrams for sending selected goods via Telegram API.
ここに出てくるmoduleはスクリプトの中身を見ることができるのか確認。
• Online 3D consultant with interaction.
• Authorization module (registration, authorization, password recovery).
• Feedback module.
• Demo MySQL database for initial testing.
• Scripts for filling in your own database of goods and promo codes through the API of the Admitad.com partner program.
• And most importantly. You buy a time saving in the amount of a year of fairly dense development =)
デモを見ているとunityでなくてもswiftなどでも作れる2dの内容のよう。また、アプリ内の商品画像をクリックすると他のサイトに飛ぶようになっている。
http://perfect-human.com/FairDeal/Demo/
3d系とは関係なさそうなので、こちらはパスとする。
現状の3dワールドはスマホ画面には狭すぎるためコンシューマー市場というよりはPCでの運用をベースとするtoB向けを意識した方が良さそう。最終的にはMRメガネなどによりコンシューマーにも浸透する形になると考えるが、これはまだ数十年後の話になりそう。VR機器は不便(重い、眼鏡がずれる、酔う、2dで代替可能)なため現状大衆には使われなさそう。VRの内容をPCで運用するというのがメイン。
3dワールド経済圏の構築要素を確認・準備しつつ、その過渡期技術を現状需要があるtoB中間点に対してアウトプットする方向性に向かう。
中間点の候補となるのはアリババの「芝麻信用」や遠隔医療/医療シミュレーション、仮想通貨など。他にも技術的に3dワールド経済圏に連携されるものでアウトプットをしていく
参考：芝麻信用
これはデータベースの収集と収集データのAIによる帰納・演繹計算にもたらされるので、主軸となるのはAIの予測精度となる。AIの予測精度はデータ量に比例するため中国が群を抜いて有利なところ。手がつけられればこちらもやりたいが優先順位は高くない。
https://www.soumu.go.jp/main_content/000605069.pdf
https://www.nri.com/-/media/Corporate/jp/Files/PDF/knowledge/publication/kinyu_itf/2017/10/itf_201710_7a.pdf
https://digital-shift.jp/china/190628
https://xtrend.nikkei.com/atcl/contents/18/00230/00005/
参考：遠隔医療/医療シミュレーション
こちらの方が3d系であり、ワールド構築との相乗効果があるので比重は重い。
世界の医療シミュレーション需要の伸び2022年に2800億円（3年で２倍の成長率）、診断支援ソフトウェア2020年に日本国内770億円などと市場としては面白い。特に診断支援ソフトウェアは医療法が改正され、認可がおりやすくなったよう。
患者固有データでの3DCG仮想シミュレーションできるソフトに需要があるとのこと。少しモデルの作成・シェーダーなどの方に重点がお枯れている内容。
医用画像はDICOMデータと呼ばれるものであり、そちらの利活用に需要が大きくあるとのこと。
多すぎる医用画像の統合・融合3d画像が必要なため、
→その際の画像融合の位置合わせ
→表示画像のセグメンテーション/部位の表示非表示を可能にする
→レンダリングによりより良い可視化
→実際にシミュレーションし、部位の変形などで手術方法の検証
などで対応できればベスト。
情報取得タイミングが手術直前、手術件数の不足でAI化不能、現状の医用画像の性能が不十分といった問題を解決するために使われる。
他には、個人の医療情報を自身のアプリに保存し、どの病院でも同様の医療情報を共有できるなどのシステム設計も需要があるとのこと。
インドネシアでは「都市部での診療待ち時間が数時間に及ぶ一方、地方部では医師がとても遠い」という問題解決のために、スマートフォンで診察から医薬品購入・配送まで完了する遠隔診療が成立しているし、米国には遠隔医療に特化した世界初の「病床のない病院」が出現している。
感度双方向カメラや、オンライン対応の機器やリアルタイムのバイタルデータなどから、患者がどこにいても診察を受けられるようことができるよう設計されているそう。
https://www.jetro.go.jp/ext_images/_Reports/02/2017/2fbd6d9d9e8b8713/rpny-201705.pdf
後述の遠隔コミュニケーションは先々の3d空間内でのコミュニケーション技術にそのまま反映できるので検証しがいがありそう。
