🔥?OOM介紹（out of memory 內(nèi)存溢出）🔥

Android和java中都會(huì)出現(xiàn)由于不良代碼引起的內(nèi)存泄露，為了使Android應(yīng)用程序能夠快速高效的運(yùn)行，Android每個(gè)應(yīng)用程序都會(huì)有專門Dalvik虛擬機(jī)實(shí)例來(lái)運(yùn)行，也就是每個(gè)程序都在屬于自己的進(jìn)程中運(yùn)行。

某個(gè)應(yīng)用程序內(nèi)存泄露僅僅只會(huì)使自己進(jìn)程被kill掉不會(huì)影響其他進(jìn)程（如果是system_process等系統(tǒng)進(jìn)程出現(xiàn)問(wèn)題，就會(huì)造成系統(tǒng)重啟），另一方面，系統(tǒng)為每一個(gè)應(yīng)用程序分配了不同的內(nèi)存上限，如果超過(guò)這個(gè)上限被視為內(nèi)存泄露，從而被kill掉。

Dalvik Heap size因不同設(shè)備的RAM不同而有所差異，應(yīng)用占用內(nèi)存接近這個(gè)閥值，在嘗試分配內(nèi)存就會(huì)引起outofmemoryError的錯(cuò)誤。?

🔥 出現(xiàn)OOM的幾種情況 🔥?

1、加載對(duì)象過(guò)大

2、相應(yīng)資源過(guò)多，來(lái)不及加載。

解決方案 :??

1、內(nèi)存引用上做一些處理，常用的有軟引用。

2、內(nèi)存中加載圖片直接在內(nèi)存中做處理（如邊界壓縮）
3、這個(gè)GlideFresco 圖片框架可能封裝好了
4、動(dòng)態(tài)回收內(nèi)存
5、優(yōu)化Delivk虛擬機(jī)的堆內(nèi)存分配
6、自定義堆內(nèi)存大小

?🔥?共享內(nèi)存 🔥

Android應(yīng)用程序的進(jìn)程都是從Zygote的進(jìn)程fork出來(lái)的。Zygote進(jìn)程在系統(tǒng)啟動(dòng)并載入通用的framework代碼和資源后啟動(dòng)。一個(gè)新的應(yīng)用程序啟動(dòng)，系統(tǒng)就會(huì)從Zygote中fork出來(lái)一個(gè)新的進(jìn)程，在新的進(jìn)程中加載并允許應(yīng)用程序的代碼。這使得大多數(shù)RAM pages被分配給framework的代碼，并且RAM資源能夠在應(yīng)用的所有進(jìn)程之間共享。

大多數(shù)static 數(shù)據(jù)被mmapped到一個(gè)進(jìn)程中，這樣使得同樣的數(shù)據(jù)在進(jìn)程之間能夠共享，而且在需要的時(shí)候能paged out.常見(jiàn)static 數(shù)據(jù)包括Dalvik code ,app resourecs,so 文件等。

大多數(shù)情況下，Android通過(guò)顯示的方式分配共享內(nèi)存區(qū)域（例如ashmem或gralloc）來(lái)實(shí)現(xiàn)動(dòng)態(tài)RAM區(qū)域能夠在不同進(jìn)程之間進(jìn)行共享的機(jī)制。比如，Window Surface在APP和Screen Composition之間使用共享的內(nèi)存，
Cursor Buffers在Content Provider與Clients之間共享內(nèi)存。

🔥?分配與回收內(nèi)存 🔥

每個(gè)進(jìn)程的Dalvik heap都反應(yīng)了使用內(nèi)存的占用范圍,（Dalvik Heap Size）,他可以根據(jù)需要進(jìn)行增長(zhǎng)，但是系統(tǒng)有一個(gè)上限。

?HeapSize跟實(shí)際的物理內(nèi)存大小是不對(duì)等的，PSS（proportional Set Size）記錄了應(yīng)用程序自身占用以及和其他進(jìn)程共享的內(nèi)容。

?Android不會(huì)對(duì)heap空閑區(qū)域進(jìn)行做碎片整理。系統(tǒng)僅僅在新的內(nèi)存分配之前判斷Heap的尾端剩余空間是否足夠，不夠就會(huì)觸發(fā)gc操作，從而騰出更多空閑的內(nèi)存空間。

