遊戲/程序/更新/二次開發/小作品相關發佈
Jun 28
iOS14开放给开发者的大一统的小控件WidgetKit出来了。作为“抄袭安卓”的必不可少的一步。初探下苹果如何在偏向于安卓的高自由度,高可配,和自己风格的安全,隐私,高性能之间作出平衡,最终设计出的这个WidgetKit呢。

概览

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

方案对标
Mar 28
现代电商类应用很常见一种“双向联动列表”的设计,比如京东分类页类目列表的顶部tab联动锚定:
點擊在新視窗中瀏覽此圖片

并且行业内各种移动端组件库也有类似的输出:https://taro-ext.jd.com/plugin/view/5edf005bbe897edf72b35ea8。不过看起来真正用这样的组件的人并不多——就算用肯定也是自己开发的。究其原因,我们在讨论某个场景是否适合使用这个交互方式的时候,注意到几个痛点:
Feb 28
最近遇到一个内部企业应用由于业务发展需要,毕竟现在国内线下拓客逃不掉微信,因此需要这个内部应用也接入微信分享来辅助线下提效。接了一半,才注意到在年初加入规则,未上架应用一天只能分享100次。这不完犊子了嘛。但业务诉求很强烈,由于我们分享目标是用户端小程序地址,因此我们立刻意识到,分享小程序二维码的图片,即调用系统分享的图片分享,就可以解决这个问题。
Feb 26
背景

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

看起来很自然。但是由于定位下游会进行网络请求,因此在定位sdk的解耦过程中,为了把网络请求解开,初始化过程变为了:
Feb 20
之前UC提出了一个webview容器增强方式,NSR(https://www.infoq.cn/article/9UKos4Xh_6wL4Fh1FOGL)即Native Side Rendering。听着很玄幻但是其实就是将常见的webview本地优化方式的一个极限做法,如果要用人话描述的话,就是本地SSR+请求预加载+同构的集合体。为什么要请求预加载:肯定要做请求预加载的;为什么要本地SSR而不是资源离线化:其实可以,但是离线化无法解决spa应用在webview中初始化与渲染的耗时;为什么要同构而不是用rn或者weex之类的看起来离线化根彻底性能能达到相同目的的方案而是死折腾web:技术栈收敛并且业务场景受限。
Jan 24
之前用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了。
Jan 17
在ReactNative使用过程中,我们遇到一个特殊动作下Android端RN页面直接卡死的场景,本文记录该卡死的排查过程与原理分析。

问题现象