Android模块化设计方案之使用代理模式解耦

Android模块化设计方案系列文章：

成都创新互联公司专注于新华企业网站建设,成都响应式网站建设公司,商城网站制作。新华网站建设公司,为新华等地区提供建站服务。全流程定制设计，专业设计，全程项目跟踪，成都创新互联公司专业和态度为您提供的服务

1、 Android模块化设计方案模型图

2、 Android模块化设计方案之接口API化

3、 Android模块化设计方案之使用代理模式解耦

本篇是Android模块化设计方案的第三篇，也是对 第一篇 中ThridLibs Proxy模块进行说明。

很多人觉得对那些优秀的第三方依赖库再次封装是一件多余的事情，因为这些库可能出自大神/大厂，或有非常高的star并且使用起来十分稳定，可以在项目中直接拿来使用。当然每个开发者都有自己的态度，我也只是根据以往的经验，表达一下自己的看法。

作为从了解四大组件就不愁找不到工作的互联网大时代中一路走来的Android老鸟，经历了网路请求框架从HttpConnection到Volley再到OkHttp，也经历了图片加载框架从UniversalImageLoader到Picasso再到Gilde，技术的迭代随时都会发生。让项目架构具有良好的扩展性是在设计之初就需要考虑的东西。

那么接下来我用一个简单的demo来演示一下如何使用代理模式对第三方框架进行解耦。

现在我们有一个名为 thirdlib 的模块，为我们提供图片加载功能。

第一步：我们创建了一个新的模块 thridlibproxy ，并且该模块依赖于 thirdlib ，我们在该模块中创建包私有的接口ImageLoaderInterface，这个接口中把thirdlib模块中提供的功能抽象为接口：

第二步：创建包私有的接口的实现类ImageLoaderOneImpl，类中图片加载的业务逻辑是通过调用 thirdlib 中的ImageLoader类实现的：

第三步：我们提供一个供外部调用的ImageLoaderOneImpl接口代理类ImageLoaderProxy：

最后我们就可以通过ImageLoaderProxy中提供的loadImage方法进行图片的加载了。

看到这里有些盆友就会问了，在第二步的时候，我们就完成了 thirdlib 的封装工作，为什么还要有第三步？还有我写一个单例类直接对 thirdlib 进行封装不就行了，为什么还要抽象出接口？

原因很简单，为的就是尽可能的满足软件设计七大原则中的第一个： 开闭原则 。

一个好的软件设计，需要对拓展开放，对修改关闭。我们在设计之初就要想到，在更换图片加载框架之后如何最大程度上满足开闭原则。

如果直接对 thirdlib 进行封装，是面向类的开发而不是面向接口。如果此时更换图片加载类库，那必然会对封装出来的类进行大量的修改，把原来的实现替换为新的实现。

使用代理模式的好处就是，我新创建一个被代理的类ImageLoaderTwoImpl：

然后只需要对第三步中的被代理类进行替换就行了。

在想要达到相同效果的时候，最大程度的满足了开闭原则。

我们业务层模块也和第三方库实现了完全的解耦，我不需要知道 thridlibproxy 是如何帮我完成图片加载工作的，但是只要调用它提供的方法就完事儿的，这也符合软件设计七大原则中的： 最少知道原则 。

关于为何以及怎么通过代理调用第三方依赖库，到这里就介绍完毕了，赶快动手试试吧~

我只想说： 原则是死的，人是活的????

如果觉得有收获的话，欢迎点赞评论以及关注~

Android后台进程保活方案

思想： 使用 Linux 中的 fork 机制创建 Native 进程，在 Native 进程中监控主进程的存活，当主进程挂掉后，在 Native 进程中立即对主进程进行拉活。

原理： 在 Android 中所有进程和系统组件的生命周期受 ActivityManagerService 的统一管理。Android5.0以下通过 Linux 的 fork 机制创建的进程为纯 Linux 进程，其生命周期不受 Android 的管理。

该方案主要适用于 Android5.0 以下版本手机。

该方案不受 forceclose 影响，被强制停止的应用依然可以被拉活，在 Android5.0 以下版本拉活效果非常好。

详情

对于 Android5.0 以上手机，系统虽然会将native进程内的所有进程都杀死，这里其实就是系统“依次”杀死进程时间与拉活逻辑执行时间赛跑的问题，如果可以跑的比系统逻辑快，依然可以有效拉起。在 某些 Android 5.0 以上机型有效。

详情

作者5.0以下系统用一个java进程和一个fork出来的纯native进程双管道互锁监听对方的状态，无论哪个被杀后都拉起第三个进程，第三个进程来拉活常驻进程，实现拉活。

5.0以上同一进程组的进程会被同时杀死，所以5.0以上使用双java进程在native层互锁文件实现监听，但任务管理器会在短时间内杀死所有进程，只能用反射提前初始化pacel，在进程被杀的时候和系统抢那几十毫秒的时间发送一个拉活的广播。用4个文件来让两个进程实现互锁来做监听，但实际效果很一般，测试了几个5.0以上的国产机型都不行，效果是根本监听不到进程被杀，目测原因是当任务管理器查杀进程的时候将所有的进程都挂起了，随后全部杀掉，并在一段时间内禁止进程启动。

PersistedJobService.java

BootReceiver.java静态注册BroadcastReceiver

注册，开机，网络切换、拍照、拍视频时候，利用系统产生的广播也能唤醒app，不过Android N已经将这三种广播取消了

常用的拉活权限

BackgroundService.java

