android方案,安卓方案定制开发
Android -- 保活方案
1、前台进程：当前运行的进程，除非APP的内存超过系统给定的最大内存，导致OOM才会被杀掉
创新互联专业为企业提供贺兰网站建设、贺兰做网站、贺兰网站设计、贺兰网站制作等企业网站建设、网页设计与制作、贺兰企业网站模板建站服务，十多年贺兰做网站经验，不只是建网站，更提供有价值的思路和整体网络服务。
2、可见进程、服务进程：当前可见、运行的音乐这种
3、空进程：给新打开的APP使用，优先级最低
Service 的启动方式有两种，一种是startService(),一种是bindService().这两种方式有有什么区别.
startService()，启动完之后该service就在后台运行，其生命周期跟启动它的Context没有任何关系。也不能跟Context通讯。
bindService()启动之后生命周期跟启动它的Context有关，比如Activity、fragment、service等。在Context中解绑之后，如果改Service没有任何绑定后该Service也就结束。
Service 的生命周期跟启动方式有关。
stratService的生命周期： onCreate() - onStartCommand() - onDestroy()
bindService的生命周期: onCreate() - onBind() - onUnbind() - onDestroy()
1.PARTIAL_WAKE_LOCK：保证CPU保持高性能运行，而屏幕和键盘背光（也可能是触摸按键的背光）关闭。一般情况下都会使用这个WakeLock。
2.ACQUIRE_CAUSES_WAKEUP：这个WakeLock除了会使CPU高性能运行外还会导致屏幕亮起，即使屏幕原先处于关闭的状态下。
3.ON_AFTER_RELEASE：如果释放WakeLock的时候屏幕处于亮着的状态，则在释放WakeLock之后让屏幕再保持亮一小会。如果释放WakeLock的时候屏幕本身就没亮，则不会有动作。
1.PARTIAL_WAKE_LOCK：保证CPU保持高性能运行，而屏幕和键盘背光（也可能是触摸按键的背光）关闭。一般情况下都会使用这个WakeLock。
2.ACQUIRE_CAUSES_WAKEUP：这个WakeLock除了会使CPU高性能运行外还会导致屏幕亮起，即使屏幕原先处于关闭的状态下。
3.ON_AFTER_RELEASE：如果释放WakeLock的时候屏幕处于亮着的状态，则在释放WakeLock之后让屏幕再保持亮一小会。如果释放WakeLock的时候屏幕本身就没亮，则不会有动作。
对于 API level 18 ：调用startForeground(ID， new Notification())，发送空的Notification ，图标则不会显示。
对于 API level = 18：在需要提优先级的service A启动一个InnerService，两个服务同时startForeground，且绑定同样的 ID。Stop 掉InnerService ，这样通知栏图标即被移除。
该方案过于流氓，而且效果不好，所以不写。
JobSchedule 允许在特定状态与特定时间间隔周期执行任务。我们可以利用它的这个特点来完成保活功能，效果就像开启一个定时器，与普通定时器不同的是其调度由系统来完成。
在发送特定系统事件时，系统会发出广播，通过在AndroidManifest中静态注册对应的广播监听，即可在发送响应事件时拉活。
但是Android7.0开始，对广播进行了限制，而且在8.0更加严格。
Android8.0开始对广播有了限制：很多隐式广播接收器不能在清单中静态注册。但清单注册广播接收器仍是可以的（豁免广播或自定义广播-注意，自定义广播要显式发送）。实现隐式广播（系统广播）的接收也是可以的，但只能通过动态注册来实现了。
有多个app在用户设备上安装，只要开启其中一个， 就可以将其他的app也拉活。
具体实现：
一、系统同步机制拉活
总结 - 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布局解决方案(汇总)
概述：记录一下常见布局的编写方式。
答：使用recyclerView的网格布局即可。
答：使用别人的开源组件。
应用场景，b站视频的标签，商品标签等等。
答：使用LinearLayout布局，设置weightSum属性，子view设置layout_weight属性。记住需要把设定的宽度或者高度设置0dp。
答：使用RelativeLayout布局，最后一个子View会显示在屏幕的最上方，不会被遮挡，常用来做activity标题头(titlebar)。
答：使用如下属性即可。
答：推荐使用NestedScrllView。
答：参考：
答：如下
在布局中添加如下属性
待补充。。。
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方案,安卓方案定制开发
链接地址：http://pwwzsj.com/article/dsgepcg.html
