独立产品研发系列文章第三篇

独立产品研发系列文章第二篇

上篇文章从 iOS 开发的视角介绍了独立 App 从确定需求、开发、上线中所用到的一些资源。因为各项资源的限制，也只能完成一些仅上架于苹果 Appstore 的工具类 App。

这篇文章就着眼于一个具备完善功能的全平台产品的研发，研发过程中我们碰到的一些问题及其解决方案。在这里给大家分享一下我是如何一步步构建自己 公众号、小程序 + App 完整产品生态 的。

1、产品目标

产品目标往大了说，是指产品实现的价值。即使有用户场景存在，但做出来的产品没有价值（不能盈利，用户量极少），那也就没有存在的必要。

甚至再大点，从 产品的愿景 讲起...

打住，先不用考虑这么多，不然你的产品可能就只能存在于你的不停设想中了。

在资源有限，人力有限，投入有限的情况下，我们的产品目标就很明确了，它要解决哪些问题？或者它需要完成的功能！

比如说，我在做 文件管理器 的时候，MVP 的产品目标就很明确：实现手机和电脑之间的文件传输。

在完成了 MVP 需求之后，自然而然的带来了一些其他需求，有的来自我自己的产品计划，更多的来自于用户反馈：

• 1.0.0 完成手机和电脑之间的传输
• 1.1.0 实现图片、视频、音频文件的预览或者播放
• 1.2.0 实现文件分组、移动、删除、压缩、分享功能
• 1.3.0 优化播放器
• 1.4.0 完成安全验证功能：手势验证码、生物认证
• 2.0.0 添加内购功能
• 2.1.0 完成文件扫描功能
• ....

明确一个目标，它不需要很大，但可以实施，一次聚焦一个点，错了也先坚持下去（不做完你怎么知道是错的呢 ◔ ‸◔？），把它完成，然后复盘。

2、产品原型

在上篇文章中，我有提到自己其实尝试了很多原型设计工具，最后结论是 设计原型的时间都足够自己使用 xib 将页面搭建完成了。

在这里推翻一下自己 ,,Ծ‸Ծ,,

在做个人工具类 App，且毫无后续规划，只想着将其完成上线时，确实会带来这种想法。

随着产品的迭代，这种毫无原型规划，做一步考虑一步的处理方式，会给自己未来的开发造成很大的困扰。设计原型的过程其实是梳理产品逻辑的过程。

推荐几款 原型设计工具，我目前常用的可能就是 墨刀 了。

3、项目管理

在经历了独立的 iOS App 开发上架之后，我发现了一个很严重的问题。就是 毫无项目管理概念，有时间了做一下，想起来了做一下，偷懒了就不做了。

因为是自己的产品，自己设计，自己开发，且 MVP 版本大概率没有付费用户，也就没有给用户负责的心态。

这其实会严重阻碍项目进度，长期的无计划开发，还会造成项目流产。

在公司，经历了几年的迭代管理，发现使用项目管理工具进行个人项目的管理还是行之有效的。当我们有了明确的产品目标，有了对应逻辑自洽的原型，进而将任务进行拆解，就顺理成章了。

这里我用的是 coding.net 来进行项目管理，同时它也可以用来做代码托管。

将任务项按照小时的粒度拆分，一方面方便任务管理，另一方面也方便测试 case 的编写。在正式编码前，我目前的习惯是先将测试 case 写完，这很有必要。

原型是对产品逻辑的梳理，测试 case 则是对研发细节的梳理，完整的测试 case 可以引导我们完成正确的业务逻辑 ✅，也能避免很多业务错误 ❌。

4、技术选型

好了，到目前为止，我们做的都是一些准备工作，仍然没有进入到开发中。很关键的问题在于，开发只有自己，要完成文章开头的目标：公众号、小程序 + App 完整产品生态。

我们需要同时具备小程序、iOS 开发、Android 开发技能。编程语言的上手难度不高，问题在于同样的业务，需要三次开发成本。这显然不太现实。

通常情况下，我们可能会选用 web 来实现多平台的使用体验，甚至于抛弃 App，只做公众号 + 小程序生态。在产品初期，产品需求快速验证的情况下，这种方式也是非常可取的一种方案。

其实，稍微搜索一下就会发现，市面上还是有挺多跨平台技术实现的。要做到 App + 小程序，三端一套代码，可以用 Uni-App 来实现。它使用的是 Vue.js 前端框架，iOS 和 Android 则借助了 Weex 实现。

用于做一些个人产品，或者小型商业化产品足够了。

5、数据管理

