古いプロジェクトとランダムなコード フラグメントの多くを収集し、コードベースに整理しています。小さなライブラリが大きなライブラリよりも効率的かどうかを調べようとしています。
コードベースは、ブラウザ アプレット、デスクトップ アプリケーション、およびサーバー アプリケーションで使用されます。どうもありがとう。
2 に答える
3
私の知る限り、クラス ローダーとセキュリティ マネージャーは、特定のクラスを初めてロードするときに、少なくとも 1 回はパフォーマンスに影響します。
JVM は、関連するすべてのクラス (最終的には JAR) を起動時にメモリにロードします ( import.
リフレクションなどを使用している場合、これが「オンデマンドのロード」が行われる方法です。
しかし、私が伝えたかった結論は、もし私があなただったら、コードをできるだけ多くの断片に分割するということです.
これにより、長期的には保守性が大幅に向上し、その点はすべてのソフトウェア ライフ サイクルにおいて非常に重要です。
幸運を！
于 2012-10-25T00:32:17.890 に答える
1
個人的には、コード ライブラリを機能ごとにまとめようとしています。
単純なコンソールまたは Web プロジェクトを実行している場合、すべての UI ライブラリ コードを一緒にドラッグしたくはありません。同様に、私はいくつかの UI ライブラリを持っており、それらはユーティリティ、コンポーネント、アニメーション/アドバンスまたは特殊ライブラリなどに分割されています。
私にとって、これは多くの小さな非常に特殊なライブラリを作成する傾向があります (一部は他のライブラリに依存しています - たとえば、私のライブラリの多くは同じコア/ユーティリティ ライブラリに依存しています) が、可能な限り大きな柔軟性を提供します。多くの、さもなければ役に立たない荷物をドラッグする必要なく、現在のプロジェクトをサポートするのに最適なライブラリを選択してください。
管理が少し複雑になります (物事がどこにあるかを覚えておく必要がありますが、名前を付けてグループ化する方法に注意すれば問題ありません)。また、ビルド プロセスが長くなる可能性があります (どのビルド システムを使用するかによって異なります)。使用する）。
実行の観点からは、それが大きな違いを生むとは思いません（ネットワーク展開などを行っている場合は、サイズが重要です;））
私見では
プロジェクトを小さなサイズに保つのに役立ちます。モノリシックなライブラリの数が少ない場合よりも、自重がはるかに少ないためです...（これは作業中の状況であり、完全な苦痛です）。
于 2012-10-25T00:36:31.470 に答える