gc操作(garbage collection)也就是所謂的垃圾回收，Android在適當(dāng)時(shí)候觸發(fā)gc操作，將一些不再使用的對(duì)象回收，在Android高級(jí)系統(tǒng)針對(duì)Heap空間有一個(gè)Generational Heap Memory的模型，最近分配的對(duì)象在放在young generation區(qū)域，當(dāng)停留一段時(shí)間，這個(gè)對(duì)象會(huì)被移動(dòng)到old generation中，最后在移動(dòng)到permanent generation區(qū)域中。

系統(tǒng)會(huì)根據(jù)內(nèi)存中不同的內(nèi)存數(shù)據(jù)類型進(jìn)行g(shù)c操作，young generation區(qū)域的對(duì)象更容易被銷毀，而且gc操作的速度比old generation的速度要快，時(shí)間更短。
每個(gè)generation的內(nèi)存區(qū)域都有固定的大小，隨著新的對(duì)象陸續(xù)被分配到此區(qū)域，當(dāng)這些對(duì)象的大小快達(dá)到閥門值時(shí)，就會(huì)觸發(fā)gc操作。通常情況下，gc操作發(fā)生時(shí)，所有線程都是暫停的。

如何查看本機(jī)heap size :
ActivityManager manager=(Activity)getSystemService(Context.ACTIVITY_SERVICE); int heapsize=manager.getMemoryClass();?

🔥?應(yīng)用切換操作 🔥?

Android系統(tǒng)不會(huì)再用戶切換應(yīng)用的時(shí)候進(jìn)行交換內(nèi)存的操作，而是把不包含F(xiàn)oreground組件的應(yīng)用進(jìn)程放到LRUCache中，比如用戶啟動(dòng)一個(gè)應(yīng)用，系統(tǒng)會(huì)為它創(chuàng)建一個(gè)進(jìn)程，但是當(dāng)用戶離開(kāi)這個(gè)應(yīng)用，此進(jìn)程不會(huì)被立即銷毀而是會(huì)放到一個(gè)Cache中，當(dāng)用戶切換回來(lái)夠快速的恢復(fù)。

?🔥?發(fā)生OOM的條件 🔥

通過(guò)不同的內(nèi)存分配方式對(duì)不同的對(duì)象(bitmap,etc)進(jìn)行操作因Android版本差異發(fā)生變化。
4.0以上，廢除了external的計(jì)數(shù)器，類似bitmap的分配改到dalvik的Java heap(堆)中申請(qǐng)，只要allocated+新分配的內(nèi)存>=getMemoryClass()就會(huì)發(fā)生OOM。(在AS memory monitor查看內(nèi)存中Dalvik Heap的實(shí)時(shí)變化)

🔥?如何避免OOM 🔥

減少OOM的第一步就是要盡量減少新分配出來(lái)的對(duì)象占用內(nèi)存的大小，盡量使用更加輕量的對(duì)象。?

?使用更加輕量的數(shù)據(jù)結(jié)構(gòu)

考慮使用ArrayMap/SpareseArray而不是傳統(tǒng)的HashMap等數(shù)據(jù)結(jié)構(gòu)，Android系統(tǒng)為移動(dòng)系統(tǒng)設(shè)計(jì)的容器ArrayMap更加高效，占用內(nèi)存更少，因?yàn)镠ashMap需要一個(gè)額外的實(shí)例對(duì)象來(lái)記錄Mapping的操作。而SparesArray高效的避免了key和value的自動(dòng)裝箱，而且避免了裝箱后的解箱。

?避免在Android中使用Enum

減少Bitmap對(duì)象的內(nèi)存占用
Bitmap是一個(gè)消耗內(nèi)存的大胖子，減少創(chuàng)建出來(lái)的Bitmap的內(nèi)存占用很重要。一般有兩種措施 :?

1、inSampleSize:縮放比例，在把圖片載入內(nèi)存之前，我們需要計(jì)算一個(gè)合適的縮放比例，避免不必要的大圖載入。

2、decode format:解碼格式，選擇ARGB_8888/RBG_565/ARGB_4444/ALPHA_8，存在很大差異。

?使用更小的圖片

在設(shè)計(jì)圖片資源的時(shí)候，我們要考慮圖片是否存在可以壓縮的空間，是否能使用更小的圖片，使用小圖在xml加載資源時(shí)就不會(huì)在初始化視圖因?yàn)閮?nèi)存不足而發(fā)生InflationException,其根本原因就是發(fā)生了OOM。

