Day Day Up

Google I/O 2013笔记

以下视频都可以在Google I/O官网上找到

重点推荐 - Web相关

• Instant Mobile Websites Techniques and Best Practices，移动Web性能优化的最佳实践
• Mobile HTML: The Future of Your Sites，移动Web开发需要注意的问题
• Web Page Design with the GPU in Mind，Chrome渲染的入门介绍
• Jank Free Chrome Rendering Performance，渲染性能优化的原理及工具
• Chrome DevTools Revolutions 2013，Chrome调试工具的新功能介绍
• Point, Click, Tap, Touch - Building Multi-Device Web Interfaces，触屏事件需要注意的地方
• Mobile Performance from the Radio Up Battery, Latency and Bandwidth Optimization，2G/3G/4G网络底层原理及注意事项

重点推荐 - Android相关

• Volley Easy, Fast Networking for Android，新的官方http库
• Android Graphics Performance，渲染性能优化工具
• What's New in Android Developer Tools / The New Android SDK Build System ，新的开发和编译工具
• Enchant, Simplify, Amaze Android's Design Principles，优秀用户体验的设计原则

各个Sessions

以下是我看过后做的笔记，可以通过它了解每个视频的要点

A Trip Down Memory Lane with Gmail and DevTools

• 介绍了V8中的GC机制
• GMail通过线上选取了一个用户来跟踪分析内存使用和延迟
• GMail的监控会通过用户使用时间来分维度，这样后面优化的收益就可以区分段时间使用的用户和长时间使用的用户，对于长时间使用的用户收益会更明显
• Chrome 22中默认开启了window.performance.memory，可以获得内存使用情况
• 使用Chrome中的Timeline - Memory发现有内存泄露
• 使用Profiles中新增的Track Allocations来根据时间线找内存泄露的元素（目前只有在Canary版本中才有）

整体感觉：随着WebApps的流行，内存监控越来越重要了，后续需要关注

Accelerating Oz with V8 Follow the Yellow Brick Road to JavaScript Performance

• 演示了一下Find Your Way To Oz，页面效果真nb，不过遇到了性能问题
• 一般网站有20%-40%的时间花在V8上（表示怀疑）
• 介绍V8中的GC，和Gmail那个介绍用的是同样的ppt内容
• 介绍V8中的运行时优化机制
• 改变对象内容也可能导致性能问题
• 使用Chrome --no-sandbox --js-flags="--prof --noprof-lazy --log-timer-events" + V8中的plot-timer-events，发现了很多代码并没有很好地优化
• 然后使用mac-tick-processor来分析代码细节性能瓶颈
• 然后使用Chrome --no-sandbox --js-flags="--trace-deopt --trace-opt-verbose"，找到disabled optimization，发现原因是for in代码目前V8不能很好地优化，于是将for in中的代码放到另一个函数中，问题解决

整体感觉：举的这个例子有点特殊，其实是V8编译优化缺陷的问题，在大部分项目中这一般不会是瓶颈，而且要定位和解决必须对V8的实现很了解，不过对于了解V8还是有些帮助

Instant Mobile Websites Techniques and Best Practices

• 将Wikipedia页面加载从5秒优化到2秒了，使用的分析工具是WebPagetest
• 引用The impact of HTML delay on mobile business metrics报告中的数据来说明性能的重要性
• 4个应对mobile高延迟的对策：避免跳转、减少server处理时间、避免阻塞render的资源、优先考虑展现的内容
• 跳转m.xx.com会导致1.2秒延迟
• 介绍了一下浏览器的渲染过程，css和js对渲染的影响
• 避免head中的外链css和js，css内嵌、js后移
• 将css中的背景图内嵌虽然可以避免一次请求，但由于TCP的slow start机制，congestion window初始只有14k，太大的内嵌css会导致页面空白
• 演示了去掉跳转后展现速度提升了1.2秒
• 居然使用New Relic的服务来演示了监控server响应性能
• 将初始展现的HTML和CSS首先展现，后续延迟加载

