在iOS开发开源领域，BeeFramework可以说是国人的一面旗帜，到目前为止，它在Github已有超过1800的star数和超过600的fork数，并且已有不少商业项目的成功案例，能够用在生产环境当中。BeeFramework采用的是一种“semi-Hybrid”的架构，是一个用HTML/XML+CSS技术开发原生App的整体解决方案。现在，让我们来听一听它的作者对iOS开发的思考，以及为什么开发这个项目的。
受访者：郭虹宇。BeeFramework作者，目前任职于Geek-Zoo Studio。
CocoaChina：非常感谢您能和大家分享自己在开发过程中的宝贵经验。首先请您简单介绍下自己，以及是如何开始iOS开发的。
郭虹宇：他们都叫我 “老郭”，微博账号是“@老郭为人民服务”，八年开发经验。最近一份打工经历（2年前的事了）在腾讯无线做开发Leader，目前与朋友一同创业，经营着Geek-Zoo Studio。
最早接触iOS开发应该是在5年前吧（大概是iOS3的时代），因为参与了QQ斗地主的游戏开发，从而开始了iOS App的开发征程。那时候国内做iOS开发的人不多，多数是从Symbian、MTK等平台转过来的，我是其中一员。
CocoaChina：我们知道BeeFramework是一款非常受国人开发者欢迎的框架，能给我们介绍下BeeFramework最新的进展情况吗？
郭虹宇：经过1年多的技术积累和沉淀，BeeFramework近乎稳定，今年更新了0.6版本，在原有功能之上增加了实现预览的功能（Live load），其他功能还在规划中。
BeeFramework已经能够满足App日常开发需求，在该技术支撑下最近又多出一些App案例，例如：BTV大媒体、ECMobile、凤凰彩票、SideChef等等。
BeeFramework本质是一款中规中矩的MVC框架，在原生App的基础上附加Hybrid UI特性及一些组件，大家用的最多的特性就是XML UI + Signal的组合，构成了Bee的一部分核心。
目前我们在BeeFramework的Github主页上加上了Experiment，不是说它是个实验性产品，而是试图来告知Bee爱好者与其广大用户，技术是在不断变革的，每次更新可能是一次新的技术尝试，也可能存在缺陷，需要大家来共同的完善它。
最后，开源项目离不开大家的支持和贡献，感谢BeeFramework其他作者的共同努力：QFish，STCui，ilikeido，gelosie，lancy，uxyheaven，Yulong，esseak，inonomori
CocoaChina：为什么称BeeFramework为semi-hybrid？它与一般的Hybrid开发有什么异同？
郭虹宇：BeeFramework应该不属于传统意义上的Hybrid技术。
“Semi-Hybrid” 是 “Hybrid” 的一个分支，如果说Hybrid是处于Native和Web的中间，那么BeeFramework处于Native和Hybrid的中间，之所以叫Semi的原因就在这里，BeeFramework实际上更侧重于Native开发。“Semi-Hybrid” 可以赋予开发者使用 Obj-C + HTML/XML + CSS 开发App的能力。
它与一般Hybrid开发相比，具备以下特性及优势：
移动优先，只保留App端必要的HTML标签（十几种），及基本CSS语法。
便于扩展，可通过自定义标签名，如
便于集成，因本身是Native框架，可快速将Obj-C的组件集成进来。
便于仿真，直接支持Liveload，在iOS模拟器中直接预览看效果。
便于调试，依然可以选择使用XCode做为主要调试工具，断点或查值。
便于传承，XML+CSS资源更方便的在不同人与不同项目间Copy/Paste来传承分享。
更好体验，直接使用iOS系统特性做交互，使体验上与Native没有差别。
更低成本，开发者不再需要学习庞大的前端开发知识体系，兼具Web灵活性，与Native体验。
CocoaChina：如今使用Hybrid/Web技术来进行移动开发非常火热，您如何评价这些技术？
郭虹宇：我曾经看过一些相关的技术文章，也在一直关注Polymer、AngularJS、Bootstrap等技术的发展。
在我看来，这些技术将Web开发彻底模块化，使代码变得简单且可复用，在设计思想上更注重使分离和解耦。
人们看到的是技术的表面，如何使得代码写得优雅健壮耦合度低，但这些技术带来的价值不仅如此。
如同世界范围的程序员如何交流编程思想，最原始方式是 “show me the code”。渐渐的，聪明的程序员开始学会总结归纳，可能有人提出 “数据结构”，可能有人提出 “编码规范”，可能有人提出 “设计模式”。当这些聪明的人转行做Web开发的那一天，了解到前端开发的混乱，必须找到一种可行方法来使得代码变得简单可复用好理解。
我想这就是各种移动Web开发技术出现的原因，它们是契约、规范、最佳实践的。
从我的角度并不是看这些技术的细节，而是看到他们所解决的问题和思想，是否能够在App开发中用到。
看看今天的行业现状，看看iOS开发技术的发展史，到底处于一个什么样的阶段？我认为依然处于一个初级阶段。初级到什么程度呢？举个例子，我想在GITHUB或其它代码库上找到一个UI组件，整合成App的View层并使之工作，怎么做？
如果这是一道iOS面试题，那么10个人可能每个人有10个答案，一共100种做法。
UI组件怎么编写、怎么集成、数据如何绑定？难道不应该有一套规范与最佳实践吗？
再想想，如果同样的题在问一位Web开发者，可能答案会相对集中，这就是技术发展不同阶段的反差。所以，iOS开发者需要一款框架级的解决方案，使之规范起来。
BeeFramework就是我的其中一个实验对象，目前初步实现了Component，DataBinding的规范及实现，希望通过这类技术来使App模块化，组件化。
CocoaChina：随着iPhone 6/6 Plus的发布，iOS可以说彻底走进了响应式设计的时代，您如何评价AutoLayout/VFL以及类似的技术，BeeFramework的相关技术与它们相比有什么优缺点？
郭虹宇：从 UIKit 技术演进（从IB到AutoLayout/VFL）可以看出 Apple团队对UI响应式技术准备不足，不过从另一个角度来看，也算是该团队另类的创新风格吧。
我认为，AutoLayout“反人类”的思维方式，并不是终极的响应式UI解决方案，基于该技术写出来的东西使开发与协作门槛变得很高。
BeeFramework尝试在NativeApp中推行更倾向于Web的响应式布局技术，不同于AutoLayout，我们使用XML/HTML + CSS。
和AutoLayout相比，BeeFramework的优点和缺点总结如下：
优点：
开发快速（Copy/Paste代码比拖拽Constraint快速很多）
复用度高（公共样式、公共布局、公共组件）
方便合作（可多人维护同一套样式或模版）
遵循标准（HTML/CSS标准）
易读易懂
便于分享
缺点：
学习成本
技术还不是很成熟
我们可以对比一下代码，同样是UI样式，使用AutoLayout和CSS相比
1 2 3 4 5 6 7 8 9 10 11 12 | //AutoLayoutNSDictionary *metrics = @{@"hPadding":@5,@"vPadding":@5,@"imageEdge":@150.0}; NSString *vfl = @"|-hPadding-[_boxV]-hPadding-|"; NSString *vfl0 = @"V:|-25-[_boxV]"; NSString *vfl3 = @"V:|-vPadding-[_headerL]-vPadding-[_imageV(imageEdge)]-vPadding-[_backBtn]-vPadding-|"; //CSS.style { width: 100%; height: 100%; padding: 25px;} |
可以看到CSS的代码更简短易懂，而AutoLayout的代码的写、读、修改都很困难。
AutoLayout整体给我的感觉是在重造轮子，并且造的不是那么太好，甚至不能让人接受。举个例子，AutoLayout支持跨层级的相对布局，想像一下，当RootView与SubView's SubView有绑定关系时，如果要修改其中一个视图，你需要修改中间的所有视图，是不是有种牵一发动全身的坑爹意思？
CocoaChina：iOS 8发布了WKWebView，进一步提升了性能以及对HTML5的支持，您如何看Web App在iOS上的前景？
郭虹宇：WKWebView的出现，是Apple对Hybrid/Web App认同的一个很好的开始，很可能会成为Apple后续推荐的关键App开发技术之一。
我想Apple团队也会在考虑，是继续奇葩的AutoLayout，重新定义Responsive Design？还是鼓励开发者切到Web App上去？或是有另外一种解决方案（Semi-Hybrid App）？
前景这些由时间来证明吧，自然会有答案。
以上就是本次访谈的全部内容，读者们对文中的看法是否认同？欢迎留言交流。
联系客服
