无论是哪个App，它的启动步骤都大体相同，如图9-3所示：
图9-3 App启动流程
我们仔细研究一下图9-3中的每一步都做了哪些事情：
1）Splash广告的逻辑是，首次加载App包中的图片，同时调用MobileAPI的一个接口，获取下一次打开的图片URL，把这张图片存放在本地。那么下次再打开这个App时，就加载这张新图片，同时，仍然调用MobileAPI的那个接口，看是否有新的Splash图片要下载。为了确保首页打开速度，MobileAPI的这个接口一定是异步调用的。
2）引导页，不要超过4页，甚至4页我都认为多。最近流行在引导页加入动画，让App变得活泼生动一些。因为做原生动画比较耗费人力和时间，所以很多公司要么不加，要么用gif动画来实现。
3）进入首页之前，很多App会要求用户选择所在城市，有的App是默认选一个城市进入，有的App则是异步定位当前城市，同时给用户选择所在城市的机会。
4）App首页的设计，则经历过几次大的革命。过去是把公司的主要产品放在首页很显眼的位置，次要产品则放在二级页面，也有的公司是每个品类做一个App。现在通用的做法是，尽可能多的把所有产品都显示在首页，会有轮播广告，会有搜索框，会有滚动条。首页这个位置太重要了，只要出现在首页的产品，卖的都很好。
以上都是看得见的东西，接下来说一些在后台做的看不见的事情：
1）友盟打点统计，统计激活数。
2）注册推送。
3）如果是从消息推送点击进入的App，则要根据推送协议，跳转到具体的页面。
4）初始化崩溃收集机制，如果上次崩溃时没有来得及发送崩溃信息，那么这次发送。
总结一下上述这些事情的共性，都是要调用MobileAPI接口获取数据的。为了不影响首页打开速度，这些操作都是在后台异步执行的。
不同公司的App，它们所使用的第三方服务不同，所以还会做一些别的事情。对于其中比较耗时的，也都是要放在后台异步执行。
由此而引入一款嗅探器，WireShark，也有使用fiddler的。当我们试图探索别人家App为什么首页加载速度那么快的时候，使用嗅探器可以观察出首页加载期间该App调用了哪些MobileAPI接口，以及返回用了多长时间，下载了哪些Zip包以及Zip包中有哪些东西。
很多App升级新版本后会直接崩溃，这是程序员没有做好App兼容导致的，肯定是上一个版本遗留下来什么脏数据，在升级后新版本没有处理好如何兼容这些脏数据就崩溃了。所以App发版前必须要做兼容性测试，以确保稳定性。最好的解决方案是，App升级后，除了用户信息要保留之外，所有遗留数据都要清除。