整体感觉：由于高延迟，mobile web的性能优化比pc要细致得多，优化和不优化的区别会很大

Jank Free Chrome Rendering Performance

• 介绍了Chrome中的render过程
• 使用Dev tools中的Show paint rectangles来展现哪些区域渲染了
• 如果只是scroll性能会很好，因为不需要repaint，重新生成图片，只需要gpu composite（把layer当成texture来渲染）
• 但有repaint就慢了，因为要cpu算，举了一个有hover的例子来说明repaint导致卡的问题
• 通过例子说明了使用css translate3D性能更好
• 介绍了tracing工具新增的功能，能直接看到layer来分析，了解layer的生成原因和gpu内存使用，很强大
• 弄了一个汇总渲染流畅度相关资料的网站http://jankfree.org/

整体感觉：通过Chrome的开发者工具可以用来发现界面卡的原因，前端工程师应该多了解和使用它

Point, Click, Tap, Touch - Building Multi-Device Web Interfaces

• 判断设备支持touch就只用touch会有问题，因为像Chrome pixel这样的设备同时支持触屏和鼠标，如果这样判断会导致体验不好，必须要触屏操作，建议两个都监听，然后使用preventDefault来避免多次执行
• 如果DOM节点会被删除，需要在touchstart时绑定相应的事件
• Chrome后续不会引入内部手势api，建议使用hammer
• 移动设备的click事件会有延迟（为了支持double tap），建议使用fastclick
• touchmove事件发生很频繁，会比屏幕刷新率快，通过监听touchmove它来操作会有性能问题，比较好的方法是将这个操作解耦，然后通过requestAnimationFrame来更新界面
• touch handler会导致滚动的性能问题，尤其是在document上监听
• pointer事件统一了鼠标和触屏事件，可以简化开发，目前只有IE支持，但可以通过hanjs.codeplex.com等库来让其它浏览器部分支持

整体感觉：触屏有很多细节问题，相关开发人员最好都有所了解

Volley Easy, Fast Networking for Android

• 介绍了使用原生库请求数据的各种问题，冗余代码多、要背景执行、自己做cache、解析json等
• 在2.2之前，HttpURLConnection有bug，而Apache的HTTP client目前不维护了，Volley封装了这两种情况，使得对不同版本都能很好地支持
• Volley提供了很友好的api，可以设置优先级、retry、cache，并提供了ImageView的替代来方便展现图片等
• 在开发时可以使用adb shell setprop log.tag.Volley VERBOSE来查看更详细信息
• 图片解码的并行数设置为cpu的core数（因为这是cpu bound操作嘛）
• 请求被cancel后，操作不会传递，这样就没必要检查getActivity()为null了，避免了之前容易crash的问题
• Volley在benchmark上全面超过其它库

整体感觉：非常好的库，而且现在就可以直接使用了，推荐用来替换现有的http库

Android Graphics Performance

• 这次主要讲后续打算弄的东东
• reording可以将解码中的元素渲染顺序打乱，这样就可以先画一批bitmap，然后再画一批text，这么做的gpu性能会更好，因为减少了状态切换
• merging可以将一批bitmap或text合并起来，这样就能一次画出来
• 在实例中，原先的8个gpu命令可以减小到3个，从而提升了渲染性能
• 使用PerfHUD ES来调试
• 多线程rendering
• 4.2可以开启GPU overdraw来看是否有区域被重复绘制了
• 4.1可以使用adb shell dumpsys gfxinfo来分析应用最近120帧的性能情况
• 现在可以直接在设备上通过Profile GPU rendering来开启实时显示，方便调试
• 4.2中可以在设备上开启OpenGL的Systrace来查看OpenGL的命令调研
• 后续版将提供android.os.Trace来监控性能，它最大的好处是不会影响应用的性能，结果很精确，不过需要通过systrace.py -a来开启
• demo介绍了如何发现和去掉不必要的重复绘制来提高性能
• 对于缩小50%以上的图片，在4.2中可以通过setHasMipMap来获得更好的显示效果
• 介绍了几个canvas中提高性能的技巧，比如直接通过合成颜色来避免适应弄个alpha
• 4.1中的imageView可以用setImageAlpha取代setAlpha来提高性能
• 如果各个view间不相互覆盖，在4.1中可以通过设置hasOverLappingRendering为false来提高性能
• canvas中由于cpu和gpu渲染不同会导致些细节问题

