经过调研，我选取了艾瑞互联网大数据服务平台，电子阅读分类，按月度活跃设备排名靠前的3款app。
确定竞品为：掌阅，QQ阅读，书旗小说，再加上我们的OPPO书城，APP产品共4款。
APP名称掌阅iReader书旗小说QQ阅读OPPO书城版本号7.5.210.6.8.656.6.1.8883.0.4.303数据取自360手机市场，截止2018年5月10日，其中oppo书城取自rdm最新打包
二、竞品分析竞品分析主要包含了以下四个方向基础调研，性能调研，流畅性调研，产品分析
1.基础调研基础调研，主要调研安装包下载量和安装包大小。
1） 下载量查阅了两个知名的app分发中心，360手机市场和腾讯应用宝。
其中掌阅app划分为两个：掌阅和爱掌阅读，这个和公司发展战略有关，我们暂时只分析掌阅。
360市场的下载量如下：
APP名称掌阅iReader书旗小说QQ阅读OPPO书城下载量（亿）1.741.340.46无可以看出掌阅的下载量较书旗小说和qq阅读多，这也和开头的艾瑞数据吻合。
应用宝的下载量如下：
APP名称掌阅iReader书旗小说QQ阅读OPPO书城下载量（亿）1.71.53.1无可以看出，QQ阅读的下载量与掌阅和书旗加起来相当。
2） 安装包大小安装包大小如下:
APP名称掌阅iReader书旗小说QQ阅读OPPO书城安装包大小15.99M25.82M22.78M17.63M安装包大小是我们技术同学比较关心的一个点，安装包的大小，一方面关系到用户流量问题，越大，用户下载耗费的流量越多。另一方面，因为白牌项目要预装到手机里面出厂，厂商很可能对安装包大小做要求，所以我们要尽量精简安装包的大小。
下面我们分析下，这几个项目的安装包中包含了些什么，可以从哪些方面进行优化。Android Studio3.x支持分析安装包的资源，直接将安装包拖入AS中，进行观察。
掌阅
项目中排行较大的文件夹为assets目录，其中包含字体文件和各种插件apk.
缺点：字体方案方正黝黑1.2M，占很大一部分空间，可能和产品设计有关，默认为此字体，从安装包大小看来，不是一个很好的选择，应该尽量选取较小体积的字体，后期可通过产品内提示用户下载。
优点：图片资源控制较好。查阅图片资源目录，基本上未见100K以上图片。
书旗
项目中排行较大的文件夹为assets目录,lib目录
查阅了这两个目录，对里面包含的内容十分吃惊。assets目录大小8.8M，包含epub文件，字体文件，图片文件，感觉直接把书放到包里面有点问题，不知道他们产品怎么设计的。字体文件方正兰亭黑3.7M，比掌阅的还大。图片文件含有100K以上的。从中还可以看出使用了淘宝的Atlas技术，还是比较先进的。lib目录大小6.3M，这两个文件夹8.8+6.3=15.1M，都快相当于一个掌阅项目了。可以看出书旗app有很大的优化空间。但是为什么要这么做，可能与产品策略有关，我们不得而知。
qq阅读
项目中排行较大的文件夹为res目录，assets目录。
res目录中有多张100K左右的图片，assets目录中有一个3.1M的压缩包，搜索到可能与腾讯支付相关。
oppo书城
项目中排行较大的文件夹为res目录，assets目录。res目录中大于100K的图片较多，个别文件接近220K,这其中存在很大的优化空间。assets目录中包含一个apk文件，较大。还有和qq阅读中同名的zip文件.比qq阅读的小上不少，911k。不知道这两者的差距。
总结：
从分析结果来看，要控制包体大小，有以下几个要点：
项目中图片资源应该严格控制，可使用腾讯智图工具或TinyPNG进行图片压缩，对50K以上的图片进行统一处理；可以进行lint检测，清除未使用的资源文件；使用较小体积的默认字体，如果有切换字体的需求，建议使用远端下载的方式；可以精简一些不常用的插件功能，类似字体进行远程下载使用。2.性能调研性能分析从五个方面进行分析：启动时间，cpu，内存，流量，电量。
1） 启动时间毫无疑问，启动时间越短越好，用户点下桌面上的app图标，就开始走启动流程。这其中流程十分复杂，我们暂时不理会这其中的过程，可以留作以后研究。一般来讲，启动分为三种启动：冷启动，热启动，暖启动。
冷启动为应用在开机后或者被系统停止后的第一次启动过程。热启动为用户退出应用，但随后重新启动它。应用的进程还在运行，但应用必须重新从 onCreate() 开始创建 Activity。具体可以参考这篇博文（Android 性能优化——启动时间优化指南），讲解的非常好。
此次进行竞品分析，我们分析冷启动和热启动。
使用此命令进行分析,查看 App 启动耗时:
adb shell am start -W packagename/activity
通过反编译，查阅到以下信息：
app名称查看方式掌阅adb shell am start -W com.chaozh.iReaderFree/com.chaozh.iReader.ui.activity.WelcomeActivity书旗adb shell am start -W com.shuqi.controller/com.shuqi.activity.SplashActivityQQ阅读adb shell am start -W com.qq.reader/com.qq.reader.activity.SplashActivityOPPO书城adb shell am start -W com.oppo.book/com.qq.reader.activity.SplashActivity使用上述代码，进行测试。
冷启动，测试方式为，清空程序后台，点击app，记录数据。取五次测试结果的平均值，测试数据如下(测试单位：ms):
App名称数据1数据2数据3数据4数据5均值掌阅621638649684641647书旗628622598603629616QQ阅读665609674680675661OPPO书城582560580543556564可以看出oppo书城以微弱的优势领先，剩余三款app，启动时间不相伯仲。
热启动，测试方式为，打开app并退出，不清理后台，点击app，记录数据。取五次测试结果的平均值，测试数据如下(测试单位：ms):
App名称数据1数据2数据3数据4数据5均值掌阅607582576590570585书旗175181192174175179QQ阅读188201192188172188OPPO书城184179181179184181可以看出，掌阅的数据比较异常，测试机为oppo手机，每次启动均以冷启动的方式进行启动。猜测，可能掌阅的退出为杀掉应用进程的方式，非destory方式。剩余三款app启动时间差距不大，基本一致。
总结：一般成熟的app，都会用一个splash页做启动页，在启动的时候减小黑屏或白屏时间，尽量少的做初始化操作，未使用到的模块或功能进行延迟初始化或延迟加载，尽量减少启动时间。
2) cpu查看app的cpu使用率，需要使用top命令。首先输入adb shell,进入linux的命令行模式。然后输入top -n 1 -d 5, 查看手机当前各进程cpu使用情况。 -n 代表刷新次数，-d 代表刷新间隔，我们在5秒后刷新一次，取出瞬时cpu占用。得出的结果为所有进程，我们只关心当前测试app的cpu情况，所以可以使用管道命令，查询出我们所需的内容，即top -n 1 -d 5 | grep packagename，所得结果类似 18751 7 3% S 61 1754024K 136604K fg u0_a158 com.chaozh.iReaderFree，其中18751为进程pid,3%即为cpu占用。
因为现在app大多使用多进程架构，我们计算所有的进程占用总和。
测试分为四种典型使用场景：
主页读书界面漫画界面听书界面测试结果如下：
掌阅：
场景/进程主页读书漫画听书com.chaozh.iReaderFree361420com.chaozh.iReaderFree:channel1000com.chaozh.iReaderFree:adp0NANANAcom.chaozh.iReaderFree:nocket0000可以看出听书界面cpu占用比较高，可能涉及到编解码操作。adp进程，后期就消失了，具体后文会继续分析。
书旗：
场景/进程主页主页不显示动画读书漫画听书听书不显示动画com.shuqi.controller351197234com.shuqi.controller:channel000000com.shuqi.controller:pushdaemon000000com.shuqi.controller:daemonwatch000000com.shuqi.controller:daemonwatch000000相比于掌阅，书旗多出了两种不同的场景。这是由于书旗阅读在首页和听书页面显示动画时，相比于没有动画时，cpu的占用明显增高。滑动列表使水波纹头部消失，cpu占用就下去了。听书页同理，也有一个动态的背景，导致cpu占用较高。下文的流畅性分析中也有和此处相关的测试。
QQ阅读：
场景/进程主页主页不显示动画读书漫画听书com.qq.reader111841com.qq.reader:QS00000com.qq.reader:game_process00000com.qq.reader:pushservice00000com.qq.reader:dl00000同理，主页头部的水波纹移出屏幕后，cpu占用下降。
OPPO书城：
场景/进程主页读书漫画听书com.oppo.book2563com.oppo.book:dcs0000可以看出，OPPO书城在这4者中表现最好。
总结：从上面四个表格中可以看出，四款app均使用多进程技术，引入原因暂且不表。一般都是主进程在占用CPU时钟，对比来看，OPPO书城性能最好，QQ阅读次之，书旗最差。究其原因，书旗中使用了持续播放的动画，导致一直在占用cpu。这个东西以后在产品设计的时候一定要注意，恰当少量引入，在合适的位置引入，不然会引起耗电量问题和性能问题。
3）内存内存指标有 VSS、RSS、PSS、USS，他们的含义分别是：
VSS：Virtual Set Size 虚拟耗用内存（包含共享库占用的内存）RSS：Resident Set Size 实际使用物理内存（包含共享库占用的内存）PSS：Proportional Set Size 实际使用的物理内存（按比例分配共享库占用的内存）USS：Unique Set Size 进程独自占用的物理内存（不包含共享库占用的内存）一般来说内存占用大小有如下规律：VSS >= RSS >= PSS >= USS，一般测试中关注的比较多的是 PSS 这个指标。
查询程序的内存占用，使用以下步骤:
adb shell (进入linux命令行)top | grep packagename (查询关心的进程pid)dumpsys meminfo pid (查询进程的内存信息)我们以qq阅读为例，dumpsys meminfo 7872
我们关心PSS指标，可以看出TOTAL的第一项数据就是我们关心的结果。可以使用grep命令简化数据，下面的测试数据均使用dumpsys meminfo pid | grep TOTAL测出。
内存测试场景，也分为主页，读书，漫画，听书四部分测试。由于app使用了多进程技术，我们要把所有进程均计算在内。以下数据测试单位均为M。
掌阅
进程/场景主页读书漫画听书com.chaozh.iReaderFree108.21117.88124.75159.86com.chaozh.iReaderFree:channel15.9616.4313.2312.98com.chaozh.iReaderFree:nocket15.6115.5615.5915.69com.chaozh.iReaderFree:adp11.50NANANA总计151.28149.87153.57188.53可以看出，主进程内存占用最高，其余进程占用稍小。其中adp进程在进入主界面后消失，猜测这个adp为adprocess,即广告进程，主界面前的开屏广告为单独的进程。个人观点不是太必要，如此设计adp进程的初始化信息后续的主进程无法使用，但是此处的初始化基础信息如屏幕宽高等，后续进程都是需要使用的，不知是何种考虑，以后可以慢慢探讨。
书旗
场景/进程主页读书漫画听书com.shuqi.controller180.72194.34239.08214.21com.shuqi.controller:channel25.9422.3621.6721.16com.shuqi.controller:pushdaemon11.2211.1210.7710.12com.shuqi.controller:daemonwatch9.208.708.278.33com.shuqi.controller:daemonwatch6.136.136.086.06com.shuqi.controller:audioNANANA15.00总计233.21242.65285.87274.88可以看出，书旗的各场景内存占用均比掌阅的高，而且，书旗在听书界面分出来一个audio进程，这个很有借鉴价值。一般来讲分进程有几种原因：
分担主进程压力，如推送进程，游戏进程等减小产品风险，划分单独进程，出现问题不影响主进程，如web进程，听书进程等守护进程，和主进程互相守护，互相保活，如daemon进程可以看出，书旗划分的进程贴合了上述几种原因，单独的听书进程，单独的push进程，两个守护进程。当然进程也不是越多越好，多进程之间信息共享与进程开销都比正常单进程应用复杂，都要看产品设计和架构设计。
QQ阅读
场景/进程主页读书漫画听书com.qq.reader61.4692.92134.75101.05com.qq.reader:QS11.6110.4310.0310.97com.qq.reader:game_process46.0136.7636.1136.73com.qq.reader:pushservice9.9710.3410.3310.35com.qq.reader:dl28.7219.8419.7218.85总计157.78170.29210.95177.94可以看出，QQ阅读各场景的内存占用比书旗要好，和掌阅相当。此处唯一有疑问的是game_process进程，一般来讲，进程都是在使用的时候创建，不使用的时候销毁，从字面意义来看，这属于游戏进程，但是我在上述四个场景中，并未使用到任何游戏相关的功能，自始至终游戏进程都存在，占用了一部分内存。后续可以查看下主线代码，看看此进程的用意。
OPPO书城
场景/进程主页读书漫画听书com.oppo.book105.31144.32156.72144.54com.oppo.book:dcs4.794.804.794.77总计110.10149.12160.51149.31直观上可以看出，OPPO书城是四款产品中内存使用情况最少的，表现最好。当然这个和他产品特点有关，进程数量少，猜测push使用系统push，保活有系统保证。漫画界面内存增长较高，可能与图片较多，较大有关。其中dcs进程在测试过程中时有时无。
4）电量和流量电量和流量是很重要的两个性能指标，这个十分影响用户体验。耗费流量越少，产生的资费越少；耗费的电量越少，待机时间越长。所以用户肯定喜欢耗流量少，耗电少的应用，这才是用户喜闻乐用的应用。
流量：
流量指标测试比较麻烦，因为时间和设备原因，暂时未能进行详细的测试。在此处可以提出几点测试原则和开发原则。
测试原则：使用控制变量法，测试4G,WIFI等环境下，各使用场景的流量消耗情况。
开发原则：4G网络下的流量弹框提醒，网络重试次数时机控制等。分模块划分缓存时长，对于实时性不敏感的数据，进行缓存处理等。
电量：
电量测试也比较麻烦，实际使用中，需要测试同学制定相应的测试用例，测试4G,WIFI等环境下，各使用场景的电量消耗情况。
此次分析使用了battery-historian V2.0，对四款app进行了简要的电量消耗分析。
Battery historian是一款通过上传bugreport文件分析用户手机中App的电池耗电情况的工具。具体的使用流程可以参考此篇博文（battery-historian V2.0的数据获取及参数分析）。由于搭建分析环境比较麻烦，有热心的网友搭建了在线服务，此处提供一下地址（在线分析网站），大家可以在线分析了，不用自己搭建，方便省心，再次感谢热心网友。
测试场景如下：测试时长 10分钟 = app浏览1分钟 + 电子书阅读3分钟 + 漫画浏览3分钟 + 听书3分钟。对上述场景，按照上述博文描述，进行电量日志抓取，文末会给出文件，大家也可以拿文件进行分析。
我们首先拿掌阅的app进行测试，给出一个分析步骤，后续的均按照此步骤分析。
上传完日志文件，可以生成一个图表，类似下图：
当然此处可以分析的不止箭头指出的那么简单一项，下面还有详细的各项内容，可以参考上述提到的博文中各项参数进行分析。此次我们只关注流量和电量，别的暂时先不分析。app stats选项卡下，有电量信息，如下图：可以看出我们使用了2.02%的电量。Network Information下有具体的流量消耗，此次测试仅测试WIFI网络，其余环境暂未测试。可以看出我们使用了7.29M的流量。
测试结果如下表：
APP电量电量(%)流量（M）掌阅2.027.29书旗2.126.89QQ阅读2.1728.17OPPO书城1.9134.63对比来看，电量消耗相当，但是流量情况差距比较大。不知道是我自己测试的问题，还是实际使用情况如此，QQ阅读和OPPO书城的流量使用比掌阅和书旗的大，具体可以问测试同学要详细的测试数据。Battery historian中还有更加详尽的描述，如service，jobservice使用情况，cpu使用情况，alarm使用情况，wifilock，wakelock等。由于电量差距不是很大，此处便不做详尽分析，后续遇见异常情况可以使用此工具分析。
3.流畅性调研流畅性分析主要分为以下两个方面：GPU呈现模式分析和GPU过度绘制
1）GPU呈现模式分析具体可以参考这篇博文（Android开发者选项——Gpu呈现模式分析），我们此次测试主要关注绿线（16ms线），红色条形（执行任务时间），蓝色条形（测量绘制时间）
掌阅
掌阅的流畅性方面是4款产品中表现最好的。大部分页面滑动效果流畅，未超过16ms线。
书旗
书旗这个和CPU测试结果一样，因为在某些页面存在持续性的动画，导致一直在渲染绘制，比如主页头部的水波纹特效。
QQ阅读
QQ阅读整体表现也很棒，但是有一个界面卡顿状况明显。书库界面，每每滑动，就会出现越过16ms线的部分，从图中可以看出，最底下绿色较多，对照博文中的信息可知，代表Input Handling（事件处理）Misc Time/Vsync Delay（UI渲染跟不上vSync的信号），猜测此处可能执行了大量的主线程任务，有可能和图片处理和图片复用有关，具体的可以对照代码进行分析。
OPPO书城
对比QQ阅读来看，同样是书城/分类界面，表现就很优异，基本上都在16ms线以下。可能测试的页面较少，未发现有特别卡顿的页面。
总结：整体来看，OPPO书城表现最优异，其余三者不相伯仲。可以看出动画的使用会影响模式分析结果，如书旗首页头部水波纹动画，QQ阅读、书旗小说、掌阅听书指示动画。
2）GPU过度绘制过度绘制（Overdraw）描述的是屏幕上的某个像素在同一帧的时间内被绘制了多次。在多层次重叠的 UI 结构里面，如果不可见的 UI 也在做绘制的操作，会导致某些像素区域被绘制了多次，同时也会浪费大量的 CPU 以及 GPU 资源,所以我们应该避免过度绘制。具体关于过度绘制的知识点可以参考博文Android性能优化-过度绘制解决方案，然后对照下图进行分析。
掌阅
毫不夸张的讲，掌阅的过度绘制优化是我见过最好的，做的和系统app一样优秀,他们应该下了不少功夫进行过度绘制优化。只有极少部分有4x的，大部分都是1x,2x,十分优秀。翻页界面，漫画界面等等，表现十分良好，大家可以自己按照博文的步骤，进行测试。有部分界面有1x,应该可以去掉的，有优化空间。
书旗
书旗的书城界面，过度绘制比较严重，存在优化空间。可能是由于控件背景未移除，导致过度绘制严重。大量二级三级页面都是红色的，需要进一步进行优化。值得表扬的是阅读界面，没有过度绘制的现象。
QQ阅读
QQ阅读过度绘制问题比较明显，挑几个比较直观的地方说
侧栏过度绘制严重，这个上面博文中有解决方案，可以参考下，看下是否能解决。部分二级页网页形式，存在3x重绘。
书籍详情页和读书界面有过度绘制情况，具体情况可以以后慢慢分析，逐渐解决。
对比下QQ阅读的书城和掌阅的书城，如下图（左掌阅，右QQ阅读）
可以很直观的看出差距，也许我们与掌阅差了一个背景色的距离。
OPPO书城
书城也有部分页面存在过度绘制问题可以看出我们的书架页面和QQ阅读书架页面是有差距的，QQ阅读是1X，2X，我们是3X，4X，可以向主线同学学习，进行优化。听书界面也存在过度绘制。
最严重的问题出现在夜间模式场景下。打开夜间模式后，所有界面都增加了1x，漫天绯红，惨不忍睹。现在主流的app夜间模式都是采取控件换肤模式，我们也可以采用这种方案解决这个问题，而不是添加一层半透明遮罩。
总结
这一环节掌阅大比分胜出，QQ阅读和OPPO书城表现较差，这方面还有较大的优化空间。
4.产品分析作为研发同学，也要有一些产品思维，研发可以说是接触产品时间最长的用户，也能代表一部分用户观点。平时有好的用户需求，交互逻辑等，都可以与产品同学交流，共同促进用户体验。因为此前未做过此类产品分析，此次分析主要参考此篇博文（从阅读、交流场景的功能设计，对四种阅读类APP进行竞品分析）思路，均为个人观点，如果不合理的地方，欢迎批评指正，交流学习。以下所有产品分析，因OPPO书城未在应用市场上线，只参与部分分析。
产品分析从以下几点进行分析：
1）用户与产品定位用户定位：
没有调查就没有发言权，我们首先了解下宏观上的产品定位。拿数据说话，从艾瑞app指数划分用户如下：
App项目男女35岁以下占比25-30岁占比掌阅63.436.694.8541.58QQ阅读53.9146.0995.0639.59书旗42.3657.6493.9339.63数据表明：掌阅男性用户较多，书旗女性用户较多，QQ阅读男女用户占比相当。大部分用户为35岁以下，其中25-35岁居多。
产品定位：
一般产品定位可以从企业的slogan看出。我们打开产品的闪屏页一般都会带有这句话。依次打开，发现如下：
掌阅：引领品质阅读。可以看出，掌阅主打品质阅读，较为关注书籍品质。书旗：不一样的阅读。可以看出，应该是较为关注用户阅读体验。QQ阅读：海量原著，想读就读。可以看出，QQ阅读较为关注书籍内容广度，体现在于书库资源丰富，从APP内的产品分类详细程度上可以窥见一斑。2）产品功能分析产品功能分析从以下三个部分进行解读：阅读需求，产品结构，功能分析。
1.阅读需求阅读分为电子书和纸质书，需求一般分为：
娱乐爱好：各类网文，男频女频等知识积累：专业书籍，各类出版物等新型阅读：漫画杂志，听书等我们着重分析前两类需求，总结出来的需求大致如下：
KANO模型用户需求基本型需求阅读稳定性，便捷性等期望型需求推书，搜书等魅力型需求用户交流，阅读效率等三个产品，基本上都实现了以上的需求对应的功能。
2.产品结构为了给用户提供1中表格的功能，产品设计方面就要围绕此表格进行设计，还有部分扩充。我们一一看下3款产品，提出优点与不足。此次分析的四款产品均为底部多tab结构，清晰明确。体现出了同质化设计，用户切换成本较小。而且此设计经调研，可运营可扩展性强，属于业内主流设计，如微信，QQ等。
掌阅
优点：
书城划分合理，分类清晰明确，比较符合直观感受发现页面定位为书友交流，其余三款均有此功能，但入口较深。缺点： 本地书架缺少书名提示
书旗
优点： 单独拎出免费专区，方便用户查找。
缺点： 书城定位模糊，仅突出了4大类，具体分类页放在了精选下一个小条目。
QQ阅读
优点： 书库页分类详细，种类繁多。用户可挑选自己喜欢的类目进行查阅。
缺点： 书库页不能滑动切换分类，而且书评广场入口隐藏较深。作为QQ类产品，用户量庞大，应突出书评交流。
OPPO书城
优点： 分类页既有掌阅的简洁大方，又有QQ阅读的详实充足
缺点：听书分类和漫画分类不太明显。
3.功能分析从用户需求出发，阅读的本质就是读书，我们从读书前，读书中，读书后三个部分进行功能分析，看一看三款APP的合理与不合理之处。
读书前
读书前的功能分析主要分为，找书，搜书，推荐。
推荐方面，均有热门推荐，排行榜，相似推荐等功能找书方面，书库目录子条目清晰，分类明确搜书方面，搜索页热门推荐，搜索关键字自动补全等。三款产品做得中规中矩，可以算是打成平手。值得一提的是，QQ阅读中有阅读基因功能，后期可以让用户指定喜爱的类别，进行修正。掌阅和书旗出现在引导页，app内未发现修改入口。
读书中
读书中的功能分析主要分为，阅读功能，段落评论和批注。阅读功能属于阅读类产品特有的功能，三款产品设计也都是大同小异，不做过多评价。值得一提的是段落评论功能，这个设计有失也有得，失在于打破了安静的阅读环境，引诱用户点击，降低用户阅读效率。得在于增进用户交流，深化用户阅读体验，类似于B站弹幕类，体验较好。
读书后
读书后，主要分为书评，书友交流。书评功能做得都比较好，在当前阅读页的设置中，都加入了书评入口，方便用户进行阅读评论，掌阅的书评入口在二级设置页，稍微有点深。书友交流功能三款产品设计差异较大，分析如下：
掌阅，单独划分发现页，对书友交流重视程度较大书旗，未见单独的书友交流功能，主页划分出一个原创tab，可能产品侧重点不同QQ阅读，包含书友交流，名为书评广场，个人感觉可以单独拎出来做产品方向，值得深入挖掘总结
三款产品在此分析环节，表现均优异，平分秋色。大方向上各有侧重，具体设计上可以看出同质化，猜测产品同学也经常进行竞品分析。此处建议多从阅读本质出发，多从用户角度出发，结合KANO模型，设计出用户喜欢，满意的功能，尽量避免为了需求而需求的伪需求发生。
总结通过竞品分析，我们可以了解到竞品的优势和劣势，知己知彼，百战不殆，从而更好的去优化我们自己的产品。当然以上只是简单的技术分析，更详细的可以参考以往同学写的内容，进行补充。此次也重温了下许多基础知识，确实是一个快速了解产品的好办法。当然，写的比较仓促，如果有错误的地方，欢迎大家指出问题，进行修改，互相学习。
附录：竞品分析文件：