QCon 参会笔记

字数统计: 3.4k阅读时长: 11 min

 2015/04/24 

前言

这两天在北京国际会议中心，QCon 全球软件开发大会正如期举行，我有幸参加了此次会议。QCon 此次参会的人数远远超过了主办方的预期，以至于提前关闭了报名通道。大会现场很多演讲人员爆满，现场周围都站满了人。

在会议上，我不但听了很多感兴趣的演讲，还见到了很多在网上多次交流，但从未谋面的好朋友，也认识了很多新朋友。这次交流对我来说收获挺多，在此总结一下。

和 gaosboy 聊天

gaosboy 是 SegmentFault 的联合创始人，现在在天猫。他在天猫工作两年了，在做 iOS 基础架构方面的事情。我和他之前在网上交流多次，也是由于他的引荐，我才加入了 InfoQ 的编辑团队。我和他交流了一些团队发展的问题，以及 iOS 的一些技术细节。

关于应用架构和开发方式

关于应用开发，天猫是将产品划分成很多组，每个小组的功能做完通过测试后，再 merge 到发布分支，发布分支要发布前，再进行一次集成测试，就可以上线了。这样可以各组之间不必完全同步进行开发，做完的就可以上线，没做完的小组顶多是赶不上某些上线，不会影响别的组的工作。

天猫也做了很多方便后台定制客户端的工作，例如用 JSON 来定制界面，又如将 UI 控件进行标准化。通过和他的交流，我能感受到天猫的产品是很偏重运营的，所以他们在做技术架构的时候，会考虑到怎么方便运营同事能够在后台快速配置生成运营相关的界面。某一方面，他们在努力尝试跨平台的各种方案，也是为了解决运营上的快速变化和配置便捷的需求。这让我认识到，其实没有绝对意义上标准的应用架构，好的应用架构应该是与自己的产品特点紧密联系的，这样才是最合适的。

关于 UIWebView 与其它界面的混排

gaosboy 也给我分享了关于原生界面和 UIWebView 混合排版的一些技巧，还挺有意思的。如果做过这方面工作的朋友就会知道，UIWebView 如果外层再套 UIScrollView，在内部和外部都可以上下滑动时，体验其实是不太好的，通常的做法是把内部的 UIWebView 高度完全展开，使得内部不再可以滑动，然后只用滑动外层的 UIScrollView 即可。

但是这个方案也有一些问题，就是 UIWebView 内容的高度并不是可以很方便地获取的。因为 UIWebView 中的图片资源会异步加载，加上一些 JavaScript 逻辑也可能在 DOM 加载完成后二次操作 DOM 做界面调整，所以原生层很难方便地知道 UIWebView 的高度。

gaosboy 给我分享了他在 SegmentFault 使用的技巧：利用 KVO 来监控 UIWebView 的 contentSize 的变化。这样可以随时知道 UIWebView 的内容高度有变化，然后就可以做相应的调整了。

gaosboy 另外还给我分享了一个 “黑科技”，即将原生的控件直接用 addSubView 插入到 UIWebView 的内部，然后在 UIWebView 内部用 css 控制相应的 padding ，给原生的控件留出相应的空白位置。

这个方案的优点是：这种办法可以保证整个界面只需要一个 UIWebView 即可完成。否则用之前的办法，如果某个界面有几个不相连的地方要用 UIWebView 展示，就得实例化多个 UIWebView 了。

但之所以把它称做 “黑科技”，是因为这种方法也有一些缺点：

一个是直接往系统控件里面插子 view 这种操作有很大风险。因为你不知道哪一天 iOS 系统升级后，这些控件内部的机制有没有调整，会不会造成这种黑科技挂掉。典型的例子就是 iOS8 刚升级那阵，微信的 ActionSheet 都弹不出来了。另外 iOS 8.3 的时候，我记得微信也出现过返回键失灵的情况。这些都是基于系统控件的一些内部机制做了一些事情，由于系统升级机制改变而受到的影响。
由于 padding 是事先留好的，如果是往 UIWebView 的中间插入元素，那么当页面调整后，需要重新更新控件的位置。

