前言

　　對于 oracle 的內(nèi)存的管理，截止到9iR2，都是相當重要的環(huán)節(jié)，管理不善，將可能給數(shù)據(jù)庫帶來嚴重的性能問題。下面我們將一步一步就內(nèi)存管理的各個方面進行探討。

概述

　　Oracle 的內(nèi)存可以按照共享和私有的角度分為系統(tǒng)全局區(qū)和進程全局區(qū)，也就是SGA和PGA(process global area or private global area)。對于SGA區(qū)域內(nèi)的內(nèi)存來說，是共享的全局的，在UNIX 上，必須為oracle 設置共享內(nèi)存段（可以是一個或者多個），因為oracle 在UNIX上是多進程；而在WINDOWS上oracle是單進程（多個線程），所以不用設置共享內(nèi)存段。PGA是屬于進程（線程）私有的區(qū)域。在oracle 使用共享服務器模式下（MTS）,PGA中的一部分，也就是UGA會被放入共享內(nèi)存large_pool_size 中。

　　對于SGA部分，我們通過sqlplus 中查詢可以看到：

　　SQL> select * from v$sga;

　　NAME VALUE

　　-------------------- ----------

　　Fixed Size 454032

　　Variable Size 109051904

　　Database Buffers 385875968

　　Redo Buffers 667648

　　Fixed Size

　　Oracle 的不同平臺和不同版本下可能不一樣，但對于確定環(huán)境是一個固定的值，里面存儲了SGA 各部分組件的信息，可以看作引導建立SGA的區(qū)域。

　　Variable Size

　　包含了shared_pool_size、java_pool_size、large_pool_size 等內(nèi)存設置。

　　Database Buffers

　　指數(shù)據(jù)緩沖區(qū)，在8i 中包含db_block_buffer*db_block_size、buffer_pool_keep、buffer_pool_recycle 三部分內(nèi)存。在9i 中包含db_cache_size、db_keep_cache_size、db_recycle_cache_size、db_nk_cache_size。

　　Redo Buffers

　　指日志緩沖區(qū)，log_buffer。在這里要額外說明一點的是，對于v$parameter、v$sgastat、v$sga查詢值可能不一樣。v$parameter 里面的值，是指用戶在初始化參數(shù)文件里面設置的值，v$sgastat是oracle 實際分配的日志緩沖區(qū)大小（因為緩沖區(qū)的分配值實際上是離散的，也不是以block 為最小單位進行分配的），v$sga 里面查詢的值，是在oracle 分配了日志緩沖區(qū)后，為了保護日志緩沖區(qū)，設置了一些保護頁，通常我們會發(fā)現(xiàn)保護頁大小大約是11k(不同環(huán)境可能不一樣)。參考如下內(nèi)容

　　SQL> select substr(name,1,10) name,substr(value,1,10) value

　　2 from v$parameter where name = 'log_buffer';

　　NAME VALUE

　　-------------------- --------------------

　　log_buffer 524288

　　SQL> select * from v$sgastat ;

　　POOL NAME BYTES

　　----------- -------------------

　　fixed_sga 454032

　　buffer_cache 385875968

　　log_buffer 656384

　　SQL> select * from v$sga;

　　NAME VALUE

　　-------------------- ----------

　　Fixed Size 454032

　　Variable Size 109051904

　　Database Buffers 385875968

　　Redo Buffers 667648

　　關(guān)于各部分內(nèi)存的作用，參考Oracle體系結(jié)構(gòu)，在此不再敘述。

　　SGA的大小

