2012已经快尼玛过去半个月了，我终于能腾出手来写点东西了（其实这么说真他妈的矫情，感觉我很忙一样的），其实我真不算忙，因为我每天还能有半个多小时能刷刷腾讯微博，能跟同事蛋逼半个小时，吃中饭晚饭还尼玛要费去俩小时，拉屎睡觉费掉的时间也不少，在虾米上听歌耗掉的时间就更多了，其实每天我大部分的时间都是在搞毛线，只有极少数的时间是全心全意地在工作，工作绝大部分的时间是在写代码。

2011是一个特殊的一年，因为这一年我有了一些角色的小小改变，以前自己一个人写代码，只需要自己搞定自己的事情就OK了，2011年我们的郭英同学加入了Android团队，从完全不熟悉Java到如今能完全独立地完成一个功能，我们的郭英同学进步不算慢，虽然郭英童鞋的代码还有很多不成熟的地方，例如：。。。，还是不要说啦，其实这些问题大家都尼玛有，慢慢地会好的，郭英童鞋，我看好你哦！

2011年，喜讯天天从0.4.0 Beta 到 喜讯天天0.6.2 Beta，画说Android版本从0.1.0 Beta 到 0.2.6 Beta，经历了21个版本的发布，平均一个月1.75个版本，工作强度自然不消说了，因为喜讯天天和画说Android版本0.1.0 Beta到0.1.12 Beta版本我是Android客户端唯一的程序员，郭英的加入确实很大程度上减轻了客户端开发的工作量，这可以算是2011年公司的一大收获，因为郭英童鞋非常非常有自己的想法，而且喜欢钻研东西，不过好像郭英童鞋对于客户端编程不是特别感冒，跟我当年的情况比较相似，对自己目前从事的技术总是不能提起十二分兴趣，对于其他的一些新技术或者对自己来说很新鲜的东西倒是非常非常的感兴趣，关键是郭英童鞋还是个文艺青年，受不鸟啊，技术组经常被他hold住，木有人人能接上话啊，有木有？？？来首古诗尼玛谁能接上啊，有木有？？？

Android开发中碰到了很多的问题，有一些解决了，有一些灭有（这是废话），跟设计一起的合作更顺利了，也开始在推动一些事情了，不过效果不好，可能是自己主动性还不够吧，再接再厉咯。

o(︶︿︶)o 唉，写到这里吧，刘琪，你大爷，赶紧下班回去啦，哥等你等得都犯困了，你妹啊~

您可能也喜欢：
《黄金矿工喜讯特别版》发布了	Android Bitmap内存限制	| 7dot9's Laputa	“狗日的”的腾讯？
无觅

离开校园两年多了，常常会想念校园生活中的点点滴滴，有宿舍的深夜扯淡，有男生扎堆的黄色笑话交流，有窝着看的AV，更有年轻时无所畏惧的强健体魄。成为办公室马铃薯的两年间，自己的产出甚微，在超图待了一年多的时间，正式进入到项目一年，写了一些代码改了一些Bug，算是给SuperMap Objects Java 6R贡献了一些些数据转换模块的代码和自定义控件的代码，至于平时的修修补补工作更是不值一提啦。来到喜讯一年多了，还记得自己是2010年5月18日，正式来喜讯上班，当时我是2010年5月17日从北京超图软件股份有限公司研发中心离职，立马来到喜讯入职。期间没有离职休假，也没有旅行，直接的工作状态切换，非常干脆，看起来就想是移花接木般的直接嫁接。

在喜讯的一年多时间里，经历了几个产品，从《黄金矿工》开始，在《喜讯分享》中跌倒了，在《喜讯天天》中历练，在《画说》中成长，如今依然在《画说》项目中前进，项目中也进来了新的同事，开始能分担一些工作了。伴着自己职业道路的继续，在自己编码素养上的提升是最为明显的，明显得犹如自己日益加粗的水桶腰，明显得犹如自己由每周剧烈运动5小时以上剧减到每周轻微运动时间不足一小时，生活带给你的改变其实还远远不只这些你能看到的。

去年，歪歪的母亲，我们一群人可亲可爱的歪歪伯母检查出有肺癌，当时就几乎击倒了我们一贯坚强的歪歪，不过还好发现得较早，目前已经完全治疗完毕，伯母的身体也渐渐恢复了，只是不似以前那般健朗了，如今歪歪刚刚添了一个千金，明年春节回老家摆喜酒，希望这些喜庆能给我们可亲的伯母带来更多的欢乐，而忘却曾今的病痛吧。

今年年中，听刘琪说起他的一个发小，家中突生变故，父母双方都被查出有重病，父亲更是癌症，母亲的病也需要做脑科大手术才可能完全康复，他的发小还是一个军医，家中境况也才是刚刚才装好，突生变故将全家人打入冷窟，家中的担子差点就要将他压垮，幸好他母亲的手术十分成功，目前应该已经完全康复痊愈，作为一个旁观者，我只能唏嘘感叹和祝福祈愿。

