邵明博

《富爸爸，穷爸爸》读书笔记

2015-03-22T13:44:00+08:00

最近在整理Evernote，看到当年读这本书的一些笔记。

富人买入资产，穷人只有支出，中产买入他们以为是资产的负债
资产的类别：
- 不需要我到场就能运作的业务
- 股票、基金、债券
- 可以产生收入的房地产
- 其他可以产生收入且市场流通性好的东西
找到一个超现实的理由：想要与不想要的结合体
每天做出自己的选择：使用我们的时间、金钱以及头脑里的知识来实现目标
掌握一种模式，然后再学习一种新的模式：并不要求你学太多，（因为你学到的时候，这个东西基本上就已经过时了)而在于你学得有多快！
自律，可以增强上述所有功能

Alpha的秘密

2015-02-02T21:08:00+08:00

Google 最近搞了个Android Performance Patterns，挺好的，光这个名字，就已经给整个社区很好的定位了。其实性能优化这档子事吧，android 社区从来就有。只不过，从前都是只言片语，大伙也只能各自摸着石头过河。这一次Google不但在G+上搞了这个讨论区，还以“Patterns”的形式推出了一套指导视频，从渲染、内存、电池三大方面剖析了性能优化的方法、工具以及一些小的技巧。这一系列的动作，引发了各界不小的反应，我还看到有国内的开发者把这套视频翻译为”android性能优化典范“，着实给力呢。

既然有了这么好的氛围，这个博客也打算凑凑热闹，帮忙翻译、整理一些和性能优化有关的Tips。你可能不敢相信，一个简单的优化步骤能带来多大的性能提升？！让我们先看一张图：

如果你已经看过Profile GPU Rendering 的介绍，一定会被这幅对比图惊艳到。仅仅是一个alpha 属性的设置，两者的渲染性能差别如此之大。据Roamn Nurik 介绍view的alpha属性在合成之前需要放到屏幕外的缓冲区中作额外的渲染工作。但，如果只对textcolor作alpha属性的设置，渲染性能立刻提升了10倍。

与之类似，在TextView中使用background set,Spannable text以及让文字被选中，都会加重渲染的负担。了解渲染负担并合理的避免，应该才是性能优化的王道。

参考资料

improving performance by switching from view alpha to text color alpha

class文件从硬盘到内存的心路历程

2015-01-28T21:25:00+08:00

0x00 加载

类的加载本质上是由类加载器将字节码转换为java.lang.Class对象的过程
除了引导类加载器之外，所有的类加载器都有一个父类加载器
每一层的类加载器在收到加载请求之后，会将请求委派给父加载器执行；只有父加载器无法完成加载请求的时候，子加载器才尝试自己加载
这种双亲委托模型一方面避免了类的重复加载，另一方面还能防止Java 核心API被子加载器替换带来的隐患

0x01 链接

链接分为三步：验证、准备和解析。其本质上是将字节码合入JVM运行时的过程。
验证阶段主要是确认字节码结构的合法性，一旦验证失败，JVM会抛出java.lang.VerifyError异常
准备阶段主要是将Java类的静态域初始化为默认值（并不执行任何代码）
解析阶段主要是确保所有引用的类能被正确的找到，这通常会导致引用类被加载

0x02 初始化

该阶段的任务主要是初始化静态域，以及执行静态块代码。一个类被初始化之前，其父类会被先初始化。关于这一点，有2个需要注意的地方：

通过Java反射API也可能造成类的初始化
当访问一个类的静态域时，只有真正声明这个域的类才会被初始化。则，考虑如下代码：

class Base {
   static int value = 100;
   static {
      System.out.println("我会被输出.");
   }
}

class A extends Base {
   static {
      System.out.println("我不会被输出");
   }
}

public class Test {
   public static void main(String[] args) {
      System.out.println(A.value);
   }
}

如上所述，上述代码的运行结果为：

0x03 参考资料

定位Native异常

2015-01-26T21:08:00+08:00

0x00 ndk-stack

Google从NDK r6开始提供这个方便的工具，帮助开发者定位Native 异常。和ndk-build一样，这个命令行工具被放在NDK安装目录下。作为Debug 工具，其操作方法也十分简单：只需在参数里指定包含符号表的so文件即可。

如果需要实时获取异常信息，我们可以直接运行：adb shell logcat | ndk-stack -sym $PROJECT_DIR/obj/local/armeabi；有的时候日志文件并不一定能直接看到，该工具也支持“异步”分析。这里我们首先运行：adb shell logcat > android.log来模拟“异步”获取日志。在获得日志文件之后，我们拿它喂给命令行工具：ndk-stack -sym $PROJECT_DIR/obj/local/armeabi -dump android.log。

就这样，天书一般的日志文件瞬间变得友好可读了。

0x01 addr2line以及objdump

对于有经验的程序员来说，可能更熟悉这2款工具。方法类似，结果相同，所以这里就不再赘述了。

蛋疼的BUG：binder事务异常

2014-11-11T15:15:00+08:00

一句log”!!! FAILED BINDER TRANSACTION !!!“，伴随着App的崩溃，留下的是程序员深深的思考。定位到android 的源码，此log 出自android_util_Binder.cpp。

void signalExceptionForError(JNIEnv* env, jobject obj, status_t err, bool canThrowRemoteException)
{
    switch (err) {
        ...
        case FAILED_TRANSACTION:
            ALOGE("!!! FAILED BINDER TRANSACTION !!!");
            // TransactionTooLargeException is a checked exception, only throw from certain methods.
            // FIXME: Transaction too large is the most common reason for FAILED_TRANSACTION
            //        but it is not the only one.  The Binder driver can return BR_FAILED_REPLY
            //        for other reasons also, such as if the transaction is malformed or
            //        refers to an FD that has been closed.  We should change the driver
            //        to enable us to distinguish these cases in the future.
            jniThrowException(env, canThrowRemoteException? "android/os/TransactionTooLargeException": "java/lang/RuntimeException", NULL);
            break;
        ...
    }
}

很明显，按照注释的描述，我们遇到的问题就转换为了TransactionTooLargeException引起的程序崩溃了。去官网一查，它给出的说明更清晰：远程调用的时候，参数和返回值都以Parcel 的形式保存在Binder 事务的缓存对象中。如果参数或返回值过大，则会抛出TransactionTooLargeException异常。

