㈠ 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。