备注：本文为笔者对工作中沟通相关事项的技巧与方法的总结，有一定片面性，请酌情参考。

工作中总是在提高效沟通，沟通前准备，沟通中技巧，沟通后跟进。step by step执行。诚然，如果能将日常所提到的高效沟通的方法论执行到70%以上，日常工作效率一定会有一个质的飞跃。但是到这个时候，也往往会陷入另一种瓶颈：沟通的第一目的，即信息上的流动于对齐，确实非常高效的达成了，但是往往还是无法到达自己心里最终的目的地。

由于国家公祭日等一些原因。我们客户端也需要将部分核心页面置灰。虽然可以通过预留的大促方案或者主题化方案进行配置。但是，1. 相关方案的配置并不彻底，一般多多少少会有遗漏的地方，那在这类场合会相当眨眼。2. ugc内容无法控制。因此，我们需要尝试一个更通用的方案进行处理。

方案对标

现代电商类应用很常见一种“双向联动列表”的设计，比如京东分类页类目列表的顶部tab联动锚定：


并且行业内各种移动端组件库也有类似的输出：https://taro-ext.jd.com/plugin/view/5edf005bbe897edf72b35ea8。不过看起来真正用这样的组件的人并不多——就算用肯定也是自己开发的。究其原因，我们在讨论某个场景是否适合使用这个交互方式的时候，注意到几个痛点：

最近遇到一个内部企业应用由于业务发展需要，毕竟现在国内线下拓客逃不掉微信，因此需要这个内部应用也接入微信分享来辅助线下提效。接了一半，才注意到在年初加入规则，未上架应用一天只能分享100次。这不完犊子了嘛。但业务诉求很强烈，由于我们分享目标是用户端小程序地址，因此我们立刻意识到，分享小程序二维码的图片，即调用系统分享的图片分享，就可以解决这个问题。

背景

参考mPaaS等比较理想化的客户端native组件解藕落地方案，我们已经把各个基础SDK解耦了，非常理想的情况下我们可以在podfile里指啥引啥，不依赖别的任何东西了。但是这样做会有一个副作用。比如我有一个定位sdk，原本初始化的方式是：

- (BOOL)initLocationServiceWithUUID:(NSString *)uuid
                           clientID:(NSString *)cilentID
                            authKey:(NSString *)authKey;

看起来很自然。但是由于定位下游会进行网络请求，因此在定位sdk的解耦过程中，为了把网络请求解开，初始化过程变为了：

之前UC提出了一个webview容器增强方式，NSR(https://www.infoq.cn/article/9UKos4Xh_6wL4Fh1FOGL)即Native Side Rendering。听着很玄幻但是其实就是将常见的webview本地优化方式的一个极限做法，如果要用人话描述的话，就是本地SSR+请求预加载+同构的集合体。为什么要请求预加载：肯定要做请求预加载的；为什么要本地SSR而不是资源离线化：其实可以，但是离线化无法解决spa应用在webview中初始化与渲染的耗时；为什么要同构而不是用rn或者weex之类的看起来离线化根彻底性能能达到相同目的的方案而是死折腾web：技术栈收敛并且业务场景受限。

之前用canvas手动编写了光照/阴影绘制（https://lrdcq.com/me/read.php/110.htm）与空间阴影/投影绘制（https://lrdcq.com/me/read.php/115.htm），接下来花了相当多的时间了解实时图形学工程实践中光线反射是怎么解决的。当然，除了光追，实际使用的最多的都是类似于预渲染或者探针类构建时方案，要么就是多个摄像机成本极高，唯独屏幕空间反射SSR（Screen Space Reflection）能一定程度的做到较高精度低成本实时反射渲染，也可以快速上手写demo试试。

Demo：https://lrdcq.com/test/ssr-canvas/，确实相当卡，就不嵌入iframe了。

在ReactNative使用过程中，我们遇到一个特殊动作下Android端RN页面直接卡死的场景，本文记录该卡死的排查过程与原理分析。

问题现象

月初的时候llvm仓库出现了一个巨大的pr:[Implement __attribute__((objc_direct)), __attribute__((objc_direct_members))]（https://github.com/llvm/llvm-project/commit/d4e1ba3fa9dfec2613bdcc7db0b58dea490c56b1）。简单说起来就是为oc语言添加了direct方法的功能。direct一看就是说的Direct Dispatch的，让oc像普通静态语言那样方法直接调用来提高性能（而不是Message Dispatch）。

最近在内部群里有一些讨论，主要是各种重构重构和重构遇到的困难，和里氏替换原则真的是一个可执行的原则么，特别是iOS日常业务开发上。我们的结论是，麻烦！但是可以解决问题！
里氏替换原则是我们六大设计原则中存在感最弱的： “派生类对象可以在程序中代替其基类对象。” 也就是说，任何子类通过某种方式均可以保持和其父类一样的行为。