月度归档:2012年02月

读《青春》

book_qingchun

韩寒的新书《青春》出版了,betway官网首页 虽然其中大部分的文章我已经在韩寒的新浪博客上看过了,我还是买了一本。看书,我个人还是倾向于纸质出版物的。网上虽然能够免费获取到,但是每次都要正襟危坐的在电脑前,而且在电脑面前诱惑太多,一会儿看看新闻,一会儿QQ,很难静下心来看书。去年买了一部bambook,就是看中了其功能单一,但问题又来了,免费的资源虽然很多,但是大部分是复制/粘贴而成的,缺少出版中的校对过程,错别字/错句相当多,极度影响阅读的心情。

我个人并非韩寒的粉丝,前几年读过他的成名作《三重门》,betway官网首页 没什么感觉。去年购入bambook后,还在云中书城购买过他的作品《1988 我想和这个世界谈谈》,看了前面几章就没有兴趣再看下去了。后来看了他的博客,觉得写得还是有点意思,才慢慢关注他。这本《青春》就是集结博客上的文章出版的。

封面上的副标题写的有些悲观:“这一代年轻人的希望在哪里?”整本书差不多是对近几年热点事件的一些看法/点评,基调属于那种比较“愤青”的,主题不外乎房价/物价/油价等等。不过与一般“愤青”不同的是,言语比较诙谐,表述有条理,而不是简单的骂娘。当然不管怎么“愤”,这个世界还是这个世界,喷完后,大家该干嘛还是干嘛,只能过过干瘾,对于改变中国的现状没有任何帮助。所以,这本书只是属于消遣一类的,要说有什么思想深度,根本上谈不上。相对于博客,betway官网首页 书中的文章并非按照时间的顺序依次呈现,每篇文章前面都有一段话,算是文章的点睛之笔。

前段时间的方韩舌战也不知道进行的怎样了,我还是宁愿相信这些文章都是韩寒所写的,否则中国真的是让人绝望了。

Android中的硬件加速

本文的主要内容来自SDK文章的"Hardware Acceleration”.

从Android 3.0开始,Android的2D渲染管线可以更好的支持硬件加速。硬件加速使用GPU进行View上的绘制操作。

硬件加速可以在一下四个级别开启或关闭:

  • Application
  • Activity
  • Window
  • View

Application级别

往您的应用程序AndroidManifest.xml文件为application标签添加如下的属性即可为整个应用程序开启硬件加速:

<application android:hardwareAccelerated="true" ...>

Activity级别

您还可以控制每个activity是否开启硬件加速,只需在activity元素中添加android:hardwareAccelerated属性即可办到。比如下面的例子,在application级别开启硬件加速,但在某个activity上关闭硬件加速。

<application android:hardwareAccelerated="true">
    <activity ... />
    <activity android:hardwareAccelerated="false" />
</application>

Window级别

如果您需要更小粒度的控制,可以使用如下代码开启某个window的硬件加速:

getWindow().setFlags(
    WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED,
    WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED);

注:目前还不能在window级别关闭硬件加速。

View级别

您可以在运行时用以下的代码关闭单个view的硬件加速:

myView.setLayerType(View.LAYER_TYPE_SOFTWARE, null);

注:您不能在view级别开启硬件加速

为什么需要这么多级别的控制?

很明显,硬件加速能够带来性能提升,android为什么要弄出这么多级别的控制,而不是默认就是全部硬件加速呢?原因是并非所有的2D绘图操作支持硬件加速,如果您的程序中使用了自定义视图或者绘图调用,程序可能会工作不正常。如果您的程序中只是用了标准的视图和Drawable,放心大胆的开启硬件加速吧!具体是哪些绘图操作不支持硬件加速呢?以下是已知不支持硬件加速的绘图操作:

  • Canvas
    • clipPath()
    • clipRegion()
    • drawPicture()
    • drawPosText()
    • drawTextOnPath()
    • drawVertices()
  • Paint
    • setLinearText()
    • setMaskFilter()
    • setRasterizer()

    另外还有一些绘图操作,开启和不开启硬件加速,效果不一样:

  • Canvas
    • clipRect(): XOR, Difference和ReverseDifference裁剪模式被忽略,3D变换将不会应用在裁剪的矩形上。
    • drawBitmapMesh():colors数组被忽略
    • drawLines():反锯齿不支持
    • setDrawFilter():可以设置,但无效果
  • Paint
    • setDither(): 忽略
    • setFilterBitmap():过滤永远开启
    • setShadowLayer():只能用在文本上
  • ComposeShader
    • ComposeShader只能包含不同类型的shader (比如一个BitmapShader和一个LinearGradient,但不能是两个BitmapShader实例)
    • ComposeShader不能包含ComposeShader

    如果应用程序受到这些影响,您可以在受影响的部分调用setLayerType(View.LAYER_TYPE_SOFTWARE, null),这样在其它地方仍然可以享受硬件加速带来的好处

