NoWakeLock

  • NoWakeLock 应用计划/说明

  • 更新

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    20.03.04 初始化
    20.03.10 更新
    20.03.13 Log
    20.03.15 Log
    20.03.17 Log
    ... Log
    20.04.08 Log
    ...
    20.04.16 Log,更新应用计划.
    20.04.17 Log
    20.04.20 Log
    20.05.03 ...
    20.05.12 ...
    20.05.26 beta 版计划梳理
    20.06.18 Log
    22.06.17 目前计划整理
    22.11.17 规划一下 2.0 稳定版 计划

目标

  • 终于到了具体项目了,名称什么随便起的,不要在意这些细节.

  • 目标: Amplify 的完整复刻.

  • App 要求:

    • kotlin 实现
    • 符合 Android 官方架构,全部采用 Jetpack.
    • 全面的测试 发布 上架流程.

当前状态(Beta)

  • 1.0.15-Alpha

    • bug
      • wakelock fragment 按钮和唤醒间隔(1.0.16)
  • 1.0.16-Alpha

  • 1.0.20-Alpha

  • 1.0.1-beta

    • 第一个 beta 版本
  • 1.1.0-beta2

    • 设置导入导出完成
    • 调整排序标准 为实际允许的唤醒次数.
  • 1.1.0-beta4

    • 长期停滞版本

当前状态(Beat2)

计划

  • Alpha:

    • Alarm 记录
    • Alarm 限制 Alarm 正则限制
    • 设置项
    • Service 记录
    • Service 限制
    • Wakelock 唤醒时间统计.
    • Xposed 检测
  • Beta:

    • 数据导入导出备份.
    • UI改版
    • 长按复制信息
    • Fragment 具体信息支持
    • 唤醒锁信息
    • 禁用方案加载
    • 批处理操作.
    • 数据重置选项
    • 太极支持
    • 正则改进
  • Release:

    • 应用统计
  • 积攒的博客

    • listadapter 配合datadbing 使用
    • navigation 使用
    • koin 依赖注入的更新
    • 使用 NavigationUI 更新界面组件: fragment 配合Toolbar 标变化
    • 定制神色主题,沉浸状态栏,取MD颜色, Navigatio 居然把菜单跳转都做了..
    • android X 下setting 的设置
    • android 8 以后启动前台服务.添加权限,设置兼容库等,特别对8 8.1 的处理
    • ContentProvider
    • aidl…
    • @VisibleForTesting @Synchronized
    • 依赖注入的viewmodel 和ViewModelProvider 获取的貌似并不是同一个对象
    • 变色icon 只需要在生成的xml 颜色换了就行
    • 原来协程的非阻塞是 不阻塞当前调用的线程, 获取结果的过程是阻塞式的(等待) 需要runblock…大部分情况下,协程都相当于起了另外一个线程,任务扔过去,不管了..
    • kotlin 高阶函数..
    • kotlin 作用域函数
    • sql 内连接
    • 泛型的实例化, in;ine 和 reified

LOGS

(20.03.10)快被 Room 的单元测试搞疯了..明明代码已经写完了,单元测试连启动都无法启动..

(20.03.11)原来是 room 对协程和 livedate 不能同时支持…心累..整理一些更新内容.数据库总算是单元测试通过了.

(20.03.13)到了写的时候什么都计划不了…遇到问题就要改…

(20.03.15)果然什么都计划不了,随时会面临先前的设计问题…不过还好数据结构基本成型了,并且测试通过,计划有变,先做一个单查看wakelock->阻止wakeLock->再拓展到 alarm 和 server.用了大量的协程,希望不会成为性能障碍.

(20.03.17) UI 定下了基本方案.(又要重画地图了,葛某人名言..)

(20.03.18)fragment 坑好多啊,简单的 Android:Onlick 报错,习惯使用 Activity 还真需要适应..好在 Navigation 把生命周期和 fragment 间通信都搞定了..

(20.03.19)好的,底层又大改,参考了官方架构的示例 sunflower ,原来问题还是挺多的,协程虽好,可不要为了用协程而专门设计数据结构.

(20.03.21)头大,总不能一直改下去..先按照最低原则做完…
….中间省略数十天的LOG….

(20.04.08) 上述的总结

  • UI 界面除了一点设置界面的 BUG 基本完工
  • 其实还剩下最麻烦的 xp 部分,数据结构闹不好还需要再修改.
  • ContentProvider 在 xprivacylua 也是用的这个.这个过程需要整理很久,才能稳定.
  • 已经积攒了 N 篇没写,工作的事情也是波折不断.接下来更新应该会慢了.至于能不能4月上线.随缘.

….中间省略八天的LOG….

(20.04.16)

  • 初版已经上传,但是审核真的很慢.
  • 为了谨慎起见,暂定 Alpha 阶段,实际上已经可以作为 beta 版本了.
  • 之后在正式版之前,会持续迭代,直到 Beta 版完成.
  • UI 设计现在在细节上遇到了麻烦,有待解决.
  • 上架的问题,随缘吧.

….中间省略四天的LOG….

(20.04.20)

  • 初版,在酷安已发布,但是xp功能还是很乱,暂时更新频率上不去.
  • selinux 问题,评估后,放弃 XSharedPreferences .
  • 之后是快速迭代,完成 Alpha 阶段开发.酷安更新除非有严重 bug 或功能更新,否则 Alpha 阶段,不会太频繁.

….

(20.05.03)

  • Alpha 过半,Alarm 已经添加完毕,Service 进行中
  • Servie 完毕后,扫荡一下代码,完善一下翻译,进入 beta 版,play 版应该会同步更新.
  • 其他计划还在制定中.

(20.05.12)

  • 重写了 xposed 部分,大量 ipc 问题标记解决.
  • 设置部分可以控制同步的间隔.
  • wakleock 时间统计,提前到 Alpha.

(20.05.26)

  • Alpha 已过,梳理 Beta 版计划.
  • 中间要把 UI 的代码重构一次.
  • Play / 酷安 分别打包还是个问题.

(20.06.18)

  • 版本更迭到 beta2
  • 设置导入/导出测试完成.
  • 计数逻辑调整.
  • 重写了部分数据库,卡了很久,不过最后还是解决了,这样禁用方案的支持也可以进行了.

数据架构

  • hook 后进程请求 NoWakeLock 数据,跨进程通信选择?

    • 暂定 ContentProvider 依附于一个前台 Service.考虑过 AIDL 线程安全不太好弄.
      • 否决,待定.通过 ContentProvider call 调用可以,但是多线程等等处理…还有启动问题,因为要处理全部应用,工作量很多.
    • 还是按部就班来,直接单 ContentProvider.
      • 目前实现,还需要调试很久.
    • 前台 Service + AIDL 还需要额外把 AIDL 文件共享给客户端应用.线程安全还是麻烦, Service 的启动也是问题.
    • ContentProvider 自定义 call 完全够用了.
  • ContentProvider 与 Room 配合?

    • 实际查看后可以保持 Room 的全局单例,然后在 ContentProvider 的 CURD 引用 DAO 方法.
    • 好在 hook 后的进程只需要插入和查询数据.
    • 考虑到性能和数据库的作用是数据持久化而不是即使删改数据,数据模型改为单例的 Repository 持有一个HashMap(套HashMap), ContentProvider 的修改更新只在这个 HashMap 上,在应用结束时保存到数据库.HashMap 的 o(1) 加上在内存中,应该不会有性能瓶颈.
    • 至于内存占用问题,还没到那一步…如果内存占用大,需要换成 ArryMap,ArryMap 是二分查找,性能会有损失.
    • 使用 HashMap 是为了加快查询速度,可原来的设计浪费太多,而且整个应用共用一个 Repository,这根本就搞错了方向,而且带来了各种同步问题.
    • 唯一可信源是全局单例的数据库,为了加快查询采用 HashMap 思路没错,就是设计太粗糙了.
    • 暂时全部否决
    • 已无问题
  • 基础数据结构,Room 数据库设计?

    • appinfo 一个表.
    • appsetting 一个表.
    • wakelock alarm service 3个的表.
    • 设置 wakelock alarm service 3个的表.
    • 限制规则表,同外键约束.
  • 数据架构

    • Room 是 UI 的唯一可信数据源
    • UI 的数据全部由 Room -> LiveData .各自持有对应的 viewModel 和 Repository.
      • AppList: 负责维护 appList 表
      • WakeLockList: 负责刷新 wakelock 表.
    • 后台 Server 持有对应的 viewModel 和 Repository,在 server 中引用 List<WakeLock>,xp 查询修改数据时只针对内存.仅在 server 退出,或手动触发刷新时才写入到 Room.
    • 至于应用中的计数,每次都重置再存储到数据库,UI 的通知由 Room 到 LiveData 自动完成.
    • Room 是唯一可行数据源.
  • 手动刷新流程

    • 重新获取一遍已安装应用,逐个查询数据库是否存在,不存在即新建.
  • 删不删已卸载应用数据?

    • 很难选择,有时只是重装下应用,对应记录删除了不爽.
    • 注册应用卸载广播不太现实,不喜欢这样.
    • 暂时不删.
    • 删除
  • UI 要求更新数据,之前发生了安装卸载怎么处理?

    • 主要问题是 HashMap 和 数据库的同步问题.
    • 如果数据库不清理已卸载,那么 HashMap 也暂时不清理已卸载应用.
    • 对于刷新时新安装的应用,插入数据库创建实例.
  • 安装卸载应用处理(不在初版计划中)

    • 因为对广播的限制,写 service 的时候再定夺.
    • service 注册应用安装卸载广播,实时同步安装&删除.

UI

  • UI 基础设计?

    • 带侧边栏,不带菜单.
    • 带应用栏,增加按照唤醒次数排序.区分系统和用户应用.
    • 次页暂时只选择完成功能,美化等靠后…
    • 带悬浮按钮,保存到数据库.
    • 设置选项中 系统应用 充电时处理.,处理不处理吧,毕竟意义不大.
  • 单 Activity + 导航组件 + 多片段.(又要从头学了..)

xposed

  • xposed 模块如何编写?

    • 初始化 xposed 模块(20.03.04)
  • Android wakeLock 机制?需要找到 hook 的具体方法等?

    • 进行中

应用逻辑

  • 过滤的优先级?

    • 全局黑/白名单最高,区分已内置的规则,对 google play 和 android 系统不轻易开放修改.
    • 应用内设置单个优先级最高.其次应用内正则.
  • 系统唤醒如何处理?

    • 必须非常谨慎,初始版本中只处理用户应用.
    • 基础功能已完善

其他

  • 分支划分问题,现在初版还没就绪,暂时就 Master 和 dev.正式上架后会遵循 3 个分支.稳定版,开发版,测试版.