🔥?內(nèi)存對(duì)象的重復(fù)利用 🔥?

?Android最常用的緩存算法LRU(Least Recently Use)

?復(fù)用系統(tǒng)自帶的資源，比如字符串、圖片、動(dòng)畫(huà)、樣式、顏色、簡(jiǎn)單布局，在應(yīng)用中直接引用，減少自身負(fù)重、apk大小、減少內(nèi)存的開(kāi)銷、復(fù)用性更好。但需要考慮版本差異。

?Listview和GirdView出現(xiàn)大量重復(fù)子組件的視圖里面對(duì)ConvertView的復(fù)用。

?Bitmap對(duì)象的復(fù)用

在ListView和GridView等顯示大量圖片的控件里面需要使用LRU機(jī)制緩存Bitmap.

利用inBitmap的高級(jí)特性提高Android系統(tǒng)在Bitmap分配和釋放執(zhí)行效率，inBitmap屬性可以告知Bitmap解碼器使用已經(jīng)存在的內(nèi)存區(qū)域而不是重新申請(qǐng)一塊內(nèi)存區(qū)域存放Bitmap,也就是新解碼的Bitmap會(huì)使用之前那張bitmap在heap占用的內(nèi)存區(qū)域，即使是上千張圖片，也只占用屏幕能放下圖片的內(nèi)存

?SDK19以后：新申請(qǐng)的BItmap大小必須小于或等于前面賦值過(guò)的bitmap的大小

新的Bitmap和原來(lái)的解碼格式要相同，我們可以創(chuàng)建包含多種類型可以重用的bitmap對(duì)象池，這樣后序的bitmap創(chuàng)建就可以找到合適的模板去重用。

避免在onDraw方法里面執(zhí)行對(duì)象的創(chuàng)建
在onDraw這種頻繁調(diào)用的方法要避免對(duì)象的創(chuàng)建操作，因?yàn)樗麜?huì)迅速增加內(nèi)存的使用，引起頻繁的gc，甚至內(nèi)存抖動(dòng)

StringBuilder
如果代碼中有大量字符串拼接操作，使用StringBuilder代替"+"

🔥?避免對(duì)象的內(nèi)存泄露 🔥?

內(nèi)存對(duì)象的泄露會(huì)導(dǎo)致不再使用的對(duì)象無(wú)法及時(shí)釋放，不僅浪費(fèi)了寶貴的內(nèi)存空間，后續(xù)要分配內(nèi)存的時(shí)候，空間不足造成OOM。這樣，每級(jí)的generation會(huì)變小，gc更加容易觸發(fā)，引起內(nèi)存抖動(dòng)，帶來(lái)性能問(wèn)題。

?LeakCanary開(kāi)源控件可以幫助我們發(fā)現(xiàn)內(nèi)存泄露的問(wèn)題。

Activity泄露是內(nèi)存泄露最為嚴(yán)重的問(wèn)題，涉及內(nèi)存多，影響面廣 .

• 內(nèi)部類引用導(dǎo)致Activity的泄露
  典型的是Handler導(dǎo)致的Activity泄露，如果Handler中有延遲的任務(wù)或者等待執(zhí)行的任務(wù)隊(duì)列過(guò)長(zhǎng)，很可能因?yàn)镠andler繼續(xù)執(zhí)行造成Activity的泄露。
  引用鏈?zhǔn)荓ooper->MessageQueue->Message->handler->Activity,解決辦法是在退出UI之前執(zhí)行 remove Handler消息隊(duì)列中的消息與runnable對(duì)象。或者使用Static+WeakReference的方式來(lái)判斷Handler和Activity之間存在引用關(guān)系。
• Activity Context被傳遞到其他實(shí)例中，可能導(dǎo)致自身被引用而發(fā)生泄露 .? ? ?
• 考慮使用Application Context而不是Activity Context 除必須使用Activity Context的情況(Dialog的context必須是Activity),我們可以使用Application Context來(lái)避免Activity泄露

