xml地图|网站地图|网站标签 [设为首页] [加入收藏]
浅谈Hybrid技术的设计与实现,浅谈Hybrid技术的设
分类:web前端

浅谈Hybrid技术的设计与实现第三弹——落地篇

2016/10/25 · 基础技术 · Hybrid

原文出处: 叶小钗(@欲苍穹)   

根据之前的介绍,大家对前端与Native的交互应该有一些简单的认识了,很多朋友就会觉得这个交互很简单嘛,其实并不难嘛,事实上单从Native与前端的交互来说就那点东西,真心没有太多可说的,但要真正做一个完整的Hybrid项目却不容易,要考虑的东西就比较多了,单从这个交互协议就有:

① URL Schema

② JavaScriptCore

两种,到底选择哪种方式,每种方式有什么优势,都是我们需要深度挖掘的,而除此之外,一个Hybrid项目还应该具有以下特性:

① 扩展性好——依靠好的约定

② 开发效率高——依赖公共业务

③ 交互体验好——需要解决各种兼容问题

我们在实际工作中如何落地一个Hybrid项目,如何推动一个项目的进行,这是本次我们要讨论的,也希望对各位有用。

文中是我个人的一些开发经验,希望对各位有用,也希望各位多多支持讨论,指出文中不足以及提出您的一些建议

设计类博客


iOS博客

Android博客

代码地址:

因为IOS不能扫码下载了,大家自己下载下来用模拟器看吧,下面开始今天的内容。

总体概述在第一章,有兴趣大家去看

细节设计在第二章,有兴趣大家去看

本章主要为打补丁

浅谈Hybrid技术的设计与实现

2015/11/05 · 基础技术 · Hybrid

原文出处: 叶小钗(@欲苍穹)   

我就是要用CSS实现

2016/01/15 · CSS · CSS

原文出处: AlloyTeam   

边界问题

在我们使用Hybrid技术前要注意一个边界问题,什么项目适合Hybrid什么项目不适合,这个要搞清楚,适合Hybrid的项目为:

① 有60%以上的业务为H5

② 对更新(开发效率)有一定要求的APP

不适合使用Hybrid技术的项目有以下特点:

① 只有20%不到的业务使用H5做

② 交互效果要求较高(动画多)

任何技术都有适用的场景,千万不要妄想推翻已有APP的业务用H5去替代,最后会证明那是自讨苦吃,当然如果仅仅想在APP里面嵌入新的实验性业务,这个是没问题的。

前言

随着移动浪潮的兴起,各种APP层出不穷,极速的业务扩展提升了团队对开发效率的要求,这个时候使用IOS&Andriod开发一个APP似乎成本有点过高了,而H5的低成本、高效率、跨平台等特性马上被利用起来形成了一种新的开发模式:Hybrid APP。

作为一种混合开发的模式,Hybrid APP底层依赖于Native提供的容器(UIWebview),上层使用Html&Css&JS做业务开发,底层透明化、上层多多样化,这种场景非常有利于前端介入,非常适合业务快速迭代,于是Hybrid火啦。

本来我觉得这种开发模式既然大家都知道了,那么Hybrid就没有什么探讨的价值了,但令我诧异的是依旧有很多人对Hybrid这种模式感到陌生,这种情况在二线城市很常见,所以我这里尝试从另一个方面向各位介绍Hybrid,期望对各位正确的技术选型有所帮助。

Hybrid发家史

最初携程的应用全部是Native的,H5站点只占其流量很小的一部分,当时Native有200人红红火火,而H5开仅有5人左右在打酱油,后面无线团队来了一个执行力十分强的服务器端出身的leader,他为了了解前端开发,居然亲手使用jQuery Mobile开发了第一版程序,虽然很快方案便被推翻,但是H5团队开始发力,在短时间内已经赶上了Native的业务进度:

图片 1图片 2图片 3

突然有一天andriod同事跑过来告诉我们andriod中有一个方法最大树限制,可能一些页面需要我们内嵌H5的页面,于是Native与H5框架团队牵头做了第一个Hybrid项目,携程第一次出现了一套代码兼容三端的情况。这个开发效率杠杠的,团队尝到了甜头,于是乎后续的频道基本都开始了Hybrid开发,到我离开时,整个机制已经十分成熟了,而前端也有几百人了。

场景重现

狼厂有三大大流量APP,手机百度、百度地图、糯米APP,最近接入糯米的时候,发现他们也在做Hybrid平台化相关的推广,将静态资源打包至Native中,Native提供js调用原生应用的能力,从产品化和工程化来说做的很不错,但是有两个瑕疵:

① 资源全部打包至Naive中APP尺寸会增大,就算以增量机制也避免不了APP的膨胀,因为现在接入的频道较少一个频道500K没有感觉,一旦平台化后主APP尺寸会急剧增大

