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

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

写在前面：

因为业务须要，接触到一个Hybrid APP混合开发的项目。当时是第一次接触混合开发，有一些经验和总结，欢迎各位一块儿交流学习~

一、混合开发概述

Hybrid App主要以JS+Native二者相互调用为主，从开发层面实现“一次开发，多处运行”的机制，成为真正适合跨平台的开发。Hybrid App兼具了Native App良好用户体验的优点，也兼具了Web App使用HTML5跨平台开发低成本的优点。

目前已经有众多Hybrid App开发成功应用，好比美团、爱奇艺、微信等知名移动应用，都是采用Hybrid App开发模式。

二、移动应用开发的三种方式比较

移动应用开发的方式，目前主要有三种：

• Native App： 本地应用程序（原生App）
• Web App：网页应用程序（移动web）
• Hybrid App：混合应用程序（混合App）

 

图1：三种移动应用开发方式

如图1所示，三种移动应用开发方式具体比较如表2所示：

 

表2：三种移动应用开发方式比较

三、混合开发应用场景

（1）折中考虑——若是企业使用 Hybrid 开发方法，就能集Native 和web二者之所长。一方面，Native 让开发者能够充分利用现代移动设备所提供的所有不一样的特性和功能。另外一方面，使用 Web 语言编写的全部代码均可以在不一样的移动平台之间共享，使得开发和平常维护过程变得集中式、更简短、更经济高效。

（2）内部技能——许多企业都拥有Web 开发技能。若是选择 Hybrid 开发方法，在合适解决方案的支持下，Web 开发者只要仅仅运用 HTML、CSS 和 JavaScript 等 Web 技能，就能构建 App，同时提供 Native 用户体验。

（3）考虑将来——HTML5的可用性和功能都在迅速改进。许多分析师预测，它可能会成为开发前端 App 的默认技术。若是用 HTML 来编写 App 的大部分代码，而且只有在须要时才使用 Native 代码，公司就能确保他们今天的投入在明天不会变得过期，由于 HTML 功能变得更丰富，能够知足现代企业一系列更普遍的移动要求。

四、混合开发框架和层次结构图

混合开发结构图

 

1）移动终端web壳（如下简称“壳”）：壳是使用操做系统的 API 来建立嵌入式 HTML的渲染引擎。壳主要功能是定义Android应用程序与网页之间的接口，容许网页中的JavaScript调用Android应用程序，提供基于web的应用程序的Android API，将Web嵌入到Android应用程序中。

2）前端交互js：包括基础功能js和业务功能js。

3）前端适配器：适配不一样的终端：Pad、android、ios、wap。

混合开发层次结构图

 

1） 页面加载

1. 页面容器（XdjaWebView）类，是整个框架的核心和基础，主要用来实现页面的加载，以及对页面加载完成后的后续操做提供支持，例如：文件下载、js支持、文件上传，数据缓存、进度条等；
2. 页面加载接口：对页面的加载过程进行跟踪；例如：页面加载进度百分比，页面开始加载、页面加载出错、页面加载完成等

2） JS调用Android功能

1. 网页：页面调用js接口中的具体方法；
2. JS接口：调用android接口中一一对应的具体方法；
3. android接口：直接调用框架中集成的功能，或者经过框架接口在应用系统中自定义功能（例如，退出、返回键响应等)；其中升级功能的返回结果或者过程信息，能够在客户端中经过升级接口获取。
4. XdjaClientHelper：若是须要将框架中的方法返回值通知给js方法，大家能够经过XdjaClientHelper类来实现；

3）应用系统调用JS功能

应用系统经过XdjaClientHelper来实现对js功能的调用；

4） 应用系统调用HDF功能

应用系统能够调用框架集成的工具类、消息提示框、升级模块以及手机上常见的打电话发短信等功能。

五、性能优化

1） 单个页面

登陆、首页以及共用代码（样式文件、JS文件、页面加载loading代码）等放在index页面里。页面展现前显示fake页面（过场页面），首屏加载完后，fake页面消失。

页面虽然按照业务模块分为不一样的页面，可是展现的时候会在同一个页面即index页面展现。具体的说，须要某个功能页面的时候将页面以AJAX的形式请求到index页面，使用完毕删除。

