安卓绿色公约app

绿色公约是AppSo与绿色守护联合推出的一款绿色应用软件，主要是为了改善安卓手机卡、耗电快的问题，目前已有2万多的支持，认证的应用也有13个，可以说是安卓手机的救星，有兴趣的可以下载安卓绿色公约app体验一下。

什么是绿色公约

自从推出这个公约后，AppSo 的后台收到最多的质疑是：这件事情太理想主义了，不仅是 Google 在国内缺失的问题，还有背后行业利益链等问题，能成事的机会实在太渺茫了。

但在 Oasis Feng 心中，绿色守护（Greenify）这个产品，本身就是一次理想主义的尝试。

它是一个诞生于 2012 年业余开发的小工具，如今已经走过了近 5 年的道路。5 年的坚持，最大的动力还是源于用户的支持和那份单纯的捐赠。

相比五年前，Android 生态早已今非昔比，厂商和开发者间的斗争，用户成了最大的牺牲者，我们的手机内存被大量重复的后台推送服务给塞满，国外 2G 内存的手机就能流畅使用，在国内连翻一番都捉襟见肘。

这场无尽之战已深陷囚徒困境，每一个局中人都明知这是玉石俱焚，任何一方都无路可退。究其根源，还是互联网长期被扭曲的商业模式塑造了这一切，早已埋下了这一死局的种子。

这就是「绿色应用公约」的诞生背景：先让一部分有良知有担当的应用团队，在保全流量利益的大前提下，卸去对设备体验的伤害，转而再推动手机厂商卸去它们对这部分应用的敌意和束缚，从而让双方都有机会携手创造一个更加良性的国内 Android 生态。

今年初，我回阿里去做过一个内部分享，其中一个主题是谈的「流量圈地时代的终结，对移动应用的发展会有什么冲击」。实际上，当流量圈地结束后，将迎来的是刺刀见红的注意力肉搏战。你抢夺的每一分用户注意力，都是别人损失的用户注意力。

移动应用最惧怕的用户流失是什么？显然是卸载。所以，好死不如赖活着，跪舔用户的时代大潮很快就要到来了；其次是「打开率」的问题，当应用被大量后台冻结、休眠后，也丧失了主动激活用户的机会。

当然，这个趋势肯定不是从巨头开始的，毕竟他们的提供了用户无法割舍的服务。但是，行业中的先知先觉者，已经意识到即将到来的问题，开始行动了。

绿色守护联合 AppSo 推出的「绿色应用公约」，正是看准了这个时代转变的契机，给中小应用一个让用户无需卸载的理由，和免于被休眠的机会；给行业第二、第三的挑战者一个虎口拔牙的武器。

绿色公约介绍

宗旨

这是一项旨在推动Android生态中的优秀应用共同维护一个更加良性的『设备体验』而发起的开放公约。

设备体验：影响效应超出用户与应用进行显性交互的过程之外，在用户感知中属于设备整体性的体验因素的总称。包括设备的安全性、整体流畅性、耗电程度、发热程度等。

由于Android系统的设备体验是由设备本身的软硬件及安装在设备中的众多应用所共同影响的，后者的影响往往随着安装的应用数量增长而迅速扩大。这种由应用所造成的外溢性影响，存在着典型的 『公地悲剧』 。安装的众多应用中，某一个应用对于设备体验的损害往往很难被用户直接辨识，以至设备体验问题长期得不到应用开发团队的足够重视。造成的后果间接的由全部应用，乃至整个Android生态共同承担。

因此，除了加强用户对于设备体验损害的辨识能力外，有必要推动整个Android开发社区以更高的标准优化各自应用的设备体验影响，共同维护一个良性的Android生态。

开放编撰

此公约的内容修订和扩充面向整个Android开发社区，采取开放接纳、充分讨论、积极修订的原则。如果对规约有任何的疑问（包括实施中的困难）和建议，请通过此公约的 GitHub issue tracker 提交。

核心原则