整体感觉：后续在设备上调试将会越来越方便，了解底层渲染机制对性能优化很有帮助

High Performance Applications with RenderScript

• GPU浮点计算速度明显超过CPU，10-15倍，内存速度也是4倍
• 但在PC上，需要从CPU的内存拷贝到GPU的内存中，而PCI总线的速度只有12G，小于CPU内存(DDR3)的50G和GPU内存(GDDR5)200G
• 在Mobile上的情况则不一样，因为内存是共享的，GPU浮点计算速度也只CPU的3倍多
• 在Mobile上有用于相机的ISP(Image Signal Processor)和其它专用的DSP
• RenderScript可以跨不同设备，提供高性能计算的支持，具体计算设备是动态指定的
• RenderScript发布时使用的是bitcode(LLVM)，运行时编译
• RenderScript中的内容会自动创建相应的Java类来方便调用
• 使用Script Group性能更好，后续也是RenderScript的优化重点（比如将任务分散到CPU和GPU上）
• 下一版的新Feature
  • 提供Compatibility Library来兼容2.3，是通过编译成native library的方式，但不支持gpu
  • rsSetElementAt
  • 运行时Debug的支持
  • 更多内置方法
  • YUV和性能优化

整体感觉：下一版RenderScript看起来靠谱些了，不过使用场景有限（主要是图片处理），而且不能跨iOS，不如NDK灵活

Web Components in Action

• 介绍了Polymer，通过模拟来让大多数浏览器支持Web Components
• 内建了g-ratings等组件
• 居然还有一个builder

整体感觉：HTML/CSS/JS的相互独立使得之前Web组件化都很难通用，Web Components是一个不错的参数，而Polymer能让更多浏览器支持，但目前比较适合内部应用和原型开发，线上应用短期内不可能

Web Languages and VMs Fast Code is Always in Fashion

• 介绍JS引擎中的编译和GC，不过是从很高的角度概况介绍
• 开始推广Dart，为什么它会比JavaScript快
• DOM对象是基于引用计数的（浏览器实现一般用c++），而JS对象是traced的，它们间的相互引用会导致内存泄露问题，因为跨两个区域了
• 于是在Blink中打算将DOM对象也纳入进来了（我想应该是打算用JS实现DOM）
• 介绍了Dart对SIMD的支持，并演示了完全基于Dart的3D渲染（非WebGL），效果很流畅
• 问答中有亮点，GWT用户的吐槽了被无视了，哈哈哈，果然GWT被无情抛弃；Lars Bak又吐槽了一下开发者对太关注语言，其它浏览器不会接受Dart

整体感觉：将DOM整合进来将很好解决现在Web的内存泄露问题，从后续发展来看Blink的性能会将比WebKit好很多，需要多关注它

Web Page Design with the GPU in Mind

• 在cpu渲染下，当滚动时chrome采取内存拷贝的方法来更新区域
• cpu完成渲染后，将内容分割成一个个tiling作为texture传到gpu中
• 离可视区域太远的tiling会被清除，减少gpu的内存占用
• 如果有动画时，会导致区域repaint影响性能，所以引入了layer机制
• canvas、video、插件及有css 3d transform属性的元素都会有自己单独的layer
• 在动画开始时会创建新的layer，结束后就销毁
• 太多layer会导致内存消耗，因为这意味着要创建更多的tile
• 目前chrome在android、windows、chrome os中composite移到了新的线程，让页面更流畅
• 监听和处理touch事件会导致性能问题（比如iScroll），最好用position:fixed

