论安卓铁屋中的囚徒

近来夜读《天工开物》，忽见西人所谓"安卓系统"者横行于世。街巷间尽是垂首划屏之辈，倒似当年阿Q画押时伸长脖子的模样。忽忆起前日里见几个后生围坐争论SDK封装之事，面上俱是青白颜色，仿佛被困在代码筑就的铁屋里。

"封装本是极好的物事，怎地倒成了作茧自缚的勾当？"

一、类与接口的吃人筵席

观今之安卓开发，Activity好比未庄的老秀才——看着体面周全，内里早被各种回调蚕食得只剩空壳。onCreate()里塞着视图初始化的皮肉，onDestroy()中吊着资源释放的残骨。

  • 视图绑定如裹脚布：findViewById这等老物什仍要后生们亲手摆弄，倒似新青年偏要穿前朝的朝靴
  • 生命周期似无常索：横竖躲不过configuration change这等鬼打墙的把戏
  • 回调地狱若阿鼻狱：AsyncTask坟头的草已三尺高，却仍有孤魂野鬼在LiveData的回调链里徘徊

二、封装的药与刀

有识之士欲造救世良方，将BaseActivity比作华老栓的人血馒头。abstract class BaseActivity : AppCompatActivity() { ... }——这行代码写得愈工整，倒愈显出吃人筵席上刀叉的寒光来。


class MainActivity : BaseActivity() {
    // 层层继承之下
    // 竟不知父辈在onCreate里埋了多少定时炸弹
}

君不见Jetpack组件库虽好，ViewModelProviders这等旧制仍如九斤老太的裹脚布般又臭又长？幸而后来者用起by viewModels()，方知委办代理之法可破这层层枷锁。

三、组合之道的新曙光

"从来如此便对吗？"狂人的诘问在IDE中回响
旧法继承新派组合
BaseActivity
↓
BaseXxxActivity
↓
具体业务类
class MyActivity : ComponentActivity() {
  // 功能模块化注入
}
多级父类控制反转难
单一职责接口灵活装配
钻石继承困境
(Diamond Problem)		装饰器模式扩展无忧
 
// 网络模块化作鹰犬
interface NetworkDelegate {
    fun fetchData(callback: (Result) -> Unit)
}

// UI控制权收归中央
class ViewController(private val root: ViewGroup) {
    fun showLoading() { ... }
}

// Activity终成光杆司令
class CleanActivity : AppCompatActivity() {
    private val network = RetrofitDelegate()
    private val views = ViewController(findViewById(R.id.root))

    override fun onCreate(...) {
        network.fetchData { result ->
            views.updateUI(result)
        }
    }
}

* 此段伪代码乃仿照当下流行架构所作,望读者明鉴其中真意。