　　那么我們現(xiàn)在來考察內(nèi)存參數(shù)的設置。實際上，對于特定的環(huán)境，總是存在著不同的最優(yōu)設置的，沒有任何一種普遍適用的最優(yōu)方案。但為什么在這里我們還要來談設置這個話題呢，那僅僅是出于一個目的，避免過度的犯錯誤。事實上，在任何一個生產(chǎn)系統(tǒng)正式投入使用之前，我們不擁有任何系統(tǒng)運行信息讓我們?nèi)フ{(diào)整，這樣就只有兩種可能，一是根據(jù)文檔推薦設置，另外一種就是根據(jù)經(jīng)驗設置。相對來說，根據(jù)經(jīng)驗的設置比根據(jù)文檔的設置要可靠一些。尤其是那些24*7 的系統(tǒng)，我們更要減少錯誤的發(fā)生。那么我們嘗試去了解不同的系統(tǒng)不同的應用的具體設置情況，從而提供一個參照信息給大家。

　　為了得出一個參照設置，我們就必須假定一個參照環(huán)境。以下所有設置我們基于這樣一個假定，那就是硬件服務器上只考慮存在操作系統(tǒng)和數(shù)據(jù)庫，在這個單一的環(huán)境中，我們來考慮內(nèi)存的設置。

　　在設置參數(shù)之前呢，我們首先要問自己幾個問題

　　一：物理內(nèi)存多大

　　二：操作系統(tǒng)估計需要使用多少內(nèi)存

　　三：數(shù)據(jù)庫是使用文件系統(tǒng)還是裸設備

　　四：有多少并發(fā)連接

　　五：應用是OLTP 類型還是OLAP 類型

　　根據(jù)這幾個問題的答案，我們可以粗略地為系統(tǒng)估計一下內(nèi)存設置。那我們現(xiàn)在來逐個問題地討論，首先物理內(nèi)存多大是最容易回答的一個問題，然后操作系統(tǒng)估計使用多少內(nèi)存呢？從經(jīng)驗上看，不會太多，通常應該在200M 以內(nèi)（不包含大量進程PCB）。

　　接下來我們要探討一個重要的問題，那就是關(guān)于文件系統(tǒng)和裸設備的問題，這往往容易被我們所忽略。操作系統(tǒng)對于文件系統(tǒng)，使用了大量的buffer 來緩存操作系統(tǒng)塊。這樣當數(shù)據(jù)庫獲取數(shù)據(jù)塊的時候，雖然SGA 中沒有命中，但卻實際上可能是從操作系統(tǒng)的文件緩存中獲取的。而假如數(shù)據(jù)庫和操作系統(tǒng)支持異步IO，則實際上當數(shù)據(jù)庫寫進程DBWR寫磁盤時，操作系統(tǒng)在文件緩存中標記該塊為延遲寫，等到真正地寫入磁盤之后，操作系統(tǒng)才通知DBWR寫磁盤完成。對于這部分文件緩存，所需要的內(nèi)存可能比較大，作為保守的估計，我們應該考慮在0.2——0.3 倍內(nèi)存大小。但是如果我們使用的是裸設備，則不考慮這部分緩存的問題。這樣的情況下SGA就有調(diào)大的機會。

　　關(guān)于數(shù)據(jù)庫有多少并發(fā)連接，這實際上關(guān)系到PGA 的大小（MTS 下還有l(wèi)arge_pool_size）。事實上這個問題應該說還跟OLTP 類型或者OLAP 類型相關(guān)。對于OLTP類型oracle 傾向于可使用MTS,對于OLAP 類型使用獨立模式，同時OLAP 還可能涉及到大量的排序操作的查詢，這些都影響到我們內(nèi)存的使用。那么所有的問題綜合起來，實際上主要反映在UGA的大小上。UGA主要包含以下部分內(nèi)存設置

　　SQL> show parameters area_size

　　NAME                        TYPE                VALUE

　　------------------------------------ ------- -------------

　　bitmap_merge_area_size      integer            1048576

　　create_bitmap_area_size     integer            8388608

　　hash_area_size  ;            integer            131072

　　sort_area_size              integer            65536

　　在這部分內(nèi)存中我們最關(guān)注的通常是sort_area_size，這是當查詢需要排序的時候，數(shù)據(jù)庫會話將使用這部分內(nèi)存進行排序，當內(nèi)存大小不足的時候，使用臨時表空間進行磁盤排序。由于磁盤排序效率和內(nèi)存排序效率相差好幾個數(shù)量級，所以這個參數(shù)的設置很重要。這四個參數(shù)都是針對會話進行設置的，是單個會話使用的內(nèi)存的大小，而不是整個數(shù)據(jù)庫使用的。偶爾會看見有人誤解了這個參數(shù)以為是整個數(shù)據(jù)庫使用的大小，這是極其嚴重的錯誤。假如設置了MTS，則UGA被分配在large_pool_size，也就是說放在了共享內(nèi)存里面，不同進程（線程）之間可以共享這部分內(nèi)存。在這個基礎(chǔ)上，我們假設數(shù)據(jù)庫存在并發(fā)執(zhí)行serverprocess 為100 個，根據(jù)上面我們4 個參數(shù)在oracle8.1.7 下的默認值，我們來計算獨立模式下PGA 的大致大小。由于會話并不會經(jīng)常使用create_bitmap_area_size 、bitmap_merge_area_size，所以我們通常不對四個參數(shù)求和。在考慮到除這四個參數(shù)外會話所保存的變量、堆棧等信息，我們估計為2M，則200 個進程最大可能使用200M 的PGA。

　　現(xiàn)在，根據(jù)上面這些假定，我們來看SGA 實際能達到多少內(nèi)存。在1G 的內(nèi)存的服務器上，我們能分配給SGA 的內(nèi)存大約為400—500M。若是2G 的內(nèi)存，大約可以分到1G的內(nèi)存給SGA，8G 的內(nèi)存可以分到5G的內(nèi)存給SGA。當然我們這里是以默認的排序部分內(nèi)存sort_area_size=64k進行衡量的，假如我們需要調(diào)大該參數(shù)和hash_area_size等參數(shù)，然后我們應該根據(jù)并發(fā)的進程的數(shù)量，來衡量考慮這個問題。

　　事實上，通常我們更習慣通過直觀的公式化來表達這樣的問題：

　　OS使用內(nèi)存+SGA+并發(fā)執(zhí)行進程數(shù)*(sort_area_size+hash_ara_size+2M) < 0.7*總內(nèi)存

　　(公式是死的，系統(tǒng)是活的，實際應用的調(diào)整不必框公式，這不過是一個參考建議)

　　在我們的實際應用中，假如采用的是裸設備，我們可適當?shù)脑龃骃GA(如果需要的話)。由于目前幾乎所有的操作系統(tǒng)都使用虛擬緩存，所以實際上如果就算SGA 設置的比較大也不會導致錯誤，而是可能出現(xiàn)頻繁的內(nèi)存頁的換入與換出(page in/out)。在操作系統(tǒng)一級如果觀察到這個現(xiàn)象，那么我們就需要調(diào)整內(nèi)存的設置。

