【转载】Hybrid APP了解

原文:http://uikoo9.com/blog/detail/hpp

不错的hybrid app框架:http://www.dcloud.io/case/#group-1

HPP
hybirdApp或者hbuilderApp,

指通过html,css,js语言开发出ios和android两个版本的APP,

开发效率成倍上升,开发时间大幅缩减,开发成本同样也大大缩减。

移动互联网时代,还有多少中小公司没有自己的app,原因何在?
1.中小公司有多少?
这个都不需要引用相关数据,想想一句话就明白了,

“一将功成万骨枯”,这句话同样适合创业者,普通人耳熟能详的大公司已经很多了,

可以想象下中小公司有多少,数量极多极多。

2.大部分中小公司没有自己app
迫于app开发人员的用人成本极高,

初级android,ios工资基本10k左右,中级15k左右,高级25k左右,大概这个价,

中小公司找两个初级的做不出东西,找两个中级的差不多了,但是时间成本用人成本都很高,

最终的结果是只能做出一个demo类的app,或者计划一直往后拖,

又或者根本没有能力招app开发~

HPP,让所有中小公司轻松拥有自己的APP
1.成本比较
拿开发一个app,需要6个月,android,ios两个版本,

配备andorid中级(15k)+ios中级(15k)来说,成本是30*6=180k=18w,

配备一个hpp中级(15k)来说,成本是15*3=45k=4.5w,

这里是乘以3不是乘以6,因为hpp开发速度绝对比原生开发快一倍。

这样一来,

hpp开发app的成本是原生app的四分之一~

hpp开发app的成本是原生app的四分之一~

hpp开发app的成本是原生app的四分之一~

2.招人难度
android和ios的工资这么高(相对其他工种),原因之一就是招人比较难,

而hpp开发,只要会html+css+js就可以,

想想哪个java开发,php开发,.net开发不会点html+css+js,只需要在精通点,

想想哪个前端开发,不精通html+css+js呢,

所以招人来说,完成原生app

3.流畅度和加载速度
很多人会说流畅度,

随着手机厂商的竞争,手机硬件的发展,想想现在的千元小米,魅族之流,

目前来说千元机都很流畅,以后来说是手机就很流畅。

很多人说加载速度,

诚然,中小公司自己的带宽限制等等因素,加载页面比较满,

但是想想网络发展,从2g,3g,4g以及之后的5g,以及wifi的adsl,光纤,512k,1m,2m,10m,20m,

以及现在越来越普及的云服务,百度bae,新浪sae,阿里云等等,

网速也不是问题了。

HPP详述
1.HPP由来
其实用html+css+js本人用得比较多的是dcloud(公司)推出的hbuilder(ide),使用mui(ui)+nativejs开发app,

但是总这么hbuilder,mui的叫,感觉不是很顺口,或者不是很响亮,

百度上说基于html+css+js开发app的技术叫做HybirdApp,详见:这里

所以借用HybirdApp和Hbuilder开发的App这两个概念,推出HPP的叫法,

简单,好记。

2.HPP案例
说了这么多,如果你已经心动了,不妨看看这些HPP案例,

http://dcloud.io/case/#group-1

可以看出,HPP开发app本身流畅度是毫无问题,问题在于ui设计太low,一下子拉低档次,

如果有一个好的ui,外加一下开发的技巧,开发出的app还是很棒的,例如“爱学车”这个HPP。

3.HPP趋势如何
硬件趋势:手机硬件性能越来越好,

网络趋势:网速越来越快,

就业趋势:12年错过了android的你,15年还想错过HPP?

疑问解答
1.一次开发,生成android和ios两种app?
是的

2.需要熟悉哪里技术才可以从事HPP开发?
需要熟悉html,css,js,最好熟悉jquery,以及一些常用框架的上手方法(bootstrap,amazeui)。

3.具体使用哪些技术工具?
使用Hbuilder做ide进行开发打包app,

使用mui做ui层,理论上可以用其他的ui框架,例如amazeui,bootstrap,jquery mobile等,

使用nativejs做js桥调用原生方法,这个无可替换,比较重要。

4.免费吗?
Hbuilder已经开源,所以ide免费:https://github.com/dcloudio/HBuilder-opensource

mui已经开源,所以ui免费:https://github.com/dcloudio/mui

总之都是开源,都是免费的,看这里:https://github.com/dcloudio

5.开发的时候用浏览器调试和看效果?
no

虽然开发语言是html+css+js,但是成果是一个app,也就是一个apk或者ipa,

你见过用浏览器调试apk或者ipa的吗?

最佳推荐是真机调试。

