面试官问你项目？_面试问你开发的项目可以看吗-CSDN博客

本文链接：https://blog.csdn.net/BIBIBIA/article/details/121244891

文章目录

一、为什么学习前端？
二、为什么用RN?
三、RN是怎么实现的？
四、项目的定位
五、怎么通信的
六、什么协议的接口
七、怎么知道他是否执行成功
八、怎么优化的
九、最大的收获印象最深的最成就感的
十、做了啥思路经历
十一、优缺点
十二、收获

一、为什么学习前端？

二、为什么用RN?

综合

1、开发方式
（1）代码结构： React Native更为合理，组件化程度高
（2）UI布局：Web布局灵活度 > React Native > Native
（3）UI截面图：React Native使用的是原生组件，
（4）路由／Navigation：React Native & Native更胜一筹
（5）第三方生态链：Native modules + js modules = React Native modules

2、性能 & 体验
（1）内存：Native最少；因为React Native含有框架，所以相对较高，但是后期平稳后会优于Native。
（2）CPU：React Native居中。
（3）动画：React Native动画需求基本满足。
（4）安装包体积：React Native框架打包后，811KB。相比热更新，可以忽略和考虑资源规划。
（5）Big ListView
（6）真机体验：Native >= React Native > H5/Hybrid

3、更新 & 维护
（1）更新能力: H5/Hybird > React Native > Native
（2）维护成本: H5/Hybird <= React Native < Native

开发角度

代码结构
前端角度而言，React Native跨平台特性，不要开发者深入的了解各平台就能开发一款高效App。同时，语言层面而言，JavaScript运用很广泛，入门门槛相对较低。React Native虽然抛弃了MVC分离实践，但是从业务角度而言，更为合理。一切而言：对前端，对移动领域是利好的消息。
UI角度
React Native既综合了Web布局的优势，采用了FlexBox和JSX，又使用了Native原生组件。比如我们使用一个文本组件。
路由
在Web单页面应用中，路由由History API实现。
而React Native采用的路由是原生的UINavigationController导航控制器实现。
React Native NavigatorIOS组件封装程度高；Navigator可定制化程度高。
第三方库也多，便于引用，但是也存在缺点。

性能方面

内存：内存释放相对明显
动画：有Animated库。实现简单效果。但是不适合做游戏
native是UIView 动画
H5是js动画还有canvas还有translate
安装包体积大了一些，就是一些图片还有静态资源，但是用内存来换灵活性
长列表：h5的就是直接渲染了，native都可以实现不渲染视图外的区域？
这个是怎么实现的？
依赖 PanResponder 来计算 touch 事件导致的视图改变。

更新维护方面

（1）更新能力
H5/Hybird：随时更新，适合做营销页面，目前携程一些BU全部都是H5页面；但是重要的部分还是Native。
React Native：React Native部分可以热更新，bug及时修复。
Native：随版本更新，尤其iOS审核严格，需要测试过关，否则影响用户。
（2）维护成本
H5/Hybird： Web代码＋ iOS/Android平台支持
React Native：可以一个开发团队＋ iOS/Android工程师；业务组件颗粒度小，不用把握全局即可修改业务代码。
Native：iOS/Android开发周期长，两个开发团队。

三、RN是怎么实现的？

rn官网是如何通信的

四、项目的定位

是一个用于集中控制硬件产品的APP

五、怎么通信的

建立P2P 连接和收发命令
建立TCP 通信（如在局域网内与同一个路由器下的其他设备通信）

六、什么协议的接口

https协议

七、怎么知道他是否执行成功

服务端看状态码，我看返回的信息是怎么样的。

八、怎么优化的

提升运行性能

避免使用NativeProps
为了提升用户在频繁刷新页面时的性能，推荐开发者使用setState 和shouldComponentUpdate 方法操作DOM。
说明
setNativeProps 直接操作浏览器的DOM，导致扩展程序加载时的渲染开销较大，且setNativeProps 在底层（DOM、UIView等）记录state，代码逻辑复杂；
有关NativeProps 的详细说明，请参见React Native 相关文档。
使用FlatList 组件
为了方便开发者写出高性能的流畅顺滑的FlatList，降低ListView 性能的制约，米家扩展程序SDK 为开发者提供了FlatList 组件，帮助开发者提升扩展程序的性能，如加速内存回收等；此外，开发者如需进一步提高扩展程序的性能，请在使用FlatList 组件时，注意如下内容：
- 请尽量在renderItem 中添加无状态组件，避免放置内存state；
- 使用keyExtractor 指定key，不要使用索引（尤其是在列表的增删的情况下）；
- 若开发者无需渲染即可得知每行的高度，请使用getItemLauout；
- 使用合适的windowSize。
  优化扩展程序UI
  - 减少复杂动画
  为了提高扩展程序在不同性能终端上的运行速度，开发者可使用Host.systemInfo.mobileModel()判断用户终端的型号，使用Host.systemInfo.sysVersion() 判断终端系统的版本，并在性能较低的终端上，适当减少扩展程序中复杂的动画。
  - 优化Image 标签
- 尽量避免使用与Image 标签尺寸相差较大的图片；
- 设置Image 标签的resizeMethod 属性，解决小尺寸加载大图的问题；
- 优先使用32位色彩深度的图片：
  - Adnroid推荐ARGB_8888 格式的图片；
  - iOS推荐32 位深度的图片。