SGA內(nèi)參數(shù)設置

　　Log_buffer

　　對于日志緩沖區(qū)的大小設置，通常我覺得沒有過多的建議，因為參考LGWR寫的觸發(fā)條件之后，我們會發(fā)現(xiàn)通常超過3M意義不是很大。作為一個正式系統(tǒng)，可能考慮先設置這部分為log_buffer=1—3M 大小，然后針對具體情況再調(diào)整。

　　Large_pool_size

　　對于大緩沖池的設置，假如不使用MTS，建議在20—30M 足夠了。這部分主要用來保存并行查詢時候的一些信息，還有就是RMAN 在備份的時候可能會使用到。如果設置了MTS，則由于UGA部分要移入這里，則需要具體根據(jù)server process數(shù)量和相關(guān)會話內(nèi)存參數(shù)的設置來綜合考慮這部分大小的設置。

　　Java_pool_size

　　假如數(shù)據(jù)庫沒有使用JAVA，我們通常認為保留10—20M大小足夠。事實上可以更少，甚至最少只需要32k，但具體跟安裝數(shù)據(jù)庫的時候的組件相關(guān)(比如http server)。

　　Shared_pool_size

　　這是迄今為止最具有爭議的一部分內(nèi)存設置。按照很多文檔的描述，這部分內(nèi)容應該幾乎和數(shù)據(jù)緩沖區(qū)差不多大小。但實際上情況卻不是這樣的。首先我們要考究一個問題，那就是這部分內(nèi)存的作用，它是為了緩存已經(jīng)被解析過的SQL，而使其能被重用，不再解析。這樣做的原因是因為，對于一個新的SQL（shared_pool 里面不存在已經(jīng)解析的可用的相同的SQL），數(shù)據(jù)庫將執(zhí)行硬解析，這是一個很消耗資源的過程。而若已經(jīng)存在，則進行的僅僅是軟分析（在共享池中尋找相同SQL），這樣消耗的資源大大減少。所以我們期望能多共享一些SQL，并且如果該參數(shù)設置不夠大，經(jīng)常會出現(xiàn)ora-04031錯誤，表示為了解析新的SQL，沒有可用的足夠大的連續(xù)空閑空間，這樣自然我們期望該參數(shù)能大一些。但是該參數(shù)的增大，卻也有負面的影響，因為需要維護共享的結(jié)構(gòu)，內(nèi)存的增大也會使得SQL 的老化的代價更高，帶來大量的管理的開銷，所有這些可能會導致CPU 的嚴重問題。

