[Android] AsyncTask、HandlerThread原理分析

寫Android時難免會遇到UI要回應使用者的動作，同時還要執行一些計算
通常的解決辦法是使用HandlerThread和AsyncTask

用AsyncTask、HandlerThread當官見自就可以google出很多使用方法
不過最近看到比較特別的是這篇: Android應用程序線程消息循環模型分析
比較深入的介紹這些事件驅動的原理

雖然HandlerThread和AsyncTask看網路上的一些例子就會用了
但有機會我想還是多了解一點比較好吧

[紀錄] Android Out Of Memory

詳細請見: [Android]Android Out Of Memory(OOM) 的詳細研究

這篇主要是講大量的圖片檔案轉換成Bitmap物件時，出現Out Of Memory Exception的問題
不過其實也可以延伸思考「Android的記憶體分配」

以下節錄一小段:
通過一些瞭解，得知如下：
優化Dalvik虛擬機的堆記憶體分配

對於Android平臺來說，其託管層使用的Dalvik Java VM從目前的表現來看還有很多地方可以優化處理，比如我們在開發一些大型遊戲或耗資源的應用中可能考慮手動干涉GC處理，使用 dalvik.system.VMRuntime類提供的setTargetHeapUtilization方法可以增強程式堆記憶體的處理效率。當然具體原理我們可以參考開源工程，這裡我們僅說下使用方法: private final static float TARGET_HEAP_UTILIZATION = 0.75f; 在程式onCreate時就可以調用 VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION); 即可。
Android堆記憶體也可自己定義大小

對於一些Android專案，影響性能瓶頸的主要是Android自己記憶體管理機制問題，目前手機廠商對RAM都比較吝嗇，對於軟體的流暢性來說RAM對性能的影響十分敏感，除了 優化Dalvik虛擬機的堆記憶體分配外，我們還可以強制定義自己軟體的對記憶體大小，我們使用Dalvik提供的 dalvik.system.VMRuntime類來設置最小堆記憶體為例:

//設置最小heap記憶體為6MB大小。當然對於記憶體吃緊來說還可以通過手動干涉GC去處理
private final static int CWJ_HEAP_SIZE = 6* 1024* 1024 ;
VMRuntime.getRuntime().setMinimumHeapSize(CWJ_HEAP_SIZE);

[紀錄] 在Android中使用ormlite

可以參考:
Android中使用ormlite實現持久化--HelloOrmLite
Android中使用Ormlite實現持久化(二)--持久化類的詳細配置

另外補充:
DAO設計模式

一個高品質的js統計圖製作: highchartsjs

highcharts js: http://www.highcharts.com/

highchartjs 讓你只要寫一些簡單的javascript，就可以在你的網頁上做出漂亮的圖表
圖表涵蓋了各種常用的類型，如長條圖、圓餅圖等
特別的是它還可以用動畫展示，真的是非常花俏
有興趣的話點網址進去看看就知道多花俏了XD

它的範例及API也很豐富完善，基本需求通常只要改改範例就可以完成
不過要注意的是，若用免費版本，圖表下方會有一個他們的logo
就看介不介意囉


其他的 javascript chart library:
http://wowtree.com/tree.php?aid=864

htaccess使用

很多範例及flag的用法
http://www.cccspace.net/b/htaccess.html

使用實例，可以複製過來直接改
http://www.zzbaike.com/wiki/Htaccess%E4%BD%BF%E7%94%A8%E5%AE%9E%E4%BE%8B#.E7.A6.81.E6.AD.A2.E6.98.BE.E7.A4.BA.E7.9B.AE.E5.BD.95.E5.88.97.E8.A1.A8

[javascript] 物件存取特性

一般有在寫javascript的話，都會知道要取一個如下物件

var obj = { a: '123', b: '456' }

的a值，應該要這麼用:

console.log( obj.a );

但是，其實還有另外一個方法，就是使用類似陣列的動態存取

console.log( obj['a'] );

這是一個很方便的特性，假設你要取的物件屬性是不一定的， 我們假設是一個變數。

這時候，如果不知道可以用動態存取方法的話，你就只能這麼寫:

var attr = 'a';
var value = eval('obj.'+attr);

用eval的話，在效能和安全性的考慮上就可能不是這麼的好。

改變一下作法，若是這麼寫:

var attr = 'a';
var value = obj[attr];

這樣不就簡潔又美觀了呢?

在用json的時候，也可以很方便的這麼用

var value = json['key'] || defaultVal;

是不是很棒呢!

用python擷取MSN訊息

為了做無線網路的期末專題，寫了個小程式來抓MSN的訊息..

別問我這跟無線網路有什麼關係.. 因為我也不知道

我是使用python+pcap來做，這邊就介紹一下是怎麼做的

測試環境：

Windows 7

Windows Live Message (MSN) version 2009 (Build 14.0.8117.416)

環境要求：

Python 2.6 

Pcap version 1.1 for win32-py2.6

WinPcap 4.1.2

Appserv 2.5.10

其中pcap是Python的WinPcap API，再找要用哪個lib的時候也是考慮了很久

這個lib看起來許久沒更新了，資料也是很久以前的

但這個似乎是最簡便的，資料也比較多，最後在時間壓力下還是用他了


以下是pcac一些參考的資料，不過其實都大同小異
用法並不困難
http://devbbs.doit.com.cn/thread-11317-1-1.html
http://www.iteye.com/topic/372874
http://python.6.n6.nabble.com/CPyUG-85013-pcap-dpkt-python-td2854242.html
http://blog.sina.com.cn/s/blog_4b5039210100gnlu.html

原理

MSN是用1863port，以TCP的方式傳送、接收資料。我們用wireshark找到這點後，用python監聽1863port，並用regex濾出我們想要的訊息(登入訊息及談話內容)。最後存入遠端網頁(測試時是本機)，模擬MSN被惡意軟體監聽的情況。

程式碼

A star algorithm

A*常用在找「地圖路線」或是「電玩內的NPC移動路徑」
原因是因為，跟許多演算法比起來，A*會從現有找到的路挑最好的出來(Best-First)，並且猜測接下來最好的路是哪一條(Greedy)

也就是說，A*是一種結合Best-First和Greedy的聰明演算法

評估方法如下: (節錄自: http://blog.minstrel.idv.tw/2004/12/star-algorithm.html)
f(n) = g(n) + h(n)

g(n): 從啟始點到目前節點的距離
h(n): 預測目前節點到結束點的距離(此為 A* 演算法的主要評價公式)
f(n): 目前結點的評價分數

其中, h(n) 主導著A* 演算法的表現方式. 有以下幾種情形:
1. h(n)=0: A* 演算法這時等同 Dijkstra演算法, 並且保證能找到最短路徑
2. h(n)<目前節點到結束點的距離: A* 演算法保證找到最短路徑, h(n)越小, 搜尋深度越深
3. h(n)=目前節點到結束點的距離: A* 演算法僅會尋找最佳路徑, 並且能快速找到結果
4. h(n)>目前節點到結束點的距離: 不保證能找到最短路徑, 但計算比較快
5. h(n)與g(n)高度相關: A* 演算法此時成為 BFS (Best-First Search)


A*的優點從以下圖可明顯看出 :

(圖片節錄自: http://blog.minstrel.idv.tw/2004/12/star-algorithm.html)

A*的搜尋範圍明顯的比Dijkstra小

但是也有一點缺點:

(圖片節錄自: http://ndltd.ncl.edu.tw/cgi-bin/gs32/gsweb.cgi/login?o=dnclcdr&s=id=%22097NCCU5394024%22.&searchmode=basic)

A*有可能沒辦法找到最好的路徑