无论是公共号还是H5开发都是使用的网页开发，本质上是一样的，差别可能在于有对使用环境做限制； 比如公共号里面的网页可能限制了只能在客户端里面打开，才可以实现微信登录，支付等等功能；但H5可能就没有这些限制； H5还可以内嵌在APP壳子里面，成为一个独立的APP，完全脱离微信客户端，就可以独立实现一些原生APP才有的功能；如果是H5可以试一试一门APP打包；
把手机h5页面转成微信小程序，可以通过代码实现，方法及详细的操作步骤如下：
1、首先，一个h5页面，其中包含四个文件。
2、其次，由于操作环境不同，为了在编译时和运行时执行一些兼容的操作，需要一个配置文件。
3、接着，编写一个名为“build.js”的构建脚本。
4、然后，执行先前编写的脚本。
5、最后，手机h5页面就转成了微信小程序。
一、运行环境的不同
H5的运行环境是浏览器，包括webview，而微信小程序的运行环境并非完整的浏览器，因为小程序的开发过程中只用到一部分H5技术。
小程序的运行环境是微信开发团队基于浏览器内核完全重构的一个内置解析器，针对性做了优化，配合自己定义的开发语言标准，提升了小程序的性能。
二、开发成本的不同
开发一个微信小程序，由于微信团队提供了开发者工具，并且规范了开发标准，则简单得多。前端常见的HTML、CSS变成了微信自定义的WXML、WXSS，WXML，官方文档中都有明确的使用介绍，开发者按照说明专注写程序就可以了。
需要调用后端接口时，调用发起请求API；需要上传下载时，调用上传下载API；需要数据缓存时，调用本地存储API；引入地图、使用罗盘、调用支付、调用扫码等等功能都可以直接使用；UI库方面，框架带有自家weui库加成。
并且在使用这些API时，不用考虑浏览器兼容性，不用担心出现BUG，显而易见微信小程序的开发成本相对低很多
三、获取系统级权限的不同
微信小程序相对于H5能获得更多的系统权限，比如网络通信状态、数据缓存能力等，这些系统级权限都可以和微信小程序无缝衔接。
而这一点恰巧是H5 被诟病的地方，这也是H5的大多应用场景被定位在业务逻辑简单、功能单一的原因。
四、页面体验不同
H5网页需要在浏览器中渲染，会给人明显的「卡顿」感觉，面对复杂的业务逻辑或者丰富的页面交互时尤为明显。
而微信小程序，它的代码直接在微信上运行，省去了通过浏览器渲染的步骤，因此，在微信中使用小程序，才会比H5流畅很多。
除了首次打开需要几秒的加载时间外，小程序各个页面的切换、跳转等体验已经媲美原生App，有着同样的柔丝般顺滑的效果。
第一、运行环境不同传统的HTML5的运行环境是浏览器，包括webview，而微信小程序的运行环境并非完整的浏览器。小程序的开发过程中会用到HTML5相关的技术(并非全部)。
第二、开发成本的不同第三、获取系统级权限的不同微信小程序相对于HTML5 web应用能获得更多的系统权限，比如网络通信状态、数据缓存能力等，这些系统级权限都可以和微信小程序无缝衔接，也就是官方宣称的拥有Native App的流畅性能，而这一点恰巧是HTML5 web应用经常被诟病的地方，这也是HTML5的大多应用场景被定位在业务逻辑简单、功能单一的原因。
第四、应用在生产环境的运行流畅度长久以来，当HTML5应用面对复杂的业务逻辑或者丰富的页面交互时，它的体验总是不尽人意，需要不断的对项目优化来提升用户体验。
但是由于微信小程序运行环境独立，尽管同样用html+css+js去开发，但配合微信的解析器最终渲染出来的是原生组件的效果，自然体验上将会更进一步。
h5小游戏可通过代码开发和专业的制作工具制作。
如果你想自己通过代码进行定制的话，可以在网上搜一搜html、css之类的教程，但由于这些技术的专业性比较高，要在短期内学好几乎是不太可能的。
如果你想尽快掌握H5小游戏的制作技能，那你可以选择直接使用意派Epub360 H5页面制作工具进行制作。它是一款专业的h5页面制作工具，支持SVG路径动画、微信高级接口JsSDK以及摇一摇、碰撞检测、重力感应、关联控制等。此外，它还拥有参数变量、条件判断、数据库等高级数据组件，可轻松实现测试题、抽奖、社交轻游戏类H5设计。
你可以先熟悉各项功能组件，再到意派Epub360的教程中心搜索关键词查看相应的教程，有了教程，学起来会容易得多。
以下是使用意派Epub360制作的h5游戏案例，感兴趣的朋友可以到意派官网的案例库中查找、参考~
将小程序植入H5跳转，需要先在小程序管理后台设置小程序跳转H5的URL和参数，并在H5页面中添加跳转代码，如在链接中加入小程序的AppID、页面路径等信息。
当用户点击跳转按钮时，H5页面会自动调用微信客户端打开小程序，并跳转到指定页面。同时，还需要注意用户手机上是否已安装微信客户端以及微信版本是否支持跳转功能。因此，跨平台跳转需谨慎选择，避免用户体验受到影响。
小程序的技术，是基于HTML和CSS以及JS的 HTML5包含HTML、CSS、JavaScript技术 小程序当中，结构的书写方式、CSS的样式处理以及JS的一些处理是和HTML5完全相同的，但是在数据交互方式上有自己的规则，还需要学习相应的规则（特定语法），才能够做。
微信小程序上线大半年，大部分技术原理也有文章介绍了，本文尝试从需求出发探讨微信小程序技术方案的来源，以及最近公测的支付宝小程序技术方案的考量。
微信小程序
微信小程序的需求是让第三方开发者可以接入，可以使用微信的提供的接口去开发应用嵌入在微信里。对于这个需求，最简单的实现方案是：让外部开发者开发纯H5应用，在微信的 H5 容器里打开，容器提供微信 native 接口，就行了。在有小程序之前，已经有很多这样的业务接入，像京东购物，钱包里的各种友商大众点评/滴滴出行等，都可以认为是一个“小程序”，内嵌在微信里，能调用微信 native 接口，是不是沿着这种模式下去，把相应的接口开放给第三方，再提供个入口就行了？
实际上这种简单的方案不能满足需求，在产品上微信小程序有另外两个很重要的需求：
管控。作为一个平台必须对接入的应用有管控能力，必须能尽量精确控制应用的内容和类型，毕竟若出现非法应用平台是要承担责任的，H5 的方式太过自由，开发者可以随时改变整个应用的内容，平台难以检测到这些改变，无法管控。另外H5开发质量参差不齐，平台也无法管控，这对于一向有洁癖的微信来说无法接受。
体验。作为一个“小程序”需要让体验接近原生，而上述像京东购物这些普通 H5 页面的体验不太行，包括启动速度/页面切换流畅度都有问题，跟原生体验没法比。
所有小程序的技术方案都是为了这两个需求服务。
管控
为了满足管控的需求，技术上微信做了两个事情：小程序框架和分离JS运行环境。
框架/DSL
H5太自由，首先要做的就是限制它的自由，怎样限制？自然是做个框架套住，让开发者只能按框架的规则去开发。那应该使用怎样的框架？
在 PC SNS 时代，Facebook 做开放平台时有类似的场景，为了第三方开发者能在 Facebook 平台上开发，同时又能限制住开发者的权限，Facebook 要求开发者使用自定义的一套 DSL(FBML)去开发，而这个 DSL 能怎么写，最终能转成什么，如何执行，都是平台说了算，同时也可以很方便做代码扫描和审查。
小程序正好能借鉴这样的设计思路，界面不使用 HTML 开发，而是自定义一套 DSL，这样就可以很容易配合审核/代码扫描/域名限制等系列措施去做管控，这就是小程序这一套框架的来源。这套框架通过 wxml 去描述界面，wxss 描述样式，js 去处理逻辑和数据，再通过工具一系列处理把这些转为 HTML/CSS/JS 显示在 webview 上，并处理界面交互和数据更新。
这样用一套框架去限制开发方式，再造一层 DSL，除了管控外还有一个好处，就是容易进行针对性优化，DSL 最终转成什么，最终如何执行渲染都由框架决定，上层不感知，可以做成由 webview 渲染，有条件也可以用类似RN的方案自己实现渲染层。
JS 环境
通过框架限定开发方式后，管控上还有个问题，就是如何限制应用端类JS语言调用dom API？小程序跑在 webview 上，渲染时必然要通过 JS 操作 dom，如果小程序框架和应用 JS 代码都有权限操作 dom，应用可能会通过各种方式在上线后绕过检查，注入 JS 调用 dom 接口去修改页面结构和内容，变成跟审核时不一样的应用。怎样能限制应用的 JS 调用 dom 的权限？微信想了个比较创新的解决方案，就是：JS 运行环境与浏览器分离，运行在单独的 JS 引擎上。
脱离了浏览器，JS 自然没有 dom 的调用权限，任何跟 webview 界面相关的 API 都无法拿到。而小程序框架核心JS运行在webview上，可以自由操作dom，通过小程序框架定义的机制，应用端通过 wxml/wxss 定义固定的渲染样式，JS 端只管数据绑定，数据可以通过 native 桥梁从 JS 引擎传递到 webview，JS端无法做任何渲染相关的操作，可以对渲染的内容有完整的管控权。
独立的 JS 运行环境除了满足管控需求外，也额外带来一些好处和一些坏处，好处在于：
多个页面可以共享一个 JS 运行环境，数据可以很方便地共享，整个小程序生命周期里共享同一个上下文，更接近 APP 的开发体验。
JS 与页面渲染分离并行执行，不会出现 JS 执行时卡住页面渲染的情况，提升渲染性能。
坏处在于：
多了数据序列化传输的开销，数据需要从 JS 传到 webview 给视图层渲染，需要序列化为字符串格式再进行传输。
iOS 上 WKWebview 的 JS 引擎比 JavaScriptCore 多了 JIT 优化，执行速度快很多倍，小程序的 JS 运行在 JavaScriptCore 上无法享受到这个优化。
由于管控需求过于刚需，这个方案带来坏处可以接受。
体验
小程序最主要的两个技术点 — 框架和JS运行分离 都是源自管控需求，而体验上的需求就是由各种细致的性能优化组成了，很多文章也分析过，这里简单说下，包括：
离线包：整个小程序打包下发，不需要打开每个页面都去请求，减少第二次打开时间以及页面切换时间。
预加载：预加载多一个wkwebview放后台，用户打开小程序时省去初始化wkwebview时间。另外对于一个小程序内的页面切换，得益于框架的设计，可以做到预渲染模板，切换时再填充数据，加快渲染速度。
缓存：退出小程序后不会立即销毁，会在后台继续跑5分钟，在这期间用户切回小程序时速度快。
视觉：小程序首次加载通过loading和动画的方式过渡，拒绝白屏，给人一种快的感觉，同时提升了小程序的标识度。
剩下的就是围绕小程序这个平台的周边建设了，像组件，native接口，IDE，后台管理，版本管理，权限控制等基础支持。
支付宝小程序
策略
微信小程序推出时主要面向的场景是线下，希望商家能开发小程序，做像点菜买票这样的即时性应用，提升线下商户体验，支付宝作为线下战场的主要竞争对手自然要跟进。
支付宝要做小程序应该怎么做？可以根据自身的情况，定义另一套技术体系，让第三方接入。但这样的话第三方如果要同时接入微信和支付宝，需要开发两套程序，成本很高，而微信有先发和平台优势，很可能变成只开发微信小程序而放弃接入支付宝小程序，所以最好的做法是降低这里的接入成本，让微信小程序的代码可以复用在支付宝小程序上。所以支付宝小程序对外的框架/API/组件必须是跟微信小程序接近或力求一致，技术上没得选择，所以可以看到支付宝小程序公测版的文档很多跟微信一致。
实现
支付宝小程序框架对外接口是跟微信一样，又因为同样有管控/安全和体验的需求，有些策略是类似的，像独立 JS 环境，离线包，缓存策略等，但在小程序框架的实现上就跟微信完全不一样。小程序框架作为一层屏蔽了实现细节的 DSL 层，最终通过什么技术手段实现都可以是由框架底层自由定制的，这边底层架构基于蚂蚁前端团队多年的积累，最终 web 版小程序是以 react 为基础实现。
React Native
除了对外的跟微信一致的 web 版小程序，内部一直在尝试 React Native 版小程序，渲染层不适用 webview，而是用 RN 去渲染，提升性能和体验，这也是小程序 DSL 层带来的好处，底层渲染引擎可以很方便地替换实现方案，甚至同时存在多套方案。
很多人问为什么不用 weex，按我理解首先是蚂蚁的前端技术栈基于 react，切换成本高，另一个 RN 相对 weex 成熟度高，社区支持度高，并保持着不间断的更新，相对友好。
RN 本身不跨平台，iOS/Android有各自的写法，在 RN 的使用上，业界很多人各自实现了基于 RN 的跨三端或两端的开发方式（例如JDReact），也就是一次开发，能同时支持 RN 在 iOS / Android 两端做原生渲染，也支持 fallback 到 webview 渲染。这里小程序也算是这样一套方案，上层通过自定义 DSL 开发业务，部署时通过工具分别转换成三个平台不同的代码，在三个平台运行。
内部应用
小程序是一套对外的方案，主要用于第三方应用接入，因为上文也说了，框架上很多技术方案都是为了满足对第三方管控和安全方面的需求，而小程序相关的很多体验优化其实用纯 H5 也可以做到，内部业务用 web 版小程序开发并没有带来什么好处，反而增加学习成本。但 RN 版小程序不一样，它有一些优势，包括：
RN 相对 webview 性能优势明显，秒开率高，交互也更流畅。
相对于单纯使用 RN 开发，使用小程序可以屏蔽平台差异，实现跨平台一次开发。
小程序有配套的开发环境/IDE/包管理等基础设施支持，无需再重复建设。
对于业务开发者，小程序不是全新的一套开发方式，在业界可复用，对于框架实现者，RN也是业界流行开源方案，有强大的社区支持。对内对外都避免了另外创建一套只能在内部使用的技术体系，极大降低技术成本。
基于这些原因，在蚂蚁财富这边一些内部原本应该使用 H5 实现的业务，也正尝试更多地使用小程序实现，以提升用户体验，目前部分基于小程序 RN 版开发的业务已在线上稳定运行，后续也会继续尝试把小程序 RN 版持续打造成高性能稳定的三端统一动态化方案。
微信扫码
用户中心
意见反馈
APP
热线电话