A
跟后面的 113 题类似，只是这个更简单一些。
除了利用递归思想外，还要把问题从“加法”转换为“减法”。
递归的终止条件为：当前结点值与当前传入值相等，并且当前结点为叶子结点，则返回 true，否则返回 左右子树的递归的或运算，注意，左右子树递归时，传入的 sum 为 sum - root.val，这就是前面所说的“将加法转换为减法“，也是简化该题目的核心；
R
Stop Using Post/PostDelayed in Your Android Views
★★★★☆
文章主要内容可分为两部分
-
使用 view.post/postDelay （其实都是借助的 handler）的缺点；
-
post 方法，一个常见的使用场景是，在 View 显示出来时做动画，因为要获取 View 的位置或者大小，来设置动画的属性，所以要保证 View 执行完 measure 方法。
-
存在的问题是，不能确定下一个帧就能执行measure，而且这种代码看起来就很 heck。
-
postDelayed 方法，很容易出现的问题是：当 delay 完后，如果在回调函数里又用到了该 View，此时页面可能已经销毁后者 View 已经被销毁，而出现 NPE；如果使用这种方式，要时刻想着在合适的时机将 callback 移除：view.removeCallback(**Runnable)
-
建议使用 OnPreDrawListener 和 OnGlobalLayoutListener 代替；前者会在 View 将要布置时通知，此时 View 已经被 measure；后者在 View 的状态改变时通知；
T
组合优于继承、面向接口编程的体会
最近做了一个小需求”webivew 创建保护“，简单来说就是创建 webview 对象时 catch 异常（因为部分机型 webview 组件找不到或者被停用时会崩溃）。
项目中有 BrowerView，是继承自 WebView 的，使用 BrowerView 的地方众多，甚至还有直接在 xml 中使用的，这改起来非常麻烦，要在每个创建的地方都修改。而 xml 中的变为在代码中动态创建和 addView。
一个更为合理的方式是，将 BrowserView 的继承改为组合使用 WebView（BrowserView 最好继承自某个Android 的某个 View），好处是，只需要修改 BrowserView 内部创建 WebView 的地方，外部使用（包括 xml）BrowserView 的地方几乎不用动。这就彰显出了”组合优于继承“。
另外一种设计方案是，BrowserView 依然继承自 WebView，作为对官方控件的扩展，另外使用静态代理模式，比如搞一个 IWebView 的接口，BrowserView 和 BrowserViewWrapper 都实现该接口，BrowserViewWrapper 作为 BrowserView 的带来对外暴露。使用的地方尽量都只依赖 IWebView 接口。这样，对于 webview 的创建保护，就可以只修改 BrowserViewWrapper 即可，其他地方也几乎可以不动。这也体现了”面向接口编程“的优点。
