假设让我又一次设计一款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。