1.序言
这篇文章献给那些准备从其他语言开发转到小程序开发的的程序员。程序员是个需要终身学习的职业，技术的更新迭代，以及市场和公司业务的变化都需要调整自己的技术方向来与之适应。本人这么多年也经过多次的技术转型变化，从最开始用c# sqlserver javascript 开发web系统和网站，后来随着移动互联网时代的来临， 学习objective-c c++转到ios移动端的开发，曾今有一段时间去学习cocos2d、 opengl es、 unity3d 差点转型去做游戏，如今的AI深度学习在NLP 和 视觉上取得很大的突破，业余时间也在学习python 和 相关方面的数学、框架、作为兴趣研究这一领域，程序员就是一个一直在折腾自己的职业，只有在不影响本职工作下不断学习才能适应这个时代的变化。现在微信小程序的大热，借助微信庞大社交能力来引流获客、开发成本低、以及不需要安装等等一些优点， 很多app都不错过这个流量入口开发了小程序版。
2.小程序开发与ios开发比较
同为一种客户端，首先来说微信小程序的api 框架设计还是不错的，上手很容易，看2遍api 下几个demo看看别人的代码，基本就能开始做项目了，当然对于那些有前端经验的来说就更简单了，对于非前端比如ios android 转过来写小程序，会比较陌生的是css，不过问题也不大，百度一下，问问同事很快就能学会了。从一个高级面向对象语言转到脚本语言刚开始还是会有些不适应的。
1.ios上自带的很好用的观察者模式通知，kvo。在小程序上需要自己去设计实现。首先介绍一下这个观察者模式，举个栗子，比如ios的通知，你的页面A、B、C同时订阅一个通知，你在controll层或者其他页面执行了业务操作，需要更新这些页面的某些值或刷新一些ui显示，那这时候只需要发送一个通知，传递一个值，订阅的页面收到通知就能做出相应的修改，比如小程序里Tabbar的几个页面想在c页面修改了值，更新a页面的某个ui显示，有了观察者模式就不需要用全局变量来控制交互了，还有组件，多层组件之间互相需要传递信息更新ui等操作都会很方便。这里我说下ios里观察者的设计思路，还没来得及在小程序中实现，今后的文章中我会把实现教程发出来，首先观察者用单例模式建立一个观察中心，订阅者需要把对象本身的指针引用 、一个订阅名称、一个通知执行的函数闭包，发送给订阅中心，订阅中心收到相应的订阅名称需要update的时候，就可以根据订阅名给订阅者发送通知了
2.ios上还有一个很好的优化思路我觉得值得借鉴，当初iphone4 1Ghz 512内存 比安卓2G 4G 双核 4核还流畅，一个很重要的原因就是得益于系统的优化，其中最主要的思想就是只渲染当前显示的内容，回收那些用户看不到的，比如一个很长的列表，列表每一行称为一个cell,每次只渲染屏幕能看得到的cell和即将显示的1、2个cell，ios的渲染分为前帧缓存和后帧缓存，后帧缓存做计算，计算完成渲染好了，前后帧缓存交互位置，后帧变前帧显示，前帧到后帧计算新的渲染。程序不同但是思路是通用的，很多游戏引擎都是如此，只渲染一个视锥截面体内的顶点，光照，纹理，场景，用矩阵来控制复杂的变换， 小程序要实现复杂动画的时候可以借鉴。
3.小程序开发模板消息的使用
小程序不允许像app那样自由给用户推送消息，只能通过模板消息来实现消息的通知，这个模板消息在微信中叫服务通知，界面大概长这样
整个推送流程如下图：
我来解释下这个流程：微信默认只能发送支付行为的通知，我们想实现自定义的模板消息需要在我们的小程序端收集formid（formid就是一串加密串）,保存到服务端，服务端每次要发送通知的时候，就会消耗一个formid。对于客户端要做的就是把页面上用户会经常点到的按钮换成微信的buttion 用form包含。
<form bindsubmit="formSubmit" report-submit="{{true}}" >
<button data-type='click' formType="submit" class="formBtn baby-babyTopBtn flex-center" bindtap='clickToUrl' >
</from>
buttion 主要是formType="submit" 这个属性，要设置
form 标签 report-submit="{{true}}" 这个属性不能漏了
form 表单设置 bindsubmit="formSubmit" 提交表单的方法,然后在js文件中定义该方法,
点击一次可以获得一个formid
//提交 formid给服务端
formSubmit: function (e) {
console.log('获得formid：', e.detail.formId);
var formid = e.detail.formId;
formIdManage.submitFormidToService(formid);
},
，把这个按钮样式修改为你页面的样子
比如
formid 有个坑需要注意：
如果你的小程序有开发版和体验版，对应的服务端是统一的，但是收集formid的时候来自不同的版本，当用户收到消息，点击消息打开的会是formid 收集到的那个版本，举个栗子：比如我们在早上9点发布了一个v1版本，假设服务端保存10个formid,数据库目前的10个formid都是来自v1 版本收集的，这时候发现一个通知跳转进去有问题，我们修改了代码，发布一个V2版，如果从之前的服务通知点进去或者你从服务端新发了一条通知，肯定跳到的还是v1版本的小程序，这时候你怎么测试都是还有问题的，因为跳转的还是旧版本。这时候就需要清除服务端数据库的旧的formid,1让服务端直接给你删除，2因为服务端保存formid也是队列形式先进先出的原则，所以你可以在你的新版上收集formid的地方去点10次，点一次formid变一次，就是一个新的，保存到服务端，把旧的formid替换掉，然后再发一次通知，这时候跳转的才是你最新的版本。
4.小程序的一些比较坑的限制
1.本地存储限制10M ，，就是你想做一些下载缓存保存下临时文件不能耐超过10m，这个很好理解不多做解释
2.在IOS不支持虚拟支付。可能是因为苹果对虚拟商品的收费需要抽成，微信无法对接和审核这些交易，所以干脆不支持，虚拟商品比如一些知识付费，游戏的交易等等。不过是有变通解决方案的，就是利用客服消息，小程序对接客服消息，然后购买的时候客服消息会发送一条购买的链接给用户，用户点击这个购买链接就可以支付，其实就是躲开苹果的审查就行了
3.整个开发包限制4M,包括代码、图片资源等，图片可以存服务端，不过网络差的时候体验可能会差一点，代码省着写吧，顾名思义“小程序”
4.通过 wx. navigateTo 推入后台的页面最多10层，超过会无法打开新页面
目前发现这些吧，还有一些运营上的坑，比如你想做一些通过分享转发来推广，然后解锁某些功能这是不允许的，涉嫌“诱导分享”微信直接封杀，想想有点可怕，生杀大权微信说了算
5. 小程序适合做哪些？不适合做哪些？
首先不得不说大部分app都是可以用app来实现或者实现核心功能的，比如 共享单车、饿了么、滴滴打车、爱奇艺，今日头条 等。 还有对于那些移动互联网产品不是核心产品，但是需要一个移动端来形成闭环做一些“售后服务“式的程序 ，可以节省成本只做小程序。 那哪些app是不适合或者说小程序目前无法实现的呢？
1、需要大量本地缓存的app，比如QQ音乐这种音乐类的app，由于小程序还是依附在微信这个 app上来实现的，本质上微信也是给每个小程序分配一定沙盒空间（小程序存储限制10m以内），如果不做这个限制，那每个小程序都大量存储，要管理这些小程序的缓存也是很麻烦的，那微信的存储也就是用户收集的存储可能很快就满了。
2、需要用到一些比较底层技术的app小程序目前还无能为力，比如像抖音这种需要对视频进行编辑 合成 一些app
3、一些先进新技术无法在上面使用，比如 IOS android 都有推出相应的一些在视觉 AR 和 深度学习方面应用的库 。
6.小程序整体看法？
目前市面上很多app都有做一个对应的小程序版，。互联网以app为核心的产品大公司的app都只把一些核心功能简化做一个小程序版本，我想他们还是想把核心渠道把握在自己手里，不能把鸡蛋放一个篮子里的意思吧，毕竟小程序 ios android 都是一个入口。做小程序是一个互利共赢的模式，对于公司来说多来一个获客渠道，对于微信来说，微信就是一个超级app,功能“无所不能”，同时也带来一个问题，小程序入口之争以后将来很激烈，任何一个新鲜的热点都将带来红利期，我们也得警惕红利消失后，蓝海的竞争是非常剧烈的。马化腾曾说：“小程序并不是想取代App，而是降低App的用户流失率”，张小龙为什么把小程序的入口设置那么深，不明显，我想也是这个意思。个人认为小程序 ios android 都是一道菜，谁都不能当主食来吃，但是多了一道菜用户多了种口味。
