85456

1.launchMode
https://blog.csdn.net/CodeEmperor/article/details/50481726
https://blog.csdn.net/hp910315/article/details/49306511
应用场景：
singleTop适合接收通知启动的内容显示页面。例如，某个新闻客户端的新闻内容页面，如果收到10个新闻推送，每次都打开一个新闻内容页面是很烦人的。

singleTask适合作为程序入口点。例如浏览器的主界面。不管从多少个应用启动浏览器，只会启动主界面一次，其余情况都会走onNewIntent，并且会清空主界面上面的其他页面。之前打开过的页面，打开之前的页面就ok，不再新建。

singleInstance适合需要与程序分离开的页面。例如闹铃提醒，将闹铃提醒与闹铃设置分离。singleInstance不要用于中间页面，如果用于中间页面，跳转会有问题，比如：A -> B (singleInstance) -> C，完全退出后，在此启动，首先打开的是B。

AMS WMS
https://www.jianshu.com/p/47eca41428d6

3.compileSdkVersion，minSdkVersion，targetSdkVersion 的区别和比较
https://blog.csdn.net/u010286855/article/details/54691614

4.objectanimator PathInterpolator android playTogether

5.SharedPreferences调用导致的ANR分析
SharedPreferencesImpl
SharedPreferences中的commit和apply方法
https://blog.csdn.net/jake9602/article/details/18414841
1. apply没有返回值而commit返回boolean表明修改是否提交成功
2. apply是将修改数据原子提交到内存, 而后异步真正提交到硬件磁盘, 而commit是同步的提交到硬件磁盘，因此，在多个并发的提交commit的时候，他们会等待正在处理的commit保存到磁盘后在操作，从而降低了效率。而apply只是原子的提交到内容，后面有调用apply的函数的将会直接覆盖前面的内存数据，这样从一定程度上提高了很多效率。
3. apply方法不会提示任何失败的提示。
由于在一个进程中，sharedPreference是单实例，一般不会出现并发冲突，如果对提交的结果不关心的话，建议使用apply，当然需要确保提交成功且有后续操作的话，还是需要用commit的。

 

6.mediaRecorder.prepare放在子线程

7.systemproperties.set 是否是耗时操作

8.android renderthread

9.Trace.traceBegin

10.关于Android的SystemProperties的 set和get可能存在延时的分析
https://blog.csdn.net/songjinshi/article/details/38679117

11.
Android性能优化之UncaughtExceptionHandler定制自己的错误日志系统
https://www.cnblogs.com/whoislcj/p/5468190.html

12.
view的post方法产生的问题
https://blog.csdn.net/mayong_/article/details/78779696