docs: Weex

Chapter1 - iOS/1.74.md

@@ -6634,6 +6634,27 @@ typedef NS_ENUM(NSUInteger, WeexAPMType) {
 };
 ```
 
+统计线上数据发现，Weex 页面渲染失败率为4.09%，所以看上去页面渲染失败率还是蛮高的。目前发现失败率最高的场景为 App 启动时候按照功能模块组织的配置清单。
+类似于下面的配置：
+```
+"//goods/detail": {
+    "configParams": "",
+    "js": "https://xxcdn.cn/bizName/Phone/Goods/detail.js",
+    "id": 00001,
+    "pageId": 00101,
+    "md5": "f2d8d44bc6d5693b46fb7849bcd00e50"
+},
+```
+
+因此，针对于这样的场景。我们希望针对 Weex 资源的拉取和访问机制做一些优化。
+目前有几个流程不太合理：
+1. 当前启动时的js 预载入流程里的JS下载失败 和 进入Weex页面后的JS拉取失败 两处的上报失败未做区分，没法实际统计加载页面时有多少JS获取失败的情况。
+2. 随着业务迭代， Weex 页面越来越多，需要做 JS 拉取相关优化，避免白屏问题
+3. 目前 JS 缓存逻辑为，每个 Weex 模块单独维护一个 LRUCache，并且会做大量的预加载，但可能大多数页面根本不会访问到。浪费了内存资源去做了一些不会被调用到的页面预加载，可能还会造成 OOM 问题
+![](https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/WeexResourcePull.png)
+
+// todo? 参考前端资源模块化，如何实现资源预加载（全局 LRU或者基于用户行为路径的预热功能，比如某个收银员角色固定的情况下，他日常的操作行为是固定的，商品扫码、开单）
+
 
 
 ### 2. Flutter 异常监控
@@ -6727,6 +6748,8 @@ typedef NS_ENUM(NSUInteger, WeexAPMType) {
 另外随着问题的暴露或者技术研究的渗入，监控方案本身是可以迭代演进的。
 
 
+1. 8060 会有特例，比如8060满足了，且此时主线程空了。因为某个 ImageView 在子线程上根据 URL 异步请求资源，之后会再次触发渲染。所以这个情况下，方案还是存在问题的
+
 
 ## 十一、 APM 小结