端午佳节倍思亲

端午佳节倍思亲
  2016第一帖

差不多三年没在Blogger上更新博文，自从有了微博、微信（朋友圈）、新闻App、头条App，生活的碎片化时间很容易被占据，业余时间想静下心来思考一些事情并且能写下来的机会真的很难得，少之又少。

其实，一直以来我比较喜欢写博文的，尤其篇幅不短而能娓娓道来那样的谈论下去的博文，当然有做到有深度的博文是我至高的追求。

借着端午假期，轻快地开始2016第一帖。端午节假三天时间，匆忙回家（福建.漳州）一趟看望父母、奶奶、外公、还有我的小侄女，以及走访家附近的亲朋好友。引用一首苏轼的词，帮助感受端午节的气息。

《浣溪沙》
【宋】苏轼
轻汗微微透碧纨。明朝端午浴芳兰。
流香涨腻满晴川。彩线轻缠红玉臂，
小符斜挂绿云鬟。佳人相见一千年。





图1. 排骨凉瓜汤，奶奶煲的汤甘甜可口，酷暑降火，八十多岁的奶奶还是心灵手巧，善解人意，祝奶奶身体健康。



图2. 外公在家门口送别，九十多岁的外公今年身体没有往年矫健了，祝外公身体健康。


图3.老宅家门口的树花开了，从老宅搬出已有五年光阴了，树儿仍然亭亭玉立。

关于“乱讲”

• 关于“乱讲”

有一天，小明和小红一起出去游玩。边走边聊，有说有笑的……中间小明（不小心）说了一句“乱讲，我觉得是这样的……”，小红突然就不高兴了，不理小明了，并挤着眼吐着嘴自己一人先行离开了……

好，简单的故事讲完了。观众朋友们，你们知道为什么小红不理小明了吗？很简单，因为小明说了“乱讲”，不小心冒犯了小红。为啥小红因“乱讲”而不高兴，更具体原因详见下文剖析。

显然，这是一段虚构的小故事，小小情侣的俏皮故事。呵呵，听听就好不必认真，只是给“乱讲”的话题做个引子。

乱讲可能有误会，可能有冲突，更深的探讨就可能还包括自尊的心理活动。

乱讲，最直接理解就是否定对方前面的陈述。平时生活中，或许你经常会听到“乱讲”这词，比如有些人喜欢在否定对方观点并陈述自己时顺口随口曰，乱讲。这情况，往往可以被人们理解为口头禅（乱讲）。不知道你是否遇到过没有，反正我认识的一些人确实有这样的。当然了我没有这样的口头禅，可是却有位姑娘（一位重要的姑娘）指着我说，我有这样的口头禅了！为了表示反驳表示我没有这样的口头禅，所以我想写写这篇文章，关于“乱讲”。哈哈，当然这是一种带着调侃口吻而全无冒犯姑娘的说辞，不必当真:-) 

随口一句，“乱讲，我是说……”，或“乱讲，不是那样的……”，或“乱讲，其实是……”等等，诸如这些简单的话语其实多多少少暗藏着不友好的态度，当然对于那帮损友们来说天天互损而又相处融洽的情况且另当别论，这里只讲一般认识一般交情或彼此自尊自重分量有足的情况。我要说的“乱讲”二字很容易另对方产生歧义或困惑，怀疑是否没有得到尊重，甚至怀疑说话人的谈吐礼仪或素养。因为直接两字“乱讲”，足以赤裸裸地把对方的先前的观点给否定了，而且还带着一种意思指明对方在胡说八道的感觉。不管说者是否有带着这个意思，反正听者很可能就自然有着那样的感觉了。“言者无心，听者有意”，也差不多就是这个意思了。

或许有人会说，“不就两字嘛至于去反感吗？至于那么脆弱心灵吗？”，“乱讲，少误会了，全没那意思，就觉得顺口好玩，而且有点带着台湾味道的口语啊，好玩！”。那我只能说，“还真的是有些人那么敏感，不喜欢这，特在乎自尊，与心灵强弱无关”，“好玩的多了去了，如此可能伤人，这台湾味道的有啥好稀罕的。”

