App Launch time & Activity creation (Android Performance Patterns Season 6 Ep. 2)

  AS developers,there's nothing we like more than an amazing activity that delights and entertatins our users.But sadly,initializing all the subsystems,resources,and layouts provide that experience takes a bit of time and memory,meaing like user are going to have to wait for their transcendent experience.And one of the most important things that you can do for the health and performance perception of your application is optimizing the performance of loading your activities.

  Remember,when the user launches your app,they'll be shown a start window while your app is loading and getting ready to display.Now,most of the time,if your user is spending too much time starting at the screen,the problem is most likely to be in the creation of your main activity.i mean,a bunch of stuff happens here.

--作为开发者，没有什么比的上能让我们的用户感到快乐，这是我们最喜欢的。但是，伤心的是，初始化所有子系统，资源和布局，会占用一些时间、内存，意味着用户必须等待这体验他们。另外一个最重要的事情，你可以为你的应用做一些健康性能感知的事情，就是优化加载你的activities的性能。

  记住，用户启动你的应用，你的app加载完，准备展示之后，它们会先显示一个启动窗口。如果大多数时间，用户在启动屏幕上花太多的时间，主要问题可能在你的main activitiy的创建。我的意思是，一堆的事情发上在这里。

 

 you're setting the theme data,inflating view hierachy,loading bitmaps,deserializing networking fetches,writing user prererences-you know,all the stuff you need to display your activity.

--设置主题数据，填充视图层次，加载位图，反序列化获取网络，编写用户参数，你知道的，所有这些事情，你需要在你的activity上展示。

 

But if you're not careful,each of these little operations can fall into their own performance pitfalls-things like multiple garbage collection events or wating to inflate views or blocking on network requests-all things which can delay the time it takes for the first pixel to be shown to the user.

--如果你不够小心，这些操作都将会把你带入性能陷阱。就像多种多样的垃圾回收时间或者等待填充视图或者网络请求阻塞，所有这些事情都会延迟你想展示第一帧给用户时的时间。

 

 so if you'd like to streamline your activity loading to give users the best experience possible,here's what you need to do.First,figure out if you actually have a problem,which you can do with the method tracing tool.This will give you a snapshot your call stack and let you visually see what functions are taking longer than others.

--所以，如果你想要简化你activity的加载，来带给用户最好的体验，这里有你需要的东西。首先，如果你的应用真的有问题，找出它，你可以用tracing 工具来解决。这个工具能够给你一个调用堆栈的快照，并且让你可视化的看看是哪个函数运行的时间比较长。

   

  

  if the onCreate function of your activity is taking longer than 16 to 30 milliseconds,then it's worth exploring more to see what might be causing the delay.

--如果你的activity 里面，onCreate函数运行的时间在16-30毫秒之间，然后去看下什么原因导致了这种延迟/

 

 And this can be done by inserting trace commands at various parts of your code.

并且我们也可以在你的代码各个地方插入跟踪命令来查看。

  

 when you do this,the timing between the begin section and end sections will be logged and then displayed in your Systrace captures.so that you can see more information about where your timing is going.

--

 

  Now ,if you've found that your load time is taking too long,hopefully you've been able to narrow it down using the inline tracing code.if not,here's couple of common problems and how to address them.Firstly,the most common problem we see with slow activity loads has to be the time it takes to inflate a view hierachy.see,the larger  your hierachy,the more time it's taken to inflate it,and the more bitmaps or resources it requires to load also adds to its load time.As such,anything you can do to flatten the hierarchy,reduce complexity,or stub out portions that aren't visible right now will help to reduce the time spent doing this work at the creation time of your activity.

 

  secondly,try to structure your code to rely on lazy loding and async processing as much as possible.commly,the onCreate method of your activity becomes a junk drawer for all sorts of different initialization routines.some of those things do need to happen right now.others can be delayed until later.

 

 

 This includes things like doing initial minimal loading of your hierarchy,loading all of your initial p_w_picpaths in an async fashion,and waiting to initailize heavy systems until they are absolutely needed.

 

 

 

转载于:https://blog.51cto.com/7080696/1855054