[toc]

账号管理

前言：主要账号

一、苹果开发者账号

见 苹果设备注册管理.md

1、苹果开发者设备

因苹果设备每年只能添加100台，且即使删除后也是当做一台设备。所以请真正有需要的用户才提交申请。

如需申请，请填写表：

附、udid获取方式

方式1、请自行使用浏览器进入蒲公英的一键获取udid工具

方式2、直接扫码获取

二、Bugly

官网：https://bugly.qq.com/

Id获取方式如图：

End

[toc]

数据结构规范–消息

一、推送消息规范

推送模拟参考：：《iOS进阶_推送模拟》

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

{
    "code": 0,
    "message": "success",
    "result": {
        "msgType": 1,
        "msgDes": "金豆消息(对msgType的描述)",
        "msgData": {
            "msgId": "1234567890",
            "msgTitle": "金豆消息标题",
            "msgContent": "金豆消息内容",
            "msgImage": "http://www.baidu.com/xxx.jpg"
        },
        "msgOnTap": {
            "action_type": "route",
	          "action_name": "发布内容",
            "action_value": "appScheme://xxx"
        }
    }
}

msgOnTap：代表点击该按钮需要进行的操作。

点击规范请查看：《路由规范(含点击属性规范).md)》

二、聊天消息规范

建议与推送消息结构完全一致，至少与推送消息中的result一致。

End

[toc]

数据结构规范–卡片

一、内容卡片规范

1、内容卡片规范

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

[
  {
    "cardType": "content",
    "contentCard": {

    },
    "userCard": {

    },
    "bannerCards": [

    ]
  },
  {
    "cardType": "user",
    "contentCard": {

    },
    "userCard": {

    },
    "bannerCards": [

    ]
  },
  {
    "cardType": "banner",
    "contentCard": {

    },
    "userCard": {

    },
    "bannerCards": [

    ]
  }
]

2、需求1：长按卡片，弹出反馈列表。

分析：因为同一个卡片在不同业务页面，不一定都可以进行反馈，所以需要提前知道每个卡片在不同业务页面是否可以进行反馈，甚至是知道可以进行哪些反馈选项操作。

方案1：提前知道每个卡片在不同业务页面是否可以进行反馈。

后台数据返回

1
2
3
4

"canNegativeCardTypes": [
  "mallHomePage#cardType_content", 
  "mallHomePage#cardType_user"
]

代码实现

1
2
3
4
5
6
7
8
9
10
11
12

void longPressCard() {
  var cardType = "content";
  var position = "mallHomePage";
  var flag = "$position#cardType_$cardType"
  bool canNegative = canNegativeCardTypes.contains(flag);
  if (!canNegative) {
    return; // 不用相应
  }

  List<NegativeModel> negativeModels = await request(Url, {flag: flag});
  showNegativeList(negativeModels);
}

方案2：提前知道每个卡片在不同业务页面可以进行哪些反馈选项操作。

后台数据返回

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

"negativeFeedbackConfig": {
	"mallHomePage": {
    "cardType_content": [
      {
        "image": "xxx.png",
        "text": "不喜欢该内容",
        "negativeId": 1
      },
      {
        "image": "xxx.png",
        "text": "不喜欢该作者",
        "negativeId": 2
      },
      {
        "image": "xxx.png",
        "text": "举报",
        "negativeId": 3
      }
    ],
    "cardType_user": [
      {
        "image": "xxx.png",
        "text": "不喜欢该作者",
        "negativeId": 2
      },
      {
        "image": "xxx.png",
        "text": "举报",
        "negativeId": 3
      }
    ],
  }
}

代码实现

1
2
3
4
5
6

void longPressCard() {
  var cardType = "content";
  var position = "mallHomePage";
  List<NegativeModel> negativeModels = negativeFeedbackConfig[$position][cardType_$cardType];
  showNegativeList(negativeModels);
}

End

[toc]

项目CodeReview

一、

1、非空、空值是否合理

2、类型定义是否合理 （字符串/枚举值）

3、方法是否统一（如数字字符串的小数位数保留、弹窗）

4、变量的位置定义是否合理，是否需要传递。局部变量，全局变量。

5、接口是否简化，接口参数是否过多（如跳转到聊天页）

6、必要注释是否缺失

7、代码实现顺序是否合理

参考文章

• code review 流程探索

End

[toc]

APM选型-备选筛选

产品选型流程通常包含以下步骤：

