也不知道现在我的有没有固定的粉丝的读者,如果有的话可能大家对我的映像应该就是文青一枚吧!
其实这样认为我觉得是是错的,最正确的描述应该是,我是黑青一枚,略带文艺气息,略施粉黛!
既然已经入驻了,那么露一手我看是坑定是必不可少了啊!
接下来我就给大家带来我的第一篇技术文章,希望大家能够喜欢哈!
~~~~色彩和字体太单调了,没有什么我喜欢的色彩与字体!
<有关 Hybrid 开发模式实践总结>
前言
随着公司业务不断发展,移动开发项目越来越多,项目任务时间紧,我们内部开发流程是以项目为导向,有别于一般公司对产品不断迭代的做法,但移动端开发人员资源有限,需要在不同项目之间做业务场景切换开发,就会经常出现项目完成时间 Delay。面对这样的问题,我们该如何去解决呢?现在了解到的现状是每个业务组都有配备 Web 前端开发人员,那么是否能把涉及到业务模块分发给具体业务组 Web 前端开发人员去开发,剥离业务模块,我们移动端开发人员则专注于框架的开发或者手机端设备能力开发,比如可支持调用摄像头,监听网络状态变化,提供地理位置信息等等,有没有这样一套适合的解决方案呢,答案当然是有的。我们引入了可利用 Web 前端能力和移动端操作系统原生能力相结合开发模式,叫做 Hybrid 混合开发。
目录
- 为何选择 Hybrid 开发模式
- 在实践过程中碰到什么问题和解决
- 经验总结
为何选择 Hybrid 开发模式
1,目前工作中碰到的问题
随着公司业务飞速发展,移动端定制的项目越来越多,同时每个项目的业务逻辑呈现出复杂化和差异化特点,每个项目都需要提供 Android 版本和 IOS 版本,增加开发成本,开发周期往往又会被拖长。同时近年来前端技术蓬勃发展,HTML5 大行其道,很多主流 APP 厂商都利用 HTML5 前端能力来编写业务模块并结合原生设备能力进行混合开发,常见的比如淘宝、京东、微信、携程等等。虽然目前业务项目多,但是用户交互体验要求不高,常见页面也是列表,表单居多,适合充分利用HTML 5能力,因此引入Hybrid 混合开发模式,这样只需要 Web 前端开发人员写一遍前端业务代码,却能同时在Android 系统和 IOS 系统中执行。
2,Web APP、Hybrid APP、Native APP 对比
目前主流应用程序大体分为三类:Web App、Hybrid App、 Native App,如图:
Web APP
Web App 指采用Html5 语言写出的 App,不需要下载安装。类似于现在所说的轻应用。生存在浏览器中的应用,基本上可以说是触屏版的网页应用。
优点
(1)开发成本低,更新快
(2)更新无需通知用户,不需要手动升级
(3)能够跨多个平台和终端
缺点:
(1)临时性的入口
(2)无法获取系统级别的通知,提醒,动效等等
(3)用户留存率低
(4)设计受限制诸多
(5)体验较差
Hybrid App
Hybrid App 从外观上来看是一个Native App ,实则只有一个UIWebView,里面访问的是一个Web App ,如新闻类和视频类的应用普遍采取该策略:Native 的框架加上Web 的内容。不同于Native App 需要针对不同的平台使用不同的开发语言(如使用Objective-C、Swift开发iOS应用,使用Java等开发Android应用),Hybrid App 允许开发者仅使用一套网页语言代码(HTML5+CSS+JavaScript),即可开发能够在不同平台上部署的类原生应用 。由于Hybrid App 结合了Native app良好用户交互体验和Web App 跨平台开发的优势,能够显著节省移动应用开发的时间和成本,Hybrid App 得到越来越多公司的青睐。
按照网页语言和程序语言的混合,Hybrid App 通常可以分为三种类型:
- 多View混合型:Native View 和 Web View 独立展示,交替出现。 其应用主体通常是Native App,Web技术作为补充。即在需要的时候,将 Web View作为独立的 View 运行,在 Web View内完成相关的展示操作。开发难度与Native App相当.比如:微信里的公众号文章使用的是Web View 。
- 单View混合型:在同一个View 内,Native View 和Web View 为层叠关系,同时出现。开发成本较高,难度较大,但是体验较好。比如:百度搜索同时实现充分的灵活性和较好的用户体验。
- Web主体型:应用主体是Web View ,穿插 Native 功能,主要以网页语言编写。整体开发难度低,基本可以实现跨平台,而用户体验好坏,主要取决于底层中间件的交互与跨平台能力。比如:项目管理工具 Basecamp 使用Web view呈现内容,调用系统原生 API 实现界面导航等功能来提高用户体验。
Hybrid App 也并非是完美的解决方案。由于其使用 HTML5,某些依赖于复杂的原生功能或者繁重的过渡动画的应用会出现卡顿。同时,为了模拟Native App 的UI和感官,需要投入额外的时间和精力;尽管可以跨平台,但是并不能完全支持所有的设备和操作系统。最后,如果应用的体验不够原生化,如一个简单的网站,则还有被Apple App Store拒绝的风险。
Native App
Native APP 指的是原生程序,一般依托于操作系统,有很强的交互,是一个完整的 App,可拓展性强。需要用户下载安装使用。
优点:
(1)打造完美的用户体验,性能稳定
(2)操作速度快,上手流畅
(3)访问本地资源(通讯录,相册)
(4)设计出色的动效,转场,
(5)拥有系统级别的贴心通知或提醒,用户留存率高
缺点:
(1)分发成本高(不同平台有不同的开发语言和界面适配)
(2)维护成本高(例如一款App已更新至V5版本,但仍有用户在使用V2, V3, V4版本,需要更多的开发人员维护之前的版本)
(3)更新缓慢,根据不同平台,提交–审核–上线 等等不同的流程,需要经过的流程较复杂
三者技术特性
如下图表中对比了Native App、 Hybrid App、Web App在不同方面的表现,可以根据实际情况选择最佳的解决方案。
3,主流 APP Hybrid 应用比例
那么在实际应用场景中,有哪些选择了Hybrid app呢?实际上,我们很可能使用过很多Hybrid app,却并没有意识到它们是借了Native台子唱戏的Web app。根据Appcelerator的官网,目前单是运行基于它的平台搭建的Hybrid app的设备就有近2.86亿台。国外常见的有LinkedIn、Yelp、Netflix、Wunderlist ,国内主流的大厂基本也是采用了Hybrid 模式,应该是应用很广泛,同时技术上也是成熟稳定。
4,选择 Hybrid 混合开发的原因
-
Hybrid 开发模式在开发页面 UI 上有天生的便利,而原生的则如果需要一个比较华丽的界面,就需要花很长的时间去开发。
-
在业务上,看具体情况,有些简单业务在 Web上就可以处理,而如果涉及到复杂的业务,则可以用原生来写。
-
在基本能力上,原生的强,可以提供手机端独有的特性,但 Hybrid 则需要依赖 Javascript 中间层进行转化获取设备能力。
-
对于少界面,重业务的可以用原生,对于多界面,重效果的,可以用 Web 方式开发
在实践过程中碰到什么问题和解决
项目背景介绍
目前在一个项目实行的开发模式就是 Hybrid 混合开发,Web 技术与 Android 原生能力结合开发,Web 技术负责界面开发和相关业务, Android 原生能力则提供手机端特有设备能力,比如调用摄像头,网络状态监听,数据库操作等等。但这个项目的特殊性相关业务与我们提供的 Android 原生插件能力高度耦合,比如为这个项目提供数据库插件就是专门定制开发的,对于 Excel 插件的能力也是高度依赖一机一档相关字段,这跟我们选型用Hybrid 混合开发模式 的初心是相背离。我们初心是希望 Web 开发人员只需要专注于业务开发和界面绘制,原生部分则是提供相应的Android 设备能力集即可,每个插件跟业务是完全无关,这样就可以做到原生开发和Web开发互相解耦,两者之间通过接口隔离即可。
实践过程中碰到的问题
无论如何,一机一档项目是第一个应用 Hybrid 混合开发进行实战的项目,遇到的问题或者坑都是很正常,积极面对解决,并且不断进行总结和反思。把之前碰到的问题,简单罗列总结下:
- 开发人员调试困难问题。前端人员在开发时候是编写HTML5页面,所运行的环境跟 PC 端有很大的不同,因为需要运行在具体手机的环境上,因此需要每次编写完,需要通过移动端人员集成打包出一个APP 包进行安装验证,每新增或修改一个页面就需要重新打包验证,每次都需要集成测试,步骤繁琐,效率低下。
- 项目集成测试问题。Android 系统 Webview 和 PC 端浏览器内核版本差异问题导致加载效果不一致。
- 前端开发框架兼容问题。前端开发人员技术选型是基于 Vue.js 框架,这是一个渐进式 Javascript 框架,刚开始不支持。
- 文档不规范问题。在前期开发阶段,文档提供不详细,开发人员使用规则不清楚,导致沟通成本增加。
- Webview 性能问题。
如何解决
- 关于调试困难问题。提供一个调试工具叫做 Chrome DevTool,通过 Inspect 模式加载手机端里的 HTML5 页面,为何选择用 Chrome,因为Chrome 是目前主流前端开发调试利器,不仅能支持 Web 端开发,对于 HTML5 页面调试开发同样是能监听到 Javascript 报错或 CSS 报错,对于资源、网络、日志、内存等等,都是一步到位。同时在 APP 里提供一个在线调试环境,就是 Web 前端开发人员布置一个站点,在手机端通过 IP 地址远程访问站点,这样就可以在手机端实时看到刚刚修改内容是什么。
- 关于项目集成测试问题。在集成测试阶段,对Android 系统 Webview 和 PC 端浏览器内核版本区别有进一步认识,在Android 5.0 之前选用的是 Webkit 内核来加载 Web 资源文件,而在 Android 5.0 之后,则选用 Chromium 作为内核来加载,那么在为 PC 端浏览器端,如果你选择的是 Chorme 作为你默认浏览器的话,它的内核也是 Chromium 。尽管两者内核类型一样,都是 Chromium ,但两者加载 Javascript 效果上表现也不一样,比如最新浏览器版本可支持 ES 6 特性,但是在最新版的手机上就不一定 ES 6特性,目前通过调查 Android 5.0 之前的系统市场占有率,发现比例为不到20%,暂时适配到 Android 5.0 版本。
- 关于前端开发框架兼容问题。刚开始选用 Hybrid 开发模式时,对于公司内部 前端开发人员选用何种前端框架不甚了解,我们这边提供的 Demo 则是最原始的 HTML + Javascript + CSS 写法,以为前端人员只需要简单了解下就能上手,但在实践中发现却不是这样的。他们选型的前端技术是基于 Vue.js ,因为 Vue.js 是需要编译打包,生成发布的内容是混淆过的HTML + Javascript ,里面 Javascript 文件加载顺序使得我们开发 Javascript 插件调用引起问题,那样就会导致前端人员在调用具体插件能力时候,发现这个插件里的某个方法还没定义,就导致页面数据出错。后来通过了解 Vue.js 开发方式,调整项目工程中 Javascript 执行顺序, 确保具体插件调用在 Vue.js 执行前触发。
- 关于文档不规范问题。在前期开发阶段,前端人员没有统一查找目前已有插件能力的地方,仅仅根据我们提供的 Javascript 文件里的方法注释,虽然是针对每个方法的 Demo 用法,但是在实际开发中,前端开发人员也会调用出错。不是这个方法回调方法写错,就是参数类型传入传错,这样就导致的一个结果,前端开发人员不断地过来询问这个方法是如何调用的,我明明已经根据你的 Demo 写法进行编码了,为何还是报错的,前期的沟通成本还是很高。所以需要一个提供统一文档地方,里面写明了具体配置如何,写法如何,怎么是一步一步走,基本上可以避免类似的错误,更好的提高工作效率,减少沟通成本,所以一个规范的文档是很有必要的。
- 关于 WebView 性能加载问题。这是在解决 WebView 加载 HTML + Javascript + CSS 等资源时发现一个白屏问题,同时用 HTML5 做页面本身就会比原生加载来的慢。为了提高用户体验,在加载等待时,提供一个加载框来提示,等 HTML 资源文件全部渲染完毕后,等待框再消失,这样就可以避免一定的白屏现象。
经验总结
整体来说,为何会选择 Hybrid 混合开发模式是基于当前业务场景需要,技术是服务于业务发展,业务场景变化导致技术解决方案的选型也需要相应变化。面对以项目导向的开发现状,不能一昧追求最新最酷的技术,也不能对过时的技术方案过分保守,应该需要对当前业务场景进行判断,选择合适的解决方案才最佳的策略,没有一劳永逸的技术手段,只有时刻变化的业务需求和不断更新迭代技术方案。通过在具体项目中实战,面对问题,积极解决问题,也正是在解决问题过程中,产生新的想法和尝试,不断地完善框架能力,使得框架功能越来越全,进而更好的服务于业务开发问题,提高业务响应能力,降低开发成本,提升工作效率。