自适应

WEBAPP开发技巧总结

由 怎甘沉沦 提交于 2020-02-15 00:04:27
自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开发技巧总结

由 风流意气都作罢 提交于 2020-02-15 00:04:14
自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开发技巧总结

由 旧街凉风 提交于 2020-02-14 23:58:30
自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一样，维护比较简单，它其实就是一个站点

网页自适应屏幕

由 最后都变了- 提交于 2020-02-14 22:24:02
网页自适应手机、电脑屏幕的设置方法 　　<head> 　　<meta name="viewport" 　　content="width=device-width,minimum-scale=1.0,maximum-scale=1.0" /> 　　<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> 　　<link rel="stylesheet" type="text/css" /> 　　<script src="jquery.min.js"></script> 　　<title>Insert title here</title> 　　</head> 　　<meta http-equiv="Content-type" name="viewport" content="initial-scale=1.0, maximum-scale=1.0, user-scalable=no, width=device-width"> 　　第一个meta标签表示： 　 强制让文档与设备的宽度保持1：1； 　 文档最大的宽度比列是1.0（initial-scale初始刻度值和maximum-scale最大刻度值）； 　 user-scalable定义是否可缩放（0为不缩放），使页面固定设备上面的大小。 来源： https

布局：上下两个div高度固定，中间自适应

由 假装没事ソ 提交于 2020-02-08 22:16:26
需求：经典布局 —— 头尾固定高度中间高度自适应布局 头部固定高度，宽度100%自适应父容器； 底部固定高度，宽度100%自适应父容器； 中间是主体部分，自动填满，浏览器可视区域剩余部分，内容超出则中间部分出现流动条； 整个内容填满浏览器可视区域，并且不超出此区域！ 方法一：position:absolute定位，不设高，并改变"包含块"的尺寸渲染 固定头尾，所以，至少头和尾要用到position定位。因为浏览器大小是可以调节的，而且不同尺寸，不同分辨率的浏览器可视区域的高度是不固定的， 这就决定是中间主体部分的高度不固定。所以真正的问题核心也正在此。解决了这个问题，整个布局也就解决了一多半 最重要的一段就是中间部分绝对定位，top为头的高度，bottom为尾的高度 <!DOCTYPE HTML> <html> <head> <meta charset="gb2312"> <title>头尾固定中间高度自适应布局</title> <style> html, body { height:100%; margin:0; padding:0 } #dHead { height:100px; background:#690; width:100%; position:absolute; z-index:5; top:0; } #dBody { background:#FC0; width

css经典布局——头尾固定高度中间高度自适应布局

由 那年仲夏 提交于 2020-02-08 22:15:43
转载：穆乙 http://www.cnblogs.com/pigtail/ 相信做过后台管理界面的同学，都非常清楚这个布局。最直观的方式是框架这个我不想多写费话，因为我们的重心不在这里。如果有不了解的同学可以百度、google。这里我不得不吐下槽！！ 百度实在让我这个“粉丝”失望。就目前情况来说，百度已经完全轮为“有钱人排行榜”！再也不顾及用户的搜索需求了，因为主导地位实在是：不可撼动！ 不相信的同学，可以亲身对比下B vs G的搜索结果。别告诉我google如何强大！！ 很久以前，百度的搜索结果更符合目标，因为他更了解中国人的习惯，这是不可争议，现在情况已经完全相反！ 虽然google经常是六脉神剑，但我更欣赏它的搜索结果。吐槽打住!!! 现在开始正式谈论这个经典布局 —— 头尾固定高度中间高度自适应布局 下面说下要求： 1 头部固定高度，宽度100%自适应父容器； 2 底部固定高度，宽度100%自适应父容器； 3 中间是主体部分，自动填满，浏览器可视区域剩余部分，内容超出则中间部分出现流动条； 4 整个内容填满浏览器可视区域，并且不超出此区域！ 先看下效果图： 相信，做过两年前端的同学，拿到这个需求，都有一个感觉——这挺简单的！ 是的，本来就挺简单！ 方法一：position:absolute定位，不设高，并改变"包含块"的尺寸渲染 从我脑海崩出来的第一个念头就是定位布局—

微信小程序新单位rpx与自适应布局