1. 确定需求：明确产品选型的目的和需求，包括所需功能、性能、规格、成本等方面的要求。
2. 调研市场：了解市场上已有的产品和解决方案，分析其特点、优劣势和市场占有率等。
3. 制定评估标准：根据需求和市场调研结果，制定产品选型的评估标准，包括技术指标、产品性能、价格、服务等方面的标准。
4. 筛选备选方案：根据评估标准，筛选出符合要求的备选方案，并进行初步比较和评估。
5. 进行实地考察：对备选方案进行实地考察，包括参观厂家、现场考察、试用产品等。
6. 编制报告：根据实地考察和评估结果，编制产品选型报告，包括备选方案的优缺点、技术指标、价格、服务等方面的比较和评估结果。
7. 决策和采购：根据产品选型报告，进行决策和采购，选定最终方案，并进行合同签订、交货、安装、调试等工作。
8. 跟踪和评估：对选定的产品进行跟踪和评估，及时发现和解决问题，提高产品使用效率和维护质量。

一、比对准备

1、同类型比较

为保证数据准确性，所有的比较必须在同一环境下进行处理。相关的环境因为有时间、平台、版本、灰度、采样率。

二、比对因素与实施步骤考虑

1、比对因素

2、实施步骤

1、罗列比较因素表。

2、观测并在上述表中记录数据

（每一天：iOS、Android）

三、数据因素项支持情况比对

略

四、数据因素值比对结果

1、环境值(前提)

以下数据的比对基于相同环境因素，其值如下：

2、结果值(观测数据)–优先级：共有-独有、价值高低

2.1、崩溃、卡顿/anr、错误率

2.1.1、崩溃

2.1.2、卡顿/anr

2.1.3、错误率

2.2、启动体验

2.2.1、启动次数

2.2.2、启动耗时

2.2.2.1、概念说明

参考文档：xxx

概念简述：

2.3、页面体验

2.4、用户数据

End

[toc]

FlutterGetX框架选择历程

为什么

• Flutter 状态管理框架 Provider 和 Get 分析

前言

1.getX的功能不只是只有状态管理功能。
2.只是为了状态管理的话，项目中新功能可使用。使用不影响其他人。且目前项目中的依赖已包含getX。
3.如果是旧功能，在赶项目的阶段如果没法把握能保量保质的完成开发，不建议使用。当然还是希望大家使用，但任务的完成质量是第一位，如果只是为了使用而影响了项目进度，我认为不是特别可取，除非涉及严重问题不得不。所以没有规定不能使用，但结果是要完成好开发，而不是简单的“好了”，然后存在有很多细节没完善的地方。

对于一个功能，我认为所谓的好了，起码是
①主流程没问题，
②特殊流程已处理，
③异常已容错，
④界面效果与ui完全一致，不差任何一两个像素及颜色偏差，
⑤使用上至少不存在用户感知到的卡顿，
⑥自己发现的问题已跟进处理，而不是挂着等测试或产品提，
⑦别人发现的也一样处理，而不是不重要，
⑧甚至不应该出现用户感知是可点击的，结果点了了没任何效果的问题，哪个加个toast也比没有强
⑨流程上的有些偏可以下沉到底层的，如按钮的重复点击问题处理，图片的加载缓存404等处理，是否在自己的模块上处理完成，或者说告知之前这块没处理过，后面安排处理，
⑩debug模式是否正常，而不是像项目一开始时候的debug都基本无法debug，都在跑release。
等等…

对内的代码结构是否合理，

所以在能保证质量完成开发或者除了不影响使用的解决不了的情况下很希望大家也多看看多学学多了解和使用一些优秀的框架。但框架是为开发服务的，不能说想使用了什么框架结果完成不了，或做得有点大概。
4.另外对于getX的状态管理使用，也不是一使用了就得全部替换，甚至说新功能就一定得按getX来实现。拿个关于页面，一个简单页面用getX与现有的，反而使用getX可认为是完全没必要，因为页面可认为是不需要“可变”状态，只是需要很独立的数据显示而已。类似于做原生，也有很多优秀的框架甚至架构，但mvc的模式肯定在你的项目里有存在，而且在那种场景下，它的优点反而更明显。可以理解为越简单的东西越没有必要使用非常强大的框架，没必要用大炮打小鸟。

优秀新框架的初使用，我认为在前期是允许使用，而不是规定都得使用。好比有人很熟悉，但其他人不熟悉可能做起来，他就没法完成他原本安排的任务，形象而夸大的说，可以想象成让你换个语言开发，排期不变，保证开发完成和质量，而且还不是说他那块的就一定得使用新框架才能。

所以鼓励使用优秀的技术，但别忘了保证完成自己的开发。当然使用新技术时候，如果时间差不多，也可同产品商量适当一两天，在其接受延期的情况下才能延期，不然要使用的话，哪怕加再多班也得完成。而对于一些类似完全重构的任务，自然会同产品协商专门安排一期处理。不管是原生开发还是跨平台，我觉得这些理念和思维应该都差不多。

