基于圖像識(shí)別的適用于模擬器的fgo腳本，目前支持穩(wěn)定3T的刷本
已完成的內(nèi)容
需自主添加的內(nèi)容
使用的資源
主要思路
界面及設(shè)置說明
遇到的問題及目前的解決辦法
已完成的內(nèi)容
實(shí)現(xiàn)了按腳本設(shè)置釋放技能和選擇指令卡、戰(zhàn)斗指定次數(shù)、吃指定類型蘋果（指未打包時(shí)，打包后問題多多，對(duì)的，所以穩(wěn)定指的是3T能夠穩(wěn)定）
ps：本作為整活性質(zhì)，起初僅為自己使用考慮，順帶鍛煉做項(xiàng)目的能力，類似自發(fā)的“大學(xué)生的第一篇論文”。靈感來自maa，是明日方舟的一個(gè)掛機(jī)腳本，相當(dāng)優(yōu)秀，界面以及功能一定程度上模仿了maa。各方面都慘不忍睹，不過好在東西基本都是自己腦子想出來的。同時(shí)現(xiàn)在已經(jīng)有許多成熟的腳本方案如FGO-py，以及BBchannel等，連接如下。
FGO-py的GitHub地址：https://github.com/hgjazhgj/FGO-py/blob/master/doc/contact.png
BBchannel的B站地址：https://www.bilibili.com/read/cv12976388?spm_id_from=333.880.0.0
ps2：分辨率需高于512*288，另外得是16：9的。
ps3：現(xiàn)已加入GitHub開源豪華套餐（大概算），網(wǎng)址為
需自主添加的內(nèi)容
adb：在壓縮包內(nèi)platform-tools_r33.0.3-windows/platform-tools，需將platform-tools這個(gè)文件夾添加至系統(tǒng)環(huán)境變量中才能正常使用?；蛟S能優(yōu)化，優(yōu)化后不再需要這個(gè)操作。不過再說。
airtest（現(xiàn)以無需下載，但airtest是一個(gè)優(yōu)秀的軟件，有效降低自主編寫腳本門檻，有點(diǎn)想法的可以下載）：前往airtest官網(wǎng)下載airtestIDE，按照教程連接模擬器一次。如果我道行夠高的話，自己的腳本說不定也能實(shí)現(xiàn)這個(gè)操作，有點(diǎn)不現(xiàn)實(shí)，可以當(dāng)夢(mèng)想（夢(mèng)想完成辣）。
Airtest Project地址：http://airtest.netease.com/
使用的資源
重要的有
scrcpy（劃掉），airtest（劃掉），paddlepaddle（劃掉），pyqt5，CV2，minicap，pyminitouch(minitouch)
山路十八彎的Android機(jī)子屏幕獲取方法匯總
adb screencap：方便，最簡單，有adb就能用。問題是巨慢無比，傳一張圖要個(gè)兩秒左右，延遲太大影響腳本正常運(yùn)行。
scrcpy+grabWIndow（在win32gui庫里面）：比上一個(gè)快許多。但是grabWindow要求窗口不在最小化狀態(tài)，同時(shí)其依賴的win32gui庫打包后不能正常引用。
scrcpy：利用自帶的錄屏功能，不使用grabWindow。但代價(jià)是速度慢。
minicap：快，其他什么的也都好的很。缺點(diǎn)是不好理解，寫代碼巨麻煩，scrcpy就是將minicap集成的例子，不過最后方案使用的這個(gè)，畢竟這個(gè)困難可以克服。
airtest：同樣利用minicap，缺點(diǎn)是......缺點(diǎn)是我沒法通過pip下載，而IDE不能和本來的python兼容。最后方案利用了這個(gè)軟件在模擬器中安裝minicap，不過這個(gè)可以被繞過去，現(xiàn)在的腳本已經(jīng)內(nèi)置了minicap的安裝方法。
圖像識(shí)別的算法(現(xiàn)從SIFT迭代至matchTemplate+OCR迭代至僅有matchTemplate）
SIFT
CV2中自帶的SIFT算法，即尺度不變特征變換，通過像素點(diǎn)周圍環(huán)境變化情況給出八個(gè)方向（即八個(gè)近鄰點(diǎn)）的顏色變化向量，并且生成圖片上的特征點(diǎn)。判斷圖像上這些特征點(diǎn)上的向量差值大小，就能判斷圖片是否相似（包含相同要素）。真正的原理里面還涉及空間尺度濾波器什么的，據(jù)我所理解似乎與高斯卷積生成模糊圖像然后與原圖相減獲得梯度圖相關(guān)？沒怎么看明白。
反正可以通過這個(gè)函數(shù)獲得相似特征點(diǎn)對(duì)（對(duì)比的兩圖像中兩個(gè)相似的特征點(diǎn)即特征點(diǎn)對(duì)）的數(shù)目，限制這一數(shù)目的閾值就能判斷圖片兩圖片是否相似以至于一個(gè)圖片是否包含于另一個(gè)圖片，畢竟特征點(diǎn)是一樣的。
在無旋轉(zhuǎn)的兩圖（用于本腳本中尤其適合）中還可以將兩特征點(diǎn)坐標(biāo)相減得到圖片的坐標(biāo)原點(diǎn)，幾乎所有正確的特征點(diǎn)對(duì)將會(huì)得到基本相同的坐標(biāo)原點(diǎn)，據(jù)此可以剔除不正確的坐標(biāo)原點(diǎn)，也就剔除了不正確的特征點(diǎn)對(duì)（當(dāng)然也可能是兩個(gè)相同的圖像出現(xiàn)在同一幅母圖之中），提高判斷的精度。
若想將所有的圖像都識(shí)別出來（如果由相同圖像的話）可以識(shí)別出一個(gè)圖像后將其剔除（染成黑色），再次進(jìn)行識(shí)別，循環(huán)至無合適的特征點(diǎn)對(duì)為止。
要想實(shí)現(xiàn)這個(gè)功能還有許多其他的算法。
matchTemplate
比SIFT算法簡單不少，SIFT直接調(diào)用返回的是圖像的特征點(diǎn)信息，而matchTemplate返回的是一個(gè)相似度矩陣，只需要驗(yàn)證相似度矩陣的最大值大于閾值，即可知道圖像是否存在以及在哪個(gè)位置。
OCR
使用了paddlepaddle飛槳提供的OCR的API接口，簡單，方便，但不快捷。分辨率高的圖像識(shí)別的還挺快，但是不知道為什么，分辨率降到512*288之后識(shí)別速率驟降。而且識(shí)別程序明明在QThread的線程里面跑的，OCR識(shí)別過程中窗口居然假死了。好在不會(huì)全程使用OCR，只有在助戰(zhàn)選擇的時(shí)候會(huì)調(diào)用一下，因?yàn)楸緛淼倪x擇框定在第一個(gè)助戰(zhàn)位置，識(shí)別失敗就往下滑一格。本來想的挺好的，但是下滑一個(gè)不夠精準(zhǔn)，同一個(gè)參數(shù)時(shí)，一次滑多一點(diǎn)，一次滑少一點(diǎn)。不過......現(xiàn)在用matchTemplate應(yīng)該能達(dá)到同樣的效果？還不如matchTemplate呢，已替換。
主要思路
屏幕更新線程
點(diǎn)擊連接開始時(shí)，屏幕更新線程開始。
低配版將使用adb獲取模擬器界面，保存到電腦文件中，讀取文件，顯示在屏幕中。
高配版將使用minicap獲取屏幕轉(zhuǎn)換為tcp數(shù)據(jù)流向端口轉(zhuǎn)發(fā)，獲取這些數(shù)據(jù)并重新編碼生成圖片文件。
點(diǎn)擊連接開始后，該按鈕將兼具暫停、恢復(fù)功能，點(diǎn)擊連接結(jié)束式結(jié)束屏幕更新線程。
動(dòng)作線程
將流程分狀態(tài)識(shí)別，每個(gè)狀態(tài)配備一個(gè)動(dòng)作：
1、戰(zhàn)斗前
2、嗑藥
3、助戰(zhàn)選擇
4、戰(zhàn)斗準(zhǔn)備
5、戰(zhàn)斗
6、結(jié)算
7、重復(fù)戰(zhàn)斗
狀態(tài)之間轉(zhuǎn)移關(guān)系為
1->2,3 以體力是否足夠區(qū)分 不夠則進(jìn)入2 夠則進(jìn)入3
2->3
3->4,5 以是否為重復(fù)戰(zhàn)斗區(qū)分 重復(fù)則進(jìn)入5 否則進(jìn)入4
4->5
5->6
6->7
7->2,3 以體力是否足夠區(qū)分 不夠則進(jìn)入2 夠則進(jìn)入3
其中5、戰(zhàn)斗分為六個(gè)線性狀態(tài)，操作在內(nèi)部完成，封裝成一個(gè)戰(zhàn)斗總狀態(tài)
1）第一回合技能選擇
2）第一回合指令卡選擇
3）第二回合技能選擇
4）第二回合指令卡選擇
5）第三回合技能選擇
6）第三回合指令卡選擇
每一個(gè)狀態(tài)轉(zhuǎn)移對(duì)象總是下一個(gè)狀態(tài)，最后一個(gè)狀態(tài)結(jié)束將結(jié)束戰(zhàn)斗總狀態(tài)
點(diǎn)擊運(yùn)行開始，動(dòng)作線程開始
圖像識(shí)別獲取所處狀態(tài)，當(dāng)識(shí)別成功時(shí)執(zhí)行該狀態(tài)的動(dòng)作，執(zhí)行完畢后待機(jī)進(jìn)入下一個(gè)狀態(tài)的判定。
每當(dāng)出現(xiàn)重復(fù)戰(zhàn)斗界面，戰(zhàn)斗次數(shù)+1，當(dāng)戰(zhàn)斗次數(shù)足夠時(shí)，動(dòng)作線程停止
界面及設(shè)置說明
上側(cè)第二三行為測試按鈕，現(xiàn)已刪除，留有reset按鈕，當(dāng)顯示狀態(tài)于實(shí)際狀態(tài)不符合時(shí)，點(diǎn)擊此按鈕，將重新識(shí)別狀態(tài)并進(jìn)入
test按鈕為測試用，因?yàn)楹罄m(xù)開發(fā)還會(huì)有用，暫且不刪，勿用
點(diǎn)擊連接開始，經(jīng)過初始化后（這將花費(fèi)一些時(shí)間），界面將不斷更新模擬器屏幕，同時(shí)連接結(jié)束按鈕將可用。點(diǎn)擊后該按鈕變?yōu)闀和０粹o，再次點(diǎn)擊后變?yōu)榛謴?fù)，此后二者循環(huán)。同時(shí)運(yùn)行開始將可用。
點(diǎn)擊連接結(jié)束，左側(cè)按鈕重新變?yōu)檫B接開始按鈕，自身重新變?yōu)椴豢捎脿顟B(tài)。
點(diǎn)擊運(yùn)行開始，將執(zhí)行腳本。
ps：受不明因素干擾，即便照搬左側(cè)對(duì)應(yīng)的代碼，腳本仍不能實(shí)現(xiàn)暫停、恢復(fù)以及結(jié)束后再重啟。目前要想重新開始腳本的話，關(guān)了重開吧。
點(diǎn)擊清空日志，將發(fā)生顯而易見的事情，日志將被清空。
右側(cè)為運(yùn)行日志，現(xiàn)階段有點(diǎn)繁瑣，將精簡。
策略有點(diǎn)抽象，但不復(fù)雜。一場戰(zhàn)斗分為三個(gè)回合，記作Turn i，i可取1，2，3。每個(gè)Turn有兩個(gè)輸入框，第一個(gè)表征技能，第二個(gè)表征指令卡。
技能由一系列三位數(shù)字描述，由空格分割，每三位數(shù)字描述一個(gè)技能。第一位數(shù)字是釋放技能的從者編號(hào)，可取1，2，3，4，5（前三個(gè)容易理解，4為御主禮裝技能，5為換人技能，單獨(dú)由530描述）。第二位數(shù)字是釋放的技能編號(hào)，可取1，2，3，每個(gè)可釋放技能單位均有且只有三個(gè)技能，無例外。第三個(gè)數(shù)字是釋放的對(duì)象編號(hào)，可取0，1，2，3（0代表無釋放對(duì)象如群沖技能，1，2，3容易理解）
指令卡由三位字符描述，前后代表選取順序。
共有兩個(gè)策略可以備選（方便保存一個(gè)副本），用下方的策略選擇替換
助戰(zhàn)選擇小門道：進(jìn)入初始選擇界面時(shí)，點(diǎn)擊更新將助戰(zhàn)替換為第一位的助戰(zhàn)。要想更新為更多的助戰(zhàn)，需要把助戰(zhàn)界面向下拉，讓其處于第一位置。
為了涵蓋單個(gè)從者的數(shù)個(gè)再臨形態(tài)，助戰(zhàn)選擇包括三個(gè)備用的選項(xiàng)。
為了適配開發(fā)時(shí)的白情活動(dòng)（這個(gè)活動(dòng)的禮裝太多了，如果總是關(guān)心禮裝，有時(shí)將老找不到對(duì)應(yīng)的從者＋禮裝，后續(xù)活動(dòng)的話可以把關(guān)心禮裝勾上），設(shè)置了是否關(guān)心禮裝選項(xiàng)，若不勾選，將無視禮裝，僅關(guān)心從者來選人。
勾選是否多次戰(zhàn)斗則根據(jù)戰(zhàn)斗次數(shù)進(jìn)行戰(zhàn)斗，似乎多余，不過還是留著把。
體力不夠時(shí)將自動(dòng)吃蘋果，可以指定蘋果類型。
如果想花完所有體力，不吃蘋果，那么應(yīng)該怎么辦呢？算一算floor(體力/40)，動(dòng)動(dòng)腦更健康。
模塊介紹：
模擬器選擇：目前加入兩個(gè)模擬器（分別是mumu和夜神），不過其他模擬器用戶請(qǐng)安心，模擬器選項(xiàng)可以自行添加，詳見后續(xù)
模擬器連接測試：想要確認(rèn)連接地址是否正確，在模擬器開啟的時(shí)候點(diǎn)擊此按鈕即可，注意模擬器選擇應(yīng)在正確的位置。
minicap和minitouch安裝：第一次使用時(shí)不能直接啟動(dòng)屏幕更新線程，將報(bào)錯(cuò)（我沒寫，所以大概率就是閃退），因?yàn)槟M器內(nèi)沒有對(duì)應(yīng)的minicap和minitouch文件。確認(rèn)模擬器連接成功后可以點(diǎn)擊模擬器添加nimicap及minitouch安裝按鈕，完成安裝。完成后下方標(biāo)簽將顯示模擬器的架構(gòu)和sdk版本以及'success'。由于這個(gè)功能測試較少，并且我覺得這些版本的彎彎繞多的很，極容易出現(xiàn)意料之外的錯(cuò)誤。比如可能是因?yàn)槟M器上的版本正好沒有對(duì)應(yīng)的文件，而且某個(gè)版本之前似乎要額外的文件才能正常運(yùn)行。出錯(cuò)的話可以查看一下模擬器內(nèi)data/local/tmp是否有對(duì)應(yīng)的三個(gè)文件（分別是minitouch、minicap、minicap.so)
自主添加模擬器選擇：在文本框中輸入模擬器的名稱+' '＋連接地址，再點(diǎn)擊模擬器添加,即成功添加，重啟后查看模擬器選擇選項(xiàng)，確認(rèn)是否添加成功。注意，這里的模擬器名稱可以按照自己喜好來，而非官方名稱，使用英文最好，如夜神模擬器用nox表示。
自主刪除模擬器選擇：為了避免過多的模擬器選擇擾亂視線，添加了刪除模擬器選擇功能，在文本框中輸入模擬器名稱，點(diǎn)擊模擬器刪除按鈕即可刪除
遇到的問題及目前的解決辦法
一：模擬器界面獲取相關(guān)
最主要的時(shí)如何將模擬器中的畫面截取到目錄中，最開始直接抓取窗口句柄，失敗。
后了解到scrcpy能用adb輸出模擬器的視頻流，于是抓取scrcpy窗口句柄獲取窗口畫面（這個(gè)b東西為什么沒有自帶的截屏，只有錄屏）。存在問題有需要保持scrcpy窗口不能最小化，一個(gè)不小心就會(huì)讓腳本出錯(cuò)；而且同時(shí)出現(xiàn)的窗口過多，容易混亂；最嚴(yán)中的問題時(shí)，打包成exe之后老提示我沒有win32gui相關(guān)的dll（就是獲取窗口句柄和界面的庫）。
再后想到利用不斷錄屏獲取錄像并保存到本地，用opencv庫解析視頻獲取畫面信息，同樣能夠達(dá)到效果，并且繞過了win32gui這個(gè)庫，打包后也不會(huì)報(bào)錯(cuò)。然而麻煩總是從一個(gè)地方轉(zhuǎn)移到另一個(gè)地方。scrcpy沒有錄屏指定時(shí)間的指令，只能通過結(jié)束程序產(chǎn)生錄屏文件。我給出的方法是......不斷打開關(guān)閉scrcpy，我愿稱之為開關(guān)大法。這個(gè)方法可以但比較......非常精神污染，畢竟有個(gè)窗口不斷出現(xiàn)消失的。并且，有時(shí)候會(huì)截屏失?。╯crcpy啟動(dòng)的初始化需要一點(diǎn)時(shí)間，而且不那么固定，若是還沒啟動(dòng)就被噶了，自然也沒有錄屏文件），不過通過程序可以容忍這個(gè)問題。
再再后，找到了方法，使用vbs命令可以隱藏調(diào)用程序的窗口，于是，問題被解決了......并不，打包之后vbs隱藏窗口的指令還是會(huì)讓cmd窗口出現(xiàn)一小會(huì)兒，這意味著，還是有東西會(huì)在腳本正常運(yùn)行的時(shí)候不斷的閃不斷的閃。
再再再后，接觸到了網(wǎng)易的airtest還有其他幾廠的基于圖像識(shí)別的開發(fā)工具。其中airtest有自己的IDE，直接從官網(wǎng)下載就能使用。有傻瓜腳本模式，和按鍵精靈幾乎一模一樣，但是功能比按鍵精靈更加深入。單純寫腳本的話開發(fā)起來很舒服，同時(shí)可以用python模式實(shí)現(xiàn)更多功能。問題依舊存在，python對(duì)airtest可以通過pip下載airtest庫進(jìn)行引用，但是pip下載出現(xiàn)了問題，并且它告訴我說不是pip自身的問題？瀏覽了網(wǎng)上的一般解決方案（幾乎都是降python版本之類的操作），最終依舊沒有解決。而下載airtestIDE時(shí)會(huì)自行安裝一個(gè)新環(huán)境的python，這意味著 ......分別存儲(chǔ)，互不干擾。也就是在這邊寫的python代碼沒法在另一邊運(yùn)行。
再再再再后，看到了一個(gè)天大的好消息。airtestIDE成功與模擬器建立連接后會(huì)在模擬器上自行安裝合適版本的minicap（實(shí)際上scrcpy就是用minicap集成出來的這些功能），而這minicap解釋輸出模擬器視頻流的關(guān)鍵，在minicap上建立tcp連接，轉(zhuǎn)發(fā)端口，利用socket可以獲取數(shù)據(jù)流，進(jìn)行解碼就能得到圖片。雖然非常憨憨的半天沒搞明白tcp傳輸數(shù)據(jù)到底咋接收，但是一天之后，磕磕絆絆的實(shí)現(xiàn)了圖片傳輸。雖然傳過來的畫面不知道為什么會(huì)抖動(dòng)（估計(jì)可以用解碼的技巧解決），但是不影響程序判定。并且再度偷懶的使用了開關(guān)大法（不這樣的話好像對(duì)數(shù)據(jù)流不能正常分割，解碼出來的數(shù)據(jù)自然不正確，重啟就沒有這樣的煩惱）。天大的壞消息：打包后還是會(huì)有cmd窗口不斷閃現(xiàn)。由于只有打包后才會(huì)出現(xiàn)這個(gè)現(xiàn)象，我甚至不確定是哪句代碼啟動(dòng)了這個(gè)窗口，只能懷疑是socket建立連接時(shí)自然產(chǎn)生的。如果能夠克服數(shù)據(jù)傳輸問題，摒棄開關(guān)大法，那么，未來可期。
再再再再再后，彈窗問題實(shí)際由python內(nèi)部os庫引起。但凡cmd命令和os庫沾點(diǎn)邊，都會(huì)在執(zhí)行的時(shí)候彈出一個(gè)彈窗，然后消失，也就是所謂的閃現(xiàn)。使用subprocess庫里的run，并且設(shè)置run的參數(shù)shell為true，能夠避免彈窗出現(xiàn)。但是此時(shí)屏幕刷新率低到要命，估計(jì)只有個(gè)半幀每秒。
再再再再再再后，可以將minicap的代碼中將屏幕照片從模擬器中獲取至本地文件中再獲取至程序中。這時(shí)不再使用開關(guān)大法，因?yàn)槲乙呀?jīng)參透了socket（并沒有），成功獲取到了自己想要的數(shù)據(jù)，也就是屏幕畫面。似乎同時(shí)讀寫同一個(gè)文件會(huì)出問題，這句疑似為廢話，本來就不應(yīng)該同時(shí)打開一個(gè)文件兩次。所以不用兩個(gè)線程讀寫同一個(gè)文件，用同一個(gè)線程進(jìn)行這個(gè)操作。
自此，屏幕獲取殺青，不會(huì)有更多問題了，應(yīng)該吧。
二：指令輸入
十分必要的輸入指令包括觸摸、滑動(dòng)，非必要但可以整的包括啟動(dòng)程序，回到主界面等。
初始使用adb shell input指令，觸摸為在input后附加'tap x y'，滑動(dòng)為 'swipe x0 y0 x1 y1 s'，s為滑動(dòng)時(shí)間。缺點(diǎn)是資源占用率相當(dāng)高，在先前諸多階段都還正常，但是一旦到了戰(zhàn)斗狀態(tài)，高頻的觸摸操作能讓電腦本來30%的cpu占用率飆升至60%。當(dāng)然我的資源規(guī)劃一塌糊涂，但是adb input模式當(dāng)背大鍋。
后使用minitouch模式，minitouch與minicap是配套的，對(duì)比adb原初的方式，也就是screencap和input，最大的優(yōu)點(diǎn)就是高效、節(jié)能，也不知道怎么做到這種魔法一般的效果的，哪天我說不定會(huì)去了解一下這里面的細(xì)節(jié)機(jī)制，還蠻有興趣的。最初用于哪個(gè)很大的項(xiàng)目來著？反正minitouch和minicap好用但不太好用。好用是指完成之后運(yùn)行效率高，資源占用少；而不好用是指很難完成（類似linux用戶梗）。相比minicap更友好的一點(diǎn)是minitouch有高人做了一個(gè)很牛的封裝pyminitouch，里面的接口只需要使用device、device.tap、device.swipe就能完成本來復(fù)雜的要命的指令。所以，現(xiàn)在的資源占用率一直在30%多點(diǎn)了，優(yōu)化的相當(dāng)成功。
三：如何識(shí)別指令卡，如只出紅卡或只出綠卡，但留作更新
悲報(bào)：識(shí)別指令卡什么的其實(shí)不難，同樣輕松用圖像識(shí)別解決。真正的難點(diǎn)在于，如果需要指令卡補(bǔ)足傷害輸出的話，意味著如果沒有指令卡，將無法完成擊殺，也就是需要4t，這在腳本中絕難處理，這樣的翻車將意味著程序卡死在某個(gè)進(jìn)程不在動(dòng)彈......似乎也還能接受？相比起全手動(dòng)而言，四五個(gè)小時(shí)后突然宕機(jī)也是已經(jīng)賺麻?？傊?，開發(fā)中，或許可以利用機(jī)器學(xué)習(xí)判斷怪血量選擇最合適的策略也說不定。
ps1：本人水平略撈，代碼是一個(gè)文件里面的一千五百多行字，我知道這樣不好，但是腦子一抽就寫下來了?，F(xiàn)在正在努力把這坨代碼分開，增加點(diǎn)可讀性。敬請(qǐng)讀者提出寶貴建議或者指導(dǎo)
ps2：已在GitHub上發(fā)布，源文件可在qcfei/fgoScript中找到