我们的ZZM这两天也在发愁，母亲查出重病需要钱来动手术，家中目前境况又不太好，只好四处借款，我们这些刚刚毕业不久的又穷又苦的大学同学义不容辞地需要伸出自己的手，尼玛能帮多少是多少啦，可怜的我才发现自己从毕业到现在，身上从来都没有一分钱积蓄，总是一年一年光一月一月光，从未给过家中半毛钱，自己依然过得不能算是萧条落魄，但也是将就将就得过且过。如今他人需要，自己却很是无奈的表示自己只能力所能及，“艹，这尼玛就像吃了个苍蝇一样，you know ？”。

看到刘琪、ZZM的QQ签名都提到了健康二字，突然发现自己两年多以来，我们不求物质上有太多的收获，当然也不可能有太多的收获，在职业道路上的成长其实究竟有多大，还待积年之后再回首吧，但是我们失去的其实已经可以看到了。今天去慈铭体检中心体检，最后做了一项彩超，医生告诉我左肾囊肿，当时我也没怎么在意，也不太明白那是个什么概念，也没有主动问一下医生需要做些什么，医生可能看我也比较二逼，竟然不发问，也就做了闷葫芦不说话，完了我就提裤子出来了。回到办公室，发布完版本之后，简单查了一下，发现肾囊肿倒并不是非常严重的问题，心中悬着的石头也就下来了，等体检结果出来之后到时候再去医院确诊一下。

连续的一些事情让我开始意识到自己的健康已经慢慢地在溜走，我热爱生命犹如我每天都要吃的米饭，犹如我每天要呼吸的空气（虽然我痛恨北京的空气），犹如我每天要喝的水（其实北京的水也很难喝啦），我当然热爱我的健康，拥有一个健康的身体对于任何一个人来讲，那都是一件如此令人幸福的事情，要让自己成为一个幸福的人，我想我们是需要一些行动的，可是我们究竟要如何开始行动呢？其实我也不知道，不过既然已经意识到了，那么我想我还是需要想办法来避免这个问题的。身体是自己的，谁都给你挣不来，你可以挣到各种东西，也可以挣到健康，恰当地舍弃一些吧，合适地追求一些吧，健康其实并不讨厌我，我也很爱健康。

您可能也喜欢：
漫谈JNI	Ubuntu下让Air程序TweetDeck成功使用代理发推	LineNumberReader和FileWriter同时使用碰到的问题	Android Bitmap内存限制
无觅

这里讲一个题外话，也就是为何Android要限制每个应用程序的可用内存大小呢？其实这个问题可能有多方面的解答，目前我自己考虑到的有两点：

1. 使得内存的使用更为合理，限制每个应用的可用内存上限，可以防止某些应用程序恶意或者无意使用过多的内存，而导致其他应用无法正常运行，我们众所周知的Android是有多进程的，如果一个进程(也就是一个应用)耗费过多的内存，其他的应用还搞毛呢？当然在这里其实是有一个例外，那就是如果你的应用使用了很多本地代码，在本地代码中创建对象解码图像是不会被计算到的，这是因为你使用本地方法创建的对象或者解码的图像使用的是本地堆的内存，跟系统是平级的，而我们通过Framework调用BitmapFactory.decodeFile()方法解码时，系统虽然也是调用本地代码来进行解码的，但是Android Framework在实现的时候，刻意地将这部分解码使用的内存从堆里面分配了而不是从本地堆里分配的内存，所以才会出现OOM，当然并不是说从本地堆里分配就不会出现OOM，本地堆分配内存超过系统可用内存限制的话，通常都是直接崩溃，什么错误可能都看不到，也许会有一些崩溃的错误字节码之类的。
2. 省电的考虑，呃…，原因我好像也不能很明白地说出来。

回到正题来，我们在应用的设计和开发中可能会经常碰到需要在一个界面上显示数十张图片乃至上百张，当然限于手机屏幕的大小我们通常在设计中会使用类似于列表或者网格的控件来展示，也就是说通常一次需要显示出来图片数还是一个相对确定的数字，通常也不会太大。如果数目比较大的画，通常显示的控件自身尺寸就会比较小，这个时候可以采用缩略图策略。下面我们来看看如果避免出现OOM的错误，这个解决方案参考了Android示范程序XML Adapters中的ImageDownloader.java中的实现，主要是使用了一个二级缓存类似的机制,就是有一个数据结构中直接持有解码成功的Bitmap对象引用，同时使用一个二级缓存数据结构持有解码成功的Bitmap对象的SoftReference对象，由于SoftReference对象的特殊性，系统会在需要内存的时候首先将SoftReference对象持有的对象释放掉，也就是说当VM发现可用内存比较少了需要触发GC的时候，就会优先将二级缓存中的Bitmap回收，而保有一级缓存中的Bitmap对象用于显示。

其实这个解决方案最为关键的一点是使用了一个比较合适的数据结构，那就是LinkedHashMap类型来进行一级缓存Bitmap的容器，由于LinkedHashMap的特殊性，我们可以控制其内部存储对象的个数并且将不再使用的对象从容器中移除，这就给二级缓存提供了可能性，我们可以在一级缓存中一直保存最近被访问到的Bitmap对象，而已经被访问过的图片在LinkedHashMap的容量超过我们预设值时将会把容器中存在时间最长的对象移除，这个时候我们可以将被移除出LinkedHashMap中的对象存放至二级缓存容器中，而二级缓存中对象的管理就交给系统来做了，当系统需要GC时就会首先回收二级缓存容器中的Bitmap对象了。在获取对象的时候先从一级缓存容器中查找，如果有对应对象并可用直接返回，如果没有的话从二级缓存中查找对应的SoftReference对象，判断SoftReference对象持有的Bitmap是否可用，可用直接返回，否则返回空。