End

[toc]

APM调研

一、确定需求

APM（Application Performance Management）选型的主要目的是通过监控、分析和优化应用程序的性能和行为，提高应用程序的可靠性、可用性和响应速度，提高用户体验和满意度，从而提升业务价值和竞争力。

APM的选型对应到手机APP上，其目的和需求分别主要如下：

目的：提升手机APP的性能和用户体验，提高用户满意度，增强品牌竞争。

1、痛点/所需功能/期望

痛点典型场景：

• 参考文章 听云

  请求分析场景

  在大多数情况下，网络耗时和可用性仍然是衡量用户体验质量的标准。

  • 过长的响应时间会极大的降低客户容忍度，关键支付接口可用性直接影响GMV（成交总额），在某些情况下超长的响应耗时往往是由于后端响应缓慢导致。
  • 用户使用过程中会因为网络阻塞或处于弱网环境导致各种各样的网络错误，且往往无法通过服务端日志收集，而且令运维人员头疼的网络错误，往往跟客户端环境有着密切的联系。

  用户感知分析场景

  数字化时代，随着业务规模地逐渐增大，应用承载的业务逻辑也越来越复杂，对应的性能问题也日益增多：应用崩溃、卡顿、网络延时、图片加载失败等等性能问题就如同附骨之疽难以去除，由性能带来的各种问题会直接影响业务成交率及品牌好感度。

  现有用户体验优化方案已经不再像过去那样简单地处理占比最高的崩溃和解决数量最多的错误，而是有针对性地优先修复最影响用户体验的Bug，以便提高用户留存。

  基调听云App通过监控应用启动、页面展现和用户操作三大核心场景，以业务视角综合分析应用使用过程中的「启动耗时」、「首屏加载」及「用户操作」指标，覆盖了应用的全生命周期，从而综合评估用户使用过程中的体验情况。

  更多内容，请查看原文链接。

2、预算成本

不限定，以最后对比数据后，再做选择。

二、调研市场

了解市场上已有的产品和解决方案，分析其特点、优劣势和市场占有率等。

1、调研包含内容/考虑点

2、调研产品列表

3、调研包含内容/考虑点对比表

APM选型调研对比表

三、制定评估标准

将APM产品的功能清单转化为具体的评估指标，并根据用户需求和期望，给予不同指标不同的权重。例如，对于监控指标，可以考虑启动时间、页面加载时间、卡顿率、崩溃率等方面，对于诊断指标，可以考虑问题定位时间、错误率、准确性等方面。

根据上述评估标准，我们将《火山引擎》和《听云》列入备选方案。

四、筛选备选方案、实地数据对比

根据评估标准，筛选出符合要求的备选方案，并进行初步比较和评估。

1、筛选方案，详见：APM选型-2备选筛选

2、筛选方案下的实地数据对比，详见：云雀：APM火山VS听云数据对比

五、选型决策和采购

六、跟踪和评估

End

[toc]

UI组件选择历程

前言

对于组件定制(非从0开发)，现有业内有Bruno和Templates等成套组件库，其中多为个人或团队开发，少为公司或企业开源；

组件的实现，有使用多个业内公认性强的独立组件和使用成套组件开发两种方式。

一、现有UI规范与三方UI组件库比较

与三方的比较相似度：

1：不一致，可定制成UI样式，无影响

2：不一致，不可定制成UI样式，

编号	类型	现有UI规范图	三方UI组件图	相似度	是否已实现	备注
1	Loading			0%	已实现
2	Toast			100%	已实现
3	Alert/Dialog			10%	已实现
4	ActionSheet			40%	已实现
5	ItemPicker			60%	已实现
6	DatePicker			60%	已实现
7	AreaPicker			0%	已实现
8	Button			95%	已实现

基于，目前app中对应的UI组件，基本已实现过，只是缺少统一，导致有复制代码，局部定制的不当操作；

又由于避免重复开发，统一组件，是必须处理的事项。所以，当前的处理方案为抽离并保持已实现的UI，新开发部分采用从组件中调用。此工作与后续其他部分不重合。

而后续如有其他需要定制成组件的部分，对UI实现的图，继续优先与第三方组件库从匹配度、扩展性、维护性等角度考虑。

如果从数据上比价，得知该三方UI组件库与现有UI匹配度较低(匹配度=符合规范的组件个数/总的组件个数)。

基于匹配度较低的情况，处理方案有如下两种。

方案一：UI规范向三方组件靠齐，即后续UI设计使用三方组件样式；

方案二：放弃三方组件库，分别使用独立三方组件，定制成现有UI想要的特有样式；

二、UI规范选择方案比较

1、开发优先，放弃特有风格

