今天跟大家分享的这个实践，名字听起来有点玄乎，叫“冲突的意志”。说白了，就是我在安卓老项目里头，想往一个旧列表里塞新东西，结果系统死活不配合，非得跟我对着干的这么一个糟心过程。
接手任务：给老物件加新零件
任务很简单，领导说，有个用了好几年的安卓页面，现在要加入一个动态的新功能展示区。这个区，不能替换掉原来的内容，得老老实实地贴在旧内容的最下面。我一听，这不就是标准的追加（Append）操作吗？我想都没想，直接说“没问题，一天搞定”。
我动手了。
我直接找到了那个页面对应的布局文件。这布局文件简直就是一坨“史前遗迹”，里面嵌套着好几层自定义的ScrollView，然后包着一个巨大的LinearLayout。我的目标就是把我的新动态列表，作为一个子View，直接塞到这个LinearLayout的末尾。
冲突爆发：系统的不配合
我写好了适配器，准备好了数据模型，然后用最原始的办法，直接调用了父布局的addView方法。我信心满满地跑起来，结果，系统马上就给我泼了一盆冷水。
- 新加的内容是上去了，但是位置总是奇奇怪怪的。
- 更要命的是，每次我拉动屏幕的时候，新加的这部分视图，老是跟上面老的那些内容抢地盘，数据渲染得错乱，偶尔还会闪一下，感觉像是被系统无故“砍掉”了一块。
我当时就觉得，这哪里是写代码，这是跟系统的渲染机制在打架。每次我Append上去，它就立马要给我重算尺寸，而且算出来的结果总是不尽如人意。它好像在用一种沉默的方式拒绝我：“你塞进来的这个东西，不是我想要的。”
掰手腕：凌晨三点的调试
我开始折腾。我怀疑是不是线程的问题，所以我尝试着把所有Append的逻辑都强制扔到主线程里跑，确保它不会在后台偷偷摸摸地操作UI。结果？界面卡顿更明显了，但错乱问题依旧。白折腾。
我开始研究那个“史前”LinearLayout的各种属性。我发现这个老前辈布局，对子View的测量（Measure）和布局（Layout）有自己一套非常执拗的逻辑，它会优先保证它里面固定那几个老View的显示，至于我这个新来的“私生子”，它根本不放在心上。
我那晚真的跟系统杠上了，一直抠代码到快天亮。我试过给我的新列表手动设定一个固定的超大高度，想着这样总不会被挤压了？结果，虽然高度是有了，但界面下方多了一大块空白，丑得要命，而且还是时不时会错位。
最终的胜利：土办法治大病
当我快要放弃的时候，我冷静下来，喝光了一口隔夜的凉咖啡。我意识到，不能直接让父布局去处理这个“陌生”的子列表。我需要先驯服它。
我改变了策略。
我没有直接把我的动态列表Append进去，而是先创建了一个全新的、简单的、只做容器用的FrameLayout（就是个框子），然后把我的列表塞进了这个框子。我把这个小框子作为整体，再Append到那个大布局里头。
光是这么做还不够，关键是数据绑定。为了彻底避开父布局在渲染时期的“干扰”，我用了一个特别土但特别有效的办法：强制推迟执行。
我让Append操作先执行，布局先添加上去，但是列表的数据填充，我把它放到了一个延时执行的队列里（用了那个很老派的post(Runnable)）。我告诉系统：“你先去忙你的，等所有界面都画好了，你再来处理我这个数据。”
这么一来，奇迹出现了。我的新列表终于服服帖帖地贴在了老内容的底部，不再跟老大哥们抢占资源，滑动流畅，数据准确。我的“意志”终于强过了系统的“冲突”。
搞定之后，我瘫在椅子上，感觉这活儿比新开发一个应用还累。这经验告诉我，在老项目里加新东西，很多时候比从头写一个还要耗费精力，因为你要跟代码里那些陈年的“习惯”做斗争。这个实践，就是记录我跟安卓布局系统的一次艰难又值得的心理战。