6.只是网页套了个webview吗?原生功能可以调用吗?
完全不是,原生功能都可以调用,原生体验:http://www.dcloud.io/runtime.html

7.mui是个啥,可以替换吗?
mui是负责你做出来app的ui效果的,

完全可以替换为其他ui框架,bootstrap,amazeui等等,

dcloud做的不好的是mui太杂了,让很多人搞不清楚,

mui既负责了ui框架的部分:样式,组件,效果

mui又负责了js操作的部分:dom操作,事件绑定等,完全是copy的jquery,但是做的又没有jquery好,有很多坑。

mui又负责了原生调用的一部分:mui.init,mui.plusready等,

在我看来,mui只需要做好ui的部分就行,或者干脆交给国内类似的amazeui做,节省精力,效果还更好,

然后让js操作用jquery实现,又节省好多精力,效果性能还好,

最后专注于nativejs的开发,研发更多更好的原生能力,三方插件等。

技术的意义究竟何在?
1.提高效率,降低成本
以javaee的mvc框架们为例,

从刚开始的jsp+servlet,

到后来的ssh1(spring+struts1+hibernate),

再后来的ssh2(spring+struts2+hibernate),

然后的ssm(spring+springmvc+mybatis)。

除了jsp+servlet只是在学习过程中使用,而没有在工作中使用外,其他的框架都在工作中使用过,

也见证了几个公司框架的更新路程,

但是,停下来思考下,为什么框架在不停的更新,不停的变,

也许框架怎么变,最终用户看到的东西都是一样的,从用户的角度看,框架的变更毫无意义。

那么意义是?可能有人很快就会说,“更加安全”,“开发更快”。。。

伪原因:更加安全

为什么这么说,旧的框架由于历史原因会有很公开很明显的漏洞,为了避免这个漏洞你更新到了新框架,

但是请相信,新的框架也会有漏洞在等着你,

所以“更加安全”这个理由完全是为了凑字数或者说你作为架构者想推行自己熟悉框架的借口~

原因1:开发快

这个才是真正的原因,开发快,比较下jsp+servlet时代和后期的mvc框架时代,

不得不说,开发速度大大加快。

原因2:成本低

就公司招人的成本来说,新人总是熟悉新框架,当你想招一大波廉价的劳动力的时候,

发现你公司用的ssh1对于新人来说早已不知道是什么玩意,反而炫耀自己用的ssm,嘲笑你用的ssh1,

所以如果你想在目前的市场招到一大波的廉价劳动力,那么更新公司的框架在所难免。

原因3:自我实现

这个原因听起来比较怪,但是可以说却是根本原因,

技术世界就像中国的历史朝代一样,不停的更替,

如果一个技术新人,技术相当好,却出生(工作)在ssh1时代,

为了想证明自己的技术能力,为了让自己获得更好的报酬,

所以举起“更加安全,更加快速”的大旗,开始建立自己的朝代(ssm)。

同样,对于培训机构来说,为了招到更多的学生,

总是不停的退出新的框架教程,

最后,招来了更多的学生,培训出了更多熟悉新框架的工作新人。

技术研发者和技术推广者(培训)的自我实现才是推进技术更新换代的最根本原因,

技术接受者(新人)和技术使用者(公司)只能被迫的接受这种变化。

站在公司的角度,技术存在的意义只有:

提高工作效率:同样的时间内开发更多的东西;

降低用人成本:使用工作新人们都懂的框架,以便以更低的成本找到更多的人。

2.提高用户体验,科技方便生活
上面所说的技术意义,偏向于用户看不到的后台的技术,其意义就是降低成本,

还有一种技术是和用户实时相关的,用户看得见的,一直在使用的,可以方便生活,简化工作流程的。

例如html5,css3,让用户看到的网页越来越好看越来越有意思,

例如android,将用户拉进移动互联网时代,充话费,买外卖等等动动手指就做到了,大大方便人们的生活。

总结:
技术就是降低成本,方便生活,HPP是一门好技术~

HPP例子——滴石
官网:http://uikoo9.com/dishi

源码:https://github.com/uikoo9/dishi

教程:http://uikoo9.com/book/detail/3

HPP例子——识岁
官网:http://uikoo9.com/shisui

源码:https://github.com/uikoo9/shisui

教程:http://uikoo9.com/book/detail/5

http://uikoo9.com/
更多精彩内容
时间: 2024-12-09 18:07:23

【转载】Hybrid APP了解的相关文章

【转载|前端科普】聊聊Web App、Hybrid App与Native App的设计差异