如上阐述，可以说“乱讲”二字只可能有带来误解或更深的误会情况，其他别无一处（益处）。既然如此那么有这样口头禅的，劝你尽快改掉改掉再改掉。少说的或没说过的，建议尽量避免得了，干净。少一句是省一句的事儿，别不信。

好了，此话题到这里讲完了，就此打住足矣。我想表达的意思已融汇在其中了。

最后附上一句：你若安好，便是晴天。另，携手同行！

（完）

时间紧迫症

时间紧迫症

  -- 时间紧迫的恐惧感

 昨夜至今天（20130421）我深刻反省自己，并勇敢地认识到：近几日得了时间紧迫症，内心反复触发起恐惧感。缘由来自最近工作的项目，一个对先前设计方案不断优化与改进的项目，这是之前出自我手的一个分享文件的设计方案（程序）。这段时间（10 天左右）关于项目优化的细节占据着我思维的大部分（80%），除了工作时间几乎占用全部之外，早晨睡醒脑子里第一件事情就是它或者说它把我从睡梦中叫醒，午休时候同样如此，晚上睡觉前最后一件事考虑的事情同样也是关乎方案的优化细节。

这些日子，优化细节不断从思绪中涌出，而且我总能很快付诸行动去编码、测试、观察性能、改动继续编码（反复）……如此反复的情况正是不断尝试调优的过程。这些日子，我的精力如此旺盛，在前面的日子丝毫不感疲倦……终于在昨天下午我深感累了，这种感觉似的来的异常快速，快速的令我不得不去反思回味前面的过程……其实，我应该更加理性一下，有些时候过于投入容易出现无法自拔的境地。

至此，项目的调优效果明显已达到原来预期的效果（甚至有点惊喜），至少可以满足领导们现在的期望了。因为所采用的优化方案不会对原来的设计结构大动干戈，而且经测试验证其效果理想，这样我们可以松了好几口气，可以暂缓下来去做其他比较紧急的另一个事情了，按理说现在我应该内心放缓轻松下来，不必为此事而费神了。但是，对于源源不断涌现出来的优化细节，我却抑制不住放缓不下来而是内心莫名紧迫起来恨不得立刻付诸行动去尝试……还有其他的工作事务安排所以容不得我去放纵。所以，后面这几天我的内心常常自我矛盾。最后深深发现自己累了，在网上搜索了解到“时间紧迫症”，与我的情况最相近了。

最后，我想简单地总结一句表达我想说的：由于最近工作的项目在不断地调优过程：思考、编码、测试、验证、改进、思考、编码……如此反复，导致近几日内心默默产生一种紧迫感，即一旦有思绪恨不得一蹴而就，立马付诸行动得以理想的优化结果，竟然一段时间乐此不疲精力旺盛。与如此情况最相近的就是时间紧迫症。累了，今日深刻自省，已放缓过来。

关于时间紧迫症，从网上捞到的定义（参考互动百科的时间紧迫症 ）：

  时间综合症是指人们对时间的反应过于关注而产生的情绪波动、生理变化现象。时下，快节奏的现代生活，使都市白领感到时间越来越不够用，对事业的专注使人对紧迫的时间感到焦躁不安、紧张过度，这样会引发心率加快、血压升高、呼吸急促等症状。

咳咳……如上这些的表达都是为了尝试另我放松下来，我歇息歇息，满血再战！

记于20130421（完）

成功的老板都善于讲故事

成功的老板都善于讲故事
 -- 20130221 听Big boss 说价值观

刚好（20130221）今天是我第一天上班，中午就恰逢老板CEO（还有看看公司的CEO付总）请蜘蛛网兄弟们吃饭，前面说是老板与我们互相交流，而事后看来其实不如说是大家听他（们）讲故事，灌输一些价值观给我们，在此谈不上洗脑，毕竟老板说的那些事情我们相对比较认可的，而且也有类似娱乐新闻的趣味故事，笼统的回想回想，掐指算算聊到的话题，有：

1，聊自组网应用前景。嵌入在快传、手雷提供组网与数据传输服务，搭建平台。具体应用于文件分享、游戏平台等。