小程序 + App 的实现方案解决了之后，还有另外一个关键问题，数据存哪？

如果只是一个工具类产品，那么数据存在 App 本地即可。但我们的目标是一个具备完善用户体系的信息平台，甚至于较为复杂的用户 UGC 社区怎么办呢？

Uni-App 提供了自己的 uniCloud 服务，使用 js 即可完成服务器开发工作，小程序和 App 可以免域名使用服务器。

在这里，我选用了另外一种做法，将数据托管到 serverless 平台 LeanCloud，小程序和 App 通过 LeanCloud 的 js sdk 访问托管数据库。

其开发版可支撑 3 万次 / 天的免费 Api 访问，同时也提供短信服务。可以顺利完成用户体系建设、用户数据上传、平台数据的拉取。

当超过开发版的访问次数之后，说明你的产品也有了一定规模的用户量，相信这时候，流量带来的收入也足够你开通按量付费的商用版了。

数据来源之骚操作

如果你想做一个天气 App，或者咨询类 App，没有天气和资讯类数据怎么办呢？

国内有很多 Api 市场平台，比如：

阿里云 Api 市场

腾讯云 Api 市场

百度云 Api 商城

聚合数据

EastApi

等等

这些市场一方面提供了收费 Api 服务，另一方面也提供免费的 Api。

• 如果你的产品有很好的流量变现方式，可以考虑使用收费 Api。

• 如果没有，可以考虑白嫖。但 100 次的试用，测试阶段就很快消耗完了。怎么办呢？

这里就可以将 serverless 数据库托管平台 leancloud 和 Api 商城结合起来使用，以每日天气为例，如果 serverless 数据库托管平台没有查询到数据，则可以请求 Api 商城，之后将数据存入到数据库托管平台。

可是，100 次还是不足以覆盖所有城市怎么办呢？发挥白嫖精神，多申请几个平台吧。

6、上线运营

至此，我们搞定了小程序、App 以及 Server 的开发工作。上线怎么办呢？

小程序比较好说，微信公众平台 按照引导一步步申请小程序即可。

iOS 上架需要一个付费的开发者账号，这是一个门槛，长期运营的话，还是建议在苹果开发者官网申请一个账号，现在申请比较简单，苹果手机下载 Developer App 就可以付费了。

Android 上架则需要软件著作权了，正常申请可能需要 1-2 两个月，也可以付费找三方中介完成。

继续发挥白嫖精神，App 和 小程序配置的一些运营位，图片或者音视频资源存放在什么地方呢？

公众号媒体资料库可以解决这个问题。将图片和音视频资源存到公众号后，获取原链接，App 和 小程序即可访问了。

7、获取收益

较为简单的流量变现方式就是 广告 了。

可现在各平台对于流量主的接入要求越来越高，个人开发者基本很难完成广告接入。

• Uni-App 提供了一键接入功能，具体可以参考 文档。

• 公众号积累粉丝后，也可以开通文章内广告位。

• 小程序达成 1000 个 UV 访问后，可开通流量主权限。

8、小结

至此我们就完成了文章开头介绍的 公众号、小程序 + App 完整产品生态。

按照以上步骤，我也完成了三个产品的操作，可以扫码体验下：

• 代码埋点
• 可视化埋点
• 无埋点

这篇文章主要介绍了 无埋点 的想法和实践过程。

1、代码埋点

代码埋点，即在需要埋点的节点调用接口直接上传埋点数据，第三方数据统计服务商也大都提供了代码埋点的 api，非常方便。

但是带来一个问题，埋点代码散落在业务的各个地方，和业务耦合严重，尤其是在页面改版，业务变动的过程中，旧的埋点不知道怎么处理，新的埋点不知道需不需要，当埋点数量上来之后，对散落的埋点代码的维护是个灾难。 当然你可以通过宏、工厂类去简化埋点代码，但并不能改变什么

1
2
3
4
5
6

- (void)viewDidDisappear:(BOOL)animated {
    [super viewDidDisappear:animated];

    // 埋点
    APE(kEvent4001);
}

2、可视化埋点

可视化埋点，即通过可视化工具配置采集节点，在前端自动解析配置并上报埋点数据，从而实现所谓的“无痕埋点”， 代表方案是已经开源的 Mixpanel。

3、无埋点

无埋点或者叫做全埋点，它并不是真正的不需要埋点，而是采集全部事件上报。剩下交给服务器做过滤，筛选出有用的数据。

无埋点进一步优化，可以通过服务器下发配置文件，直接由前端进行事件过滤。

