大家好我是源源，微信小程序api文档，关于微信小程序api文档怎么做很多人还不知道，那么现在让我们一起来看看吧！

微信小程序api文档 微信小程序api文档怎么做微信小程序api文档 微信小程序api文档怎么做


微信小程序api文档 微信小程序api文档怎么做


1、框架/DSL微信小程序上线大半年，大部分技术原理也有文章介绍了，本文尝试从需求出发探讨微信小程序技术方案的来源，以及最近公测的支付宝小程序技术方案的考量。

2、微信小程序微信小程序的需求是让第三方开发者可以接入，可以使用微信的提供的接口去开发应用嵌入在微信里。

3、对于这个需求，最简单的实现方案是：让外部开发者开发纯H5应用，在微信的H5容器里打开，容器提供微信native接口，就行了。

4、在有小程序之前，已经有很多这样的业务接入，像京东购物，钱包里的各种友商大众点评/滴滴出行等，都可以认为是一个“小程序”，内嵌在微信里，能调用微信native接口，是不是沿着这种模式下去，把相应的接口开放给第三方，再提供个入口就行了？实际上这种简单的方案不能满足需求，在产品上微信小程序有另外两个很重要的需求：管控。

5、作为一个平台必须对接入的应用有管控能力，必须能尽量控制应用的内容和类型，毕竟若出现非法应用平台是要承担的，H5的方式太过自由，开发者可以随时改变整个应用的内容，平台难以检测到这些改变，无法管控。

6、另外H5开发质量参不齐，平台也无法管控，这对于一向有洁癖的微信来说无法接受。

7、作为一个“小程序”需要让体验接近原生，而上述像京东购物这些普通H5页面的体验不太行，包括启动速度/页面切换流畅度都有问题，跟原生体验没法比。

8、所有小程序的技术方案都是为了这两个需求服务。

9、 管控为了满足管控的需求，技术上微信做了两个事情：小程序框架和分离JS运行环境。

10、H5太自由，首先要做的就是限制它的自由，怎样限制？自然是做个框架套住，让开发者只能按框架的规则去开发。

11、那应该使用怎样的框架？在PCSNS时代，Facebook做开放平台时有类似的场景，为了第三方开发者能在Facebook平台上开发，同时又能限制住开发者的权限，Facebook要求开发者使用自定义的一套DSL(FBML)去开发，而这个DSL能怎么写，最终能转成什么，如何执行，都是平台说了算，同时也可以很方便做代码扫描和审查。

12、小程序正好能借鉴这样的设计思路，界面不使用HTML开发，而是自定义一套DSL，这样就可以很容易配合审核/代码扫描/域名限制等系列措施去做管控，这就是小程序这一套框架的来源。

13、这套框架通过wxml去描述界面，wxss描述样式，js去处理逻辑和数据，再通过工具一系列处理把这些转为HTML/CSS/JS显示在webview上，并处理界面交互和数据更新。

14、这样用一套框架去限制开发方式，再造一层DSL，除了管控外还有一个好处，就是容易进行针对性优化，DSL最终转成什么，最终如何执行渲染都由框架决定，上层不感知，可以做成由webview渲染，有条件也可以用类似RN的方案自己实现渲染层。

15、JS环境通过框架限定开发方式后，管控上还有个问题，就是如何限制应用端类JS语言调用domAPI？小程序跑在webview上，渲染时必然要通过JS作dom，如果小程序框架和应用JS代码都有权限作dom，应用可能会通过各种方式在上线后绕过检查，注入JS调用dom接口去修改页面结构和内容，变成跟审核时不一样的应用。

16、怎样能限制应用的JS调用dom的权限？微信想了个比较创新的解决方案，就是：JS运行环境与浏览器分离，运行在单独的JS引擎上。

17、脱离了浏览器，JS自然没有dom的调用权限，任何跟webview界面相关的API都无法拿到。

18、而小程序框架核心JS运行在webview上，可以自由作dom，通过小程序框架定义的机制，应用端通过wxml/wxss定义固定的渲染样式，JS端只管数据绑定，数据可以通过native桥梁从JS引擎传递到webview，JS端无法做任何渲染相关的作，可以对渲染的内容有完整的管控权。

19、多个页面可以共享一个JS运行环境，数据可以很方便地共享，整个小程序生命周期里共享同一个上下文，更接近APP的开发体验。

20、JS与页面渲染分离并行执行，不会出现JS执行时卡住页面渲染的情况，提升渲染性能。

21、坏处在于：多了数据序列化传输的开销，数据需要从JS传到webview给视图层渲染，需要序列化为字符串格式再进行传输。

22、iOS上WKWebview的JS引擎比JaScriptCore多了JIT优化，执行速度快很多倍，小程序的JS运行在JaScriptCore上无法享受到这个优化。

23、由于管控需求过于，这个方案带来坏处可以接受。

本文到这结束，希望上面文章对大家有所帮助。