[[191595]]

所謂的熱點圖，是圖1)構(gòu)建一張灰度圖，圖2)在每個熱點的位置上繪制并疊加形成灰色的熱點圖，圖3)根據(jù)顏色表生成熱點圖。不難看出，最核心的是圖2的過程。

[[191596]]

圖1

[[191597]]

圖2&圖3

1強(qiáng)調(diào)兩處細(xì)節(jié)

這種思路效率高，缺點就是不夠靈活，每個點都是同一個樣式，沒有考慮該點的半徑和權(quán)重。創(chuàng)建大小不一的模版(章)，每個熱點根據(jù)自己的半徑值選擇對應(yīng)的章就可以，實現(xiàn)思路如下：

半徑&模版

權(quán)重的不同，是通過蓋章的“力度”，權(quán)重越大，不透明度越大，這樣疊加時也越能體現(xiàn)權(quán)重大的效果。是否發(fā)現(xiàn)，這個方式會產(chǎn)生覆蓋情況，并不嚴(yán)謹(jǐn)。

權(quán)重&透明度(力度)

2大數(shù)據(jù)渲染

我們看看在不同數(shù)據(jù)量下的性能分析。7759個熱點，每個點有經(jīng)緯度和權(quán)重三個float值，生成一張2000*1400左右的熱點圖。采用pa7/heatmap.js，在Chrome下測試1w(1倍)，5w(5倍)，10w(15倍)，60w(75倍)，100w(150倍)，600w(750)六個級別，***別會崩潰。

備注：只測試了一次，誤差估計不小，僅供參考。

數(shù)據(jù)轉(zhuǎn)換消耗(毫秒)

純渲染時間(毫秒)

在這種方式下渲染時間依次為：68，100，194，894，2918，63817(ms)。數(shù)據(jù)量在100w以內(nèi)的還好，渲染時間將近3s。但再往上就不給力了。***別下讀取會崩潰，內(nèi)存達(dá)到1.2G以上。渲染就算可用，從時間消耗上也不實用。

在渲染性能方面，之前我們通過模版，蓋章的思路已經(jīng)優(yōu)化了，沿著這個思路提升空間不大。而且，因為渲染上存在疊加依賴，很難并行。

CPU并行

自己實現(xiàn)渲染算法，以并行的方式實現(xiàn)數(shù)值計算部分。思路如下：對熱點圖這個目標(biāo)圖片，遍歷每一個像素，以像素半徑做一個緩沖區(qū)分析，獲取對應(yīng)的熱點數(shù)據(jù)(數(shù)據(jù)支持范圍查詢)。如果沒有熱點，則該像素為空;如果存在N個熱點，則計算該點的熱點值。乍看上去，這不是又倒退到逐點計算的思路上。

坦白說，我很不喜歡這個思路，就好比老師出了一道1+2+3……+100的題目，本來是想讓你發(fā)現(xiàn)規(guī)律和數(shù)據(jù)模型，?？墒悄阏娴脑谝粋€個累加。但全班同學(xué)合作，把這100個數(shù)分解成10組，每人分別計算一部分，同樣也能很快得出結(jié)果，這就是另一個角度的智慧。

因為每個點的計算是獨立的，可以通過并行來優(yōu)化“渲染”時間。但這種思路是以放棄渲染技術(shù)為代價的，也要借助于空間索引，并行計算，在JS上很難實現(xiàn)。

另外，這個思路讓我認(rèn)為(不知道對不對)，點差值和熱點圖并無本質(zhì)區(qū)別。

GPU并行

下圖是OpenGL的思路：每一個熱點構(gòu)造成一個正方形，對角線將其分為兩個三角形，有四個頂點和6個頂點索引。采用批次渲染的方式，每個批次下渲染1w個熱點(對應(yīng)4w個頂點)，將數(shù)據(jù)分解為多個批次，實現(xiàn)大數(shù)據(jù)的渲染，GPU中實現(xiàn)混合效果。具體的shader代碼可以參考pyalot。

我在WebGL下實現(xiàn)了這個思路，還是剛才那個7759個熱點的數(shù)據(jù)，我放到一個渲染批次，對這一個批次渲染多次， 1s內(nèi)完成***別的渲染。

3問題

數(shù)據(jù)解析是瓶頸，比如經(jīng)緯度點最終要轉(zhuǎn)換到像素單。如果性能還不夠，就“偷工減料”，建立矢量金字塔，本質(zhì)就是把N個點合并成一個，減少渲染過程的計算量。

二維對應(yīng)的策略是，渲染性能不夠，就把渲染問題轉(zhuǎn)為for循環(huán)下的簡單計算，然后通過CPU并行優(yōu)化;對于三維，需要點轉(zhuǎn)三角形，創(chuàng)建buffer，然后通過GPU實現(xiàn)渲染過程。

從渲染的角度來看，無論二維還是三維，在十萬級別下的性能都不錯，***別也能接受，差別不大，但十萬以上，兩者的渲染差距則體現(xiàn)出來，前者像打狗棒，強(qiáng)調(diào)的是心法和招式，后者則是降龍十八掌，靠的是內(nèi)力。兩點區(qū)別，二維是因為渲染性能不行，只好采用最簡單的數(shù)值計算，以這樣的代價實現(xiàn)核心計算的并行;三維本身就是并行策略，就是通過shader，通過頂點和片元實現(xiàn)GPU的并行。第二，GPU的并行能力顯然不是CPU可以媲美的，換句話說，GPU能夠承擔(dān)更多的并發(fā)計算量，盡可能少的對原始數(shù)據(jù)做預(yù)處理，理論上，只要內(nèi)存夠用或讀取數(shù)據(jù)合理，顯存上通過批次渲染，可以渲染任意大的數(shù)據(jù)量，而且時間和批次應(yīng)該是線性的。

***，再強(qiáng)調(diào)一下數(shù)據(jù)。簡單計算了一下，假如是一個二進(jìn)制流的方式，一個熱點占12個字節(jié)，這樣1kw個點要占120M，即使壓縮后也得20M，這還沒有考慮數(shù)據(jù)轉(zhuǎn)換上的消耗。對于Web端，基于原始數(shù)據(jù)，需要有一種機(jī)制，能夠快速的完成數(shù)據(jù)傳輸和處理。

有一個不一定對的思路，建一個GeoHash，大范圍的預(yù)先生成熱點圖，更新頻率可以不高;局部范圍則通過GeoHash獲取對應(yīng)的熱點，實現(xiàn)本地渲染。GeoHsh貌似是一種很不錯的大數(shù)據(jù)設(shè)計方式，我也不太了解，有時間再研究研究。

還有一個收獲，當(dāng)復(fù)雜度達(dá)到一定程度，原先行得通的算法和方案不一定滿足要求了。更精彩的是，因為性能低，以前認(rèn)為比較差的思路，因為思路簡單，容易實現(xiàn)并行改造，竟然可行了。