按照这个提示，我跟到驱动层的binder.c的代码看了一下binder_transaction以及binder_alloc_buf方法，证实了前面注释代码所言非虚。另外，官方文档提到了一个1M 大小的buffer空间的限制，我翻了几个版本的代码来看，发现其实这个数值并没有写死。buffer 应该是不大于2M而不是它说的1M，但正如文档所说，由于binder 被所有跨进程通讯所共享，即使你的parcel 不大，但是使用binder 的人很多，也有可能造成上述异常。所以，这里解决问题的方法，应该是尽可能的传递小一点的parcel或者使用其他数据通讯方案。是的，说的就是你，不要用binder 传那么多那么大的高清图片了！

android内存泄露及分析工具

2014-10-24T14:42:00+08:00

话说，任何开发环境，想要取得上乘的性能，内存优化是一个不可避免的话题。虽然android 开发过程中，有GC陪伴，但这并不意味着你可以完全忽略内存的分配与释放。这是因为，不恰当的代码仍然会导致内存泄露，以至于GC也无力回天。

内存限制

为了维持多任务的运行环境，android 给每个运行的应用规定了一个内存上限（因不同设备的物理内存大小而变化，常见的有16M~48M不等）。每当你的应用企图在触碰上限的情况下分配内存，就会引发OutOfMemoryError。

内存泄露

虚拟机中的内存泄露基本上就一条：代码残留了对象，让GC无法回收。也许这个情况一时半会不会翻起大浪，但也可能在下一秒，就触碰内存限制，导致程序崩溃。所以，内存泄露的BUG通常都非常隐蔽、随机、让人头大。

常见的泄露有以下几种：

Cursor没有关闭
registerReceiver之后没有成对的unregisterReceiver
I/O Stream没有关闭
Context泄露

前面3种情况，没啥好说的，在代码层面稍加注意即可避免。最后一种情况可能有些变种需要注意，这里使用2个例子尝试着描述一下。首先借用Romain Guy的例子：

private static Drawable sBackground;

@Override
protected void onCreate(Bundle state) {
  super.onCreate(state);

  TextView label = new TextView(this);
  label.setText("Leaks are bad");

  if (sBackground == null) {
    sBackground = getDrawable(R.drawable.large_bitmap);
  }
  label.setBackgroundDrawable(sBackground);

  setContentView(label);
}

万恶的静态变量出现了，引用关系Drawable–> TextView–> Activity导致整个Activity 无法被回收。此外，经常被讨论的Webview 泄露，情况也是类似的。解决方法可以参考这个帖子。这里要谈的另外一种Context泄露是由于非静态内部类引用导致的:

public class DemoActivity extends Activity {
    class LeakRUN implements Runnable {

        @Override
        public void run() {
            try {
                TimeUnit.DAYS.sleep(365);
            } catch (InterruptedException e) {
            }
        }
    }

}

正确的处理这种泄露应当仿造ViewRoot中的内部类W那样使用弱引用。这么做的好处是，一来不会出现空指针，二来不会导致内存泄露。

内存工具

尽管上面罗列了种种常见的泄露情况，但实际开发中遇到的现象总是千奇百怪的，解决泄露的方法也会因情况而异。所以，这里更重要的是需要了解如何使用工具来发现应用内存是如何泄露的。

Logcat

越简单的方法，往往越直接有效。Logcat 提供实时的虚拟机日志，每当垃圾回收发生的时候，我们会看到这样的日志D/dalvikvm: , , , 。其中，垃圾回收的原因、回收内存的大小这些并不是现在关注的重点，我们的兴趣点应该放在堆的状态上。这个状态通常会提供两个数值，“空闲内存的比例”以及“内存占用的比例”。如果后者在每次垃圾回收之后，持续上升，那么几乎就可以断定出现内存泄露了。

Monitor

Monitor是一个工具大集合，开发者可以从Android studio/ Eclipse直接找到它的入口，调试人员也可以直接从目录/tools/下找到它。比起Logcat 被动的查看log, Heap Update提供了可视化的内存数据界面以及垃圾回收的操作接口。连续的在观察数据、回收内存以及应用交互的过程中往返，可以帮助我们定位“哪些操作”引起了内存激增。Allocation Tracker则提供了更为精确的代码级定位。

adb

adb 命令行工具提供的内存查询接口则更为灵活，信息也更加丰富。一行命令adb shell dumpsys meminfo 即可完成操作。有精力的开发者完全可以依此定制一款自己的工具来帮助内存泄露的定位。一般来说，我们可以关注Pss Total以及Private Dirty这两项数据来掌握内存信息，而Objects栏目的数据可以帮助引导我们更直观的发现泄漏的情况。

Heap Dump

最有效的工具，肯定需要最后出场。在Monitor 中选择Dump HPROF file，可以导出整个设备的虚拟机内存信息。由于该文件并不是传统的java 虚拟机内存文件，因此需要使用android sdk 中的hprof-conv工具对其进行转换。对于转换后的文件，可以使用Eclipse Memory Analyzer Tool (MAT)进行分析。该工具提供两种不同的视图（Histogram和Dominator tree）分别从不同的视角帮助你分析内存。值得一提的是，如果需要更为精确的导出时机的话，还可以在项目的代码中进行控制。

以上工具的具体使用方法，可以参考以下链接的文献，这里就不再赘述了。

参考资料

警惕libgl1-mesa-glx:i386

2014-10-19T15:13:00+08:00

编译android工程应该来说没啥技术含量，按照官方的guide line一步一步的做，基本上都还OK。但，之所以想写个日志，主要是因为被这个工程的编译环境搞得有点抓狂了。起初是在osx上折腾，之后发现各种依赖关系搞起来太费神，就开始了转投传说中最稳定、顺畅的ubuntu 12.04了。万万没有想到，在虚拟机上跑了4个小时，最后给我看这个：

刚查到解决方案的时候，打算给虚拟机更大的内存跑编译任务，于是重启了。重启之后，蛋疼的卡在了logo界面。一顿排查，发现原来是在准备编译环境的时候出了问题。

sudo apt-get install git gnupg flex bison gperf build-essential \
  zip curl libc6-dev libncurses5-dev:i386 x11proto-core-dev \
  libx11-dev:i386 libreadline6-dev:i386 libgl1-mesa-glx:i386 \
  libgl1-mesa-dev g++-multilib mingw32 tofrodos \
  python-markdown libxml2-utils xsltproc zlib1g-dev:i386

症结所在

Ubuntu 12.04.5 上执行sudo apt-get install libgl1-mesa-glx:i386时，会提示你安装libgl1-mesa-dri:i386。如果按照这个建议执行，你会发现安装程序会帮你删除一批不兼容的软件，其中包括xorg，最终导致你无法进入桌面。

解决办法

将libgl1-mesa-glx:i386替换为libgl1-mesa-glx-lts-:i386，其中release 根据ubuntu的版本可以是Quantal、Raring、Saucy以及Trusty。我自己安装的是libgl1-mesa-glx-lts-Trusty:i386。至此，该问题完美解决。

