移动互联网仍然是个炙手可热的战场，但是移动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个方向，能让胖客户端更好满足用户需求的同时，仍然能保持轻量化的良好用户体验。