主要的代码段如下：

private static final int HARD_CACHE_CAPACITY = 16;

// Hard cache, with a fixed maximum capacity and a life duration
private static final HashMap<String, Bitmap> sHardBitmapCache = new LinkedHashMap<String, Bitmap>(HARD_CACHE_CAPACITY / 2, 0.75f, true) {
    private static final long serialVersionUID = -57738079457331894L;

    @Override
    protected boolean removeEldestEntry(LinkedHashMap.Entry<String, Bitmap> eldest) {
        if (size() > HARD_CACHE_CAPACITY) {
            // Entries push-out of hard reference cache are transferred to soft reference cache
            sSoftBitmapCache.put(eldest.getKey(), new SoftReference<Bitmap>(eldest.getValue()));
            return true;
        } else
            return false;
    }
};

// Soft cache for bitmap kicked out of hard cache
private final static ConcurrentHashMap<String, SoftReference<Bitmap>> sSoftBitmapCache = new ConcurrentHashMap<String, SoftReference<Bitmap>>(HARD_CACHE_CAPACITY / 2);

/**
* @param id
*            The ID of the image that will be retrieved from the cache.
* @return The cached bitmap or null if it was not found.
*/
public Bitmap getBitmap(String id) {
    // First try the hard reference cache
    synchronized (sHardBitmapCache) {
        final Bitmap bitmap = sHardBitmapCache.get(id);
        if (bitmap != null) {
            // Bitmap found in hard cache
            // Move element to first position, so that it is removed last
            sHardBitmapCache.remove(id);
            sHardBitmapCache.put(id, bitmap);
            return bitmap;
        }
    }

    // Then try the soft reference cache
    SoftReference<Bitmap> bitmapReference = sSoftBitmapCache.get(id);
    if (bitmapReference != null) {
        final Bitmap bitmap = bitmapReference.get();
        if (bitmap != null) {
            // Bitmap found in soft cache
            return bitmap;
        } else {
            // Soft reference has been Garbage Collected
            sSoftBitmapCache.remove(id);
        }
    }

    return null;
}

public void putBitmap(String id, Bitmap bitmap) {
    synchronized (sHardBitmapCache) {
        if (sHardBitmapCache != null) {
            sHardBitmapCache.put(id, bitmap);
        }
    }
}

上面这段代码中使用了id来标识一个Bitmap对象，这个可能大家在实际的应用中可以选择不同的方式来索引Bitmap对象，图像的解码在这里就不做赘述了。这里主要讨论的就是如何管理Bitmap对象，使得在实际应用中不要轻易出现OOM错误，其实在这个解决方案中，HARD_CACHE_CAPACITY的值就是一个经验值，而且这个跟每个应用中需要解码的图片的实际大小直接相关，如果图片偏大的话可能这个值还得调小，如果图片本身比较小的话可以适当的调大一些。本解决方案主要讨论的是一种双缓存结合使用SoftReference的机制，通过使用二级缓存和系统对SoftReference对象的回收特性，让系统自动回收不再敏感的图片Bitmap对象，而保有一级缓存也就是敏感的图片Bitmap对象。

通常实际应用中我们会把桌面Widget作为应用的快捷方式和缩略展示，那么通常我们做的事情一般是点击桌面Widget上某控件后，跳转到对应的Activity中，那么我们就需要使用到PendingIntent.getActivity(Context context, int requestCode, Intent intent, int flags)来获取一个PendingIntent实例，通常我们会在Intent中指定我们的目标Activity，并通过putExtra方法来传递一些必要的参数。例如：

Intent intent = new Intent(context, MainActivity.class);

intent.putExtra(“GREETING”,”HelloWorld”);

PendingIntent pendingIntent = PendingIntent.getActivity(context, 0,intent, 0);

remoteViews.setOnClickPendingIntent(R.id.widget_goto_main, pendingIntent);

上面的这个代码呢，主要目的就是能让桌面Widget上的控件响应点击事件，并且能直接进入MainActivity。这里我们将requestCode和flags都设置为0了，目前Android中还没有使用到requestCode来做什么控制，只是预留了这么一个参数方便于未来的扩展，但是Flag能就非常有用了，因为系统会通过Flag来识别需要进行的行为。我么先来看一下官方文档上的一段话：

A PendingIntent itself is simply a reference to a token maintained by the system describing the original data used to retrieve it. This means that, even if its owning application’s process is killed, the PendingIntent itself will remain usable from other processes that have been given it. If the creating application later re-retrieves the same kind of PendingIntent (same operation, same Intent action, data, categories, and components, and same flags), it will receive a PendingIntent representing the same token if that is still valid, and can thus call cancel() to remove it.

