每个小程序起起来时就会有一个App实例，同理每个页面打开也会有一个Page实例（这个链接打开往下滑还有生命周期函数的图解），我们只需要在这个实例中添加自己的逻辑即可,唯一不同的是这是在javascript这种语言上写的（java和javascript的区别就像是雷锋和雷峰塔，所以这里形式上的不同还是蛮大的）。

视图层代码

前面说了，写视图层的体验有点像Web前端，主要是写多了Android，习惯性地会把界面的样式以及交互放在一块儿写（事实上就是你在xml上做的工作），而在Web端，需要html和css文件来共同完成。在小程序里面，对应的是WXML(WeiXin Markup Language)和WXSS(WeiXin Style Sheets)，注意虽然模式和web很像，但是在形式上算是微信自己开发的一套（所以你需要使用他们自己的标签）。具体来讲，你需要做两件事：

在WXML中通过组件（微信所提供的标签）构建页面结构，并且在其中完成数据绑定和事件绑定在WXSS中完成样式的定义，用以控制WXML中组件的样式。WXSS具有CSS大部分特性,同时也有部分扩充。

基本上，视图层很像在写Web端。不过你也看到了，和Android比起来，限制因素在于微信给你提供了组件，然后你最多改改样式，更多的像自定义组件什么的就不可能了。

逻辑层代码

不同于Android有一堆的组件（Activity、Service..）来支撑逻辑层，小程序就一个Page()函数(类似与App()函数，在框架里面填逻辑)，所以显得很简单。基本上，数据通过双向绑定进行传递和刷新的，然后在page内可以完成一些交互处理，更多的能力(访问网络、存储)是通过微信的API完成的，这些api以wx.开头，目前来看，不是太多，所以可以很快看完，当然也意味着其实可以完成的工作还着实有限，这个后面说。

工程组织

整体来说,小程序的工程组织还是蛮清晰的,MINA程序包含一个描述整体程序的app和多个描述各自页面的page，一个MINA程序主体部分由三个文件组成，必须放在项目的根目录，是app.js,app.json,app.wxss，分别用作生命周期函数、配置文件和样式文件，一个MINA页面由四个文件组成，是.js,.wxml,.json,.wxss，分别用作生命周期函数、布局文件、配置文件和样式文件，他们需要通过同名且放在同名文件夹下（方便框架通过名字路由）。比起Android来，套路应该是固定而简单得多。

Android

再回头看看Android开发，突然觉得可以玩的简直是太多了…下面简单描述一下，肯定是不全的。

一些生命周期函数

App、Activity是肯定的，其实套路和小程序还是差不多的。只不过组织形式是类而不是函数对象。之前说了，这是因为Js和Java语言特性造成的。

视图层代码

通常来讲，Android的界面在.xml文件中定义，其实仔细想想就会发现，在文件中，我们是同时定义了布局，和交互逻辑的，这是因为本质上这些.xml声明都是View类的子类，我们通过重写View的声明周期方法来完成了对齐的样式(onDraw以及LaoutParams)、以及交互的定义（各种on..listener）。所以在.xml中更像是对这些对象进行一系列实例化。至于双向数据绑定,Android也开始支持了

逻辑层代码

这一层还是要复杂得多..放到后面对比来说吧。

工程组织

…..不想说了，一方面写法多，一方面相对于小程序也蛮复杂的。

功能上的对比

要怎么对比呢？读Android的开发文档我之前看了一个星期，而微信小程序的文档也就两三个小时，从体量上说就知道无意Android功能要强大的多。所以基本上小程序能做的以外就是不能做的，这句话听起来很废话，但事实上是因为微信给的API有限，所以你基本上能把自己需求列出来，查一下API是否给出，没给出的话基本上还是算了吧。下面我根据Android的APIguide（科学上网）来罗列下小程序的局限。

自定义控件和布局

这个应该是最直观的一点，因为实际上你所使用的视图层是被微信进一步封装了的，小程序自定义控件还是蛮复杂的，因为MINA给出了绘图（但是只能在<canvas/>上作画）和动画（类似于Android中的属性动画）的功能，所以或许存在理论上的可能性。

数据存储

这个要特别拿来说一下，官网原文是：

每个微信小程序都可以有自己的本地缓存，可以通过wx.setStorage（wx.setStorageSync）、wx.getStorage（wx.getStorageSync）、wx.clearStorage（wx.clearStorageSync）可以对本地缓存进行设置、获取和清理。注意： localStorage是永久存储的，但是我们不建议将关键信息全部存在localStorage，以防用户换设备的情况。

所以微信小程序使用的是缓存而非有一个自己的数据库，这里的缓存应该类似于android的SharedPreference之类的，用键值对存的。而且小程序只能对文件进行存的操作。所以说对于那种需要数据库的应用，小程序是不适合的。

后台服务，多线程

Android中，Service是蛮重要的类，然后多线程与异步任务虽然复杂，但是能完成许多工作，但是小程序是不具有这种能力的，当然其实你可以看到你也是可以异步读写的…所以微信应该是只提供了部分功能的异步能力。

对系统服务的获取

写到这里，主要是想到了之前应用需要闹钟模块，需要让系统定时通知应用以完成特定的事件。而小程序其实是封装在微信这个应用之内的应用，所以理论上它是可以获得系统服务的，但是，如果微信不给接口一切都白说，从API文档中可以看到，微信还是提供了位置、网络状态等系统信息的，不过像通知这些服务，是暂时没有的。

与其他应用交互

这里的概念主要是对应Android的隐式意图和ContentProvider，这里Android提供了一种能力，让应用程序之间可以相互调用甚至相互操作数据（比如A打开B的音乐播放器，将A的网页内容保存到B的便签中..这里主要是场景可扩展），而微信中，这种能力被具体场景化了，比如你仍然可以调用相机拍照（微信调用隐式意图帮你实现），其他的场景你却无法实现，因为微信没有做这一层封装。

内嵌网页

这一点不知道要不要说..因为微信小程序其实就是一种”内嵌网页”的解决方案？只不过使用了类似于hybrid的解决方案。

性能优化

在Android中许多业务已经被MINA封装了（网络请求、websocket…）所以一方面你实现功能的成本降低了，另一方面这一部分优化的空间并不是那么大。

开源库

因为我还是个Js的初学者，所以暂时不知道如何在微信小程序中使用轮子。但微信和web前端那一套还真不太一样，所以也应该没法直接使用一些开源库。（10.8更新,今天看到了LeanCloud已经可以支持js开发了..也说明了可行性）

最后的总结

如前所说，如果说一般应用的容器(不知道这个比喻恰不恰当)是操作系统，那么小程序的容器则是操作系统下的一款应用，自然而然的，它本身就是某个应用下的一个子模块。而这个模块能有多少功能取决于微信写了多少接口。另一方面，因为这个容器是微信，至少我们可以假设这些接口的跨平台特性，很可能我们调用的这些接口，会比我们自己写android调用系统接口更稳定，甚至依附于微信，我们可能少了诸如在某些手机系统中管理应用生命周期、避免程序被杀死的麻烦。总之，我的感受是

虽然功能有限，但是足够敏捷开发在需求能够被满足的情况下，尽量适用微信开发。

声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。