摘要：整个小程序所有分包大小不超过单个分包主包大小不能超过微信小程序主流框架对比应该算是最早发布的小程序开发框架，提供了类的语法风格和特性，现阶段应该也是应用最广泛的框架吧。不过微信官方为了防止下载离线包的时间过程，也严格限制了小程序包的体积。
那些年我们踩过的坑
css样式不能引用本地图片资源，只能引用线上资源(background-image)，引用本地图片资源只能用
{{}}不能执行函数方法，{{}}只支持基本的简单运算和ES6拓展运算符。如价格格式化这种常用的处理，只能在js代码中处理好然后再模板中渲染。
this.setData({ price: this.formatPrice(this.data.price)})
可以通过wxs模块解决{{}}中不能执行函数的问题。可以做到模拟vue.js中过滤器的功能。
// wxs模块var formatPrice = function (price){ price = price >> 0; return Number(price / 100).toFixed(2);}module.exports = { formatPrice}
小程序不支持分享链接到朋友圈，暂时的通用做法是生成保存有页面小程序吗的图片到本地相册。又用户自行发朋友圈转发。前端可以利用canvas来实现，减轻服务端压力。但是会有图片锯齿不清晰的问题。建议预览图和保存到真机的图片采用不同的尺寸。保存在真机的图片按照750的宽度实现。相比于预览图要大一些，这样保存到手机的图片会清晰很多。
小程序布局采用rpx单位，UI稿按照750的宽度出图。可直接使用UI稿的尺寸。但是在某些机型上1rpx会无法显示。可以用H5的方式实现1px效果。
iphoneX吸底按钮的适配，可以用媒体查询获取wx.getSystemInfo获取机型。参考
@media only screen and (device-width : 375px) and (device-height : 812px) and (-webkit-device-pixel-ratio : 3) { }
页面A -> 页面B，页面B的操作触发了页面A的数据更新。返回更新页面A的数据，通常有两种方式来实现(我司采用了方案二)：
在页面A监听onShow事件，在onShow事件触发时无脑更新页面数据。
通过EventBus来实现跨页面通信。
复杂组件的开发，省市区三级联动选择器的开发，获取微信地址库的地址的编码和业务采用的省市区编码对不上。
页面路径的层级，最大不能超过10层。
小程序小程序分包加载，微信对小程序包的大小有如下限制。
整个小程序所有分包大小不超过 8M
单个分包/主包大小不能超过 2M
微信小程序主流框架对比
wepy
mpvue
Taro
wepywepy应该算是最早发布的小程序开发框架，提供了类vue.js的语法风格和特性，现阶段应该也是应用最广泛的框架吧。我开发的几个小程序也都是采用了wepy这个框架。我先来说说当初为什么选择这个框架的原因吧。
类Vue.js的语法风格，适合我们团队原有的的技术栈
支持组件化（当时微信官方的API还不支持组件化）
支持加载外部npm包
支持ES6的写法
前期使用wepy的过程中，wepy自带bug。不过好在开发者响应及时，基本上都能覆盖大部分场景。
但是有个最大的坑点就是，wepy组件的实现方式。组件使用的是静态编译组件，即组件是在编译阶段编译进页面的，每个组件都是唯一的一个实例。 多个组件共享同一个数据。并且静态编译组件。导致组件A，在页面A和页面B被引用，会copy两份代码到页面A和页面B内部。导致拆分组件并没有对包的体积有任何减少。后期微信官方API支持组件化编程后，我们逐步把一些比较核心，体积较大的组件用原声API重构了。
mpvue由美团团队开发，mpvue和wepy一样也是在小程序上提供了类vue.js的开发体验。作为后来者，抢占了很多wepy的市场份额（ps：我们团队近期也在考虑从wepy迁移到mpvue）。这个框架的原理相比wepy要更加复杂一点，mpvue 修改了 Vue.js 的 runtime 和 compiler 实现，提供了更加接近于vue.js的开发体验。
TaroTaro是由京东团队开源的一套遵循 React 语法规范的多端开发解决方案。本身我对React和Taro都不是很了解，就不多解释了。具体可以看开发团队的博客和代码了解更多细节多端统一开发框架 - Taro
我看小程序我想从技术的角度来谈谈我对微信小程序的理解，我觉得小程序本身是一个非常优秀的Hybrid App的技术方案。有很多值得学的地方，可以应用到我们Hybrid App的技术方案设计中来。了解和学习小程序技术原理也能更好的优化我们的代码。
渲染层和逻辑层分离
相比于之前常见的Hybrid的方案，小程序使用了双线程模型：小程序的渲染层和逻辑层是是分开的，逻辑层通过JSCore来解析和执行，渲染层是通过webview来渲染。之前的常见Hybrid离线包的方案大多使用webview同时实现页面的渲染和js的解析。这样做的的结果就是隔离了js的runtime，在js代码中无法操作webview中的DOM对象和BOM对象。Js无法做任何和页面渲染有关的操作。只能通过setData把数据从JsCore传递到webview。
独立的JS运行环境，相比于webview同时处理页面的渲染和JS的执行带来了一些好处：
js无法动态的在页面插入节点和干预页面的渲染，解决了安全和管控的问题，否则小程序的上线审核就变得毫无意义。
渲染层和逻辑层的分离，减轻了webview的压力，js的执行和页面的渲染可以并行，不会出现js执行卡主页面渲染的情况。
多个页面可以共享一个JS运行环境，数据很方便的共享，整个小程序的生命周期共享同一个上下文，接近App的体验。
坏处在于：
多了很多webview和JSCore数据传输的消耗，数据需要序列化成字符串格式进行传输。
离线包加载离线包加载，常见的Hybrid App通过webview加载H5页面，前端页面都是放在服务器端。虽说保证了灵活性。但是加载性能收网速影响大。页面切换白屏时间长。小程序离线包的加载方式。一次性加载所有的前端资源到本地再解压。大大提升了用户体验。不过微信官方为了防止下载离线包的时间过程，也严格限制了小程序包的体积。（分包加载情况下子包大小不能超过2M，也就是初次打开加载的资源不能超过2M）
多webview架构多webview的页面架构，小程序每新开一个页面，都会用一个新的webview来渲染。为了防止webview对内存的消耗。小程序限制层级不能超过10层。
预加载webview预加载webview，微信会预加载多一个wkwebview(ios平台)放后台，用户打开小程序时省去初始化wkwebview时间。
更多技术资讯可关注：gzitcast
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/116369.html
摘要：框架这部分是小程序开发的核心，小程序采用视图和逻辑层代码相分离的结构，如果你用过这部分也不难理解，但是也有一些区别。工具这部分没有什么好说的，微信开发开始还是用微信自己的开发工具比较方便。 小程序开发文档使用说明 小程序的文档分为 简易教程、框架、组件、API 、工具https://developers.weixin.qq.... 简易教程---介绍小程序开发的一些基本情况 开发方式...
摘要：和都是辅助小程序开发的开源库，本文对两者做个对比。微信的这种限制决定了小程序一般只是用于实现核心功能，不会用作复杂功能。在笔者了解的很多小程序，甚至大都是用原生开发的。 grace和wepy都是辅助小程序开发的开源库，本文对两者做个对比。 注：本文是作者本人的一些拙见，纯粹的技术讨论，不想引起技术信仰之争，欢迎积极、正向的讨论及建议。 如果你还不了解Grace, 请参考：微信小程序开发...
摘要：微信小程序应用号开发资源汇总文档工具教程代码插件组件文档从搭建一个微信小程序开始小程序开发文档小程序设计指南工具小程序开发者工具官方支持微信小程序实时预览的支持的微信小程序组件化开发框架转在线工具小程序云端增强社区微信小程序 微信(小程序or应用号)开发资源汇总-文档-工具-教程-代码-插件-组件 文档 从搭建一个微信小程序开始 小程序开发文档 小程序设计指南 工具 小程序开发者...
摘要：官方资料微信公众平台注册小程序。官网开发文档社区开发工具部署微信小程序微信小程序本身不需要部署，在微信开发工具中直接上传代码就行。 为什么 学习 Java 三年，目前已经工作了2年，因为自学，基础差，所以打算年末总结一下常见的基础知识和面试点； 也可以通过独立做一个项目整合自己工作期间学习的知识，加深印象。 但是想着回家或是平时手机用的多，做一款APP和小程序很方便查看。 项目展示 本...
阅读 2767·2021-11-22 09:34
阅读 2296·2021-09-30 09:47
阅读 1163·2021-09-03 10:32
阅读 3471·2021-08-16 10:49
阅读 1593·2019-08-30 15:55
阅读 2309·2019-08-30 15:52
阅读 3216·2019-08-30 15:44
阅读 1204·2019-08-30 15:44
