• 1.5 版本更新说明 BUI 1.5版本以后变化很大,统一新的风格,新的规范750,新增基于Dom的数据驱动,完善了单页路由页面的生命周期等等,在...后续我们还会整理一些实战类的教程,欢迎关注BUI Webapp专栏。 一...

    原文地址: https://segmentfault.com/a/1190000012994082

     

    1.5 版本更新说明

    BUI 1.5版本以后变化很大,统一新的风格,新的规范750,新增基于Dom的数据驱动,完善了单页路由页面的生命周期等等,在好用的路上越走越远,如果你也觉得好用,帮我们推荐给您身边的朋友,谢谢。后续我们还会整理一些实战类的教程,欢迎关注BUI Webapp专栏

    一、案例代表

    点击预览QQ交互效果GIF

    这是你看下去的动力, 我用BUI仿照QQ的手机截图做出来的一个demo, 包含QQ的常见交互, 侧滑边栏,TAB切换,侧滑列表,下拉刷新,下拉菜单,弹窗搜索等交互操作, 这几种操作很多UI框架都有, 但几种操作结合在一块, 不同方向之间的交互冲突, 不是那么简单的事情. 使用BUI耗时1天.

    通过这个看似简单的例子, 使用BUI快速开发出来的应用是可以上得了台面的.在没有设计稿的情况下, 我们可以仿照任何一款APP开发,并且按照APP的相同比例完美还原. 另外一个是在各种复杂的手势操作交互里面, BUI游刃有余.

    请使用手机扫码操作看看.

    QQ演示地址

    建议扫码在手机预览, PC预览不支持手势操作.

    点击PC预览Demo

    BUI控件demo

    二、前言

    今天的主角就是BUI交互框架, 又不仅仅只是框架, 这是一整套快速开发Webapp的解决方案. 请查看BUI官网, 里面有DEMO演示, 给你最直观的感受.

    如果你也跟我一样在寻找一款快速开发的Webapp框架, 相信我,你来对地方了. 欢迎加入BUI 移动开发交流群: 691560280满 
    BUI 移动开发交流群2: 4170980

    我自己从2011年开始接触移动混合app开发至今, 开发的应用也有几十个了, 这些经验可能对别人也会有所帮助. 于是我把它整理出来, 围绕着快速开发,BUI做了很多事情, 看完你就会明白, BUI的快是有意义的.

    面向的开发者

    • 混合App开发者
    • 后端开发者
    • 前端
    • 美工

    我对框架的要求

    我找过很多框架, 对框架有一些要求:

    1. 简单学习上手快;
    2. 能够轻松定制UI;
    3. 开发一次,跨平台全适配,什么安卓,IOS,微信,淘宝,支付宝,钉钉,浏览器等等;
    4. 控件要多,至少满足平常所需;
    5. 能结合第三方打包平台,打包成独立应用;
    6. 有案例或者模板可以参考;
    7. 支持物理按键后退;
    8. 支持后退刷新;
    9. 支持后退到指定页面带动画;
    10. 模块化开发;
    11. 反应速度快;

    ...

    这样的要求不过分吧? 
    但发现每个UI框架都有自己的定位, 跟我要的还不太一样, 于是我们只能自己造轮子.
    既然自己造轮子,那就要先做最适合自己的,然后才是适合别人. 这里有必要交待一下背景.

    三、背景

    早在2011年, 品高公司就开始接触移动互联网, 并有了第一个基于Cordova的混合app开发框架及打包平台--Bingotouch (那个时候除了Appcan,没有像Dcloud,APICloud等比较成熟的平台) ,为了配合Bingotouch开发框架, 我们需要有一个UI, 于是我们有了一个简单的UI, 那时只有一些简单的基础控件, 简单的适配(可以在打包自适应,但无法在浏览器预览), 页面切换传参使用原生的切换, 其它复杂点的就用第三方的插件, 下拉刷新就用iscroll, 投入到项目开发中就没去管UI了, 一晃就4年过去了, 简直就是奇迹.

    但随着混合应用的技术推广及系统的升级,手机屏幕越来越大,我们的UI存在的一些不足,我们意识到,我们的UI必须升级了. 经过4年的移动开发项目经验沉淀, 于是2015年底我们就开始着手UI的改造.

    四、移动开发的难点

    这里顺便交待一下我们的旧UI存在的问题吧.

    1.viewport问题

    旧UI采用viewport固定宽度的方式适应, 把设计稿更改成320大小, 然后我们按这个大小量取间隙,还原设计稿, 这样会导致在浏览器整个页面变大, 之前不考虑浏览器,所以问题还不大, 但随着viewport在不同手机设备的表现, 这种方式瓶颈越来越大, if else 越来越多.

    2.UI组件少

    早期的时候,基于zepto的控件还要适应移动端, 是少之又少, 所以我们经常需要上网找或者自己写控件, 这样就造成每个控件的使用方式不一, 兼容不一, 较难上手.

    3.不同平台需要多次开发

    由于页面切换是使用原生切换,这样体验较好, 但是也带来一个问题,跟框架结合过于紧密, 有些项目需求, 开发以后,客户要求在微信上线, 这样就得开发2次, 如果还要在其它平台呢? 不敢想象.

    ...

    正是因为有了这些问题, 才让我们的新BUI适应性越来越强.

    五、设计思路

    很多看完文档不太理解BUI的更多是Native模块, 这里是我们区别于其它webapp开发框架的地方, BUI的一个控件或者一个方法不止做一件事情. 我们这里主要分析一下Native模块的设计.

    前面谈到我们的页面切换传参是用的原生切换, 在安卓2.多的系统,如果使用location.href跳转会泛白,单页在不同安卓下的表现也不尽完美, 所以我们这里采用的原生, 而原生在web浏览器是不能运行的. 于是我们想采用一种兼容的方式, 像混合应用一样, 中间做一层转换, 这样就可以各取所需, 需要web时, 整体切换成web.

    Method <- web <- BUI -> Bingotouch -> Native

    1. 思路1

    BUI设计思路1

    思路解析: bui 通过 bui.isWebapp (旧版是bui.debug) 来选择是web,或者native, 所有native模块需要在 bui.ready 里面去初始化, 就这样,我们把Bingotouch 里面常用的交互, 页面跳转, 传参, 刷新, 回退, 请求, 上传, 下载 等常用的功能模块做了封装统一API, 每个native模块的方法都对应两个不同的方法, 这样在使用过程,用户不需要关注是原生还是web, 只需要知道,我在浏览器运行, 就设置 bui.isWebapp 为true, 需要打包, 就用 bui.isWebapp 为false;

    BUI设计思路2

    以上就是我们的BUI 为我们公司的Bingotouch而实现的一套UI思路, 细心的你可能会发现, Bingotouch 跟互联网上的第三方平台很像, 没错的, 但是我们出来比较早. 这点我觉得很引以为豪. 所以看下那个设计思路, 我们也是为了扩展到第三方平台预留了接口. 于是我们有了不同版本的 bui.js .

    2. 思路2

    BUI设计思路3

    场景1: 客户指定要使用第三方平台打包;

    我们的Bingotouch就派不上用场,即使我们很优秀, 但是客户不放心, 用第三方平台后面可以不依赖于某一家公司, 可以很容易找到其他开发者, 客户的担心也不无道理.

    第三方平台的出现方便了开发者,但也带来了新的难题, 一个第三方平台,会有自己的开发生态, 工具, API, UI, 开发者要学习的东西太多.

    于是我们BUI又可以派上用场了, 我们还是用我们熟悉的方式开发, 只是特殊部分原生接口,使用第三方的就可以了, 这样你只需要学习一次BUI,就能开发其它平台,使用其它平台的部分原生接口,想想是很美好的事情. 后面发现每个平台的上传,下载,文件处理等的方式都不同, 处理起来很耗费时间, 针对第三方平台我们精简了部分Native方法, 只保留了 页面加载,传参,后退,请求,刷新这些.

    这样, 客户不管指定哪个平台,都可以使用我们的UI来做开发交互, 开发人员都不用再学习新的UI, 能减少一点是一点啊.

    六、框架特点

    围绕这个想法去设计, 再分析了互联网上的一些UI的特点, 我们的框架应该是这样子的:
    介于webapp跟混合app开发之间, 大部分应用有80%以上的功能都是由UI实现的, 这样通过学习一次BUI, 你就可以游刃于不同平台之间.

    BUI成本优势

    1. 简单学习,快速上手

    在软件公司里面, 开发者占多数以及人员的流动等因素, 如果开发者愿意去学习使用, 可以解决招不到合适的前端问题. 所以学习要快,简单.

    技术选型

    我们在技术上没有依赖于vue,react等先进理念, 我们就是要简单, Dom是最基础也是最容易理解的, 所以我们基于zepto或者jquery.

    工具

    开发者习惯用什么工具,就用什么工具.习惯用什么 webpack,gulp,sass,less 完全由自己做主. 但是如果使用我们推荐的sublimetext工具, 我们有针对这个工具的一个插件, 可以快速书写,事半功倍.

    丰富的文档及入门视频

    BUI的入门文档只需要5分钟 
    BUI的控件API文档 
    BUI的规范文档
    BUI的FAQ

    2. 多终端多平台适配

    我们采用独有的规范,使用REM适配,开发出来的页面,能够在各种安卓IOS系统,webkit浏览器(淘宝,微信,QQ,钉钉),第三方打包平台(Dcloud,APICloud,APPCan等) 不同分辨率,保持一致的缩放效果. 跟web保持一致的切图习惯,只是在做单位转换的时候, 是基于540px设计稿,1rem=100px
    这是很多UI欠缺的, 给你一个设计稿,没有什么指引告诉你图要怎么切, 大部分是采用响应式自适应出来的效果, 看上去一样,实际效果是跟效果图有出入的.

    如图, 其它UI的适配的高度是固定的, 随着屏幕增高, 底部的空白会越来越多, 而BUI是整体等比缩放, 像一张大图缩放到合适的屏幕一样. 真正是一次开发,多平台适配.

    其它UI的适配:

    其它UI的适配

    BUI的适配:

    BUI的适配

    3. 丰富的交互组件

    BUI控件演示Demo

    前面我们也说过,旧UI我们需要经常找插件,找来的插件也不一定能用, 调用系统原生的交互,在安卓跟ios会有不同的表现, 为了避免这种情况, 我们把互联网上常见的插件都统一开发出来, 一致的交互, 一致的使用方式, 一致的API.

    BUI的组件还有些不太一样的地方, 我们关注控件的交互,主张相同交互由同一个控件实现. 我们的组件是内容跟结构交互分离, 一个组件可以做多件事情, 例如:

    bui.slide 是一个焦点图组件, 它除了自身支持, 横向,纵向,全屏,自动播放等功能以外, 我们稍微改变了参数, 它就变成了 tab 组件.

    **(这里不能直接上传gif交互图,我把重要的交互展示一下,想看更多交互请直接点击预览交互效果)**

    bui.slide 焦点图控件

    预览交互效果

    js:
    var uiSlide = bui.slide({
        id:"#uiSlide",
        height:200
    })
    html:
    <div id="uiSlide" class="bui-slide">
        <div class="bui-slide-main">
            <ul>
                <li>
                    <!--第1屏-->
                    <img src="" alt="">
                    <div class="bui-slide-title">图片标题</div>
                </li>
            </ul>
        </div>
        <!-- 分屏菜单 -->
        <div class="bui-slide-head">
            <ul >
                <li>1</li>
            </ul>
        </div>
    </div>

    TAB 选项卡

    TAB初始化

    js: 
    var uiSlideTab = bui.slide({
        id:"#uiSlideTab",
        menu:".bui-nav",
        children:".bui-tab-main ul",
        scroll: true
    })
    html:
    <div id="uiSlide" class="bui-tab">
        <div class="bui-tab-head">
            <ul class="bui-nav">
                <!-- 分屏菜单 active 是激活的TAB样式 -->
                <li class="bui-btn active">Tab1</li>
            </ul>
        </div>
        <div class="bui-tab-main">
            <ul>
                <li>
                    第1屏
                </li>
            </ul>
        </div>
    </div>

    仔细观察下这两个的结构及交互,变的只是父层的样式, 其它结构及操作都是一样的. 我们把TAB的结构再拆分一下, 就变成了 TAB在顶部以及在底部的效果.

    TAB在顶部
    TAB在顶部

    TAB在底部
    TAB在底部

    TAB在侧边
    TAB在侧边

    这样是方便了,但是要记住的参数很多,怎么破? 这就要谈到我们的BUI Fast插件了, 一个快速书写的 Sublimetext插件, 这个后面篇幅再介绍. 我们把比较重要的组件给大家介绍一下.

    还有什么是bui.slide能做的? 例如: 微信里面的推广,经常是整屏往上滑动, 我还用过 bui.slide 去拓展了一个简单的有动画效果的路由. 发挥你的想象前, 先仔细了解控件的特性. 后面我们有自己更简单的单页路由.

    bui.list 下拉刷新及上拉加载控件

    bui.list是基于 bui.scroll 扩展的一个加载分页及刷新的一个控件, 默认把分页都处理好了,你只需要配置一个数据请求的地址, 能返回一个数组就行了, 如果返回的字段不一样, 也是提供了字段映射的配置, 开发一个加载及下拉刷新功能的列表, 只要5分钟. 如果这个满足不了你的需求, 你可以再看 bui.scroll 及 bui.pullrefresh 这两个控件.

    bui.list

    bui.dialog 弹出层组件

    bui.dialog 弹出层插件同样是一个扩展性特别强的插件, 支持从不同方向进入, 支持关闭打开, 支持全屏等, 支持动态创建以及静态渲染,
    这两者的区别 例如,

    动态渲染
    bui.confirm, bui.alert, bui.prompt 都是基于dialog动态创建的控件, 这种方式简单,只需要传入content参数;
    静态渲染
    还有bui.select,bui.actionsheet, bui.pickerdate 等控件. select及actionsheet 的底层都是一个静态渲染的对话框, 这样有个好处就是, 对话框的内容都自由定义.

    预览交互效果GIF

    bui.select 选择控件

    选择控件,支持单选,多选, 支持弹窗或者不弹窗, 支持静态或者动态渲染.

    图片描述

    bui.actionsheet 上拉菜单控件

    上拉菜单控件, 常用于分享

    图片描述

    bui.swipe 滑动组件

    bui.swipe 也是很强大的一个控件, 解决同一个页面的各种手势操作冲突. 像 bui.sidebar ,bui.listview 都是基于bui.swipe扩展的插件.

    图片描述

    bui.sidebar 侧边栏组件

    支持左边跟右边,支持同时, 但还是建议同一个页面不要出现太多这类交互.

     

    bui.listview 侧滑列表组件

    侧滑列表控件,支持菜单在左边或者右边

    图片描述

    bui.hint 自动消失提醒组件

    消息提醒自动消失, 支持上中下等方向, 并且支持自动关闭或者手动关闭, 可以指定在某个容器内.

    图片描述

    bui.accordion 折叠组件

    折叠菜单, 显示隐藏, 支持全部显示,或者一次只能显示一个.

    图片描述

    bui.dropdown 下拉菜单组件

    下拉菜单, 常用于搜索旁边的选择, 选项不宜过多.

    图片描述
    这些都是基本的组件, BUI官网其实还有很多, 就不一一列举了.

    4. 轻松定制UI

    BUI是有规范可循的,这个在输出设计稿的时候,尤其有用. 而且BUI更多的是关注UI交互这块, 只要遵循BUI的结构规范, 里面的内容是可以自由定制的, UI也是随你怎么修改,只要ID不变, 交互就不变.

    5. 快速开发

    重头戏来了, 前面这些都只是铺垫, 只有简单的文档, 丰富的组件, 这些每个框架都有, 不能算快. 
    我们围绕着开发人员快速开发, 做了很多事情, 让你如虎添翼.

    5.1 BUIFast插件

    BUIFast 是Sublimetext的一个插件, 前面我们也说了,我们并不要求用户使用某个工具, 但如果用户使用我们推荐的工具, 那就是如虎添翼. Sublimetext是一个优秀的编辑器. 安装好BUIFast插件以后, 你可以使用BUI的快速书写.

    规则如下: 
    ui- 生成结构, bui- 生成脚本

    ui-html 生成BUI的标准引用
    ui-page 生成BUI标准结构页面

    ui-控件名 生成 控件的结构;
    bui-控件名 生成 控件的初始化; 
    两个前呼后应.

    后面我们新增了 bu-控件名-demo 直接生成示例代码. 所以前面说的, 你根本不需要去记住结构,你只需要记住有什么控件名. 比方 bui-slide-tab

    点击预览效果22

    5.2 buijs Node命令行工具

    全局安装buijs以后,每次创建如果有新版本都会从github获取, 可以在任意地方创建, 并且可以指定模板及打包平台.

    安装

    sudo npm install -g buijs

    简单创建工程包(默认webapp平台)

    buijs create demo

    指定模板 
    同一个工程可以重复新增模板, main- 开头会覆盖main 模块, page-开头是新增模块. 点击查看更多模板预览 部分模板我们还增加了常用的交互处理, 比如登录输入框的删除, 注册发送验证码的倒计时, 如果不需要可以自行删除.

    buijs create demo -t main-tab

    指定dcloud平台
    指定平台以后,创建的工程可以直接覆盖到平台新创建的应用目录, 默认bui绑定了物理后退按键的处理.

    buijs create demo -p dcloud

    点击预览效果23

    5.3 模板库

    模板库有2个,一个是配合buijs工具创建的, 但由于每次创建都会获取最新,如果太多模板,这里创建工程就会偏慢, 所以我们只把常用的模板放github上面, 我们还有一个新模板库, 那里下载下来每个都是 CSS,js,html 一起的.

    模板库

    5.4 插件库

    bui的官方组件只是一些基本的组件, 后续还会扩展.

    5.5 案例库

    除了插件,模板,官网还提供了一个案例库, 这个案例是一些通用的例子, 下载下来就能拿去开发. 
    这里比较有代表性的一个案例是仿照QQ的一个交互, 交互复杂,但开发起来我们只耗时1天.

    BUI代表案例QQ

    点击预览
    建议扫码在手机预览, PC预览不支持手势操作.

    七、设计思路改进

    1. 去平台化

    从BUI出来诞生到现在, 在品高内部已经两年了, 服务了近百个项目, 其中也暴露出来了一些问题.

    1.第三方打包平台如雨后春笋般增长, 我们的兼容何时才休?

    用户在做开发的时候,一开始选择了平台其实也不会再转换其它平台了, 虽然我们提供了这种可能, 对于用户来说, 在webapp及打包平台间切换用场会比 APICloud 平台转换到 Dcloud平台之类的场景要多得多, 所以我们目前只兼容 Bingotouch, APICloud, Dcloud 有对应的 bui.js , 其它平台暂时不考虑.

    2.由于我们基于DOM开发,入门门槛低,带来的问题是开发过程中的代码质量无法保证;
    3.每个人喜欢用的模块化不一样, 有人喜欢用requirejs, 有人喜欢用seajs, 同样的模块不能在项目之间共享;

    2. 单页路由

    在用第三方平台的原生跳转里面, 也有一定的局限性, 比方, 后退刷新, 后退多层到指定页面 等, 这些每个平台的处理都不一样, 而且有的都不允许这么处理. 我们需要更灵活的路由, 支持效果自定义, 支持后退刷新, 支持后退到指定页面, 支持物理后退 等, 这一切创建对应工程包的时候, 你就已经拥有.

    路由效果

    这里我们默认采用的是微信的切换效果, 你还可以选择其它交互, 例如 dcloud 的 cover, QQ 的slide 切换效果, 这些效果都是为了让你的应用更好的嵌入对应的平台. 这种特别在原生跟轻应用之间切换较为常用.

    预览交互效果26

    3. 模块化

    我们使用我们自己的模块化,跟路由一起配合使用, 开发的模块在项目之间的共享成为了可能, 我们还按照requirejs,seajs 的接口设置, 可以兼容之前的模块.

    4. 路由及模块化的原理

    当你打开index.html的时候,就会自动加载main模块, 模块的命名, 除了main, 其它匿名模块默认都是.html前面的路径名, 比方: main 模块有个按钮, 按钮有个链接(注意不能使用a标签)

    main模块, 路径: pages/main/main.html

    <div class="bui-btn" href="pages/sidebar/sidebar.html">跳转到sidebar</div>

    点击会自动跳转到 pages/sidebar/sidebar.html , 这时会自动加载 pages/sidebar/sidebar.js

    sidebar.js 路径: pages/sidebar/sidebar.js

    loader.define(function(require,exports,module){
        
        module.exports = {};
    })

    这样, 如果其它页面要调用sidebar的模块

    loader.require("pages/sidebar/sidebar",function(sidebar){
       //  
    })

    这是路由最简单的用法, 当然他还有很多其它定义, 具体需要自己查看API了.

    路由

    八、总结

    与其说bui是一个交互框架,我觉得我们更像是一个移动快速开发解决方案, 围绕开发过程中的效率,一点一点的进步优化, 我们也针对了常用的平台的快速创建工程包, 创建完覆盖到对应的平台应用包里面就能使用了, 是不是开发最快的webapp框架? 我希望是, 但我更希望整理的这些内容对别人有所帮助.

    BUI的目的不是要成为一个很优秀的框架, 而是可以帮助大家解决80%问题的框架.

    一个人快, 节省的只是一个项目的时间, 如果每个人都能开发更快, 节省的是N个项目的时间. 后面我们会在 segmentfault的 BUI的专栏 里,把一些常用的技巧,及使用上的FAQ整理一下, 欢迎一起理性探讨.

    展开全文
  • 什么用mui开发webAPP只用HTML5做app带来的问题HTML5plus RuntimeNative.js 只用HTML5做app带来的问题 HTML5过去被称为有“性工能”障碍,即性能不如原生,工具不如原生、功能不如原生。 HTML5plus Runtime ...

    只用HTML5做app带来的问题

    HTML5过去被称为有“性工能”障碍,即性能不如原生,工具不如原生、功能不如原生。
    在这里插入图片描述

    HTML5plus Runtime

    HTML5plus Runtime,简称5+ Runtime,是运行于手机端的强化web引擎,除了支持标准HTML5外,还支持更多扩展的js api,使得js的能力不输于原生。5+ Runtime内置于HBuilder,在真机运行、打包时自动挂载

    在app开发中,若要使用HTML5+扩展api,必须等plusready事件发生后才能正常使用,否则可能会报“plus is not defined”的错误; mui为简化开发,将plusReady事件封装成了mui.plusReady()方法,凡涉及到HTML5+的api,建议都写在mui.plusReady方法中
    在这里插入图片描述

    Native.js

    原生API在iOS和Android上各自有40多万,有些API并不常用,而且不具有跨平台特性,比如ios的game center api。太多的API封装到HTML5plus里,会过多增加runtime的体积,但若有需求要使用这些api又很麻烦。

    一种把40w原生API映射为JS API的技术

    Native.js技术,简称NJS,是一种将手机操作系统的原生对象转义,映射为JS对象,在JS里编写原生代码的技术

    展开全文
  • webApp开发心得

    2018-08-29 12:38:53
    从事单页相关的开发一年有余,期间无比的推崇webapp的网站模式,也整理了很多移动开发的知识点,但是现在回过头来看,webapp究竟是好还是不好真是一言难尽哟! webapp使用JavaScript修改页面;紧接着再从服务器传递...

    从事单页相关的开发一年有余,期间无比的推崇webapp的网站模式,也整理了很多移动开发的知识点,但是现在回过头来看,webapp究竟是好还是不好真是一言难尽哟!

    webapp使用JavaScript修改页面;紧接着再从服务器传递更多数据然后再修改页面,如此循环。

    从性能的角度看,在现代浏览器中单页面Web App已经能够和普通native应用程序相媲美,而且几乎所有的操作系统都支持现代的浏览器。

    所以,很多人认为webapp是HTML5流行过程中最大的赢家,那么他有哪些特定呢?

    SPA(single page application),即单页webapp,它具有以下优点:

    用户体验,对于内容的改动不需要加载整个页面。这样不会出现白页情况,页面与页面无缝切换,甚至带有一定动画效果。

    请求量少,请求内容无需服务器解析,对服务器压力较小,消耗更少的带宽,比如每次不需要接收完整的html结构,而只需要json数据。

    当然,单页应用也不是完美无瑕的,他也具有以下问题:

    由于历史原因,单页应用对SEO支持不是太好,需要对SEO做特殊处理。

    首次加载量过大,首屏加载慢,所以首屏需要做特殊处理。

    本身入门门槛就高,加之view编码需要释放资源,以免heap值过高,对编码人员的要求较高。

    现状

    传说中的webapp足以媲美native app,事实上这个足以还有很大的距离,预计这个“足以”需要用2-3年时间填平,所以事实是什么呢?

    事实上移动端的webapp模式的网站很少很少,一淘半年前还是,这两天一看又变回来了,小钗虽然对webapp抱有信心,但是信心从何而来呢?

    携程webapp独树一帜,去哪儿ipad介入webapp,但是国内主流网站依旧是传统网站,主要原因不过有二:

    ① SEO

    ② 不想吃螃蟹

    所以,携程的webapp在国内,何其可贵,说到这里,我都要哭出来了......

    优劣之分

    孰优孰劣非是小钗可以论断,求稳,webapp不比传统网站;求SEO,webapp需要其它解决方案;说垃圾收集,webapp需要自己释放资源。

    说体验,webapp需要考虑首屏加载;说动画,webapp要考虑低端手机,所以webapp还有很长一段路需要走!

    现在的webapp效果不可媲美native app,总有一天,当webapp不再制约于网络、设备,那么webapp的春天不会远。

    虽说如此,现阶段webapp也会有许多优化心得、奇技淫巧可以拿出来说说的,这里小钗做一次分享,希望可以对webapp的同学有所帮助。 

    网络传输优化

    综述

    前端优化分为两个切入点:网络传输与DOM操作,而网络传输是制约一个网站速度的主要因素。

    网络传输的优化要点是,零请求,无流量,其意是最大程度的减少请求数,降低请求量。

    对webapp模式的应用来说,首屏加载慢是一个不可避免的问题,所以提升webapp首屏加载速度是提升整体网站速度的关键。

    fake页-首屏加速

    以上是一个网站首页的加载时间,我们分别取其150kb与30kb网速的加载速度,可以看出会慢!若他是webapp,我们可以做一些优化

    我们应该避免页面长时间白页,这个时候便提出了fake页的概念。页面渲染只需要完整的HTML以及CSS,这个便是第一个优化点。

    从数据请求数以及请求量来说,webapp首页的响应应该比较慢,若是任由js加载完成再渲染页面,用户很有可能失去耐心。

    但是从DOMContentLoaded来看,首页事实上页面响应比较迅速,所以这个加载结束后页面第一屏便渲染结束,然后再异步加载js,当js改变后再动态改变dom结构中的一些关键点

    这个时候一个静态HTML页面,装载首屏的基本内容,让首页快速显示

    然后js加载结束后会马上重新渲染整个页面,这个样子,用户就可以很快的看到页面响应,给用户一个快的错觉,给人感觉快得多。

    降低请求数

    由webapp首页来说,不可避免的使用的js文件较多,这些文件分为两类:

    ① 框架js-css

    ② 各个业务团队js-css

    所以可以限定每个业务团队只会加载这四个文件,以最小降低请求数,这里又涉及到并行加载,数量与容量有一个临界值,如何取这个临界值需要各位自己去实验 

    降低请求量

    虽说图片压缩是不必说的事情,但是总会有些时候你会发现一些网站的图片尺寸很大,这个需要处理,而且必须处理。

    以框架库为例,除了核心包以外,不需要的UI或者功能库可以剔除,用到了再动态加载,减少首次加载量,这个一开始就得做好,做不好后期就不好改

    以业务团队为例,首次加载的js与html模板会将常用的几个页面压缩合并,其它页面访问时再请求,若是想提升首屏加载便可以只下载需要的页面文件。

    另外,以下两点尤其需要注意:

    ① 若是你们是要的还是jQuery库的话,可以考虑换成zepto了

    ② 勿胡乱引用第三方库,若是要引用一定是读懂源码的情况下重写使用之,这样的好处是,吃得透,万一有问题,能改,而不是没办法又换库

    缓存Ajax/localstorage

    该方案的原理与前面类似,我们发送Ajax请求时候,应该缓存一些非实时数据,比如城市信息和常用联系人,但是我们只能缓存非敏感信息,

    产品搜索页至列表页的请求数据会缓存30s-60s,若是过期时间内用户回到列表页的话不会重新请求数据

    这对服务器压力,页面响应皆是有利的,这个在30s内事实上意义不大,可以减少一次请求。

    另外,对于get和post的效率,曾经有人做过一次测试:

    get100次平均耗时323ms;post100次平均耗时589ms,所以post方式是比get慢的,但post请求的优点是安全,并且参数没有长度限制。

    是选择post还是选择get,皆需要处理,避免截断url,或者处处post。-

    lazyload

    只显示首屏页面,其它内容需要时再加载,比如列表页、图片lazyload,皆需要做

    DOM操作优化

    综述

    DOM操作主要分为页面渲染与资源清理(heap控制),两者之间又相辅相成,若是DOM操作一块处理不好,其产生的感觉就不再是慢,而是卡

    所以DOM操作优化的主要目的就是消灭页面卡的问题,这个在移动端尤为重要。

    关于页面渲染

    浏览器会解析三个东西:HTML、Javascript、CSS

    浏览器首先会根据HTML生成DOM Tree,其次会根据CSS生成CSS Rule Tree,javascript可以通过DOM API与CSS API操作DOM Tree与CSS Rule Tree,从而引起页面变化。

    浏览器解析结束会通过DOM Tree与CSS Rule Tree形成render tree,只有display不为none的元素才会形成render Tree,render Tree形成后浏览器会调用GUI绘制页面,在此之前做的一件事情便是layout或者说reflow。上面的描述简单而言可以分为以下流程:

    l  生成DOM树

    l  计算CSS样式

    l  构建render tree

    l  reflow,定位元素位置大小

    l  绘制页面

    在这个过程中,若是javascript动态改变DOM Tree便会引起reflow

    页面中的元素改变,只要不影响尺寸,比如只是颜色改变只会引起repaint不会引起回流

    否则,reflow不可避免,这个时候便需要重新计算形成render Tree

    reflow分为局部回流与全局回流,会影响下面的,不会影响上面的元素

    reflow耗用的系统资源较大,DOM Tree中受到影响的节点皆会reflow,然后影响其子节点最坏的情况是所有节点reflow,该问题引发的现象便是低性能的电脑风扇不停的转,手机变得很热,并且非常耗电,以下操作可能引起reflow

    l  操作dom结构

    l  动画

    l  DOM样式修改

    l  获取元素尺寸的API

    减少使用定位属性(fixed/absolute)

    static元素处于文档流中,其渲染速度是最快的,我们做过一个测试:

    100个absolute元素与100个static元素渲染时差在0.01-0.007ms

    100000个元素渲染差距便增至30ms左右,这个微小的时差在移动端变得尤为明显,比如:

    小米/三星手机(1000左右),便存在明显的渲染问题,具体表现为:

    l  定位元素在手机上不能显示。

    l  定位元素动画效果失效。

    以上问题便是UI渲染失效多导致,最好的解决方案是减少使用定位元素,否则只能引起强烈reflow才能解决。

    另外,产品经常会有fixed的相关需求,比如支付按钮一直出现在低端,这个需求会造成两个问题:

    l  fixed元素遭遇文本框时失效,可能会飘到页面中间阻挡输入

    l  影响效率

    问题一原因与移动端的实现有关,暂时没有完美的解决方案,问题二便与渲染直接关联

    滚屏时,页面上所有的像素会跟着滚动,显卡对全屏幕上下移动的处理很快,但是若是出现一个fixed元素或者有元素不跟着一起滚动,那么滚动对手机浏览器来说就是一个负担,这种滚动的性能甚至体现在了iphone 4s,因为滚动可能会造成reflow,这个现象体现在:

    使用absolute配合javascript模拟fixed效果时,会有断片的效果,该问题在iphone5s便不会出现这个问题。

    奇技淫巧

    当然,我们不能忽略产品的需求,fixed类需求应该在技术上得到解决,还用户一个良好的体验。

    虚拟键盘导致fixed元素错位

    fixed元素一定会伴随虚拟键盘的出现,但是虚拟键盘只是“贴”在了viewport上,表面上不会对dom产生“任何”影响,但是这个时候fixed元素表现却变得怪异起来,会错位。

    应用层面解决问题方案是,虚拟键盘弹出时将fixed元素设置为static,虚拟键盘消失时候设置回来。

    由于虚拟键盘出现并未抛出事件,而检测scroll或者resize事件,皆会有一定延迟,会出现闪烁现象,所以现有最好的方案是setinterval定时器监控当前获取焦点元素是否为文本元素,若是是的话便需要处理,如此便可解决fixed元素错误问题。

    fixed元素滑动惯性平滑度

    我们常常遇到这种产品需求,tab标签栏开始固定,当滚动向下超过该标签栏后便会变成fixed元素,一直出现在头部,这样的需求在电脑上没有问题,但是在iPhone5s以下的手机常常会出现小范围错位或者快速移动大范围错位的问题。

    这个时候我们可以引起reflow迫使浏览器重绘以解决这个问题,这里推荐一个奇怪的hack写法:同时设置三个image元素的src属性,便可以全范围解决该难题,  该方案被团队证实并得到应用。

    //三图片src,引发reflow,处理fixed方案惯性问题

    var el = this.els.ctlc.find('img');

    $(el[0]).attr("src", 'http://res.m.ctrip.com/html5/Content/images/144.png');

    $(el[1]).attr("src", 'http://res.m.ctrip.com/html5/Content/images/144.png');

    $(el[2]).attr("src", 'http://res.m.ctrip.com/html5/Content/images/144.png');

    另外,上图中的tab标签下面的蓝线具有动画,但是在小米或者三星手机上可能不会移动,这个时候也可以动态引起reflow解决这个BUG。

    其它

    l  CSS选择器尽量使用id与class,避免过度层叠

    l  避免使用数值,比如:border: none不会引起渲染,而boder: 0会

    l  动画时候让元素脱离文档流,以免导致大量reflow

    l  避免逐条修改DOM样式,改以className实现同样功能

    l  操作DOM时将display设置为none,因为这种元素不会影响渲染,或者操作fragment对象取代操作显示在页面上的DOM

    l  避免将获取DOM样式属性的操作写在循环中,可能引起重复reflow

    内存资源优化

    移动端的javascript

    首先,移动端的性能与PC端的性能完全不在一个数量级上,比如,我哥做过一个测试,使用innerHTML绘制大段,之后想获取HTML的ID节点,事实上是获取不到的,这种问题在单页模拟多页,动态创建DOM会经常发生

    var element   = $('<div id = "test">...大量结构...</div>');

    $(root).html(element)

    $('#test)  //为空

    这类问题匪夷所思,因为页面UI渲染与DOM操作是互斥的,但是就算出现了这个问题,一个解决方案是使用settimeout,更好的方案是使用DOMNodeRemoved事件监控页面DOM改变,将我们的DOM操作回调放入以确保渲染结束。

    以上问题只是为了说明移动端的性能问题,这类性能问题会导致很多莫名其妙的问题,而且很多与渲染有关。但是这也从侧面说明了移动端资源的紧缺,若是heap值过大,会导致操作出现卡的现象,更有甚者,会引起页面假死直接退出。

    webapp的模式,完全依赖于浏览器的垃圾回收,基本就是作死,因为传统页面一旦刷新页面整个资源完全释放,而webapp没有刷新这类操作,只有一个状态到两一个状态,不相关的内存会保留,资源必须手动释放,或者说,框架必须提供垃圾释放的机制。

    这个由图表heap值变化可以清晰看出。

    而view切换过程中,不用的资源若是不手动设置为null会导致变量得不到回收便脱离框架控制而失控了。所以我们在webapp的过程中需要注意:

    l  释放没有使用的闭包

    l  观察者需要得到清理

    l  释放定时器

    l  view切换过程中,在destroy中释放view相关资源

    ——感谢艾伦友情支援

    闭包陷阱

    在我们工作过程中,滥用局部变量极有可能引起闭包陷阱,这个问题不止是性能问题,在逻辑上会引起错误,而且不易发现,比如,在AMD闭包中使用一个局部变量

    var _attributes = {};

    callback ($.extend(_attributes, opts));

    如此操作,会改变_ attributes对象,若是一个实例还无问题,但是两个实例的话便会发生变量污染。

    这只是一个例子,但是在代码中滥用局部变量可能会引起不必要的隐忧,戒之慎之。

    webapp资源释放

    根据前面的描述,我们可以得出一个结论:

    无论是view还是UI组件我们得提供统一的destroy接口,以便让用户继承释放资源。

    若是view的资源得不到释放导致heap值过高,webapp模式的网站其价值大减。这里有几点可以考虑:

    l  webapp中view实例保存不超过5个,多了便释放dom结构以及内存引用(临界值自己判断最优)

    l  view隐藏时释放内部资源,解除DOM事件句柄

    l  UI组件与view相同,需要统一释放机制

    但是单页应用由于页面不会刷新,总有一些资源得不到释放,此问题任重道远,平时编写过程可以做以下优化:

    l  使用函数替换逻辑

    让我们的函数产生一个返回值替换函数中的大段逻辑,这样的第一个好处便是逻辑清晰,第二个好处是这些函数在不同的函数中,这个函数被使用后便会自动得到释放。

    l  清理闭包引用

    当一个闭包函数或者什么使用结束后,若不会再使用,便需要手动清理该变量,以便解除闭包之间的引用关系,从而释放资源。

    l  使用对象属性或者方法

    一个对象可以引用其他对象的属性或者方法,比如obj.foo = thatObj;这种情况下,我们可以随时删除对象解除引用关系,然后便可以清理资源。

    动画与假死

    动画而言建议采用CSS3实现动画,CSS3中又推荐采用最新的接口,比如使用transform取代top/lelf操作,这样操作效率搞得多。

    若是采用动画可以将对应元素设置为absolute以减少回流,另外最关键一点还是

    避免移动DOM树过多的节点,这个时候需要驳回产品无理需求,比如:

    产品要求日期滚屏组件,显示半年的数据,这半年的数据便是180个DOM树

    这个级别的DOM一旦移动整个手机会直接卡死,甚至构建DOM树,渲染页面也会出现假死现象,该问题需要规避。

    Application Cache

    Application Cache是HTML5为webapp离线使用而增加的API,与localstorage、cookie等不同,Application Cache存储的是一系列请求资源允许浏览器在请求资源时不必通过网络,设计得当的话可以实现离线应用。

    使用Application Cache主要是在网络性能上提升,有效降低了网络延迟,提升请求加速

     

    但是也会有一些问题,比如新版本缓存不立刻生效;manifest中的请求路径相对于manifest文件,而非加载页面;更新/回滚等问题,所以使用与否还得论证。

    体验优化

    区域滚动

    移动端经常需要实现区域滚动的需求,成熟的也有IScroll解决方案,但是方案却不理想。

    就官方的例子便会出现以下问题:

    l  头部消失

    l  偶尔不能显示文本框焦点,或者焦点错位

    若是以上问题可忽略,但是文本框不见了这种事情,我是不会接受的

    导致的原因与组织浏览器默认事件有关,所以,我这里不太推荐各位大范围的使用区域滚动,而改在区域使用,

    就去哪儿的ipad版本在一个具有文本框的地方使用了IScroll,其提高的用户体验与导致的问题一样引人入胜。

    事实上,小钗及其推崇IScroll库,虽说他有这样那样问题,但是,IScroll是最有可能带来移动端革命的库,因为他可以:

    ① 解决webapp区域滚动

    ② 变相解决fixed问题

    ③ 解决动画过程带来的长短页问题

    总而言之,IScroll方案的提出,是让webapp媲美native app靠近了一大步,真正的平起平坐还需要浏览器的支援

    点击响应

    click本身在移动端响应是没有问题的,但是我们点击下来300ms 的延迟却是事实,这种事实造成的原因就是

    手机需要知道你是不是想双击放大网页内容

    所以click点击响应慢,而touch却不会有这样的限制,于是移动端的touch相当受欢迎,至于鼠标慢,他究竟有多慢,我会告诉你每次会慢300ms

    所以该问题需要处理,具体见:http://www.cnblogs.com/yexiaochai/p/3462657.html#_h2_7

    结语

    webapp不是一天两天的事情,总有一天,webapp会绽放其应有的风采!

    展开全文
  • 开发webapp工具和语言

    2018-06-06 16:06:03
    首先外壳可以cordova,也可以HBuilder结合css+html5+knockout(数据绑定)+framework7+require.js

    首先外壳可以用cordova,也可以用HBuilder

    结合css+html5+knockout(数据绑定)+framework7+require.js

    展开全文
  • 自Iphone和Android这两个牛逼的手机操作系统发布以来,在互联网界从此就多了一个新的名词-WebApp(意为基于WEB形式的应用程序,运行在高端的移动终端设备)。 开发者们都知道在高端智能手机系统中有两种应用...


    自Iphone和Android这两个牛逼的手机操作系统发布以来,在互联网界从此就多了一个新的名词-WebApp(意为基于WEB形式的应用程序,运行在高端的移动终端设备)。



    开发者们都知道在高端智能手机系统中有两种应用程序:一种是基于本地(操作系统)运行的APP;一种是基于高端机的浏览器运行的WebApp,本文将主要讲解后者。



    WebApp与Native App有何区别呢?



    Native App:



    1、开发成本非常大。

     

    一般使用的开发语言为JAVA、C++、Objective-C。



    2、更新体验较差、同时也比较麻烦

     

    每一次发布新的版本,都需要做版本打包,且需要用户手动更新(有些应用程序即使不需要用户手动更新,但是也需要有一个恶心的提示)。



    3、非常酷

     

    因为native app可以调用IOS中的UI控件以UI方法,它可以实现WebApp无法实现的一些非常酷的交互效果



    4、Native app是被Apple认可的

     

    Native app可以被Apple认可为一款可信任的独立软件,可以放在Apple Stroe出售,但是Web app却不行。



    Web App:

     

    1、开发成本较低

     

    使用web开发技术就可以轻松的完成web app的开发



    2、升级较简单

     

    升级不需要通知用户,在服务端更新文件即可,用户完全没有感觉



    3、维护比较轻松

     

    和一般的web一样,维护比较简单,它其实就是一个站点



    Webapp说白了就是一个针对Iphone、Android优化后的web站点,它使用的技术无非就是HTML或HTML5、CSS3、JavaScript,服务端技术JAVA、PHP、ASP。



    当然,因为这些高端智能手机(Iphone、Android)的内置浏览器都是基于webkit内核的,所以在开发WEBAPP时,多数都是使用HTML5和CSS3技术做UI布局。当使用HTML5和CSS3l做UI时,若还是遵循着一般web开发中使用HTML4和CSS2那样的开发方式的话,这也就失去了WEBAPP的本质意义了,且有些效果也无法实现的,所以在此又回到了我们的主题–webapp的布局方式和技术。



    在此所说的移动平台前端开发是指针对高端智能手机(如Iphone、Android)做站点适配也就是WebApp,并非是针对普通手机开发Wap 2.0,所以在阅读本篇文章以前,你需要对webkit内核的浏览器有一定的了解,你需要对HTML5和CSS3有一定的了解。如果你已经对此有所了解,那现在就开始往下阅读吧……



    1、首先我们来看看webkit内核中的一些私有的meta标签,这些meta标签在开发webapp时起到非常重要的作用

     

    1 <meta content=”width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0;” name=”viewport” />

     

    2 <meta content=”yes” name=”apple-mobile-web-app-capable” />

     

    3 <meta content=”black” name=”apple-mobile-web-app-status-bar-style” />

     

    4 <meta content=”telephone=no” name=”format-detection” />



    第一个meta标签表示:强制让文档的宽度与设备的宽度保持1:1,并且文档最大的宽度比例是1.0,且不允许用户点击屏幕放大浏览;

     

    第二个meta标签是iphone设备中的safari私有meta标签,它表示:允许全屏模式浏览;

     

    第三个meta标签也是iphone的私有标签,它指定的iphone中safari顶端的状态条的样式;

     

    第四个meta标签表示:告诉设备忽略将页面中的数字识别为电话号码



    2、HTML5标签的使用

     

    在开始编写webapp时,哥建议前端工程师使用HTML5,而放弃HTML4,因为HTML5可以实现一些HTML4中无法实现的丰富的WEB应用程序的体验,可以减少开发者很多的工作量,当然了你决定使用HTML5前,一定要对此非常熟悉,要知道HTML5的新标签的作用。比如定义一块内容或文章区域可使用section标签,定义导航条或选项卡可以直接使用nav标签等等。



    3、放弃CSS float属性

     

    在项目开发过程中可以会遇到内容排列排列显示的布局(见下图),假如你遇见这样的视觉稿,哥建议你放弃float,可以直接使用display:block;



    4、利用CSS3边框背景属性

     

    这个按钮有圆角效果,有内发光效果还有高光效果,这样的按钮使用CSS3写是无法写出来的,当然圆角可以使用CSS3来写,但高光和内发光却无法使用CSS3编写,这个时候你不妨使用-webkit-border-image来定义这个按钮的样式。-webkit-border-image就个很复杂的样式属性。



    5、块级化a标签

     

    请保证将每条数据都放在一个a标签中,为何这样做?因为在触控手机上,为提升用户体验,尽可能的保证用户的可点击区域较大。



    6、自适应布局模式

     

    在编写CSS时,我不建议前端工程师把容器(不管是外层容器还是内层)的宽度定死。为达到适配各种手持设备,我建议前端工程师使用自适应布局模式(支付宝采用了自适应布局模式),因为这样做可以让你的页面在ipad、itouch、ipod、iphone、android、web safarik、chrome都能够正常的显示,你无需再次考虑设备的分辨率。



    7、学会使用webkit-box

     

    上一节,我们说过自适应布局模式,有些同学可能会问:如何在移动设备上做到完全自适应呢?很感谢webkit为display属性提供了一个webkit-box的值,它可以帮助前端工程师做到盒子模型灵活控制。



    8、如何去除Android平台中对邮箱地址的识别

     

    看过iOS webapp API的同学都知道iOS提供了一个meta标签:用于禁用iOS对页面中电话号码的自动识别。在iOS中是不自动识别邮件地址的,但在Android平台,它会自动检测邮件地址,当用户touch到这个邮件地址时,Android会弹出一个框提示用户发送邮件,如果你不想Android自动识别页面中的邮件地址,你不妨加上这样一句meta标签在head中1 <meta content=”email=no” name=”format-detection” />



    9、如何去除iOS和Android中的输入URL的控件条

     

    你的老板或者PD或者交互设计师可能会要求你:能否让我们的webapp更加像nativeapp,我不想让用户看见那个输入url的控件条?



    答案是可以做到的。我们可以利用一句简单的javascript代码来实现这个效果

     

    1 setTimeout(scrollTo,0,0,0);



    请注意,这句代码必须放在window.onload里才能够正常的工作,而且你的当前文档的内容高度必须是高于窗口的高度时,这句代码才能有效的执行。



    10、如何禁止用户旋转设备
    我曾经也想禁止用户旋转设备,也想实现像某些客户端那样:只能在肖像模式或景观模式下才能正常运行。但现在我可以很负责任的告诉你:别想了!在移动版的webkit中做不到!
    至少Apple webapp API已经说到了:我们为了让用户在safari中正常的浏览网页,我们必须保证用户的设备处于任何一个方位时,safari都能够正常的显示网页内容(也就是自适应),所以我们禁止开发者阻止浏览器的orientationchange事件,看来苹果公司的出发点是正确的,苹果确实不是一般的苹果。
    iOS已经禁止开发者阻止orientationchange事件,那Android呢?对不起,我没有找到任何资料说Android禁止开发者阻止浏览器orientationchange事件,但是在Android平台,确实也是阻止不了的。

    11、如何检测用户是通过主屏启动你的webapp

    看过Apple webapp API的同学都知道iOS为safari提供了一个将当前页面添加主屏的功能,按下iphoneipodipod touch底部工具中的小加号,或者ipad顶部左侧的小加号,就可以将当前的页面添加到设备的主屏,在设备的主屏会自动增加一个当前页面的启动图标,点击该启动图标就可以快速、便捷的启动你的webapp。从主屏启动的webapp和浏览器访问你的webapp最大的区别是它清除了浏览器上方和下方的工具条,这样你的webapp就更加像是nativeapp了,还有一个区别是window对像中的navigator子对象的一个standalone属性。iOS中浏览器直接访问站点时,navigator.standalone为false,从主屏启动webapp时,navigator.standalone为true, 我们可以通过navigator.standalone这个属性获知用户当前是否是从主屏访问我们的webapp的。在Android中从来没有添加到主屏这回事!


    12、如何关闭iOS中键盘自动大写


    我们知道在iOS中,当虚拟键盘弹出时,默认情况下键盘是开启首字母大写的功能的,根据某些业务场景,可能我们需要关闭这个功能,移动版本webkit为input元素提供了autocapitalize属性,通过指定autocapitalize=”off”来关闭键盘默认首字母大写。



    13、iOS中如何彻底禁止用户在新窗口打开页面

     

    有时我们可能需要禁止用户在新窗口打开页面,我们可以使用a标签的target=”_self“来指定用户在新窗口打开,或者target属性保持空,但是你会发现iOS的用户在这个链接的上方长按3秒钟后,iOS会弹出一个列表按钮,用户通过这些按钮仍然可以在新窗口打开页面,这样的话,开发者指定的target属性就失效了,但是可以通过指定当前元素的-webkit-touch-callout样式属性为none来禁止iOS弹出这些按钮。这个技巧仅适用iOS对于Android平台则无效。

    14、iOS中如何禁止用户保存图片\复制图片


    我们在第13条技巧中提到元素的-webkit-touch-callout属性,同样为一个img标签指定-webkit-touch-callout为none也会禁止设备弹出列表按钮,这样用户就无法保存\复制你的图片了。


    15、iOS中如何禁止用户选中文字

     

    我们通过指定文字标签的-webkit-user-select属性为none便可以禁止iOS用户选中文字。


    16、iOS中如何获取滚动条的值

     

    桌面浏览器中想要获取滚动条的值是通过document.scrollTop和document.scrollLeft得到的,但在iOS中你会发现这两个属性是未定义的,为什么呢?因为在iOS中没有滚动条的概念,在Android中通过这两个属性可以正常获取到滚动条的值,那么在iOS中我们该如何获取滚动条的值呢?

     

    通过window.scrollY和window.scrollX我们可以得到当前窗口的y轴和x轴滚动条的值。


    17、如何解决盒子边框溢出

     

    当你指定了一个块级元素时,并且为其定义了边框,设置了其宽度为100%。在移动设备开发过程中我们通常会对文本框定义为宽度100%,将其定义为块级元素以实现全屏自适应的样式,但此时你会发现,该元素的边框(左右)各1个像素会溢了文档,导致出现横向滚动条,为解决这一问题,我们可以为其添加一个特殊的样式-webkit-box-sizing:border-box;用来指定该盒子的大小包括边框的宽度。


    18、如何解决Android 2.0以下平台中圆角的问题

     

    如果大家够细心的话,在做wap站点开发时,大家应该会发现android 2.0以下的平台中问题特别的多,比如说边框圆角这个问题吧。

     

    在对一个元素定义圆角时,为完全兼容android 2.0以下的平台,我们必须要按照以下技巧来定义边框圆角:

     

    1\-webkit这个前缀必须要加上(在iOS中,你可以不加,但android中一定要加);

     

    2\如果对针对边框做样式定义,比如border:1px solid #000;那么-webkit-border-radius这属性必须要出现在border属性后。

     

    3\假如我们有这样的视觉元素,左上角和右上角是圆角时,我们必须要先定义全局的(4个角的圆角值)-webkit-border-radius:5px;然后再依次的覆盖左下角和右下角,-webkit-border-bottom-left-radius:0;-webkit-border-bottom-right-border:0;否则在android 2.0以下的平台中将全部显示直角,还有记住!-webkit这个前缀一定要加上!



    19、如何解决android平台中页面无法自适应

     

    虽然你的html和css都是完全自适应的,但有一天如果你发现你的页面在android中显示的并不是自适应的时候,首先请你确认你的head标签中是否包含以下meta标签:

     

    1 <meta name=”viewport” content=”width=device-width,initial-scale=1.0,maximum-scale=1.0,user-scalable=0;” />

     

    如果有的话,那请你再仔细的看清楚有没有这个属性的值width=device-width,如果没有请立即加上吧!



    20、如何解决iOS 4.3版本中safari对页面中5位数字的自动识别和自动添加样式

     

    新的iOS系统也就是4.3版本,升级后对safari造成了一个bug:即使你添加了如下的meta标签,safari仍然会对页面中的5位连续的数字进行自动识别,并且将其重新渲染样式,也就是说你的css对该标签是无效的。

     

    1 <meta name=”format-detection” content=”telphone=no” />



    我们可以用一个比较龌龊的办法来解决。比如说支付宝wap站点中显示金额的标签,我们都做了如下改写:

     

    1 <button class=”t-balance”style=”background:none;padding:0;border:0;”>95009.00</button>
    展开全文
  • 开发模式: 1.原生开发:react native(Facebook)。用户体验好,即使在网络断开的情况下也能打开app,缺点是技术难度高,开发成本高,拓展性弱。代表:淘宝 2.web开发开发快,成本低,拓展性强,但是用户体验差...
  • 结合网上相关资料,以及自己项目中的经验,收集汇总了iOS Webapp相关的开发知识,如下。 WebApp是一种新出现的基于WEB形式的类应用程序,运行在高端的移动终端设备上,其应用范围会越来越广。 开发者们都知道在...
  • 开发webApp准备一

    2018-08-08 11:32:54
    如何在原有项目基础上开发整个webApp 前端页面的扩展和开发 NodeJS服务端环境的搭建和服务设施的提供 mock数据的提供和模拟 webApp整体搭建方式 逆向软件工程 自己熟悉的技术、反推 基于通用过的工程、反推 ...
  • webapp开发框架

    2017-11-16 14:38:08
    介绍几个移动web app开发框架     jQuery Mobile  jQuery Mobile框架能够帮助你快速开发出支持多种移动设备的Mobile应用用户界面。jQuery Mobile最新版本是1.4.0,默认主题采用扁平化设计风格。jQuery ...
  • 那么进行webApp开发步骤如下: 1 新建一个Web project项目 2 在你所建的项目里的WEB-INF下添加一个html文件。其中我根据我的需求所写代码如下 index page 显示员工信息  当然可以根据自己的实际需求...
  • 商品配送系统手机WebApp开发(Asp.Net MVC5、HTML5、jQuery Mobile、Backbone) 适合人群:中级 课时数量:18课时 用到技术:Asp.Net MVC5、HTML5、jQuery Mobile、Backbone 涉及项目:手机WebApp、消息推送、富...
  • webapp什么

    2018-07-03 14:49:12
    Webapp网络应用程序WebApp是指基于Web的系统和应用,其作用是向广大的最终用户发布一组复杂的内容和功能。从一个简单的帮助消费者计算汽车租借费用的网页,到为商业人员和度假者提供全套旅游服务的大型复杂的WEB站点...
  • HTML5开发Webapp总结

    2015-09-15 14:16:16
    最近h5写了一个简单的Webapp,感觉和web页面最大的不同是head部分,如下: 需要多增加一此meta配置,viewport主要用来识别设备,设置页面宽度。 2. 滑动功能 2.1 参考imooc上的课程:...
  • 25学堂小编还没有找到比较合适的html5+css3开发webAPP项目教材。 这里分享了一个《网易微博Web App开发过程》但是这个过程的重点不是在于开发过程,还是开发Web App的项目大体步骤和人员搭配等。 所以,25...
  • 手机APP开发/WebApp应用

    2018-10-22 21:38:13
    APP开发,是指智能终端设备应用软件开发。由于智能手机、平板电脑等移动终端设备的不断普及,使APP应用软件得到广泛的使用,导致APP开发的“兴起”。App是application的缩写,通常专指手机上的应用软件,或称手机...
  • webapp开发

    2017-08-16 11:06:10
    webapp主要利用h5技术加web开发技术实现,使之在移动手机上操作的应用开发。 优点是开发快,因为web页面开发很灵活,可以尽可能的去模仿android布局,后台使用的仍是mvc,这样不用再去学习android那一套东西。 ...
  • ((webapp+Java原生)移动端开发(微信小程序,公众号,头条app))+web网站) Web发展简史 1:在那时,Web开发还比较简单,开发者经常会去操作web服务器(主要还是他自己的机器),并且他会写一些HTML页面放到服务器...
  • ionic 开发WebApp入门

    2017-07-05 14:45:16
    在这个技术日新月异的情况下,学习是提高个人技术能录的唯一路径,下面就ionic 的入门做以下小结。... 大家在开发中会遇到诸多的坑,而填坑也是一件很有意思的事情,下面就本人在填坑过程中找到的好的资料分享给
  • Vue.js 2.0和Cordova开发webApp环境搭建
1 2 3 4 5 ... 20
收藏数 67,667
精华内容 27,066