使用一个页面，公共的CSS和JS只会加载一次。

2）CSS、JavaScript

在本次混合开发框架开发中，CSS所有写在一个文件里。

CSS和Jquery Mobile的相关文件写在index页面头部，其他公用JS等写在index页面底部。防止JS阻塞页面加载。各业务逻辑JS写在各业务页面的底部。

开发完成后，CSS和JS须要进行压缩，减小用户使用时初次请求时间。

3） @font-face

本次混合开发中使用@font-face来实现图标字体化，统一控制图标的颜色和大小。

使用@font-face优势：减小页面因使用图片而带来的流量，大大缩短页面响应时间；图标能够随意改变大小和颜色，而不会致使失真。

使用时注意：全部的图标须要是矢量的SVG格式。

使用限制：只适用于纯色扁平化的图标。背景图等比较复杂的图片仍然使用图片。

4） 本地存储LocalStorage

HTML5本地存储LocalStorage，在混合开发中主要用来存储最近查询记录等。

拿首页最近查询来讲，用户每次在综合查询中点击一个模块，经过LocalStorage将图标和对应的功能名字存储起来，若是用户不清除，LocalStorage中的数据是一直存在本地的。下次打开应用的时候从LocalStorage中读取最近查询记录等。

使用LocalStorage的好处是，不进行后台交互，速度快。

5）异步AJAX

本次开发中多处实现都是经过使用AJAX。首先，显示页面时，先显示框架，而后异步加载内容；其次，分页功能中，先显示部分简项列表，上拉获取更多内容。再次，每打开一个新功能，页面以AJAX的形式获取新页面的内容并展现出来。

异步AJAX，交互体验更好。从性能的角度考虑，速度也更快。

 http://www.cnblogs.com/kingplus/p/5588339.html