　　在一個充分使用綁定變量的比較大的系統(tǒng)中，shared_pool_size 的開銷通常應該維持在300M 以內(nèi)。除非系統(tǒng)使用了大量的存儲過程、函數(shù)、包，比如oracle erp 這樣的應用，可能會達到500M甚至更高。于是我們假定一個1G內(nèi)存的系統(tǒng)，可能考慮設置該參數(shù)為100M，2G 的系統(tǒng)考慮設置為150M,8G 的系統(tǒng)可以考慮設置為200—300M。

　　對于一個沒有充分使用或者沒有使用綁定變量系統(tǒng)，這可能給我們帶來一個嚴重的問題。所謂沒有使用bind var 的SQL，我們稱為Literal SQL。也就是比如這樣的兩句SQL我們認為是不同的SQL,需要進行2 次硬解析：

　　select * from EMP where name = ‘TOM’;

　　select  * from EMP where name = ‘JERRY’;

　　假如把’TOM’ 和 ‘JERRY’ 換做變量V，那就是使用了bind var，我們可以認為是同樣的SQL 從而能很好地共享。共享SQL 本來就是shared_pool_size 這部分內(nèi)存存在的本意，oracle的目的也在于此，而我們不使用bind var 就是違背了oracle 的初衷，這樣將給我們的系統(tǒng)帶來嚴重的問題。當然，如果通過在操作系統(tǒng)監(jiān)控，沒有發(fā)現(xiàn)嚴重的cpu問題，我們?nèi)绻l(fā)現(xiàn)該共享池命中率不高可以適當?shù)脑黾觭hred_pool_size。但是通常我們不主張這部分內(nèi)存超過800M（特殊情況下可以更大）。

　　事實上，可能的話我們甚至要想辦法避免軟分析，這在不同的程序語言中實現(xiàn)方式有差異。我們也可能通過設置session_cached_cursors 參數(shù)來獲得幫助（這將增大PGA）。

　　Data buffer

　　現(xiàn)在我們來談數(shù)據(jù)緩沖區(qū)，在確定了SGA 的大小并分配完了前面部分的內(nèi)存后，其余的，都分配給這部分內(nèi)存。通常，在允許的情況下，我們都嘗試使得這部分內(nèi)存更大。這部分內(nèi)存的作用主要是緩存DB BLOCK，減少甚至避免從磁盤上獲取數(shù)據(jù)，在8i中通常是由db_block_buffers*db_block_size 來決定大小的。如果我們設置了buffer_pool_keep 和buffer_pool_recycle，則應該加上后面這兩部分內(nèi)存的大小。

9i下參數(shù)的變化

　　Oracle的版本的更新，總是伴隨著參數(shù)的變化，并且越來越趨向于使得參數(shù)的設置更簡單，因為復雜的參數(shù)設置使得DBA們經(jīng)常焦頭爛額。關(guān)于內(nèi)存這部分的變化，我們可以考察下面的參數(shù)。事實上在9i中數(shù)據(jù)庫本身可以給出一組適合當前運行系統(tǒng)的SGA相關(guān)部分的參數(shù)調(diào)整值（參考V$DB_CACHE_ADVICE、V$SHARED_POOL_ADVICE），關(guān)于PGA也有相關(guān)視圖V$PGA_TARGET_ADVICE 等。

　　Data buffer

　　9i 中保留了8i中的參數(shù)，如設置了新的參數(shù)，則忽略舊的參數(shù)。9i中用db_cache_size來取代db_block_buffers ， 用db_keep_cache_size 取代buffer_pool_keep, 用db_recycle_cache_size 取代buffer_pool_recycle；這里要注意9i 中設置的是實際的緩存大小而不再是塊的數(shù)量。另外9i新增加了db_nk_cache_size，這是為了支持在同一個數(shù)據(jù)庫中使用不同的塊大小而設置的。對于不同的表空間，可以定義不同的數(shù)據(jù)塊的大小，而緩沖區(qū)的定義則依靠該參數(shù)的支持。其中n 可以為2、4、6、8、16 等不同的值。在這里順便提及的一個參數(shù)就是db_block_lru_latches，該參數(shù)在9i中已經(jīng)成為了保留參數(shù)，不推薦手工設置。

