add files

CharonChui · CharonChui · commit 342511f41c9a · 2016-06-16T20:19:19.000+08:00
diff --git a/Android加强/性能优化相关工具.md b/Android加强/性能优化相关工具.md
@@ -248,7 +248,12 @@ public void ProcessPeople() {
 - 连接你的手机或者模拟器。 
     出于安全性考虑，`Hierarchy Viewer`只能连接开发者版的系统的手机。 
 - 运行程序，并且让界面显示出来。
-- 启动`hierarchy view`工具，接着就能看到左边栏显示出了对应的设备，展开后可以看到一些组件的名称。这个页面包含了应用的界面以及系统的界面。选择你的应用中想要查看的界面即可。    
+- 启动`hierarchy view`工具，接着就能看到左边栏显示出了对应的设备，展开后可以看到一些组件的名称。这个页面包含了应用的界面以及系统的界面。选择你的应用中想要查看的界面直接双击就可以了。    
+
+![image](https://raw.githubusercontent.com/CharonChui/Pictures/master/gettingstarted_image005.png?raw=true)
+如果你的界面显示的不是这个样子，少一些东西的话，你可以使用`Window>Reset Perspective`来重置样式。 
+
+
 
 但是我并打不开。   
 如果你的手机是`Android 4.1`及以上版本你必须要在你的电脑上设置一个`ANDROID_HVPROTO`DE 环境变量才可以。
@@ -267,6 +272,56 @@ public void ProcessPeople() {
         ```
     - `source .bash_profile`
 
+如果配置完成后仍然不能用的话，你可以:   
+
+- 关闭`Android Studio`.
+- 执行`add kill-server`，然后`adb start-server`.
+- 通过命令行开始`hierarchyviewer`.
+
+好了，我们直接打开自己的页面进行查看布局吧(有点慢)。   
+它是介个样子滴 ：     
+![image](https://raw.githubusercontent.com/CharonChui/Pictures/master/hierarchy_vierwe_page.png?raw=true)
+
+我们可以看到所有结构，点击对一个的节点，能直接看到该界面的`UI`效果，并展示该布局包含多少个`View`，以及该布局`measure,draw,layout`所消耗的时间。选中`Show Extras`选项可以看到在右下角看到界面效果。   
+
+选中要查看的节点后点击`Profile Node`选项，可以看到如下界面:    
+
+![image](https://raw.githubusercontent.com/CharonChui/Pictures/master/hierarchy_profile_node.png?raw=true)
+
+可以看到每个布局都出现了三个点。有不同的颜色,从左到右这三个点分别表示:   
+
+- 左边的点代表`Draw`阶段。
+- 中间的点代表了`Layout`阶段。
+- 右边的点代表了`Execute`阶段。
+
+这三个点有分别对应了`pipeline`中的不同阶段，如下图:    
+![image](https://raw.githubusercontent.com/CharonChui/Pictures/master/gettingstarted_image015.png?raw=true)
+
+不同的颜色代表不同的性能:    
+
+- 绿色代表渲染的非常快，至少是其他`View`的一半。
+- 黄色代表`View`渲染比最后那一半的`View`快。
+- 红色代表`View`渲染是几乎是在最慢的那部分中间。
+
+
+
+Interpreting Hierarchy Viewer Profiling Results
+Hierarchy Viewer measures the relative performance of a node, so there are always red nodes in a profile, and it doesn't necessarily mean that view is too slow for the users of your app.
+
+Hierarchy Viewer software rasterizes your Activity to acquire the timing information. Rasterization is the process of taking a high-level primitive, such as a circle or a vector font, and turning it into pixels on the screen. Typically, rasterization is done by the GPU on your device, but in the case of software rasterization, rendering is done on the CPU with ordinary software. This means that the absolute reported timings are correct relative to each other, but are bloated and vary depending on the overall and changing CPU workload on your device and PC. Profile several times to get a feel for the average measurements.
+
+The following are guidelines for interpreting Hierarchy Viewer profiling output.
+
+A red node is a potential problem in any situation where your app has unexpectedly slow performance. In a relative setting, there is always a slowest node; make sure it is the node you expect. The following examples illustrate how to interpret red dots.
+
+Look for red dots in leaf nodes or view groups with only a few children. This might point to a problem. Your app may not be slow, or it may not be slow on your device, but you need to be aware of why that dot is red. Systrace or Traceview can give you additional information.
+If you have a view group with many children and a red measure phase, take a look at the children to see how they are performing.
+A view with yellow or even red dots might not be performing slowly on the device. That's where the actual numbers are helpful. Systrace or Traceview can give you additional information.
+If the root view of a hierarchy has a red measure phase, red layout phase, and yellow draw phase, this is somewhat typical, because it's the parent of all the other views.
+If a leaf node in a tree with 20+ views has a red draw phase, this is a problem. Check your OnDraw method for code that shouldn't be there.
+
+
+
 
 ###过度绘制
 
@@ -285,12 +340,17 @@ public void ProcessPeople() {
 
 在Honeycomb版本中引入了硬件加速（Hardware Accleration）后，我们的应用在绘制的时候就有了全新的绘制模型。它引入了DisplayList结构，用来记录View的绘制命令，以便更快的进行渲染。但还有一些很好的功能开发者们往往会忽略或者使用不当——View layers。
 
-使用View layers（硬件层），我们可以将view渲染入一个非屏幕区域缓冲区（off-screen buffer，前面透明度部分提到过），并且根据我们的需求来操控它。这个功能主要是针对动画，因为它能让复杂的动画效果更加的流畅。而不使用硬件层的话，View会在动画属性（例如coordinate, scale, alpha值等）改变之后进行一次刷新。而对于相对复杂的view，这一次刷新又会连带它所有的子view进行刷新，并各自重新绘制，相当的耗费性能。使用View layers，通过调用硬件层，GPU直接为我们的view创建一个结构，并且不会造成view的刷新。而我们可以在避免刷新的情况下对这个结构进行进行很多种的操作，例如x/y位置变换，旋转，透明度等等。总之，这意味着我们可以对一个让一个复杂view执行动画的同时，又不会刷新！这会让动画看起来更加的流畅。下面这段代码我们该如何操作：
-
+使用View layers（硬件层），我们可以将view渲染入一个非屏幕区域缓冲区（off-screen buffer，前面透明度部分提到过），并且根据我们的需求来操控它。这个功能主要是针对动画，因为它能让复杂的动画效果更加的流畅。而不使用硬件层的话，View会在动画属性（例如coordinate, scale, alpha值等）改变之后进行一次刷新。而对于相对复杂的view，这一次刷新又会连带它所有的子view进行刷新，并各自重新绘制，相当的耗费性能。使用View layers，通过调用硬件层，GPU直接为我们的view创建一个结构，并且不会造成view的刷新。而我们可以在避免刷新的情况下对这个结构进行进行很多种的操作，例如x/y位置变换，旋转，透明度等等。总之，这意味着我们可以对一个让一个复杂view执行动画的同时，又不会刷新！这会让动画看起来更加的流畅。
 在阅读了ViewPager的源码后，我发现了在滑动的时候会自动为左右两页启动一个硬件层，并且在滑动结束后移除掉。
 
 在两页间滑动的时候创建硬件层也是可以理解的，但对我来说小有不幸。通常来讲加入硬件层是为了让ViewPager的滑动更加流畅，毕竟它们相对复杂。
 
+
+是的，但是再使用硬件layers的时候还是有几点要牢记在心：
+
+- 回收 – 硬件层会占用GPU中的一块内存。只在必要的时候使用他们，比如动画，并且事后注意回收。例如在上面ObjectAnimator的例子中，我们增加了一个动画结束监听以便在动画结束后可以移除硬件层。而在Property animator的例子中，我们使用了withLayers()，这会在动画开始时候自动创建硬件层并且在结束的时候自动移除。
+- 如果你在调用了硬件View layers后改变了View，那么会造成硬件硬件层的刷新并且再次重头渲染一遍view到非屏幕区域缓存中。这种情况通常发生在我们使用了硬件层暂时还不支持的属性（目前为止，硬件层只针对以下几种属性做了优化：otation、scale、x/y、translation、pivot和alpha）。例如，如果你另一个view执行动画，并且使用硬件层，在屏幕滑动他们的同时改变他的背景颜色，这就会造成硬件层的持续刷新。而以硬件层的持续刷新所造成的性能消耗来说，可能让它在这里的使用变得并不那么值。
+
 有关如何使用`Hardware Layer`请参考之前写的文章:[通过Hardware Layer提高动画性能](https://github.com/CharonChui/AndroidNote/blob/master/Android%E5%8A%A0%E5%BC%BA/%E9%80%9A%E8%BF%87Hardware%20Layer%E6%8F%90%E9%AB%98%E5%8A%A8%E7%94%BB%E6%80%A7%E8%83%BD.md)
 
 
