Android Performance

Google publishes an excellent list of performance tips (see  http://developer.android.com/training/articles/perf-tips.html), which the following are largely taken from and expanded upon. Some of these optimizations take a very macro approach, and some take a very micro approach to optimization and will only remove a line or two of bytecode from the generated classes.dex in the APK. These micro-optimizations will probably be handled by future just-in-time DVM optimizations or ahead of time by the new ART or Android Runtime virtual machine, which is a replacement for the DVM. However as ART is at the time of writing available only on Android KitKat, it may be a while before these automated optimizations become commonplace.

• Avoid creating unnecessary objects or memory allocations. There are two basic rules for writing efficient code:

• Don’t do work that you don’t need to do.
• Don’t allocate memory if you can avoid it.

• Mobile development is relatively simple right now; we don’t have the layers and layers of complexity that always appear as a technology matures, such EJBs.
• But it is inevitable that this is going to happen sooner or later on Android. People are already putting ORMs into their Android apps, so try to move to more of a TDD (test-driven development) model, and think about what you’re introducing. Do you really need to reinvent some caching mechanism to satisfy the feature you’re implementing, or not? If you are still worried, then apply the YAGNI concept— You Aren’t Going to Need It, because you really don’t need it.
• Avoid internal getters/setters. Virtual method calls are expensive, more so than instance field lookups. It’s reasonable to follow common object-oriented programming practices and have getters and setters in the public interface, but within a class you should always access fields directly. This is an example of a micro-optimization that removes a line or two of bytecode from the generated classes.dex in the APK.
• Use static/final where appropriate. Because of the way the code is compiled into Davlik bytecode, any code that refers to intVal will use the integer value 42 directly if you use a static final, and accesses to strVal will use a relatively inexpensive “string constant” instruction instead of a field lookup.
• Use floats judiciously. Floating-point calculation is expensive, usually taking twice as long as integer calculations on Android devices.
• Make fewer, more productive, NDK calls. Context switching between Java and C++ using the JNI or NDK can be expensive. There are also no JIT optimizations.
• But if the app uses some core algorithm or functionality that doesn’t need to be tied to the UI in any significant way, it should probably be run natively. Running things natively is almost always going to be faster than Java even with the JIT compiler. The NDK also comes with some major security benefits, as it’s much harder to reverse-engineer C++ code.
• Inflate Views only when needed. Basically, the idea here is that you only inflate the views a minimum number of times or better still delay displaying the view, because inflating views is pretty expensive.
• Use standard libraries and enhancements. Use libraries rather than rolling your own code. Android also sometimes replaces library methods with optimized hand-coded assembler. For example, using String.indexOf() and the System.arraycopy() method is about nine times faster than a hand-coded loop.
• Use StrictMode. To limit the chance of an Android Not Responsive (ANR) error, it helps to not include any slow network or disk access in the applications main thread. Android provides a utility called StrictMode, which is typically used to detect if there are any unwanted disk or network accesses introduced into your application during the development process. Add StrictMode to your onCreate() method as shown in Listing 3-1. StrictMode calls are also pretty expensive, so make sure the code isn’t shipped as production code.

  Listing 3-1.   Using the Strictmode utility

  public void onCreate()
  {
          // remove from production code
          if (BuildConfig.DEBUG){
                  StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder(),
                  .detectDiskReads()
                  .detectDiskWrites()
                  .detectNetwork()
                  .penaltyLog()
                  .build());
       {
          super.onCreate();
    
  }

• Optimize the onSomething(  ) classes. Earlier we talked about perception being reality for web applications; in the Android world, if your onStart(), onCreate(), and onResume() classes are lightning fast, then the application is going to be perceived to be a faster Android app. So if there is any code that you can put elsewhere or optimizations that you might want to apply, then spending time in these classes will bring rewards. Wait as long as you can to inflate any views. Using android.view.ViewStub will allow objects to be created when needed, a technique known as lazily inflating a view.
• Use Relativelayouts instead of Linearlayouts. New Android developers tend to create a UI over-using LinearLayouts. As the application becomes more complex, these linear layouts can often become quite nested. Replacing these LinearLayouts with a single RelativeLayout will improve your UI loading speed. Lint and the Hierarchy Viewer will help you identify deeply nested LinearLayouts.

Java Performance

There are books and books written about Java performance, and Android can also benefit from some well-written Java code. The Java Performance Tuning page (http://www.javaperformancetuning.com/tips/rawtips.shtml) is a page of links to articles about Java optimization with summaries and reviews of each of these pages of optimization tips.

The most common optimizations are as follows:

1. Use + for concatenating two Strings; use Stringbuffer for concatenating more Strings.

• Don’t synchronize code unless synchronization is required.
• Close all resources, such as connections and session objects, when finished.
• Classes and methods that aren’t going to be redefined should be declared as final.
• Accessing arrays is much faster than accessing vectors, Strings, and StringBuffers.

SQLite Performance

Website inefficiencies could often be summed up as “It’s the database, Stupid.” And while it’s less of an issue on Android, where SQLite is used more for client-side caching of information, there is no reason why EXPLAIN PLAN cannot still be very useful in your performance tuning. And don’t forget you can create indexes on SQLite, too, if you need them (see Figure 3-3).

Web Services Performance

For Web services it’s a case of “everything old is new again.” We’re right back to the web site optimization techniques I mentioned earlier. Use the server logs, as shown in Figure 3-2 earlier, to see how long each call is taking and optimize the slowest, most-used Web services. Some common optimizations for Web services are as follows:

• Minimize the size of the Web service envelopes; choose REST over SOAP and JSON over XML where possible.
• Reduce the number of round trips, steer clear of chatty Web service calls, and keep the number of Web service transactions to a minimum.
• Remove any duplicate calls, which are not as uncommon as they might seem.
• Similar to database SELECT * FROM TABLE statements, careful choice of query parameters can dramatically limit the amount of data returned via the Web service.
• Avoid maintaining state across calls; the most scalable of Web services maintain no state.
• Gzip the data.

Web proxy tools such as Charles Proxy (http://www.charlesproxy.com/) are an excellent way to see how your app is interacting with Web services.

The topic of Web services is covered in more detail in Chapter 8.

Optimized Code

In the next few pages you’re going to see how some of these optimizations are used in the ToDo List application. To begin, Listing 3-2 shows Splash.java, which has a bare-bones onCreate() method.

Listing 3-2.   The ToDo List Application’s Splash.java page

package com.logicdrop.todos;
  
import android.app.Activity;
import android.os.Bundle;
import android.content.Intent;
  
public class Splash extends Activity {
    public void onCreate(Bundle savedInstanceState) {
        // TIP: Optimized the onSomething() classes, especially onCreate()
        super.onCreate(savedInstanceState);
  
        // TIP: View - inflate the views a minimum number of times
        // inflating views are expensive
        /*for (int i=0; i<10000; i++)
            setContentView(R.layout.splash);*/
  
        // TIP: Splashscreen optional  (DONE)
        setContentView(R.layout.splash);
        Thread timer = new Thread() {
            public void run() {
                try {
                    sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                } finally {
                    Intent openStartingPoint = new Intent("com.logicdrop.todos.TodoActivity");
                    startActivity(openStartingPoint);
                }
            }
        };
        timer.start();
    }
}
  

ToDoActivity.java, shown in Listing 3-3, has many of the Android and Java optimizations mentioned in this chapter; see comments in the code for more information. It also shows how to stop and start profiling using the Traceview API.

Listing 3-3.   The ToDo List Application’s ToDoActivity.java page

package com.logicdrop.todos;
  
import java.util.List;
import java.util.ArrayList;
  
import android.app.Activity;
import android.os.Bundle;
import android.util.Log;
import android.view.View;
import android.view.View.OnClickListener;
import android.widget.AdapterView;
import android.widget.AdapterView.OnItemClickListener;
import android.widget.ArrayAdapter;
import android.widget.Button;
import android.widget.EditText;
import android.widget.ListView;
import android.widget.TextView;
import android.os.StrictMode;
  
import com.logicdrop.todos.R;
  
public class TodoActivity extends Activity
{
     public static final String APP_TAG = "com.logicdrop.todos";
  
     private ListView taskView;
     private Button btNewTask;
     private EditText etNewTask;
     private TodoProvider provider;
  
     // TIP: Use static/final where appropriate
     private final OnClickListener handleNewTaskEvent = new OnClickListener()
     {
          @Override
          public void onClick(final View view)
          {
               Log.d(APP_TAG, "add task click received");
  
               TodoActivity.this.provider.addTask(TodoActivity.this
                         .etNewTask
                                   .getText()
                                   .toString());
  
               TodoActivity.this.renderTodos();
          }
     };
  
    // TIP: Traceview
     @Override
     protected void onStop()
     {
          super.onStop();
  
          // Debug.stopMethodTracing();
     }
  
     @Override
     protected void onStart()
     {
        // Debug.startMethodTracing("ToDo");
  
          super.onStart();
     }
  
     // TIP: Use floats judiciously
     @SuppressWarnings("unused")
     private void showFloatVsIntegerDifference()
     {
          int max = 1000;
          float f = 0;
          int i = 0;
          long startTime, elapsedTime;
  
          // Compute time for floats
          startTime = System.nanoTime();
          for (float x = 0; x < max; x++)
          {
               f += x;
          }
          elapsedTime = System.nanoTime() - startTime;
          Log.v(APP_TAG, "Floating Point Loop: " + elapsedTime);
  
          // Compute time for ints
          startTime = System.nanoTime();
          for (int x = 0; x < max; x++)
          {
               i += x;
          }
          elapsedTime = System.nanoTime() - startTime;
          Log.v(APP_TAG, "Integer Point Loop: " + elapsedTime);
     }
  
     // TIP: Avoid creating unnecessary objects or memory allocation
     private void createPlaceholders()
     {
        // TIP: Avoid internal getters/setters
          provider.deleteAll();
  
          if (provider.findAll().isEmpty())
          {
            // TIP: Arrays are faster than vectors
               List<String> beans = new ArrayList<String>();
  
               // TIP: Use enhanced for loop (DONE)
               // This is example of the enhanced loop but don't allocate objects if not necessary
                  /*for (String task : beans) {
                     String title = "Placeholder ";
                    this.provider.addTask(title);
                    beans.add(title);
                  }*/
  
               /*for (int i = 0; i < 10; i++)
               {
                    String title = "Placeholder " + i;
                    this.getProvider().addTask(title);
                    beans.add(title);
               }*/
          }
     }
  
         // TIP: Avoid private getters/setters - consider using package (DONE)
     /*EditText getEditText()
     {
          return this.etNewTask;
     }*/
  
     /*private TodoProvider getProvider()
     {
          return this.provider;
     }*/
  
     /*private ListView getTaskView()
     {
          return this.taskView;
     }*/
  
     @Override
     public void onCreate(final Bundle bundle)
     {
        // TIP: Use Strictmode to detect unwanted disk or network access
        // Remove from production code (DONE)
        //StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
        //        .detectDiskReads()
        //        .detectDiskWrites()
        //        .detectNetwork()
        //        .penaltyLog()
        //        .build());
          super.onCreate(bundle);
  
             // TIP: Do not overuse Linearlayouts, as they become more complex (DONE)
             // Replace them with Relativelayouts, increasing UI loading speed
          this.setContentView(R.layout.main);
  
          this.provider = new TodoProvider(this);
          this.taskView = (ListView) this.findViewById(R.id.tasklist);
          this.btNewTask = (Button) this.findViewById(R.id.btNewTask);
          this.etNewTask = (EditText) this.findViewById(R.id.etNewTask);
          this.btNewTask.setOnClickListener(this.handleNewTaskEvent);
  
          this.renderTodos();
  
          // TIP: Again, don't allocate unnecessary objects that expand the heap size to significant proportions (DONE)
          // Once GC occurs, a large amount of the heap memory is dumped, especially with
          // local data structures, which renders a large portion of the heap unused.
          // SEE: optimizedHeap.png, deoptimizedHeap.png, heap-before.tiff, heap-after.tiff
          /*ArrayList<uselessClass> uselessObject = new ArrayList<uselessClass>();
          for (int i=0; i<180000; i++)
              uselessObject.add(new uselessClass());*/
     }
  
     private void renderTodos()
     {
          final List<String> beans = this.provider.findAll();
  
          Log.d(TodoActivity.APP_TAG, String.format("%d beans found", beans.size()));
  
          this.taskView.setAdapter(new ArrayAdapter<String>(this,
                    android.R.layout.simple_list_item_1,
                    beans.toArray(new String[]
                    {})));
  
          this.taskView.setOnItemClickListener(new OnItemClickListener()
          {
               @Override
               public void onItemClick(final AdapterView<?> parent, final View view, final int position, final long id)
               {
                    Log.d(TodoActivity.APP_TAG, String.format("item with id: %d and position: %d", id, position));
  
                    final TextView v = (TextView) view;
                    TodoActivity.this.provider.deleteTask(v.getText().toString());
                    TodoActivity.this.renderTodos();
               }
          });
     }
  
    // Class with 26 double data members used to expand heap size in example
    /*private class uselessClass {
        double a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z;
    }*/
}
  

Finally, ToDoProvider.java, shown in Listing 3-4, has examples of some of the remaining optimizations, such as always closing resources and only using SELECT statements to return a minimum of data.

Listing 3-4.   The ToDo List Application’s ToDoProvider.java Page

package com.logicdrop.todos;
  
import java.util.ArrayList;
import java.util.List;
  
import android.content.ContentValues;
import android.content.Context;
import android.database.Cursor;
import android.database.sqlite.SQLiteDatabase;
import android.database.sqlite.SQLiteOpenHelper;
import android.util.Log;
  
final class TodoProvider
{
     private static final String DB_NAME = "tasks";
     private static final String TABLE_NAME = "tasks";
     private static final int DB_VERSION = 1;
     private static final String DB_CREATE_QUERY = "CREATE TABLE " + TodoProvider.TABLE_NAME + " (id integer primary key autoincrement, title text not null);";
  
     // TIP: Use final wherever possible (DONE)
     private final SQLiteDatabase storage;
     private final SQLiteOpenHelper helper;
  
     public TodoProvider(final Context ctx)
     {
          this.helper = new SQLiteOpenHelper(ctx, TodoProvider.DB_NAME, null, TodoProvider.DB_VERSION)
          {
               @Override
               public void onCreate(final SQLiteDatabase db)
               {
                    db.execSQL(TodoProvider.DB_CREATE_QUERY);
               }
  
               @Override
               public void onUpgrade(final SQLiteDatabase db, final int oldVersion,
                         final int newVersion)
               {
                    db.execSQL("DROP TABLE IF EXISTS " + TodoProvider.TABLE_NAME);
                    this.onCreate(db);
               }
          };
  
          this.storage = this.helper.getWritableDatabase();
     }
  
     // TIP: Avoid synchronization (DONE)
     public void addTask(final String title)
     {
          final ContentValues data = new ContentValues();
          data.put("title", title);
  
          this.storage.insert(TodoProvider.TABLE_NAME, null, data);
     }
  
     public void deleteAll()
     {
          this.storage.delete(TodoProvider.TABLE_NAME, null, null);
     }
  
     public void deleteTask(final long id)
     {
          this.storage.delete(TodoProvider.TABLE_NAME, "id=" + id, null);
     }
  
     public void deleteTask(final String title)
     {
          this.storage.delete(TodoProvider.TABLE_NAME, "title='" + title + "'", null);
     }
  
     // TIP: Don't return the entire table of data. (DONE)
     // Unused
     public List<String> findAll()
     {
          Log.d(TodoActivity.APP_TAG, "findAll triggered");
  
          final List<String> tasks = new ArrayList<String>();
  
          final Cursor c = this.storage.query(TodoProvider.TABLE_NAME, new String[]
          { "title" }, null, null, null, null, null);
  
          if (c != null)
          {
               c.moveToFirst();
  
               while (c.isAfterLast() == false)
               {
                    tasks.add(c.getString(0));
                    c.moveToNext();
               }
  
               // TIP: Close resources (DONE)
               c.close();
          }
  
          return tasks;
     }
}

DDMS

In this section we’ll be covering the System Performance, Heap Usage, Threads, and Traceview tools, all of which come as part of DDMS. We’ll also look at the Memory Analyzer Tool (MAT), which can be downloaded as part of the Eclipse tool and used to report on how memory is being managed in the Heap.

Traceview

Once you’ve identified the methods to take a closer look at, you can use the command-line version of Traceview with the tracing API for more accurate measurement. Add Debug.startMethodTracing, and Debug.stopMethodTracing around the code you want to profile, as shown in Listing 3-5. Compile your code again and push the APK to your device.

Listing 3-5.   startMethodTracing and stopMethodTracing

public class ScoresActivity extends ListActivity {
        public void onStart() {
                // start tracing to "/sdcard/scores.trace"
                Debug.startMethodTracing("scores");
                super.onStart();
                // other start up code here
        }
  
        public void onStop() {
                super.onStop();
                // other shutdown code here
                Debug.stopMethodTracing();
        }
  
        // Other implementation code
}
  

The trace file can now be pulled off the device and displayed in Traceview using the following commands:

  
adb pull /sdcard/scores.trace scores.before.trace
  

Figure 3-11 shows the results before code optimization.

Optimize the code using some of the suggestions earlier in the chapter and measure again, this time using the following command:

  
adb pull /sdcard/scores.trace scores.after.trace
  

Figure 3-12 shows the results after optimization; the difference is clear.

Lint

Lint is, like its original Unix namesake, a static code-analysis tool. It replaces the layoutopt tool, which was used to analyze your layout files and point out potential performance issues to get quick performance gains by reorganizing your UI layout. It now does so much more, including the following error-checking categories:

• Correctness
• Correctness:Messages
• Security
• Performance
• Usability:Typography
• Usability:Icons
• Usability
• Accessibility
• Internationalization

If you run the command lint --list Performanceit will tell you that Lint does the following performance checks, many of which we’ve already seen in the Android Tips section:

• FloatMath: Suggests replacing android.util.FloatMath calls with java.lang.Math.
• FieldGetter: Suggests replacing use of getters with direct field access within a class.
• InefficientWeight: Looks for inefficient weight declarations in LinearLayouts.
• NestedWeights: Looks for nested layout weights, which are costly.
• DisableBaselineAlignment: Looks for LinearLayouts, which should set android:baselineAligned=false.
• ObsoleteLayoutParam: Looks for layout params that are not valid for the given parent layout.
• MergeRootFrame: Checks whether a root <FrameLayout> can be replaced with a <merge> tag.
• UseCompoundDrawables: Checks whether the current node can be replaced by a TextView using compound drawables.
• UselessParent: Checks whether a parent layout can be removed.
• UselessLeaf: Checks whether a leaf layout can be removed.
• TooManyViews: Checks whether a layout has too many views.
• TooDeepLayout: Checks whether a layout hierarchy is too deep.
• ViewTag: Finds potential leaks when using View.setTag.
• HandlerLeak: Ensures that Handler classes do not hold on to a reference to an outer class.
• UnusedResources: Looks for unused resources.
• UnusedIds: Looks for unused IDs.
• SecureRandom: Looks for suspicious usage of the SecureRandom class.
• Overdraw: Looks for overdraw issues (where a view is painted only to be fully painted over).
• UnusedNamespace: Finds unused namespaces in XML documents.
• DrawAllocation: Looks for memory allocations within drawing code.
• UseValueOf: Looks for instances of “new” for wrapper classes, which should use valueOf instead.
• UseSparseArrays: Looks for opportunities to replace HashMaps with the more efficient SparseArray.
• Wakelock: Looks for problems with wakelock usage.
• Recycle: Looks for missing recycle() calls on resources.

Lint can be run from within Eclipse or on the command line. If you just want to run the performance checks on your project, type lint --check Performance < ProjectName > on the command line. Listing 3-6 displays the output of this command for the sample application, showing that there are some layouts that need to be better organized.

Listing 3-6.   Lint Performance output for the CallCenterApp project

Scanning CallCenterV3: ...................................................
Scanning CallCenterV3 (Phase 2): ......................
reslayoutcustom_titlebar.xml:6: Warning: Possible overdraw: Root element paints background #004A82 with a theme that also paints a background (inferred theme is @style/CustomTheme) [Overdraw]
    android:background="#004A82"
    ∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼
reslayoutcustom_titlebar_with_logout.xml:6: Warning: Possible overdraw: Root element paints background #004A82 with a theme that also paints a background (inferred theme is @style/CustomTheme) [Overdraw]
    android:background="#004A82"
    ∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼
reslayoutcustom_titlebar_with_settings.xml:6: Warning: Possible overdraw: Root element paints background #004A82 with a theme that also paints a background (inferred theme is @style/CustomTheme) [Overdraw]
    android:background="#004A82"
    ∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼
reslayoutlogin_screen.xml:5: Warning: Possible overdraw: Root element paints background @drawable/bg_app with a theme that also paints a background (inferred theme is @style/CustomTheme) [Overdraw]
    android:background="@drawable/bg_app"
    ∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼
reslayoutqueues_screen.xml:5: Warning: Possible overdraw: Root element paints background @drawable/bg_app with a theme that also paints a background (inferred theme is @style/CustomTheme) [Overdraw]
    android:background="@drawable/bg_app"
    ∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼
reslayoutsettings_screen.xml:5: Warning: Possible overdraw: Root element paints background #1D1D1D with a theme that also paints a background (inferred theme is @style/CustomTheme) [Overdraw]
    android:background="#1D1D1D"
    ∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼
resdrawable-hdpig_login.9.png: Warning: The resource R.drawable.bg_login appears to be unused [UnusedResources]
resdrawable-hdpitn_ok_xlarge.png: Warning: The resource R.drawable.btn_ok_xlarge appears to be unused [UnusedResources]
resdrawable-hdpi
o_xlarge.png: Warning: The resource R.drawable.no_xlarge appears to be unused [UnusedResources]
resmenusettings_menu.xml: Warning: The resource R.menu.settings_menu appears to be unused [UnusedResources]
resvaluesstrings.xml:7: Warning: The resource R.string.loginMessage appears to be unused [UnusedResources]
    <string name="loginMessage">Enter Your Login Credentials</string>
            ∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼
resvaluesstrings.xml:8: Warning: The resource R.string.CSQ_default appears to be unused [UnusedResources]
    <string name="CSQ_default">Log In</string>
            ∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼
resvaluesstrings.xml:11: Warning: The resource R.string.default_time appears to be unused [UnusedResources]
    <string name="default_time">00:00:00</string>
            ∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼
resvaluesstrings.xml:12: Warning: The resource R.string.oldest_in_queue appears to be unused [UnusedResources]
    <string name="oldest_in_queue">Oldest Call In Queue: </string>
            ∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼
resvaluesstrings.xml:16: Warning: The resource R.string.add_to_queue appears to be unused [UnusedResources]
    <string name="add_to_queue">Add To Queue</string>
            ∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼
reslayoutlogin_screen.xml:9: Warning: This LinearLayout view is useless (no children, no background, no id, no style) [UselessLeaf]
    <LinearLayout
    ^
reslayoutcustom_titlebar.xml:10: Warning: This RelativeLayout layout or its LinearLayout parent is useless; transfer the background attribute to the other view [UselessParent]
    <RelativeLayout
    ^
reslayoutcustom_titlebar_with_logout.xml:10: Warning: This RelativeLayout layout or its LinearLayout parent is useless; transfer the background attribute to the other view [UselessParent]
    <RelativeLayout
    ^
reslayoutcustom_titlebar_with_settings.xml:10: Warning: This RelativeLayout layout or its LinearLayout parent is useless; transfer the background attribute to the other view [UselessParent]
    <RelativeLayout
    ^
reslayoutqueue_list_item.xml:13: Warning: This TableRow layout or its TableLayout parent is possibly useless [UselessParent]
        <TableRow
        ^
reslayoutqueue_list_item.xml:45: Warning: This TableRow layout or its TableLayout parent is possibly useless [UselessParent]
        <TableRow
        ^
reslayoutcustom_titlebar.xml:3: Warning: The resource R.id.photo_titlebar appears to be unused [UnusedIds]
    android:id="@+id/photo_titlebar"
    ∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼
reslayoutqueue_list_item.xml:7: Warning: The resource R.id.nameTable appears to be unused [UnusedIds]
        android:id="@+id/nameTable"
        ∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼
reslayoutqueue_list_item.xml:14: Warning: The resource R.id.tableRow1 appears to be unused [UnusedIds]
            android:id="@+id/tableRow1"
            ∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼
reslayoutqueue_list_item.xml:19: Warning: The resource R.id.activeIndicatorDummy appears to be unused [UnusedIds]
                android:id="@+id/activeIndicatorDummy"
                ∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼
reslayoutqueue_list_item.xml:46: Warning: The resource R.id.tableRow2 appears to be unused [UnusedIds]
            android:id="@+id/tableRow2"
            ∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼
reslayoutqueue_list_item.xml:62: Warning: The resource R.id.callsInQueueLabel appears to be unused [UnusedIds]
                android:id="@+id/callsInQueueLabel"
                ∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼
0 errors, 27 warnings
  
reslayoutqueue_list_item.xml:7: Warning: The resource R.id.nameTable appears to be unused [UnusedIds]
        android:id="@+id/nameTable"
        ∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼
reslayoutqueue_list_item.xml:14: Warning: The resource R.id.tableRow1 appears to be unused [UnusedIds]
            android:id="@+id/tableRow1"
            ∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼
reslayoutqueue_list_item.xml:19: Warning: The resource R.id.activeIndicatorDummy appears to be unused [UnusedIds]
                android:id="@+id/activeIndicatorDummy"
                ∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼
reslayoutqueue_list_item.xml:46: Warning: The resource R.id.tableRow2 appears to be unused [UnusedIds]
            android:id="@+id/tableRow2"
            ∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼
reslayoutqueue_list_item.xml:62: Warning: The resource R.id.callsInQueueLabel appears to be unused [UnusedIds]
                android:id="@+id/callsInQueueLabel"
                ∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼∼
0 errors, 27 warnings

Hierarchy Viewer

Another useful tool in debugging performance issues, specifically for layouts, is the Hierarchy Viewer. At its most basic it will show you how long it takes to inflate the layouts. You start Hierarchy Viewer from within Eclipse by adding the perspective; this is similar to the way you would add back DDMS if it ever disappeared.

Hierarchy Viewer first displays a list of devices and emulators; click the name of your app from the list and then click Load View Hierarchy. The Tree View, the Tree Overview, and the Tree Layout will then open, as shown in Figure 3-13. The Tree View shows all the layouts that you defined in your XML files. We talked earlier in this chapter about how nested layouts can be bad for performance, and Tree Overview is a great way to see just how nested your layouts have become and figure out if it’s time to merge them into a RelativeLayout. Tree View shows how long each layout took to display, so you can identify which views you need to debug and optimize to speed up your UI.

In Figure 3-13 we can see that our login view took almost 33ms to display. It also shows what layouts are part of the login view, and by hovering over specific views you can see just how long each took to display.

Hierarchy Viewer also includes a Pixel Perfect tool for designers. We won’t be covering that in this book.

Unix Tools

Because Android is built on Linux, we can leverage many of the same shell command tools as Linux for performance testing. The main tools focus on total process load, individual process details, and memory utilization.

  
adb shell dumpsys meminfo 1599
  

  
adb shell dumpsys procstats