David，RubyonRails作者，37signals合作伙伴畅销书作家，演说家，赛车手，业余摄影师，顾家好男人37signals于2013年2月发布了Basecamp的iPhone应用程序，在此之前，我们制作许多尝试使用原生开发（native）或混合开发（hybrid）。当项目在2012年启动时，大多数人都倾向于原生开发。Facebook在2012年发布了他们新的iOS应用，为了获得更好的用户体验，他们放弃了原有的HTML5混合开发方式。考虑到2010-2011年，HTML在移动端的表现确实不尽如人意，这个决定在当时看来是合理的。回到2010年，我们认为iPhone3G/3GS足够快，但以今天的标准来看，它们太慢了。因此，在为移动应用程序开发设计架构时，我们需要考虑新移动设备的计算能力，而不是旧设备和过时设备的计算能力。移动开发架构的设计不需要过多考虑设备的性能。我们从一些测试中得出的结论之一是，目前的移动设备具有强大的计算能力，运行原生应用和HTML应用的效果相差不大。成本远低于原生开发。当然，这个结论在某些领域并不适用。如果要开发3D游戏，原生的开发方式可以带来更好的游戏体验。但是如果你的移动端应用像Basecamp一样专注于信息处理，为了降低开发成本，可以考虑混合开发方式。我们是这样的，下面是我们三代移动端产品的发展轨迹：第一代产品：nativeshell（nativeshell）+嵌套WebView这个版本是一个简单的nativeshell，负责界面导航，嵌套一个WebView来展示BasecampRail应用程序，它基本上展示了我们的移动网站页面，加上一些特殊的样式。在手机网站的页面上嵌套一个nativeshell，听起来很像网页，但是给用户带来的实际体验却大不相同。用户可以在苹果应用商店找到我们的应用，一旦登录应用，就再也不用重新登录了（手机版的Safari好像经常清除cookies，逼着你重新登录）。我们的应用程序非常受欢迎，用户评分在4到5之间。整个app由一个程序员和一个设计师开发，成本不高，因为我们可以在已有的手机网站的基础上开发。如果我们开发了一个完全原生的应用程序，那么10人的团队可能不会在一年半的时间内完成。第二代：NativeShell+NativeNavigation几个月前发布的BasecampAndroid应用是我们的第二代，我们在里面做了很多改进。我们从第一代iPhoneapp就感受到了原生导航界面的强大，所以在Android版本中，我们从HTML页面导航切换到了原生导航界面。我们从HTML页面生成原生导航界面，用户体验更流畅，原生界面和HTML页面的体验差异越来越小，甚至分不清哪些部分是原生部分哪些是HTML.Android版本由一两个程序员和一个设计师开发（50%输入）。我们复用了移动站点和iPhoneapp中使用的所有webview，大大提高了开发效率。同时，用户也喜欢它。1000多名用户打出了4.5~5的高分。许多公司都在抱怨他们的iOS移动项目进展缓慢，而他们的Android项目似乎更是如此。也许他们习惯了iOS项目的开发流程，也许是因为Android的屏幕碎片问题，但这些对我们来说都不是问题。我们推出的Android应用表现良好，重用了95%的代码，并且开发团队规模很小。因地制宜采用原生开发方式我们目前正在开发第三代产品，发布平台暂时保密，不过大家应该不难猜到。在前两代产品中，我们增加了原生导航界面的使用，同时进一步确定了以webview为核心的整体架构。在第三代产品中，我们会因地制宜地选择原本需要开发的功能，善用好钢。从之前的100%HTML到现在的90%HTML+10%native，我们会选择最值得native开发的10%部分。最终目标是让应用程序的原生部分和HTML部分的体验相差无几。混合开发模型中使用的技术混合开发模型的技术非常简单。主要处理webview的集成，网页的加载，原生内容和HTML内容的交叉链接。事实上，它可能比你想象的要简单得多。在HTML方面，我们的RailsWeb应用程序同时支持Web和移动平台，Rails4.1特性的变种起到了很大的作用。这对我们发布新功能也有很大帮助。想象一下，如果我们每次都需要更新这么多平台：Rails桌面应用程序、一个RailsAPI应用程序、一个客户端MVC应用程序、一个移动Web包装器应用程序、一个Android应用程序和一个iPhone应用程序，像我们一家公司这样只有10个程序拥有7名员工和7名设计师，根本承担不起如此庞大的工作量。除了减少工作量外，修复bug的效率也得到提升，因为大部分代码逻辑都在web服务器端，我们可以随时修改代码发布，无需经过AppleApp的审批流程店铺。所以我们的移动应用程序，就像网络应用程序一样，也是不断部署的。正如我之前提到的，混合模式开发并不适合所有情况。2010年之前，当时手机处理能力不强，所以HTML/JS的体验不好，用户不喜欢。但是时代变了，现在手机的处理能力有了很大的提升，HTML/JS性能已经不是问题了。混合开发模式对原生开发模式的挑战混合开发模式在降低开发复杂度方面有其优势。如果你的产品主要是展示和处理信息，我觉得可以不同程度的采用这种模式。对于小型团队和公司来说，iOS原生应用优先模式并不是必须的。使用混合模式不需要你重新开发一个应用程序，可以降低维护成本，也更容易在未来扩展到其他平台。当然，我知道很多人会质疑这种模式，可能是因为他们的app里面有很多地方需要原生开发（可能他们只是这么认为）。或者，也许他们花了太多时间让应用程序中的UITableView看起来如此漂亮，如果没有其他地方，它就不会完美。又或者大公司就是喜欢费时费力的原生开发，有钱就是这么任性。无论如何，混合开发现在应该成为我们移动开发战略的一个选项。如果您认为这是一个不错的选择，那么恭喜您，玩得开心！原文链接：Hybridsweetspot:Nativenavigation,webcontent在David给读者的回答下面添加一些：MikeWaite@2014-05-08：我很好奇你是如何决定使用哪些功能进行原生开发的？大卫@2014-05-08：主要是感觉，这毕竟不是科学。如果你觉得你的app的某个部分用native开发会更好，你可以尝试做一个快速原型（spike）。很多时候，我们就是这样证明自己的想法是错误的。当然，如果你需要用到手机上的功能，比如：摄像头等设备，HTML目前是不适合的，但千万不要说死。MikeParsons@2014-05-08：很棒的文章。想知道你们是否使用像PhoneGap或Cordova这样的框架，或者你们是否自己开发了一个？David@2014-05-08：我们没有使用任何框架。（此处省略xxx字）Derick@2014-05-08：安卓浏览器渲染速度慢怎么解决？这也是为什么Android平台上更多人倾向于开发原生应用的原因。David@2014-05-08：不知道你的结论是最近的还是以前的？BasecampAndroid应用程序在我的Nexus5和HTCOne上完美运行。Derick@2014-05-08：就在最近。我猜这可能与您使用的JavaScript数量有关。因为根据我个人的经验，JavaScript在Android上运行非常慢。如果您感兴趣，请查看这篇文章：https://www.timroes.de/2013/11/23/old-webview-vs-chromium-webview/David@2014-05-08：我们使用了很多JavaScript，当然不如WebMVC客户端。我们还使用了Turbolinks:)