　　PGA

　　在9i 里面這部分也有了很大的變化。在獨立模式下，9i已經(jīng)不再主張使用原來的UGA相關(guān)的參數(shù)設置，而代之以新的參數(shù)。假如workarea_size_policy=AUTO（缺省），則所有的會話的UGA 共用一大塊內(nèi)存，該內(nèi)存由pga_aggregate_target 設置。在我們根據(jù)前面介紹的方法評估了所有進程可能使用的最大PGA 內(nèi)存之后，我們可以通過在初始化參數(shù)中設置這個參數(shù)，從而不再關(guān)心其他”*_area_size&rdquo; 參數(shù)。

　　SGA_MAX_SIZE

　　在9i中若設置了SGA_MAX_SIZE，則在總和小于等于這個值內(nèi)，可以動態(tài)的調(diào)整數(shù)據(jù)緩沖區(qū)和共享池的大小

　　SQL> show parameters sga_max_size

　　NAME ;          TYPE             VALUE

　　------------------------------------ ------- -------------

　　sga_max_size&nbsp; unknown&nbsp;         193752940

　　SQL> alter system set db_cache_size = 30000000;

　　System altered.

　　SQL> alter system set shared_pool_size = 20480000;

　　System altered.

　　Lock_SGA = TRUE 的問題

　　由于幾乎所有的操作系統(tǒng)都支持虛擬內(nèi)存，所以即使我們使用的內(nèi)存小于物理內(nèi)存，也

　　不能避免操作系統(tǒng)將SGA 換到虛擬內(nèi)存（SWAP）。所以我們可以嘗試使得SGA 鎖定在物理內(nèi)存中不被換到虛擬內(nèi)存中，這樣減少頁面的換入和換出，從而提高性能。但在這里遺憾的是，windows 是無法避免這種情況的。下面我們來參考在不同的幾個系統(tǒng)下怎么實現(xiàn)lock_sga

　　AIX 5L（AIX 4.3.3 以上）

　　logon aix as root

　　cd /usr/samples/kernel

　　./vmtune (信息如下) v_pingshm已經(jīng)是1

　　./vmtune -S 1

　　然后oracle用戶修改initSID.ora 中 lock_sga = true

　　重新啟動數(shù)據(jù)庫

　　HP UNIX

　　Root身份登陸

　　Create the file "/etc/privgroup": vi /etc/privgroup

　　Add line "dba MLOCK" to file

　　As root, run the command "/etc/setprivgrp -f /etc/privgroup":

　　$/etc/setprivgrp -f /etc/privgroup

　　oracle用戶修改initSID.ora中l(wèi)ock_sga=true

　　重新啟動數(shù)據(jù)庫

　　SOLARIS (solaris2.6以上)

　　8i版本以上數(shù)據(jù)庫默認使用隱藏參數(shù) use_ism = true ，自動鎖定SGA于內(nèi)存中,不用設置lock_sga, 如果設置 lock_sga =true 使用非 root 用戶啟動數(shù)據(jù)庫將返回錯誤。

　　WINDOWS

　　不能設置lock_sga=true,可以通過設置pre_page_sga=true,使得數(shù)據(jù)庫啟動的時候就把所有內(nèi)存頁裝載，這樣可能起到一定的作用。

關(guān)于內(nèi)存參數(shù)的調(diào)整

　　關(guān)于參數(shù)調(diào)整，是oracle的復雜性的一個具體體現(xiàn)。通常來講，我們更傾向于讓客戶做statspack 報告，然后告訴我們os 監(jiān)控的狀況，在這些的信息的基礎(chǔ)上，再向客戶索取具體

　　的詳細信息以診斷問題的所在。系統(tǒng)的調(diào)整，現(xiàn)在我們通常采用從等待事件入手的方法。因為一個系統(tǒng)感覺到慢，必然是在某個環(huán)節(jié)上出現(xiàn)等待，那么我們從等待最多的事件入手逐步診斷并解決問題。

　　對于內(nèi)存的調(diào)整，相對來說簡單一些，我們首先可以針對數(shù)據(jù)緩沖區(qū)的大小來看。首先觀察命中率。