参考资料

LTS Enablement Stacks

android数据库升级tips

2014-10-16T22:18:00+08:00

唯一不变的是变化

App 版本迭代的过程中，一定会遇到sqlite 数据库需要升级的情况。一个简单粗暴的解决方法，是不顾用户的数据，直接去重建各个数据表。显然，今天要分享的并不是这个粗暴的方法。

常见的困惑

SQLiteOpenHelper提供了一个处理数据库升级的APIonUpgrade(final SQLiteDatabase db, int from, final int to)。从语义上来看，升级策略的描述应该有一个起始点from，也还应该有一个终点to。但由于起始点的不确定性，致使这里的代码分支会略显复杂。老实讲，在写这篇日志之前，我都没有把握温柔细致的处理好这件事。

灵感来源于android源码

DownloadManager也使用数据库存储下载状态。其子类DatabaseHelper将升级函数降维，把原本复杂的升级过程，分解为多个原子的升级过程，而这个原子过程是简单、确定的。直接上代码吧：

@Override
 public void onUpgrade(final SQLiteDatabase db, int oldV, final int newV) {
    ...
    //循环体内，每次只升一个版本
    for (int version = oldV + 1; version <= newV; version++) {
                upgradeTo(db, version);
    }
}

//Upgrade database from (version - 1) to version.
private void upgradeTo(SQLiteDatabase db, int version) {
    switch (version) {
        case 100:
            createDownloadsTable(db);
            break;
        case 101:
            createHeadersTable(db);
            break;
        case 102:
            addColumn(db, DB_TABLE, Downloads.Impl.COLUMN_IS_PUBLIC_API,
                              "INTEGER NOT NULL DEFAULT 0");
            break;
        case 105:
            fillNullValues(db);
            break;
        ...
        default:
            throw new IllegalStateException("Don't know how to upgrade to " + version);
        }
}

以上代码不仅逻辑清晰，而且还能很好的复用。比如在onCreate函数里需要初始化数，就可以直接调用upgradeTo(db, CURRENT_VERSION).这样一来，无论是从哪个版本升级上来，都能平滑的处理版本问题了。

参考资料

DownloadProvider

谈谈android屏幕适配

2014-10-08T17:32:00+08:00

痛并快乐着

“碎片化”像一个魔咒，从android 平台问世那天至今，伴随其成长。客观的说，这样的多样性的确帮助android 俘获了数以亿计的用户，但却给该平台下的设计师和开发者带来了不小的挑战。学会适应这样的生态环境，不仅需要更加广泛的知识还需要更加高超的技巧。不过话说回来，在满足各式各样的用户的过程中，你将成为一个更好的设计师或开发者。不得不说，这是一个值得追求的挑战！

目标

想要收获挑战的胜利果实，必须要有一个明确的目标。本文并不想纠结于品牌、乃至OS 版本的碎片化等问题，那需要更多的篇幅和精力去探讨。这里只想专注于屏幕适配这一问题进行集中的讨论。

从OpenSignal这份报告来看，2014年支持android 的设备就有18796种，而设备屏幕的种类也是千奇百怪的。理想状态下，为每一种目标设备设计一套视觉资源，似乎就不存在适配的问题。但，没有一个设计师会愿意接受这种方案（工作量太大了好吗？）。就算有“勇士”接受了这样的设计任务，应用安装包也将变得臃肿不堪（apk太大了好吗？）。

这样看来，屏幕适配的目标就清晰了许多：尽可能设计可重用的视觉资源，让目标设备良好呈现。这通常需要视觉人员以及程序猿的通力配合，才能达到预期的效果，任何一方的懈怠，都会导致功亏一篑。

怎么搞

设计的好不好，决定了适配程度的优劣。这里谈到的设计与视觉效果关系不大，而主要是适配设计。从以往的经验来看，设计师们习惯了用视觉语言去描绘设计，而程序猿们则习惯了用代码去实现设计。所以适配问题只有在视觉走查这个阶段才会让双方感到蛋疼。

明确需要支持的范围

那么多屏幕，可能有很多并不是我们的目标用户（比如TV屏），将有限的精力瞄准该做的事从来不会有错。国内的一些第三方市场报告能够给我们这方面的“灵感”，另外Google 也会定时更新在全球范围内的统计报告(需要翻墙)。

使用模糊定位和相对布局

通常来讲，设计师们直接给出的标注往往会让android 程序猿们头疼。这是因为，设计稿通常绑定了一个静态的设备分辨率，这就导致其标注出来的数字具有相当的局限性——只对一种分辨率有效！。换句话讲，在适配屏幕的过程中，程序猿们并不希望看到一些硬编码的数值标注，因为这会使得这份设计过渡依赖当前这个分辨率，而使得适配难上加难了。

好在Android 平台为我们提供了强大的适配语言：使用wrap_content以及match_parent来描述单个控件的大小，还有超级强大的RelativeLayout来描述多个控件的组合……系统在运行时，会通过动态计算摆放它们的位置。用自然语言说，最好不要告诉程序员具体大小，而是告诉他们一些个相对数值。让我们看个例子：

“先战一把”的按钮并不需要知道自身要有多长多宽(使用match_parent)，而只要知道自己和周围的距离，就能摆放恰当了; 再看看应用图标的摆放甚至都不需要知道左右的相对距离（使用wrap_content），只要给出类似“水平居中”这样的模糊定位，即可良好呈现。

通常一个设计稿，如果从上到下，从左到右（反过来也行），能够让每个控件尽量使用模糊定位和相对布局，那么适配各种屏幕，简直就是轻而易举。不过，有些刁巧的设计并不适用于这类描述。那么这个时候，可能就需要产品经理去权衡展示效果和适配力度之间的问题了。

使用资源限定符

细心的读者可能已经发现，上面的方法虽然能够尽可能的规避具体控件的大小，但是“漏网之鱼”以及一些相对距离还是硬编码来的啊！虽然他们只是边边角角，但是为了视觉呈现的效果，还是可以使用资源限定符来进行适配的。简单的说，资源限定符可以让设备在程序运行的时候，自动选择与设备最匹配的资源。不过，在正式介绍资源限定符之前，恐怕还得介绍一些个相关概念：