② 糯米前端框架团队封装了Native端的能力,但是没有提供配套的前端框架,这个解决方案是不完整的。很多业务已经有H5站点了,为了接入还得单独开发一套程序;而就算是新业务接入,又会面临嵌入资源必须是静态资源的限制,做出来的项目没有SEO,如果关注SEO的话还是需要再开发,从工程角度来说是有问题的。

但从产品可接入度与产品化来说,糯米Hybrid化的大方向是很乐观的,也确实取得了一些成绩,在短时间就有很多频道接入了,随着推广进行,明年可能会形成一个大型的Hybrid平台。但是因为我也经历过推广框架,当听到他们忽悠我说性能会提高70%,与Native体验基本一致时,不知为何我居然笑了……

总结

如果读了上面几个故事你依旧不知道为何要使用Hybrid技术的话,我这里再做一个总结吧:

JavaScript

Hybrid开发效率高、跨平台、底层本 Hybrid从业务开发上讲,没有版本问题,有BUG能及时修复

1
2
Hybrid开发效率高、跨平台、底层本
Hybrid从业务开发上讲,没有版本问题,有BUG能及时修复

Hybrid是有缺点的,Hybrid体验就肯定比不上Native,所以使用有其场景,但是对于需要快速试错、快速占领市场的团队来说,Hybrid一定是不二的选择,团队生存下来后还是需要做体验更好的原生APP

好了,上面扯了那么多没用的东西,今天的目的其实是为大家介绍Hybrid的一些设计知识,如果你认真阅读此文,可能在以下方面对你有所帮助:

① Hybrid中Native与前端各自的工作是什么

② Hybrid的交互接口如何设计

③ Hybrid的Header如何设计

④ Hybrid的如何设计目录结构以及增量机制如何实现

⑤ 资源缓存策略,白屏问题……

文中是我个人的一些开发经验,希望对各位有用,也希望各位多多支持讨论,指出文中不足以及提出您的一些建议

然后文中Andriod相关代码由我的同事明月提供,这里特别感谢明月同学对我的支持,这里扫描二维码可以下载APP进行测试:

Andriod APP二维码:

图片 4

代码地址:

写在最前

我们都是前端工程师,无论你现在是页面仔,还是Node服务开发者,抑或是全端大神,毋庸置疑的是,我们都是前端工程师,我们生来就对追求页面的极致拥有敏锐的触觉,无论是页面实现方式的高大上、页面的极致的性能还是页面完美的展现,都是我们孜孜不倦的追求目标。即使这些在别人眼里,只是跟其他的页面一样没什么不同,但我们却能为其中那只有我们才知道的一抹别致而窃喜。

而今天我要讲的,就是我们最熟悉的老朋友,CSS。不讲枯燥的语法,抛开js,让我们一起来看业务中那别致的纯CSS实现,让我们一起来追求那更好的页面实现,希望我带着你走完这段旅程后,你能收获一些惊喜甚至灵感。

交互约定

根据之前的学习,我们知道与Native交互有两种交互:

① URL Schema

② JavaScriptCore

而两种方式在使用上各有利弊,首先来说URL Schema是比较稳定而成熟的,如果使用上文中提到的“ajax”交互方式,会比较灵活;而从设计的角度来说JavaScriptCore似乎更加合理,但是我们在实际使用中却发现,注入的时机得不到保障。

iOS同事在实体JavaScriptCore注入时,我们的原意是在webview载入前就注入所有的Native能力,而实际情况是页面js已经执行完了才被注入,这里会导致Hybrid交互失效,如果你看到某个Hybrid平台,突然header显示不正确了,就可能是这个问题导致,所以JavaScriptCore就被我们弃用了。

JavaScript

JavaScriptCore可能导致的问题: ① 注入时机不唯一(也许是BUG) ② 刷新页面的时候,JavaScriptCore的注入在不同机型表现不一致,有些就根本不注入了,所以全部hybrid交互失效

1
2
3
JavaScriptCore可能导致的问题:
① 注入时机不唯一(也许是BUG)
② 刷新页面的时候,JavaScriptCore的注入在不同机型表现不一致,有些就根本不注入了,所以全部hybrid交互失效

如果非要使用JavaScriptCore,为了解决这一问题,我们做了一个兼容,用URL Schema的方式,在页面逻辑载入之初执行一个命令,将native的一些方式重新载入,比如:

JavaScript

_.requestHybrid({ tagname: 'injection' });

1
2
3
_.requestHybrid({
     tagname: 'injection'
});

这个能解决一些问题,但是有些初始化就马上要用到的方法可能就无力了,比如:

① 想要获取native给予的地理信息

② 想要获取native给予的用户信息(直接以变量的方式获取)

作为生产来讲,我们还是求稳,所以最终选择了URL Schema。

明白了基本的边界问题,选取了底层的交互方式,就可以开始进行初步的Hybrid设计了,但是这离一个可用于生产,可离落地的Hybrid方案还比较远。

Native与前端分工

在做Hybrid架构设计之前需要分清Native与前端的界限,首先Native提供的是一宿主环境,要合理的利用Native提供的能力,要实现通用的Hybrid平台架构,站在前端视角,我认为需要考虑以下核心设计问题。

