1.5版本更新说明BUI1.5自1.5版本以来变化很大，统一新样式，新规范750，增加了基于DOM的数据驱动，改进了单页路由页面的生命周期等，在易用性的道路上越走越远。如果您觉得好用，请帮我们推荐给您的朋友，谢谢。以后我们会整理一些实用的教程。欢迎关注BUIWebapp专栏。1.案例代表这是你继续读下去的动力。我用BUI模仿了一个QQ手机截图的demo，包含了QQ常见的交互，滑动侧边栏，TAB切换，滑动列表，下拉刷新，下拉菜单，弹出窗口搜索等交互操作，这几种Operations在很多UI框架中都有，但是当几个Operation组合在一起的时候，不同方向之间的交互冲突就不那么简单了。使用BUI需要1天。通过这个看似简单的例子，一个使用BUI快速开发的应用程序就可以摆上台面了。在没有设计稿的情况下，我们可以模仿任何一个APP开发，按照APP的同比例完美还原。另外就是在各种复杂的手势操作交互中，BUI更是游刃有余。请用手机扫码查看。推荐手机端扫码预览，PC端预览不支持手势操作。点击PC预览DemoBUI控件demo。它不仅仅是一个框架，它是一整套快速开发Webapp的解决方案。请查看BUI官网，有DEMO演示，给你最直观的感受。如果你和我一样正在寻找快速开发Webapp的框架，相信我，你来对地方了。欢迎加入BUI移动开发交流群：691560280全BUI移动开发交流群2：4170980new2011年开始接触移动混合app开发，开发过几十款应用。这些经验也可能对其他人有所帮助。于是整理了一下，BUI围绕快速开发做了很多事情。看完你就会明白，BUI的速度是有意义的。面向开发者和混合App开发作为后端开发者，前端美工，我找了很多框架满足我对框架的要求，我对框架有一些要求：易学，上手快;易于定制用户界面；一次开发，跨平台全面适配，Android、IOS、微信、淘宝、支付宝、钉钉、浏览器等；控件较多，至少能满足平时的需要；可结合第三方打包平台，打包成独立的应用；有案例或模板可供参考；支持物理按键返回；支持后台刷新；支持动画返回指定页面；模块化开发；响应速度快；……这样的要求是不是太过分了？但是我发现每个UI框架都有自己的定位，和我想要的不太一样，所以我们只能自己造轮子了。既然自己造轮子，就要先造最适合自己的，再造适合别人的。这里有必要说明一下背景。三、背景早在2011年，Pingo公司就开始接触移动互联网。并拥有第一个基于Cordova的混合应用开发框架和打包平台——Bingotouch（当时除了Appcan，还没有Dcloud、APICloud等比较成熟的平台）为了配合Bingotouch开发框架，我们需要一个UI，所以我们有一个简单的UI。适配（打包时可以自适应，但在浏览器中无法预览），页面切换传参使用原生切换，其他复杂点使用第三方插件，拉取使用iscroll-下来刷新一下，投资项目开发。一晃四年过去了，真是奇迹。但是随着混合应用的技术提升和系统升级，手机屏幕越来越大，我们的UI也出现了一些不足。我们意识到我们的UI必须升级。经过4年的移动开发项目经验，我们在2015年底开始对UI进行改造。4.移动开发的难点这里顺便说明一下我们老UI的问题。1.视口问题老了UI适配固定宽度的视口。把设计稿改成320的尺寸，然后我们按照这个尺寸测量间隙，还原设计稿。这会导致浏览器中的整个页面变大。之前没有考虑浏览器，所以问题还是不大，但是随着viewport在不同移动设备上的表现，这种方法的瓶颈越来越大，ifelse也越来越多。2.UI组件少。早期基于zepto的控件要适配移动端，是的很少，所以我们经常需要去网上找控件或者自己写控件，这就导致了各个控件的使用方式和兼容性不同，很难开始。3、不同平台需要多次开发，因为页面切换使用的是原生Switching，这样体验更好，但是也带来了一个问题，与框架的结合太紧密，有些项目需求，开发完成后，客户要求上线在微信上，所以要二次开发，如果需要在其他平台上呢？想象一下....正是因为这些问题，我们新的BUI才越来越适应。5、设计思路多。看了文档，BUI不懂。大多数Native模块，这里是我们和其他webapp开发框架的区别，BUI的一个控件或者一个方法做的不止一件事。这里主要分析Native模块的设计。前面提到，我们使用原生切换进行页面切换和传递参数。在Android2.系统中，如果使用location.href跳转会白，而且不同Android下单页表现不完美，所以我们这里使用原生的，原生的跑不了在网络浏览器中。所以我们想用一种兼容的方式，像混合应用一样，在中间做一层转换，这样就可以得到你所需要的，当你需要web的时候，切换到web.Method<-web<-BUI->Bingotouch->Native1。思路1分析：bui是通过bui.isWebapp选择的（老版本是bui.debug）是web还是native。所有原生模块都需要在bui.ready中初始化。这样我们就使用了缤果touch中常用的交互、页面跳转、传参、刷新、回滚、请求、上传、下载等功能，模块封装了统一的API。每个本机模块方法对应两种不同的方法。这样用户在使用过程中就不需要关注是native还是web了。他们只需要知道，当我在浏览器中运行时，我设置bui.isWebapp为true，如果需要打包，则使用bui.isWebapp为false；以上就是我们BUI为我们公司的Bingotouch实现的一套UI思路。如果你细心一点，你可能会发现Bingotouch与互联网上的第三方平台非常相似。没错，不过我们出来的比较早。我为此感到非常自豪。所以从设计思路上看，我们也预留了扩展到第三方平台的接口。所以我们有不同版本的bui.js.2。思路二场景一：客户指定使用第三方平台进行打包；我们的Bingotouch不会派上用场，虽然我们很优秀，但是客户不放心，第三方平台也不需要依赖某家公司。很容易找到其他开发商，客户的顾虑也不无道理。第三方平台的出现方便了开发者，但也带来了新的问题。一个第三方平台都会有自己的开发生态，工具，API，UI，开发者要学的东西太多了。这样我们的BUI又可以派上用场了，我们还是按照自己熟悉的方式开发，但是对于原有界面的特殊部分，可以使用第三方的，所以只需要学一次BUI，就可以开发其他平台，使用其他平台的一些原生接口。想想真是一件美妙的事情。后来发现各个平台的上传、下载、文件处理方式都不一样，处理起来非常耗时。对于第一个三方平台，我们对Native的一些方法进行了简化，只保留页面加载、传参、返回、请求、刷新。这样无论客户指定哪个平台，都可以使用我们的UI进行开发交互，开发者不需要再学习新的UI，可以减少一点是点击这里。6.Frameworkfeatures围绕这个思路进行设计，然后分析网上一些UI的特点。我们的框架应该是这样的：在webapp和hybridapp开发之间，大部分应用有80%以上的功能都是通过UI来实现的，这样只要学习一次BUI，就可以在不同平台之间轻松驾驭。1.简单易学，上手快在软件公司中，开发人员占多数，人员流动等因素，如果开发人员愿意学习和使用，可以解决招不到合适的前端的问题。因此，学习必须快速而简单。我们在技术选型上不依赖vue、react等先进概念。我们就是要简单，而Dom是最基础的，也是最容易理解的，所以我们是基于zepto或者jquery的。工具开发人员使用他们习惯的任何工具。使用webpack、gulp、sass和less完全取决于他们。但是如果你使用我们推荐的sublimetext工具，我们有这个工具的插件，可以快速编写，事半功倍。丰富的文档和介绍视频BUI介绍文档只需5分钟BUI控制API文档BUI规范文档BUIFAQ2.我们使用Unique规范，使用REM适配，开发的页面可以在各种AndroidIOS系统，webkit浏览器（淘宝，微信，QQ，钉钉），第三方封装平台（Dcloud，APICloud，APPCan等）解析，以保持一致的缩放效果。与网页保持一致的图片裁剪习惯，但在做单位换算时，以540px设计稿为准，1rem=100px；这是很多UI所欠缺的，我给大家一个设计稿。什么攻略告诉你怎么切图，大部分都是响应式自适应的效果，看起来一样，实际效果和效果图不一样。如图所示，其他UI适配的高度是固定的，随着屏幕高度的增加，底部的空白会越来越多，而BUI整体是按比例缩放的，就像一个大的图片缩放到合适的屏幕。它真的是一个开发，多平台适配。其他UI适配：BUI适配：3.丰富的交互组件BUI控件demoDemo之前说过，我们需要经常为旧UI寻找插件，而我们找到的插件不一定能用。调用系统原生的交互在Android和ios上会有不同的表现，为了避免这种情况，我们统一开发了网上常见的插件，交互一致，使用一致，API一致。BUI组件有一些区别，我们关注的是控件的交互，自称交互相同通过相同的控件实现。我们的组件将内容与结构交互分开。一个组件可以做很多事情。例如：bui.slide是一个焦点图组件。除了本身支持横屏、竖屏、全屏、自动播放等功能之外，我们稍微改了一下参数，就变成了一个tab组件。**（这里不能直接上传gif交互图，我会展示重要的交互，如果想看更多交互，请点击直接预览交互效果）**bui.slide焦点图控件js:varuiSlide=bui.slide({id:"#uiSlide",height:200})html:
