最好用的安卓毕业第三方墓碑-Noactive的完整教程
NoActive正如其名，让Android后台CPU不再活跃
安卓墓碑是需要一定阅读理解和操作性的，如果你的手机没有root是无法使用的，快去root吧！
题外话：
本篇文章基于神经模拟回路的Chat-Gpt-ARLY模拟名称为---“春恋桃”的人格，分析和整理的此篇文章。
-
在操作前先完整看3-5遍，别说什么太细或者太麻烦。我写这些固然都是有意义的
-
该教程偏向[使用教程]，在看完此此文章后就基本上能解决90%的需求如果查缺补漏请在下面的文章查找
如需跳过前面的索引和提示直接“点此”直接跳转到使用界面 -
如要查缺补漏，请在下面的文章查找剩下的文档可以点此进入冰梦的文档：
[链接]冰梦的文档 -
本教程版本为2.9beta【285】，[
冰梦网盘的noactive资源] -
想要直接超作业给钱那种，教程麻烦，你用嘴说吧。你不是给我添麻烦，这些都不重要。
重要的是我对这篇文章的挑衅，所以我也不会回答你的问题，直到你和我的教程成为朋友为止。
魔法禁书目录 【点击就可以跳转到相应位置】
我喜欢NoActive的原因
这部分只是为了让大家基础的了解noactive
noactive软件的简单原理：
通俗理解运行方式是如果app不在主屏幕上----3秒后就会进行墓碑----app被冻结，对就这么简单
作为我心目中目前最好的类ios墓碑类软件
Noactive有着最让人养老的几个特性:
省心：折腾完后就可以不管不顾了，除非之后有需要管控的app，noactive都是完全省心的
自定义：可以让app实现多种识别方式来进行管控，例如对进程进行 冻结/杀死/白名单等操作
操作方便：有足够便利的ui让您可以针对性进行软件调整，本身并不需要复杂麻烦的命令行控制
简洁：noa并没有什么花里胡哨的功能，一点即用
凉爽：如果你从来没用过noactive，那么调整成功之后你一定会在炎热的夏天喜欢它的
用了墓碑就别换手机了，来看教程吧
大家就和吃泡泡糖一样慢慢看慢慢嚼就行，不急
不要神话noactive，我们只是先行者。
很显然最好的方案就是等待厂商ota，但是能不能ota我也不清楚
noactvie在后面简称为noa
Q：我不会怎么办？
A：先看1-3遍教程，再来问我或者问其他人
Q：为什么没有群了？
A：目前的群已经变成QQ频道，更方便你们和作者反馈BUG
Q：为什么不上传酷安？
A：因为酷安不适合发“教程”这种东西，所以冰梦的博客是必要的
Q：这篇文章的作者是谁？
A：是来自酷安的Starrhymelodge
需要知道的小提示:
支持性
最低支持安卓10，但最佳的版本是安卓12-13
目前的noa理想工作状态应该是安卓12+miui13，8月份的开发版
冲突性
无法与其他“具有相同功能的墓碑”使用
或是早期thanox上面myflavor写的墓碑
Noactive的作用
-
hook应用切换事件，冻结切换至后台的应用，解冻切换至前台的应用【解冻前台应用和冻结后台应用】
-
Hook显示暂停执行已缓存开关，仅显示无作用(Happy freezer)
-
获取PMS为冻结后的APP释放唤醒锁【释放唤醒锁】
-
Hook获取NMS为冻结后的APP断开网络连接【保持连接】
-
Hook接收小米Millet网络临时解冻APP【millet网络解冻版保持连接】
-
Hook接收小米Binder通知临时解冻APP【可以理解为binder保活】
NoActive的版本
大家用的目前也就分为两个版本吧
-
2.8lts【长期稳定版本】 在myflavor定义为长期不更新的意思
- 2.9bata【282】 在apple的意见下加入了单独应用定时解冻的按钮
目前增加了定时解冻对那个其实就是2.8lts的延申，也是正常使用 - 目前2.9Alpha【285】增加了压缩内存和解冻binder,但文件管理有bug。
- 如果是从285升级上来的遭遇到了配置丢失，把配置文件丢到config里面就可以
- 如果没有log文件夹需要新建一个，这样就有log了
- 2.9bata【282】 在apple的意见下加入了单独应用定时解冻的按钮
-
魔改版：可能会出现于熊猫的版本，这些你们也没几个用的吧，熊猫自己都跑路了
这里面的所有功能将在Noactive3.0实现
关于NoActive3.0?
myflavor将会在不久重构noactive，3.0版本将会以稳定性优先。
添加更多功能，自定义选项，在app内就可以看到日志
自动判断冻结模式更智能，修复了各种难用和令人头疼的点
这些无论对我这种写教程的或者还是对使用的用户都有了更舒服的体验。
- 甚至myflavor对外公开宣布为了实行他的“myflavoros”的第一步
你们可以把自己的配置上传到“myflavor云”。
不管墓碑怎么走下去，我在这里还是要喊一句，NoActive，yyds
关于小米设备的millet？
- millet在miui13开始支持
- 他是小米自己的墓碑。分别为v1和v2两个版本
- 此特性miui13开发板8月之后完善关于binder？
- binder是安卓系统中负责应用间通讯的，效率极高。
- 为了方便理解在这里为冻结做通讯工作。
- 同时除了miui，作者明确告诉了其他系统没法修复binder。在这个软件需要注意的是 ：
binder和millet为miui的专属
很多功能可能只有miui才能实现，其他系统可能会出现一些bug
关于内存模块？防杀？
- 关于一些内存模块：
我的态度依旧是，安卓目前不需要依赖这些其他的通过十分不科学魔改lmkd的方式进行保护后台的操作。
尤其在安卓13本身已经拥有mglru的情况下，更没必要去鼓捣那些”安卓团队辛苦做出来的成果“
所以温和的对待系统，系统也可以温和的对待你至于一些内存模块的杀进程，这个没什么说的。不包括魔改其实对这些我是不干预的
我也很鼓励你们去杀掉一些没用的进程，毕竟对负载友好
但不鼓励一些频繁的杀后台，这跟重载没区别甚至会增加无用耗电
- 关于防杀后台：
保护后台模块分为两个部分：
- 清理应用无用进程：清理应用进程达到”内存瘦身“，前者非常适合配合使用
- 修改安卓内存的机制：后者虽然可以带来强大的机制，但可能会导致耗电，严重的会导致手机因为保后台太强而系统彻底死掉
这里只推荐don't kill
关于使用的安卓版本为安卓12-13
作者：海浪逃向岛屿的酷安主页
这两个模块已经足够，包括我自己都是这么用的。
- MGLRU
- 这是一个新的内存机制，他出现在安卓13。目前支持的内核特性应该是5.4以上
- 这个机制会减少百分之40的杀后台，kspdw百分之30的CPU占用。
- 同时对内存是否“真正”需要回收，判断的更严谨更聪明
- 如果想看是否启用的话请输入以下命令：
su cat /sys/kernel/mm/lru_gen/enabled 如果为无文件说明不支持，如果0x0000为关闭/0x0003为开启
还是那句话，能正常就别瞎整。维持系统稳定最重要，这也是myflavor的建议
不对系统大刀阔斧，尊重系统系统选择
我个人并不推荐一开始为了所谓的为了保护后台而破坏一些后台的内存机制。
对于你们这些刚使用的新手来说建议从noa稳定2-3天之后再开始使用也不迟，这样也好对照变量
所以我基本上只推荐小阳光、a1、thanox、和焕晨。对于内存模块的讨论和使用不在本教程范围内，一笔带过就好
！！！！保后台不是魔法科技，不能代替物理内存。这东西是有利有弊的，可以参考华为的设备。
为什么用墓碑？
我们大家的目标都是一样的，无非就是希望自己的手机越来越好用。
就像我在用13u给你们发教程一样，我是希望你们一直可以钉下去的。毕竟换手机真的没必要
多钉钉子会省点钱，每个人都可以享受到这些。
如果后面还有问题就会再更新，没有就可能宣告2.9版本结束了
但在这之前我会慢慢修补我前面文章的错误，我们将迎来新一轮墓碑赛道的开始
到时候说不定谁写教程呢，有可能是我看你教程会的新版本noactive呢？你们说对不对？
我测试过的设备？
我曾尝试使用过的noactive的设备：
| 设备： | 结果： |
|---|---|
| 坚果 pro2s | 笑死根本不能用 |
| lgv50 | 直接闪退了，换冻它 |
| 小米10s | 1.6版本 |
| 红米k40 | 2.3lts |
| 红米k20pro premium edition | 2.3lts |
| 小米12pro | 陪伴NoActive测试了一半以上的版本截至在2.8lts |
| 红米k50ultra | 2.9Alpha【282】 |
| 小米13ultra | 2.9Alpha【285】 |
目前的教程版本：v0.99beta
目前使用机器为：小米13ultra
新手推荐版本为:2.9【282】；我的目前版本为：2.9【285】
如果遇到了文中没提到的问题，并且您“尝试解决成功”了。
后续考虑到反馈这些问题可能会到频道里面
后面再说吧Noactive的安装部分
xposed框架
xpoesd框架作用域的简要说明：
勾选系统框架加上电量和性能【电量和性能是miui专属的，如果没有请点击这里跳过】
如果你连lsp框架都没勾选，那么是根本没法正常使用的
don't kill?的配置
电量和性能
-
防止夜间掉卡片【就是应用还活着，但后台没卡片】
- 现在有新的noactive plugin lsp框架来配合防止杀后台，和don‘tkill互不不影响
noactive plugin
-
禁用millet的部分功能，noactive现在有新的禁用millet
magisk模块用来配合使用，下面是进行millet的功能检查
Miui的millet部分
【查看是否正常 没有此功能的手机可以没必要看】
-
在终端输入以下命令行
sucmd greezer ls lsfzgetprop | grep millet
需要注意的true和false有这些：
persist.sys.gz.enable=false 但我的机器没有gz.enable
persist.sys.brightmillet.enable=false
persist.sys.powmillet.enable=false
persist.sys.millet.cgroup1=true miui修过的v1不泄露
persist.sys.millet.newversion=新机器才有 最好false 【这是两种不同的冻结方式，但我为了为标准就为false】
persist.sys.millet.handshake=true 可以使用网络解冻 false就不行
**如果条件不满足上面所说的就需要noa的禁用millet的模块**现在lsp的配置基本上完毕了
安装完之后重启手机，我们就开始了墓碑之旅了
关于Noactive的设置界面
用户界面
打开app需要root权限，请授予权限
如果没有需要去面具给予权限
从上往下看 可以看到，右上角为应用设置
下面是app的搜索
旁边是：
- 用户应用
- 系统应用
- 全部应用
方便查看冻结目标
在来到屏幕中间你就可以看见软件上面有独特的彩色字体标识了
- 白名单
- 其他配置
- 后台级别
- 电池优化
用户软件界面
这里是我对app的配置(因为是当教程所以就举例子)
默认情况下noa是会对所有非系统软件进行冻结
-
白名单：noa不会对白名单的应用进行任何操作
-
其他配置，对app进行了：
- 杀死进程/白名单
- 电池优化
- 定时解冻
- 保持连接的操作
-
后台级别：
- 前台服务
- 可见窗口
- 强制冻结
- 先来到普通软件
我们就可以看见能调节的东西
白名单
-
关于白名单：
Noactive不会对白名单过的app进行冻结操作
就是你觉得什么app不想被墓碑就开启白名单
感觉app完全没限制太可惜了再加个电池优化就行。
- 白名单推荐：
- 微信、 第三方输入法
李跳跳，木头爬上去的软件等。这种不需要限制后台的软件
- 微信、 第三方输入法
- mipush：
- 其他机器给白名单
- 在miui系统，mipush3.10版本之后已经变为系统软件，不再需要给予白名单
关于墓碑配合mipush原理
以及调整应用每个进程是否冻结/白名单/杀死的选项
杀死进程和大家想的不一样 不是应用还活着就会杀死
杀死的思路和冻结一样 应用离开屏幕后3秒杀死进程
电池优化
- 电池优化 【只有开启白名单的情况下才能开启】--noa默认会接管电池优化【白名单会添加到电池优化的不优化选项卡】
也就意味着如果想要默认的系统优化就开启这个选项，默认情况下不会开启
-
定时解冻 【十分建议单独应用出现冻死的用户来实现单独后台保活】--目的是因为其他系统没有binder或不好用，不能保活。所以利用这种定时解冻的方式，3分钟解冻一个app为1秒，让他不至于被彻底压死未响应
-
保持连接 【是否使用第三方推送通道，例如mipush、hms这种】--默认关闭使不使用app自身推送，采用第三方推送通道，反之开启使用app自身推送，这个我想很少有人能开启
- 关于mipush和Noa的配合
后台级别
- 关于mipush和Noa的配合
来到后台级别：
前台服务
【切换应用到后台或者桌面3秒后冻结】--例如导航、运动类型app、正在播放的音频、视频、无障碍应用、通知栏这种虽然在后台但是需要前台进行运行的任务的应用，将不会进行冻结，你要是再不理解那就就是需要一直保持后台活着才能正常用的app
-
关于一些音频app，例如b站压不住这些问题
在你设置完后台播放之后，如果后台播放完之后是会一直有占用的。
这属于是判断问题，目前没有特别好的方案，这里给出一个相对还算能实行的方案：
灭霸设置后台，在后台设置半小时到一小时内杀掉b站这种音频软件，这是使用noa之后主要的续航问题。 -
另外b站还有一个bug，我不知道你们留意没。我目前用的是6.4版本。
这个版本会发生超大核后台bug，就是在你把b站放后台挂了一段时间内。
他会一直满载超大核心，如果你有这个问题也可以留意一下。
可见窗口
【切换应用到后台或者桌面3秒后冻结】--这种基本上就是能看得见的基本上都算。非前台服务但看得到画面的应用，例如小窗、悬浮窗这种，说人话就是他只要不是在你的屏幕上就冻结
强制冻结
【回到后台或者桌面立即冻结】--就是直接就冻上了，非常的暴力，也没什么好说的
QQ和微信设置
怎么利用Mipush进行QQ的推送？
- 关于qq怎么设置：留mobileqq进程和msf进程，剩下的全部杀了就可以
正常不需要任何设置。除非你觉得qq特别流氓，自己也不打qq电话，可以设置成强制冻结。
按照我正常设置就对了。别瞎整
对于目前qq的推送无法推送频道，所以没办法推送频道内容
只留这俩冻结，剩下的全是杀死
微信
-
对于微信来说我是设置白名单的
微信并不建议冻结，因为微信目前没有什么比较好用的推送渠道。
微信比qq来说其实省电不少，自己也会杀掉无用进程
系统应用
我们从普通应用切换至系统应用
系统应用在默认状态下，Noactive是不会干涉的
需要用户自己将系统应用变成黑名单方可冻结系统app
注意系统应用下的开关是黑名单，就是选中就会被冻结
关于高级模式
冻结方式
从上往下看
有冻结方式/提权模式/定时冻结/轮番解冻/详细日志 以及关于开发者
来到冻结模式的推荐：
方便检测的工具
jark006的挂载检测脚本：冰梦的网盘)
从N0A3.0拆分出来的一个模块NoActive-Monitor： 在这里可以使用冻结查看软件，冻结版本。
Termux终端：官网
MT管理器：官网
关于冻结方式：
从左到右边推荐，左为最好
冻结方式：API > v2 > v1 kill 【v1+也算v1里面】
cgroup：CGroup Freezer V2 >= CGroup V2 > 小米修复v1> FreezerV1(v1不泄露) > SIGSTOP 。是最糟糕的是FreezerV1泄漏
不要老是在意是不是v2和v2frozen，其实无所谓。v2的大部分用户都是没binder特性的，你都没binder了还在意这些干什么。。。。
这里给大家一个初步印象，然后下面是各种机器推荐的模式
推荐的模式
非Miui设备
【包括刷第三方系统没有binder的小米手机】
在binder不能调用的情况下都用API+轮番解冻+定时冻结
在API抽风的时候如果有需要可以指定v1、v2模式，但大部分都不成功。
对于没有binder的机器来说，冻结版本肯定是越高越好
但对于v2 CGroup和v2 CGroup freezer 来说，区别没有v2比v1那么特别大
所以这东西看自己。
在一些v2的设备上【大多数都是oppo/vivo】，可能也会出现正常的模式也会内存泄露，这是因为魔改了冻结方式
从而导致noa不能正确调用，API模式会出现同时使用V1+v2这种情况。
如果设备有问题再提权 挂载/卸载 模式
| 可用的冻结模式 | 建议 |
|---|---|
| 只能用v1 | 那就老实用吧 |
| v1+v2同时拥有 | 请注意挂载目录是否为 sys，如果为dev将需要---取消挂载/重新挂载v1，否则系统同时调用可能会出现问题 |
| v2 | 可以是否提升为v2 CGroup Freezer，但不必须 |
挂载模块分为4个：v1/v2 取消和挂载，所以大家一定要使用适合自己的
冻结方式
推荐：v2frozen>v2uid=>v1
【v2frozen 和 v2uid 不是一个东西，她们两个不存在是否不完整这个问题】
挂载模块：
挂载是需要你的内核支持特性的，不是说你挂载了一定就用的了
所以老机器有需要还是需要第三方支持
例如:
冻结模式：v1 /sys
挂载后得到
冻结模式：v2[uid] /sys
冻结模式：v1 /sys取消挂载模块：
例如一些冻结目录为dev的
就需要通过模块来让之前的目录失效并挂载到让noa能识别其中的冻结路径
例如v1有毛病【v2同理】：
冻结模式：v1 /dev
取消挂载后得到
冻结模式：v1 /sys
冻结模式：v2[frozen] /sys
冻结模式：v1 /dev
挂载后得到
冻结模式：v2[frozen] /sys
冻结模式：v1 /sys在脚本里面判断的
v2 CGroup uid = v2 CGroup
v2 CGroup Freezer = v2 CGroup frozen
意思都一样，能懂就行
Miui设备
注意！miui设备刷官改、国际版或者内核 可能也会有死机/不兼容等问题，
所以miui的例子都为稳定版。
5.10及以上内核【例如8gen1、8gen1、8gen2、7gen1 7gen2 8100】
拥有millet特性的miui+拥有millet特性 5.10以上的内核设备，及其以上内核可以考虑两个模式：v2/api 如果能用api优先api，不能用再v2求稳
举例：小米13 最次使用v2 api能用是最好的
4.14-4.19的内核设备【例如855 865 870】
拥有millet特性的miui+拥有millet特性 4.14-4.19的内核设备：直接选择v1
举例:小米10 miui14/k40使用v1
5.4的内核设备 【目前只知道888+和888 778】
5.4内核的手机比较特殊，目前没有特别成功的作业。大概率binder有问题，如果正常就使用v2或api。不正常可以使用轮番解冻+定时冻结来缓解。
实在binder有问题搞的我头大怎么办？
所有miui不正常的binder实在没办法均可以按照非miui的方法来这么处理，或者每过一天就重启一次手机系统。
因为本人玩机阅历比较少，其他的内核或者处理器请翻阅下面的冻结模式特性自行选择想要的冻结版本
其他需要知道的
- 四个字概括就是：内核版本、内核版本、内核版本很重要
- 【再次强调】需要注意的是在miui正常运转binder的设备上也会出现大量莫名其妙的binder堵塞问题。这个目前没有解决方案，TV说noa跟内核不发生冲突。
- 个人建议如果binder有问题刷了tv内核没有改善可以刷回官核看看binder是否正常，对自己没坏处。
- 也有人重装系统/各种换内核就莫名其妙的好了，这个问题目前无解
- 只有miui的机器才能有binder特性，作者没修复别的系统，所以其他机型大部分到后台后卡死就是因为没binder，可能会出现闪弹重载，出现这种情况就要打开轮番解冻，轮番解冻将在下面的部分说到
- 不同手机有不同的内核，不同的系统，甚至有不同的模块。都会有不同的关系；这个需要自己清楚，只能听天由命，tv内核给出了补齐的方案，但补齐也不一定能好用。原理同上面需要同时具备的条件
所以啰嗦了一大堆，就是自己测试过能正常用就是最好的。请记住不论是什么墓碑，只要他能正常稳定的运行，而且听话就可以了。
下面的这部分，是涉及到冻结模式的。如果不想了解可以跳过
Cgroup和Binder的区别？
关于noa里面的冻结模式：
-
cgroup和binder功能是不一样的，千万不要把冻结方式 和cgroup，还有binder弄混了。
-
cgroup【冻结方式】|binder【binder特性】
这两个特性都有才算完整的冻结组合，只有miui的机器才能有binder特性，作者没修复别的系统
所以其他机型大部分到后台后卡死闪弹和黑重载这些问题，就是因为没binder。 -
假如内核支持 cgroup freezer【冻结方式】
但不支持 binder freeze【binder特性】，那么进程在冻结后虽然会留在后台
但解冻后就会杀掉进程，出现这种情况就要打开轮番解冻和定时冻结
当然，比较简单看binder有没有问题的方法是有的，就是看日志崩没崩
冻结模式特性
下面来讲讲这些模式的特性：
| 冻结模式 | 特性【作用】 |
|---|---|
| sigstop/sigtstp kill19/20 |
kill19和20基本上都支持，这种冻结方式是linux原始的进程控制机制，并不会考虑安卓当前的应用状态是否适合冻结。一旦进程收到该信号进程则被立即强制暂停运行所以会出现一些很明显的bug，重新回到前台解冻时，更容易发生闪弹，重载等等现象。其冻结 最为彻底 ，但容易出问题，所以才需要freezer. 至于这两个有什么区别，有些可以用19，有些是20。但我真看见了有部分用户用kill效果说还可以的 |
| v1 | FreezerV1 很早便在内核中支持，3.x/4.x/5.x内核都会支持，v1有少部分机器会有缺陷。app会延迟冻结或者无法冻结，会内存泄漏，而且无法解决，重启也慢。不推荐在泄露的时候长期开机。 搭载Millet的MIUI设备无需担心binder问题，因为针对Freezer V1缺陷的修复就集成在Millet的内核修改中，只要你使用的内核支持Millet就无需担心Freezer V1的副作用。 |
| v1+ | 用来缓解部分的系统用v1导致内存泄露 |
| v2 | 在CGroup V2跟CGroup Freezer V2并不是一个概念。【v2的概念部分由tv大佬赞助，少年不行就刷个tv内核呗？】 CGroup V2于4.19内核引入并在OEM的机子中广泛使用，但是Freezer V2则是在搭载4.19内核的机型更新了一次Android版本后才开始被引入进这些设备的内核中（非强制）。 然而很多OEM可能自始至终并未将CGroup Freezer V2添加进他们4.19内核的设备中（罪魁祸首是Vendor Freeze），所以如果想在确认不受支持的设备使用Freezer V2则需要通过第三方内核来提供Freezer V2 API支持。 高通平台内核4.19起一般就完备v2的freezer子系统了，冻结进程没啥问题，而binder的freezer特性直到5.10内核才具备（我在最新主线5.4内核源码中发现已经实现了，但是目前市面上大多数5.4内核还不支持。 所以5.10内核起才算完整的冻结，AOSP默认的“暂停执行已缓存的应用”主要就是用到这俩 |
| 自动 | auto大法好，推荐miui自动，但自动不好用的时候就推荐手动了。 |
| API | API：通过调用系统自带接口来实现冻结，本质上这个如果能稳定就是最理通过调用系统自带接口来实现冻结，本质上这个如果能稳定就是最理想的冻结方式。但缺点是系统有什么出什么，所以说可能会有不按套路出牌的时候。例如会同时使用v1/v2特性 这时候就需要要固定为v1或者v2这种的冻结方式 |
内核如果要是换第三方的内核一般推荐使用tv内核@TheVoyager ，性能更好更加省电的同时做了相应的添加补全。但也不一定能好用。原理同上面需要同时具备的条件。tv现在正在做feas的移植，在一些较新的内核【5.4 5.10 5.15】加入了安卓13特性的mglru。
提权模式
来介绍下提权模式吧：
首先需要明白的一点是，NoActive仅仅作用于系统框架，不是Root权限，权限不足
十分不推荐在noa正常的情况下使用提权，可能会使原本没有问题的环境出现特别恶劣的问题.
最少myflavor说过他是十分不愿意给与多余权限的，他说给多权限之后系统会出现问题，卡死都是家常便饭
如果你使用除了API的所有模式还是冻结失败，你可以开启提权模式再次尝试，配置之后必须重启才能使noa提升权限冻结失败或者没办法用的模式在打开后就可以正常使用了挂载一些冻结的方式需要提权模式，挂载只能支持v1、v2、kill19、kill20，虽然提升权限了。
但这将改变noa的权限方式，现在需要做的是手动给予noa自启动的权限，不要有任何的软件限制noa，否则这会使noa卡死，也就变相什么都会卡死了。
定时冻结和轮番解冻
其中关于“定时冻结”与“轮番解冻”，会建议
所有非MIUI系统的都开启该选项！！！
究其原因这是binder的原因。开启后，需要重启手机才能正常使用。
-
定时冻结：一分钟冻结一次所有在noa上面的黑名单应用
-
轮番解冻：因为没有binder 压死之后就需要让app来活一会让他以为自己还活着，轮番的意思是1分钟解冻一个app3秒，解冻是最久没打开的那个app
假如我有5个应用，正常情况下是按顺序解冻的，也就是 12345 但这时候我突然打开了3，这时候顺序就会变成12453.
测试模式【高级模式】
虽然noa叫【高级模式】，在我这里我就叫测试模式了
-
压缩进程和冻结binder
这两个都为测试功能
推荐的内核版本myflavor说5.4以上开
使用可能会出现很明显的bug
严重的会造成续航砍半，待机功耗直线上升
依然是只建议你稳定noa2-3天后再尝鲜体验
有稳定使用的条件再来尝尝鲜我觉得没什么
冻结binder
-
关于冻结binder：
冻结binder会使解冻速度变快，更跟手丝滑
根据目前用户反馈来看
目前可以很好使用的范围只推荐5.10以上的miui用户
使用API+冻结binder
其他用户自测，我保证不了任何稳定
我的13u没法使用这个特性：例如qq切到后台一段后会一直断网，直到杀掉重新打开app
打开会出现后台app冻死的问题，而且概率很高
压缩进程
- 关于压缩进程：
冻结后压缩进程。
这个开关是即开即用的，不需要重启
目前反馈的bug的最严重
我自己用完功耗异常高 但是当时在v2，api我没测
老版本安卓用了之后会炸内存
其实我觉得不如zram。。。
目前有问题，不建议用
调用的很僵硬
本人使用内存压缩会有功耗bug，功耗多抬升0.5w
详细日志
- 详细日志一般都是出bug给作者看的，没什么大用处。开了也会更加费电。正常使用不建议开
- 另外详细日志不需要再开了，作者因为制作3.0也不会去看你的错误!没必要了
开了之后log里面会显示的是DEBUG(调试信息)状态
NoActive的群和myflavor的网站、以及如何捐赠
开发者的网站和群的一些信息，捐赠部分也没什么好说的.
- 目前群只提供文件信息，聊天和反馈都去了qq频道。
- 可以先进群再通过置顶进入频道。
- 你说什么？怎么没有群号？你是云玩家吧！
关于错误的诊断、目录配置
NoActive的目录配置
上面说了有详细目录，那么noa的目录在那里呢？
目录在/data/system/NoActive/log
一共有两个文件夹：
一个config一个log
这次因为noa更新了，我的教程这边也要更新
但版本的问题我觉得不大，毕竟目录差不多
而且即使是更新了，我依然觉得之前的2.9的282测试目前是最佳选择.
!!!如果你发现你的noa找不到配置文件或者丢失
- 你没给NoActive的root权限/没勾选LSP系统框架
- 你使用的是最新的2.9【285】系统，需要新建文件
进入要config的时候可以注意一下freezer.API的文件名字，他将会显示您当前在什么冻结模式；例如v1也就是freezerv1
第一个文件夹包括各种配置已经高级设置，没啥好说的，正常人我也觉得不会用这个来切换模式
第二个log文件夹包括了本次运行日志和上次日志 currentlog和lastlog
关于log
现在进入log来查看日志文件
下面我来举例子
2023-08-19 01:25:11 INFO -> Debug off
前面是日期 中间是调试信息
DEBUG(调试信息)【开详细日志才有】
INFO(基本信息)
WARN(警告信息)
ERROR(错误信息)
关于文档的说明并不多，我翻译的也可能不准确
Android 13 安卓版本
Auto Wakelock 释放唤醒锁
Auto Standby 限制app后台
INFO -> Auto block network 冻结后断开网络连接
Activity helper 阻止休眠长时间不活跃的应用
Freezer V2 冻结版本
Binder Freeze On 冻结binder
Compact Process On 进程压缩
Listen app switch app开关监听
Listen screen state 屏幕状态监听
Auto deep doze 冻结的软件自动深度doze
Listen power idle add 电池优化名单添加
Listen power idle remove 电池优化名单移除
Listen broadcast deliver 广播分发事件监听
Auto keep ANR noanr的意思是屏蔽被冻结的应用接收广播，从而避免触发未响应弹窗
Disable task trim 关闭任务队列
Perfect Freezer 显示暂停执行已缓存开关 【但没任何作用，作者的恶趣味】
Listen binder state 监听binder状态
Network helper 保持连接
Disable Android Freezer 关闭安卓自带冻结
Load success 加载成功
在下面就是binder的状态 识别挺简单的
一共就这两句话：
com.tencent.mobileqq check binder 正在检查binder
com.netease.cloudmusic received sync binder binder同步成功
com.tencent.mobileqq check binder
com.netease.cloudmusic check binder
com.netease.cloudmusic check binder
tv.danmaku.bili check binder
tv.danmaku.bili check binder
com.netease.cloudmusic received sync binder
com.netease.cloudmusic received sync binder
com.netease.cloudmusic received sync binder
com.netease.cloudmusic received sync binder
com.netease.cloudmusic received sync binder
tv.danmaku.bili received sync binder
com.yqs112358.tombedappsmonitor received sync binder
com.yqs112358.tombedappsmonitor received sync binder
com.xiaomi.vipaccount received sync binder
com.xiaomi.vipaccount received sync binder
com.netease.cloudmusic received sync binder
com.netease.cloudmusic received sync binder
com.netease.cloudmusic received sync binder这种都是正常的，也不需要管
关于其他类原生没binder是不会弹这种东西的，因为没binder
log里面可能会有报错，如果没有发生特别多的重复打印的状态，那么基本可以无视了
关于log错误
诊断错误
binder出现问题
binder大量没有处理的堆积造成的堵塞
或者是因为一个binder被冻结，但与另一个通信没有中断造成的堵塞
那么binder出现问题了会发生什么现象呢？
如果遭遇日志炸了，那就是binder出问题了，即使binder在运行中
我做了一个图来表示正常、冻结、出现binder的表现:
-
正常
-
冻结正常
-
重载
如果只是应用的程序被冻结，而没有冻结其binder通信接口，其他app就没法和他通信，就无法及时回复
这时候超时不回复将被系统认为应用有问题而强制杀掉。而后用户将要返回将应用解冻时，大概率将发生瞬间闪退，重启，重载等等情况。
下面来讲解各种异常症状【图全是偷的，我就懒】：
闪弹
问题1：应用进入后台之后再次打开，应用在动画没结束的时候就会自动闪退。等再次进入的时候就会发现重新启动了【这种再次重新加载也被成为冷启动】，目前闪弹触发条件不明，我觉得大部分出现于kill上面。
问题2：应用卡片存在于后台的界面，切换应用或者亮屏后进入应用【只要是进入该app的操作】，就会发现应用对操作无反应或是短时间内掉出应用界面，打开后台查看会发现任务卡片消失了
重载
感谢某位不知名的12s用户精简说明
重载目前分为两种情况：
- 问题1：一种是黑重载，这种情况出现是不好的，他相当于冷启动，因为存在程序不完整或者进程丢失，也就是binder出现了问题
我相信看到这里你们肯定能理解binder有问题是什么意思了。不多说
- 问题2：另一种是白重载，应用在后台被压缩了，这是正常的。
从我个人角度看貌似是属于MGLRU类似的行为。通过淘汰掉无用页来让内存能有空间放下app，不至于资源紧张。
等有需要的时候再加载回去，来让app不会杀掉后台。
但这种操作也有可能会破坏应用的数据空间，可能也会导致重载，但大多发生在内存紧张时。意图是保存上次浏览的内容
内存泄露
在正常的情况下杀死app会回收占用过的内存 也就是说app占用1个g，杀掉我们就获得1g内存。
但是在内存泄露的情况下是没办法回收内存的，导致占用越来越高，在最后卡顿或者严重的会死机。
内存泄露只存在于一些没有得到修复小米老机型，可以使用millet的v1冻结方式的手机理应不会存在v1内存泄露
如果存在内存泄露请使用v1+
掉卡片
问题1：软件进程还在，你去点应用的快捷方式还能打开，但是后台任务卡片掉了
问题2：长时间不用的app在后台界面，卡片和进程一起丢失
以抖音为例子：
怎么知道我的软件在冻结？
关于查看如何压住没压住：
只需要看3秒后，被冻结的app是否cpu占用为0
如果压制之后依然有占用，就没压住
报错
-
关于报错：目前大部分弹的这个错误应该最多。
error thawv1 failed process died or not suppoorted
就是说你的解冻v1失败，程序死了或者不支持解冻。
同理
error thawv2 failed process died or not suppoorted
v2解冻失败，程序死了或者不支持解冻
可能是你挂载冻结模式有问题或者你的noa发现路径cgroup有问题 -
如果遇到doze fail 的也没关系 就是doze退出了 不管
-
关于大量check binder的问题
你不能拥有特别多的checkbinder这样会让手机浪费电量 -
我对报错的态度还是，你有问题弹一大堆的时候再说自己有问题。
-
或者是关于noa提权之后被限制后台导致无法冻结和解冻app造成的
su disconnected 提权断开
su connected 提权连接
NoActive应用:墓碑配合mipush
mipush的教程：mipush教程
mipush的下载：mipush下载
什么是统一推送?
有关于mipush先说说“统一推送”这个概念：
其实统一推送早应该出来了，只不过国内环境肮脏且无人管理，苹果推送和国外的谷歌fcm已经做到了。
统一推送是干什么的呢？
早期国内的app缺乏管理，应用自己有推送通道。
但条件是应用和推送进程必须活着，也就是国内应用为了活着要多流氓有多流氓。
不说别的，我们单算这些推送进程，算你一个app一个10mb的内存占用，你看看10个多少？
1个g了，够开一个游戏了不？
qq的推送进程 一个100mb
但今非昔比，我们现在已经人均mipush的时代已经无需此顾虑
你只需要一个推送服务，然后让这些app注册到推送服务上，这样就可以用推送服务代替app接收通知了。
即使是app死了，推送服务都会接收消息。
但这样大家想没想过一个问题，我是装了推送服务，那么在app活得时候我不就会收到两个通知了吗？
能反思这样的问题十分好，于是在第三方的推送服务是有这样的逻辑的：
-
在app的消息推送接口打开的时候“第三方推送【例如mipush】”是不会推送消息的,noa在冻结之后虽然消息通知接口还是打开的
-
但“保持连接”按钮关闭的时候，noa会在应用冻结的时候关闭推送socket【接口】，这样第三方的推送就可以推送消息了。
利用这个特性
noa+推送服务才可以做到qq不杀后台也可以实现苹果的“消息接收中”转圈效果，也就变相省电了
好了，本文就到此结束。超级究极完整篇继续详细填充了一些“对于某些人没必要的知识”。我详细这篇文章对您是很有用的。
我的教程免费，并且我也付出了一定量的时间。我不要求什么回报，我的理想就是让大家都能一起开心的使用墓碑，然后吹吹水聊聊天，我喜欢这样，毕竟大家都喜欢手机更好使，大家都开心!
不同手机有不同的内核版本，不同的系统，甚至有不同的模块，都会导致有一些莫名其妙的错误。我的教程只能针对正常情况下的问题，具有局限性。
所以墓碑没办法抄作业，也更没有一个能照抄一套的完美解决方案。作者都做不到更别提我这种搬运工了，我目前跟我交流过的百分百舒服的都是自己折腾出来的。
- 本文链接：https://bzmshang.top/Noactive-starrhymelodge
- 版权声明：本博客所有文章除特别声明外，均采用 『CC BY-NC-SA 4.0』 许可协议。转载请注明来自 『冰梦博客』!
