我有点不太想写这个总结。不是没有话说，而是最近实在太忙了。在最终给自己弄了个大长假好好休息一番之前，觉得还是把这个总结了了事。
虽然去年前半年的事情也不少，也算比较忙的状况，但如果将前半年比喻成天堂的话，那么后半年可绝对是地狱了。一切都以那个被强制打乱了的项目为分界线。
前半年比较好的是决定将自己研究的网游服务器的想法慢慢的完善公开，虽然其中的代码不是很多，但比之前被我丢弃掉的那些服务器模型，还算是目前比较满意的了。如果不是后半年的事情，现在一定可以在其中进行交易等等得了。前半年的项目和研修基本上都是按部就班的，即使提前，也是在预料之中的，将自己之前在BREW上制作的中间层添加了opengles的支持，这样可以在支持opengles的设备上几乎不用做更改即可运行了（当然要重新编译了）。在刚开始的时候，由于接到的是一个完全BREW API的项目，于是就为这类项目做了个opengles的移植支持，即将BREW 相关的API用opengles封装，后来同事在移植另外一个j2me项目到该平台的时候，采用了j2me项目使用我的中间层移植到BREW上（我的中间层在内存模型和调试上比较方便），然后再将被封装的BREW API拿过来（当时我还未整理扩展我的中间层），放进去，再简单修改下完成了，这样的做法倒是有点出乎我的意料。后来给了一个任务，关于MTK平台的开发，在只有SDK的情况下，就将中间层又添加了MTK的支持，这样维护一套代码，同时支持三个平台的移植。当时测试中间层的代码（也是例子）全平台编译一遍竟然要花费半个消失，大概编译了9遍之多。如果我有时间研究下iPhone的编译的话，一定会把iPhone的也整合到编译脚本中去。
刚开始的时候，MTK的测试手机迟迟不到，就只好优化中间层的架构，将和平台相关的代码尽可能清楚的分开，完善文档等等，等到测试手机到的时候，发现中间层的例子在真机上速度异常的慢。仔细查找原因，甚至我找了别的公司的MTK的源代码来研究硬件部分，最后发现原因在于该手机平台的内存访问速度上，如果不能有速度相匹配的周边芯片的话，再好的CPU也白搭了。但如果使用该sdk的自带函数的话，则很多图像特效就没有了。在完成项目优先的情况下，只好不使用中间层来移植了（项目本身也不大，如果大的话，我不会这样来做的）。同时申请了调试用的Trace线，如果Trace线在两周之后能到的话，则就会非常的顺利了，因为后续还有一个海外的项目，优先级比较高的项目在等着我。就像测试手机一样，Trace线大概在一个半月到两个月的样子送到了，但海外的项目已经开始了，无暇再继续之前的项目了。然后呢，总经理发话，国内优先，于是，又切回来，然后花费了将近三周的时间来对应后续的检查及测试。然后，切回去。一看，比预订进度晚了一个月。晚就晚吧，依我的速度，快一些的话还是赶的过来的。
然后就是岳丈出事了，又消耗了将近两周的样子；项目组重新划分了，MTK平台的机器要转到别的同事那里，同时还好负责指导下开发；结果我原来用的开发机器出现问题了，无法正常使用了，只好更换机器，又消耗了一周；拿过来同事后来更新的java代码一比较，完了，几乎完全不一样，之前移植所做的将近三周的工作完全白费了；时间完全不够用了，只好协调，要求追加一个月。然后，就埋头苦干到现在，不断的追赶进度。总算在过年休大假之前，算是赶上了新的进度表。即使这样，相比较最初提出的合理的计划表，也还少两个月。
回想最初提交的计划表的时间安排，当时便考虑意外情况，项目叠加情况，安排不周到的问题等等，其实当时还主要考虑的一个问题是将另外一个部门所做的库重新简化移植下。他原来的库如果是用在应用程序领域的话，还算不错，但如果用在游戏领域的话，则效率和使用的方便性是很大的问题，而且，程序难于调试。在很早的时候，他们专门介绍了这个库，我看了文件的组织结构，便大致明白了其架构组成，当时甚至怀疑他们做这个架构，不是为了方便移植，而是为了增加工作量。基于效率考虑，我更倾向于架构的简单直接有效，而他们在系统上进行了一层一层的封装。到最后真实的项目中使用的时候，他们说更加的完善了，然后我翻开代码一看，因为要用STL，全局变量等等，他们推荐换编译器，用gcc的。换编译器这种事情，我并不是非常的在意。但看了主循环中，大量的进行临时的内存分配，释放，还有临时的string类（基本上全是STL的）等等，但并没有进行调试处理的辅助函数，我快要疯了，一个不小心，用错了一下，这下整篇的内存泄漏，查着都难查。java平台的函数和brew平台的函数某些函数接口不一致，如果要用的话，则要注意了，容易出错。每个描绘行为为一个类，举例来说，局部画一张图片是一个实现类，整体画一张图片是一个实现类，反转画是一个类，缩放画是一个类，描绘字符串是一个单独的类，描绘矩形是一个类，填充矩形是一个类，总之，每个都是类，如果你想将一张图在进行缩放或矩阵变换的时候进行alpha变化，除了创建中间的临时图像，我想不出直接的办法了。我甚至怀疑写库的人是否刚学完设计模式，非得将模式用到极致似的。等到拿到通信库的时候，有曾无减。平时比这个项目要大的多的项目，我基本上优化最多两周即可，但这个项目，我到现在已经优化了一个月了，还非常不满意，只好加个跳帧并且动态平衡下，才凑或满意了。即使这样，一遍玩下来，估计至少10W次以上的内存分配。想着都害怕，之前我弄的最多的内存分配次数大概2W左右。
我也曾经仔细研究过设计模式，也曾经尝试着用非常清晰的设计模式写架构，非常想在别人面前吹嘘：“这是某某模式”，但非常遗憾的是，严格的遵循最后导致的是不合实际用处。因此，我总告诉别人，关键是写出符合实际的合理代码，而不是遵循设计模式。在计算机的世界中，比较好的事情是，只要合乎规则，便是对的。并不会因为选择了hard模式，而爹不是李刚便难以玩下去。另外的经验就是尽可能避免写死循环或者递归或者阻塞调用的方式，而且，毕竟，递归是神用的。第三个经验就是小心使用线程，合理的使用线程可以给你带来很大的方便，而滥用的话，只会有麻烦。
然后，就到过年了。