WakeLock

作为前台应用运行，提高应用存活几率

service被关掉后自动启动

START_STICKY

如果系统在onStartCommand返回后被销毁，系统将会重新创建服务并依次调用onCreate和onStartCommand（注意：根据测试Android2.3.3以下版本只会调用onCreate根本不会调用onStartCommand，Android4.0可以办到），这种相当于服务又重新启动恢复到之前的状态了）。

START_NOT_STICKY

如果系统在onStartCommand返回后被销毁，如果返回该值，则在执行完onStartCommand方法后如果Service被杀掉系统将不会重启该服务。

START_REDELIVER_INTENT

START_STICKY的兼容版本，不同的是其不保证服务被杀后一定能重启。

service注册，权限设置为高优先级

KeepAliveService.java

注册，在新的独立进程内启动，适用5.0以下的原生系统，5.0以上同样会被杀死

他的局限性在于：

第一，用户会在系统设置的账户列表里面看到一个不认识的账户；

第二，同步的事件间隔是有限制的，最短1分钟，见源码，如果小雨60秒，置为60秒。而且各种国产机怎么改的源码我们未可知，是不是都能用仍然未可知；

第三，很致命，某些手机比如note3需要手动设置账户，你如何骗你的用户给你手动设置账户完了之后不卸载你；

第四，也很致命，必须联网！google提供这个组件是让你同步账户信息，不联网你同步个鬼，我们要保活，可以不联网不做事，但是不能不联网就死

集成三方推送平台sdk，友盟极光等

总结 - Android UI适配方案

1、最原始的dp+自适应布局+weight，多套dimens.xml

缺点：只能满足90%以上的手机，同一像素的手机，dpi不一样

2、smallestWidth适配,res 文件夹下创建各种屏幕分辨率对应的 values-sw{xxx}dp 文件夹

缺点: 1、包会增加500kb左右

2、只支持3.2及以上的系统

3、AutoSize今日头条屏幕适配方案

当前设备屏幕总宽度（单位为像素）/ 设计图总宽度（单位为 dp) = density

原理：调用Android API，根据设备某一维度（宽或高）的真实长度（单位是px）与这一维度在UI设计图上的dp值之间的关系，重新计算density来实现

缺点: 第三方库适配

Android保活方案

系统出于性能和体验上的考虑，APP退到后台后并不会真正的kill、掉进程，而是将其缓存起来。

打开的应用越多，缓存的应用也就越多，在系统进程不足的情况下，系统根据自己的一套进程回收机制，来判断kill掉哪些进程，以腾出进程给需要的app，这套进程回收机制叫做low memory killer。

内存阀值，每个手机都不一样，当可用内存小于该值得时候，Android就会杀死对应优先级得进程。

进程的优先级通过oom_adj来判断，oom_adj取值如下：

0-3是比较安全的oom_adj一般不会被系统杀死的，所以我们只要保证自己的app oom_adj在0-3之间就可以了。

可以通过adb命令：cat /proc /4181/oom_adj来查看自己app的oom_adj的值

4181是进程号

原理：手机关闭屏幕的时候，偷偷创建一个activity，让应用成为前台进程，打开屏幕时关闭activity，这样用户就不会发现什么异常，我们知道前台应用的oom_adj为0是不会被杀死的，这样就达到看保活的目的。

缺点：activity不够干净，只有在息屏的时候才生效，存在局限性比较大，而且谷歌原生的系统息屏的时候不会清理进程，但是现在很多厂商会在息屏的时候清理内存，所以本方案的可行性不高，可以作为了解。

保活原理：启动一个前台服务，从而拉高整个应用的优先级。

因为一旦通知被用户干掉那么该保活方案就不好用了，所以通知图标存在与否是该方案是否可行的关键。

但是该方案是谷歌官方承认的保活方案，所以可行性还是很高的。

需要适配

API18通知图标不会显示

API=18API26可以启动双服务，绑定同样的D,然后stop

这个方法的原理是8.0系统之前会根据服务的id来判断通知，那么第二个id设置跟第一个相同，然后自杀，系统就会误认为此通知已死就不会通知了，那么通知栏上面就不会显示

API=26后暂时没有方式能够隐藏

8.0之后不可以创建同样的id的通知，所以此隐藏通知的方法就不好用了，当然了，通知显示与否不是该方案成功的评判标准，所以说还是可以用的。

在发生特定系统事件时,系统会发出广播,通过在 Androidmanifest中静

态注册对应的广播监听器,即可在发生响应事件时拉活

但是从 android7.0开始,对广播进行了限制,而且在8.0更加严格该方法就不适用了。

有多个app在用户设备上安装,只要开启其中一个就可以将其他的app也拉

活。比如手机里装了手Q、QQ空间、兴趣部落等等,那么打开任意一个app后,其

他的app也都会被唤醒

系统每隔一段时间会进行账户同步，当系统去账户同步的时候(不一定多长时间，跟系统有关)，我们就去拉活app，这个方案是非常稳定的，当然了国内的系统都是定制的，所以还是需要一定的适配的。

优点：系统唤醒，比较稳定

缺点：时间不能把控

JobScheduler允许在特定状态与特定时间间隔周期执行任务。可以利

用它的这个特点完成保活的功能，效果即开启一个定时器，与普通定时器不

同的是其调度由系统完成。

同样在某些ROM可能并不能达到需要的效果

本文名称：android方案,基于android的设计与实现
分享路径：http://lswzjz.com/article/dsdoiis.html