2，小团队作战能力精悍，反应敏捷效果突出。举了个例子几年前迅雷对手网际快车的第一作者（侯延堂），当时单枪匹马可以把软件设计的很好，但是后来交手给了十多人的团队反而没把握好方向了，慢慢做得不行了（落后了）。

3，迅雷也一直努力站在用户的利益。老板做迅雷牵扯的利益要面对股东、ZF、还有网民（用户）。老板技术出身一直崇尚技术但毕竟也是位商人，在当年中国环境办公司做生意必须学会与ZF妥协，要做好迅雷最终面对的是用户所以一直放用户利益至上。需要在股东与ZF面前争夺用户的利益。

4，在国内的互联网公司，老板最佩服的公司是阿里巴巴，在IT业界电商方面它不仅把技术、服务做得第一，还给中国提供了无数就业机会与商机。

5，在当今中国经商不得不与官员打交道，需要懂很多门道，还有老板风趣说趣事比如，有时某位官员觉得迅雷不听话想找茬，最后迅雷常常先找到了他的上司，这样就安然无事了。

6，迅雷碰到最多的官司关于版权问题……常常很难与好莱坞那边谈拢合作起来，可恶的美国人表面很斯文实际上都是很强势的（老板在美国生活了十年时间深有体会）。迅雷与好莱坞那边有过几次官司谈判，结果都不是很愉快。最后迅雷找到了好莱坞的爸爸（默多克）作为靠山，通过华人邓文迪（默多克第？任妻子）加盟了迅雷股东，这会迅雷在谈判上就有了足够的底气了。

7，老板说到自己一段不孝子的故事。2011年迅雷在香港、美国路演筹备上市（虽然最终未果），其年迈的父亲也一直跟随之儿子，但老父一直有个吐痰的习惯，当时在路演过程儿子正因此（不良）习惯而在父亲身上感到过羞愧……事后老板认真反省过，羞愧自己不孝，更应该体谅老父年老。日后要努力做好孝子。

记于20130221（完）

关于C++ 静态成员对象的一段小故事

关于C++ 静态成员对象的一段小故事
  -- 20130322 静态对象做单例的危险

• 微博吐槽

（引用）近几天遇到一工作问题令我困惑不已，且又不是我所熟悉过的，直观体验完全感觉不出问题存在，但从大量测试统计能微微发现问题确实是存在的。诸多排除法之后还是觉得无从下手，甚至有违常理的感觉...一遍一遍review代码是件痛苦事情，最后靠着一点点改动希望接近问题所在，再得以解决。 附图：

btw. 吐槽不是重点，重点的是作为经验告诫提醒自己或他人。还有，吐槽了让我明天继续满血（激情动力）查问题。

• 故事细节

今天，Review代码时发现一个比较重要线索，线索不是最终问题（即下载速度变慢）但也是问题是程序存在的漏洞，但是很可能两者关系紧密。要知道在查“莫名”问题的整个过程是相当枯燥乏味的，还得顶着上面人的催赶压力，所以发现一丝可疑线索是足够令人兴奋起来的，何况该线索又是看似比较重要。发现了线索、解决问题并验证、提交测试验证跑速度对比，这个过程是轻快的，之后就等测试对比结果。由于晚上十点钟才提交开始部署测试，只能等到明早上班时间才能出结果。所以，先不管了安心回家睡觉，静待明日结果，如上图。

线索（问题）描述：DLL模块存在两个单例对象，都是数据量比较大的类型，这两个单例对象都是以全局的static静态对象存在的。所以，只要DLL被LoadLibrary加载起来了，即使什么事情也不做，这两个静态对象也被生成了（包括构造函数做的具体操作也统统被执行到了），直至DLL被FreeLibrary卸载掉它们才会被析构的。具体情况详见如下示例。

• 示例说明

 class A {

private:

   A() {

     ... ...

   }

   static A _s_a;

 public:

   static A* get_instance() {

     return &_s_a;

   }

   void do_work() {

   }

 }

 int main() {

  A *a = A::get_instance();

  a->do_work();

  ... ...

 }