注意臨時(shí)Bitmap的及時(shí)回收
大多數(shù)情況下，我們對(duì)Bitmap對(duì)象增加緩存機(jī)制，但是有時(shí)候部分bitmap需要及時(shí)回收。比如我們臨時(shí)創(chuàng)建的摸個(gè)相對(duì)大的bitmap對(duì)象，變換得到新的bitmap對(duì)象后，盡快回收原始的bitmap,及時(shí)釋放原來(lái)的空間。

注意監(jiān)聽(tīng)器的注銷
android程序里面register后要及時(shí)釋放unregister那些監(jiān)聽(tīng)器，自己手動(dòng)add的listener，要記得remove這個(gè)listener.

注意緩存容器的對(duì)象泄露
有時(shí)候我們?yōu)榱颂岣邔?duì)象的復(fù)用性，把某些對(duì)象放到緩存容器中，如果這些對(duì)象沒(méi)有及時(shí)從容器中清楚，也可能導(dǎo)致內(nèi)存泄露.

注意webview的泄露
Android不同版本對(duì)webview產(chǎn)生有很大差異，較為嚴(yán)重的問(wèn)題是webview的泄露，解決辦法：為webview新開(kāi)一個(gè)進(jìn)程，通過(guò)AIDL與主進(jìn)程通信，根據(jù)業(yè)務(wù)的需要在合適的時(shí)機(jī)進(jìn)行銷毀，從而達(dá)到內(nèi)存的釋放。

🔥?內(nèi)存使用策略優(yōu)化 🔥?

謹(jǐn)慎使用large heap
android設(shè)備由于軟硬件的差異，heap閥值不同，特殊情況下可以在manifest中使用largeheap=true聲明一個(gè)更大的heap空間，使用getLargeMemoryClass()來(lái)獲取到這個(gè)更大的空間。但是要謹(jǐn)慎使用，因?yàn)轭~外的空間會(huì)影響到系統(tǒng)整體的用戶體驗(yàn)，并且會(huì)使每次gc的運(yùn)行時(shí)間更長(zhǎng)。切換任務(wù)時(shí)性能大打折扣，large heap并不一定能獲取到更大的heap.

綜合考慮設(shè)備內(nèi)存閾值與其他因素設(shè)計(jì)合適的緩存大小
例如，在設(shè)計(jì)ListView或者GridView的Bitmap LRU緩存的時(shí)候，需要考慮的點(diǎn)有：

1、應(yīng)用程序剩下了多少可用的內(nèi)存空間?

2、有多少圖片會(huì)被一次呈現(xiàn)到屏幕上？有多少圖片需要事先緩存好以便快速滑動(dòng)時(shí)能夠立即顯示到屏幕？

3、設(shè)備的屏幕大小與密度是多少? 一個(gè)xhdpi的設(shè)備會(huì)比hdpi需要一個(gè)更大的Cache來(lái)hold住同樣數(shù)量的圖片。

4、不同的頁(yè)面針對(duì)Bitmap的設(shè)計(jì)的尺寸與配置是什么，大概會(huì)花費(fèi)多少內(nèi)存？

5、頁(yè)面圖片被訪問(wèn)的頻率？是否存在其中的一部分比其他的圖片具有更高的訪問(wèn)頻繁？如果是，也許你想要保存那些最常訪問(wèn)的到內(nèi)存中，或者為不同組別的位圖(按訪問(wèn)頻率分組)設(shè)置多個(gè)LruCache容器。

6、onLowMemory() 與onTrimMemory() :?

????????Android可以在不同的應(yīng)用當(dāng)中隨意切換。為了讓background轉(zhuǎn)到foreground, 每一個(gè)background都會(huì)占用一定的內(nèi)存。系統(tǒng)會(huì)根據(jù)內(nèi)存的使用情況決定回收部分background的應(yīng)用內(nèi)存。background的應(yīng)用從暫停狀態(tài)恢復(fù)到foreground，比較快，如果從kill狀態(tài)恢復(fù)比較慢。????????

資源文件需要選擇合適的文件夾進(jìn)行存放

我們知道hdpi/xhdpi/xxhdpi等等不同dpi的文件夾下的圖片在不同的設(shè)備上會(huì)經(jīng)過(guò)scale的處理。例如我們只在hdpi的目錄下放置了一張100100的圖片，那么根據(jù)換算關(guān)系，xxhdpi
的手機(jī)去引用那張圖片就會(huì)被拉伸到200200。需要注意到在這種情況下，內(nèi)存占用是會(huì)顯著提高的。對(duì)于不希望被拉伸的圖片，需要放到assets或者nodpi的目錄下。

