android商业软件开发全程实战 源码-android项目实战手机安全卫士开发案例解析

图片加载框架：Android-Universal-Image-Loader、Glide、Fresco、Picasso

缓存框架：DiskLruCache、Robospice

Json解析框架：Gson、Fastjson、Jackson

事件总线：EventBus、Otto

ORM框架：GreenDAO、Litepal

还有各种其他开源自定义控件、动画等。 除了上面提到的开源框架，还有一些非开源的SDK

统计：友盟统计、百度统计...

崩溃合集：腾讯bugly、bugtags...

云存储：七牛...

偶通：欢欣、融云、阿里百川……

推送：小米推送、腾讯推送、百度推送……

安全加固：360加固宝，爱加密...

一般来说，我选择是否引入一些开源框架是基于以下几个因素：

选择非开源SDK主要基于以下考虑：

进入友盟APP

总结：选“轮”事半功倍

3.抽象依赖第三方框架

为什么抽象要依赖第三方框架？ 这里和第一点是相互呼应的，就是减少我们对某个特定框架的依赖，方便我们快速切换到不同的框架。 说到这里，大家可能觉得很抽象，那我就举个加载图片的例子吧。

假设你目前在你的项目中引入了一个加载图片的框架——Android-Universal-Image-Loader，最简单的方法就是添加相应的依赖包，在需要加载图片的地方编写如下代码段。

ImageLoader imageLoader = ImageLoader.getInstance(); // Get singleton instance
// Load image, decode it to Bitmap and display Bitmap in ImageView (or any other view 
//  which implements ImageAware interface)
imageLoader.displayImage(imageUri, imageView);
// Load image, decode it to Bitmap and return Bitmap to callback
imageLoader.loadImage(imageUri, new SimpleImageLoadingListener() {
    @Override
    public void onLoadingComplete(String imageUri, View view, Bitmap loadedImage) {
        // Do whatever you want with Bitmap
    }
});

这种做法最简单粗暴，但也带来了最严重的问题。 如果我在几十个、几百个地方都这样写，有一天，听说Facebook出了一个神器Fresco，想替换Android-Universal-Image-Loader，你会发现你要疯狂改几十个几百处的代码，不仅工作量大，而且容易出错。 这样做的原因是项目和加载图片的框架之间存在强耦合。 其实项目本身应该不知道我是用哪个框架来加载图片的。

正确的做法应该是对框架进行抽象封装，以应对未来的变化。 我直接引用我的开源项目AndroidAlbum中的一个封装方法。

安卓相册

一般代码如下：

//1、声明 ImageLoaderWrapper 接口，定义一些抽象的加载接口方法
public interface ImageLoaderWrapper {
    /**
     * 显示 图片
     *
     * @param imageView 显示图片的ImageView
     * @param imageFile 图片文件
     * @param option    显示参数设置
     */
    public void displayImage(ImageView imageView, File imageFile, DisplayOption option);
    /**
     * 显示图片
     *
     * @param imageView 显示图片的ImageView
     * @param imageUrl  图片资源的URL
     * @param option    显示参数设置
     */
    public void displayImage(ImageView imageView, String imageUrl, DisplayOption option);
    /**
     * 图片加载参数
     */
    public static class DisplayOption {
        /**
         * 加载中的资源id
         */
        public int loadingResId;
        /**
         * 加载失败的资源id
         */
        public int loadErrorResId;
    }
}
// 2、将 UniversalAndroidImageLoader 封装成继承 ImageLoaderWrapper 接口的 UniversalAndroidImageLoader ，
//这里代码有点长，感兴趣可以查看项目源码中的实现 https://github.com/D-clock/AndroidAlbum
// 3、做一个ImageLoaderFactory
public class ImageLoaderFactory {
    private static ImageLoaderWrapper sInstance;
    private ImageLoaderFactory() {
    }
    /**
     * 获取图片加载器
     *
     * @return
     */
    public static ImageLoaderWrapper getLoader() {
        if (sInstance == null) {
            synchronized (ImageLoaderFactory.class) {
                if (sInstance == null) {
                    sInstance = new UniversalAndroidImageLoader();//https://github.com/nostra13/Android-Universal-Image-Loader
                }
            }
        }
        return sInstance;
    }
}
//4、在所有需要加载图片的地方作如下的调用
ImageLoaderWrapper loaderWrapper = ImageLoaderFactory.getLoader();
ImageLoaderWrapper.DisplayOption displayOption = new ImageLoaderWrapper.DisplayOption();
displayOption.loadingResId = R.mipmap.img_default;
displayOption.loadErrorResId = R.mipmap.img_error;
loaderWrapper.displayImage(imagview, url, displayOption);

这样一来，切换框架的代价就会变得很小，这就是不直接依赖框架的好处。 当然以上只是我比较简单的封装，大家还可以进行更细化的处理。

总结：保留改动，不与第三方框架强耦合