交互设计

Hybrid架构设计第一个要考虑的问题是如何设计与前端的交互,如果这块设计的不好会对后续开发、前端框架维护造成深远的影响,并且这种影响往往是不可逆的,所以这里需要前端与Native好好配合,提供通用的接口,比如:

① NativeUI组件,header组件、消息类组件

② 通讯录、系统、设备信息读取接口

③ H5与Native的互相跳转,比如H5如何跳到一个Native页面,H5如何新开Webview做动画跳到另一个H5页面

资源访问机制

Native首先需要考虑如何访问H5资源,做到既能以file的方式访问Native内部资源,又能使用url的方式访问线上资源;需要提供前端资源增量替换机制,以摆脱APP迭代发版问题,避免用户升级APP。这里就会涉及到静态资源在APP中的存放策略,更新策略的设计,复杂的话还会涉及到服务器端的支持。

账号信息设计

账号系统是重要并且无法避免的,Native需要设计良好安全的身份验证机制,保证这块对业务开发者足够透明,打通账户信息。

Hybrid开发调试

功能设计完并不是结束,Native与前端需要商量出一套可开发调试的模型,不然很多业务开发的工作将难以继续,这个很多文章已经接受过了,本文不赘述。

至于Native还会关注的一些通讯设计、并发设计、异常处理、日志监控以及安全模块因为不是我涉及的领域便不予关注了(事实上是想关注不得其门),而前端要做的事情就是封装Native提供的各种能力,整体架构是这样的:

图片 5

真实业务开发时,Native除了会关注登录模块之外还会封装支付等重要模块,这里视业务而定。

WHY,为什么

“我有很多事要做诶,忙都忙不过来,难道我要在这CSS上面浪费很多时间?”

不,不,不,我们要做的事情,当然不会只是满足技术的追求,而是会有实质的好处的!

我的观点如下:

  1. CSS跟UI结合更加紧密;
  2. 用CSS来实现,能减少JS计算,减少样式修改,减少重绘,提升渲染效率;
  3. 用CSS实现的,是一种模块化,更符合Web Components组件化思想,shadow DOM不就是致力于这么做么;
  4. 咱最爱的,逼格更高~

 

账号体系

一般来说,一个公司的账号体系健壮灵活程度会很大程度反映出这个研发团队的整体实力:

① 统一的鉴权认证

② 短信服务图形验证码的处理

③ 子系统的权限设计、公共的用户信息导出

④ 第三方接入方案

⑤ 接入文档输出

⑥ ……

这个技术方案,有没有是一回事(说明没思维),有几套是一回事(说明比较乱,技术不统一),对外的一套做到了什么程度又是一回事,当然这个不是我们讨论的重点,而账号体系也是Hybrid设计中不可或缺的一环。

账号体系涉及了接口权限控制、资源访问控制,现在有一种方案是,前端代码不做接口鉴权,账号一块的工作全部放到native端。

Hybrid交互设计

Hybrid的交互无非是Native调用前端页面的JS方法,或者前端页面通过JS调用Native提供的接口,两者交互的桥梁皆Webview:

图片 6

app自身可以自定义url schema,并且把自定义的url注册在调度中心, 例如

  • ctrip://wireless 打开携程App
  • weixin:// 打开微信

我们JS与Native通信一般就是创建这类URL被Native捕获处理,后续也出现了其它前端调用Native的方式,但可以做底层封装使其透明化,所以重点以及是如何进行前端与Native的交互设计。

WHEN,何时

“我懂了,看起来是有那么点意思,可是我什么时候能用CSS来做大事啊?”

在我看来:

  1. 实现的对象是非交互性UI;
  2. 这么做不会给你带来过量的DOM。要知道最不能忍受的,就是臃肿的页面;
  3. 这么做能完美实现UI、能覆盖所有场景,否则设计跟产品不服。

什么是非交互性UI,就是不会在用户触发了某种行为时,哗啦啦来个闪瞎眼的交互,吓得用户直接高潮,而是从页面渲染后,就一直在那里,那么安静,那么美的女子,哦不,UI。

 

native代理请求

在H5想要做某一块老的App业务,这个APP80%以上的业务都是Native做的,这类APP在接口方面就没有考虑过H5的感受,会要求很多信息如:

① 设备号

② 地理信息

③ 网络情况

④ 系统版本

有很多H5拿不到或者不容易拿到的公共信息,因为H5做的往往是一些比较小的业务,像什么个人主页之类的不重要的业务,Server端可能不愿意提供额外的接口适配,而使用额外的接口还有可能打破他们统一的某些规则;加之native对接口有自己的一套公共处理逻辑,所以便出了Native代理H5发请求的方案,公共参数会由Native自动带上。

JavaScript

//暂时只关注hybrid调试,后续得关注三端匹配 _.requestHybrid({ tagname: 'apppost', param: { url: this.url, param: params }, callback: function (data) { scope.baseDataValidate(data, onComplete, onError); } });