整体感觉：不错的chrome gup渲染入门介绍，介绍了很多细节点

Google I/O 2013 - Stunning Mobile Visualization with CSS Filters

• Adboe的工程师介绍了运用CSS中的Filter、Regions、Exclusions等来构建杂志级别的排版效果
• CSS custom filters可以使用GLSL来渲染DOM元素，nb啊
• 演示了用phonegap打包运行在nexus 10上的效果（奇怪，android自带的webview现在应该还不支持这些功能的，难道是4.2改进了？待查）

整体感觉：custom filters以后要多加关注，可以做的效果太丰富了，几乎无限可能

WebM and the New VP9 Open Video Codec

• 对比了VP9和H264的效果，VP9效果超过H264很明显
• YouTube新上传的视频中720p以上的已经占一半了
• 在HD画质下V9的带宽需求只有H264的一半
• 介绍了一下VP9的技术实现，感觉和H265的想法很类似
• 介绍了VP9的后续计划，包括实时视频的支持

整体感觉：VP9明显比H264好，和H265应该是同一级别的，但在这里没做对比，所以VP9估计比H265差些，但已经很不错了，对于改善YouTube还是挺有帮助的

Introduction to Portable Native Client (PNaCl)

• 通过meta来通知浏览器加载native client文件
• 目前只有Web store中才默认开启
• PNacI只需要一个pexe文件（其实是LLVM的bytecode），加载时需要动态编译（有cache机制）
• 目前在Chrome 29中可以通过flag开启
• 插件目前只支持PPAPI方式
• Box2D在开启O2优化后性能是原生的85%

整体感觉：但最近Emscripten在使用asm.js后性能可以在C的50%，随着JS引擎的进一步优化，将会使得Native Client的性能优势进一步减小，加上它不知何时才能默认开启（即便开启其它浏览器也不会支持），PNaCl后续前景并不看好

Mobile HTML: The Future of Your Sites

• 主要介绍@media和@viewport
• flexbox
• position:sticky，类似fixed，只在parent在可视区域时出现，方便做一些效果，但目前浏览器支持比较少
• 监听用户移动可以使用navigator.geolocation.watchPosition
• online和offline事件
• Android下可以调用native app的Intents
• 全屏支持
• WebRTC、Web Audio、WebGL居然Android上都支持了

整体感觉：介绍了很多移动web开发基础及需要注意的问题，对入门很有帮助，才发现原来android上的chrome进步这么快，很多之前不支持的都支持了，看来以后得多关注了

Chrome DevTools Revolutions 2013

• 在DevTools中修改css可以直接写到本地，这样就不需要像以前那样拷贝粘贴了
• 支持Sass，可以直接跳转到对应的源码
• 将提供Chrome扩展来启动adb，这样android chrome的调试用起来就像iOS的Safari那样方便 了
• 提供了Prot Forwarding来让手机的localhost指向本机（在手机上直接输入本机ip不就行了？）
• CPU Profile中可以在左下角可以切换到Flame Chart上看JS函数调用的timeline
• 新的Canvas Profile 工具，可以看canvas绘图调用的细节（感觉就是把WebGL Inspector整合进来了）
• Continuous repaint mode，调试paint性能用
• FPS meter & memory consumption，在移动端GPU内存需要多关注
• paint的分析工具，在Jank free中已经介绍了
• 内存申请分析工具，在GMail中已经介绍了
• Layout细节分析，可以了解layout是什么引起的，还有Forced synchronous layout的提示

整体感觉：DevTools越来越强大了，很多功能鲜为人知，掌握好后对开发和性能调试都很有帮助

Dart HTML of the Future, Today!

• 方便的异步语法糖、参数语法糖、匿名函数语法糖
• 有类型所以IDE提示精确，开发起来方便
• 内建了一些类似jQuery中的api来方便开发
• 内建对浏览器兼容性问题的解决
• 内建模板机制（基于Web Components标准）