如果从未开发，则基于前期开发效率考虑，使用方案一成套组件库进行开发（需领导批准，同步UI团队改变设计规范）。

2、风格保持，实现次之

如果为了保证维持app特有的风格，组件实现则必须与UI设计保持一致，则

1、三方成套组件库与UI匹配度高：

直接使用

2、三方成套组件库与UI匹配度低：

则组件的实现，有以下两种方式

①尝试基于成套组件库，进行深度定制，如无法定制指定效果，放弃；

②使用与UI匹配度高的独立三方组件，进行快速定制；

三、保持UI风格使用自己规范时，开源库选择标准

成套组件库 VS 各独立组件，我们主要从以下三点考虑：

一、后期维护性。维护性是避免该组件不进行维护，导致需要使用新的组件进行替换。从概览上讲成套组件的不维护风险比由多个独立组件组成的集体不维护风险概览大，从而产生的维护替换成本也会较高。

二、扩展性。扩展性是指该组件支持的可定制程度。为了避免有些组件早高度封装下，可定制程度不高，当后期需要补充定制其他功能时候，无法支撑需求，从而导致需要修改源码或使用新组件来替换，我们会优先考虑扩展性强的组件，从而节省后期的维护成本。

三、受众广度。指一个组件或一群组件组成的组件库在业内使用开发者的多少或流行度。以下以轻提示控件toast举例，单个toast和组件库里的toast，在https://pub.flutter-io.cn/上查到的受众广度分别如下：

对于项目中前期已实现的组件，是优先以使用github上与我们匹配最高且Star最多的组件来进行二次封装，从而定制成App所需的实际样式。如无或只是简单封装，才使用一次封装和定制，为的是避免对只是简单封装的控件也产生不必要的依赖。就开发成本上来讲，与使用成套组件无实际差别，并不会多增加，且有降低成套组件后续维护性风险的好处。

四、后续

基于目前从产品、UI上已统一使用Bruno中的风格，所以后续对于前期未实现的组件（如后续可能需要的底部弹窗下拉关闭组件）会直接使用Bruno组件库中的组件；而前期已实现的部分，在产品和UI有需要更新风格的情况下，也会按需进行替换成组件库中的风格

End

[toc]

切为H5的标准

针对指示的h5实现方式和空态页面体验优化问题，我们经讨论，处理方案如下

问题一：对目前app中存在的H5页面，哪些是需要处理成h5的，初步定为如下标准：

1、黄金主流程的必须保证flutter实现，更稳定；

2、对于强运营的、改动量比较频繁的采用h5，一般为活动页；

3、对于纯展示交互少的采用h5，如隐私协议、玩法说明等；

按以上标准，目前app中，需要处理成h5页面的有：

状态1：已由H5实现，无需修改；

状态2：待开发，直接开发成H5；

状态3：原生实现，后续优化时调整为H5；

1、注册协议、隐私政策、玩法说明：待开发，直接开发成H5；

2、频道页：目前只有潮物是h5，其他已用flutter实现，后续待频道页优化时调整为H5；

3、活动规则(百愿清单、愿望星规则等)：目前已有部分由flutter实现，后续逐步调整为H5；

4、大转盘、动物运动会、4大场景(生日、节日、结婚、生娃)：已由H5实现；

5、首页banner跳转的落地页：跳转百愿清单、愿望单为黄金主流程已由flutter实现；跳转电子邀请函、动物运动会已由H5实现；

问题二：对app中无数据的空态页面太空的体验优化问题，晚上产品会把所有页面都列出来，再跟您对一遍，然后我们再统一做修改。

方案陈述以上，如有描述不当或需要再补充的，感谢指点！

[toc]

加固选型

参考文档：

• 五大移动应用加固平台评测
• 乐固加固FAQ

腾讯云加固功能介绍-官网

一、确定需求

1、痛点/所需功能/期望

2、预算成本

二、调研市场

了解市场上已有的产品和解决方案，分析其特点、优劣势和市场占有率等。

1、调研包含内容/考虑点

2、调研产品列表

3、调研包含内容/考虑点对比表

三、制定评估标准

将APM产品的功能清单转化为具体的评估指标，并根据用户需求和期望，给予不同指标不同的权重。例如，对于监控指标，可以考虑启动时间、页面加载时间、卡顿率、崩溃率等方面，对于诊断指标，可以考虑问题定位时间、错误率、准确性等方面。

根据上述评估标准，我们将《XXX》和《XXX》列入备选方案。

四、筛选备选方案、实地数据对比

根据评估标准，筛选出符合要求的备选方案，并进行初步比较和评估。

1、筛选方案，详见：

2、筛选方案下的实地数据对比，详见：

五、选型决策和采购

六、跟踪和评估

End