開発デバイスが通常のデバイスよりも多くのリソースを提供するのはなぜですか?


9

私は第4世代のiPod Touchと会社の第5世代のiPod touchで動作するアプリを作成しました。

開発者以外のデバイスがアプリを実行した後に発生するクラッシュを発見したとき、私たちはリリースしようとしていました*。

「開発者用デバイス」として登録されたデバイスにより、アプリはより多くのリソースを使用できるようになるという考えが浮上しました。存在する理由を考えることができなかったので、これは私には正しくないようです。建物またはプロビジョニングプロファイリングの問題である可能性が高いように感じます。

しかし、それは議論を促しました。そもそも、ゲームコンソール開発キットなど、ターゲットプラットフォームよりも多くの機能を持つデバイスが存在するのはなぜですか。もちろん、プログラムのストレステストを行うのは良いことですが、ターゲットプラットフォームのより正確な表現が意味をなさないのではないでしょうか。

TL; DR-開発キットにターゲットプラットフォームよりも多くのリソースがあるのはなぜですか?

*開発者以外のデバイスが第3世代以上の場合。アプリとxcodeがインストールされているコンピューターから直接ではなく、サーバーからアプリをダウンロードするiOSデバイス。

似たような別の質問があることに注意してください。ただし、シミュレータについて質問しているため、実際には異なります。シミュレータと実際のデバイスの使用には大きな違いがあることを理解しています。


7
@gnat-この投稿は、iPhoneアプリをテストする必要がある理由の複製ではありません。シミュレータと実際のデバイスの使用には大きな違いがあることを理解しています...
カタマリタコ2013

回答:


8

開発環境(スタンドアロンJavaアプリケーションでも、モバイル環境でも、組み込みデバイスでも)には、通常、リモートデバッグ、拡張ロギング、および環境の他のタイプの内部観察(通常は不要なもの)を実行する機能があります。プロダクション組み込みデバイスにロジックアナライザーのすべてのフックを追加します)。

これらの追加のものは、追加のリソースを必要とします。vmまたはその他のリモート環境に対してリモートデバッガーを開くと、もう一方のリソースが消費されます。厳しく制限されたモバイルの領域では、これらの追加リソースにより、標準アプリケーションに許可されている制限を超える可能性があります。したがって、追加のロギングまたはデバッグを開始するときにリソース制限に達しないように、より多くのリソースが開発環境に提供されます。

これは、本番環境のミラーで常に何かをテストする必要があるという点までさらに進んでいます。開発者のマシンで微調整やさまざまな変数を使用して動作することを信頼するだけでは、本番環境で正しく動作することを確認するのに十分ではありません。


1
はい、QAは常に開発環境ではなく、エンドユーザー環境でテストする必要があります。

数年前、私は2つの完全に異なるCPUボードを開発しなければならないプロジェクトに関わっていました。私が深く関わっているボードを担当したハードウェアエンジニアは、彼のボードにたくさんのテストコネクタを配置し、デバッグフェーズの保険をかけて、何でもプローブできることを確認しました。彼は不動産とお金を浪費するために多くの静態をとりました。他の男はそのようなお金と不動産を無駄にしませんでした。おかしなこと:ボードにコネクタは必要ありませんでした。他のボードを統合することは絶対に悪夢だったと報告されています。「保険」を考えてください。
John R. Strohm 2013

@ JohnR.Strohm開発用としては、プローブが適しています。開発ボードとは異なる製品ボードを使用するように設計されている場合は、開発製品で成功した後、製品製品で再度テストする必要がある(そして必要に応じて調査する)必要があると私は言っています。

これは、典型的な「開発キット」にとって非常に理にかなっています。好奇心から、iOSの場合、どのiDeviceも「開発者デバイス」として使用できます。同じハードウェアの2つの部分でどのように違いがあるのですか?
カタマリタコ2013

1
@Katamaritacoは、同じ物理デバイスであるという理由だけで、アプリケーションがiOS内で同じ権限を持つことを意味しません。リモートデバッグなどの機能により、アプリケーションがアクセスできるリソースが変わる場合があります。

5

それはあなたが後で最適化できるリソース貪欲な概念実証を作成することを可能にします。

メモリ制限を5バイト超えるため、アプリのクラッシュには意味がありません(リリースのスペースを節約するためにオプティマイザを設定することで解決できますが、デバッグバージョンを実行しています)。

テスト中にコンシューマの制限を超えると、警告がログにポップアップ表示されるので、ここでは便利です。


1

それは部分的には「信頼」の問題です。開発者は自分が何をしているかを知っていると想定されているため、デバイスとそのすべてのリソースへの自由なアクセスが与えられます。これは、未使用のリソースが無駄なリソースである小規模な企業や開発チームにとって大きな助けになります。

大規模な企業環境、または特に一般市民では、セキュリティの懸念とリソースを必要とする他のアプリケーションとうまくやり取りする必要があるため、この種のアクセスは法的責任となります。

これは本当に新しいアイデアではありません。作業中のマシンが2台あります。開発者のマシンでは管理アクセス権がありますが、インターネットから隔離されています。私がメール、Office、インターネットアクセスに使用している他のマシンでは、プログラムをインストールすることすらできません。

これが、開発前のデバイスでアプリケーションを展開する前にテストして、正常に動作することを確認する必要がある理由です。:)


0

iOSでは、開発が有効になっているデバイスを使用して、デバッグビルドを直接実行できます。これには、リリースビルドとは異なるコンパイラバグのセットが含まれている可能性があります。また、デバッグのnubの下でアプリを実行できます。また、さまざまなスレッドやリークされたメモリのバグを表示/非表示にすることもできます。

開発デバイスはデバッグ機能なしではあまり役に立ちません。デバッグ機能のあるユーザーデバイスは、(さらに)アプリとアプリデータのセキュリティ問題を提起します。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.