Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

10 ways to improve your Android app performance

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Wird geladen in …3
×

Hier ansehen

1 von 55 Anzeige
Anzeige

Weitere Verwandte Inhalte

Diashows für Sie (20)

Anzeige

Ähnlich wie 10 ways to improve your Android app performance (20)

Aktuellste (20)

Anzeige

10 ways to improve your Android app performance

  1. 1. 10 ways to improve your Android app Boris Farber @borisfarber
  2. 2. ● Long launch time ● Janky scrolling ● Unresponsive app Data intensive apps
  3. 3. IF YOU HAVE A SMALL APP FORGET THESE SLIDES
  4. 4. 1 - Activity leaks
  5. 5. Activity
  6. 6. ● Holding references to unused Activity ● Activity holds its layout ⇒ holds all views
  7. 7. public class LeakActivity extends Activity { // ... @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); NastyManager.getInstance().addListener(this); // ... Listeners leak
  8. 8. @Override public void onDestroy() { super.onDestroy(); NastyManager.getInstance().removeListener(this); } Listeners leak + fix remove listener
  9. 9. ● Activities/fragments etc - they have a life cycle ● Activity will not be GC-ed ● Static references ○ become dangling "pointers" ○ m_staticActivity = staticFragment.getActivity() Static References
  10. 10. Activity
  11. 11. 2 - Activity leaks
  12. 12. Outer class (Activity) Inner class (Handler)
  13. 13. public class MainActivity extends Activity { // ... Handler handler; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); // ... handler = new Handler() { @Override public void handleMessage(Message msg) { } }; // ... This is a leak
  14. 14. handler.postDelayed(...) What happens if
  15. 15. private static class MyHandler extends Handler { private final WeakReference<MainActivity> mActivity; // ... public MyHandler(MainActivity activity) { mActivity = new WeakReference<MainActivity>(activity); // ... } @Override public void handleMessage(Message msg) { } // ... } This is a leak + fix
  16. 16. Outer class (Activity) Inner class (Handler)
  17. 17. ● Non static Handler → Activity leak ● Both classes have a different a different lifetimes Prefer static to non static inner classes
  18. 18. ● Remove away static references ● Use event bus ● Unregister listeners ● Prefer static inner classes to non static ones Avoid Activity leaks
  19. 19. ● Do code reviews ● Understand your app structure ● Use tools (MAT ...) ● Print logs on callbacks Avoid Activity leaks
  20. 20. 3 - Use UI thread only for UI
  21. 21. ● Scrolling Symptoms
  22. 22. ● Images ● Networking ● JSON ● Database access Not on UI thread
  23. 23. ● Images ● Networking ● JSON ● Database access Not on UI thread Use libraries Use Loaders
  24. 24. 4 - Use libraries
  25. 25. ● Already solve the problem ● Requires specialization (easy to make mistake) ○ Threading ○ Memory ○ Networking ○ Images Use libraries
  26. 26. ● Don’t lose focus ● Developer your solution for a good reason Use libraries
  27. 27. ● Volley ● OkHttp ● Retrofit Common libraries - Async Http
  28. 28. ● Glide ● Picasso ● Fresco ● UIL Common libraries - Image loading
  29. 29. ● Solves your problem ● Plays nicely with your current dependencies ● Dex method count ● Dependencies ● Maintenance ● Runtime permissions Pick 3rd party lib checklist
  30. 30. 5 - Large JSONs
  31. 31. ● Parsing has a performance effect ● Converted to class with getters and setters JSON
  32. 32. ● Small JSONs - GSON is the best ● Large JSONs ○ Jackson ○ ig-json-parser ○ GSON + immutables type adapters JSON
  33. 33. ● Keep UI thread only for UI ● Understand concurrency APIs ● Use libraries (memory, caching, json ...) ● Use loaders Scrolling
  34. 34. 6 - System abuse
  35. 35. ● Don't call private APIs by reflection ● Don't call private native methods (NDK/C level) ● Don't use Runtime.exec ● "adb shell am" to communicate with other process is not something we want to support System abuse
  36. 36. ● Don't abuse the system ● Know and use APIs System abuse
  37. 37. 7 - Deprecation
  38. 38. ● API will be removed ● Your app will not work ● No way to update APIs and tools Deprecation
  39. 39. ● There is a compelling reason to move ○ Security ○ Correctness ○ Performance Deprecation
  40. 40. ● Removed at M (still available as dependency) ● Use HttpURLConnection ○ Simple API ○ Small size ○ Transparent compression ○ Response caching Don’t use Apache Http Connection
  41. 41. ● Know and use APIs ● Refactor your dependencies ● Update your dependencies and tools Deprecation
  42. 42. 8 - Bring your own gloves
  43. 43. ● Various versions, devices, OEMs ● APIs and libraries shipped with platform might behave differently ● Async task ... Bring your own gloves
  44. 44. ● Consider bundling your own version ● Check dex limit ● Check code bloat Bring your own gloves
  45. 45. ● Own wrapped library (SSL/crypto etc') ● Rooted devices ● Your own sensitive data/protocols Security
  46. 46. 9 - Architecture
  47. 47. ● Activities ● Fragments ● Tasks ● Flags ● Add logs on callbacks Understand app components life cycle
  48. 48. ● Consistent ● Get people on board quickly ● Have someone experienced ● Pick your dependencies wisely What can you do
  49. 49. ● Sleeping most of the time ● Responsive when “awaken” Design your app
  50. 50. 10 - Know your APK
  51. 51. ● https://goo.gl/94woV7 ● Executables browser ● Innovation comes from frustration ClassyShark
  52. 52. tree view detail view
  53. 53. ● Dex limit numbers ● Obfuscation ● Package counts ● Why I need the dependency Know your executable
  54. 54. ● https://medium.com/@BorisFarber/ ● https://medium.com/@_tiwiz/shrinking-your-build-with-no-rules- 8d9fb88281ac#.j0gb0lf8i Learn more
  55. 55. #ClassyShark Boris Farber @borisfarber Thank You!

×