分类目录归档:点点滴滴

点点滴滴便是点点和滴滴是也

2011 年不完全回顾

2011 年是史无前例的一年,也是全然新鲜的一年,史上没有哪一年跟 2011 年一般,因为历史上只会有一个 2011 年,我这一辈子中也只有一个 2011 年,所以我对每年的态度都是一样的,当你们在我死命地拽着你的尾巴的时候,你毅然决然地离开了我,我当然还会是以前那句话“2011,我草你大爷的,我他妈真怀念你”。

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 唉,写到这里吧,刘琪,你大爷,赶紧下班回去啦,哥等你等得都犯困了,你妹啊~

健康,别走

曾几何时,我也曾挥洒泪水在湘江之畔岳麓山下中南大学的塑胶绿茵场,场场满场跑(其实我只是一个后卫啦)得气喘吁吁,大汗淋漓得如此痛快,青春已经渐渐褪去,生活的担子慢慢地沉重了起来,生活尼玛才不管你丫的有木有做好承担的准备,你丫能不能接住,Who care ?

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

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

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

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

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

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

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

迷失的上半夜

博客好像已经有很长很长一段时间都没有再做过更新了,至于为什么我想完全没有必要说过来说过去,就是没有更新咯,反正这个地方就是我自己的,我想什么时候更新就什么时候更新咯,什么时候写不出来或者不想写,又或者写出来了又删掉了,这也没有什么问题,反正千金难买我乐意。

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

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

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

近期 Android 开发经验积累

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

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

例如某些时刻程序执行时,控件关联数据发生改变可能导致控件对数据的呈现不能达到最佳,例如有两个 ListView 在当前窗体中,ListViewAListViewB 分别对应两组数据,一组数据对应本月代码提交列表,另一组对应本月 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 通常都是在主线程中执行的,也就是说我们通常在 ServiceonCreate()onStart(Intent intent, int startId) 方法中执行的操作如果耗时耗资源,那么就应该另起线程,或者选择 IntentService 来实现,因为 IntentService 拥有自己独有的线程来执行其操作。所以还是建议使用 Service 时一定要注意。

不要在线程内部使用 TOAST

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