我翻译一下：一个PendingIntent就是一个Android系统管理并持有的用于描述和获取原始数据的对象的标志(引用)。这就意味着，即便创建该PendingIntent对象的进程被杀死了，这个PendingItent对象自己在其他进程中还是可用的。如果创建该PendingIntent对象的进程随后又重新获取了一个同类型的PendingIntent（对于程序来讲，就是通过同样的方法获取的，例如都是通过getActivity、getBroadcast、getService方法来获取的，并且传递给getXXX方法的Intent对象的Action是相同的，Data也是相同的，Categories也是相同的，Components也是相同的，Flags也是相同的），如果之前获取的PendingIntent对象还有效的话，那么该进程获取到的PendingItent对象将获得同一个对象的引用，而且可以通过cancel()方法来从系统中移除它。

如果我们只是想通过设置不同的Extra来生成不同的PendingIntent对象是行不通的，因为PendingIntent对象由系统持有，并且系统只通过刚才在上面提到的几个要素来判断PendingIntent对象是否是相同的，那么如果我们想在每次更新Widget的时候也更新PendingIntent对象的话，我们应该怎么做的，目前我能想到的就是通过设置Flag的方式来做。

目前在Android中有以下flag：

FLAG_CANCEL_CURRENT:如果当前系统中已经存在一个相同的PendingIntent对象，那么就将先将已有的PendingIntent取消，然后重新生成一个PendingIntent对象。

FLAG_NO_CREATE:如果当前系统中不存在相同的PendingIntent对象，系统将不会创建该PendingIntent对象而是直接返回null。

FLAG_ONE_SHOT:该PendingIntent只作用一次，如果该PendingIntent对象已经触发过一次，那么下次再获取该PendingIntent并且再触发时，系统将会返回一个SendIntentException，在使用这个标志的时候一定要注意哦。

FLAG_UPDATE_CURRENT:如果系统中已存在该PendingIntent对象，那么系统将保留该PendingIntent对象，但是会使用新的Intent来更新之前PendingIntent中的Intent对象数据，例如更新Intent中的Extras。这个非常有用，例如之前提到的，我们需要在每次更新之后更新Intent中的Extras数据，达到在不同时机传递给MainActivity不同的参数，实现不同的效果。

大概就是这么多了，:-)，其实自己也还是有点晕，以后有工夫了再慢慢补充吧，先做个记录也好！整个四月份都没有发过博客了，在四月份和五月份交接的此时此刻，发布一篇，以做纪念吧，:-)。

过完年回到北京，自己给自己找了个事情做，那就是每天晚上回家睡觉之前一定要在本子上写点什么，不管是什么，闲言碎语各种东西。到现在也写了一个多月了，发现好像绝大部分都是在凌晨3点以后写下的，好像每天的开头都是“今天回得有点晚”，这种现象其实从年前大概11月份已经开始了，持续到现在，几乎每天都是凌晨下班的，绝大部分时间是在一点半以后。创业总是会有一些特殊的时期，如今正处于创业初期的我，需要学习的东西还非常的多，需要去做的事情也是非常的多，项目的进度完全取决于个人成长速度和编码的效率，那种感觉目前还是头一回，不过知道目前位置，感觉还算良好。

其实编码的过程更多的时候并不是非常的顺利和快乐的，其实写程序有点像孕妇怀胎，分娩是痛苦的，之后是很幸福的。代码编写的过程如同怀胎十月，需要做足功课，当然目前我对于怀孕和妊娠这些概念还是比较生疏的，不过大体上我知道整个过程中需要付出很多而且要非常的小心谨慎，其实代码编写的过程中也是如此，只是代码是可以调试的，而生命是容不下调试二字的。在喜讯的这些日子里学习到了很多的东西，在这里有比较宽松的工作环境当然也有非常的压力和机会，一个工作经验尚不足一年的我已经独立承担了两个产品客户端的程序开发工作，目前两个产品有一个早已发布，近期发布了一个《喜讯天天》，工作量不大不小刚刚好，压力稍微有点大，当然这个跟自己经验太少有着直接的关系，其实项目还是很小的，只不过自己暂时还没能完全承担下来。

写着写着，其实我已经不知道我想写些什么了，所谓的迷失的上半夜，其实大体的意思就是我的生活中已经没有了夜晚，只有凌晨归家之后疲惫地迅速入睡，生活相对简单和紧凑。其实我的性格是不大适合如此这般生活的，我对于作息时间有着非常强烈的规律感，可是如今我的生活没有太大的规律，除了每天都是8点半起来的，其他的规律都是浮云。上半夜的迷失伴随了什么呢？我也不知道，创业的懵懂和冲动，对于未来和理想的追求，抑或是对于北京如此这般高压力的畏惧，对于财富的渴望对于技术的迷恋？其实我一向不是一个愿意穷根究底的人，可是最为一个程序员需要拥有这种打破沙锅问到底的精神和性格，至于这些问题的答案，其实也许自己心里很明白，但是不知道如何表达罢了。我想其实每个人都在迷失，有些人迷失在上半夜，有些人迷失在下半夜，甚至有些人迷失在晨阳高升的清晨。生活势必会有各种迷失和纠结，就像我写的这篇文章，我个人就认为写得很NB，虽然我压根儿就不知道这篇文章的中心思想是什么，小学老师时常告诉我们写作文一定要有中心思想，全文的展开一定要围绕中心思想。好吧，我承认我是SB，我TM写的本来就JB跟浮云一样的，为什么需要有JB中心思想啊。