屏幕密度：一言以蔽之，同样的物理尺寸，密度大的屏幕通常显示更为细腻。这是因为该屏幕单位面积内可以用来显示的“点”更多。所以，屏幕密度的单位是dpi(dot per inch，每英寸点)就很好理解了。这里还需要强调的是，屏幕尺寸和屏幕密度是2个独立的概念。一些个山寨手机虽然屏幕大，但显示效果却不尽如人意。这是因为山寨屏的单位面积内可用来显示的“点”太少，导致图像细节在显示过程中丢失。android 平台目前将屏幕密度分为6个等级：low（ldpi~120dpi）, medium（mdpi~160dpi）, high(hdpi~240dpi), extra-high(xhdpi~320dpi), extra-extra-high(xxhdpi~480dpi), and extra-extra-extra-high(xxxhdpi~640dpi)。
密度独立的像素(dp, Density-independent pixel): 是一个虚拟的度量单位，与屏幕密度无关。试想，在没有dp 的年代，直接使用像素去描述布局和位置。那么，1个像素在ldpi的屏幕占1/120, 而在xxdpi的屏幕上只占1/480。那么同样的视觉设计在4寸山寨屏与4寸视网膜屏的显示会相差3倍！dp 的出现完美的解决了这个问题：系统会根据当前设备密度的需要，透明的缩放尺寸。

也许你已经看出，我们的适配都寄希望于系统的自动缩放了——嗯，我想你已经领悟到了精髓。现在继续来讲前面的“硬编码”问题。所以，即使是硬编码，我们也不能直接使用px来描述，而应该使用dp。那关屏幕密度什么事呢？关资源限定符什么事呢？

可以说，除代码外的所有静态资源，全部都分布在不同类型的工程目录下，而不同类型的目录还细分了各种属性，这些属性帮助系统在运行时能够根据设备自身的配置从相应的目录中动态的加载这些静态资源，以达到适配的效果。android 资源文件夹使用-来分割限定符。拿图片文件来说，drawable-hdpi文件夹所存放的图片适用于高密度(high density)的设备屏幕，而drawable-xhdpi则适用于超高密度(etra high density)的设备屏幕。下图所示的ic_launcher.png图片重复出现在了三个文件夹里。当请求名为 ic_launcher 的图片时，系统运行时会根据设备配置自动选择适应的图片。这能让我们根据不同屏幕尺寸最优化图片的显示，但是重复存储的图片势必造成浪费资源。

动态加载静态资源的过程，可能会遇到“找不到最合适资源”的情况。这个时候，系统会拿其他目录中同名的资源进行缩放处理。举个例子，系统需要加载drawable-xhdpi下的ic_launcher.png文件，但发现找不到！这个时候找遍了资源目录却发现只有drawable-hdpi下有ic_launcher.png。系统会毫不犹豫的加载，并将其放大1.3倍。设计师看到这里可能会有点激动，“放大？那图片资源会不会失真？”没错，这个担心很合理。所以，通常的做法是保证最高密度文件夹下有相应的文件，那么系统在动态加载的时候只会处理缩小的过程。

事实上，利用上面这个特点，我们在设计输出时，应该直接瞄准那些高密度规格的设备，比如1920 * 1080。一次输出后，填满drawable-xxhdpi文件夹。这样直接可以一次性适配的分辨率就有640 * 360、1280 * 720、960 * 540。

同理，前面谈到的硬编码的相对数值（静态常量资源），应该合理的分布在不同文件夹下的dimens.xml文件里。对，这里可能就需要视觉人员给出多套标注，以达到最大限度的复用！

你以为资源限定符就这样介绍清楚了？图样图森破！不过这段文字应该能够让你对动态加载静态资源有一个清晰的认识。想要了解更多，请访问developer.android.com 进行系统的学习。(*^__^*)

使用9-patch

那么多屏幕要适配，要是图片本身就有自适应的能力该多好啊！9 patch bitmap 将赋予你这种魔力。这是一种图片格式，允许设计人员定义图片能够被拉伸的区域，通常被用在背景性质的图片中。这样带来的好处是：一方面给背景显示带来了灵活性（可拉伸），另一方面还大大降低了图片的“重量”。官方提供了简便的制作工具（需翻墙）, 网络上也有大量的文章介绍，这里就不再赘述了。显然，这类资源如果得到复用，那么必能极大地减小应用安装包的大小。另外，各种按钮、背景的图片资源如果能在设计时就考虑复用的话，那也必是极好的。

唠叨

android 平台提供的适配工具，我想先介绍到这里。本文没有提到“为特殊的屏幕类型提供不同的布局”这类细节，是因为觉得其工作原理和上述内容类似，当然太懒也是一个不容掩饰的原因。一句话总结，无非是提供可替换的静态资源，让系统自身去操心如何适配罢了。

参考文献

TCPDump for android

2014-10-04T23:41:00+08:00

抓包要有效率

前段时间一直在做一款社交类答题的App。深有体会的是，不管是前期研究竞品，还是后期和服务端联调，抓包调试都是必不可缺少的环节，而且抓包的效率深深的影响着开发的效率。

由于REST API 的盛行，已经有大量现成的工具可以方便的进行抓包，比如大名鼎鼎的Fiddler，以及免费且跨平台的Rythem。应用开发者只需要简单的设置代理，抓包信息即可尽收眼底。而非REST API的抓包则相对来说就麻烦了许多，每抓一次包既要碰电脑敲命令，又要弄手机进行测试操作，很是忧桑。因此，为了提升效率，本猿就想到基于tcpdump 重新定制一个工具。想要的效果也不复杂，一个全局的悬浮窗，给出抓包控制按钮即可。这样调试起来，就不用来回切换那么麻烦了。

编译tcpdump

首先的工作当然是编译一个可用的tcpdump。虽然Android NDK 提供了方便的交叉编译工具，但是编译过程还是有不少的坑。比如android 不支持setprotoent以及endprotoent等。详细的编译过程，这里就不做讨论了。这里提供一个arm 版本的tcpdump for android 下载。（基于tcpdump-4.6.2.tar.gz，libpcap-1.6.2.tar.gz）

开发工具

整个工具只有一个界面，一个全局窗口。代码在放在Github 上，当然你也可以直接从Google play下载、使用。噢，前两天看到一个妹纸发了一张图和抓包相关，而且还不错，这里也mark 一下。

深圳动物园一日游

2014-04-13T19:46:00+08:00

天气不错，心情也还不错。约上小伙伴，去了一趟动物园。

更多图片，查看我的Flickr相册

使用Dropbox搭建私人git仓库

2014-01-02T13:59:00+08:00

Why this?

有私人项目(不限于代码以及设计方案)
该项目（暂时）不公开
需要版本控制
虽然github 是一个不错的选择，但就项目目前状况而言premium 账号显得并不划算
项目备份以及研发环境的迁移
and so on

How

