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