我想大部分的人都曾有过这样的经历，从Google或者百度搜索到某个资源，该资源就是某论坛的某个帖子的附件，要下载的话至少是需要登录用户才可能下载，当然更有甚者还需要回复或者等级达到一定程度。这些论坛中的种种限制姑且不论，不过对于没有账号的用户那么其注册的过程是必不可少的，用户在不断的找寻资源的过程中会在形形色色的各种论坛注册过账号，当然可能很多账号只会使用一次，仅仅是为了下载当时非常需要的那个资源而已。然而注册的流程总是耗时的，而且很多余，到了一定时间，用户到了某个论坛时，都会先试试自己常用的账号是否可能登录，因为他自己根本无法确定自己是否注册过该论坛的账号。

那么使用QQ号呢，我想如今QQ号已经能成为众多企业的直接营销和客服IM工具，更别说个人对QQ号的依赖了，某个人丢失了QQ号就意味着他将会失去大半在网络上的人际网络，也就是说如今的QQ号对于网民来说，类似于如今的PC内存都普遍在128M以上了。使用QQ号直接打通所有论坛登录第一步，绝对只是一个开始。这可能只是Tencent布局的开头，从我个人臆想的角度来看，可能会有一些这样的发展：

1. 使用QQ+Discuz!打造一个中国式的”CloseID”与Google等牵头的”OpenID”形成一种比较可爱的局势，这个在我国绝对不是不可能。
2. QQ用户的Avatar以及各种VIP服务是否可以延伸到Discuz!中来，也就是利用QQ的Avatar可以形成一个中国式的”Gravatar”，解决众多论坛注册之后第一步上传头像这么通用而又繁琐的步骤，利用QQ秀已有的积累和出色的设计完全可以吸引到不少的用户。
3. QQ用户的诸多VIP服务是否可以与论坛互通，例如通过分成等手段，借助Q币这个成熟灵活的支付手段，为论坛高级服务提供支付支持，在论坛之后发展的过程中，这个并不是不可能。特别是从国外Quora近来火爆异常的现象来看,论坛的垂直化和专业化是未来的趋势,更多的论坛可能必须走精品路线,可能以知识消费为主的一些论坛会成为主流，那么消费产生的支付，可以由Tencent来协助站长和用户完成，不需要自行开发和维护这摊子事情。

目前臆测到的内容大概就是这些，不过从长远看来，如果腾讯出手来做这些事情，并不是没有可能做好的，毕竟用户全中国最多的IM用户和论坛用户，实在是不可小觑，而这两拨用户的高度重合更是为其业务的深度挖掘和整合提供了一个非常非常好的切入口，也许将来的某天，我们真的可以看到在本土的应用中，QQ成为了一个基础服务的提供者，而不再是只会在Windows右下方频繁弹窗的IM软件了。

===============================分割线====================================

我非常非常喜欢QQ这款软件，即便我常年都是光着身子跟人聊天，即便是它有不少的广告，即便是它偶尔会弹窗，但是它真的能帮我解决问题，首先聊天不是问题，视频，群通话，远程协助，文件传输，每一个功能我想都是在同类软件中的佼佼者。虽然在Ubuntu下不能体验到PC上QQ客户端那么丰富的功能，不过WebQQ是一个不错的替代者，体验依然可以算是上佳之作了。对于腾讯常年不创新不断复制的言论，我想我不必说什么，在同类产品中如果能找到腾讯的产品，我往往会选择腾讯的，因为设计感相对其他产品会好很多，当然安全类产品我想我是不会选用任何一家国内的产品的，其中包括了没事就帮我们查木马的腾讯的安全产品。

Android中实现动态更改控件尺寸

在android中编写控件，通常我们采用XML格式的Layout文件来进行描述控件的大小和位置。当时某些时候我们还是很有必要在程序运行时更改控件的大小。

例如某些时刻程序执行时，控件关联数据发生改变可能导致控件对数据的呈现不能达到最佳，例如有两个ListView在当前窗体中，ListViewA和ListViewB分别对应两组数据，一组数据对应本月代码提交列表，另一组对应本月Bug修复列表。当两组数据相当之时(即数量相差无几)，保持两个控件高度一致，可能两个ListView都会出现滚动条或者均不出现滚动条。但是当本月代码提交列表条目数远远超出本月Bug修复列表时(本月主要任务是新接口的设计和功能开发，其中包含Bug的开发，-_-!)。如果依然保持两个控件高度一致的话，那么显然对于用户来说是不友好的，此时用户的视觉焦点应该更多的是在代码提交列表，所以可以适当地增大代码提交列表的高度而减小Bug列表的高度。更有可能的设计中就存在选择某个视图的功能，例如切换到Bug列表视图时，需要将Bug列表高度扩展到全屏幕高度等等。

其实主要代码就几行，例如程序中是通过某个响应某个控件的某个事件来完成列表高度改变，例如通过单击某个按钮来改变某个列表的高度：

布局文件如下：

<?xml version=“1.0″ encoding=“utf-8″?>

<LinearLayout xmlns:android=“http://schemas.android.com/apk/res/android”

android:orientation=“vertical” android:layout_width=“fill_parent”

android:layout_height=“fill_parent”>

<Button android:id=“@+id/change_view_size”

android:layout_width=“wrap_content”

android:layout_height=“wrap_content”