但是，这个方案当前确实被 gaosboy 他们在天猫采用过，所以我觉得也是一个挺有意思的、在某些实际场景下可以考虑的方案。

Native 和 Web 融合 - 听天猫前端开发专家鬼道（徐凯）的分享

鬼道老师所在的团队是最先尝试使用 React Native 的，之前我总结的 iOS 开发周报中的好几篇文章都是出自他们团队。我在这里将他的分享简单整理如下。

关于 WebView

鬼道首先分享了 WebView 在客户端的问题和特点，主要有：

首次加载慢 - 用本地 zip 包来解决
长列表占内存 - 用他们开源出来的 xList 来解决（类似 UITableView 的复用方案，不过我搜了一下，只找到一个 0 star 的项目：xlist，很可能找错了）
动画、w3c 慢
需要做 Hybird API
更新快
可以用 Hotpatch 来修复线上问题
他们做了一套叫 Windvane 的框架，可以对 WebView 的强化，对缓存和网络的扩展。他说好象也开源了，不过我没有搜到，应该是没有开源。

他们另外做了 WebView Crash 监控，通过冷加载，重构，把 Crash 率从 0.7% 降到 0.1%。

分享中还涉及一个技巧：把两倍的图的质量调整到 50%，以节省 WebView 的内存占用。

React Native

Native 可以带来更好的人机交互体验：

手势识别
动画效果
原生控件
更合适的线程模型（如图象解码，文本渲染）

Web 上的高效的开发效率和发布能力

业界现在使用 React Native 的应用:

FB ads/F8
Chinese Flashcards
天猫

比较重要的是，鬼道分享了 React Native 几个重要的性能指标：

内存：React Native 内存上的优势相对 WebView 比较明显，和原生的稍多一点。
CPU：CPU 上也比 WebView 有优势
启动时间：比 WebView 快 1 倍的样子
体积：我问了一下，几百 K 而已

要使用 React Native，基础环境还需要的工作：

埋点方案
缓存打包方案
网络改造
Framework 集成
发布机制改造
jsbundle 优化

Semi-Hybrid App Framework - Geek Zoo Studio 联合创始人郭虹宇

老郭的项目说实话最早应该是被我关注到的，当时他还在做 BeeFramework。他在阿里技术沙龙的第一次分享是我邀请的，他的第一篇采访稿是我代表 InfoQ 做的。老郭一直在尝试 Semi-Hybrid 这种混合编程方案，这个也是我个人挺感兴趣的一个技术方向。

由于我私下和他交流得太多，他的项目我也非常关注，这个分享我获得的新东西不多。但是还是给大家简单介绍一下老郭的这个项目吧。

老郭自己实现了一套浏览器的排版引擎，然后可以将正常的 HTML 和 CSS “翻译” 成原生的控件，这样就可以用 HTML 和 CSS 来写界面了。整个框架使用起来还是很cool的，大家去 star 一下他的这个项目吧，地址是：samurai-native。

最后多说一句，我觉得老郭的方案和 React Native 不是竞争关系。因为这两个框架解决问题的思路完全不一样。如果没有更新逻辑的需求，老郭的方案可能更适合天猫团队。当然，不管是samurai-native还是react native，现在都还没有开源出对 Android端的支持，不过这都只是时间问题。

移动时代用户端问题高效诊断 - 腾讯社交网络运维负责人马玉明

主要讲了移动 App 优化、云诊断技术架构、未来展望。

客户端优化：

网络定时驱动到事件驱动
TCP 粘包和半包处理
网络线程

网关劫持：