就像stage area是working directory与本地仓库的缓存，本地仓库是working directory与中心仓库之间的缓存
我们把dropbox看成是中心仓库，那么working directory与中心仓库之间的缓存就是本地仓库了
建立本地仓库git init
构建stage areagit add .
初始化提交git commit -m 'repo init'
创建dropbox 中心仓库git init --bare ~/Dropbox/git/center.git
建立远程连接git remote add dropbox ~/Dropbox/git/center.git
备份本地仓库git push dropbox master
拉取中心仓库git pull dropbox master
若开发环境发生了迁移，比如从公司换到了家里，git clone ~/Dropbox/git/center.git

写在最后

好的云存储服务有很多，而dropbox是客户端最完备的一个。本文介绍的方法显然不限于dropbox一家。
~/Dropbox/是dropbox安装后的默认路径，不同的云存储的本地默认地址会不同
git子目录是我自己创建的，所以center.git也可以根据需求命名

git 常用命令复习

2013-12-23T11:13:00+08:00

最近打算对帝傲狮进行重构，觉得应该是时候启用版本控制工具来管理代码了。想当初为了学习这个，我还专门看了几天的《Git版本控制管理》，可是长期在公司使用clearcase，现在我连它长什么样都记不起来了-_–# 。悔恨当初做的笔记太渣，现在重新把书啃一遍那基本上又不太现实。好在这两年网上积累了好多有关的优秀资源，以下便是我这两天通过学习&使用这些网络资源而整理的git 常用命令的使用说明

git clone

clone 操作将会复制一个已经存在的git仓库
clone 操作会自动的创建一个名叫origin的远程连接指向原始的仓库
This makes collaborating with Git fundamentally different than with SVN

git config

git config user.name设置用户名
git config user.email设置电子邮箱
默认情况下是对当前仓库进行设置，加上--global标签之后，则为全局设置

git add

直到运行git commit之前，git add并没有直接影响仓库
git add stage 单个文件的改变
git add stage 整个目录的改变
git add -p交互式的add

git commit

将处于stage 状态的该表保存到仓库
git commit -a会将工作区的所有改变保存到仓库
除非你真的准备好了，否则git 不会强迫你与中心仓库记性交互
就像stage 空间是工作目录与代码仓库之间的缓存一样，本地仓库是开发者的代码贡献与中心仓库之间的缓存
git commit --amend修改之前的commit。这将导致当前的stage区间与前一个commit的状态融合。
和git reset一样，git commit --amend不应该发生在发布后的上。
--no-edit可以使git commit --amend使用上一次commit的注释

git status

用来显示工作区的状态

git log

该命令被用来显示commit 历史
git log将使用默认格式显示，通常会输出多于一屏的内容。使用空格翻页，使用q退出。
git log -n 限制输出的条数
git log -oneline高度抽象概括提交情况
git log --stat同时呈现相关文件、相关行的信息
git log --author=搜索指定作者的commit。pattern可以是包含正则表达式的字符串
git log ..搜索两者之间的commit。since、until既可以是commitID,也可以是branchName或者是其他的reference
git log 查看指定文件的提交情况
git log --graph --decorate --oneline—graph 顾名思义，用来图形化提交状态；——decorate用来显示分支或者便签的名称；

git checkout

该命令有三种功能：检出file，检出commit，检出branch
git checkout 更新本地仓库与匹配，之后的操作都将记录到该分支上。检出分支后，不必担心之前的最新代码会遭到污染，任何改变如果没有commit，只存在于stage状态
git checkout 检出commit。会使得工作目录的所有代码变成该commit的状态(可以为commit hash或者是tag)。检出一个旧的commit，并不会造成代码丢失，开发状态将会变为detached HEAD。值得注意的是，开发应当发生在真正的分支上，否则代码融合的时候会遇到不小的麻烦。
git checkout 检出文件。和之前的检出不同，这种检出会影响到当前工程，使得该文件的状态变为Change to be committed,若希望还原回主线状态，应使用git checkout HEAD
git checkout -b 创建分支，并切换到该分支去
git checkout -b 与上条一样，不过创建的分支是基于，而不是当前分支

git revert

作为undo 操作存在
并没有删除任何commit 结点，而是将之前的结点append 到HEAD
比reset 更安全

git reset

是一个可能影响仓库安全的命令
和git checkout一样，根据目的不同，有多种用法
git reset 清除该文件的stage状态，保留工作区间的文件状态
git reset将stage恢复到最近一次提交，保留工作区间的文件状态
git reset --hard将stage和工作区间的文件都恢复到最近一次提交
git reset 将stage恢复到的状态，保留工作区间的状态，以便re-commit的时候有一个更干净的stage
git reset --hard 将stage和工作区间的文件恢复到状态
需要注意的是：如果之后的仓库被发布过，那么你不应该使用git reset --hard ，因为有可能其他开发者对这个及之后的代码有依赖

git clean

该命令通常和git reset --hard一起使用
主要目的是用来删除工作区间里没有被追踪的文件
git clean -n并不会真正执行清除，而是告诉你将会清除哪里文件
git clean -f将会清理当前文件夹下的未被跟踪的文件，但并不会清理文件夹以及.gitignore中提及的文件
git clean -df清理当前文件夹下的未被跟踪的文件和目录
git clean -xf清理当前文件夹下的未被跟踪的文件以及那些git 通常忽略的文件

git branch

每一个branch都可以看做是独立的开发流水线，是上述所有操作组合形成的抽象引用
git branch支持创建，罗列，删除以及重命名操作，通常需要配合git checkout进行分支切换，配合git merge进行代码融合
分支不仅可以使开发任务并行，还可以保证主线代码永远处于可用状态
git branch罗列当前仓库中所有的分支，带上-r可以罗列远程分支
git branch 创建分支，但并没有切换过去
git branch -d 如果代码已经merge回主线，则安全的删除该分支，否则给予警告，且不执行删除操作
git branch -D 强行删除分支
git branch -m 修改当前分支的名字

git merge

通常来说merge 有两种算法来执行：fast-foward merge以及3-way merge
当前分支与目标分支之间是linear path，则执行fast-forwad merge，如图1所示，git 只需要将当前分支的HEAD移过来即可（不走回头路）
如果当前分支与目标分支之间有分叉,如图2所示，则执行3-way merge。
git 使用edit/stage/commit的工作流程来解决merge 冲突：使用edit来解决冲突，使用add 来闭合修改，使用commit 来完成merge

git rebase

git rebase 将当前分支rebase为，其中可以为commit、tag或者是分支名称
使用rebase主要目的是保持项目仓库的linear状态，以便分支融合的时候可以使用fast-forward merge
和git reset一样，不要对以发布的仓库部分执行rebase
git rebase -i以交互的形式进行rebase