目前主流应用程序大体分为三类:Web App.Hybrid App. Native App. 一.Web App.Hybrid App.Native App 纵向对比 首先,我们来看看什么是 Web App.Hybrid App. Native App. 1. Web APP Web App 指采用Html5语言写出的App,不需要下载安装.类似于现在所说的轻应用.生存在浏览器中的应用,基本上可以说是触屏版的网页应用. 优点 (1)开发成本低, (2)更新快, (3)更新无需通知用户,不需要手动

Hybrid App Development: 二、关于造轮子以及在Xcode iOS应用开发中加入Cordova

转载请注明出处:http://www.cnblogs.com/xdxer/p/4111552.html [ctrl+左键点击图片可以查看原图] 在上一篇关于Hybrid App Development的文章中,我讨论了一下在iOS下UIWebView的使用方法.但是光使用一个UIWebView所提供的功能还是完全不能满足我们的需求.   关于造轮子的思考: 在UIKit中的UIWebView虽然已经提供了很多功能了,比如JavaScript和Objc之间的通信.但是考虑到一个问题,如果在Hybr

移动开发 Native APP、Hybrid APP和Web APP介绍

快速区分定义: Native App 以基于智能手机本地操作系统如IOS.Android.WP并使用原生程式(SDK)编写运行的需要用户安装使用的第三方应用程序; Web APP 以HTML+JS+CSS等WEB技术编程,代码运行在移动端浏览器中,通过该移动端浏览器来调用Device API(取决于HTML5未来的支持能力)的不需要用户安装的应用程序: Hybrid App 同时使用网页语言(Web技术)与程序语言(Java.Objective-C等)开发,通过应用商店区分移动操作系统分发,需要

Ionic开发Hybrid App问题总结

http://ionichina.com/topic/5641b891b903cba630e25f10 http://www.cnblogs.com/parry/p/issues_about_build_hybrid_app_with_ionic.html 作者:Parry 出处:http://www.cnblogs.com/parry/ 本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利. 此篇文章主要整理了最近在

Hybrid APP基础篇(四)->JSBridge的原理

说明 JSBridge实现原理 目录 前言 参考来源 前置技术要求 楔子 原理概述 简介 url scheme介绍 实现流程 实现思路 第一步:设计出一个Native与JS交互的全局桥对象 第二步:JS如何调用Native 第三步:Native如何得知api被调用 第四步:分析url-参数和回调的格式 第五步:Native如何调用JS 第六步:H5中api方法的注册以及格式 进一步完善JSBridge方案 思路 实现 注意 完整的JSBridge 完整调用流程图 另外实现:不采用url sche

转: 跨终端Web之Hybrid App

转:  http://www.infoq.com/cn/articles/hybrid-app 编者按:InfoQ开设新栏目“品味书香”,精选技术书籍的精彩章节,以及分享看完书留下的思考和收获,欢迎大家关注.本文节选自徐凯著<跨终端Web>第八章“Hybrid App”,主要讲述Hybrid App的发展现状以及技术实现,最后还介绍了两种主流Hybrid开发框架PhoneGap/Cordova和Titanium. Native App(以下简称Native)和Mobile Web(以下简称We

Hybrid App(一)App开发选型

1.几种app开发模式概述 Native App 即传统的原生APP开发模式,Android基于Java语言,底层调用Google的 API;iOS基于OC或者Swift语言,底层调用App官方提供的API.体验最好. Web App 即移动端的网站,将页面部署在服务器上,然后用户使用各大浏览器访问.一般泛指 SPA(Single Page Application)模式开发出的网站.体验最差. Hybrid App 即混合开发,由Native通过JSBridge等方法提供统一的API,然后用Ht

那些年我们一起用过的Hybrid App

Hybrid App现状分析 Web App 毫无疑问Web App就是成本最低,最快速地解决方案了.尤其是近两年非常流行的响应式设计,Web App市场提供了非常好的实践场地.最近典型的Web App最佳案例是Sun天气应用了,其细节处理让人赞不绝口. Hybrid App 一般来说,拥有下面特点的就是一个Web App了:使用浏览器运行:纯Web前端架构,很多重要手机特性无法访问,例如联系人以及Push notification之类的:Single Page App:销售渠道多限于浏览器.

Hybrid APP混合开发的一些经验和总结

Hybrid APP混合开发的一些经验和总结 写在前面: 由于业务需要,接触到一个Hybrid APP混合开发的项目.当时是第一次接触混合开发,有一些经验和总结,欢迎各位一起交流学习~ 1.混合开发概述 Hybrid App主要以JS+Native两者相互调用为主,从开发层面实现“一次开发,多处运行”的机制,成为真正适合跨平台的开发.Hybrid App兼具了Native App良好用户体验的优势,也兼具了Web App使用HTML5跨平台开发低成本的优势. 目前已经有众多Hybrid App开