背景
都知道小程序的体验要比app里面直接嵌入h5的体验要好，都知道小程序其实也是运行在app上的。那么我们为什么不能用小程序来开发app呢？这样不仅可以小程序和app只要开发一次，小程序和app都有了。还可以实现app动态更新不需要提交应用市场审核，我们只要做个小程序载体的app壳（类微信端小程序 sdk），而且体验效果也接近原生。做一个类似小程序平台把我们现在的app项目框架从组件化改成为小程序平台构架。
每个业务程序都是一个个小程序，原生提供原生能力。
什么是小程序
首先我们要知道小程序是啥？现在市场上的小程序有很多，微信小程序、百度小程序、支付宝小程序、字节跳动小程序等但都差不多。与传统app相比，小程序无需安装、卸载，运行在微信、百度、支付宝等这样大型app载体上。虽然每种小程序都差不太多，但都定义了自己的开发语言和规范，这对开发者来说也是不少的麻烦。
小程序是介于web网页应用和原生应用的一种产物；
小程序和Hybrid APP的关系
原以为Hybrid APP就是用app的webview去加载一个h5文件，然后webview通过js桥梁和原生通信，实现js调用h5方法，h5方法调原生方法。来弥补h5无法拍照、打电话等不足。但是做出来的效果h5都会有短暂白屏，体验也无法达到原生效果（提供一个简单的demo）。后来接触了小程序，觉得小程序的体验和原生差不了多少了，可以说不是专业人员基本是看不出区别的，原先以为小程序是类似RN、weex这样的原生渲染，后面才知道它也是webview渲染。竟然也是hybird app，那它的体验是什么上去的？都是webview渲染，为什么小程序的体验会比普通的h5好？这让我非常感兴趣，于是就开始了小程序的深入了解。
初步了解用h5做Hybrid APP和小程序的区别：
相同点：
1.都是webview渲染
2.都是js通过桥接和原生通信
3.都可以调用原生组件
4.都可以把资源文件下载本地加载渲染
不同点：
1.Hybrid是html 有dom操作，小程序是虚拟dom 屏蔽了直接对dom操作
2.小程序有服务层，负责处理业务逻辑和数据处理
3.小程序页面有原生页面的生命周期管理
4.小程序tab和bar是原生控件
5.小程序类web不是h5
6.小程序基于微信跨平台
小程序原理
下面以微信小程序为例，进一步展开小程序原理
都知道微信小程序有自己的开发语言，wx开头的方法也不少，那它是什么转化为微信app能识别的语言呢？微信开发工具开发完提交审核，审核通过下发到微信端的是什么样的文件呢？带着这些问题我查阅了很多资料，小程序在技术架构上非常清晰易懂。JS负责业务逻辑的实现，而表现层则WXML和WXSS来共同实现，前者其实就是一种微信定义的模板语言，而后者类似CSS。但是语法毕竟是自定义的，所以要么在下发的之前进行编译，要么就是在渲染的时候进行转化成webview能够识别的语法。我们发现这2个节点微信都做了处理，拿到下发到微信端的wxapkg格式的小程序包，解开后都是js和html已经不是我们开发的WXML和WXSS格式了。但是这一个个html直接用浏览器打开却是空白的。没错<body></body>里面是空的，渲染的时候动态加进入内容的。
1.小程序是如何编译的
我们先来看看打包编译这层，微信都做了些啥呢？微信的打包和编译都在服务端进行，我这边找了个类似的来描述下，不一定准确，只能参考下。
检测app.json文件是否存在
清空并创建指定的输出目录
根据service.html模板，带上版本信息输出到指定的目录中
读取配置文件app.json，将其注入到app-config.js中,输出到指定的目录中
读取所有小程序代码中所有的JS文件，同时判断其是否在app.json中定义，如果其没被定义也不是app.js，说明其为引入的module, 将这些JS路径名存入一个数组中，并确保app.js和页面文件放置在数组尾部
遍历JS文件数组并读取它们，根据用户设置项判断是否使用Babel将其转换为es5的代码
把js模块封装成CommonJS模块,并合并成app-service.js这个文件输出
根据app.json里的pages配置，遍历每个页面根据页面wxml,wxss生成相应的页面文件并合成page-frame.html
其他步骤应该都不难理解，我认为最难的应该是wxml,wxss生成相应的页面文件，这个页面不是普通的html文件，前面也说过它的body是空的。如果你安装了微信的开发工具的化你可以找下是否有wcc和wcsc这2个小工具。wxss 转换成了css,wxml转换成了inject_js，实际上就是virtual_dom。openVendor命令可以在小程序中获取到构建脚本wcc和wcsc，以及各个版本小程序的执行SDK***.wxvpkg，这个SDK也可以用Wechat-app-unpack解开，解开后里面就有WAService.js和WAWebview.js等代码。
根据 /Users/***/Library/Application Support/微信web开发者工具/WeappVendor 路径来找到微信开发者工具目录，以及查看工具集成的核心类。可以看到我们和熟悉的也很重要的WAService.js和WAWebview.js2个文件也在里面。不过代码都是加密混淆的，没有可读性。
2.编译好的小程序包如何下发解析
再看下下面这张图，微信下发的wxapkg格式的文件（每个小程序都是这样的一个包），这个文件可以通过从越狱的iPhone或者root的安卓手机上拿到。有部分人用charles通过https抓包拿到了下载链接，也拿到了包。解压出来就是这样的目录格式。简单解释下这每个文件的作用以及是什么来的：
app-config.json：小程序的整体配置文件，里面是一个json 主要包括page、entryPagePath、pages、global、tabBar、ext、extAppid等
{
"page": {
"pages/shop/index.html": {
"window": {
"enablePullDownRefresh": false
}
},
"pages/goods/detail.html": {
"window": {
"navigationBarTitleText": "商品详情",
"enablePullDownRefresh": false
}
},
"pages/order/address/list.html": {
"window": {
"navigationBarTitleText": "地址列表",
"enablePullDownRefresh": false,
"backgroundTextStyle": "light"
}
},
.......
},
"entryPagePath": "pages/shop/index.html",
"pages": ["pages/shop/index", "pages/order/detail/logisticsmap",......],
"global": {
"window": {
"backgroundTextStyle": "light",
"navigationBarBackgroundColor": "#f1f1f1",
"navigationBarTitleText": " ",
"navigationBarTextStyle": "black"
}
},
"ext": {
"api": {
},
"form": {
},
"name": "小店"
},
"extAppid": "########"
}
page节点：管理每个页面的整体设置，比如原生navigationBar的标题样式、是否需要下拉刷新等可以说这些设置都是对原生的ViewController的一个设置。没错一个小程序页面都有一个对应的原生页面，所以它可以封装原生页面的生命周期暴漏给小程序页面使用，包括原生的navigationBar和tabBar、下拉刷新控件等。这也是为什么小程序如果屏蔽调自带的navigationBar，自己定义navigationBar 下拉刷新也要自己重新做的原因。自定义navigationBar就不再是原生的了，它默认下拉刷新效果是在原生navigationBar下的整个webview做动画效果，这显然满足不了我们的需求。
entryPagePath：这个节点就简单了，小程序的入口页面的配置
pages节点：页面路径数组 对应小程序源代码里面的app.json文件里面的pages节点
global节点：全局设置和全局变量等；window 整个小程序的私有页面都起作用，也就是说每个页面没有自己单独设置都直接用这个全局设置的效果。
ext、extAppid节点：对应的就是ext.json文件 第三方平台部署小程序才需要
tabBar节点：对原生tabBar的样式设置和页面路径和图标等配置
app-service.js文件：这个是小程序一个很重要的文件，小程序体验好一个很重要的环节。从下图截取的代码片段很容易看出这个文件就是小程序里面全部js文件内容的集合。通过__wxRoute来路由，__wxRouteBegin=true来标记启始页面。
var__wxAppData = __wxAppData || {};var__wxRoute = __wxRoute ||"";var__wxRouteBegin = __wxRouteBegin ||"";var__wxAppCode__ = __wxAppCode__ || {};varglobal = global || {};var__WXML_GLOBAL__=__WXML_GLOBAL__ || {};var__wxAppCurrentFile__=__wxAppCurrentFile__||"";varComponent = Component ||function(){};vardefinePlugin = definePlugin ||function(){};varrequirePlugin = requirePlugin ||function(){};varBehavior = Behavior ||function(){}; define("app.js",function(require, module, exports, window,document,frames,self,location,navigator,localStorage,history,Caches,screen,alert,confirm,prompt,XMLHttpRequest,WebSocket,Reporter,webkit,WeixinJSCore){"use strict";App({onLaunch:function(){vare=this,o=wx.getStorageSync("logs")||[];o.unshift(Date.now()),wx.setStorageSync("logs",o),wx.login({success:function(e){}}),wx.getSetting({success:function(o){o.authSetting["scope.userInfo"]&&wx.getUserInfo({success:function(o){e.globalData.userInfo=o.userInfo,e.userInfoReadyCallback&&e.userInfoReadyCallback(o)}})}})},globalData:{userInfo:"hello world",text:"hello world"}}); });require("app.js"); __wxRoute ='pages/page2/page2';__wxRouteBegin =true; define("pages/page2/page2.js",function(require, module, exports, window,document,frames,self,location,navigator,localStorage,history,Caches,screen,alert,confirm,prompt,XMLHttpRequest,WebSocket,Reporter,webkit,WeixinJSCore){"use strict";Page({data:{},onLoad:function(n){},onReady:function(){},onShow:function(){},onHide:function(){},onUnload:function(){},onPullDownRefresh:function(){},onReachBottom:function(){},onShareAppMessage:function(){}}); });require("pages/page2/page2.js");
3.小程序如何渲染
除了小程序每个页面的js还包含了app.js 这个包含小程序的整个生命周期管理逻辑的js文件内容也都在这个文件里面。在微信端里面小程序的sdk会有一个单独的webview来加载app-service.js文件当作这个小程序的服务层，负责每个页面逻辑处理，而且这个服务在这个小程序的整个生命周期它是一直在的，每个页面的js文件都已经压缩在这个文件里面，并在小程序服务启动的时候已经加载到内存中，所以在点击按钮需要做逻辑交互的时候体验会那么快。
App Service(逻辑层)主要就是由app-service.js文件和集成在微信app里面的WAService.js组成，如一个页面加载需要网络请求就是由逻辑层处理请求参数并交给原生来进行请求，原生把请求到的数据返回给App Service(逻辑层)进行数据处理，最后把处理好的数据通过原生JSBridge传给view(试图层)进行渲染。对 逻辑层和视图层没有直接的交互，逻辑服务层和视图层也不在一个线程里面，2个webview 只能通过原生来进行通信。
几个文件夹没啥特别的 就是和你微信小程序开发的目录是一样，放的都是你的页面和组件的html文件。但是值得一提的是这里面的html文件内容很少，它不是一个完整的页面，可以说这个页面的样式，静态内容都不在这个html里面。里面放的是这个页面css、路由路径和加载入口方法的调用generateFunc: $gwx('./pages/order/rights/index.wxml')。可以看下我的hello world页面代码，就更加清晰了。
<!--pages/page2/page2.wxml-->
<text class="pageText">hello world page2</text>
/* pages/page2/page2.wxss */
.pageText {
background-color: red;
width: 100%;
height: 100rpx;
display: flex;
align-items: center;
justify-content: center;
}
这是一个很简单的小程序页面代码，那它编译后的html页面代码是什么样的呢？下面我展示出来给大家看。
var__setCssStartTime__ =Date.now(); setCssToHead([".",[1],"pageText { background-color: red; width: 100%; height: ",[0,100],"; display: -webkit-flex; display: flex; -webkit-align-items: center; align-items: center; -webkit-justify-content: center; justify-content: center; }\n",],undefined,{path:"./pages/page2/page2.wxss"})()var__setCssEndTime__ =Date.now();document.dispatchEvent(newCustomEvent("generateFuncReady", { detail: { generateFunc: $gwx('./pages/page2/page2.wxml') }}))
发现了啥？“hello world page2“ 这样页面关键内容不见了，那它是如何渲染的？懂js的人估计很容易就可以看到这个页面的入口方法generateFunc: $gwx 是的 这个方法是一个很重要的方法。那么这个方法在哪里？“hello world page2“ 这样页面关键元素又在哪里？肯定是跟着这个资源包一起下发的。对的所以的页面标签、元素 内容都在page-frame.html文件里面。也就是wxml文件的代码都编译压缩到page-frame.html文件里面，而对应页面的html文件只放对应的wxss文件代码和入口js代码。而入口方法的触发是由原生app调用js"generateFuncReady"事件触发调用。原生sdk这块后面可以以OC为例贴出对应代码，再展开说明下。
page-frame.html文件：这个文件应该是一个小程序包里面最大一个文件，所以里面的代码也不好都贴出来，简单介绍下里面的组成和作用。第一大块：模版 View（视图）层如何绘制每个页面都是公共的，如何把vdom渲染到webview上。$gwx方法就在这个模版里面，一个页面的入口。
再找找我们刚才html页面消失的关键元素“hello world page2“在哪里？把每个元素都转化为Z数组了，每个页面都是一个类似这样的代码块。由于混淆和压缩加大了我们阅读的难度，但是如果你以为看完这个文件就完了，那就错了。View（视图）层除了这几个html文件外 还需要一个很重要的文件，那就是放在微信app包里面的WAWebview.js文件。和服务层里面也有一个WAService.js文件配合使用达到和原生交互的效果。
和原生交互这块是属于小程序框架，所以肯定不会在下发的小程序包里面，除了原生sdk代码之外，还有2个很重要的js文件就是上面提到的WAService.js文件和文件。接下来我们就开始简单了解下：
为了方便理解我整理了js和原生的一些API，有app(小程序)级别的、有页面级别的、有原生组件级别的。可见js和原生交互是非常频繁的，可以说每个操作都是需要提供View（视图）层的WAWebview.js调用原生的桥梁需要原生处理就原生处理后再调用app Service（逻辑）层的WAService.js 由WAService.js通知 逻辑层处理对应逻辑，再把处理结果返回到原生。
小程序在App中执行时的时候分为三个不同的模块，View/Service/Native，各司其职。View和Service都在WKWebView中执行，互相无法调用，不直接操作DOM。他们之间通过Native层通信。Native和WebView之间通过webkit.messagehandler和evaluateJavascript互相调用。小程序借助的是JSBridge实现了对底层API接口的调用，所以在小程序里面开发，开发者不用太多去考虑IOS，安卓的实现差异的问题，安心在上层的视图层和逻辑层进行开发即可。
WeixinJSBridge.publish: view和service之间的透传，在WKWebView之间传递消息。
WeixinJSBridge.subscribe: 注册监听，监听view和service之间的消息调用。
WeixinJSBridge.invoke: View或者Service传递消息到Native,然后Native使用逻辑调用js callback。
WeixinJSBridge.on:监听Native的事件。
启动小程序服务startAppWithAppInfo根据appid等基本信息判断小程序是否已经下载到本地，没有的话下载解压加载配置信息等。然后进入manager，manager其实也是分为几部分一个是小程序级别的管理，一个是单个小程序的管理。具体的可以通过下面的类图更加直观。
下图显示了小程序启动时会从CDN和服务器校验和下载资源。也就是是小程序启动的时候会有点慢的主要原因，还有一些时间就是需要初值化小程序本地服务。
4.小程序的生命周期
关于小程序的生命周期，可以两个部分来理解：应用生命周期（左侧蓝色部分）和页面生命周期（右侧绿色部分）。
其中应用的生命周期是这样一个流程：1、用户首次打开小程序，触发 onLaunch（全局只触发一次）。2、小程序初始化完成后，触发onShow方法，监听小程序显示。3、小程序从前台进入后台，触发 onHide方法。4、小程序从后台进入前台显示，触发 onShow方法。5、小程序后台运行一定时间，或系统资源占用过高，会被销毁。
页面生命周期是这样的一个流程：1、小程序注册完成后，加载页面，触发onLoad方法。2、页面载入后触发onShow方法，显示页面。3、首次显示页面，会触发onReady方法，渲染页面元素和样式，一个页面只会调用一次。4、当小程序后台运行或跳转到其他页面时，触发onHide方法。5、当小程序有后台进入到前台运行或重新进入页面时，触发onShow方法。6、当使用重定向方法wx.redirectTo(OBJECT)或关闭当前页返回上一页wx.navigateBack()，触发onUnload。同时，应用生命周期会影响到页面生命周期。
用Page 实例说明的页面的生命周期
由上图可知，小程序由两大线程组成：负责界面的视图线程（view thread）和负责数据、服务处理的服务线程（appservice thread），两者协同工作，完成小程序页面生命周期的调用。
视图线程有四大状态：
初始化状态：初始化视图线程所需要的工作，初始化完成后向 “服务线程”发送初始化完成信号，然后进入等待状态，等待服务线程提供初始化数据。
首次渲染状态：当收到服务线程提供的初始化数据后（json和js中的data数据），渲染小程序界面，渲染完毕后，发送“首次渲染完成信号”给服务线程，并将页面展示给用户。
持续渲染状态：此时界面线程继续一直等待“服务线程”通过this.setdata（）函数发送来的界面数据，只要收到就重新局部渲染，也因此只要更新数据并发送信号，界面就自动更新。
结束状态：页面被回收或者销毁、应用被系统回收、销毁时触发。
服务线程五大状态：
初始化状态：此阶段仅启动服务线程所需的基本功能，比如信号发送模块。系统的初始化工作完毕，就调用自定义的onload和onshow，然后等待视图线程的“视图线程初始化完成”号。onload是只会首次渲染的时候执行一次，onshow是每次界面切换都会执行，简单理解，这就是唯一差别。
等待激活状态：接收到“视图线程初始化完成”信号后，将初始化数据发送给“视图线程”，等待视图线程完成初次渲染。
激活状态：收到视图线程发送来的“首次渲染完成”信号后，就进入激活状态既程序的正常运行状态，并调用自定义的onReady()函数。此状态下就可以通过 this.setData 函数发送界面数据给界面线程进行局部渲染，更新页面。
后台运行状态：如果界面进入后台，服务线程就进入后台运行状态，从目前的官方解读来说，这个状态挺奇怪的，和激活状态是相同的，也可以通过setdata函数更新界面的。毕竟小程序的框架刚推出，应该后续会有很大不同吧。
结束状态：页面被回收或者销毁、应用被系统回收、销毁时触发。
小程序在App中的应用场景
说了这么多技术理论，最后说下小程序在项目中如何应用。整个项目都是小程序不现实，毕竟小程序的定义是轻量级的，像IM、消息等用原生肯定比小程序更加适合，所以用小程序和原生混合开发是不可少的。还有一个让你不得不混合开发的一个重要原因，你的app不是一个新项目，是一个现有的原生app，一次性用小程序重新做一次不现实，所以混合会是最好的选择。我这边做的混合开发不是技术层面的，我们都知道小程序是很原生通信很频繁的，它需要原生提供各种能力才能到达接近原生的体验，所以本身就是一个混合。而我这里说的混合是指业务层面的混合开发，打破我们以往对小程序的认知。不管是百度小程序还是微信小程序都是运行在他们生态下的一个独立应用程序。比如一个商城小程序它不会有部分页面是原生部分页面是小程序，也只会有一个入口，一个出口。而我们要用小程序来开发app，我们app有自己的需求我们需要让小程序看起来像原生页面一样，对用户来说它还是一个app，不存在哪个页面是原生哪个页面是原生的。所以一切都是从技术层面来说，就是小程序和原生进行混合开发的业务app。你可以理解为你的app里面嵌入h5一样的开发模式，只是小程序页面比一般的h5页面交互体验要好一些而已。
我可以从原生页面跳转到小程序的任何页面，如果必要的话也可以从小程序页面跳转到原生页面。所以小程序服务不能在进入小程序页面的时候才启动，也不能因为回到原生页面而销毁。必须根据你的业务场景来调用控制。
以上是个人对与小程序开发app的一些浅薄看法，期待和业界同仁共同探讨。你有什么想法呢？欢迎评论交流。
最后感谢业界各位大佬的贡献，在这里附上我的参考文献：
https://blog.csdn.net/ListenToSennTyou/article/details/53258163
https://www.jianshu.com/p/92c6a75c2323
https://blog.csdn.net/xiangzhihong8/article/details/66521459
https://yq.aliyun.com/articles/72825?t=t1
https://github.com/weidian-inc/hera-cli
https://www.cnblogs.com/viaiu/p/9935602.html
https://www.jianshu.com/p/51ac882ea9f4