git remote

该命令可以让你创建、查看、删除与其他仓库的连接，这些连接更像是一个个书签
git remote呈现你的所有连接
git remote -v和上一条命令一样，但是要多显示URL
git remote add 创建一个连接，在此之后，可以直接使用来访问这个连接了
git remote rm 删除这个连接
git remote rename 修改连接名称

git fetch

git fetch 将该连接的所有分支全部导入本地
git fetch 仅导入该连接的特定分支
我们可以checkout 远程分支，但此刻会处于一个HEAD detached状态；可以想象这些远程分支为只读的，我们能做的是review他们的代码以及merge到我们的本地分支上来

git pull

git pull 将该连接的当前分支导入本地，并进行融合操作
git pull --rebase 和上述操作效果一样，但使用rebase而不是融合
git pull与SVN的update类似，作用都是保持本地代码最新
--rebase可以避免不要的merge操作
使用git config --global branch.autosetuprebase always将pull的默认动作设置为rebase

git push

git push 将推送到远程仓库去。如果本地仓库和远程仓库之间的代码不能执行fast-forward merge，则git 会拒绝该次推送
git push --force和上一条效果一样，只不过会强制执行
git push --tags将本地标签全部推送到远程仓库去

参考资料

附图

图1 a fast-forward merge

图2 a 3-way merge

android无线调试

2013-12-03T20:04:00+08:00

使用无线调试对于我来讲，只有一个理由：爱惜手机电池。长时间的调试过程，使得我们的爱机必须通过USB 与电脑相连。长此以往，手机电池就会变得非常不经用。

很早之前，以为只有获得ROOT 权限的手机才能开启这个功能，直到有一天被我发现statckoverflow 上的一个帖子。（之所以会有这个错觉，是因为看到Google Play上提供的相关APP 都有root权限的声明）。那么，这里我就分别总结一下，不同情况下该如何使用无线adb

如果手机拥有ROOT 权限

在shell 里执行以下命令：

开启adb无线调试

su
setprop service.adb.tcp.port 5555
stop adbd
start adbd

这也是大部分完成无线调试APP的核心基础：在应用内使用Process 对象来执行这些命令。其中start/stop adbd，你可以通过手动开启/关闭调试模式来完成同样的目的。如果希望回到usb 模式，则应该将tcp.port修改回-1。

如果手机没有ROOT 权限

事情并没有因为少一个权限而变得麻烦
首先将手机通过USB连接到PC
在命令行中执行adb tcpip 5555，即可开启无线adb了
想要恢复有线adb时，在保持手机与PC连接的前提下，命令行中执行adb usb即可

连接与断开手机

开启无线adb后，想要通过WIFI连接手机，请先确保电脑和手机在同一网段
连接：adb connect android-device-ip
终止：adb disconnect

进程与线程

2013-11-17T15:57:00+08:00

Android 组件具有天生的跨进程特性，因此，android 应用开发者通常是不需要关注进程概念的。但这也往往导致我们忽视了进程的一些细节问题。这里，就目前的认识做一些小结。

Android 是以进程对用户的重要性为依据来管理进程的。其重要性分为5个层级，重要性越低的进程越容易被系统干掉。

Foreground process
Visible process
Service process
Background process
Empty process

Foreground process

优先级最高，即使在系统内存吃紧的情况下不到万不得已，是不会杀这类进程的。如果这类进程被杀，通常是因为用户界面卡得不能动弹而被迫执行的。这类进程所包含的组件通常满足以下特征：

1.  activity 正在与用户进行交互
2.  service 绑定的activity 正在与用户交互
3.  service 执行了`startForeground()`
4.  service 正在执行生命周期回调函数
5.  BroadcastReceiver 正在执行`onReceived()`

Visible process

优先级次之，系统在保证Foreground process 的前提下，保证这类进程的运行。这类进程虽不直接与用户交互，但用户能在界面上看到与之相关的组件。这些组件通常会有以下特征：

1.  activity 在Paused 状态，处于可视但不可交互的状态
2.  service 绑定的activity 处于paused 状态

Service process

虽然没有与用户直接交互，但它们所做做的事情与用户息息相关。所以系统会按照优先级，在保留上述进程的前提下，尽可能的保留此类进程。不符合上面描述的Service 进程都属于Service Process。

Background process

随时会被系统回收。为了提升用户体验，系统使用LRU 缓存维护这类进程，使得用户最近使用的进程推迟回收。这类进程通常只持有不可视组件，如paused 状态下的activity。

Empty process

这类进程的存在仅仅只是为了让启动进程看起来更快一些，也因此更容易被系统回收。

android:multiprocess 属性

默认情况下，该设置为false，表示该组件会在定义组件的应用进程中运行。当第三方应用调用该组件时，会有2个进程启动：第三方应用以及定义组件的应用。

如果该属性设置为true，表示允许该组件“嫁”出去：当第三方应用调用该组件时，会直接在该进程中构造组件。这么做会让组件在整个系统中的数量增加，但与调用者之间的交互更为紧密。值得一提的是，在实际开发中，这么做需要考虑并发的复杂性。

零散的知识点

一个进程如果包含多个组件，那么，该进程取组件中优先级最高的作为自己的优先级
一个进程的优先级会因为其他进程的依赖而提升
由于service 比后台进程优先级高，一些长时间操作在service 中运行更有安全感
IBinder、 ContentProvider 的方法通常要注意线程安全

参考资料

视图的绘制

2013-11-08T14:48:00+08:00

在《Listview 子控件重复加载》中谈到了onMeasure()方法，谈到了layout，但更细致的内容没有提到。这里找了一下相关资料来补充：

绘制过程是一个控件树遍历的过程，从根控件开始
ViewGroup负责通知它的子视图，View负责自绘，按照顺序，父视图先于子视图绘制
绘制实际上是2个自顶向下的过程：measure 和layout。
经过measure 之后，每个View都会保存自己的尺寸，而在layout 过程中父视图会使用这些尺寸来摆放子视图
View对象的高宽会受到父视图的限制，以保证整个视图的正常显示
父视图会多次调用子视图的measure方法。比如：父视图会先计算不受约束的情况下，子视图的大小；如果子视图过大或者过小，父视图都会指定一个具体的值
Measure 过程还会涉及ViewGroup.LayoutParams以及MeasureSpec的设置
ViewGroup.LayoutParams被View 对象用来告诉其父控件，自己想如何被计算以及摆放，最基本的是指定长宽：
1. MATCH_PARENT, which means the View wants to be as big as its parent (minus padding)
2. WRAP_CONTENT, which means that the View wants to be just big enough to enclose its content (plus padding).
3. 具体数值
MeasureSpec 指定一种计算模式：
1. UNSPECIFIED: This is used by a parent to determine the desired dimension of a child View.
2. EXACTLY: This is used by the parent to impose an exact size on the child.
3. AT MOST: This is used by the parent to impose a maximum size on the child.

