微信小程序和HTML5与之间的区别

作为前端工程师，从前端的视角，为大家分析下微信小程序和HTML5与之间的主要区别第一条是运行环境的不同。传统的HTML5的运行环境是浏览器，包括webview，而微信小程序的运行环境并非完整的浏览器，大家注意，我这里写的是“非完整的浏览器”

rem由来 ：font size of the root element，那么rem是个单位，单位大小由它第一代老祖宗的 font-size 的大小决定。现在前端码农们为了能在各个屏幕上看到一个健康的网页在默默的牺牲着自己的健康，因为不仅要知道rem是个单位，更重要的是要知道怎么能在不同分辨率下呈现的页面都很NB。

事故造成原因：

1px单位在PC上很流行，在手机屏幕上一看，MLGB的，同样的12px却小的跟蚂蚁似的。

2好不容易在iPhone4上调的正常了，换个菊花牌手机，MBD不堪入目了。

3知道了rem的用法，但是html的font-size到底是多少才合适啊啊啊，妈蛋~。

好了，那么现在来解决这些问题。

在解决之前，麻烦各位大婶要了解一些你可能不想了解的东东（警告：不了解这些就不能知道真相哟~）：

1 物理像素(physical pixel)

我们看到的每个屏幕都是由一颗颗我们肉眼难以看到的小颗粒（物理像素）组成的。

2逻辑像素

是计算机坐标系统中的一个点，这个点代表一个可以由程序使用的虚拟像素(比如说CSS像素)。

3设备的像素比(device pixel ratio)简称DPR

它的数值体现了物理像素和逻辑像素之间的关系，用公式可以计算出该设备的DPR的大小：

DPR= 物理像素 / 逻辑像素

那么了解了上面这些概念，就可以知道，为什么css在pc上写着font-size=12px;但是换到手机上却变小了？因为DPR啊啊啊，大哥~。

没错，我们在电脑屏幕上的DPR是1，但是手机却不同，可能是它可能是2，也可能是3。获取设备DPR的方法还是有的：

1在JavaScript中，通过windowdevicePixelRatio来获取

2在css中，可以通过-webkit-device-pixel-ratio，-webkit-min-device-pixel-ratio和 -webkit-max-device-pixel-ratio进行媒体查询，对不同DPR的设备，做一些样式适配(这里只针对webkit内核的浏览器和webview)。

本人也在网上看了不少动态设置rem的文章，下面把几个常用的列举出来：

一，用媒体查询来设置html的font-size：

@mediascreen and (min-width:320px) {html{font-size:14px;}} @mediascreen and (min-width:360px) {html{font-size:16px;}} @mediascreen and (min-width:400px) {html{font-size:18px;}} @mediascreen and (min-width:440px) {html{font-size:20px;}} @mediascreen and (min-width:480px) {html{font-size:22px;}} @mediascreen and (min-width:640px) {html{font-size:28px;}}

二、利用js来动态设置

!(function(doc, win){vardocEle = docdocumentElement,        evt ="onorientationchange"inwindow"orientationchange":"resize",        fn =function(){varwidth = docEleclientWidth;            width && (docElestylefontSize =20 (width /320) +"px");        };        winaddEventListener(evt, fn,false);    docaddEventListener("DOMContentLoaded", fn,false); }(document,window));

我要说的是最后一种，也是我认为目前比较好的实现方法：

利用js计算当前设备的DPR，动态设置在html标签上，并动态设置html的font-size，利用css的选择器根据DPR来设置不同DPR下的字体大小（这个方法很不错哦~）

