㈠ android 怎麼使用protobuf庫
一、 下載protobuf-net 及配置
下載之後解壓到你的硬碟的某個目錄 ， 最好是將 Precompile\precompile.exe 以及 ProtoGen\protogen.exe 兩個文件加入到環境變數中 ， 之後方便使用。
我們還需要CoreOnly\ios中的三個文件，之後會用到，而且最終會放到unity工程下。
二、生成cs代碼
使用protogen 命令行來生成代碼 (precompile以及protogen都只能在windows下運行，在mac上可能可以通過mono來運行這個exe，但是沒有試過。)
使用例子如下：
protogen -i:Test1.proto -i:Test2.proto -i:Test3.proto -o:Output.cs -ns:com.fbmly.model
-i 是輸入文件,可以有多個
-o 輸出的cs文件, 只能有一個..如果-i有多個 會將所有的代碼生成到這一個cs文件當中
-ns 命名空間 最好使用，如果不使用每次生成的默認命名空間是proto的文件名。
通常來說 只要把所有的數據結構生成到一個cs就行了（要不然使用多個-i ， 要不就把所有protobuf定義寫在一個proto文件中），這樣之後之後操作比較方便一些。
經過這一步你就得到了生成之後的cs文件。
三、編譯dll庫
使用MonoDevelop工具 將上一步生成的cs文件編譯成dll庫.
1.創建一個新的工程 (File->New->Solution)
2.在彈出的對話框中選擇 C# 再選擇 Library.
3.在下方填寫好工程的名字 (這個名字是生成dll的名字,所以要起好)
4.點擊forward (之後還要點一次ok)
5.刪掉默認生成的MyClass.cs文件，有必要的話在AssemblyInfo.cs里填寫一些版權信息。
6.將上一步用protogen生成的cs文件 加入到工程 (在左邊工程名 上右鍵 就可以添加)
7.添加protobuf-net引用庫
點擊工程的References->Edit References
然後選擇剛才的CoreOnly\ios下的dll庫 ， 雙擊庫文件就可以加到右邊
最後檢查下References裡面如果有protobuf-net.dll就正確了。
8.都做好後, 點擊Build->Build All就可以在當前工程生成dll了
不要忘記 debug 和 release的選擇 ，測試完後應該重新拿release再編譯一次的。
9. 左下角提示成功 就 會在當前工程目錄下生成dll文件了 (我這里是 TestModel.dll)
這個dll存放的是你所有的數據結構。
四、預編譯序列化庫
上一步生成了數據的dll文件，這一步需要用到上一步的dll文件來生成專門序列化的dll文件。
首先要保證TestModel.dll和編譯時所使用的庫在同一目錄 ( 上一步生成的dll文件目錄，會自動把protobuf-net庫文件也復制過來 , 所以只需要記住這一點就行了。 比如你要是復制到其他目錄進行操作， 這點會很重要 )
然後打開命令行， 定位到dll工程目錄下的bin\Debug 或 bin\Release目錄
然後執行以下命令（修改成你所設置的名字）：
precompile TestModel.dll -o:ProtobufSerializer.dll -t:com.fbmly.ProtobufSerializer
TestModel.dll就是上一步生成的dll文件，-o是生成的文件名 -t是在ProtobufSerialize.dll中所生成的序列化類的類名 支持命名空間，不用命名空間就直接寫類名就可以了。
如果最後有 All Done 提示， 就代表生成成功了。
D:\protobuf-net\Precompile\Model>precompile TestModel.dll -o:ProtobufSerializer.
dll -t:com.fbmly.ProtobufSerializer
protobuf-net pre-compiler
Detected framework: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727
Resolved C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorlib.dll
Resolved C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.dll
Resolved protobuf-net.dll
Adding Fbmly1.Fbmly...
Compiling com.fbmly.ProtobufSerializer to ProtobufSerializer.dll...
All done
㈡ 淺談怎樣加快C++代碼的編譯速度
首先一點 加快編譯速度意義不大。
需要整個項目重新編譯的情況並不多，而每次只修改若干文件的情況下，加快速度也不會有太大影響。
更重要的應該把目光放在加快運行速度上。
要加快編譯速度，可以從這幾個方面嘗試。
一、代碼角度
1、在頭文件中使用前置聲明，而不是直接包含頭文件。
不要以為你只是多加了一個頭文件，由於頭文件的"被包含"特性，這種效果可能會被無限放大。所以，要盡一切可能使頭文件精簡。很多時候前置申明某個namespace中的類會比較痛苦，而直接include會方便很多，千萬要抵制住這種誘惑；類的成員，函數參數等也盡量用引用，指針，為前置聲明創造條件。
2、使用Pimpl模式
Pimpl全稱為Private Implementation。傳統的C++的類的介面與實現是混淆在一起的，而Pimpl這種做法使得類的介面與實現得以完全分離。如此，只要類的公共介面保持不變，對類實現的修改始終只需編譯該cpp；同時，該類提供給外界的頭文件也會精簡許多。
3、高度模塊化
模塊化就是低耦合，就是盡可能的減少相互依賴。這里其實有兩個層面的意思。一是文件與文件之間，一個頭文件的變化，盡量不要引起其他文件的重新編譯；二是工程與工程之間，對一個工程的修改，盡量不要引起太多其他工程的編譯。這就要求頭文件，或者工程的內容一定要單一，不要什麼東西都往裡面塞，從而引起不必要的依賴。這也可以說是內聚性吧。
以頭文件為例，不要把兩個不相關的類，或者沒什麼聯系的宏定義放到一個頭文件里。內容要盡量單一，從而不會使包含他們的文件包含了不需要的內容。記得我們曾經做過這么一個事，把代碼中最"hot"的那些頭文件找出來，然後分成多個獨立的小文件，效果相當可觀。
其實我們去年做過的refactoring，把眾多DLL分離成UI與Core兩個部分，也是有著相同的效果的 - 提高開發效率。
4、刪除冗餘的頭文件
一些代碼經過上十年的開發與維護，經手的人無數，很有可能出現包含了沒用的頭文件，或重復包含的現象，去掉這些冗餘的include是相當必要的。當然，這主要是針對cpp的，因為對於一個頭文件，其中的某個include是否冗餘很難界定，得看是否在最終的編譯單元中用到了，而這樣又可能出現在一個編譯單元用到了，而在另外一個編譯單元中沒用到的情況。
之前曾寫過一個Perl腳本用來自動去除這些冗餘的頭文件，在某個工程中竟然去掉多達了5000多個的include。
5、特別注意inline和template
這是C++中兩種比較"先進"的機制，但是它們卻又強制我們在頭文件中包含實現，這對增加頭文件的內容，從而減慢編譯速度有著很大的貢獻。使用之前，權衡一下。
二、綜合技巧
1、預編譯頭文件（PCH）
把一些常用但不常改動的頭文件放在預編譯頭文件中。這樣，至少在單個工程中你不需要在每個編譯單元里一遍又一遍的load與解析同一個頭文件了。
2、Unity Build
Unity Build做法很簡單，把所有的cpp包含到一個cpp中(all.cpp) ,然後只編譯all.cpp。這樣我們就只有一個編譯單元，這意味著不需要重復load與解析同一個頭文件了，同時因為只產生一個obj文件，在鏈接的時候也不需要那麼密集的磁碟操作了,估計能有10x的提高，看看這個視頻感受一下其做法與速度吧。
3、ccache
compiler cache, 通過cache上一次編譯的結果，使rebuild在保持結果相同的情況下，極大的提高速度。我們知道如果是build，系統會對比源代碼與目標代碼的時間來決定是否要重新編譯某個文件，這個方法其實並不完全可靠(比如從svn上拿了上個版本的代碼)，而ccache判斷的原則則是文件的內容，相對來講要可靠的多。
很可惜的是，Visual Studio現在還不支持這個功能 - 其實完全可以加一個新的命令，比如cache build，介於build與rebuild之間，這樣，rebuild就可以基本不用了。
4、不要有太多的Additional Include Directories
編譯器定位你include的頭文件，是根據你提供的include directories進行搜索的。可以想像，如果你提供了100個包含目錄，而某個頭文件是在第100個目錄下，定位它的過程是非常痛苦的。組織好你的包含目錄，並盡量保持簡潔。
三、編譯資源
要提高速度，要麼減少任務，要麼加派人手，前面兩個方面講得都是減少任務，而事實上，在提高編譯速度這塊，加派人手還是有著非常重要的作用的。
1、並行編譯
買個4核的，或者8核的cpu，每次一build，就是8個文件並行著編，那速度，看著都爽。 要是你們老闆不同意，讓他讀讀這篇文章：Hardware is Cheap, Programmers are Expensive
2、更好的磁碟
我們知道，編譯速度慢很大一部分原因是磁碟操作，那麼除了盡可能的減少磁碟操作，我們還可以做的就是加快磁碟速度。比如上面8個核一塊工作的時候，磁碟極有可能成為最大的瓶頸。買個15000轉的磁碟，或者SSD，或者RAID0的，總之，越快越好。
3、分布式編譯
一台機子的性能始終是有限的，利用網路中空閑的cpu資源，以及專門用來編譯的build server來幫助你編譯才能從根本上解決我們編譯速度的問題，想想原來要build 1個多小時工程的在2分鍾內就能搞定，你就知道你一定不能沒有它 - Incredibuild。
4、並行，其實還可以這么做。
這是一個比較極端的情況，如果你用了Incredibuild，對最終的編譯速度還是不滿意，怎麼辦？其實只要跳出思維的框架，編譯速度還是可以有質的飛躍的 - 前提是你有足夠多的機器：
假設你有solution A和solution B，B依賴於A，所以必須在A之後Build B。其中A，B Build各需要1個小時，那麼總共要2個小時。可是B一定要在A之後build嗎？跳出這個思維框架，你就有了下述方案：
◦同時開始build A和B 。
◦A的build成功，這里雖然B的build失敗了，但都只是失敗在最後的link上。
◦重新link B中的project。