参考资料

How Android Draws Views

Listview 子控件重复加载

2013-11-04T20:45:00+08:00

这是一个常见的listview 资源文件的写法。

listview资源文件

    
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:id="@+id/listView"
    />

注意到android:layout_height 被设置为wrap_content，这似乎很合理。但如果我们留心的话可以发现，与这个listview 关联的adapter对象的getView()方法被重复调用了好几遍!这对于那些依赖listview 展示大量数据的应用来说，绝对是性能打击。

解决方案：

将这个属性设置为match_parent 或者固定的数值

原因：

通过分析AbsListView 以及Listview的代码，发现答案应该在onMeasure()方法里：由于wrap_content 并没有指定一个固定值，系统需要通过尝试layout来满足wrap_content。每次尝试都会调用onMeasure(),layoutChildren(),使得getView()被重复调用

Service 心经

2013-11-04T15:21:00+08:00

Service 作为一个“看不见”的android 组件，天然的就应该为Android 程序去处理那些费事费力的苦活。但即使这样，作为四大组件之一的它依然运行在主线程上。也就是说，那些理所当然的“负担”如果直接运行在Service 上必然会影响程序的UI 性能。因此，我们通常需要与之对应的后台线程来完成工作。

与其他组件一样，要想Service 正常运行，就必须在AndroidManifest.xml 中对其进行声明。如果Service 作为一个开放组件（允许外部程序调用），则还需要设置Intent Filter 来支持隐式调用；反之，如果它只在程序内运行，则可省去Filter 设置，更妥当的做法是将export属性设置为false。

总的来说，Service 有两种形式：命令启动类(Started) 与 绑定类(Bound)。两种形式之间并不总是非此既彼的关系，同一个应用的同一个Service 可以同时满足这两种形式，而这一点完全取决于应用逻辑。

命令启动类（started）的Service

一旦被启动，如果没有其他组件调用stopService()而且自己也没有调用stopSelf(int)，那么它将会一直运行下去（除非系统内存吃紧）
onStartCommand()有三类返回值，分别代表Service 在执行完该函数之后，如遭遇系统Kill 的不同策略：
1. START_NOT_STICKY，除非有新的命令，不然不会重新构建Service
2. START_STICKY，不死Service。如果系统资源允许，会重新构建Service并调用startCommand()，但并不会重新传递最后一次发过来的intent。（适用于不care 命令，而care 启没启动的操作，比如恢复音乐播放）
3. START_REDELIVER_INTENT, 对intent 负责到底。在系统资源允许的情况下，重新构建service并将最后一次发送的intent 通过参数传递给startCommand()。（适用于care 命令，比如恢复下载某个文件）
和绑定类服务不同，如果希望得到交互结果，则必须使用Broardcast传递
startCommand() 会有并发的情况，但stopService() 只会执行一次。所以在具体应用场景中，我们需要考虑命令Service们能不能、该不该被中途停止。如果得到的答案是否定的，那么我们应该尝试使用stopSelf(int)来管理service，其参数为希望停止的service ID。

简化的命令服务IntentServie

如果你不希望Service 处理并发请求，那么IntentService 是不二的选择。之所以这么说，是你几乎只需要三步就可以实现一个为你完成后台操作的单线程服务：1，继承IntetnService；2，覆盖onHandleIntent()；3，在构造函数中初始化父类。那么IntentService 会帮你做到： – 创建一个后台线程 – 创建一个消息队列来执行任务 – 当没有任务的时候自动停止

如果希望自己覆盖某些Service 的方法，那么一定要记得调用super，否则会导致一些意想不到的结果出现。

绑定类(Bound)服务

IBinder 表示客户端与服务端交互的接口
三种提供Binder 接口的方法：
1. 直接继承Binder 类，提供API 给客户端调用。这些API 既可以由Binder 子类来实现，也可以通过API 返回该服务或其他服务的实例，由服务本身提供的方法去完成调用；这种方法适用与私有服务。
2. 使用Messenger返回binder。该方法的本质是AIDL，提供了一种线程安全的跨进程通讯方案。这种方法适用于服务与调用组件不在同一个进程的情况。详见参考代码
3. 如果服务不但跨进程，而且还希望处理并发请求，则应该使用AIDL来实现
多个客户端可以绑定同一个服务，但onBind() 只会在第一个客户端绑定的时候被调用。之后绑定的客户端虽然会获得同样的binder，但已经不会再调用onBind()了
四大组件中除了Broardcast Receiver之外都可以绑定服务
onServiceDisconnected()只会在服务崩溃的时候调用，而并不会在unbind 的时候被调用
bind 应与unbind 成对出现，服务与其绑定的客户端组件共存亡。如果交互工作完全结束的话，可以尽早的结束绑定，而不一定要等到组件消亡(比如某浪sso 接口那样)
bind 与unbind 不应该出现在onResume() 以及onPause()里，这样会使得服务的绑定与解绑操作过于频繁
绑定类服务又恰巧被调用了startService()，则只有同时满足以下条件，服务才会终止：1，没有客户端组件绑定该服务；2，服务调用了stopService() 或者stopSelf(int)
如下图所示，只有当unBind()返回true 的时候，下次绑定的时候，系统才会调用onRebind()，否则还会继续调用onBind()
所有对象均为跨进程引用计数
如果服务连接丢失的话，容易引发DeadObjectException

前台服务

前台服务能够极大的提升不被杀掉的概率
前台服务必须有与之对应ON-GONING通知显示
stopForeground()并不会停止服务；而停止服务后，通知自然消亡

AIDL

Stub 继承自Binder 还实现了aidl 中的接口，除此之外还提供类似asInterface(IBinder)的辅助方法
AIDL 接口调用是直接方法调用，不应该想当然的认为它们在哪个线程中执行。如果是本地进程调用，那么接口会和调用者使用同一个线程执行；如果是远程调用，会由服务所在的进程的线程池派发一个线程来执行；如果使用oneway修饰，在远程调用中是非阻塞的，而在本地调用中依然是同步的。
AIDL 支持java 的基础类型、String、Charsequence、List、Map，除此之外的类型，都需要实现Parcebal接口，且必须使用import来声明，即使它们在同一个包
调用不保证会执行，所以从一开始设计的时候就应该考虑线程安全
为了避免ANR，应该将调用转移到单独的线程中执行
抛出的异常不会被调用者捕获（跨进程异常是不可取的）