为了 kpi，基于无埋点的思想，造了一个轮子 WKTrackingData。

这里把 WKTrackingData 实现中碰到的一些问题与想法做一下记录。

实现思想很简单，所有代码如下：

其中 WKTrackingDataManager 负责所有的数据管理，事件追踪配置。

WKTrackingDataViewPathHelper 负责 event_path 生成。

AOP 模块负责所有事件的追踪。

详细的用法可以点击 github 查看。

如何唯一标示某个事件？

这里涉及两个问题，一是事件怎么表示？二是如何确保事件的唯一性？

事件的表示

对于事件的表示，使用了 event_path 实现。核心思想是对于触发了某个事件的 responder ，顺着其响应者链条，构建出其响应者链条的 path。

生成的响应者 path 如下：

1

"event_path" = "#buttonClick:#UIButton#UIButton[0]#UIView[0]#ViewController#...#UIApplication#AppDelegate

唯一标示某个事件

这里有个问题是，某些业务场景下，同一个 button 或者其他控件，会因为其某些属性的改变，在业务上表示的是多种不同的事件。

如，首页一个 button 在未登录时显示 点击登录，登录未实名时显示 去实名等等。

那么对于这同一个 button 来说，它的视图树并未发生改变，生成的响应者 path 就是相同的。

类似的业务场景还有 UISwitch 的开关，UISegmentedControl 的 indexSelect，UIStepper ，以及 UITableView 和 UICollectionView 的 cell 点击。

针对于这种情况，WKTrackingData 在生成 event_path 时，有选择的将控件自身的不同属性也拼接上，生成的 event_path 就变成了这样：

1

"event_path" = "#buttonClick:#UIButton#UIButton[0]#UIView[0]#ViewController#...#UIApplication#AppDelegate#currentTitle=Button#state=1#enabled=1#selected=0";

业务扩展

继续考虑另外一种业务场景，首页有一个 banner 轮播图，

banner 每一个广告位的图片和跳转 url 都是由服务器下发的，且位置可配置。

这时 banner 的 每一个 index，对应什么页面都是不固定的，0 位所对应的事件，由 event_path 是无法确定的。

这时就需要拼接上具体的业务参数，才能够唯一标示某个事件，如 url。

WKTrackingData 也提供了业务方的参数扩展，允许业务方拼接上自定义参数：

对于不希望进行事件追踪的控件，可以通过 wk_ignoreTracking 进行忽略：

1

self.slider.wk_ignoreTracking = YES;

其他问题

在对于不同事件的追踪上，WKTrackingData 基于面向切面的思想，使用 runtime 直接做方法交换。

但是对于 UIAlertView、UIActionSheet、UITableView、UICollectionView 的统计，需要交换其 delegate 的方法。

• 如果其 delegate class 已经实现了相应的方法，那么直接交换即可。

• 如果其 delegate class 未实现相应的方法，这时仍然想要追踪到这些事件，那么就需要手动添加一下对应的 delegate method 的实现。

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

- (void)wk_swizzleInstanceSelector:(SEL)origSel_ fromClass:(Class)fromClass replaceSelector:(SEL)replaceSel_ originNotImp:(SEL)notImpSel_ {
    
    Method originalMethod = class_getInstanceMethod([self class], origSel_);
    
    if (originalMethod) {
        [self wk_swizzleInstanceSelector:origSel_ fromClass:fromClass replaceSelector:replaceSel_];
    } else {
        Method notImpMethod = class_getInstanceMethod(fromClass, notImpSel_);

        // 如果delegateClass没有实现 origSel_ 方法
        // 则给delegateClass的 origSel_ 添加 orginReplaceMethod 的实现
        BOOL didAddNotImpMethod =
        class_addMethod([self class],
                        origSel_,
                        method_getImplementation(notImpMethod),
                        method_getTypeEncoding(notImpMethod));
        if (didAddNotImpMethod) {
            NSLog(@"%@ did add not imp method %@" , NSStringFromClass([self class]) , NSStringFromSelector(notImpSel_));
        }
    }
}

具体实现在这里

但在实践过程中发现，UITableView、UICollectionView 的 delegate 对象，在未实现相应方法时，手动给 tableView:didSelectRowAtIndexPath: 添加了 implementation，仍然不会触发。

我们先来看一下，正常 tableView:didSelectRowAtIndexPath: 调用栈：

这里面，UITableView 前后会调用这四个方法，进行 cell 点击的响应。