Android的绘制模型

开启硬件加速后,Android框架将采用新的绘制模型。基于软件的绘制模型和基于硬件的绘制模型有和不同呢?

基于软件的绘制模型

在软件绘制模型下,视图按照如下两个步骤绘制:

1. Invalidate the hierarchy(注:hierarchy怎么翻译?)

2. Draw the hierarchy

应用程序调用invalidate()更新UI的某一部分,失效(invalidation)消息将会在整个视图层中传递,计算每个需要重绘的区域(即脏区域)。然后Android系统将会重绘所有和脏区域有交集的view。很明显,这种绘图模式存在缺点:

1. 每个绘制操作中会执行不必要的代码。比如如果应用程序调用invalidate()重绘button,而button又位于另一个view之上,即使该view没有变化,也会进行重绘。

2. 可能会掩盖一些应用程序的bug。因为android系统会重绘与脏区域有交集的view,所以view的内容可能会在没有调用invalidate()的情况下重绘。这可能会导致一个view依赖于其它view的失效才得到正确的行为。

基于硬件的绘制模型

Android系统仍然使用invalidate()和draw()来绘制view,但在处理绘制上有所不同。Android系统记录绘制命令到显示列表,而不是立即执行绘制命令。另一个优化就是Android系统只需记录和更新标记为脏(通过invalidate())的view。新的绘制模型包含三个步骤:

1. Invalidate the hierarchy

2. 记录和更新显示列表

3. 绘制显示列表

类图:WebKit WebCore到Chrome Browser

在挖掘chromium这座宝藏时,发现官方文档上有一组类图,对了解其框架有所帮助。由于原图有些不清楚,就自己重新绘制了一幅图,要查看原图,点击这里。

WebKit中定义了一些xxxClient,就是将一些用户交互的工作丢给外围实现,webkit只负责排版和渲染。Chromium中则使用了相当多的代理模式。

2012

按照惯例,每年到了年终,都会有一个年终总结。交给公司的年终总结,都有一套模板,写起来也有一定的套路。个人的总结呢,可以随意一点,但是没有上头催,所以一直没有下笔。转眼上班已经两个星期了,还是思考一下2012年该做点什么吧。

去年一年的时间都是做浏览器相关的产品。开始是做一款自主开发引擎的浏览器,其中很多地方借鉴了webkit。想想才几杆枪,就做浏览器引擎,当时的老板决心真够大的。这款浏览器最终做出了,但是只能浏览一些简单的网页。html解析引擎,是按照wml和xhtml的思路做的,先是选择了tinyxml进行html解析。但是现实中网页并没有写得很规范,为了解决这一问题,改用expat进行解析,在其中加入了很多异常处理。但没有超强的容错能力,没有办法从根本上解决问题,最终异常处理越来越多,代码质量也越来越差(补充一点,W3C后来尝试推行xhtml 2.0,但是没有成功,而浏览器的纠错能力越来越强,大家都接受了html的松散语法)。另外排版也是一大问题,我们根据手机的特点,选择了流式布局,对于一般的网页,效果还不错,但碰到网页中有绝对定位就傻眼了。当然最大的软肋是不支持Javascrpit,随着手机性能越来越强,Javascript的重要性越来越高。当时也有想法将Webkit的解析引入,同时加上Javascript支持,终因难度太大,人手不足只得作罢。最后这款浏览器就一直处于半成品状态,主要用途就是用来忽悠客户了。

