浅谈移动应用的技术选型

标签: IT技术 HTML5 移动应用 | 发表时间:2016-10-11 12:05 | 作者:ThoughtWorks
出处:http://blog.jobbole.com

在这个巨变的时代,技术选型是个很难做决定的事情,而移动应用技术领域在几个巨头(Google,Facebook,Apple etc.)的带动下更是日新月异。所以说要选择一个适合业务需求并且匹配开发人员能力的技术方案并不是一件简单的事情。我也只是在移动开发上做过一点微小的工作,此处仅能抛个砖,希望各位有玉的大神尽管砸过来。

做移动应用开发,说起来技术方案不外乎HTML5(没错,做Mobile Web其实也算是一种移动应用)、Native(在Android上不管是用Java、Kotlin还是Scala,iOS上不管是用Objective-C还是Swift)和使用原生UI,用JavaScript来实现逻辑的诸如React Native一类的方案。除此之外,还有结合HTML5和Native的Hybird混合方案。不同的技术方案有着不同的适应场景,至于具体如何选择,接下来我简单地谈谈自己的理解。

1、HTML5

也就是Web App的方案。这种方案最大的优点在于“Write Once, Run Everywhere”,不管你是Android还是iOS,都可以用一套代码搞定,在国内的话还能对接微信公众号,给用户提供一个方便快捷的入口,并且还有版本升级容易的优势(毕竟服务器是受自己控制的)。但是这种方案的缺点也很明显——无法使用系统级API,只能做为一个临时的入口,用户很难留存,并且因为浏览器性能的原因,很难带来很好的用户体验。

所以说Web App的主要适用场景还是在于作为对非核心业务在移动端的入口补足,或者是作为用户轻量、低频使用的体验增强。

1-meituan_guide

美团移动网站引导页

2-meituan_home

美团移动网站首页

美团的移动网页就是很典型的例子,主要还是提供给不经常使用的用户一个入口,网站内部还是在尽量引导用户下载使用客户端。

2、Hybird

Hybird是一种兼顾Native与HTML的开发模式,但根据实现的不同,还可以再细分为两种实现方案:

  • 在Native App中使用WebView加载远端Web资源
  • 使用Cordova/PhoneGap等框架通过WebView加载本地资源进行页面渲染

第一种方案其实已经应用得非常普遍了,很多应用的展示页面都是通过这种方式实现的。因为展示页面需要的正是能够轻易更换内容及布局的格式,并且这种纯展示的页面也并不需要复杂的动画与特效,使用Web页面是一个非常合适的解决方案。

而第二种方案前一段时间非常火,因为它在跨平台,在高效开发以及快速发布上有着明显的优势,毕竟Web内容只需要开发一次就可以在各个平台使用。而且将资源打包到本地也可以在一定程度上缓解从远端加载静态资源导致UI展示延迟的问题,并且还可以通过桥接Native和Web来调用一些Device的API。但其劣势也很明显,一是通过WebView执行代码效率较低,很难实现一些炫酷的效果,并且还存在不同设备的兼容性问题;二是如果想调用相关平台的API,需要针对平台单独进行开发,如果在应用中用到了大量的Device API,那么开发的效率将大大降低;三是很难应用到平台相关的新特性,比较难做出有特色的产品。

使用HTML页面来实现纯展示页面是非常推荐的一种方案。而Cordova/PhoneGap则更适用于对Mobile预算有限的公司、创业团队,或者对App进行快速的上线验证。

正好之前有个项目就用到了这种方案,为一家业务转型的零售商提供了使用一套基本代码来完成Android和iOS两个平台的App和微信公众号的相关页面的技术方案。

3-jingbao_app 4-jingbao

零售商Android应用零售商微信端

3、React Native

把React Native单独拿出来,是因为确实不能简单的将它分到其它任意一种方案里面去。React Native确实是最近最火的跨平台App解决方案了。它脱胎于React,因为React基于Virtual DOM来进行界面渲染,所以用Native的View来替换掉原本React的HTML DOM就顺理成章的引出了React Native的概念。

