接触小程序有一段时间了，总得来说小程序开发门槛比较低，但其中基本的运行机制和原理还是要懂的.
但JS-SDK 的模式并没有解决使用移动网页遇到的体验不良的问题，比如受限于设备性能和网络速度，会出现白屏的可能。因此又设计了一个增强版JS-SDK，也就是“微信 Web 资源离线存储”，但在复杂的页面上依然会出现白屏的问题，原因表现在页面切换的生硬和点击的迟滞感。这个时候需要一个 JS-SDK 所处理不了的，使用户体验更好的一个系统，小程序应运而生。
- 快速的加载
- 更强大的能力
- 原生的体验
- 易用且安全的微信数据开放
- 高效和简单的开发
小程序的开发同普通的网页开发相比有很大的相似性，小程序的主要开发语言也是 JavaScript，但是二者还是有些差别的。
- 普通网页开发可以使用各种浏览器提供的 DOM API，进行 DOM 操作，小程序的逻辑层和渲染层是分开的，逻辑层运行在 JSCore中，并没有一个完整浏览器对象，因而缺少相关的DOM API和BOMAPI。
- 普通网页开发渲染线程和脚本线程是互斥的，这也是为什么长时间的脚本运行可能会导致页面失去响应，而在小程序中，二者是分开的，分别运行在不同的线程中。
- 网页开发者在开发网页的时候，只需要使用到浏览器，并且搭配上一些辅助工具或者编辑器即可。小程序的开发则有所不同，需要经过申请小程序帐号、安装小程序开发者工具、配置项目等等过程方可完成。
小程序启动会有两种情况，一种是「冷启动」，一种是「热启动」。假如用户已经打开过某小程序，然后在一定时间内再次打开该小程序，此时无需重新启动，只需将后台状态的小程序切换到前台，这个过程就是热启动；冷启动指的是用户首次打开或小程序被微信主动销毁后再次打开的情况，此时小程序需要重新加载启动。
作为开发者，无论是前端开发者，还是后端开发者，了解常见的安全问题，以及常见的解决方案是非常必要的。
对于这样的问题，微信官方并没有做出太多反制措施。毕竟小程序模拟的是浏览器，一般的前端项目，在浏览器端右键即可查看源码，在控制台可以查看网络请求等更加详细的信息。
开发者很容易通过抓包，第三方工具等方式获取到小程序的网络请求。小程序开发者应当在后台接口被调用时，对本次调用进行权限校验，包括自建后台接口和云函数，否则容易发生越权问题和数据泄漏。
对于敏感数据、开发能力相关接口需要在后台进行鉴权，通常可检验openid，IP地址，自定义登录态等信息。
鉴权的逻辑应该放在后台进行，不应在小程序中以隐藏页面、按钮等方式来代替。
常见的鉴权示例如下：
//自建后台鉴权functionactionDelete(){ $item_id = $_POST["item_id"]; $openid = $_POST["openid"]; $ip = $_SERVER['REMOTE_ADDR']; $user_role = $_SESSION["user_role"];if($openid ==="xxx"&& $ip ==="192.168.0.101"&& $user_role ==="admin") {// 进行删除操作// ...return0; }else{// 记录非法请求// ...return-1; }}//云函数鉴权exports.main =async(event, context) = {const{ OPENID, APPID, UNIONID } = cloud.getWXContext();if(OPENID ==="xxx") {// 进行删除操作// ...}else{// 记录非法请求// ...}}当使用 git、 svn 等版本管理工具时，会产生 .git 等目录。某些编辑器或软件也会在运行过程中生成临时文件。若这些目录或文件被带到生产环境，则可能发生源码泄漏。
对于包含用户输入内容，如评论、修改昵称、头像等功能。开发者需要自行调用信息过滤接口，判定内容是否有违规内容。对于没有配置相应功能的小程序，会被警告然后限制搜索。我之前开发过的一款社区类目小程序就因为这个原因，被封禁了好久。
对于存储在本地的敏感数据，如用户信息，openid等数据，开发者应当对敏感数据自行加密存储。
什么是双线程架构？
一条线程负责处理逻辑层一条线程负责处理渲染层。线程之间通过native层通信。
1.最重要的点： 这个一个基于安全于管控的方案
2.其次：比纯web更好的交互体验。
3.原生版本迭代更为便捷 小程序选择的是webview+原生组件的形式，hybrid方式，既享受到了webview页面的低门槛和在线更新，️可以使用部分流畅的native原生组件，并且最重要的是空对开发的内容进行一定程度按的管控，同时在安全问题从设计层面就予以了解决。
首先说小程序的交互体验肯定是比不上原生app的，app的响应速度肯定是最快的，相对指的的h5 web，网页开发的渲染线程和脚本线程是互斥的，二者是共享一个线程的，也就是说在运行脚本线程的时候可能会让页面失去响应，所以这也是为什么我们在开发网页的时候需要将script脚本的引入放在body的后面然后winow.onload去知道已经渲染完的节点。而在小程序中渲染线程和逻辑（脚本）线程相互独立，不能直接干扰对方，渲染线层和逻辑线程可以同时运行。联想一下，这是不是从设计层面就规避了react16推出fiber架构所为了解决的最重要的问题问题（一次大的更新任务会长时间占据着当前线程的资源，导致页面无法响应带来的交互问题！）。
我们都知道原生渲染的体验优势，这也是为什么会出现夸端框架的weex,react native ，flutter的框架去直接生成原生应用的方式来进行开发，但是小程序是依赖于宿主环境的，小程序的发版不可能说随着微信的大版本去迭代，如果是这样我觉得就和小程序分质治理的理念不合了，也会有很多的弊端，并且也不能发挥web的优势。
那么web的优势是什么呢？--答案是在线更新。--，小程序也是在线更新，但是小程序比h5多了另外一项优势--底层资源的动态注入。h5的脚本资源都是通过请求获取的，获取完了之后还要解析，然后再去运行实际的业务层面的代码。而在小程序中在初始化的时候，native就会将WXSDK动态的加载注入到新打开的页面中，由于小程序的pageFrame技术，在后续打开的页面中，直接读取缓存中准备数据，直接省去的解析的过程。小程序这些优化直接的效果是
自2017年上线以来，小程序就一直是互联网巨头的“兵家必争之地”，腾讯、阿里、百度、字节等都期望借助小程序的能力建设来丰富自家的生态，将自家的主流平台打造成为超级App。
但，时至今日，互联网巨头的蜂拥而至却反而为小程序开发者和品牌商家提供了更多元的选择，使得旗下的小程序应用不需要局限在单一平台生态之下。
虽然互联网大厂并未将这部分小程序运行能力技术开放出来，但是我们也不必望而生羡，市面上早就推出了类似的技术能力，我们一般称之为小程序容器技术。
今天要给大家分享的也正是目前在 GitHub 很热门的前端容器技术 —— FinClip 。
只需简单集成 FinClip SDK , 即可在 iPhone、Android、Windows、Linux、macOS、统信等平台下的应用中运行你的小程序。
而且 FinClip SDK 极其轻量，应用在集成后安装包的体积仅仅增大了不到 3MB。
你可以在这个 FIDE 里面，对现有项目进行二次开发，扩展功能和接口。
同时，它还支持 小程序一键转换成 App，可以将已有小程序代码导出为 IOS 与 Android 中可用的工程文件,并上架至各应用市场 。由于导出的工程文件自动集成了 FinClip SDK ，所以直接拥有小程序的运行能力，后续可在这个 APP 上继续上架更多小程序，自建自己的小程序生态。
并且 FIDE 中还包含各类扩展插件和接口，开发者可自主勾选所需的支持插件，从而增强所生成 App 原生能力。
在小程序开发前，需要了解相应的问题，以预防可能出现的问题。在开发完成后，也要对可能出现问题的地方进行排查，防止出现不要用的损失。