整体感觉：Dart比GWT靠谱得多，而且目前的发展思路很正确，可以说是现在Web组件化开发最优雅的方案，内部应用可以考虑使用

WebP Deploying Faster, Smaller, and More Beautiful Images

• 最新版本已经加上color profile和动画了，意味着它能同时取代png、jpg和gif
• 后续还打算弄更多，更好的arm支持、大于8位的色深、3D等
• 但目前编码速度比JPEG慢5-10倍，解码速度慢1.3倍
• JS可以通过使用Modernizr库检测，server端可通过header判断
• 用PageSpeed可以自动转换和适配
• 图片链接分享问题可以通过server端判断解决；用户另存为问题Chrome会解决（存成jpg？png？）
• Google内部产品大量使用了，Google+在Android上使用节省了50%的带宽
• 有个网站大量使用png图片，居然加载要86MB，使用WebP优化后只要28MB
• iOS上也有库支持

整体感觉：WebP的出现还是带来了很多新气象，由于浏览器支持问题使得在Web上用得不多，发展缓慢，但在移动客户端上将是很好的选择

Enchant, Simplify, Amaze Android's Design Principles

• Keep it brief
• Pictures are faster than words
• Decide for me but let me have the final say
• Only show what I need when I need it
• I should always know where I am
• Never lose my stuff
• If it looks the same, it should act the same
• Only interrupt me if it's important
• Give me tricks that work every where
• It's not my fault
• Sprinkle encouragement
• Do the heavy lifting for me
• Make important things fast

整体感觉：非常好的设计原则整理，需要多review

Mobile Performance from the Radio Up Battery, Latency and Bandwidth Optimization

• WiFi是从LAN扩展出来的，它传输数据是独占的，所以需要等待然后重试，这就是为什么很多人聚集的地方WiFi很差
• WiFI的光谱(spectrum)共享，这导致WiFi集中的地方性能变差，如果使用5 GHz的新路由因为周围人用得少将获得明显性能提示
• 对于实时通信，使用WebRTC会是更好的选择
• 2G、3G和4G的设计和WiFi完全不同，因为要考虑很多人共享及耗电问题
• 于是它们选择了Radio Resource Controller机制，由接入来控制数据传输
• 在3G下等待接入调度的延迟最高可达2.5 s，而在4G下减小到了100 ms
• 4G每次启动连接的总延迟可达150 ms，由于耗电（是屏幕在之后的第二大耗电部件），所以它会不活动的几百毫秒后进入半睡眠状态，下次连接时会有50 ms的延迟，而不活动10秒后就会进入睡眠状态（具体看图会清晰些）
• 加上DNS、TCP、TLS等时间，在3G下的网络延迟可达600 - 3500 ms，在4G下为240 - 500 ms
• 由于这些延迟问题，在移动下的设计需要多注意，采用异步、操作及时反馈都是很重要的，这样能让用户感觉快
• 开启信号时就会耗电，即便在没有传输任何数据的时候，所以间歇性传输数据会很耗电
• 引用了一篇文章"A Call for More Energy-Efficient Apps"中的研究，发现如果每分钟连一次网络，每小时就要耗掉3%的电。Pandora的app会定期传输用户行为监控数据，这是非常耗电的，更好的方法是在用户下载歌的同时就传输
• AT&T有个监控app能分析系统的耗电情况（ARO）
• 省电的方法：预读取、避免poll、采用push、合并请求
• 传输需要经过Serving gateway和packet gateway，关掉信号其实并没有断开TCP链接，所以没必要定期连接
• 4G的RTT可以媲美WiFi，但即便是美国，4G预计也要到10年才能全面取代3G
• 对于Beacon请求（一般用来监控），W3C正在指定规范来让浏览器优化，减少耗电