> 问题在哪里？

 当程序还未执行到main()的A *a = A::get_instance();这行代码，对象_s_a已经被构造出来了，构造函数A()的逻辑也被执行了。

 当程序逻辑出现比较多这样的类型的静态成员对象，而且之间存在依赖关系的话，程序很可能在启动时候出现莫名其妙的问题。

• 安全的单例

> 更好的单例解决方案是什么？

*** 简单的单例模板：

template < class _Type >

class singleton

{

public:

    static _Type* get_instance()

    {

        // 通过观察汇编代码，static 变量初始化在多线程下并不安全，

        // 多个线程同时首次调用 get_instance，可能导致 instance 被初始化多次

        // 所以，强烈建议在进入程序时显式调用一次 get_instance。

        static _Type instance;

        return &instance;

    }

}

推荐在进入程序时，显式调用一下 get_instance

线程安全，dll 被 Load 多次时安全

singleton 的缺点是，对象只在程序退出时被析构，

所以无法控制它的析构时机，不安全！

*** 扩展的单例模板：

template < class _Type >

class singleton_ex {

public:

    static void create_instance();

    static _Type* get_instance();

    static void destroy_instance();

};

安全性最高，但是需注意其特殊用法，要求：

在进入程序时，必须调用 create_instance

在退出程序时，必须调用 destroy_instance

线程安全，即使dll 被 Load 多次时也是安全的。

只给出单例声明的模板，对于具体的实现细节在此不必给出，请自行YY脑补。另，强烈推荐在create_instance用从堆数据动态分配内存并构造（即new操作）单例对象。

（引用）singleton与singleton_ex的对比：

一般简单的单子,可以考虑使用 singleton

但是正因为它简单,所以忽略了一个问题,那就是多个单子类的析构顺序问题

如果多个单子的首次 get_instance 调用顺序是不确定的，那么它们的析构

顺序同样也是不确的。如果多个类的析构互相依赖，那么就肯定会存在问题。

所以，当有多个互相依赖的单子时，有两个解决方案：

1.使用 singleton_ex，进入程序时，按照期望的顺序调用 create_instance，

  在退出程序时，按照相反的顺序调用 destroy_instance。

2.使用 singleton，进入程序时，按照期望的顺序调用 get_instance，这样可以

  保证在 dll 被卸载时，多个单子按照与构造相反的顺序被析构。

所谓的“进入程序”，在 Dll 中，就意味着 DllMain 函数中的 DLL_PROCESS_ATTACH 分支

所谓的“退出程序”，在 Dll 中，就意味着 DllMain 函数中的 DLL_PROCESS_DETACH 分支

所谓的“dll 被 Load 多次”：dll 中的单子会面临一个问题，例如某个进程中，dll 被多

个模块分别 LoadLibrary 多次。因为单子的实质是 static 变量，故在整个进程中只有一个，

这可能是设计者期望的，也可能是设计者不期望的，所以必须要注意。

singleton_ex 中的 create_instance 和 destroy_instance 就设计了 _ref() 来处理被

多个模块多次调用。当然，singleton 不存在该问题。

>>>>> 对于更加牛逼的单例实现方案，参见Loki库的Singleton。还有，可参考我之前的另一篇关于单例的文章“单例安全性”。

（完）

Fwd: Android（程序）性能分析 Traceview

Android（程序）性能分析 Traceview

---

• 介绍Traceview

     “Traceview是android平台配备的一个很好的性能分析工具。它可以通过图形界面的方式让我们了解我们要跟踪的程序的性能，并且能具体到method。”

     Traceview程序是（Eclipse）android开发环境自带工具存在...\android-sdks\tools\;

     Traceview图形界面如下： 

     

图1. Traceview界面

   

•      a. 时间轴面板

          显示不同线程的执行情况，线上有不同颜色部分是代表线程执行不同函数。右上角显示时间轴的时间总长，左上角显示当前选中时间点的性能数据。

          注：在图形上点击鼠标拖拽就可以有放大效果，恢复原图只要双击最上面的时间轴横线即可。

