三角洲的引擎版本是4.24织狐，其硬件基線為：
- PC為GTX 650
- Android為Adreno 512
PC版本性能標(biāo)準(zhǔn)給出如下：
- Base Pass的DP：從500 ~ 1200
- 同屏總面數(shù)：1M ~ 3M
- Base Pass面數(shù)：0.6M ~ 1.4M
- 局部光源數(shù)：3 ~ 5
移動(dòng)端性能標(biāo)準(zhǔn)：
- 總DP：250 ~ 650
- 場(chǎng)景總DP：180 ~ 510
- Base Pass DP：140 ~ 390
特效DP：10 ~ 40
面數(shù)：3k ~ 6k
場(chǎng)景頂點(diǎn)數(shù)：35w ~ 100w
這里對(duì)一體化的定義是：
- 相同的資源
- 同一批開(kāi)發(fā)同學(xué)
- 同一套制作開(kāi)發(fā)工具
要求做到：
- 一次性的編輯制作（絕大部分情況下）
- 玩法體驗(yàn)的一致
- 兼顧多平臺(tái)性能
移動(dòng)端+PC的跨平臺(tái)挑戰(zhàn) & 解決方案：
1.硬件差異導(dǎo)致的性能差異
a.不同設(shè)備運(yùn)行不同的renderer（deferred + forward）
2.多平臺(tái)聯(lián)動(dòng)狸吞、協(xié)同體驗(yàn)伟墙，要求資產(chǎn)跟玩法的同步發(fā)行
a.通過(guò)一套管線镣丑，實(shí)現(xiàn)多端的同步研發(fā)與發(fā)布
多端的支持，可以拆分為兩個(gè)部分：
1.生產(chǎn)管線：美術(shù)資源的制作
2.運(yùn)行時(shí)體驗(yàn)：包括gameplay跟性能優(yōu)化
資源制作管線的挑戰(zhàn)在于如何用一套資源實(shí)現(xiàn)多個(gè)平臺(tái)的支持鹅心，其中涉及到了資產(chǎn)的制作方式级历，LOD、Shader等的管理捣郊，這里面會(huì)面臨很多的問(wèn)題：
- 資產(chǎn)制作層面
- 雙端是否共用同一套關(guān)卡
- mesh晶密、texture如何應(yīng)用到多個(gè)平臺(tái)： LOD起始Index、切換距離模她；物理碰撞的精度稻艰；材質(zhì)復(fù)雜度 —— 做好配套的資源規(guī)范工具（LOD切換距離、頂點(diǎn)密度侈净、貼圖尺寸尊勿、材質(zhì)復(fù)雜度等）
- 地形數(shù)據(jù)如何實(shí)現(xiàn)多平臺(tái)的兼容
- 如何保證雙端的物理表現(xiàn)一致
- 如何保障復(fù)雜的資產(chǎn)制作約束規(guī)則下的生產(chǎn)效率
- 同時(shí)研發(fā)端游 & 手游，人力&優(yōu)先級(jí)如何權(quán)衡：白盒 -> 端游效果&性能 -> 手游效果&性能 -> 雙端兼顧
- 如何實(shí)現(xiàn)多端表現(xiàn)的高效debug（快速預(yù)覽）
- 離線優(yōu)化層面
- 如何從編輯關(guān)卡轉(zhuǎn)化為具有最佳性能表現(xiàn)的運(yùn)行時(shí)關(guān)卡（兼顧PIE跟構(gòu)包）—— 在Cook階段做了很多處理畜侦，包括：
A. 構(gòu)建針對(duì)不同平臺(tái)的地形數(shù)據(jù)（heightmap之類）
B. 構(gòu)建針對(duì)不同平臺(tái)的植被數(shù)據(jù)
C. 場(chǎng)景物件處理（過(guò)濾不需要的component元扔，完成物件到grid、layer的分配旋膳，合并ISM澎语，陰影優(yōu)化，SOC遮擋物優(yōu)化）验懊，結(jié)果以增量形式存在（擅羞？），這里物件是基于剔除時(shí)的screensize來(lái)設(shè)置其所屬的grid/layer的（仿造TextureGroup的概念义图，增加了一個(gè)MeshGroup的概念减俏，方便實(shí)現(xiàn)對(duì)某一類數(shù)據(jù)的批量處理） - 不同平臺(tái)的運(yùn)行時(shí)關(guān)卡該如何做分別的處理
D. 構(gòu)建場(chǎng)景物理數(shù)據(jù)
E. 移動(dòng)端做物件的合批處理
F. 構(gòu)建PVS
G. 構(gòu)建遠(yuǎn)景
- 運(yùn)行時(shí)優(yōu)化層面
- 哪些算法需要雙端各有一套：移動(dòng)端需要合批（PC用模組化+GPU Driven）
- 哪些算法需要雙端各有一套參數(shù)配置：Streamping配置（加載范圍、cell size）
- 哪些資源需要雙端各有一套：裝飾物（有的只有PC有碱工，有的則是PC具有多樣化的物件）
從上圖可以看到娃承，針對(duì)某一類固定資產(chǎn)奏夫，有些數(shù)據(jù)是可以跨平臺(tái)復(fù)用的，有些則是不能历筝，如果我們希望生產(chǎn)管線能夠自動(dòng)適配多個(gè)不同平臺(tái)酗昼，就要將不能復(fù)用的數(shù)據(jù)拆出來(lái)，這對(duì)引擎改造來(lái)說(shuō)是一項(xiàng)大工程梳猪。
此外仔雷，針對(duì)不同的資產(chǎn)類型，處理的方式也是完全不同的舔示，從而進(jìn)一步加劇了這個(gè)問(wèn)題。
展開(kāi)來(lái)說(shuō)：
1.針對(duì)同一套材質(zhì)电抚，需要考慮如何輸出不同平臺(tái)的兩套shader惕稻，而且，這里還需要考慮不同渲染管線的區(qū)別
2.Mesh的LOD雖然在復(fù)用的處理上比較簡(jiǎn)單蝙叛，但是FPS游戲希望在多端上的碰撞表現(xiàn)是一致的
3.貼圖的分辨率以及壓縮設(shè)置也需要做不同的處理（這個(gè)看起來(lái)相對(duì)簡(jiǎn)單）
4.還需要將當(dāng)前平臺(tái)不用的數(shù)據(jù)從cook列表中剔除出去
在管線的選擇上：
1.PC+高端移動(dòng)機(jī)型俺祠，采用的是延遲渲染管線
2.中低端移動(dòng)機(jī)型，采用的是前向渲染管線
為了通過(guò)同一套材質(zhì)來(lái)應(yīng)對(duì)上述設(shè)備借帘、管線的差異蜘渣，DFM提出了一種叫做Virtual Material System的東西，這個(gè)東西有如下特性（看起來(lái)更像是一個(gè)大雜燴肺然，而非一套從最初就完整設(shè)計(jì)好的系統(tǒng)蔫缸，應(yīng)該也是初次使用）：
1.將資源與shading解耦
2.支持對(duì)資源的自定義組織，比如貼圖通道的remapping
3.支持對(duì)不同平臺(tái)际起、不同quality level的配置（相當(dāng)于性能的分級(jí)）
4.提供了一套模塊化的材質(zhì)函數(shù)模塊以實(shí)現(xiàn)材質(zhì)邏輯的復(fù)用
在編輯器模式下拾碌，美術(shù)跟TA同學(xué)會(huì)為對(duì)應(yīng)的資源（模型）配置好母材質(zhì)，并編輯對(duì)應(yīng)quality level的效果街望，在cook的時(shí)候校翔，會(huì)將這個(gè)材質(zhì)烘焙成不同的材質(zhì)實(shí)例，并完成這個(gè)材質(zhì)實(shí)例與資源的關(guān)聯(lián)灾前。
下面看看這個(gè)系統(tǒng)是如何工作的防症，系統(tǒng)組織邏輯如下圖所示：
1.整個(gè)系統(tǒng)分為三個(gè)模塊，分別是Material Layer哎甲、Virtual Material Template以及Virtual Material Instance
a.Material Layer是整個(gè)系統(tǒng)的核心模塊蔫敲，大部分的功能都是由這個(gè)模塊承接
b.Template模塊可以認(rèn)為是對(duì)UE母材質(zhì)的封裝，基于這個(gè)Template炭玫，美術(shù)跟TA同學(xué)可以完成材質(zhì)的編輯與配置工作
c.Instance是整個(gè)系統(tǒng)的產(chǎn)出物燕偶，在cook的時(shí)候會(huì)被烘焙成不同平臺(tái)的Material Instance
2.Material Layer包括三個(gè)部分，分別是Data Provider础嫡，Effect Layer以及Blend Controller
a.Data Provider負(fù)責(zé)材質(zhì)的數(shù)據(jù)部分指么，包括搜集貼圖酝惧、暴露貼圖插槽以及管理不同quality level的資源
b.Effect Layer包含兩個(gè)功能，分別是負(fù)責(zé)材質(zhì)的效果邏輯以及與上一層的blend（伯诬？）
c.Blend Controller則是負(fù)責(zé)一些復(fù)雜的混合邏輯
基于這個(gè)設(shè)計(jì)晚唇，就能實(shí)現(xiàn)shader跟mesh之間的解耦，從而實(shí)現(xiàn)同一個(gè)mesh在不同平臺(tái)上的不同shader實(shí)現(xiàn)
下面來(lái)看下盗似，針對(duì)不同平臺(tái)上哩陕，怎么做到同樣的碰撞表現(xiàn)。
DFM中將模型分為6級(jí)LOD赫舒，其中PC會(huì)使用完全的6級(jí)（悍及？），而移動(dòng)端則只使用后面3級(jí)接癌。
可以看到心赶，移動(dòng)端上的Mesh LOD Bias為3，因此mesh的精度相對(duì)于PC會(huì)有所下降缺猛，因此部分細(xì)節(jié)會(huì)丟失缨叫，如下圖所示，圖中的圍欄從LOD3的時(shí)候就會(huì)被移除：
1.如果圍欄對(duì)應(yīng)的碰撞還在移動(dòng)端上保留荔燎，那玩家的體驗(yàn)就會(huì)下降
2.如果碰撞移除耻姥，那么跟PC的體驗(yàn)就會(huì)不一致
3.如果PC跟移動(dòng)端的碰撞都移除，就會(huì)導(dǎo)致效果上的不真實(shí)
這里采取的解決方案是為不同平臺(tái)設(shè)計(jì)不同的碰撞數(shù)據(jù)有咨，這里沒(méi)有詳細(xì)描述解決方案（說(shuō)是TA的talk中有更多描述琐簇，后面有時(shí)間可以來(lái)補(bǔ)充一下）。這里想到的一個(gè)方案是在LOD減面的時(shí)候座享，需要考慮碰撞數(shù)據(jù)的影響鸽嫂，對(duì)于會(huì)影響碰撞表現(xiàn)的部分，在減面的時(shí)候要予以保留征讲。
這種為不同平臺(tái)進(jìn)行數(shù)據(jù)定制的策略不僅僅用在碰撞上面据某，對(duì)于其他的一些資產(chǎn)如天空盒的貼圖與壓縮配置、lightmap的相關(guān)配置诗箍，也是采用同樣的策略癣籽。
講完了資產(chǎn)編輯與準(zhǔn)備，接下來(lái)看看場(chǎng)景的表現(xiàn)與性能滤祖，在這里筷狼，既需要兼顧場(chǎng)景的豐富度，也需要照顧移動(dòng)端性能下的加載范圍
為了實(shí)現(xiàn)上面所述的兼顧匠童，這里的思路是將場(chǎng)景的資源拆分為兩個(gè)部分：
1.共享層埂材，存儲(chǔ)的是各個(gè)平臺(tái)共用的數(shù)據(jù)
a.出于玩法的統(tǒng)一，對(duì)于玩法有影響的數(shù)據(jù)需要放到這個(gè)地方
b.出于保持主體視覺(jué)的一致汤求，場(chǎng)景的基本布局相關(guān)數(shù)據(jù)也要放在這里
2.平臺(tái)層俏险，存儲(chǔ)的是各個(gè)平臺(tái)特有的數(shù)據(jù)：出于性能的兼顧严拒，一些偏表現(xiàn)層的數(shù)據(jù)則可以考慮放到這里
對(duì)于共享的數(shù)據(jù)，也需要針對(duì)平臺(tái)的不同做一些處理竖独，如下圖所示裤唠，共享數(shù)據(jù)會(huì)被分為HD & Mobile兩類。
為了減少美術(shù)同學(xué)的工作量莹痢，這里的另一個(gè)原則是盡量將數(shù)據(jù)往共享層挪种蘸，基于這個(gè)原則，通過(guò)PCG或者其他自動(dòng)生成工具輸出的數(shù)據(jù)都會(huì)自動(dòng)被拆分為多個(gè)平臺(tái)的
下面看下不同平臺(tái)下的效果對(duì)比：
大型項(xiàng)目的另一個(gè)問(wèn)題竞膳，如何實(shí)現(xiàn)海量資源的高效管理航瞭，包括如何維護(hù)資源的規(guī)范以避免混亂，如何降低數(shù)據(jù)的冗余（比如通過(guò)對(duì)資源的掃描坦辟，找出重復(fù)的貼圖或材質(zhì)等）以及如何保障資源的正確引用等刊侯，常用的策略是提供相應(yīng)的檢查與預(yù)警工具
針對(duì)不同平臺(tái)，在運(yùn)行時(shí)的Streaming配置也需要做不同的處理：
1.為不同平臺(tái)长窄、不同資源類型設(shè)置不同的加載距離
2.對(duì)于開(kāi)鏡時(shí)的處理也會(huì)有所不同，PC是全加載纲菌，在開(kāi)鏡的時(shí)候切換可見(jiàn)性挠日；移動(dòng)端則是在開(kāi)鏡的瞬間加載在Frustum內(nèi)部的數(shù)據(jù)（性能？）
接下來(lái)看看DFM針對(duì)Runtime level做了哪些優(yōu)化：
1.一些debug的actor會(huì)從runtime levele中移除出去
2.物理模擬跑在DS上翰舌，需要將之從Mesh中抽取出來(lái)嚣潜，并按照一定規(guī)則做合并
3.為了降低植被的內(nèi)存&drawcall消耗，針對(duì)不同的foliage類型椅贱，做了不同的streaming設(shè)置
4.地形被替換成基于CDLOD實(shí)現(xiàn)的方案
5.由于使用的引擎是UE4懂算，不能直接使用UE5的World Partition，這里就直接采用了類似的基于grid劃分的方式來(lái)對(duì)mesh actor進(jìn)行分塊streaming
如下圖所示庇麦，上述過(guò)程中的部分優(yōu)化是集成在自動(dòng)構(gòu)建環(huán)節(jié)中的：
其中針對(duì)移動(dòng)端计技，還做了靜態(tài)合批以減少Drawcall：
1.先對(duì)需要合批的模型進(jìn)行合并前的確認(rèn)，包括材質(zhì)山橄、貼圖等是否符合合并規(guī)則
2.之后確認(rèn)合并后的數(shù)據(jù)的有效性垮媒，比如頂點(diǎn)數(shù)是否超上限、貼圖是否超出最大分辨率以及距離是否合理（指的是待合并的模型之間的距離航棱？）
靜態(tài)合并的好處是可以保證數(shù)據(jù)有較好的局部性睡雇，同時(shí)提升渲染時(shí)的性能
接下來(lái)看看DFM在渲染上的一些策略、如何在多端上實(shí)現(xiàn)統(tǒng)一的gameplay效果以及常用的一些性能工具：
雖然不同平臺(tái)的渲染管線是不同的饮醇，但是項(xiàng)目組希望不同平臺(tái)都具有相同或者相似的主要特性它抱，下面給了兩條管線的框架（如果想要復(fù)刻這套思路，我們也應(yīng)該有一張自己的圖朴艰，圖中甚至需要給出不同級(jí)別的設(shè)備的差異）：
先看光照部分观蓄，為了實(shí)現(xiàn)統(tǒng)一的光照效果混移，對(duì)于主要的特性而言，在不同平臺(tái)上的實(shí)現(xiàn)方式會(huì)有所不同蜘腌，比如sky occlusion是多端共享的沫屡，但是AO的實(shí)現(xiàn)策略卻有所不同，移動(dòng)端走烘焙撮珠，PC則使用的是GTAO以及DFAO（距離場(chǎng)）沮脖，基于這種一致性設(shè)計(jì)，美術(shù)同學(xué)就不需要為場(chǎng)景做兩套設(shè)計(jì)芯急，可以大大提高工作效率
GI方案是基于體素實(shí)現(xiàn)的勺届，體素中存儲(chǔ)的不是光照信息，而是離線烘焙的probe與權(quán)重?cái)?shù)據(jù)（娶耍？）免姿，為了實(shí)現(xiàn)多端統(tǒng)一的效果，做了如下約束：
1.probe分布算法在多端是一致的榕酒，不同的是PC端的probe密度會(huì)更高
2.probe的數(shù)據(jù)填充邏輯是一致的
3.probe的streaming邏輯是一致的
區(qū)別體現(xiàn)在基于性能考慮的一些計(jì)算方式上：
1.移動(dòng)端數(shù)據(jù)密度低（probe密度）胚膊，GPU性能稍差，因此probe數(shù)據(jù)是在CPU完成讀取想鹰，并組裝成3D貼圖紊婉，之后傳給GPU進(jìn)行采樣計(jì)算。優(yōu)化的重點(diǎn)在于如何提升CPU的讀取效率（比如提高緩存友好度辑舷，優(yōu)化數(shù)據(jù)壓縮算法等）
2.PC上的數(shù)據(jù)密度高喻犁，不需要通過(guò)CPU中轉(zhuǎn)，直接讀取到GPU中何缓，在GPU中完成數(shù)據(jù)的解壓與解析肢础。GPU的關(guān)注重點(diǎn)為如何提高顯存的利用率，這里的做法是將probe按照稀疏的樹(shù)狀結(jié)構(gòu)存儲(chǔ)碌廓，此外传轰，考慮到CPU到GPU數(shù)據(jù)傳輸時(shí)的卡頓，這里也做了異步處理
有了動(dòng)態(tài)GI谷婆，很自然的就可以添加TOD效果路召，DFM的TOD是通過(guò)sequencer驅(qū)動(dòng)的，多平臺(tái)共用的參數(shù)存儲(chǔ)在基礎(chǔ)sequencer中波材，跟平臺(tái)相關(guān)的額外參數(shù)則存儲(chǔ)在另一個(gè)單獨(dú)的sequencer中：
地形的方案是優(yōu)先PC股淡，在先進(jìn)特性的實(shí)施過(guò)程中，考慮在移動(dòng)端的落地：
1.看下圖描述是基于Material ID實(shí)現(xiàn)的
2.Texture Array移動(dòng)端最多32套廷区，PC端則是256套
a.數(shù)據(jù)支持動(dòng)態(tài)的增減
3.每個(gè)像素可以支持多層混合
4.采用了AVT技術(shù)唯灵，還做了運(yùn)行時(shí)VT的壓縮
5.在移動(dòng)端上的規(guī)格為，每米大約會(huì)占用到500+個(gè)texel隙轻，以及3套材質(zhì)
6.Cliff（懸崖峭壁）也是基于VT實(shí)現(xiàn)埠帕，采用了隨機(jī)的tri-planar blend方案
7.還以米為單位存儲(chǔ)了biome（植被）信息（染色垢揩、濕度以及AO）以提升場(chǎng)景的豐富度。這里的數(shù)據(jù)是用clipmap存儲(chǔ)的敛瓷，相對(duì)于完全平鋪的方式叁巨，可以極大的節(jié)省內(nèi)存：從133M到2M
8.用了大量的貼花與軟件Tessellation
9.用80k的頂點(diǎn)實(shí)現(xiàn)了接近380k的遠(yuǎn)景效果（用的Tessellation？）
關(guān)于地形的渲染細(xì)節(jié)呐籽，在Unreal Fest 2023中有更多分享
接下來(lái)看下Gameplay一致性如何保障锋勺，這里將整體的gameplay邏輯分為三層：
1.Core feature layer：對(duì)應(yīng)的是所有平臺(tái)都一直的一些基礎(chǔ)特性，比如Gameplay框架狡蝶、網(wǎng)絡(luò)模型庶橱、移動(dòng)同步、武器射擊以及其他的一些戰(zhàn)斗細(xì)節(jié)贪惹。
2.Flexible feature layer：負(fù)責(zé)提供一些可以在不同平臺(tái)上做伸縮控制的特性苏章，這些特性可以基于設(shè)備的性能、quality level等來(lái)進(jìn)行參數(shù)的動(dòng)態(tài)調(diào)控與特性的開(kāi)關(guān)
3.Platform feature layer：用于實(shí)現(xiàn)平臺(tái)不同的特性奏瞬，比如input/HUD等
關(guān)于角色動(dòng)畫(huà)的跨平臺(tái)設(shè)計(jì)包括：
1.各平臺(tái)使用同一套basic skeleton枫绅，只是PC上會(huì)增加一些額外的骨骼與動(dòng)態(tài)信息
2.動(dòng)畫(huà)數(shù)據(jù)基于同一個(gè)角色的parent skeleton創(chuàng)建，因此可以在雙端進(jìn)行復(fù)用
a.PC上會(huì)采用更高的幀率與效果更好的壓縮方式
大部分的動(dòng)畫(huà)特性都是雙端共享的硼端，只在部分特性上做了處理并淋，對(duì)于這些做了處理的特性，有一些也會(huì)提供一些開(kāi)關(guān)允許在高端設(shè)備上開(kāi)啟显蝌，比如換彈動(dòng)畫(huà)预伺，在PC上是完整的動(dòng)作片段订咸，而在移動(dòng)端上則是通過(guò)IK來(lái)模擬的曼尊，雖然看起來(lái)差不多：
DFM還設(shè)計(jì)了一套規(guī)劃算法，來(lái)基于每臺(tái)設(shè)備的性能表現(xiàn)與預(yù)算脏嚷，動(dòng)態(tài)決定哪些特性是否需要開(kāi)啟骆撇，總的來(lái)說(shuō)，這套算法的思路跟knapsack算法類似父叙，會(huì)需要先為每個(gè)feature指定一個(gè)權(quán)重神郊，之后會(huì)基于feature開(kāi)啟后的性能消耗來(lái)對(duì)所有feature進(jìn)行評(píng)估權(quán)衡，以獲得最高性價(jià)比
這里還給了兩個(gè)演示視頻來(lái)展示這個(gè)算法的效果
DFM還設(shè)計(jì)了一套自適應(yīng)的UI框架趾唱，大部分的UI數(shù)據(jù)都是包含在這個(gè)框架里的涌乳。
為了提升跨平臺(tái)共用的效率，這里會(huì)將平臺(tái)相關(guān)的參數(shù)抽取到framework layer（甜癞？）：
1.DPI會(huì)跟屏幕分辨率有關(guān)夕晓，因此需要為不同平臺(tái)做專屬設(shè)計(jì)，Display Ratio悠咱、Padding也有同樣的問(wèn)題
2.不同平臺(tái)的UI導(dǎo)航方式（蒸辆？）會(huì)不一樣征炼，這部分會(huì)需要放在navigation layer中
DFM的目標(biāo)分辨率設(shè)定是2k：
1.UI資源的原始尺寸是2k的話，在移動(dòng)端上會(huì)被cook成1080P的
2.PC跟Mobile共享的資源躬贡，在PC平臺(tái)會(huì)在運(yùn)行時(shí)被DPI下采樣為原始資源的2/3谆奥，但是會(huì)達(dá)到跟4k一樣的效果（？）
3.在PC上拂玻，建議打開(kāi)mipmap來(lái)避免像素的mismatch
最后看看性能工具酸些，DFM對(duì)工具訴求是：
1.支持跨平臺(tái)使用
2.不需要pre-instrumentation（代碼預(yù)埋）
3.支持長(zhǎng)時(shí)間的、可擴(kuò)展的數(shù)據(jù)搜集
4.不會(huì)對(duì)運(yùn)行時(shí)性能產(chǎn)生影響
最終自己開(kāi)發(fā)了一套：
工具的邏輯可以分為三層：
1.通過(guò)一套跨平臺(tái)可調(diào)用的接口實(shí)現(xiàn)高性能的數(shù)據(jù)采樣纺讲，這個(gè)采樣會(huì)結(jié)合每幀的時(shí)間消耗與自定義的數(shù)據(jù)擂仍，統(tǒng)計(jì)出每一幀的性能數(shù)據(jù)
2.對(duì)每個(gè)函數(shù)的性能數(shù)據(jù)與函數(shù)的堆棧進(jìn)行分析，得到一幀的call tree
3.通過(guò)一個(gè)服務(wù)+既定的規(guī)則來(lái)對(duì)所有數(shù)據(jù)進(jìn)行分析熬甚，這里會(huì)進(jìn)行一系列的自動(dòng)化分析逢渔，比如Pearson correlation coefficient（皮爾遜相關(guān)系數(shù)分析），基于這個(gè)可以統(tǒng)計(jì)出函數(shù)之間的關(guān)聯(lián)關(guān)系