• 1、[UITableView _userSelectRowAtPendingSelectionIndexPath:]
• 2、[UITableView _selectRowAtIndexPath:animated:scrollPosition:notifyDelegate:]
• 3、[UITableView _selectRowAtIndexPath:animated:scrollPosition:notifyDelegate:isCellMultiSelect:]
• 4、[TableViewController tableView:didSelectRowAtIndexPath:]

根据调用顺序可以发现 UITableView 在真正调用 delegate class 的 tableView:didSelectRowAtIndexPath: 前，会先触发自己的 _selectRowAtIndexPath:animated:scrollPosition:notifyDelegate:isCellMultiSelect: 方法。

直接给 _selectRowAtIndexPath:animated:scrollPosition:notifyDelegate:isCellMultiSelect: 打一个断点进入汇编查看，发现：

如果 delegate class 如果有实现 tableView:didSelectRowAtIndexPath: ，则一切正常，会完成 tableView:didSelectRowAtIndexPath: 的调用。

但如果 delegate class 未实现 tableView:didSelectRowAtIndexPath: ，即便手动给 tableView:didSelectRowAtIndexPath: 添加 implementation，也不会尝试响应 tableView:didSelectRowAtIndexPath: 了。

跟随汇编调用发现，会直接 jump 到另外一个指令。

WKTrackingData 这里换了种做法，直接对 [UITableView _userSelectRowAtPendingSelectionIndexPath:] 进行了交换（UICollectionView 类似）。 实现了 UITableView、UICollectionView 的 delegate 对象，在未实现相应方法时对 cell 事件的追踪。

4、小结

多个event_path对应同一个事件

考虑另外一种情况，线上存在多个版本，不同版本的页面都有一些细微的差别，那么对于同一个事件来说，它就可能存在多个 event_path。

在实践过程中，这一块的映射，就需要服务器同学的配合了，可以让服务器做成后台可配置的。

事件统计优化

在 业务扩展 中提到了如何添加业务参数，WKTrackingData 使用了分类实现。

在实践过程中发现，全埋点的方案，造成了大量流量的浪费，有好多事件不需要啊[(ŏ_ŏ)]。

进一步优化，可以由服务器下发配置文件，里面直接包含了，希望客户端上报的所有事件，只有和配置文件中符合的 event_path 才进行上报。

这一步的业务参数获取，也可以不采用 WKTrackingData 的实现，直接使用 kvc 获取。

形如：

1

key_path = "viewController.banner.url"

看到这里就点开 WKTrackingData 给个star吧，有问题可以在guthub上提issue，或者下方评论～

独立产品研发系列文章第一篇

作为一个移动端的开发者，最大的愿望当然是写一个app坐等收钱了( ͡° ͜ʖ ͡°) 。

那么在独立完成一个app的路上会碰到些什么问题呢？ 最近上线了一个自己的 App，在这里把碰到的问题和自己的解决方案分享给大家。

1、确定需求

每个人想做独立 App 的出发点可能都会略有不同。

往大了说，看到了一个人们迫切的需求，这个需求的解决方案可以改变世界（就差一个程序员了）。

往小了说，就是想在 AppStore 上看到自己的 App，它可能只是新技术的试水之作（ iOS8 的 today extension 出了之后，AppStore上出现了很多特色的基于 today extension的 App），也可能是真正能解决一些自己生活上某些不方便的辅助 App（文件操作类app，各种功能贴心的天气类应用）。

确定一个需求，不管大小，这是能支撑你一直做下去的动力。

我自己基于媳妇的需求，做了一款文件操作管理的 App ----“文件管理器”。

“文件管理器” 将手机作为服务器，允许其他同wifi下的终端能够通过浏览器管理操作手机上的文件，可以通过浏览器进行文件夹分组，文件的拷贝、移动、下载与上传。

当确定了这个需求点之后，前前后后做了差不多三个月时间，才把这个项目上线。（ 顺便学习了下swift )

2、App 的原型设计和界面交互

当有了需求及其解决方案之后，一些模糊的原型和用户操作脑海里也会有一些概念。下面就是将具体的页面与交互确定下来了。

笔者也尝试了几个原型设计工具，然后放弃了。

尝试过程中发现，熟悉原型设计工具并使用其将页面设计出来耗费的时间，已经足够我使用xib把界面搭好了。之后笔者使用纯手工画草稿的方式，解决了自己原型的问题。

后来做其他产品的过程中，发现原型还是很有必要的，这其实是一个逻辑梳理，逻辑自洽的过程。

3、App 的小图标怎么办？

确定了原型之后，整个项目的框架，自己内心也大致有了个概念。抛开代码层面的问题，还剩下一个独立开发者怎么都绕不过去的问题！！