　　數(shù)據(jù)緩沖區(qū)命中率

　　SQL> select value from v$sysstat where name ='physical reads';

　　VALUE

　　----------

　　14764

　　SQL> select value from v$sysstat where name ='physical reads direct';

　　VALUE

　　----------

　　50

　　SQL> select value from v$sysstat where name ='physical reads direct (lob)';

　　VALUE

　　----------

　　0

　　SQL> select value from v$sysstat where name ='consistent gets';

　　VALUE

　　----------

　　167763

　　SQL> select value from v$sysstat where name = 'db block gets';

　　VALUE

　　----------

　　14305

　　這里命中率的計算應該是

　　令 x = physical reads direct + physical reads direct (lob)

　　命中率 =100 - ( physical reads - x) / (consistent gets + db block gets - x)*100

　　通常如果發(fā)現(xiàn)命中率低于90%,則應該調(diào)整應用可可以考慮是否增大數(shù)據(jù)緩沖區(qū)共享池的命中率

　　SQL> select sum(pinhits-reloads)/sum(pins)*100 "hit radio" from v$librarycache;

　　hit radio

　　----------

　　99.809291

　　假如共享池的命中率低于95%,就要考慮調(diào)整應用（通常是沒使用bind var ）或者增加內(nèi)存。

　　關(guān)于排序部分

　　SQL> select name,value from v$sysstat where name like '%sort%';

　　NAME  &nbsp;              VALUE

　　---------------------------------------------------------------- -------

　　sorts (memory) &nbsp;     67935

　　sorts (disk)&nbsp;   &nbsp;    1

　　sorts (rows)         7070

　　假如我們發(fā)現(xiàn)sorts (disk)/ (sorts (memory)+ sorts (disk))的比例過高，則通常意味著sort_area_size 部分內(nèi)存較小，可考慮調(diào)整相應的參數(shù)。

　　關(guān)于log_buffer

　　SQL> select name,value from v$sysstat

　　2 where name in('redo entries','redo buffer allocation retries');

　　NAME          &nbsp;                VALUE

　　-----------------------        -------------------------------------

　　redo entries           &nbsp;    &nbsp;  2325719

　　redo buffer allocation retries 10

　　假如redo buffer allocation retries/ redo entries 的比例超過1%我們就可以考慮增大log_buffer

　　通常來說，內(nèi)存的調(diào)整的焦點就集中在這幾個方面，更多更詳細的內(nèi)容，建議從statspack入手來一步一步調(diào)整。最后關(guān)于內(nèi)存的調(diào)整，再強調(diào)這一點，一定要結(jié)合操作系統(tǒng)來衡量，任何理論都必須要實踐來檢驗。在操作系統(tǒng)中觀察page in/out 狀況，發(fā)現(xiàn)問題嚴重，應該考慮調(diào)小SGA。

32bit 和64bit 的問題

　　對于oracle 來說，存在著32bit與64bit的問題。這個問題影響到的主要是SGA的大小。在32bit的數(shù)據(jù)庫下，通常oracle只能使用不超過1.7G的內(nèi)存，即使我們擁有12G的內(nèi)存，但是我們卻只能使用1.7G，這是一個莫大的遺憾。假如我們安裝64bit的數(shù)據(jù)庫,我們就可以使用很大的內(nèi)存，我們幾乎不可能達到上限。但是64bit 的數(shù)據(jù)庫必須安裝在64bit 的操作系統(tǒng)上，可惜目前windows 上只能安裝32bit的數(shù)據(jù)庫，我們通過下面的方式可以查看數(shù)據(jù)庫是32bit 還是64bit：

　　SQL> select * from v$version;

　　BANNER

　　----------------------------------------------------------------

　　Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production

　　PL/SQL Release 8.1.7.0.0 - Production

　　CORE 8.1.7.0.0 Production

　　TNS for 32-bit Windows: Version 8.1.7.0.0 - Production

　　NLSRTL Version 3.4.1.0.0 - Production

　　但是在特定的操作系統(tǒng)下，可能提供了一定的手段，使得我們可以使用超過1.7G 的內(nèi)存，達到2G 以上甚至更多。在這里我們針對不同的平臺下的具體實現(xiàn)方式做一個總結(jié)。