android內存限制

㈠ 安卓的內存佔用

相信不少朋友有這樣的疑問，為什麼手機4GB運行內存還卡？這到底應該誰背鍋？看完這篇文章你就懂了。

2018年，主流品牌的旗艦機運行內存都飆升至了6GB，比如小米MIX2S、榮耀10，甚至連千元機的魅藍E3也都全系標配6GB運行內存。這一配置升級的背後，反映了手機運行內存佔用越來越大。

此前，Android系統的佔用不過500MB左右，到現在Android 8.1，系統佔用已經達到接近2GB；又比如微信，從一開始的30MB左右，如今已經達到220MB+的運行內存佔用了。折算下來，4GB手機平均能常駐後台6個APP，相對而言有些捉襟見肘。因此，現在手機廠商紛紛將運行內存提升至6GB，這樣能保證平均常駐大概11個後台。

那麼，為什麼APP要佔用越來越多的運行內存呢？

首先，我們要站在開發者的角度來想。開發者和用戶的思維不一樣，他們不是努力的想要節省運行內存，而是想著如何利用更多的運行內存，以帶來更流暢的體驗——這么多運行內存，不用白不用，浪費太可惜。

結果，APP的運行內存佔用就越來越大，這也使得常駐後台的APP數量不斷減少。而為了給用戶帶來更流暢的體驗，手機廠商們不得不把運行內存不斷做大，從1GB到2GB，再到4GB、6GB、8GB。

然而，這又讓開發者眼睛都亮了——正愁著怎麼在運行內存和運行流暢度上進行平衡，沒想到廠商那麼好心，直接把運行內存做大了。於是開發者們又開啟新一輪的運行內存佔用了。

好了，單個APP為什麼運行內存佔用越來越大，你理解了嗎？

但還有個問題，卡頓。有時候，明明只打開了一個APP，卻還是有點卡的感覺。於是你就產生了「4GB、6GB運行內存不夠用，安卓機必須上頂配」的感覺。那這個問題又要誰背鍋呢？

這就要說到整個國內安卓生態了。筆者用的是Pixel 2，運行的是最純凈的Android系統。一段時間的使用下來，筆者印象最深刻的是國內APP的流氓程度，如果不用黑域進行限制，幾乎分分鍾就爆滿運行內存了。

下面這張圖，是筆者取消了黑域限制的後果。清空後台之後，隔了一段時間再看，啟動了一堆APP，幾乎都是國內APP。有些APP以前基本不打開，比如高德地圖、京東，自啟動情況非常嚴重。

所以，表面上你打開的是一個APP，其實背後已經運行了無數個APP。這樣的情況下，想要不卡頓幾乎是不可能的。值得一提的是，這些國內APP幾乎都是從Google Play下載的（QQ被Google Play下架），顯然流氓並不因審查機制的不同而不同。

這個鍋到底誰背？開發者顯然已經不是重點了，而是企業的態度問題。常駐後台，APP可以調用更多許可權，記錄用戶更多的信息，並推送廣告、消息。但問題是，比如地圖APP的使用頻率低，它那麼積極的常駐後台是為何？對不起，筆者真的只能想到廣告。

㈡ Android中如何防止內存溢出（摘）