1
2
3
4
5
6
7
8
9
10
11
12
//暂时只关注hybrid调试,后续得关注三端匹配
_.requestHybrid({
     tagname: 'apppost',
     param: {
         url: this.url,
         param: params
     },
     callback: function (data) {
         scope.baseDataValidate(data, onComplete, onError);
     }
});

这种方案有一些好处,接口统一,前端也不需要关注接口权限验证,但是这个会带给前端噩梦!

前端相对于native一个很大的优点,就是调试灵活,这种代理请求的方式,会限制请求只能在APP容器中生效,对前端调试造成了很大的痛苦

1
前端相对于native一个很大的优点,就是调试灵活,这种代理请求的方式,会限制请求只能在APP容器中生效,对前端调试造成了很大的痛苦

从真实的生产效果来说,也是很影响效率的,容易导致后续前端再也不愿意做那个APP的业务了,所以使用要慎重……

JS to Native

Native在每个版本会提供一些API,前端会有一个对应的框架团队对其进行封装,释放业务接口。比如糯米对外的接口是这样的:

JavaScript

BNJS.http.get();//向业务服务器拿请求据【1.0】 1.3版本接口有扩展 BNJS.http.post();//向业务服务器提交数据【1.0】 BNJS.http.sign();//计算签名【1.0】 BNJS.http.getNA();//向NA服务器拿请求据【1.0】 1.3版本接口有扩展 BNJS.http.postNA();//向NA服务器提交数据【1.0】 BNJS.http.getCatgData();//从Native本地获取筛选数据【1.1】

1
2
3
4
5
6
BNJS.http.get();//向业务服务器拿请求据【1.0】 1.3版本接口有扩展
BNJS.http.post();//向业务服务器提交数据【1.0】
BNJS.http.sign();//计算签名【1.0】
BNJS.http.getNA();//向NA服务器拿请求据【1.0】 1.3版本接口有扩展
BNJS.http.postNA();//向NA服务器提交数据【1.0】
BNJS.http.getCatgData();//从Native本地获取筛选数据【1.1】

JavaScript

BNJSReady(function(){ BNJS.http.post({ url : '', params : { msg : '测试post', contact : '18721687903' }, onSuccess : function(res){ alert('发送post请求成功!'); }, onFail : function(res){ alert('发送post请求失败!'); } }); });

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
BNJSReady(function(){
    BNJS.http.post({
        url : 'http://cp01-testing-tuan02.cp01.baidu.com:8087/naserver/user/feedback',
        params : {
            msg : '测试post',
            contact : '18721687903'
        },
        onSuccess : function(res){
            alert('发送post请求成功!');
        },
        onFail : function(res){
            alert('发送post请求失败!');
        }
    });
});

前端框架定义了一个全局变量BNJS作为Native与前端交互的对象,只要引入了糯米提供的这个JS库,并且在糯米封装的Webview容器中,前端便获得了调用Native的能力,我揣测糯米这种设计是因为这样便于第三方团队的接入使用,手机百度有一款轻应用框架也走的这种路线:

JavaScript

clouda.mbaas.account //释放了clouda全局变量

1
clouda.mbaas.account //释放了clouda全局变量

这样做有一个前提是,Native本身已经十分稳定了,很少新增功能了,否则在直连情况下就会面临一个尴尬,因为web站点永远保持最新的,就会在一些低版本容器中调用了没有提供的Native能力而报错。

HOW,该怎么做

“可是我还是不懂该如何做才能这么有逼格”

我个人的见解:

  1. 布局之美,理解透盒子模型,熟悉各种布局,不要忘了这是咱的根本;
  2. 自适应之美,放心交给浏览器去做,我们要做的,是思考规则;
  3. Magic,新技术及小技巧,总能在某一刹那给你最需要的援助;
  4. 前人之鉴,坑王之王,你已经身经百战了,还怕什么。

这些就是我总结出你要用CSS来实现一个别人想不到的东西时,应该具有素质。最重要的还是思考,因为没有一个东西是绝对最好的,我们总在前进。

图片 7

下面就以两个手机QQ实际业务的例子,带领大家感受一下CSS的魅力。

 

注入cookie

前端比较通用的权限标志还是用cookie做的,所以Hybrid比较成熟的方案仍旧是注入cookie,这里的一个前提就是native&H5有一套统一的账号体系(统一的权限校验系统)。

因为H5使用的webview可以有独立的登录态,如果不加限制太过混乱难以维护,比如:

我们在qq浏览器中打开携程的网站,携程站内第三方登录可以唤起qq,然后登录成功;完了qq浏览器本来也有一个登录态,发现却没有登录,点击一键登录的时候再次唤起了qq登录。

当然,qq作为一个浏览器容器,不应该关注业务的登录,他这样做是没问题的,但是我们自己的一个H5子应用如果登录了的话,便希望将这个登录态同步到native,这里如果native去监控cookie的变化就太复杂了,通用的方案是:

Hybrid APP中,所有的登录走Native提供的登录框