再后来,离开了这家公司,加入新的公司。新的公司虽然主营业务和浏览器一点关系没有,但设备中需要做浏览器。在新公司里,开始做chromium的定制工作,主要是定制UI,增加遥控器操作的支持等。初次拿到chromium的源码,真是吓坏了,以前看webkit的源码就觉得够恐怖了,而chromium的源码比webkit多得多。不过chromium的代码结构非常好,注释也多。相对于html解析和排版,UI的东东还是简单很多。所以这段时间还是相对轻松很多。不过UI这种东西涉及到用户体验,其实也是相当深奥的一个领域。由于输入设备的限制,最然做了很多工作,最终用户体验还不是很好。进入到测试阶段,在UI上也纠缠了很久,不过最终还是按照设计师的要求改造了很多UI。在这中间,还改造了Android的系统浏览器,没有什么特别之处。也做过一段时间chromium浏览器的clutter移植,后因为有其它的安排,中途停掉了。

总结2011这一年,做了很多事情,但不够专精。不论是浏览器引擎,还是UI,都没有深入。在2012年,希望专注于如下几件事情:

1、掌握一门脚本语言python

在工作中,经常会做一些重复的劳动,总是想着有写一个工具的时间,还不如手工做掉算了。掌握一门脚本语言,编写各种小工具会更快捷一些,就没有借口可找了。

在chromium中,也有大量的python脚本,从系统构建,到自动化测试,用脚本达到出神入化的境界。

2、专注于浏览器的GPU加速

WebKit做得相当好了,V8也一直提速,但自己还没有那个实力去做Javascript提速。只有在GPU加速渲染方面还有潜力可挖,当然也不会那么容易,所以要坚持。

3、掌握chromium架构

chromium真的可以看作软件架构设计的典范,值得学习的东西很多,重点学习chromium的多进程模型,UI框架。

加油,2012。

(BTW,经常会觉得时间不够用,后来在网上看到一张图,明白原来大部分时间用到无意义的上网上了,和大家分享一下,具体出处已经忘记了,见谅)

time_wasted

Google推出Android版Chrome移动浏览器

Google的开发速度还真是快,去年宣布要将chrome移植到Android,昨天就宣布推出Android版chrome。目前还是beta版,在Google Android Market上可以下载,只适用于Android 4.0的手机和平板。先看看Market上的介绍:

简洁快速的Chrome,现在也可以用在你的手机和平板上了。

特点:

  • 加速的页面加载、翻页和缩放,使得浏览网页速度更加快速
  • 地址栏中直接搜索或网址浏览
  • 新开标签页和标签页切换更加快捷直观
  • chrome书签同步
  • 只需一次点击就可以从桌面Chrome将网页发送到智能手机或平板上,供离线阅读
  • 私密模式浏览 下载链接:Chrome for Android beta,cnbeta上也有一篇介绍文章。

悲催的是,现在有几个手机和平台是Android 4.0的系统呢?要想享用Android版本Chrome,首先扔掉你的手机吧。而且现在也只在American Market上发布,国内的用户还不能立刻享用(不过这也难不倒国人,网上很多下载攻略)。

前段时间一直在关注Chrome for Android的移植进展,在chromium source中也陆陆续续的看到一些Android代码和编译脚本,主要是一些测试脚本,并不是一个完整的chromium浏览器。从chromium trunk最新的代码上看,也没有完整的for android代码,不过最新的build指导已经有Android下chromium的编译指导了。

非常遗憾的是,根据Android下chromium的编译指导只能build一些单元测试用例,完整的浏览器代码还没有公布,不过官方有这样一段话:New capabilities added for Chrome for Android will be open sourced in phases,即分阶段开源。

参考:

1. 根儿正苗儿红的 Chrome for Android 发布,但只支持 4.0 ICS 系统

2. 关于 Chrome for Android 你必须知道的 N 件事儿

3. 如何用 Chrome for Android 做远程遥控 debugging

4. 【持续更新】Chrome for Android Beta 上手初体验

5. Google Code上的Google Chrome for Android