【轉載】Android Studio 設置內存大小及原理

http://www.cnblogs.com/justinzhang/p/4274985.html

http://tsroad.lofter.com/post/376316_69363ae

 

Android studio 1.0.2默認最大內存是750M，這樣跑起來很是的卡，難以忍受，機器又不是固態硬盤，最後發現，這個默認值是能夠修改的，在android studio目錄下找到：studio64.exe.vmoptions文件，綠色部分爲修改的參數（-Xmx1050m)，將默認參數修改成1050MB，這樣跑起來就很是流暢了，若是以爲仍是不夠流暢，能夠改得更高：

-Xms128m
-Xmx1050m
-XX:MaxPermSize=350m
-XX:ReservedCodeCacheSize=96m
-ea
-Dsun.io.useCanonCaches=false
-Djava.net.preferIPv4Stack=true
-Djna.nosys=true
-Djna.boot.library.path=

-Djna.debug_load=true
-Djna.debug_load.jna=true
-Djsse.enableSNIExtension=false
-XX:+UseCodeCacheFlushing
-XX:+UseConcMarkSweepGC
-XX:SoftRefLRUPolicyMSPerMB=50
-Didea.platform.prefix=AndroidStudio
-Didea.paths.selector=AndroidStudio

 

mac系統下在Android studio包內容中的contents-bin-studio.vmoptions

 

若是這個設置沒有生效，在 File->Ivalidate Caches中，選擇 Ivalidate and Restart就能夠生效了：

 

最後，在資源管理器中能夠看到，studio64.exe的內存佔有瞬間漲到了1GB以上。

 

 

————————————————————————————————————————————

從AndroidStudio的啓動參數瞭解到的下JVM的一些東西（內存使用，JIT等）

若是你使用AndroidStudio常常以爲很卡，那有多是由於系統給AS分配的內存不夠的緣由。打開/Applications/Android Studio.app/Contents/bin/studio.vmoptions (Mac)，能夠看到有如下配置：

-Xms128m -Xmx750m -XX:MaxPermSize=350m -XX:ReservedCodeCacheSize=96m -XX:+UseCompressedOops

這些參數分別是什麼意思呢？

-Xms128m

The -Xms option sets the initial and minimum Java heap size. The Java heap (the 「heap」) is the part of the memory where blocks of memory are allocated to objects and freed during garbage collection.

就是JVM啓動的起始堆內存，堆內存是分配給對象的內存。這裏我把它改爲了512m

-Xmx750m

This option sets the maximum Java heap size.

也就是AndroidStudio能使用的最大heap內存，這裏我改爲了2048m

這兩個參數都是-X開頭的，表示非標準的參數。什麼叫非標準的呢？咱們知道JVM有不少個實現，Oracle的，OpenJDK等等，這裏的-X參數，是Oracle的JVM實現使用的，OpenJDK不必定能使用，也就是沒有將這些參數標準化，讓全部的JVM實現都能使用。

-XX:MaxPermSize=350m

這個參數指定最大的Permanent generation大小。
根據oracle的文檔：

Permanent Generation (non-heap): The pool containing all the reflective data of the virtual machine itself, such as class and method objects. With Java VMs that use class data sharing, this generation is divided into read-only and read-write areas.

可知，Permanent Generation也是一塊內存區域，跟heap不一樣，它裏面存放的事類自己（不是對象），以及方法，一些固定的字符串等等。更多關於Permanent Generation

-XX:ReservedCodeCacheSize=90m

ReservedCodeCacheSize (and InitialCodeCacheSize) is an option for the (just-in-time) compiler of the Java Hotspot VM. Basically it sets the maximum size for the compiler's code cache.

設置JIT java compiler在compile的時候的最大代碼緩存。簡單地說就是JIT（Just In Time）編譯器在編譯代碼的時候，須要緩存一些東西，這個參數指定最多能使用多大內存來緩存這些東西。
什麼叫JIT呢？看wikipedia的解釋：

In computing, just-in-time compilation (JIT), also known as dynamic translation, is compilation done during execution of a program – at run time – rather than prior to execution.Most often this consists of translation to machine code, which is then executed directly, but can also refer to translation to another format. JIT compilation is a combination of the two traditional approaches to translation to machine code – ahead-of-time compilation (AOT), and interpretation – and combines some advantages and drawbacks of both.[1] Roughly, JIT compilation combines the speed of compiled code with the flexibility of interpretation, with the overhead of an interpreter and the additional overhead of compiling (not just interpreting). JIT compilation is a form of dynamic compilation, and allows adaptive optimization such as dynamic recompilation – thus in principle JIT compilation can yield faster execution than static compilation. Interpretation and JIT compilation are particularly suited for dynamic programming languages, as the runtime system can handle late-bound data types and enforce security guarantees.

咱們知道編程語言分兩種： - 編譯型，先將人寫的代碼整個編譯成彙編語言或機器語言，一條一條代碼而後執行。 - 解釋型，不須要編譯，將人寫的代碼一條一條拿過來一次執行，先取一條，執行，完了再取下一條，而後在執行。

而對於Java來講，這個狀況就比較特殊了，由於在Java這裏，JVM先是將Java代碼整個編譯成bytecode，而後在JVM內部再一條一條執行bytecode代碼。你說它是編譯型的吧，bytecode又不用編譯成機器代碼，二是一條條bytecode一次執行。你說它是解釋型的吧，它又有一個編譯的過程。對於Java究竟是編譯型仍是解釋型到如今也沒有一個定論。不過，咱們仍是能夠探討一下Java的JIT編譯技術。
剛剛說了，在bytecode層面，代碼是解釋執行的。解釋型的語言會比較慢，由於它沒有辦法根據上下文對代碼進行優化。而編譯型的語言則能夠進行優化。Java的JIT技術，就是在bytecode解釋執行的時候，它不必定是一條條解釋執行的，二是取一段代碼，編譯成機器代碼，而後執行，這樣的話就有了上下文，能夠對代碼進行優化了，因此執行速度也會更快。
可見，JIT技術結合了編譯型（速度更快）和解釋型語言（代碼更靈活）兩者的優點。對於動態語言的執行來講，是一個很是大的優點。

-XX:+UseCompressedOops

這個參數容許系統將代碼裏面的引用(reference)類型用32位存儲，同時卻可以讓引用可以使用64位的內存大小。
咱們知道現代的機器基本都是64位的，在這種狀況下，Java代碼裏面的reference類型也變成了用64位來存儲，這就致使了兩個問題：
1. 64位比32爲更大，佔的內存更多，這是顯然的，固然這個問題在整個程序看來根本不顯然，由於哪怕系統同時有1000個引用存在，那多出來的內存也就4M，這個不重要，由於如今手機都動不動好幾個G，大型服務器就更加不用說了。更重要的是第二點。 2. 相對於內存，CPU的cache就小的可憐了，當reference從32bit變成64bit時，cache裏面能存放的reference數量就頓時少了不少。因此64bit的reference對cache是個大問題，因而就有了這個選項，能夠容許系統用32bit來存儲reference，讓cache裏面能存放更多的reference，同時又不影響reference的取址範圍。至於他們是怎麼作到的，我就不得而知了。。。

以上三個參數是以-XX開頭的，根據Oracle的說明，

Options that are specified with -XX are not stable and are subject to change without notice.