下发 HTTP 页面–检测 html 页面并且 webview 展示
下发错误数据
协议和端口限制–后台优化，客户端轮换 ip。私有协议用 443 端口成功率比较高。
异步启动的协议和端口限制
协议包头（异步）检测劫持

移动网络容灾调度：

server iplist 拉取和 push
移动终端网络质量数据监控
支持版本、地区、运营商、ip 段，qq 号的调度
具备断网、失效身份、踢下线、屏蔽命令字、进程自杀等能力

其中的很多问题我们都曾经遇到过，比如被运营商封禁这种事情。私下和马玉明聊天，他说他们都不敢把一些内容放到 qq.com 之外的其它域名，因为由于 QQ 的流量很大，运营商是不封禁的，而其它域名，一旦流量太大，很可能就被运营商给封禁了。所以在这方面，由于有移动运营商这一层，在运维上还有挺多事情需要做的。

最后马玉明成分享了他们的云诊断平台：http://huatuo.qq.com 。

美团移动平台背后的技术 - 陈晓亮

陈晓亮也从美团的业务出发，介绍了他们的做法。具体细节和最先提到的 gaosboy 的做法不同，但都是为了与自己的业务模式契合。

简单来说，晓亮他们用平台 + 频道来解决业务线种类多、差异大的问题。用 CocoaPods 、Jenkins 等来做代码的依赖和集成。

另外，他们利用类似注册的方法，来解决模块之间的解耦。他们把这个方法叫做 Protal。我听着感觉和 Android 的发 Intent 类似。即每个页面可以向一个中心注册，说我提供哪些服务，然后这个中心就知道每个服务应该用哪个类来处理。当要进行服务切换时，这个中心来负责做相应类的实例化，页面跳转等逻辑。服务在 iOS 里面可以用自定义的 url 来表示。注册中心可以拿一个单例来实现。

关于这种页面之前解耦，其实最早 Facebook 的 three20 框架就有。不过 Facebook 把它叫做 Router。three20 被废弃之后，也有很多人开源相应的解决方案。我记得 gaosboy 就开源过 urlmanager， github 上也有一个叫 HHRouter 的开源库，大家感兴趣可以自已学习下。

另外我才知道，美团他们大量使用了 ReactiveCocoa，有机会真是想好好讨论一下。

这次分享也见到了同在美团的梁士兴，我们以前一起在 IBM 的 Symphony 项目组实习过。

谷歌，投资，创业：懂技术的优势和通病 - 技德科技 CEO 周哲

这位 Google 的第 103 号员工在财务自由之后，做了一段天使投资人，然后选择了创业。他给我们讲了他在谷歌、投资、创业中的故事。

在看完《从 0 到 1》之后，再听他的故事，就觉得更加有趣了。因为你会发现，《从 0 到 1》里面提到的，“发现秘密” 这件事情，真是的非常困难的。Google 在早期，在很长一段时间内都没有考虑用广告来赢利，在最初做 Adwords 的时候，也只有 2.5 个工程师在做，而且这些工程师从来不点广告，认为这个东西做出来没人用。

那事情的结果大家都知道了，广告成了搜索引擎公司最大的收入来源。现在看来，大家会觉得这个想法是非常自然的，但是如果真的是这样的话，当时的搜索巨头雅虎就不会把这块业务”OEM“给 Google 来做了。

关于投资，周哲说虽然投兰亭集势成功了，投资主要的收获是那些失败的案例。而且选择创业，自然是认为他看到了另一个未被人发现的” 秘密 “。他讲了好几个故事，包括：教他编程的爸爸不会用 Windows 8，他自己花了 5 分钟不知道 Windows 8 如何关机，他当初是如何嘲笑 iPad 就是一个大一号的 iPhone，为什么大家现在还要用笔记本。最终他觉得当前没有谁在这方面很好地解决了用户的痛点，于是他选择了自己创业。

他的创业作品在 http://www.jide.com/ ，是一个基于 Android 的、带键盘的笔记本。