NoWakeLock

  • NoWakeLock 应用计划/说明

  • 更新

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    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 ...

目标

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

  • 目标: Amplify 的完整复刻.

  • App 要求:

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

当前状态

  • 1.0.15-Alpha

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

计划

  • Alpha:

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

    • 应用统计.
    • 数据导入导出备份.
    • 批处理操作.
    • 太极支持
  • 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 高阶函数..

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.

数据架构

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

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

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

    • appinfo 一个表 + 唤醒的总计数/阻止计数.
    • 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 自动完成.
  • 手动刷新流程

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

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

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

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

UI

  • UI 基础设计?

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

xposed

  • xposed 模块如何编写?

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

    • 进行中

应用逻辑

  • 过滤的优先级?

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

    • 必须非常谨慎,初始版本中只处理用户应用.

其他

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