标签：至少1个，最多5个
开篇之前,先讲一个自己开发中的一个小插曲:
今天周日,iOS版 App 周一提交,周三审核通过上架,很给力.不过,中午11:30的时候,运营就反应某个页面有一个很明显的问题,页面没法拉到底部,部分信息显示不全;那个页面是基于react-native写的,项目中本身已经有了热更新的相关机制;原因很简单,13:00左右,解决问题,发了一个补丁,测试环境自测完毕;补丁发给Leader,他可以提交到线上;出去吃饭,13:00 回来午休;14:00,Leader回到工位,补丁提交到线上;确认补丁生效,问题解决.
不要吐槽说,流程可以更优化,解决的问题更快,这涉及到另一个话题,改日有心情再聊.
如果按照没有热更新能力的解决流程,大致会是:
11:30 发现问题,13:00 解决,确认测试环境生效;生成测试包,上传 提交;人品好的话,可以走紧急审核;3~5天后,问题修复.3~5天的审核期,有人认为很长,有人早已习以为常.
小插曲而已,看看就好.我只是想让大家明白,react-native本身,可能对你的业务,确实是一个很有意义的工具,仅此而已.许多人,也是认同 react-native 的价值的,但是可能并没有在自己的项目中应用,而没有应用的原因,相对一部分原因,是很难驾驭.从我目前的实践来看,没有一个能够同时自由驾驭Native和react栈的技术人员存在,一个技术组是很难有可能把react-native应用起来的.因为前期,必须有 native 技术栈的人,去填补一些可能用react比较难实现的功能;中后期,又必须 有 react 技术栈的人,来深入地利用react本身的技术栈,来提高开发效率,比如redux的应用等.
类似的例子,我是见过一些,有死在 node 环境配置的,有卡在 native 已有应用无法集成的,当然,也有卡在不知道 如何下手使用 react-native的 的热更新能力的.
热更新,本身机制的设计,网上讨论的也是有一些,一个最简化的模型是: react-native 是基于 main.bundle 加载的; main.bundle 本身是一个文件夹;每次打开app,都去查看有无最新的 main.bundle,有就下载更新本地文件即可.blablalba.....会涉及到许多细节问题,但我相信,一个搞Native开发的人,是都可以独立解决的.
今天,要说的问题是, main.bundle 里,是包含所有的资源文件的,现在发补丁,我是整个 把最新的 完整的 main.bundle 发出去了,本身压缩后,不到 1M,和一个大图片也差不多,基本用户无感;但我现在是需要逐步把原生的部分代码,逐渐迁移到 react 来的,其中的比较基础也比较关键的一步是,把 原先Native代码中的资源文件,迁移到 main.bundle 里,使用 main.bundle 管理.
好吧,不要又吐槽我说, main.bundle 里,是不会打包未使用的图片的; 我的确是,手动把图片放到 main.bundle 里的,里面新建个 native 文件夹,用于放置 native 代码需要的一些资源,这样 native 代码,也可以部分使用 热更新的逻辑了.现在项目中,热更新的逻辑有两部分: JSPatch 和 react-native,我是通过 一个 补丁类型字段来区分的.如果为 native 和 react单独分开设计 热更新机制,想想都心累--或者说,有点太懒,有些代码,还不想去动.--别怪我话多,这是一个很有价值的策略,如果你也是基于Native来混编react-native的话,或许有种茅塞顿开或者英雄所见略同的感觉,虽然我只在iOS上试验过.
有点跑题了,再次试图回归正题.说到两个main.bundle 比较diff出一个差集,网上讨论的很多,大家搜下,勉强多少有些可以借鉴的.index.jsbundle文件本身的diff,我暂时不考虑,感觉没必要,压缩后 只有 300 k的东西,还不值得我去改热更新的实现代码,而且 jsbundle 本身的机制一直在变,比如最近的 jsbundle 都有个了一个对应的 index.jsbundle.meta 文件,原来的设计,可能是有问题的;我今天要讨论的只是,文件级别的 对比操作--简单说,就是 找到两个文件夹中不相同的文件,放到第三个文件夹中,就这样.
有人说,可以比较 md5 什么的--当然也是可以的;但是,我现在不想去知道这个原理,或者说,原理我是知道的,我不想去实现这段代码,没写过,谁知道有什么坑呢?比如,文件目录结构如何保留什么的.我想知道的是,有没有一种简单的方法,一个ctrl+c ctrl+v,就可以直接得到答案问题的方法?
当然是有的, shell 脚本嘛,什么不可以搞,如下:
rsync -aHxv --progress
--compare-dest=$(pwd)/main_old.bundle/ $(pwd)/main_new.bundle/ $(pwd)/main.bundle/
find $(pwd)/main.bundle/ -type d -empty -delete
好吧,脚本本身确实不难,只是我自己刚好需要用到,google出来,再分享给大家而已.我相信,一个深度使用 react-native 到项目中,并且比较依赖其可以热更新特性的人,是肯定有这个需求的;而且,我也知道,他们相当一部分,要么不能准确地问出问题,要么傻傻地自己去写 文件夹对比的代码...我不能说那不对,我想说的是:
编程这种东西, 多学点总是好的.此处奉上原始google参考链接,与原始答案有细微不同,懂shell的人,一眼就看的出来,不懂的,估计就算搜到答案,也有很大几率弄不出来结果.链接奉上:
还有就是,react-native 我很看好它,虽然它很有可能将来把我自己的饭碗给砸了.大势所趋,没办法;浪潮之下,要么开车,要么被压平成路,硬着头皮上吧,万一大家以后都用这个搞了呢...
0 收藏&&|&&3
你可能感兴趣的文章
3 收藏，2k
26 收藏，2.1k
3 收藏，397
本作品采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可
分享到微博？
你好！看起来你挺喜欢这个内容，但是你还没有注册帐号。 当你创建了帐号，我们能准确地追踪你关注的问题，在有新答案或内容的时候收到网页和邮件通知。还能直接向作者咨询更多细节。如果上面的内容有帮助，记得点赞 (????)? 表示感谢。
明天提醒我
我要该，理由是：React Native（1）
当我第一次尝试ReactNative的时候，我觉得这只是网页开发者涉足原生移动应用领域的歪门邪道。
我认为一个js开发者可以使用javascript来构建iPhone应用确实是一件很酷的事情，但是我很快放弃了自己去使用它的念头。毕竟我因为爱好而从事ios原生开发多年，并且目前为止已经很熟悉这一套开发专业工具。
我已经创造了一些我引以为傲的iOS应用——一些使用Object－C和Xcode构建的应用，通常人们都是这么做的。这两样工具是苹果公司提供的、用来开发iOS应用的，所以，我和其他的苹果开发者都在用。并且当两年前苹果公司发布Swift时，我也毫不犹豫地去尝试它。
Swift依旧被使用在Xcode中，并且依旧是苹果公司推荐的开发方式，所以我很快地深入，并且毫不费力地学会了这门语言。我满足于我的苹果生态系统圈。React Native看上去只是一个小小的乐子，在我的脑海中，一切原生应用必须被 原生 地开发。对正要开始掌握 原生 开发方式的我来说，学习javascript（我并没有这方面的经验）和一种几乎全新的构建app的方式简直是荒废时间。
时间快进到几个月过后，我可以打保票说，我再也不会使用Objective－C或者Swift来开发iOS应用了。
我们接手了一个新的移动应用开发项目，我大概的看了一下设计和需求。正当我要点开Xcode那漂亮的蓝色图标新建一个新的工程时，我们的交互设计师，Adam走过来说，“我们用React Native来做这个东西吧。”
他解释说，这个项目合同的一部分明确提及了要给这个应用做一个安卓版本。尽管React Native并不支持安卓，我们知道Facebook正积极地在这方面研究。理论上来说，如果我们用RN构建了这个应用的iOS版本，很多部分能够直接工作在以后的安卓版本上。
好吧，我并不乐意。我觉得我已经站在了iOS开发能力的顶峰，现在却要我把这一切全部丢弃。在不可避免的学习曲线面前，我怀疑我是不是能够及时地发布一个高质量的产品。但除此之外，我更加质疑RN是否有能力成产一个高质量的产品。现在看来，我甚至没有觉得这样的质疑是不公平的。当时RN作为一个Beta版本刚被公布不久，文档欠缺，开源库和组建的数量稀少，演示代码或者Stack Overflow上的参考几乎没有。
我连看都不想看它一眼。但是我这种闭塞的态度只会带来更多的不良后果。我的第一道坎是学习Flexbox，RN制作UI布局的方式。从最基础的界面构建器开始，纯粹使用代码来布局UI几乎击溃了我的自信。我挣扎着去构建最基础的视觉效果。
但不仅仅是UI——任何事情都变的不一样。这对于我是最大的挑战。
”每当我止步不前或者不理解的时候，我就告诉自己“如果用Objective－C我能够在五秒钟之内解决它”。每当我发现了RN中的一个BUG（并且bug的数量非常大），我就会想，“oc中根本不会有这种bug，我为啥一定要和RN斗智斗勇呢？”
整整两个星期，我都在工作中痛苦挣扎。我对自己的感觉从一个杰出的iOS开发者变成了一个从未写过一行代码的人。这很受挫折，直到我花费了整整一个礼拜理清了思路。我后退一步，认识到Adam对RN做了许多研究。作为我的交互知道，我不得不信任他，相信他没有把我领入一条错误的道路。我发誓我要在周一投入工作，埋头苦干，假装Objective－C和Swift从来没有存在过，并解决这个项目。
学会去喜欢React
几周之前，我们向App Store提供了第一个React Native应用。对于应用的最终表现结果我真的非常自豪，并且我迫不及待的要开始构建下一个项目了。在仅仅一个月多一点的时间里，我完全踏上了RN的贼船，是什么改变了我的想法呢？
React 范例
在React中，所有UI的组件都被放置在render（）方法中，并且被state状态控制。你的render（）方法定义了UI在各种状态是如何展现的。当调用setState()的时候，React会找到需要改变的部分并替你修改。想象一个简单的视图，拥有一个“Hello World”标签和按钮。每点击一下按钮，标签会在“Hello World”和“Goodbye World”之间切换。在Objective－C中，我在按钮的句柄中需要一些难堪的if声明，就像下面一样。&
if([label.text isEqual:@”HelloWorld”]){label.text&=@”GoodbyeWorld”;}else{label.text&=@”HelloWorld”;}
这样很有用，但是这种UI代码和我第一次创建这个标签的地方（可能在代码中，也可能在界面构建器里）完全脱节。在React中，我们会在state状态中定义一个buttonClicked的bool变量，在render()函数中，标签看起来会是这样的:
&Text&{this.state.buttonClicked ? ‘Hello World’ : ‘Goodbye World’}
并且我们的按钮句柄也会非常简单
this.setState({buttonClicked:!this.state.buttonClicked});
所有和可视化相关的代码都在同一地方，并且由状态控制一切。这使得理解和修复这段代码变的非常容易。
这就是我一开始非常痛恨的UI布局工具，现在变成了RN中我最喜欢的事物之一。我承认一开始非常难以掌握，但一旦你开始使用，它把 为多种不同尺寸屏幕构建UI这件事 变的机器快速和简单。我曾经对Xcode中的可视化界面编辑器十分热衷，相比于Flexbox，它的自动布局还是国语复杂。Flexbox使用的CSS式样式使得样式重用变的和复制粘贴一样简单。其中最棒的事莫过于允许你在一瞬间将样式值改变到完美。
Live/Hot Reload
没错，想看看按钮右移5像素的样子就和command＋s一样简单。React Native能够被设置为在iPhone模拟器中自动重绘当前画面而不重建Xcode工程。这非常厉害因为你不仅可以通过避免重新编译儿节省时间，你还能够调整一个深度嵌套在应用中的界面，调整UI而不用回到最初的界面。
现在依旧没有发布，但就快了——这一定会非常神奇。在最初我对于ReactNative犹豫不决是因为我已经习惯于做原生的iOS开发。对此我从没有过任何的抱怨。但是我也做过原生的安卓开发，这并不让人开心。React Native在安卓上会变的很瘦欢迎，同时我也在期待它的发布。这会改变移动应用开发的现状，通过使用相同的代码来部署两个平台的应用。
想念 Xcode
我还是会想念Xcode，或者说是一个IDE编辑器。我已经有了一个很好的RN开发设置，但这并不容易，Sublime Text和一大堆的插件让我有了语法高亮。sublime能够完成同一个文件中基于变量的自动补全，但始终少了一些Xcode自动补全的稳健性。我还是不得不一直查询开发者文档做参考。
小缺点，比如键入React.PropTypes.f &IDE并不会告诉我我到底在找func还是function，这很让人困惑。我也怀念Xcode的版本控制——允许我一一比较我上一次git提交的版本和现在的版本，甚至还允许我基于行撤销一些特别的改动。我意识到第三方程序能够帮助我完成这些，但是对IDE来说最棒的事情就是将这些囊括到一个包中。（译者使用VSCode可以解决这些问题）
为了运行RN项目，我需要终端运行npm，Chrome用来debug，sublime来编辑代码，最终还需要Xcode来运行这个项目并打开模拟器。在大项目中，这些都是细小的抱怨，但是当我面对RN的时候这依旧是缺点。对于Nuclide（Facebook的新IDE）我抱有很高的期望，希望它能结束所有的这些缺点。
Facebook还没有也不会去提供所有iOS转向React Native的API，所以对于那些缺失的片段他们提供了桥接js的方法。当我第一次深入RN的时候，这方面的文档非常的糟糕。每当我意识到我需要连接某些事物的时候，我差点就对RN放弃了，因为这些事情早就能够在Objective－C中正常运作。但是当她们更加详细地解释了桥接过程，提供优秀的实例之后，这就无所惧怕了。它仍然是一个麻烦，但是我能够预见到开源社区和nom上会有所有的桥接方案。事实上，大多数的iOSAPI已经存在了。
漏洞，文档，开源社区
大概所有我最初关于RN的抱怨现在都已经消失殆尽，如果我从今天开始学习它的话。漏洞每天都在被修复，新版本每一周都在迭代。文档还需要加把劲，但比以前好多了。Facebook和开源社区对于研发这个框架变的十分严谨。人们开始聚集在Github和Stack Overflow上探讨它。如果你是一个正在考虑尝试RN的iOS开发者，你要知道你不是一个人在战斗。RN非常棒，你应该带着开放的态度拥抱他。不要像我一样吧自己局限在温室里。
走出温室，世界才刚开始。
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：96870次
积分：2052
积分：2052
排名：第18732名
原创：74篇
转载：58篇
评论：12条
(6)(4)(1)(2)(8)(3)(2)(4)(6)(17)(5)(4)(10)(26)(9)(7)(10)(11)你似乎来到了没有知识存在的荒原...
来源链接是否正确？用户、话题或问题是否存在？React-Native 调用 iOS Native 方法 - IOS - 伯乐在线
& React-Native 调用 iOS Native 方法
React Native在设计之初，就考虑到了React Native提供的API,不能够完全的覆盖平台对应的所有API.因此在React Native中可以方便的调用Native的方法，Android上面对应Java方法，IOS上对应Object-C方法。
有的时候在处理数据库，多线程上面，使用Native加的方便。
下面就以调用IOS系统的Alert为例，看下怎么使用JavaScript代码调用Object-C的Native方法的。
RCTBridgeModule
RCT是ReaCT的缩写，React Native中Object-C相关的命名均以RCT开头。
RCTBridgeModule是定义好的protocol，实现该协议的类，会自动注册到Object-C对应的Bridge中。
Object-C Bridge上层负责与Object-C通信，下层负责和JavaScript Bridge通信，而JavaScript Bridge负责和JavaScript通信.
这样,通过Object-C Bridge和JavaScript Bridge就可以实现JavaScript和Object-C的相互调用。
先要定义一个类：RNIOSAlert用来现实RCTBridgeModule协议。
#import "RCTBridgeModule.h"
@interface RNIOSAlert : NSObject
#import #import #import "RCTBridgeModule.h"&@interface RNIOSAlert : NSObject&@end
RCT_EXPORT_MODULE
所有实现RCTBridgeModule的类都必须显示的include宏命令:RCT_EXPORT_MODULE()。
RCT_EXPORT_MODULE的作用是:自动注册一个Module,当Object-c Bridge加载的时候。这个Module可以在JavaScript Bridge中调用。
RCT_EXPORT_MODULE宏命令的定义:
#define RCT_EXPORT_MODULE(js_name) \
RCT_EXTERN void RCTRegisterModule(Class); \
+ (NSString *)moduleName { return @#js_ } \
+ (void)load { RCTRegisterModule(self); }
#define RCT_EXPORT_MODULE(js_name) \RCT_EXTERN void RCTRegisterModule(Class); \+ (NSString *)moduleName { return @#js_ } \+ (void)load { RCTRegisterModule(self); }
可以看到RCT_EXPORT_MODULE接受字符串作为其Module的名称，如果不设置名称的话默认就使用类名作为Modul的名称。
引入RCT_EXPORT_MODULE:
#import "RNIOSAlert.h"
@implementation RNIOSAlert
RCT_EXPORT_MODULE();
#import "RNIOSAlert.h"&@implementation RNIOSAlert&RCT_EXPORT_MODULE();&@end
RCT_EXPORT_METHOD
RCT_EXPORT_METHOD是用来定义被JavaScript调用的方法的宏。RCT_EXTERN_METHOD调用了宏RCT_EXTERN_REMAP_METHOD,最终调用宏RCT_EXTERN_REMAP_METHOD。
RCT_EXTERN_REMAP_METHOD的代码实现：
#define RCT_EXTERN_REMAP_METHOD(js_name, method) \
+ (NSArray *)RCT_CONCAT(__rct_export__, \
RCT_CONCAT(js_name, RCT_CONCAT(__LINE__, __COUNTER__))) { \
return @[@#js_name, @#method]; \
#define RCT_EXTERN_REMAP_METHOD(js_name, method) \&&+ (NSArray *)RCT_CONCAT(__rct_export__, \&&&&RCT_CONCAT(js_name, RCT_CONCAT(__LINE__, __COUNTER__))) { \&&&&return @[@#js_name, @#method]; \&&}
它的作用是在RCT_EXPORT_MODULE定义的Module下面，定义一个可以被JavaScript调用的方法。
RCT_EXPORT_MODULE的使用，需要写入方法名,参数以及完整的实现，例如:
#import "RNIOSAlert.h"
@implementation RNIOSAlert
RCT_EXPORT_MODULE();
RCT_EXPORT_METHOD(show:(NSString *)msg){
UIAlertView * alertView=[[UIAlertView alloc] initWithTitle:@"react-native" message:msg delegate:nil cancelButtonTitle:@"关闭" otherButtonTitles:nil, nil];
[alertView show];
12345678910111213
#import "RNIOSAlert.h"&@implementation RNIOSAlert&RCT_EXPORT_MODULE();&RCT_EXPORT_METHOD(show:(NSString *)msg){&&&UIAlertView * alertView=[[UIAlertView alloc] initWithTitle:@"react-native" message:msg delegate:nil cancelButtonTitle:@"关闭" otherButtonTitles:nil, nil];&&&&[alertView show];&}@end
JavaScript调用
在JavaScript中调用Object-C定义的方法，需要先导入NativeModules,再使用RNIOSAlert：
完整代码如下:
StyleSheet,
NativeModules,
TouchableOpacity
} from "react-native";
var RNIOSAlert = NativeModules.RNIOSA
class RNIos extends Component {
render() {
RNIOSAlert.show('from react native ')}&
12345678910111213141516171819
import {&& &&&&StyleSheet,&&&&Text,&&&&View,&&&&NativeModules,&&&&TouchableOpacity} from "react-native";&var RNIOSAlert = NativeModules.RNIOSAlert;&class RNIos extends Component {&&&&render() {&&&&&&&&&return (&&&&&&&&&&&&RNIOSAlert.show('from react native ')}&&&&&&&&&&&&&&&&&&&&&Alert&&&&&&&&);&&&&}}
成功调用Alert：
RCT_EXPORT_METHOD支持需要JSON所支持的数据类型，JavaScript中的参数与Object-C的参数的对应关系。
string -& NSString
number -& (NSInteger,float,double,CGFloat,NSNumber)
boolean -& (BOOL,NSNumber)
array -& NSArray
object -& NSDictionary
function -& RCTResponseSenderBlock
另外React Navite还提供了RCTConvert,详情的代码可以参照 ,他的作用可以把传入的参数转换为需要的数据类型。
比如我们在Object-C中定义一个方法，该方法接收NSDictionary参数：
RCT_EXPORT_METHOD(showTime:(NSDictionary*)dict){
NSDate * date =[RCTConvert NSDate:dict[@"time"]];
UIAlertView * alertView=[[UIAlertView alloc] initWithTitle:@"react-native" message:[date description] delegate:nil cancelButtonTitle:@"关闭" otherButtonTitles:nil, nil];
[alertView show];
RCT_EXPORT_METHOD(showTime:(NSDictionary*)dict){&&NSDate * date =[RCTConvert NSDate:dict[@"time"]];&&UIAlertView * alertView=[[UIAlertView alloc] initWithTitle:@"react-native" message:[date description] delegate:nil cancelButtonTitle:@"关闭" otherButtonTitles:nil, nil];&&[alertView show];&&}
这里使用RCTConvert直接把NSDictionary中的值转换为NSDate.
在JavaScript中的调用showTime方法:
var date = new Date();
RNIOSAlert.showTime(
time: date.getTime()
1234567891011
...... {&&&&&&&&&&&&&&&&&&&&var date = new Date();&&&&&&&&&&&&&&&&&&&&RNIOSAlert.showTime(&&&&&&&&&&&&&&&&&&&&&&&&{&&&&&&&&&&&&&&&&&&&&&&&&&&&&time: date.getTime()&&&&&&&&&&&&&&&&&&&&&&&&}&&&&&&&&&&&&&&&&&&&&)&&&&&&&&&&&&&&&&}}&&&&&&&&&&&&&&&&&&&&&Time......
源代码地址:
关于作者：
可能感兴趣的话题
关于iOS频道
iOS频道分享iOS和Swift开发，应用设计和推广，iOS相关的行业动态。
新浪微博：
推荐微信号
（加好友请注明来意）
– 好的话题、有启发的回复、值得信赖的圈子
– 分享和发现有价值的内容与观点
– 为IT单身男女服务的征婚传播平台
– 优秀的工具资源导航
– 翻译传播优秀的外文文章
– 国内外的精选文章
– UI,网页，交互和用户体验
– 专注iOS技术分享
– 专注Android技术分享
– JavaScript, HTML5, CSS
– 专注Java技术分享
– 专注Python技术分享
& 2017 伯乐在线ReactNativ（2）
以下均是使用经验之谈，如果有不同意见的欢迎指出。
本人使用code-push做版本更新还是比较多的，确实是方便，只要不需要动到java层的代码，使用code-push来做版本迭代就是非常方便的；
我们的做法：通常都是先思考好技术路线，然后在一定时间范围内（比如半年内版本），把java层代码预先埋入app内部，在使用到的时候再去使用那部分模块的功能，不过ios我们还是不敢那么放得开，一旦出现个什么意外导致我们的app被下架就尴尬了。
学习新技术我还是比较建议大家去看官方的文档，毕竟是比较专业的人写出来的文档肯定是相当完整的，看别人的见解只能是参考。
1、部署这一块建议去github查看：（避免坑）
2、ios与android发布更新的不同之处
1）、说在前面：以下说到的版本是指android的build.gradle里面的versionName，和ios的General的version。
2）、android:
android在code-push发布更新的时候，版本独立不影响的位数是两位数。
举例说明：
①、versionName为2.1，和versionName为2.2的两个app版本，
当versionName=2.2的app发布codepush更新的时候，受影响的只有2.2 和2.2.X，X为正整数。
versionName=2.1是不会收到任何影响的，所以后续就需要创建两条线路对不同的版本进行维护。
②、由①可以知道，versionName=2.2.1和versionName=2.2.2两个版本在获取更新上，获取的是同个版本。
当versionName=2.2.2发布更新的时候，versionName=2.2.1的app同样会受到影响接受更新。
总结：从以上特性，我们主要将这个功能用在小版本更新，或者bug修复上。versionName = X.Y.Z的版本中，我们主要发布到应用市场的软件一般都是改变：X.Y的值。
对于创业公司来说，要维护多个软件版本成本是非常高的，所以我们也是尽量要求用户升级到最新版本。
3）、IOS：
IOS在codepush发布更新时，版本独立不影响的位数是三位数。
即iOS版本都是独立不影响，version=X.Y.Z，当codepush发布更新时，只会影响与其X.Y.Z三位数完全相同的版本。
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：2755次
排名：千里之外
(1)(1)(2)(1)