- 推荐使用云端图片，除非必要的图片，建议使用云端的方式显示图片。
  说明：展示在扩展程序中的图片与内存中的图片尺寸，受图片文件压缩的影响会有较大的差异，当图片在内存中解压并加载到屏幕上时，可能会出现相关性能问题。
  - 使用StyleSheet.create
  使用StyleSheet.create 函数时，传入的Object 将会被转为优化后的StyleID，从而优化内存的占用和Bridge 的通信，灵活地控制扩展程序的样式。

在写代码的时候要考虑性能优化

九、最大的收获印象最深的最成就感的

会修改nodemoudles包了用patch-package，用了他别的同事也可以在git中拉取到我修改的源码文件
patch-package是一个用来给其他npm包打补丁的包，实际原理也是在本工程保存一份修改的代码，只不过不是用全量代码的形式保存，而是保存了git diff的结果，节省了代码体积
用法如下：

npm i -S patch-package安装patch-package
直接在node_modules下修改需要修改的包源码
执行npx patch-package 包名, patch-package会将当前node_modules下的源码与原始源码进行git diff，并在项目根目录下生成一个patch补丁文件
后续只要执行npx patch-package命令，就会把项目patches目录下的补丁应用到node_modules的对应包中，这个执行时机一般可以设置为postinstall这个勾子

“scripts”: {
“postinstall”: “patch-package”
}
优化相册系统
首先判断是几个手指，一般情况下是一个手指会触发双击和左右移动，两个手指是放大缩小。

  if (new Date().getTime() - _this.lastClickTime < 500 
  && !_this.isHorizontalWrap 
  && (this.horizontalWholeCounter!==0 
  || this.horizontalWholeOuterCounter !== 'undefined')) 
  {
+console.log('zoom这里是触发了双击')
 if (this.isDoubleClick && !_this.isHorizontalWrap) {
+ console.log('滑动的时候触发了双击')
+ return
}
_this.lastClickTime = 0.0;
// 因为可能触发放大，因此记录双击时的坐标位置 ,x从0到3000多,y从100多到700
_this.doubleClickX = evt.nativeEvent.changedTouches[0].pageX;
_this.doubleClickY = evt.nativeEvent.changedTouches[0].pageY;
 // 缩放
_this.isDoubleClick = true;
 if (_this.props.enableDoubleClickZoom) {
if (_this.scale > 1 || _this.scale < 1) {
console.log('zoom 回归原位')
// 回归原位
 _this.scale = 1;
_this.positionX = 0;
_this.positionY = 0;
}
//单击放大缩小改这里
 else {
// 开始在位移地点缩放
// 记录之前缩放比例
 // 此时 this.scale 一定为 1
if (_this.isHorizontalWrap) {
_this.scale = 1

}
+
 var beforeScale = _this.scale;
 // 开始缩放
_this.scale = 2;
 // 找到两手中心点距离页面中心的位移
// 移动位置 392width 585height
_this.positionX = ((_this.props.cropWidth / 2 
- _this.doubleClickX) * diffScale) / _this.scale;
//然后在缩放的时候更加流畅
 react_native_1.Animated.timing(_this.animatedScale, {
toValue: _this.scale,
duration: 100
easing: react_native_1.Easing.linear,
}),
//滑动的时候判断面积或者位移，那个大滑到哪边去
ImageViewer.prototype.imageDidMove = function (type) {
if (this.props.onMove) {
this.props.onMove({
type: type,
positionX: this.positionX,
positionY: this.positionY,
lastPositionX: this.lastPositionX + this.props.imageWidth / 2 - 50,
lastPositionY: this.lastPositionY,
 if (offsetXRTL < 0) {
//说明往左滑动，当前的选择的是数组中的一个或者最后一个，然后要加载的就是后面那一张
if (_this.state.currentShowIndex || 0 < _this.props.imageUrls.length - 1) {
_this.loadImage((_this.state.currentShowIndex || 0) + 1);
}
}
else if (offsetXRTL > 0) {
//说明往右活动，要加载的是上一张要减一
if (_this.state.currentShowIndex || 0 > 0) {
_this.loadImage((_this.state.currentShowIndex || 0) - 1);
}
setTimeout(() => {
 _this.setState({
currentShowIndex: nextIndex
}, function () {
if (_this.props.onChange) {
_this.props.onChange(_this.state.currentShowIndex);
}
});
}, 200);}

十、做了啥思路经历

产品提需求，然后结合实际评估需求能否百分百实现。
可以实现，和服务端同事沟通接口的实现，我获取接口的数据来渲染数据。
这个过程是并行的，我按照ui图开发，他写接口，双端思考接口怎样用合理，并且可以重用。
开发完了提测，测试去测，后面跟踪bug，修复bug。

十一、优缺点

优点：
自学能力提高了，因为同事大哥们都很忙，不必要的时候不去问
沟通能力提升了，每天和产品测试沟通，对于需求，适当的给他解释，对于bug，告诉他应该如何测试
解决错误的能力提升了，遇到问题很耐心去解决它，而不是抛锅，更加勇于承担错误了。
工作习惯更加良好了，每天都做日志记录。每一个需求我也会做一个文档来记录。完成这个需求之后我也会做复盘。用到了那些方法，其他的项目可以沿用。遇到了那些bug，其他项目要去避免。
缺点：
有时候考虑的不太全面，对于一些失败的处理，还有边界。