android:text=“ChangeSize” android:onClick=“onViewClick” />

<ImageView android:id=“@+id/logo” android:layout_width=“wrap_content”

android:layout_height=“wrap_content” android:src=“@drawable/logo”/>

<ListView android:id=“@+id/network_infos”

android:layout_width=“fill_parent”

android:layout_height=“wrap_content” />

<ListView android:id=“@+id/network_infos2″

android:layout_width=“fill_parent”

android:layout_height=“wrap_content” />

</LinearLayout>

关键代码如下：

public void onViewClick(View view){

// 单击ChangeSize按钮，改变列表高度

if(view == mChangeViewSize){

mNetInfoList.post(new Runnable() {

@Override

public void run() {

LinearLayout.LayoutParams params = new LinearLayout.LayoutParams(LinearLayout.LayoutParams.FILL_PARENT, mNetInfoList.getHeight()/2);

mNetInfoList.setLayoutParams(params);

mNetInfoList.requestLayout();

}

});

}

}

使用线程避免出现ANR异常

Android中经常会出现ANR错误，因为经常性的Android桌面也会出现该问题，该问题主要是因为当前程序在5秒中内未能完成UI事件的响应，Android认为该程序已经进入了无响应状态，Android主动弹出一个提示框，提示用户是继续等待该程序还是将其强制关闭。

我们来看看Google I/O大会上的一个PPT中的分享：

ANRs (“Application Not Responding”)

• ANRs happen when,

– main thread (“event thread” / “UI thread”) doesn’t respond to

input event in 5 seconds,

– a BroadcastReceiver doesn’t finish in 10 seconds

– typically, when

• doing network operations on main thread,

• doing slow ‘disk’ operations (un-optimized SQL) on the main thread

那么防止这些问题的出现，很多时候都是需要使用线程来进行的，特别是连网的操作通常都是耗时的，而且极有可能出现连接超时的错误(国内的网络环境，你懂的)。

还有就是某些有left join 和right join等的SQL查询也是有可能导致耗时过长的，可以尝试着使用AsyncQueryHandler类来实现异步查询。

另外一定要注意在BroadcastReceiver中的onReceive(Context context, Intent intent)方法中的操作时间不能超过10s，否则也可能出现ANR异常，那么如果觉得有可能触碰到临界值时还是选择使用线程吧

PS:之前一直以为Service是在自身独有的线程中执行的，直到最近才明白，其实并不是这样的。我们来看看官方的说明：

A Service is an application component representing either an application’s desire to perform a longer-running operation while not interacting with the user or to supply functionality for other applications to use.

但是接下来的说明才是最重要的：

Note that services, like other application objects, run in the main thread of their hosting process. This means that, if your service is going to do any CPU intensive (such as MP3 playback) or blocking (such as networking) operations, it should spawn its own thread in which to do that work. More information on this can be found in Application Fundamentals: Processes and Threads. The IntentService class is available as a standard implementation of Service that has its own thread where it schedules its work to be done.

这也就是说Service通常都是在主线程中执行的，也就是说我们通常在Service的onCreate()和onStart(Intent intent, int startId)方法中执行的操作如果耗时耗资源，那么就应该另起线程，或者选择IntentService来实现，因为IntentService拥有自己独有的线程来执行其操作。所以还是建议使用Service时一定要注意。

不要在线程内部使用TOAST

在android中，我们通常会使用Toast来通知用户一些信息，例如网络出现异常等等，但是经过实践表明在线程中使用Toast的show()方法似乎是不可行的，因为Toast最终的所有显示操作应该都是处于UI主线程中，如果我们在子线程中做这样的操作，显然是违背了“只在主线程中刷新UI”的原则，不过由于Toast的特殊性，其抛出的异常跟在子线程中改变View控件的异常并不一致，其抛出的异常是你需要在使用handler之前通过Looper.prepare()方法来将当前线程作为一个looper，这显然是不对的。所以在线程中需要作任何UI操作，还是需要通过handler来通知主线程进行操作。

在做Android之前，我做过一年时间的JNI开发，一门原本非常非常偏门的中间件开发技术，在进入之前的公司(SuperMap)之前，我从未接触过JNI开发，虽然在零星地做着一些Java方面的工作，但是均只限于Demo的学习与演练，绝对没有半分实践的经验。进入超图之后，开始学习JNI开发技术，半年之后渐入佳境，日常的开发工作之余开始接触一些业务的东西，也就是说开始接触了一些技术支持方面的工作，偶尔需要到客户的现场处理缺陷或者针对用户的使用场景提出解决方案。当然这么说好像有点大，好吧，我承认有点虚。不过当时山中无老虎，猴子尚且称霸王呢，自己当时也算是团队中的核心开发成员了，所以当时有幸出了一次差，而且有幸坐了第一次飞机，体验了一下空中交通工具的便捷性。还是回到正题吧，在超图工作的重点有两个，一个是编码一个是支持，编码的过程非常简单，流程化很高。接口设计由架构团队讨论决定之后，底层开发团队根据功能需求完成基础接口，然后由Java层面通过JNI技术将底层团队提供的C/C++接口封装起来，当然同时还有.NET团队在做CLR的封装。