?Try catch某些大內(nèi)存分配的操作
在某些情況下，我們需要事先評(píng)估那些可能發(fā)生OOM的代碼，對(duì)于這些可能發(fā)生OOM的代碼，加入catch機(jī)制，可以考慮在catch里面嘗試一次降級(jí)的內(nèi)存分配操作。例如decode bitmap的時(shí)候，catch到OOM，可以嘗試把采樣比例再增加一倍之后，再次嘗試decode。

?謹(jǐn)慎使用static對(duì)象
因?yàn)閟tatic的生命周期過(guò)長(zhǎng)，和應(yīng)用的進(jìn)程保持一致，使用不當(dāng)很可能導(dǎo)致對(duì)象泄漏，在Android中應(yīng)該謹(jǐn)慎使用static對(duì)象。

?特別留意單例對(duì)象中不合理的持有
雖然單例模式簡(jiǎn)單實(shí)用，提供了很多便利性，但是因?yàn)閱卫纳芷诤蛻?yīng)用保持一致，使用不合理很容易出現(xiàn)持有對(duì)象的泄漏。

珍惜Services資源?

如果你的應(yīng)用需要在后臺(tái)使用service，除非它被觸發(fā)并執(zhí)行一個(gè)任務(wù)，否則其他時(shí)候Service都應(yīng)該是停止?fàn)顟B(tài)。

另外需要注意當(dāng)這個(gè)service完成任務(wù)之后因?yàn)橥Ｖ箂ervice失敗而引起的內(nèi)存泄漏。

當(dāng)你啟動(dòng)一個(gè)Service，系統(tǒng)會(huì)傾向?yàn)榱吮Ａ暨@個(gè)Service而一直保留Service所在的進(jìn)程。

這使得進(jìn)程的運(yùn)行代價(jià)很高，因?yàn)橄到y(tǒng)沒(méi)有辦法把Service所占用的RAM空間騰出來(lái)讓給其他組件，另外Service還不能被Paged out。

這減少了系統(tǒng)能夠存放到LRU緩存當(dāng)中的進(jìn)程數(shù)量，它會(huì)影響應(yīng)用之間的切換效率，甚至?xí)?dǎo)致系統(tǒng)內(nèi)存使用不穩(wěn)定，從而無(wú)法繼續(xù)保持住所有目前正在運(yùn)行的service。

建議使用IntentService，它會(huì)在處理完交代給它的任務(wù)之后盡快結(jié)束自己。

優(yōu)化布局層次，減少內(nèi)存消耗?

越扁平化的視圖布局，占用的內(nèi)存就越少，效率越高。我們需要盡量保證布局足夠扁平化，當(dāng)使用系統(tǒng)提供的View無(wú)法實(shí)現(xiàn)足夠扁平的時(shí)候考慮使用自定義View來(lái)達(dá)到目的。

?謹(jǐn)慎使用“抽象”編程

很多時(shí)候，開(kāi)發(fā)者會(huì)使用抽象類作為”好的編程實(shí)踐”，因?yàn)槌橄竽軌蛱嵘a的靈活性與可維護(hù)性。然而，抽象會(huì)導(dǎo)致一個(gè)顯著的額外內(nèi)存開(kāi)銷：他們需要同等量的代碼用于可執(zhí)行，那些代碼會(huì)被mapping到內(nèi)存中，因此如果你的抽象沒(méi)有顯著的提升效率，應(yīng)該盡量避免他們。

使用nano protobufs序列化數(shù)據(jù)?

Protocol buffers是由Google為序列化結(jié)構(gòu)數(shù)據(jù)而設(shè)計(jì)的，一種語(yǔ)言無(wú)關(guān)，平臺(tái)無(wú)關(guān)，具有良好的擴(kuò)展性。類似XML，卻比XML更加輕量，快速，簡(jiǎn)單。如果你需要為你的數(shù)據(jù)實(shí)現(xiàn)序列化與協(xié)議化，建議使用nano protobufs。

謹(jǐn)慎使用依賴注入框架

使用類似Guice或者RoboGuice等框架注入代碼，在某種程度上可以簡(jiǎn)化你的代碼。

