- 投稿日：2021-01-29T23:23:17+09:00
休学中にアプリを作ったらappleにスパムアプリと言われた話
今年度大学を１年間休学しました。その間に作ったアプリをリリースしたのでやってきたことを振り返ろうかな〜と思いこの記事を書きました。
作ったトークアプリ
『ChillTalk』というトークアプリをつくりました。1つのルームにユーザーが集まり、移動をすることでいろんなグループの話が聞け、話相手を見つけられるのが特徴です。自分の付近にいるユーザーの声だけが聞こえます。
3月
まず、わたしは機械工学部なのでプログラミングは少しいじっただけでまともに勉強したことがありませんでした。高校を選ぶ頃はものづくりが好きだったり、宇宙飛行士に憧れ機械系に進みました。しかし、もともとガジェットやアップルなどのテック企業が大好きだったこともありソフトウェアへの関心が強くなり仕事ではハードではなくソフトを作りたいと考えるようになりました。そんなとき、今やっている研究も楽しくなく来年度を続けるのかと考えるととても気が重くなり、休学を考えました。
一年後には学生に戻れて学生じゃ無くなるわけじゃないし、休学金もかかりません。ソフトウェアの勉強して、なにか作ってみたいと思い休学しました。4 - 5 月
まだやることがあったので4月は学校に行っていました。
休学し始めた頃は、インスタのARフィルターを作っていました。
あとは、LINEスタンプとかも作りました。6 - 7 月
ここで、真剣に1年なにやろうか考えました。そこで思いついたのがアプリ制作でした。
今までは自分で作って満足していたけどあまり人に使ってもらうことは考えていませんでした。今度はみんなに使ってもらえるアプリ作りたいと思いました。そこで考えたのがトークアプリです。
twitterのようなくだらない話をしたり、いきなり知らない人と絡められる、そんな気軽に人としゃべれる場所が欲しいなあと思いました。トークアプリすでに多くあります。しかし、ほとんどが１対１で会話するものです。いきなり２人きりで喋るのはきつい。話す内容を考えるのにハードルが高い。そんな感じで今まで１回も使ったことがありませんでした。
そこで考えたのが1つのルーム内にユーザーを集めてその中を移動して会話相手(グループ)を見つけるというものです。↓友人に見みせるために書いたアイデア
映画の話をしたかったらマップ上の映画館に行けばいいし、誰かと話をしたかったらぶらぶらマップ内をあるいて話し相手を見つけれる、というものです。マンダロリアンの新作について誰かと話したいし、友達つくりたい。これならルームに入るだけで話し相手を見つけられるんじゃないか。
早速作り始めました。8月
早速Xcodeで作りはじめました。
音声通話まわり
WebRTCという仕組みを使えば通話ができるらしい。そして、WebRTCを行う場合の通信方法がいくつかある。
P2P : ユーザー同士が直接通信する。ユーザー側の処理が増えるので接続数には制限がある。
MCU : サーバーを介して通信する。サーバー側の処理が増えるので接続数が増やせる。
SFU : サーバーを介して通信する。WebRTCに使われる。2,3人の通信だとP2P品質がいいとのこと。今回つくりたいのは大人数の会話を行いたいのでその場合はSFUを使うといいらしい。
そして、NTT CommunicationsがSkyWayというWebRTCアプリのSDKを提供していた。これを使おう!!移動まわり
ジョイスティックを使って移動したい。けど実装難しくない!?時間かかりそう。とりあえず十字キーにすることにしました。
ゲームみたいにスムーズに移動したいけどXcodeだとできない。毎フレームごとわずかな移動を連続させると処理が重くなりカクカクするし...とりあえず「x座標に１移動する」みたいな処理になりました。
そして、他のユーザーに近づくとその人のSkyWayのトークルームに入室に、会話でできるようにしました。本来実装したかったユーザー間の距離による音量減衰はできませんでした。とりあえずテスト版が出来た
赤丸 : 自分、青丸 : 他ユーザー
思ってたのと違う!! 移動方法も移動もスムーズじゃない。
よく考えれば、自分がやろうとしていることはシステム的にはゲームなんじゃないかと気づきました。
ゲーム開発ならUnityをつかうことになるけど、せっかくSwift勉強してXcode使えるようにそれを一切使わずに他の開発するのはもったいないと思いました。けれど、このアプリのアイデアはウケるし気がしたしみんなに使ってもらいたい。どうしてもこのアプリを作りたいと強く思いUnityを勉強しました。9月
Unityの本を買ってきてサンプルのアプリを一通り作りました。思っていたより簡単である程度のことはすぐにできました。
スムーズに移動できる! ジョイスティックはアセットストアにあったものを使いました。(アセットストア便利すぎw)
リアルタイム同期にはPUNを使いました。簡単に説明すると、Photon(PUN)はユーザー間の通信をリレーするサーバーを提供してくれるサービスです。SDKを入れて設定するだけで簡単にリアルタイム通信を行うことができました。また、Photonが提供しているPUN VoiceをというボイステャットができるSDKを使用しました。そして、ユーザーのオブジェクトごとにスピーカーを設定することで音量減衰を実装できました。
今までXcodeでやっていたことはなんだったんだろう?と思うレベルで、すぐにアイデアを実装できました。行き詰まったとき
ときどきアプリが思ったように動かなかったり、エラーが連続したりしてモチベーションがなくなるときが結構ありました。
そんなときはいろいろ作ったりして遊んでいました。初めてOculuQuestを買ってボウリングしたり、
VRで外国人とAppleのイベントみたり
LEDテープをディスプレイ裏に貼ってArduinoとPCをつなげて画面の色と同期したり
3Dプリンタでジョイスティックを作ったり
スマホを車のHUDにして速度を表示するアプリを作りました
これはAR,VR関係の人達に反響があって嬉しかったです。
Google PlayStoreでリリースしたのでダウンロードしてくださいーー!
ということで「Speed Display」リリース
— Brian (@Brian3546) November 30, 2020
位置情報のアクセスを許可してねhttps://t.co/XUNNfYFSac pic.twitter.com/MXeL30YqSa冬あたり
SNSみたいにフォロー機能をつけて、フォローした人がアプリを立ち上げたらフォロワーに通知がいく機能や、フォローしているルーム内の座標を取得してそこにワープ出来たらいいなと思い実装を始めました。しかし、これが地獄の始まりでした。誰をフォローしたかなどを保存するのにはサーバーが必要です。そのあたりはFirebaseを使いました。swiftで使ったこともあってかサーバーへの保存・読み取りは簡単でした。しかし、フォローリストをサーバーとリアルタイムに同期させたり、フォロー一覧のスクロールビューを作るのにものすごい時間がかかり、それに伴いモチベーションも低下し気づいたら１ヶ月経っていました。
そして、ある程度出来たのがこちらなんとか形になった!
数人の友人にTestFlightで使ってもらいました。
アイコンの移動や同期はうまくいきましたが、重大な問題が発覚しました。
スマホのスピーカーを使用して通話するとマイクがスピーカーの音を拾ってしましい、ハウリングが発生しました。
話すたびにハウリングし、まともに会話が出来ませんでした。
自分がイヤホンするとハウリングは発生しないのですが相手のマイクが自分の声を拾い、数秒後に声が返ってきます。非常に話しづらい...
(この原理を利用して、相手の話をやめさせる機械があるそうですw)PUN Voiceのマニュアルをみてみるとスマホとスピーカーを使用しての会話は非推奨とのこと。ハウリングを無くす機能もありませんでした。他の通話アプリはどうしているのかLINEを使ってテストしました。そしたら、相手が話している時は自分のマイクがミュートされていました。反対に自分が話しているときには相手の音声はオフになって聞こえなくなっていました。なるほど、意外とシンプル。これなら実装出来そう。
自分の音量が一定値を超えたら相手の音声をオフにし、音量が一定値以下になったら相手の音声をオンにする。というシンプルなものを作ってみました。
これでテストしてみたら、だいぶハウリングが無くなりました。しかし、遅延の存在を忘れていました。自分が話終えたあとすぐに相手の音声をオフにしていたので、相手のマイクから自分の声が聞こえてきます。自分が話し終えた後も遅延分音声をオフにしている必要があるのです。
遅延分も考慮して実装してみると、確かにハウリングは無くなりました。しかし、話し終えた後に相手の声が聞こえるまでの時間があり、素早い会話ができません。例えると、一球一球丁寧にキャッチボールをしているような感じでした。また、遅延も一定ではありません。相手の話ているのに音声がオンになっていなかったり使いづらかったです。遅延分の制御がとても大変でした。ここでまた2,3週間かかってしまいました。そんな時、本来なくてもいい機能に時間を費やし過ぎていることに気がつきました。思いついた機能を付けたすことで、コードもエラーも多くなりました。確かにあったほうがいい機能かもしれないが、まだユーザーもいない状態で肝の機能以外で時間を費やすことは無駄だと思いました。とりあえず最低限の機能を持ったものをリリースしようと決めました。ここから一気に進捗が捗りました。
・アプリデザイン
・サインイン関係
・アイコン写真の設定
・バグの修正そして、ハウリング問題を解決するためにもう一度PUN Voiceのマニュアルを読んでみると、ハウリングキャンセリング設定も見つけました!数ヶ月前には無かったはずなのに!!!設定のチェックマークをオンにすると、たしかに綺麗にハウリングが消えている!スピーカーつかっても普通に会話できる!時間かけて作ったアルゴリズムはなんだったんだ。と複雑な気分になりました。
その時に本当にこの機能が必要なのか考え結果、とりあえずアプリのコンセプト部分だけでいいからリリースすることを優先するようにしました。
こうして一通りアプリが完成しました。
AppStoreとの戦い
いよいよストアの審査へ提出します。GooglePlayは問題ないと思っていたのですが、AppStoreがとても心配でした。
というのも上記にあった車のスピードをHUD表示するアプリをAppStoreに申請した際、何回か修正と提出を繰り返した後にこう言われました。
Guideline 4.2 - Design - Minimum Functionality
We understand that there are no hard and fast rules to define useful or entertaining, but Apple and Apple customers expect apps to provide a really great user experience.
要するに、シンプルすぎるからだめ。
ここまできていきなり殴られた気分になりました。（まあ、このアプリは3,4日で作ったのでそんなに傷は深くないですが）
こんなことが今回もある可能性があると思うととても心配でした。いざトークアプリを提出しました。
何回かリジェクトされ、バグの修正やアプリ情報を追加している時、こんなメッセージが来ました。
Guideline 4.3 - Design
メッセージのやりとりはもう見れず細かい文章はもう覚えていないのですが、「マッチングアプリはもうたくさんあるからいらないよ。他と似たようなアプリならばスパムとみなして、アカウント消すよ。アプリのデザインを一からやり直して」というような事を言われました。
調べてみるとちらほら同じ4.3リジェクトをくらっている人がいましたが、このリジェクトされた場合はもう審査は通らないという感じでした。
落ち込みます。半年間作ってきたものをスパムと言われ、リリースできないなんて一体自分は何をしてきたのだろう。この日は一日中落ちこんでいました。それでも、どうしてもリリースしたかったのでメールを書きました。
The matching feature is just a part of the app.
It was created to be used with people you know, such as classmates, workmates, and friends.The best feature of this app is that it allows you to move around the room, listen to different conversations, and participate in the ones that interest you. This feature has been well received by many people and we believe it is much desired.
There is no other app in the App Store that has this feature. This is a unique feature that only this app has. For these reasons, I don't think it's the same as other matching apps or talk apps.
I am responsible for being the developer of this app. While the app is being used by users, I will always check and strictly respond to reports from users to maintain the quality of the app.
・自分が作りたかったのは、このアプリにくれば誰とでも何人とでも話ができるというものです。それはどのアプリにもない独自性のある機能である事。
・個人開発者ではあるがユーザーの秩序を保ち利用規約を守らせる事。
を書きました。少しオーバーに書き過ぎたかもw
この熱量が少しでも伝われ！！と思いかきました。なんとかなるかもしれないと。翌朝アプリのステータスを確認してみると...
やったぁーー!!!!!!
あっさりと審査通りました。この時は本当に嬉しかったです。
地獄から一気に元気になりました。
GooglePlayでも審査が通り、こうして無事リリースできました。この一年で学んだこと
・アプリ開発初心者がいきなりリアルタイム同期(SNS)のアプリを作るのはハードルが高い
・やらない事を決める
・100%の完成はしない
・ある程度完成したらみんなに使ってもらい、ユーザーの声を聞いて機能の追加を考えていく
・困ったらエラーログをしっかり読む
・アプリ制作たのしい
・ものづくりたのしいこれからもアプリを作ってくうえで一番気を付けたいことは、100%を目指したらいつまでも終わらないことです。そんあんことは前から分かったつもりでいたけれど、なんだかんだこり始めてしまうものです。twitterにもアプリ起動後のロード時間はあるし、iPhoneにもいろいろバグがあります。世の中を見てみるとみんな完璧ではないことに気づきました。
決して動作が速く、バグもない完璧な物が評価いいわけではありません。みんなが気に入るのは根幹にあるアイデアなのかなと思いました。これからはもっとアイデアに重点を置いて短い期間でアプリを作っていきたいと思います!
最後まで読んでいただきありがとうございました。ぜひ「ChillTalk」を使ってみてください!
GooglePlayはこちら
AppStoreはこちらtwitterもフォローお願いします!
https://twitter.com/Brian3546
- 投稿日：2021-01-29T16:24:24+09:00
UGUI Atlasバッチ処理時のInclude in オプションをどうのように理解しますか？
今回の主な話題：UGUI Atlasバッチ処理時のInclude in オプションをどうのように理解しますか、Android端末のジャムを指定する方法、フォグ効果を実現する方法、シリアライズ化されたファイルの冗長な引用をクリーンアップする方法。
UGUI
Q1: UGUIのバッチ処理についていくつかの疑問があります。
1）UGUIのバッチ処理はいつ行われましたか？バッチ処理はEditorで合併された大きな画像なら、AssetBundleをパッケージする時にアトラスファイルと関連する小さな画像のみがパッケージされて、合併した大きな画像は見ていませんでした。では、これはUnityがLate in bindingを行う時に合併しましたが？
2）Include in Buildにいったい何が含まれていますか？私の理解では、チェックすると生成した大きな画像が含まれ、チェックしないと含まれません。では、まだ質問１に戻ります。チェックしない場合、大きな画像は実行中に生成しましたか？
3）小さな画像のサイズはパフォーマンスに影響しますか？まず、小さな画像のソースはパッケージ本体のサイズに確実に影響します。
質問1と質問2に基づいて、大きな画像は実行時に生成されなら、大きな画像を生成する時に、I / Oはバイトストリームの形式で空白の大きな画像に入力、合併しますか？そうであれば、実行中大きな画像を生成するボトルネックはソースファイルのサイズと形式はずでしょう？（アトラスとソースの圧縮形式は違うと仮定します。）
回答は以下になります。
1、Unityのバッチ処理のタイミングは設定次第です。
上図のように、パッケージ化時でもエディターの実行時でも合併することができます。Editorで合併された大きな画像はキャッシュディレクトリLibraryAtlasCacheに配置されます。2、About “Include in Build” behaviourを参照できます。
私の理解では、Include in Buildをチェックすると、アトラスリソースがAppにパッケージされます（AssetBundleパッケージではない）。アトラスはAssetBundleパッケージに管理させている場合、チェックしないほうがより良いです。そうしないとリソースは２倍になります。どちらのリソースは２倍になれるのは、テストする必要があります。
3、Unityは最終的に合併した大きな画像のみを使用し、小さな画像自体はリリースされたAppまたはAssetBundleパッケージに入らないため、小さな画像のソースファイルのサイズはパフォーマンスに直接影響しません。ただし、通常、小さな画像のサイズとSpriteの設定は、合併されたアトラスに影響を与えるため、最終的なパフォーマンスに間接的な影響を及ぼします。
Sprites Atlasが違うSprite Packer Modeオプションでパッケージすることについて、実験をしました。結果は次通ります。
1.最初の3つのオプション（Disabledと２つのLegacy Sprite Packer）の結果は同じ場合
パッケージしたAssetBundleに何もありません。この状況で、散図までもありませんはずです、完全にリソースをロードできません。さらに、UnityのBugの疑いが見つかりました。新しく作成されたAtlasとすでにパッケージ化されているAtlasでは、禁止オプションでパッケージ化の結果が異なります。
2.後の２つのオプションの結果は同じ場合
AssetBundleパッケージを生成すると、アトラスがすでに作成されました。
制作
Q2: マテリアルのShader、またはGameObjectコンポーネントのMonobehaviorは、開発中に一つのShaderのPropertyまたはコードのシリアライズ化パラメータを削除する場合があります。これらのパラメータが削除された後、マテリアルまたはGameObject Prefabファイルにある、このパラメータのシリアライズ化データは削除されていません。
たとえば、下図にあるTestGetDependencyという名前のコンポーネント。パラメータtestSubjectがコードからもう削除されていました。
ただし、このGameObjectのPrefabに、testSubjectのレコードがまだ存在します。
これにより、AssetDataBase.GetDependenciesみたいな方法を使用してアセット依存を取得する時、testSubjectによって引用されるオブジェクトを取得するため、パッケージ化時に不要なリソースが含まれることになります。スクリプトを使用してSerializedObjectをスキャンする方法でこれらの引用をクリアできますが、これには違う状況ごとに個別のスクリプトが必要です（現在はShaderのみがマテリアルに対応し、コードファイルはPrefabに対応します）、遺漏または不適切な処理が行われる可能性があります。ですから、Unityネイティブのクリーニング方法はあるかどうかを知りたいです。または、業界でスクリプトによってこのようなシリアライズ 化引用問題を処理する一般的な方法を知りたいです。
もう一度保存したら大丈夫です。
さらに厄介なのはShaderです。serializedObjectを自分で分析してからクリーンアップする必要があります。
レンダリング
Q3: 下図のように、パフォーマンスレポートで、Camera.Render下CreateVBOのオーバーヘッドが高いことがわかりました。これはどのように発生しますか？
これは基本的に、メッシュの再構築が引き起こします。非UGUIのUI再構築、テキストメッシュ再構築などで良く見られます。再構築する時のCPU時間コストは、主にメッチュ再構築の量に影響されます。ただ1フレームの場合、問題ありませんが、頻繁にオーバーヘッドが発生する場合は、特別な注意を払う必要があります。
制作
Q4: 図のように、インターフェイスフォグ効果を実現したいです。UIで実現するほうがいいでしょうか？それともそのようなシーンを作って実現するほうがいいでしょうか？現在の星図は3DのPrefabでアリ、黒いベースマップで覆い、影響範囲に応じてベースマップの明るい領域を変更する予定です。何か関するプラグインありますか？どこから始めればいいのでしょうか？
RenderTextureを作成できます。ピクセルとマップを1対1で対応させ、RenderTextureカラーの変更に介して、Shaderに対する計算を行って、効果を得ます。Unity 5.4以降、配列をShaderに渡すことでこの効果を実現できます。
メモリ管理
Q5: 異なるAndroidとApple設備で（1G、2G、3G、4G…）、クラッシュが発生しないように、ゲームのメモリピーク値をどのぐらい高く設置したら良いですか？
ここである人がiOSのメモリピークを更新し続けます。投稿の下で誰かがメモリピークをテストするためのツールも投稿しました。非常に使いやすく、参照できます。
https://stackoverflow.com/questions/5887248/ios-app-maximum-memory-budget.
UWA Technologyは、モバイル/VRなど様々なゲーム開発者向け、パフォーマンス分析と最適化ソリューション及びコンサルティングサービスを提供している会社でございます。
UWA公式サイト：https://jp.uwa4d.com
UWA公式ブログ：https://blog.jp.uwa4d.com
- 投稿日：2021-01-29T16:15:39+09:00
iOSをレビューする前に、プロジェクトのロード方法に注意してください
今回の主な話題：iOS監査の悲劇（拒否）を回避する方法、メモリリークの調査、ilcpp.soライブラリファイルのサイズ、il2cppコードサイズを縮小する、Strip byte Code。
アセット管理
Q1: 私たちのプロジェクトはAssetBundleパッケージング方式を使用し、WWWでローカルロードを行い、プログレスバーもあり、ロードされているデータと全体的なデータを指摘するヒント枠もあります。iOSレビューに送信した後、拒否されました。ヒントは4.2.3でした。
Guideline 4.2.3 – Design – Minimum Functionality
Your app did not include sufficient content in the binary for the app to function at launch, and we were required to download or unpack additional resources before we could use it.
We were required to download or unpack additional resources to continue using your app; however, the size of the download was not disclosed, and we were not prompted to choose to download additional resources. If your app requires additional resources, you must disclose the size of the download and prompt users before doing so.内部で何もダウンロードされていないことが確認されていますが、ローカルリソースのみがロードしていて、ヒントも与えました。なぜ拒否されたのか分かりません。
いくつかの考えすべき事項があります。
１）圧縮リソースを使用しないでください。パッケージ内のリソースには非圧縮またはLZ4圧縮形式を使用してください。パッケージ本体のサイズが敏感な場合はLZ4を使用してください。LZ4を使用する場合、アセットをロードするときに解凍必要があることに注意ください。これはAssetのローディングに時間がもっとかかることを引き起こします。フレームレートが敏感なときにアセットをロードする場合は、LoadAssetAsyncの使用を考慮する必要があります。
２）iOSでは、WWWの代わりにLoadFromFileを使用してください。WWWはより多くのメモリを必要とします。特にwww.bytesを使用する場合、下図のように、それが役に立たなくても、LoadFromFileの2倍になります。（WWWを使用するとダウンロードする必要があることが検出された場合があるとある報告されました、まだ確認していません。）
３）当社はもともと7zを使用してリソースを圧縮していましたが、却下された後、圧縮なしに変更され、スムーズにレビューに合格しました。
メモリ
Q2：妙な問題に遭いました。ダンジョンを繰り返し出入りすると、合計メモリは増加し続けます（1回あたり約10MB）。この時点では、各リソースメモリ、Monoメモリ、およびLuaメモリは基本的に変更されていません。つまり、Unityによってカウントされたあるメモリはありますが、詳細情報には含まれていません。 この部分は何でしょうか？
問題主が提供するスクリーンショットから判断すると、AssetBundleの常駐が原因である可能性があります。毎回シーンを出入りすると、アセットのローディングはAssetBundleで行いますか？AssetBundleの数は変更されましたか？そして、3回目、4回目以降、メモリも毎回10MBずつ増加しますか？AssetBundleを使用してロードする場合、実際にはAssetBundleでロードされた一部のメモリは、Detailedモデルで観察されません。この方面から調べることをお勧めします。
IL2CPP
Q3: IL2CPPの体積を減らすことについて質問します。公式ドキュメントによって、https://docs.unity3d.com/Manual/IL2CPP-BytecodeStripping.html
私の理解は次のとおりです。
しかし、実際にテストしたところ、正しくではないようです。
2018.2.7f1、左側の図にStrip Engine Codeは開きましたが、右側のほうに開きませんでした。
いくつかの問題があります。１）Strip Engine Codeを開いた後、いくつかのxx_Module cppファイルが欠落していることがわかりますが、これらのcppはC#とDllから転換してくるすべきですが、Byte Code StripのステップでStripする必要があります。Strip Engine Codeパラメーターの影響を受けないはずです。（公式ドキュメントがこのパラメーターはEngine Native CodeのStripのみに影響ありますと言っています。）どうする？
2）LinkステップのStripは私自身の推測です。XCodeに余り精通していませんから、Linkする時に不要なSymoblsを削除するためにどちらのCompileとLinkパラメーターは使えますが良くわかりません。この部分について何か正確な結論ありませんか？
3）Package Managerでは、不要なEngine Builtin Moudeleを明確にDisableします。例えば、AIやXRがIL2CPP の時に引き続きcppソースコードを生成します。常識に反しているように感じます。この部分は最終的にあるステップで削除されますか？
4）Strip Engine Codeは開いていますか？この前に、裁断が引き起こす問題を回避するために（特にホットアップデート）、開けないことにしましたが、現在、体積を減らすために開きたくなりました。何か注意すべき点がありませんかを聞きたいです。
ソースコードを調べました、https://github.com/Unity-Technologies/UnityCsReference
CodeStrippingUtils.csおよびAssemblyStripper.csにStrip Engine Codeに関するコンテンツがあります。このオプションをオンにすると、ModulesにStripを行います。（この一歩は完全には理解していません。おそらく、先にRoot Assemblyが使用するClassをフィルタして、これらのClassが使用するModuleを記録します。また、これらのModule自身のプロパティにも関連しています。）ここで、具体的に保存されたModuleとClassはファイルUnityClassRegistration.cppに記録されます。
私の理解は以下とおります。
Strip Engine Codeが影響するのは「Byte Code StripステップでUnity Engine CodeにStrip処理をするか」どうかということです。PackageManager内の設置をMonoの形式でパッケージしてみます。Strip Byte CodeでもStrip Assembliesでも、依然としてDisableのbuilt-in Moduleに対応するdllファイルを生成します。ここのDisableはパッケージ化のStrip操作と関係ありませんと推測します。
上記はただUnity buildに対して私個人的な理解であります。最も重要な問題は、Strip Engine Codeを開きますかどうかということです。私の前回のプロジェクトでは開きました。プロジェクトにリフレクションを使用していなかったので、目前には問題ありません。以後、問題があれば直したら大丈夫です。Unityの公式ドキュメントから、「開くとコードの量を減らすことができますが、問題がある場合閉めてください。」問題主に自分のプロジェクトによって決めることをお勧めします。
アセット管理
Q4: 最近、Android端末プロジェクトのパッケージかをIL2CPPの形式に変更したいですが、エクスポートされたapkのil2cpp.soファイルが40MBと大きく、libmono.soが作成した3MBのサイズよりもはるかに大きいことがわかりました。ですからapkもはるかに大きくなりました。何か解決策がありませんか？
Libli2cpp.soにはロジックコードが含まれています。libil2cpp.soとlibmono.soのサイズを直接比較することは無意味です。一般的に、IL2CPP方式のパッケージ化がパッケージを大きくする原因はC#コードがコンパイルされてC++コードに変更すると、コードの量が急激に増えるためです。この点について、Unityの新しいバージョンも常に最適化しています。
問題主が使用しているUnityのバージョンはなんでしょうか？Strip Engine Codeオプションが有効になっていますか？
Unityのバージョンが新しいほど、この点についての最適化効果が高いと言われています。 公式もこれに言及しました：https://docs.unity3d.com/Manual/dotnetProfileLimitations.html
アセット管理
Q5: 私のプロジェクトは、プレハブを非同期でロードするときにピークがあります。詳しく確認すると、この関数が原因であることがわかりました。これはなぜですか？どうすれば避けられますか？
これは、アセットを非同期ロードする時の時間コストです。アセットのローディングには常に時間コストがあります、必ずしも回避する必要はありません。アセットの非同期ローディングに頻繁ローディング問題があるかどうかを確認することを問題主にお勧めします。存在する場合には、できる限りに改善してください。
UWA Technologyは、モバイル/VRなど様々なゲーム開発者向け、パフォーマンス分析と最適化ソリューション及びコンサルティングサービスを提供している会社でございます。
UWA公式サイト：https://jp.uwa4d.com
UWA公式ブログ：https://blog.jp.uwa4d.com
