在寫WG或者一些輔助小工具的過程中，難免會(huì)涉及到向窗口的某個(gè)控件發(fā)送鼠標(biāo)消息，或者是直接點(diǎn)擊窗口或者屏幕上的某一個(gè)區(qū)域。在資料不充分（例如對(duì)方使用的是DirectUI，控件的句柄就很難獲得，自然也很難知道某個(gè)控件或者對(duì)象相對(duì)于窗口或者屏幕左上角的坐標(biāo)值）的情況下，很難確定在發(fā)送鼠標(biāo)消息的時(shí)候，鼠標(biāo)的坐標(biāo)是多少。那么，如何快速地利用工具作簡單的查找呢？
筆者在制作一個(gè)QQ游戲的輔助工具時(shí)，就曾經(jīng)因?yàn)橐粫r(shí)間找不到兩幅圖片相對(duì)于窗口左上角的坐標(biāo)而苦惱。
（因?yàn)檫@個(gè)找茬輔助工具是基于屏幕截圖，像素點(diǎn)之間逐一直接比對(duì)的）
如何知道上圖兩個(gè)紅點(diǎn)分別相對(duì)于窗口左上角的坐標(biāo)值呢？
擴(kuò)展，又如何知道兩幅找茬圖片的寬度和高度呢？
網(wǎng)上不乏好的查找方法，但是為了獲取幾組值而另外寫程序，筆者認(rèn)為不夠靈活。程序員還是應(yīng)該懶一點(diǎn)~解決方案如下：
運(yùn)用photoshop的標(biāo)尺功能即可完成任務(wù)：
筆者用的是photoshopCS4，估計(jì)其他版本也有這個(gè)功能。
第一步：
利用QQ自帶的截圖功能（TX這回自作聰明了，QQ截圖居然可以針對(duì)某個(gè)特定窗口或者某個(gè)特定控件截圖，從而省卻了全屏截圖過后裁切窗口的步驟），截取游戲窗口的PP，如下
：
第二步，在photoshopCS4中打開這張圖片，放大之，然后在工具欄中選擇標(biāo)尺工具，如圖：
標(biāo)尺工具
接著在圖片左上角的位置開始，沿著任意方向拖曳標(biāo)尺工具，就像平時(shí)在windows畫圖中畫直線一樣，然后我們會(huì)看到一條很細(xì)的直線被拖出；
筆者往下垂直拖曳，這除了能夠確定左上角坐標(biāo)之外，還可以測量出圖片的高度。
紅色框框里面的灰色線條（兩頭有十字圖案的）就是拖曳出來的直線標(biāo)尺。
藍(lán)色框框有幾組值，熟悉windows窗口編程的童鞋們應(yīng)該都可以笑而不語了，筆者不才，還是斗膽解說一下：
x：相對(duì)于圖片左上角的像素橫坐標(biāo)（也就是我們要找的圖片或者控件相對(duì)于窗口左上角的坐標(biāo)值）
y：相對(duì)于圖片左上角的像素縱坐標(biāo)（同上）
w：width，線段兩端端點(diǎn)之間的
水平寬度（單位是像素）在這里是負(fù)數(shù)是因?yàn)楣P者的終點(diǎn)在起點(diǎn)的水平方向左邊，因此是負(fù)數(shù)。
h：height，線段兩端端點(diǎn)之間的
垂直寬度（單位是像素）
注意：這里得到的數(shù)值是一個(gè)小數(shù)，其實(shí)說白了也是精度問題。
平時(shí)在做windows窗口編程的
過程中，控件的坐標(biāo)總是整數(shù)，例如上圖的x = 9.44，要取9還是取10，那就要看我們?cè)谝婚_始選點(diǎn)的時(shí)候是否夠貼近真值。
這里目測一下（噗！O(∩_∩)O哈哈~），顯然是比真實(shí)圖像稍微偏左了，因此取10，其他值都按照這個(gè)方法處理。
用這種方法，可以測出兩幅圖片的左上角坐標(biāo)和圖片的寬、高。獲得值之后，運(yùn)用到程序中，誤差不會(huì)超過5個(gè)像素，到時(shí)在測試過程中微調(diào)一下就OK了。
筆者很幸運(yùn)，第一次取整的時(shí)候就估中了，O(∩_∩)O哈哈~
針對(duì)QQ游戲大家來找茬，發(fā)放一下小屏幕版本的關(guān)鍵數(shù)據(jù)吧：
x1 = 10
y1 = 185
x2 = 403
y2 = 185
nWidth = 380
nHeight = 285
最后惡心一下：祝各位準(zhǔn)備YY各種游戲輔助工具的親們開發(fā)愉快，噗哈哈哈哈哈！
誰說只有美工能用PS捏？咱們程序員也可以適當(dāng)投機(jī)取巧一下嘛~哈哈posted @
2011-07-24 22:22 ArthasLee 閱讀(10210) |
評(píng)論 (0) |
編輯 收藏
Q1：為什么程序的數(shù)據(jù)需要放在堆、棧兩個(gè)不同（甚至更多）的地方？
對(duì)于堆和棧中的數(shù)據(jù)內(nèi)容來說：
棧：編譯器需知道數(shù)據(jù)內(nèi)容的生存周期、但是可以快速管理和分配棧內(nèi)存；
堆：編譯器無需知道數(shù)據(jù)內(nèi)容的生存周期，保證靈活性、但是分配和回收內(nèi)存不如把數(shù)據(jù)放在棧中來得快；
Q2：對(duì)象在其生命周期結(jié)束后經(jīng)歷什么步驟而后被釋放？銷毀機(jī)制具體是怎樣的？底層通過什么實(shí)現(xiàn)？
當(dāng)程序執(zhí)行到一個(gè)塊or作用域（scope）的結(jié)尾，會(huì)自動(dòng)清理其維護(hù)的棧中的內(nèi)存數(shù)據(jù)。
于是，如果保存在棧中的唯一reference掛掉了，就意味著再?zèng)]有辦法可以操作其原先引用的對(duì)象了。
但是保存在堆中的對(duì)象在這時(shí)候還沒有被清理掉。
對(duì)于在堆中，沒有被引用的對(duì)象。垃圾回收器會(huì)直接把他們占據(jù)的內(nèi)存空間釋放掉。
真的如書中所說，這種機(jī)制滴水不漏嗎？會(huì)不會(huì)有陷阱？
會(huì)不會(huì)有一些不經(jīng)意的操作導(dǎo)致引用計(jì)數(shù)永遠(yuǎn)不為零，然而用戶卻懵然不知呢？
內(nèi)存泄漏真的可以在真正意義上得到避免嗎？
Q3：垃圾回收機(jī)制究竟能干什么，不能干什么？究竟本質(zhì)是什么？
垃圾回收機(jī)制原來只會(huì)對(duì)new出來的堆內(nèi)存起作用！！！
萬一不是new出來的，那還是得人工回收……
1、You might not get garbage collected！
哎……這樣的垃圾回收機(jī)制啊……
還真是懶啊……
總之就是，垃圾回收機(jī)制只會(huì)回收對(duì)象在堆中的內(nèi)存，但究竟這個(gè)對(duì)象的操作曾經(jīng)干了什么，有沒有“歷史遺留問題”，java是一概不管的……
這個(gè)垃圾回收機(jī)制還是回到回憶中去吧……（我沒吐槽最終幻想，真的沒有！）
ClassName obj；//局部對(duì)象，放在棧中（C++可以這樣，java不行）
C++的好處：作用域結(jié)束，局部對(duì)象的destructor自動(dòng)被調(diào)用，釋放棧中內(nèi)存；
New出來的對(duì)象：
//C++的壞處：不執(zhí)行delete的話，對(duì)象占用的內(nèi)存會(huì)一直賴在堆中。就讓內(nèi)存漏一會(huì)兒吧。
//java的好處：不用顯式執(zhí)行，只要作用域結(jié)束，reference被清除，垃圾回收器就會(huì)自動(dòng)回收堆中的內(nèi)存；
而且，java兄還不讓你在棧中創(chuàng)建局部對(duì)象呢……
Q3/1：那究竟new操作發(fā)生的時(shí)候，java語言為用戶干了什么？new的操作也會(huì)對(duì)引用計(jì)數(shù)產(chǎn)生作用——例如初始化和創(chuàng)建嗎？垃圾回收器如何工作呢？
相對(duì)于堆而言，在棧中釋放和分配內(nèi)存還是效率較高。這可能也是一些程序的數(shù)據(jù)放在棧中，一些放在堆中的原因之一吧？
引用計(jì)數(shù)類似是一個(gè)對(duì)象中的成員；有東西引用對(duì)象，就增加1，當(dāng)有引用在棧中被釋放或者設(shè)為NULL，就減少1；發(fā)現(xiàn)引用計(jì)數(shù)為0，就證明這個(gè)對(duì)象已經(jīng)沒人要了……
缺點(diǎn)：
垃圾回收器要掃描整個(gè)對(duì)象列表，查找引用計(jì)數(shù)為0的對(duì)象；
如果有兩個(gè)對(duì)象碰巧相互引用了彼此，那這兩個(gè)對(duì)象的引用計(jì)數(shù)就用不為零，即使沒人要也不會(huì)被清除掉；
最悲催的是：
JVM都不是通過這種機(jī)制實(shí)現(xiàn)垃圾回收滴……
JVM是這么干的……
逆向思維，不找死的，找活的！從一個(gè)引用出發(fā)，遍歷其對(duì)象-樹（自己作的）。透過每一個(gè)在棧中或者在靜態(tài)區(qū)中保存的引用，以之為根節(jié)點(diǎn)，遍歷由他出發(fā)可以到達(dá)的對(duì)象節(jié)點(diǎn)。
好處：
不用遍歷所有堆中的對(duì)象。
解決兩個(gè)對(duì)象互相引用而導(dǎo)致引用計(jì)數(shù)恒不為0的問題；
經(jīng)過上述處理，沒被找到的對(duì)象會(huì)被清理掉，但是會(huì)留下內(nèi)存碎片，浪費(fèi)空間。所以……
妙！
把程序停止下來，把活動(dòng)的對(duì)象copy到新的堆內(nèi)存，連續(xù)存放，這樣就騰出了那些原先成為碎片的空間。
然而，一直copy來copy去需要有額外的堆內(nèi)存來保存copy的數(shù)據(jù)，實(shí)際上copy發(fā)生的時(shí)候需要雙倍于被copy內(nèi)容的堆內(nèi)存同時(shí)可用。
其次，copy也需要時(shí)空開銷……
于是……
JVM就把sweep-and-mark和stop-and-copy結(jié)合起來（thinking in java有詳述）
大對(duì)象占用一個(gè)block，每個(gè)block有一個(gè)generation count作為其可用與否的標(biāo)記。
一些小對(duì)象放在一個(gè)block里；
根據(jù)引用來遍歷其對(duì)象-樹的操作開始執(zhí)行：
一般來說，大對(duì)象是不會(huì)被copy的；
小對(duì)象會(huì)被復(fù)制和重新管理，釋放內(nèi)存碎片；
JVM在碎片多的時(shí)候進(jìn)行stop-and-copy來整理碎片，騰出空間；在堆內(nèi)存足夠和碎片不多的情況下，則只執(zhí)行sweep-and-mark。
在這樣的垃圾回收機(jī)制下，只要是new出來的東西，真的都能回收了。某程度上還真是滴水不漏啊……
顯然是抄IBM大型機(jī)的外存管理嘛！數(shù)據(jù)集放在block中，被刪除的數(shù)據(jù)集的block標(biāo)記為不可用，新建的數(shù)據(jù)集放在后面的block中。當(dāng)存儲(chǔ)空間不夠了，整理那些已經(jīng)存在又可用的數(shù)據(jù)集，存放在一片連續(xù)空間中，把碎片重新整理為可用內(nèi)存，真是……
抄吧抄吧，不是罪……
posted @
2011-03-04 20:49 ArthasLee 閱讀(872) |
評(píng)論 (1) |
編輯 收藏