但是Android採用的是java語言編寫，所以在很大程度上，Android的內存機制等同於Java的內存機制，在剛開始開發的時候，內存的限制問題會給我們帶來內存溢出等嚴重問題。在我們不使用一些內存的時候，我們要盡量在Android或者其他平台上避免在運行其他程序時，保存必要的狀態，使得一些死進程所帶來的內存問題，應該盡量在關閉程序或者保存狀態的時候釋放掉，這樣能提高系統在運行方面的流暢性。Android的內存主要表現在：1. 在Android平台上，長期保持一些資源的引用，造成一些內存不能釋放，帶來的內存泄露問題很多。比如：Context（下文中提到的Activity都是Context），在一些你需要保持你的首個類對象狀態，並且把狀態傳入其他類對象中時，這樣消除掉首個類對象之前，你必須先把接收類對象釋放掉。需要注意一點的是：因為在Java或者Android內存機制中，頂點的結點釋放前必須保證其他對象沒有調用才能被系統GC回收釋放。我們來看一段代碼： @Override protected void onCreate(Bundle state) { super.onCreate(state); TextViewlabel = new TextView(this); label.setText("Leaksare bad"); setContentView(label); }這個代碼的意思就是我們把一個TextView的實例載入到了我們正在運行的Activity（Context）當中，因此，通過GC回收機制，我們知道，要釋放Context，就必須先釋放掉引用他的一些對象。如果沒有，那在要釋放Context的時候，你會發現會有大量的內存溢出。所以在你不小心的情況下內存溢出是一件非常容易的事情。 保存一些對象時，同時也會造成內存泄露。最簡單的比如說點陣圖（Bitmap），比如說：在屏幕旋轉時，會破壞當前保持的一個Activity狀態，並且重新申請生成新的Activity，直到新的Activity狀態被保存。我們再看一段代碼： privatestatic Drawable sBackground; @Override protected void onCreate(Bundle state) { super.onCreate(state); TextView label = new TextView(this); label.setText("Leaks are bad"); if (sBackground == null) { sBackground =getDrawable(R.drawable.large_bitmap); } label.setBackgroundDrawable(sBackground); setContentView(label); } 這個代碼是非常快的同時也是錯誤的。它的內存泄露很容易出在屏幕轉移的方向上。雖然我們會發現沒有顯示的保存Context這個實例，但是當我們把繪制的圖連接到一個視圖的時候，Drawable就會將被View設置為回調，這就說明，在上述的代碼中，其實在繪制TextView到活動中的時候，我們已經引用到了這個Activity。鏈接情況可以表現為：Drawable->TextView->Context。所以在想要釋放Context的時候，其實還是保存在內存中，並沒有得到釋放。如何避免這種情況：主要在於。線程最容易出錯。大家不要小看線程，在Android裡面線程最容易造成內存泄露。線程產生內存泄露的主要原因在於線程生命周期的不可控。下面有一段代碼：publicclass MyTest extends Activity { @Override publicvoid onCreate(BundlesavedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main); new MyThread().start(); } privateclass MyThread extends Thread{ @Override public void run() { super.run(); //do somthing } } } 代碼很簡單，但是在Android上又來新問題了，當我們在切換視圖屏幕的時候（橫豎屏），就會重新建立橫屏或者豎屏的Activity。我們形象的認為之前建立的Activity會被回收，但是事實如何呢？Java機制不會給你同樣的感受，在我們釋放Activity之前，因為run函數沒有結束，這樣MyThread並沒有銷毀，因此引用它的Activity（Mytest）也有沒有被銷毀，因此也帶來的內存泄露問題。有些人喜歡用Android提供的AsyncTask，但事實上AsyncTask的問題更加嚴重，Thread只有在run函數不結束時才出現這種內存泄露問題，然而AsyncTask內部的實現機制是運用了ThreadPoolExcutor,該類產生的Thread對象的生命周期是不確定的，是應用程序無法控制的，因此如果AsyncTask作為Activity的內部類，就更容易出現內存泄露的問題。線程問題的改進方式主要有：（1） 將線程的內部類，改為靜態內部類。（2） 在程序中盡量採用弱引用保存Context。 2. BitmapBitmap是一個很萬惡的對象，對於一個內存對象，如果該對象所佔內存過大，在超出了系統的內存限制時候，內存泄露問題就很明顯了。。解決bitmap主要是要解決在內存盡量不保存它或者使得采樣率變小。在很多場合下，因為我們的圖片像素很高，而對於手機屏幕尺寸來說我們並不用那麼高像素比例的圖片來載入時，我們就可以先把圖片的采樣率降低在做原來的UI操作。如果在我們不需要保存bitmap對象的引用時候，我們還可以用軟引用來做替換。具體的實例代碼google上面也有很多。綜上所述，要避免內存泄露，主要要遵循以下幾點：第一：不要為Context長期保存引用（要引用Context就要使得引用對象和它本身的生命周期保持一致）。第二：如果要使用到Context，盡量使用ApplicationContext去代替Context，因為ApplicationContext的生命周期較長，引用情況下不會造成內存泄露問題。第三：在你不控制對象的生命周期的情況下避免在你的Activity中使用static變數。盡量使用WeakReference去代替一個static。 A obj = new A（）； WeakReference wr = new WeakReference（obj）； obj = null； 這是一個簡單的弱引用的例子，簡單來說就是回收那些NULL值對象所佔的內存空間。 java與C系列語言不同之一就是內存操作都是由後台進行的，其中System.gc（）方法可以回收內存。 比如你使用了一個BITMAP，在使用之後馬上讓它的值為NULL，這個BITMAP用過的內存就會被gc回收（也可以直接加上System.gc（）快速回收），從而達到利用弱引用來緩解內存溢出的目的。 )第四：垃圾回收器並不保證能准確回收內存，這樣在使用自己需要的內容時，主要生命周期和及時釋放掉不需要的對象。盡量在Activity的生命周期結束時，在onDestroy中把我們做引用的其他對象做釋放，比如：cursor.close()。 其實我們可以在很多方面使用更少的代碼去完成程序。比如：我們可以多的使用9patch圖片等。有很多細節地方都可以值得我們去發現、挖掘更多的內存問題。

㈢ 目前的安卓手機的運行內存（RAM）最大是多少

最大的4g，但系統要佔大約五百兆，所以大概3.5g

㈣ android系統嚴格規定了每個應用所能分配的最大的內存為多少

Android應用程序的默認最大內存值為16M，不同的手機版本和型號有所不同(我的三星galaxy s3的是256M)

Android應用程序的默認最大內存值

有些應用程序可能會出現內存溢出,譬如：

ERROR/AndroidRuntime(264): java.lang.OutOfMemoryError: bitmap size exceeds VM budget

除了要檢查修正代碼之外，還可以考慮修改Android應用程序的默認最大內存值。

㈤ android系統需要多大內存

手機內存的話至少1G！
低配置的可以root，然後用冰雪 凍結不使用的app，一樣玩的很6，
開發android的話，電腦最好8G以上，條件允許就上SSD硬碟，
編譯代碼和開虛擬機，非常耗內存和CPU。

㈥ 一個android應用在內存中佔用多少內存

在Android中，一個Process 只能使用16M內存，如果超過了這個限制就會拋出Android Out Of Memory(OOM) 這個異常。 在Android中： 1.一個進程的內存可以由2個部分組成：java 使用內存 ，C 使用內存 ，這兩個內存的和必須小於16M，不然就會出現OOM...

㈦ 安卓系統對內存的需求大小

Android對於內存的要求是越大越好，2000左右的RAM一般都是512M，機子因為是照相所以我推薦
索愛
的。

㈧ android系統運行需要多大內存

安卓手機我用過好多，從最早的256M到512M到1G到2G，個人感覺還是2G運行內存的不影響使用，1G的還湊和，再少的話，就非常差了。

㈨ 如何突破24M內存的限制，為Android程序分配到更多內存

一個Android的應用最多使用16M的內存,如果要突破這個限制,則要使用c/c++編寫JNI,即直接調用底層的函數來處理.linux也是用c/c++來編寫的,因此有非常非常多的函數庫可以調用.