国庆节尾巴上花了一点时间读微信小程序的官方文档,在对比之前自己做得Android，有了下面的内容。这篇文章将围绕下面几个方面：

• 从开发模式（过程）上对比Android和小程序，比较两种”模式”的异同
• 从实现功能上对比，主要是看看微信小程序的局限
• 自己的一些看法，微信的优势

开发过程上的对比

 在我看来,开发一款app，需要做的主要是界面布局以及交互处理,然后是后面的业务逻辑处理。虽然平台不同，但是任务都是趋同的。下面从这两个大的方面进行对比一下。

小程序

 微信把这个小程序框架称为“MINA”，并声称：

MINA(MINA IS NOT APP) 是在微信中开发小程序的框架。

MINA的目标是通过尽可能简单、高效的方式让开发者可以在微信中开发具有原生APP体验的服务。

MINA提供了自己的视图层描述语言WXML和WXSS，以及基于JavaScript的逻辑层框架，并在视图层与逻辑层间提供了数据传输和事件系统，可以让开发者可以方便的聚焦于数据与逻辑上。

 个人觉得第三点说得特别好。大概说清楚了开发者要干什么。大概就是以写Web的方式写好前端，然后通过双向数据绑定技术和业务端交互,业务端通过javascript代码实现业务处理,必要时调用微信接口完成一些处理。

一些生命周期函数

 这里所说的生命周期函数是指的整个应用以及每个页面的声明周期函数,在Android中，对应着App、Activity类，而在小程序中,对应着App和Page两个函数对象（注意,javascript是基于原型和构造器的，而Java是基于类的，所以这里就造成了一些写法的不同）。以App为例,下面是一个代码实例:

App({
  onLaunch: function () {
    console.log('App Launch')
  },
  onShow: function () {
    console.log('App Show')
  },
  onHide: function () {
    console.log('App Hide')
  }
})
1
2
3
4
5
6
7
8
9
10
11
1
2
3
4
5
6
7
8
9
10
11

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

视图层代码

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

1. 在WXML中通过组件（微信所提供的标签）构建页面结构，并且在其中完成数据绑定和事件绑定
2. 在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调用系统接口更稳定，甚至依附于微信，我们可能少了诸如在某些手机系统中管理应用生命周期、避免程序被杀死的麻烦。 
 总之，我的感受是

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