构建Android 应用时一定要绕过的35个坑

世界上有两种人，一种人靠跳坑来学习，一种人学习是为了绕过别人跳过的坑。这里我分享一下一路上跳过的坑以及所得的经验。

1、在添加任何一个第三方库之前，请三思而后行，这很重要；

2、如果用户都看不到，请不要浪费时间，内存和CPU去画出来。

3、数据库能不用则不用

4、遇到65k方法限制是迟早的事（“65k方法限制”指程序代码的总方法数超过goole规定的65535个方法，原因是Android对dex进行优化的工具DexOpt会把每一个方法id存在一个链表中，链表长度是用一个short类型保存，导致方法id数不能超过65536个）。只有MultiDex能救你。（Multidex是指将该dex文件拆成两个或多个，为此谷歌官方推出了multidex兼容包，在Android studio可以实现了一个APK包含多个dex）。

5、RxJava是处理异步任务最好的选择，没有之一。

6、Retrofit是最好用的网络请求库。

7、要精简代码请使用Retrolambda （指lambda语法，个人认为不建议去学，代码是精简了，对于不会lanbda的人来说可读性不强）。

8、RxJava + Retrofit + Retrolambda ==无敌

9、Eventbus不错，但我只是偶尔用。用多了会使代码库变得一团糟。

10、按功能分包，而不是按层。

11、把所有东西（耗时的后台操作）从主线程移开。

12、使用lint检查你的视图，以便优化布局和层次结构，确定那些可能需要被删除的冗余视图。

13、使用gradle的话，尽你所能去加速它。

14、建立构建分析报告，以便清楚哪里花费了构建时间。

15、使用知名的架构。

16、测试是需要时间，但只要你掌握了窍门，比敲代码不测试要快并且稳定很多。

17、使用依赖的方式注入，使程序更模块化，也更容易测试。

18、去听Fragmented podcast吧，成就一个牛逼的你。

19、绝不用个人邮箱作为安卓市场的应用发布账号。

20、使用合适的输入类型。

21、使用分析工具去发现使用模板和隔离的bug

22、关注最新的 libraries（使用dryrun 来快速查看它们的的效果）。

23、Service只需做他们需要做的，做完就摧毁它。

24、使用账号管理器来提示登录用户名和邮箱

25、使用CI（持续集成）建立和分发您的beta版本及apk应用；

26、不要自己去跑一个CI服务器，维护服务器非常耗时，因为磁盘空间/安全问题/更新服务器防范SSL攻击等。使用 circleci, travis或者shippable。便宜且省心。

27、使部署到playstore的流程自动化。

28、不要为了一小部分功能而使用一个巨大的库，你可以试着找一个小一点的（比如依赖Proguard）

29、不要使用多于实际需要的module。如果模块并非经常修改，重新编译一个module或者仅仅是检查上个module是否最新所需要的时间几乎是加载 binary 、jar/、aar依赖的4倍以上；

30、考虑用SVG来替代PNG ；

31、使库中的类抽象化，这样在你需要的时候可以很容易的转换成一个新的库（比如AppLogger.d(“message”) 能包含 Log.d(TAG, message) ，并且随后实现 Timber.d(message) 也是一个好选择）。

32、监控你的连接情况以及连接类型（比如有wifi时是否更新更多数据）。

33、监控你的电源和电量（比如是否在充电的时候更新更多的数据，电量低的时候是否需要暂停更新）；

34、用户界面就如笑话一样，如果你需要解释，说明它不够好；

35、测试非常有利于性能：慢而正确的实现功能，然后验证优化。有了测试，这一切将得到保证。

以下是英文原文：

Building Android Apps — 30 things that experience made me learn the hard way

There are two kinds of people — those who learn the hard way and those who learn by taking someone’s advice. Here are some of the things I’ve learned along the way that I want to share with you:

1.Think twice before adding any third party library, it’s a really serious commitment;
2.If the user can’t see it, don’t draw it !;
3.Don’t use a database unless you really need to;
4.Hitting the 65k method count mark is gonna happen fast, I mean really fast! And multidexing can save you ;
5.RxJava is the best alternative to AsyncTasks and so much more ;
6.Retrofit is the best networking library there is;
7.Shorten your code with Retrolambda ;
8.Combine RxJava with Retrofit and Retrolambda for maximum awesomeness!;
9.I use EventBus and it’s great, but I don’t use it too much because the codebase would get really messy;
10.Package by Feature, not layers ;
11.Move everything off the application thread;
12.lint your views to help you optimize the layouts and layout hierarchies so you can identify redundant views that could perhaps be removed;
13.If you’re using gradle , speed it up anyway youcan;
14.Doprofile reports of your builds to see what is taking the build time;
15.Use a well known architecture;
16.Testing takes time but it’s faster and more robust than coding without tests once you’ve got the hang of it ;
17.Use dependency injection to make your app more modular and therefore easier to test;
18.Listening to fragmented podcast will be great for you;
19.Never use your personal email for your android market publisher account ;
20.Always use appropriate input types;
21.Use analytics to find usage patterns and isolate bugs;
22.Stay on top of new libraries (use dryrun to test them out faster);
23.Your services should do what they need to do and die as quickly as possible;
24.Use the Account Manager to suggest login usernames and email addresses;
25.Use CI (Continuous Integration) to build and distribute your beta and production .apk’s;
26.Don’t run your own CI server, maintaining the server is time consuming because of disk space/security issues/updating the server to protect from SSL attacks, etc. Use circleci, travis or shippable, they’re cheap and it’s one less thing to worry about;
27.Automate your deployments to the playstore;
28.If a library is massive and you are only using a small subset of its functions you should find an alternative smaller option (rely on proguard for instance);
29.Don’t use more modules than you actually need. If that modules are not constantly modified, it’s important to have into consideration that the time needed to compile them from scratch ( CI builds are a good example), or even to check if the previous individual module build is up-to-date, can be up to almost 4x greater than to simply load that dependency as a binary .jar/.aar.
30.Start thinking about ditching PNGs for SVGs ;
31.Make library abstraction classes, it’ll be way easier to switch to a new library if you only need to switch in one place (e.g. AppLogger.d(“message”) can contain Log.d(TAG, message) and later realise that Timber.d(message) is a better option);
32.Monitor connectivity and type of connection ( more data updates while on wifi ?);
33.Monitor power source and battery ( more data updates while charging ? Suspend updates when battery is low ?);
34.A user interface is like a joke. If you have to explain it, it’s not that good;

35.Tests are great for performance: Write slow (but correct) implementation then verify optimizations don’t break anything with tests .