JNI封装的工作性质很简单，主要就是与C/C++层面的通信，把一堆基础接口攒成一个可用性高的接口，当然这个工作主要有架构师团队完成设计。编码工作中主要注意的东西有一些，异常判断，数组搬移，野指针等等。SDK作为基础开发平台主要就是模块化，稳定压倒一切。在超图的工作经历，让我对与JNI整个的工作机制以及编码方法有了一个大体的了解，来到喜讯之后，做了第一个游戏——《黄金矿工喜讯特别版》Android版本。编码的过程中逐渐开始熟悉Android的开发方式以及框架结构，在开发过程中碰到了很多的问题，不过所幸最后产品还是成功的出炉了。据说市场反应还不错，因为这作为公司一个磨练团队的产品，目前还没有后续的开发和维护，只是出了一个版本，对于市场反馈也没有做太多的统计，甚至都没有放到Google Market上去，只是在一些国内论坛和第三方市场中做过分享。不过大体了解一些Android中开发的猫腻和技巧，Android由于其开源的特性，有很多东西可以窥探到，在Android Framework中有很多带有// TODO标签的代码段，很多的注释中直接标明“This is a bug”类似的字眼。不过正因为它的开源，很多Framework的机制可以自己一一剥开来慢慢瞧，例如对于图像解码中非常容易出现的OOM错误，顺着代码链，我们可以看到所有的代码，从Java=>JNI=>C，最终可以跟踪到VM创建时堆大小的初始化，详情可以参见我这篇博客。

虽然最终我们看似已经找到了问题，但是究竟如何解决这个问题呢，目前我还没有找到非常好的方法，因为这个受到了Framework的限制，而Framework也没有提供非常好的机制来防止该问题的出现，不过也许可以借助异常的捕获来解决该问题，不过本人自己还未做过该方面的尝试。在做完这个游戏之后，又经历了两个软件项目，项目中自己主要负责的是UI层面的东西，不过主要的设计和UE控制并不由我主要负责，本人主要负责代码实现，主要设计与UE控制由设计师来完成。Android原生的开发环境是Java，按说开发效率是比较高的，当然这个并不是我自己说的，也是从网络上诸多的报告和大牛们的分析中看到的，至于他们为什么得出这个结论我自己并不是非常明了，我自己比较有感触的就是Java相对于C/C++来说，自由度相对要小，不过基础库非常完备，很多的特性均有平台完成，程序员主要负责的就是逻辑和界面的问题，相对来说会较C/C++效率高一些(当然这还是因人而异的)。既然Java开发效率要高一些，那么Android中的开发效率是否会高一些呢？我看不尽然，Android虽然提供Java的开发环境，但是其框架环境非常庞大和复杂，个人认为比Java SE复杂多了很多。Java只是Android开发中的一个敲门砖而已，不过既然已经没有了语言层面上的问题，那么就剩下框架的问题。

然而框架的问题并不是那么的简单，Android是一个在工程实验室中就被推到市场上的项目，当年Andy Rubin创建Android具体是什么时候不是很清楚，不过Andy Rubin还是Danger, Inc.的联合创始人，而Danger在2008年2月份才被Microsoft收购。

The company was originally started by former Apple Inc., WebTV and Philips employees Andy Rubin, Joe Britt, and Matt Hershenson. Danger was acquired by Microsoft on 11 February 2008, for a price rumored to be around $500 million (USD).

由此看来这家公司参与者还有Apple的身影。再来看看Android

In July 2005, Google acquired Android Inc., a small startup company based in Palo Alto, California, USA.^[20] Android’s co-founders who went to work at Google included Andy Rubin (co-founder of Danger),^[21] Rich Miner (co-founder of Wildfire Communications, Inc.),^[22] Nick Sears (once VP at T-Mobile),^[23] and Chris White (headed design and interface development at WebTV).^[24] At the time, little was known about the functions of Android, Inc. other than that they made software for mobile phones.^[20] This began rumors that Google was planning to enter the mobile phone market.

从这两个简介中看来Andy Rubin的经历不能不说是很神奇啊，曾经供职过Apple, Philips，然后是WebTV,Danger，现在是Google，Andy Rubin好像一直都是在做移动设备，在该领域他的经验非常的丰富和恐怖。从Danger和Android的两个简介看来，Andy Rubin在这两个公司之间是有交集的，不只是职务上，在时间上也是有的，Android 05年被Google收购，08年Danger被Microsoft收购。当然我们不管这个了，这只是一个八卦而已。Android存在的问题很多，昨天看了一下在Google Code上的Android Issues列表，目前Open Issues的数量是9257，总共Issues是13851，也就是说Fixed的Issued最多就是4594个，比例是0.331672803，百分比33%，刚刚1/3。当然这跟Android Open是有一定关系的，任何人都可以提交Issue，还有很多的Issue是重复的。不过我还是认为这个是能说明一些问题的，那就是开发者对于Android Framework还不是很满意和放心，当然这其中包括我自己，因为Android中有太多@hide标签的东西以及需要自己去Hack的东西，一个AlertDialog你想自定义其风格，非常的困难，而系统提供的默认UI风格真的非常的一般，从我自己的心眼里来说我非常的不感冒Google原生的UI，我使用的Legend自带的HTC Scense我就认为非常出色，是一个不可多得的UI套件，当然现在市面上已经有了很多很多的UI套件，著名一些的国内UI套件，有点心科技、MIUI等等。这确实说明了大家对Google原生的UI不是很感冒，而且既然你开放，别人能做得比你好干嘛不做啊。