4.从MVC到MVP

说实话，在接触MVP架构之前，我一直都是采用MVC模式进行开发。 而且随着项目越来越大，Activity或者Fragment中的代码越来越臃肿，看着就恶心，改了就想拉屎。。。其他各种架构先抛在这里，我只比较MVC和MVP。

MVC

你会发现，如果View层只包含xml文件，那么我们的Android项目对View层的操作并不多。 我们顶多用include来重用布局。 Activity之类的简直就是一个奇怪的东西。 虽然属于Controller层，但实际上做的是View层的工作（View的初始化和相关操作都在Activity中）。 正是这种既是View又是Controller的结构，违背了单一职责原则，也造成了Activity中的上述臃肿问题等等。

最有价值球员

与MVC相比，MVP在层级划分上更加清晰，不会出现一人两份的情况（有单元测试的童鞋会发现单元测试用例写的更好）。 这里可以看出View和Model并不知道彼此的存在，这样更有利于处理变化。 很多时候是View层的变化，而Model层的变化会比较小，按照MVP的架构开发好之后，再改代码就没那么痛苦了。

这里也有需要注意的地方android商业软件开发全程实战 源码，因为大量的交互操作都集中在Presenter层，所以需要把握好Presenter的粒度。 一个Activity可以持有多个View和Presenter，这样就可以避免一个庞大的View和Presenter上去的问题。

给大家推荐两个不错的MVP架构项目。 不懂的童鞋可以自己体会一下他们的设计思路：

总结：在实践中理解 MVP

5.存档代码

整理一些常用的工具类或业务流程代码android商业软件开发全程实战 源码，添加到自己的代码库中（如果没有自己的个人代码仓库可以考虑自己建一个）。 如加解密、拍照、裁剪图片、获取系统所有图片的路径、自定义控件或动画等常用工具。 归档有助于提高你的开发效率，遇到新项目时可以方便的引入和使用。 如果你想更好地维护自己的代码库，不妨在不泄露公司机密的情况下，将这个带有详细文档的私有代码库开源。 这样可以吸引更多的开发者使用这些代码，也可以获得相应的bug反馈，从而定位和修复问题，增强本仓库代码的稳定性。

总结：合理归档代码，可能的话开源维护

6.性能优化

关于性能优化，我们一般关注那些方面：内存、CPU、功耗、卡顿、渲染、进程存活率等。至于这些地方的性能优化思路和分析方法，网上已经有很多答案，所以我不会在这里重复它们。 我只想说以下几点：

总结：合理优化，数据量化

7.实践新技术

Rxjava、React Native、Kotlin……兴起之后，周围的很多开发者都会效仿。 学习新技术的精神是很鼓舞人心的，但是没有经过一段时间的实践观察就把新技术引入商业项目是不合适的。 对于大公司的团队，会有专门的团队或项目来研究这些新兴技术，以确定是否将其引入到自己的产品线开发中。 但是作为一家小公司，是否意味着没有机会去实践和尝试新技术呢？ 不是！ 我个人有以下建议：

总结：空谈害国，实干兴邦

8. 统一机器语言

UML，一个驯服代码和理解项目结构的强大工具，我也在学习和体验它的好处的路上。 不管项目大小，有了它，你可以更好的梳理一些上下文结构。 对付陈旧庞大的项目代码，或者有兴趣阅读一些开源项目代码的开发者，绝对是居家必备。

总结：工欲善其事，必先利其器

9.自制“轮子”

上面2中提到，一个项目不可能从0开始，需要引入很多第三方框架。 这与2并不矛盾，但是建议想提升技能的开发者可以在业余时间编码实现一个框架。 如果你对网络访问和图片加载有研究见解，不妨将脑海中的这些想法实现成具体的代码。 也许你会发现，当你开始修行的时候，你会考虑更多的东西，最后你会得到更多。 （特别推荐给看过很多开源代码，但还没有自己发布的朋友）

总结：不要停留在api调用的层面

10.拓展技术圈

有空又买得起的时候，不妨去参加一些自己感兴趣的技术交流会，很多都有大牛上台演讲，听听别人的解决方案，拓宽自己对问题的思考，多参与含金量高的线上活动。 我在参加活动时结识了很多开发者朋友。 有时候遇到一些技术上的问题，我会互相讨论，交流思路，寻求解决方案。 非常好！

总结：拓宽技术视野

11.写一篇博客总结

这个可能没什么好说的，但是大家看完标题就明白了。 它最大的优点是：

总结：认真总结，不断提高

12.找人

程序员应该停止一直盯着电脑，找个人提高自己的幸福感。 都说幸福感高的程序员，编码效率高，出bug的几率小……

总结：做一个面向对象的程序员

能想到的就这么多了，以后想写更多的话，再开新篇章。 东拉西扯写了这么多，最重要的还是自己去实现。 听了太多的道理，还是过不好的日子！ ！ ！ ！