Comments数週間ほど更新が出来ておらず、申し訳ございません。今週から再開いたしますので、これまでご覧いただいていた方は今後ともよろしくお願いいたします。前回は、フレーム画像をサーバーにアップロードする方法をご紹介しました。今回は、フレーム保存からアップロード処理の改善を行いました。前回までの記事で、フレーム毎に画像を保存し、保存した画像をサーバーへアップロードする処理の一通りは出来ていましたが、1秒当たりのアップロードファイル数が極端に少なく実用性がありませんでした。以下の障害が発生していました。1秒あたりのアップロード数が1枚カメラで写しているものの表示が異常にカクつく上記が発生していた原因としては、フレーム保存を同期処理で行っていたことと、フレーム保存のたびに通信を行っていたことにあります。画像保存前のデータ及び送信データがNSDataであるため、単純にフレーム処理自体をやめて生成したNSDataをそのままアップロードデータとして設定することでフレーム保存処理をまるごと省略することができます。この方法をとった場合、フレーム毎に通信を行う件を解決するためには、生成したNSDataを配列で一時的に保持し、監視タイマーを用意して一定枚数毎に通信を行うように制御する必要が有ります。実際に動作させてみたところ、アップロード速度がフレーム毎のUIImageの保持速度に間に合わず数十秒撮影し続けると、保持しているデータが膨大になり、メモリ使用量がみるみるうちに増え、エラーが発生してしまいます。エラーは発生してしまったものの、アップロード処理を制御することで、パフォーマンスの改善がみられたためファイルの保存処理を別の方法で解決することで、残りの問題も解決できそうです。保存時負荷を防ぐために、NSDataを書き込まずに配列で保持して、使用するよう変更しましたが、メモリ使用量の問題が発生しては意味がないため、アップロードファイルの保持は元の通りローカルストレージへの一時保存に戻します。保存処理」を行うためのスレッドをそれぞれ用意し並列で処理を実行することで解決することができます。通信のキュー化やサブスレッド・非同期処理について、いろいろなサイトで説明がされているため、詳しくはそちらをご覧ください。今回の対応で変更となった箇所について、その部分だけを抜粋して記載します。atomically:YES];});終わった後に改めて考えると、なんとも簡単な方法でした。実際に作業しているときには、なかなか気付けないものですね。これで、スマホ側のアップロード処理が使えるレベルまで改善されたため、残りはサーバー側の受け取った画像での動画作成周りを終わらせることができれば、終わりです。出てきていないOculusが登場する日も遠くはなくなってきたため、皆さん楽しみにしていてください。以上で、パフォーマンス改善は終了となります。最後までご覧いただきありがとうございました。弊社では全国各地の請負い(ご自宅)で作業協力頂ける、フリーランスエンジニアの方を常時探しております。ご興味ある方は、お気軽にお問い合わせ下さい。コメントをキャンセルメールアドレスが公開されることはありません。BlogFeathersFeathersHTMLJavaScript。