上一次關(guān)注Qt Lighthouse是在6月初，可是現(xiàn)在都8月底了。時間真快...

Lighthouse 是 QPA(Qt Platform Abstraction) 項目的名字，它使得將Qt移植到新的平臺變得比較簡單。盡管現(xiàn)在它已經(jīng)完全融入到了Qt主干代碼中，lighthouse作為獨立項目已經(jīng)不復(fù)存在了，但本文中，我們繼續(xù)使用這個名字(雖然已不太恰當(dāng))。

QPA 抽象了什么？

不妨看看QPA前后，有何不同：

之前

考慮一下，傳統(tǒng)的Qt是如何實現(xiàn)圖形界面的夸平臺：

• 針對不同的窗口系統(tǒng)(WS)定義相應(yīng)的宏： Q_WS_*

Q_WS_X11
Q_WS_MAC
Q_WS_QWS
Q_WS_WIN
Q_WS_S60

• 代碼中夾雜大量的編譯預(yù)處理指令 (處理小段)

#if defined(Q_WS_X11)
...
#elif defined(Q_WS_MAC)
...
#elif defined(Q_WS_WIN)
...
#endif

• 各個窗口系統(tǒng)相關(guān)的代碼文件 (處理大段)

qapplication_x11.cpp
qapplication_win.cpp
qapplication_s60.cpp
qapplication_mac.mm
qapplication_qws.cpp
...
qwidget_win.cpp
qwidget_qws.cpp
qwidget_mac.cpp
qwidget_x11.cpp
...

• src/gui/kernel.pri 等工程文件內(nèi)，控制哪些文件參與編譯

win32 {
...
}
symbian {
...
}
unix:x11 {
...
}

這一切這意味這什么？？

如果我們想在這個基礎(chǔ)上支持一個新的窗口系統(tǒng)，比如wayland，需要

• 添加平臺相關(guān)的宏，代碼中針對該窗口再擴充 #if #elif #endif

• 添加平臺相關(guān)的文件，擴充 **.pri 文件使其融入Qt
• ...

總之，需要對Qt的代碼進行大量的修改。這一切使得將Qt移植到新的窗口系統(tǒng)中，變得不是那么容易。

之后

QPA 定義了一套接口，而后，將窗口系統(tǒng)相關(guān)的代碼放到插件中：