1
Hybrid APP中,所有的登录走Native提供的登录框

每次打开webview native便将当前登录信息写入cookie中,由此前端就具有登录态了,登录框的唤起在接口处统一处理:

JavaScript

/* 无论成功与否皆会关闭登录框 参数包括: success 登录成功的回调 error 登录失败的回调 url 如果没有设置success,或者success执行后没有返回true,则默认跳往此url */ HybridUI.Login = function (opts) { }; //=> requestHybrid({ tagname: 'login', param: { success: function () { }, error: function () { }, url: '...' } }); //与登录接口一致,参数一致 HybridUI.logout = function () { };

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
/*
无论成功与否皆会关闭登录框
参数包括:
success 登录成功的回调
error 登录失败的回调
url 如果没有设置success,或者success执行后没有返回true,则默认跳往此url
*/
HybridUI.Login = function (opts) {
};
//=>
requestHybrid({
     tagname: 'login',
     param: {
         success: function () { },
         error: function () { },
         url: '...'
     }
});
//与登录接口一致,参数一致
HybridUI.logout = function () {
};

API式交互

手白、糯米底层如何做我们无从得知,但我们发现调用Native API接口的方式和我们使用AJAX调用服务器端提供的接口是及其相似的:

图片 8

这里类似的微薄开放平台的接口是这样定义的:

粉丝服务(新手接入指南)

读取接口

接收消息

接收用户私信、关注、取消关注、@等消息接口

写入接口

发送消息

向用户回复私信消息接口

生成带参数的二维码

生成带参数的二维码接口

我们要做的就是通过一种方式创建ajax请求即可:

JavaScript

1
https://api.weibo.com/2/statuses/public_timeline.json

所以我在实际设计Hybrid交互模型时,是以接口为单位进行设计的,比如获取通讯录的总体交互是:

图片 9

一、手Q吃喝玩乐  好友去哪儿九宫格图

下图是手Q吃喝玩乐  好友去哪儿九宫格图的图示:

图片 10

 

从上图我们可以分析出如下需求:

  • 图片大小自适应;
  • 图片个数不同时,图片按照指定方式排列;
  • 图片相邻处有1px空白间隙。

我们以最复杂的6图布局为例,一步一步来看如何以纯CSS实现。

账号切换&注销

账户注销本没有什么注意点,但是因为H5 push了一个个webview页面,这个重新登录后这些页面怎么处理是个问题。

我们这边设计的是一旦重新登录或者注销账户,所有的webview都会被pop掉,然后再新开一个页面,就不会存在一些页面展示怪异的问题了。

格式约定

交互的第一步是设计数据格式,这里分为请求数据格式与响应数据格式,参考ajax的请求模型大概是:

$.ajax(options) ⇒ XMLHttpRequest type (默认值:"GET") HTTP的请求方法(“GET”, “POST”, or other)。 url (默认值:当前url) 请求的url地址。 data (默认值:none) 请求中包含的数据,对于GET请求来说,这是包含查询字符串的url地址,如果是包含的是object的话,$.param会将其转化成string。

1
2
3
4
$.ajax(options) ⇒ XMLHttpRequest
type (默认值:"GET") HTTP的请求方法(“GET”, “POST”, or other)。
url (默认值:当前url) 请求的url地址。
data (默认值:none) 请求中包含的数据,对于GET请求来说,这是包含查询字符串的url地址,如果是包含的是object的话,$.param会将其转化成string。

所以我这边与Native约定的请求模型是:

JavaScript

