分类: 未分类

Android 开发中的猥琐与底层

做 sku 的过程中,使用了很多猥琐的技巧。起因是因为,我需要在这个需求中解决几个问题:

  1. 如何使用 RecyclerView 做出 ViewPager 的效果。
  2. 如何在 RecyclerView 中 hook 到几个可 Override 的生命周期。
  3. 如何解决通用容器和专用业务容器的界限划定。

所谓的猥琐,就是阅读一遍相关的 Android 系统源码,然后去 hook Android api 的方法,然后去各种调教他的入参出参,做出自己的私活。

比如每次滑动距离要增加一个固定距离,比如关掉惯性滑动,比如尝试失败的 Recycler 回收 View做出单/多切换功能,比如之前一直没有解决的头图容器二次渲染白色的问题,等等。

说猥琐,其实也还好。Android 中很多现在大家约定俗称的东西,Google 文档里并没有这么写,只是一开始摸索 Android 的人,都这么写了,在网上的文章里也大多这么分享了,大家也就很自然地去做了。比如为什么 remove View 再重新 add View 就不行? 而要重新 new 一个 View ?的确,Android 上这样会有闪烁的问题。但是在有些不需要 care 闪烁的场景,就这么用,有他的好处。节约内存,省掉 GC,无需状态同步,等等。猥琐的方法用多了,也就变成了堂堂正正的路。

真正的问题大概是,对于框架层的东西,没有必要保持敬畏之情,上去干就好了。阅读一遍 google 的源码,就能搞清楚他的一个惯性滑动是怎么处理的。即便是一个 private 的 field,也可以丧心病狂地使用反射把他的值给改了。我们所需要 care 的点始终只是:

  1. 产品上做这个点有没有价值
  2. 如果有,工程上多猥琐的技巧都能把他给做了。
  3. 万一有风险怎么办?try catch,Tlog,orange,abtest,一堆兜底方案,哪怕98%的场景 ok,2%的场景挂了,只要能兜住,新业务能跑起来,2%的场景兜住不 crash,事后慢慢分析就可以了。没准还没分析完,业务先死了,那就更没有分析的必要了。

开发的层面上,没有解决不了的问题。因为开发始终是用快速学习、工程经验、与产品和视觉的沟通,游走在各种我可能不熟悉的领域,变成比较熟悉,做出东西来验证价值。如果有价值,再交给更专业的人去深入深化。如果解决不了,说明这是算法、当前技术水平、等等一系列的问题,不应当到开发层面。否则,只要无节操,多猥琐都能干了。

另一个有所领悟的点是,认清楚什么是自己的底层。过去认为系统的 API 就是自己的底层,那么一旦找不到一个 API 解决自己的功能,就会手足无措。但是,一旦迈出第一步去阅读 Android 源码,hook 系统公用 API 来做私活了,就会觉得,自己的底层又往下了一步。等到用反射去修改 private field 了,就会觉得,节操更低了,但也更强大了。因此,时刻怀疑自己的底层,是否真的足够底层了,也许再低一点,又会有新的突破。