• src/plugins/platforms/xlib/*
• src/plugins/platforms/wayland/*
• src/plugins/platforms/cocoa/*

這時，如果我們想支持一個新的窗口系統(tǒng)，怎么辦？只需要編寫一個新的插件，而Qt自身的代碼則不需要任何改變。

(當(dāng)然，編寫插件本身還是很有難度的，哈...)

QPA源碼結(jié)構(gòu)

為了使插件能供工作，Qt中需要提供有相應(yīng)的加載接口，在Qt源碼中搜索*_qpa.h、*_qpa.cpp、 *_qpa_p.h 即可找到所有(fixme)和 qpa有關(guān)的代碼：

• QTDIR/src/opengl
  • qgl_qpa.cpp
• QTDIR/src/gui
  • painting
    • qcolormap_qpa.cpp
    • qpaintdevice_qpa.cpp
  • image
    • qpixmap_qpa.cpp
  • egl
    • qegl_qpa.cpp
  • kernel
    • qplatformintegrationplugin_qpa.cpp
    • qplatformcursor_qpa.cpp
    • qwidget_qpa.cpp
    • ...
  • text
    • qfontengine_qpa.cpp
    • qfontengine_qpa_p.h
    • ...

可以看到代碼集中在 gui/kernel 部分；除此外，和字體相關(guān)gui/text，和繪圖相關(guān)gui/painting、gui/image、gui/egl，和opengl相關(guān)

QPA結(jié)構(gòu)

QPlatformIntegration

這個應(yīng)該算是 QPA 的核心了，

• 它是QApplication(準(zhǔn)確地說是QApplicationPrivate)的成員

class Q_GUI_EXPORT QApplicationPrivate : public QCoreApplicationPrivate
{
...
    static QPlatformIntegration *platform_integration;
...

• 在初始化QAppliction時它會被創(chuàng)建

QApplication::QApplication()
  QApplicationPrivate::construct()
   qt_init()
     init_platform()
       QPlatfromIntegrationFactory::create()

• 它是所有窗口系統(tǒng)相關(guān)函數(shù)的入口點

class Q_GUI_EXPORT QPlatformIntegration
{
public:

這樣一來：

QPlatformWindow 與 QWindowSurface

相對而言，QPlatformWindow 出現(xiàn)的比較晚一點(見Say hello to QPlatformWindow一文）之所以。之所以分離開來，原因見Remodelling the Lighthouse。

QPlatformScreen

• 代表屏幕(顯示器)
• 它提供的api對應(yīng)用程序來說是只讀的
• 用來計算分辨率 dpi

class Q_GUI_EXPORT QPlatformScreen : public QObject
{
...
    virtual QRect geometry() const = 0;
    virtual QRect availableGeometry() const {return geometry();}
    virtual int depth() const = 0;
    virtual QImage::Format format() const = 0;
    virtual QSize physicalSize() const;

QPixmapData

為什么要有這個東西？

通常我們似乎都不怎么區(qū)分QImage和QPixmap，盡管在Manual中很大的篇幅在描述這二者的區(qū)別。

設(shè)計目的和用途(一個是IO和像素操作，一個是屏幕顯示)：

• QImage is designed and optimized for I/O, and for direct pixel access and manipulation
• while QPixmap is designed and optimized for showing images on screen.

典型的用途：

• Typically, the QImage class is used to load an image file, optionally manipulating the image data, before the QImage object is converted into a QPixmap to be shown on screen.
• Alternatively, if no manipulation is desired, the image file can be loaded directly into a QPixmap.

與QImage不同，QPixmap 是平臺相關(guān)的

• Note that the pixel data in a pixmap is internal and is managed by the underlying window system.

于是它的后端需要由各個窗口系統(tǒng)來提供也就不足為奇了。

QPlatformFontDatabase

提供字體信息

詳見Fonts in Lighthouse一文。

其他

• QPlatformClipboard
• QPlatformCursor
• ...

同前面幾個一樣，從名字上容易看出是做什么的。

參考

• http://labs.qt.nokia.com/2010/04/06/remodelling-the-lighthouse/

• http://labs.qt.nokia.com/2010/04/21/say-hello-to-qplatformwindow/

• http://labs.qt.nokia.com/2010/09/02/fonts-in-lighthouse

最近讀了《卓有成效的程序員》，感覺收獲頗大。這是一本寫給程序員的難得的好書。書中大都是一些淺顯的道理，但作者將這些東西加以收集、歸納、總結(jié)，并最終成書。作者為了收集各種提高效率的工具和方法，東奔西走，可謂費了一番苦心。

我覺得此書第一部分總結(jié)的一些法則非常好，我提取了一下：

法則： 

1.加速法則

    關(guān)注本質(zhì)，而非形式

    一個應(yīng)用程序列表的有用程度與它的長度成反比 

    程序員的很多時間都浪費在找東西上 

    華而不實的東西中看不中用

    鍵盤輸入總比導(dǎo)航快

    首選鍵盤而非鼠標(biāo)

    地址欄是Windows資源管理器界面中最高效的部分

    花點時間來學(xué)習(xí)你手邊的所有隱藏的快捷鍵

    環(huán)境切換會消耗時間

    成批復(fù)制粘貼要比反復(fù)多次復(fù)制粘貼快

    忘記歷史就意味著你得再輸入一遍

    嵌入圖形化工具的命令提示符讓你魚與熊掌兼得

    在上下文中學(xué)習(xí)IDE快捷鍵，而不要去背長長的列表

    當(dāng)你第二次輸入一個復(fù)雜結(jié)構(gòu)時，將它做成模板

    如果要對多行文本做同樣的操作，就應(yīng)該找出其中的模式，并把它記錄為一個宏

    不要總是重復(fù)輸入相同的命令

    每天花一點點時間來使每一天都更高效 

2.專注法則

    精力越集中，思維越縝密

    排除干擾：隔離策略，關(guān)掉不需要的提示，創(chuàng)造安靜時間  

    草堆越大，從中找到一根針就越難

    不要問文件樹，要搜索

    使用多顯示器

    虛擬桌面可以讓原本雜亂無章的一大堆窗口變得整潔 

3.自動化法則

    不要重新發(fā)明輪子

    用Selenium瀏覽網(wǎng)頁

    不要浪費時間動手去做可以被自動化的事情

    用Windows Power Shell替代批處理文件

    馴服Subversion命令行

    以創(chuàng)造性的方式解決問題，有助于在將來解決類似的問題

    是否應(yīng)該自動化的關(guān)鍵在于投資回報率和緩解風(fēng)險

    研究性的工作應(yīng)該放在時間盒里做

    別給牦牛剪毛 

4.規(guī)范性法則

    對于任何你不自己去構(gòu)建的東西，只在版本控制中保存一份副本

    使用標(biāo)準(zhǔn)的構(gòu)建服務(wù)器

    通過復(fù)制粘貼來復(fù)用是邪惡的，不論你復(fù)制粘貼的是什么

    利用虛擬平臺使項目依賴標(biāo)準(zhǔn)化

    不要讓對象 - 關(guān)系映射工具（O/R映射器）違反規(guī)范原則 

    通過擴展。開放類（open class），或者部分類（partial class） 來為生成的代碼增加行為

    始終保持代碼和數(shù)據(jù)結(jié)構(gòu)的同步

    過時的文檔比沒有文檔更糟，因為它會主動誤導(dǎo)你

    任何需要費勁創(chuàng)造的東西，都讓它的創(chuàng)造者欲罷不能

    白板 + 數(shù)碼相機強過任何CASE工具

    盡量生成所有技術(shù)文檔

    重復(fù)是軟件開發(fā)中最大的阻力 

工具：

書中，還提到了大量的提高效率的工具，都是非常不錯的。相信很多人都有自己的一個列表，下面是我電腦中必不可少的幾款軟件：

    1. FireFox 及其各類插件

    2. Launchy啟動加速器

    3. Total Commander

    4. ClipX多重剪切板

    5. EmEditor文本編輯器 

    6. Vistual Studio的VA插件

    7. Search And Replace

    8. Everything

    9. Miranda IM

    10. .... 

感觸： 

1. 憤怒的猴子 

在書中的第二部分，提到了很多實踐相關(guān)的內(nèi)容。讓我感觸最深的是“憤怒的猴子”的故事：

“早在20世紀(jì)60年代（那時候科學(xué)家們可以做任何瘋狂的事情），行為科學(xué)家們進行了一項實驗。他們把五只猴子和一架活梯放在一間屋子里，并在天花板上掛了一串香蕉。這些猴子很快就想到它們可以爬上梯子去吃香蕉，但每當(dāng)它們靠近活梯的時候，科學(xué)家們就用冰水浸滿整個屋子。我想你能猜到會發(fā)生什么：一群憤怒的猴子。很快，再沒有一只猴子會去靠近那個梯子了。

之后，科學(xué)家們將其中一只猴子替換成另一只沒有忍受過冰水折磨的新猴子。這只新猴子所做的第一件事就是直奔那架梯子，但當(dāng)它這么做時其他所有猴子都痛打它。它不明白為什么，但很快就學(xué)乖了：不要去靠近那架梯子。科學(xué)家們逐漸將最初的那些猴子都替換成新猴子，直到這群猴子中誰都沒有被水浸泡過，然而它們還是會去攻擊任何靠近梯子的猴子。

這說明了什么？軟件項目中許多慣例之所以存在，就因為”我們一直是那樣做的“。換句話說，是因為憤怒的猴子。”

我們小組在制定C++相關(guān)的代碼規(guī)范時就遇到過無數(shù)類似的問題。比如，在制定變量的命名規(guī)范時，我們針對是否采用匈牙利命名法爭論了很久。有的人認為， 幾乎以前看到的所有C++代碼都采用了匈牙利命名法，甚至，微軟定義的所有API都使用了此類命名法。剛開始，我也是有同樣的疑惑。

后來，我們經(jīng)過仔細分析C++匈牙利命名法由來，漸漸感覺我們就是那些憤怒的猴子，盲目跟從前人的方式，缺乏打破傳統(tǒng)的勇氣。C++有著其特殊的歷史原因，很多標(biāo)準(zhǔn)一直沉淀下來并很少改變。我們再看看后來新生的那些編程語言，C#, Python…… 都拋棄了匈牙利命名法，同時再看看現(xiàn)在C++前沿的C++ 0x以及現(xiàn)在出版的一些書中，也漸漸放棄了對匈牙利命名法的使用。因為類型的意義在對象模型中越來越弱化。因此，最后我們放棄了匈牙利命名法這個老古董。 

2. 敏捷開發(fā)

這本書帶有強烈的ThoughtWorks色彩，敏捷的思想貫穿全書，包括測試驅(qū)動設(shè)計，白板，結(jié)對編程。這也讓我對敏捷產(chǎn)生了更加強烈的興趣。 其中有一段測試驅(qū)動開發(fā)TDD的一段故事：

“記得第一次和一些已經(jīng)習(xí)慣于單元測試的開發(fā)人員一起動手開始修改代碼時，我也是非常緊張，因為大量的修改往往會破壞很多東西，但他們看起來絲毫沒有猶豫。逐漸地，我也放下心來，因為我慢慢地認識到：有了測試的保證，完全可以放心大膽地去修改代碼。” 

3. 有趣的故事 

書中還有一些有趣的故事，比如作者的一個朋友在和別人結(jié)對編程時，為了養(yǎng)成同伴使用快捷鍵的習(xí)慣，每當(dāng)同伴未使用快捷鍵時，他都會要求將操作撤銷，然后要求使用快捷鍵再重復(fù)操作3次。然后，在其兇狠的眼神中，同伴很快掌握了快捷鍵。 

總結(jié)：

這本書很薄，蘊藏的道理卻不少，相信每個讀過它的人都會從中收獲。讀過之后，我們不應(yīng)該局限于書中提到的某些小技巧， 或是書中某一個細節(jié)，畢竟，提供效率的方法有很多很多，法則也有很多很多，一本書很難將其窮舉完。我們應(yīng)該從書中吸取其思想，并在實際工作和學(xué)習(xí)中不斷總結(jié)，做一個真正的“卓有成效的程序員”！

剛接觸單元測試時，我實在是搞不懂這種測試到底有多大的意義，無非都是一些簡單的ASSERT，但近年積累一些經(jīng)驗教訓(xùn)之后我才發(fā)現(xiàn)，單元測試這玩意兒真的是一種保證程序質(zhì)量的強有力手段。

為什么這樣說？舉個最典型的例子，無論是開發(fā)新功能還是維護老程序，都不可避免的要反復(fù)修改某些代碼，那該怎么保證修改的代碼不會引入新的問題？如果你說你用人品擔(dān)保，那我服了。我們應(yīng)該需要一種可靠的手段來保證修改一個BUG不會引入兩個三個BUG，或者不會讓之前正確的功能出錯，甚至是不會引入之前已經(jīng)修改過的其它BUG。測試無疑是一種很好的手段，在沒掌握其它更好的方法之前，很多人喜歡用人工測試，即編譯 – 運行 – 輸入典型值 – 看程序運行結(jié)果 – 如果出錯 – 修改后再編譯……從長遠來看，這種測試方法的缺點很明顯：1、耗時耗力，每次修改代碼后都需要人工重復(fù)測試所有的典型情況；2、容易出錯、漏測，人腦太復(fù)雜，你很難記得幾個月前的那個BUG到底是什么情況，因此沒法測試，久而久之，N久前的那個BUG可能又神不知鬼不覺的重現(xiàn)了。相比之下，單元測試的優(yōu)點就凸顯出來了，把需要測試的典型情況編寫為測試代碼，然后編譯運行即可完成自動化的測試，當(dāng)發(fā)現(xiàn)BUG后，把它添加到測試用例，不僅可以提高測試覆蓋率，還能保證以后不會再次引入同樣的BUG，有了足夠的單元測試（覆蓋率），你就可以理直氣壯的說代碼沒問題！當(dāng)然引入單元測試會在前期花費不少的時間來編寫測試代碼，但相應(yīng)的也會大大減少后期的維護工作，最主要的是能可靠的提高程序的質(zhì)量，所以是值得的，甚至是必要的。（如果你編譯過開源的Google Chromium瀏覽器，你會發(fā)現(xiàn)測試代碼就占了不少，光是編譯測試代碼就得花很長的時間）

除了上面說的優(yōu)點外，單元測試還有一些其它的好處，比如幫你理清設(shè)計。一些人反對單元測試就是因為說我們的應(yīng)用太復(fù)雜了，沒法做單元測試。其實不一定是應(yīng)用復(fù)雜，而有可能是設(shè)計得有問題，導(dǎo)致了沒有可測試性。比如有些人喜歡在CXXXDialog里編寫所有的功能實現(xiàn)，要測試這樣的代碼，必須得創(chuàng)建出Dialog，可能還需要點擊，這顯然沒法做單元測試，但如果把Dialog和業(yè)務(wù)邏輯分開設(shè)計，那至少業(yè)務(wù)邏輯是可測試的（暫不討論UI的測試）。因此要做單元測試，就得設(shè)計好各個接口，保證某個接口只完成單一的功能，沒有過多的耦合依賴。

前面只是泛泛而談了一些單元測試的皮毛，鼓吹了一些優(yōu)點，有興趣的自己找更詳細的資料看吧。另推薦一個Google的開源C++測試框架googletest。