•      b. Profile面板

          纵轴显示程序执行到的不同函数。横轴显示对应函数的性能数据，包括这些字段：Incl Cpu Time %，Incl Cpu Time，Excl Cpu Time %，Excl Cpu Time，Incl Real Time %，Incl Real Time，Excl Real Time %，Excl Real Time，Calls+RecurCalls/Total，Cpu Time/Call，Real Time/Call。

          大体上介绍一下以上字段含义：

          Incl是Inclusive（包含的），表示该函数的调用包括所有子函数的调用。

          Excl是Exclusive（独有的），表示该函数的调用仅包括基本操作，不包括子函数的调用。

          Cpu Time，就是真正在占用CPU的时间，Elapsed Real Time = CPU Time + Wait Time。详细参考http://en.wikipedia.org/wiki/CPU_time

          Real Time，就是时钟计时的时间（时长）。

          "Elapsed real time is always same or more than CPU time for computer program which use only one CPU for processing. If no wait is involved for I/O or other resources, elapsed real time and CPU time are very similar."

          %，占有的百分比。

          所以，字段“Incl Cpu Time %”就表示对应函数的Cpu Time在整个时间轴的函数调用中占的百分比。

•      c. 搜索框

     搜索框根据函数名称搜索显示对应的性能数据。

还有，可以参考Traceview 官网说明 http://developer.android.com/tools/debugging/debugging-tracing.html

• 抓取分析数据

     上面内容介绍了Traceview工具，光有工具而没有分析数据，哪来的性能分析。所以这部分内容讲述抓取分析数据。

    该部分说明如何抓取分析数据，即创建分析数据文件（Trace File）。其方法有三种：

•      1. 使用Eclipse的DDMS功能

         该方法是最简便也最实用，没有之一。而且不需要去修改代码也不管程序是否有读写SDCard权限（如方法2）。具体操作如下：

          a. Eclipse切换至DDMS页面，选中需要分析的程序（如xlwireless.wirelessadhocnetwork），点击右上角按钮“Start Method Profiling”，如下图：

          

图2. DDMS启动Traceview

          b. 停止操作时点击同一按钮，则Eclipse会自动弹出中Traceview图形界面，直接显示了Trace（文件）的分析结果。

          c. 若想保持分析数据（trace文件），只要操作Eclipse菜单File -> Save As ... 即可。

          的确是实在太简洁的操作吧！

          注意：该方法不支持Android 1.5设备，Android 2.1或更早版本需SDCard机器权限，而Android 2.2之后即使没有SDCard也行。（引用自官方说明）

• • If you are using DDMS, Android 1.5 devices are not supported.
  • If you are using DDMS, Android 2.1 and earlier devices must have an SD card present and your application must have permission to write to the SD card.
  • If you are using DDMS, Android 2.2 and later devices do not need an SD card. The trace log files are streamed directly to your development machine.

•      2. 使用Debug Class代码添加功能

         MainActivity的OnCreate方法添加：

  Debug.startMethodTracing("xl-adhoc-trace");

         MainActivity的OnDestory方法添加：

  Debug.stopMethodTracing();

         或者，你也可以换成在MainActivity的OnStart与OnStop方法。有人出现这样情况：“但是在实际的测试时发现这种方式其实并不好用，因为通常情况下我们的activity的onDestroy()是由系统决定何时调用的，因此可能等了很长时间都不会得到这个trace文件。因此决定在onStop()中来调用Debug.stopMethodTracing()。这样当我们切换到其它activity或者点击home键的时候onStop()就会被调用，我们也就可以得到完整的trace file。”

        使用该方式获取trace数据需注意：程序须有SD卡读写权限，当然还有代码权限。

        程序运行结束后，会在SD卡下生成对应trace文件（如xl-adhoc-trace.tracing），使用adb pull命令拉取trace文件或其他可视化拷贝都可以。

•      3. adb 命令行启动

        命令如下：

         adb shell am profile start

         adb shell am profile stop

        但该方法没有去做过尝试。