requestHybrid({ //创建一个新的webview对话框窗口 tagname: 'hybridapi', //请求参数,会被Native使用 param: {}, //Native处理成功后回调前端的方法 callback: function (data) { } });

1
2
3
4
5
6
7
8
9
requestHybrid({
  //创建一个新的webview对话框窗口
  tagname: 'hybridapi',
  //请求参数,会被Native使用
  param: {},
  //Native处理成功后回调前端的方法
  callback: function (data) {
  }
});

这个方法执行会形成一个URL,比如:

hybridschema://hybridapi?callback=hybrid_1446276509894¶m=%7B%22data1%22%3A1%2C%22data2%22%3A2%7D

这里提一点,APP安装后会在手机上注册一个schema,比如淘宝是taobao://,Native会有一个进程监控Webview发出的所有schema://请求,然后分发到“控制器”hybridapi处理程序,Native控制器处理时会需要param提供的参数(encode过),处理结束后将携带数据获取Webview window对象中的callback(hybrid_1446276509894)调用之

数据返回的格式约定是:

JavaScript

{ data: {}, errno: 0, msg: "success" }

1
2
3
4
5
{
  data: {},
  errno: 0,
  msg: "success"
}

真实的数据在data对象中,如果errno不为0的话,便需要提示msg,这里举个例子如果错误码1代表该接口需要升级app才能使用的话:

JavaScript

{ data: {}, errno: 1, msg: "APP版本过低,请升级APP版本" }

1
2
3
4
5
{
  data: {},
  errno: 1,
  msg: "APP版本过低,请升级APP版本"
}

代码实现

这里给一个简单的代码实现,真实代码在APP中会有所变化:

JavaScript

window.Hybrid = window.Hybrid || {}; var bridgePostMsg = function (url) { if ($.os.ios) { window.location = url; } else { var ifr = $('<iframe style="display: none;" src="' + url + '"/>'); $('body').append(ifr); setTimeout(function () { ifr.remove(); }, 1000) } }; var _getHybridUrl = function (params) { var k, paramStr = '', url = 'scheme://'; url += params.tagname + '?t=' + new Date().getTime(); //时间戳,防止url不起效 if (params.callback) { url += '&callback=' + params.callback; delete params.callback; } if (params.param) { paramStr = typeof params.param == 'object' ? JSON.stringify(params.param) : params.param; url += '¶m=' + encodeURIComponent(paramStr); } return url; }; var requestHybrid = function (params) { //生成唯一执行函数,执行后销毁 var tt = (new Date().getTime()); var t = 'hybrid_' + tt; var tmpFn; //处理有回调的情况 if (params.callback) { tmpFn = params.callback; params.callback = t; window.Hybrid[t] = function (data) { tmpFn(data); delete window.Hybrid[t]; } } bridgePostMsg(_getHybridUrl(params)); }; //获取版本信息,约定APP的navigator.userAgent版本包含版本信息:scheme/xx.xx.xx var getHybridInfo = function () { var platform_version = {}; var na = navigator.userAgent; var info = na.match(/scheme/d.d.d/); if (info && info[0]) { info = info[0].split('/'); if (info && info.length == 2) { platform_version.platform = info[0]; platform_version.version = info[1]; } } return platform_version; };

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
window.Hybrid = window.Hybrid || {};
var bridgePostMsg = function (url) {
    if ($.os.ios) {
        window.location = url;
    } else {
        var ifr = $('<iframe style="display: none;" src="' + url + '"/>');
        $('body').append(ifr);
        setTimeout(function () {
            ifr.remove();
        }, 1000)
    }
};
var _getHybridUrl = function (params) {
    var k, paramStr = '', url = 'scheme://';
    url += params.tagname + '?t=' + new Date().getTime(); //时间戳,防止url不起效
    if (params.callback) {
        url += '&callback=' + params.callback;
        delete params.callback;
    }
    if (params.param) {
        paramStr = typeof params.param == 'object' ? JSON.stringify(params.param) : params.param;
        url += '&param=' + encodeURIComponent(paramStr);
    }
    return url;
};
var requestHybrid = function (params) {
    //生成唯一执行函数,执行后销毁
    var tt = (new Date().getTime());
    var t = 'hybrid_' + tt;
    var tmpFn;
 
    //处理有回调的情况
    if (params.callback) {
        tmpFn = params.callback;
        params.callback = t;
        window.Hybrid[t] = function (data) {
            tmpFn(data);
            delete window.Hybrid[t];
        }
    }
    bridgePostMsg(_getHybridUrl(params));
};
//获取版本信息,约定APP的navigator.userAgent版本包含版本信息:scheme/xx.xx.xx
var getHybridInfo = function () {
    var platform_version = {};
    var na = navigator.userAgent;
    var info = na.match(/scheme/d.d.d/);
 
    if (info && info[0]) {
        info = info[0].split('/');
        if (info && info.length == 2) {
            platform_version.platform = info[0];
            platform_version.version = info[1];
        }
    }
    return platform_version;
};

因为Native对于H5来是底层,框架&底层一般来说是不会关注业务实现的,所以真实业务中Native调用H5场景较少,这里不予关注了。

float布局

最容易想到的,也是最简单的方案,就是 float 布局:

  • 图片大小自适应:宽度百分比,高度使用 padding-top 百分比
  • 图片个数不同时,图片按照指定方式排列:使用 nth-child 伪类指定不同情况下的元素大小
  • 图片相邻处有1px空白间隙:使用 border-box + border模拟边框

这里父元素的高度未知,height使用百分比行不通,而padding的百分比值是依据父元素的宽度来计算的,我们可以使用padding-top撑开高度。

让我们一瞅伪码,猛击我看demo

XHTML

<div class="float"> <div class="item">1</div> ... <div class="item">6</div> </div>

1
2
3
4
5
<div class="float">
    <div class="item">1</div>
    ...
    <div class="item">6</div>
</div>

 

CSS

.float { overflow: hidden; } .item { float: left; padding-top: 33.3%; width: 33.3%; border-right: 1px solid #fff; border-top: 1px solid #fff; } .item:nth-child(1) { padding-top: 66.6%; width: 66.6%; } .item:nth-child(2), .item:nth-child(3), .item:nth-child(6) { border-right: 0 none; } .item:nth-child(1), .item:nth-child(2) { border-top: 0 none; }

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
.float {
    overflow: hidden;
}
.item {
    float: left;
    padding-top: 33.3%;
    width: 33.3%;
    border-right: 1px solid #fff;
    border-top: 1px solid #fff;
}
.item:nth-child(1) {
    padding-top: 66.6%;
    width: 66.6%;
}
.item:nth-child(2), .item:nth-child(3), .item:nth-child(6) {
    border-right: 0 none;
}
.item:nth-child(1), .item:nth-child(2) {
    border-top: 0 none;
}

 

实际效果并不理想,如下图:

图片 11

可以看到 float 布局的优点是DOM结构十分简单,缺点是容易出现空白间隙错位,优缺点都十分明显,它更适用于js计算的版本。

公共业务的设计-体系化

在Hybrid架构中(其实就算在传统的业务中也是),会存在很多公共业务,这部分公共业务很多是H5做的(比如注册、地址维护、反馈等,登录是native化了的公共业务),我们一个Hybrid架构要真正的效率高,就得把各种公共业务做好了,不然单是H5做业务,效率未必会真的比Native高多少。

底层框架完善并且统一后,便可以以规范的力量限制各业务开发,在统一的框架下开发出来的公共业务会大大的提升整体工作效率,这里以注册为例,一个公共页面一般来说得设计成这个样子:

公共业务代码,应该可以让人在URL参数上对页面进行一定定制化,这里URL参数一般要独特一些,一面被覆盖,这个设计适用于native页面

1
公共业务代码,应该可以让人在URL参数上对页面进行一定定制化,这里URL参数一般要独特一些,一面被覆盖,这个设计适用于native页面

图片 12

URL中会包含以下参数:

① _hashead 是否有head,默认true

② _hasback 是否包含回退按钮,默认true

③ _backtxt 回退按钮的文案,默认没有,这个时候显示为回退图标

④ _title 标题

⑤ _btntxt 按钮的文案

⑥ _backurl 回退按钮点击时候的跳转,默认为空则执行history.back

⑦ _successurl 点击按钮回调成功时候的跳转,必须

只要公共页面设计为这个样子,就能满足多数业务了,在底层做一些适配,可以很轻易的一套代码同时用于native与H5,这里再举个例子:

如果我们要点击成功后去到一个native页面,如果按照我们之前的设计,我们每个Native页面皆已经URL化了的话,我们完全可以以这种方向跳转:

JavaScript

requestHybrid({ tagname: 'forward', param: { topage: 'nativeUrl', type: 'native' } });

1
2
3
4
5
6
7
requestHybrid({
     tagname: 'forward',
     param: {
         topage: 'nativeUrl',
         type: 'native'
    }
});

这个命令会生成一个这样的url的链接:

_successurl == hybrid://forward?param=%7B%22topage%22%3A%22nativeUrl%22%2C%22type%22%3A%22native%22%7D

完了,在点击回调时要执行一个H5的URL跳转:

JavaScript

window.location = _successurl

1
window.location = _successurl

而根据我们之前的hybrid规范约定,这种请求会被native拦截,于是就跳到了我们想要的native页面,整个这一套东西就是我们所谓的体系化:

图片 13

常用交互API

良好的交互设计是成功的第一步,在真实业务开发中有一些API一定会用到。

flex布局

还有谁?flex!flex布局有以下重要特性

  • 可以将 flex 布局下的元素展示在同一水平、垂直方向上;
  • 可以支持自动换行、换列(移动端-webkit-box暂不支持,好消息是从iOS9.2、Android4.4开始都支持新flex了);
  • 可以指定 flex 布局下的元素如何分配空间,可以让元素自动占满父元素剩余空间;
  • 可以指定 flex 布局下的元素的展示方向,排列方式。

这里面的子元素同一水平、垂直方向展示对我们很有帮助,它使我们更容易控制子元素的排列,而不会错位。

使用 flex 布局与 float 布局不同的地方在于,移动端目前主要还是-webkit-box,因此图片个数不同时,我们需要使用不同的html,组合出不同的块。

离线更新

根据之前的约定,Native中如果存在静态资源,也是按频道划分的:

JavaScript

webapp //根目录 ├─flight ├─hotel //酒店频道 │ │ index.html //业务入口html资源,如果不是单页应用会有多个入口 │ │ main.js //业务所有js资源打包 │ │ │ └─static //静态样式资源 │ ├─css │ ├─hybrid //存储业务定制化类Native Header图标 │ └─images ├─libs │ libs.js //框架所有js资源打包 │ └─static //框架静态资源样式文件 ├─css └─images

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
webapp //根目录
├─flight
├─hotel //酒店频道
│  │  index.html //业务入口html资源,如果不是单页应用会有多个入口
│  │  main.js //业务所有js资源打包
│  │
│  └─static //静态样式资源
│      ├─css
│      ├─hybrid //存储业务定制化类Native Header图标
│      └─images
├─libs
│      libs.js //框架所有js资源打包
└─static //框架静态资源样式文件
    ├─css
    └─images

我们这里制定一个规则,native会过滤某一个规则的请求,检查本地是否有该文件,如果本地有那么就直接读取本地,比如说,我们会将这个类型的请求映射到本地:

JavaScript

//===>> file ===> flight/static/hybrid/icon-search.png

1
2
3
http://domain.com/webapp/flight/static/hybrid/icon-search.png
//===>>
file ===> flight/static/hybrid/icon-search.png

这样在浏览器中便继续读取线上文件,在native中,如果有本地资源,便读取本地资源:

图片 14

但是我们在真实使用场景中却遇到了一些麻烦。

跳转

跳转是Hybrid必用API之一,对前端来说有以下跳转:

① 页面内跳转,与Hybrid无关

② H5跳转Native界面

③ H5新开Webview跳转H5页面,一般为做页面动画切换

如果要使用动画,按业务来说有向前与向后两种,forward&back,所以约定如下,首先是H5跳Native某一个页面

JavaScript

//H5跳Native页面 //=>baidubus://forward?t=1446297487682¶m=%7B%22topage%22%3A%22home%22%2C%22type%22%3A%22h2n%22%2C%22data2%22%3A2%7D requestHybrid({ tagname: 'forward', param: { //要去到的页面 topage: 'home', //跳转方式,H5跳Native type: 'native', //其它参数 data2: 2 } });

1
2
3
4
5
6
7
8
9
10
11
12
13
//H5跳Native页面
//=>baidubus://forward?t=1446297487682&param=%7B%22topage%22%3A%22home%22%2C%22type%22%3A%22h2n%22%2C%22data2%22%3A2%7D
requestHybrid({
    tagname: 'forward',
    param: {
        //要去到的页面
        topage: 'home',
        //跳转方式,H5跳Native
        type: 'native',
        //其它参数
        data2: 2
    }
});

比如携程H5页面要去到酒店Native某一个页面可以这样:

JavaScript

//=>schema://forward?t=1446297653344¶m=%7B%22topage%22%3A%22hotel%2Fdetail%20%20%22%2C%22type%22%3A%22h2n%22%2C%22id%22%3A20151031%7D requestHybrid({ tagname: 'forward', param: { //要去到的页面 topage: 'hotel/detail', //跳转方式,H5跳Native type: 'native', //其它参数 id: 20151031 } });

1
2
3
4
5
6
7
8
9
10
11
12
//=>schema://forward?t=1446297653344&param=%7B%22topage%22%3A%22hotel%2Fdetail%20%20%22%2C%22type%22%3A%22h2n%22%2C%22id%22%3A20151031%7D
requestHybrid({
    tagname: 'forward',
    param: {
        //要去到的页面
        topage: 'hotel/detail',
        //跳转方式,H5跳Native
        type: 'native',
        //其它参数
        id: 20151031
    }
});

比如H5新开Webview的方式跳转H5页面便可以这样:

JavaScript

requestHybrid({ tagname: 'forward', param: { //要去到的页面,首先找到hotel频道,然后定位到detail模块 topage: 'hotel/detail ', //跳转方式,H5新开Webview跳转,最后装载H5页面 type: 'webview', //其它参数 id: 20151031 } });

1
2
3
4
5
6
7
8
9
10
11
requestHybrid({
    tagname: 'forward',
    param: {
        //要去到的页面,首先找到hotel频道,然后定位到detail模块
        topage: 'hotel/detail  ',
        //跳转方式,H5新开Webview跳转,最后装载H5页面
        type: 'webview',
        //其它参数
        id: 20151031
    }
});

back与forward一致,我们甚至会有animattype参数决定切换页面时的动画效果,真实使用时可能会封装全局方法略去tagname的细节,这时就和糯米对外释放的接口差不多了。

flex 布局上下划分

来,我们快动手分块吧!新解决方案出现导致的肾上腺素上升,使我们迫不及待使用了传统css文档流自上而下的方式来划分,我称为上下划分,如下图:

图片 15

上面一块包含左侧1个2/3的大块,右侧2个1/3的小块,下面一块则是3个1/3的小块。

我们指定2/3的大块宽度是66.6%,1/3的小块宽度是33.3%(实际可以使用-webkit-box-flex来分配,这里为了下面的计算方便)。

来看下实际效果,你也可以猛击demo来查看源码:

图片 16

demo中我们看到中间那条竖空白间隙错位了,为什么?按照预期我们上面块左侧宽度66.6%,下面块左侧宽度33.3%

  • 33.3%,两个宽度应该相等才对。

然而我们忽略了flex一个重要特性,子元素会自动占满父元素剩余空间,这时子元素宽度计算受flex控制,下面块的3个子元素宽度计算并非一定是相等的,会有些许差异,此时66.6% != 33.3% + 33.3%

怎么破!别急,我们刚刚只是受到了肾上激素的影响,让我们冷静下来重新思考如何划分。

本文由澳门新葡亰手机版发布于web前端,转载请注明出处:浅谈Hybrid技术的设计与实现,浅谈Hybrid技术的设

上一篇:App技术解析,isolate的表现和作用 下一篇:没有了
猜你喜欢
热门排行
精彩图文