越来越多 app 在结构上都在同质化，Banner＋时间线的方式成为了大部分 app 共同的“首页”。从某个角度来看，也是国内 app 生态圈的无奈之举。要想办法延长用户停留时间，又希望可以通过内容分享到社交平台来获取更多曝光和新用户，而官方运营的文章类内容看起来似乎可以满足这两个诉求，再加上各类产品天生的话题性（比如旅游app写攻略，医疗类app写健康知识），造就了现在每个产品里都带着一整套的内容浏览体系。但现阶段来看，大多数的 app 的内容浏览体系，不说乏善可陈，不少连能用的级别都达不到。并且对于制作内容的后端（文字撰写），也很少看到令人满意的方案。
我尝试着写下自己对于 app 内内容浏览方案的思考。大概分为四部分：
- 文章内容的撰写与管理
- 文章页面需要具备的功能特性
- App 端内容浏览的实践
- App 端第三方内容浏览的实践
文章内容的撰写与管理
要做内容浏览，首先要有制造内容的后台。这个后台不能像其他的数据平台或者管理平台，而是应该参考现代博客的后台。例如使用 分类|文章|编辑器 的三栏布局，可以清晰的呈现和浏览应用内的各个分类栏目内容。和博客不同的是，每个文章都必须归属于一个或多个分类，而不像博客有一个主时间线。
第二个需要具备的功能是草稿和定时保存。在线编辑的最大问题是数据的易丢失性，如果没有避免因为意外丢失撰写的文字的方法，那么就很容易失去内容运营人员的信任，使得他们转而去用离线编辑工具，而这对于网络编辑来说其实是不可接受的（原因在下文会解释）。
第三，一个靠谱的文章编辑器是关键。好的在线文字编辑器少之又少。考虑到大多数文章都会在手机和桌面端两侧被浏览，那就不应该让编辑器来指定元素的样式，更不应该允许编辑器设置具体的字体——毕竟，你根本不知道用户的手机上有什么字体。所以比较理想的编辑语法其实是 MarkDown，无样式纯语法，然而现实是大多数内容运营人员不知道也没想学习这样一门新语法，所以我们只能退而求其次，用一些简化的处理器（比如彩程设计做的Simditor来限制运营人员无尽的脑洞，然后用预设好的桌面和手机端的样式来统一各终端上的体验。这样一来，就不能允许运营人员用 Word 或其他在线编辑器创建一篇包含丰富自定义样式的文章再粘贴过来，否则会产生大量错误的样式。
第四，和产品业务的强联动。原本这也算是编辑器的一部分，比如说，一个电商 app 的运营文章一定会需要插入很多自家的商品。糟糕的做法就是运营人员自己编辑图片和文字，最后再设置一个超链接。好的做法则是编辑器本身集成插入商品的功能，可以按照 id、商品名搜索并插入到文章中，也可以只插入超链接。毕竟一个良好格式化的商品样式可以很好的兼容桌面和手机端，而图片只能忍受模糊或者拉伸，并且还没法及时更新。
第五，良好的元数据设计。很多人看到文章就只能想到正文，但出于 SEO、传播和效果的考虑，我们还需要有一些元数据让运营人员单独设定，如：
- 标题。用久了微信，很多人已经不知道怎么给文章写标题了。最基本要考虑的是，标题在 app 里怎么展示，是否有换行的机会。这样才好拿捏给多少字数避免被截断省略。
- URI。这个大概只有写过博客的人才会理解吧，就是文章的具体网址部分怎么写。国内某知名IT新闻站最喜欢在URI上搞个大新闻。
- 封面。打从 Medium 引入超大封面以来，给文章配一个大图就成为了很多场合的标配。另一方面，在不同场合，封面的呈现形式往往还不一样，有时是在标题上面，有时又是作为标题的背景，更有时还会有 Parallex Scroll 的效果，所以作为一个元数据来设置再合适不过。
- 标签。这个就不用我多说了吧，SEO。
- 摘要。考虑到在 app 中的时间线展示，手动写一段摘要要好过让程序断句在莫名其妙的地方。
- 分享文案。当用户分享到微信、微博的时候，为他们准备一个漂亮的标题和微博文字是一个不错的选择。
- 是否允许评论。总会有些文章不适合开启评论功能，你懂的。
文章页面需要具备的功能特性
首先要注意这几个基础特性。
- 文章就要有文章的样子，url 绝对不能搞成一大串参数，反面参考如微信公众账号的文章。几乎没法传播。相反的，做成类似 abc.com/post/2016-01-01/why-i-leave-the-company 就是个容易看的多的例子。
- 你永远不知道用户是在手机还是在电脑上看你的文章，所以一定要考虑适配桌面端的样式————最不济，你可以把页面的内容宽度设置为最大 540，保持样式和手机上一致。
- Open Graph、Web Schema、AppLinks、Twitter Cards 支持。要让网页在微博、微信里有漂亮的带有缩略和预览图的展示，就务必要支持，无非就写几个 meta 的事情。微信没有公开提到的支持，但似乎转发时会读取 Open Graph 标签。
- 支持 Apple Search。
上述都是一些不痛不痒的细节，接下来则是关系到传播和导流的大事。
文章页面在不同环境下打开的处理
尽管 Apple 在力推一些跨 app 的跳转和内容浏览方案，但中国的 app 大多都喜欢自己发明一个 WebView 来打开第三方网页，所以当我们希望用文章的传播来为 app 带来下载量时，就有了下面的痛苦而复杂的方案。
在 Safari/第三方应用的 Safari View Controller 中打开
在 iOS 9 开始，Apple已经设计好了几乎完美的方案，但前提是按照 Apple 玩法，得重度的依赖于 Safari 或者指望第三方应用都能乖乖去用 Safari View Controller 来打开第三方页面（在中国这几乎不现实，但愿几年后能有所改变）。在这种情况下，网页（和自己的应用）只需要支持以下两项即可。
- Universal Links，意味着当用户在 Safari 里打开我们的网页时，如果 app 已安装，iOS 就会自动跳转到我们的 app 来展示对应内容。
- Smart App Banners，会自动判断用户是否有安装我们的 app，然后展现 App Banner 和“打开”或“安装”按钮。Safari View Controller 能够展示这些 Banners 极大程度的简化了在第三方应用里通过文章网页安装 app 或者跳转激活 app 的复杂度。
在第三方 app 的 WebView 中打开
WebView的最大限制是，让我们无法判断自己的应用是否已经安装，而且 Smart App Banners 也不能工作，所以我们就不得不做一些比较蠢的设计：
- 在网页的顶部、底部或者其他不影响布局的位置，显示一个 app 的宣传条，同时提供“安装”和“打开”按钮。
很多 app 没有考虑到“打开”的重要性，就很容易导致用户在网页里看到了感兴趣的商品或者活动，却因为网页不是在自家 app 内打开而无法点击收藏或查看详情。
紧接着我们会遇到第二个问题，很多 app 对 WebView 跳转到 自定义 URL Scheme 会做些（吃饱了撑的没事干的）限制，比如微信。这个时候我们的“打开”按钮（甚至“下载”按钮）都会失效，点击不会有任何反应。这时候唯一的办法是
- 对于涉及自定义 URL Scheme 的按钮，在点击后，展示“在 Safari 中打开”的引导。
这不能从根本上解决问题，但也算是唯一的办法。当然，考虑到这里最大的大头“微信”，如果你能找到张小龙刷脸开白名单，那么在微信里你的网页跳转 app 至少是可以畅通无阻的，参考京东、豆瓣。
除此以外，你在微信里大概还会遇到跳转到 App Store 的链接也被屏蔽的问题。唯一的办法是，在微信里打开时，App Store 的链接需要跳转到你的应用在腾讯应用宝的页面，应用宝会帮你在微信里打开 App Store。这是微信给同公司的产品应用宝拉量的策略，恶心，但没办法。
说回来，如果你是一个看重数据的产品经理或者运营，那么你肯定还有一个需求：统计运营页面、文章页面在各个平台的浏览量和转化率。所以还有一个要做的事情就是
- 通过 UserAgent 判断并统计文章的访问渠道。当然，你得预先定义好要统计哪些主要渠道，比如微信、微博、QQ 等。
在自家 app 内打开
这大概是最容易被忽略的一部分了。通用的做法是用一个 WebView 来打开这个网页，然后再加上前进后退刷新分享这些基本功能。然而实际上需要做的却远不止这些。
- 因为是在自家 app 中打开，所以不需要展示 app 的宣传条。所以网页要根据 UserAgent 来判断是否是在自家应用中被打开。
- 文章中出现的涉及到自身业务的跳转，比如某个商品的超链接，（在第三方应用中打开会访问到对应商品网页），在自家 app 内点击后，则 app 应该捕获这次跳转，然后打开应用内的商品界面（而不是网页）。
- 同样还有统计访问渠道，要把自家 app 也记进去。
上述的是相对简单的做法，更复杂的做法则是 app 不再只是简单打开一个 WebView，而是打开一个做了一定样式的 view，其中包含一个 WebView 来显示正文内容，而文章标题、封面、评论甚至相关内容推荐等则用原生的组件来实现。这样更容易实现一些华丽的效果，比如标题的 Parallex Background。
App 端内容浏览的实践
前面说的都是 Web 端要做的事情，相对的，app 本身也有一些工作是不可或缺的。
- 如上文所说，首先必须设置好 UserAgent，让页面能够判断是在自家 app 内打开。大多数 app 都没这么干，有些是懒得，有些则是用别的方法，比如自己在 url 后面加参数，前提是记得分享的时候把参数干掉。而我觉得还是 UserAgent 统一、简单。
- 改进分享的样式。在国内常常见到的情况是，一个只支持几个主流应用的分享组件占据了大多数 app。对于 app 内的非常规内容这样可以理解，但对于常规内容比如图片、网页，这就非常的愚蠢了。大多数 app 连一个 在 Safari 中打开 都没有，更别提支持 AirDrop 分享给附近的人。其实简单的解决方案是，在常规的分享下面，增加一个“更多”的按钮，点击后展示 iOS 系统的 Activity View Controller 即可。（直接展示固然也行，但不免被诟病对被惯坏的小白用户不够友好）
- 或者也可以进一步，如上文所说的，不用简单的 WebView，而是混合一些原生的组件来展示标题、封面、评论等，可以在相当大的程度提升体验效果。
App 端第三方内容浏览的实践
最后这部分相对就没那么重要，更多是避免被别人家挖坑。
- 对外部页面，首先得能识别出来，其次最好用 Safari View Controller 来打开。对于用户来说好处多多，比如和 Safari 公用 cookie 和 Keychain，意味着我在 Safari 里登录过的网站，通过你家 app 打开，也就不需要再登录，可以直接进行操作（如收藏）。
- 你可能需要统计用户打开的链接。风险控制，你懂的。
- 使用 Safari View Controller 的话，自由度想对就没那么高，那么想要对这个网页做的操作的入口就得放在 Activity View Controller 中。
暂时想到这么多。有什么再补充。
