0

簡単に言えば、私の質問はほとんどタイトルにあります。最初の大きなプロジェクトがあり、1 つの大きなファイルに 11,000 行のコードを記述した後、しばらくしてフラッシュを試した後、メモリの問題が発生しました。ゆっくりと遅くなります。できるときは常にコンテナをクリアし、不要なときはリスナーを削除しても、何もできなくなるまでダウンします。

手続き型、知らない人のために、私はすべてを大きなメイン関数に持っており、その中に何百もの他の関数があります。

おっとロジックは、この時点で試して理解するには少し大きすぎるように感じます。これまでの手続き型は、私にとってはるかに自然でした...

メモリ不足を防ぐためのヒントはありますか?

4

3 に答える 3

2

それを分解するためにオブジェクト指向プログラミングは本当に必要ありません。

物事をグループ化および分離できる場所のロジックを少し適用するだけです。また、コード行が繰り返される可能性も非常に高くなります。

まず、行のグループ化を開始します。それらをさまざまな関数内に配置し、メインで呼び出します。

すべてをチャンクに落とし込んだら、関数をクラスにグループ化することも考え始めることができます。しかし、少なくとも最初のステップで問題は解決したはずです。

于 2013-03-18T08:25:50.427 に答える
0

オブジェクト指向プログラミングを使用しないと、問題を解決するのは困難です。ところで、C スタイルのコーディングは通常「命令型プログラミング」と呼ばれます。

悪いニュースは、1 つのファイルに 11,000 行のコードがあるということは、すべてのコードが 1 つの翻訳単位内にあることを意味するため、コーディングしたものはすべて常にメモリ内にあるということです。

クラスに分割すると、個々のクラス インスタンス (オブジェクト) が要件に基づいて作成および破棄されるため、必要なだけのメモリが占​​有されます (静的ではなく、拡大および縮小)。

最後に、あたかも C であるかのように as3 を使用することは、長期的には他の多くの点であなたを傷つけます。ですから、OOP を学び、モノリシック コードをオブジェクトに分割してください。

于 2013-03-18T08:14:29.597 に答える
0

結局のところ、これを悪い習慣と呼ぶと、VM (仮想マシン) に息を吹き込む機会を与えない可能性があります...つまり、手順が状態のポーリングのようなループで毎回ビジー状態になる場合、VM が状態を見つけられない可能性が高くなりますガベージコレクトの機会。これは災害です。

そのため、実行している場合はイベントをポーリングしないでください。グランド プロシージャ (すべての先見者:) を取り除き、必要に応じてイベント ハンドラによって中央監視プロシージャが呼び出される別のアーキテクチャを試してみてください。

そして落ち着いたら、商品を売ってお金持ちになりましょう。おっと、できるだけ早く学びます:)

于 2013-03-18T08:34:36.587 に答える