8GBRAM今后会成为安卓旗舰机的标配吗？看了运行内存测试你就一目了然！
针对这个问题，首先我们要明确一点，技术发展的趋势决定必须要增大RAM才能适应手机软硬件的发展需求。如果硬要给它规定一个意义的话，“大势所趋”可能是最贴切的。
那么手机RAM到底多大合适呢？有必要买6GB，甚至更高的8GB RAM的手机吗？8GB RAM今后会成为安卓旗舰机的标配吗？要明确这些问题的答案我们不妨先了解一下什么是RAM，嘿嘿！ RAM的全称是Random Access Memory，即随机存取存储器，也就是我们常提到的运行内存。而在手机中还有另一种内存，即Read Only Memory ，我们常说的存储ROM。 手机或者电脑的处理器是不能直接读取硬盘存储（ROM）数据的，因为相对CPU的处理速度，ROM的读取速率实在是慢的可怜，所以它需要通过RAM来间接完成这项任务。打个比方，ROM就相当于各种商品的工厂，而RAM就是一个容纳成品的大超市，充当工厂和消费者之间的一座中转站。理所当然，超市越大我们的选择越多元化，也更丰富。作为制约手机性能的重要指标，RAM的吞吐能力越强，也就更利于手机的运行。如果技术支持的话，手机RAM当然是越大越好。 手机RAM越大，同时运行的应用程序就越多；不同应用之间切换的速度也更快。作为与CPU交换的高速缓存数据区，RAM虽然不能长期存储数据，但是对于手机正常运行却是意义非凡。 手机RAM增大有其必然性和必要性 在简单地了解了RAM的作用和影响之后，我们再来看看当今手机RAM发展的必然性和必要性。 在IT产业领域有三大定理：摩尔定理、安迪比尔定理以及反摩尔定理。这三大定理很好地解释了RAM为什么会越来越大以及其必然性。 摩尔定理规定，当价格不变时，集成电路上可容纳的元器件的数目，约每隔18-24个月便会增加一倍，性能也将提升一倍。换言之，每一美元所能买到的电脑性能，将每隔18-24个月翻一倍以上。这则由摩尔在1975年提出的预测直到今天依旧没有被打破。 对于现在的手机来说，每两年硬件就要翻一番。而对于手机RAM来说，今明两年必定是8GB RAM的天下，因为6GB RAM在今天已经是旗舰手机的标配了。 而安迪比尔定理则从软硬件的关系层面进一步验证了大RAM的必然性。 “Andy gives, Billtakes away.（安迪提供什么，比尔拿走什么。）”安迪比尔定理让手机、电脑等产品从耐用品变成了消耗品，新的硬件的诞生，需要软件应用的支持，周而复始，软件容量越来越大，数量越来越多，需要调用更大的RAM，RAM变大已是大势所趋。
近几代Android系统内存占用情况，单位MB 简单地统计了一下最近几代Android版本的系统内存占用情况，结果还是非常直观，6年前的Android 4.0内存占用只有200-300MB左右，短短6年就翻了5、6倍，直到最新的Android 7.0竟然高达1.8GB！不仅系统如此，就连我们常用的微信也从开始的30多MB变成了几乎300MB的庞大体积。Andy gives, Bill takes away.软硬件不断升级的闭环短时间内不会被打破。 我们再来看看反摩尔定理又为手机企业验证了什么。反摩尔定理说，一个 IT 公司如果今天和十八个月前卖掉同样多的、同样的产品，它的营业额就要降一半。IT 界把它称为反摩尔定理（Reverse Moore’s Law）。 其实这个定理很好理解，就是一家公司如果赶不上摩尔定理的更新速度的话，那这家公司很难盈利。事实也是如此，“恰逢其时”总是比“相见甚晚”来得高明。所以旗舰机的RAM已经鲜有2、3GB的了，基本都是4GB起跳，今天6GB已经成为了标配。这不仅是用户的需求，也是IT技术发展的必然性。 好了，扯了一大堆，来看点实际的，现在普遍的智能手机的RAM都是4GB，这个大小的RAM能干什么呢？小编亲测了一下：（测试机为4GB RAM）只运行系统，不开任何APP：
打开微信、微博、浏览器、今日头条、百度贴吧、腾讯视频、QQ后：
在没有运行任何App的情况下，单系统就占了51%；而打开一些日常应用后，基本上就只剩下不到1GB的RAM，再打开个游戏基本就满了。从人们日常生活的使用习惯看，4GB对于轻度用户来说确实够用了。但是！如果你是个懒癌患者，很多天都不会清理内存的话，可能就会出现内存不足的情况了。不过针对这一情况，很多的手机厂商为了保持流畅度都在系统上做出了大胆的优化和调整，自动释放一些不使用的RAM，但是这样依然不够。 接下来，我们再分别用6GB RAM（用一加3T）、8GB RAM（一加5）跑一遍。 6GB，不开任何APP：
打开微信、微博、浏览器、今日头条、百度贴吧、腾讯视频、QQ后：
8GB，不开任何APP：
打开微信、微博、浏览器、今日头条、百度贴吧、腾讯视频、QQ后：
结果一目了然，在剩余内存方面，8GB也占有绝对的优势，8GB的剩余RAM还能让你干很多很多事。即使你懒，经常忘了清理也没关系，因为它足够的大。 所以说，如果你是个强迫症用户，总担心RAM不够用的话，买个6GB、8GB的旗舰手机，可能会让你在1年甚至更久不用考虑手机RAM问题。反之，如果你买了一个4GB甚至更小的3GB RAM的手机，以现在手机软硬件的发展速度，不出一年，甚至半年，你可能就要面对换手机的窘境，还不如一步到位，买个8GB的更合算，大家觉得呢？当然，再大的RAM也需要其他硬件的支持，一个优秀的CPU、GPU、一块大容量的ROM也是你需要考虑在内的。 只能说，RAM不断增大已经是大势所趋，大RAM才是未来的发展趋势，在下半年，8GB RAM一定会成为安卓旗舰机的标配。 PS：快用上Android 8.0的你，内存还够用吗？1.什么是OOM？
03-21 21:05:28.771: E/dalvikvm-heap(13316): Out of memory on a -byte allocation.
03-21 21:05:28.779: E/AndroidRuntime(13316): java.lang.OutOfMemoryError
这几句的意思是，我们程序申请需要byte太大了，虚拟机无法满足我们，羞愧的shutdown自杀了。这个现象通常出现在用到很多图片或者很大图片的APP开发中。通俗讲就是当我们的APP需要申请一块内存来装图片的时候，系统觉得我们的APP所使用的内存已经够多了。即使它有1G的空余内存，它不同意给我的APP更多的内存里，然后即使系统马上抛出OOM错误，而程序没有捕捉该错误，故弹框崩溃了。
2.为什么会有OOM？
因为android系统的app的每个进程或者每个虚拟机有个最大内存限制，如果申请的内存资源超过这个限制，系统就会抛出OOM错误。跟整个设备的剩余内存没太大关系。比如比较早的android系统的一个虚拟机最多16M内存，当一个app启动后，虚拟机不停的申请内存资源来装载图片，当超过内存上限时就出现OOM。Android系统的APP内存限制怎么确定？
2.1 Android的APP内存组成：
dalvik内存
native内存
2部分组成，dalvik也就是java堆，创建的对象就是就是在这里分配的，而native是通过c/c++方式申请的内存，Bitmap就是以这种方式分配的。（android3.0以后，系统都默认通过dalvik分配的，native作为堆来管理）。这2部分加起来不能超过android对单个进程，虚拟机的内存限制。
每个手机的内存限制大小是多少？
ActivityManager activityManager = (ActivityManager)context.getSystemService(Context.ACTIVITY_SERVICE)
activityManager.getMemoryClass();
以上方法会返回以M为单位的数字，不同的系统平台或设备上的值都不太一样，比如HTC默认24M, Galaxy36M, emulator-2.3 24M，等等。我的moto xt681是42M。3
上面取到是虚拟机的最大内存资源。
而对于head堆的大小限制，可以查看/system/build.prop文件。
dalvik.vm.heapstartsize
dalvik.vm.heapgrowthlimit = 48m
dalvik.vm.heapsize = 256m
heapsize参数表示单个进程heap可用的最大内存，但如果存在以下参数&dalvik.vm.headgrowthlimit =48m&表示单个进程heap内存被限定在48m，即程序运行过程实际只能使用48m内存。
2.2 为什么android系统设定APP的内存限制？
要使开发者内存使用更为合理。
限制每个应用的可用内存上限，可以放置某些应用程序恶意或者无意的使用过多的内存。而导致其它应用无法正常运行。Android是有多进程的，如果一个进程（就是一个应用）耗费过多的内存，其他应用就无法运行了。因为有了限制，使得开发者必须好好利用有限资源，优化资源的使用。
&屏幕显示内容有限，内存足够即可。
即使有万千图片千万数据需要使用到，但在特定时刻需要展示给用户看的总是有限的，因为屏幕显示就那么大，上面可以放的信息就是很有限的。大部分信息都是处于准备显示状态，所以没必要给予太多heap内存。也就是说出现
OOM现象，绝大部分原因是我们的程序设计上有问题，需要优化
。优化方法很多，比如通过时间换空间，不停的加载要用的的图片，不停的回收不用的图片，把大图片解析成适合手机屏幕大小的图片等。
多APP多个虚拟机davlik的限制需要。
android上的app使用独立虚拟机，每开一个应用就会打开至少一个独立的虚拟机。这样可以避免虚拟机崩溃导致整个系统崩溃，同时代价就是需要浪费更多的内存。这样设计保证了android的稳定性。
2.3 不是GC自动回收资源么，为什么还会OOM?
Android不是用GC会自动回收资源么，为什么app的那些不用的资源不回收呢？
Android的gc会按照特定的算法回收程序不用的内存资源，避免app的内存申请约积越多，但是gc一般回收的资源是那些无主的对象内存或者软引用的资源，或者更软引用的引用资源。比如：
Bitmap bt = BitmapFactory.decodeResource( this .getResources(), R.drawable.splash);
//此时的图片资源是强引用，是有主的资源。
//此时这个图片资源就是无主的了。gc心情号的时候就会去回收它。
SoftReference&Bitmap& softRef =
SoftReference&Bitmap&(bt);
其他代码...
当程序申请很多内存资源时，gc有可能会释放softref引用的这个图片内存。bt＝softRef.get()，此时可能得到的是null，需要重新加载图片。
当然这也说明了用软引用图片资源的好处，就是gc会自动根据需要释放资源，一定程度上避免OOM。
TIPS:编程要养成习惯，不用的对象设置为null。其实更好的是，不用的图片直接recycle。因为通过设置null让gc来回收，有时候还是会来不及。
2.4 怎么查看APP内存分配情况?
& & & &1 &通过DDMS中的heap选项卡监视内存情况：
Heap视图中部有一个叫做data object， 即数据对象，也就是我们的程序中大量存在的类类型的对象。
在data object一行中有一列是"Total Size", 其值就是当前进程中所有Java数据对象的内存总量。如果代码中存在没有释放对象引用的情况，则data object的"Total Size"值在每次gc后不会有美线的回落。随着操作次数的增加"Total Size"的值会越来越大。直到到达一个上限 后导致进程被kill掉。
2 &在App里面我们可以通过totalMemory与freeMemory：
Runtime.getRuntime().freeMemory()
RUntime.getRuntime().totalMemory()
3 &adb shell dumpsys meminfo com.android.demo
3. 常见避免OOM的几个注意点：
3.1 适当调整图像大小
。因为手机屏幕尺寸有限，分配给图像的显示区域有限，尤其对于超大图片，加载自网络或者sd卡，图片文件提及达到几M或者十几个M的：
加载到内存前，先算出该bitmap的大小，然后通过适当调节采样率使得加载的图片刚好，或稍大捷克在手机屏幕上显示就满意了：
BimtapFactory.Option opts =
BitampFactory.Option();
opts.inJustDecodeBounds =
opts.inSampleSize=computeSample(opts, minSideLength, maxNumOfPixels);
// Android 提供了一种动态计算的方法 computeSampleSize
opts.inJustDecodeBounds =
BitmapFactory.decodeFile(imageFile, opts);
catch (OutOfMemoryError err){
3.2 图像缓存
。在listview或Gallery等控件中一次性加载大量图片时，只加载屏幕显示的资源，尚未显示的不加载，移出屏幕的资源及时释放，采用强引用＋软引用2级缓存，提高加载性能。缓存图像到内存，采用软引用缓存到内存，而不是在每次使用的时候都从新加载到内存。
3.3 采用低内存占用量的编码方式
。比如Bitmap.Config.ARGB_4444比Bitmap.Config.ARGB_8888更省内存。
3.4 及时回收图像
。如果引用了大量的Bitmap对象，而应用又不需要同时显示所有图片。可以将暂时不用到的Bitmap对象及时回收掉。对于一些明确直到图片使用情况的场景可以主动recycle回收
App的启动splash画面上的图片资源，使用完就recycle。对于帧动画，可以加载一张，画一张，释放一张。
3.5 不要在循环中创建过多的本地变量
。慎用static，用static来修饰成员变量时，该变量就属于该类，而不是该类实例，它的生命周期是很长的。如果用它来引用一些内存占用太多的实例，这时候就要谨慎对待了。
3.6 自定义堆内存分配大小
。优化Dalvik虚拟机的堆内存分配。
ClassName{
Context mC
4. App使用图片时避免OOM的几种方式：
直接null或recycle
对于app里使用的大量图片，采用方式：使用时加载，不显示时直接置null或recycle。
这样处理是个好习惯，记本可以杜绝OOM，但是缺憾是代码多了，可能会忘记某些资源recycle。
而有些情况下会出现特定图片反复加载，释放，再加载等，低效率的事情。
& 4.2 简单通过SoftReference引用方式管理图片资源
建个SoftReference的hashmap
使用图片时先查询这个hashmap是否有softreference， softreference里的图片是否为空，
如果为空就加载图片到softreference并加入hashmap。
无需再代码里显式的处理图片的回收与释放，gc会自动处理资源的释放。
这种方式处理起来简单实用，能一定程度上避免前一种方法反复加载释放的低效率。但还不够优化。
& 4.3 强引用＋软引用二级缓存
Android示范程序ImageDownloader.java, 使用了一个二级缓存机制。就是有一个数据结构直接持有解码成功的Bitmap对象引用，同时使用一个二级缓存数据结构保持淘汰的Bitmap的softreference对象，由于softreference对象的特殊性，系统会再需要内存的时候首先将softreference持有的对象释放掉，也就是说当vm发现可用的内存较少需要出发gc的时候，二级缓存中的bitmap对象将被回收，而持有一级缓存的bitmap对象用于显示。
其实这个解决方案最为关键的一点是使用了一个比较合适的数据结构，那就是LinkedHashMap类型来进行一级缓存Bitmap的容器。由于LinkeHashMap的特殊性，我们可以控制其内存存储对象的个数并且将不在使用的对象从容器中移除，放到softreference二级缓存里，我们可以在一级缓存中一致保存最近被访问到的bitmap对象，而已经被访问过的图片在LinkedHashMap的容量超过我们预设值时将会把容器中存在的时间最长的对象移除，这个时候我么可以将被移除的LinkedHashMap中的放到二级缓存容器，而二级缓存中的对象管理就交给系统来做了，当系统需要gc时就会首先回收二级缓存容器的Bitmap对象了。
在获取图片对象时候先从一级缓存容器中查找，如果有对应对象并可用直接返回，如果没有的话从二级缓存中查找对应的SoftReference, 判断SoftReference对象持有的Bitmap是否可用，可用直接返回，否则返回空。如果二级缓存都找不到图片，那就直接加载图片资源。
& &4， LruCache &+ sd的缓存方式
5. 两种容易OOM的场景建议：
& &5.1 网络下载大量图片
比如微博客户端： 多线程异步网络，小兔直接用LRUCache+SoftRef+Sd，大图按需下载：
& & 5.2 对于需要加载非常多条目信息的listview，gridview等的情况
在adapter的getView函数里有个convertView参数，告知你是否有可重用的view对象。 如果不使用convertView的话，每次调用getView时每次都会重新创建view，这样之前的view可能还没销毁，加之不断的新建view势必会造成内存剧增，从而导致OOM。另外在重用convertView时，里面原有的图片等资源就会变成无主的了。
这里Google官方推荐使用："convertview＋静态类viewholder"
官方给出解释是：
a 重用缓存convertView传递给getView()方法来避免填充不必要的视图。
& b 使用ViewHolder模式来避免没有必要的调用findViewById；因为太多的findViewById也会影响性能。
附ViewHolder类的作用：ViewHolder模式通过在getView方法返回的视图的标签（tag）中存储一个数据结构。这个数据结构包含了指向我们要绑定数据的视图的引用，从而避免每次调用getView()的时候调用findViewById();
6 申请超过内存限制的内存分配方式：
&6.1 从Native C分配内存。使用NDK(本地开发工具包)和JNI, 它可能从C级(如malloc/free或新建／删除)分配内存，这样的分配是不计入24MB的限制。这是真的，从本机代码分配内存是为了java方便，但它可以被用来存储在ram的数据（即使图片数据）的一些打击呢。
&6.2 使用OpenGL的纹理。纹理内存不计入限制，要查看你的应用程序确实分配了多少内存可以使用android.os.Debug.getNativeHeapAllocatedSize(), 可以使用上面介绍的两种技术的Nexus之一，我可以轻松地为一个单一的前台进程分配300MB-10倍以上的默认24MB 的限制，从上面看来使用native代码分配内存是不在24MB的限制内的（开放的GL的质地也是使用native代码分配内存）。
但是，这两个方法的风险就是，本地堆分配内存超过系统可用内存限制的话，通常都是直接崩溃。
记住登录状态
重复输入密码“大胃王”是如何炼成的 Android手机内存为何会缩水_产品_电脑爱好者
“大胃王”是如何炼成的 Android手机内存为何会缩水
电脑爱好者
条评论 标签：
随着央视炮轰智能手机存储容量缩水的问题后，这一老生常谈的话题再度喧嚣尘上。那么，谁才是导致手机内存缩水的&大胃王&呢？借此机会就让我们重新调查一番吧。
央视向存储容量开炮
5月中旬，央视财经就6款16GB手机实际可用存储空间的大小进行了调查，最终发现容量最大的小米3实际只有12.38GB，而容量最小的联想K900竟然仅有7.88GB（图1）。排除二进制和十进制算法的误差，16GB换算下来的空间也应在14.88GB左右。由此，专家将问题归结于手机预装且无法卸载的第三方APP。那么，事实果真如此吗？
谁是手机内存大胃王
首先我们需要了解智能手机参数中的&两个内存&：RAM和ROM。其中，RAM就是运行内存，就好似PC中的内存条；而ROM就是央视炮轰的存储空间，相当于PC中的硬盘。手机厂商在标注产品参数时，往往也会选择2GB RAM和16GB ROM的格式。好了，既然手机厂商在参数上明明注明内置了16GB的存储空间，为何连接电脑后（或是在&系统设置&存储&选项中查看）却只能被系统识别出10GB左右的空间？缩水背后隐藏的&大胃王&到底是谁？
答案很简单。以Android手机为例，16GB的ROM空间实际上是由三大部分构成（图2），它们分别是：
系统分区----用于存放Android系统（Android4.x版系统至少500MB以上）、还原备份（300MB左右）、刷机Recovery资源（约20MB～50MB）、系统级APP（安装在此空间的APP需要Root权限才可卸载）以及交换空间、硬件底层空间等等，加在一起约1.5GB～2GB。这部分空间就好似PC上安装在C盘中的Windows系统和硬件驱动程序，以及用于存放一键恢复镜像的隐藏分区。
程序分区----用于存放随机预装的第三方APP（用户可卸载），你自己下载的所有APP主程序都会安装到这个空间内，手机厂商通常会为此分区预留1GB～3GB的存储空间。当该空间被占满后，你再安装APP时会出现无空间安装的报错提示。我们可以将其理解为PC C盘里的&Program Files&文件夹，只是你所安装的所有程序默认只能安装于此且无法修改路径。&系统分区＋程序分区&的总和就是电脑C盘的全部空间。
存储分区----这才是当手机连接PC后所识别出来的&移动硬盘&，小米3的12.38GB和联想K900的7.88GB就是存储分区。这部分空间可以由用户自由支配，可存放大型游戏的数据包、音乐、图片、视频，可像U盘一样随意折腾。换做PC领域，存储分区就好似D盘、E盘、F盘等非系统分区。
由此可见，导致Android手机存储空间缩水的&大胃王&实际上就是系统分区和程序分区，虽然无法被用户直接利用，但却承担着非常重要的角色。
冤枉还是&理所应当&
如果按照16GB手机的存储空间就必须达到14.88GB的理论会出现什么问题？答案很简单，相当于你买了一部连DOS都没有安装的PC，而且你也无法自行安装系统，和&砖头&没啥区别。OK，那我们放宽条件，保留系统分区（安装了Android系统）并将程序分区压缩至最小可以吗？答案也是否定的，这就相当于你只给PC的C盘划分了15GB存储空间，而Windows系统和驱动就已经占用了14GB，此时你只有1GB空间来安装软件（Android的存储机制让你无法将APP安装在C盘以外的空间）。这意味着你不能安装大于1GB的程序，而且想装新软件前必须卸载老软件来释放空间。
总之，对Android手机来说系统分区是没有商量的，而程序分区容量的划分则是可选项。问题是，程序分区大了，存储分区自然就小了（图3）。因此，厂商对程序分区的态度就直接反映到了央视所报道的存储空间缩水的问题之上。
03----程序分区并非越小越好，太小了就没有空间安装更多的APP了
目前Android平台的中小型游戏大都在50MB上下，少数大型游戏（无需数据包，APK直装型）则在100MB以上。矛盾就此出现了：
如果你是游戏控，喜欢同时安装无数游戏和程序，如果程序分区空间小于2GB根本不够用（图4）；
04----当程序分区空间不足时，我们可以将部分APP&移动到存储卡&，只是并非所有APP均支持数据转移
如果你喜欢听音乐看视频，但手机却提供了3GB程序分区，这意味着留给你的存储分区所能保存的歌曲和视频文件数量将大幅缩水；
看似矛盾的话题，难道就没有解决方案吗？其实并不复杂，如果手机支持存储卡扩充，则可适当为程序分区加大空间保证安装更多的APP，牺牲的存储分区空间借由存储卡弥补。如果手机不支持存储卡且仅内置16GB甚至8GB存储空间，那就将程序分区设定在&够用就好&的档位（如1.5GB～2GB），保证用户有足够的可支配的存储空间，或是购买无线存储器，以Wi-Fi的形式无线扩容。
至此，相信大家已经对Android手机存储空间缩水的问题有了较为深刻的了解。从原理来讲，手机厂商是无辜的，Android的存储机制必然导致存储空间小于实际的ROM标称容量。但是，厂商有没有在宣传上注明&实际可用容量&就体现出人性化与否的态度了。
为什么PC用户从不抱怨明明500GB硬盘却只有400GB的可用空间？因为PC上我们可以随意更换系统卸载程序、自定义不同分区的容量。Android系统的存储机制虽然能用PC翻译，但二者最大差别是用户失去了自定义的权限，厂商拍拍脑门就可随意修改程序分区空间或是预装很多无用的第三方APP。如果哪一天可以在首次开机的设置向导界面上，由用户自行划分不同分区的容量，也许就不会再有今天的口水仗出现了。
　　　　　　　　　　
您可能感兴趣的文章：
增值电信业务经营许可证编号：合字B2-
海淀分局备案编号：，
Copyright(C) .cn,All rights reserved
法律顾问:周涛律师&&
&&（总）网出证（京）字第047号