当说到android app启动流程的话，用户角度认为的启动流程是：打开手机-点击app图标-进入app页面，这就是用户理解的流程；而作为一名开发者，对他们来说并不简单，他们是app的开发者，知道每款app启动流程的背后需要付出多少心血。app启动流程并不像表面那么简单，它是一个繁琐而复杂的过程，接下来就以“友盟 u-apm”带大家了解下android app的启动流程是什么！
第一次启动
Dalvik虚拟机在app第一次启动时，会对dex文件进行dex2opt操作，对dex进行验证和优化，并生成odex文件，之后的启动都会基于这idex文件启动，所以Dalvik虚拟机在第一次启动app时会很慢。
流程
1.点击桌面APP图标时，Launcher的startActivity()方法，通过Binder通信，调用system_server进程中AMS服务的startActivity方法，发起启动请求
2.system_server进程接收到请求后，向Zygote进程发送创建进程的请求
3.Zygote进程fork出App进程，并执行ActivityThread的main方法，创建ActivityThread线程，初始化MainLooper，主线程Handler，同时初始化ApplicationThread用于和AMS通信交互
4.App进程，通过Binder向sytem_server进程发起attachApplication请求，这里实际上就是APP进程通过Binder调用sytem_server进程中AMS的attachApplication方法，上面我们已经分析过，AMS的attachApplication方法的作用是将ApplicationThread对象与AMS绑定
5.system_server进程在收到attachApplication的请求，进行一些准备工作后，再通过binder IPC向App进程发送handleBindApplication请求(初始化Application并调用onCreate方法)和scheduleLaunchActivity请求(创建启动Activity)
6.App进程的binder线程(ApplicationThread)在收到请求后，通过handler向主线程发送BIND_APPLICATION和LAUNCH_ACTIVITY消息，这里注意的是AMS和主线程并不直接通信，而是AMS和主线程的内部类ApplicationThread通过Binder通信，ApplicationThread再和主线程通过Handler消息交互。 ( 这里猜测这样的设计意图可能是为了统一管理主线程与AMS的通信，并且不向AMS暴露主线程中的其他公开方法，大神可以来解析下)
7.主线程在收到Message后，创建Application并调用onCreate方法，再通过反射机制创建目标Activity，并回调Activity.onCreate()等方法
8.到此，App便正式启动，开始进入Activity生命周期，执行完onCreate/onStart/onResume方法，UI渲染后显示APP主界面 APP启动过程的部分代码思考。
总结
对于android app启动流程的总结就是以上的介绍了。针对启动流程这块内容呢，是一个繁琐而复杂的过程，对开发者来说，是件不容易操作的事情，在启动过程中时不时的还会给你出点难题，出现闪退、黑屏什么的。我相信只要是开发人员，就会变得头大。这时，可以借助一些第三方工具来帮助检测性能问题，“友盟 u-apm应用性能监控平台”作为一款监测工具，就可以帮助开发者检测一些启动流程以及app性能上的问题。
除此之外，U-APM 是友盟 推出的App稳定性监控、性能监控和云真机测试平台。通过轻量级的集成接入即可拥有实时、可靠、全面的应用崩溃、ANR、自定义异常等捕获能力，及卡顿、启动分析等性能能力。另外，友盟 搭载在U-APM应用性能监控平台上推出了友盟 云真机服务，为移动开发者提供了灵活地测试操作界面，支持ADB调试、WEB远程调试、扫码、抓包、虚拟定位等测试功能，并提供了测试报告供开发者后续查看。
