假设让我又一次设计一款Android App

转载请注明出处：

本文来自aspook的博客：http://blog.csdn.net/ahence/article/details/47154419

开发工具的选择

开发工具我将选用Android Studio，它是Google官方指定的Android开发工具。眼下是1.2.2稳定版，1.3的预览版也已经公布了。

Android Studio的长处就不需多说了。GitHub上大部分的Android开源库也都已迁移到Android Studio上来。在未提供jar文件时，使用Android Studio能够极为方便地集成开源库。

最为重要的是Google已宣布将在年底前停止对Eclipse Android开发工具的一切支持（Google
Ends Support for Android Eclipse Tools）。因此请早日转移到Android Studio上来。

App设计风格

这一点对于一个开发人员来说。貌似没有决定权，终于的决定权在产品部门手里。虽然这样，我还是会尽力说服产品部门将App设计成Material Design风格。这一点说多了都是泪啊，作为一个Android开发人员，却整天开发着iOS风格的App，相信非常多公司都这样，为了节省成本和时间。Android和iOS共用一套UI。举一个最常见的样例，Android App中每一个页面TitleBar的左上角放一个返回button。这在iOS里是必须的，但Android有返回键啊，这样设计对于Android全然是多此一举。真心希望产品设计者尊重每种操作系统的风格及使用习惯，不要再设计不伦不类的产品。Material Design正好提供了一种这种规范，自MD规范公布以来，其优雅的设计和清新的风格已吸引了大批设计者和开发人员，现在MD设计不止在Android上（已有官方类库支持MD风格），甚至在CSS、HTML、JavaScript网页设计上都越来越火。因此，对于App的设计风格，Material Design当仁不让，或许你以前错过了Android Design，请不要再错过Material
Design。

一些相关的链接：

Material Design官网

Material Design配色模板

MD一个设计案例站点

MD风格的Andorid抽屉源代码：Android-MaterialDesign-NavigationDrawer

MD风格的一个App源代码（有妹子哦）：Android-MaterialDesign-DBMZ

版本号支持

对于Android要支持的最低版本号，能够參考各个版本号的市场占有率。事实上最靠谱的是依据自家App的统计数据来决定。眼下我们的App最低支持2.2。

以个人观点觉得，尽管2.x的版本号仍然有一部分用户，但事实上手机更新换代特别快，为了更好的用户体验。也为了应用更新的API（非常多第三方库也都有版本号要求）。应该提高最低支持的版本号，大概3.0为宜，即API Level为11。

App框架设计

相信大家都有体会，随着功能模块的添加，App越来越大，假设没有良好的架构设计。则代码将会变得臃肿且不易维护。各功能模块的耦合度会越来越高。

因此能够把App模块化，将一个完整的App划分成几个相对独立的模块，这样即能够减少模块间的耦合也利于复用。

1.网络模块

已经非常少有单机版的App了吧，大部分都需要联网。从server请求数据，因此网络模模块不可缺少。GitHub上的开源网络框架也特别多，个人觉得能够使用开源框架，眼下我会选okHttp或者Volley。或许以后会有更好的网络框架出现。注意假设使用开源框架，则必需要阅读其源代码，必须能够驾驭它，这样就不至于当bug出现时束手无策。当然还能够自己写网络模块。眼下我们的App网络模块就全然是自己写的。这种优点是自己熟悉所写的代码，当有bug时能够迅速定位问题，同一时候注意处理一些联网过程中的细节，如：

（1）对HTTPS的支持、HTTPS证书的验证（眼下非常多做法都是默认同意全部HTTPS证书的，事实上这样做是不安全的，应当真正地做证书校验）

（2）支持Wap方式上网，移动、联通、电信代理的设置

（3）支持重定向、数据压缩传输等

（4）其它值得注意的问题

自己写网络框架能够完美地处理这些细节，但时间成本比較大。

假设使用开源框架，一般都没有处理这些细节，因此我们能够在第三方框架上做些改动，这样时间成本将会节省非常多。

2.图片管理模块

图片也是App中不可少的元素，并且图片是占用内存的大户。因此图片管理框架特别重要。不好的图片框架easy引起内存泄露甚至导致崩溃。当然能够自己实现图片框架（眼下我们也是这样做的），实现图片的下载、解码、缓存等关键环节。

