文章目錄

• 錯(cuò)誤描述
• • 錯(cuò)誤分析
  • 效率
• 找到的正確的代碼
• 個(gè)人維護(hù)的Astar倉庫

---

看懂本文的前提是了解清楚A星算法的原理

推薦這篇 A星算法詳解(個(gè)人認(rèn)為最詳細(xì),最通俗易懂的一個(gè)版本)

---

錯(cuò)誤描述

項(xiàng)目里的尋路算法是主程(已經(jīng)走了)從網(wǎng)上直接copy下來用的
簡單測試了下，以80*80的地圖為例，發(fā)現(xiàn)從(0,0)到((30,30)之間隨便找個(gè)起點(diǎn)，到終點(diǎn)(length-1,length-1)的路徑全都尋不到

排查到問題之后挺無語，百度搜到的Java實(shí)現(xiàn)的Astar算法都一模一樣，計(jì)算出的曼哈頓值都沒乘代價(jià)10就直接當(dāng)做H使用，不止有很多路尋不到，并且還會(huì)產(chǎn)生大量(非常大量)多余的消耗 (斷點(diǎn)分析時(shí)發(fā)現(xiàn)有異常大量的結(jié)點(diǎn)被加入到closeList，地圖越大越多、消耗越大）。稍后會(huì)分析錯(cuò)誤是如何產(chǎn)生的

2021.07.28 補(bǔ)充
通過查詢到的錯(cuò)誤資料的時(shí)間推斷，大概率認(rèn)為是各路"神仙"從這個(gè)github復(fù)制的代碼：倉庫鏈接
經(jīng)過和作者溝通，確定了是有錯(cuò)誤的。相關(guān)issues：issue#1、issue#3
我也創(chuàng)建了一個(gè)倉庫對該實(shí)現(xiàn)進(jìn)行了bug修復(fù)、效率優(yōu)化并進(jìn)行以后的維護(hù)：倉庫鏈接

貼幾個(gè)無腦復(fù)制的錯(cuò)誤示例，目的是讓大家找資料的時(shí)候不要拿來就用

錯(cuò)誤分析

簡單舉個(gè)例子，當(dāng)曼哈頓值不乘代價(jià)直接作為H值來用時(shí)，造成最直接的問題就是 會(huì)取到錯(cuò)誤的最優(yōu)點(diǎn)

假設(shè)在12*12的無障礙物地圖中，從(4,4)尋路到(11,11) (4,4)周圍的八個(gè)格子中，理論上最優(yōu)點(diǎn)(F值最小的點(diǎn))應(yīng)該是(5,5) 而實(shí)際在這個(gè)錯(cuò)誤的算法中最優(yōu)點(diǎn)會(huì)變成(4,5) 因?yàn)槁D值不乘10(DIRECT_VALUE橫豎移動(dòng)代價(jià))而直接作為H使用，是這樣的：(4,5)的G=10,H=13;(5,5)的G=14,H=12;明顯10+13 < 14+12 乘上DIRECT_VALUE再看：(4,5)的G=10,H=130;(5,5)的G=14,H=120;明顯10+130 > 14+120

在整個(gè)算法過程中，這會(huì)導(dǎo)致有非常多錯(cuò)誤的最優(yōu)點(diǎn)，產(chǎn)生大量沒用的分析計(jì)算，資源浪費(fèi)非常嚴(yán)重，并且經(jīng)常尋不到路

效率

下面對比一下錯(cuò)誤代碼和進(jìn)行修復(fù)之后的代碼(具體實(shí)現(xiàn)思路都一樣，進(jìn)行了修復(fù)和效率優(yōu)化)
差距非常懸殊 (再次吐槽無腦復(fù)制)

消耗大的是網(wǎng)上錯(cuò)誤的代碼(曼哈頓值直接作為H使用)，不僅非常慢，還會(huì)有很多點(diǎn)尋不到

消耗小的是正確的代碼(曼哈頓值乘代價(jià)(10)作為H)

找到的正確的代碼

百度篩選截止到16年的博文，基本都是正確的實(shí)現(xiàn)
如 A*算法的java實(shí)現(xiàn)

個(gè)人維護(hù)的Astar倉庫

github：wushu037/java-astar
對原有實(shí)現(xiàn)進(jìn)行了bug修復(fù)、效率優(yōu)化，添加了尋路用例、路徑地圖打印

---

😁歡迎加入QQ群交流： [游戲-Web-開發(fā)技術(shù)棧 ??] ‘300567032’
點(diǎn)擊下方圖標(biāo)一鍵加入！

---

總結(jié)

以上是生活随笔為你收集整理的Astar算法的Java实现 (其他很多都是错的，没有计入曼哈顿值的代价)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。