没事，隔壁 android studio 比 xcode 还要难用。

7890 这个显然是你的梯子代理端口

就想当年 windowsphone8 ，把系统音乐、照片这些音乐和系统拆开了更新，结果这些新 App 做的还没老版本好，功能界面都达不到老版本的程度，后来 windowsphone 就没了。

是的，别说预览了，就是代码提示都卡，输入都卡。而且还能把系统界面页带卡了。

肥皂水

还记事本小时种呢，估计你连上架都没法上，直接被以同类应用过多而被驳回。

播放音乐就行了，哪来那么多文章。

台湾以前半导体产业发达，很简单的原因。

那个只是一个声明，没有代码检查也不可能有代码检查。如果你找到了他偷你数据的证据，你可以拿着这个声明去法院告他。

可以在 for of 里用 awit 顺序执行

@GreatAuk 新架构主要解决性能方面的问题，问题是 RN 就不是一个主打性能的方向，RN 能挖掘的深度也有限。

不会拉黑，你可以在更新说明那里解释一下你只是换名字。

@darkengine 对。0.7 之后模版默认开启新架构，但是你可以不用 turbo native modules 和 fabric 相关的功能就行。用了之后一些第三方库还没适配会出错，浪费时间。

一般确诊心肌梗塞就不让患者出院了，准备好 3 ～ 5 万块钱做手术。
药物治疗除非患者症状真的很轻。

急性期就两种手术方式，微创手术就是心脏支架，从手臂或者大腿的血管放一根金属丝到心脏附近血管堵塞处放一个金属支架，撑开血管保障血液流通量。这样心肌恢复供血，恢复心肌功能。这个金属支架国内之前做改革已经不卖外国的了。国内的比较便宜，但就是金属支架，国外的是高分子材料，会随着时间慢慢溶解消失。

心脏支架是微创手术，出血少，时间快，最快半个小时做完。主要看病人要放几个支架，支架数量越多风险越大。

另外一种开放性手术是心脏搭桥，就是切大腿的一段血管给替换掉心脏附近堵塞的血管，这种手术风险很极大。一般作为微创手术的后备方案，即微创手术过程中血管破裂之后的应急手段。或者患者血管过于狭窄，金属丝无法抵达患处。

然后这个病年轻化趋势也比较明显，上次看见一个 20 ～ 30 的男人去做手术，叫前女友来陪的。

React Native 你如果只是部分迁移，一部分页面用 RN ，大部分用原生。实际上操作可能需要你建两个工程的。
正常 RN 开发你可能也需要两个工程。简单的说就是两边依赖的版本可能不一样，安卓可能某个依赖能工作，但是 iOS 那边不行，你得切换版本。如果你不想切换的时候重新 yarn 安装依赖。你可能需要建两个工程。

就算你在一个工程里做双端的，你也是 xxx.android.js xxx.ios.js 这种分开处理的时候会比较多。两边好处是逻辑代码大部分一样，但是具体代码还是要分开来修改的。

但是相比原生的每次修改都需要编译才能看效果，RN 的动态预览将效率提升了太多。而且因为你用的是 js ，不用每次都编译，电脑也会凉快不少。如果是 iOS 那种预览，电脑得卡的要死，而且超过一定的代码量，就不给你预览了。

如果你决定了用 RN ，千万不要马上使用 RN 的“新架构”，现在坑还很多。

一种就是作品借画师的名气，画师会按他的想法和参考你的要求画出来，但是你提意见的地方不多，也不会后期给你确认反复修改。
一种，画师只是个没名气的代工，自己没有流量，批量作画的机器人。甲方要求贼几把多，画出来总是达不到要求要经常修改。AI 作画就是要挤兑这部分工作者的资源。

这类问题隔一段时间就会有人问。
对于前端来说，网络连接问题是最优先的，其次才是后端返回的各种数据异常问题，反正异常处理就这样分层了。

请求成功返回 200 ，前端就知道网络请求成功了，然后再去判断这个请求是否业务上成功。
异常提示字符串直接从后端返回 json 里取，这样大大减轻了前端的工作量。
后端只返回几种意义不明显的状态码，前端还要了对照这些状态做不同的显示，没点效率。