由 好久不见. 提交于 2020-02-08 08:51:09
rpx是微信小程序新推出的一个单位，按官方的定义，rpx可以 根据屏幕宽度进行自适应 ，在rpx出现之前，web页面的自适应布局已经有了多种解决方案，为什么微信还捣鼓出新的rpx单位？在解释这个单位前，我们先简单了解一下目前的主流的自适应布局解决方案： 响应式（ Responsive web design ) rem 流式布局 scale伸缩布局 响应式 响应式布局的问题在于需要维护多个样式文件，维护成本太大，一般的移动H5页面都不会优先考虑。 rem rem是近几年比较流行的方案，淘宝移动web端就是采用此方案，由于1rem=根元素font-size，所以rem布局的本质就是 通过rem把页面按比例分割 达到自适应的效果，因为rem是相对根路径font-size尺寸，不同的页面设置不同的font-size尺寸，即可达到自适应的效果。为了方便理解，我写了一个简单的 rem布局demo ，通过设置 document.documentElement.style.fontSize = window.innerWidth + 'px'; 然后设置 <div class="box"></div> 的宽高等于1rem，就可以使box的宽高自适应各种设备尺寸。因为box的单位1em是跟页面设备的宽对应的，所以能做到自适应各种尺寸。 流式布局 流式布局需要用到百分比或者flex

自适应布局 的 解决方案

由 喜你入骨 提交于 2020-02-08 03:44:52
曾几何时为了兼容IE低版本浏览器而头痛，以为到Mobile时代可以跟这些麻烦说拜拜。可没想到到了移动时代，为了处理各终端的适配而乱了手脚。对于混迹各社区的偶，时常发现大家拿手机淘宝的H5页面做讨论—— 手淘的H5页面是如何实现多终端的适配 ？ 那么趁此 Amfe阿里无线前端团队双11技术连载 之际，用一个实战案例来告诉大家，手淘的H5页面是如何实现多终端适配的，希望这篇文章对大家在Mobile的世界中能过得更轻松。 目标 拿一个双11的Mobile页面来做案例，比如你实现一个类似下图的一个H5页面： 目标很清晰，就是做一个这样的H5页面。 DEMO 请用手机扫下面的二维码 痛点 虽然H5的页面与PC的Web页面相比简单了不少，但让我们头痛的事情是要想尽办法让页面能适配众多不同的终端设备。看看下图你就会知道，这是多么痛苦的一件事情： 点击 这里 查看更多终端设备的参数。 再来看看手淘H5要适配的终端设备数据： 看到这些数据，是否死的心都有了，或者说为此捏了一把汗出来。 手淘团队适配协作模式 早期移动端开发，对于终端设备适配问题只属于Android系列，只不过很多设计师常常忽略Android适配问题，只出一套iOS平台设计稿。但随着iPhone6，iPhone6+的出现，从此终端适配问题不再是Android系列了，也从这个时候让移动端适配全面进入到“杂屏”时代。 上图来自于

创建分辨率自适应的Windows Phone 8应用程序

由 旧时模样 提交于 2020-02-07 01:03:36
1. 引言 Windows Phone 7平台只支持WVGA分辨率（480*800）的设备，这对于应用程序的UI设计来说是有利的，因为设计人员不用考虑多分辨率对UI控件布局的影响。但是，Windows Phone 8平台打破了这个局面，支持三种分辨率，分别为WVGA、WXGA（768*1280）和720p（720*1280）。随之而来的问题就是，开发者该如何应对多分辨率对应用程序的影响？这仿佛又把我们带回了Windows Mobile那个多分辨率的时代。那个时候，我们的应对方法就是使用控件的Docking and Anchoring属性，或者利用本地代码创建Orientation-Aware and Resolution-Aware的应用程序。其实，在Windows Phone 8平台上，我们处理的方式和方法也是类似的。 2. 分辨率对比 Windows Phone 8和Windows Phone 7平台支持的分辨率情况如下表所示： 名称 分辨率 比例 Windows Phone 7 Windows Phone 8 WVGA 480 × 800 15:9 支持 支持 WXGA 768 × 1280 15:9 不支持 支持 720p 720 × 1280 16:9 不支持 支持 表1：Windows Phone 7与Windows Phone 8分辨率对比
订阅 自适应