整体感觉：很实用的移动网络底层介绍，移动开发工程师都最好能了解，很多地方和PC不一样

Real-time communication with WebRTC

• 随着Firefox的支持，很快WebRTC就能支持10亿用户了（就差IE和Safari）
• 通过调用摄像头和话筒可以做出很有意思的应用
• 还可以屏幕共享
• 支持P2P连接，除了视频音频，还可以传输数据，实现共享文件功能
• 通过STUN和TURN服务来穿透NAT
• 演示了使用phono来通过JS打电话

整体感觉：看起来WebRTC快成熟了，很多之前Web做不了的事情都可以通过它来实现

Taking Advantage of Android Platform Features

• 使用fragment来模块化界面，Gmail通过它来支持Phone和Tablet
• 使用Google Cloud Message，而不是poll
• 背景操作使用IntentService
• NotificationCompat加上Action可以方便使用
• 大文件下载使用DownloadManager
• 备份使用BackupAgentHelper

Seeing the World Through High DPI

• viewport的with使用device-width
• 在css中用dppx等屏幕大小判断来支持高分屏，js中使用window.devicePixelRatio（ie不支持）
• 浏览器已经支持sub-pixel渲染，但1像素仍然是css可控的最小单位
• 在移动浏览器中会文本会采用不同的布局算法，可以在css中使用text-size-adjust来调整
• 矢量图天然支持High DPI
• 背景图记得设置background-size
• 很多2x大小的jpg在30%质量下的效果居然还比1x在90%下要好，而且体积也比1x小
• 在CSS4中可以通过image-set来方便区分高分屏
• 对哦，还有canvas、favicon也要记得修改

整体感觉：支持High DPI将会越来越重要，但又要引入很多工作量了，对后续的Web开发是不小的挑战

A More Awesome Web Features You've Always Wanted

• 新的CSS单位vm、vh，基于viewport计算
• Intrinsic sizing，根据内容来指定高宽
• chromestatus.com
• 使用@supports和window.CSS.supports来做feature detection
• sticky，前面提到了
• http://www.chromestatus.com/features
• clip-path，可以用任何shape来裁剪
• WebRTC的几个api
• SpeechRecognition api，演示了一下使用它来实现类似Siri的人机交互效果

整体感觉：最新W3C出了很多新api，需要多关注

Fireside Chat with the Chrome Team

• Blink要弄Lazy Block layout
• Chromium的Android WebView正在开发中
• Mozilla的工程师想要Chrome的Crash数据，但被拒绝了，因为Crash数据可能会有url、表单提交等敏感数据，而且可能会是安全隐患导致的
• 原来Chrome的插件有同步api，这样就能同步插件中的数据了
• 64位还在开发中，由于扩展的问题导致进展不快

其它

• Standardizing Payments on the Web Introducing requestAutocomplete()
  • Chrome和Chrome for Android中都支持了，可以方便自动填写信用卡信息
• Device Agnostic Development
  • 如果看过前面的，这个可以不用看了
• True Grit Debugging CSS and Render Performance
  • 比较入门，介绍了render、layout和composite的过程
• Secrets of Video Stabilization on YouTube
  • YouTube越来越强大了，这个技术几乎完美解决了手持设备抖动的问题，非常好的想法
• Designing Products for a Multi-screen World The YouTube Perspective
  • 原来是通过卡片式设计来解决不同屏幕大小的问题
• What's New in Android Developer Tools
  • 演示了很多细节功能，好多这些IDEA快捷功能之前都没用过，学了不少
• Project Ground Truth Accurate Maps Via Algorithms and Elbow Grease
  • 介绍了Google Map中的数据校对内部工具，可以很方便查看和调整，抽取出道路中的标志，真nb。。。
• The Modern Workflow for Developing the Mobile Web
  • 介绍了移动Web开发的常用工具，比较入门
• The New Android SDK Build System
  • 介绍新的编译工具Gradle使用方法
• A Moving Experience
  • 在Android中如何实现动画效果