支付寶的SDK的需要營業(yè)執(zhí)照，要搞到營業(yè)執(zhí)照需要先申請一家公司，申請公司需要注冊資金和一堆麻煩的手續(xù)......微信同理。那么個(gè)人想要在軟件里做會(huì)員的功能要怎么辦呢：各種聚合支付的公司和發(fā)卡平臺(tái)。收費(fèi)黑就不說了，十個(gè)有九個(gè)是騙子。

自建發(fā)卡平臺(tái)或許可行，但發(fā)卡的原理至今沒搞太清楚，好像聽人說是購買淘寶的虛擬商品......總之這個(gè)也需要相當(dāng)麻煩的手續(xù)。

只是收款不是難事，掛個(gè)二維碼就行，主要的問題是需要在收款以后自動(dòng)處理一些東西。

問題的核心是，如何監(jiān)控到用戶的付款。開始的想法很單純：在服務(wù)器上整個(gè)安卓模擬器，里面登錄支付寶，然后寫個(gè)腳本定時(shí)刷新賬單并判斷是否有人付款。

這個(gè)方案是可行的，但腳本如果不夠完美就很容易出問題，還有可能出現(xiàn)其它不可預(yù)料的情況阻斷腳本原本的邏輯。而且，這樣我就不能用支付寶了......

或者可以發(fā)包模擬登錄支付寶，直接獲取到賬單的信息......前提是能破解支付寶的通信協(xié)議。

想想都難，于是我逆向思維想出了第二種方案：直接在用戶的手機(jī)上判斷是否付款成功。

落到實(shí)施上就是：利用安卓的輔助功能判斷用戶是否支付成功，并把結(jié)果告訴服務(wù)器。

如果我是用戶，肯定就會(huì)偽裝發(fā)送數(shù)據(jù)包，所以防止偽裝是最重要的?？梢园延脩糁Ц哆^程中的一些變量加密并送給服務(wù)器，比如在某個(gè)頁面停留的時(shí)間，當(dāng)前的時(shí)間之類的......大概就和滑塊還有那種點(diǎn)一下就通過的驗(yàn)證碼差不多，問題的核心是判斷出這一條請求確確實(shí)實(shí)是在支付完成以后發(fā)送的，而不是用發(fā)包軟件模擬的。

安卓的輔助功能(AccessibililtyService)可以讓開發(fā)者獲取到屏幕上出現(xiàn)的控件，布局，文字......并且可以點(diǎn)擊屏幕上的控件?，F(xiàn)在多被用于一些跳過廣告的軟件還有腳本軟件。

利用可以獲取屏幕信息的特性，就能夠判斷用戶是否支付成功了......才怪。

支付寶是不行的，支付成功的文字，金額，按鈕的文字......有用的信息全都獲取不到，應(yīng)該是因?yàn)橹Ц秾毜腢I并不是原生的，或者支付寶的開發(fā)者為了安全考慮用某種手段屏蔽掉了。

總之，一開始想的直接判斷支付成功頁面的文字就行了，還是太天真了。

支付寶內(nèi)部不行，但是通知欄的文字是可以盡數(shù)獲取到的，而支付寶每次付款都會(huì)發(fā)送一條通知。理論上是可行的，但是經(jīng)過十幾次測試以后，支付寶突然不發(fā)送通知了，過了一會(huì)又能發(fā)送了......支付寶的開發(fā)人員不會(huì)連我要根據(jù)通知欄判斷支付結(jié)果這種事也預(yù)料到了吧。

原因應(yīng)該是我在短時(shí)間內(nèi)付款的次數(shù)過多了吧......話是這么說但是這種方式還是不太穩(wěn)定，萬一失敗了要被用戶罵的。

最后想到的方法是，利用每個(gè)頁面不同的特征來判斷用戶在支付寶的哪個(gè)頁面。輔助功能可以得到控件的類名，所謂的特征就是那個(gè)頁面的類名加能夠獲取到的為數(shù)不多的文字。

比如，確認(rèn)支付的對話框彈出以后，一定有一個(gè)名為com.alipay.android.msp.ui.views.MspContainerActivity的類，出現(xiàn)這個(gè)類就認(rèn)為用戶進(jìn)入了輸入密碼的階段。但是還是不行，很容易出錯(cuò)......

但這個(gè)思路是對的，根據(jù)為數(shù)不多的信息判斷用戶在哪個(gè)頁面，到達(dá)支付成功的頁面就算支付成功。唯一的不足就是，需要用戶手動(dòng)打開輔助功能，有些麻煩。

最后想到是通知欄+特征的方法，判斷用戶是否經(jīng)歷了支付必經(jīng)的兩個(gè)頁面，然后判斷：如果有新通知并且金額對得上就直接認(rèn)為支付成功，沒有就判斷第三個(gè)頁面是不是支付成功后的頁面，雖然大概率會(huì)誤判......

還有一個(gè)問題就是，支付寶更新后，頁面的特征會(huì)變，需要提前把特征記錄下來，然后根據(jù)支付寶的版本使用不同的方案判斷......簡直就和以前用CE改崩崩崩一個(gè)思路，崩3這種游戲直接搜索生命值肯定是改不了的；那么很容易想到我直接改靜態(tài)數(shù)據(jù)，因?yàn)閿?shù)據(jù)都在一個(gè)dll文件里。每次進(jìn)游戲都會(huì)對文件的完整性進(jìn)行檢驗(yàn)所以改靜態(tài)數(shù)據(jù)也不行......

最后的方法是，用動(dòng)態(tài)的方式改靜態(tài)的數(shù)據(jù)。崩壞3每次進(jìn)入戰(zhàn)斗之前才會(huì)加載角色的數(shù)據(jù)，戰(zhàn)斗結(jié)束會(huì)判斷數(shù)據(jù)有沒有被修改，只要進(jìn)入戰(zhàn)斗前改好，完成后再改回來就行了。

然后問題就變成了怎么獲取角色的數(shù)據(jù)......特征碼。

如果搜索到內(nèi)存里某一串?dāng)?shù)據(jù)符合特征，那一串?dāng)?shù)據(jù)就是角色的靜態(tài)數(shù)據(jù)。生命值上限，攻擊力，防御力，SP上限是按順序排列的......根據(jù)某個(gè)角色的部分初始數(shù)據(jù)的特征，就能找到這個(gè)角色的數(shù)據(jù)在內(nèi)存里的哪個(gè)位置。現(xiàn)在不知道這個(gè)方法還能不能行，同樣的方案在原神里就行不通，不知道是不是靜態(tài)數(shù)據(jù)也加密了。不過這次判斷支付的方案確實(shí)是特征碼帶來的靈感。

希望這個(gè)不太正常的方案行得通。