浅谈移动应用的技术选型

标签: IT技术 HTML5 移动应用 | 发表时间:2016-10-11 04: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.)的带动下更是日新月异. 所以说要选择一个适合业务需求并且匹配开发人员能力的技术方案并不是一件简单的事情. 我也只是在移动开发上做过一点微小的工作,此处仅能抛个砖,希望各位有玉的大神尽管砸过来.

3家NFC移动公司组成全球联盟:促进NFC技术应用

- 成 - GeekPark 捕风捉影
三家NFC(近场通信)移动营销公司今天宣布组成一个全球性联盟,以促进NFC技术在移动营销上的应用. 参与NFC全球联盟(NFC World Alliance)的公司分别代表不同的地区,它们是Blue Bite(代表美国地区),Proxama(代表欧洲、中东、非洲三地区)和Tapit(亚太地区). 这三家公司都已成功地开展基于NFC的营销活动,帮助众多品牌与大规模的消费者建立联系.

移动开发技术周报:用NetBeans开发HTML5应用,Objective-C和Cocoa最佳实践(2013.02.26)

- - InfoQ cn
总结性周报这个东西,是有时间阅读的人整理给没时间阅读又需要阅读的人看的. 有用的周报,相当于成功的用整理者的时间投入节约了阅读者的时间支出,皆大欢喜;否则,是浪费了双方的时间. 希望今天开始的这个周报会是个有用的周报. 有任何建议、反馈,欢迎写在评论里. 另,如果大家看到什么好东西(尤其是中文界的技术内容)想要分享,欢迎去Fenng的新店 Startup News踩踩.

移动应用排行榜

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

Touchanote,近场通讯技术新应用

- junyu - 爱范儿 · Beats of Bits
爱范儿在前几日报道了 Marc Andreessen 关于软件正在吞噬这个世界的想法,作为软件应用公司,如何更大地释放软件的影响力呢. 诸如腾讯,新浪,Twitter 等实例都启示我们开放 API 构建应用平台是一个行之有效的办法. 正所谓演绎数字时代的又一场集体智慧,作为老牌的知名笔记应用,Evernote 也趁着一轮融资之后开放了API,企图建立笔记类应用的标准平台.

应用架构和技术架构

- - 人月神话的BLOG
在这里再谈下应用架构和技术架构的关系和边界问题,这里的说明和标准的TOGAF会有一些区别,仅为个人理解的一些点滴记录. 首先再说下应用架构,应用架构是和业务架构有强烈的映射关系的一个架构,应用架构要说明的是整体企业内部信息化建设和规划应该分为哪些应用系统去建设,应用系统间的集成关系是如何的. 即我们常说的应用架构和应用集成架构.

谈Hadoop下各技术应用场景

- - 人月神话的BLOG
数据采集和DataFlow. 对于数据采集主要分为三类,即结构化数据库采集,日志和文件采集,网页采集. 对于结构化数据库,采用Sqoop是合适的,可以实现结构化数据库中数据并行批量入库到hdfs存储. 对于网页采集,前端可以采用Nutch,全文检索采用lucense,而实际数据存储最好是入库到Hbase数据库.

Solr Facet技术的应用与研究

- - 美团技术团队
在 《搜索引擎关键字智能提示的一种实现》一文中介绍过,美团的CRM系统负责管理销售人员的门店(POI)和项目(DEAL)信息,提供统一的检索功能,其索引层采用的是SolrCloud. 在用户搜索时,如果能直观地给出每个品类的POI数目,各个状态的DEAL数目,可以更好地引导用户进行搜索,进而提升搜索体验.