私はいくつかのリサーチを行っていますが、これが原因でメモリリークが発生する可能性がある場合は、まだ100%確実ではありません。私はボタンビュー(v.context)を使用しています。私はコンテキストが静的なものとして保存されていないので私はOKだと思いますが、可能であればフィードバックをお願いします。私が目にしている主な問題はOSMonitorです。(M)の値はUP、UP、UPになります。ウィジェットのオープン/クローズとスクリーン回転のたびに。静的メモリリーク(コンテキストあり)
32M 43M 61M 77M 等...
私は(M)はメガバイトまたはMegebitsであるかはわかりません。これがスタックに基づいている場合、ほとんどのハイエンドデバイスはスタック(または何か)の32/48 MBに制限されているので、私はMegebitsのperhpasと仮定しています。
フィードバック/余分な目をありがとう!
これはところで、市場でのバナーアプリです...
public class Globals {
public static final String PREF_NAME = "BannerPreferences";
public static final int MAX_TEXT_SIZE = 20;
// refresh ALL widgets loaded on the user's screens
// this could be for removing or adding 'pendingIntents or during bootup
public static void refreshAllWidgets(Context context) {
Logger.d("BANNER", "Globals:refreshAllWidgets");
invalidateWidgets(context, BannerWidget.class); // 1x4
invalidateWidgets(context, BannerWidget1x2.class);
invalidateWidgets(context, BannerWidget2x2.class);
}
// there has to be a API way to do this!! Until then, just loop thru all
// widget_provider classes..
private static void invalidateWidgets(Context context, Class<?> cls) {
ComponentName comp = new ComponentName(context, cls);
AppWidgetManager appWidgetManager = AppWidgetManager.getInstance(context);
int[] appWidgetIds = appWidgetManager.getAppWidgetIds(comp);
for (int i = 0; i < appWidgetIds.length; i++) {
BannerWidgetBase.updateAppWidget(context, appWidgetManager, appWidgetIds[i]);
}
appWidgetIds = null;
}
メモリーがリークしていると思われる場合は、DDMSを使用してヒープ・ダンプを生成し、Eclipse MATユーティリティーで結果を分析してください。 – CommonsWare
@CommonsWare私はそれを使用するためのガイドに従ったが、少し圧倒される。私は変換し、それは日食を使用して開いたが、私はかなりデータを使用するcouldnt。多くの方法に。 – kenyu73