它与之前的跨平台方案有一个本质的区别,在于:其它方案都在追求写一次code解决所有平台的问题,而React Native的理念在于“Learn Once, Write Anywhere”。虽然大部分代码是平台无关的,但是平台相关的代码都需要单独实现,这虽然对跨平台带来了不便,但是引入的好处也是显而易见的,View层的部分通过原生组件实现,性能比其他WebView的方案不知道高到哪去了。而且React Native整套的逻辑代码都通过JavaScript实现,这样就让跨平台应用能够方便的复用逻辑代码。另外虽然React Native没有支持使用CSS来实现样式,但是提供了类似CSS的样式表支持,有过UI开发经验的人都能够非常快的上手。由于前端React也是非常的火,很多React社区的很多产出都可以在React Native上借鉴使用。

React Native对于没有复杂动画效果的一般应用来说不失为一个很好的解决方案。而且对于一些小型的企业级应用也是非常适用的。但是,React Native对于Android平台的支持度是不如iOS平台的,而且现有的非常成熟的应用也较少,所以说如果要在一些面向用户量很大,讲求用户体验的App中使用还是要慎重考虑的。

但是,其实Facebook已经在自家的App上用起来了,而且实测效果还是很好的。不过呢,人家毕竟是自家维护的,所以说真正要在项目上用可能还是得试了才知道效果。

5-facebook 6-facebook_ios

facebook Androidfacebook iOS

4、原生应用

原生应用的开发真的是让人又爱又恨。爱在于你可以在它上面施展拳脚、使用新特性、实现炫酷的效果。而恨则在于它跨平台性几乎为零,除了资源外几乎没有可重用的东西,即使是相似架构上的逻辑你也得再实现一遍。使用原生开发,能够方便地添加动画效果,调用底层硬件,所有的限制仅仅是来自平台的限制。但是正常情况下需要对不同的平台搭配不同的开发人员,而且如果要追求良好的用户体验,整个应用的设计还得满足相应平台的设计规范,这不仅是对Dev的考验,也是对UX的考验。不过如果真的对App的质量有很高的要求,我觉得这一切的付出也还是都是值得的。

如果针对的是要求硬件性能、讲究动画效果、追求用户体验的应用,还是建议分平台单独设计,并且都使用原生的技术方案来实现。其实这也是目前市面上大部分企业做出的选择。

使用原生开发我个人还有一个观点,就是 设计上要尽量遵守原生应用的设计规范,如果想要一套设计通吃所有平台,最终只会搞一个不伦不类的应用出来。知乎算是国内在这方面做得比较好的应用了,也取得了不错的效果。

7-zhihu

知乎

其实,在真正启动项目之前,在进行技术选型时,除了要考虑更符合业务的架构外,还要考虑开发人员的能力及技术栈。毕竟最后App还是由Dev们开发的。如果仅仅考虑业务而不考虑开发人员的技术能力来选择技术方案,不仅有一种钦定的感觉,而且最后往往坑到的还是自己。

我们常说:工具是死的,人是活的。考虑多种因素,在技术选型上做出更充分的考量,才是真正正确的选择。所以说又回到那句老话上:“It depends…”

浅谈移动应用的技术选型,首发于 文章 - 伯乐在线

相关 [移动应用 技术] 推荐:

移动应用开发技术选择六要素

- - 技术改变世界 创新驱动中国 - 《程序员》官网
作者从平台环境、操作系统、设备能力、云端、应用类型、跨平台开发六大方面分享了其在移动应用开发中的技术选择经验. 这是一个新的时代、新的机会. 自从2007 年1月乔布斯揭开iPhone的面纱以来,移动时代的大潮滚滚向前,已经走过近5个年头. 这个产业正在从新生走向成熟阶段. 在这样的产业时代背景下,各种不同的系统平台,不同的技术路线,自然是层出不穷、迅猛发展.

【译】Hybrid移动应用:用网页技术提供Native体验

- - 携程设计委员会
原文: http://www.smashingmagazine.com/2014/10/21/providing-a-native-experience-with-web-technologies/. 翻译: 叮当当咚当当小胖妞呀 杀手爱elva Ivan_z3 肖弦. 根据最近的一篇 报告显示,HTML是移动应用开发人员使用最多的语言,开发人员对于选择哪种网页技术考虑的最主要因素,是代码的跨平台便携性和开发的低成本性.

浅谈移动应用的技术选型