参考资料

参考代码

Activity 心经

2013-11-03T11:33:00+08:00

Android 四大组件中，Activty 最为常见。这里对Activity 的相关知识进行梳理，以供日后查阅。

生命周期

六种状态构成了生命周期金字塔
位于顶端的Resumed 状态有着与用户交互的特权
金字塔的第二层对于用户来说可视或部分可视
金字塔的第三层虽然存在于系统内存，但对于用户来说不可视
从箭头的指向来看，Resumed 与Paused 之间的转换最为活跃，为了保证UI流畅，这里应尽可能的放一些轻巧的代码
从Activity 对象的角度来讲，只有三种状态持续存在：Resumed，Paused，Stopped
Activity 的Paused 状态对于自身而言是被前台的Activity(或窗口）遮挡了一部分，对于用户来讲这个Activity 只有部分可见。在这种状态下，Activity 对象依然停留在内存里，也同时被windows manager 引用着；Activity 的Stopped状态与Paused 状态类似，除了更彻底的不可见之外，此时此刻这个Activity已经不被windows manager 引用了
当Activity 的Paused 或Stopped状态遭遇系统内存吃紧：系统要么温柔的调用finish() 逐个清理Activity，要么粗暴的结束掉该对象所在的进程

资源管理

鉴于内存吃紧的不可预见，我们应该在onStop()中释放掉那些容易造成内存泄漏的资源

关于onPause()方法更具体的建议

1.  停止动画等消耗CPU 的操作
2.  注销广播监听器、传感器监听器等影响电池寿命的资源
3.  仅当用户需要的情况下，提交未保存的状态。为了保证界面的平滑切换，应避免在这里调用CPU-Intensive 的操作（如，写数据库），而应将其移至之后的stop方法中

onSaveInstanceState()默认的会保存Activity 的视图结构，如Checkbox 是否被选中，Edittext 中的编辑文字，但前提是为每个控件都配备有一个独特的ID
当且仅当有数据需要恢复的时候，onRestoreInstanceState()才被系统调用，且一般在onStart()之后
可以使用finish()以及finishActivity(int requestCode)来关闭Activity，但除非你确定必须这么做，不然最好将这项工作交由系统来完成
一般情况下，如果一个应用退到后台超过30分钟，系统会清理掉该堆栈中的acitivties。但如果android:alwaysRetainTaskState属性被设置为true，用户重返应用的时候总会获得上次Activity的状态。这一点对于浏览器应用相当有用
如果属性android:noHistory被设置为true，那么当用户从这个activity 离开的时候，就会自动调用finish()。因此，无法从任务堆栈中找回该activity 的历史轨迹了
一般来讲，onDestroy() 的执行应该在onPause()或者onStop()之后。但如果，你在onCreate()中直接调用finish()，则系统会直接跳过他们调用onDestroy()的

运行模式

Task 是由一组为了完成某项工作的Activities 组成，它们不受进程或应用的约束，体现的是Activity 之间相互调用和执行的关系
Activity 的运行模式有四种:standard，singleTop，singleTask，singleInstance。除了Standard 之外的三种模式对于activity均有不同程度的复用
standard 与singleTop 类似，在程序运行的过程中，这两种模式的activity 会有多个实例出现在一个或多个Task 中的任意位置。但二者之间有着细微的差别：singleTop 模式下的activty 如果在目标task 的顶部，对于新收到的intent会使用onNewIntent()回调来响应；其他情况下和standard 模式一样，对于每一个新收到的intent 都对应一个新的实例。
singleTask 与singleInstance 类似，都只能出现在一个task stack 内，且始终呆在stack 的根部，对于整个设备来说它们只有一个实例。除此之外，它们都使用onNewIntent() 来响应创建后收到的intent。但两者之间有着细微的差别：singleTask 允许引入新的activity 来组建task，而singleInstance 永远自成一派。很显然，singleInstance适合内存消耗较多的界面，如播放器、浏览器等。

其他

如果项目中没有一个Activity 被设置为MAIN action 或者LAUNCHER category，那么桌面就不会显示相应的图标
程序运行过程中，如遇到配置变动，则会引起activity 重启，这是系统自动适配的行为。
重启后，其数据需要得到重新填充。如果数据量较小，则可以依赖onSaveInstanceState()以及onRestoreInstanceState()这两个回调接口；反之，则需要特殊对待：要么规避系统的重启行为，自己来做适配工作；要么在配置变更的时候通过接口onRetainNonConfigurationInstance()来保存数据对象，待到重启之后使用getLastNonConfigurationInstance()来恢复相关数据

参考资料

廉价的吐槽

2013-04-14T19:44:00+08:00

这几年，你有没有发现“赞美”变成了一件奢侈的事情？尤其当你面对一群挑剔的听众，你的赞美往往会被人扭曲：“你拿了人家什么好处，这样帮他说话？”、“推销？你被洗脑了吧！”、“这你都没见过？有什么好大惊小怪的。”…诸如此类。不晓得从什么时候开始，开口赞美，也变得越来越有压力了。

赞美的起点似乎总比被赞美的事物要低，反而吐槽更容易让你居高临下，优越感一览无遗。不管人家说什么，你跟着去赞美，容易被人说成是拍马，而吐槽的言行至少不会显得你太低端（哈哈，说这是批判精神）。这种不用思考的“安全反应”，使得越来越多的人，习惯了吐槽。当跟风赞美变成弱智、“五毛”之后，跟风吐槽就显得有节操，有品位了。任何事情，你都可以表现得不屑一顾，“安全的”凌驾于其之上。只是，这种廉价的破烂习惯，让我们的社会关系变得越来越冷漠了。

其实，生活中并不缺乏温情的画面，讲一个刚刚发生的故事。昨天晚上，我习惯性的去了趟沃尔玛。轮到我结账的时候，为了不让后面排队的人等太久，我手忙脚乱的把货品往买来的2个袋子里塞。收银员打断了我的动作，说：你这些速冻食品压在最底下，回家的时候肯定就烂掉了。我愣了一下，结果，她很自然的接手了剩下来的操作。只用了一个袋子，就将所有货品麻利的装了进去，还照顾到了各种货品的运输属性（易碎性、温度、空间等），合理的安排了他们在装袋时的位置。很快的，我缓过神来，没有说话，但竖起了大拇指。

同样是排队结账，吐槽就显得太过廉价了。你永远可以调侃中国人多，甚至责怪超市收银出口太少，但绝大多数的情况下，你都无法避免排队等候。而这种廉价的吐槽行为，只会让自己愤怒，说不定还会影响他人，人与人之间就在消费吐槽时，变得淡了下来。