此公约的核心原则完全遵照Android本身的演进方向（包括 Android O 所引入的新变化），积极引导和协助应用开发团队平滑完成对接Android最新变化的节奏，在确保应用核心功能不受影响的前提下，减少不必要的应用后台行为，并以更加高效、节能的调度机制改善后台行为的调度。

涉及到功能与设备体验之间的潜在冲突时，遵循最终选择权给予用户的原则。

规约

必要部分

1， Target SDK Version >= 24 (Android 7.0)

原因：Project Svelte在Android 7中得到了一些关键的的强化，有助于降低应用后台行为对设备体验的影响。

2， 不在运行时强制请求『读取手机状态和身份（READ_PHONE_STATE）』权限。

原因：IMEI泄露是目前用户隐私和手机安全中的一个突出问题。它具有相当的隐蔽性，在Android 6.0之后的运行期权限体系中依然未能获得足够清晰的信息披露。由于Android系统仅仅将其显示为『读取手机状态和身份』，使得大部分用户在应用请求此项权限时虽然困惑，但仍未意识到授予这个权限背后存在的安全隐患。

若应用中的某些功能（如通话相关的特性）依赖此权限（须具备逻辑上的合理性），则只能在对应功能交互中请求此权限。即便用户拒绝授予权限，不依赖此权限的功能仍须保持可用。

3， 除用户的主动交互触发外，避免启动其它应用未处于运行中的进程。

原因：用户在主动交互中通常对交互的响应时间（例如从触摸到界面变化）存在一定的宽容度，而被动交互（例如启动过程的等待、媒体播放中）中出现的延迟或卡顿更易引发用户的反感。此间如果涉及到启动多个进程，除进程创建本身的显著开销和内存压力之外，如果启动的是其它应用的进程（即通常所说的『交叉唤醒』），对方的初始化开销则是一个完全不可控的因素。而交叉唤醒在应用之间往往具有连锁效应，在安装有较多关联应用（例如集成了相同SDK的多个应用）的情况下极易触发『链式唤醒』，引发CPU、内存、IO等资源短时间内的巨大压力，造成设备流畅性的急剧下降、耗电上升，带来严重的应用启动阶段用户体验和全局设备体验的双重损害。

4，使用请求唤醒CPU的周期性Alarm、JobScheduler的周期最小不低于30分钟，建议不低于1小时。避免在不必要的时间段（如夜间）继续调度周期性事件

原因：周期性唤醒CPU会打断设备的深度睡眠状态，造成设备待机时长的明显缩短。按照Google在Project Volta中的粗略测算，设备每1秒钟的活跃工作会让待机时间损失大约2分钟。大部分应用的后台周期性任务往往以网络访问为主，通常会持续数秒至数十秒（甚至超过1分钟）。如果此类周期性后台活动调度过于频繁，对待机时间的影响是极其显著的。Android从4.4开始，不断在迭代中优化周期任务的后台调度，但所有这些努力都只能在长周期任务中产生明显的效果。倘若有一个应用请求过于频密的周期任务，则整个系统的待机时长就会因为短木桶效应而受制，

5，为用户提供可达成『后台纯净 (Background-free)』目标的选项。（不必默认开启）

原因：后台持续运行的服务，是一系列设备体验问题的温床，如长连接基带持续工作增加的耗电、低内存时服务循环重启引起的设备迟缓、间歇性CPU和IO资源占用造成的卡顿…… 后台纯净是Android O对应用后台约束的一项重大原则性变化，它倡导的是『如非必要，勿启后台』的新原则。

后台纯净 (Background-free)：指符合面向Android O的应用开发要求中关于后台运行的约束。其核心要求是应用进入后台短时间内（至多3分钟，并在屏幕关闭前）停止所有后台服务，且在除了收到广播和执行来自通知的PendingIntent之外的其它条件（如JobScheduler）触发的后台行为期间不可以再启动新的后台服务。

6， 对于存在内容更新、数据同步或弱实时性通知的应用场景，建议在『后台纯净』模式下以周期性轮询替代推送。 （参见前述的最低周期约束）

对于Android 5.0及以上版本的系统，不在AndroidManifest.xml中静态注册以下广播：（从Android O开始，以下全部广播均已不再支持静态注册）