个人建议能够採用一些比較好的图片库，或许会比我们自己管理图片更完好和高效。我会推荐例如以下几个图片管理库：

（1）Glide，Google的一些官方App。如Google photos都使用了。还要解释很多其它吗？

（2）Fresco，FaceBook的开源库，功能超级强大，支持WebP、Gif、JPEG渐进显示。关键是其对图片内存的设计思想，使得图片内存开销大大降低。

（3）Android-Universal-Image-Loader，在出现上述图片库之前，貌似这个最火吧，之前个人的App中也用了它。

（4）Picasso，Square的开源库。据说Glide就是參考Picasso设计的。

3.本地数据库模块

或许你的App须要用到本地数据库。那么建议你採用流行的ORM框架，如ActiveAndroid或greenDAO，使用第三方库会大慷慨便你对sqlite的操作，个人觉得在使用中我们须要注意数据库升级以及多线程并发操作数据库的问题。

4.文件管理模块

一个App。肯定会涉及到一些文件。如配置文件、图片、视频、音频、SharedPreferences文件等。我们能够提供一个全局的文件管理模块，负责文件的增、删、改、查等操作。另外还需支持文件压缩。文件的上传与下载操作，对于下载须要支持多线程并发下载、断点续传等功能。

5.组件内、组件间通信机制

对于一个App，组件通信不可缺少，通信类型能够分为点对点和点对面的的通信，点对点即仅仅有唯一的接收者能够响应消息，点对面则类似于消息广播。即全部注冊过的都能够响应消息。在Android中，通常使用消息机制来实现，但消息机制的耦合度比較高。眼下也有一些通信框架，如EventBus、Otto等事件总线框架，这些框架能够极大地减少组件间的耦合，但无法完美地实现点对点通信，因此建议消息机制和事件总线机制结合使用。

6.数据处理框架

事实上还应该有一个数据处理框架，当发出数据请求后（走子线程），经网络模块返回数据（一般为JSON格式），JSON数据一般不能直接交给View层使用，须要解析成相应的Model，同一时候如有须要，还要缓存数据，因此这些流程能够抽象成一个数据处理的框架。这个框架能够觉得接受数据请求的url。并将数据Model返回给Activity或Fragment。

对于JSON数据解析。建议使用fastjson。速度快且稳定，缺省值也比較完好。

7.线程调度模块

事实上Android中有非常多操作，如请求数据、下载图片、清除缓存等都是须要在子线程中运行的，往往非常多时候都是直接起一个Thread来做了，这样做就会非常乱并且线程多了将难以管理。因此能够抽象出一个线程调度模块。它维护一个线程池，假设有须要线程的话就通过线程调度模块取线程来做，这样就方便统一管理。

当然第三方库中的线程操作我们将无法归到线程调度模块来管理，但其它涉及到线程的操作都应该来统一处理（实际上眼下大多数第三方库都自带线程池，建议尽可能地使用统一的线程池，以减小开销）。

8.业务层

业务层大概就是四大组件、Fragment、View了。建议尽可能地使用原生组件，少用自己定义组件，由于原生组件性能是最好的。至于各种层出不穷的架构，如MVP、MVVM等，以及经典的MVC，事实上每种架构都并不是十全十美。都有适用的场景。因此这里不会厚此薄彼，不论什么一种架构仅仅要用得好都没问题。

9.APK动态载入机制

随着App的增大。功能的扩展，非常多App已经採用了APK动态载入的机制，也能够叫做插件化。因为本人没有在实际的App中应用过，所以不便发表过多评论。

但这样的机制个人觉得非常有前途，这样的机制将利于App的解耦、功能扩展和局部升级。详细能够參考一个商用的解决方式：ApkPlug-移动应用模块化解决方式和一个开源的APK动态载入框架。

10.App的安全性考虑

Android App的安全问题非常少有人重视，但这的确是一个非常严重的问题。一些好的App常常被人破解。

建议将一些核心算法等写成.so库。重要的逻辑放在server端。数据请求採用加密等，另外打包APK时至少要混淆代码，还能够採用APK加壳机制。总之这类的防范措施永远不嫌多。

一口气漫无逻辑地写了这么多，可能会有遗漏的内容，兴许会补充完好。

我想假设依照上述原则，至少能够开发出一款不错的App。