前端，产品，管理
微信官方已经开放微信小程序的官方文档和开发者工具。前两天都是在看相关的新闻来了解小程序该如何开发，这两天官方的文档出来之后，赶紧翻看了几眼，重点了解了一下文档中框架与组件这两个部分，然后根据简易教程，做了一个常规的todo app。这个app基于微信小程序的平台，实现了todo app的常规功能，同时为了让它更接近实际的工作场景，也用到了loading与toast这两个组件来完成一些操作的交互与反馈。这个平台给我的直观感受是，技术层面，它跟vue有相似性，但是远没有vue强大；开发时候的思路，不像vue，反倒觉得比较像backbone。所以要是使用过backbone,vue等mvc,mvvm框架的人，会觉得这个平台上手很容易。本文主要介绍这个todo app实现的一些要点。
先补充下本文相关的资料：
官方文档：
官方开发者工具下载：
本文todo app的功能演示：
注：需长按todo的text，才能直接编辑。因为是在手机端，所以不能使用双击事件来进行编辑，改成了长按事件。小程序的平台也没有提供双击事件的绑定。
相关源码：
如果你想在本地运行这个项目，需要先安装开发者工具，按照文档中简易教程的描述，先建好一个项目； 建完之后，开发者工具就会打开这个项目；
接着在磁盘上，找到建好的项目的文件夹，把里面的内容都删掉，把上面源码文件夹下的文件都粘贴进去；
然后重新打开开发者工具，先进入到编辑页签，然后点击编译按钮，就会直接进入到调试界面，查看app的功能：
下面来介绍下这个app开发的要点：
1. 这个app的目录结构以及配置等就不详细介绍了，这些在文档-框架部分都有很详细的描述。这个平台里面没有html和css，取而代之的是wxml和wxss。wxss跟css几乎没有区别，缺点就是不如css强大，支持的选择器有限。但是好处是由于只有微信这一个平台，所以几乎没有兼容性问题，能够使用标准的，更新的css技术。wxml里面只能用平台提供的那些组件的标签，html的标签不能直接用，各个组件的在wxml的使用方式，都可以在文档-组件这一部分找到说明的示例。所以实际上wxml跟wxss编写起来都没有什么难题。
2. wxml支持以下这些特性：
在todo app里面除了模板和引用没有用到之外，其它的都使用到了，不过没有使用到每个特性的各个细节，只根据app的需要选用合适的功能。前几天看到有文章说，微信小程序可能是基于vue框架来实现的，所以就看了下vue的文档。对于数据绑定，条件渲染，列表渲染，事件这几部分都详细看了vue的用法。对比下来，wxml提供的这些特性，跟vue的相关特性是还比较像，不过功能并没有那么多，所以也不能轻易地直接拿vue框架的特性用到小程序里面。最佳实践，还是基于官方文档中提供的说明来，如果官方文档中没有提到的功能，通过猜测的方式去用，肯定是行不通的。我通过打印的方式，查看一些对象的原型，也并没有发现比官方文档要多的一些实例方法，说明小程序的框架功能确实是有限的。
3. wxss其实是可以用less或者sass来写的，只要选择器满足框架的要求即可。由于时间原因，就没有在这个app里面去尝试了。
4. 没有双向绑定。在vue里面，一个vue实例就是一个view-model；view层对数据的更新，会实时反馈到model；model的更新，也会实时反馈的到view。在小程序里面，没有双向绑定，view的更新不会直接同步到model；需要在相关事件回调里面，直接从view层拿到数据，然后通过setData的方式，更新model，小程序内部会在setData之后重新渲染page。比如单个todo项，toggle的操作：
toggleTodo: function( e ) {
var id = this.getTodoId( e, 'todo-item-chk-' );
var value = e.detail.value[ 0 ];
var complete = !!
var todo = this.getTodo( id );
this.updateData( true );
this.updateStorage();
以上代码中，通过e.detail.value[0]拿到单个todo项里面checkbox的值，通过该值来判断todo的complete状态。最后在updateData的内部，还会通过setData方法，刷新model的内容。只有这样，在toggle操作之后，app底部的统计信息才会更新。
5. 事件绑定的时候，无法传递参数，只能传递一个event。比如上面那个toggle的操作，我其实很想在回调里面把当前todo的id传到这个回调里面，但是想尽办法都做不到，最后只能通过id的方式来处理：就是在wxml中绑定事件的组件上面，加一个id，这个id全page也不能重复，所以id得加前缀，然后在id最后加上todo的id值；当事件触发的时候，通过e.currentTarget.id就能拿到该组件的id，去掉相应的id前缀，就得到todo的id值了。这是目前用到的一个方法，我认为不是很优雅，希望后面能发现更好的办法来实现。
6. app中考虑到了loading的效果，要利用button组件的loading属性来实现。但是loading仅仅是一个样式的控制，它不会控制这个按钮是否能重复点击。所以还要利用buttong的disabled属性，防止重复点击。
剩下的实现细节，都在下面两个文件的源码中，欢迎大家指出其中的问题。
index.wxml的源码：
&!--list.wxml--&
&view class="container"&
&view class="app-hd"&
&view class="fx1"&
&input class="new-todo-input" value="{{newTodoText}}" auto-focus
bindinput="newTodoTextInput"/&
&button type="primary" size="mini" bindtap="addOne" loading="{{addOneLoading}}" disabled="{{addOneLoading}}"&
&view class="todos-list" &
&view class="todo-item {{index == 0 ? '' : 'todo-item-not-first'}} {{plete ? 'todo-item-complete' : ''}}" wx:for="{{todos}}" wx:for-item="todo"&
&view wx-if="{{!todo.editing}}"&
&checkbox-group id="todo-item-chk-{{todo.id}}" bindchange="toggleTodo"&
&label class="checkbox"&
&checkbox value="1" checked="{{plete}}"/&
&/checkbox-group&
&view id="todo-item-txt-{{todo.id}}" class="todo-text" wx-if="{{!todo.editing}}" bindlongtap="startEdit"&
&text&{{todo.text}}&/text&
&view wx-if="{{!todo.editing}}"&
&button id="btn-del-item-{{todo.id}}" bindtap="clearSingle" type="warn" size="mini" loading="{{todo.loading}}"
disabled="{{todo.loading}}"&
&input id="todo-item-edit-{{todo.id}}" class="todo-text-input" value="{{todo.text}}" auto-focus bindblur="endEditTodo" wx-if="{{todo.editing}}"/&
&view class="app-ft" wx:if="{{todos.length & 0}}"&
&view class="fx1"&
&checkbox-group bindchange="toggleAll"&
&label class="checkbox"&
&checkbox value="1" checked="{{todosOfUncomplted.length == 0}}"/&
&/checkbox-group&
&text&{{todosOfUncomplted.length}} left.&/text&
&view wx:if="{{todosOfComplted.length & 0}}"&
&button type="warn" size="mini" bindtap="clearAll" loading="{{clearAllLoading}}" disabled="{{clearAllLoading}}"&
Clear {{todosOfComplted.length}} of done.
&loading hidden="{{loadingHidden}}" bindchange="loadingChange"&
{{loadingText}}
&/loading&
&toast hidden="{{toastHidden}}" bindchange="toastChange"&
{{toastText}}
index.js的源码：
var app = getApp();
todos: [],
todosOfUncomplted: [],
todosOfComplted: [],
newTodoText: '',
addOneLoading: false,
loadingHidden: true,
loadingText: '',
toastHidden: true,
toastText: '',
clearAllLoading: false
updateData: function( resetTodos ) {
var data = {};
if( resetTodos ) {
data.todos = this.data.
data.todosOfUncomplted = this.data.todos.filter( function( t ) {
return !t.
data.todosOfComplted = this.data.todos.filter( function( t ) {
this.setData( data );
updateStorage: function() {
var storage = [];
this.data.todos.forEach( function( t ) {
storage.push( {
text: t.text,
complete: t.complete
wx.setStorageSync( 'todos', storage );
onLoad: function() {
this.setData( {
todos: wx.getStorageSync( 'todos' ) || []
this.updateData( false );
getTodo: function( id ) {
return this.data.todos.filter( function( t ) {
return id == t.
getTodoId: function( e, prefix ) {
return e.currentTarget.id.substring( prefix.length );
toggleTodo: function( e ) {
var id = this.getTodoId( e, 'todo-item-chk-' );
var value = e.detail.value[ 0 ];
var complete = !!
var todo = this.getTodo( id );
this.updateData( true );
this.updateStorage();
toggleAll: function( e ) {
var value = e.detail.value[ 0 ];
var complete = !!
this.data.todos.forEach( function( t ) {
t.complete =
this.updateData( true );
this.updateStorage();
clearTodo: function( id ) {
var targetI
this.data.todos.forEach( function( t, i ) {
if( targetIndex !== undefined ) return;
if( t.id == id ) {
targetIndex =
this.data.todos.splice( targetIndex, 1 );
clearSingle: function( e ) {
var id = this.getTodoId( e, 'btn-del-item-' );
var todo = this.getTodo( id );
todo.loading = true;
this.updateData( true );
var that = this;
setTimeout( function() {
that.clearTodo( id );
that.updateData( true );
that.updateStorage();
clearAll: function() {
this.setData( {
clearAllLoading: true
var that = this;
setTimeout( function() {
that.data.todosOfComplted.forEach( function( t ) {
that.clearTodo( t.id );
that.setData( {
clearAllLoading: false
that.updateData( true );
that.updateStorage();
that.setData( {
toastHidden: false,
toastText: 'Success'
startEdit: function( e ) {
var id = this.getTodoId( e, 'todo-item-txt-' );
var todo = this.getTodo( id );
todo.editing = true;
this.updateData( true );
this.updateStorage();
newTodoTextInput: function( e ) {
this.setData( {
newTodoText: e.detail.value
endEditTodo: function( e ) {
var id = this.getTodoId( e, 'todo-item-edit-' );
var todo = this.getTodo( id );
todo.editing = false;
todo.text = e.detail.
this.updateData( true );
this.updateStorage();
addOne: function( e ) {
if( !this.data.newTodoText ) return;
this.setData( {
addOneLoading: true
//open loading
this.setData( {
loadingHidden: false,
loadingText: 'Waiting...'
var that = this;
setTimeout( function() {
//close loading and toggle button loading status
that.setData( {
loadingHidden: true,
addOneLoading: false,
loadingText: ''
that.data.todos.push( {
id: app.getId(),
text: that.data.newTodoText,
compelte: false
that.setData( {
newTodoText: ''
that.updateData( true );
that.updateStorage();
loadingChange: function() {
this.setData( {
loadingHidden: true,
loadingText: ''
toastChange: function() {
this.setData( {
toastHidden: true,
toastText: ''
最后需要补充的是，这个app在有限的时间内依据微信的官方文档进行开发，所以这里面的实现方式到底是不是合理的，我也不清楚。我也仅仅是通过这个app来了解小程序这个平台的用法。希望微信官方能够推出一些更全面、最好是项目性的demo，在代码层面，给我们这些开发者提供一个最佳实践规范。欢迎有其它的开发思路的朋友，帮我指出我以上实现中的问题。
阅读(...) 评论()小程序开发多少钱
公司动态小程序开发多少钱
17:53:29阅读1127
这要从以下几方面算&&& 1、，工程量并不小，它不等同于网站开发和微信官网应用开发，那些技术成熟，有现成的模板。小程序开发，相当于简单一些的APP开发，需要涉及的东西很多，后端服务器、数据库、通讯、API等等。&2、微信搞出小程序，是想来终结APP的——但是一个网站网页的技术，怎么可能来终结那么多APP功能需求呢?&&& 所以，我们要提高小程序产品开发的成本预期和时间预期。&& 首先要计算开发的费用&&& 我们假定要开发的是一款电商购物小程序，用户注册登录、产品陈列、加入购物车、下单购买、支付、售后与服务跟进，这是典型的电商需求，这种需求，在市面上有无数APP或公众号H5 网站。&&& 定制化的需求开发，一般要按照开发商或技术团队投入的人力来报价，大约需要投入的人手如下：需求分析 兼 项目经理 兼 team leader1 人* 20 天*1k元=2w&& UI 设计1 人* 10 天*0.8k=8k&&& 前端开发(小程序开发) 1 人* 20 天*0.8k=1.6w(前期人才稀缺，可能有一定上浮)前端开发(PC端) 1 人* 20 天*0.8k=1.6w&& 后端开发 兼 系统架构1 人* 20 天*0.8k=1.6w&&& 测试 兼 维护部署 兼 售后客服1 人* 30 天*0.8k=2.4w&& 小计： 10w这样看起来，开发一个小程序，好像和“开发一个APP”差不多。这个价格也接近开发商和技术团队的成本了。可能有人觉得这些技术人员的“日单价”，是不是胡乱编的，事实上市场上做定制开发的技术团队，对人头的定价是参差不齐的，而我们是假定出品的微信小程序，是有一定品质的，这意味着每个项目的技术团队参与者的水平都不会太差。&&& 参考现在市面上好的人才身价，能独当一面的优秀工程师，月薪都是5w起跳，如果再摊上企业经营成本和人力闲置率，这个定价并不算高。&有没有可能降低成本?&& &方法一：像电商购物这种典型的需求，随着各个开发技术团队推出的产品日益成熟，各种标准化模块越来越多，价格也会稳步下降。&&& 方法二：有的技术开发团队，会将通用的功能沉淀成标准模块，通过“走量”销售来降低成本;也有的技术团队，会将开发抽象成“生产线”和“开发平台”，可以减少开发工作量与风险，从而达到降低成本的目的。&& 方法三：降低成本的第三个方法，等等，再等等：参考公众号定制、APP定制的市场发展轨迹，笔者估计小程序推出后的半年内，定制开发技术团队的价格会下降至少50%-70%，也就是说，随着各类开发技术团队的“开发平台”和“标准化模块”的成熟，上文的需求可能会降到5w-8w。&1、租赁服务器——目前我们处于一个云服务快餐化时代，运行一个互联网软件，再也不需要进行繁琐的硬件采购、网络租赁与托管、网络安全、容灾，我们只需选择一个可靠的技术服务商。&&& 自己购置硬件、租赁服务器，每年不会低于 5000 元，所谓的 “本地部署“，意味着什么都得自己买，费时费力费钱，一般购置服务器和租赁网络带宽的初始费用是5w起跳，还需要自身的技术团队去维护;& 2、注册认证——腾讯的代理认证机构会征收每年 300 元认证服务费，权当交给腾讯的保护费吧，每年都要交哦。还有，注册个域名吧，每年 70 元。&&& 如果你作为一个项目经理;老板问你，我们搞个微信小程序，要花多少钱?&& 你就可以理直气壮的告诉你的老板， 2 万左右。&& 但这也并不是绝对的标准，作为参考。&&& 但不难看出，小程序需要的费用包括 5 个方面， 前端+后端+服务器+功能迭代+维护这 5 个方面决定开发成本。&& 这么看来，小程序的费用至少是APP的1/10，也正因为如此，引来如此多的开发者和企业的高度关注和参与。&开发小程序需要注意哪些问题?&&& 与APP和微信公众号不同的是，微信对于小程序有着非常严格的审核标准，虽然APP也经过苹果审核，但近几年苹果受到业绩压力和微信对其商业模式的挑战，甚至上线了竞价排名模式，其审核标准也就可想而知了。&& 01、首先诊断自己是否符合微信官方要求，比如不涉及直播、游戏、虚拟付费。比如“得到”小程序就在上线几天后暂停服务，就白白浪费开发成本。&& 02、诸多案例已经证明，小程序的最佳实现场景是“线下、服务、交易”，拥有线下场景的企业可以考虑做小程序开发。&& 03、由于开发者只提供技术产品，实现功能和需求由企业提供，但小程序能否成功，实现功能和玩法是重中之重。&小心“一键生成”所产生的骗局&&& 网上有网友表示，“仅仅是在每年的服务费上，不出两年，你的小程序价格就变成了一万元以上，你还必须永远跟着那个公司走，对方也不会给你提供源程序搬迁的，你不要对方的服务，就是彻底放弃你的小程序了。&为用户定制开发小程序，为用户提供源代码，根据不同行业的用户，为其定制开发不同的功能，为用户打造功能齐全、快捷方便，与APP同步的小程序，目前，腾米科技还为小程序代理商提供加入代理，便可为其免费赠送小程序！
全国免费热线你该开发微信小程序还是App？ - 简书
你该开发微信小程序还是App？
“微信稍微掀一下裙底，整个互联网都高潮了”
阅读本文你总共需要8.88分钟
2016年初1月11日张小龙在北京微信公开课上首次透露“应用号”，历经大半年后，就在昨晚（9月21日晚），微信官方宣布：“应用号”正式开始内测。微信官方将应用号称为“小程序”，但下文将以“应用号“代替
当应用号出来后，很多人就将原生App和应用号作对比，甚至有“原生App将死”的言论
今天我将从产品的角度，带大家去解决以下问题：
小程序应该使用在哪些需求场景？
作为不同的互联网从业者（产品、运营、技术）该怎么迎接小程序？
你该开发微信“小程序”还是App？
1. ”应用号“是什么？
首先，先来看三张图：
第一张：官方微信
第二张：微信创始人张小龙
张小龙朋友圈
第三张：官方回答
Paste_Image.png
从上面的图可以看出：应用号是内置于微信的云端的应用程序。
官方称为：小程序，可以理解为”镶嵌在微信的App“
与订阅号、服务号和企业号属于同级体系。由此，小程序、订阅号、服务号、企业号形成了并行的微信生态四大体系。
2. ”应用号“的作用
首先，我们来看开放了内测资格开发的界面：
然后是微信小程序的开发设计文档，详细请
开发设计文档
从上图可以看出：
应用号的重心会首先体现在开发者层面
通过为开发者提供基本的SDK（组件、框架API以及开发者调试工具），向开发者开放多种服务及支撑能力
3. 应用号的特点
通过上面的描述，你大概了解到应用号是什么了，那么：
应用号对于不同使用者有什么特点？
和现在的WebApp、原生APP有什么区别？
请看下面分析：
3.1 对于用户
性能比WebApp好微信为开发者提供基本SDK（组件、框架API以及开发者调试工具）同时开放后台服务器，这使得应用号的性能和流畅度远高于WebApp
但性能和流畅度还是不及原生App
使用成本更低无需安装，不占内存，在微信内即搜即用，使用成本相对于安装App来说降低了很多
3.2 对于开发者
学习门槛低微信应用号的底层技术支持和HTML技术有很多相似之处，前端技术相对于其他技术来说无论是入门和学习门槛都较低
开发成本低相比于开发成本和维护成本居高不下的App来说，在满足功能需求、性能需求的前提下，“应用号”基于其跨平台的属性，无疑开发成本和维护成本更加低
3.3 对于产品策划者
基于微信的社交关系链和生态系统的产品矩阵，让产品形式的创新有了更进一步的想象空间
当然这取决于微信本身的开放程度。
基于应用号开发成本和性能体验的平衡特点，让产品策划者在设计产品解决方案时多了一种极具性价比的产品解决方案
特别是用于MVP试错、快速验证产品模式
3.4 对于产品运营者
绝大部分的App都会面临用户获取成本太高、活跃不足和留存难的问题，特别是现在用户需求基本被满足的时代，流量的获取和转化成本越来越高。
由于微信对小程序的克制，小程序的获客成本和用户留存问题更加严重，根本没有提供流量红利，完全没有。
获客成本微信对小程序并不提供如同应用商店一样的营销推广支持，用户只能通过：
线下扫一扫：一来是微信希望小程序的使用场景对接线下，把线下流量都引到微信上。二来是微信不允许第三方来它的生态里控制流量入口
应用内搜索：还是精确搜索！用户得对产品有较强的认知和偏好才可能搜索产品名称，根本不存在所谓的SEO和ASO
好友分享：纯依靠好友分享，微信群一个群最多500人一个人最多有5000好友，流量规模根本不足。
小程序的获客成本可能比APP更高。APP推广还有应用商店、移动广告平台之类的花钱渠道，小程序的获客，可能你有钱都不知道去哪儿花。
关于留存张小龙多次强调：小程序用完即走。实际上，根本不存在留存问题。用户想不起你，你根本无法触达用户，这意味着你无法对用户进行群Push或过多的营销动作，小程序只能发送客服信息和模板信息。App还能Push、应用内调起等等
小程序留给产品运营者的空间真的非常小，如何做好用户获取和用户留存更是一大难点
应用号是WebApp和原生App的一种中间产品形态：在开发成本和性能体验之间取得了很好的平衡
对于开发者、产品/运营者有机遇也有挑战，具体情况要看具体操盘
对于用户来说，应用号是一种新的技术解决方案，最后目的还是为了满足用户日益变化的需求
4. 应用号的应用场景
在了解其功能和特点后，那么，应用号适用于什么需求场景呢？请看下图：四象限需求层次图：
横轴=需求刚性，纵轴=需求频次，象限=需求类别
四象限需求层次图
4.1 象限1：高频、刚需
对于高频、刚需的使用场景，由于用户使用频次很高，对于产品形态要求：
寻找产品的成本要低
性能和流畅度要求非常高
应用号并不使用高频、刚需的使用场景，因为应用号：
寻找产品成本高：每次都必须在微信内重新搜索，成本比固定在手机某个位置高得多
性能和流畅度不及原生App
结论：应用号不适用于高频、刚需的需求场景，该场景下应采用原生App
4.2 象限2：高频、非刚需
对于高频、非刚需的使用场景，由于里面涉及的产品类型较多（内容型、工具型、社区型、游戏型），要试情况而定：娱乐类需求（阅读、音乐、视频、游戏、社区）
阅读类的内容型产品需要深度阅读环境和较高的交互、视觉体验，建议使用原生App；
当然你也可以先用订阅号或服务号进行导流
偏工具的内容型产品（如音乐类和视频类）功能和性能满足的前提下，基于开发成本和使用成本，建议采用应用号
社区类产品鉴于微信拥有强大的关系链，建议先用应用号进行快速试错 / 作为入口，待尝试成功后再将流量导入到原生App
游戏类产品鉴于游戏要求很高的交互、视觉体验和沉浸感，建议采用原生App
当然小游戏类别的产品，采用应用号是非常不错的，因为微信有着天然的获客和传播能力
日常工具类产品在功能和性能满足的前提下，基于开发成本和使用成本，建议采用应用号
假如野心足够大，有足够的战略布局成为平台级产品的话，如美图秀秀，可以先做应用号，再导流到原生App
偏运营为主或带有媒体属性的产品根据张小龙对应用号的定义：用完即走，可以预测微信对于应用号在推送消息、运营方面会非常克制，这有区别于订阅号/服务号推送消息、App推送消息，所以，假如你的产品是以运营为主或带有一定的媒体属性产品，建议你还是优先采用订阅号或服务号（具备发送消息功能），甚至是原生App
由于高频、刚需场景市场已经被巨头垄断，所以很多创业者基本会选择在高频次、非刚需的场景切入
区别于“原生App开发难度大、周期长、获客成本极高、推广成本极高”的现状，应用号在开发成本和性能体验取得了较好的平衡+微信天然的传播能力和获客能力，所以创业者应该通过应用号来进行MVP产品的尝试
结论对于高频、非刚需的使用场景，采用的产品形态试情况而定，应用号主要适用于：
偏工具的内容型产品
日常工具类产品
社区类产品（作为导流作用）
游戏类产品（小游戏）
创业者进行MVP产品形式的探索
4.3 象限3：低频、非刚需
对于低频、非刚需需求，基本是属于小众的需求，一般有两种情况：开发者自身兴趣 / 专业级产品，面向某领域专业用户
对于第一种情况，就看开发者本身的能力，如果你是移动端开发者，那就开发原生App；如果你是前端，就开发应用号
对于第二种情况，由于专业级产品一般对于性能和交互体验较高，所以优先采用原生App
4.4 象限4：低频、刚需
对于低频、刚需的需求场景，这里涵盖了大量长尾的生活服务需求，比如说各种旅游需求、各种上门服务等等。这类长尾需求的现状是：
原生App：大量使用频次过低（一个月甚至半年才1、两次）的原生App却占据着手机大量内存
订阅号 / 服务号：WebApp的性能和流畅体验无法满足功能需求
是的，这类长尾需求的的解决方案正是处于原生App和订阅号 / 服务号 进退两难的地步，而应用号是WebApp和原生App的一种中间产品形态：在开发成本和性能体验之间取得了很好的平衡。所以说，应用号正好是解决这样需求场景的解决方案
结论：应用号非常适用于低频、刚需的长尾生活服务需求
应用号场景总结：（以按优先级排序）
基本涵盖所有低频、刚需的长尾生活服务需求场景
初创企业进行产品模式的探索
作为增量渠道，为原生App进行导流
小部分高频、非刚需场景
具体看下图：
5. 应用号的初衷
对不起，下面不会有”微信要做操作系统“诸如此类的长篇大论，仅仅只是同样作为产品人，对于腾讯、张小龙开发应用号的初衷分析
同样作为产品人，我一直坚持做产品的信仰：勿忘初衷。对于腾讯、对于微信、对于张小龙我相信亦是一样：连接一切
微信作为腾讯的拳头产品，自然担任着这种重要任务，我们先来看下微信的发展历程：
微信1.0目的：连接人与人功能形式：即时通讯、摇一摇、朋友圈和附近的人
微信2.0目的：连接人与信息功能形式：订阅号、朋友圈热文搜索
微信3.0目的：连接人与服务功能形式：企业号、服务号
显然，微信对于1.0时代和2.0时代的任务已经完成得无可挑剔，堪称现象级产品策略和操盘。
但是，对于微信3.0 连接人与服务呢？微信为搭建连接人与服务平台试过了微信服务号，微信企业号，然而都没有达到预期的效果。
同时，通过上面的四象限需求场景分析，你会发现，服务号作为产品解决方案的需求场景基本被应用号所取代。
所以，应用号颠覆的并不是原生App，而是服务号。
请你把上面把应用号的作为解决方案的需求场景换成服务号，你会相信便是现在市场现状
虽然原生App的应用场景受到了一定的冲击，但原生App的需求场景依旧无法被取代
腾讯又一次颠覆了自己，就像当年微信颠覆QQ一样
再加上日常增显的用户关于长尾生活服务的需求：
原生App：大量使用频次过低（一个月甚至半年才1、两次）的原生App却占据着手机大量内存
订阅号 / 服务号：WebApp的性能和流畅体验无法满足功能需求
是的，这类长尾需求的的解决方案正是处于原生App和订阅号 / 服务号 进退两难的地步，而应用号是WebApp和原生App的一种中间产品形态：在开发成本和性能体验之间取得了很好的平衡。所以说，应用号正好是解决这样需求场景的解决方案。
于是，在我看来，微信开发应用号的初衷是：
从公司战略（初衷）出发，应用号实际上是微信在服务号的基础上对提高企业服务能力的一次尝试，更进一步连接人与服务。
从用户需求角度出发，解决”大量使用频次过低（一个月甚至半年才1、两次）的原生App却占据着手机大量内存“+“WebApp性能无法满足生活服务需求”的问题，为了囊括市场大量高频、非刚需的长尾生活服务需求场景，将海量用户与海量服务进行对接，更进一步连接人与服务
在满足用户需求的前提下实现公司战略和商业模式，勿忘初衷，这正是张小龙让我佩服的地方
分析到这里，相信大家已经明白：什么场景下我该开发微信“小程序”，什么场景下该开发原生App
6.1 App是不是不用活了？
每当一种新技术的出现，人们往往会将其与之前技术对比，并采用”非此即彼“的做法。
一般出现上面这种言论的人，基本上是开发者：前端 Vs 移动端 。
我先问个问题哈
民国年代，人们基本以自行车代步；之后，当汽车甚至是飞机面世后，请问，自行车这种出行方式还存在吗？
相信你应该能明白我的意思：任何撇开需求场景而空谈解决方案都是没有意义的，应用号仅仅只是作为一种新的技术解决方案出现。
同时，从上面四象限需求层次分析可以看出：
原生App和应用号的应用需求场景不同，所以无谓说颠覆
真的要说颠覆，那么应用号颠覆的是服务号，而不是原生App
应用号实际上是提供了一种新的产品解决方案，微信是在鼓励H5开发，但依旧开放了App的接口能力，这说明未来H5和App并不是‘你死我活’的状态，应该是混合应用的趋势。
对于开发者、产品/运营者，要做的应该是正确判断需求场景，然后选择合适的解决方案更好地去服务用户
而不是一味叫喧App将死、开发应用号就足够了这些浮躁的言论。
6.2 应用号会不会成功？
早在微信做应用号之前，这种基于H5的“轻应用”模式已经被国内几家巨头所尝试。
2013年，百度正式推出“轻应用”平台。李彦宏当时对其寄予厚望，“未来搜索引擎在智能识别用户需求后将实现无需任何下载安装，直接调起应用”。
同样的问题也出现在更早之前的浏览器“网页应用”上。UC浏览器、360浏览器、百度浏览器等早在百度提出“轻应用”概念之前，就已经开始推广“网页应用”了，三者都基于客户端或者手机浏览器进行架构。
但是，他们都失败了。原因主要是：“轻应用分发平台”、“网页应用”极大程度上依赖于主产品的属性认知和使用场景：
搜索和浏览网页的工具属性太强，无法唤起人们进去使用其他服务的认知
搜索和浏览网页属于非刚需、中低频需求，用户使用频率和活跃时长较低，无法撑起整个服务生态
但是，对于微信来说：
已从”即时通讯工具“转变成‘生活服务平台”：各种城市服务+生活服务，使用场景早已拓宽
本身社交属于高频、刚需的需求，保证了用户的使用频率和活跃时长
所以说，微信一定会成功吗？我觉得倒不一定。
但是，假设有一天，如果有一款产品能在“轻应用”领域上取得成功的，我相信一定是微信。
最后再唠叨几句：
微信稍微掀了一下裙底而已，不要一下子都高潮了
对于用户来说，我建议你的手机清多几个G内存来迎接应用号的到来
对于产品 / 运营者来说，要做的应该是正确判断需求场景，然后选择合适的解决方案更好地去服务用户。跟风最可怕
对于开发者来说，兴趣最重要。跟风最可怕
欢迎关注的简书！
不定期分享关于产品策划方法论干货，追求短、平、快，但却不缺深度。
CSDN签约作者、简书推荐作者、稀土掘金专栏作者
走在产品路上的Android研究生
分享 Android、产品运营干货
CSDN：http://blog.csdn.net/carson_ho
稀土掘金：https://juejin.im/user/58d4d6ba65edc
Github：/Carson-Ho