移动互联网仍然是个炙手可热的战场，但是移动APP已经不是当年单兵作战的节奏了，小而美的APP可以继续抢占蓝海，而大而全的APP才会更深度的满足用户刚性需求。APP需要提供更多更有价值的服务，需要不仅仅拘泥于一个小小的手机屏幕，需要解决不同平台不同尺寸的适配问题，需要与兄弟APP形成合力共同为用户提供服务集群。随着不断的迭代迭代再迭代，功能越来越多，慢慢变成一个胖APP，胖APP发生了怎样的变化，又需要面临什么样的转型呢?
本文主要讲述胖APP的4大发展方向——1.APP插件化;2.APP互通化 3.APP破壳化 4.APP扩展化。这4个方向，能让胖客户端更好满足用户需求的同时，仍然能保持轻量化的良好用户体验。
1.APP插件化
随着移动APP的版本迭代，仅仅满足基本功能的APP，在发展路径上多少都会受挫，而提供更多的增强功能又会让APP变得臃肿。怎样平衡用户的需求与APP的臃肿度呢?一个简单的办法就是打造APP插件化，给瘦APP增肥，给胖APP瘦身，而这一切，都是根据用户的需求进行的选择。
eg.百度云
百度的工具包，就是这样一种插件化的手段。你可以把你的通讯录、短彩信都备份到云上，可以安装在线视频播放插件、图片处理插件，而这一切，都是根据你的需求来获取的。当你需要的时候，经过授权，才会安装相应的插件。这样就能保证，APP的功能是完整的，而安装包还是足够的小。也不会有太多的干扰因素割裂主任务。
eg.微信
微信也是如此，随着不断迭代增加的新功能，势必会导致APP变得臃肿。为了使产品使用起来更加轻量化，微信就把一些不重要的功能隐藏起来，把一些不常用的功能做成插件，用户可以选择性安装。比如语音输入、QQ邮箱提醒等等。只不过到了微信5.0版本，这些插件大部分变成了服务号，比如QQ离线消息、QQ邮箱提醒，我想这是微信尽量把插件从SDK这种客户端形式转化成WebAPP这种轻量化形式的一种转型。同时用户也不需要理解插件这种技术化的概念，只是当你需要的时候，能获得对应的服务就可以了。
2.APP互通化
单一APP难以行成强大的气候，也很难满足越来越复杂的深度需求。而拆解成多个子APP，则可以互相借力，可以互带流量。尤其是当两个APP处于需求链上下游的时候，如果能互调调用解决某些特定的需求，则是非常提升用户体验的事情。APP之间的互通，即是APP互相带量的手段，也是用户需求满足的手段。
eg.Google+、照片、环聊
Google系的产品互相之间能形成推广链条，利用各自的侧边栏用做互推资源位。从Google搜索首页可以点击进入Google+，从Google+的侧边栏，则可以点击调起相册或者环聊，而从相册的侧边栏，还可以再次点击调起Google+。
这是Google产品互调的逻辑图，可以看到Google产品其实也是缺乏完全统一的布局和思考的。虽然利用各APP之间的跳转能带来一定的量，但是互调既有调起APP的逻辑，又有切换标签的逻辑，就会导致返回逻辑往往是错乱的。但是相对来说已经算是APP互调手法里最好的了。
eg.微信、微视
微信可以调用多种第三方APP，其中结合的比较好的案例，就是微信调用微视，拍摄视频后再分享到微信的过程。
微信调用微视，是属于中间插入任务堆叠类的插入式流程，一旦调用流程结束，微视也就完成使命了。这种调用方式，是以完成任务为使命的。
互调无论是为了带量，还是为了满足需求，都要非常仔细的去处理APP之间的返回逻辑，这样才能让用户体验行程闭环，避免APP切换产生的割裂感。
3.APP破壳化
每个APP都是一个信息孤岛，当用户下载APP之前，根本无法知道APP里面到底有多少有价值的信息。而APP的下载、安装、登录成本又是极高的。试想一想，你想看一视频，需要十几个APP一个一个的去搜，想看一本电子书，也是需要下载十几个APP一个一个的去找。所以APP破壳检索的确是一个厄待解决的问题。怎样在不安装APP的情况下，可以快速知道APP里的内容?怎样在装了APP的情况下，可以快速索引到APP里的内容?
Google的为解决这个问题，推出了App Indexing，APP Indexing是同时有网站和App的开发者用的，它是将一个网页和一个App页面对应起来，于是现在你搜索网页也相当于同时搜索App的内容，如果搜到了，它会显示一个“Open in App”的按钮。但是，如果你没有下载该App，它就不会显示这个按钮了。
eg.Google搜索、百度APP
Android平台系统级别的应用均可以被检索到，比如用Google搜索，你就能搜到联系人信息、索引到所有应用、找到chrome浏览历史等等。而iOS平台也是，仅有系统级别的APP，能被更好的索引到内容，用百度APP搜索某个联系人，可以直接索引到通讯录。而其他的第三方APP，则很难破壳索引到内容，这种情况厄待解决。
eg.豌豆荚
豌豆荚的应用内搜索，也是跟Google APP Index类似的解决方案，不同的是Google APP Index是需要APP配套网页来实现检索的。而豌豆荚的应用内检索并不需要网页支持。通过内容来进行索引，再调起对应的APP来浏览内容，这大概是目前为止最有想象空间的方法了，但彻底打破APP孤岛壁垒，还需要更多的APP一起来支持应用内搜索。
4.APP扩展化
随着时间的推移，各大厂商的不断迭代，平台越来越丰富，分辨率越来越多样，历史版本越来越多，维护成本和适配成本也越来越高。为此不得不在开发版本的时候，充分考虑到APP的扩展性。APP是否能兼容多种不同的分辨率，一套设计是否能适配多个平台?是否适合小屏幕大屏幕穿戴屏幕多种使用场景?
eg.Google Now
Google Now是考虑扩展性的最好案例，不仅仅是移动端全平台的考虑，Google Now适配Google Glass、Android Wear貌似都很轻松，甚至Now这种语音交互的形式，简直像是考虑可穿戴先行而设计出来的。
eg.百度云
百度的Android版、iPhone版、PC版、Mac版、TV版相继推出，如果不考虑扩展性的化，设计师和产品团队都会心力交瘁的。好在目前去做设计架构的时候，都是最大程度的考虑全平台扩展性，甚至未来可穿戴市场的适配。APP功能多但结构仍然要维持简单。
最后让我们来回顾一下，胖APP发展下去，一定会成为用户的负担的，所以我们不得不考虑胖APP瘦身，或者胖APP拆分，主要可参考本文提到的手法——1.APP插件化;2.APP互通化 3.APP破壳化 4.APP扩展化。这4个方向，能让胖客户端更好满足用户需求的同时，仍然能保持轻量化的良好用户体验。