!function(win, lib){vartimer,        doc    = windocument,        docElem = docdocumentElement,        vpMeta  = docquerySelector('meta[name="viewport"]'),        flexMeta = docquerySelector('meta[name="flexible"]'),        dpr  =0,        scale =0,        flexible = libflexible || (libflexible = {});// 设置了 viewport metaif(vpMeta) {consolewarn("将根据已有的meta标签来设置缩放比例");varinitial = vpMetagetAttribute("content")match(/initial\-scale=([\d\]+)/);if(initial) {            scale =parseFloat(initial[1]);// 已设置的 initialScaledpr =parseInt(1/ scale);// 设备像素比 devicePixelRatio}    }// 设置了 flexible Metaelseif(flexMeta) {varflexMetaContent = flexMetagetAttribute("content");if(flexMetaContent) {varinitial = flexMetaContentmatch(/initial\-dpr=([\d\]+)/),                maximum = flexMetaContentmatch(/maximum\-dpr=([\d\]+)/);if(initial) {                dpr =parseFloat(initial[1]);                scale =parseFloat((1/ dpr)toFixed(2));            }if(maximum) {                dpr =parseFloat(maximum[1]);                scale =parseFloat((1/ dpr)toFixed(2));            }        }    }// viewport 或 flexible// meta 均未设置if(!dpr && !scale) {// QST// 这里的 第一句有什么用 // 和 Android 有毛关系 varu = (winnavigatorappVersionmatch(/android/gi), winnavigatorappVersionmatch(/iphone/gi)),            _dpr = windevicePixelRatio;// 所以这里似乎是将所有 Android 设备都设置为 1 了dpr = u ( (_dpr >=3&& (!dpr || dpr >=3))                        3: (_dpr >=2&& (!dpr || dpr >=2))                            2:1)                :1;        scale =1/ dpr;    }    docElemsetAttribute("data-dpr", dpr);// 插入 viewport metaif(!vpMeta) {        vpMeta = doccreateElement("meta");                vpMetasetAttribute("name","viewport");        vpMetasetAttribute("content","initial-scale="+ scale +", maximum-scale="+ scale +", minimum-scale="+ scale +", user-scalable=no");if(docElemfirstElementChild) {            docElemfirstElementChildappendChild(vpMeta)        }else{vardiv = doccreateElement("div");            divappendChild(vpMeta);            docwrite(divinnerHTML);        }    }functionsetFontSize(){varwinWidth = docElemgetBoundingClientRect()width;if(winWidth / dpr >540) {            (winWidth =540 dpr);        }// 根节点 fontSize 根据宽度决定varbaseSize = winWidth /10;        docElemstylefontSize = baseSize +"px";        flexiblerem = winrem = baseSize;    }// 调整窗口时重置winaddEventListener("resize",function(){        clearTimeout(timer);        timer = setTimeout(setFontSize,300);    },false);// 这一段是我自己加的// orientationchange 时也需要重算下吧winaddEventListener("orientationchange",function(){        clearTimeout(timer);        timer = setTimeout(setFontSize,300);    },false);// pageshow// keyword: 倒退 缓存相关winaddEventListener("pageshow",function(e){if(epersisted) {            clearTimeout(timer);            timer = setTimeout(setFontSize,300);        }    },false);// 设置基准字体if("complete"=== docreadyState) {        docbodystylefontSize =12 dpr +"px";    }else{        docaddEventListener("DOMContentLoaded",function(){            docbodystylefontSize =12 dpr +"px";        },false);    }      setFontSize();    flexibledpr = windpr = dpr;    flexiblerefreshRem = setFontSize;    flexiblerem2px =function(d){varc =parseFloat(d) thisrem;if("string"==typeofd && dmatch(/rem$/)) {            c +="px";        }returnc;    };    flexiblepx2rem =function(d){varc =parseFloat(d) /thisrem;if("string"==typeofd && dmatch(/px$/)) {            c +="rem";        }returnc;    }}(window,windowlib || (windowlib = {}));

忘了说了，手机淘宝很多页面用的就是这种方法来适配终端的。

一、运行环境的不同。

传统的HTML5的运行环境是浏览器，包括webview，而微信小程序的运行环境并非完整的浏览器，大家注意，我这里写的是“非完整的浏览器”，有以下几个原因

小程序的开发过程中会用到HTML5相关的技术(并非全部)

小程序最后的发布上线需要微信审核，微信在不更新自身软件的情况下可以将小程序更新到自身软件内，这就联想到了ReactNative框架,并且已经有开发者在微信小程序的开发工具源码中发现使用了React和NodeWebkit库

官方文档中着重强调了脚本内是无法使用浏览器中常用的window对象和document对象（基于这一点，像zepto/jquery这种 *** 作dom的库就被完全抛弃了）

所以我个人认为，小程序的运行环境很有可能是微信开发团队基于浏览器内核完全重构的一个内置解析器，针对小程序专门做了优化，配合自己定义的开发语言标准，提升了小程序的性能。

不过由于微信给开发者提供了开发工具，而开发工具中也内置了编程、调试、开发环境、发布于一身，我们也不用再探讨它的最终运行环境了，只要按照官方文档进行开发就可以了。并且从微信团队给开发者提供开发工具这一举动，让我联想到了苹果给开发者提供的X-CODE开发工具，可以想象微信的“野心”可见一斑

二、开发成本的不同。

这里我提出了一个问题，当我们面对一个HTML5web开发需求时，我们需要考虑什么呢？抛去开发工具（vscode、sublimtext、Atom等）不谈，大到前端框架（Angular、react、vue、backbone等）、模块管理工具（Webpack、Browserify等）、任务管理工具（Grunt、Gulp等），小到UI库选择、接口调用工具（ajax、FetchApi等）、浏览器兼容性等都要我们一一考略，再不济用jqery插件写H5，也要在开发过程中去寻找合适的jquery插件来配合项目。尽管这些工具可定制化非常高，并且提高了开发者的开发效率，但我相信项目开发的配置工作已经消耗了不少精力，尽管大部分开发者都有自己的配置模板，但长久以来对于项目中使用的各种外部库的版本迭代、版本升级所产生的成本应该也不低。

而当我们面对一个微信小程序的开发需求时，我们需要考虑什么呢？微信团队提供了开发者工具，并且规范了开发标准，前端常见的HTML、CSS变成了微信自定义的WXML、WXSS，WXML中尽管全部是自定义标签，但官方文档中都有明确的使用介绍，相信上手应该是非常容易的；WXSS、JSON和JS文件中的写法稍有限制，但整体相差不多。在统一了这些标准之后，作为一个开发者，你会发现，自己只要专注写程序就可以了：

当需要调用后端接口时，调用发起请求API

当需要上传下载时，调用上传下载API

当需要数据缓存时，调用本地存储API

引入地图、使用罗盘、调用支付、调用扫码等等功能都可以直接使用

UI库方面，框架自然带有自家weui库加成

并且在使用这些API时，你不用再去顾虑浏览器兼容性，不用担心生产环境中出现不可预料的奇妙BUG，可见微信小程序的开发成本确实相比以往的web开发低很多。

三、获取系统级权限的不同。

微信小程序相对于HTML5web应用能获得更多的系统权限，比如网络通信状态、数据缓存能力等，这些系统级权限都可以和微信小程序无缝衔接，也就是官方宣称的拥有NativeApp的流畅性能，而这一点恰巧是HTML5web应用经常被诟病的地方，这也是HTML5的大多应用场景被定位在业务逻辑简单、功能单一的原因。

四、应用在生产环境的运行流畅度。

这条无论对于用户还是开发者来说，都是最直观的感受。长久以来，当HTML5应用面对复杂的业务逻辑或者丰富的页面交互时，它的体验总是不尽人意，需要不断的对项目优化来提升用户体验。但是由于微信小程序运行环境独立，尽管同样用htmlcssjs去开发，但配合微信的解析器最终渲染出来的是原生组件的效果，自然体验上将会更进一步。

首先，下载微信小程序源码，用微信开发者工具打开，在不同的小程序设置页中，根据参考文档步骤配置appid、appsecret等，此配置十分重要，保证每个参数正确无误，同时配置后端服务器地址。

检查是否按照weui样式框架编写，非 weui 样式编写或者是布局表现明显有误的话，调整样式，正确的完成HTML布局。

检查从小程序端拉取数据时，后台服务器是否使用>

一、首先打开可免费小程序制作网站类似网站还有不少，大家可以多找几个对比试试。打开网站后，填写好基本信息注册并登陆，然后点击立刻免费建站。

二、接下来选择要建立的小程序类型，如下图所示。

三、再下来是点击选择小程序模板，也就是你喜欢的风格样式，然后会打开对应的模板，然后根据自己想要的进行选择即可！

四、然后根据小程序制作向导进行编辑修改就可以了，如下图所示。

编辑好后可以进行预览效果，直到编辑到自己满意为止。

五、自己的小程序制作好了之后，最后就是绑定微信小程序，发布即可。

以上就是10分钟制作属于自己的小程序教程，可视化 *** 作，无需会编程，小白也可以轻松制作自己的小程序了。

以上就是关于微信小程序和HTML5与之间的区别全部的内容，包括:微信小程序和HTML5与之间的区别、小程序开发-基础-html+css、HTML5和微信小程序的异同等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！