フラッシュアプリケーションをリリースモードではなくデバッグモードでリリースして、アプリのリリース後にtrace()の結果を確認したいと思います。
デバッグモードによって処理速度が少し遅くなることは気にしません。
処理速度を除いて、デバッグモードでコンパイルされたフラッシュアプリケーションをリリースすることには不利な点がありますか?
デバッグモードが原因で、アプリが例外をスローしたり、アプリのユーザーのFlash Playerがクラッシュしたりする可能性はありますか?
2 に答える
ここにいくつかの欠点があります。いくつかの簡単なテストを行いましたが、それがさまざまなプレーヤーによって引き起こされたものかどうか、追加のメモリ/ファイルサイズの値が線形に増加するのか、そのレベルに留まるのかがわからないため、実際には何も証明されません。彼らはただ違いがあることを示しています。
- ファイルサイズの増加
- 1行でテスト済み(mxmlc 4.5.1)の空のドキュメントクラス:
-debug=false
:550バイト-debug=true
:667バイト
- コードの各行に追加の行番号命令を追加します(おそらく各宣言/ステートメント/式に対しても)
- 1行でテスト済み(mxmlc 4.5.1)の空のドキュメントクラス:
- プロジェクト構造が含まれています:.asファイルへのフルパス。
- プライバシーに関する懸念の可能性(ローカルユーザー名が表示される可能性があります)
- 内部プロジェクト名を表示します。パスで使用されている場合は内部バージョンである可能性があります
- おそらく使用済みのOSおよび/またはIDEを示しています
- メモリ消費量の増加
- タスクマネージャーを監視する非常に簡単なテスト:ローカルオブジェクトを作成するforループ
- デバッグ:〜6300k〜7400k
- リリース:〜5800k-6900k
- タスクマネージャーを監視する非常に簡単なテスト:ローカルオブジェクトを作成するforループ
- 遅い(質問ですでに述べたように)
ここでセキュリティが問題になるかどうかはわかりません。トレースステートメントでは、メモリから抽出できなかったものや、逆コンパイルによって再構築できなかったものは何も明らかにならないためです。トレースの存在は、それがアプリケーションの重要な部分である可能性があることを示している可能性がありますが、一般に、非デバッグバイトコードでさえそれらのトレース命令が含まれています。ただし、逆コンパイラーは行番号を使用して、よりきれいなコードを作成できます。
@kapepの答えは、デバッグモードがswfに対して行うことについて正しいです。
ただし、トレースにデバッグモードを使用する必要はありません。リリースモードでコンパイルし、次のような別のデバッグツールを使用します。
- モンスターデバッガー
- アルコンロガー
- ..。
また、ロギングフレームワークを使用して、外部ロガーによってキャッチされたものだけでなく、通常のトレースステートメントも使用することもできます。
私はここでこれをお勧めできます:parsley + spicelib
ここに短いマニュアルがあります:http ://www.spicefactory.org/parsley/docs/2.0/manual/logging.php#intro