若是让我从新设计一款Android App

开发工具的选择

开发工具我将选用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的左上角放一个返回按钮，这在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了吧，大部分都须要联网，从服务器请求数据，所以网络模模块必不可少。GitHub上的开源网络框架也特别多，我的认为可使用开源框架，目前我会选okHttp或者Volley，也许之后会有更好的网络框架出现。注意若是使用开源框架，则必需要阅读其源码，必须可以驾驭它，这样就不至于当bug出现时一筹莫展。固然还能够本身写网络模块，目前咱们的App网络模块就彻底是本身写的，这样的好处是本身熟悉所写的代码，当有bug时能够迅速定位问题，同时注意处理一些联网过程当中的细节，如：

（1）对HTTPS的支持、HTTPS证书的验证（目前不少作法都是默认容许全部HTTPS证书的，其实这样作是不安全的，应当真正地作证书校验）

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

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

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

本身写网络框架能够完美地处理这些细节，但时间成本比较大。若是使用开源框架，通常都没有处理这些细节，所以咱们能够在第三方框架上作些修改，这样时间成本将会节省不少。

2.图片管理模块

图片也是App中不可少的元素，并且图片是占用内存的大户，所以图片管理框架特别重要，很差的图片框架容易引发内存泄露甚至致使崩溃。固然能够本身实现图片框架（目前咱们也是这样作的），实现图片的下载、解码、缓存等关键环节。我的建议能够采用一些比较好的图片库，也许会比咱们本身管理图片更完善和高效。我会推荐以下几个图片管理库：

（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了，建议尽量地使用原生组件，少用自定义组件，由于原生组件性能是最好的。另外建议使用MVC模式就好，只要设计管理好本身的逻辑，至于MVP、MVVM等模式我的认为都有缺陷，总之寻求一个折中吧，有得必有失。

9.APK动态加载机制

随着App的增大，功能的扩展，不少App已经采用了APK动态加载的机制，也能够叫作插件化。因为本人没有在实际的App中应用过，因此不便发表过多评论。但这种机制我的认为颇有前途，这种机制将利于App的解耦、功能扩展和局部升级。具体能够参考一个商用的解决方案：ApkPlug-移动应用模块化解决方案和一个开源的APK动态加载框架。

10.App的安全性考虑

Android App的安全问题不多有人重视，但这的确是一个很严重的问题，一些好的App常常被人破解。建议将一些核心算法等写成.so库，重要的逻辑放在服务器端，数据请求采用加密等，另外打包APK时至少要混淆代码，还能够采用APK加壳机制，总之这类的防范措施永远不嫌多。

一口气漫无逻辑地写了这么多，可能会有遗漏的内容，后续会补充完善。我想若是按照上述原则，至少能够开发出一款不错的App。