开放带来的问题不只是UI的分裂和多样化，还带来了设备的极大丰富和多样，分辨率的多样和分裂更是成为诸多开发者的噩梦。不过其实也不是那么夸张啦，只是需要很大的精力来做好适配，开发者需要更多的时间来调试，设计者需要为多种设备做考虑。这样的情况下，粗看下来，其实设备更多市场越大，用户越多，开发出来的游戏和应用能更大程度地体现价值，更有可能得到不错的回报。这是一个毫无疑问的肯定句，不过能做到适配多机型的软件并不是非常多，因为这个工作量确实不小，关键是设计的工作量不小。Android开发的难度大不大我想这个因人而异吧，小米团队号称80多天弄出来一个MIUI，那可是非常强大的呢，而我折腾了半年有余，至今未见什么动静。不过我想我碰到的问题每个开发者难免多少都会碰到一些，所谓都在河边走，谁能不湿鞋啊，不湿鞋的那是光着脚走路。

1. Android开发中没有良好的可视化控件开发工具，虽然ADT中有一个简单的XML预览功能，但是确实非常的简陋，不过ADT 8.0.1已经好很多了。
2. Android Framework对于内存有限制，默认一个Activity分配的非Native内存由生产商在VM初始化确定其值为多大，在MDPI的模拟器上是16M，在HDPI的模拟器上是24M。很多开发者都曾碰到过让人头疼讨厌的OOM错误。
3. 多设备和多分辨率带来的问题，虽然说这可以是一个正面的数据，大不了不支持那么多就行了，但是随便支持几个，你都会或多或少地碰到一些问题，这些问题就是因为分辨率的适配，你的Layout甚至可能需要依照分辨率来编写，你的图像资源文件几乎是完全按着分辨率来重新制作的。
4. UI 的不统一型带来的问题，由于某些ROM直接修改了系统默认控件的效果，在很多时候你无法预知你的程序发布出去用户安装之后是一个什么样的运行效果，因为你无法充分测试所有的设备和ROM，如果非得从根本上让应用在所有设备上效果一致，控件需要自己完全重新实现，这个非常的不现实。
5. 用户免费心理对开发者的打击甚大，目前在Android上收费的软件成功的很少，虽然Android号称已经在全球市场上超过了iPhone，但是目前还仍未出现一个公司能通过在Android Market上出售软件实现盈利。遍地开花的破解软件商店，粗制滥造的免费应用充斥着市场等等，无疑让这趟浑水越来越浑了。
6. 版本的错乱导致的特别版本，针对NDK的程序必须在1.6以上的机器上运行，Android几乎是每半年一个大版本，非常有开源社区的风格。每次更新都会带来一些新的特性，那么你能在你的应用中使用吗？我想大多数时候，回答是否定的。市场上的设备很少能及时跟上Android版本更新的速度，为了向下兼容，很多时候我们经常是看着已有的轮子不能用，非得自己重新造轮子。
7. Native开发环境的恶劣，几乎无法调试的开发，让开发者几近发狂。JNI开发的特殊性本来就让挺多人挺头疼的了，目前还没有什么好的开发环境，更是让开发者有苦难言啊。
8. 胜利就在眼前，而你却看不见胜利，多么地令人遗憾啊！
9. 没有第九点。

相对而言，iPhone成功的App Store和优秀的开发环境和稳定的SDK，版本相对稳定，机型更是全球唯一确定的那么几种。Symbian呢，我也不知道说什么，我挺喜欢Nokia的，能做这么好的手机的厂商也就是Nokia了。WP 7会是2011年微软最成功的产品吗？Visual Studio的易用性世人皆知，Windows系统的操作习惯早日深入全世界人民心中，Microsoft又舍得在这上面砸钱。

我想说的是WTF，真混乱，趟浑水究竟要到什么时候啊…

I have a dream, One day there is no mobile device in this world.

2010年同样有很多的第一次，现在开始计数：

1. 第一次离职换工作
2. 第一次换房子搬家
3. 第一次连续两个月加班到12点（甚至以后）
4. 第一次买超过一千块钱的手机，还是个Android手机
5. 第一次更换开发平台
6. 第一次买代理
7. 第一次参加同事的婚礼
8. 第一次开始同一部电影主动看两遍
9. 第一次读库没有追着看
10. 第一次在手机上看电子书，看了很多，古龙的小说看了有十本以上了

2010年同样有很多的遗憾，现在开始计数：

1. 直到现在读库才读到1004
2. 没能还掉09年管同学借的钱
3. 没能给家里寄钱
4. 没能写一个自己用的软件
5. 没能持续写博客
6. 没能持续购书并读书
7. 没能每天按时睡觉
8. 没能每天按时吃饭

2010年比较喜欢的电影有：

月满轩尼诗

教父（1，2，3）重看之后觉得很好

逍遥法外，同上

让子弹飞，很好

动作片依然很喜欢，有不少，不列举了，也记不住

2010年的扯淡就到此结束吧，2010年的收获目前还在积累，有很多，不知道如何说起。