趁今晚老大不在偷偷早下班,所以有时间继续跟大伙扯扯UI设计之痛,也算一个是对上篇《Android:一个高效的UI才是一个拉风的UI(一)》的完整补充吧。写得不好的话大家尽管拍砖~(来!砸死我把~)

前言

  前篇博客翻箱倒柜的介绍了优化UI设计的两个方法,第一个就是使用尽量少的组件来实现布局功能,第二个就是使用<merge>标签来减少不必要的根节点,这两个方法都可以提高应用UI的运行效率,但是够了吗?远远是不够的,方法就像money一样永远不嫌多,所以不再介绍多一些UI设计优化的方法说得过去么?

  摸摸口袋里面的都快四岁、运行着古老的android 2.2系统的屌丝机对于我来说,随便一个大于10M的应用都有完爆他几条街死机崩溃的超能力。但是对于某信来说,如今已经24M大小的它依然在屌丝机濒临垂死的硬件资源上运行如飞(至少没崩溃过),让我不得不感叹应用优化做的相当不错,也满足我们这种屌丝在深深的寂寞夜晚来摇一发的情感需求。所以来说,一个应用能赢得市场,不仅仅是赢得先机,而更多的是因为相同需求它功能做的比你好,相同功能它比你的简约,相同简约设计它运行比你快!

----------------------------------我是分割线---------------------------------天王盖地虎-------------------------------------------------------------

排队,一个一个慢慢来

  当ActivityA跟ActivityB打招呼说:“偶要回家了,你来顶上”。说明就马上溜得无影无踪,这时候急呀,ActivityB赶紧measure呀、layout呀、draw呀赶紧搞出一个界面来应付观众先,忙的不亦乐乎;更要命这时候的是他们还要搞一个交接仪式——超炫超牛的切换动画!然而在日益无穷大的欲望与逐渐干瘪的资源这强大的根本矛盾下,毫不犹豫的当机了几百毫秒。这一卡顿让手机前的强迫症患者来说是多大的心理创伤,自然而然会说:“这软件真渣!切个画面都会总得顿一下才死心”。用户体验瞬间降为0~

  解决方案有哪些?当然很简单的就是,取消牛逼哄哄的切换动画咯,但是如果你的产品经理死活不同意那还不得另寻途径。在不放弃动画的前提下,我们可以把某些measure呀、layout呀、draw呀的步骤延迟在动画后面执行不就行咯,排队一个一个来,至于怎么操作呢?那我们要引入一个轻量级组件<ViewStub>,也就是动态加载的方法。

  我们通常使用它来做预加载处理,来改善页面加载速度和提高流畅性,ViewStub本身不会占用层级,它最终会被它指定的层级取代。有时候我们也需要复杂的视图且少用,我们可以按需要的时候装载以便减少内存,提高体验。以前我们都是设置在布局中,然后使用View.GONE属性来隐藏组件,但是耗资源影响性能。总得来说这玩意就是一个轻量级的View,它一个看不见的,不占布局位置,占用资源非常小的控件。

下面上代码:

要加载的ActivityB布局(复杂的动画代码请忽略)

<merge xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    >
    <ViewStub  
        android:id="@+id/mystub"  
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        />
    <ImageView
        android:id="@+id/loading_image"  
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:src="@drawable/loading_image"
        />
</merge>

  在这个UI界面中,当我们切换ActivityB时,因为兼顾到动画效果。所以我们就让ViewStub暂缓加载比较复杂的布局,而先把较为简单的显示加载画面loading_image加载出来,当稍后时间我们就在代码里面开始加载该布局,见代码如下:

@Override
protected void onCreate(Bundle savedInstanceState) {  
  super.onCreate(savedInstanceState);  
  setContentView(R.layout.layout_loading);  
          
  LoadHandler = new Handler();  
  myStub = (ViewStub)findViewById(R.id.mystub); 
  loadingView = (ImageView)findViewById(R.id.loading_image);  
  myStub.setLayoutResource(R.layout.layout_main);//设置加载资源
  LoadHandler.postDelayed(new Runnable() {  
    @Override  
    public void run() {  
      myStub.inflate();//开始加载复杂界面
      loadingView.setVisibility(View.GONE);//隐藏临时加载的简单界面
    }  
  },500);

  上面代码实现了先执行复杂动画,当切换界面到到500ms时,handler开始执行加载复杂的界面子线程,从而错开了资源的集中利用,这里使用的是动态添加ViewStub指向布局资源的方法,简单而实用吧,对于一个用户来说,延迟半秒加载界面远远比切换画面卡顿更容易接受。

使用ViewStub需要主要几点:

1、ViewStub只能被Inflate一次,当Inflate之后ViewStub对象就被置为空值,说得更通俗点就是当ViewStub被某个布局Inflate后,就不能通过ViewStub来控制它,因为它已经功成身退了,自然对于需要不同场景下显示隐藏的情况建议用visibility。

2、ViewStub只能用来Inflate一个布局文件,对于单个具体的View它是无能为力的,当然如果把View搞在某个布局文件中也是可以接受的。

3、VIewStub中不能嵌套merge标签。

重用布局是一个好习惯

  重用是一个好习惯,既然大家都常念叨,无图无真相呀楼主,为了避免大家说no picture you say a jb~这类回复,我还是勉勉强强上个图吧。

  这个界面由三个小部分组成,分别是标题栏、内容显示和底端按钮。如果你手指闲不住前前后后点一点,按一按;会发觉各个界面的风格惊人的相似!而且不仅仅是在这软件上会体现,而且市场上大部分应用都是这样!其实说白了这就是一个风格的问题。

那么,既然这么多重复了,作为二十一世纪标准码农的我们来说,我们能忍受这种浪费吗?所以我们要用用<include>标签——模块化布局

布局如下:多简单的layout复用,你还会说你不喜欢用<include>标签吗?

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    android:orientation="vertical"
    >
 <include android:id="@+id/head_menu" layout="@layout/head_menu" />
 <include android:id="@+id/content" layout="@layout/content_showweibo" />
 <include android:id="@+id/bottom_menu" layout="@layout/bottom_menu" />
</LinearLayout>

使用<include>的好处有:

1、模块化布局,提高重用率,易于日后的维护和扩展。

2、降低生成的app的体重,用户的流量是很贵的!

简单说说剩下的点

1、减少不必要的inflate

(1)对于inflate的布局可以直接缓存,用全部变量代替局部变量,避免下次需再次inflate

if (loadingView != null) {
    loadingView.setVisibility(View.VISIBLE);
}
else{
    loadingView =LayoutInflater.from(context).inflate(R.layout.loadingView, this, true);
}

(2)BaseAdapter中item的convertView缓存用法,详细请参考《关于BaseAdapter的使用及优化心得

PS:第一次写的博文,写的渣得不能看。。。。。。

2、避免有太多的视图

每个视图都会消耗内存,在一个布局中布置太多的视图,布局会占用过多的内存,假设一个布局包含超过80个视图,layoutopt可能会给出下面这样的建议:

-1:-1 This layout has too many views: 83 views, it should have <= 80!

上面给出的建议是视图数量不能超过80,当然最新的设备有可能能够支持这么多视图,但如果真的出现性能不佳的情况,最好采纳这个建议。

3、千万别布局嵌套太多

布局不应该有太多的嵌套,layoutopt(和Android团队)建议布局保持在10级以内,即使是最大的平板电脑屏幕,布局也不应该超过10级,RelativeLayout可能是一个解决办法,但它的用法更复杂,好在Eclipse中的Graphical Layout资源工具更新后,使得这一切变得更简单。

下面是布局嵌套太多时,layoutopt的输出内容:

-1:-1 This layout has too many nested layouts: 12 levels, it should have <= 10!  305:318 This LinearLayout layout or its RelativeLayout parent is possibly useless 

嵌套布局警告通常伴随有一些无用布局的警告,有助于找出哪些布局可以移除,避免屏幕布局全部重新设计。

4、在某些场景下使用非主线程绘制的UI组件,具体组件名称我忘了,后面想起来补上哈。

 

作者:enjoy风铃
出处:http://www.cnblogs.com/net168/
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则下次不给你转载了。

posted on 2014-10-10 23:40  码农叔叔  阅读(5932)  评论(10编辑  收藏  举报