APP开发模式一般分为Web APP与Native APP原生模式两种，这两种模式均各自有本身的优点，究竟是采用Native App开发仍是采用Web App开发一直是业界争论的焦点，可是随着HTML5的发展及云服务普及，采用HTML5进行Web App开发正在成为一种趋势，用户能够根据应用特色和需求进行选择，亦可选择二者混合模式： 　　Native App开发 　　Native App开发即咱们所称的传统APP开发模式（原生APP开发模式），该开发针对IOS、Android等不一样的手机操做系统要采用不一样的语言和框架进行开发，该模式一般是由“云服务器数据+APP应用客户端”两部份构成，APP应用全部的UI元素、数据内容、逻辑框架均安装在手机终端上。 　　Web App开发 　　Web App开发便是一种框架型APP开发模式（HTML5 APP 框架开发模式），该开发具备跨平台的优点，该模式一般由“HTML5云网站+APP应用客户端”两部份构成，APP应用客户端只需安装应用的框架部份，而应用的数据则是每次打开APP的时候，去云端取数据呈现给手机用户。 　　原生APP开发及Web APP开发模式的区别 　　Web APP需开发“html5云网站”和“APP客户端”，昆明天度网络公司总结这类型APP应用呈现如下特色： 　　（1）每次打开APP，都要经过APP框架向云网站取UI及数据； 　　（2）手机用户没法上网则没法访问APP应用中的数据。 　　（3）框架型的APP没法调用手机终端的硬件设备（语音、摄像头、短信、GPS、蓝牙、重力感应等） 　　（4）框架型APP的访问速度受手机终端上网的限制，每次使用均会消耗必定的手机上网流量； 　　（5）框架型APP应用的安装包小巧，只包含框架文件，而大量的UI元素、数据内容刚存放在云端； 　　（6）APP用户每次均可以访问到实时的最新的云端数据； 　　（7）APP用户无须频繁更新APP应用，与云端实现的是实时数据交互； 　　适用企业：电子商务、金融、新闻资讯、企业集团需常常更新内容的APP应用。 　　Native App（原生型APP）须要开发“云服务器数据中心”和“APP客户端”，昆明天度网络公司总结这类型的APP应用呈现如下特色： 　　（1）每次获取最新的APP功能，须要升级APP应用； 　　（2）原生型APP应用的安装包相对较大，包含UI元素、数据内容、逻辑框架； 　　（3）手机用户没法上网也可访问APP应用中之前下载的数据。 　　（4）原生型的APP能够调用手机终端的硬件设备（语音、摄像头、短信、GPS、蓝牙、重力感应等） 　　（5）APP应用更新新功能，涉及到每次要向各个应用商店进行提交审核。 　　适用企业：游戏、电子杂志、管理应用、物联网等无需常常更新程序框架的APP应用。 　　到底该如何选择Web App和Native App开发模式 　　移动Web无所不在，移动Web是目前惟一的支持各类设备访问的平台，与桌面Web同样，移动Web支持各类标准的协议。移动Web也是惟一一个可供开发者发布移动应用的平台，它将各类移动交互与桌面任务有效地链接了起来；而开发Native App能够充分利用设备的特性，而这一点每每是Web浏览器作不到的，因此对一个产品自己而言，Native App是最佳的选择。下面几节将讨论一下Native App的一些主要功能。 　　何时应该选择Native App 　　1.为应用收费 　　没有任何地方规定开发者不能对一个移动Web App收取使用费，可是因为某些缘由，人们经常认为不能或是不该该对一个Web App收取费用。因为历史缘由，致使移动设备上付费服务遭遇两大阻力： 　　2.付款方式 　　在移动设备上输入信用卡号至关麻烦，并且在许多老式设备上也没有安全保障。一种典型的方式是，若是你须要对你的应用收费，你能够与运营商达成协议，让运营商代为为你的服务收费。这也意味着，你须要和多个运营商达成合做。这一般是首选的方法，由于许多手机用户可能根本就没有信用卡，好比青少年。 　　另外一种方法是将用户的信用卡信息保存在一个安全的网站上。用户能够经过登陆到该网站购买应用服务。这个过程不算特别理想，由于这意味着用户不能直接经过他们的移动设备购买服务了。 　　3.强制分红 　　移动运营商是会提成的。App不管是经过运营商仍是经过移动设备发布，他们都为应用提供了一套收费机制。这些运营商和移动设备将会提取部分收益，而后将剩余的部分交给应用开发商，这也意味着，开发人员必须遵照他们的市场规则。适应运营商的市场规则一般是很是困难的，须要投入大量的人力资源。相比而言，移动设备的市场规则则简单许多，可是也存在很多的困难。 　　妨碍运营商和移动设备开发商利益的应用以及服务都将受到阻扰。过去，那些不靠运营商和移动设备开发商运做的网站若是收入过于显眼的话，都逃脱不了被关闭的命运，可是最近，这样的事情鲜少发生了。 　　若是你想为你的Native App收费，那么你就必须接受这个现实——你必须遵照别人的市场规则，还得放弃部分收益。 　　4.开发游戏 　　若是你是想开发一个移动游戏（移动游戏是移动市场上最大的一块），那么你须要开发一个Native App。游戏对资源的占用很大，而且须要使用许多设备API或平台API。虽然，如今有几款彻底使用Web技术开发的游戏占有了必定的市场份额，可是和Native App市场的占有状况相比，仍是微不足道的。游戏用户对应用的视觉和操做效果要求很高。移动Web虽然提供了一些仿真体验，但还远远不能知足用户的需求。 　　在开发移动游戏时，你须要慎重考虑你的应用须要支持哪些平台。幸运的是，如今有许多工具可以帮助你将你的游戏推向多个平台，可是完成这些工做，仍是须要花费大量的人力和物力。 　　5.使用定位功能 　　下一个功能就是定位功能，能够经过GPS或者是信号检测肯定用户当前的位置信息。之前只能经过Native App的APIs查看用户的位置信息，但如今大多数主流移动浏览器上都嵌入了W3C Geolocation API。像iPhone或Android这样安装了WebKit的设备，或是配置了Opera或Mozilla浏览器的设备，均可以获取用户的位置信息。 　　我相信定位功能会为Web技术带来许多全新的应用。若是可以合理利用Web浏览器，Web开发商就能使用用户的位置信息和其余内容开发出更加有趣的应用。虽然这在技术上没有太大的困难，但却受到隐私保护条例的限制。咱们将Web浏览器当作是用户进入World Wide Web的入口。加入定位功能，意味着在网站中引入了一些敏感信息，这有可能致使严重的后果。可是位置感知应用中显示的位置信息必须通过用户的受权，用户固然有权禁止应用发布本身的位置信息。 　　6.使用摄像头 　　摄像头能够为你的应用提供丰富的可能性。以往移动MMS（Multimedia Messaging Service）被用于处理移动照片。换言之，你拍了一张照片后，须要使用MMS将它传送给一个服务器，服务器对照片作出相应的处理，并将处理完成的结果通知给你。这个过程是很是耗时的，并且至关复杂，也没有可靠性保障。 　　经过访问摄像头，Native App开发者可以简化拍照的过程。用户能够直接在客户端对照片作一些简单的处理，只有在有须要的时候才将照片上传给服务器，并且是经过可靠的HTTP传输。W3C正在开发一个访问摄像头的API，但如今尚未将这部分工做正式整合到浏览器中。 　　在许多类型的移动Apps中，摄像头是很是有用的，好比快拍应用、短片拍摄应用等等，摄像头能够用来捕捉许多重要的瞬间。不久的未来，咱们能够看到——只要经过摄像头拍摄某个标识，应用程序就能自动完成对标识上的语言转换工做——这个技术在日本已经开始流行起来了。 　　7.使用感应器 　　如今愈来愈来越多的移动设备上都新增了感应器功能，该装置能够感知设备的物理速度以及重力，并将感知的数据结果传送给设备。这个装置常被用来感应设置是否被翻转，应用根据接受到的信息自动调节画面的方向。 　　感应器能够用来帮助用户提高与设备交互时的真实感；大多数移动设备都是手持的，应用可以根据设备的方向调整内容画面，好比翻转屏幕，或是检测物理移动，并能据此猜想用户所处的环境。举一个简单的例子：好比用户正在走路，那么感应器可以检测到一个轻缓的移动或是速度，这时能够为用户提供一个大字体的用户界面，从而使得用户更容易看清屏幕上的内容。 　　然而，开发者也不能过度依赖感应器，由于感应器没法区分究竟哪些交互是有意的，而哪些是没有意义的。每一个移动交互都须要经过“传输测试”。设计你的交互时必须考虑用户在一个拥挤的汽车或是火车上的场景。考虑一下若是用户正身处拥挤的地铁或是正在驾车时，你的应用可否正确处理用户摇晃移动设备的动做。一般，大多数开发者都没有考虑这些因素。确保为每一个任务设计一个备用方案以处理特殊场景中的移动交互。 　　8.访问文件系统 　　若是你的应用须要将数据保存在本地，那么你须要开发一个Native App。好比你要保存用户的地址簿、电话或E-mail信息，或是保存从其余设备上获取的数据。 　　访问文件系统经常会涉及到安全和用户隐私保护的问题。恶意应用程序可能会修改或是删除你的移动设备上的数据。一个携带病毒的应用程序能够利用移动设备上的关系网将病毒扩散到许多其余的手机上，在采用移动应用认证机制之前，这种事情是经常发生的。 　　另外一方面，移动设备正变得愈来愈私人化，移动设备上保存了大量用户的我的信息，以及用户的朋友信息和商业信息。针对这些私人信息开发应用是一个不错的想法。可是这也存在必定的风险，使用保存在移动设备上的数据能够为用户提供更加有针对性的服务。 　　开发者必须谨记，只有在得到用户的受权后才能访问用户的私人数据。咱们看到许多应用在没有获得用户受权的状况下使用了大量的用户私人数据，而被误认为是垃圾信息或是钓鱼应用，即便这些应用本来是在提供一些很是有用的服务。人们对你的应用的误解将会影响到你的服务的推广，若是运营商收到过多关于你的应用的投诉，那么你的服务可能将被终止，甚至会牵连其余的应用。 　　访问文件系统时相当重要的一点就是在没有得到用户受权的状况下，不要访问任何用户的私人数据。而这一点，每每被大多数应用忽略了。W3C正在为移动开发商开发相关的标准API，但目前该工做还没有完成。 　　9.离线用户 　　最后一个须要开发Native App的理由就是，用户有多是离线的或者没法接入移动网络。这在城市可能不多发生，即便是在农村，网络的覆盖也已经逐步普及了。可是短暂的网络链接中断仍是时常发生的，你的应用程序应该考虑如何处理这种情景。 　　想一想用户一般在何时，在哪里会使用你的App。若是是一个移动游戏，那么用户极可能在飞机上使用这个App。跟踪地图应用常在偏远且网络覆盖不佳的地方使用。移动旅游向导常在一个国外的网络中访问，每每须要支付漫游和国际网络费用。这时，应用程序最好可以为用户提供离线服务，保证用户在不接入网络的状况下，仍然能享受同等的服务。 　　如今支持HTML5的浏览器也能实现脱机访问功能，但对用户来讲可能不太明显。随着愈来愈多的浏览器都开始支持脱机访问，应用须要明确地告诉用户网络链接中断时，他们仍然能够访问移动Web Apps。 　　Native Apps经常假设网络链接是可靠的。App一般只考虑了网络情况良好的情景，想固然地认为网络是封闭的，而且网速足够快。移动设备从网络良好的环境忽然进入一个网络糟糕的环境并很多见。Native Apps应该在网络情况最差的状况下测试。好比用户启动任务时可能仍是全信号覆盖，而在任务结束时可能已经彻底没有网络信号了。 　　用户在安装Native Apps时，根本不会考虑是在线访问仍是离线访问——他们指望的是无论在任何情况下，Native Apps都能正常工做。而这也是开发者的职责。 　　何时应该选择Web App 　　只要你的应用程序不知足以前提到的Native App条件之一，那么你就没有必要开发一个Native App，而应该选择开发一个Web App。正如文章以前提到的，我是一个Native App的拥护者，我认为Native App有许多优秀的特质，而且具备很大的市场潜力，可是Web Apps是惟一一个经久不衰的移动内容、服务、应用开发平台。 　　Native App并不能明显地为用户提供更好的服务；它反而会增长项目的成本，减小了应用发布的渠道，增长了App升级的复杂度，削弱了开发者对应用的控制和利润，而且可能会给设备带来麻烦。Native App能够为开发者带来短时间的效益，但这是有必定风险的，甚至可能会影响到移动市场的可持久发展。 　　移动Web App的优点在前文中已经提到过了。若是上一节提到的几点功能是促成你选择Native App的惟一缘由，那么若是可以在移动浏览器上屏蔽这些障碍，你是否还会坚持选择Native App呢？Palm的webOS已经着手解决了上述的部分问题。他们基于WebKit构建了一个全移动操做系统，将手机变成了一个Web浏览器。所谓的“Native Apps”实际上就是一个Web Apps。 　　PhoneGap也是一个相似的项目，这个开源项目用于帮助开发者在iPhone、Android以及BlackBerry设备上开发Native Apps，而且可以模拟设备上的功能（如定位功能和文件系统）供Web Apps调用。这些代码能够在各个设备的应用商店中发布而且出售，可是他们使用的通用代码和设计是能够共享的。因为开发的是一个Web App，开发者能够为低端的移动浏览器开发一个简化版的应用。只用开发一次，就能够部署在多个平台上了， 　　对于那些有着丰富的移动开发经验的程序员来讲，一提到“要开发一个功能丰富的应用”时，可能首先想到的就是Native App。虽然在不少设备上，这一想法仍然适用，可是如今移动Web Apps上也提供了足够丰富的功能接口供开发者调用。这使得Web App不只能够像Native App同样被设计得功能丰富界面绚丽，并且还能在各个平台上迁移，甚至不用修改一行代码。 　　如今在移动设备开发中，移动Web Apps的创新进入了史无前例的高潮时期。但更重要的是，这是有史以来第一次，移动设备开发商决定共同制定一个移动Web开发的标准，就像是桌面Web上的标准同样。不只如此，那些支持移动Web App创新功能的设备或是支持第三方浏览器的移动设备都受到消费者的欢迎。