Articles of 内存

为什么Android 4.0 / Ice Cream Sandwich会分配如此多的堆内存?

我注意到在我的Galaxy Nexus上, android.content.res.Resources正在分配大约11MB。 我发现这是因为我正在使用DDMS和“ Dump HPROF file ”选项来分析事物。 所以,我花了两个小时试图查看分配是由于我的代码或支持库中的某些内容。 我删除了所有数据,大量的类,我的所有库,并没有看到任何变化。 在活动的onCreate()方法开头的代码中放置断点后,它显示已经存在11MB分配。 在彻底混淆之后,我决定连接我运行CM7的root用户Nook Color,以查看它为同一应用程序的初始内存使用情况报告的内容。 由MAT报告的最坏情况记忆“问题可疑”的重量仅为896KB。 ICS是头重脚轻的吗? 我在这里错过了什么吗? 据我所知,我的应用程序运行正常,但堆使用率表示97%已满,让我担心潜在的故障。 如果它有帮助,MAT表明消耗所有内存的主要对象是BitmapDrawables , NinePatchDrawables和NinePatchDrawables 。 我不明白这些分配来自何处。

Android Honeycomb中的Bitmap#recycle()实际上做了什么?

我正在为Android Honeycomb编写一个内存密集型应用程序,我一直非常小心地尽可能recycle()未使用的Bitmap ; 实际上,这对于应用程序来说是必要的,因为Bitmap不断地循环进出内存。 但是,我刚刚在Activity实现了onConfigurationChanged() ,因此(出于多种原因)我试图在onStop()放置内存释放例程。 目前我的onStop()方法: 设置一些View以显示默认的Drawable ; 在这些View之前使用的Bitmap上调用recycle() ; nulls对Bitmap的引用。 不幸的是,使用Eclipse内存分析器,似乎根本不会影响内存使用情况 。 你可以想象,我已经做了很多努力以一种名义上垃圾收集的语言来释放资源,我希望能有更多的效果。 所以我的问题是: recycle()做了什么? 它是否实际触发垃圾收集,或者系统是否会保留在内存中 – 即使你调用System.gc()直到它感觉需要摆脱某些东西? NB我知道Bitmap实际上并没有保存在常规堆中,但我认为调用recycle()足以确保它们被从本机堆中删除。 答案的一部分 我发现如果ImageView包含已经回收的Bitmap , Bitmap数据仍会保留在内存中,直到在ImageView上调用setImageBitmap(null) 。 如果调用setImageResource(…)或setImageDrawable(…)甚至可能就是这种情况(它们是在一个相对较小的九个补丁中加载 – 但是,MAT分析显示这并没有删除大的Bitmap ,这是包含在ImageView的私有成员中。 简单地在onStop()上调用此函数已经从我们的应用程序堆中剔除了大约10MB。 显然,这可能不是预装Honeycomb版本的Android的情况。

Android NDK:Dalvik Heap和Native Heap – 两者之间的区别

我知道在Android平台上有Dalvik(JVM)堆和Native堆。 并且Dalvik GC在本机堆上没有工作。 但我不确定这是如何工作的,我的意思是Android操作系统是如何将它们分开的? 可能的情况1:由独立的内存硬件组成(我不相信太多) 可能的情况2:Android OS对两个堆都有固定的内存量 可能的情况3:Android OS必须在必要时将部分Dalvik内存堆分配为本机堆,因此本机堆和Dalvik堆的大小是灵活的。 哪一个是真的,还是我没有提到的可能性?

为什么位图大小在内存中比在Android上的磁盘大?

我的SD卡上有一个2448×3264图像,消耗1,667,072字节,但当我将其作为位图加载并使用getRowBytes()*getHeight()计算其大小时,我最终得到15,980,544字节。 为什么会发生这种情况?如何计算文件的实际大小?

EditText导致内存泄漏

介绍: 我有一个具有以下结构的应用程序:ActionBar up top(ActionBarSherlock)ViewPagerIndicator(用于标签)ViewPager(hosts Fragments) 我有一个问题,我的一个片段导致相当大的内存泄漏。 我将问题缩小到以下情况: 导致泄漏的碎片除了在onCreateView方法中膨胀布局外什么都不做。 这是通过以下方式完成的: return inflater.inflate(R.layout.filter_auctions_fragment, container, false); 这里没什么不寻常的。 布局文件中只包含一个ScrollView , LinearLayout和两个EditText (包含更多通常的内容,但我将问题缩小到这些视图以使其变得简单)。 现在用于添加片段的代码:mTabsAdapter.addTab(tabName,ProblematicFragment.class); mTabsAdapter是mTabsAdapter的一个实例, mTabsAdapter是一个扩展支持库的FragmentPagerAdapter的类。 这是相当标准的,所以我不包括使这个问题尽可能短的来源。 现在有趣的部分: 当我来回旋转设备几次时,堆会发生这种情况: 12-28 12:26:27.180: D/dalvikvm(18841): GC_CONCURRENT freed 530K, 7% free 10701K/11436K, paused 4ms+7ms, total 58ms 12-28 12:26:27.180: D/dalvikvm(18841): WAIT_FOR_CONCURRENT_GC blocked 24ms 12-28 12:26:28.270: D/dalvikvm(18841): GC_CONCURRENT freed 737K, 8% free 11048K/11964K, paused 4ms+5ms, total […]

ArrayList.clear()方法是否释放内存?

如果我没弄错的话,ArrayList包含存储位置的值,在这些位置中存储了你添加到List中的variables。 因此,我的假设是,当您调用ArrayList.clear()方法时,它只释放上述值(内存位置),但不会释放这些内存位置本身。 我将尝试用一个例子来说明这一点: 假设您已拥有内存的当前状态: [Memory location] (type of variable) *value* [1000] (int) 32 [1002] (int) 12 [1003] (float) 2.5 然后将它们添加到列表myList中,因此它包含指向1000,1002,1003内存位置的指针。 当您调用myList.clear()时,指针将无效,但内存位置1000,1002,1003仍将包含先前给定的值。 我错了吗?

分配游标时内存不足

我有一个我无法弄清楚的记忆问题。 我有一个类可以完成所有数据库检索工作。 我遇到的错误如下: android.database.CursorWindowAllocationException: Cursor window allocation of 2048 kb failed. # Open Cursors=733 (# cursors opened by this proc=733) 执行此操作时发生内存分配错误: mDatabaseInterface.getGraphForLevel(level); 我知道这是一个漏洞,因为我大约每2.5秒调用一次这种方法,并且5或6次首次呼叫很容易通过。 现在这里是我的DatabaseInterface类中的方法: public Graph getGraphForLevel(Level level) { //get the nodes ArrayList nodes = new ArrayList(Arrays.asList(this.getNodesWithLevel(level))); //get the edges ArrayList edges = new ArrayList(Arrays.asList(this.getEdgesWithNodes(nodes))); return new Graph(nodes, edges); } public Node[] getNodesWithLevel(Level level) { […]

Android如何获得设备的总内存RAM?

我可以获得总可用内存: ActivityManager activityManager = (ActivityManager) getSystemService(ACTIVITY_SERVICE); MemoryInfo memoryInfo = new ActivityManager.MemoryInfo(); activityManager.getMemoryInfo(memoryInfo); memoryInfo.availMem; 但是,如何获得设备的总内存(RAM)? 我读过: 如何在Android中发现我的应用程序的内存使用情况? 它似乎没有添加pidMemoryInfo.getTotalPss()给我总内存。

凌空出现内存错误,奇怪的分配尝试

有时随机Volley在启动时崩溃我的应用程序,它在应用程序类中崩溃,用户无法再次打开应用程序,直到他们进入设置并清除应用程序数据 java.lang.OutOfMemoryError at com.android.volley.toolbox.DiskBasedCache.streamToBytes(DiskBasedCache.java:316) at com.android.volley.toolbox.DiskBasedCache.readString(DiskBasedCache.java:526) at com.android.volley.toolbox.DiskBasedCache.readStringStringMap(DiskBasedCache.java:549) at com.android.volley.toolbox.DiskBasedCache$CacheHeader.readHeader(DiskBasedCache.java:392) at com.android.volley.toolbox.DiskBasedCache.initialize(DiskBasedCache.java:155) at com.android.volley.CacheDispatcher.run(CacheDispatcher.java:84) “diskbasedbache”试图分配超过1千兆字节的内存,没有明显的原因 我怎么能让这件事不发生? 它似乎是Volley的一个问题,或者可能是基于自定义磁盘的缓存的问题,但我没有立即看到(从堆栈跟踪)如何“清除”此缓存或执行条件检查或处理此exception 洞察力赞赏

关于android中最大堆大小和可用内存的两个问题

我看到堆大小会随着应用程序的需要自动增加,直到手机的最大堆大小为止。 我还看到最大堆大小因设备而异。 所以我的第一个问题是,Android设备上的典型Max Heap大小是多少? 我已经在一部手机上测试了内存分配,该手机能够使用超过40mb的堆,而另一部手机在20的mbs中发出OutOfMemory错误。 常用设备中最低的是什么,普通设备上最高的是什么? 有标准还是平均? 第二个问题,更重要的一个问题,是如何确保您能够使用每台设备可用的资源,但避免使用太多? 我知道有一些方法,比如onLowMemory(),但这些方法似乎只适用于整个系统内存,而不仅仅是特定应用程序的堆。 有没有办法检测设备的最大堆大小,还检测可用堆内存何时达到应用程序的低点? 例如,如果设备仅允许最大堆24mb并且应用程序接近分配的限制,那么它可以检测并缩小。 但是,如果设备可以舒适地处理更多,它将能够利用可用的东西。 谢谢