• 分析性能

     工具 + 数据 = 分析结果

     通过已保存有的trace文件，用命令行启动Traceview分析程序性能。

     1. 把Traceview目录添加到系统的环境变量Path，如c:\users\<user-name>\android-sdks\tools\;

     2. CMD命令行：traceview  ***.trace （注意：全路径的trace 文件，否则可能不行）。

     3. 自动弹出traceview图形界面，通过这个图形界面就开始分析程序的性能。

     结合图形，做简单的示例分析：

     a. 日志版的自组网程序刚启动时间（2s左右）的性能结果：

         

         从上图分析结果：打印日志的逻辑占了程序性能很大比例。

     b. 非日志版分享文件时的性能结果：

          

          从上图分析结果：可以优化的地方包括Wifi列表更新操作的refreshWifiScanResult，文件分享（发送方）的onRequestFileRange。

•      具体函数的分析

          针对分享文件数据（上图的）详细分析一下，查找refreshWifiScanResult与onRequestFileRange函数在具体地方占用其性能比例在哪里？

          见下图显示，用红圈标注出了性能的关键地方。

          

          

          

          

     

（完）

Fwd: 2013春节故事2（图文）

2013春节故事2（图文）

溪边洗涤.逝去的农村生活习惯 20130207 往外公家，路过小溪，在拱桥上看到桥下一位不识的老妇在溪边洗衣，竹篓、木槌、肥皂。顿然，感慨这种农村以前的陈旧生活习惯，小时候比较常见农村妇人在溪边洗涤，而随着生活水平提高妇女们早已方便在家洗涤。久违这样的画面了。 奖状.向五老同志致敬 20130207 ＂革命传统发扬光大，四化建设再展宏图＂，外公的奖状，其年纪比我大。外公曾说过以前他是某团重要通信员，后来回家与外婆结婚就没有再回去参军也就没了更好发展了，一直在老家当农民（村干部），再后来他的好多部下都成了地方的高级领导……是不是说，那年代的淳朴的战士，或许现在有人说憨厚无知，今非昔比，如今物欲横流。 枯黄芭蕉叶.季节的痕迹 20130209 （图，外公家门前的枯黄芭蕉叶）十月那会鲜绿的芭蕉叶，短短数月，如今枯黄凋零。岁月，一把无形杀猪刀。冬天已来过，留下了烙印，春天还远吗？ 残墙断壁.岁月的痕迹 20130209 （残墙断壁） 外婆家门前的＂残墙断壁＂，谁说岁月无痕？小时候还是一座完好的小土（圆）楼，二十年前的一场火灾狠狠摧残了它，再经过人们这么多年的摈弃，如今这般只剩一面断墙... 桃花朵朵开.好运相随 20130212 （图，桃花花开好时节） 春风习习，桃花朵朵开。看，春天的脚步已悄悄到来... 鸭子与炮竹碎纸.新年氛围 20130212 （图，鸭子与炮竹碎纸） ＂春江水暖鸭先知＂人过年，它也过年，新年快乐！ 乡村画面.自然美 20130212 一幅乡村景色画面。在乡村，这样的景色很自然而常见，美。黑云、白云、一线蓝天、群山、雾气、水泥路、一条公狗…… 红艳艳三角梅.红红火火 20130214 某伯伯院里的三角梅，正是花开好时节，红红火火。补充（20130216）：刚好，那天是情人节，都过了两天了，我才知道，真是无情人便空情调了！顺祝新年好运，桃花朵朵开。 祠堂祭拜.光宗耀祖 20130213 我在老家祠堂祭拜，纯属打酱油般摆摆Pose！＂光宗耀祖＂ 20130213 中午，父亲把我叫到单独的地方，带着比较严肃表情说：＂前天晚上我做了个梦...就想你这几天还是不要出门了好！＂，我被惊讶到了，他没具体说什么梦，我也没再问什么但大概明白意思，就以简单的＂嗯噢＂答应了他。正好也就不再考虑这两天外出游玩的打算...好像从来没直面过父亲迷信的一面，唉天下父母心，顺其心意，彼此安然。顺祝新年一家幸福安康！  公路上2B大兵.童趣无邪 20130213 年度最佳2B小弟，大马路上冒充大兵，话说装备齐全！  翠绿的嫩叶.茁壮成长 相濡以沫或相忘江湖，也就就那么一念之间。