这两天在北京国际会议中心,QCon 全球软件开发大会正如期举行,我有幸参加了此次会议。QCon 此次参会的人数远远超过了主办方的预期,以至于提前关闭了报名通道。大会现场很多演讲人员爆满,现场周围都站满了人。
在会议上,我不但听了很多感兴趣的演讲,还见到了很多在网上多次交流,但从未谋面的好朋友,也认识了很多新朋友。这次交流对我来说收获挺多,在此总结一下。
gaosboy 是 SegmentFault 的联合创始人,现在在天猫。他在天猫工作两年了,在做 iOS 基础架构方面的事情。我和他之前在网上交流多次,也是由于他的引荐,我才加入了 InfoQ 的编辑团队。我和他交流了一些团队发展的问题,以及 iOS 的一些技术细节。
关于应用开发,天猫是将产品划分成很多组,每个小组的功能做完通过测试后,再 merge 到发布分支,发布分支要发布前,再进行一次集成测试,就可以上线了。这样可以各组之间不必完全同步进行开发,做完的就可以上线,没做完的小组顶多是赶不上某些上线,不会影响别的组的工作。
天猫也做了很多方便后台定制客户端的工作,例如用 JSON 来定制界面,又如将 UI 控件进行标准化。通过和他的交流,我能感受到天猫的产品是很偏重运营的,所以他们在做技术架构的时候,会考虑到怎么方便运营同事能够在后台快速配置生成运营相关的界面。某一方面,他们在努力尝试跨平台的各种方案,也是为了解决运营上的快速变化和配置便捷的需求。这让我认识到,其实没有绝对意义上标准的应用架构,好的应用架构应该是与自己的产品特点紧密联系的,这样才是最合适的。
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 了。
但之所以把它称做 “黑科技”,是因为这种方法也有一些缺点:
但是,这个方案当前确实被 gaosboy 他们在天猫采用过,所以我觉得也是一个挺有意思的、在某些实际场景下可以考虑的方案。
鬼道老师所在的团队是最先尝试使用 React Native 的,之前我总结的 iOS 开发周报中的好几篇文章都是出自他们团队。我在这里将他的分享简单整理如下。
鬼道首先分享了 WebView 在客户端的问题和特点,主要有:
他们另外做了 WebView Crash 监控,通过冷加载,重构,把 Crash 率从 0.7% 降到 0.1%。
分享中还涉及一个技巧:把两倍的图的质量调整到 50%,以节省 WebView 的内存占用。
Native 可以带来更好的人机交互体验:
Web 上的高效的开发效率和发布能力
业界现在使用 React Native 的应用:
比较重要的是,鬼道分享了 React Native 几个重要的性能指标:
要使用 React Native,基础环境还需要的工作:
老郭的项目说实话最早应该是被我关注到的,当时他还在做 BeeFramework。他在阿里技术沙龙的第一次分享是我邀请的,他的第一篇采访稿是我代表 InfoQ 做的。老郭一直在尝试 Semi-Hybrid 这种混合编程方案,这个也是我个人挺感兴趣的一个技术方向。
由于我私下和他交流得太多,他的项目我也非常关注,这个分享我获得的新东西不多。但是还是给大家简单介绍一下老郭的这个项目吧。
老郭自己实现了一套浏览器的排版引擎,然后可以将正常的 HTML 和 CSS “翻译” 成原生的控件,这样就可以用 HTML 和 CSS 来写界面了。整个框架使用起来还是很cool的,大家去 star 一下他的这个项目吧,地址是: samurai-native。
最后多说一句,我觉得老郭的方案和 React Native 不是竞争关系。因为这两个框架解决问题的思路完全不一样。如果没有更新逻辑的需求,老郭的方案可能更适合天猫团队。当然,不管是samurai-native还是react native,现在都还没有开源出对 Android端的支持,不过这都只是时间问题。
主要讲了移动 App 优化、云诊断技术架构、未来展望。
客户端优化:
网关劫持:
移动网络容灾调度:
其中的很多问题我们都曾经遇到过,比如被运营商封禁这种事情。私下和马玉明聊天,他说他们都不敢把一些内容放到 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 项目组实习过。
这位 Google 的第 103 号员工在财务自由之后,做了一段天使投资人,然后选择了创业。他给我们讲了他在谷歌、投资、创业中的故事。
在看完《从 0 到 1》之后,再听他的故事,就觉得更加有趣了。因为你会发现,《从 0 到 1》里面提到的,“发现秘密” 这件事情,真是的非常困难的。Google 在早期,在很长一段时间内都没有考虑用广告来赢利,在最初做 Adwords 的时候,也只有 2.5 个工程师在做,而且这些工程师从来不点广告,认为这个东西做出来没人用。
那事情的结果大家都知道了,广告成了搜索引擎公司最大的收入来源。现在看来,大家会觉得这个想法是非常自然的,但是如果真的是这样的话,当时的搜索巨头雅虎就不会把这块业务”OEM“给 Google 来做了。
关于投资,周哲说虽然投兰亭集势成功了,投资主要的收获是那些失败的案例。而且选择创业,自然是认为他看到了另一个未被人发现的” 秘密 “。他讲了好几个故事,包括:教他编程的爸爸不会用 Windows 8,他自己花了 5 分钟不知道 Windows 8 如何关机,他当初是如何嘲笑 iPad 就是一个大一号的 iPhone,为什么大家现在还要用笔记本。最终他觉得当前没有谁在这方面很好地解决了用户的痛点,于是他选择了自己创业。
他的创业作品在 http://www.jide.com/ ,是一个基于 Android 的、带键盘的笔记本。
听了两天的 QCon,感觉大会整体的质量在逐年提高,自己的收获也很多,希望明年能够办得更好。
Posted by 唐巧 Apr 24th, 2015 iOS
原创文章,版权声明:自由转载-非商用-非衍生-保持署名 | Creative Commons BY-NC-ND 3.0