🔥?謹(jǐn)慎使用多進(jìn)程 🔥?

使用多進(jìn)程可以把應(yīng)用中的部分組件運(yùn)行在單獨(dú)的進(jìn)程當(dāng)中，這樣可以擴(kuò)大應(yīng)用的內(nèi)存占用范圍，但是這個(gè)技術(shù)必須謹(jǐn)慎使用，絕大多數(shù)應(yīng)用都不應(yīng)該貿(mào)然使用多進(jìn)程，一方面是因?yàn)槭褂枚噙M(jìn)程會(huì)使得代碼邏輯更加復(fù)雜，另外如果使用不當(dāng)，它可能反而會(huì)導(dǎo)致顯著增加內(nèi)存。當(dāng)你的應(yīng)用需要運(yùn)行一個(gè)常駐后臺(tái)的任務(wù)，而且這個(gè)任務(wù)并不輕量，可以考慮使用這個(gè)技術(shù)。

一個(gè)典型的例子是創(chuàng)建一個(gè)可以長(zhǎng)時(shí)間后臺(tái)播放的Music Player。如果整個(gè)應(yīng)用都運(yùn)行在一個(gè)進(jìn)程中，當(dāng)后臺(tái)播放的時(shí)候，前臺(tái)的那些UI資源也沒(méi)有辦法得到釋放。類似這樣的應(yīng)用可以切分成2個(gè)進(jìn)程：一個(gè)用來(lái)操作UI，另外一個(gè)給后臺(tái)的Service。

🔥 剔除不需要的代碼 🔥?

?使用ProGuard來(lái)剔除不需要的代碼
ProGuard能夠通過(guò)移除不需要的代碼，重命名類，域與方法等等對(duì)代碼進(jìn)行壓縮，優(yōu)化與混淆。使用ProGuard可以使得你的代碼更加緊湊，這樣能夠減少mapping代碼所需要的內(nèi)存空間。

🔥?謹(jǐn)慎使用第三方libraries 🔥?

?很多開(kāi)源的library代碼都不是為移動(dòng)網(wǎng)絡(luò)環(huán)境而編寫(xiě)的，如果運(yùn)用在移動(dòng)設(shè)備上，并不一定適合。即使是針對(duì)Android而設(shè)計(jì)的library，也需要特別謹(jǐn)慎，特別是在你不知道引入的library具體做了什么事情的時(shí)候。例如，其中一個(gè)library使用的是nano protobufs, 而另外一個(gè)使用的是micro protobufs。這樣一來(lái)，在你的應(yīng)用里面就有2種protobuf的實(shí)現(xiàn)方式。這樣類似的沖突還可能發(fā)生在輸出日志，加載圖片，緩存等等模塊里面。另外不要為了1個(gè)或者2個(gè)功能而導(dǎo)入整個(gè)library，如果沒(méi)有一個(gè)合適的庫(kù)與你的需求相吻合，你應(yīng)該考慮自己去實(shí)現(xiàn)，而不是導(dǎo)入一個(gè)大而全的解決方案。

?🔥?設(shè)計(jì)風(fēng)格 優(yōu)化 🔥

設(shè)計(jì)風(fēng)格很大程度上會(huì)影響到程序的內(nèi)存與性能，相對(duì)來(lái)說(shuō)，如果大量使用類似Material Design的風(fēng)格，不僅安裝包可以變小，還可以減少內(nèi)存的占用，渲染性能與加載性能都會(huì)有一定的提升。

🔥 總結(jié) 🔥?

?內(nèi)存優(yōu)化并不就是說(shuō)程序占用的內(nèi)存越少就越好，如果因?yàn)橄胍３指偷膬?nèi)存占用，而頻繁觸發(fā)執(zhí)行g(shù)c操作，在某種程度上反而會(huì)導(dǎo)致應(yīng)用性能整體有所下降，這里需要綜合考慮做一定的權(quán)衡。

?Android的內(nèi)存優(yōu)化涉及的知識(shí)面還有很多：內(nèi)存管理的細(xì)節(jié)，垃圾回收的工作原理，如何查找內(nèi)存泄漏等等都可以展開(kāi)講很多。OOM是內(nèi)存優(yōu)化當(dāng)中比較突出的一點(diǎn)，盡量減少OOM的概率對(duì)內(nèi)存優(yōu)化有著很大的意義。