项目中使用的各种小图标怎么办？

在这里给大家推荐几个笔者使用过的图标库：

• 阿里爸爸的图标库 -> 整套整套的矢量图标，随意搭配颜色和大小，业界良心呐。当然如果是商用还是要获得作者授权的～
• icons8 -> 56,500 Free Flat Icons！！各种平台下的图标都有，还有mac版软件哦～
• iconfinder -> 同样整套的图标，商业化模式更加明显。

4、自测与内测

在公司我们有测试，有产品，有其他同事一起合作，帮助我们不断完善 App。但是独立开发者怎么能最大程度上提早发现和避免 bug 呢。

4.1 自测

以前交由测试美眉的工作就只能自己来喽～当然除了手动测试之外，我们还可以养一个测试猴子，帮助我们完成测试。

4.2 招募内测

既然是独立 App，那么我们就不只是一个开发了，还身兼产品，运营，客服....同样的 App推广与宣传也需要我们自己身体力行了，从朋友、同学、家人开始，在各种社交网络上表示我的独立 App快要完成喽，来帮我点点吧～

内测用户的作用不只是在测试上，他们对我们更大的帮助是可以提出新的需求和建议，这是能更大程度丰满和完善我们 App的。

4.3 测试包分发

如果比较方便能获取到内测用户设备标示的，可以使用诸如蒲公英、fir.im等的内测托管平台。（设备有限制）

如果内测用户设备标示不太容易获取到的，我们可以使用苹果 iOS8 之后开放的 TestFlight。(多达 1 万个内测名额)

5、上架的截图

为什么要把app上线的截图单拎出来呢？对于我们独立开发者来说，没有那么多推广渠道。我们 App的入口和门面就是我们 Appstore 产品展示页面的截图和描述了。

如果产品展示页的截图太 low，那么我们就有可能会流失掉这个看到我们 App的用户。

在公司我们有 UI 有产品帮助我们完成产品展示页面的截图，如果是我们自己怎么获取合适尺寸的截图呢。

5.1 在模拟器上截图

直接使用模拟器截取应用某些页面当然是可以的，但会显的有些粗糙。

5.2 稍微美化的方法

在这里给大家推荐一个免费网站shotbot，可以上传素材，制作出一整套格式统一的产品展示图。

2022-04-11 备注：我自己后来写了一个 Mac App 专门用于自己制作上架应用的截图

6、笔者用到的其他资源

当涉及到某些页面交互与设计时，单纯的三方提供的工具也好，人家做好的图标也好，或多或少会有那么些不尽如人意的地方。

那么，自己来ps吧！

当然对于大部分开发来说 ps 的功底并不扎实，还有些童鞋压根不会，怎么办呢。

给大家推荐两个网站：在线ps、美图秀秀网页版

不用下载繁重的 adobe 软件，使用浏览器就可以轻松的实现一些简单的ps效果，对于我们不怎么会 ps 的童鞋来说，这是个福音。

除了 ps 相关的，我们 App 的 Icon 也是一个非常困扰的问题。同样给大家推荐一个网站MakeIcon，直接上传 1024x1024 的 logo ，就能自动切出来其他所有尺寸的 Icon了。而且，支持 iOS10 的 iMessage 哦。

7、小结

笔者是在没有 UI 帮助下使用现有的一些资源完成自己的开发，有 UI 的童鞋请出门右转朝南墙不送￣ヘ￣。

开始有自己做 App 的心思不是一两天了，直到最近把一些需要的东西捋顺了之后才正式开始着手做。当然最重要的是需求确定下来了，顺便学了一下 Swift。

在开发过程中笔者也有过1周没敲过几句代码的经历，然后发现在做独立 App 的时候需求才是真正能驱动自己坚持下去的动力。需求不在大小，最重要的是能解决问题。

随着开发的深入，需求也在慢慢的增加，Airdrop 共享，iCloud 集成，ShareExtension 开发等等都未完成，嗯，加油一点点迭代吧～ʘʚʘ（我是不会说出来我做这个 App 的初衷是为了在 pc、手机、pad 上共享我的"收藏.avi"的）

附上个人app的地址----最简洁的文件操作管理方式-文件管理器

2022-04-11 备注：App 已经搜不到了，没有一个好的变现方式，卖给了一家外包公司。卖出之后，也引起了我很多思考，详细的总结可以看下一篇文章。

原文发在简书上，后来简书被盗，其他文章一直被封，现将所有博客都迁移到 github.io。