- - 文章 – 伯乐在线
在这个巨变的时代,技术选型是个很难做决定的事情,而移动应用技术领域在几个巨头(Google,Facebook,Apple etc.)的带动下更是日新月异. 所以说要选择一个适合业务需求并且匹配开发人员能力的技术方案并不是一件简单的事情. 我也只是在移动开发上做过一点微小的工作,此处仅能抛个砖,希望各位有玉的大神尽管砸过来.

移动应用排行榜

- - 曉生語錄
根据2011年中国ios应用下载排行榜整理出的表格,并分为四类:. 第一类.PC端的附属产品,指的是在发布移动应用在PC端已经有成熟的产品,移动应用是为了覆盖用户的零碎的使用时间,产品架构是提炼了PC端的主要功能. 第二类.同样的PC端的附属产品,但是移动应用利用了移动设备自身特性,并可能成为增加用户量的主力产品.

移动应用表单设计秘籍

- - 落花流水——elya妞╰_╯
一直想写一篇文章,关于移动应用表单设计的,可惜最近项目很忙,忙到没有时间打理博客. 最近体验产品的时候,经常看到错误的的表单设计,要么信息混乱,要么步骤繁复、要么语言程序化,要么视觉焦点跳跃,要么校验顺序混乱,要么反馈不及时,如此种种的问题,让我很想认真的总结一下,思考一下,为移动应用的表单设计,提供一些个人力所能及的建议,希望更多地设计师能认真思考移动应用表单的特殊性,能最大限度的提升表单设计的体验,提升效率,提高满意度.

移动应用注定无法长久?

- - cnBeta.COM
移动应用的历史是一个漫长而痛苦的过程,一开始是简单复制台式机的做法,然后窘迫地认识到,这种方式不太可行. 其实,这是一切事物进步的方式,不仅在技术领域,艺术和音乐也遵循类似的模式,复制、延伸,最后发现一个新的模式. 要摆脱旧的范式,需要耗费一段时间. 移动应用显然是成功的,并且在某些情况下,其盈利非常可观.

移动应用推广八法

- - CocoaChina移动观察
文/ John Koetsier. 如果一棵树在森林中轰然倒下,是否会有人听到. 如果你的应用出现在一个拥挤不堪的市场中,是否会有人注意到它呢. 虽然我所开发的应用目前都有数十万的下载量,但遗憾的是,上述问题的默认答案是“不会”. 事实上,最近的一项调查表明,有60%的应用以零收益而告终. 如果你不想让自己的应用沦落在这60%之中,那么不要指望什么运气,一定要采取实际的行动去争取.

移动应用广告的未来

- - 月光博客
  移动应用内置广告已经成为移动广告市场主流,但是现在相对滞后的广告模式(广告条、广告墙等)却制约了移动应用广告市场的发展,那么我们应该采用哪些更新颖的应用广告模式呢.   2007 年苹果发布 iPhone 和 App Store 掀起移动互联网的第一波浪潮,近两年随着移动应用开发门槛也逐渐降低和移动互联网发展再加速,人们获得信息的方式发生改变,移动应用逐渐成为移动设备第一载体.

HTML5 杀不死移动应用

- clowwindy - 月光博客
  苹果在其对抗 FLASH 的过程中,是否让自己也限了进去. 通过明文禁止 Flash 应用到 iPad 和 iPhone 上,苹果迫使 Web 开发人员不得不放弃采用 Flash 技术. 可以说,苹果和乔布斯为 Adobe 公司的放弃移动 Flash 业务的最终决定“提供了很有价值的参考意见”.

jQuery Mobile开发HTML5移动应用

- - HTML5研究小组
随着移动互联世界的到来,目前已发展到多种移动 操作系统割据的局面,而开发者则急需要能运用原有的开发知识和技能,快速方便地构建移动应用程序,并期望能运行在不同的 手机操作平台上,比如Android,iOS,黑莓等. 而目前,出现了一批十分优秀的支持HTML5/CSS3的移动应用开发框架,其中最为大家熟悉的是jQuery Mobile框架(http:// jquerymobile.com),它可以让熟悉jQuery框架的开发者快速开发出基于HTML5的移动应用,而且直接通过 手机的浏览器即可浏览.